• Installation et configuration de Subversion
  

Il ne reste plus qu'à configurer notre serveur Subversion. Celui-ci permettra de mettre à jour plus facilement les modules puppet à partir de machines clients et de garder une trace des modifications apportées aux fichiers. Afin de gagner du temps dans la configuration, tout comme Puppermaster, Foreman et MRepo, celui-ci fonctionne grâce à Apache via le module SVN/WebDAV. Pource faire, on commecne tout d'abord par installer les packages nécessaires :

[root@sophie conf.d]# yum -y -q install subversion mod_dav_svn

L'installation du package mod_dav_svn va, au passage, créé un fichier de configuration pour Apache. Dès lors, il n'y a qu'à le modifier :

[root@sophie conf.d]# cat >> /etc/httpd/conf.d/subversion.conf << EOF
<Location /svn>
  DAV svn
  SVNPath /var/svn
  AuthType None
</Location>
EOF

Il ne reste plus qu'à affecter les droits du dépot SVN à l'utilisateur apache puisqu'à travers WebDAV, c'est cet utilisateur qui gérera l'envoi et le téléchargement des données du dépot :

[root@sophie conf.d]# mkdir -p /var/svn
[root@sophie puppet]# chown -R apache:apache /var/svn/*
[root@sophie puppet]# chmod -R 775 /var/svn/*
[root@sophie conf.d]# service httpd restart
[root@sophie conf.d]# svnadmin create /var/svn

Maintenant que Subversion est installé, il faut créer le dépot local et y déposer les premiers modules développés. Ces modules sont ceux qui ont été créés par Foreman et se situe par défault dans le répertoire /etc/puppet/modules. On peut très bien imaginer prendre le répertoire /etc/puppet comme racine pour Subversion, mais on devra alors se farcir les fichiers de configuration de Puppet. Le plus propre est donc de mettre tous les modules dans un répertoire /etc/puppet/svn qui deviendra notre racine Subversion.

[root@sophie puppet]# mkdir /etc/puppet/svn/
[root@sophie puppet]# mv /etc/puppet/modules/ /etc/puppet/svn/
[root@sophie puppet]# chown -R apache:apache /etc/puppet/svn/
[root@sophie puppet]# chmod -R 775 /etc/puppet/svn/

Tout est prêt pour envoyer la liste des module vers le serveur Subversion. Toutefois, comme Subversion est généré à travers Apache, il faut que ce soit l'utilisateur Apache qui est tous les droits sur le serveur SVN. Pour ce faire, il faut que l'utilisateur apache ajoute les modules au dépot :

[root@sophie puppet]# su apache -s /bin/sh
sh-4.1$ svn co http://sophie/svn /etc/puppet/svn/
sh-4.1$ cd /etc/puppet/svn/ && svn add * && svn commit
sh-4.1$ exit

Les données étant dorénavant correctement envoyés au serveur, n'importe quel serveur peut télécharger et modifier ces modules, sous couvert que le dit serveur ait accès au port 80 du serveur Foreman/Puppet/MRepo/SVN (ca commence à faire long ). A-t'on fini ?? NON ! Ne surtout pas qu'on a modifié la configuration du serveur puppet ; les modules, auparavant dans /etc/puppet/, sont maintenant dans /etc/puppet/svn/ et il faut donc l'indiquer dans le fichier de configuration de Puppet, puis le redémarrer :

[root@sophie puppet]# sed -i "s@/etc/puppet/modules@/etc/puppet/svn/modules@g" /etc/puppet/puppet.conf
[root@sophie puppet]# service puppet restart

• Mises à jour automatiques de Subversion
  

Waow, c'est cool, on a un serveur Subversion flambant et ça claque ! Mais dans les faits, si à chaque modification d'un utilisateur, l'administrateur est obligé de se connecter pour balancer un svn update dans /etc/puppet/svn, non seulement c'est pas pratique mais la mauvaise humeur de l'admin va aller croissante avec le nombre de développeurs... Le mieux, ça serait de pouvoir mettre à jour automatiquement le répertoire des modules Puppet dès qu'un svn commit est soumis par un des utilisateurs. Pour cela nous avons utilisé les hooks de Subversion qui (contrairement au capitaine éponyme qui sert à rien) permettent de déclencher des actions au moment de certains événements. Dans notre cas, après qu'un svn commit a eu, on souhaite qu'un svn update soit executé dans le répertoire /etc/puppet/svn du serveur. On va utiliser pour cela le hook (Rien à voir non plus à voir avec un quelconque bibliothèque d'une quelconque Université de l'Invisible) dit de post-commit.

[root@sophie hooks]# cat > /var/svn/hooks/post-commit << EOF
#!/bin/sh
cd /etc/puppet/svn
svn up
EOF
[root@sophie hooks]# chmod 775 /var/svn/hooks/post-commit

• Un hook pour les corriger tous (facultatif}
  

Un post-commit, c'est bien, mais un pre-commit, c'est mieux ! OK, la mise à jour automatique du dépot est très pratique pour le serveur mais, comme à terme, le serveur est censé déployé un code sur tous ses clients, que se passera-t-il si le code est faux ?? La question se pose d'autant plus qu'à présent, le code est mis à jour sur le serveur sans aucune vérification. C'est pour cela que j'ai mis en place ce hook de pre-commit qui contrôle la syntaxe des fichiers soumis. Si celle-ci n'est pas conforme, le commit est interrompy jusqu'à correction du code erroné.

[root@sophie puppet]# yum -y -q install rubygem-puppet-lint

On installe donc tout d'abord puppet-lint donc la seule tâche est de vérifier le code Ruby soumis pour Puppet. C'est grâce à lui que mon code Ruby sera toujours propre et joli à lire

[root@sophie hooks]# cat > /var/svn/hooks/pre-commit << EOF
#!/bin/sh
REPOS="\$1"
TRANS="\$2"
for FILE in \$(svnlook changed -t "\$TRANS" "\$REPOS" | cut -b 5-); do
  if [ "\${FILE: -3}" == '.pp' ]; then
    svnlook cat -t "\$TRANS" "\$REPOS" "\$FILE" > /tmp/puppet-lint.check
    puppet-lint --no-autoloader_layout-check /tmp/puppet-lint.check >&2
    RETVAL=\$?
    rm -f /tmp/puppet-lint.check
    if [ \$RETVAL -ne 0 ]; then
      echo "Commit error: Syntax error in \$FILE" >&2
      exit 1
    fi
  fi
done
exit 0
EOF
[root@sophie manifests]# chmod 775 /var/svn/hooks/pre-commit