Description of problem: In installing and running an anonymous FTP server, I noticed that there were delays when connecting to it. Doing some quick digging, I saw that the host had an outbound TCP connection to the auth port in SYN_SENT state (the client I was using to test was being a NATting firewall, so the connections to that port would have been dropped). The configuration contained: IdentLookups off ... but unfortunately, not in the correct section. Version-Release number of selected component (if applicable): 1.3.1-8.fc9.x86_64 How reproducible: As below. Steps to Reproduce: 1. Connect to a server running the default configuration from a client behind a firewall; 2. On the server, do "netstat -t -n | grep :113" 3. Actual results: tcp 0 1 192.168.1.3:51639 63.224.43.239:113 SYN_SENT Expected results: (empty) Additional info: See the link: http://www.proftpd.org/docs/howto/Vhost.html and in particular, the section: Anything inside of a <Global> section is applied to every server configuration in the file, to every <VirtualHost> as well as the default "server config" server. Which brings us to the "server config" context. The name is ill-suited, and is really borrowed directly from Apache's naming conventions. The "server config" context refers to anything not in a <VirtualHost> or <Global> context in the proftpd.conf file. Unlike Apache's httpd.conf, ProFTPD's configuration is designed such that one should be able to use the simplest file as possible. In fact, proftpd will start if the proftpd.conf is completely empty; try it! This will cause the daemon to use all of the default settings, which in most cases is not what is wanted, but it is possible. With this in mind, there is always at least one server configuration present: the default server context, and it is this context that is known as the "server config". Just like the <VirtualHost> context, any configuration directives inside the "server config" context do not apply outside of the context. Many administrators often assume that this is the case. It is not. This is what the <Global> context is for.
Created attachment 350788 [details] Proposed new version of proftpd.conf Here's the proftpd.conf I'm proposing to ship in the next proftpd update. The <IfDefine> bits will be specified in a new file /etc/sysconfig/proftpd. What do you think?
(In reply to comment #1) > Created an attachment (id=350788) [details] > Proposed new version of proftpd.conf > > Here's the proftpd.conf I'm proposing to ship in the next proftpd update. The > <IfDefine> bits will be specified in a new file /etc/sysconfig/proftpd. > > What do you think? Seems reasonable. But don't we need to test for mod_dso.c? Or do we just assume it's always present? <IfModule mod_dso.c> ... all the stuff relying on "LoadModule" directives ... </IfModule> Or, is there a way to cause it to fail if it's been built *without* mod_dso.c?
Also, can we add an <IfDefine ...> around IdentLookups and UseReverseDNS? Some people might want these on... <Global> ... <IfDefine !IDENT_LOOKUPS> IdentLookups off </IfDefine> ... </Global> and something similar (not in the Global section, obviously) for UseReverseDNS... -Philip
(In reply to comment #3) > Also, can we add an <IfDefine ...> around IdentLookups and UseReverseDNS? Some > people might want these on... > > <Global> > ... > <IfDefine !IDENT_LOOKUPS> > IdentLookups off > </IfDefine> > ... > </Global> > > and something similar (not in the Global section, obviously) for > UseReverseDNS... > > -Philip Forgot to mention: the default of "IdentLookups" *was* on prior to 1.3.3rc1. Now it's off. So that creates certain issues for keeping the same config file across upgrades... Unless we spell it out both ways: <IfDefine IDENT_LOOKUPS> IdentLookups on </IfDefine> <IfDefine !IDENT_LOOKUPS> IdentLookups off </IfDefine> bletch.
(In reply to comment #2) > (In reply to comment #1) > > Created an attachment (id=350788) [details] [details] > > Proposed new version of proftpd.conf > > > > Here's the proftpd.conf I'm proposing to ship in the next proftpd update. The > > <IfDefine> bits will be specified in a new file /etc/sysconfig/proftpd. > > > > What do you think? > > Seems reasonable. But don't we need to test for mod_dso.c? Or do we just > assume it's always present? > > <IfModule mod_dso.c> > ... all the stuff relying on "LoadModule" directives ... > </IfModule> > > Or, is there a way to cause it to fail if it's been built *without* mod_dso.c? I don't think we need to test it because the config file comes with the rpm, and the rpm build always includes mod_dso.c. If someone wants to hack the SRPM to remove that, they can always change the config file too. (In reply to comment #3) > Also, can we add an <IfDefine ...> around IdentLookups and UseReverseDNS? Some > people might want these on... > > <Global> > ... > <IfDefine !IDENT_LOOKUPS> > IdentLookups off > </IfDefine> > ... > </Global> > > and something similar (not in the Global section, obviously) for > UseReverseDNS... Well we could, but I'm not too keen on that. My aim with the <IfDefine> sections was to enable/disable significant blocks of configuration rather than one-liners, so as to keep diffs between the stock config and one on an installed system readable, as this helps when it comes to upgrades and people have to merge their config changes with those in a new rpm. So adding <IfDefine> sections for things that would be a 1-line diff isn't really worth it I think. It would also set us off on a slippery slope towards moving more and more config from /etc/proftpd.conf to /etc/sysconfig/proftpd, which I don't think is particularly desirable. I'm open to persuasion though, and I'd like to know what Matthias thinks, since it's his package after all.
> (In reply to comment #3) > > Also, can we add an <IfDefine ...> around IdentLookups and UseReverseDNS? Some > > people might want these on... > > > > <Global> > > ... > > <IfDefine !IDENT_LOOKUPS> > > IdentLookups off > > </IfDefine> > > ... > > </Global> > > > > and something similar (not in the Global section, obviously) for > > UseReverseDNS... > > Well we could, but I'm not too keen on that. My aim with the <IfDefine> > sections was to enable/disable significant blocks of configuration rather than > one-liners, so as to keep diffs between the stock config and one on an > installed system readable, as this helps when it comes to upgrades and people > have to merge their config changes with those in a new rpm. So adding > <IfDefine> sections for things that would be a 1-line diff isn't really worth > it I think. It would also set us off on a slippery slope towards moving more > and more config from /etc/proftpd.conf to /etc/sysconfig/proftpd, which I don't > think is particularly desirable. > > I'm open to persuasion though, and I'd like to know what Matthias thinks, since > it's his package after all. That's a reasonable argument, I guess. Of course, dumping everything into /etc/sysconfig/proftpd *does* resolve the issue of having to reconcile /etc/proftpd.conf.rpmnew stuff... but once we get the config file reasonably stable so that new releases don't require a new config (hopefully all new features will have reasonable defaults) then that problem should go away.
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.
Same issue applies in all releases, so bumping release to F-10 and re-opening. I'm awaiting feedback from Matthias on my proposed changes at the moment.
proftpd-1.3.2a-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-2.fc10
proftpd-1.3.2a-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8267
proftpd-1.3.2a-3.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-3.fc10
proftpd-1.3.2a-3.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-8875
proftpd-1.3.2a-4.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-4.fc10
proftpd-1.3.2a-4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9249
proftpd-1.3.2a-5.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/proftpd-1.3.2a-5.fc10
Finally got around to installing it. Couple of suggestions: /etc/proftpd.conf should contain explicit "ServerType standalone" and "MaxLoginAttempts 2" to call out the defaults. /etc/sysconfig/proftpd should contain a comment that the values for PROFTPD_OPTIONS must explicitly be given as "server_args = ..." in /etc/xinetd.d/xproftpd if run in inetd-mode. Maybe replicate that same comment in /etc/xinetd.d/xproftpd as well.
proftpd-1.3.2a-5.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update proftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-9386
proftpd-1.3.2a-5.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.