Open perryk opened 5 years ago
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.
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.
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
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
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
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.
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 givenfilename.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.