… et donc pour convertir en ordre lexicographique tout un dossier de JPEG, sans faire de boucle, sans gérer l'index soi-même et sans limite de taille de ligne de commande (sans * quoi), le tout en parallèle sur tous les cœurs dispo :

ls -1 | grep JPG | MAGICK_TMPDIR=/dev/shm parallel convert {} '/dev/shm/tests/$(printf %04d {#}).png'

(oui je fais tout dans shm, c'est plus rapide de mettre les fichiers temporaires et les résultats dans la RAM quand on en a assez, et ça bourrine moins HD/SSD)

Article que j'ai trouvé très complet, avec de bonnes explications sur comment fonctionne qemu-user, à quoi ça sert etc.
Pour utiliser qemu-arm-static, j'ai dû installer le paquet qemu-user-static (ce n'est pas décrit). Le -static désinstalle le -binfmt. Bizarre. Pourtant même après ça, le bon interpréteur est tout de même utilisé automagiquement et les fichiers de "registration" des formats sont toujours là (voir /proc/sys/fs/binfmt_misc/).
En fait en rédigeant j'ai regardé et le -static rajoute de lui-même les binfmt… voir /var/lib/dpkg/info/qemu-user-static.postinst pas très homogène tout ça on dirait.

J'ai voulu ajouter rapidement un petit daemon à un système Alpine pour qu'il démarre au boot. J'ai donc cherché des infos sur les script openrc. On tombe principalement sur les wiki de Gentoo et Arch, puis enfin celui d'Alpine.
Les deux premiers sont super remplis mais ne disent pas comment définir un user particulier… sauf à redéfinir la fonction start et stop et la ligne start-stop-daemon. Le wiki Alpine dit que la page est en chantier et de pas l'utiliser (et n'en parle pas non plus).
J'ai donc lu la page de man directement, lu les exemples, pris ce qui me semblait minimal, trouvé le paramètre user… pas si compliqué au final. Un peu frustrant. Et pas différent de systemd au final, pour les trolleurs ;)

#!/sbin/openrc-run
command=/srv/davmail-4.9.0/davmail.sh
command_args="/srv/davmail-4.9.0/davmail.properties"
pidfile=/var/run/davmail.pid
command_background=true
command_user=davmail
name="Davmail Daemon"

Depuis juillet, lorsqu'on a/utilise un drone de loisirs, il est théoriquement obligatoire de suivre une mini-formation en ligne et d'enregistrer son appareil. Je viens de m'y coller (mais je n'ai utilisé le mien qu'une fois depuis juillet il me semble).
En fait le bouzin est effectif depuis 3 jours de ce que je comprends, donc ça tombe bien.

En gros, ça se fait. Le site est pas trop mal fichu, la "formation" c'est juste regarder quelques vidéo infantilisantes, et le QCM de l'attestation c'est 20 questions quasiment toutes directement issues des vidéo, et on peut recommencer autant de fois qu'on veut si on se rate (c'est l'histoire du gag classique de celui qui veut gagner 3 secondes et perd 3 minutes…).

La formation est ici : https://fox-alphatango.aviation-civile.gouv.fr/ Il y a besoin d'un compte uniquement lorsqu'on veut passer le QCM.
Le site hors formation est directement sur https://alphatango.aviation-civile.gouv.fr/ et est pas trop mal fichu, il faut être honnête !

P.S. l'attestation de formation est re-générée à chaque fois qu'on clique sur télécharger… comme j'ai téléchargé la mienne à 13h34, j'ai attendu 3 minutes et l'ai re-créée pour avoir 13h37…

Quand on essaye d'envoyer un mail avec openssl s_client, au moment de faire un RCPT TO, on a perdu : s_client voit la commande 'R' et essaye de renégocier la session TLS…
Donc bon à savoir : openssl essaye d'interpréter ce qu'on envoit…
(là on contourne avec rcpt au lieu de RCPT et lala)

J'ai acheté un nouveau disque dur, et mis de l'ext4 dessus (dans un conteneur LUKS mais ça on s'en fiche). J'ai remarqué qu'il y avait en continu un tout petit peu d'activité disque, et comme j'ai aussi des lags bizarres et des compteurs SMART qui s'envolent j'ai suspecté le disque d'être mauvais.
Pour les SMART, une partie a arrêté de s'envoler en changeant de contrôleur et câble SATA dans la tour… une vieille tour que j'ai utilisée car je compte déplacer le disque après.
Pour les IO, il semble que ce soit ext4lazyinit, on peut le voir avec la commande donnée sur la page liée :
iotop -bktoqqq -d .5
J'utilise maintenant un dock USB3 pour tester, mais du coup je ne peux plus vérifier les SMART…

EDIT: monter avec init_itable=0 pour éviter que le thread fasse du throttling et torcher ça au plus vite… ça se passe à environ 70 Mo/s comme cela, contre 4 ko/s avant.

Pour ARN, pour travailler sur un incident on aurait eu besoin d'une sorte de smokeping (ping en continu avec graph pour voir quand il y a des problèmes (latence, pertes, …)). J'ai cherché rapidement et à part "smokeping" qui a un mode daemon et visualisation web, le reste avait l'air proprio/winwin/…
Je suis tombé par hasard sur la page liée ici, où, simplement, ils font ça avec… ping et gnuplot.

J'ai donc bidouillé à partir de là, et au final ça donne :

ping4 -i 10 addresse-à-tester -D -n | grep --line-buffered icmp_seq | awk -F [=\ ] -W interactive {'print $1, " ", $(NF-1); fflush()'} | stdbuf -o0 tr -d '[]' > /dev/shm/pings4

Le plus difficile est à chaque commande pour être sûr de ne pas bufferiser, ce qui permet de lire le fichier de sortie immédiatement, sans arrêter la commande ou autre. Pas de soucis de faire des petites écritures puisqu'on envoie dans un ramdisk.
On a donc des paires "timestamp RTT"

Pour grapher cela, on peut utiliser :

gnuplot -e 'set term png size 1280,1024; set output "ping.png"; set xlabel "Time (UTC)"; set ylabel "RTT in milliseconds"; set xtics rotate; set xdata time; set timefmt "%s"; set format x "%b %d %H:%M"; clamp(a) = (a < 42) ? a : 42; plot "pings4" using 1:(clamp($2)) notitle'

Ici le plus sioux c'est d'une part la gestion du temps (timestamp vers "pretty"), d'autre part la limite (min ou clamp) pour éviter d'avoir un graph tassé/pollué par les ping vraiment trop hauts. Ici tout ce qui est plus grand que 42 ms est affiché à 42.

Ce qui reste difficile, c'est la détection de pertes. On ne les voit pas vraiment, surtout quand le graph commence à être large. En général en cas de problème on le remarquera autrement (nous ici, session BGP qui tombent). Après on peut aller fouiller en mode interactif (sans utiliser la sortie PNG de gnuplot). Et là on voit rapidement quand il y a un "trou" dans une certaine zone. En général ça correspond aussi à des moments où il y a eu un lot de ping à plus de 42 ms de RTT.

Si des gens veulent utiliser ça, en tous cas c'est relativement sans prise de tête et sans installation ou autre !

Doc bien complète sur la remontée d'erreurs RAM/PCI dans le noyau Linux. Je suis tombé sur cette page en cherchant comment savoir la répartition de la RAM dans un serveur et ses caractéristiques, et en particulier son ranking (combien d'accès séparés / en parallèle sur les barettes).
À noter que l'outil edac-util ne fonctionne plus trop pour avoir les informations de ranking sur des intel modernes, puisqu'on n'a plus l'interface csrow mais dimm dans le sysfs.
dmidecode reste tout de même le plus simple pour trouver le ranking, lorsqu'il est affiché. Sous la main, j'ai des exemples de ranking 1, 2 et 4.

En faisant du debug sur un conteneur LXC, je me suis rendu compte qu'au milieu de syslog par exemple, il y avait des messages du noyau concernant l'hôte ou un autre LXC. J'ai trouvé ça pas top (même si pas très important).
Il y a apparemment deux facettes :
  - /proc/kmsg, utilisé par rsyslogd
  - le syscall "syslog" utilisé par dmesg
Peut-être aussi via /dev/kmsg, mais ce n'est pas le cas chez moi (https://github.com/lxc/lxcfs/issues/131).

Le lien lié ici propose comment bloquer le syscall via les seccomp. Ça fonctionne.

Pour kmsg le lien précédent prétend que cela va casser des choses, j'ai tout de même voulu essayer. Par contre par défaut sur Debian Stretch, apparmor n'a pas l'air activé complètement, le module est là mais pas l'accès via proc (https://wiki.debian.org/AppArmor/HowToUse et aa-status). Je n'ai donc pas pu essayer de modifier cela (les autres restrictions, qui ont tout de même l'air de fonctionner malgré l'absence des paramètres cmdline sont dans /etc/apparmor.d/abstractions/lxc/container-base).

En attendant il suffit de cat /proc/kmsg depuis n'importe où pour tout savoir sur ce qu'il se passe sur le système côté noyau :P

Ah et aussi, ce n'est pas si simple que cela : https://lxadm.com/Lxc:_restricting_container_view_of_dmesg
D'autant que l'option est maintenant activée par défaut depuis Debian Stretch. En LXC root (pas non-privilégié donc) ça fonctionne tout de même (comme dit dans le lien github ci-dessus).

Article plutôt clair sur les histoires de courant alternatif, de cosinus phi, même un peu de triphasé à la fin.
Je pense que j'ai appris des choses, de là à retenir… j'ai clairement pas tout compris.
Sinon on peut aussi voir le wikipédia anglais : https://en.wikipedia.org/wiki/AC_power (la version fr j'ai trouvé moins claire).