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