Environment from ldap not used/set.

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

PvdM
11 ●2

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
[master]
        vardir = /opt/puppetlabs/server/data/puppetserver
        logdir = /var/log/puppetlabs/puppetserver
        rundir = /var/run/puppetlabs/puppetserver
        pidfile = /var/run/puppetlabs/puppetserver/puppetserver.pid
        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

[main]
        certname = myhost.mydomain.lab
        dns_alt_names = puppet,puppet.mydomain.lab,myhost.mydomain.lab,myhost
        run_interval = 3600

[agent]
        pluginsync=true
        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.

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

PvdM
11 ●2

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 (https://github.com/elconas/puppet-pub...) 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.

#!/bin/bash
# This script is based on https://github.com/elconas/puppet-public-example/blob/master/enc/puppet_enc.sh
#
ldapsearch -h ldap.company.lan -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 ENVIRONMENT
export CLASSES
export REPOS

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

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

Use it in your master like this:

[master]
  node_terminus = exec
  external_nodes = /etc/puppetlabs/code/hiera/ldap-enc.sh

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.

/etc/puppetlabs/code/hiera/ldap-enc.sh testserver.company.lan

It will return the results in a similar style:

---
classes:
  - common-base
environment: lab
parameters:
  repositories:
    - 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

Comments

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