Si jamais systemctl --user marche pas avec cette erreur, il suffit de définir la variable d'environnement qui va bien pour débloquer la situation :
XDG_RUNTIME_DIR=/run/user/$(id -u)
Pas besoin de bricoler avec du dbus ou quoi. On peut l'exporter dans son bashrc par exemple. Probablement dû à un sshd configuré sans PAM dans mon cas mais il y a sûrement d'autres raisons possibles.

Ma syncho mail était cassée depuis quelques temps par perte de connectivité entre mes deux réplicats dovecot (en IPv6, pas d'accès tunnel HE chez Cogent).
Pour contourner cela, je me suis demandé s'il n'y avait pas moyen de faire du routage dans un tunnel SSH. Et la réponse est oui, c'est même facile : ssh -w 0:0 (en root des deux côtés) va créer une paire de tun0 qu'il suffira de configurer !
ip link set tun0 up
ip route add … dev tun0
… le forwarding, etc.

En lisant la page liée, j'ai donc juste eu à créer une paire de clefs SSH, faire la config (sshd_config without-password et PermitTunnel) et c'est tombé en marche rapidement :)

Fichiers sysfs faciles à accéder pour voir les compteurs des interfaces réseau sans passer par une commande ou parser des sorties plus ou moins obsolètes comme ifconfig. Exemple pour le rx :
/sys/class/net//statistics/rx_bytes
/sys/class/net//statistics/rx_packets

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.

3.3V apparemment ça marche ? Bah moi d'abord j'ai fait tourner un RPi zero WH avec du 3V, na.
En fait j'ai oublié de vérifier la tension sur le transfo avant de brancher le RPi, je l'avais mis au minimum pour un petit ventilateur… ça aurait pu faire de la casse.
Au contraire, tout fonctionnait même le WiFi et l'HDMI. Juste pas l'USB…
J'ai aussi de la corruption sur certains fichiers, mais j'ai passé les mises à jour pendant la période 3V donc je pense que le contrôleur de la carte SD a fait ce qu'il a pu (ou que la carte est foireuse de toutes façons).
À noter qu'une libpam corrompue, ça te laisse à la porte de ta machine comme une merde, que ce soit SSH ou login. Normal mais bon… après réinstallation du paquet ça va quand même mieux.

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"

Les applications CUDA indexent les GPU de la machine par défaut dans l'ordre de performance supposée, alors que dans nvidia-smi le listing est donné par ordre PCI.
On peut changer le comportement dans les applications avec CUDA_DEVICE_ORDER=PCI_BUS_ID dans l'environnement.

Depuis un moment j'avais des mails de cron sur mon conteneur web, disant que logrotate n'arrivait pas à reload apache. J'ai un peu creusé le problème au début, puis étant bloqué sur systemd parlant de namespace, j'étais resté coincé puis étais passé à autre chose.
Pour compliquer le debug, une fois un restart d'apache effectué, pas de problème pendant "un certain temps"…
Là j'ai retenté ma chance et pouf, je suis tombé sur ce rapport de bug Debian.
En fait, c'est tmpreaper qui nettoie les dossiers de "PrivateTmp" de systemd. Du coup au moment de mettre en place l'environnement pour lancer le reload, systemd n'arrive pas à accéder au namespace du /tmp puisqu'il a été viré !
Un message d'erreur plus explicite de la part de systemd aurait été appréciable. Et le problème n'est pas lié à LXC, ni à apache.
Quick fix (pour être complet) :
TMPREAPER_PROTECT_EXTRA='/tmp/systemd-private/'

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 !

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

Si certains mails ne passent pas, supposément parce qu'ils sont en "userunix@localhost" et ce même si le header From: est juste, c'est probablement une histoire de Sender/Return-Path, eux aussi validés par les MTA.
504 5.5.2 wp@localhost: Sender address rejected: need fully-qualified address
Il ne faut pas s'acharner sur mail/sendmail/php mail(). Ce champ est ajouté par le MTA local.
Plusieurs options sont listées dans la page liée. Pour moi, il a suffit de corriger /etc/mailname en mettant quelque chose de valide (oui j'aurais pu y penser au début, avant de passer 2h sur le problème…).

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.

Passer un gitlab du postgresql du système à celui qui est intégré au paquet omnibus, c'est faisable, c'est pas trop tricky quand on a la doc de quelqu'un qui l'a déjà fait et qui s'y connait (j'aurais jamais pu deviner tout ça perso). Par contre il faut bien suivre les instructions à la lettre, sinon ça marche pas (j'en ai fait les frais).
Est-ce une bonne idée de le faire ? Probablement pas en absolu, mais c'était un reste de mon setup "from source" alors que je suis passé au paquet omnibus depuis un moment, pour des raisons de facilité : c'est vraiment pratique les paquets et j'ai jamais eu de problème avec le leur.
Il y avait des problèmes de version entre les outils (postgresql plus vieux dans la distro). Là au moins c'est homogène… et les dump se passent bien, par exemple.

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, …

J'ai remarqué que l'hibernation prenait parfois super longtemps sur mon Debian 9 Stretch, avec LED d'activité stockage allumée en continu. En faisant un tour dans dmesg j'ai remarqué la ligne :
PM: Need to copy XXXXXXX pages
Avec des pages de 4096, j'avais environ 13Go d'image ! Ce qui correspondait en gros à l'utilisation de ma mémoire en incluant le cache (alors que j'étais à environ 1G utilisé réellement par les programmes). Ça me parait stupide de sauver le cache dans l'image mais bon. Du coup j'ai un peu creusé.

Au final, la solution la plus simple est de passer à uswsusp, qui s'occupe en userspace de gérer l'image et surtout de drop le cache, accessible via les commandes s2* que je connaissais déjà. On l'installe, puis on le reconfigure pour avoir droit aux questions. Mettre 0 comme taille d'image pour la minimaliser (drop la mémoire cache).
aptitude install uswsusp
dpkg-reconfigure uswsusp

Il faut encore demander à systemd de l'utiliser lui. Pour ça, voir la page liée, mais en gros :
systemctl edit systemd-hibernate.service
et mettre :
[Service]
ExecStart=
ExecStartPre=-/usr/bin/run-parts -v -a pre /lib/systemd/system-sleep
ExecStart=/usr/sbin/s2disk
ExecStartPost=-/usr/bin/run-parts -v --reverse -a post /lib/systemd/system-sleep
(attention, sur la doc liée c'est /usr/bin/s2disk et pas sbin ! sous Debian apparemment c'est sbin… de même, le dossier pre/post est dans /lib sous Debian, alors que la doc Arch dit /usr/lib) :-'

Maintenant je ne bourrine plus les write de mon SSD avec du cache, j'ai un joli progress à l'écriture/lecture de l'image et le tout est plus rapide (quelques secondes au lieu de l'ordre de la minute). Oui j'ai passé plus de temps à chercher/tester/rédiger, mais j'ai appris des trucs au moins :)

Je re-shaarli juste encore une fois le coup du mount bind pour voir le contenu d'un point de montage y compris ce qui serait caché par un autre montage… j'y ai plus pensé, et j'avais le cas de données prenant de la place mais non atteignables…

"This is why I use the initrd.gz from stable hd-media, because the 8.2 multiarch netinst ISO is missing the iso-scan toolset entirely."
Passer 2h là dessus juste pour booter une netinst depuis une clef multiboot… check. L'affirmation semble encore exacte pour Debian 9.

La commande "pv" a pas mal d'options. Pour avoir rapidement une idée du nombre de requêtes sur une page web qui se fait par exemple DDoS, on peut construire quelque chose comme :
tailf /var/www/<site>/access.log | grep lapage | pv -l -i 10 -r > /dev/null
On aura le nombre de ligne par seconde, sur les 10 dernières secondes.

Tester simplement si un dossier a été copié, sans tenir compte des owner/dates/etc. donc sans passer par tar :

find /path -type f | sort -u | xargs cat | md5sum

On peut troller sur md5 mais pour ça, ça fait largement le boulot, et si vraiment ça t'amuse, pas compliqué de mettre un sha42sum quelconque :)

Pour appliquer une limite de débit à n'importe quel flux en ligne de commande : pv --rate-limit ! Ici appliqué à dd, mais ça devrait être pareil pour tout (cat, nc, …).