Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!samsung!uunet!mcsun!ukc!mucs!cns!ran From: ran@cns.umist.ac.uk (Bob Nutter) Newsgroups: comp.sys.apollo Subject: Re: named and /lib/libresolv Summary: possible suggestions... Message-ID: <1990Mar26.162834.286@cns.umist.ac.uk> Date: 26 Mar 90 16:28:34 GMT References: <1990Mar22.212921.17536@terminator.cc.umich.edu> Sender: bob nutter, b.nutter@umist.ac.uk Organization: UMIST, Manchester, England. Lines: 61 Hi! (I'm new to this news game, and news.announce.newusers isn't available, so bear with me if I mess up or break some golden rule of etty-kitty) In article <1990Mar22.212921.17536@terminator.cc.umich.edu> rees@citi.umich.edu (Jim Rees) writes: > >In article , gjalt@ele.tue.nl (Gjalt de >Jong) writes: >> >> We are running the name server (/etc/named) now on our apollos (SR10.2). But >> now not all the programs which should use the name server, use it. >> > > ...deleted > >I wanted to set up a local named to cache names in the local domain, so that >if the remote named goes down I can still get around. I read the named man >page many times and tried lots of things but can't get it to work. Here is >the /etc/named.boot that I think should do it (addresses have been changed >to protect the innocent; x and y are real numbers): > >secondary ifs.umich.edu 35.1.37.x 35.1.128.y /etc/named.cc1 >forwarders 35.1.37.x 35.1.128.y > >Has anyone got this to work? -try taking the forwarders line out and using a cache. I'm certainly no expert at this, but I'm told this might cause it not to work as expected. The manual says you should always use a cache for a standard server. -another idea is to get hold of the source for named. We had to do this as we're running sr10.1 and the named there is about version 4.5 rather than the 4.8 you can get the source for (getting a new routed helped us enormously as well, but I don't know how bad it is at 10.2). We got the source from Imperial College London (ic.doc.src.ac.uk) over ftp (username guest, password your_mail_id) in "unix/bsd-sources/src/bind-4.8.tar.Z",but it *must* be available in the States somewhere. This has quite a bit of useful documentation (RFC's etc). -a problem with /etc/resolv.conf is that it is only read when the node boots up. (certainly at 10.1). The resolver(3) is initialised when the global inlibs are initialised, ie: at boot time. This is obvioulsy an apollo mod. The manual pages refer to the normal behaviour. If you *really* want a way round this, get hold of the source and turn the resolver into a new global inlib (which we're currently trying to do!) You can then get any behaviour you want! ;-) Good luck, you'll probably need it! bob --------------------------------------------------------------- bob nutter, computer officer Notice: The witty message dept. of computation UMIST is on holiday PO Box 88 Manchester M60 1QD UK tel: +44/0 61 200 3312 email: b.nutter@umist.ac.uk (pref) rn@ap.co.umist.ac.uk ran@cns.umist.ac.uk #include