Newsgroups: comp.sys.apollo
Path: utzoo!utgpu!news-server.csri.toronto.edu!helios.physics.utoronto.ca!alchemy.chem.utoronto.ca!system
From: system@alchemy.chem.utoronto.ca (System Admin (Mike Peterson))
Subject: Re: reducing the delay between edrgy and getpwuid() etc ...
Message-ID: <1991Feb20.185751.22334@alchemy.chem.utoronto.ca>
Organization: University of Toronto Chemistry Department
References: <1093@usage.csd.unsw.oz.au> <384@camdev.comm.mot.com?>
Date: Wed, 20 Feb 1991 18:57:51 GMT

In article <384@camdev.comm.mot.com?> mmuegel@camdev.comm.mot.com	 (Michael Muegel) writes:
>In article <1093@usage.csd.unsw.oz.au> cameron@spectrum.cs.unsw.oz.au writes:
>>My problem is currently that after I've called the make-an-account call, and
>>edrgy's replied with a prompt indicating all is happiness, I often won't be
>>able to successfully do a getpwuid() or getpwnam() on said account for quite
>>a while (typically about a minute). Currently I sit in a loop polling
>>getpwuid() and sleeping for 10 seconds until it works, so that the program
>>can continue on its way and make home directories and set ownership, etc.
>
>In my Perl scripts I wrote for our admins I simply parse edrgy -v -a login
>output. I know better than to even try to trust the /etc/passwd file ;-).
>We have a fairly large network (~130) and it seems to take an unberably long
>time for the passwd file to reflect the true state of the registry.

I can believe it. I added a 'sleep 15' after the account creation 
and before creating the new users directory in our Addusers script
(we have only 5 nodes, with 2 rgyd nodes, yet they still can't keep in
synch it seems). For some "reason", our DN10000 master registry node does ALL
its registry lookups on the DN4500 slave rgyd node (a great waste of time -
all such "network" requests should be satisfied locally if possible). 
Basing a critical service like authentication on a daemon is crazy; it
should be file based (a daemon system could be used to update the file,
retaining the "old" copy in case of a crash during the update).
This would avoid most of the problems of screwed registries, since the
master file could be editted by hand (from backups if necessary).
Unfortunately, I gather OSF has adopted the rgyd approach.
-- 
Mike Peterson, System Administrator, U/Toronto Department of Chemistry
E-mail: system@alchemy.chem.utoronto.ca
Tel: (416) 978-7094                  Fax: (416) 978-8775
