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.

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.

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

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

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

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…

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.

Je voulais faire un miroir chiffré de mes photos à distance qui soit simple, et sans trop de configuration à refaire en cas de problème. Pas de sauvegarde, pas d'incrémental ou quoi que ce soit, juste une copie de sécurité (cas où y'a l'feu quoi).
Là de base, on pense à rsync et ssh. Restait à trouver la partie chiffrement, avant transfert de préférence. J'ai déjà touché à ecrypts mais pas toujours très bien compris comment ça fonctionne et comment refaire le montage sur une autre machine (on y arrive mais des clefs sont dans un keyring lié à la session etc.). On trouve rsyncrypto qui chiffre d'une manière compatible avec la synchronisation des modifications (comme par rsync). Mais il faut donc une copie des données chiffrées avant de lancer le rsync. Pas le bon plan si on a des données qui peuvent potentiellement devenir volumineuses.
Encfs est une solution : entièrement userspace, simple à initialiser et utiliser.

On peut donc imaginer : données ⇒ rsync ⇒ encfs ⇒ sshfs vers le serveur distant.

Facile à mettre en place pour un administrateur système :
sshfs serveur:stockage montage-sshfs
encfs montage-sshfs montage-encfs
rsync -vriit données montage-encfs

Lorsque le dossier source d'encfs n'est pas encore initialisé, on nous demande ce qu'on veut comme option et un mot de passe. Les options sont enregistrées par défaut dans .encfs6.xml à la racine du dossier chiffré, donc sur le serveur distant. C'est pas forcément le plus malin mais au moins tout est au même endroit.

À noter :

• L'arboresence est recréée côté chiffrement, mais les noms sont masqués (hashage/chiffrement) ;
• Si on supprime un fichier chiffré ou si on démonte le sshfs (sauvagement, parce qu'il y a un problème réseau, …) l'encfs n'affiche juste plus les fichiers qu'il n'atteint pas, sans erreur. Si on remet en place, tout repart immédiatement.
• Avec les paramètres dans un fichier côté serveur distant, on n'a besoin que du mot de passe pour retrouver les données depuis n'importe où.
• Monter le sshfs avec -o idmap=user si on a des UID différents entre utilisateur local et distant.

Je me suis fait un petit script pour ne pas avoir besoin de reconstruire à chaque fois l'assemblage, et qui permet donc de faire un miroir de n'importe quoi n'importe où facilement (tant qu'il y a ssh sur le serveur distant et les 3 outils en local).

Envie d'accéder à un disque externe / clef USB / stockage quelconque de manière permanente sur un serveur sans se poser de question type fstab / autofs ?
Ce script tout simple qui se fait lancer par une règle udev est peut-être une solution. En tous cas quand ça fonctionne c'est tout simple et pratique : on a un mount.d / umount.d pour balancer des scripts si besoin et un lien est créé pour nous donner un point de montage fixe (pas comme un dev ou autre qui peut varier).

Tips :

• Pour voir si usbmount serait bien lancé par udev (et plein d'autre choses par rapport à l'événement déclencheur) : udevadm test --action=add /sys/class/block/sdxn
• Pour trouver le nom donné au système de fichiers trouvé sur le support : mettre en verbeux dans la conf puis lire syslog
• Pour déclencher l'événement udev d'ajout de stockage sans avoir à le faire physiquement : echo add | sudo tee /sys/block/sdx/sdxn/uevent
• Si on veut aussi le label de la partition en lien dans /var/run/usbmount, ajouter le bout de script qui nous arrange ; on peut obtenir ce label avec : /sbin/blkid -p "$UM_DEVICE" -s LABEL -o value

Attention : ne fonctionne pas si on a un système de fichier monté en userspace (ntfs/exfat ou tout autre FS qui passe par FUSE). Voir https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=774149 (assez long, en gros udev utiliise les cgroup et clean tout à la fin de la gestion de l'événement). Pour l'instant j'ai contourné de manière crade en éditant le script et en passant par at pour sortir du cgroup : echo mount […] | at now
Voir : http://unix.stackexchange.com/questions/28548/how-to-run-custom-scripts-upon-usb-device-plug-in/28711#28711

Bref ce n'est pas si simple au final même s'il y a quasiment rien dans ce script…
On ne peut pas trop éviter le petit tour par la doc avant de commencer : zless /usr/share/doc/usbmount/README.gz

Une table de partitions GPT est écrite au début de l'espace partitionné, mais aussi en backup au bout (voir schéma sur la page). Il y a donc une certaine symétrie. Et évidemment, on ne peut pas définir de partition après la table secondaire. Donc dans certains cas (agrandissement de disque virtuel, boîtier externe qui coupe artificiellement à 2To, …) on risque d'avoir un problème (pour moi, avec gdisk, ça s'est manifesté par le "last usable sector").
Comme il n'y avait rien sur le disque, j'ai juste recréé une table de partitions vide.
Apparemment, pour remettre la table secondaire à la fin, on peut utiliser sgdisk -e (je n'ai pas testé).

L'installation d'un module python avec un python perso échoue en chargeant le mauvais module python (le module du système au lieu du module recompilé dans l'install perso de python) ?
Il y a un petit fichier fourni par easy-install qui est changé et qui ajoute au PYTHONPATH des dossiers avant la variable d'environnement ! Et ce fichier est dans le home, donc commun à tous les python que l'utilisateur lance… donc s'il y a le dossier système dedans (va savoir pourquoi…) bah le chargement de modules persos utilise le module système quand même.

Pour mettre le fichier hors d'état de nuire :
mv .local/lib/python2.7/site-packages/easy-install.pth .local/lib/python2.7/site-packages/easy-install.pth.orig