Créer un démon Subversion

Par défaut le paquet subversion ne fournit pas de script init.d.
Nous devons donc le coder nous même. Cet article s’appuie énormément sur la documentation d’ubuntu.

De petites adaptations sont présentes pour être conforme à la logique Debian.

Créer un dépot SVN

sudoer~: addgroup svn --system
sudoer~: adduser svn --system --home /var/svn-repos/ --no-create-home --ingroup svn
sudoer~: chown -R svn: /var/svn-repos/

Configurer les fichiers

On prépare un fichier dans /etc/default/subversion. Ce fichier indique les paramètres requis à l’exécution du démon subversion.

sudoer~: nano /etc/default/subversion
#Virtual root for repositories served
REPO=/var/svn-repos/

Ensuite nous préparons le script init.d pour gérer les tâches d’exécution. Le script est complétement inspiré de la documentation ubuntu

sudoer~: nano /etc/init.d/subversion

#!/bin/sh -e
### BEGIN INIT INFO
# Provides:          subversion
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:     $local_fs $remote_fs $network $syslog
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Start/stop subversion daemon
### END INIT INFO

if [ -x /usr/bin/svnserve ] ; then
        HAVE_SVNSERVE=1
else
        echo "Svnserve not installed."
        exit 0
fi

. /lib/lsb/init-functions
. /etc/default/subversion

case "$1" in
 start)
        log_action_begin_msg "Starting SVN server"
       start-stop-daemon --start --chuid svn:svn --exec /usr/bin/svnserve -- -d -r $REPO
        log_action_end_msg $?
       ;;
 stop)
        log_action_begin_msg "Stoping SVN server"
       start-stop-daemon --stop --exec /usr/bin/svnserve
        log_action_end_msg $?
       ;;
 force-reload|restart)
        $0 stop
        $0 start
        ;;
 *)
         echo "Usage: /etc/init.d/svnserve {start|stop|restart|force-reload}"
        exit 1
        ;;
esac

exit 0

Activer le démon

Il ne faut pas oublier de rendre le script exécutable. l’utilisation de chmod suffit.

sudoer~: chmod 755 /etc/init.d/subversion

Debian fournit update-rc.d un script qui permet d’appliquer au bons endroits les appels au script lors du démmarage pour cela il s’appuis sur les informations LSB. Dans notre nous nous sommes inspiré ce celles utilisées par le script apache2.

sudoer~: update-rc.d subversion defaults
Adding system startup for /etc/init.d/subversion ...
  /etc/rc0.d/K20subversion -> ../init.d/subversion
  /etc/rc1.d/K20subversion -> ../init.d/subversion
  /etc/rc6.d/K20subversion -> ../init.d/subversion
  /etc/rc2.d/S20subversion -> ../init.d/subversion
  /etc/rc3.d/S20subversion -> ../init.d/subversion
  /etc/rc4.d/S20subversion -> ../init.d/subversion
  /etc/rc5.d/S20subversion -> ../init.d/subversion

Messages

  • Et sinon (oui désolé, je troll)

    mkdir repo.git

    cd repo.git

    git init —bare

    git clone git@host:repo.git

  • S’lt

    Oui git c’est bien. À titre personnel, je ne travaille même qu’avec ça. Tu peux voir par exemple Giggle : Client pour GIT.

    Donc ce n’est même pas amusant, tu ne trolles pas. C’est juste hors sujet pour le coup.

    Mais ne t’inquiètes pas, tu vas avoir plein d’autres occasions :)

  • Et quel est l’intérêt, plutôt que d’utiliser Apache ?

  • Pourquoi svnserve et pas Apache/Dav_svn ? On peut noter au moins :

    • d’optimiser un peu mieux ses ressources
    • la volonté d’isoler les services

    Apache est largement plus consommateur de ressources que svnserve. Ce qui peut déjà faire pencher la balance. Une machine délicate acceptera plus facilement svnserve. On peut noter aussi qu’on limite les problématique de maintenance, du fait qu’on utilise moins d’applicatifs.

    Ce qui nous amène au second point, isoler les services. Si on souhaite passer par Apache cela amène un nombre certain de dépendances qu’on ne souhaite pas avoir à subir.

    On peut rétorquer que si on installe Trac, ça ne coûte rien de mettre en place Dav_svn. C’est une des raisons qui ne me font pas particulièrement aimer Trac :) On devrait pouvoir isoler ces services.

    En contrepartie svnserve est loin d’être idéal car on ne peut utiliser ldap pour gérer les développeurs, ce n’est pas sécurisé. Il est bien plus simple de mettre en place un https:// qu’un svn+ssh ://

    Finalement pourquoi pas Apache, parce qu’il devrait venir en complément d’un service de base fournit pas svnserve.

Un message, un commentaire ?

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.