Description
Cette page décrit l'utilisation de bcfg2 en pratique.
Installation
Lors de l'installation d'un serveur (pour l'exemple ça sera toto) la première chose à faire, après lui avoir ajouté le support du réseau, c'est d'installer bcfg2 puis de lui demander de configurer le serveur avec au moins les définitions communes à tous les serveurs du Cr@ns (groupe crans, cf wiki:Self:../ArchitectureCrans):
pour cela rajouter dans /var/lib/bcfg2/Metadata/clients.xml sur le serveur bcfg2:
<Client name="toto.adm.crans.org" profile="toto"/>
puis créer le profile dans /var/lib/bcfg2/Metadata/groups.xml:
<Group name="toto.adm.crans.org"
profile="true">
<Group name="crans"/>
</Group>
Éventuellement on peut rajouter des groupes supplémentaires pour rajouter des services.
Comme bcfg2 est encore en développement il y a pas mal de fonctionnalités en plus dans la dernière version qui ne sont pas dans la version du paquet dans debian stable. C'est pourquoi on a un paquet maison.
Il faut donc commencer par ajouter le dépôt Debian du crans avec en particulier le dépôt maison. À mettre dans /etc/apt/sources.list:
deb ftp://mdr.adm.crans.org/debian etch main contrib deb ftp://mdr.adm.crans.org/debian-volatile etch/volatile main contrib deb ftp://mdr.adm.crans.org/debian-security etch/updates main # Paquets maison deb ftp://mdr.adm.crans.org/custom ./
Ensuite:
toto# aptitude update; aptitude install bcfg2
Là il va râler pour la clé, il faut l'accepter. (TODO: améliorer ça avec un script d'installation de dom-U ?)
Ensuite il faut créer un fichier de configuration initial pour bcfg2 (/etc/bcfg2.conf), le plus simple c'est de le recopier depuis un autre serveur:
toto# scp zamok:/etc/bcfg2.conf /etc/bcfg2.conf
Ensuite on lance bcfg2 pour qu'il fasse tout le nécessaire (avec -v pour voir ce qui se passe):
toto# bcfg2 -v
Ouf ! pas besoin de configurer à la main l'authentification par ldap, le nfs, d'installer tous les outils indispensables...
Faire des modifications
Vous avez fait des modifications sur le dépôt, vous voulez maintenant les propager sur les autres serveurs. Bien sûr vous êtes sérieux et avant de pousser la configuration sur toutes les machines vous commencez par le faire sur un dom-U de test pour voir si tout marche bien.
Pour cela vous vous loguez sur ce dom-U, puis vous lancez la commande suivante:
# bcfg2 -v -I
Cette commande va demander la configuration au serveur et appliquer les changements. L'option -I permet de faire les modifications en mode interactif, bcfg2 demandant alors avant d'appliquer chaque modification.
Vous corrigez tous les problèmes et une fois que ça marche vous êtes prêt à envoyer violemment la nouvelle configuration sur tous les serveurs. Pour ça il y a la commande bcfg2-remote qui permet de demander à un client de se reconfigurer, à exécuter sur le serveur de bcfg2.
# bcfg2-remote -H toto
TODO: faire un script qui éxécute un bcfg2-remote pour tous les serveurs
TODO: patcher bcfg2 pour qu'il écoute sur autre chose que son interface principale, en l'occurrence sa patte sur le vlan public, ce qui rend cette commande totalement inutile pour l'instant vu qu'on fait passer bcfg2 par le vlan adm ...
Un peu plus loin
Alors là vous êtes près de la crise de nerfs, vous avez modifié des fichiers et bcfg2 refuse de vous produire une conf pour un client. Pas de panique, on dispose de l'outil bcfg2-info assez utile pour déboguer.
Lancer bcfg2-info sur le serveur:
# bcfg2-info
Il va alors lire tout le dépôt et éventuellement signaler quelques erreurs.
1. Regarder déjà ces erreurs s'il y en a.
Sinon vous disposez maintenant d'une console dans laquelle vous pouvez notamment taper help. Une commande particulièrement utile est buildfile qui génère un fichier de conf à partir du dépôt.
2. Regarder les erreurs lors de la génération du fichier de conf.
3. S'arracher les cheveux s'il n'y a aucune erreur dans bcfg2-info, ou tout simplement se plonger dans le code source.
Note: bcfg2-info ne surveille pas le dépôt comme le fait bcfg2-server, si vous modifiez les fichiers entre temps il faut taper (deux trois fois jusqu'à ce qu'il y ait 0 mises à jours) la commande update pouà la fin que les modifications soit prise en compte.
Utiliser les domU pour faire des tests et éviter de tout péter
Le scénario à éviter est le suivant:
- 1. On fait des modifs sur sa copie locale du dépôt
- 2. On record et on envoie le patch
- 3. On lance bcfg2 et on se rend compte qu'on a fait des erreurs de syntaxes
- 4. On fait des commits pour corriger les erreurs de syntaxes
- 5. Au final il reste des bugs
- 6. On corrige les bugs et on refait plein de commits
Et à la fin on se retrouve avec plein de commits inutiles et un dépôt qui est resté inconsistant pendant un bout de temps.
Pour éviter ça il y a les deux domU bcfg2tmp0 et bcfg2tmp1. bcfg2tmp1 fait tourner un serveur bcfg2 avec une copie du dépôt. Ces deux serveurs utilisent bcfg2tmp1 comme serveur pour bcfg2. La bonne procédure est donc la suivante:
1. On édite les fichiers. Pour ça vous faites comme vous voulez, moi j'ai mis ma clé dans le compte root sur bcfg2tmp1 et je monte la racine en sshfs... -- WikiDim
- 2. On test sur bcfg2tmp1 et/ou bcfg2tmp0. AU passage on peut utiliser bcfg2-repo-validate qui indique s'il y a des erreurs dans les fichiers xml.
- 3. Une fois que ça marche on fait un commit et on l'envoie sur le serveur principal de bcfg2.
