I think I have a few things to bring up concerning
sshd, tinydns, resolv.conf, and nsswitch.conf
I'll try to keep it concise :-)
But there are things that cause issues.
Things that could be covered in the docs.
Does anybody's dns work as well as they think it should?
A quick way to check is to login to the LEAF box and run
this command on it:
netstat -a
Any pause at all is an indication that your dns is not
resolving as it should.
So here we go:
================
I rebooted my LEAF box 17 days ago, and haven't saved any
changes since January.
Today, while trying to ssh into my LEAF box from my internal
NAT'd lan, I got the dreaded 1-2 minute delays before logging in.
Why? Nothing had changed since January, as I mentioned.
Was tinydns stuck? Full? Crashed? How about dnscache?
None of the above. I restarted both and got the same problem.
I rebooted because I needed coffee, and I felt st00pid. That
made no difference. It wasn't a lack of memory or ramdisk space.
I'll get to the point. I think I must have made a change
that I didn't back up. It's possible that I haven't ssh'd
into the LEAF in 17 days, also. Making the correct changes
in my /etc fixed things.
Here are the problems I want to address:
=========================================
1) When people run sshd, it tries to do reverse name lookups
on the ip address of the client. JN mentions this in his
sshd faq.
2) His faq suggests adding the private lan IP that's failing
lookups into /etc/hosts. That caused me more confusion.
3) I run tinydns and dnscache. Those need to be able to handle
the sshd resolutions correctly. They didn't. Both resolv.conf
and the tinydns-private/root/data files needed to be adjusted.
4) But the tinydns docs don't mention how to set /etc/resolv.conf
on the LEAF box. I wish they would. It's possible that someone
will run tinydns by itself (if they lack ram for dnscache). In
that case, they need to know how to set up resolv.conf. To reach
only tinydns, the resolv.conf would be this:
nameserver 127.0.0.1
search somedomain.net
5) The dnscache docs also fail to explain setting up resolv.conf.
It's not clear whether the nameserver should be 127.0.0.1 or
192.168.1.254. The confusion arises, because the IP's that
tinydns and dnscache uses are reversed from those used in the djbdns
FAQs. Once the admin realizes that the dnscache runs on 192.168.1.254,
then they realize that resolv.conf would look like this:
nameserver 192.168.1.254
search somedomain.net
6) JN's tinydns screenshot that shows what /etc/tinydns-private/root/data
looks like,
http://leaf.sourceforge.net/devel/jnilo/tinydns3.html#AEN454
has problems. I'm not sure if it's meant to be a working example, but
I don't think it works. Here's why:
* It only diagrams A (address, alias) records, not both
A and PTR records for each LAN comp. The LAN comps
need to be listed as:
=xena.schalit.net:10.2.2.2
=luke.schalit.net:10.2.2.3
or similar. A computer listed in a DNS zone needs both A
and PTR records.
* There's no listing for localhost in tinydns's data.
=localhost:127.0.0.1
That's also not shown in any djbdns docs. It's possible this
is unnecessary, but the result is this: If someone uses this
nameserver 127.0.0.1
in resolv.conf then lookups come directly from tinydns, bypassing
dnscache, and in that scenario, localhost doesn't resolve. It
ends up coming out of /etc/hosts. Prove it to yourself using
netstat -a
as I suggested previously. The 30 sec delay is the proof as far
as I've deduced.
7) It's not necessary to have localhost listed in tinydns if you use dnscache,
though, because dnscache handles the localhost A and PTR lookups internally.
So by using dnscache, we coverup this localhost problem, but at least it
works.
I'm going to take this up on the djbdns mailing list.
8) /etc/hosts gets in the way if you run dnscache and tinydns. It covers
up a misconfigured dns. I see no need for it besides the
127.0.0.1 localhost
entry that's historical and perhaps an entry for your static external IP name,
if any, i.e.:
63.194.213.179 adsl-63-194-213-179.sfnc21.pacbell.net
Well that's about it. Adding = records in the data file and fixing
/etc/resolv.conf to point to the internal nic ip that dnscache is bound
to were the fixes.
Sorry about the long post. I know those can be a pain sometimes.
Matthew
_______________________________________________
Leaf-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-devel
