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.