Si jamais vous avez un "vieux" conteneur LUKS (chiffrement des données), il se peut que le discard/trim ne soit pas activé, ce qui est un peu dommage si vous l'avez sur un SSD.
Pour l'activer, il suffit de convertir le conteneur en LUKS2 et d'activer le discard dessus d'une manière ou d'une autre (j'ai choisi via les header, comme ça c'est toujours activé sur ce volume-ci).
Les distributions à jour ont toutes via systemd ou autre un cron/timer pour trim périodiquement (attention du coup ça ralentit les I/O un moment, genre si ça se déclenche quand vous démarrez l'ordi et la session, ça se ressent bien).

Commandes :
cryptsetup convert
cryptsetup --allow-discards --persistent refresh

Depuis le temps que je bidouille du /e/n/i je n'avais jamais eu à mettre plusieurs IP au même bloc iface… en fait c'est simple (apparemment depuis iproute2), il suffit de mettre 2 blocs iface. Même que ça marche (sous Buster) !

ffmpeg utilisé comme ici et couplé à un serveur rstp (comme spydroid, disponible sur f-droid) sur le téléphone permet d'avoir une webcam via android sur son linux. v4l2loopback est packagé dans Debian. C'est donc assez simple à tester.

Je n'ai cependant pas réussi à avoir mieux que 320×240 de définition depuis spydroid et il faut passer un paramètre au module v4l2loopback (https://github.com/umlaeute/v4l2loopback/issues/78) pour le rendre compatible avec les applis "relou" comme Chromium. Sinon ça va. Et non je ne vais pas montrer ma tronche en visio conf mais j'ai quand même tout testé comme si… histoire de savoir.

J'ai quelques sites web qui tournent chez moi depuis un moment (2010…), et au fur et à mesure j'ai appris des choses, mis d'autres choses en vrac, changé des configurations, etc.

Je suis en train de migrer une partie de mes services dans des VM sur d'autres machines. C'était donc le moment de revoir de fond en comble mon setup web.

J'ai beaucoup cherché s'il n'y aurait pas moyen de tout mettre dans un système magique qui s'occupe un peu de tout, calcule des infos en plus (graph), permet de filer un coin de web rapidemement à quelqu'un sans se prendre la tête etc. et forcément il y a plein d'outils qui existent et qui prétendent faire le café.

Grosso modo j'ai vu soit des gros trucs pour revendeurs à la cpanel/vesta/ispconfig/… soit des scripts maison mais qui du coup ne fonctionnent que sur par exemple Ubuntu (LEMPer) ou CentOS (VPSSIM). Or toute mon infra est en Debian, et je n'ai pas besoin d'intégration mail/DNS/TLS/… car tout cela est déjà géré par d'autres briques. Sortent un peu du lot, froxlor et tinycp…

J'ai hésité pour froxlor mais beaucoup de doc date de Debian wheezy, il y a tout de même cette notion de revendeur, DNS, mail, … qui ne m'intéresse pas (mais il suffit de ne pas les utiliser, on est d'accord… alors que ça rajoute quand même de la complexité et des risques de failles). Et au final ça ne semblait pas me rajouter beaucoup de facilité. Il aurait aussi fallu gérer les mise à jour et mises à niveau (comme pour tout outil quoi).

Tinycp avait l'air vraiment sympa mais actuellement les dev sont en train de se demander comment ils vont fournir leur bidule et dans tous les cas le code n'est pas libre. Donc compliqué dans le temps si on a pas envie de se prendre le chou et pas propre éthiquement.

J'ai donc perdu beaucoup de temps pour au final écrire le script qui fait juste ce que je veux et voilà. J'espère que je ne suis pas passé à côté de certaines notions élémentaires que les panel sus-cités ont déjà pris dans la tronche et corrigé : le web c'est compliqué et pas vraiment passionnant.

De nos jours sur un système avec systemd (comme une Debian "à jour" sans bidouille pour l'enlever), logrotate est lancé par un timer systemd, et enregistré en tant qu'unit systemd. Pour faire un run de test, il suffit de le start comme un service normal du coup… trop simple.

Pour tester une configuration logrotate, on peut aussi feinter la date de dernière exécution dans /var/lib/logrotate/status et donc après un start, bien vérifier que tout se passe bien… trop simple aussi, mais j'ai dû chercher pour tout ça, je me dis que ça peut servir souvent plutôt que "flemme".

Toi aussi passe 2h à comprendre pourquoi ton scanner (HP, bien géré par hplip normalement) marche plus depuis mise à jour en Debian Buster…
Verdict : il faut recompiler hplip avec le patch ci-lié…

Problème : tout marche avec hp-scan mais au moment de lire des données
error: No data read.

Éléments notables :
3.18.12 buster = pas marche
3.17.10 VM mint = marche

Très utile :
SANE_DEBUG_DLL=128
hp-scan -g

S'il y a du rouge ou des erreurs à la construction du paquet, je suppose que c'est normal en tous cas ça gène pas…

On ne doit plus voir la ou les lignes d'appel à l'option après patch :
[dll] sane_control_option(handle=0x134a1d0,option=9,action=1,value=0x7ffdf74d0b60,info=0x7ffdf74d0b54)

Le patch modifie une lib cpython, distribuée par le paquet hplip, donc il faut soit l'installer lui (et pas la partie libsane comme je faisais un moment) soit juste copier la lib comme un bourrin.

Rapport de bug d'où le patch semble venir (Debian a "juste" importé 34 (!) patches de Fedora… entre autres) : https://bugzilla.redhat.com/show_bug.cgi?id=1684434

J'ai un système de fichiers corrompu (un rootfs de RPi), mais pas trop, et pour la science je me demande quels sont les fichiers impactés. Je me suis souvenu qu'il y a dans les metadata de tous les paquets deb (ou presque) un fichier avec les md5sum de tout ce qu'ils contiennent. Je me suis dit qu'il devait bien y avoir un moyen de les utiliser. C'est possible avec debsum.
Sur le post ci-lié ils suggèrent debsums -a, pour mon cas c'est plutôt debsums -s qui m'intéresse.
On obtient une liste des fichiers qui ne correspondent pas au md5sum d'origine (pour peu que lui-même ne soit pas corrompu…) avec pour chaque le nom du paquet auquel il appartient.
Pas la peine de troller sur les collisions dans md5sum etc. pour ça, ça suffit amplement.

J'ai toujours trouvé checkinstall pratique pour complier, tester avec installation réelle et modifier un soft sans risquer de mettre le bazar sur son système (oui on peut aussi faire des chroot, des VM, … mais bon).
Apparemment cmake a une fonction équivalente, cpack. On peut soit le configurer dans le projet, et il suffit de faire "make package" pour que le projet soit packagé/taré à la fin soit directement lancer l'outil cpack avec toutes les variables sur la ligne de commande. Ici le lien utilise la configuration.

Pour être honnête j'ai pas trop compris, je me mangeais un mur tout le temps comme quoi cpack ne pouvait pas initialier la sortie en "DEB" mais tout à coup ça s'est débloqué après avoir testé d'autres sorties… les magies de cmake et des configurations changées à la volée je suppose (oui j'avais reset le dossier build…).
Bref bien pratique !

Bug entre uswsusp et plymouth de 2013, dup d'un de 2010, qui apparait en 2019 dans Debian Buster car desktop-base dépend de plymouth… on adore les broutilles qui passent entre les mailles des filets et qui pètent à la gueule des années plus tard.

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/'

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

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

Petite "découverte" du jour, ou plutôt une remarque : il existe dans Debian des backports de backports, en gros qui "traversent" 2 versions, dans backports-sloppy.

Tiens, ça y est, Mozilla et Debian s'entendent enfin sur les histoires de licence pour avoir le droit d'utiliser "Firefox" ? :)
Tant mieux, pas la peine de faire des exceptions de partout. Après ça a pas l'air non plus si simple et clair, avec des avis divergents (comme toujours)…

coquelicot (interface web de partage de fichiers orienté vie privée) est packagé dans Debian. Mais dans Jessie, il tourne en root alors que le cron de cleanup tourne bien avec l'utilisateur spécial "coquelicot".
C'est corrigé dans la version 0.9.4 du package. Il suffit de prendre le paquet et de l'installer par-dessus. Il y a même le bout de migration qui va bien (changement des permissions, on peut le voir a posteriori dans le postinst, /var/lib/dpkg/info/coquelicot.postinst).
Un peu crade surtout que du coup on perd le support de sécurité mais bon.

Script perl qui regarde quels processus utilisent encore des libs qui ont disparu depuis leur démarrage (mises à jour).

Liste :
needrestart -r l -v
(le -v affiche de quelles libs il est question, et comment il est arrivé à la conclusion que ces services-là doivent être relancés (ou ignorés : cas d'un process lancé à la main en session utilisateur)).
Par exemple pour une instance picomon "ban" lancée par systemd :
[main] #183 exe => /usr/bin/python3.4
[Core] #183 is a NeedRestart::Interp::Python
[Core] #183 source is /usr/local/bin/picomon
[main] #183 is picomon@ban.service

On peut aussi directement lui faire relancer les services, avec -r i (ou rien, c'est par défaut). On a alors soit un debconf qui permet de sélectionner les service que l'on souhaite (tous pré-cochés sauf certains comme journald ou dbus), soit une ligne-question par services.

needrestart est packagé dans Debian (depuis Jessie et wheezy-backports) et intègre des hooks pour apt/dpkg.

Des sources.list plus clairs, plus faciles à lire/écrire programmaticalement et permettant de factoriser mieux, pourquoi pas. Surtout quand on commence à avoir les backports, les symboles de débugage, différentes suites, …
Attention j'ai lié un mail préliminaire, dans le thread il y a des considérations intéressantes et des changements au format, c'est juste pour dire que c'est en cours.

Ça a l'air pas mal : des paquets Debian de symboles de débugage, automatiquement construits sans intervention du mainteneur et disponibles en-dehors du dépôt officiel (c'est quand même des paquets rarement utilisés). Au moins on sera sûr qu'il y a le paquet correspondant (actuellement c'est à la discrétion du mainteneur) et ce en-dehors du chemin (mirrorer ça partout et les avoir tous toujours dans les listes de paquets c'est un peu overkill).

Upgrade wheezy vers jessie dans un conteneur LXC sur un host lui-même déjà en jessie ? Et sans cracher sur systemd ? Facile, il suffit de rajouter à la config LXC les deux lignes proposées ici (le reste sur getty/udev est déjà de base ou inutile).
lxc.autodev = 1
lxc.kmsg = 0

Les polices horribles sur certaines pages dans firefox après upgrade à Debian Jessie ?
dpkg-reconfigure fontconfig-config
puis directement en faisant F5 sur un page problématique c'est reparti…