bob@cis.ohio-state.edu (Bob Sutterfield) (04/07/89)
Though there are technical problems with University-wide, multi-OS uid schemes, those are probably solvable, given the exertion of enough sweat by enough talented people. YP (from Sun), Hesiod (from MIT), and Vice/Virtue (from CMU) are all steps toward providing bits and pieces of that "one-world" environment. Others will surely follow, because there are lots of talented people out there. You may find that the biggest problems are political, rather than technical. The longer your campus' various disparate computing communities have been developing, the more entrenched they probably are in their own procedures, and the more difficult it will be to convince them of the overriding benefits of unification. Remember, all those little computing feifdoms have heretofore been in competition for hardware funds and talented systems people. There may be long-standing traditions of, if not animosity, at least habitual lack of cooperation. If your campus has a strong, well-respected, well-funded, technically progressive central computing facility, perhaps they can be instrumental in pulling it off. Otherwise, you're in for quite a battle. Good luck!
hedrick@geneva.rutgers.edu (Charles Hedrick) (04/07/89)
In theory secure RPC could be used to avoid having organization-wide uid's. However it's going to take some work to make that actually happen (and for non-U.S. customers you'd need to do some hacking to get secure RPC to work anyway). Currently we do in fact have university-wide uid's. We have a program that is used to create new users. It talks to a central server that keeps a global username/uid database. Different departments can customize the program as they like to fit their environment, but they at least have to get uid's from the common database. I'm not real enthusiastic about this, since you can only have 32K of uid's. (There are security problems with having uid's above 32K under release 4.0.) But so far we've been able to live with it. We are strongly encouraging Sun to both - do the necessary work on tools so that secure RPC can really be used to decouple different departments' networks. (Also figure out a way to get it to non-U.S. customers. I suggest shipping the code from the U.S. with the des module left out, and letting Sun in Finland supply des.o.) - expand uid's and gid's to 32 bits (and while they're at it, user names to 39 characters). I have no idea how you'd integrate VMS into this. I was hoping that the VMS implementations would provide some sort of mapping.
libes@cme.nbs.gov (Don Libes) (04/22/89)
mcvax!etive.ed.ac.uk!keith@uunet.uu.net (K Farvis) writes: >brings with it the spectre of having a unique uid for all University >users. As well as the fact that the uid range may not be sufficient for >our needs, we would have to change all our current machines (and archive >files) to use these new values. I can't help you with the problem of range, but I can help you with the other problem. I wrote a program, called "pwdiff", which checks multiple passwd files for uid/name overlap, for exactly the reasons you describe. It just got to our site yesterday (3/28) from rsalz's comp.source.unix distribution (v18i068). (Although I submitted it last June!) Don Libes libes@cme.nbs.gov ...!uunet!cme-durer!libes
colin@uunet.uu.net (Colin Grant) (04/26/89)
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
stanonik@nprdc.navy.mil (Ron Stanonik) (05/03/89)
I'd like to see yp domains enumerated and integrated with uids (and gids) to identify users. Then each group could administrate its own users, machines, printers, etc within their own yp domain. References between domains could include the domain name. For example, smith in eecs could have an account on a physics machine by putting +smith.eecs in the physics passwd file. Printers across domains could be referred to by including the domain name; eg, lp0.eecs. (Symbolics allows something like this in it's namespace concept.) The yp commands all seem to take the yp domain as an argument, but nothing (user, printer, hosts, etc references) seems to use that flexibility. Yet? Ron Stanonik stanonik@nprdc.arpa ucsd!nprdc!stanonik