haynes@ucscc.UCSC.EDU (99700000) (12/15/90)
In article <9012142229.AA11803@delwin.MIT.EDU> jon@MIT.EDU (Jon A. Rochlis) writes: > >Other than that we generate the dump files, awk/sed/join them to our >hearts content and then reload. If you've got a slave then you don't >need to have any downtime. > What kinds of things are you doing when you do these operations? We're still on the threshold of worrying about how to run an Athena installation; and most of the operational system-administrator-type procedures seem to be all in people's heads. haynes@ucscc.ucsc.edu haynes@ucscc.bitnet "Any clod can have the facts, but having opinions is an Art." Charles McCabe, San Francisco Chronicle
jon@MIT.EDU (Jon A. Rochlis) (12/16/90)
> >Other than that we generate the dump files, awk/sed/join them to our >hearts content and then reload. If you've got a slave then you don't >need to have any downtime. > What kinds of things are you doing when you do these operations? We're still on the threshold of worrying about how to run an Athena installation; and most of the operational system-administrator-type procedures seem to be all in people's heads. About the only time we do such things is to remove user's who have graduated. We move the user's who don't show up on the registrar's tape into the "deactivated" state in Moira. After enough time goes by for correcting mistakes, we remove the users from Moira (and generate a script to nuke their disk space, etc.). Given the list of nuked users we awk/join whatever them out of the kerberos database. That's about it. Doesn't happen often. We have also gone through and fixed expiration times en masse (some early programs created principal's with expiration time of now + 2 or 3 years). -- Jon
martin@iastate.edu (Calsyn Martin Robert) (12/17/90)
We were faced with a need to add 300+ rcmd.hostname entries to the database and so created a program capable of adding principals from a file. The principals are added with random keys, so to create user principals would require a modification to generate useful passwords. We use a heavily modified version of Moira and the registration server and so, as at MIT, users obtain their principals at the time they register. Deleting principals is a particular nuisance. Jon, is there a particular reason why kdb_edit, or some such program, doesn't support a delete operation. The underlying database systems (dbm, ndbm) are certainly capable of it. Am I breaking a design constraint if I add such a function? Martin R. Calsyn martin@iastate.edu Project Vincent Systems Support gg.mrc@isumvs.bitnet Iowa State University Computation Center voice: (515) 294-9889 Ames, Iowa 50011 fax: (515) 294-1717
jon@MIT.EDU (Jon A. Rochlis) (12/19/90)
Deleting principals is a particular nuisance. Jon, is there a particular reason why kdb_edit, or some such program, doesn't support a delete operation. The underlying database systems (dbm, ndbm) are certainly capable of it. Simple conservatism. If it's difficult to delete principals then it's not likely to happen unless you really want it to. Am I breaking a design constraint if I add such a function? Not as long as you're will to come in at 3:00am and pick up the pieces when a bug in Moira deletes half of your Kerberos database. We'd rather delete people from Moira, remove their mailing list pointer, etc, (all of which can be undone easily) and then at our lesiure delete principals from the Kerberos databse by doing a dump/awk/join cycle. It's up to you to weigh the tradeoffs for yourself. Our call won't make everyone happy. -- Jon
jtkohl@MIT.EDU (John T Kohl) (12/19/90)
Martin asks "is there a particular reason why kdb_edit, or some such program, doesn't support a delete operation". Besides the reasons Jon Rochlis gave, there's also a security-related one. If you delete names and they get re-used, there's a chance that the new owner of the name may get unintended access to services which have the name on an Access Control List, but didn't remove it when the old principal was destroyed. John