Le principe des table de hash distribuées

• http://www.suumitsu.eu/2014/12/11/lapres-tpb-dht-infohash-et-indexation/
• DEFCON 18: Crawling BitTorrent DHTs for Fun 1/2 https://www.youtube.com/watch?v=v4Q_F4XmNEc
• DEFCON 18: Crawling BitTorrent DHTs for Fun 1/2 https://www.youtube.com/watch?v=mO3DfLtKPGs
• https://www.usenix.org/legacy/event/woot10/tech/full_papers/Wolchok.pdf

Prenons un bash qui ouput sur sa sortie standard (stdout) et sur sa sortie d'erreur (stderr) :

cat test.bash

echo good
echo bad >&2
echo vanish >&2
echo good!

Comment faire pour rediriger la sortie standard vers un fichier (ou /dev/null pour l'exemple) et filter la sortie d'erreur pour retirer la ligne "vanish" ?

Pour ça il faut utiliser un process substitution :

/root/test.bash 2> >(grep -v vanish >&2) >/dev/null

Bien pratique dans un crontab pour recevoir un peu moins de mail lorsqu'on a des "erreurs" acceptables (rsync vanished par exemple)

SHELL=/bin/bash

• • • • • root /root/test.bash 2> >(grep -v vanish >&2) >/dev/null

Pour en savoir plus sur les process substitution : http://tldp.org/LDP/abs/html/process-sub.html

Bon article, résume très bien les volumes dans docker

Je prends de plus en plus le réflexe de "git init" dans certains dossiers un peu chaud qui bougent beaucoup comme des dossiers de configuration..

Et là arrive le moment où je me pose la question : qu'est ce que j'ai touché depuis que j'ai fais mon git ini ? Et voilà la commande magique qui répond à ma question :

git diff --name-only SHA1 SHA2

Après si vous voulez la liste entre le premier et le dernier commit :
git diff --name-only HEAD $(git log --format=%H | tail -1)

Bon à savoir, pour rediriger la sortie standard d'un cron dans un fichier avec la date, penser à échapper les "%"

/path/to/log/dir/$(date +\%Y-\%m-\%d).log

D'après la doc :

don't confuse RUN with CMD.

RUN actually runs a command and commits the result;

CMD does not execute anything at build time, but specifies the intended command for the image.

An ENTRYPOINT helps you to configure a container that you can run as an executable. That is, when you specify an ENTRYPOINT, then the whole container runs as if it was just that executable.

Unlike the behavior of the CMD instruction, The ENTRYPOINT instruction adds an entry command that will not be overwritten when arguments are passed to docker run. This allows arguments to be passed to the entry point, i.e. docker run <image> -d will pass the -d argument to the entry point.

You can specify parameters either in the ENTRYPOINT JSON array (as in "like an exec" above), or by using a CMD instruction. Parameters in the ENTRYPOINT instruction will not be overridden by the docker run arguments, but parameters specified via a CMD instruction will be overridden by docker run arguments.

Le RUN sert à build l'image

Le CMD et l'ENTRYPOINT servent au moment du docker run
Donc au final, il vaut mieux avoir un ENTRYPOINT avec des paramètres qu'on ne peut pas écraser (non overridable)
Pourquoi pas un CMD avec des paramètres par défauts overridable

hebergement à base de docker