rn@ap.co.umist.ac.uk (bob nutter) (03/19/91)
Hi! Has anyone experienced the following, and do they have any solutions?:- On certain nodes, an su is rebuffed with `You do not have permission to su root'. The thing is, I *do*! Running groups(1) just prints a blank line, whilst doing 'groups rn' gives the expected answer. Thus what I have to do to su root is first to su to myself, and then su to root. This baffles me. Perhaps I've missed something obvious. The only thing that happened before this started was that I ran cops and tightened up things quite a bit ;->. It's obviously a registry problem (aren't they all?) so any help would be appreciated. This is for 10.1, don't have the diskspace to go to 10.3 yet... bob ------------------------------------------------------------------------------- bob nutter, computer officer | "If there's no class divide, then how come UMIST dept of computation | you're standing here waiting for a bus po box 88 manchester m60 1qd uk | when somebody drives past in a car worth tel:+44 61 200 3386 | the price of a house?" email:b.nutter@umist.ac.uk | -Class War grafitti
etb@milton.u.washington.edu (Eric Bushnell) (03/21/91)
In article <1991Mar19.154313@ap.co.umist.ac.uk> rn@ap.co.umist.ac.uk (bob nutter) writes: > >On certain nodes, an su is rebuffed with `You do not have permission to su >root'. The thing is, I *do*! Running groups(1) just prints a blank line, whilst ... >for 10.1, don't have the diskspace to go to 10.3 yet... Yes! But I get it at 10.3. groups(1) usually returns an *incomplete* list. Earlier discussion leads me to believe that rgyd does *not* update /etc/passwd[group] in a timely or accurate way. I've also had trouble with reusing unix id numbers. I assigned a number from a deleted acct to a new user, and *one* machine insisted upon using the previous owner's name and rights. Could we force rgyd to update the unix files if we delete /etc/passwd[group]? Eric Bushnell Univ of Washington Civil Engineering etb@zeus.ce.washington.edu etb@milton.u.washington.edu
wjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (03/21/91)
In article <1991Mar19.154313@ap.co.umist.ac.uk> rn@ap.co.umist.ac.uk (bob nutter) writes:
=>Hi!
=>
=>Has anyone experienced the following, and do they have any solutions?:-
=>
=>On certain nodes, an su is rebuffed with `You do not have permission to su
=>root'. The thing is, I *do*! Running groups(1) just prints a blank line,
=>whilst
=>doing 'groups rn' gives the expected answer. Thus what I have to do to
=>su root
=>is first to su to myself, and then su to root. This baffles me.
=>Perhaps I've
=>missed something obvious. The only thing that happened before this
=>started was
=>that I ran cops and tightened up things quite a bit ;->. It's obviously a
=>registry problem (aren't they all?) so any help would be appreciated.
=>This is
=>for 10.1, don't have the diskspace to go to 10.3 yet...
=>
Did you by any change put yourself into more than 8 (eight) groups.
I once did that, and it had the same type of effects. ( Groups(1) ... )
The problem could then lie in the original BSD code which allows a person
to be member of no more than 8 groups.
Eceeding this limit is asking for trouble.
Regards,
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 Netherlandstroy@plod.cbme.unsw.oz.au (Troy Rollo) (03/22/91)
From article <18743@milton.u.washington.edu>, by etb@milton.u.washington.edu (Eric Bushnell):
etb> In article <1991Mar19.154313@ap.co.umist.ac.uk> rn@ap.co.umist.ac.uk (bob nutter) writes:
rn>
rn>On certain nodes, an su is rebuffed with `You do not have permission to su
rn>root'. The thing is, I *do*! Running groups(1) just prints a blank line, whilst
etb> ....
rn>for 10.1, don't have the diskspace to go to 10.3 yet...
etb> Yes! But I get it at 10.3. groups(1) usually returns an *incomplete* list.
etb> Earlier discussion leads me to believe that rgyd does *not* update
etb> /etc/passwd[group] in a timely or accurate way.
Which in itself wouldn't be a problem, as the last data to be put there should
be still there. So unless you've just been added to wheel, you will already
appear in /etc/groups. Unfortunately the Apollo functions to get password file
information seem to always refer to the registry, and if they can't find it,
give up. Perhaps a better recourse would be to then look in /etc/groups, but
Apollo would probably call that a weakness.
This can also be (and in my experience usually is) caused by your node using
somebody else's glbd for a while. If this is happening, and your glb is on a
node on the same subnet as somebody else's glb, you can find out as follows:
# /etc/ncs/lb_admin:
lb_admin: l
.
.
.
You may find that this shows registries from other sites on your subnet.
This problem only occurs on gateway machines, as far as I can tell, and
is fixed by invoking glbd with -li dds (/etc/rc) and by listing the sites
where you expect to find your glbd in /etc/ncs/glb_site.txt in the form
dds://hostname
___________________________________________________________
troy@mr_plod.cbme.unsw.oz.au