This is so the paremter ordering in the configuration is stable. It also
force the :allow key (if it exists) to be first in the sort ordering.
It would probably be better to change `$vhost_cfg_append` into an array
of one key hashes but would require a public API change.
There were some bugs in the existing $::operatingsystem based approach.
* amazon was it's own package set when it's properly part of $::osfamily ==
'redhat' as of facter >= 1.7.2
* gentoo was improperly part of the amazon package set; this patch removes
support for gentoo but it was broken anyways
modifications to nginx:📦:redhat were made as well
* it no longer tries to setup the nginx.org yumrepo for fedora as no packages
for fedora are currently provided
* amazon release numbers are inconsistent with EL. Unknown
$::lsbmajdistrelease values are now mapped to 6 so it's no longer nessicary to
test for $::lsbmajdistrelease being undefined. This logic will need to be
reworked after RHEL7.x is released.
* the url to the nginx repo was including $::operatingsystem in it but
nginx.org only has package dirs for 'rhel' & 'centos' which are presently
identical; the usage of the 'rhel' dir has been hardcoded. This fixes broken
yum repo setup for all $::osfamily == 'redhat' platforms other than redhat and
centos.
It is bad practice to use 644 on a private key so we
have migrated the key mode to 0400. The cert is already
avaliable publicly through nginx so we have allowed it
0444.
Nothing should need to write either the cert of the key
after puppet has run, so we have denied any writing.
This is so the paremter ordering in the configuration is stable. It also
force the :allow key (if it exists) to be first in the sort ordering.
It would probably be better to change `$vhost_cfg_append` into an array
of one key hashes but would require a public API change.
I get the above error message. It is easily fixed by removing the `ensure` inside `ensure_resource`, since `ensure_resource` should already be setting `$ensure` to `file`.
