TL;DR: je pose ça là histoire de le noter quelques part et peut être que d’autres trouveront l’idée intéressante.
Dans une autre discussion sur ce forum, je lis:
Le soucis avec ça c’est que si on éteint son serveur, la personne qui visite aura un équivalent de sablier qui tourne en rond pendant 30s avant d’avoir la confirmation que non y a rien à voir.
Hors ce qu’on souhaiterait dans ce genre de use case, c’est de pouvoir afficher un message expliquant que le serveur n’est dispo qu’à certaines heures.
On a le même genre de problématique lors des maintenances.
Alors évidement on peut faire des reverse proxy et autre trucs complexes qui nécessitent finalement plus de serveurs.
Du coup, je me demande quelles solutions pour gérer simplement et j’ai eue une idée de protocole (qui existe peut être déjà):
On déclare un enregistrement TXT « Server Unavailibility » du genre:
SI le navigateur trouve un enregistrement, alors il peut rediriger sur une autre page ou afficher un message.
Évidemment c’est un brouillon en 5min:
Il me semble évident qu’il y a un soucis de sécu si un attaquant envoie une fausse réponse TXT su1
il n’y a pas que le web, ça pourrait marcher avec d’autres trucs pas web, mais dans ce cas faut peut être juste prévoir un message plutôt qu’une page web de redirection
Peut être, que je réinvente la roue et que ça existe déjà.
Chez Résilien (avec @KillianKemps) nous prévoyons de couper seulement les services type HedgeDoc, Nextcloud …
Pour une question de référencement les sites internet seront en ligne toute la nuit.
Nous avons prévu (un jour) de mettre en place une redirection à l’aide de Traefik vers une page spécifique de notre site internet qui expliquera la démarche et qui explicitera quand le service redémarrera
Avec Traefik la démarche sera assez simple avec 2 fichiers de configuration qui pourra changer avec un crontab (on a jamais trop parlé du coté technique encore de notre coté mais c’est ce que j’avais imaginé).
L’approche via une ligne TXT m’a fait penser à la technique du Round-robin DNS mais qui malheureusement ne couvre pas le cas des machines arrêtées.
Ça ajoute une couche c’est certain, mais si l’objectif est surtout l’économie d’énergie alors un reverse-proxy parait intéressant s’il est par exemple sur un raspberry ou sur une des machines qui ne s’arrêtent pas (pour d’autres raisons). Il peut aussi permettre d’éteindre plus de machines.
Je pense en particulier à ce cas:
Un reverse-proxy configuré pour que lorsque son backend est down il serve au choix (1) une page qui affiche pourquoi le site est fermé ou (2) la dernière version qu’il a en cache de la page demandée, me semble intéressant dans ce cas. Pour le coup ça permettrait d’arrêter plus de machines.
Ça dépend ce que l’on cherche. Si on cherche à ne pas consommer du tout, alors il faut se rendre à l’évidence : ce sont des services géré par des humain·es, nous aurons besoin d’eux !
Par contre, si on cherche à diminuer au maximum notre consommation éléctrique sur une certaine période, alors avoir un raspberry pi 0 qui consomme <1w le soir pour nous permettre d’économiser les 500w et quelques de l’infra du jour, ça me paraît un bon compromis.
On pourrait faire bien plus low tech et avoir configurer sur nos cartes mère le rallumage automatique au rétablissement du courant, et brancher un relaie sur une horloge comptoise. Quand les aiguilles de l’horloge se touchent, un circuit se ferme, et hop les serveurs sont de retours en ligne.
Reste malgré tout le soucis du chiffrement. On va difficilement pouvoir contourner la saisie d’un mot de passe pour le déchiffrement d’une partition, à moins que les clés puissent être récupérées d’une manière qui me soit inconnue par des docker ou autre.
Beh tout dépend des détails mais a priori si quelqu’un a un accès physique il pourra poser sa clé ssh sur le serveur, et juste attendre que les volumes sont montés/déchiffrés. À ce moment là il a accès aux données et peut même ajouter un key slot dans luks.
Se prémunir de ça nécessite au moins une détection d’intrusion bien affûtée (ce qui, dans ma maigre expérience, n’est réaliste qu’avec beaucoup beaucoup beaucoup d’automatisation, peut être même zéro maintenance à la main) et beaucoup de précaution avant chaque déverrouillage de clé (ce qui contrarie le fait qu’un robot ou un humain déverrouille chaque matin le volume).
Bref ; je ne suis pas spécialement optimiste.
Il faudrait à minima désigner de quel(s) service(s) tu parles, je pense. Ton DNS autoritaire sur le domaine peut être ok avec un serveur web éteint à l’adresse renseignée. Ou alors forcer que exemple.com. soit un A ou un AAAA auquel cas toute la machine est concernée. (Et quid si le DNS est au même endroit ?)
S’il s’agit uniquement de web, tu pourrais imaginer plutôt passer par un entête un peu dans le style de HSTS.
Sinon il existe des protocoles comme SMTP qui tolèrent assez bien une disponibilité intermittente.
Une autre méthode serait de ne jamais lancer le service, sauf si il y a une demande qui arrive.
Par exemple, si quelqu’un va sur Hedgedoc, le service est lancé lors de la requete HTTP et s’éteint au bout de X minutes si il n’y a pas de trafic qui vient. Donc le premier usage démarre le logiciel (donc un peu plus long), mais ça s’arrête tout seul après.
Autant la partie démarrage à la demande, je sais que systemd peut le faire sans souci (via le socket activation, quand ç’est pertinent), autant la partie « extinction quand rien ne se passe » est plus rare dans mon souvenir (vu qu’il faut que le serveur le supporte, et la majorité ne le supporte pas).
Et bien sur, faut pas que le serveur se fasse rallumer par tout les bots qui passent.
