Sur une idée basée sur ce script qui affirme qu'il n'y a pas besoin de partition pour créer un disque de machine virtuelle et en utilisant extlinux, j'ai passé un peu de temps à transférer un conteneur LXC non-privilégié (fait alamano au début quand LXC 1.0 est sorti) vers une VM full qemu/kvm sous Proxmox.
Voici ce que j'ai fait :
sudo qm create 302
sudo qm set 302 -virtio0 local-zfs:10
=> création de la VM, avec un disque de 10 Go dans le zfs ; oui ça aurait pu se faire en une ligne mais entretemps j'ai réfléchi et au lieu de faire un fichier qcow2 et de le monter avec qemu-nbd et tout ce bazar je me suis dit que ça serait plus simple avec un bon vieux block device
sudo mkfs.ext4 /dev/rpool/data/vm-302-disk-0
=> pas de partition
sudo mount /dev/rpool/data/vm-302-disk-0 /mnt/
cd /mnt
=> tellement simple par rapport à un qcow2 + partition + éventuellement LVM… oui c'est pas chiffré mais pour un site d'affichage public, ça devrait aller
ssh IP-VM-avec-LXC 'sudo -S -u lxcguests lxc-usernsexec -- tar cf - /home/lxc/lxcguests/.local/share/lxc/web/rootfs/' | sudo tar xf -
=> copie avec tar pour la préservation des attributs de tout le rootfs ; lxc-usernsexec pour que tar soit exécuté dans le namespace uid du lxc (sinon root aurait été uid 100000 etc. selon ma configuration de l'époque). EDIT: Si l'on copie un LXC booté ou avec des montages, ajouter --one-file-system au tar cf pour être sûr de ne pas emporter trop de monde (/dev, /proc …) - FEDIT
sudo chroot .
apt install linux-image-amd64
=> on ajoute un noyau, ça va servir…
exit
sudo extlinux --install /mnt/
=> on le fait de l'extérieur, partition montée. d'après le man, c'est fait pour et ça nous évite de bind-mount /dev et compagnie dans le chroot ; là si on lance la VM on est déjà dans notre bootloader, qui demande quoi faire avec boot:

On peut alors booter en tapant tout à la main dans extlinux. Après un peu de tests et en regardant la config d'un autre extlinux qui fonctionne, j'ai pu arriver dans l'initramfs, puis dans un système qui boot mais avec le / en read-only.
Ma commande à la main dans extlinux (promt boot:) était :
/vmlinuz initrd=/initrd.img modules=ext4 root=/dev/vda
On utilise les liens dans / qui sont encore créés par le paquet du noyau sous Debian… :)
Ensuite j'ai posé ça dans un fichier de conf histoire de booter facilement quand même :
DEFAULT virt
LABEL virt
MENU LABEL Linux oasis
LINUX vmlinuz
INITRD initrd.img
APPEND root=UUID=db01b05e-2e90-4df7-a9b2-96a1ee04b1aa modules=ext4

J'ai aussi créé un fstab puisqu'il était vide (mais a priori pas vraiment utile du coup). L'histoire du / qui restait en read-only a perduré même avec un rw sur la cmdline linux, même avec le fstab… et est parti dès que j'ai mis systemd…
EDIT: sans fstab et avec systemd, read-only aussi ; réglé avec un fstab donc il faudrait les deux… ?

Bref ça fonctionne bien. J'ai perdu du temps à vouloir booter depuis extlinux à la main, à ne pas pouvoir monter / car pas de module ext4 (il disait juste "no such file or directory" ce con de mount…) et avec le read-only. Et j'ai aussi passé la mise à jour de jessie à stretch que j'avais jamais faite avant…

Classe, le site que j'utilise depuis des années pour savoir quand passera ISS par chez moi et à quelle luminosité publie une visualisation en 3D "en live" de la station au-dessus de la terre :) c'est mignon !

J'ai voulu tester du let's encrypt (oui…) sur une VM Alpine. Apparemment il y a enfin un setup simple, qui fait ce qu'on veut et qui juste marche. Mais je n'ai pas encore pu tester le renouvellement auto évidemment.
Avec les paquets, on peut installer acme-client-plus et acme-client. Le dernier est le client ACME d'OpenBSD, écrit en C et avec pas mal de fontionnalités (mais pas les wildcard si j'ai bien compris). Le premier est un script shell et les quelques fichiers de conf pour qu'il renouvelle au besoin.
Plus rien à copier, mettre en place, installer, il suffit de faire un "acme-client-plus issue" et hop on a son certificat (une fois qu'on a corrigé nos erreurs de DNS/routage/config serveur web/…). Un peu comme le script que j'avais mis en place il y a longtemps, à la main. Là c'est pareil mais en tout prêt.
À voir au renouvellement… !

Apparemment Alpine, bien qu'utilisant /etc/networg/interfaces à la Debian, n'a pas les petits sugar genre autoconf, dad-attempts, accept_ra etc.
Dans leur doc ils disent de désactiver la prise en compte des RA d'IPv6 avec un pre-up (soit avec un echo, soit avec sysctl). Seulement chez moi ça ne suffit pas, la route par defaut est déjà mise en place avant que ifup ne se bouge, donc on a une erreur "file exists" (mais qui ne gène pas). Par contre, la default est valide seulement le temps d'expiration du RA qui a été pris en compte. Donc au bout d'un moment la default disparait \o/ pour le voir, champ "expires" :
default via fe80::xxxx dev eth0 proto ra metric 1024 expires 1778sec hoplimit 64 pref medium
J'ai simplement créé un fichier sysctl :
$ cat /etc/sysctl.d/01-noslaac.conf
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.all.accept_ra = 0
net.ipv6.conf.all.dad_transmits = 0
net.ipv6.conf.default.autoconf = 0
net.ipv6.conf.default.accept_ra = 0
net.ipv6.conf.default.dad_transmits = 0
net.ipv6.conf.eth0.autoconf = 0
net.ipv6.conf.eth0.accept_ra = 0
net.ipv6.conf.eth0.dad_transmits = 0

et là plus de problème. Oui je bourrine, mais on sait jamais si le nom de l'interface venait à changer par exemple #traumatisé. :)

On peut ajouter dans Qemu via virtio une source de random qui remonte de l'hôte. A priori c'est pour accéder aux sources "matérielles" mais on peut aussi coller ça sur par exemple /dev/urandom.
J'ai testé pour voir, et ça a effectivement débloqué le "problème" que je vois, à savoir que ssh boot tellement avant que urandom soit setup qu'il attend des fois plus d'une minute d'avoir de l'entropie. Pas très important, juste pour le level up/connaissance.
Je n'ai pas eu besoin de lier cette sources au random "kernel" d'une manière ou d'une autre genre avec hwrng comme proposé par-ci par-là.

Pour pouvoir déverrouiller le disque chiffré de ma VM, je me suis dit que plutôt que de passer par l'interface et le noVNC ou de bidouiller le VNC hors interface, je pourrais utiliser le port série. J'avais déjà joué avec ça dans des VM il y a un moment, bah ça s'est pas trop arrangé.
Avec systemd, maintenant on a bien un getty partout automatiquement, ça c'est pas si mal.
Par contre, les messages de boot et le prompt pour le mot de passe ça a l'air d'être le chantier (et pas à cause de systemd, hein, no troll).
https://github.com/systemd/systemd/issues/9899
Le workaround qu'on retrouve partout, c'est d'installer plymouth… sur une VM serveur etc. je me suis d'abord dit que nope nope nope. Mais en vrai ça juste marche, y'a un thème "text only" par défaut et l'installation a pris…882 ko donc bon si ça fait le job, en vrai, pourquoi pas… bootlogd par exemple ne fonctionne pas avec systemd, donc pas trop d'alternative pour le mot de passe en lui-même donc bidouiller un truc juste pour le blabla de boot c'est pas si utile.
Bref en gros, ajouter un serial au KVM, configurer le cmdline de Linux, configurer grub, installer plymouth et on peut tout faire par les deux moyens (qm terminal et noVNC).

Utilisant depuis peu un serveur sous proxmox pour la virtualisation, avec du ZFS pour la gestion du raid soft et des "partitions" des VM, j'ai eu la surprise de voir une utilisation complètement folle de la RAM d'après les outils classiques (top/free/htop).
Il s'agit apparemment d'un cache ARC utilisé par ZFS qui est supposé être meilleur dans le cadre d'un serveur de fichiers (ce qui du coup n'est pas le cas mais est un cas fréquent).
D'après https://superuser.com/questions/1137416/how-can-i-determine-the-current-size-of-the-arc-in-zfs-and-how-does-the-arc-rel :
Because of how ZFS on Linux is implemented, the ARC memory behaves like cache memory (for example, it is evicted if the system comes under memory pressure), but is aggregated by the kernel as ordinary memory allocations.

Pour regarder :
arcstat, /proc/spl/kstat/zfs/arcstats, arc_summary

Pour jouer un peu :
https://www.svennd.be/tuning-of-zfs-module/
pour le désactiver :
zfs set zfs set secondarycache=none rpool
zfs set secondarycache=none rpool
cela réagit bien à un drop des caches (mais pas complètement, moi il restait dans les 400 méga) :
echo 3 > /proc/sys/vm/drop_caches

Pour l'instant j'ai remis, c'est supposé être capable de réagir en cas de demande de mémoire (mais pas toujours : some applications will require a certain amount of memory to start, or request memory on a rate that is quicker then ARC size can lower, resulting in a crash/swapping). Je verrai bien mais il vaut mieux être prévenu…

Avec gnuplot on peut faire des choses "compliquées" comme noter les min/max locaux d'une courbe. Bon c'est un peu verbeux quand même, et fait à la main mais ça fonctionne.
Ici le post montre le code pour les maximum mais il suffit de rajouter la condition pour minimum aussi, par exemple : || (last2y > lasty && $2 > lasty)
On remarquera que j'ai supprimé le paramétrage des colonnes qui rend le code quand même beaucoup moins lisible (tous ces column() de partout).

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

… et donc pour convertir en ordre lexicographique tout un dossier de JPEG, sans faire de boucle, sans gérer l'index soi-même et sans limite de taille de ligne de commande (sans * quoi), le tout en parallèle sur tous les cœurs dispo :

ls -1 | grep JPG | MAGICK_TMPDIR=/dev/shm parallel convert {} '/dev/shm/tests/$(printf %04d {#}).png'

(oui je fais tout dans shm, c'est plus rapide de mettre les fichiers temporaires et les résultats dans la RAM quand on en a assez, et ça bourrine moins HD/SSD)

Cacher un exchange où les administrateurs n'ont pas activé IMAP derrière davmail, ça devient presque supportable niveau réactivité quand on passe en accès EWS au lieu du webdav, comme suggéré sur le lien ci-lié.
Attention, ne pas mettre d'espace après l'URL :-' https://sourceforge.net/p/davmail/mailman/message/33184515/

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"

Ennuyé d'avoir à utiliser du Outlook/OWA/Exchange pour gérer sa boite mail d'une entité full-Microsoft ?
J'avais testé il y a plus de 5 ans davmail sur mon poste de stagiaire mais plutôt pas très concluant… il me semble que ça fonctionnait un peu mais que j'avais des problèmes, en tous cas j'avais laissé tombé et me suis farcis OWA depuis (et c'est bien bien relou).
L'autre jour en discutant avec un autre utilisateur de ce système, il m'a expliqué qu'il utilisait davmail sur son poste directement, et j'ai re-regardé un peu.
Il y a même un mode serveur. Aujourd'hui, je me suis dit que c'était le moment de tenter, et j'ai fait rapidement une petite VM sur mon desktop à la maison avec une Alpine basique et ça…
Tout a fonctionné comme sur des roulettes. La seule chose que j'ai changé de la configuration d'exemple à part les spécificités de connexion, c'est l'activation d'IMAP IDLE, qui derrière faire un polling… j'ai mis une minute pour mimer le comportement de l'interface web qui est instantanée. S'ils sont pas content de la charge ils avaient qu'à cocher la case IMAP dans leur Exchange, chose que je réclame régulièrement depuis le début sans succès.

Donc voilà, Exchange/OWA/Outlook on peut rendre ça compatible avec le rste du monde via davmail. Ça reste tout aussi crade derrière mais un peu plus utilisable, puisqu'on peut utiliser un vrai client mail (je découvre Thunderbird dans la foulée…).
Pour ouvrir à plus de gens, il resterait à chiffrer les communications entre le client et davmail, il y a les options mais je me suis pas encore foulé avec les certificats puisque pour l'instant ça ne sort pas de mon PC…

Depuis juillet, lorsqu'on a/utilise un drone de loisirs, il est théoriquement obligatoire de suivre une mini-formation en ligne et d'enregistrer son appareil. Je viens de m'y coller (mais je n'ai utilisé le mien qu'une fois depuis juillet il me semble).
En fait le bouzin est effectif depuis 3 jours de ce que je comprends, donc ça tombe bien.

En gros, ça se fait. Le site est pas trop mal fichu, la "formation" c'est juste regarder quelques vidéo infantilisantes, et le QCM de l'attestation c'est 20 questions quasiment toutes directement issues des vidéo, et on peut recommencer autant de fois qu'on veut si on se rate (c'est l'histoire du gag classique de celui qui veut gagner 3 secondes et perd 3 minutes…).

La formation est ici : https://fox-alphatango.aviation-civile.gouv.fr/ Il y a besoin d'un compte uniquement lorsqu'on veut passer le QCM.
Le site hors formation est directement sur https://alphatango.aviation-civile.gouv.fr/ et est pas trop mal fichu, il faut être honnête !

P.S. l'attestation de formation est re-générée à chaque fois qu'on clique sur télécharger… comme j'ai téléchargé la mienne à 13h34, j'ai attendu 3 minutes et l'ai re-créée pour avoir 13h37…

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.

Quand on essaye d'envoyer un mail avec openssl s_client, au moment de faire un RCPT TO, on a perdu : s_client voit la commande 'R' et essaye de renégocier la session TLS…
Donc bon à savoir : openssl essaye d'interpréter ce qu'on envoit…
(là on contourne avec rcpt au lieu de RCPT et lala)