Bug 509251

Summary: Canned /etc/proftpd.conf contains certain commands in "server config" instead of <Global> context
Product: [Fedora] Fedora Reporter: Philip Prindeville <philipp>
Component: proftpdAssignee: Paul Howarth <paul>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: low Docs Contact:
Priority: low    
Version: 10CC: matthias, tj
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: 1.3.2a-5.fc10 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-24 05:25:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Proposed new version of proftpd.conf none

Description Philip Prindeville 2009-07-01 20:59:33 UTC 
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.
Comment 1 Paul Howarth 2009-07-07 12:57:01 UTC 
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?
Comment 2 Philip Prindeville 2009-07-07 20:21:56 UTC 
(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?
Comment 3 Philip Prindeville 2009-07-07 20:28:04 UTC 
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
Comment 4 Philip Prindeville 2009-07-07 20:37:02 UTC 
(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.
Comment 5 Paul Howarth 2009-07-07 20:50:42 UTC 
(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.
Comment 6 Philip Prindeville 2009-07-07 21:46:33 UTC 
> (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.
Comment 7 Bug Zapper 2009-07-15 08:20:30 UTC 
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.
Comment 8 Paul Howarth 2009-07-15 09:12:26 UTC 
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.
Comment 9 Fedora Update System 2009-08-03 15:32:36 UTC 
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
Comment 10 Fedora Update System 2009-08-05 00:32:48 UTC 
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
Comment 11 Fedora Update System 2009-08-19 22:50:36 UTC 
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
Comment 12 Fedora Update System 2009-08-22 01:06:13 UTC 
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
Comment 13 Fedora Update System 2009-09-02 11:11:57 UTC 
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
Comment 14 Fedora Update System 2009-09-03 00:32:45 UTC 
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
Comment 15 Fedora Update System 2009-09-07 15:08:02 UTC 
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
Comment 16 Philip Prindeville 2009-09-07 16:57:42 UTC 
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.
Comment 17 Fedora Update System 2009-09-09 01:48:35 UTC 
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
Comment 18 Fedora Update System 2009-09-24 05:25:28 UTC 
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.