Je vous soumets un petit problème qui me laisse pantois depuis
quelque temps. Considérons une machine à 500 km de Paris qui
distribue un NIS (configuré correctement avec un ypserv.securenet
aux petits oignons) sur un réseau local et sur un réseau local
"distant" par une connexion ADSL. Cette machine est une Sun U60
bipro tournant sous une linuxerie Debian (testing) sans aucun
problème. Considérons maintenant une machine sur Paris faisant
office de NIS esclave pour un réseau local réttaché au premier
réseau local. Cette machine est une Sun 420R (bipro aussi avec la
même version du système d'exploitation).
Mon problème est très simple. Lorsque cette machine boote sans le
NIS, je me connecte dessus en tant que root et je peux lancer
/etc/init.d/nis start qui démarre les daemons ypserv et ypbind, le
NIS étant actif et fonctionnant sans problème. Si je mets dans
/etc/rc2.d (je démarre en init 2 par défaut), S99nis, seul ypserv
est lancé et le système me refuse même la connexion en tant que root
(je ne vois pas pourquoi d'ailleurs, root étant un utilisateur local
!). Première question, qu'elle est la différence entre S96nis et
/etc/init.d/nis start ? Pour moi, il s'agit de la même chose.
J'ai donc écrit un script permettant de relancer NIS si ypbind ne
tourne pas (c'est un pis aller, mais au point où j'en suis...).
#!/bin/bash
#===============================================================================
# Routine testant régulièrement l'état de la connexion NIS (ypbind)
# Copyright 07.2002 J. Bertrand
#
# Test de la présence du DAEMON ypbind (bug qui ne lance que ypserv au
# boot)
#===============================================================================
if [ $TEST_YPBIND -eq 0 ]; then
/etc/init.d/nis stop 2>&1 /dev/null
/etc/init.d/nis start 2>&1 /dev/null
fi
exit 0
Ce truc est lancé régulièrement par le cron et ne fonctionne que si
ypserv ne tourne pas. Typiquement, si S99nis est dans /etc/rc2.d, le
script ne fonctionne pas, alors que si le NIS n'est pas lancé au
boot, il permet de remettre les choses dans l'ordre ! Deuxième
question : pourquoi ? Je ne suis pas tout à fait débutant sur les
systèmes Unix, mais là, j'en perds mon latin.
Merci de votre attention,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Philippe Delsol
"JKB" a écrit dans le message de news:
Bonjour à tous,
Je vous soumets un petit problème qui me laisse pantois depuis quelque temps. Considérons une machine à 500 km de Paris qui distribue un NIS (configuré correctement avec un ypserv.securenet aux petits oignons) sur un réseau local et sur un réseau local "distant" par une connexion ADSL. Cette machine est une Sun U60 bipro tournant sous une linuxerie Debian (testing) sans aucun problème. Considérons maintenant une machine sur Paris faisant office de NIS esclave pour un réseau local réttaché au premier réseau local. Cette machine est une Sun 420R (bipro aussi avec la même version du système d'exploitation).
Mon problème est très simple. Lorsque cette machine boote sans le NIS, je me connecte dessus en tant que root et je peux lancer /etc/init.d/nis start qui démarre les daemons ypserv et ypbind, le NIS étant actif et fonctionnant sans problème. Si je mets dans /etc/rc2.d (je démarre en init 2 par défaut), S99nis, seul ypserv est lancé et le système me refuse même la connexion en tant que root (je ne vois pas pourquoi d'ailleurs, root étant un utilisateur local !). Première question, qu'elle est la différence entre S96nis et /etc/init.d/nis start ? Pour moi, il s'agit de la même chose.
J'ai donc écrit un script permettant de relancer NIS si ypbind ne tourne pas (c'est un pis aller, mais au point où j'en suis...).
#!/bin/bash
#====================================================================== ======= > # Routine testant régulièrement l'état de la connexion NIS (ypbind)
# Copyright 07.2002 J. Bertrand # # Test de la présence du DAEMON ypbind (bug qui ne lance que ypserv au # boot)
if [ $TEST_YPBIND -eq 0 ]; then /etc/init.d/nis stop 2>&1 /dev/null /etc/init.d/nis start 2>&1 /dev/null fi
exit 0
Ce truc est lancé régulièrement par le cron et ne fonctionne que si ypserv ne tourne pas. Typiquement, si S99nis est dans /etc/rc2.d, le script ne fonctionne pas, alors que si le NIS n'est pas lancé au boot, il permet de remettre les choses dans l'ordre ! Deuxième question : pourquoi ? Je ne suis pas tout à fait débutant sur les systèmes Unix, mais là, j'en perds mon latin.
Merci de votre attention,
Problème de "run level" ? J'aurais tendance à penser qu'il faut démarrer NIS au niveau 3 (/etc/rc3.d)
JKB
Philippe
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
"JKB" <bertrand@chezmoi.com> a écrit dans le message de news:
slrnbsu1no.32o.bertrand@zebigbos.makalis.fr...
Bonjour à tous,
Je vous soumets un petit problème qui me laisse pantois depuis
quelque temps. Considérons une machine à 500 km de Paris qui
distribue un NIS (configuré correctement avec un ypserv.securenet
aux petits oignons) sur un réseau local et sur un réseau local
"distant" par une connexion ADSL. Cette machine est une Sun U60
bipro tournant sous une linuxerie Debian (testing) sans aucun
problème. Considérons maintenant une machine sur Paris faisant
office de NIS esclave pour un réseau local réttaché au premier
réseau local. Cette machine est une Sun 420R (bipro aussi avec la
même version du système d'exploitation).
Mon problème est très simple. Lorsque cette machine boote sans le
NIS, je me connecte dessus en tant que root et je peux lancer
/etc/init.d/nis start qui démarre les daemons ypserv et ypbind, le
NIS étant actif et fonctionnant sans problème. Si je mets dans
/etc/rc2.d (je démarre en init 2 par défaut), S99nis, seul ypserv
est lancé et le système me refuse même la connexion en tant que root
(je ne vois pas pourquoi d'ailleurs, root étant un utilisateur local
!). Première question, qu'elle est la différence entre S96nis et
/etc/init.d/nis start ? Pour moi, il s'agit de la même chose.
J'ai donc écrit un script permettant de relancer NIS si ypbind ne
tourne pas (c'est un pis aller, mais au point où j'en suis...).
#!/bin/bash
#====================================================================== ======= > # Routine testant régulièrement l'état de la connexion NIS (ypbind)
# Copyright 07.2002 J. Bertrand
#
# Test de la présence du DAEMON ypbind (bug qui ne lance que ypserv au
# boot)
if [ $TEST_YPBIND -eq 0 ]; then
/etc/init.d/nis stop 2>&1 /dev/null
/etc/init.d/nis start 2>&1 /dev/null
fi
exit 0
Ce truc est lancé régulièrement par le cron et ne fonctionne que si
ypserv ne tourne pas. Typiquement, si S99nis est dans /etc/rc2.d, le
script ne fonctionne pas, alors que si le NIS n'est pas lancé au
boot, il permet de remettre les choses dans l'ordre ! Deuxième
question : pourquoi ? Je ne suis pas tout à fait débutant sur les
systèmes Unix, mais là, j'en perds mon latin.
Merci de votre attention,
Problème de "run level" ?
J'aurais tendance à penser qu'il faut démarrer NIS au niveau 3
(/etc/rc3.d)
JKB
Philippe
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Je vous soumets un petit problème qui me laisse pantois depuis quelque temps. Considérons une machine à 500 km de Paris qui distribue un NIS (configuré correctement avec un ypserv.securenet aux petits oignons) sur un réseau local et sur un réseau local "distant" par une connexion ADSL. Cette machine est une Sun U60 bipro tournant sous une linuxerie Debian (testing) sans aucun problème. Considérons maintenant une machine sur Paris faisant office de NIS esclave pour un réseau local réttaché au premier réseau local. Cette machine est une Sun 420R (bipro aussi avec la même version du système d'exploitation).
Mon problème est très simple. Lorsque cette machine boote sans le NIS, je me connecte dessus en tant que root et je peux lancer /etc/init.d/nis start qui démarre les daemons ypserv et ypbind, le NIS étant actif et fonctionnant sans problème. Si je mets dans /etc/rc2.d (je démarre en init 2 par défaut), S99nis, seul ypserv est lancé et le système me refuse même la connexion en tant que root (je ne vois pas pourquoi d'ailleurs, root étant un utilisateur local !). Première question, qu'elle est la différence entre S96nis et /etc/init.d/nis start ? Pour moi, il s'agit de la même chose.
J'ai donc écrit un script permettant de relancer NIS si ypbind ne tourne pas (c'est un pis aller, mais au point où j'en suis...).
#!/bin/bash
#====================================================================== ======= > # Routine testant régulièrement l'état de la connexion NIS (ypbind)
# Copyright 07.2002 J. Bertrand # # Test de la présence du DAEMON ypbind (bug qui ne lance que ypserv au # boot)
if [ $TEST_YPBIND -eq 0 ]; then /etc/init.d/nis stop 2>&1 /dev/null /etc/init.d/nis start 2>&1 /dev/null fi
exit 0
Ce truc est lancé régulièrement par le cron et ne fonctionne que si ypserv ne tourne pas. Typiquement, si S99nis est dans /etc/rc2.d, le script ne fonctionne pas, alors que si le NIS n'est pas lancé au boot, il permet de remettre les choses dans l'ordre ! Deuxième question : pourquoi ? Je ne suis pas tout à fait débutant sur les systèmes Unix, mais là, j'en perds mon latin.
Merci de votre attention,
Problème de "run level" ? J'aurais tendance à penser qu'il faut démarrer NIS au niveau 3 (/etc/rc3.d)
JKB
Philippe
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Arnaud Gomes-do-Vale
JKB writes:
Ce truc est lancé régulièrement par le cron et ne fonctionne que si ypserv ne tourne pas. Typiquement, si S99nis est dans /etc/rc2.d, le script ne fonctionne pas, alors que si le NIS n'est pas lancé au boot, il permet de remettre les choses dans l'ordre ! Deuxième question : pourquoi ?
Je serais bien incapable de te dire pourquoi root « n'existe pas » si NIS est lancé au démarrage. Par contre, je soupçonne que dans ce cas, cron n'exécute pas sa crontab tout simplement parce qu'il ne connaît pas l'utilisateur. Voilà, c'était la réponse à la question facile. :-)
-- Arnaud
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB <bertrand@chezmoi.com> writes:
Ce truc est lancé régulièrement par le cron et ne fonctionne que si
ypserv ne tourne pas. Typiquement, si S99nis est dans /etc/rc2.d, le
script ne fonctionne pas, alors que si le NIS n'est pas lancé au
boot, il permet de remettre les choses dans l'ordre ! Deuxième
question : pourquoi ?
Je serais bien incapable de te dire pourquoi root « n'existe pas » si
NIS est lancé au démarrage. Par contre, je soupçonne que dans ce cas,
cron n'exécute pas sa crontab tout simplement parce qu'il ne connaît
pas l'utilisateur. Voilà, c'était la réponse à la question facile. :-)
--
Arnaud
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Ce truc est lancé régulièrement par le cron et ne fonctionne que si ypserv ne tourne pas. Typiquement, si S99nis est dans /etc/rc2.d, le script ne fonctionne pas, alors que si le NIS n'est pas lancé au boot, il permet de remettre les choses dans l'ordre ! Deuxième question : pourquoi ?
Je serais bien incapable de te dire pourquoi root « n'existe pas » si NIS est lancé au démarrage. Par contre, je soupçonne que dans ce cas, cron n'exécute pas sa crontab tout simplement parce qu'il ne connaît pas l'utilisateur. Voilà, c'était la réponse à la question facile. :-)
-- Arnaud
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 2003-12-04, à propos de Re: NIS esclave et comportement bizarre, Philippe Delsol écrivait dans fr.comp.os.linux.moderated :
Problème de "run level" ? J'aurais tendance à penser qu'il faut démarrer NIS au niveau 3 (/etc/rc3.d)
Je ne vois pas ce que le runlevel vient faire là-dedans. Seuls les 0, 1 et 6 ont une signification particulière en SysV. J'ai tout à fait le droit de lancer le NIS en runlevel 2 (d'ailleurs, le NIS primaire est en runlevel 2 et fonctionne tout à fait normalement). De toute façon, en lançant le NIS à la main, cela fonctionne en restant en runlevel 2. Je pense que le problème est plus sournois que cela. Je penchais tout d'abord pour un problème d'établissement de la connexion entre les deux NIS (lancement de ppp et de tout le bazar pour attaquer le NIS esclave du NIS maître), avec à la clef un plantage lamentable de ypbind, mais cette hypothèse a été infirmée par mon script qui ne fait rien lorsque le NIS est lancé par init 2 alors que la connexion ppp fonctionne !
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 2003-12-04, à propos de
Re: NIS esclave et comportement bizarre,
Philippe Delsol écrivait dans fr.comp.os.linux.moderated :
Problème de "run level" ?
J'aurais tendance à penser qu'il faut démarrer NIS au niveau 3
(/etc/rc3.d)
Je ne vois pas ce que le runlevel vient faire là-dedans. Seuls les
0, 1 et 6 ont une signification particulière en SysV. J'ai tout à
fait le droit de lancer le NIS en runlevel 2 (d'ailleurs, le NIS
primaire est en runlevel 2 et fonctionne tout à fait normalement).
De toute façon, en lançant le NIS à la main, cela fonctionne en
restant en runlevel 2. Je pense que le problème est plus sournois
que cela. Je penchais tout d'abord pour un problème d'établissement
de la connexion entre les deux NIS (lancement de ppp et de tout le
bazar pour attaquer le NIS esclave du NIS maître), avec à la clef un
plantage lamentable de ypbind, mais cette hypothèse a été infirmée
par mon script qui ne fait rien lorsque le NIS est lancé par init 2
alors que la connexion ppp fonctionne !
Cordialement,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 2003-12-04, à propos de Re: NIS esclave et comportement bizarre, Philippe Delsol écrivait dans fr.comp.os.linux.moderated :
Problème de "run level" ? J'aurais tendance à penser qu'il faut démarrer NIS au niveau 3 (/etc/rc3.d)
Je ne vois pas ce que le runlevel vient faire là-dedans. Seuls les 0, 1 et 6 ont une signification particulière en SysV. J'ai tout à fait le droit de lancer le NIS en runlevel 2 (d'ailleurs, le NIS primaire est en runlevel 2 et fonctionne tout à fait normalement). De toute façon, en lançant le NIS à la main, cela fonctionne en restant en runlevel 2. Je pense que le problème est plus sournois que cela. Je penchais tout d'abord pour un problème d'établissement de la connexion entre les deux NIS (lancement de ppp et de tout le bazar pour attaquer le NIS esclave du NIS maître), avec à la clef un plantage lamentable de ypbind, mais cette hypothèse a été infirmée par mon script qui ne fait rien lorsque le NIS est lancé par init 2 alors que la connexion ppp fonctionne !
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
LeAg
Le 04 Dec 2003 11:04:43 GMT JKB a bafouillé :
Mon problème est très simple. Lorsque cette machine boote sans le NIS, je me connecte dessus en tant que root et je peux lancer /etc/init.d/nis start qui démarre les daemons ypserv et ypbind, le NIS étant actif et fonctionnant sans problème. Si je mets dans /etc/rc2.d (je démarre en init 2 par défaut), S99nis, seul ypserv est lancé et le système me refuse même la connexion en tant que root (je ne vois pas pourquoi d'ailleurs, root étant un utilisateur local !). Première question, qu'elle est la différence entre S96nis et /etc/init.d/nis start ? Pour moi, il s'agit de la même chose.
Aurais-tu modifié le fichier /etc/nsswitch.conf ?
Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ? - /etc/nsswitch.conf - /etc/yp.conf - /etc/ypserv.securenets - /etc/ypserv.conf
-- LeAg
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 04 Dec 2003 11:04:43 GMT
JKB <bertrand@chezmoi.com> a bafouillé :
Mon problème est très simple. Lorsque cette machine boote sans le
NIS, je me connecte dessus en tant que root et je peux lancer
/etc/init.d/nis start qui démarre les daemons ypserv et ypbind, le
NIS étant actif et fonctionnant sans problème. Si je mets dans
/etc/rc2.d (je démarre en init 2 par défaut), S99nis, seul ypserv
est lancé et le système me refuse même la connexion en tant que root
(je ne vois pas pourquoi d'ailleurs, root étant un utilisateur local
!). Première question, qu'elle est la différence entre S96nis et
/etc/init.d/nis start ? Pour moi, il s'agit de la même chose.
Aurais-tu modifié le fichier /etc/nsswitch.conf ?
Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ?
- /etc/nsswitch.conf
- /etc/yp.conf
- /etc/ypserv.securenets
- /etc/ypserv.conf
--
LeAg
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Mon problème est très simple. Lorsque cette machine boote sans le NIS, je me connecte dessus en tant que root et je peux lancer /etc/init.d/nis start qui démarre les daemons ypserv et ypbind, le NIS étant actif et fonctionnant sans problème. Si je mets dans /etc/rc2.d (je démarre en init 2 par défaut), S99nis, seul ypserv est lancé et le système me refuse même la connexion en tant que root (je ne vois pas pourquoi d'ailleurs, root étant un utilisateur local !). Première question, qu'elle est la différence entre S96nis et /etc/init.d/nis start ? Pour moi, il s'agit de la même chose.
Aurais-tu modifié le fichier /etc/nsswitch.conf ?
Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ? - /etc/nsswitch.conf - /etc/yp.conf - /etc/ypserv.securenets - /etc/ypserv.conf
-- LeAg
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 2003-12-09, à propos de Re: NIS esclave et comportement bizarre,
Bonjour,
LeAg écrivait dans fr.comp.os.linux.moderated :
Le 04 Dec 2003 11:04:43 GMT Aurais-tu modifié le fichier /etc/nsswitch.conf ?
Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ?
Mon problème n'est toujours pas résolu... Sauf par un cron, mais cela n'est pas intellectuellement satisfaisant ;-)
protocols: db files services: db files ethers: db files rpc: db files
netgroup: nis
- /etc/yp.conf
domain xxx.fr server (nom de la machine qui est présente dans le /etc/hosts)
- /etc/ypserv.securenets
# Always allow access for localhost 255.0.0.0 127.0.0.0
# This line gives access to everybody. PLEASE ADJUST! 255.255.255.0 192.168.0.0 host adresseIP du NIS primaire host adresseIP du NIS escalve
- /etc/ypserv.conf
* : shadow.byname : port * : passwd.adjunct.byname : port * : * : none
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 2003-12-09, à propos de
Re: NIS esclave et comportement bizarre,
Bonjour,
LeAg écrivait dans fr.comp.os.linux.moderated :
Le 04 Dec 2003 11:04:43 GMT
Aurais-tu modifié le fichier /etc/nsswitch.conf ?
Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ?
Mon problème n'est toujours pas résolu... Sauf par un cron, mais
cela n'est pas intellectuellement satisfaisant ;-)
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
- /etc/yp.conf
domain xxx.fr server (nom de la machine qui est présente dans le
/etc/hosts)
- /etc/ypserv.securenets
# Always allow access for localhost
255.0.0.0 127.0.0.0
# This line gives access to everybody. PLEASE ADJUST!
255.255.255.0 192.168.0.0
host adresseIP du NIS primaire
host adresseIP du NIS escalve
- /etc/ypserv.conf
* : shadow.byname : port
* : passwd.adjunct.byname : port
* : * : none
Cordialement,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
protocols: db files services: db files ethers: db files rpc: db files
netgroup: nis
- /etc/yp.conf
domain xxx.fr server (nom de la machine qui est présente dans le /etc/hosts)
- /etc/ypserv.securenets
# Always allow access for localhost 255.0.0.0 127.0.0.0
# This line gives access to everybody. PLEASE ADJUST! 255.255.255.0 192.168.0.0 host adresseIP du NIS primaire host adresseIP du NIS escalve
- /etc/ypserv.conf
* : shadow.byname : port * : passwd.adjunct.byname : port * : * : none
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
LeAg
Le 09 Dec 2003 11:38:12 GMT JKB a bafouillé :
> Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ?
Le système va d'abord "interroger" les fichiers /etc/passwd, /etc/group et /etc/shadow avant de consulter NIS.
-- Au paradis on est assis à la droite de Dieu. C'est normal, c'est la place du mort. -- Desproges, Pierre
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 09 Dec 2003 11:38:12 GMT
JKB <bertrand@chezmoi.com> a bafouillé :
> Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ?
Le système va d'abord "interroger" les fichiers /etc/passwd, /etc/group et /etc/shadow avant de consulter NIS.
--
Au paradis on est assis à la droite de Dieu. C'est normal, c'est la place du mort.
-- Desproges, Pierre
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le système va d'abord "interroger" les fichiers /etc/passwd, /etc/group et /etc/shadow avant de consulter NIS.
-- Au paradis on est assis à la droite de Dieu. C'est normal, c'est la place du mort. -- Desproges, Pierre
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 2003-12-11, à propos de Re: NIS esclave et comportement bizarre, LeAg écrivait dans fr.comp.os.linux.moderated :
Le 09 Dec 2003 11:38:12 GMT JKB a bafouillé :
> Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ?
Pour "passwd", "group" & "shadow', je mettrai en premier "files"
Le fait d'avoir nis avant files est délibéré. Par contre, si le problème vient bien de là, il y a un gros dysfonctionnement dans le nsswitch qui est censé passer à files s'il ne trouve pas nis. Ce qui m'ennuie dans le fait de mettre files avant nis, c'est que je préfèrerais que les comptes NIS soient prioritaires sur les comptes locaux. En tout état de cause, je teste. Merci.
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 2003-12-11, à propos de
Re: NIS esclave et comportement bizarre,
LeAg écrivait dans fr.comp.os.linux.moderated :
Le 09 Dec 2003 11:38:12 GMT
JKB <bertrand@chezmoi.com> a bafouillé :
> Si ton problème n'est pas résolu, peux-tu joindre les fichiers suivant dans ton futur message ?
Pour "passwd", "group" & "shadow', je mettrai en premier "files"
Le fait d'avoir nis avant files est délibéré. Par contre, si le
problème vient bien de là, il y a un gros dysfonctionnement dans le
nsswitch qui est censé passer à files s'il ne trouve pas nis. Ce qui
m'ennuie dans le fait de mettre files avant nis, c'est que je
préfèrerais que les comptes NIS soient prioritaires sur les comptes
locaux. En tout état de cause, je teste. Merci.
Cordialement,
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Pour "passwd", "group" & "shadow', je mettrai en premier "files"
Le fait d'avoir nis avant files est délibéré. Par contre, si le problème vient bien de là, il y a un gros dysfonctionnement dans le nsswitch qui est censé passer à files s'il ne trouve pas nis. Ce qui m'ennuie dans le fait de mettre files avant nis, c'est que je préfèrerais que les comptes NIS soient prioritaires sur les comptes locaux. En tout état de cause, je teste. Merci.
Cordialement,
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
LeAg
Le 11 Dec 2003 11:14:52 GMT JKB a bafouillé :
Le fait d'avoir nis avant files est délibéré. Par contre, si le problème vient bien de là, il y a un gros dysfonctionnement dans le nsswitch qui est censé passer à files s'il ne trouve pas nis. Ce qui m'ennuie dans le fait de mettre files avant nis, c'est que je préfèrerais que les comptes NIS soient prioritaires sur les comptes locaux. En tout état de cause, je teste. Merci.
Pour mon information, qu'est ce qui te fait préférer les comptes NIS aux comptes locaux ?
Vu dans "/usr/share/doc/nis/nis.debian.howto.gz". Une piste pour restreindre les comptes utilisateurs.
3.7 Setup the server.
If you want to restrict access to your NIS server, you'll have to setup the NIS server as a client as well by running ypbind and adding the plus-entries to /etc/passwd _halfway_ the password file. The library functions will ignore all normal entries after the first NIS entry, and will get the rest of the info through NIS. This way the NIS access rules are maintained. example:
-- La foi, semelle inusable pour qui n'avance pas. -- Michaux, Henri
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 11 Dec 2003 11:14:52 GMT
JKB <bertrand@chezmoi.com> a bafouillé :
Le fait d'avoir nis avant files est délibéré. Par contre, si le
problème vient bien de là, il y a un gros dysfonctionnement dans le
nsswitch qui est censé passer à files s'il ne trouve pas nis.
Ce qui m'ennuie dans le fait de mettre files avant nis, c'est que je
préfèrerais que les comptes NIS soient prioritaires sur les comptes
locaux. En tout état de cause, je teste. Merci.
Pour mon information, qu'est ce qui te fait préférer les comptes NIS aux comptes locaux ?
Vu dans "/usr/share/doc/nis/nis.debian.howto.gz". Une piste pour restreindre les comptes utilisateurs.
3.7 Setup the server.
If you want to restrict access to your NIS server, you'll have to setup
the NIS server as a client as well by running ypbind and adding the
plus-entries to /etc/passwd _halfway_ the password file. The library
functions will ignore all normal entries after the first NIS entry, and
will get the rest of the info through NIS. This way the NIS access rules
are maintained. example:
--
La foi, semelle inusable pour qui n'avance pas.
-- Michaux, Henri
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le fait d'avoir nis avant files est délibéré. Par contre, si le problème vient bien de là, il y a un gros dysfonctionnement dans le nsswitch qui est censé passer à files s'il ne trouve pas nis. Ce qui m'ennuie dans le fait de mettre files avant nis, c'est que je préfèrerais que les comptes NIS soient prioritaires sur les comptes locaux. En tout état de cause, je teste. Merci.
Pour mon information, qu'est ce qui te fait préférer les comptes NIS aux comptes locaux ?
Vu dans "/usr/share/doc/nis/nis.debian.howto.gz". Une piste pour restreindre les comptes utilisateurs.
3.7 Setup the server.
If you want to restrict access to your NIS server, you'll have to setup the NIS server as a client as well by running ypbind and adding the plus-entries to /etc/passwd _halfway_ the password file. The library functions will ignore all normal entries after the first NIS entry, and will get the rest of the info through NIS. This way the NIS access rules are maintained. example:
-- La foi, semelle inusable pour qui n'avance pas. -- Michaux, Henri
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
JKB
Le 2003-12-12, à propos de Re: NIS esclave et comportement bizarre, LeAg écrivait dans fr.comp.os.linux.moderated :
Le 11 Dec 2003 11:14:52 GMT JKB a bafouillé :
Pour mon information, qu'est ce qui te fait préférer les comptes NIS aux comptes locaux ?
Mes utilisateurs utilisent plusieurs machines au choix dans un laboratoire. Et le NIS permet d'avoir un seul endroit avec les données des utilisateurs à sauvegarder.
Vu dans "/usr/share/doc/nis/nis.debian.howto.gz". Une piste pour restreindre les comptes utilisateurs.
3.7 Setup the server.
If you want to restrict access to your NIS server, you'll have to setup the NIS server as a client as well by running ypbind and adding the plus-entries to /etc/passwd _halfway_ the password file. The library functions will ignore all normal entries after the first NIS entry, and will get the rest of the info through NIS. This way the NIS access rules are maintained. example:
Je connais (c'est le b-a-ba du NIS) ;-)
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
Le 2003-12-12, à propos de
Re: NIS esclave et comportement bizarre,
LeAg écrivait dans fr.comp.os.linux.moderated :
Le 11 Dec 2003 11:14:52 GMT
JKB <bertrand@chezmoi.com> a bafouillé :
Pour mon information, qu'est ce qui te fait préférer les comptes NIS
aux comptes locaux ?
Mes utilisateurs utilisent plusieurs machines au choix dans un
laboratoire. Et le NIS permet d'avoir un seul endroit avec les
données des utilisateurs à sauvegarder.
Vu dans "/usr/share/doc/nis/nis.debian.howto.gz". Une piste pour restreindre les comptes utilisateurs.
3.7 Setup the server.
If you want to restrict access to your NIS server, you'll have to setup
the NIS server as a client as well by running ypbind and adding the
plus-entries to /etc/passwd _halfway_ the password file. The library
functions will ignore all normal entries after the first NIS entry, and
will get the rest of the info through NIS. This way the NIS access rules
are maintained. example:
Je connais (c'est le b-a-ba du NIS) ;-)
JKB
--
Pour contacter l'équipe de modération : moderateurs-fcolm@efrei.fr
ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans
la liste de distribution des modérateurs.
Le 2003-12-12, à propos de Re: NIS esclave et comportement bizarre, LeAg écrivait dans fr.comp.os.linux.moderated :
Le 11 Dec 2003 11:14:52 GMT JKB a bafouillé :
Pour mon information, qu'est ce qui te fait préférer les comptes NIS aux comptes locaux ?
Mes utilisateurs utilisent plusieurs machines au choix dans un laboratoire. Et le NIS permet d'avoir un seul endroit avec les données des utilisateurs à sauvegarder.
Vu dans "/usr/share/doc/nis/nis.debian.howto.gz". Une piste pour restreindre les comptes utilisateurs.
3.7 Setup the server.
If you want to restrict access to your NIS server, you'll have to setup the NIS server as a client as well by running ypbind and adding the plus-entries to /etc/passwd _halfway_ the password file. The library functions will ignore all normal entries after the first NIS entry, and will get the rest of the info through NIS. This way the NIS access rules are maintained. example:
Je connais (c'est le b-a-ba du NIS) ;-)
JKB
-- Pour contacter l'équipe de modération : ATTENTION: Postez DIRECTEMENT vos articles dans le groupe, PAS dans la liste de distribution des modérateurs.
