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

Si toi aussi tu as un fichier polkit (pklocalauthority) pour pouvoir monter des disques en CLI sans se compliquer la vie et sans pmount (je sais plus pourquoi c'était pas bon…), que donc tu utilises udisksctl, et que tout à coup le nom de l'action se prend un -other-seat parce qu'il y a une autre session existante en VNC, alors il suffit d'ajouter un gentil '*' au bout de l'action et zout :)

$ cat auto-mount.pkla
[Allow Automount]
Identity=unix-group:plugdev
Action=org.freedesktop.udisks2.filesystem-mount*
ResultAny=yes
ResultInactive=yes
ResultActive=yes

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

Début décembre, lors d'une "opération photo", après beaucoup de recherches et de discussions, je choisissais le Sigma 50-500mm F4,5-6,3 DG APO OS HSM. C'est un objectif pour appareil photo plein format, à fort zoom, ouverture correcte, stabilisateur optique, bref normalement de la qualité. Pourquoi Sigma et pas l'objectif correspondant de la marque du boîtier ? Parce que Sigma fait peu de boîtiers, mais des objectifs compatibles avec beaucoup de marques, est donc un peu en marge de celles-ci, et en passant propose des produits qui semblent de qualité similaire pour beaucoup moins d'euros en échange.
J'ai acheté cet objectif dans l'idée d'avoir, pour les années à venir, un télé-objectif photographique de qualité, robuste, et relativement poussé. Pour partir sur quelque chose de bien quoi, tant qu'à faire !

Sauf que depuis le départ j'avais l'impression que les photos à l'infini pouvaient être mieux, une sorte de "flou" permanent, que ce soit en autofocus ou manuel. J'ai fait plein de tests, dans des cas différents, avec des paramètres d'exposition différents etc. et même un mail à Sigma France pour leur demander si c'était normal, jusqu'au jour où, en balade dans les Vosges, quelqu'un avec un Sony Cybershot DSC HX60V, un petit appareil compact, a pris en même temps que moi, la même photos d'une maison au loin. Et là, c'était clairement le drâme !

J'ai donc déposé l'objectif au SAV, et 12 jours plus tard j'ai pu le reprendre. Sauf que, la personne qui me l'a remis m'a annoncé une "mauvaise nouvelle" : ils n'avaient apparemment rien fait, car pas de problème détecté dans leurs tests ! Mais il m'a aussi prévenu que des fois ils font la maintenance de routine puis seulement après les tests et que donc j'avais de l'espoir… et que si jamais c'était toujours pas réparé, il suffirait de faire un 2e tour SAV en mettant bien en gras que c'était le deuxième tour et qu'ils devraient se bouger ce coup-ci :P

J'ai donc refait quelques tests (fichier ci-lié), et ça me semble concluant : c'est bon maintenant ! Peut-être une simple calibration de routine a suffit ? Peut-être ont-ils voulu cacher le problème en disant qu'il n'y en avait pas (pour les stats au autre) ? Ou une incompatibilité avec mon boîtier qui aurait été corrigée avec une mise à jour de routine du firmware ?

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

Dans une trame ethernet, le tag 802.1Q (aussi connu comme « dot1q ») se glisse entre la MAC source et l'ethertype.
Les 2 premiers octets (qui seraient ethertype sinon) sont une sorte de "magic number" pour dire « hééé c'est le numéro de vlan qui va suivre, pas le payload ». Ensuite -- et c'est ce que j'ai découvert aujourd'hui -- il y a 3 octet de classe de service, un niveau de priorité. Et c'est celui-ci que je cherchais (après m'être fourvoyé dans du DSCP, qui lui est dans la trame IP).
Apparemment c'est utilisé, et il est même précisé ici qu'on peut faire du 802.1Q uniquement pour ça (en mettant un numéro de VLAN bidon, 0).

NB : à la question « est-ce que ça fait fragmenter de mettre un tag 802.1Q » il semblerait que la réponse soit non, en fait ça rallonge juste la trame mais le payload reste aux même limites, ce qui est pratique (ça compte même pour diminuer le minimum du payload, logique).

Apparemment le client DHCP ISC place toujours la valeur DSCP des paquets émis à 4 :

DSCP 4 (Hex 10 if you look at the entire 8 bits incl ECN) is the old
ToS low delay value. Currently there is no way to change this in ISC DHCP.

Et comme il utilise des socket raw on peut pas non plus y toucher via netfilter…

Lorsqu'on configure la réplication dans dovecot, on peut donner un intervalle uid_min / uid_max de filtre sur les utilisateurs qui seront synchronisés.
Sauf que si la synchro a déjà fonctionné mais qu'on modifie ces limites après (par exemple on a des erreurs sur l'utilisateur "nobody"), dovecot continue s'en préoccuper. En fait apparemment il "retient" qui est concerné par la réplication.

Il suffit de :
doveadm replicator remove nobody
pour s'en débarrasser ! Je n'avais pas trouvé, mais là en replongeant dans ma configuration ces erreurs faisaient un peu trop de bruit dans les logs… et je suis tombé rapidement sur ce mail.

Liste des utilisateurs qui seront synchronisés :
doveadm replicator status ' '*'

Sale : pour "palier" au "problème" que Ubuntu a 127.0.0.1 comme serveur DNS dans le resolv.conf par défaut (dnsmasq en local), les paquets docker utilisent google DNS par défaut pour le serveur DNS des conteneurs.
Forcément si on a un FW qui bloque on le remarque... mais même sinon, c'est très pas beau.

Je ne savais pas que strace avait des catégories de syscall prédéfinies, pratique.
On peut donc avec strace -e trace=network tracer tous les calls en rapport avec le réseau d'un process. Il y a pas mal d'autres catégories comme signal, memory…

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.

Je cherchais à faire du lookahead/lookbehind avec sed. Apparemment, pour avoir l'option perl regex, il faut passer à ssed, super sed. Et ça fonctionne.

En python on peut quand même bien s'amuser autour du langage… envie de savoir où est installé un module ? inspect.getsourcefile est là. On peut aussi accéder au code du module de la même manière. C'est toujours marrant de voir ce qu'il y a autour du langage, ici pour de la magie avec pyinstaller par exemple.
Je suppose que c'est pareil avec les autres langages du même style.

Ah oui, mettre le tangage à 90° ça change plein de choses… toujours autant "fun" de galérer avec hugin, mais apparemment tout à coup ça peut des fois tomber en marche, en tous cas pour moi oui. Mais là pour ce 360° vers le ciel avec 4 caméra fisheye j'en ai ch**. Vraiment.

Les userdir apache, vieux comme le monde. Mais je ne connaissais pas la variante "hors home" où en fait on peut choisir n'importe quel dossier racine dans lequel seront, par dossier, les données de chaque utilisateur. Ça me semble pas mal pour éviter de devoir ajuster les permissions x de tout le home par exemple.
Je ne savais pas non plus qu'on pouvait activer/désactiver des utilisateurs, ou rediriger vers des URLs externes.

Si toi aussi tu comprends pas pourquoi ton "appli" python sort rien dans le journal de systemd, pense juste aux basiques, et au buffer sur stdout.
Lancer python avec -u pour passer en unbuffered, au moins le temps du debug.

Un gros disque formaté en ext4 et de l'activité lente bizarre une fois monté ? C'est juste une étape d'initialisation qui se fait en arrière-plan : ext4lazyinit.