sites-enabled on redhat?

[ubellavance]

Hi,

I would like to know why the debian-specific method is used on Red Hat? I can see that the result is the same, but why doesn't it use conf.d instead?

Thanks,

[wyardley]

I think this is pretty typical for modules that manage Apache / Nginx (I've seen similar things with Chef modules), but your question is well-timed... I put in a PR that has a (configurable, off by default) way to get the more expected behavior, and won't create (or delete) sites-enabled / sites-available or create symlinks.

#878
if you'd like to comment / test

[wyardley]

ps - One reason I can think of that one might want to separate it in certain cases is that conf.d/* sometimes has configs dropped down by RPMs, which is why there's an option to enable / disable $confd_purge. and $vhost_purge separately. Having separate namespaces for the files that rpms drop down vs. the ones Puppet drops down might be useful for some folks.

That said, I prefer having stuff in conf.d, and don't find the sites-enabled / sites-available workflow that useful for my situation, especially when I'm using config management.

[ubellavance]

I understand the reason, but there are many modules that use .d directories. It is the responsibiliy of the user/module author to use unique names and make sure nothing is overwritten by mistake.

What's the use of the sites-enabled/available? You can quickly disable a vhost without having to search and comment the relevant lines? Apparently.... And it allows the use of commands to enable/disable.

I agree that I'm OK with .d directories on Red Hat.

I'm not sure how I could test your code though... I'm not that familiar with Git and PRs.

Thanks,

[wyardley]

I think when not using declarative config management, there are some big advantages to the Ubuntu system... as you say, easier to enable / disable a particular site.

As far as how to test, you could apply the patch at:
https://patch-diff.githubusercontent.com/raw/voxpupuli/puppet-nginx/pull/878.diff
against your module and then set nginx::config::confd_only to true. Or follow #878 and wait to see if it gets merged.

[ubellavance]

Are PRs merged quickly in this module?
How do I apply a patch on an installed module?

[wyardley]

If you're installing via 'puppet module' directly, I don't use that command (and we fork all the 3rd party modules that we use), so I don't know. In theory, you should be able to apply the patch against the module directory, but don't know if it would get wiped out at some point.

But yes, overall, this project tends to move pretty quickly. I'm not sure how long after that it would take for a version bump. You can also poke someone in the #voxpupuli channel in Puppet Community slack or on Freenode IRC. I've been hesitant to push for this one to be merged too quickly, because I'd still like to get some feedback from other folks on it.

[ubellavance]

I can always do a snapshot of the VM and rollback once my tests are done. Do I simply use the patch command with the diff file as an argument? Can you provide me with the full command (RHEL7) and the path I must be in? The module is in /etc/puppet/modules/nginx/.

[ubellavance]

I figured out what commands to use to patch the module code:

cd /etc/puppet/module/nginx/
patch -p1 < /path/to/878.diff

It tested OK. If I use nginx::config::confd_only: true, it creates the conf.d directory and the vhost files inside it. If I set it to false afterwards, it reconfigures nginx.conf to use the sites-enabled and sites-available dirs and even cleans up the conf.d dir so that no unused .conf files are left behind. Good job.

[ubellavance]

By the way, I use

nginx::config::vhost_purge: true
nginx::config::confd_purge: true

[wyardley]

I've updated #878 (to reflect recent changes). As to whether it gets included in the next release, I am not sure yet. Closing this issue.