ORIGINAL POSTING :
>I have recently reorganized my NIS system. The NIS passwd file
>is now _NOT_ /etc/passwd on the master server.
>
>After setting this up and getting yppasswdd working, a question
>crossed my mind...
>
> How does one edit the NIS passwd file safely while
> yppasswdd is running?
>
>I had never thought about this before, since I assumed the using
>the standard password file locking mechanism (vipw, /etc/ptmp)
>would keep me and yppasswdd from tangling.
>
>Does yppasswdd employ any mechanism for mutex on the password file?
>How can I cooperate with yppasswdd so we don't do something we will
>both regret?
>
>Thanks for any info, I will post a summary.
SUMMARY :
The consensus is that...
Some locking mechanism is necessary to avoid contention on the
ASCII version of the passwd file (ala vipw).
The distributed (4.1, 4.1.1, 4.1.2) version of rpc.yppasswdd
uses a different lock file than vipw. The latter uses /etc/ptmp
of course, while the distributed rpc.yppasswd uses /etc/passwd.ptmp.
This means that even if you are using /etc/passwd on the master
server as your NIS password file you are not safe.
A few persons offered scripts and modified versions of vipw to
fix the problem, but I believe that the correct solution is to
install the rpc.yppasswdd available in Sun patch #100201-04. This
version of rpc.yppasswdd uses /etc/ptmp as the lockfile. This patch
is available on ftp.uu.net.
This does not automatically solve the problem if you are using an
alternate source file, since vipw will automatically read in and
later update /etc/passwd. My solution will be to; invoke vipw which
will read in the master server's passwd file, empty the edit buffer,
read in the NIS password file, make changes, write the changes back
to the NIS password file, then quit without updating /etc/passwd.
Still not quite clean, but at least it is safe if done properly.
Charles Seeger pointed out that an additional problem exists with
building the dbm maps. There is nothing to prevent two NIS makes
to attempt building the dbm maps simultaneously. He suggests not
allowing rpc.yppasswdd to do makes, nor sysadmins, but rather relying
on a cron entry to rebuild the maps on a regular basis. I think that
maybe this problem could be diminished by inserting a lockfile test/set
in the NIS makefile.
THANKS TO :
Mike Raffety <miker@sbcoc.com>
seeger@thedon.cis.ufl.edu (F. L. Charles Seeger III)
Ace Stewart <jstewart@mailbox.syr.edu>
dinah@rockytop.tivoli.com (Dinah McNutt {sysadmizon})
don@mars.dgrc.doc.ca (Donald McLachlan)
Travis Priest <travis@fmd00.larc.nasa.gov>
lees@cps.msu.edu (John Lees)
cfoley@arsenic.cray.com (Chuck Foley)
Larry Chin <larry@cch.com>
Pravir K Chawdhry (EDC Data Exch) <P.K.Chawdhry@newcastle.ac.uk>
Casper <casper@fwi.uva.nl>
PATCHES :
100201-04/README:Synopsis: SunOS 4.1, SunOS 4.1_PSR_A 4.1.1: c2 jumbo patch
100564-01/README:Synopsis: SunOS 4.1.2: C2 Jumbo patch
-----------------------------------------------------
Tim Perala (tperala@ub.d.umn.edu) (218) 726-6122
University of Minnesota, Duluth - Information Services
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:44 CDT