Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!PAN.SSEC.HONEYWELL.COM!thompson
From: thompson@PAN.SSEC.HONEYWELL.COM (John Thompson)
Newsgroups: comp.sys.apollo
Subject: re: problems with root access
Message-ID: <9101311851.AA27495@pan.ssec.honeywell.com>
Date: 31 Jan 91 18:51:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 81



(sorry for the bandwidth -- ucsd.edu didn't like me)

Margaret --

> Basically, they have two servers and some diskless nodes. After the power
> failure, the sys admin can't log in as root or do 'su' (getting 'login 
> incorrect' or 'sorry'). However, everybody can log in as an ordinary user.
> Also, the ownership of files owned by root is shown by root's ID, i.e., 0,
> and not by its name 'root'. Some files 'can not be found'.
Sounds to me like the registry daemon isn't being started / starting up.
If, when 'normal users' log on, the DM (display mangler) output window says
something about "Unable to access Network Registry, using local registry"
then that's the case (or else networking is really confused).  You will
sometimes get this "Unable to find..." message for the first bit, as the
rgyd warms up, and as the local node starts looking on the network.

> ...
> It seems rather obvious to me that some corruption of the file system
> has occurred - perhaps of the rgy files ? One can always go back
> to the distribution tapes and backups, and restore everything from scratch,
> but perhaps this is an overkill. 
Unlike standard Unix, Apollos use a registry daemon to service registry 
requests.  The 'files' /etc/passwd, /etc/group, /etc/org, etc are really
special objects that access the network registry daemons to get the information.
That way, you can have one central location for rgy info, so it's always 
up-to-date.  (In practice, you would normally set up a few 'slave' rgyd
processes, so that you have redundancy in case of crashes.  The rgyd processes
exchange info with each other, and keep things up-to-date internally.
In addition to the rgyd process(es), you must have a couple other processes
hanging around to get/keep things working.  You must have a local-location
broker (llbd) on any node that offers NCS services (the rgyd uses NCS, and 
therefore offers services).  You must also have a global-location broker (glbd)
that maintains info from all the llbd processes.  A circular loop is caused,
since the glbd processes offer NCS, so they need to have an llbd running too.

Here's the MINIMUM that you need to have running:
    On a master node (one of the 2 servers), run llbd, glbd, and rgyd.
Here's a BETTER setup (IMHO):
    On each server node, run llbd, glbd, and rgyd.

To start things up:
    llbd      started in /etc/rc -- command is '/etc/ncs/llbd'
    glbd      "" "" "" "" "" "" "" "" "" "" "" '/etc/ncs/glbd'
              to make the first one, '/etc/ncs/glbd -create -first')
              to make others, '/etc/ncs/glbd -create -from //node_with_glbd'
    rgyd      started in /etc/rc -- command is '/etc/rgyd'
              to make a replica(slave), '/etc/rgyd -create'
              to restart a broken one,  '/etc/rgyd -recreate'

If the rgyd isn't starting up successfully, there may be problems, because
you need to become root in order to fix the thing that lets you become
root.  He/she might want to try the default passwords, on the hope that
its hiding in the local-registry (a simple file lookup) w/ an old password.
If a glbd or an llbd isn't running, that fix is a lot easier.  Just get 
on as someone who can add objects to the /etc/daemons stub-file directory,
and add entries.  (If a glbd has never been running, you're in the same 
boat as w/ the rgyd -- you need to be root to create a glbd).  They might
be able to put commands into the /etc/rc file to create things, reboot,
and then un-edit the file back to its original state.

> Somebody suggested to me that the system might have reset the root passwd
> to the default password. I had no chance to check it this helps, but would
> this account for file ownership showing as belonging to "0" instead of
> "root" ?
Probably not the case.  It certainly wouldn't account for the '0' instead of
'root'.

> Any help/hint/advice appreciated. Thanks in advance.
Hope I helped, rather than babbled.  You're welcome.


-- jt --
John Thompson
Honeywell, SSEC
Plymouth, MN  55441
thompson@pan.ssec.honeywell.com

As ever, my opinions do not necessarily agree with Honeywell's or reality's.
(Honeywell's do not necessarily agree with mine or reality's, either)