rn@ap.co.umist.ac.uk (bob nutter) (08/10/90)
Hi!
I've suffered the same problems with crp from time to time, but my worst
problem has been with NCS, which has caused the printer not found/can't
bind socket type errors. This might be different, then again...
I've been getting 'registry server unavailable' messages on our gateway
to a large campus backbone. Merging registries doesn't work, and does
rebooting (full or phase II) *sometimes* worked. I finally traced the
problem to being due to the llbd on the node thinking that the glb was
somewhere off our local network and on the ethernet backbone. Thus I was
getting totally unknown apollos registered (with various addresses, ip
and dds) as objects such as the glb, registry updates/queries, etc. As
we had *Domain* routing switched off we weren't expecting this. I
haven't found a way to stop this yet, so if anyone has any ideas...
However a temporary cure, which lasts a random amount of time (usually
in days) is to disconnect from the offending network, retstart the llbd
after removing it's database and then reconnecting the network.
eg: kill <llbd_pid>
rm /tmp/llbdbase.dat
/etc/ifconfig eth0 down #or whatever interface
/etc/server -p /etc/ncs/llbd &
#then check using lb_admin that the correct glb is being used
/etc/ifconfig eth0 up
#restart lpd, etc if needed
-on bootup roughly the same thing happens, except we put a sleep on the
ether ifconfig to give the llbd chance to get the right glb. BTW, we
have a domain network number unique to our campus (at least) as well now.
It took a long time to realise this, so I hope it's of some help to
anyone suffering the same/similar problem. Glancing at the sr10.2
release notes, I notice that you can restrict glb to certain address
families to limit a glb to a subset of hosts on an internet. Is this
'new feature' a bug fix, perchance? ;-) If anyone else has had this
problem (especially if they've found a permanent fix for it!) I'd be
glad to hear from them....
bob
--------------------------------------------------------------------
bob nutter, computer officer | I'm happy, I'm happy, I'm happy,
UMIST dept of computation | -And I'll punch the man who says
PO box 88 Manchester m60 1qd uk | I'm not.
tel:+44 61 200 3386 |
email:rn@ap.co.umist.ac.uk | -Ivor Cutlerwjw@eba.eb.ele.tue.nl (Willem Jan Withagen) (08/13/90)
In article <1990Aug10.093611.11456@cns.umist.ac.uk> rn@ap.co.umist.ac.uk (bob nutter) writes: The Problem: >somewhere off our local network and on the ethernet backbone. Thus I was >getting totally unknown apollos registered (with various addresses, ip >and dds) as objects such as the glb, registry updates/queries, etc. As >we had *Domain* routing switched off we weren't expecting this. I The solution?: Create the file /etc/ncs/glb_site.txt. It will tell the station where to find its glb-broker. You can even tell it to only use 'dds' so it would not on the Ethernet. Create the file /etc/ncs/glb_obj.txt by uuid_gen > /etc/ncs/glb_obj.txt It tells the uuid of the glb-deamon so only if they match they'll communicate. You've got to do this on all stations using the same glbd. Then reboot all. And it then it should work. It did at least at our site. Success, Willem Jan Withagen Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl Digital Systems Group, Room EH 10.10 BITNET: ELEBWJ@HEITUE5.BITNET P.O. 513 Tel: +31-40-473401 5600 MB Eindhoven The Netherlands Willem Jan Withagen Eindhoven University of Technology DomainName: wjw@eb.ele.tue.nl
dente@els.ee.man.ac.uk (Colin Dente) (08/14/90)
In article <572@eba.eb.ele.tue.nl> wjw@eb.ele.tue.nl writes: >In article <1990Aug10.093611.11456@cns.umist.ac.uk> rn@ap.co.umist.ac.uk (bob nutter) writes: > >The Problem: > >>somewhere off our local network and on the ethernet backbone. Thus I was >>getting totally unknown apollos registered (with various addresses, ip >>and dds) as objects such as the glb, registry updates/queries, etc. As >>we had *Domain* routing switched off we weren't expecting this. I Heh heh heh - sorry Bob, all my fault ;-) (For those not in the know, UMIST is really part of the University of Manchester, they just like to pretend they're nothing to do with us ;-)) > >The solution?: > >Create the file /etc/ncs/glb_site.txt. It will tell the station where to > find its glb-broker. You can even tell it to only use 'dds' so > it would not on the Ethernet. >Create the file /etc/ncs/glb_obj.txt by > uuid_gen > /etc/ncs/glb_obj.txt > It tells the uuid of the glb-deamon so only if they match they'll > communicate. >You've got to do this on all stations using the same glbd. Then reboot all. >And it then it should work. It did at least at our site. Just one caveat(sp?) to this (I haven't done this yet, but I'm about to...) When Willem says you must do the above on all machines, *don't* do a separate uuid_gen on each machine, or every machine will get a different uuid (Universal Unique ID), and nothing will work. Rather, you should do the uuid_gen once, and copy the result to each machine. I had come to the conclusion myself that this was the way to go about this, but would someone from the passwd/etc. (or whatever it's called) group like to comment (Joe Pato, can you hear me?). Colin -- Colin Dente | JANET: dente@uk.ac.man.ee.els Manchester Computing Centre | ARPA: dente@els.ee.man.ac.uk University of Manchester, UK | UUCP: ...!ukc!man.ee.els!dente ... I am the one you warned me of ...
rn@ap.co.umist.ac.uk (bob nutter) (08/15/90)
Yeah, I realised that the glb_obj.txt file might sort the problem out, but surely this is for sr10.2, and we're still running 10.1 (we're happy with it's bugs and don't want any more for the moment...). Can I install the sr10.2 NCS s/w on 10.1 nodes and will it work??? Anyone tried this? bob (pretending that the University of Manchester doesn't exist... ;->) --------------------------------------------------------------------------- bob nutter, computer officer | UMIST dept of computation | "It's a turnip with a pencil stuck in po box 88 manchester m60 1qd uk | it. BRILLIANT!" tel:+44 61 200 3386 | -Vic Reeves email:rn@ap.co.umist.ac.uk |