[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: nightmare: apt slink->potato using cds




Allright, I've gotten rid of ip* from the cron.* directories.
So presumably firewall stuff is not why named is failing
(unless the current version depends on it? who knows)

On Sun, Nov 19, 2000 at 12:25:18PM -0500, Brenda J. Butler wrote:

> 3)  named doesn't seem to resolve even the localhost's
> name any more.  Maybe that's related to the ipchains.
> $ nslookup seal
> *** Can't find server name for address 127.0.0.1: No
>      response from server
> (finds a server at my isp, who not surprisingly doesn't
> know about my own hosts name (i'm in the middle of
> downloading mail as I write this))
> 
> $ ps ax | grep named
> (doesn't find any named process - and I didn't kill any
> either)
> And there _is_ an /etc/rc2.d entry of S19bind
> 
> I just don't get it.

Ok, named was failing to start because I had moved /etc/bind
to /etc/bind.comment.  Why does named use bind conf files,
when it has its own conf files (with largely the same info)
in /etc/named.conf and /var/named?

And now that named _is_ running (I've moved the /etc/bind.comment
back to /etc/bind), it still fails to resolve even the local host
name (in this example, I'm _not_ dialed in to my isp):

# nslookup seal
Server:  localhost
Address:  127.0.0.1

*** localhost can't find seal: No response from server
# ps ax | grep named
  142 ?       S      0:00 /usr/sbin/named
.... other named entries such as the grep, man, and info
# 

=============== contents of resolv.conf: ==================

nameserver 127.0.0.1
search stuffedanimals
nameserver 209.151.0.10
nameserver 209.151.0.12

=============== contents of /etc/named.conf: ==============

// generated by named-bootconf.pl

options {
	directory "/var/named";
	/*
	 * If there is a firewall between you and nameservers you want
	 * to talk to, you might need to uncomment the query-source
	 * directive below.  Previous versions of BIND always asked
	 * questions using port 53, but BIND 8.1 uses an unprivileged
	 * port by default.
	 */
	// query-source address * port 53;
};

// 
// Boot file for name server
// 
// type		domain			source		file
zone "." {
	type hint;
	file "named.root";
};

// Zone boot information and daemon options are kept in other files
// (autoincluded from boot.zones)
// 
// Name server zone boot file
// See named(8) for syntax and further information
// 
// type		domain			source		file
// (autoincluded from boot.options)
// 
// Options for name server
// Use `bindconfig' to automatically configure this file
// 
// type		domain			source		file
zone "localhost" {
	type master;
	file "named.local";
};

zone "127.in-addr.arpa" {
	type master;
	file "named.rev-local";
};

// Custom configurations below (will be preserved)
=============== contents of /etc/host.conf: ==============
order hosts,bind
multi on
=============== contents of /etc/hosts: ==============
127.0.0.1	localhost
192.168.110.5	seal.stuffedanimals seal       # sun sparc station 20
# ...some other machines, all on 192.168.110

# The following lines are desirable for IPv6 capable hosts
# (added automatically by netbase upgrade)

::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts
===========================================================

And why won't named dump its cache to /var/tmp/named_dump.db
when I send it the INT signal, as the man page says it should?
Where is the _PATH_DUMPFILE variable supposed to be defined?
In the environment?  I don't have any _PATH_DUMPFILE in
my environment.  And when I put one there and signal the
named, it still doesn't work:
# export _PATH_DUMPFILE=/var/tmp
# kill -HUP 142
# ls /var/tmp
vi.recover

> 4) xdm won't let me log in (neither root nor me)
> I imagine this problem will go away when I get the above

Hmm, upon reflection, perhaps xdm still won't work.  It
was complaining about permission problems in /var/log/xdm.log,
and I suppose it wouldn't be logging those if ipchains was
preventing it from receiving anything.

argh.  Well, first to fix the named problem, then the
xdm after.  To fix the xdm problem, I suppose I'll have
to learn all about xauth/xdm interaction.

-- 
bjb@achilles.net
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--



Reply to: