Yves Martin a écrit :
> On Sun, 2011-09-18 at 16:55 +0200, marc.terrier@??? wrote:
>
>> Auriez-vous une piste à me suggérer, SVP ?
>
> Voici quelques contrôles à effectuer:
>
> - Est-ce que le service "xinetd" est bien démarré ? ps
> ou /etc/init.d/xinetd status
>
> - Est-ce que le port 3690 est ouvert ? netstat -anp | grep LISTEN
>
> - Est-ce qu'il y aurait une configuration de firewall chargée ?
> iptables -L
>
> - Que donne "telnet nom-du-serveur 3690" en local et depuis une machine
> du réseau ?
>
> A+
Merci de vos réponses à tous les trois. Entretemps, mon svnserve s'est
décidé à retomber en marche, sans que je ne sache vraiment pourquoi. Je
vais donc suivre point par point à vos différentes pistes, des fois que
ça me permettrait d'en savoir un peu plus :
Suggestions de Yves :
1) Est-ce que le service "xinetd" est bien démarré ? ps
ou /etc/init.d/xinetd status
==> Cette version d'xinetd ne reconnaît pas la commande 'status', mais
ps me montre qu'xinetd est bien lancé :
ps -ef | grep xinetd
root 2819 1 0 21:47 ? 00:00:00 /usr/sbin/xinetd
-pidfile /var/run/xinetd.pid -stayalive -inetd_compat -inetd_ipv6
root 2976 2945 0 22:55 pts/0 00:00:00 grep xinetd
2) Est-ce que le port 3690 est ouvert ? netstat -anp | grep LISTEN
==> oui :
[...]
tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 2819/xinetd
[...]
3) Est-ce qu'il y aurait une configuration de firewall chargée ?
==> Non, c'est une machine à usage interne exclusivement :
iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
4) telnet nom-du-serveur 3690 est OK, aussi bien depuis le prompt de la
machine elle-même que depuis une autre machine.
Suggestions d'Olivier :
1) Sur une Debian, les logs de xinetd se retrouverons sur
/var/log/daemon.log : c'est bon à savoir, mais dans mon cas, je n'y
trouve aucune différence entre les fois où tout allait bien, la (courte)
période pendant laquelle svnserve et/ou xinetd se sont mis en grève, et
maintenant, où ça refonctionne.
2) Si le problème se situe au niveau de l'authentification de svnserve,
tu peux retrouver des logs dans /var/log/auth.log : non, ce n'était pas
un problème d'authentification, mais un problème de time-out. Le serveur
svnserve ne répondait pas dans un temps imparti, et le client finissait
par s'impatienter.
3) Après le redémarrage de xinetd, vérifie que le port 3690 est bien
ouvert: netstat -taupn|grep 3690.
==> cf. ci-dessus, réponse à Yves. Bizarrement, le redémarrage
d'xinetd n'avait pas suffi à corriger le pb, pas plus que le redémarrage
de la machine (que j'aurai aimé éviter, par principe). En revanche, bien
après le redémarrage, à un moment, j'ai refait un essai depuis le
client, et ô surprise, c'était retombé en marche... :-/
"En lançant la commande en temps que root, le paramètre "n" indique quel
est le nom du process qui écoute sur le port. Dans ton cas, cela doit
être xinetd."
==> oui, tout à fait :
netstat -taupn|grep 3690
tcp 0 0 0.0.0.0:3690 0.0.0.0:*
LISTEN 2819/xinetd
4) "strace" peut aider à trouver des intormations. Pour cela, tu peux
utiliser: strace -t -f -o /tmp/xinetd.log /etc/init.d/xinetd restart
ou moins verbeux : strace -t -f -o /tmp/xinetd.log -e open
/etc/init.d/xinetd restart
Tu fais alors un un "tail -f /tmp/xinetd.log"
et tu lances une connexion sur ton "svnserve"
==> Je l'ai fait, mais (honte sur moi), je n'ai rien compris (ou pas
grand chose) au résultat.
5) Dans mon cas, rien de tel, puisque c'est retombé en marche sans
action particulière de ma part...
6) Je ne pense que ce soit lié, mais je remarque ça :
root@debibox:~$ su svn
root@debibox:~$ echo $?
1
root@debibox:~$ id
uid=0(root) gid=0(root) groupes=0(root)
Donc je ne peux pas me connecter de façon interactive en tant que 'svn',
même en étant 'root', ce qui n'est pas étonnant, puisque :
grep svn /etc/passwd
svn:x:65533:65533::/nonexistent:/bin/false
Mais je n'ai rien modifié récemment de ce côté, et ça marchait jusqu'ici.
7) root@debibox:~$ netstat -taupn|grep 3690
tcp 0 0 0.0.0.0:3690 0.0.0.0:* LISTEN 3130/xinetd
root@debibox:~$ /etc/init.d/xinetd stop
Stopping internet superserver: xinetd.
root@debibox:~$ netstat -taupn|grep 3690 ==> rien
root@debibox:~$ su -c "/usr/bin/svnserve -i -r /srv/svn" svn
root@debibox:~$ netstat -taupn|grep 3690 ==> rien
Et après avoir lancé svnserve de la façon indiquée ci-dessus, le client
SVN échoue, avec un message différent : "Can't connect to host
'debibox': Aucune connexion n'a pu être établie car l'ordinateur cible
l'a expressément refusée." Comment se fait l'association entre
/usr/bin/svnserve et le port 3690 quand svnserve est lancé à la main,
hors xinetd ? Je ne connais rien d'autre, pour cela, que /etc/services,
qui contient bien les deux lignes suivantes :
svn 3690/tcp subversion # Subversion protocol
svn 3690/udp subversion
Mais alors, comment expliquer que je ne vois rien dans netstat -taupn,
ni dans ps -ef ?
ps -ef | grep -i svnserve
root 3186 2945 0 00:03 pts/0 00:00:00 grep -i svnserve
En revanche, si je relance xinetd, tout refonctionne : pas de message
d'erreur, et client SVN content ( donc moi aussi ).
Le mystère n'est donc pas élucidé, mais le problème est résolu, et j'ai
appris quelques trucs au passage. Merci à tous...
--
Marc
