# Revision history [back]

This answer assumes some default settings from the 3.x puppet config: environmentpath=$confdir/environments, basemodulepath=$confdir/modules:/usr/share/puppet/modules .

1. Any module that is _environment-specific_ should go into /etc/puppet/environments/<env>/modules. Any module that is common to _all_ environments should go into /etc/puppet/modules or /usr/share/puppet/modules; I don't know what the difference is between those two directories.

• If you need different versions of Forge modules in different environments, you can install those modules directly into the environment by using the --target option of puppet module install - for example, puppet module install --target /etc/puppet/environments/foo/modules bar-baz
2. The default for directory environments is to load all the manifests found in /etc/puppet/environment/<env>/manifests. From my understanding, it's common practice to create a 00site.pp or similar manifest in that directory that has site-wide settings, then to create a .pp file for each node or class of nodes that you are classifying.

• If you're using the "Roles and Profiles" pattern (which I highly recommend; see the Designing Puppet: Roles/Profiles Pattern for more info), then the roles and profiles should go into modules - one named roles and one named _(drumroll)_ profiles. Within the manifests directories of those modules, you would create an almost-empty init.pp (containing just a class roles {} or class profiles {} declaration), then create a subclass file for each role or profile (e.g. for the roles::web role, you would create .../modules/roles/manifests/web.pp and declare the class roles::web {...} class).
• If you're using "profiles" as a more generic node classification term, then those would probably be the node classification files in your environment's manifests directory.
3. There are two _(really two-and-a-half)_ ways to specify the environment for a node:

1. In the node's puppet.conf file, in the [agent] section, include the environment=<environment> setting (e.g. environment=dev).
2. An External Node Classifier can return an environment setting as part of its output. See External Node Classifiers for details, if you want to write a custom script to identify which environment each node will be in. The ENC can also assign classes to nodes (its original function), and so can take the place of having node classification scripts in your manifests.
3. (Really, 2½) The puppet master's environment=<environment> setting in the [master] section will determine the default environment for any node that does not set one.

If none of these provide an environment, then the default environment is production.

_(Caveat: I'm new to Puppet too, so this is all based on googling and some playing-around research in a test puppet environment)_

This answer assumes some default settings from the 3.x puppet config: environmentpath=$confdir/environments, basemodulepath=$confdir/modules:/usr/share/puppet/modules .

1. Any module that is _environment-specific_ should go into /etc/puppet/environments/<env>/modules. Any module that is common to _all_ environments should go into /etc/puppet/modules or /usr/share/puppet/modules; I don't know what the difference is between those two directories.

• If you need different versions of Forge modules in different environments, you can install those modules directly into the environment by using the --target option of puppet module install - for example, puppet module install --target /etc/puppet/environments/foo/modules bar-baz
2. The default for directory environments is to load all the manifests found in /etc/puppet/environment/<env>/manifests. From my understanding, it's common practice to create a 00site.pp or similar manifest in that directory that has site-wide settings, then to create a .pp file for each node or class of nodes that you are classifying.

• If you're using the "Roles and Profiles" pattern (which I highly recommend; see the Designing Puppet: Roles/Profiles Pattern for more info), then the roles and profiles should go into modules - one named roles and one named _(drumroll)_ profiles. Within the manifests directories of those modules, you would create an almost-empty init.pp (containing just a class roles {} or class profiles {} declaration), then create a subclass file for each role or profile (e.g. for the roles::web role, you would create .../modules/roles/manifests/web.pp and declare the class roles::web {...} class).
• If you're using "profiles" as a more generic node classification term, then those would probably be the node classification files in your environment's manifests directory.
3. There are two _(really two-and-a-half)_ ways to specify the environment for a node:

1. In the node's puppet.conf file, in the [agent] section, include the environment=<environment> setting (e.g. environment=dev).
2. An External Node Classifier can return an environment setting as part of its output. See External Node Classifiers for details, if you want to write a custom script to identify which environment each node will be in. The ENC can also assign classes to nodes (its original function), and so can take the place of having node classification scripts in your manifests.
3. (Really, 2½) The puppet master's environment=<environment> setting in the [master] section will determine the default environment for any node that does not set one.

If none of these provide an environment, then the default environment is production.

_(Caveat: _(Disclaimer: I'm new to Puppet too, so this is all based on googling and some playing-around research in a test puppet environment)_

This answer assumes some default settings from the 3.x puppet config: environmentpath=$confdir/environments, basemodulepath=$confdir/modules:/usr/share/puppet/modules .

1. Any module that is _environment-specific_ should go into /etc/puppet/environments/<env>/modules. Any module that is common to _all_ environments should go into /etc/puppet/modules or /usr/share/puppet/modules; I don't know what the difference is between those two directories.

• If you need different versions of Forge modules in different environments, you can install those modules directly into the environment by using the --target option of puppet module install - for example, puppet module install --target /etc/puppet/environments/foo/modules bar-baz
2. The default for directory environments is to load all the manifests found in /etc/puppet/environment/<env>/manifests. From my understanding, it's common practice to create a 00site.pp or similar manifest in that directory that has site-wide settings, then to create a .pp file for each node or class of nodes that you are classifying.

• If you're using the "Roles and Profiles" pattern (which I highly recommend; see the Designing Puppet: Roles/Profiles Pattern for more info), then the roles and profiles should go into modules - one named roles and one named _(drumroll)_ profiles. Within the manifests directories of those modules, you would create an almost-empty init.pp (containing just a class roles {} or class profiles {} declaration), then create a subclass file for each role or profile (e.g. for the roles::web role, you would create .../modules/roles/manifests/web.pp and declare the class roles::web {...} class).
• If you're using "profiles" as a more generic node classification term, then those would probably be the node classification files in your environment's manifests directory.
3. There are two _(really two-and-a-half)_ ways to specify the environment for a node:

1. In the node's puppet.conf file, in the [agent] section, include the environment=<environment> setting (e.g. environment=dev).
2. An External Node Classifier can return an environment setting as part of its output. See External Node Classifiers for details, if you want to write a custom script to identify which environment each node will be in. The ENC can also assign classes to nodes (its original function), and so can take the place of having node classification scripts in your manifests.
3. (Really, 2½) The puppet master's environment=<environment> setting in the [master] section will determine the default environment for any node that does not set one.

If none of these provide an environment, then the default environment is production.