4.7.3. General Administration

This section provides information on the standard administrative techniques used when managing SIMP systems.

Various philosophical decisions are also covered to help users understand why SIMP does some of the things that it does.


While working with the system, keep in mind that Puppet does not work well with capital letters in host names.


SIMP fully supports Puppet Environments and, by default, installs into an environment named simp. This environment is symlinked to the production environment by simp config but that symlink will not be overwritten on update so you may freely change or replace the symlink to meet your needs.

There are a couple of paths on the system that are environment related. /var/simp

This space holds all static, non-Puppet created files. It is generally used for large binary items that will be centrally 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 and the Infrastructure keys.

This space is environment aware and you will note that there is an environments directory under /var/simp with, by default, the simp environment represented. If you add new environments, you will need to replicate the appropriate structure from the simp environment into your custom environment.

This space also holds FakeCA. See Infrastructure Certificates.


For more information on the SIMP rsync structure, please see HOWTO Work with the SIMP Rsync Shares /opt/puppetlabs/server/data/puppetserver/simp

This space holds all non-static, Puppet Server created files. This is used by both passgen() and the krb5 Puppet module for storing dynamically generated server-side content.

Like /var/simp this space is also environment aware but you should never need to manually adjust anything in this directory space. Package Management

The SIMP infrastructure has a consistent philosophy that managed packages should be at the latest version in the available repositories whenever the system is brought into alignment by Puppet.

All SIMP produced modules should, by default, have their versions set to present but simp_options, when set initially by simp config, should set that to latest across the environment.

The rationale behind this is that it is far easier to update a set of repositories than it is to precisely pin versions of all packages managed on a given system. Since repositories are generally common packages, the ability to create a set of symlinks that represent the latest tested state of a system should be far simpler than doing minutia management across your Puppet code. Workflow

The general workflow to keep your system properly up to date would be as follows.


We highly recommend using Beaker for testing these scenarios

  1. Update the Test repository
  2. Assign a test node to the repository via a yumrepo resource
  3. Run Puppet and evaluate the results
  4. Run a full system update and evaluate the results
  5. If all goes well, migrate the changes to the Production repository
  6. Let Puppet do the rest

See Nightly Updates for more information on setting up the repositories and providing packages to your clients. Nightly Updates

All SIMP systems are configured, by default, to do a YUM update of the entire system on a nightly basis. When the update task runs, it will pull ALL updates that the system is aware of.


Refer to HOWTO Exclude YUM Repositories for additional configuration information.


See HOWTO Modify the Nightly Update Schedule for information on changing the nightly update schedule or disabling the nightly updates altogether.

To use this effectively, packages that all systems will receive should be placed into the Updates repository provided with SIMP. Any packages that will only go to specific system sets should then be placed into adjunct repositories under /var/www/yum and the user will point specific systems at those repositories using the yumrepo Puppet Type. Any common packages can be either symlinked or hard linked between repositories for efficiency. Changing the Default Repositories

By default, SIMP stores YUM information in the following directories:

  • /var/www/yum

The base SIMP repository is in /var/www/yum/SIMP and it is highly unlikely that you would want to modify anything in this directory.

By default, access to the YUM repository is restricted to the networks contained in the simp_options::trusted_nets parameter. For this section, we will assume that this is sufficient. The Operating System Repos

The default location for the Operating System (OS) repositories, on the Puppet master, is /var/www/yum/<OSTYPE>/<MAJORRELEASE>/x86_64.

An Updates repository has been configured in this space. All OS updates should be placed within this directory.

You should run the following in the Updates directory after ANY package addition or removal within that directory.

# createrepo .
# chown -R root.apache ./*
# find . -type f -exec chmod 640 {} \;
# find . -type d -exec chmod 750 {} \; Adding a Custom Repository

For this section, we will assume that you have a repository named foo that you would like to expose to your systems. To do this, perform the following:

# cd /var/www/yum
# mkdir foo
# cd foo
# -- copy all RPMs into the folder
# createrepo .
# chown -R root.apache ./*
# find . -type f -exec chmod 640 {} \;
# find . -type d -exec chmod 750 {} \;


For more information on managing YUM repos, please see the Red Hat local repository Documentation. Configuring the Clients

Now that you have added this repository, you are going to want to add it to your clients.

The best way to do this is to make it part of your site profile. You can make it part of your module, but you will need to wrap it in a Defined Type so that the server parameter can be modified.

To add it to your clients, use the puppet yumrepo Type. You can find more information in the Puppet Type Reference.

The following is a basic yumrepo example:

yumrepo { example:
  baseurl         => "http://your.server.fqdn/yum/foo",
  enabled         => 1,
  enablegroups    => 0,
  gpgcheck        => 0,
  keepalive       => 0,
  metadata_expire => 3600
} Session Auditing

Older versions of SIMP used Sudosh to enable logging of privileged user activities.

This has been replaced by Tlog for a more seamless user experience and all activities should be able to be done without the need for additional explicit sudo commands from this point on.

By default, the actions of the root user at a login shell are audited. Please see the Tlog documentation and the SIMP Tlog Puppet Module for additional details.


The SIMP system does not allow the root user to execute sudo by default per common configuration guidance.


If you built your system from an ISO, you will probably have a local simp user that has the ability to run sudo su - root directly.

The simp user is meant as an emergency ‘break glass’ user and should be removed or disabled once your environment is configured to your satisfaction. User Accounts

The SIMP team tests both local and LDAP account access to systems. Other modes of access may function but are not tested by the SIMP test suite at this time.

We recommend that LDAP be used for adding all human users so that there is no conflict with multiple system updates and synchronization. For more information on managing LDAP users, refer to the User Management chapter.

If you need to create local system accounts, you can use the user and group Native Types. Certificate Management

This section describes the two different types of certificates used in a SIMP environment and provides links to further information. Puppet Certificates

Puppet certificates are issued and maintained strictly within Puppet. Communication between the master and agents is granted and secured with HTTPS, which requires valid identifying SSL certificates. The Puppet master acts as the certificate authority for managing these certificates.

The client will automatically send a certificate request to the server if it cannot find a valid certificate. The Puppet master will automatically sign a certificate request if the client’s name is in the autosign.conf file, otherwise an administrator must sign the request using the puppetserver ca tool.


By default, Puppet certificates expire every five (5) years. Infrastructure Certificates

Infrastructure certificates, commonly referred to as server certificates, are the standard PKI certificates assigned by an official CA. These are used by all other applications that require certificates.

SIMP offers capabilities to help manage these certificates including a FakeCA utility that will provide self-signed certificates for use on testing systems or until official certificates can be obtained.

The modules in SIMP have been designed so that infrastructure certificates can be managed from a central location and SIMP will distribute them to the applications that need them.

For more information on how to manage infrastructure certificates and how to use the FakeCA utility refer to the Apply Certificates section of Client Management. The SIMP Utility

The SIMP server provides a command line utility called simp that is an interface into SIMP-specific settings and subsystems.

You can get information on the simp utility by running simp help on your SIMP server. simp passgen

Throughout the SIMP codebase, you may find references to the passgen() function. This function auto-generates passwords and stores them in /opt/puppetlabs/server/data/puppetserver/simp/environments/<environment>/simp_autofiles/gen_passwd on the Puppet master.

For more information, see the passgen() documentation. Graphical User Interfaces

SIMP was designed as a minimized system, but you may occasionally need a GUI. Refer to the Graphical Desktop Setup documentation for information on setting up GUIs for the systems.