Gestion collaborative de l'administration des systèmes
Yves Agostini
Centre de Ressources Informatiques – Université Paul Verlaine - Metz
Ile du Saulcy - BP 80794 - 57012 Metz Cedex 1
Résumé
Depuis quelques années nos établissements mettent en place des services de plus en plus gourmands en ressources. Si la virtualisation permet de mutualiser les ressources matérielles, elle ne diminue en rien le travail d'administration système. Le nombre de serveurs (virtuels) augmente continuellement et il devient nécessaire de savoir gérer en équipe un grand nombre de serveurs ainsi que tous leurs fichiers de configuration.
Ce poster présente la solution mise en place au CRI de l'Université Paul Verlaine de Metz pour gérer de manière collaborative une trentaine de serveurs. Cette solution s'inspire des techniques utilisées dans le développement des logiciels libres. Elle combine l'utilisation d'un outil de helpdesk, d'un gestionnaire de versions, d'outils de communication ; mail, web, flux RSS, jabber et améliore notablement l'efficacité des administrateurs systèmes du CRI.
Mots clefs
administration système, gestion centralisé, configuration, svn, svk, jabber, gestion de ticket
Pendant longtemps le Centre de Ressources Informatiques (CRI) de notre établissement ne disposait que d'un administrateur système principal et d'un remplaçant. Le partage des tâches se faisait assez simplement : chacun gérait ses serveurs de prédilection, en informant son second des évolutions. La documentation se faisait par des commentaires dans les fichiers de configuration ou des notes dans /root. Les configurations particulières étaient (et sont toujours documentées) sur notre wiki public [1]. L'administration de certains serveurs était déléguée aux gestionnaires d'applications et leur gestion était classiquement notifiée dans un bon vieux cahier à spirales.
Malheureusement le nombre de serveurs ne cesse d'augmenter. D'une part par le mise en place de services de plus en plus gourmands et d'autre part la virtualisation de serveurs ont considérablement augmenté le travail d'administration système. Nous avons miraculeusement réussi à récupérer un troisième poste d'administrateur système. Il fallait absolument améliorer la communication entre administrateurs et la documentation des tâches effectuées. La solution mise en place depuis septembre 2008 s'inspire largement des méthodes de travail utilisées par les communautés de développement de logiciels libres. Il s'agit d'une part de la gestion des configurations à l'aide d'un système de gestion de versions et d'autre part de diverses méthodes de communication qui vont du mail classique, au forum jabber en passant par la gestion de ticket d'interventions.
Pour la gestion de version nous avons choisi le couple svn/svk. Subversion (svn) est actuellement le gestionnaire de versions le plus répandu et nous l'utilisons depuis plusieurs années pour nos développements. SVK est un gestionnaire de version décentralisé. Ce n'est pas l'aspect décentralisé qui nous intéresse puisque par essence nos serveurs sont toujours connectés et que l'objectif est de diffuser au plus tôt les modifications effectuées, mais plutôt l'aspect facilité d'utilisation. En effet, SVK est une surcouche à svn. Il permet d'injecter facilement un projet dans un dépôt svn. Les commandes sont très similaires à svn et surtout le projet n'est pas pollué à chaque dossier par un dossier « .svn ». Les systèmes unix ont l'avantage de conserver toutes leurs configurations sous forme de fichiers texte dans le dossier /etc. Ce dossier devient ainsi l'équivalent d'un projet de développement. On peut ainsi facilement voir qui a modifié quelle ligne de chaque fichier de configuration.
En amont, l'usage du gestionnaire de tickets d'intervention permet de planifier et de dispatcher les tâches entre les administrateurs. Le ticket initial est créé sur demande d'intervention d'un utilisateur ou sur un projet de l'équipe d'administration. Request Tracker, le gestionnaire de ticket choisi, permet de créer des fusions, dépendances, alertes sur les tickets et ainsi de réellement planifier un projet. Les webservices de Request Tracker lui permettent d'être aisément lié à subversion et jabber.
Sur debian un simple « apt-get install subversion subversion-tools », permet de disposer de l'ensemble des outils nécessaires à l'installation d'un serveur svn. L'accès distant à un serveur subversion peut utiliser diverses techniques. Nous avons choisi HTTPS et DAV pour la modularité des modes d'authentification avec apache. Nous avons alors également besoin de libapache2-svn. Nous disposons de dépôt publics accessibles en lecture sans authentification et de dépôts privés limités en lecture. C'est dans ces dépôts privés que nous déposerons les fichiers de configuration de nos serveurs. Un dossier « pub/ » contiendra les dépôts publics, un dossier « cri/ » contiendra les dossiers privés. La directive « Location » de apache permet de les distinguer et d'y appliquer des autorisations spécifiques. Les autorisations sont réalisées avec ldap.
Nous pouvons maintenant créer un dépôt « config » privé.
svnadmin create /var/svn/cri/config/
Ce dépôt doit être accessible par l'utilisateur apache
puis nous créons le « trunk » qui est traditionnellement le nom du dépôt de travail courant.
svn mkdir https://svn.univ.fr/cri/config/trunk
pour terminer par un dossier par serveur
svn
mkdir https://svn.univ.fr/cri/config/trunk/etc_monserveur
Avec
apache vous pouvez utiliser la directive « LocationMatch »
pour limiter l'accès au dépôt config, très
sensible, au seuls administrateurs. Vous trouverez en annexe 1 en
exemple de configuration de VirtualHost apache.
Sur debian/ubuntu svk est packagé. Il suffit alors d'un simple « apt-get install svk » sur la machine à co-gérer. Sur RedHat vous devrez l'installer à partir de CPAN. SVK est écrit en perl et est installable sur tous les OS. La configuration de subversion qui permet d'ignorer le stockage des logins et mot de passe n'est malheureusement pas prise en compte par svk. Vous trouverez en annexe 2 un wrapper à installer dans /usr/local/bin/svk qui nettoie le fichier qui contient ces mots de passe: .subversion/auth/svn.simple. Cela permet également à tous les administrateurs de continuer à utiliser le compte root pour travailler. Ils devront juste inclure leur login et mot de passe pour enregistrer leurs modifications lors de de la commande commit.
Nous allons créer un dépôt dans /root
svk depotmap /etc/ /root/.svk/etc
Comme je l'indiquais nous n'allons pas utiliser svk en mode décentralisé mais uniquement en mode miroir ainsi tous les enregistrements seront directement répercutés sur le dépôt svn centralisé.
svk mirror https://svn.univ.fr/cri/config/trunk/etc_monserveur /etc/mon_serveur
Nous pouvons ensuite importer le contenu de /etc dans notre dépôt svk qui sera immédiatement synchronisé avec notre dépôt global.
cd
/etc; svk import --to-checkout /etc/servname
Dorénavant dans /etc, chaque administrateur peut utiliser svk status ou svk st pour connaître les fichiers modifiés.
svk diff nom_du_fichier permet de visualiser les modifications.
svk log nom_du_fichier présentera l'historique des modifications pour un fichier particulier.
svk blame nom_du_fichier présentera le fichier en affichant l'auteur pour chaque ligne modifiée.
Les contraintes d'utilisation sont pour chaque administrateur de ne pas oublier de commiter avec svk commit ou svk ci après chaque modification et de commenter explicitement chaque changement. Nous avons également ajoutés les deux commentaires (rt: #numéro) et (closes: #numéro). Le premier permet d'ajouter les informations comme un commentaire au ticket RT référencé, le second ferme le ticket et préviens les demandeurs.
RT est un gestionnaire de tickets d'interventions, opensource en perl objet. Développé depuis 1996, il est utilisé par des entreprises comme Apple, des universités de Oxford au MIT, des CERTS, ou encore par des équipes de développement comme OpenSSL. Il est très simple à installer et surtout extrêmement adaptable. Tous les éléments, graphique ou code peuvent être surchargés.
Nous allons encore utiliser les versions packagées par debian. Ceci nous permet de bénéficier des mises à jour de sécurités et du support lors des changements majeurs de système, sans mobiliser une personne pour la maintenance de cette application.
Nous allons débuter traditionnellement:
apt-get install request-tracker3.6 rt3.6-apache2
Nous choisissons une base mysql. On crée un utilisateur « rtuser »:
mysql> GRANT ALL PRIVILEGES
ON rtdb.* TO ‘rtuser’@'localhost’ IDENTIFIED BY ‘wibble’;
mysql> FLUSH PRIVILEGES; QUIT
On génère la base pour RT:
#
/usr/sbin/rt-setup-database-3.6 --action init --dba root
–prompt-for-dba-password
Nous utilisons une authentification externe, à partir d'un REMOTE_USER généré par apache. Nous pouvons ainsi utiliser CAS avec tout module Apache. J'utilise Apache2::AuthCASSimple (apt-get install libapache2-authcassimple-perl).
On ajoute au fichier de configuration /etc/request-tracker3.6/RT_SiteConfig.pm
Set($WebExternalAuth , 1);
Set($WebFallbackToInternalAuth , 1);
Set($WebExternalAuto , 1);
Pour récupérer les informations complémentaire depuis le ldap. Nous surchargeons Web_Local.pm dans /usr/local/share/request-tracker3.6/lib/RT/Interface
Le premier webservice indispensable est la création de tickets par mail. Nous utilisons procmail et rt-mailgate-3.6 (disponible dans le paquet debian rt3.6-clients) pour dispatcher tous les mails adressés à support.univ-metz.fr vers la bonne file d'intervention. Un compte système local est crée dans la base RT avec des droits suffisants pour créer de nouveau tickets.
RT utilise le protocole de webservice REST. Vous verrez dans la configuration apache en exemple que l'url /rt/REST/1.0/NoAuth est exclue de l'authentification CAS. Nous utilisons le compte système local et limitons l'accès aux serveurs utiles.
Nous utilisons un second webservice pour commenter ou fermer un ticket en fonction d'un commit depuis svk.
Vous trouverez sur notre dépôt subversion [4] public les codes des clients que nous utilisons.
La gestion des droits des utilisateurs est très complète. Tous les éléments sont configurables en fonction de trois groupes différents « Tout le monde, Privilégié et Non priviliégié » et de trois rôles principaux « Demandeur, Intervenant, AdminCC ». Aucune autorisation n'est positionné par défaut et la configuration peut devenir extrêmement complexe. Notre site met à disposition notre configuration courante [5]. Vous y trouverez également de la documentation sur des modules complémentaires, par exemple RTFM: le gestionnaire de FAQs crées à partir des réponses aux tickets d'intervention.
Si l'utilisation de svk permet de se passer d'une cahier d'administration, il reste encore à améliorer la communication entre administrateurs. Nous allons utiliser divers canaux de communications pour diffuser les informations d'intervention sur les machines.
RT est le point d'entrée. La création d'une file permet de gérer un projet à long terme, chaque objectif ou problème peut être initié sous forme de ticket. Les possibilités de gestion de relation et de dépendances entre tickets permet également de planifier un projet à l'aide d'un groupe de tickets. On peut également sélectionner un groupe d'utilisateurs par ticket. L'historique du ticket permet de documenter le projet. L'interface web permet de diffuser l'information au groupe. Une gestion intelligente des mails transmet également les informations au groupe par mail et sans les inonder. Un accès direct par jabber est envisageable en utilisant les webservices REST.
Il existe de multiples clients web pour visualiser le contenu d'un dépôt svn. Le plus courant est viewcvs mais pour des raisons essentiellement esthétiques, j'utilise « svnweb ». Quel que soit le client que vous choisirez, soyez attentif à en limiter également l'accès aux seules personnes autorisées. Avec svnweb chaque dépôt est mappé sur une url. Nous utilisons les mêmes conventions que pour les dépôts en préfixant d'un « cri_ » les dépôts réservés, ainsi une directive LocationMatch sur /svnweb/index.cgi/cri_* permet de contrôler l'accès en lecture.
Les hooks svn permettent de déclencher une action lors d'un changement du dépôt. Dans notre dossier /var/svn/cri/config/ vous trouverez un dossier hooks contenant un ensemble de fichier .tmpl qui sont des template de scripts. Pour les activer vous pouvez les renommer en enlevant l'extension .tmpl et leur donner les droits d'exécution. Le hook le plus utilisé est généralement post-commit.
Si vous éditer le template post-commit, vous y trouverez par défaut l'appel au script commit-email.pl qui permet de recevoir un mail contenant commentaires et diff des changements. Vous n'avez plus qu'à renseigner les bonnes adresses de réception.
Vous trouverez sur notre site un script svn2feed.py qui permet de générer des flux rss publics ou privés [3]. Les flux publics n'affichent que la première ligne de commentaire alors que le flux privé affiche l'intégralité des commentaires et le chemin des fichiers modifiés. Des urls permettent d'accéder directement aux différences avec l'affichage web.
Le script svn-rt-comment.pl dans le hook post-commit permet de commenter ou fermer un ticket de RT. Request Tracker se chargera de prévenir les demandeurs.
L'usage des flux RSS nous permet de diffuser les informations de changement par d'autres biais que le mail.
En s'inspirant de l'usage d'IRC pour le développement de logiciels libres, nous utilisons un serveur Jabber (ejabberd) dédié au personnel de l'établissement. Les serveurs jabber permettent de créer des forums de discussion à accès limité ou public. Nous avons développé un robot jabber qui scrute les flux RSS. Les administrateurs présents dans le forum « cri » reçoivent en temps réel les modifications et peuvent directement en discuter. Un forum informaticien reçoit un flux RSS public. Figure 1
Figure 1 - communication dans un forum jabber
L'usage du flux RSS public est également diffusé dans un graphique temporel interactif (timeline) qui illustre les activités d'administration système du service. Mis à jour 3 fois par jour, il permet de diffuser publiquement une famille d'activités méconnues et peu prises en compte.
Figure 2 – timeline des activités d'administration système
L'augmentation du nombre de services et de système à administrer nous oblige à changer nos méthodes de travail d'administrateur système. La combinaison de l'usage de systèmes unix, où les configurations sont centralisées et sous forme de texte, et de système de gestion de version, nous ont permis d'améliorer la documentation de nos tâches et le dialogue entre administrateurs. La mise en production de la gestion de versions centralisée des fichiers de configuration depuis septembre 2008 et ensuite la liaison avec Request Tracker en mars 2009, nous a très certainement aidé à améliorer la qualité de la gestion de nos systèmes. Tous les outils sont disponibles dans les distributions debian. Vous trouverez en annexe les configurations spécifiques.
Ces solutions nous ont permis de nous enrichir d'outils de « service desk » conformes au bonnes pratiques ITIL.
La solution présentée s'améliorera bientôt avec la mise en production de RTFM qui permettra la collecte d'informations à partir des tickets d'interventions. La création de ces « articles » apportera une meilleure documentation sur l'état des systèmes et applications.
NameVirtualHost
svn.univ.fr
<VirtualHost svn.univ.fr>
ServerAdmin reseau@univ.fr
DocumentRoot /home/svn/html
# Public read repository
<Location /pub>
DAV svn
SVNParentPath /home/svn/pub
AuthType Basic
AuthName "LDAP"
AuthLDAPURL ldap://ldap.univ.fr:389/ou=people,dc=univ,dc=fr??sub?Mgroup=cri
AuthLDAPBindDN "cn=*****,ou=applis,dc=univ,dc=fr"
AuthLDAPBindPassword ******
order allow,deny
allow from all
# limitation en écriture au groupe ldap cri
<LimitExcept GET PROPFIND OPTIONS REPORT>
Require valid-user
</LimitExcept>
</Location>
# Private repository
<Location /cri>
DAV svn
SVNParentPath /home/svn/cri
AuthType Basic
AuthName "LDAP"
AuthLDAPURL ldap://ldap.univ.fr:389/ou=people,dc=univ,dc=fr??sub?Mgroup=cri
AuthLDAPBindDN "cn=*****,ou=applis,dc=univ,dc=fr"
AuthLDAPBindPassword *****
order allow,deny
allow from all
Require valid-user
</Location>
# Limitation svnweb
<LocationMatch "/svnweb/index.cgi/cri_*">
AuthType
Basic
AuthName "LDAP"
AuthBasicProvider ldap
AuthLDAPURL ldap://ldap.univ.fr:389/ou=people,dc=univ,dc=fr??sub?Mgroup=cri
AuthLDAPBindDN "cn=*****,ou=applis,dc=univ,dc=fr"
AuthLDAPBindPassword *****
AuthzLDAPAuthoritative off
order allow,deny
allow from all
Require valid-user
</LocationMatch>
</VirtualHost>
#!/bin/sh
EDITOR=vim /usr/bin/svk $@
if [ -d ${HOME}/.subversion/auth/svn.simple ]; then
/bin/rm ${HOME}/.subversion/auth/svn.simple/* 2>/dev/null
fi;
PerlOptions +GlobalRequest
<VirtualHost 195.xx.yy.zz:80>
ServerName rt.univ.fr
Include /etc/request-tracker3.6/apache2-modperl2.conf
RedirectMatch ^/$ /rt/
<Location />
SetHandler perl-script
PerlHandler RT::Mason
AuthType Apache2::AuthCASSimple
PerlAuthenHandler Apache2::AuthCASSimple
PerlSetVar CASServerName auth.univ.fr
PerlSetVar CASServerPath /
PerlSetVar CASSessionTimeout 360
PerlSetVar CASSessionDirectory /tmp
require valid-user
</Location>
<LocationMatch "/NoAuth">
Satisfy Any
Allow from all
</LocationMatch>
<Location /rt/REST/1.0>
Order Allow,Deny
Allow from 127.0.0.1
Allow from xx.yyy.zz. #mes serveurs mails
</Location>
</Virtualhost>
CRIUM, Drbd heartbeat rsync, http://www.crium.univ-metz.fr/docs/system/drbd/
CRIUM, Utilisation de subversion / svn, http://www.crium.univ-metz.fr/docs/devel/svn/
CRIUM, SVK, http://www.crium.univ-metz.fr/docs/devel/svn/svk.html
CRIUM, Dépôt RT, https://svn.univ-metz.fr/svnweb/index.cgi/pub_utils/browse/trunk/request-tracker
CRIUM, documentation Request Tracker, http://www.crium.univ-metz.fr/docs/system/rt/
CRIUM, Depôt robot jabber, https://svn.univ-metz.fr/svnweb/index.cgi/pub_jabberbot/browse/trunk