Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!sdd.hp.com!apollo!apollo.hp.com!pato
From: pato@apollo.HP.COM (Joe Pato)
Newsgroups: comp.sys.apollo
Subject: Re: crp does not work + passwd wrong type
Message-ID: <5171930a.20b6d@apollo.HP.COM>
Date: 8 May 91 18:03 GMT
References: <913@imec.UUCP>
Sender: root@apollo.HP.COM
Reply-To: pato@apollo.HP.COM (Joe Pato)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 79

In article <913@imec.UUCP>, fleureck@imec.be (Marc Fleureck) writes:
|> Hi HPollo-ers,
|> 
|> Notes : OS 10.2+psk7, DN4500
|> 
|> I have problems with crp on a node that is also a "cell",
|> what means that it has its own private glbd. It's the only
|> node in the cell too.
|> What I get when I do "crp -login ..." is : 
|> 
|> 	"Unable to set sid - no right to perform operation 
|> 	( from O/S, ACL manager )" and "? (spmlogin),
|> 	no right to perform operation ( OS/ ACL manager )".
|> 
|> If I try a slightly different syntax "crp -me" I get :
|> 
|> 	"?(spmlogin) Unable to set project list - no right ..."
|> 
|> I have checked the passwd and it was of type "unstruct", so I 
|> first tried to fix this by restarting the rgyd, even the glbd
|> and all the stuff to create a cell ( Managing NCS, Procedure 5-1 ),
|> but it did not work.  I also remoded /etc/passwd and thought the 
|> rgyd would create a new one, but that did not work too.
|> 
|> The /sys/registry dbase seems ok.  The problem originated when 
|> I had to re-install the node and made a copy of the disk with cpt,
|> but restored it with tar !!  Then problems started with corrupted
|> file types, but edrgy seemed ok, so I did not pay attention anymore
|> to the registries.  But a few weeks later I noticed that omniback
|> had not performed a backup of the node since a month or so.  Big 
|> panic !  ( Omniback tries to do a crp on every node in order to start
|> a backup process )
|> 
|> 
|> I am posting this here because I get tired of re-installing a node,
|> whenever some problem occurs that cannot be solved quickly, because
|> that is exactly what HP support recommends in such cases most of the 
|> time !!
|> 
|> So the situation is now :
|> 
|> 	1.  No /etc/passwd and /etc/group files ( I removed them and
|> 	    rgyd did not create new ones, but /sys/registry/rgy_data/
|> 	    unix/passwd and group are ok.)
|> 
|> 	2.  A crp does not work ( see above ).  Login on the node
|> 	    through the DM is ok.  
|> 
|> 	3.  Rgy_admin and edrgy are ok.  As is also drm_admin.
|> 
|> Thanks in advance for the help.
|> 
|> Marc Fleureck.
|> IMEC vzw.
|> Kapeldreef 75, 3001 Heverlee
|> Belgium.

I believe your problem is that the spmlogin program has lost its 
protected subsystem entry in its acl.  (Essentially the application
lost the setuid bit which allows it to run as root - this was due to
restoring the machine with tar instead of rbak.)

You probably have a problem with the /etc/passwd and /etc/group files
because you are running the machine as its own cell.  Your note does
not state that you are running a registry in this cell - if you aren't
then you will not be able to obtain passwd and group file data.  If you
are running a server, you still won't see the data since you deleted the
passwd and group files.  Copy a typed passwd and group file from another
node using cpf and you should be ok.

There is no
guarantee that you can perform a "crp -me" between machines in different
cells.  The idea of a cell is that you are constructing an independent
logical space - with its own registry of users.

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