trickle through to the package classes. I've avoided making them
into paramaterized classes and we just refer directly back to the main
nginx namespace to get the variable. Makes for a cleaner looking
module!
more secure
Added SSL caching to speed up SSL requests
Add server_tokens to the global config so this can be turned on|off
between dev and prod
Add proxy_set_header to vhost as different vhosts may require different
headers and the global setting is not ideal
Minor space formatting so that the generated files are fractionally
more readable
Argument configtest_enable / params.pp $nx_configtest_enable
* Default false
* If true will set service[nginx] restart with contents of nx_service_restart.
Argument service_restart / params.pp $nx_service_restart
* Default '/etc/init.d/nginx configtest && /etc/init.d/nginx restart'
* Since nginx 0.7.53 nginx supports '-s HUP' which will reload testing configuration first, to be backwards compatible above default was choosen.
Many distributions of nginx already implement a configtest before restart, however many doesn't, and many
even don't provide restart but a stop/start combination. If configtest_enable is true then puppet will force
nginx to do a configtest no matter if it was going or not to do it itself.
Added confd_purge option to tell it to purge files non managed by pupet in conf.d, default is false.
Because vhost_autogen it's not actually managed by puppet but indirectly created by a puppet executed
command, it's added as ignore to avoid getting it removed.
Better formating for confd purge support
Better formating for confd purge support
Defaults are set inside params, nginx class will set default and send it from local var to nginx::config,
so even when there is no need for set default values on nginx::config, in case someone already using
this module it's for some reason calling directly nginx::config, to avoid breaking anything defaults are
set inside nginx::config too.
This change uses the anchor relationship from the puppetlabs-stdlib
module to contain all of the module classes within the main "ntp" class.
Without this change, end users of the module may have difficulty
ordering things correctly since they will have to peek inside the module
and figure out it's internal workings to identify all classes that
require relationship edges.
Without this change, the end user of the module may run into issues
establishing relationships to the composite class (the main nginx class)
For example, the user may declare this relationship expecting
nginx to be managed after the yum repositories have been configured:
node default {
class { 'site::yumconfig': }
-> class { 'nginx': }
}
However, all of the resources exist in implementation classes, which
do not have a transitive relationship declared to the nginx class.
Without this change, Puppet may very well manage Class['nginx::config']
before Class['site::yumconfig'] even though the user clearly indicated
this should not be the case.