Utilitaire un peu comme gparted mais pour KDE, qui, lui, permet de redimensionner les partitions LUKS sans s'embêter à calculer des nombres de secteurs à la main.
Par contre, il faut opérer la modification sur le système de fichiers lui-même, à l'intérieur du conteneur… pas forcément intuitif, j'ai dû passer par la vidéo pour comprendre. Probablement parce que apparemment le conteneur LUKS n'a pas la taille totale lui-même, je suppose.

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.

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 !

GIMP est sorti en version 2.10, version qui a mis 6 ans à être prête. La nouvelle fait un peu le tour du monde libriste, mais en tant qu'utilisateur depuis une version 1.x je dois quand même avouer que j'étais bien triste de lire ça et là que le logiciel était "en perte de vitesse". Et cette version a tout de même beaucoup de points d'amélioration importants, même s'il en reste. Je vous laisse lire la dépêche ! En tous cas les quelques fonctionnalités que j'ai testées sont bien chouettes (exemple, accéder aux entrées menu/outils via une recherche unifiée (par défaut le raccourcis '/')) :)
Ce qui me rend triste et me donne envie d'aider c'est que leur infra de dev a l'air bien mal en point… c'est toujours la même histoire, pas de mystère, rien d'anormal mais tout de même. Peut-être quand j'aurai le temps ? Lol.

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.

Ces interrupteurs magnétiques sont aussi utilisés pour détecter le débit d'eau dans un tuyau et déclencher un chauffe-eau dit « instantané », sans ballon pré-chauffé.
A priori il semblerait qu'il y ait une sorte d'hélice dans le tuyau, qui, en tournant de plus en plus vite, actionne un tel interrupteur placé directement au bon endroit contre le tuyau et ferme donc un circuit, lequel actionne des relais déclenchant les résistances.
Il suffit d'approcher un aimant pour que l'interrupteur se ferme, on peut donc tester que c'est bien cet élément qui est défectueux facilement.

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

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

Si toi aussi tu as l'habitude d'utiliser imagemagick pour plein de choses, parce que c'est plutôt complet et en ligne de commande, juste pour prévenir qu'il y a des limites assez strictes maintenant… genre, 256Mo de RAM, 1Go de disque…
Ces limites sont dans /etc/ImageMagick-6/policy.xml et il suffit de dégager le fichier ailleurs pour qu'elles disparaissent (ou de le modifier gentiment).
Pour voir les limites effectives :
convert -list resource
C'est sûrement bien sur un serveur quand un site web utilise ça pour faire des vignettes par exemple, mais sinon ça a l'air bien casse-pieds ces limites. Et le message d'erreur est super-génial :
montage-im6.q16: DistributedPixelCache '127.0.0.1' @ error/distribute-cache.c/ConnectPixelCacheServer/244

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

Pour renvoyer des flux TCP ailleurs (bounce), on peut utiliser socat facilement (pas besoin de root pour les ports > 1024 ni d'iptables).
Exemple :
socat TCP-LISTEN:4242,fork TCP:machine-destination:3032
C'est une sorte de NAT sur un seul port, et qui évite de devoir monter une session de tunnel SSH.

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

Depuis que j'ai mon nouvel écran, branché en HDMI, j'utilisais la sortie casque de celui-ci. Et j'avais de temps en temps des problèmes bizarres, par exemple le début d'un morceau de musique qui passe sous silence puis se déclenche subitement, et toujours au début de chaque pause, un petit bruit légèrement désagréable. Je pensais que c'était peut-être le driver Linux du HDMI, ou l'écran lui-même ou pulseaudio ou tout autre élément dans la chaine qui était un peu mal codé.

Là j'ai voulu tester la qualité d'un film, et suis tombé sur une séquence avec seulement quelques rares bruits, et entre chaque j'avais le droit à un silence complet et cette histoire de petit bruit à chaque coupure. J'ai regardé vite fait sur le net, et suis tombé sur cette page, où il est dit que "Your output device which you've connected via HDMI needs a couple of seconds to synchronize to the datastream it starts receiving from your system.", ce que je trouve relativement étrange, mais cela m'a motivé à brancher le casque sur la sortie son directement sur ma carte mère. Et effectivement plus de problème.

Je ne sais toujours pas si c'est le driver, l'écran, pulseaudio ou autre qui est mauvais, mais c'est réellement beaucoup mieux depuis la sortie interne de la carte mère.

EDIT: j'ai aussi l'impression que le son est un peu plus cristallin/clair/distinct, ce qui correspondrait assez bien à une "carte son" pourrie (oui je sais, un écran n'est pas fait pour faire du son, alors que les sorties onboard de carte mère sont en général correctes, mais rien n'empêchait de mettre la même chose dans un écran que dans une carte mère…)

À 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 -startnumber 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.

J'ai découvert géoportail, le système de carte interactive en ligne de l'IGN. J'en avait déjà vaguement entendu parler, mais là je suis tombé dessus et j'ai joué avec.
C'est vraiment bien fait, site "moderne", clair, rapide/réactif.
Il y a beaucoup de données, et on peut les empiler, par exemple une fond de carte de photos aériennes (comme google maps), mais superposé par le cadastre, les lignes électriques, les réserves, l'hydrologie… il y a même des photos aériennes de 1950 !
Il y a aussi des outils de mesure de distance, de trajet, de surface…
Franchement, je suis assez surpris qu'un site aussi utile et bien fait soit si peu connu.
J'ai regardé vite-fait, il semblerait que ce soit hébergé chez Atos, pourquoi pas…

Quand thunar ne génère pas de miniatures sur les photos sur un sshfs, et qu'en fait il le fait jamais même sur des fichiers locaux, il suffit d'installer tumbler… ça parait logique.

J'utilise thunar pour trier mes photos, car justement l'affichage des vignettes des images est beaucoup, beaucoup plus rapide qu'avec nautilus (quasi immédiate). A priori, il ne la recrée pas mais charge simplement la vignette contenue dans le JPEG, car aucune activité processeur n'est visible.