Hello


I have a problem with NIS server
RedHat Enterprise 4. AS
ypserv (ypserv) 2.13

After successful startup it works for a few minutes and then stops answering
for clients.

I couldn't see anything suspicious in /var/log/messages - only something
like that:

======
Jan 23 14:02:21 dragon ypserv[7173]: Support for SLP (line 20) is not
compiled in.
Jan 23 14:02:21 dragon ypserv[7173]: Support for SLP (line 22) is not
compiled in.
Jan 23 14:02:21 dragon ypserv: ypserv startup succeeded
Jan 23 14:02:58 dragon ypserv[7173]: children is below 0 (-1)!
======

so I decided to start it up in debug mode (-d) and redirect stderr and out
to a log file:
ypserv -d > /root/ypservd.log 2>&1 &
....and miracle ! the server is working good. The problem as above is not
existing.

Anyhow in my log file (/root/ypservd.log) I could see some errors. I'm not
sure if they are important...

Examples:
=======
ypproc_domain("alatek.krakow.pl") [From: 10.0.2.122:937]
connect from 10.0.2.122
-> Ok.
ypproc_all_2_svc(): [From: 10.0.2.122:938]
domain = "alatek.krakow.pl"
map = "passwd"
ypdb_open("alatek.krakow.pl", "passwd")
gdbm_open: GDBM Error Code #3

=======
connect from 10.0.2.40
ypdb_open("alatek.krakow.pl", "passwd.byname")
Found: alatek.krakow.pl/passwd.byname (3)
ypdb_close() called
-> Error #-3

What else I can do to diagnose the problem?

Any utilities to query the ypserv manually? I used the yptest but it ends up
with message 'Can't communicate with ypbind' after the ypserv stops working.
Just after ypserv startup the yptest works fine.

What about the version I use? Sould I reinstall the ypserv ?

For now my workaround is:.

ypserv -d > /dev/null 2>&1 &

but I'm looking for a better solution ;-).


thanks for any suggestions
krzychosz

"krzychosz" <krzychosz@interia.pl> wrote in message
news:dra8g1$7d1$1@news.agh.edu.pl...
> Hello
>
>
> I have a problem with NIS server
> RedHat Enterprise 4. AS
> ypserv (ypserv) 2.13
>
> After successful startup it works for a few minutes and then stops
> answering for clients.
>
> I couldn't see anything suspicious in /var/log/messages - only something
> like that:
>
> ======
> Jan 23 14:02:21 dragon ypserv[7173]: Support for SLP (line 20) is not
> compiled in.
> Jan 23 14:02:21 dragon ypserv[7173]: Support for SLP (line 22) is not
> compiled in.
> Jan 23 14:02:21 dragon ypserv: ypserv startup succeeded
> Jan 23 14:02:58 dragon ypserv[7173]: children is below 0 (-1)!
> ======
>
> so I decided to start it up in debug mode (-d) and redirect stderr and out
> to a log file:
> ypserv -d > /root/ypservd.log 2>&1 &
> ...and miracle ! the server is working good. The problem as above is not
> existing.
>
> Anyhow in my log file (/root/ypservd.log) I could see some errors. I'm not
> sure if they are important...
>
> Examples:
> =======
> ypproc_domain("alatek.krakow.pl") [From: 10.0.2.122:937]
> connect from 10.0.2.122
> -> Ok.
> ypproc_all_2_svc(): [From: 10.0.2.122:938]
> domain = "alatek.krakow.pl"
> map = "passwd"
> ypdb_open("alatek.krakow.pl", "passwd")
> gdbm_open: GDBM Error Code #3
>
> =======
> connect from 10.0.2.40
> ypdb_open("alatek.krakow.pl", "passwd.byname")
> Found: alatek.krakow.pl/passwd.byname (3)
> ypdb_close() called
> -> Error #-3
>
> What else I can do to diagnose the problem?

Well, gee. Maybe you have a line mentionioning "aletek.krakow.pl" in your
/etc/passwd file? It's often easy to completely screw up an /etc/passwd or
/etc/shadow file by hand-editing, which is why Linux includes the "vipw"
command. That does sanity checking after you edit it.

I've seen similarly bad behavior when someone else accidentally left a blank
line in /etc/passwd, in NIS on Tru64 being edited by hand. NIS is often
short on sanity checking of its configuration files: it really expects you
to already have perfectly formatted configuration files.

"Nico Kadel-Garcia" <nkadel@comcast.net> wrote in message
news:rfqdnUuMRM4RW0XenZ2dnUVZ_vmdnZ2d@comcast.com. ..
>
>
> Well, gee. Maybe you have a line mentionioning "aletek.krakow.pl" in your
> /etc/passwd file? It's often easy to completely screw up an /etc/passwd or
> /etc/shadow file by hand-editing, which is why Linux includes the "vipw"
> command. That does sanity checking after you edit it.
>
> I've seen similarly bad behavior when someone else accidentally left a
> blank line in /etc/passwd, in NIS on Tru64 being edited by hand. NIS is
> often short on sanity checking of its configuration files: it really
> expects you to already have perfectly formatted configuration files.

Hi

I don't have any strange entries in /etc/passwd nor in shadow.
However I have made some manual editing of passwd, shadow and group. So as
you recommended I tried also the vipw - but I'm not sure if it makes any
sanity checking unless it does it silently. Anyhow it does not help to solve
my problem.
Next I removed all manually typed entries from passwd, shadow and group and
used a RedHat tool to add some users (system-config-users). I suppose that
this tool writes these files well formatted. Unfortunatelly the problem
still exists.
After each change I run make in /var/yp. In order to narrow the problem I
have also modified the Makefile so that only as few as possible databases
are exported:

all: passwd group hosts rpc services protocols \
# netid mail \
# netgrp shadow publickey networks ethers bootparams printcap \
# amd.home auto.master auto.home auto.local passwd.adjunct \
# timezone locale netmasks

Any other ideas ???

krzychosz

"krzychosz" <krzychosz@interia.pl> wrote in message
news:drcma7$5ep$1@news.agh.edu.pl...
>
>
>
> "Nico Kadel-Garcia" <nkadel@comcast.net> wrote in message
> news:rfqdnUuMRM4RW0XenZ2dnUVZ_vmdnZ2d@comcast.com. ..
>>
>>
>> Well, gee. Maybe you have a line mentionioning "aletek.krakow.pl" in your
>> /etc/passwd file? It's often easy to completely screw up an /etc/passwd
>> or /etc/shadow file by hand-editing, which is why Linux includes the
>> "vipw" command. That does sanity checking after you edit it.
>>
>> I've seen similarly bad behavior when someone else accidentally left a
>> blank line in /etc/passwd, in NIS on Tru64 being edited by hand. NIS is
>> often short on sanity checking of its configuration files: it really
>> expects you to already have perfectly formatted configuration files.
>
> Hi
>
> I don't have any strange entries in /etc/passwd nor in shadow.
> However I have made some manual editing of passwd, shadow and group. So as
> you recommended I tried also the vipw - but I'm not sure if it makes any
> sanity checking unless it does it silently. Anyhow it does not help to
> solve my problem.
> Next I removed all manually typed entries from passwd, shadow and group
> and used a RedHat tool to add some users (system-config-users). I suppose
> that this tool writes these files well formatted. Unfortunatelly the
> problem still exists.

It does, but it and vipw may not help you with old bad entries.

> After each change I run make in /var/yp. In order to narrow the problem I
> have also modified the Makefile so that only as few as possible databases
> are exported:
>
> all: passwd group hosts rpc services protocols \
> # netid mail \
> # netgrp shadow publickey networks ethers bootparams printcap \
> # amd.home auto.master auto.home auto.local passwd.adjunct \
> # timezone locale netmasks

I'm really unsure. I'd have to look at your /etc/passwd and /etc/shadow's to
search for the culprit. But I'd also be prepared to "touch /etc/passwd
/etc/shadow" to make

Hmmm. You know..... for sanity checking, there are also some LDAP creation
tools in /usr/share/openldap/migration or something like that, which will
parse your local /etc/passwd and /etc/shadow to create an LDAP setup. I've
actually used that to detect local lunacies.