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 0Activer 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/subversionDebian 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
1. Créer un démon Subversion, 25 février 2010, 16:30, par Damien
Et sinon (oui désolé, je troll)
mkdir repo.git
cd repo.git
git init —bare
git clone git@host:repo.git
2. Créer un démon Subversion, 25 février 2010, 16:46, par km
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 :)
3. Créer un démon Subversion, 1er mars 2010, 12:40, par Stéphane Bortzmeyer
Et quel est l’intérêt, plutôt que d’utiliser Apache ?
4. Créer un démon Subversion, 2 mars 2010, 10:43, par km
Pourquoi svnserve et pas Apache/Dav_svn ? On peut noter au moins :
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.