ellis@rata.vuw.ac.nz (Brian Ellis) (11/06/90)
I have just upgraded a DECSystem 5400 from Ultrix 3.1D to Ultrix 4.0. We were running bind 4.8.3 under Ultrix 3.1D. Using these configuration files with the named supplied with Ultrix 4.0 does not seem to work. The daemon dies and vanishes, leaving these messages in /var/spool/mqueue/syslog: Nov 6 21:18:40 localhost: 1218 named: restarted Nov 6 21:18:41 localhost: 1218 named: address of primary server not in local db: Running named with -d 9 (debugging level of 9) didn't produce any more information. There appears to be a little confusion over where the default name server configuration boot file is to be found. named(8) claims that this is /etc/named.boot, the printed manual pages indicate that it is /var/dss/namedb/named.boot. I put a sym-link in from one to the other just in case Murphy was looking over my shoulder. Is anyone out there successfully using the named supplied with Ultrix 4.0??? Brian Ellis Computing Services Centre Domain: ellis@rata.vuw.ac.nz Victoria University of Wellington Bang paths... grrrr!!!!! P.O Box 600, New Zealand. What! - no cute .sig ???
chris@wuarchive.wustl.edu (Chris Myers) (11/07/90)
ellis@rata.vuw.ac.nz (Brian Ellis) writes: >[...] The >daemon dies and vanishes, leaving these messages in /var/spool/mqueue/syslog: > >Nov 6 21:18:40 localhost: 1218 named: restarted >Nov 6 21:18:41 localhost: 1218 named: address of primary server not in >local db: > >[...] There MUST be an entry in /etc/hosts (yes, /etc/hosts!) for each and every of the nameservers listed as primary nameservers for a domain. In other words, for a line that reads: secondary foo.com a.b.c.d e.f.g.h i.j.k.l you need in /etc/hosts a.b.c.d nameserver1.foo.com e.f.g.h nameserver2.foo.com i.j.k.l nameserver3.foo.com This should solve your problem... -- Chris Myers Internet: chris@wugate.wustl.edu Software Engineer UUCP: ...!uunet!wuarchive!chris Office of the Network Coordinator BITNET: chris@wunet.bitnet Washington University in Saint Louis Phone: +1 314 726 7390
mf@ircam.ircam.fr (Michel Fingerhut) (11/11/90)
BIND info *is* in /var/dss/namedb/named.boot.
1. Did you set the /etc/resolv.conf file to contain the info it needs?
(at least a domain name entry, and one "nameserver 127.0.0.1" entry)
2. Did you correctly fill the /etc/svc.conf file?
We have named running. Once in a week or so it goes into an infinite loop
and grows the syslog file to fill its file system, but it otherwise works
like a charm (well, all other things being equal).ellis@rata.vuw.ac.nz (Brian Ellis) (11/12/90)
In article <1990Nov10.215525.11745@ircam.ircam.fr>, mf@ircam.ircam.fr (Michel Fingerhut) writes: |> BIND info *is* in /var/dss/namedb/named.boot. |> |> 1. Did you set the /etc/resolv.conf file to contain the info it needs? |> (at least a domain name entry, and one "nameserver 127.0.0.1" entry) |> |> 2. Did you correctly fill the /etc/svc.conf file? |> |> We have named running. Once in a week or so it goes into an infinite loop |> and grows the syslog file to fill its file system, but it otherwise works |> like a charm (well, all other things being equal). Hmm, One suggestion from the net worked. The solution to my problems was to add an entry for *all* the machines that rata (the machine in question) is a secondary name server for to /etc/hosts. I had to change nothing else. What really brassed me off about this matter is the named in the 4.0 distribution appears to be bind 4.8.1 or later, and bind 4.8.1 *doesn't* require the entries in /etc/hosts that the DEC supplied bind does! If named is not the same as 4.8.1, then thats fine - but it sure looks like 4.8.1 Adding value and functionality is fine - breaking it is not! Brian. Brian Ellis Computing Services Centre Domain: ellis@rata.vuw.ac.nz Victoria University of Wellington Bang paths... grrrr!!!!! P.O Box 600, New Zealand. What! - no cute .sig ???