rtb@cernapo.cern.ch (Rainer Tobbicke) (03/14/91)
I have got a problem trying to change my login shell with chsh (I'm running BSD): it says chsh: Unable to update /etc/passwd or registry. Not owner Other people do not have the same problem. Even with a second 'account' belonging to the same 'person' (in the sense of edrgy) it works fine. And of course I can change my account when I su to root. Needless to say, since chsh is essentially passwd, passwd has the same problem, /etc/edrgy is no better. It works fine with the local registry (chsh -l), which definitely points to a network registry problem since the problem does not disappear on other nodes I tried. /etc/rgy_admin showed no anomaly, and for once even /etc/ncs/drm_admin did not come up with clock skew warnings. To shake things a bit I even changed the master registry and stopped the rgyd on the node /etc/edrgy always insisted on talking to first... no go! My question: what is going on here? Thanks for any ideas! -- Rainer Toebbicke European Organisation for Nuclear Research (CERN) Geneva, Switzerland rtb@cernapo.cern.ch, rtb@cernvm.cern.ch
matt@bacchus.esa.oz (Matt Atterbury) (03/18/91)
In article <rtb.668960287@cernapo.cern.ch> rtb@cernapo.cern.ch (Rainer Tobbicke) writes:
I have got a problem trying to change my login shell with chsh
(I'm running BSD): it says
chsh: Unable to update /etc/passwd or registry. Not owner
... deleted ...
Can anyone tell me if this incredibly unreliable and unfathomable
piece of software (e.i. rgyd) is still used with SR10.3 ? I am sick to
death having to play with 25 zillion arcane tools to just keep the
bloody thing running! (it's a good idea - it just doesn't work).
cheers ...
--
-------------------------------------------------------------------------------
Matt Atterbury [matt@bacchus.esa.oz] Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari!matt@bacchus.esa.oz "klaatu barada nikto"
or: ...!uunet!murtoa!bacchus.esa.oz!matt "consider this a divorce"
ARPA: matt%bacchus.esa.oz.AU@uunet.UU.NET "life? don't talk to me about life!"dpassage@tornado.Berkeley.EDU (David G. Paschich) (03/18/91)
In article <rtb.668960287@cernapo.cern.ch> rtb@cernapo.cern.ch (Rainer Tobbicke) writes: >I have got a problem trying to change my login shell with chsh >(I'm running BSD): it says >chsh: Unable to update /etc/passwd or registry. Not owner > >Other people do not have the same problem. Even with a second >'account' belonging to the same 'person' (in the sense of edrgy) >it works fine. And of course I can change my account when >I su to root. We've been having the same problem with our registry, under SR10.3 on a net of 3500 and 4500's, and if you think it's a pain with twenty users, try it on an open access system with 1500 active accounts, most belonging to people with little or no Unix experience. The problem appeared with OS 10.3. It was previously discussed here, and the only suggestion we got was to make sure that glbd is running on the same node as the master registry, whereas the Apollo docs only say to run it somewhere on the ring. The problem isn't consistent; we've been telling our users to try it again later or on a different node. It seems to occur somehere around 50% of the time. David G. Paschich dpassage@ocf.berkeley.edu Just say not to huge .sigs!
pato@apollo.HP.COM (Joe Pato) (03/18/91)
In article <MATT.91Mar18090719@henry.bacchus.esa.oz>, matt@bacchus.esa.oz (Matt Atterbury) writes: |> In article <rtb.668960287@cernapo.cern.ch> rtb@cernapo.cern.ch (Rainer Tobbicke) writes: |> |> I have got a problem trying to change my login shell with chsh |> (I'm running BSD): it says |> chsh: Unable to update /etc/passwd or registry. Not owner |> |> ... deleted ... |> |> Can anyone tell me if this incredibly unreliable and unfathomable |> piece of software (e.i. rgyd) is still used with SR10.3 ? I am sick to |> death having to play with 25 zillion arcane tools to just keep the |> bloody thing running! (it's a good idea - it just doesn't work). |> |> cheers ... |> -- The "Not owner" error is generated upon an authentication failure when trying to update data in the network registry. In general this will happen if the user is not authorized to update the data (for password and shell changes, this means the user is updating another user's account and the active user is not the administrator for that account). The error can also occur if the user has not established the proper authentication key on the local machine. This will happen if the user logged in off of the local registry or used "crp -me" or rlogin without a password. In each of these cases the chsh process does not have access to the proper authentication key - and this will prevent the authentication protocol from running correctly which in turn causes the registry server to deny update access. -- Joe Pato Cooperative Computing Division Hewlett-Packard Company pato@apollo.hp.com
chen@digital.sps.mot.com (Jinfu Chen) (03/19/91)
In article <1991Mar18.042411.16778@agate.berkeley.edu> dpassage@tornado.Berkeley.EDU (David G. Paschich) writes: >In article <rtb.668960287@cernapo.cern.ch> rtb@cernapo.cern.ch (Rainer Tobbicke) writes: >>I have got a problem trying to change my login shell with chsh >>(I'm running BSD): it says >>chsh: Unable to update /etc/passwd or registry. Not owner >> >The problem appeared with OS 10.3. It was previously discussed here, and >the only suggestion we got was to make sure that glbd is running on the same >node as the master registry, whereas the Apollo docs only say to run it >somewhere on the ring. The problem isn't consistent; we've been telling our >users to try it again later or on a different node. It seems to occur >somehere around 50% of the time. We reported this problem to Apollo (ticket # at020256) a while back. If my memory is right, it has something to do with incompatibility of registry database in SR10.2 and SR10.3. User whose password is in SR10.2 format will have trouble changing it under SR10.3 and will get a message about "not authorized" if using /com/chpass, or "not owner" if using /bin/passwd. The only way to fix it is to have root login on the node that runs rgyd master (either via DM or via telnet, not via CRP!), then change it for the user. After this, the user will be able to use chpass or passwd. There're several other things you could check: o is the master glbd running and communicating with its replica (use /etc/ncs/drm_admin)? o if upgrading from 10.1, have you replace all 10.1 nodes that run rgyd with the 10.2/10.3 version of rgyd (it can be used on 10.1 node)? o kill all other rgyd replica and just use the master rgyd until the problem is solved. I know this will be a real royal pain for large network. o Order a copy of "Administering the Domain/OS Registry", order no 015363-A00. P.S. I was told by the person helping me in the hotline that Apollo will send a notice to user regarding this registry incompatibility problem. Apparantly, either I miss the notice, or ...
dpassage@hailstorm.Berkeley.EDU (David G. Paschich) (03/19/91)
In article <50709a54.20b6d@apollo.HP.COM> pato@apollo.HP.COM (Joe Pato) writes: >The "Not owner" error is generated upon an authentication failure when >trying to update data in the network registry. In general this will >happen if the user is not authorized to update the data (for password >and shell changes, this means the user is updating another user's account >and the active user is not the administrator for that account). The >error can also occur if the user has not established the proper authentication >key on the local machine. This will happen if the user logged in off of >the local registry or used "crp -me" or rlogin without a password. In each >of these cases the chsh process does not have access to the proper >authentication key - and this will prevent the authentication protocol from >running correctly which in turn causes the registry server to deny >update access. This error continues to occur under those conditions, i.e., the person logged in directly on console or used the crp or rlogin programs with a password. Again, our system is running SR 10.3 on 35 and 4500's with 17 nodes and four registry sites. glbd is running on the node with the master registry. David G. Paschich Open Computing Facility Site Manager UC Berkeley dpassage@ocf.berkeley.edu "I'm so happy I can't stand myself" -- Adam Glass
randall@bcstec.boeing.com (Michael Randall) (03/20/91)
In article <rtb.668960287@cernapo.cern.ch>, rtb@cernapo.cern.ch (Rainer Tobbicke) writes: > I have got a problem trying to change my login shell with chsh > (I'm running BSD): it says > chsh: Unable to update /etc/passwd or registry. Not owner > Rainer Toebbicke There is one thing you haven't mentioned. Did you check to see if you are the owner of your account entry in the rgy? It is possible to create an entry and set the owner to someone else. For Instance: edrgy=> do p Domain changed to: person edrgy=> add add person=> Enter name: guest Enter UNIX number: 9001 Enter full name in quotes: Guest Enter owner [p.g.o]: (%.%.%) root.staff.none This will create an account where the user (guest) has no rights to change his/her own account. It's just one more possibility. -- -------------------- Peace Love & E-Mail ---------------------------------- Michael W. Randall | Phone: (206) 965-9557 randall@bcstec.boeing.com | This space for rent... ...!uunet!bcstec!randall | ...Inquire within.
etb@milton.u.washington.edu (Eric Bushnell) (03/20/91)
>This error continues to occur under those conditions, i.e., the person logged >in directly on console or used the crp or rlogin programs with a password. I have noticed that the glbd's are not always very good at handling changes to their databases. Have you tried using /etc/ncs/lb_admin to look at the various glb databases? It's amazing, sometimes, what obsolete artifacts get left there. There's a "clean" command that tries to find and delete such artifacts. You may want to try that (just for grins?) I get a lot of "no rights" and "not owner" errors on one of my 10.3 nodes. I'm planning to reinstall the OS on it, since nothing else has fixed it so far. Eric Bushnell Univ of Washington Civil Engineering etb@zeus.ce.washington.edu etb@milton.u.washington.edu
hanche@imf.unit.no (Harald Hanche-Olsen) (03/21/91)
In article <738@bcstec.boeing.com> randall@bcstec.boeing.com (Michael Randall) writes:
There is one thing you haven't mentioned. Did you check to see if you
are the owner of your account entry in the rgy? It is possible to create
an entry and set the owner to someone else. For Instance:
edrgy=> do p
Domain changed to: person
edrgy=> add
add person=> Enter name: guest
Enter UNIX number: 9001
Enter full name in quotes: Guest
Enter owner [p.g.o]: (%.%.%) root.staff.none
This will create an account where the user (guest) has no rights to
change his/her own account. It's just one more possibility.
All our accounts are owned by root.staff.none, and anybody can change
their password, full name, gecos information, and shell. JLRU.
- Harald Hanche-Olsen <hanche@imf.unit.no>
Division of Mathematical Sciences
The Norwegian Institute of Technology
N-7034 Trondheim, NORWAYpato@apollo.HP.COM (Joe Pato) (03/22/91)
In article <HANCHE.91Mar20170827@hufsa.imf.unit.no>, hanche@imf.unit.no (Harald Hanche-Olsen) writes: |> In article <738@bcstec.boeing.com> randall@bcstec.boeing.com (Michael Randall) writes: |> |> There is one thing you haven't mentioned. Did you check to see if you . . . |> |> All our accounts are owned by root.staff.none, and anybody can change |> their password, full name, gecos information, and shell. JLRU. |> |> - Harald Hanche-Olsen <hanche@imf.unit.no> |> Division of Mathematical Sciences |> The Norwegian Institute of Technology |> N-7034 Trondheim, NORWAY Actually, users cannot change their fullname - only the rest of the GECOS field. The fullname is actually stored in the person record. If you use chfn and try to change this field, you will generally get the unauthorized to update error (unless of course you are the administrator for your own account). In the OSF DCE version of the registry each object contains a more complete acl and it is possible to indicate that a user can modify their own fullname. -- Joe Pato Cooperative Computing Division Hewlett-Packard Company pato@apollo.hp.com
rtb@cernapo.cern.ch (Rainer Tobbicke) (03/26/91)
Actually, together with a collegue we have traced the problem down to a change to the user's name: in order to put a user into another group, we use /etc/edrgy and 'c account.group.org -n acount.newgroup.org'. This seems to do what you would do with a vi of /etc/passwd on a vanilla Unix system, the user ends up in group 'newgroup' (I'm aware that this creates a mess in his file base). After this the poor guy cannot change his default shell any more...! Thanks to anybody who hinted at possible ownership, glbd, clock skews in drm_admin etc..., I went through the whole lot and think everything works perfectly (for once). Now, if anybody has an idea on how to change a user's group in a different manner... -- Rainer Toebbicke European Organisation for Nuclear Research (CERN) Geneva, Switzerland rtb@cernapo.cern.ch, rtb@cernvm.cern.ch
pato@apollo.HP.COM (Joe Pato) (03/28/91)
In article <rtb.669980263@cernapo.cern.ch>, rtb@cernapo.cern.ch (Rainer Tobbicke) writes: |> Actually, together with a collegue we have traced the problem down to |> a change to the user's name: in order to put a user into another |> group, we use /etc/edrgy and 'c account.group.org -n acount.newgroup.org'. |> This seems to do what you would do with a vi of /etc/passwd on a vanilla |> Unix system, the user ends up in group 'newgroup' (I'm aware that this |> creates a mess in his file base). |> |> After this the poor guy cannot change his default shell any more...! |> This is a bug, but with a simple workaround. When you use the edrgy change command to change an account's name (in order to change the default group associated with the account), it will not preserve the user's authentication key. A new key is generated. A user who is currently logged in will have the old key and therefore not be able to authenticate properly. The problem should go away after the user logs in anew - unfortunately the change to the account record neglected to update a flag associated with the authentication info that would have made this work correctly. This problem will go away if the administrator sets a new password for the account and the user logs in with the new password. - Joe Pato Cooperative Computing Division Hewlett-Packard Company pato@apollo.hp.com
rtb@cernapo.cern.ch (Rainer Tobbicke) (03/28/91)
pato@apollo.HP.COM (Joe Pato) writes: >This problem will go away if the administrator sets a new password for the >account and the user logs in with the new password. Thanks for the hint. But I reckon we'll have to change some 600 users. All at more or less the same time. Impossible to manage 600 different non-trivial passwords within a couple of hours... If only I could put the user's ENCODED password back into the registry! Anybody got an idea?? -- Rainer Toebbicke European Organisation for Nuclear Research (CERN) Geneva, Switzerland rtb@cernapo.cern.ch, rtb@cernvm.cern.ch
rpj@echo.canberra.edu.au (Ross Johnson) (03/29/91)
In <rtb.670161956@cernapo.cern.ch> rtb@cernapo.cern.ch (Rainer Tobbicke) writes: >pato@apollo.HP.COM (Joe Pato) writes: >>This problem will go away if the administrator sets a new password for the >>account and the user logs in with the new password. >Thanks for the hint. But I reckon we'll have to change some 600 users. >All at more or less the same time. Impossible to manage 600 different >non-trivial passwords within a couple of hours... >If only I could put the user's ENCODED password back into the >registry! Anybody got an idea?? This has happened twice to me in the past and so, without knowing why it might work, I offer 2 possible solutions: 1 Try using rgy_admin to change_master to another replica site, then change_master back to the original master site. This worked for me the first time I saw this problem, but not the second (under sr10.1 or sr10.0, I'm not sure). This also worked just this week when my master registry kept dying all-of-a-sudden (under sr10.2). 2 After a backup: Copy your /etc/{passwd,group} files to somewhere and then rename your /sys/registry directory and recreate your master registry. Use import_passwd to import the old saved passwd and group files. I used this the second time when I got the "not authorized" response from attempting the "change_master" solution above. [WARNING: This will destroy your current UUID -> UID rgy mappings and require you to run syncids then comb your filesystem to re-chown lots of files and directories, namely everything that doesn't belong to any of the first 8 (?) special users in your passwd file (which have permanent UUIDs).] (avoid this if possible) Any explanation of how the first solution works, or other suggestions would be most welcome. -- +----------------------+---+ | Ross Johnson | | E-Mail: rpj@ise.canberra.edu.au | Info Sciences and Eng|___| | University of Canberra | UUCP : uunet!munnari!ise.canberra.edu.au!rpj | PO Box 1 | JANET : rpj%au.edu.canberra.ise@EAN-RELAY | Belconnen ACT 2616 | BITNET: rpj%ise.canberra.edu.au@relay.cs.net | AUSTRALIA | +--------------------------+
rees@pisa.citi.umich.edu (Jim Rees) (03/30/91)
In article <rpj.670203172@ise>, rpj@echo.canberra.edu.au (Ross Johnson) writes:
2 After a backup:
Copy your /etc/{passwd,group} files to somewhere and then
rename your /sys/registry directory and recreate your master
registry. Use import_passwd to import the old saved passwd
and group files...
[WARNING: This will destroy your current UUID -> UID rgy mappings
and require you to run syncids then comb your filesystem to
re-chown lots of files and directories...
We had to do this here once. The secret to making it work right is that you
first have to "adopt" all your old person, group, and org ids into the new
registry, so you can get the old uids as well as the old Unix ids. We got a
list of all the entries in the old registry and edited this to make a script
to re-create the entries in the new registry. This worked fine, and is
easier than trying to track down and chown every file in the network!