[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Problem with ftp.skytouch.com
- To: "Erik C. Thauvin" <erik@skytouch.com>
- Subject: Re: Problem with ftp.skytouch.com
- From: Robert Dinse <nanook@eskimo.com>
- Date: Sat, 10 Mar 2001 12:58:04 -0800 (PST)
- cc: rrohan@eskimo.com, outages-list@eskimo.com
- In-Reply-To: <003401c0a95f$67e6f370$f4cee23f@pavilion>
- Resent-Date: Sat, 10 Mar 2001 12:58:19 -0800
- Resent-From: outages-list@eskimo.com
- Resent-Message-ID: <"aX5Ef2.0.xy5.gLfgw"@mx1>
- Resent-Sender: outages-list-request@eskimo.com
On Sat, 10 Mar 2001, Erik C. Thauvin wrote:
>
> Bob:
>
> Anonymous ftp login to ftp.skytouch.com no longer points to the proper
> directory (/u/s/skytouch); users are dumped into the root directory instead.
>
> Could you please fix this problem ASAP? I'm getting complains form people
> who are unable to access ftp links from various web sites.
>
> Thanks,
>
> E.
It's fixed, but it's one of those big mysteries and I don't understand why
it did what it did. A semi-technical explanation follows...
Some background, ftpd is launched by inetd when someone attaches to the
ftp port. It was previously (and is now again) going through TCP Wrappers,
not so much to limit access but just to log where connections are coming from.
I had compiled wrappers with the -DPARANOID option and added ALL@PARANOID
to the hosts.allow, in addition to ALL@ALL, to allow users with mismatching DNS
to connect because incompetent ISP's that can't get DNS right seem to be more
common than not.
This did allow users with inconsistant DNS to connect as long as their IP
had SOME inverse DNS, but if it had none at all they were still refused.
Unfortunately, some of my customers are using @home cable modems and some have
no inverse DNS on the IP's they are assigning. It used to be I'd see @home
customers assigned out of a 64.x.x.x block, but now I am seeing 216.x.x.x, and
it seems to be these latter IP's that are missing DNS.
So to try to at least temporarily fix this I bypassed wrappers altogether,
had inetd launch ftpd. What I did not realize was that doing this for some
reason broke virtual domains. I have absolutely no idea why. It works when
launched indirectly via tcpd, but it does not work when launched directly out
of inetd.
I added ALL@UNKNOWN to the hosts.allow and put it back through inetd, this
made the virtual domains work again and IP's with no DNS seem to be able to
connect this way.
A couple of things that are complete mysteries to me:
1) Why ftpd handles the virtual domains OK if launched indirectly
via tcpd, but not if launched directly out of inetd.
2) Why ALL@UNKNOWN in addition to ALL@ALL and ALL@PARANOID was required
allow sites with no inverse DNS to connect.
So it's working again but I am uncomfortable with not understanding the
above two issues. Very strange.