Ask Your Question

Environment from ldap not used/set.

asked 2017-11-28 06:53:59 -0600

PvdM gravatar image

I want to migrate/rebuild our exisiting puppet 3.8 environment to be more up-to-date and have it more structured without too much impact on the existing environment. This old environment uses ldap-stored environment settings, and for some machines also some puppetclasses. However getting ldap to work within the new setup is challenging as the official documentation (link:here) is limited and basicly incorrect. The old version works with the current ldap data, and according to various other resources that data is complete. No doubt to question that, as I checked it with ldapsearch.

I installed puppetserver 5.1.4 and the agent 5.3.3 onto a fresh machine. And made the following changes:
* pointed the cert.pem to the system one as it also contains the certificate for our proxy, otherwise module-actions would be impossible.
* installed jruby-ldap-patched (puppetserver gem install jruby-ldap-patched) The documentation refers to the 12 year old ruby-ldap, which won't work with the java based puppetserver. The jruby-ldap is able to query the ldapserver, but can't handle the results properly. (I saw the query in the ldap logs, but didn't get a sensible response)

What I do expect to see is: (old client to old server)

# puppet agent -t --noop
Warning: Local environment: "production" doesn't match server specified node environment "lab", switching agent to "lab".
Info: Retrieving pluginfacts
Info: Retrieving plugin

What I see: (new server and agent)

# puppet agent -t --noop 
Info: Using configured environment 'production' 
Info: Retrieving pluginfacts 
Info: Retrieving plugin 
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Cannot reassign variable '$environment' on node myhost.mydomain.lab 
Warning: Not using cache on failed catalog Error: Could not retrieve catalog; skipping run

I'm testing my agent on the same machine as my puppetserver, so the config is combined:

# cat puppet.conf
        vardir = /opt/puppetlabs/server/data/puppetserver
        logdir = /var/log/puppetlabs/puppetserver
        rundir = /var/run/puppetlabs/puppetserver
        pidfile = /var/run/puppetlabs/puppetserver/
        codedir = /etc/puppetlabs/code

        autosign = true
        pluginsync = true

        # ldap config
        node_terminus = ldap
        ldapserver = ldap.mydomain.lab
        ldapbase = ou=Servers,dc=my-securedomain,dc=net
        ldapstring = (&(objectclass=puppetClient)(cn=%s))
        ldapclassattrs = puppetClass
        ldapattrs = all

        certname = myhost.mydomain.lab
        dns_alt_names = puppet,puppet.mydomain.lab,myhost.mydomain.lab,myhost
        run_interval = 3600

        server = myhost.mydomain.lab

What did I miss, or did I stumble upon a bug?
Any good links on how to accomplish this task using an hiera-ldap ENC are also welcomed.

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

answered 2017-12-20 08:10:36 -0600

PvdM gravatar image

Finally got some time to dig a bit deeper into my own problem. It seems that ldap support seems to be broken by default, which in my opinion is really a shame. I decided to research the ENC-route. I found ( a sample script, which read certain values from the fqdn, and reformatted it to the correct ouput. I've adapted it to do an ldapsearch, store the results in a tempory file and format it to be used by puppet.

# This script is based on
ldapsearch -h -b ou=Servers,dc=company,dc=lan -x -LLL -ZZ "(&(objectclass=puppetClient)(cn=${CERTNAME}))" environment puppetclass repo >/tmp/puppetserver/${CERTNAME}.ldif

ENVIRONMENT="$(awk '/environment:/ { print $2}' /tmp/puppetserver/${CERTNAME}.ldif)"
CLASSES="$(awk '/puppetclass:/ { print $2}' /tmp/puppetserver/${CERTNAME}.ldif)"
REPOS="$(awk '/abxrepo:/ { print $2}' /tmp/puppetserver/${CERTNAME}.ldif)"

#### Output the yaml ...
export CLASSES
export REPOS

echo -e "---\nclasses:";
for aClass in $CLASSES; do
  echo "  - $aClass";
if [ -n "$ENVIRONMENT" ]; then
  echo "environment: $ENVIRONMENT"
echo "parameters:"
echo "  repositories:"
for aRepo in ${REPOS};do
  echo "    - ${aRepo}";

rm -f /tmp/puppetserver/${CERTNAME}.ldif
exit 0

Use it in your master like this:

  node_terminus = exec
  external_nodes = /etc/puppetlabs/code/hiera/

This functions just like the old ldap-support, and allows for more attributes to be stored in ldap, with just little work to this script. I can anonymously read the server-tree in our ldap, of course I prefer to do this secure in this case with StartTLS. Test your searches with just an ldapsearch, and you can test the script also manually.


It will return the results in a similar style:

  - common-base
environment: lab
    - EL-Our-tools
    - CentOS7-base
    - CentOS7-updates
    - EL-Tools-puppet5
    - EL-Tools-nagios

I would have prefered to do everything in memory, but the ldap-results are slightly different formatted if you pass them through to other commands. If the disk bound operations will be a problem, I can always create a FS in memory and store the files there.

I hope this might be helpful to some others.

edit flag offensive delete link more


I wonder if you should open up an issue over at and get it on the puppet team's radar... If the functionality is broken it should either be fixed or removed/deprecated.

DarylW gravatar imageDarylW ( 2017-12-20 10:23:22 -0600 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2017-11-28 06:53:59 -0600

Seen: 30 times

Last updated: Dec 20 '17