I have the following markdown snippet which will be visible on Github:
1. Ask a supervisor for a `cmprod.pem` file and move it into the `~/.ssh` folder.
2. Run `chmod 600 ~/.ssh/cmprod.pem`
3. Run `eb ssh` and type `yes` when it asks if you would like to add the key to your keychain.
4. Once connected via SSH, to access the application's source code, perform the following steps
- `sudo docker ps`
- Copy the desired value from the `CONTAINER ID` column
- Run `sudo docker exec -it $CONTAINER_ID rails c` using the copied value.
The problem is that the nested list (the three bullet points under step 4) are not formatting correctly. They end up looking like this:
Ask a supervisor for a cmprod.pem file and move it into the ~/.ssh folder.
Run chmod 600 ~/.ssh/cmprod.pem
Run eb ssh and type yes when it asks if you would like to add the key to your keychain.
Once connected via SSH, to access the application's source code, perform the following steps
- sudo docker ps
- Copy the desired value from the CONTAINER ID column
Run sudo docker exec -it $CONTAINER_ID rails c using the copied value.
This depends on which ruleset you are using. According to Commonmark, which GitHub uses (and I'm assuming is relevant here due to the [github] tag), "a list can interrupt a paragraph. That is, no blank line is needed to separate a paragraph from a following list." And Example 280 of the spec even shows an example similar to yours. If its not working for you with a Commonmark parser, then that would be a bug.
However, if you are not using Commonmark (or as a workaround to any Commonmark bug), then the Markdown rules require you to have a blank line between a list and the preceding paragraph. As the text in item 4 of your parent list would be a paragraph (inside the list item), then that paragraph and the child list item which follows the paragraph would need to have a blank line between them. Like this:
1. Ask a supervisor for a `cmprod.pem` file and move it into the `~/.ssh` folder.
2. Run `chmod 600 ~/.ssh/cmprod.pem`
3. Run `eb ssh` and type `yes` when it asks if you would like to add the key to your keychain.
4. Once connected via SSH, to access the application's source code, perform the following steps
- `sudo docker ps`
- Copy the desired value from the `CONTAINER ID` column
- Run `sudo docker exec -it $CONTAINER_ID rails c` using the copied value.
It's helpful to remember that when nesting list items, you need to follow all the same rules you would outside of a list. Then just indent one level. So, for example, everything nested in item 4 would look like this outside of a list item:
Once connected via SSH, to access the application's source code, perform the following steps
- `sudo docker ps`
- Copy the desired value from the `CONTAINER ID` column
- Run `sudo docker exec -it $CONTAINER_ID rails c` using the copied value.
You need a blank line between the paragraph and the list. Therefore, when nesting all of that in a list, you need to maintain the same formatting and maintain the blank line. Just because the first line starts after the bullet (or list number) doesn't mean it doesn't follow the same rules.
Finally, even if you are using a Commonmark parser, I would suggest using the blank line. It is just good form which any Markdown linter would suggest.
Related
I'm trying to learn how autocompletion works in zsh. I've got a simple script file (example.zsh) and I'm trying to create a simple autocomplete function that describes each of its parameters. In order to do that, I've started by creating a simple _example file which looks like this:
#compdef create_ca
_arguments \
"--caKey[name of the file that will hold the keys used for generating the certificate (default: ca.key)]" \
"--caCrt[name of the file that will hold the certificate with the public key (default: ca.crt)]" \
"--cn[common name for the root certificate (default: root.GRM)]" \
"--days[number of days that certificate is valid for (default: 10500)]" \
"--size[key size (default: 4096)]" \
"--help[show this help screen]"
The file is on the same folder as the script and I've updated my .zshrc file so that it adds that folder to the $fpath:
fpath=(~/code/linux_certificates $fpath)
autoload -Uz compinit
compinit -D
I'm using the D option so that the .zcompdump isn't generated. At first sight, everything worked out, but when I tried to update the helper autocomplete function, I'm unable to see thosee changes (ex.: changing the description). I've tried re-running the compinit command and, when using the cache .zcompdump, deleting that file. However, it simply didn't work. The only way I've managed to get it working was by deleting the autocomplete helper function with:
unfunction _create_ca
Is this the expected behavior? I mean, should't running compinit -D be enough to reload my helper autocomplete function?
btw, any good tutorials on how to create autocomplete functions (besides the official docs)?
thanks.
Once a function has been loaded, it will not be loaded again. That’s why you first have to unfunction your function, causing Zsh to unload it, so it can be loaded again.
Alternatively, you can just use exec zsh to restart your shell.
I may have missed this detail but I'm trying to see if I can control the set of plugins made available through the ini configuration itself.
I did not find that item enumerated in any of the configurable command-line options nor in any of the documentation around the pytest_plugins global.
The goal is to reuse a given test module with different fixture implementations.
#hoefling is absolutely right, there is actually a pytest command line argument that can specify plugins to be used, which along with the addopts ini configuration can be used to select a set of plugin files, one per -p command.
As an example the following ini file selects three separate plugins, the plugins specified later in the list take precedence over those that came earlier.
projX.ini
addopts =
-p projX.plugins.plugin_1
-p projX.plugins.plugin_2
-p projY.plugins.plugin_1
We can then invoke this combination on a test module with a command like
python -m pytest projX -c projX.ini
A full experiment is detailed here in this repository
https://github.com/jxramos/pytest_behavior/tree/main/ini_plugin_selection
I try to use the original riak-kv image in docker-compose and I want on init add one bucket but docker-compose up won't start. How I can edit volumes.schemas to add bucket on init?
Original image allows to add riak.conf file in docker-compose ? If yes, then how can I do that?
Creating a bucket type with a custom datatype
I assume you want to create a bucket type when starting your container. You have to create a file in the /etc/riak/schemas directory with the bucket's name, like bucket_name.dt. The file should contain a single line with the type you would like to create (e.g. counter, set, map, hll).
You can also use the following command to create the file:
echo "counter" > schemas/bucket_name.dt
After that you have to just mount the schemas folder with the file to the /etc/riak/schemas directory in the container:
docker run -d -P -v $(pwd)/schemas:/etc/riak/schemas basho/riak-ts
Creating a bucket type with default datatype
Currently creating a bucket type with default datatype is only available if you add a custom post-start script under the /etc/riak/poststart.d directory.
Create a shell script with the command you would like to run. An example can be found here.
You have to mount it as a read-only file into the /etc/riak/poststart.d folder:
docker run -d -P -v $(pwd)/poststart.d/03-bootstrap-my-datatype.sh:/etc/riak/poststart.d/03-bootstrap-my-datatype.sh:ro basho/riak-ts
References
See the whole documentation for the docker images here. The rest can be found in GitHub.
Also, the available datatypes can be found here.
I'm using my Windows PC, and I'm trying to import a "dump.sql" into the database "TEST" created with Postgres, using command prompt. I do it in two steps:
Step 1:
cd C:\Program Files\PostgreSQL\12\bin
Step 2:
psql -U username -d TEST < C:\Users\Username\Desktop\University\Politechnic\III year\INFORMATIC TECHNOLOGIES FOR THE WEB\PDF SL\SL\Materials\TIW_IOL_ServletJSP\db\dump.sql`
Long path, I know. But the result is: "Impossible to find specified file".
What can I do?
Not sure how security is where you are at, but can you attempt to write to a file with a simpler destination? Such that you take out any possibility of spaces and/or length being the issue? Then you will at least be able to remove those variables or narrow down to them depending on the outcome. Note that the max path length is 260 characters
(From comment on question)
I wrote a little CDN server that rebuilds its registry pool when new pool-content-packages are installed into that registry pool.
Instead of having each pool-content-package call the init.d of the cdn-server, I'd like to use triggers. That way it would restart the server only once at the end of an installation run, after all packages were installed.
What have I to do to use triggers in my packages with debhelper support?
What you are looking for is dpkg-triggers.
One solution with use of debhelper to build the debian packages is this:
Step 1)
Create file debian/<serverPackageName>.triggers (replace <serverPackageName> with name of your server package).
Step 1a)
Define a trigger that watch the directory of your pool. The content of file would be:
interest /path/to/my/pool
Step 1b)
But you can also define a named trigger, which have to be fired explicit (see step 3).
content of file:
interest cdn-pool-changed
The name of the trigger cdn-pool-changed is free. You can take what ever you want.
Step 2)
Add handler for trigger to file debian/<serverPackageName>.postinst (replace <serverPackageName> with name of your server package).
Example:
#!/bin/sh
set -e
case "$1" in
configure)
;;
triggered)
#here is the handler
/etc/init.d/<serverPackageName> restart
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
#DEBHELPER#
exit 0
Replace <serverPackageName> with name of your server package.
Step 3) (only for named triggers, step 1b) )
Add in every content package the file debian/<contentPackageName>.triggers (replace <contentPackageName> with names of your content packages).
content of file:
activate cdn-pool-changed
Use same name for trigger you defined in step 1.
More detailed Information
The best description for dpkg-triggers I could found is "How to use dpkg triggers". The corresponding git repository with examples you can get here:
git clone git://anonscm.debian.org/users/seanius/dpkg-triggers-example.git
I had a need and read and re-read the docs many times. I think that the process is not clearly explain or rather what goes where is not clearly explained. Here I hope to clarify the use of Debian package triggers.
Service with Configuration Directory
A service reading its settings in a specific directory can mark that directory as being of interest.
Say I create a new service which reads settings from /usr/share/my-service/config/...
That service gets two additions:
In its debian directory I add my-service.triggers
And here are the contents:
# my-service.triggers
interest /usr/share/my-service/config
This means if any other package installs or removes a file from that directory, the trigger enters its "needs to be run" state.
In its debian directory I also add my-service.postinst
And I have a script as follow to check whether the trigger happened and run a process as required:
# my-service.postinst
if [ "$1" = "triggered" ]
then
if [ "$2" = "/usr/share/my-service/config" ]
then
# this may or may not be what you need to do, but this is often
# how you handle a change in your service config files
#
systemctl restart my-service
fi
exit 0
fi
That's it.
Now packages adding extensions to your service can add their own configuration file(s) under /usr/share/my-service/config (or a directory under /etc/my-service/my-service.d/... or /var/lib/my-service/..., although that last one should be reserved for dynamic files, not files installed from a package) and dpkg automatically calls your postinst script with:
postinst triggered /usr/share/my-service/config
# where /usr/share/my-service/config is your <interest-path>
This call happens only once and after all the packages were installed, hence the advantage of having a trigger in the first place. This way each package does not need to know that it has to restart my-service and it does not happen more than once, which could cause all sorts of side effects (i.e. the service tries to listen on a TCP port and get error: address already in use).
IMPORTANT: keep in mind that the postinst should include a line with #DEBHELPER#.
So you do not have to do anything special in other packages. Only make sure to install the configuration files in the correct directory and dpkg picks up from there (i.e. in my example under /usr/share/my-service/config).
I have an extension to BIND9 called ipmgr which makes use of .ini files saved in a specific folder. It uses the files to generate DNS zones (way less errors that way! and it includes support for getting letsencrypt certificates and settings for dmarc/dkim). This package uses this case: a simple directory where configuration files get installed. Other packages do not need to do anything other than install files in the right place (/usr/share/ipmgr/zones, for this package).
Service without a Configuration Folder
In some (rare?) cases, you may need to trigger something in a service which is not driven by the installation of a new configuration file.
In this case, you can use an arbitrary name (it should include your package name to make sure it is unique since this name is global to the entire Debian/Ubuntu system).
To make this one work, you need three files, one of which is a trigger in the other packages.
State the Interest
As above, we have an interest. In this case, the interest is stated as a name on its own. The dpkg system distinguish between a name and a path because a name cannot include a slash (/) character. Names are limited to ASCII except control characters and spaces. I would suggest you stick to a-z, 0-9 and dashes (-).
# my-service.triggers
interest my-service-settings
This is useful if you cannot simply track a folder. For example, the settings could come from a network connection that a package offers once installed.
Listen for the Triggers
Again, as above, you need a postinst script in your Service Package. This captures the trigger and allows you to run a command. The script is the same, only you test for the name instead of the folder (note that you can have any number of triggers, so you could also have both: a folder as above and a special name as here).
# my-service.postinst
if [ "$1" = "triggered" ]
then
if [ "$2" = "my-service-settings" ]
then
# this may or may not what you need to do, but this is often
# how you handle a change in your service config files
#
systemctl restart my-service
fi
exit 0
fi
The Trigger
As mentioned above, we need a third file. An arbitrary name is not going to be triggered automatically by dpkg. It wouldn't know whether your other package needs to trigger something just like that (although it is fairly automated as it is already).
So in other packages, you create a trigger file which looks like this:
# other-package.triggers
activate my-service-settings
Now we recognize the name, it is the same as the interest stated above.
In other words, if the trigger needs to run for something other than just the installation of files in a given location, use a special name and add this triggers file with the activate keyword.
Other Features
I have not tested the other features of the dpkg-trigger(1) tool. There are other keywords support in the triggers files:
interest
interest-await
interest-noawait
activate
activate-await
activate-noawait
The deb-triggers manual page has additional information about those. I am not too sure what the await/noawait implies other than the trigger may happen at any time when nowait is used.
Automatic Trigger Added
The build system on Ubuntu (probably Debian too) automatically adds a triggers file with the following when your package includes a library:
$ cat triggers
# Triggers added by dh_makeshlibs/11.1.6ubuntu2
activate-noawait ldconfig
I suggest you exercise caution if your package includes libraries. If you have your own triggers file, I do not know whether this addition will still happen automatically.
This also shows us a special case where it wants to use the noawait. If I understand correctly, it has to run the ldconfig trigger ASAP so your commands will work as expected after the unpack. Otherwise ldd will not know anything about your newly installed library.