`cd_apache` automates the installation and configuration of httpd. This module is a base module simply providing the httpd service itself to be used by other role- or profile modules, adding more detailed configurations specific to the particular use case.
`**__!!! Attention: Never use this puppet module on systems which have been previously configured manually. It is impossible to predict how and what would have been configured, hence previuos configurations outside the scope of this module may be overwritten! Automated configurations require a test environment to verify that the module suits the purpose intended by the user, as well as tune the parameters, before deploying into live production!!! __**`
As stated in the ynopsis, this module was written particularly for usage as base module. `Apache httpd` has a great number of usae cases where it actually is not used directly as full blown webser, but instead as 'sub-service'. Examples here would be
* frontend proxy for other applications to avoid having to put the port number into the URL
With those use cases, you would provide the vHosts at the Puppet module for the application, not the base module. Also, if you plan to use this module to run a plain fully fledged web server, you would use a role- or profile class/module on top of `cd_apache` to set up your vHost exactly as needed. Examples for regular basic vHost configuration files are included in the examples directory as parameterized .erb files. You would create a define for vhosts, i.e. using the example parameters, and simply add `cd_apache` as requirement (i.e. require cd_apache) so it gets installed automatically.
In order to apply parameters through Foreman, **__cd_apache::params__** must be added to the host or hostgroup in question.
See [more details about class deployment on Confdroid.com](https://confdroid.com/2017/05/deploying-our-puppet-modules/).
### Parameters
The following parameters are editable via params.pp or through ENC (**__recommended__**). Values changed will take immediate effect at next puppet run. Services will be restarted where neccessary.
*`$ae_manage_user` : Whether or not to manage the user settings. Important when accessing shared resources accross nodes. Defaults to `false`.
*`$ae_manage_cfg` : Whether or not to manage the apache configuration. Defaults to `false` as this module is meant to be used through profiles or roles or other modules.
*`$ae_manage_dirs` : Whether or not to manage the directory structure. Defaults to `true`.
*`$ae_allow_user_dirs` : Whether or not to allow presenting content from end user home directories. Defaults to `false`.
All files and directories are configured with correct selinux context. If selinux is disabled, these contexts are ignored.
### Known Problems
### Support
* OS: CentOS 6, 7
### Tests
* Puppet Lint
* excluded tests:
*`--no-class_inherits_from_params_class-check`:relavant only to non-supported outdated puppet versions
*`--no-variable_scope-check`: not applicable as we are inheriting parameters from params class. the lint check does not distinguish between facts and inherited parameters.
*`--no-80chars-check`: it is not always possible to stay within 80 characters, although typically only occurring on the parameter vault `params.pp`.
*`--no-arrow_alignment-check`: this check leads to actually not having am easily readable arrow alignment, as this checks `per block`, not per class.
ConfDroid as entity is entirely independent from Puppet. We provide custom configuration modules, written for specific purposes and specific environments.
The modules are tested and supported only as documented, and require testing in designated environments (i.e. lab or development environments) for parameter tuning etc. before deploying into production environments.
