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