Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deletes /etc/httpd/conf.d/passenger.conf when including apache::mod::passenger on Centos 6 #119

Closed
Spenser309 opened this issue Nov 15, 2012 · 13 comments

Comments

@Spenser309
Copy link

By default Centos 6, there is file named passenger.conf created in the /etc/httpd/conf.d/ directory. This sets the value of PassengerRoot and PassengerRuby for all configurations. When a vhost is instantiated this file is removed from the directory.

@hunner
Copy link
Contributor

hunner commented Nov 16, 2012

Ah, then the apache::mod::passenger class should provide a configuration file template similar to https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/mod/php.pp

Have you checked this on CentOS 5? Debian?

@hunner
Copy link
Contributor

hunner commented Nov 16, 2012

Also, probably related: #115, #116

@Spenser309
Copy link
Author

From what I remember. Debian would use the
/etc/apache2/mods-available/passenger.conf file and CentOS 5 does not
include a passenger package although a gem install would stick the file in
the same spot.

The solution you posted isn't ideal. If the passenger package is updated the the location of PassengerRoot changes. Thus an upgrade could cause passenger to fail. This file should only exist not be templated or else we risk causing upgrades to fail.

What are your thoughts?

Spenser

On Fri, Nov 16, 2012 at 2:01 PM, Hunter Haugen [email protected]:

Ah, then the apache::mod::passenger class should provide a configuration
file template similar to
https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/mod/php.pp

Have you checked this on CentOS 5? Debian?


Reply to this email directly or view it on GitHubhttps://github.com//issues/119#issuecomment-10460031.

Spenser Gilliland
Computer Engineer
Doctoral Candidate

@Spenser309
Copy link
Author

Please see the following commit.

Spenser309@6bc70da

Do you think this is a good way of doing it? The gemroot/rubyroot could even be overrideable to allow for from source installs.

@antaflos
Copy link
Contributor

Am I understanding this right, in CentOS/RHEL the same directory, ${apache::params::vdir}, is used for virtual host configurations and module configurations? And because passenger.conf gets installed by a native package into that directory this module deletes it, since it purges all files it does not manage in there?

Anyway, your idea is not going to work on Debian/Ubuntu. First of all, on Debian/Ubuntu, ${apache::params::vdir} should only be used for virtual host configurations. Module configurations are supposed to go in /etc/apache2/mods-available/<modname>.conf and enabled via symlink from /etc/apache2/mods-enabled. But this is a larger issue that this module should probably deal with.

Second, /usr/share/rubygems does not exist in Debian/Ubuntu. What does it contain on CentOS/RHEL?

Third, why use a horrible exec to do cat <<EOF > ...? Why not a template, like https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/mod/php.pp (which is also not great, see issues #114, #115 and #116)?

At the very least your proposed changes should be limited to $::osfamily == 'redhat'.

In Debian/Ubuntu when using either the regular packages or the ones from https://www.phusionpassenger.com/native_packages a working passenger configuration is put in /etc/apache2/mods-available/passenger.conf (and a2enmod-activated by the package's postinst script) so the apache::mod::passenger class doesn't deal with this. Maybe it should, but that will result in conflicts between configuration files provided by this module and the package-provided configuration files. Again, I think this is a larger issue.

@Spenser309
Copy link
Author

Am I understanding this right, in CentOS/RHEL the same directory,

${apache::params::vdir}, is used for virtual host configurations and
module configurations? And because passenger.conf gets installed by a
native package into that directory this module deletes it, since it purges
all files it does not manage in there?

Yes, and yes.

Anyway, your idea is not going to work on Debian/Ubuntu. First of all, on
Debian/Ubuntu, ${apache::params::vdir} should only be used for virtual
host configurations. Module configurations are supposed to go in
/etc/apache2/mods-available/.conf and enabled via symlink from
/etc/apache2/mods-enabled. But this is a larger issue that this module
should probably deal with.

Maybe the purge of ${apache::params::vdir} should not occur on RHEL
systems?

Second, /usr/share/rubygems does not exist in Debian/Ubuntu. What does it
contain on CentOS/RHEL?

I believe this dir contains all gems installed from rubygem-* rpm packages.

Third, why use a horrible exec to do cat < ...? Why not a template,
like
https://github.com/puppetlabs/puppetlabs-apache/blob/master/manifests/mod/php.pp(which is also not great, see issues
#114 #114, #115https://github.com/puppetlabs/puppetlabs-apache/issues/115and
#116 #116)?

I have to run a lookup of which is the newest version of passenger (by
searching for the highest version number of passenger in
/usr/share/rubygems/.) To do this using a template would require adding a
fact that returns the newest version of passenger. Maybe a cleaner
solution but also requires pluginsync.

At the very least your proposed changes should be limited to $::osfamily
== 'redhat'.

Yes. Forgot that I'll add it if this is the direction to go.

In Debian/Ubuntu when using either the regular packages or the ones from
https://www.phusionpassenger.com/native_packages a working passenger
configuration is put in /etc/apache2/mods-available/passenger.conf (and
a2enmod-activated by the package's postinst script) so the
apache::mod::passenger class doesn't deal with this. Maybe it should, but
that will result in conflicts between configuration files provided by this
module and the package-provided configuration files. Again, I think this is
a larger issue.

I think this was a poor decision by the EPEL packagers to include a mix of
configuration and installation info in the same directory. It really
muddies the waters.

I can there's two directions that could be gone from here.

  1. Remove the purge for RHEL. Remove the original welcome.conf file and
    whatever else explicitly.
  2. Use something like the commit I posted.

Option one seems like a fairly simple solution whereas any patch I come up
with is gonna be ugly and not work for many other packages.

I'll try to come up with something in the direction of 1 and post a commit.


Reply to this email directly or view it on GitHubhttps://github.com//issues/119#issuecomment-10467865.

Spenser Gilliland
Computer Engineer
Doctoral Candidate

@Spenser309
Copy link
Author

This maybe a better way to fix this.

Spenser309@b732ce6

@tmclaugh
Copy link

I had this same issue this evening when I converted over from an older home grown apache module to puppetlabs-apache. I solved this by:

  • Setting $apache::params::vdir on RHEL to ${httpd_dir}/vhosts.d
    ** This isn't a RHELism but something I just typically do.
  • Created and set $apache::params::confd on RHEL and Debian to ${httpd_dir}/conf.d
    ** Also updated the apache modules that were dropping configs so they dropped their configs there.

tmclaugh/puppetlabs-apache@515e574cce827d04db1ef70b68ab2235f44c3fa1

I haven't tested this on Ubuntu but appears to be working fine on my CentOS host.

The only issue right now is a warning on apache start because modules are loaded twice. The module config files that ship for RHEL load the module which makes creating a file in mod.d unnecessary. In a related vein, there's also an issue where this module doesn't properly support both RHEL 5.x and 6.x. The default modules in the apache versions shipped with both OS major versions are different. I still haven't figured out how I want to handle this. In my fork I may get rid of mod.d all together but I'm not sure yet.

@Spenser309
Copy link
Author

tmclaugh, I like your approach with the vhost.d directory and with removing mod.d but why not leave conf as the confd directory. That way if an rpm package drops a file in there it can be overridden or left alone.

@tmclaugh
Copy link

On RHEL based systems Apache has two different locations for config files. The httpd.conf file lives in /etc/httpd/conf. It then includes the files in /etc/httpd/conf.d which is the location where packages drop their config files. The module needs to know about both directories.

@tmclaugh
Copy link

Spencer, if you're interested I created another issue where I list all the CentOS related issues I found. I also created a fork where I implemented the changes I proposed.

(Apologies that my fork is a little messy with lots of "Fix last commit" commits. I'm still new to git and don't have a way yet to get changes from my workstation to my puppetmaster without checking changes into git first. :)

@comptonqc
Copy link

I'd like to +1 the suggestion to not perform the purge on RHEL-alike systems. I had a config file being removed from /etc/httpd/conf.d and it took me quite a long time to figure out what was actually doing the removal.

Even if this doesn't completely solve the problem, the current default configuration will break things and I think that's a bad state for HEAD to be in.

@hunner
Copy link
Contributor

hunner commented Jun 6, 2013

The topic of this issue appears to be covered by https://github.com/puppetlabs/puppetlabs-apache/blob/master/templates/mod/passenger.conf.erb and the linked issues are discussed elsewhere. Thanks for your input!

@hunner hunner closed this as completed Jun 6, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants