4.7.2. Deploying SIMP Environments

SIMP fully supports Puppet Environments, and extends the practice by providing parallel environment directories to manage data that does not belong in a control repository.

This section describes how SIMP interacts with Puppet environments, and how to integrate SIMP environments into your site’s deployment strategy. SIMP Environments

The term “environment” is heavily overloaded when discussing SIMP, Puppet, DevOps, and IT in general.  We attempt to make the following distinctions:

SIMP Environments diagram

A full SIMP “Omni” environment is composed from three corresponding environments:

Environment Description
  • The standard concept of “Puppet environment” when Puppet/PE is operated independently from SIMP.
  • Acts as a namespace for managing nodes―with its own code, data, and lookup hierarchy.
  • Sourced (once deployed) from a Puppet environment directory
  • Provides SIMP with independently-maintained assets that support a specific Puppet environment
  • Useful for git-unfriendly files, such as secrets (e.g., keydist/) and large files distributed by rsync.
  • Sourced from a secondary environment directory
  • Puppet environment-specific SIMP data (e.g., simplib::passgen() data), generated by the Puppet Server
  • Data is generated automatically by Puppet functions during catalog compilation
  • Written to/sourced from the writable environment directory

Each environment has an associated directory:

Puppet environment directory

  • A single directory at $codedir/environments/<environment_name>
  • Contains the Puppet code and Hiera data needed to manage a Puppet environment:
    • site manifest(s), Puppet modules, Hiera data (Hiera 4+), and Hiera hierarchy (Hiera 5+).
  • Assets can deployed using r10k or Code Manager:
    • r10k deploy creates one Puppet environment directory per control repository branch.
    • r10k puppetfile install (using default settings) can be run at the top level of a Puppet environment directory to deploy its modules from the local Puppetfile.

Secondary environment directory

SIMP, by default, supplements each Puppet environment with a Secondary environment directory, located on the SIMP server at /var/simp/environments/<environment_name>.

This space holds all static, non-Puppet created files. It is generally used for large binary items that will be delivered via rsync, and for files that are too dangerous to add to a version control system. These include things like the SIMP rsync materials (rsync/), the Infrastructure Certificates (site_files/pki_files/files/keydist/), and the krb5 Puppet module (site_files/krb5_files/files/keytabs).

As you add new Puppet environments, you will need to replicate the appropriate Secondary directory structure here.


For more information on the SIMP rsync structure, please see HOWTO Work with the SIMP Rsync Shares

Writable environment directory

SIMP also maintains Writable environment directories in parallel with each Puppet environment at /opt/puppetlabs/server/data/puppetserver/simp/environments/. This space holds all non-static, Puppet Server created files. It is used for content that can be generated during catalog compilation, such as simplib::passgen() and ssh::autokey(),


You should never need to manually adjust anything in this directory space.

Building on the environments above, it is useful to consider the following “meta” environments:

Environment Description
SIMP “Omni” environment
  • The complete combination of Puppet + SIMP Extra (Secondary + Writable) environments of the same name
SIMP “Extra” environment
  • A combined Secondary environment + Writable environment
  • (Just the SIMP environments w/o the Puppet environment)
Infrastructure Environment
  • A local site’s dedicated internal infrastructure tier
  • Exists independently from Puppet
  • Often named something along the lines of “development,” “testing, acceptance,” “staging,” “production”, etc.,
  • In Puppet circles, this is sometimes referred to an infrastructure as an “application tier” or “permanent test environment

Scaling considerations for Extra (Secondary and Writable) environment directories

Secondary and Writable environment directories pose a problem for Puppet scaling:

  • Load-balanced compile masters must keep the contents of both secondary and writable environment directories in sync across all compile masters.
  • Alternatively, disciplined use of Hiera Eyaml encryption must be used to replace all parameters that default to using Writable-environment functions like simplib::passgen(). Deployment Scenarios

SIMP supports deploying Puppet code using r10k or Code Manager, even when its modules are installed from RPMs. However, deployment strategies vary widely, based on a site’s infrastructure, existing policies, and administrative considerations. SIMP broadly groups these strategies into high-level deployment scenarios, with some important variations:

Deployment Scenarios and Variations
Deployment Scenario Variation r10k command Control Repository? Module Repos Autodeploy?
Local Local module repos r10k puppetfile install No Local (from RPMs)  
Control Repo Manual r10k r10k deploy environment Yes Remote (Git hosting service)  
Webhook + r10k r10k deploy environment
PE Code Manager puppet code deploy

Regardless of the deployment scenario and variation employed, it is important to ensure that each Puppet environment is associated with an appropriate SIMP Omni-environment, or that the data provided by SIMP’s “Extra” environments are handled by alternate means. Local deployment scenario

The Local deployment scenario deploys Puppet modules from Local Module Repositories into an existing Puppet environment’s modules/ directory.

This scenario requires the least preparation: it doesn’t require a control repository, a remote git-hosting service, or even a functioning network. It also works automatically on any monolithic SIMP master (6.4.0+) that was installed from ISO or RPM. In fact, the initial run of simp config uses this method to deploy the system’s first modules into the production environment.

The local deployment scenario is recommended for:

  • Systems that don’t have access to a git-hosting service
  • Users who prefer to treat the SIMP framework as a vendor-packaged appliance
  • Users who prefer to avoid maintaining a control repository

It requires:

  • SIMP RPM-delivered Local Module Git Repositories
  • The simp command
  • A pre-existing Puppet environment directory (simp environment new)
  • A simp Puppetfile (simp puppetfile generate)
  • No additional compile masters.


The local deployment scenario is only suitable for a single monolithic SIMP master.


If you need to scale beyond a single master, you should deploy from a control repository. Deploying from Local module repos

This is the initial deployment scenario immediately after Installing SIMP from an ISO.

r10k + local, SIMP RPM-delivered module repositories

Under this scenario, a local r10k user will:

  • cd into an existing Puppet environment directory
  • Use the command r10k puppetfile install to deploy the modules defined in the local Puppetfile (which may include a separate Puppetfile.simp)


  • The Puppet environment directory and Puppetfile must exist before r10k puppetfile install is run
  • The modules in the Puppetfile are defined with file:// URLs, and pull from Git repositories on the local file system Control Repository deployment scenario

The Control Repository deployment scenario deploys complete Puppet environments from a remotely-hosted Control Repository.

SIMP administrators must ensure that each deployed Puppet environment is associated with an appropriate SIMP Omni-environment (or doesn’t need to be). A good starting point is to review the article, HOWTO Set up a SIMP Environment in a Control Repository

The Control repository deployment scenario is recommended for:

  • Environments that manage their infrastructure as code
  • Infrastructures that need to scale beyond a single master (e.g., compile masters)
  • Administrators who are comfortable with git and Puppet control repositories
  • Puppet Enterprise users

It requires:

  • A remote git-hosting service
  • A (remotely-hosted) Control Repository
  • r10k and/or Code Manager, configured to deploy from the Control Repository
  • Keeping all remote Puppet module repositories (and the control repository’s Puppetfile) up-to-date as SIMP RPMs deliver new module versions to the master’s local filesystem

Depending on the variation, it may also require:

  • (optional) a local webhook on the Puppet master, configured to trigger the code deploy
  • (optional) a webhook on the git-hosting service to trigger environment deployments on the Puppet master after a control repository branch is updated


Control repository deployment scenario administrators are expected to: Manual r10k deploy

r10k + Control Repository (manual deploy)

Under this scenario:

  • Puppet admins maintain a Puppet control repository (and Puppet module repositories) in an external git-hosting service.
  • An r10k user logs into the Puppet master and manually deploys entire Puppet environment directories (one per branch) from the command line:
    • r10k deploy environment [ENVIRONMENT]
    • r10k puppet code deploy [ENVIRONMENT] (Puppet Enterprise) Webhook-triggered r10k deploy

r10k + Control Repository (webhook deploy)

Under this scenario, Puppet admins:

  • Maintain a Puppet control repository (and Puppet module repositories) in an external git-hosting service
  • Deploy a Puppet environment by pushing updates to a control repository branch

When a control repository branch is updated, it automatically triggers an environment deployment on the Puppet master:

  • The Git-hosting service uses a webhook to notify the Puppet master about the branch that was changed
  • The webhook on the Puppet master triggers r10k to deploy the branch as an environment PE Code Manager

PE Code Manager + Control Repository

Under this scenario, Puppet admins:

  • Maintain a Puppet control repository (and Puppet module repositories) in an external git-hosting service
  • Deploy a Puppet environment by pushing updates to a control repository branch

When a control repository branch is updated, it automatically triggers an environment deployment on the Puppet master:

  • The Git-hosting service uses a webhook to notify the PE master/MoM about the branch that was changed
  • The webhook on the Puppet master triggers PE Code Manager to deploy the branch as a staged environment
  • The PE File Sync service distributes the staged environment to any compile masters, and promotes the code from staging to live use. Local Module Repositories

PE Code Manager + Control Repository

Each SIMP-packaged Puppet module RPM delivers it Puppet module content to two locations:

  1. Under the directory /usr/share/simp/modules/<module_name>/
  • These are reference files, and are recognized by package management tools like rpm -ql and rpm -V
  1. A tagged commit to a local Git repository at /usr/share/simp/git/puppet_modules/<org>-<module_name>/
  • This repository supports r10k puppetfile install and the simp commands, “puppetfile generate” and “environment new
  • The git repo and tags are created automatically during the RPM’s %postrun

When a SIMP-packaged Puppet module RPM is:

  • Installed, a new tag is created inside a new repository.
  • Upgraded, a new tag is created and all previous tags are preserved.
  • Removed, its local Git repository will remain on the filesystem (in case any Puppet environments still reference it).

The RPM’s %postinstall git management is handled by the simp_rpm_helper script (from the simp-adapter package). It derives the repo’s name (<org>-<module_name>) from module’s metadata.json file. The repo name is guaranteed to be unique across all Puppet modules published to the PuppetForge.


The master branch in a SIMP RPM-created Puppet module Git repository is a local transaction history of RPM-generated module tags.

  • It is NOT a copy of the module’s Git development history from its public repository.
  • It does NOT track the highest version available from the repository.
  • The branch head will be whatever the most recent successful RPM %postinstall was—even if that was a downgrade.

Therefore: your Puppetfiles should reference modules by tag (and never master) when deploying from a SIMP RPM-created Puppet module Git repository. SIMP CLI Commands for Environment Management

The SIMP CLI provides commands to aid you in many facets of Puppet environment management. This section will explain the basics of each command, many of which were used in Creating and Deploying a Test Environment Using Local Module Repositories.


All SIMP CLI environment management commands need to be run as root. simp environment new

simp environment new creates a new SIMP Omni-Environment skeleton. This allows sysadmins to create new, SIMP environments easily, when they need to create a new Puppet environment.

By default, simp environment new creates a SIMP Omni-Environment skeleton, which includes a Puppetfile that can be used to deploy Puppet modules from local, SIMP-managed Git repositories. Its behavior, however, is quite flexible. You can control which parts of the environment get created, (including the Puppetfile) with its command options. You can even have it deploy the Puppet modules using r10k puppetfile install, if you want it to create the full environment in one step.

simp environment new options are documented in its built-in SIMP CLI documentation. To see the options available, execute the following:

simp environment new -h Default Behavior

When no options are specified, simp environment new <env name> takes the following actions:

  1. Creates the Puppet environment /etc/puppetlabs/code/environments/<env name> from /usr/share/simp/environment-skeleton/puppet.

    • This includes creating the appropriate environment.conf file from the skeleton’s environment.conf.TEMPLATE.
  2. Generates the files Puppetfile and Puppetfile.simp under the new Puppet environment’s directory:

      ├── Puppetfile
      └── Puppetfile.simp
    • This was equivalent to executing:

      cd /etc/puppetlabs/code/environments/<env name>
      simp puppetfile generate --skeleton > Puppetfile
      simp puppetfile generate > Puppetfile.simp
    • See “simp puppetfile generate” for an explanation about the benefits of having these two Puppetfiles.

  3. Creates the secondary environment /var/simp/environments/<env name> from /usr/share/simp/environment-skeleton/secondary.

  4. Copies files from /usr/share/simp/environment-skeleton/rsync into /var/simp/environments/<env name>/rsync.

  5. If any tftpboot PXE image files can be found in directories matching /var/www/yum/CentOS/**/x86_64/images/pxeboot, copies those files into the appropriate sub-directory in /var/simp/environments/<env name>/rsync/RedHat/Global/tftpboot/linux-install.

  6. Creates a new FakeCA cacertkey file at /var/simp/environments/<env name>/FakeCA/cacertkey. The file is populated with a random string.

  7. Re-applies the FACLs, SELinux contexts, and permissions to the newly-created directory trees.

    • Equivalent to executing: simp puppetfile fix <env name>
  8. Does not create the Writable environment, because in this scenario, that environment will be automatically generated, as needed, when puppet is run simp environment fix

simp environment fix re-applies the FACLs, SELinux contexts, and permissions to a SIMP Omni-Environment. This can be especially useful, when you have added files to the environment and are unsure which settings are appropriate for them.

By default, simp environment fix operates on all directories in the SIMP Omni-Environment. However, its behavior is quite flexible. You can control which parts of the environment get fixed with its command options.

simp environment fix options are documented in its built-in SIMP CLI documentation. To see the options available, execute the following:

simp environment fix -h Default Behavior

When no options are specified, simp environment fix <env name> , takes the following actions:

  • Applies Puppet permissions (group) to /var/simp/environments/<env name>.
  • Applies Puppet permissions (user + group) recursively under /etc/puppetlabs/code/environments/<env name>.
  • Applies Puppet permissions (group) recursively under /var/simp/environments/<env name>/site_files.
  • Restores SELinux contexts under /var/simp/environments/<env name>.
  • Applies FACL rules to /var/simp/environments/<env name>/rsync simp puppetfile generate

simp puppetfile generate creates one of two different types of Puppetfiles:


The SIMP-only Puppetfile, used to deploy SIMP’s Puppet modules from local SIMP-managed Git repositories. These local repositories are created/updated when SIMP-packaged Puppet module RPMs are installed. This file can be regenerated to deploy the version of each module under /usr/share/simp/modules using the command:

simp puppetfile generate > Puppetfile.simp

The Parent Puppetfile, which deploys all modules from both Puppetfiles. Administrators can customize this file to declare any additional (non-SIMP) modules they may need. It also includes the content from the SIMP-only Puppetfile from the same directory. A fresh parent Puppetfile can be generated by running:

simp puppetfile generate --skeleton > Puppetfile

The files are kept side-by-side at the top level of each Puppet environment directory:

├── Puppetfile.simp
└── Puppetfile

simp puppetfile generate generates these two files separately so administrators can manage any non-SIMP modules in the Puppetfile, while permitting simp to regenerate Puppetfile.simp as the SIMP-only modules are updated. r10k will deploy all the modules in both Puppetfiles.

If you want to update SIMP-only Puppetfile entries after installing/upgrading SIMP module RPMs, all you have to do is to execute:

simp puppetfile generate > <path to your environment>/Puppetfile.simp

Any Puppet modules defined in the parent Puppetfile will be unaffected.

For example, to update the SIMP-only Puppetfile created by simp config in a standard SIMP server install from SIMP ISO or SIMP RPMs, execute:

cd /etc/puppetlabs/code/environments/production
simp puppetfile generate > Puppetfile.simp Default Behavior: Generating Latest SIMP-only Puppetfile Content

When no options are specified, simp puppetfile generate, prints to the console a Puppetfile that could be used to deploy the current set of SIMP Puppet modules installed via RPM in /usr/share/simp/modules from the corresponding local, SIMP-managed Git repositories in /usr/share/simp/git/puppet_modules.

Each Puppetfile entry will look like the following:

mod 'simp-simplib',
  :git => 'file:///usr/share/simp/git/puppet_modules/simp-simplib.git',
  :tag => '3.15.2'

The module name will be the name of the Puppet module in its metadata.json file (<Puppet Forge org>-<module name>), the Git URL will be its local, SIMP-managed Git repository, and the Git version will be the latest tag in that local repository.

SIMP chose the naming convention to match that of PuppetForge.


The corresponding SIMP-packaged Puppet module RPM name is

pupmod-<Puppet Forge org>-<module name> Generating a Parent Puppetfile Skeleton

When the --skeleton option is specified, simp puppetfile generate --skeleton prints to the console a parent Puppetfile that includes Puppetfile.simp, the assumed name of the Puppetfile containing only SIMP modules. This parent Puppetfile indicates where you would add site-specific modules, that would be deployed along with those in the included Puppetfile.simp. The Puppetfile.simp file is assumed to be in the same directory as the parent Puppetfile.


You can optionally have local modules in a specified environment automatically added to this parent Puppetfile using the --local-modules SRC_ENV option. Local modules are modules whose directories are not under Git source control and for which there is no local Git repository. Other Options

The options simp puppetfile generate provides are documented in its built-in SIMP CLI documentation. To see the options available, execute the following:

simp puppetfile generate -h Examples for Deploying SIMP Environments

The example below steps through one way to set up a test environment. You might also find the following HOWTO documents to be helpful: Updating an Existing Environment

When you are using the Local deployment scenario the following steps can be used to update and deploy Puppet modules from the local git repositories to an existing environment or to update any of your site specific modules in your environment.

  1. Update Site Specific Puppet Modules

    Follow your site procedures to update any of your site specific Puppet modules.

    Make sure all your modules have an entry in the Puppetfile. See Edit the Puppetfile to include non-simp site modules for more details.

  2. Update SIMP Local Git Repositories

    On the yum server (usually the SIMP master on smaller deployments) add any new or updated SIMP module RPMs to the yum repositories using your sites procedures.

    On your SIMP master, clear the yum cache

    yum clean all; yum makecache

    Then install or update any modules

    # For example if installing all the modules in simp-extras
    yum install simp-extras
    # or a simp Puppet module with a patch
    yum update pupmod-simp-aide

    This will update the local git repositories on the SIMP master.

  3. Deploy the Environment

    • Generate the Environment’s Puppetfile.simp

      Run simp to pull all the latest versions of the SIMP-packaged Puppet modules from the local git repositories:

      # The environment in this example is called `test`.  Replace `test` with the
      # name of your environment.
      cd /etc/puppetlabs/code/environments/test
      simp puppetfile generate > Puppetfile.simp
    • Verify the Environment’s Puppetfile

      Make sure the Puppetfile you will be deploying from includes the following:

      • A line that includes the Puppetfile.simp which should look like:

      • A line for each of your own modules. See How To Generate a SIMP Puppetfile for more information on how to generate and clean up the Puppetfile if needed.


      Any module not listed in the Puppetfile will be deleted from the target environment’s modules directory, when you use r10k to deploy the modules.

    • Deploy the Modules

      Use r10k to deploy the modules from the local Git repositories into the environment. Make sure the umask and group are set correctly so that the puppetserver has access to the files.

        # The environment in this example is called `test`.  Replace `test` with the
        # name of your environment.
        ( umask 0027 && sg puppet -c '/usr/share/simp/bin/r10k puppetfile install \
        --puppetfile /etc/puppetlabs/code/environments/test/Puppetfile \
        --moduledir /etc/puppetlabs/code/environments/test/modules' )
      Use the :command:`--force` option if you get warnings that local changes will get
      overwritten and you are sure you do not have changes that need saving.
  4. Apply node configuration

    Any new modules will now be available to use in configurations on your nodes in the updated environments. Any changes in updated modules will be applied on the next scheduled puppet run on any node in the environment. Run puppet agent -t to force puppet to run on any node in the environment if you do not want to wait for a scheduled run. Creating and Deploying a Test Environment Using Local Module Repositories

This example uses the Local deployment scenario It steps through creating a new SIMP Omni-Environment, for which the SIMP secondary and writable environments are linked to the corresponding directories in the existing production environment. This will allow the two environments to use common passwords and PKI certificates. It is helpful to test out changes in SIMP or other Puppet modules.

It assumes:

  • You have upgraded SIMP-packaged Puppet module RPMs via yum.
  • You have updated some of your own Puppet modules.
  • You want to create a test Puppet environment with both sets of the changes.
  • You want to assign a subset of nodes to this new environment to test the changes.
  1. Create the new SIMP Omni-Environment

    Run the simp command to create a SIMP Omni-Environment called test for which the SIMP secondary and writable environments are linked to the corresponding directories in the existing production environment.

    simp environment new test --link production

    This will:

    • Create the Puppet environment test
    • Copy over the entire production Puppet environment over to the test environment.
    • Link the test secondary environment to the production secondary environment.
    • Link the test writable environment to the production writable environment.
  2. Update the Puppetfile Pair

    Edit /etc/puppetlabs/code/environment/test/Puppetfile and add/update any of your own Puppet modules that you are updating.

    Then update /etc/puppetlabs/code/environment/test/Puppetfile.simp using the following:

    cd /etc/puppetlabs/code/environments/test
    simp puppetfile generate > Puppetfile.simp
  3. Deploy the Modules

    Use r10k to update the modules in the test environment:

    ( umask 0027 && sg puppet -c '/usr/share/simp/bin/r10k puppetfile install \
    --puppetfile /etc/puppetlabs/code/environments/test/Puppetfile \
    --moduledir /etc/puppetlabs/code/environments/test/modules' )
  4. Assign nodes to the new environment

    Since the secondary and writable environments for the production and test SIMP Omni-Environments are linked in this example, you can move nodes between these two environments without generating new certificates.

    You can assign the node to the new environment by changing the environment setting in the node’s /etc/puppetlabs/puppet/puppet.conf file, or, if you are using the ENC supplied by the simp-util module, adding a line like the following to /etc/puppetlabs/puppet/environments.yaml.

    node.my.domain: test
  5. Apply node configuration

    To apply the configuration for a node in the test environment, simply run

    puppet agent -t

    You should see a message similar to the following at the beginning of the log for the Puppet run:

Info: Using configured environment 'test'


Once you have deployed a Puppet environment, you can edit the modules in that Puppet environment directly to debug issues you may be having and run puppet agent -t to deploy those changes. However, the next time you use r10k to deploy the modules, it will overwrite any local changes, unless the module is defined as :local => true in the Puppetfile. It is recommended that you use git to manage your work flow. Setting up a SIMP Environment in a Control Repository using Remote Git repositories

Although (with a detailed understanding of SIMP internals) you can have a SIMP server that will function with just a Puppet environment, by default, a functioning SIMP server requires its entire SIMP Omni-Environment.

This example creates a SIMP Omni-Environment skeleton whose Puppet environment you can check into a branch in your control repository.

This example assumes the new SIMP Omni-Environment will be using its own secondary and writable environments.

Before proceeding with this section, you should

  • Have a basic understanding of control repositories.
  • Have a basic understanding of how to use git.
  • Have a Git repository that you will be using as your control repository.
  • Have read Deploying SIMP Environments. It contains detailed descriptions of key topics:
    • the SIMP Omni-Environment
    • local, SIMP-managed Git repositories maintained by SIMP Puppet module RPMs
    • SIMP CLI commands to assist with SIMP Omni-Environment management.
  • You may find it helpful to read the section that explains how a control repository works in Puppet, Inc.’s control repository documentation .
  1. Install Prerequisite Packages

    The following packages are required:

    • rubygem-simp-cli
    • simp-environment-skeleton
    • simp-rsync-skeleton
    • simp-selinux-policy

    All of these packages will already be installed if you have installed the SIMP server from ISO or from RPMs.

    These RPMS can be obtained from an ISO or if the system has access to the internet the SIMP repositories can configured as described in Installing SIMP From A Repository.

    yum install rubygem-simp-cli simp-environment-skeleton simp-rsync-skeleton simp-selinux-policy
  2. Create the SIMP Omni-Environment skeleton without SIMP local repository Puppetfiles as root:

    simp environment new dev1 --no-puppetfile-gen

    This will create two skeleton directories:

    • a Puppet directory at /etc/puppetlabs/code/environments/dev1.
    • a Secondary directory at /var/simp/environments/dev1.

    A new Writable environment directory will be automatically generated, as needed, when puppet is run.

  3. Generate the Puppetfile:

    Download the Puppetfile used to create a SIMP ISO for a specific release from the SIMP simp-core repository. In this example, we are going to use the SIMP 6.4.0-0 release.

    cd /etc/puppetlabs/code/environments/dev1
    simp puppetfile generate --skeleton > Puppetfile
    curl -o Puppetfile.simp  https://github.com/simp/simp-core/blob/6.4.0-0/Puppetfile.pinned

    Manually edit the Puppetfile.simp to remove components that are not Puppet modules, by deleting all lines up to and including moduledir  'src/puppet/modules'.

    Manually edit the Puppetfile to add entries for any other non-SIMP modules your site requires.

    For more detailed information on editing these files see How to Generate a Puppetfile. This also explains how to create the Puppetfile if you are using Local Repositories instead of Internet Repositories.

  4. Add/adjust any of the Hiera files in /etc/puppetlabs/code/environments/dev1/data

  5. Create a New Branch in Your Control Repository

    Create an empty git repository in the newly created Puppet environment:

    cd /etc/puppetlabs/code/environments/dev1
    git init .

    Add all the files to a branch named for the environment in this repository:

    # create the branch
    git checkout -b dev1
    # add the directory tree
    git add --all
    # verify the directory tree doesn't have any temporary files you created
    git status
    git commit -m 'Initial dev1 environment'

    Push the branch to your control repository:

    # Add a remote for your control repository
    git remote add control_repo <URL to the control repo>
    # Push the branch
    git push dev1 control_repo
  6. To continue configuring the environment, move on to the Client Management section in the SIMP User Guide.

By default, this environment will be using a different Certificate Authority for Infrastructure Certificates. It therefore may not be able to communicate to a server in another environment when certificate authentication is required, for example LDAP. You will have to create a new LDAP server or add the new CA to the list of trusted CA’s in the other environment.

This environment will also generate a new set of passwords when simplib::passgen function is used in a Puppet module. It therefore may not be able to talk to a server in another environment that requires password authentication.