Skip to content


Switch branches/tags

Name already in use

A tag already exists with the provided branch name. Many Git commands accept both tag and branch names, so creating this branch may cause unexpected behavior. Are you sure you want to create this branch?

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Build Status

This is the puppet module to manage a trocla installation on the puppet master. It also, provides the necessary function to query trocla from puppet.

To get a quick start you might be interested in using the trocla::yaml class on your master. This will install trocla and setup it using the default YAML storage backend for your master. There is no need to configure anything on the clients if you do not want to use trocla on the clients itself.

If you want to do your own very custom setup, you should look into the other classes.


  • Version 0.2.2 of this module is for version 0.2.2 of trocla.




trocla(KEY, FORMAT, [optional options])

This is the main function you will use. This is similar to a

trocla create foo FORMAT

on the cli. This means, that if a password for this key and format exists, it will return this one, otherwise will create one automatically and return the generated password. So you might want to do something like:

  password => trocla('user_foobar','plain')

If you want to pass down encrypted passwords, you might use:

  password => trocla('user_foobar','sha512crypt')

As descriped further in trocla's docs.

The optional options, can be used to pass options to the format, like overriding the default length for passwords that are being created:

  password => trocla('user_foobar','sha512crypt','length: 32')



trocla_get(KEY, FORMAT)

This will return the value of the passed key and format. If nothing is found an error will be raised. This is interesting if you want do not want to autogenerate a password and rather be sure that it's already existing in trocla's database.




This will set the passed password for the key/format pair and return it as well. This is mainly interesting if you want to migrate existing manifests with plenty of passwords in it to trocla.

Note that the FORMAT, in this context, is the format of the PASSWORD itself: it will not reencode it unless you pass a second argument, for example:

trocla_set('admin', 'test', 'plain')

... will return the string "test" but this:

trocla_set('admin', 'test', 'plain', 'bcrypt')

... will return a bcrypt-hashed password.

Hiera backend

Trocla can also be integrated into Hiera.

For previous hiera versions (<= 3) you might want to use ZeroPointEnergy's hiera-backend. Simply include trocla::master::hiera to make that backend available. This backend also works with newer hiera releases, but only for a global hiera level.

For hiera >= 5, there is a custom hiera backend using a puppet lookup function shipped with this module.

It ships with the same feature set as ZeroPointEnergy's hiera-backend, but uses the modern hiera interfaces, so it can also be used in per environment.

Configuration is straight forward, by adding the following hierarchy entry:

  - name: trocla
    lookup_key: trocla_lookup_key
        - hosts/%{facts.fqdn}
        - roles/%{::role}
        - defaults
      config: /etc/puppetlabs/puppet/troclarc.yaml

Important are the options:

  • trocla_hierarchy: Defines the inner-hierarchy for the trocla hierarchy level. Usually, this might match your common hiera-hierarchy.
  • config: A path to a trocla hierarchy, defining any further options.

There are two different methods to lookup a password in trocla. trocla_lookup and trocla_hierarchy


trocla_lookup will simply lookup the password for a specified key and completely ignore the hierarchy defined in the hiera configuration. If the password does not exist it will create one.

The trocla hiera backend will resolve all the variables which start with "trocla_lookup::"

The second part of the variable is used to describe the format, the last part is the variable to lookup in trocla.


You can use the backend via interpolation tokens like this:

myapp::database::password: "%{hiera('trocla_lookup::plain::myapp_mysql_password')}"

      ensure: 'present'
      password_hash: "%{hiera('trocla_lookup::mysql::myapp_mysql_password')}"


trocla_hierarchy will lookup the key in the hierarchy defined in your hiera configuration. It will simply prefix all the variables with 'hiera/source/key' where source is one of the interpolated strings defined in the hierarchy section.

It will try to find a password on every level in your hierarchy first. After that it will create a password on the first hierarchy level by default. You can overwrite the level it should create the password with the key 'order_override' in the trocla_options hash.

This is useful if you require different key for different nodes or on any other hierarchy level you desire.

If you have a hierarchy defined like this:

  - "nodes/%{::clientcert}"
  - "roles/%{::role}"
  - defaults

And you want to create a different password on the roles level, so that nodes within the same role will get the same password you can set the 'order_override' like this:

  order_override: "roles/%{::role}"

The format to lookup a password this way is the same as with 'trocla_lookup':


Here is how you would use that in hiera:

mysql::server::root_password: "%{hiera('trocla_hierarchy::plain::mysql_root')}"

options hash

Trocla takes a hash of options which provides information for the password creation. This options can be set directly in hiera globally or for every key. You can also specify options specifically for a password format. However, keep in mind that trocla will respect most of the options only on the initial/first lookup, when the password is created. As most of the options only apply for creating a password.

  length: 16
  some_other_global_setting: bla
    length: 32

    length: 64
  order_override: "roles/%{::role}"

Some formats may require options to be set for creating passwords, like the postgresql format. Check the trocla documentation for available options.

Through the options mechanism it is also possible to change the lookup key used for trocla. This is especially interesting, if you want to pass 2 different options for the same key, e.g. the render option. An example for that is to have trocla use the same key for 2 different lookups, so that with the x509 format, once a certificate and once a key is returned.

var_with_x509_cert: "%{hiera('trocla_lookup::x509::my_cert')}"
    CN: 'my-cert'
      certonly: true
var_with_x509_key: "%{hiera('trocla_lookup::x509::my_cert_only_key')}"
    CN: 'my-cert'
    trocla_key: my_cert
      keyonly: true

This will lookup one trocla key: my_cert, but with different rendering options, so that once we only get the certificat, while on the second lookup we get the private key.

Other classes


This is a class that manages a trocla configuration. You might use this one if you do not use the default yaml setup.


This class manages the installation of trocla itself. It will not configure trocla, it will just install the necessary packages.


RTFC and for more information about trocla visit: