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).

Juste pour éviter à des gens d'être surpris, maintenant sous Debian Stretch, les outils systemd pour la conteneurisation (nspawn/machinectl) sont dans un paquet séparé -- et c'est tant mieux ! :)
Après un upgrade, une fois le paquet installé, tout repart normalement.

Je n'avais jamais entendu parler de busctl… encore un outil de systemd.
La commande sert à interagir avec dbus/sd-bus de manière plus simple et plus intégrée que dbus-send et compagnie.
C'est relativement pratique, par exemple si on veut lister les différentes sessions/seat ouvertes, etc. et il y a un mode tree, monitor, introspect, …

On en apprend toujours : j'ai bloqué un moment sur du code C, pour comprendre pourquoi mes printf n'apparaissaient pas quand je faisais une redirection dans un fichier, et un tailf dessus…
Forcément c'était une histoire de buffer, forcément un write allait être la solution. Mais je voulais quand même savoir, et effectivement le buffering n'est apparemment pas le même par défaut si on envoie sur de l'interactif (line-buffered) ou un fichier (full buffering) !

À propos de la toujours grande question de quel format/codec/conteneur choisir pour une vidéo, et pouvoir éventuellement facilement la partager sur un coin de web par exemple.
Je veux un maximum de "libre" et de normalisé, ouvert, connu. Disponible un peu partout si possible, et avec des outils dans Debian stable (et donc normalement disponible dans les autres distributions courantes).
Il semblerait que le vp9 / vorbis / webm réponde à cela. Attention avec le vp9, il y a apparemment différents formats d'encodage des données notamment 10 ou 12 bits qui peut coincer (pas ou mal supporté dans Firefox 54/totem/mplayer/vlc mais OK dans mpv, voir https://trac.ffmpeg.org/ticket/5276).

Exemple de ligne de commande ffmpeg pour construire un film à partir d'images (dans mon cas un timelapse d'étoiles) :
ffmpeg -f image2 -r 12 -start_number 5480 -i PK1_%4d.png -c:v libvpx-vp9 -crf 30 -b:v 2000k -pix_fmt yuv420p -threads 8 test.webm

C'est une vidéo fixe, avec du ciel noir, mais en 1920x1281, 28 secondes. On arrive à… 1,5 Mo ! Probablement pas représentatif d'un film ou autre mais ça me semble correct, ça fonctionne partout où j'ai pu essayer, et on n'utilise que des formats ouverts.