matt@bacchus.esa.oz (Matt Atterbury) (05/23/91)
OK, I've tried everything I know (took 30 seconds :-) and I still
can't figure it out ...
We have a disked DN3500 running SR10.2 using xdm for logging in.
It _used_ to have a rgyd but we've taken it off now (the problem
seemed to occur "not long" after doing this).
When trying to log in, xdm seems to use the local registry for
passwords etc as most people can't log in, but some can. You can
rlogin and crp onto it fine from anywhere on the net, but you
(i.e. most people) just can't log in at the console! Fortunately,
the most frequent users tend to be able to log in (another
indication that it's using the local registry). Question is, WHY!?
Do I have to restart its rgyd? I've checked that /etc/passwd and
/etc/group have obty of passwd/group respectively; /sys/registry
looks OK (don't know what ACLs it should have). As I said, it
seems that only xdm has problems, so I'm lost. It's the only node
out of ~18 with this problem. help!
--
-------------------------------------------------------------------------------
Matt Atterbury [matt@bacchus.esa.oz.au] Expert Solutions Australia, Melbourne
UUCP: ...!uunet!munnari!matt@bacchus.esa.oz.au "klaatu barada nikto"
or: ...!uunet!murtoa!bacchus.esa.oz.au!matt "consider this a divorce"
ARPA: matt%bacchus.esa.oz.AU@uunet.UU.NET "life? don't talk to me about life!"pschenk%cernapo.cern.ch@PUCC.PRINCETON.EDU (Paul Schenk) (05/23/91)
> We have a disked DN3500 running SR10.2 using xdm for logging in. > It _used_ to have a rgyd but we've taken it off now (the problem > seemed to occur "not long" after doing this). We had a similar problem on a DN10k that we stopped the rgyd on. I fixed it by deleting the directory /sys/registry/rgy_data . It seems that if this directory exists the node assumes it should at least have a slave registry and tries to contact a local rgyd. This fails, of course. Deleting this directory should clear things up. Make sure you keep the rest of the stuff in /sys/registry though. Ciao, Casper Paul Schenk | University of Victoria | CERN PPE / OPAL pschenk%cernapo@cernvax.cern.ch <- Pref. pschenk@cernvm.cern.ch schenk@uvvm.bitnet " I have never seen anything fill up a vacuum so fast and still suck " -Rob Pike on X
thompson@PAN.SSEC.HONEYWELL.COM (John Thompson) (05/24/91)
> We have a disked DN3500 running SR10.2 using xdm for logging in. > It _used_ to have a rgyd but we've taken it off now (the problem > seemed to occur "not long" after doing this). > > When trying to log in, xdm seems to use the local registry for > passwords etc as most people can't log in, but some can. You can > rlogin and crp onto it fine from anywhere on the net, but you > (i.e. most people) just can't log in at the console! Fortunately, > the most frequent users tend to be able to log in (another > indication that it's using the local registry). Question is, WHY!? > Do I have to restart its rgyd? I've checked that /etc/passwd and > /etc/group have obty of passwd/group respectively; /sys/registry > looks OK (don't know what ACLs it should have). As I said, it > seems that only xdm has problems, so I'm lost. It's the only node > out of ~18 with this problem. help! Check out the global brokers (glbd). Use /etc/ncs/drm_admin to check on them and check the clock skews. If they're too far out of whack, they don't tell each other what services are available. Check out the registry with /etc/rgy_admin. Use this to find out whether your registry system still thinks there's a registry at the bad node. If it does, use 'delrep' to get it gone. Check out that node's information with /etc/ncs/lb_admin. This is a dialog based tool (w/ command line input, but that's yucky) that can do 'lookup' and 'clean' on the llbd database for a node, and on the glbd database that you specify OR THE DEFAULT THAT THE NODE FINDS. Just click on the '<= local' box in the dialog window to switch it to 'global =>', or enter 'use_broker global' Then click on 'clean', or enter 'clean * * *' to have lb_admin check out all the services. If the glbd it selects isn't valid (or isn't talking w/ the rest of them, you've found your problem. -- jt -- John Thompson Honeywell, SSEC Plymouth, MN 55441 thompson@pan.ssec.honeywell.com When in danger, when in doubt -- run in circles, scream and shout.