Administration d'un serveur SVN à l'aide de SVN

Ma vie trépidante d'administrateur m'a amené dernièrement à mettre en place un serveur SVN en place (en utilisant le module Apache couplé avec authentification LDAP) et surtout l'isolement de ce serveur dans une bulle derrière des firewalls.

D'un côté c'est vrai que c'est bien la sécurité et tout ça, mais de l'autre, à chaque fois que j'ai envi de modifier un truc sur mon serveur, je suis un peu obligé de me connecter via un VPN + tunnel SSH. Comme chacun sait, je suis un gros feignant et c'est pas par gaîté de coeur que je m'y connecte. C'est donc assez naturellement que je me suis dit : et si j'utilisais un repository SVN pour faire mon administration ? Diabolique non ? De plus je gagnais instantanément un suivi de qui modifié quoi sur mon serveur SVN. Très pratique pour savoir qui taper en cas de problème.

Création du repos adminsvn

La première étape a été de créer un repository sur mon serveur qui allait me servir à ça. Pour cela, rien de plus simple, on crée un repository SVN :

$ svnadmin create /var/svn/adminsvn

On crée ensuite un trunk pour faire jolie ainsi qu'un sous-répertoire admin :

$ svn mkdir --parent file:///var/svn/adminsvn/trunk/admin -m "Création d'un trunk/admin"

Nous allons maintenant alimenter le fichier /etc/httpd/svn.d/droits-svn.conf afin de protéger le repository d'administration :

[groups]
admins_svn = yannig,cnorris

[/]
* = rw

[adminsvn:/]
# Personne ne peut lire le contenu de ce repository
* =
# Par contre, les admins SVN ont le droit de tout faire
@admins_svn = rw

Alimentons maintenant nos utilisateurs dans le fichier svn.passwd :

$ htpasswd -nb yannig mdpdeyannig > /etc/httpd/svn.d/svn.passwd
$ htpasswd -nb cnorris chucknorrisnapasbesoindemdp >> /etc/httpd/svn.d/svn.passwd

Ajoutons maintenant ces fichiers dans le repository avec la commande suivante :

$ svn add svn.passwd droits-svn.conf

Mise en place du mécanisme de post commit

Procédons maintenant à un checkout de ce repository SVN dans un coin de notre serveur (en tant qu'utilisateur apache ou www-data selon que vous soyez sous RH ou Debian like) :

$ svn co file:///var/svn/adminsvn/trunk/admin /etc/httpd/svn.d

Nous allons maintenant mettre en place un mécanisme de mise à jour de ce checkout. Rendez-vous dans le répertoire /var/svn/adminsvn/hooks et créons un fichier shell post-commit avec la commande suivante :

echo "svn up /etc/httpd/svn.d" > post-commit
chmod +x post-commit

Comme vous pouvez le voir, le script n'est pas super complexe.

Si vous n'avez pas utiliser le bon utilisateur pour faire le checkout, vous pouvez modifier les droits avec la commandes suivantes :

chown -R apache:apache /etc/httpd/svn.d

Déclaration d'un ensemble de repository dans apache

Déclarons maintenant la racine contenant le repository dans apache en créant le fichier /etc/httpd/conf.d/svn.conf avec le contenu suivant :

<Location /svn>
  DAV svn
  SVNParentPath /var/svn/
  SVNListParentPath On

  Options +Indexes
  AuthType Basic
  AuthName "SVN"

  # Gestion authentification
  AuthBasicProvider file
  AuthzSVNAccessFile /etc/httpd/svn.d/droits-svn.conf
  AuthUserFile /etc/httpd/svn.d/svn.passwd
  Require valid-user
</Location>

Un arrêt/relance de l'ami Apache et nous voilà prêt pour la suite.

NB : Il est bien sûr évidant que vous devez disposer de l'extension mod_dav_svn. Sous RHEL, vous devrez lancer la commande yum suivante pour procéder à l'installation :

yum install mod_dav_svn

Sous Debian, ce module s'appelle libapache2-svn. Vous devrez dans ce cas utiliser la commande suivante :

apt-get install libapache2-svn

Test de notre mécanisme

Cette partie est plus simple puisqu'elle va consister à faire des commits dans notre repository. Pour se faire, vous devez donc vous munir d'un client SVN. En tant que vieux barbu, je fais ça en ligne de commande depuis mon poste Linux :

svn co --username yannig http://monserveursvn/svn/adminsvn/trunk ~/adminsvn

Éditons maintenant votre fichier droits-svn.conf de la manière qu'il nous plaira et lançons le commit :

$ svn diff
Index: changelog.txt
===================================================================
--- droits-svn.conf       (revision 1)
+++ droits-svn.conf       (working copy)
@@ -1,3 +1,4 @@
-admins_svn = yannig,cnorris
+admins_svn = yannig,cnorris,nobody

[/]
* = rw

$ svn ci -m "Ajout de l'utilisateur nobody."
Sending        droits-svn.conf
Transmitting file data .
Committed revision 2.

Allons maintenant faire un tour sur notre serveur pour vérifier que le fichier droits-svn.conf a bien été mis à jour :

$ grep nobody /etc/httpd/svn.d/droits-svn.conf
admins_svn = yannig,cnorris,nobody

La modification a bien été prise en compte. Le mécanisme fonctionne bien comme prévu !

Utilisation de webdav en ligne de commande

Depuis quelques temps, j'ai comme projet de faire un serveur de publication. Ce dernier doit héberger des sources et autres RPM mais malheureusement, il n'est pas accessible en SSH et nous devrons passer par du WebDAV (en https).

Voici donc en quelques lignes comment le mettre en oeuvre sur un serveur apache sous RedHat Enterprise/Centos 6.

Configuration du serveur apache

Premier point, nous allons créer un nouveau point webdav pour notre serveur. Pour se faire, rien de bien compliquer, il faut créer un fichier /etc/httpd/conf.d/test-webdav.conf avec le contenu suivant :

Alias /test-webdav /var/www/webdav

<Directory "/var/www/webdav">
  Dav On
  Options Indexes
  AllowOverride None
  Order allow,deny
  Allow from all
</Directory>

Bien penser à alimenter notre fichier de mot de passe (/mon/fichier/htpasswd) à l'aide de l'outil htpasswd. Par la suite, nous utiliserons un utilisateur webdav_access avec xxx comme mot de passe.

Créons maintenant notre répertoire et attribuons les droits à l'utilisateur apache (ou www-data dans le cas d'une debian) :

mkdir /var/www/webdav
chown apache:apache /var/www/webdav

Un arrêt relance de notre serveur apache et tout est prêt pour la suite. Pour s'assurer que nous n'avons rien oublier, nous pouvons essayer d'y accéder à l'aide de curl :

curl -u webdav_access:xxx http://localhost/test-webdav/

Voyons maintenant la suite du programme

Maintenant que notre nouveau contexte fonctionne, nous allons essayer d'uploader un fichier à l'aide de curl. Pour se faire, il faut utiliser l'option -T suivi du fichier à uploader. Ci-dessous un exemple :

curl -u webdav_access:xxx -T welcome.html \
     http://localhost/test-webdav/

Le serveur devrait vous renvoyer une réponse en HTML vous indiquant la réussite de l'opération sous la forme du message suivant :

Resource /test-webdav/welcome.html has been created.

C'est bien beau mais on voudrait également gérer des sous répertoires. Il faut dans ce cas utiliser l'option -X MKCOL. Ci-dessous un exemple :

curl -u webdav_access:xxx -X MKCOL \
     http://localhost/test-webdav/new_dir

Le message suivant devrait vous indiquer que ça s'est bien passé :

Collection /test-webdav/new_dir has been created.

Reste ensuite à rajouter un fichier dans ce répertoire :

curl -u webdav_access:xxx -T welcome.html \
     http://localhost/test-webdav/new_dir/

Utilisation en point de montage

Nous avons vu les possibilités de notre serveur. Sachez qu'il est également possible de monter un serveur webdav sur un serveur Linux. Ci-dessous un exemple de montage de notre point de partage :

mount -t davfs http://localhost/test-webdav/ /mnt
Please enter the username to authenticate with server
http://localhost/test-webdav/ or hit enter for none.
  Username:webdav_access
Please enter the password to authenticate user  with server
http://localhost/test-webdav/ or hit enter for none.
  Password:xxx

Rendons nous maintenant sur le point de montage /mnt et faisons quelques tests.

• Lister le contenu du répertoire :

# cd /mnt/
# ls
lost+found  new_dir  test_webdav.txt  un  welcome.html

• Supprimer un répertoire :

rmdir new_dir

• Copier un fichier :

cp /etc/hosts /mnt/

Bref, vous l'aurez compris, tout ceci se comporte comme un FS normal.

Thruk une alternative à l'interface Web de Nagios

Il était une fois un moteur nagios ...

Si comme moi vous avez été amené a mettre en oeuvre plusieurs nagios, vous avez sûrement dû vous frotter a son interface Web a base de cgi et de fichier plat exporter toutes les 10 secondes.

Ne crachons pas dans la soupe, cette interface reste très bien pour une petite installation.

Malheureusement, avec l'évolution des besoins en supervision, il devient de plus en plus difficile de se contenter de cette interface. En vrac, on va donner les éléments suivants :

• Interface vieillissante qui (en dehors des nouveaux CSS des dernières version de nagios) n'a plus évolué depuis de nombreuses années ;
• Nécessité d'héberger les CGI sur la même machine que le moteur nagios ;
• Overhead d'écriture du fichier status.dat ;
• Désynchronisation de l'interface avec le moteur nagios (pour lancer un test immédiat - même dans le cas d'un test très court - l'interface vous rend la main tout de suite et vous devez attendre le lancement du test + le temps de rafraîchissement du fichier status.dat) ;
• Explosion des temps de réponse dans le cas d'une grosse installation ;
• Dans le cas où vous auriez plusieurs nœuds nagios, vous devez vous connecter sur la bonne interface pour consulter votre serveur.

Origine de Thruk

Thruk est donc un projet qui a démarré sur ce constat afin d'offrir une alternative sans pour autant dérouté complètement les utilisateurs en reprenant - dans les grandes lignes - l'aspect de l'ancienne interface. En réalité, cette interface apporte des améliorations très intéressantes par rapport à l'ancienne interface avec notamment les points suivants :

• Possibilité de déporter l'interface de consultation sur un serveur distant ;
• Possibilité de fédérer plusieurs noeuds nagios dans la même interface ;
• Compatibilité avec n'importe quel moteur du moment que ce dernier supporte Livestatus (Shinken, Icinga, centreon engine, check_mk).

Quelques pré-requis de fonctionnement

L'installation de Livestatus se fait en rajoutant un broker à votre moteur nagios. Pour plus de détail, vous pouvez vous reporter à l'article suivant : setting up and using Livestatus. A noter que check_mk et Shinken viennent nativement avec ce support.

Autre point, dans le cas d'un accès déporter, il sera peut-être nécessaire de mettre en place un outil vous permettant d'exposer votre socket Unix sur le réseau. La documentation officiel fait appel à l'outil Unixcat (qui vient avec nagios). Pour ma part, j'ai préféré utiliser l'outil socat qui m'a donné des connexions plus stable et plus rapide. Ci-dessous un exemple de commande pour lancer socat :

socat TCP-LISTEN:1958,interface=lo,reuseaddr,keepalive,nodelay,fork,crnl \
      UNIX-CLIENT:/var/lib/nagios3/rw/live,keepalive

Installation de Thruk

Le gros défaut de Thruk est tout de même la ribambelle de plugin perl CPAN qu'il a comme dépendance. Heureusement, l'auteur du plugin propose un package tout prêt pour la plupart des plateformes disponibles (Debian, RedHat, Ubuntu, etc.). Pour se faire, il faut se rendre sur la page de téléchargement du projet, choisir le package qui vous convient et procéder à l'installation du package.

A noter que le produit a tout de même besoin de quelques dépendances au niveau système (plugin fastcgi pour apache notamment). Il faudra donc bien penser à installer ces dernières sous peine d'avoir des erreurs au moment de l'installation du package.

Une fois l'installation terminée, Thruk va créer un fichier htpasswd avec comme administrateur par défaut thrukadmin (mdp thrukadmin). Dans le cas où vous auriez déjà un fichier de mot de passe, bien penser à modifier le fichier /etc/apache2/conf.d/thruk.conf afin de pointer sur le bon. Bien penser également à modifier le fichier /etc/thruk/cgi.cfg dans ce cas là afin de définir les droits adéquates.

Enfin, il vous faudra  modifier le fichier /etc/thruk/thruk_local.conf afin de pointer sur votre noeud de supervision. Ci-dessous un exemple d'interfaçage avec un moteur Shinken :

######################################
# Backend Configuration, enter your backends here
<Component Thruk::Backend>
  <peer>
      name   = Shinken
      type   = livestatus
      <options>
          peer    = 127.0.0.1:50000
     </options>
  </peer>
</Component>

Un petit arrêt/relance du serveur apache et nous devrions être en mesure d'utiliser Thruk.

Tour du propriétaire

Connectez-vous sur l'interface Thruk (http://MONSERVEUR/thruk/). On devrait vous demander un mot de passe (thrukadmin/thrukadmin par défaut).

Au premier lancement, vous devriez avoir à attendre quelques secondes (ce comportement est normal puisque apache va devoir instancier les process fastcgi de Thruk à ce moment là). Ce délais d'attente passé, vous devriez arriver sur l'interface de Thruk. Par la suite, les process étant déjà là, vous n'aurez pas ce temps d'attente.

Comme indiqué un peu plus haut, l'interface est quasi la même que celle des CGIs si on exclue la map graphique (mais elle est avantageusement remplacé par une grille qui est plus fonctionnelle).

Du côté des améliorations, on peut noter les points suivants :

• Champ de recherche plus efficace (utilisation d'ajax pour vous proposer des solutions lors de le champ de recherche avec proposition de choix de hostgroup, nom des services et bien sûr machine) ;
• Lors du lancement d'un test, l'interface se bloque tant que le moteur nagios n'a pas récupéré le résultat du test (plus besoin de faire de rafraîchissement) ;
• Intégration des graphiques de PNP ;
• Présence de lien permettant des exports au format Excel (je sais, je suis pas forcément fan mais c'est quand même pratique).

Globalement, l'interface est plus jolie, plus réactive et vous avez également d'autres raffinements auxquels je ne pense pas forcément (générateur de rapport, gestion de la conf etc.).

Bref, comme dirait l'autre, l'essayer c'est l'adopter !

mod_proxy_http Apache et console de gestion du load-balancer

J'ai eu à faire une petite étude entre deux type de load-balancing HTTP sur des serveurs d'application WebLogic et c'est à cette occasion que j'ai découvert une perle : la console apache de load-balancing.

Je vous propose de voir ensemble comment l'activer et ce qu'elle vous apporte.

Par la suite je travaillerai avec une RedHat Enterprise 5.3 mais le principe reste le même pour n'importe quelle distribution.

Activation du module mod_proxy_http

Premier point, il vous faut installer une version récente de apache 2.2 et vérifier que la conf de ce dernier fait bien référence au module mod_proxy_http :

[root@myserver conf]# pwd
/etc/httpd/conf
[root@myserver conf]# grep mod_proxy_http.so httpd.conf
LoadModule proxy_http_module modules/mod_proxy_http.so

Un petit coup de apachectl configtest nous assurera que nous n'avons rien oublié.

Création d'une boucle de charge

Placez-vous ensuite dans le répertoire conf de votre serveur apache et créez-y un nouveau fichier de configuration contenant les lignes suivantes (à adapter suivant vos besoins) :

<Proxy balancer://lb-http>
  BalancerMember http://127.0.0.1:7002
  BalancerMember http://127.0.0.1:7004
</Proxy>

ProxyPass        /sample/ balancer://lb-http/sample/
ProxyPassReverse /sample/ balancer://lb-http/sample/

Ici, les URLs sous le contexte /sample/ seront envoyées systématiquement vers nos deux serveurs d'applications Java hébergeant l'application sample.war.

Un arrêt/relance à l'aide de la commande apachectl restart et voici notre configuration pris en compte.

Activation de la console du load-balancer

Activons maintenant la console du load-balancer en ajoutant les lignes suivantes :

<Location /balancer-manager>
  SetHandler balancer-manager
  Order Deny,Allow
  # Deny from all    <- Decommenter ici pour bloquer les accès
  Allow from all #   <- lister les IPs autorisées en les séparant par des virgules
</Location>

Un arrêt/relance sera bien sûr nécessaire pour en profiter.

Utilisation de la console du load-balancer

Il suffit maintenant de rentrer l'URL de notre serveur apache suivi de /balancer-manager pour obtenir l'écran suivant :

De là, vous pourrez désactiver ou réactiver une instance en cliquant sur l'instance à modifier. L'écran en question est le suivant :

Il vous permettra également de modifier certains paramètres de poids sur vos serveurs HTTP/Java.

Pour finir ...

Le gros avantage de ce mécanisme est que vous pourrez ainsi désactiver une instance à la demande et pouvoir ainsi procéder à une maintenance, une mise à jour etc. en limitant au maximum les perturbations.

Pour les plus curieux, je n'ai pas d'autres conseils que d'aller consulter la documentation apache de ce module disponible à l'adresse suivante : http://httpd.apache.org/docs/current/mod/mod_proxy.html.