Auto-hébergement sous OpenBSD : gestion des utilisateurs et de la configuration

Coucou,

J’auto-héberge un petit serveur sous OpenBSD. Il fait tourner du mail (OpenSmtpd+Dovecot) et du web (Nginx, à migrer bientôt sous OpenHttpd) qui ne sert pour l’instant que du contenu statique.

Tout fonctionne bien, mais le dossier /etc est un peu… bordélique. J’aimerais avoir tous les fichiers de configuration qui m’intéressent rangés dans un dossier à part, duquel je peux faire des sauvegardes facilement, et idéalement travailler dessus depuis mon ordi portable. Ansible semble répondre à mon besoin, mais il ressemble à une usine à gaz… existe t-il des choses similaires, mais bien plus légères, pour effectuer ce genre de tâches ? En ce moment j’ai un dossier /home/config, et /etc contient des liens symboliques qui pointent vers des éléments de /home/config, mais ça me semble affreusement crade.

En outre, je vais bientôt avoir accès à plusieurs autres serveurs, hébergés chez des amis. Nous aimerons autant que possible fournir un seul service, géré en parallèle par tous les serveurs. Pour le mail, ce n’est pas très difficile : l’un des serveurs est MX primaire, les autres sont MX secondaires. Nous avons l’idée suivante :

• le MX primaire fait tourner un démon Smtp et un démon Imap normalement ;
• les MX secondaires font tourner des serveurs Smtp qui accumulent les mails entrants et les redirigent vers le MX primaire ;
• en outre, le MX primaire fait des copies de sauvegarde régulières de toutes les boîtes mail vers les MX secondaires ;
• les MX secondaires font tourner des démons Imap qui permettent d’accéder aux boîtes mails en lecture seule.

De cette façon, les mails sont quand même accessibles en lecture seule en cas de panne du MX primaire, et il est facile de promouvoir un MX secondaire en MX primaire.

Cette configuration vous semble t-elle raisonnable ?

Ici, il y a beaucoup de configuration à gérer sur plusieurs machines, un ansible-like semble donc d’autant plus important.

Question subsidiaire : comment partager la liste des utilisateurs entre toutes les machines ? LDAP semble très lourd à mettre en place, et en outre nous aimerons quelque chose qui résiste à la panne d’un serveur. (Il peut y avoir un serveur maître avec lequel tout le monde se synchronise, mais si le serveur maître est occasionnellement en panne, ça ne doit pas empêcher les autres serveurs de tourner avec la dernière liste d’utilisateurs connue.)

Enfin, nous aimerions procéder un peu de la même façon pour les pages Web : avoir un serveur maître, mais s’il tombe en panne, les autres serveurs peuvent prendre le relais et continuer à servir les pages. Pour des fichiers statiques, cela ne pose pas trop de problèmes : on peut faire des copies avec Rsync, et du load-balancing au niveau des DNS. Mais si nous souhaitons héberger des applis Web (par exemple un etherpad), cette solution ne semble pas idéale…

Des idées sur tout ça ? Je suis en quête d’inspiration, donc n’hésitez pas à lancer vos idées, même si elles ne répondent pas exactement à mes questions.

Merci !

Pas compétent pour répondre à ta question, mais je passe juste te dire que ça fait super plaisir de te voir par ici, le loup. <3

Salut,

<3 <3 <3

Ce n’est pas qu’Ansible ressemble à une usine à gaz, c’est une usine à gaz.
Sinon, pour ta question de partage de fichiers, c’est peut être une idée débile, mais tu as pensé à la création de paquet ? A priori, tu pourrais avoir un serveur central où tu mets à disposition un ou des paquets à télécharger qui comprennent les fichiers à mettre en place sur les autres serveurs. Dans le cas où des modifications sont faites sur le serveur central, il te « suffit » de construire un nouveau paquet avec un numéro de version supérieur.

Du coup, si le serveur central est H.S., les autres ne savent pas vérifier s’il y a une nouvelle version du paquet, mais cela ne les empêche pas de tourner. Bon, après, cela fonctionne effectivement surtout pour des fichiers statiques (gene la liste des utilisateurs et mots de passe et des fichiers de config) et non dans le cas de changements fréquents.

À nouveau, c’est peut-être une idée stupide, mais est-ce que cela serait possible via NFS en faisant en sorte que le système partagé soit mis « en cache » (par exemple en mémoire) ou écrit sur le disque de telle manière à ce que la panne du serveur NFS n’entraîne pas l’indisponibilté des données ?

Pour les courriels, je ne saurais pas répondre, je n’ai encore jamais installé ni administré ce type de services.

PS : pour avoir publié le premier message employant l’étiquette « OpenBSD », tu as gagné la médaille Puffy, félicitations.

C’est intéressant le coup des paquets, mais pour les fichiers de configuration ça ne risque pas de poser problème ? Il y a de bonnes chances que mon smtpd.conf appartienne déjà à un paquet, ce n’est sans doute pas si facile que ça de l’écraser avec un autre paquet, si ?

Effectivement, je n’avais pas du tout pensé à NFS, mais ça ressemble assez fort à ce que je veux. Merci du tuyau !

Pour l’authentification, j’ai fini par imaginer deux trucs : soit un démon yp qui lit depuis une base SQLite, tenue à jour à coups de rsync depuis le serveur maître ; soit un cron qui regénère /etc/passwd et /etc/passwd.master à partir de ladite base SQLite quotidiennement. C’est affreusement crade, mais ça semble être une solution suggérée par la FAQ OpenBSD ?

Une médaille ? Ah, heu, merci. Ça fait plus «chien dressé» que «loup», mais je prends quand même.

A priori, si tu ne spécifies pas d’incompatibilité, non, le fichier sera écrasé sans autre formes de procès. Note, cela marche aussi avec une archive que tu construits à chaque modification, c’est juste que tu ne te reposes pas sur le système de paquet.

Ben, en soit, je ne trouve pas LDAP particulièrement propre, mais c’est mon avis. ^^"
Maintenant, s’agissant de fichiers relativement statiques, j’aurais tendance à les inclure dans les paquets, mais je ne sais pas s’il est si simple que ça de partager la base de données des utilisateurs (je veux dire : si cela ne pose pas de soucis du type « impossible de se connecter »).

Meuh non ! Avec Puffy cela fait « loup émancipé ».

J’auto-up ce sujet pour signaler Cdist, un utilitaire de gestion des configurations qui me semble plus raisonnable qu’Ansible. Le principe de base reste le même : on écrit une description de la configuration sur sa machine habituelle (laptop…) puis on lance cdist, qui se connecte en SSH sur le(s) serveur(s) et qui exécute les commandes appropriées pour mettre en place la configuration voulue (si ce n’est déjà fait).

C’est plus simple et plus flexible que de générer ses propres paquets, et (au cas où) ça marche même si les serveurs tournent sous des OS différents.

Je l’utilise également pour gérer l’authentification en SSH : j’ai une liste des utilisateurs (avec quelques paramètres : uid, shell, etc.) sur mon laptop, et j’utilise la directive __user de cdist pour m’assurer que tout le monde existe sur tous les serveurs. On utilise des clés SSH pour s’authentifier, il n’y a donc aucun mot de passe. Comme les dossiers utilisateurs (basiquement, /home) sont répliqués via rsync toutes les nuits, les utilisateurs peuvent changer de clé SSH eux-mêmes sur le serveur maître et ce sera reflété sur les serveurs secondaires après 24h maximum.

Enfin, j’ai basculé le couple OpenSmtpd/Dovecot vers des utilisateurs virtuels (au lieu des utilisateurs du système), stockés dans un fichier SQLite du serveur maître (et répliqué sur les autres, comme d’habitude). Le système de mails tourne dans un chroot et sous des restrictions assez agressives, qui n’ont dérangé personne pour le moment.

Tout cela est en test pour le moment, on verra ce que ça donne.

Il reste à réfléchir à l’hébergement Web. Pour ne pas me prendre la tête, je vais réutiliser le schéma : «un serveur maître prend tout le travail par défaut, et des serveurs secondaires prennent le relai en cas de panne». Je pense configurer Httpd de la façon suivante : chaque requête de la forme http://foo.example/$USER/… est passée en FastCGI à la socket unix /home/$USER/www/socket. Si cette socket n’existe pas, les fichiers de /home/$USER/www/ sont servis de façon statique. (Je ne sais même pas s’il est possible de configurer Httpd pour faire ça, au pire je ne garderai que la socket et je proposerai à mes utilisateurs un script fastcgi trivial pour servir des fichiers statiques.)

Concernant l’aspect «prise de relai en cas de panne», NFS avec du cache ressemble à ce que je veux, mais c’est aussi une usine à gaz. À voir.

Si ça génère de l’intérêt, je vous tiendrai au courant de mes avancées.

EDIT : dans tous les cas, quand j’aurai un truc bien stable qui me plait, je documenterai le tout en utilisant du literate programming (probablement avec Org-mode).

J’en profite pour signaler BCHS, ou : les développeurs C prennent leur revanche sur les développeurs Web.

Comment ça « d’autres OS » ?
Plus sérieusement, c’est effectivement plus fexible, également dans le cas où tu as une panne importante et souhaite rapidement reconfigurer tes machines puisque tu ne dois pas au préalable recréer un serveur de paquet.

Moi, ça m’intéresse.

<3 <3 <3

Si ça génère de l’intérêt, je vous tiendrai au courant de mes avancées.

Mais carrément !

J’en profite pour signaler BCHS, ou : les développeurs C prennent leur revanche sur les développeurs Web.

Sauf problème de connexion chez moi le lien est mort. Ce qui prouve que les développeurs C ont encore du taf pour concurrencer les devs web.

Chez moi, ça marche.™

Ça ne fonctionnait pas non plus pour moi quand Ezenku a posté son message mais ça remarche maintenant. Niveau reliability, on repassera.

Toute personne remettant en cause la fiabilité du C ou d’OpenBSD se verra infliger une lecture seule de 11 secondes (z’avez de la chance que la dernière norme soit la C11 ).

Et si on bash Node et Ruby (les trucs web à la mode/hipster), on passe combien de temps admin ? La dernière version de Node est la 7.7.4 => 774 secondes ça fait 13 minutes, je dis ça je dis rien.