Configuring modules is currently limited to Centos/RHEL only

[perryk]

As mentioned in #232 and #233 the configuring modules section is currently limited to Centos/RHEL only.

I'm working on a PR to expand this and standardise the process if possible.

The current idea is to not follow the current method adding a symlink:
/etc/nginx/modules-enabled/<shortname>.conf -> /usr/share/nginx/modules/<shortname>.conf

To instead first create a .conf file for a given filename.so module file and save as:
/etc/nginx/modules-available/filename.conf

There was some functionality to do this removed however the template file still exists.

Then add a symlink:
/etc/nginx/modules-enabled/<filename>.conf -> /etc/nginx/modules-available/<filename>.conf

Personally I think this is cleaner as it keeps to the <something>-available and <something>-enabled model used in other parts of the configuration.

Potentially we could keep support for using the <shortname> and EPEL provided .conf files already for when using EPEL and only use the template created <filename>.conf files for Official Nginx repo provided modules and for Ubuntu/Debian also.

The concern however is if anyone is already managing modules with links only directly to /usr/share/nginx/modules files, they would need to remove these links. Considering how new the recent commits are however and that there was a typo preventing their use at all I'd hazard a guess to say not many people are in this situation.

n.b I do understand other distros may use something other than /etc/nginx for the main configuration folder. I've just used this above as an example and to make things a little clearer.

[perryk]

I'm making progress on the PR for this, actually, it is pretty much done, I'm just testing it further currently.

It isn't quite as clean as may have been hoped, simply due to the variation in different operating systems and package repositories.

I figured I would record a some detail of this so if anyone goes looking there is some rationale behind it.

There are 4 configurations I'll look to cater for.

1. Centos/RHEL with EPEL repo
2. Centos/RHEL with official Nginx repo
3. Debian/Ubuntu with APT repo
4. Debian/Ubuntu with official Nginx repo

Config 1 - Centos/RHEL with EPEL repo

With the default setting for installing only the package "nginx", the installation task should bring down Nginx, a bunch of modules, and a nicely configured filesystem all ready for use with SELinux. Module .so files live in /usr/lib64/nginx/modules and Module.conf files live in /usr/share/nginx/modules/ with a short-name file naming convention e.g mod-http-geoip.conf.

The nginx_module_configs role variable will need to be specified as a list of configuration file names, minus the .conf file name extension. e.g mod-http-geoip

n.b this will allow backward compatibility, as anyone already managing modules will only be using EPEL and will be specifying config files and not module files.

Config 2 - Centos/RHEL with official Nginx repo

Any modules needed should be added to and specified in the nginx_pkgs role variable and named something like nginx-module-geoip as the installation task will only install Nginx, not any modules. Also, currently only some SELinux settings are set and I've found it necessary to also set the SELinux boolean of httpd_can_network_connect when acting as a reverse proxy. Module .so files live in /usr/lib64/nginx/modules/ and there are no Module.conf files provided. The role will use a template to create these files as needed.

The nginx_module_configs role variable will need to be specified as a list of module file names, minus the .so file name extension. e.g ngx_http_geoip_module

Config 3 - Debian/Ubuntu with APT repo

With the default setting for installing only the package "nginx", the installation task should bring down Nginx and a bunch of modules. Module .so files live in /usr/lib/nginx/modules and Module.conf files live in /usr/share/nginx/modules-available/ . with a short-name naming convention e.g mod-http-geoip.conf. Additional Module.conf files are created, perhaps by a post-install script, in /etc/nginx/modules-enabled with filenames starting with 50-. Presumably, these are to allow /usr/share files to remain as a reference and then people can add/remove the 50- files. Worth noting also there are lots more modules available if nginx-extras or nginx-full is set in nginx_pkgs role variable or manually installed later.

These 50- files are in the way for us, so I've added tasks to rename these files out of way if they exist for any particular module which we choose to manage. The file is renamed to something like mod-name.conf.renamedasmanagednow. With this extension they won't be loaded. Perhaps one case not yet considered is if you wish to manage the disabling of a specific module before ever enabling it via the role. Either set the role to enable this module once, then disable it, or manually move the 50- file out of the way.

n.b the functionality to disable modules via the role is not working yet, the code doing the enabling however is aware to not enable anything if it is specified in the do not enable section, even if it is also in the enable section.

The nginx_module_configs role variable will need to be specified as a list of configuration file names, minus the .conf file name extension. e.g mod-http-geoip

Config 4 - Debian/Ubuntu with official Nginx repo

Fairly similar to Config 2. Any modules needed should be added to and specified in the nginx_pkgs role variable and named something like nginx-module-geoip as the installation task will only install Nginx, not any modules. Module .so files live in /usr/lib/nginx/modules/ and there are no Module.conf files provided. The role will use a template to create these files as needed.

The nginx_module_configs role variable will need to be specified as a list of module file names, minus the .so file name extension. e.g ngx_http_geoip_module

Other considerations

The 2 options for what is needed in nginx_module_configs variables is listed in each section above however worth noting.

The general idea is to have files in /etc/nginx/modules-available (even if just links to elsewhere) and then links to those in /etc/nginx/modules-enabled. This is kept in all cases.

The 2 options for where the actual module .so files live is catered for with a new variable nginx_modules_location, so this shouldn't need to be specified unless someone wants to override for use with a different distribution.

All in all, it isn't too bad, perhaps seeing the code will explain it all anyway. Hopefully, just another day or so and I'll send in a PR.

Cheers.