Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!apollo!apollo.hp.com!pato
From: pato@apollo.HP.COM (Joe Pato)
Newsgroups: comp.sys.apollo
Subject: Re: RE-registry
Message-ID: <49b47085.20b6d@apollo.HP.COM>
Date: 9 Apr 90 19:43:00 GMT
References: <9004091349.AA05916@cc3.cc.umr.edu>
Sender: root@apollo.HP.COM
Reply-To: pato@apollo.HP.COM (Joe Pato)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 57

In article <9004091349.AA05916@cc3.cc.umr.edu>, obrennan@CC3.CC.UMR.EDU
(obrennan) writes:
|>                      
|> Have you tried placing the registry in maintenance mode, right after
the account
|> deletions, to force an queue update from all queues? I tend to do
that whenever I  
|> have multiple registry operations (again, redirect input to rgy_admin
with the
|> file containing SET -H host, STATE -IN_MAINTENANCE, and QUIT)
|> 

You should not need to do this.  Putting the registry into maintenance mode
simply forces the server to write the VM copy of the database to disk.  This 
will happen periodically anyway.  All updates are also written to the database
stable storage log so committed transactions won't be lost even if the server
crashes before a checkpoint occurs.

 
|> Apollo has warned us against deleting the person without deleting the
account first, 
|> although I must admit I will continue to delete via person until I
see reason otherwise.

I don't know who at Apollo gave you this advice - but it is not correct.  There
is no reason for deleting an account before deleting the person object.  Apollo
recommends that you keep old "person" objects around on the general
principle that
user-name and userid re-use is a bad idea.  Keeping the person object around
prevents you from accidentally reusing a unix id or user name.

On a related topic John Lauro writes:
>It only seem to be a problem when deleting accounts, and immediately
recreating
>them after the deletion of the accounts. (And using the same login and uid
>when recreating the accounts).

This problem exists because each machine maintains a cached mapping of 
unix ids to UIDs and vice versa.  This cache is supposed to be refreshed 
whenever the mapping changes at the server, but the code that does this 
is broken in sr10-sr10.3 and the refresh operation never occurs.  The best way
to avoid the problem is to not reuse unix ids.  (The cache is thrown away when
a machine is rebooted so if you must reuse a set of unix ids you can reboot
the client machines to make sure they get the correct mapping).

In John's case he is deleting a collection of accounts each semester and then
creating a set of new accounts (using the old unix ids).  It would be enough 
for him to reuse a set of unix ids on alternating semesters. (I'm sure that
every machine in his network is rebooted at least once a year)  It is still
safest to just assign a new range of numbers each semester (so that you avoid
remebering which set is current)



                    -- Joe Pato
                       Hewlett Packard Company / Apollo Systems Division
                       pato@apollo.com