home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / unix / misc / 3425 < prev    next >
Encoding:
Text File  |  1992-08-30  |  2.3 KB  |  46 lines
  1. Newsgroups: comp.unix.misc
  2. Path: sparky!uunet!ukma!wupost!sdd.hp.com!cs.utexas.edu!torn!csd.unb.ca!jaf
  3. From: jaf@jupiter.sun.csd.unb.ca (J Anthony Fitzgerald)
  4. Subject: Re: yp (nis) map changes - how do they happen
  5. Message-ID: <1992Aug30.131151.13011@jupiter.sun.csd.unb.ca>
  6. Keywords: passwd yp nis
  7. Organization: University of New Brunswick
  8. References: <1992Aug27.180340.729@ilinx.wimsey.bc.ca> <janet.714981984@dunnart>
  9. Date: Sun, 30 Aug 1992 13:11:51 GMT
  10. Lines: 34
  11.  
  12. In article <janet.714981984@dunnart> janet@cs.uwa.oz.au (Janet Jackson) writes:
  13. >There is a daemon, yppasswdd(8) (at least, it's called that on SunOS4.1.1)
  14. >which passwd(1) talks to.  This daemon does the updating.  It runs on the
  15. >YP master.
  16.  
  17. This brings up another question for me.  What locking mechanism (if any) does
  18. yppasswdd use for the password file.  It apparently does not use the same as
  19. vipw which uses the creation of a link for locking.  The man page for yppasswdd
  20. (at least on my system SunOS 4.1.2) does not explicitly state whether the
  21. daemon locks the file, however, one note states that the name of the password
  22. file passed to the daemon must not be a link.  Would this restriction be because
  23. the daemon uses flock(2) to lock access to the file?  If so, is flock only
  24. issued around the actual updates?
  25.  
  26. The reason I ask is because I have written a script for our account
  27. administrator to simplify adding/removing users.  He obtains a list of
  28. courses and students generated from the registrar's data bases on the MVS
  29. system and the script uses this list to add several hundred users at the
  30. start of each term and remove them at the end.
  31.  
  32. I have been concerned because of the possibility of yppasswdd updating the
  33. password file between the time the script reads in the password and group
  34. files and the rewriting of those files after applying changes.  I have been
  35. assuming that the yppasswdd changes would be quietly lost.  It would be
  36. quite simple to add a perl flock call to the script but I would like to be
  37. assured that this would fix any potential problem.  So far, the scripts seem
  38. to have caused no problem, but it might be a simple case of no one ever having
  39. used yppasswd while the script was running.
  40.  
  41. I thank you for reading this far.
  42. -- 
  43. J. Anthony Fitzgerald    jaf@UNB.ca    (506) 453-4573
  44. Computing Services  UofNB  Box 4400    (506) 453-3590  (FAX)
  45. Fredericton, NB,  CANADA,  E3B 5A3
  46.