Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!sdd.hp.com!apollo!apollo.hp.com!pato
From: pato@apollo.HP.COM (Joe Pato)
Newsgroups: comp.sys.apollo
Subject: Re: Problem with registry date
Message-ID: <4c14143e.20b6d@apollo.HP.COM>
Date: 8 Aug 90 15:29:00 GMT
References: <247@rangkom.MY>
Sender: root@apollo.HP.COM
Reply-To: pato@apollo.HP.COM (Joe Pato)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 71

In article <247@rangkom.MY>, azman@rangkom.MY (Azman Bahrom) writes:
|> 
|> Hi netters !!
|> 
|> Recently I've been having the following problems :
|> 
|>     1. the registry date is incorrect. It seems to have
|>        a "future" date. I realized this when I invoked rgy_admin :=
|> 
|>         $ /etc/rgy_admin
|> 	        Default object: rgy  default host: dds://idea_4
|>         	State: in service  slave
|>         rgy_admin: lrep -st
|>         (master)  dds://dsp10    	state: in service       
1991/03/20.11:26:17	
|>                   dds://idea_4   	state: in service       
1991/03/20.11:25:33	
|> 
|>     As a result (I think), this made the registry server to point
|>     to a replica host instead of the master node everytime I invoked
|>     /etc/rgy_admin.
|> 
|>     2. consequently, the user could not run chpass. Only root could
|>        edit the registry by /etc/edrgy -s .
|> 
|> I would appreciate it if someone in netland could help me out on these
|> problems. BTW, our system is running SR10.1 and SR10.2 in the same ring
|> of 25 nodes. Please respond by email.
|> 
|> Thanks in advance.
|> 
|> azman baharom.
|> email address : azman@rangkom.MY
|>  

When rgy_admin prints a timestamp for each replica "lrep -st" it is printing
the timestamp for the last update seen by that replica.  Update timestamps are
generated by the master server and are monotonically increasing.  If you
correct
the master's clock the timestamps generated for new updates will still appear
to be in the future - until realtime catches up with the update timestamp

Skewed update timestamps have nothing (directly) to do with why you can't find
the master server.  Rgy_admin will pick an arbitrary registry server
when it is 
first started, so will the other tools that manipulate the registry
(like chpass)
To find the registry servers (and to find the master site) the registry library
code queries the global location broker.

If the tools cannot find the master registry it is likely to be because they
cannot find a current registration for that server in the glbd.  I suspect that
this is happening because the glbd replicas also do not have their clocks
synchronized.  (If your site is like many others, you are running a glbd on
the registry machines too and we already know that at least one of these 
machines is way out of synch).  Unlike the registry servers, if the glbd sites'
clocks drift out of synch by more than 10 minutes, then they will not exchange 
information (more precisely for any two replicas, if their clocks are more than
10 minutes out of synch, then they will not exchange updates - other replicas 
that are within the synchronization tolerance will continue to exchange
updates)
Use drm_admin to determine if glbs are out of synch.

If you have glbs that are way out of synch (like the registry server that 
thought it was march of '91) it will probably be best to just delete those
glb sites, fix the clocks, and then re-create the glb site.

                    -- Joe Pato
                       Cooperative Object Computing Operation
                       Hewlett-Packard Company
                       pato@apollo.hp.com