trace_enable

is a parameter of the

apache

class: https://forge.puppet.com/modules/puppetlabs/apache/reference#trace_enable To specify a parameter when declaring a class, you can’t use the

include

function. You need to declare the class using the “resource-like” syntax. For example:

class { 'apache':
  trace_enable => "off",
}

The require function is used for setting dependencies it appears? E.G. a specific package has to be installed before attempting to configure it.

Using

require <some_class>

will automatically setup dependencies between the resources in

<some_class>

and the resources where

<some_class>

was declared so that

<some_class>

is enforced before the resources in the place where it was declared.

It also includes

<some_class>

. So it’s a declaration and the auto-setup of relationships.

Gotcha,, so it i had a class called apache_config and made it a requirement, it'd make sure to process apache_config first as well as load that class.

yup

More relevant reading: https://puppet.com/docs/puppet/7/lang_relationships.html

Welp, declaring the class apache ended up with it overriding the virtualhosts and defaulting the config of the phpipam server, so that diddn't exactly work the way I intended. I'm assuming that I have two options? - Either define Hiera data for that server within the puppet class itself to fully define the intended configuration or write a puppet module that either lays down a static config file or injects/replaces line entries in an existing configuration file?

Thank god for vm snapshots

Welp, declaring the class apache ended up with it overriding the virtualhosts and defaulting the config of the phpipam server, so that diddn't exactly work the way I intended. I'm assuming that I have two options? - Either define Hiera data for that server within the puppet class itself to fully define the intended configuration or write a puppet module that either lays down a static config file or injects/replaces line entries in an existing configuration file?

Maybe check the

purge_*

parameters of the apache class. Generally a bad idea but when transitioning from managed by hand to managed by Puppet this can help 😉

Maybe check the

purge_*

parameters of the apache class. Generally a bad idea but when transitionning from manager by hand to managed by Puppet this can help 😉

e.g. https://github.com/puppetlabs/puppetlabs-apache/blob/main/REFERENCE.md#purge_configs

Will this frequently cause weird issues if there is a blend of managed and unmanaged configuration items? I know that Terraform hates that.

Maybe check the

purge_*

parameters of the apache class. Generally a bad idea but when transitioning from managed by hand to managed by Puppet this can help 😉

And won't properly manage things or apply new configurations if it's not something it initially provisioned.

I don't have a production goal in mind, just mucking around and familiarizing myself with puppet at the moment.

I rarely used it, but when connecting a legacy server for managing it I have first classified the node to have our common apache config (so with

purge_vhost_dir

set to false). And then replaced the Vhosts 1 by 1. And then re-enabled purging.

I rarely used it, but when connecting a legacy server for managing it I have first classified the node to have our common apache config (so with

purge_vhost_dir

set to false). And then replaced the Vhosts 1 by 1. And then re-enabled purging.

Thank you, I'll tinker with it some more tommorow.

by "replaced" I mean "integrated the vhost in the puppet config"

I think that will be my eventual goal,

would best practice be to add the config for each host to modules/apache directly and then use hiera for host/app specific configuration items?

Opposed to trying to inject apache configuration data into an app-specific module?

such as a module named phpipap that installs the server?

would best practice be to add the config for each host to modules/apache directly

No. You must not modify the apache module itself. Consider that off limits, and treat it like an upstream library that you’re using…. not modifying. You’d add Vhost configurations to a different, app-specific module that declares

apache::vhost

resources as needed.

We use Foreman only to switch puppet_environment & look at puppetrun logs. Is there any alternative that is a bit lighter on resources?

puppetboard?

choria/mcollective for switch environment ?

See the

choria-mcollective

module at https://forge.puppet.com/choria/mcollective?src=slack&channel=puppet