"Exceeded MaxStartups" : erreur du monitoring sur des services ouverts sur le monde en SSH… jamais vu.
En fait il s'agit d'une limite pour éviter les DoS, ajoutée dans OpenSSH en… 2000, MaxStartups. En gros un mécanisme pour limiter puis interdire les nouvelles connexions lorsqu'il y en a trop d'ouvertes mais pas abouties simultanément.
J'ai passé le minimum de déclenchement de 10 à 15. À voir si ça suffit.
Et oui c'est sur un port différent de 22 (trolls proof). Et oui il y a déjà fail2ban, mais il faut croire qu'il a pas le temps de réagir.

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

Les machines virtuelles (KVM en tous cas) peuvent lentement perdre du temps sur leur horloge et être de plus en plus en retard. Il semblerait que ce soit dû au fait que les interrupts virtuels ne sont pas forcément pile synchronisés (ce qui parait logique : si l'hyperviseur est en train de faire autre chose lui-même il ne pourra pas synchroniser toutes ses VM à temps).

Une horloge matérielle est émulée, mais elle n'est lue qu'au démarrage de la VM en général. On pourrait périodiquement aller la lire mais pas très propre.

On peut bien sûr juste laisser les VM se synchroniser elles-mêmes, mais si on est derrière un firewall ou qu'on essaye de limiter au maximum les accès réseau par exemple avec un firewall agressif sur les VM, c'est dommage.

Une solution est de laisser les hyperviseurs se synchroniser depuis Internet en NTP (ou pas si derrière un firewall bien sûr, mais du coup de la manière normale en interne), et de relayer cela aux VM, toujours en NTP. Les hyperviseurs sont donc juste relais. Mais il faut pour cela soit qu'ils aient soit une adresse IP virtuelle, soit systématiquement les ajouter tous dans les configurations des VM. On évite ainsi que chaque VM aille interroger individuellement les serveurs de temps. Il faut toujours ouvrir le firewall des VM, mais "seulement" vers les hôtes. Par contre la configuration change si on change d'hôtes sans IP virtuelle.

Une autre solution proposée ici est d'utiliser un mécanisme de précision entre l'hôte et les VM proposé en kvm par le module ptp_kvm. Cela fonctionne comme une source de temps, via un dev. Comme fonctionnerais une source GPS.
Dans ce cas, rien ne sort de la VM au niveau réseau, pas de trafic dupliqué vers l'extérieur ni de charge inutile, et rien à configurer de plus sur les hyperviseurs.

Script rapide de passage de NTP avec systemd-timesyncd ou chrony (comme souvent par défaut sur Debian et RedHat-like) à PTP, à faire sur la VM elle-même (rien à faire sur l'hyperviseur, en tous cas avec proxmox7) :

-#- charger le module et l'ajouter au boot
echo ptp_kvm | sudo tee /etc/modules-load.d/ptp_kvm.conf
sudo modprobe ptp_kvm

-#- passer à chrony si pas déjà fait et le configurer sans NTP mais avec PTP (dépend de la config précédente pour la partie désactivation du pool NTP)
sudo apt install chrony
echo "refclock PHC /dev/ptp0 poll 2" | sudo tee /etc/chrony/conf.d/phc.conf
sudo sed -i 's/^pool/#pool/g' /etc/chrony/chrony.conf

-#- recharge de la configuration
sudo systemctl restart chrony

-#- commandes de test
timedatectl
chronyc sources

Vieil article (déjà presque 10 ans !) qui récapitule les infos sur le TRIM (libération explicite de blocs d'espace de stockage, principalement pour les SSD).

J'ai testé sur une ancienne VM à moi, qui a subit plusieurs déménagements et upgrade (Debian Jessie à la base, Bullseye maintenant).
Pour avoir accès au TRIM à tous les niveaux, il faut bien l'activer dans crypttab (une VM Bullseye fraiche l'a de base). Il faut bien faire l'update-initramfs. Le reste ne semble pas nécessaire, mais peut tout de même être utile, comme par exemple pour libérer la place non-allouée d'un LVM (fstrim n'agit que sur des systèmes de fichiers montés).

Par exemple, pour purger l'espace non-alloué d'un LVM, j'ai utilisé la méthode bourrin d'ici : https://unix.stackexchange.com/questions/97143/utility-to-trim-unallocated-space-on-drive après bien sûr avoir activé l'option de discard automatique dans lvm (qui était désactivée, et l'est toujours dans un Debian Bullseye frais).
sudo lvcreate -l100%FREE -n blkdiscard VirtualPenguin
sudo lvremove VirtualPenguin/blkdiscard

27G -rw-r--r-- 1 john john 50G Feb 20 17:53 vm-111-disk-0.raw
15G -rw-r--r-- 1 john john 50G Feb 20 17:58 vm-111-disk-0.raw
=> je gagne bien une allocation de 12 Go, quand mon LVM a 12 Go non-alloués.

À noter qu'un Debian Bullseye a un timer systemd prédéfini pour lancer fstrim toutes les semaines. Ce timer est cependant désactivé quand on vient d'une upgrade (de Buster).

Pour voir où on peut fstrim (et donc voir à partir d'où ça coince dans l'empilement de couches logiques), lsblk -o NAME,DISC-MAX,FSTYPE est pratique (à peine modifié de l'article).

Attention à ne pas se laisser avoir par un dry-run (-n) de fstrim : il dira ne rien avoir TRIM, mais on pourrait supposer comme moi qu'il dirait ce qu'il aurait pu TRIM…

À mon sens, fstrim remplace donc avantageusement un zerofree + fallocate -d (pas d'écriture) mais ne travaille que sur des systèmes de fichiers montés, donc il faut penser au reste.

Debug résal des deux derniers jours, on a (re)vu plein de notions, et appris quelques commandes/sysctl sympas !

Qu'est-ce qui fait réagir un système avec systemd aux événements ACPI (poweroff etc.) ? logind !
Du coup la doc qui dit qu'il faut acpid n'est plus utile : quand acpid fonctionne, il appelle un script qui vérifie juste que logind tourne et qu'un appel dbus précis est possible (voir /usr/share/acpi-support/policy-funcs).

J'ai creusé tout ça parce que une seule VM parmi une grosse dizaine ne répondait pas aux injonctions d'extinction "propre" de son hyperviseur…
Il se trouve que cette VM était à la base un conteneur LXC non-privilégié (oui j'ai testé ça un moment pour voir). Et dans ce conteneur, le service systemd-udevd était masqué…

J'ai appris plein de choses sur udev, acpi, logind.
J'ai découvert les modules noyal "button" et "evdev".
Par hasard je suis tombé sur lsinitramfs.
Pas si mal :)

Pour lancer acpid en mode debug + log : acpid -d -l -f

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.

Notes de mon approche pour passer sur une fibre Orange du vieux PPPoE à DHCP. Le principal problème étant que dans ma zone il est nécessaire de taguer les paquets DHCP avec la bonne priorité VLAN… j'ai donc patché busybox et odhcpc6.

À noter qu'au passage, j'ai de l'IPv6 native, un débit qui passe de 100/100 à 400/400 et je ne remonte plus forcément à Paris (donc meilleur routage vers Francfort par exemple et géoloc au bon endroit). Et aussi, plus de changement d'IP systématique toutes les semaines, même si l'IP risque de changer quand même en cas de coupure prolongée.

… 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

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…

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

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

Pour ARN, pour travailler sur un incident on aurait eu besoin d'une sorte de smokeping (ping en continu avec graph pour voir quand il y a des problèmes (latence, pertes, …)). J'ai cherché rapidement et à part "smokeping" qui a un mode daemon et visualisation web, le reste avait l'air proprio/winwin/…
Je suis tombé par hasard sur la page liée ici, où, simplement, ils font ça avec… ping et gnuplot.

J'ai donc bidouillé à partir de là, et au final ça donne :

ping4 -i 10 addresse-à-tester -D -n | grep --line-buffered icmp_seq | awk -F [=\ ] -W interactive {'print $1, " ", $(NF-1); fflush()'} | stdbuf -o0 tr -d '[]' > /dev/shm/pings4

Le plus difficile est à chaque commande pour être sûr de ne pas bufferiser, ce qui permet de lire le fichier de sortie immédiatement, sans arrêter la commande ou autre. Pas de soucis de faire des petites écritures puisqu'on envoie dans un ramdisk.
On a donc des paires "timestamp RTT"

Pour grapher cela, on peut utiliser :

gnuplot -e 'set term png size 1280,1024; set output "ping.png"; set xlabel "Time (UTC)"; set ylabel "RTT in milliseconds"; set xtics rotate; set xdata time; set timefmt "%s"; set format x "%b %d %H:%M"; clamp(a) = (a < 42) ? a : 42; plot "pings4" using 1:(clamp($2)) notitle'

Ici le plus sioux c'est d'une part la gestion du temps (timestamp vers "pretty"), d'autre part la limite (min ou clamp) pour éviter d'avoir un graph tassé/pollué par les ping vraiment trop hauts. Ici tout ce qui est plus grand que 42 ms est affiché à 42.

Ce qui reste difficile, c'est la détection de pertes. On ne les voit pas vraiment, surtout quand le graph commence à être large. En général en cas de problème on le remarquera autrement (nous ici, session BGP qui tombent). Après on peut aller fouiller en mode interactif (sans utiliser la sortie PNG de gnuplot). Et là on voit rapidement quand il y a un "trou" dans une certaine zone. En général ça correspond aussi à des moments où il y a eu un lot de ping à plus de 42 ms de RTT.

Si des gens veulent utiliser ça, en tous cas c'est relativement sans prise de tête et sans installation ou autre !

Doc bien complète sur la remontée d'erreurs RAM/PCI dans le noyau Linux. Je suis tombé sur cette page en cherchant comment savoir la répartition de la RAM dans un serveur et ses caractéristiques, et en particulier son ranking (combien d'accès séparés / en parallèle sur les barettes).
À noter que l'outil edac-util ne fonctionne plus trop pour avoir les informations de ranking sur des intel modernes, puisqu'on n'a plus l'interface csrow mais dimm dans le sysfs.
dmidecode reste tout de même le plus simple pour trouver le ranking, lorsqu'il est affiché. Sous la main, j'ai des exemples de ranking 1, 2 et 4.

En faisant du debug sur un conteneur LXC, je me suis rendu compte qu'au milieu de syslog par exemple, il y avait des messages du noyau concernant l'hôte ou un autre LXC. J'ai trouvé ça pas top (même si pas très important).
Il y a apparemment deux facettes :

• /proc/kmsg, utilisé par rsyslogd
• le syscall "syslog" utilisé par dmesg
  Peut-être aussi via /dev/kmsg, mais ce n'est pas le cas chez moi (https://github.com/lxc/lxcfs/issues/131).

Le lien lié ici propose comment bloquer le syscall via les seccomp. Ça fonctionne.

Pour kmsg le lien précédent prétend que cela va casser des choses, j'ai tout de même voulu essayer. Par contre par défaut sur Debian Stretch, apparmor n'a pas l'air activé complètement, le module est là mais pas l'accès via proc (https://wiki.debian.org/AppArmor/HowToUse et aa-status). Je n'ai donc pas pu essayer de modifier cela (les autres restrictions, qui ont tout de même l'air de fonctionner malgré l'absence des paramètres cmdline sont dans /etc/apparmor.d/abstractions/lxc/container-base).

En attendant il suffit de cat /proc/kmsg depuis n'importe où pour tout savoir sur ce qu'il se passe sur le système côté noyau :P

Ah et aussi, ce n'est pas si simple que cela : https://lxadm.com/Lxc:_restricting_container_view_of_dmesg
D'autant que l'option est maintenant activée par défaut depuis Debian Stretch. En LXC root (pas non-privilégié donc) ça fonctionne tout de même (comme dit dans le lien github ci-dessus).

Juste pour éviter à des gens d'être surpris, maintenant sous Debian Stretch, les outils systemd pour la conteneurisation (nspawn/machinectl) sont dans un paquet séparé -- et c'est tant mieux ! :)
Après un upgrade, une fois le paquet installé, tout repart normalement.

Je n'avais jamais entendu parler de busctl… encore un outil de systemd.
La commande sert à interagir avec dbus/sd-bus de manière plus simple et plus intégrée que dbus-send et compagnie.
C'est relativement pratique, par exemple si on veut lister les différentes sessions/seat ouvertes, etc. et il y a un mode tree, monitor, introspect, …