Hi Sun-Managers,
sorry for the late summary, but here is the solution:
cd /var/yp; make
instead of
cd /var/yp; make groups
There is one internal NIS-table called 'netid' which has to be
updated along with tables like 'passwd' or 'group', otherwise it
will contain old information and provoke errors as described below.
One second solution was to check wether any slave server was
inconsistent with the master server, which was not the problem
at our site
Many thanks to the following people for their helpful answers:
Nate-Itkin@ptdcs2.intel.com
Ray.Brownrigg@isor.vuw.ac.nz
reedwv@expu79.stp.xfi.bp.com
mueller@darmstadt.gmd.de
dal@gcm.com
D.Mitchell@dcs.shef.ac.uk
rruiz@Census.GOV
etnibsd!vsh@uunet.uu.net
David.Deaves@cbr.atr.com.au
mike@trdlnk.com
strombrg@hydra.acs.uci.edu
ssd@nevets.oau.org
The original request was
Hi folks,
I have the following strange problem under SunOS 4.1.3a (unpatched) on an IPX
running NIS :
A user X's main group is A but he is also in group B. A couple of months ago
he was also in C but in the meantime this group has been removed.
Now, under certain circumstances, running 'groups' or 'id' returns the groups
A and B (case 1)
and sometimes
A, B and C (case 2)
Case 2 corresponds to the situation we had before the removal of group C.
Of course it is wrong now.
Question :
- why and how does the system remember this obsolete information ???
- is this a bug or a configuration problem ?
- is it a known bug ?
Important :
- the NIS groups and passwd files are in a seperate directory (/var/etc)
rather than in /etc. The /etc groups and passwd have the + pointer to
the NIS set.
- I have checked my group and passwd files a 100 times. THEY ARE CORRECT.
Hints :
- a trace of the 'groups' and 'id' tools shows that the tools run correctly,
their 'getgroups' system call returns wrong data.
- the machine has been rebooted several times since I removed group C.
An eventual data caching by certain processes should not be at the
origin of my problem.
- I have no general rule to say when case 1 or case 2 happens. But case 1
can be reproduced in a shell derived from
init - rc.local - xdm - .xsession - xterm - shell
and case 2 happens in a
init - rc - inetd - tcpd - in.telnetd - shell.
- the bug does not appear for all users. Most users always have the
right gids.
- the reverse problem also exists : once added in some secondary groups,
certain users are not always in those groups. Again the system sometimes
deals with obsolete configurations.
- assigning the concerned users a new uid solves the problem for that user
but the old uid remains contaminated.
Any help is highly welcome and I'll post a SUMMARY if the problem has a
solution.
Emile
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:10:18 CDT