Subject: tcpwrappers & inetd.conf

From: Steve Devine <[email-masked]>
Date: Wed, 17 Jan 2001 13:03:29 -0500

Hello all, 
I have been trying to implement tcpwrappers and netatalk in order to limit
connections via hosts.allow and hosts.deny. I have seen statements in archives
stating that the inetd.conf file is to be left alone. All seem to advocate an
entry in the services file as such:
afpovertcp      548/tcp
afpovertcp      548/udp
I wonder if netatalk is not called via inetd.conf how is it run? 
A rc script maybe and if so is a reference to tcpd required?
Please if anyone is successfully using tcpwrappers / netatalk I would greatly
hearing how you did it.
I am using tcpwrappers 7.6 netatalk 1.4b2+asun2.1.3 on a Sun Ultra5 / Solaris
2.6
Thanks
///////////////////////////////////
Steve Devine
Information Technology Professional
MSU Computer Laboratory
phone: (517) 355-4500 x242
fax: (517) 353-9847
/////////////////

---

From: andrew morgan <[email-masked]>
Date: Wed, 17 Jan 2001 10:32:46 -0800 (PST)

> I am using tcpwrappers 7.6 netatalk 1.4b2+asun2.1.3 on a Sun Ultra5 / Solaris

You can compile afpd with tcp-wrappers support in it, so it will honor any
directories itself.  You don't need to call it within inetd or tcpd for
this to work.  The service name in your allow/deny files is "afpd".

On most installations, there is an rc script which starts atalkd, afpd,
and papd.

	Andy

---

From: Steve Devine <[email-masked]>
Date: Wed, 17 Jan 2001 14:10:42 -0500

> this to work.  The service name in your allow/deny files is "afpd".
Thanks for your quick response. Am I to leave the entry in services file? This
seems less than usefull without inetd calling afpd. I have compiled netatalk
with tcp wrappers support .. in the Makefile there is this reference to 
tcpwrappers :
# Location of the tcp wrapper library and include files. Comment this out 
# if you don't want tcp wrapper support. having tcp wrapper support is
# highly recommended.
TCPWRAPDIR=/usr/local/tcp_wrappers
I assume this to mean the directory that contains the source code.  I have
tried this sixteen ways to sunday an I have yet to be able to control access
via hosts.allow
BTW:
 netatalk seems happy to compile regardless of what I put under the tcpwrapdir=

--

---

From: andrew morgan <[email-masked]>
Date: Wed, 17 Jan 2001 12:46:44 -0800 (PST)

>  netatalk seems happy to compile regardless of what I put under the tcpwrapdir=

You should leave the entries in /etc/services, although I'm not sure what
they are used for.  You can check to see if afpd is linked against the
tcp-wrappers libraries by typing "ldd afpd".  Check that it says "libwrap"
in the list.

	Andy

---

From: Basil Hussain <[email-masked]>
Date: Thu, 18 Jan 2001 15:48:07 +0000

> tcp-wrappers libraries by typing "ldd afpd".  Check that it says "libwrap"

I like to make a request to whoever maintains the RPM versions of Netatalk
on Sourceforge (sorry, forgot who you are). The RPM version of Netatalk I'm
running (netatalk-1.4.99-0.20001108mdk) isn't linked against tcp-wrappers:

# ldd /usr/sbin/afpd
        libcrypto.so.0 => /usr/lib/libcrypto.so.0 (0x40018000)
        libresolv.so.2 => /lib/libresolv.so.2 (0x400d6000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x400e5000)
        libdl.so.2 => /lib/libdl.so.2 (0x400fb000)
        libdb.so.3 => /lib/libdb.so.3 (0x40100000)
        libcrypt.so.1 => /lib/libcrypt.so.1 (0x4013a000)
        libcrack.so.2 => /usr/lib/libcrack.so.2 (0x40168000)
        libpam.so.0 => /lib/libpam.so.0 (0x40173000)
        libc.so.6 => /lib/libc.so.6 (0x4017b000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

It would be really nice if it was the case, as it would add extra
piece-of-mind to people like me who have internet-facing Netatalk servers,
so that we can restrict access by IP, etc.

BTW, if the new 1.5pre version is linked against tcp-wrappers, then my
apologies... :)

Regards,

------------------------------------------------
Basil Hussain ([email-masked])

---

From: jeff <[email-masked]>
Date: Thu, 18 Jan 2001 11:58:40 -0500

> so that we can restrict access by IP, etc.

It is linked against tcp_wrappers ... statically. I don't have a
libwrap.so to link it against, so I have been sticking to the static
library.

jeff