[CentOS] Re: Re: Re: Re: What libs req'd to resolve DNSwithinachrootjail?

Tue Jan 15 03:49:23 UTC 2008
Mike Kercher <mike at vesol.com>

 

> -----Original Message-----
> From: centos-bounces at centos.org 
> [mailto:centos-bounces at centos.org] On Behalf Of Eric B.
> Sent: Monday, January 14, 2008 8:45 PM
> To: centos at centos.org
> Subject: [CentOS] Re: Re: Re: Re: What libs req'd to resolve 
> DNSwithinachrootjail?
> 
> 
> "Mike Kercher" <mike at vesol.com> wrote in message 
> news:6115482898C59848B35DB9D491C9A28E08BFA3 at srv1.home.middlefi
nger.net...
> > >> Thanks for the pointer.  Indeed, I was missing the
> > trailing . after
> > >> my FQDN in my revers file.  I have updated my reverse files, and 
> > >> nslookup is resolving better, but still not further ahead.
> > >>
> > >> My reverse file: 3.168.192.in-addr.arpa now contains the
> > following line:
> > >> 103             IN PTR  eric.test.com.
> > >>
> > >>
> > >> If I try nslookups now, my results are as follows:
> > >>
> > >> # nslookup 192.168.3.103
> > >> Server:         192.168.1.67
> > >> Address:        192.168.1.67#53
> > >>
> > >> 103.103.168.192.in-addr.arpa    name = eric.test.com.
> > >>
> > >> # nslookup eric.test.com
> > >> Server:         192.168.1.67
> > >> Address:        192.168.1.67#53
> > >>
> > >> Name:   eric.test.com
> > >> Address: 192.168.3.103
> > >>
> > >>
> > >> So from that, it seems as though the DNS / rDNS are properly 
> > >> configured, does it not?  Similarly, I have both the forward and 
> > >> reverse domain name on the DNS server as the nslookups show.
> > >> However, I still get the same error
> > >> msg:
> > >> Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from
> > >> 192.168.103.103
> > >              AAA
> > > Correct? -----|||
> >
> > Whoops - cut & paste typo.  That line is supposed to read:
> > Jan 14 17:46:50 apollo atftpd[15905]: Connection refused from
> > 192.168.3.103
> >
> 
> > Can you post your complete hosts.allow and hosts.deny files?
> 
> Not much to them actually:
> /chroot/tftpd/etc/hosts.allow:
> #
> # hosts.allow   This file describes the names of the hosts which are
> #               allowed to use the local INET services, as decided
> #               by the '/usr/sbin/tcpd' server.
> #
> in.tftpd : eric.test.com : allow
> 
> /chroot/tftpd/etc/hosts.deny:
> #
> # hosts.deny    This file describes the names of the hosts which are
> #               *not* allowed to use the local INET services, 
> as decided
> #               by the '/usr/sbin/tcpd' server.
> #
> in.tftpd : ALL : deny
> 
> 
> 
> Again, I have concerns that I might be missing something in 
> my chroot jail, but when I change my hosts.allow file to read 
> the following, it works fine.
> in.tftpd: 192.168.3.103 : allow
> 
> So I am utterly and totally confused.  I keep thinking that 
> there must be something DNS related that I need in the chroot 
> jail that I am missing.
> I do have a /chroot/tftpd/etc/resolv.conf with the nameserver 
> entry that points to the DNS server, and all files in my 
> /chroot/tftpd/etc dir are world readable.  I also have a 
> /chroot/tftpd/etc/hosts file (that is pretty much empty - 
> just a line for 127.0.0.1).
> 
> # ls -l /chroot/tftpd/etc
> -rw-r--r--  1 root root   148 Jan 14 17:53 hosts
> -rw-r--r--  1 root root   417 Jan 14 17:37 hosts.allow
> -rw-r--r--  1 root root   370 Jan 13 12:13 hosts.deny
> -rw-r--r--  1 root root  1267 Jan 12 21:43 localtime
> -rw-r--r--  1 root root  1686 Jan 12 15:50 nsswitch.conf
> -rw-r--r--  1 root root    86 Jan 14 17:52 resolv.conf
> -rw-r--r--  1 root root 20373 Jan 12 15:47 services
> 
> 
> Is there anything else I need that I am missing?  Either 
> config file or lib?
> 
> Any suggestions of things I can try?
> 
> Thanks,
> 
> Eric 
> 

Something I found:

15.2.3.2. Access Control

Option fields also allow administrators to explicitly allow or deny
hosts in a single rule by adding the allow or deny directive as the
final option.

For instance, the following two rules allow SSH connections from
client-1.example.com, but deny connections from client-2.example.com:

sshd : client-1.example.com : allow
sshd : client-2.example.com : deny

By allowing access control on a per-rule basis, the option field allows
administrators to consolidate all access rules into a single file:
either hosts.allow or hosts.deny. Some consider this an easier way of
organizing access rules. 

Conceivably, you could put all rules into one file (hosts.allow maybe).
See if that helps..

Mike