🚀 go-pugleaf

One of the real problems with organisation-wide uids (once you've sorted
out the politics) is persuading the various `add-user' scripts to use a
centraly defined number for the uid.  Most scripts that I've seen do
clever things such as assign the next unused uid.

Whereas this autonomous decision process is the correct thing to do in a
stand-alone situation (one machine/one YP domain) it doesn't half cause
problems when more than one uid domain is involved.  To combat this (we
have five uid domains) I wrote some simple software to act as a central
uid server which can assign and retrieve uids for given user names.

However, some issues need to be sorted out.  For instance what happens if
the machine with the central server is unavailable?  Do we assign a
temporary number and then get some super-user to re-do the assignment and
then chown all the new user's files?  For week old users this is not a
problem as they usually know where their files are, and they're normally
in the user's immediate directory tree.  The problems start when a user
has been around for a while and has files in lots of different places
(project libraries for instance).  Though this is probably not such a
problem for the original poster, being in an academic environment.

The software also needs to be set up as a real RPC server - at the moment
we just use remote shells to do the job.  Otherwise it works fine - I use
it whenever I have to assign new uids (If my server machine is down (a
very infrequent event - no it isn't a Sun :-)) then I can't do any work,
so I might as well handle the assignment by hand!).

The software writes all changes to backing state files before returning
values to always ensure that what is returned is correct.  It has been
written to use a write-through cache in server mode, or to simply
update/read the backing files in batch mode.  It also has a simple
super-user front-end that allows inspection/modification and a whole host
of other useful facilities.

If anyone wants a copy I'm quite happy to release the software to them.  I
would have sorted out some of the problems mentioned above but I don't
have the time - what I have works for me and thats good enough.  If
someone should want to extend the software then please let me have a copy
back.

Note that all requests will be batched until I have time to send the
source out.  This should also save bandwidth for cross-the-puddle copies.

Regards,
Colin.

Colin Grant                     |Phone: +44 223 66343            
Logica Cambridge Limited        |Fax:   +44 223 322315           
Betjeman House                  |UUCP : colin@logcam.co.uk       
104 Hills Road                  |       colin@logcam.uucp        
Cambridge CB2 1LQ   UK          |       ..!mcvax!ukc!logcam!colin