URL: https://linuxfr.org/users/spack/journaux/travail-communautaire-sur-un-serveur Title: Travail communautaire sur un serveur Authors: Spack Date: 2010年07月06日T15:28:38+02:00 Tags: debian et ubuntu Score: 5 Bonjour, Dans mon [post](http://linuxfr.org/forums/12/28930.html) sur le forum, j'étais à la recherche d'une solution pour agir sur la configuration d'un serveur de la même manière que l'on travail ensemble sur un code source. Le serveur est en fait une machine virtuelle à installer soit même. Celle-ci doit absolument utiliser le système Ubuntu Server et doit permettre la mise en commun la configuration afin que quiconque installe sa machine ait la dernière configuration en date et puisse partager ses modification avec les autres. Cette machine doit pouvoir se connecter de n'importe où donc aucune idée à l'avance des adresses IP utilisées. De plus il s'agit de la même machine donc chacune doit avoir la même configuration. Deux impératifs, la solution doit être simple et non contraignante pour être acceptée. Si on peut utiliser le serveur Subversion déjà en place, c'est un grand plus. **Installation :** L'installation de la machine virtuelle doit se faire aisément. Surtout si elle doit être réinstallée plusieurs fois. Pour cela, deux solutions ont été proposées : - [Kickstart](http://fedoraproject.org/wiki/Anaconda/Kickstart) ; - [Fully Automatic Installation](http://www.informatik.uni-koeln.de/fai/) (FAI). Kickstart est une solution que je connaissais déjà de nom qui a été créée par RedHat pour automatiser l'installation de son système. Il s'agit d'un simple fichier texte dans lequel on répond par avance aux questions posées lors de l'installation. On peut aussi installer les paquets que l'on veut et exécuter quelques commandes pour la configuration du système. Ce fichier peut être ensuite placé sur un CD-ROM, ou téléchargé par FTP/HTTP, ou etc... FAI est une autre solution qui a première vue est plus complexe. Donc j'avoue ne pas avoir trop y prêter attention tant j'étais déjà séduit par Kickstart. Etant donné qu'il s'agit d'un simple fichier texte, celui-ci peut facilement être versionné. Le serveur Subversion étant accessible publiquement, on pourra y mettre un serveur FTP pour télécharger le fichier d'installation. Seulement, il s'agit d'une solution RedHat. Moi je veux installer une Ubuntu Server. Quelques recherches montrent qu'Ubuntu est capable de s'installer avec ce fichier. Parfait ! Pour l'installation, il suffit d'ajouter la ligne suivante lors du boot sur le CD-ROM : ks=[ftp://serveur/fichier/kickstart](ftp://serveur/fichier/kickstart) L'installation se lance, juste deux confirmations à effectuer et le serveur est installé comme prévu. **Configuration :** Maintenant reste le partage de la configuration. Le [post](http://linuxfr.org/comments/1140839.html#1140839) de mathgl me rappel que [puppet](http://www.puppetlabs.com/) pourrait en effet faire l'affaire. Puppet est un système permettant de centraliser la configuration de plusieurs machines. Il s'agit d'un ensemble de fichiers textes dans lesquelles se trouvent des directives pour chaque système. Encore une fois, fichiers textes, facilement versionnable, parfait ! Un peu plus tard, je suis tombé sur [etckeeper](http://joey.kitenet.net/code/etckeeper/) qui place carrément tout le dossier /etc dans un contrôleur de version. Cette solution ne me convenait pas car beaucoup trop invasive pour le système (il installe des scripts un peu partout pour surveiller toutes actions dans le dossier /etc) et il ne supporte pas Subversion. De plus je ne souhaite modifier que quelques fichiers. Tout versionner est un peu trop. Donc on se lance avec puppet que je voulais essayer depuis un certain moment. **Puppet :** Alors ma première impression concernant puppet est : « C'est la galère ! » Les messages d'erreurs ne sont pas très clair, les logs sont rares et la documentation est encore un peu légère. Cela dit le système semble bien pensé même si je n'ai pas encore vraiment commencé à l'utiliser. Une fois que l'on arrive à tout faire fonctionner ça va. Dans les tutoriels trouvés sur le net on dit : - Installes le serveur puppetmaster. - Installes le client puppet. - Lance le client, il cherche alors le serveur qui doit correspondre au nom puppet par défaut. - Sur le serveur il faut entrer la ligne : puppetca --list - Tu dois voir que le client demande un certificat - Tapes : puppetca --sign mon_client - Ton client obtient son certificat - Le tour est joué. Chez moi, ça ne s'est pas passé comme ça. Tout d'abord, puppet fonctionne énormément avec les noms d'hôte. Donc soit on a un serveur DNS sur le réseau, ou soit il faut un fichier /etc/hosts garni bien comme il faut avec tout les hôtes du réseau et le nom exact. Dans mon cas, je ne connais pas les IP. De plus, deux IP différentes ne signifient pas deux machines différentes et mettre dans mon /etc/hosts le même nom pour plusieurs IP... hum... comment dire... c'est la galère. Il faut donc pouvoir contourner ce problème. Tentons quand même la méthode proposée sur le net. Une fois arrivé à la ligne _puppetca --list_, rien... Que se passe t-il ? Voyons dans les logs, rien... Côté client : _« notice: Did not receive certificate »_. Bien ! Quelques (heures de) recherches sur Internet et je tombe sur cette [page](http://www.karlesnine.com/post/2010/04/29/Puppet-story). 0.25 incompatible avec 0.24 ! Vérifions, le serveur sur Debian Lenny, version 0.24, sur la machine virtuelle, 0.25. Tout "s'explique" enfin. Donc je passe le paquet Debian en version testing, 0.25. Enfin, ça communique ! Cependant : « Could not resolve ip.du.cli.ent: no name for ip.du.cli.ent ». Ben oui, je pars du principe que je ne connais pas par avance les adresses IP donc rien dans mon /etc/hosts. Puppet lui cherche le nom d'hôte afin de faire correspondre ce dernier au certificat. En passant, le client vérifie lui aussi le certificat du serveur en fonction de son nom d'hôte. Donc, il faut aussi que la correspondance IP <-> nom d'hôte soit au moins dans son /etc/hosts. Et bien sûre, le nom d'hôte de mon serveur n'étant pas « _puppet_ », ça bloque aussi dans l'autre sens. La solution, forcer le client à demander un certificat en particulier et changer le nom du serveur. Pour cela, il faut ajouter les lignes suivantes dans le fichier /etc/puppet/puppet.conf du client : [puppetd] server=mon_serveur certname=mon_client Ainsi, le client, quelque soit son IP obtiendra automatiquement le certificat correspondant à « _mon_client_ ». Le nom « _mon_serveur_ » doit, lui, pouvoir être résolu par le client. Sur le serveur, ne connaissant pas les adresses des clients, il faut autorisé l'accès à tout le monde. On modifie alors le fichier /etc/puppet/fileserver.conf ainsi : [files] £spaces£ £/spaces£path /etc/puppet/files £spaces£ £/spaces£allow * [plugins] £spaces£ £/spaces£allow * Il faut aussi générer le certificat pour le client. puppetca --generate mon_client On copie ensuite le certificat sur le serveur vers le client : /var/lib/puppet/ssl/ca/signed/mon_client.pem -> /var/lib/puppet/ssl/certs/mon_client.pem /var/lib/puppet/ssl/certs/ca.pem -> /var/lib/puppet/ssl/certs/ca.pem /var/lib/puppet/ssl/private_keys/mon_client.pem -> /var/lib/puppet/ssl/private_keys/mon_client.pem Et voilà normalement avec tout ça, ça devrait être bon. **Et le versionning dans tout ça ?** Il me semble que puppet permet d'importer des modules (ensemble de fichiers de configuration) depuis un serveur Subversion. Mais je n'ai pas regardé plus loin et j'ai carrément mis le dossier /etc/puppet du serveur dans mon dépôt. Ensuite, j'ai créé une tâche cron qui raffraichit ce dossier et relance le serveur. Il n'y a donc qu'à modifier les fichiers du dépôt, faire un commit, d'attendre un peu et la configuration est partagée avec toutes les machines. Voilà, il ne me reste plus qu'à voir tout ce qu'offre puppet maintenant. PS: Le verbe « _versionner_ » n'existe pas... ;)

AltStyle によって変換されたページ (->オリジナル) /