fleureck@imec.be (Marc Fleureck) (05/07/91)
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.
wjw@ebh.eb.ele.tue.nl (Willem Jan Withagen) (05/08/91)
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 )".
=>
Shure sound like the access controlfile for spm is closed for this user.
The file \`node_data/spm_control regulates which users, groups, org
are allowed to 'crp' to this node.
Next to that, the /sys/spm/spmlogin has to belong to the login subsystem.
Ciao,
Willem Jan Withagen
--
Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl
Digital Systems Group, Room EH 10.10
P.O. 513 Tel: +31-40-473401
5600 MB Eindhoven The Netherlandspato@apollo.HP.COM (Joe Pato) (05/09/91)
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
Hannu.Martikka@lut.fi (Hannu Martikka) (05/09/91)
We have following problem with crp: % cpr -on //node_name ?(spmlogin) Error setting process name - Insufficient rights (OS/naming server) login: After that it works fine, but where does that Insufficient rights come from??? It is same thing when you add -me on crp. -- Regards from Goodi ______________________________________________________________________________ Internet: Hannu.Martikka@lut.fi / \ Bitnet : GOODGULF@FINFILES // \\ \-\-\-\-\-\-\ oh5lhh Hannu Martikka, Punkkerikatu /// \\\ | on 70cm 7C 36, 53850 Lappeenranta,SF /// | \\\______________|_________________________ Tel. 953-251446 | :) Lappeenranta University Of Technology | ------------------------------------------------------------------------------
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (05/10/91)
> 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 ) This is probably one of 2 things: 1) The ACLs are set wrong/weird on the crp?? devices and/or the `node_data/proc_dir directory. Check them both out, but my bet is... 2) You munged the protected login subsystem. Apollo has things that are similar to setuid rights in a thing called a protected subsystem. You can have programs/data that are part of the subsystem, and the programs will make calls to raise their access before making changes to the protected data elements. The login stuff comes under this category, back from before the sr10 registry was around. Here's (at least some of) what you need to have : -- jt > acl /sys/subsys/login -- Acl for /sys/subsys/login: -- Subsystem login manager -- Required entries -- root.%.% pr-x- -- %.sys_admin.% -r-x- -- %.%.none [ignored] -- %.%.% -r-x- -- jt > acl /com/login -- Acl for /com/login: -- Subsystem login manager -- Required entries -- root.%.% pr-x- -- %.sys_admin.% -r-x- -- %.%.none [ignored] -- %.%.% -r-x- -- jt > acl /sys/spm/spmlogin -- Acl for /sys/spm/spmlogin: -- Subsystem login manager -- Required entries -- root.%.% pr-x- -- %.sys_admin.% -r-x- -- %.%.none [ignored] -- %.%.% -r-x- -- Extended entry rights mask: ----- If the /sys/subsys/login file is missing, copy it over from another node. You can make things be login managers/data with the 'subs' command, but I've found it easier to just become root and ACL the elements from a known good copy (e.g. acl //bad/sys/spm/spmlogin //good/sys/spm/spmlogin) Do a HELP on protection/proected_subs to find out more. Hope this helps... -- jt -- John Thompson (I'M ENGAGED!!!!) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com A pessimist sees the tunnel. An optimist sees the light at the end of the tunnel. The realist sees the tunnel, the light at the end of the tunnel, and realizes that it's an oncoming train.
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (05/14/91)
> We have following problem with crp: > > % cpr -on //node_name > ?(spmlogin) Error setting process name - Insufficient rights (OS/naming server) > login: > > After that it works fine, but where does that Insufficient rights come > from??? > It is same thing when you add -me on crp. The problem is the ACLS (rights) on the `node_data/proc_dir directory. This directory holds the names of the processes, if they decide to name themselves (CRP processes name themselves 'username.nodenum', unless you give them an alternate name). This means that the directory must be writable by everyone. This is yet another place where /sys/node_data (normal resolution of `node_data) can give Unix people a headache. It's in a system area, but it needs to be open in order to work.... (BTW: You used to be able to name processes by using 'ctob' to catalog the UID returned by ps(t) as `node_data/proc_dir/processname. You can't any more. The command works, but doesn't change the name. You need to use the unsupported pm_$set_my_name() procedure. (There's also pm_$set_name() for setting any process' name, if you know how to use it....) -- jt -- John Thompson (I'M ENGAGED!!!!) Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com A pessimist sees the tunnel. An optimist sees the light at the end of the tunnel. The realist sees the tunnel, the light at the end of the tunnel, and realizes that it's an oncoming train.