Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1361476 - Race condition when using conf.d/perl.conf
Summary: Race condition when using conf.d/perl.conf
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: httpd
Version: 6.8
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: rc
: ---
Assignee: Web Stack Team
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-29 06:56 UTC by David Cook
Modified: 2016-08-08 00:46 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-08-07 15:25:45 UTC


Attachments (Terms of Use)

Description David Cook 2016-07-29 06:56:43 UTC
Description of problem: 

httpd only uses conf.d to include additional Apache configuration files, which means that the mod_perl owned file conf.d/perl.conf is not very useful for running "LoadModule perl_module modules/mod_perl.so".

I noticed that <Perl> sections weren't being run in my app.conf file, and PerlSetEnv values weren't appearing in my PerlPostConfigRequire startup script. It seems to be that the mod_perl directives were being ignored, because mod_perl.so hadn't been loaded yet. 

httpd's "Include" loads files alphabetically, so my app.conf was loaded before perl.conf. The solution was to add the following block to my app.conf:

<IfModule !perl_module>
  LoadModule perl_module modules/mod_perl.so
</IfModule>

However, when perl.conf was loaded, I'd get a warning in error_log saying that the module was already loaded (since app.conf had loaded it with the above block). 

So perl.conf isn't very useful in itself as it's loaded at the same time as .conf files containing virtual hosts and other directives. 

It's probably fine if your filename comes alphabetically after perl.conf but it's no good if it's before.

Other Linux distros (such as SLES) solve this by including .conf files for loading modules and setting other configuration before conf.d (e.g. /etc/apache2/sysconfig.d/loadmodule.conf) in httpd.conf. That means that your mod_perl.so module is loaded far before you start defining things like virtual hosts.

Of course, that requires a change to the httpd package layout, but I'm raising the report for the mod_perl package, since it's the one creating the problematic perl.conf file. 

Version-Release number of selected component (if applicable): 

2.0.4


How reproducible: 

Always


Steps to Reproduce:
1. Install "httpd" and "mod_perl"
2. Create "app.conf" which contains a virtual host for *:80 containing the following:
<Perl>
  $ENV{environmental_variable} = "test";
</Perl>
<Location /perl-status>
    SetHandler perl-script
    PerlResponseHandler Apache2::Status
    Order deny,allow
    Deny from all
    Allow from .example.com
</Location>
3. Go to localhost/perl-status

Actual results:

You won't see "environmental_variable" in the output. 

Expected results:

You would see "environmental_variable" in the output.


Additional info:

A hacky solution would be to install the file as _perl.conf instead of perl.conf, so that it sorts higher alphabetically, but there's still the chance that you'd have a virtual host at _app.conf which would require mod_perl but be loaded before _perl.conf.

A better solution would be to change the httpd layout and httpd.conf configuration to include sysconfig or something like that before conf.d, and then have perl.conf in that sysconfig directory.

I suppose the traditional method might be editing and maintaining conf/httpd.conf, but that seems archaic in this day and age. Packages should be able to add configuration files that load top level directives before virtual hosts are processed. Also, even though you could use Ansible to manage conf/httpd.conf, you'd run the risk of there being changes to conf/httpd.conf upstream and then having to manage the differences when doing a yum update.

Comment 1 Petr Pisar 2016-07-29 07:09:38 UTC
This issue is not specific to mod_perl and it would require changing in httpd configuration layout as you correctly pointed out. Therefore I move request to httpd component. However because that would be incompatible change, I don't believe this will be ever implemented in RHEL 6 that is in its late life cycle now. I recommend you to rename your app.conf file to get loaded after perl.conf.

Comment 3 David Cook 2016-07-29 07:26:25 UTC
Thanks for the quick reply, Petr!

That's a good point about changing it from mod_perl to httpd. I suppose RHEL 6 is pretty late in its life cycle as well. I don't know if they've changed it in RHEL 7 or not either...

In this case, it was sufficient to add the following at the top of app.conf:

<IfModule !perl_module>
  LoadModule perl_module modules/mod_perl.so
</IfModule>

Perhaps a change to make to perl.conf would be to put it in the IfModule conditional as well so it doesn't try loading the module again, but yeah... I figured there wouldn't be an upstream fix for this one in RHEL 6. I thought it was worth reporting in any case though.

Comment 4 Joe Orton 2016-08-07 15:25:45 UTC
Sorry, this is basically unfixable in RHEL6 as Petr suggests. 

We fixed this in RHEL7 by moving all LoadModule usage to /etc/httpd/conf.modules.d/*.conf, which is processed very early by httpd.conf, and conf.d/*.conf are loaded later.

Comment 5 David Cook 2016-08-08 00:46:43 UTC
(In reply to Joe Orton from comment #4)
> Sorry, this is basically unfixable in RHEL6 as Petr suggests. 
> 
> We fixed this in RHEL7 by moving all LoadModule usage to
> /etc/httpd/conf.modules.d/*.conf, which is processed very early by
> httpd.conf, and conf.d/*.conf are loaded later.

Thanks for your response, Joe. I've worked around it in RHEL6, but I'm glad to hear it's been fixed in RHEL7.


Note You need to log in before you can comment on or make changes to this bug.