Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

probl

5 réponses
Avatar
Eric Belhomme
Bonjour,

Soit une machine fraichement installée en Debian Squeeze (amd64) :
- la machine est en DHCP
- l'authentification se fait via un annnuaire LDAP distant, via les
paquets libnss-ldapd, libpam-ldapd, nslcd, et nscd
- des montages NFS sont montés par autofs5, via une configuration LDAP

La configuration est fonctionnelle, à ceci près que lors du boot de la
machine, nslcd ne démarre pas en se plaignant de ne pouvoir joindre le
serveur LDAP, et autofs ne monte pas mes auto-montages.

Une fois ces deux daemons redémarrés manuellement, le tout fonctionne.

J'en conclus que le réseau est trop long à démarrer ou du moins que
insserv n'attend pas que mes interfaces soient effectivement up avant de
passer au démarrage de ces deux démons... ce qui est ennuyeux !

J'avoue que le fonctionnement de sysv-rc et insserv est assez mystérieux
pour moi, malgré la lecture de http://wiki.debian.org/LSBInitScripts/
DependencyBasedBoot

Je prends donc toute explication claire sur la façon *propre* de
customiser l'ordre de démarrage des daemons avec ce nouveau système...

Merci !

--
Rico

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/ig1kb1$obu$1@dough.gmane.org

5 réponses

Avatar
Sylvain L. Sauvage
Le mercredi 5 janvier 2011 à 12:23:13, Eric Belhomme a écrit :
Bonjour,



’jour,

Soit une machine fraichement installée en Debian Squeeze
(amd64) :
- la machine est en DHCP
- l'authentification se fait via un annnuaire LDAP distant,
via les paquets libnss-ldapd, libpam-ldapd, nslcd, et nscd
- des montages NFS sont montés par autofs5, via une
configuration LDAP

La configuration est fonctionnelle, à ceci près que lors du
boot de la machine, nslcd ne démarre pas en se plaignant de
ne pouvoir joindre le serveur LDAP, et autofs ne monte pas
mes auto-montages.

Une fois ces deux daemons redémarrés manuellement, le tout
fonctionne.

J'en conclus que le réseau est trop long à démarrer ou du
moins que insserv n'attend pas que mes interfaces soient
effectivement up avant de passer au démarrage de ces deux
démons... ce qui est ennuyeux !

J'avoue que le fonctionnement de sysv-rc et insserv est assez
mystérieux pour moi, malgré la lecture de
http://wiki.debian.org/LSBInitScripts/ DependencyBasedBoot



http://wiki.debian.org/LSBInitScripts/DependencyBasedBoot ne
contient effectivement pas grand-chose d’utile pour la
modification. En revanche http://wiki.debian.org/LSBInitScripts
est assez clair, non ?

Je prends donc toute explication claire sur la façon *propre*
de customiser l'ordre de démarrage des daemons avec ce
nouveau système...



La façon propre me semble être de modifier les entêtes LSB .
Puis de lancer update-rc.d sur le script pour recalculer les
dépendances.


Pour ton problème, et comme proposé sur le wiki, tu peux dà ©jà
vérifier le graphe de dépendances :

aptitude install insserv graphviz
/usr/share/insserv/check-initd-order -g > boot.dot
dotty boot.dot

Les nœuds ronds, les flèches vertes et les flèches jaunes
représentent des dépendances pour des services qui ne sont pas
installés sur ta machine. Les services précédés d†™un $ sont
virtuels : il n’y a pas de script correspondant ; ils sont
explicités dans /etc/insserv.conf et dans la page de man de
insserv.

Tu dois voir que tout est lancé dans le bonne ordre (nslcd
après $network). Et pour nslcd et autofs, les dépendances m†™ont
l’air correctes.

Et donc, reste ta seconde idée : « le réseau est trop long à
démarrer »…
Sauf que, si je ne me trompe pas, /etc/init.d/neworking lance
et attend ifup -a qui lance et attend dhclient qui ne part en
tâche de fond que lorsque l’interface est configurée. Don c, à
moins que ton interface soit configurée différemment, le rés eau
doit être fonctionnel quand nslcd est lancé.

Si je n’ai pas été clair ou convaincant, tu peux và ©rifier la
séquence de boot à partir des n° de liens S* dans /etc/rc?.d /
(en fait, tu dois même avoir networking en rcS et nslcd en rc2,
non ? donc networking forcément avant nslcd). Et tu peux aussi
ajouter un test au début de /etc/init.d/nslcd pour vérifier que
l’interface est bien configurée (un simple envoi de ifconfig - a
vers un fichier te permettra de le vérifier a posteriori).

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Pascal Hambourg
Sylvain L. Sauvage a écrit :

Et donc, reste ta seconde idée : le réseau est trop long à
démarrer
Sauf que, si je ne me trompe pas, /etc/init.d/neworking lance
et attend ifup -a qui lance et attend dhclient qui ne part en
tâche de fond que lorsque l'interface est configurée.



Quid quand l'interface est démarrée avec allow-hotplug au lieu d'auto,
ce qui me semble être la configuration par défaut après l'installation ?

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Sylvain L. Sauvage
Le dimanche 9 janvier 2011 à 14:22:33, Pascal Hambourg a écrit :
Sylvain L. Sauvage a écrit :
> Et donc, reste ta seconde idée : le réseau est trop long
> à démarrer
>
> Sauf que, si je ne me trompe pas, /etc/init.d/neworking
> lance et attend ifup -a qui lance et attend dhclient qui ne
> part en tâche de fond que lorsque l'interface est
> configurée.

Quid quand l'interface est démarrée avec allow-hotplug au
lieu d'auto,



C’est udev qui s’en occupe. J’ai cherché un peu pour voir
quand et comment ça se passe…

Or donc, udev lance ifup --allow=hotplug dès que l’interfa ce
est « renommée » (devient « eth0 »). Et, d†™après
/usr/share/doc/udev/README.Debian.gz, ce /renommage/ a lieu
après que la racine a été montée (ou même dans le initrd si /
est en nfs). Ça n’est pas très précis mais je suppos e que ça se
fait dès que udev est lancé ou dès que le module de la carte
réseau est chargé, au dernier arrivé. Donc très tô t. Plus tôt
que auto.

ce qui me semble être la configuration par défaut après
l'installation ?



Oui, c’est la config habituelle.
Et pour revenir au problème initial, si l’interface n†™est pas
configurée assez tôt avec allow-hotplug (j’en doute quand même),
essayer avec auto…

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Eric Belhomme
Le Sat, 08 Jan 2011 16:01:48 +0100, Sylvain L. Sauvage a écrit :

/usr/share/insserv/check-initd-order -g > boot.dot dotty boot.dot

Tu dois voir que tout est lancé dans le bonne ordre (nslcd
après $network). Et pour nslcd et autofs, les dépendances m’ont l’air
correctes.



ça, j'avais fait, et les dépendances sont correctement séquencées.

Et donc, reste ta seconde idée : « le réseau est trop long à
démarrer »…
Sauf que, si je ne me trompe pas, /etc/init.d/neworking lance
et attend ifup -a qui lance et attend dhclient qui ne part en tâche de
fond que lorsque l’interface est configurée. Donc, à moins que ton
interface soit configurée différemment, le réseau doit être fonctionnel
quand nslcd est lancé.




Là c'est ma faute, mea culpa. mes explications quant àaux détails de ma
config sont erronées dans mon 1er post :
- ma config IP est en adressage fixe, et non pas en DHCP
- surtout (et c'est AHMA la cause du problème), j'utilise deux interfaces
aggrégées en 802.3ad !

En investigant, je me suis rendu compte que ifupdown n'attend pas que le
bonding soit prêt pour considérer l'interface "up". Du coup j'ai ouvert
le ticket #609242 sur le paquet ifenslave-2.6 (j'ai hésité avec ifupdown,
mais ifenslave-2.6 m'a semblé plus adapté)

En attendant, la seule bidouille très crade que j'ai trouvé pour palier
au problème consiste à rajouter un "post-up" afin de faire perdre du
temps à ifupdown, le temps que mes interfaces négocient l'agrégation avec
le switch...

En tous cas merci pour le lien sur sysv-rc, il est bien plus utile que
celui que j'avais référencé !


--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/igemm3$p94$
Avatar
Pascal Hambourg
Eric Belhomme a écrit :

- surtout (et c'est AHMA la cause du problème), j'utilise deux interfaces
aggrégées en 802.3ad !

En investigant, je me suis rendu compte que ifupdown n'attend pas que le
bonding soit prêt pour considérer l'interface "up". Du coup j'ai ouvert
le ticket #609242 sur le paquet ifenslave-2.6 (j'ai hésité avec ifupdown,
mais ifenslave-2.6 m'a semblé plus adapté)



Ce problème n'est pas spécifique au bonding puisqu'il affecte également
d'autre types d'interface réseau. Par exemple :
- PPP : pppd passe en tâche de fond immédiatement sans attendre que la
connexion soit établie. Quand je redémarre ma passerelle ADSL sous lenny
(avec le système de démarrage traditionnel non basé sur les
dépendances), il arrive fréquemment que BIND9 démarre avant que
l'établissement de la connexion PPP soit achevé.
- bridge : le délai d'ouverture (forward delay) après l'activation, qui
est pris en compte avec un sleep dans /etc/network/if-pre-up.d/bridge.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/