Forge Home


Manage HP server BIOS settings


10,113 latest version

3.5 quality score

We run a couple of automated
scans to help you access a
module's quality. Each module is
given a score based on how well
the author has formatted their
code and documentation and
modules are also checked for
malware using VirusTotal.

Please note, the information below
is for guidance only and neither of
these methods should be considered
an endorsement by Puppet.

Version information

  • 0.0.2 (latest)
  • 0.0.1
released Feb 3rd 2014

Start using this module

  • r10k or Code Manager
  • Bolt
  • Manual installation
  • Direct download

Add this module to your Puppetfile:

mod 'tobyriddell-conrep', '0.0.2'
Learn more about managing modules with a Puppetfile

Add this module to your Bolt project:

bolt module add tobyriddell-conrep
Learn more about using this module with an existing project

Manually install this module globally with Puppet module tool:

puppet module install tobyriddell-conrep --version 0.0.2

Direct download is not typically how you would use a Puppet module to manage your infrastructure, but you may want to download the module in order to inspect the code.



tobyriddell/conrep — version 0.0.2 Feb 3rd 2014


Puppet type & provider to modify BIOS of HP servers using conrep


List conrep resources:

puppet resource conrep

puppet apply -e "conrep{ 'default': intelprocessorturbomode => 'Enabled' }"

In a manifest:

In a class:


  • There's only one collection of BIOS settings per host so there's only one conrep resource per host, the name is hardcoded to 'default'.
  • Property names must conform to the Puppet grammar, as defined in grammar.ra in the Puppet source. Thus 'Intel_Hyperthreading' becomes 'intelhyperthreading'.
  • You may want to run this code (and therefore conrep) only when required - running conrep may interfere with reading the realtime clock from the CMOS (see footnote 4 here:

Regenerating lib/puppet/type/conrep.rb

It may be necessary to regenerate the Ruby code for the provider if new BIOS settings are added or names change. Here's an example of how to do this:

Design choices

Ideally there would be a single type for managing BIOS settings across all hardware platforms and a provider per-vendor. However, the target is a moving one; vendors have different names for the same BIOS setting, BIOS revisions can change property names ('name-creep'), new hardware may introduce new settings. Owing to the fact that Puppet doesn't support dynamic property names (see the names of properties must be pre-defined.

One option would be to map between a setting (e.g. C-states) and a well-defined name, but there are drawbacks to this approach:

  • what to do it a setting is only supported by HP and not Oracle (for example)
  • if a setting's name changes the mappings would have to be updated

After considering these points I implemented a type & provider for HP hardware. The conrep utility is used under the hood to query and change settings. In order to make life easier in the face of name-creep, the code for the type can be regenerated automatically using XML output from conrep (the provider doesn't contain any hard-coded property names and therefore shouldn't need to be changed so often). This auto-generation may also be needed to support different BIOS revisions that have different names for settings.

Because property names are auto-generated they can be non-intuitive, for example 'intelrhyperthreadingoptions' instead of plain 'hyperthreading'. As mentioned above, I don't want to have to maintain a static mapping and hence have chosen not to use more friendly names. Running 'puppet resource conrep' on a server is a good way to determine the name of the relevant property.