Perso j'ai chiffré tout le serveur dédié (sauf /boot) avec un serveur httpd & cgi intégré à l'initrd et un formulaire qui permet de déchiffrer le / et continuer le boot.
C'est un vieux projet qui a bientôt 10 ans, j'ai mis les codes sur mon git : https://git.rapsys.eu/
J'avais ça sur un dédié, puis passé sur un dédié OVH puis Hetzner.
Distcook permet de générer une image tar d'une mageia configurée.
Distgen permet de générer deux images raw pour faire les tests via virtualbox.
Ihttpd est un packaging du httpd intégré à l'initrd.
Faudra que je documente ça à l'occasion, je crois avoir déjà mis ça dans un vieux commentaire sur linuxfr.
A l'utilisation c'est plutôt fiable, le seul problème est au redémarrage du serveur avec une mise à jour du kernel, dracut ou systemd qui auraient changé de comportement attendu.
En vérifiant que l'upgrade passe sur virtualbox en général on évite les soucis, je ne fais ça que quand ça a cassé en général pour savoir d'où vient le problème.
Puis ben c'est passage en rescue ou kvm et blind debug à distance :p
Les seules fois où j'avais pas accès au reboot, ça venait d'un changement de priorité systemd, modification dracut ou bug du serveur qui plante.
[^] # Re: 3, 2, 1 ... Sauvegarde
Posté par Raphaël G. (site web personnel) . En réponse au journal Y'a le feu. Évalué à 1.
Perso j'ai chiffré tout le serveur dédié (sauf /boot) avec un serveur httpd & cgi intégré à l'initrd et un formulaire qui permet de déchiffrer le / et continuer le boot.
C'est un vieux projet qui a bientôt 10 ans, j'ai mis les codes sur mon git : https://git.rapsys.eu/
J'avais ça sur un dédié, puis passé sur un dédié OVH puis Hetzner.
Distcook permet de générer une image tar d'une mageia configurée.
Distgen permet de générer deux images raw pour faire les tests via virtualbox.
Ihttpd est un packaging du httpd intégré à l'initrd.
Faudra que je documente ça à l'occasion, je crois avoir déjà mis ça dans un vieux commentaire sur linuxfr.
A l'utilisation c'est plutôt fiable, le seul problème est au redémarrage du serveur avec une mise à jour du kernel, dracut ou systemd qui auraient changé de comportement attendu.
En vérifiant que l'upgrade passe sur virtualbox en général on évite les soucis, je ne fais ça que quand ça a cassé en général pour savoir d'où vient le problème.
Puis ben c'est passage en rescue ou kvm et blind debug à distance :p
Les seules fois où j'avais pas accès au reboot, ça venait d'un changement de priorité systemd, modification dracut ou bug du serveur qui plante.