> At 06:39 20/10/2000 -0400, you wrote:
> >On Fri, 20 Oct 2000 thomas.hoelsken@xxxxxx wrote:
> >
> > > The FTP-service is working, but the firtst connect takes nearly a minute.
> >
> >are you running ftpd under tcp wrappers? your inetd.conf will be something
> >like
> >
> >ftp stream tcp nowait root /usr/sbin/tcpd wu.ftpd
> >
> >if so, you are having troubles with identd (lookup the HOWTO).
> >change the line to
> >
> >ftp stream tcp nowait root /usr/sbin/wu.ftpd wu.ftpd
>
> Alternatively you can tweak your hosts.allow, and you hosts file to allow
> access.
> make sure that the relevant machines in the cluster have local IP entries
> in you /etc/hosts file, and are allowed in /etc/hosts.allow
This is the preferred route from a security standpoint. For testing,
dropping the TCP wrappers may be fine, but before going live for
production, you probably want to enable the wrappers; this is particularly
true if you don't want the whole world to connect to your servers, or
you want to keep specific IPs out of your servers, but there are benefits
even if you let the whole world in, such as logging of every connection.
> The problem that I had was the inability to resolve host names for machines
> within a NAT cluster because of their local only IP address. The minute
> timeout is a "typical" name lookup timeout.
Yes, the local non-routed non-DNS names can cause delays. I am seeing
a lot of that at a current client, a huge company (with lots of internal
systems that are apparently not in DNS anywhere).
> I don't know if this is entirely relevant.... I lost the previous setup
> description e-mails. But I do know that disabling tcp wrappers is not
> necessarily the right solution as it will disable logging and allowed IP
> security checks. I have a NAT cluster running FTP and telnet and ssh, all
> tcp wrappered with no access delays / problems.
This is absolutely correct (in my humble opinion). I have setup and
maintained hundreds of production systems with the TCP wrappers enabled
over the last five years, with a minimum of trouble.
--
John Cronin
|