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

Si on s'est trompé de nom (ou a oublié une parie) à l'installation d'une machine Proxmox, renommer n'est pas trop compliqué, suivre la doc officielle. Par contre (comme dit ici : https://memo-linux.com/proxmox-renommer-un-noeud/) il peut être nécessaire de faire un bon vieux reboot au bout, en tous cas on n'a pas réussi sans, même à relancer la plupart des services.

… en tous cas sur un Tplink Archer C7 v4, le hardware offloading fonctione avec OpenWRT 19.07 ! Je suis passé de environ 350 mbps avec iperf3 à 750 mbps (donc proche de la limite à 800 de mon abonnement fibre). C'est pas mal de savoir qu'un firmware libre arrive à ces débits sur du NAT sur un routeur grand public.

À savoir que l'offload se fait à coup de règles iptables, se configure donc au niveau du firewall (et si on utilise l'interface luci, ce sont des cases à cocher : Système -> Firewall -> software offload et hardware offload).

Exemple :
FLOWOFFLOAD  all  --  anywhere             anywhere             /* !fw3: Traffic offloading */ ctstate RELATED,ESTABLISHED FLOWOFFLOAD hw

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.

Tiens jouons un peu sur les chiffres, pour comparer à la louche (ordre de grandeur) la rente du gentil pauvre et la rente du méchant riche. Partons du RSA. Pas de troll "c'est pas assez/trop/branleur/etc." pour l'un ou pour l'autre, on s'en fiche là, on parle juste maths et on se concentre sur les revenus/rentes, pas le capital. On ne parle pas non plus de chômage ou autre allocation, juste le RSA.

Donc d'après ce site le RSA pour une personne seule c'est 559.74€ par mois. Donc 6716,88 par an.

Si on part sur de l'assurance vie, le placement préféré des français (!), on trouve à ce lien-là que du 2% de rendement c'est possible, pas rare : https://www.lerevenu.com/placements/assurance-vie/assurance-vie-les-rendements-2018-des-meilleurs-contrats. On soustrait la CSG de 17,2% et on ignore l'impôt sur le revenu (trop compliqué avec des délais de possession, un choix entre forfaitaire   abattement ou barème progressif etc. et existe aussi pour le RSA) et on arrive à 1.656% par an. 6716,88÷1.656×100 = 405608 et donc une personne au RSA a une rente équivalente à 400k€ d'assurance vie.

Si on part sur un placement en actions, qu'on ignore la spéculation (bah oui on parle de rente là, pas de capital on a dit), entre les boites qui n'ont pas de dividende et celles qui baissent de cours tout en gardant leur dividende haut on doit atteindre en moyenne du 3% sans trop se fouler (voir des pages avec les descriptions de porte-feuille de tel ou tel ponte du domaine). En appliquant la flat tax de 30% (oui ici j'inclus donc l'impôt sur le revenu, le calcul sera d'autant plus juste) on a du 2,1%. 6716,88÷2.1×100 = 319851 et donc une personne au RSA a une rente équivalente à 320k€ de placement pépère en actions.

Si on part sur de l'obligataire, je n'ai pas trouvé de moyenne mais de toutes façons le taux actuariel, si la valeur est assez liquide, s'ajustera en fonction du moment… là j'ai sous les yeux une obligation du crédit agricole 1,50 % décembre 2018 / 2028 et actuellement en juin 2019 elle cote à 102% donc à peine au-dessus. Si on applique aussi la flat tax, on a 1,05% (oui c'est pire que l'assurance vie car eux ils ont d'anciens placements à des taux plus hauts, alors que ici on parle de là maintenant sans arriérés). 6716,88÷1.05×100 = 639702 donc il faudrait 640k€ à investir dans la CASA 1.5 2018 pour arriver à un RSA.


Je trouve intéressant de voir cette comparaison, parce que pour moi 400k€ d'assurance vie à son nom c'est déjà une rente conséquente alors qu'au final, actuellement, c'est ce qui correspond à un RSA… il faut croire que rentier sur le capital avec peu de risque c'est pas efficace actuellement. Même si cette comparaison rapide est pleine d'approximation.

Souvent cité comme visualiseur de données de Graphite, Grafana est un outil web de visualisation de données arbitraires. Comme il n'est pas lié à un format de données ou une base de données précise, il est obligé d'être très souple, ce qui est plutôt pratique MAIS forcément on doit tout définir à la main… ce qui les a conduit à mettre en place un espace d'échange de "dashboards" communautaire plutôt pratique.
Pour l'installation, j'ai juste pris le deb fourni, dans une VM dédié… ça juste marche et puis c'est tout. Après on peut se balader dans l'interface, ça fait très web 2.0 lourd appli etc. mais en vrai c'est quand même pratique d'avoir ses graph interactifs, de pouvoir zoomer/voir précisément, etc.
Il y a un mécanisme de "commit" des modifications, ce qui fait qu'on ne risque pas trop de "casser" ses graph par erreur.
En plus de Proxmox, j'ai aussi installé un collectd (paquet dispo dans Debian) qui envoie dans Graphite. Le grafana a donc accès à ces deux sources via l'API de Graphite.
Le dashboard qui a marché immédiatement pour collectd (les autres avaient des problèmes d'accès aux données, genre sous-dossier vs '.' etc.) est : https://grafana.com/dashboards/9576
Dans les variables du dashboard, ils ont pensé à laisser une variable pour le nom du serveur ce qui fait qu'on a un menu déroulant pour passer de l'un à l'autre, pratique.
Pour l'instant le seul "problème" de Grafana outre le côté appli web, c'est que le format des dates est hard-codé de partout, on ne peut pas le changer, et est à l'américaine, ce qui est confusionnant pour nous… https://github.com/grafana/grafana/issues/1459

Je pense qu'avec proxmox + collectd + graphite + grafana on a moyen de faire quelque chose de vraiment propre pour surveiller une infrastructure (probablement plus propre qu'avec un outil tout fait comme zabbix, mais beaucoup moins clé en main car les données et le visualiseur sont décorrélés donc il faut passer du temps à tout définir, ou tomber sur un dashboard tout fait qui répond au problème).

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…

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

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