Ok... Ok... Please stop!
The response from Sun-Managers to my NIS questions has been overwhelming,
and at the time of writing totals more than 40 replies! I've spent most of
the day just reading them.
Firstly I would like to thank everyone who sent suggestions.
My inital query concerned yp-master and yp-slave interactions, and I have
already summerised. But, at the risk of repeating myself, it appears that
I was taking the terms Master Server and Slave Server to literaly:
Master Server - machine where NIS database files are stored and
pushed from; otherwise just like a slave.
Slave Server - machine where NIS maps are stored, and used by *any*
other machine on the net for NIS services, EVEN the
NIS master machine; dependent on loads.
The main reason for this inital query, and, the reason why I was concerned
that `ypwhich` returned different answers on different machines, was that
when making a new group on the master, typing `groups` as a user in this
new group did not list it.
All the replies were along the same lines: "We agree with your understanding
of how NIS works so muck around with various NIS daemons and /etc files."
Here is more detail:
-------------------
a) Several people suggested I made sure that the client & slave /etc/group
files had a +: on the last line, so that the NIS group would be consulted
after the local one (a local group entry would override an NIS one!) - all
of ours did; no local entry.
b) Others thought that the master might not have an up-to-date record of its'
slave servers:
ypcat -k ypservers
should produce a list of NIS servers known to the master. I found duplicate
entries for each of our slaves; perhaps because there are two ethernet cards
in each. The gateway server names have '-gw' appended but the ypservers were
listed:
hostname1 hostname1
hostname2 hostname2 ...
so, just in case, I removed the duplicates by:
cd /var/yp/`domainname`
/usr/etc/yp/makedbm -u ypservers > ypservers
edit ypservers:
hostname1
hostname2 ...
/usr/etc/yp/makedbm ypservers ypservers
I don't think that this was the problem, but it might do some good.
c) A lot of you thought that running 'ypxfr' would help. This is run on the
slaves, and 'pulls' the current NIS maps from the server. This should happen
automatically when doing a 'make' on the master with 'pushed <map>' message.
The Admin. Manual suggests putting entries into the crontab to perform a
'ypxfr' on a regular basis, but to my mind this isn't needed. Any thoughts?
d) THE SOLUTION.
About a third of you seem to know about a wierd 'bug?' in the NIS. Apparenty,
when making the 'group' map, you must also make the 'netid' map. We usually
type 'make' on its own, which does a 'make all' and there is no problem.
Sometimes I do a 'make passwd' - again, no problem.
But, I typed 'make group' ...fatal mistake. You must also type 'make netid'.
I'm going to edit the Makefile so that this is done automatically when doing
a 'make group' on its own.
The reasoning is that, when logging in, the netid map is consulted,
NOT the group map. So, if I add 'newgroup' to the group file, type 'make
group' and log on as userA, typing groups might give "group1 group2", but
typing 'groups userid' would give "group1 group2 newgroup" - the same as
logging on as root and typing 'groups userid'.
As for the printer, its sorted it's self out as they often do, and may or may
not be connected.
Thanks, Dave.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:10 CDT