Ansible Error – “NSPlaceholderDate initialize may have been in progress in another thread when fork() was called”

If you have came across the same error as I did  ( error below ) then solving this might be easier than you think

TASK [Test credstash lookup plugin -- get the password with a context defined here] ***********************************************************************************************************************************************************************************************
objc[6763]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called.
objc[6763]: +[__NSPlaceholderDate initialize] may have been in progress in another thread when fork() was called. We cannot safely call it or ignore it in the fork() child process. Crashing instead. Set a breakpoint on objc_initializeAfterForkError to debug.

You just need to run the following ( https://github.com/ansible/ansible/issues/31869 )





Redhat 7 – LDAP authentication using Ansible

Hey! Recently along with Sanderv32 we have been trying to get LDAP authentication working on Redhat machines. I must admit that we have spent some quite looking for more structured and decent information how to get this working. However up to our surprise information were completely inaccurate or outdated.

So without big delays we have decided to tackle this challenge using Ansible. Of course first attempts were just to get the idea working. As we were moving our playbook were growing to reach stage at which we could deploy LDAP authentication mechanism to all of our RedHat 7 systems

Below is the output of the runbook being used:

    - name: "LDAP Authentication | Install the required packages"
      yum: >
        - "nss-pam-ldapd"
        - "oddjob"
        - "oddjob-mkhomedir"
        - "ldap"
        - "packages"
        - "packages_ldap"

    - name: "LDAP Authentication | Ensure services are running"
        - "nscd"
        - "nslcd"
        - "oddjobd"
      register: services_ldap
        - "ldap"
        - "services_ldap"

    - name: "Debug | Display results"
      debug: msg="{{services_ldap.results}}"
        - "ldap"

    - name: "LDAP Authentication | Enable LDAP PAM modules"
      command: "authconfig --enableldap --enableldapauth --enablemkhomedir --update"
        - "ldap"

    - name: "LDAP Authentication | Adding configuration templates"
      template: >
        - "nslcd.conf"
        - "ldap"
        - "repository"
        - "repository_ldap"
        - restart services ldap

And associated handler

  - name: "restart services ldap"
    service: >
    with_items: services_ldap.results
      - "ldap"
      - "services_ldap"


In the above I have highlighted the part which we use to template NLSCD config file. The file contents are completely overwritten so make sure you adjust it to your needs.

This template has been used to connect to Active Directory with dedicated bind user and modified pagesize ( so our results are not trimmed )

# {{ ansible_managed }}
uid nslcd
gid ldap

uri {{ ldap.uri }}
base {{ ldap.basedn }}
binddn {{ ldap.binduser }}
bindpw {{ ldap.binduserpw }}
scope sub
tls_reqcert allow

pagesize 10000
referrals off
idle_timelimit 800
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    passwd uid              sAMAccountName
map    passwd homeDirectory    unixHomeDirectory
map    passwd gecos            displayName
map    passwd loginShell       "/bin/bash"
filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
map    shadow uid              sAMAccountName
map    shadow shadowLastChange pwdLastSet
filter group  (objectClass=group)

ssl no
tls_cacertdir /etc/openldap/cacerts



Thats it folks! If it would not work with you please leave some comments as this is used to make sure we have means of using LDAP auth on Linux boxes



Ansible – Using template lookup

For some of actions / modules / roles it might be that you would like to use your Jinja template as variable. I have been looking some time for this lookup module. Therefore to save you from crawling over internet this is how could you use it

Example of Jinja template

  location ~ \.php$ {
    try_files $uri =404;
    root           /var/www/htdocs/;
    fastcgi_pass   unix:/var/run/php65-php-fpm.sock;
    fastcgi_intercept_errors        on;
    fastcgi_buffers 256 16k;
    fastcgi_max_temp_file_size 0;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include        fastcgi_params;

    {% if env is defined and env=="testos" %}
    auth_basic           "Ninja Test ";
    auth_basic_user_file {{ nginx_basic_auth }} ;
    {% endif %}

And then within our playbook we define it as following

- name: Testing
  hosts: localhost
    - blabla: "Testing123"
    - testing: "{{ lookup('template', 'template.j2') }}"

  - debug: msg="{{testing}}"


Are you using this in other way ? Comment whats your approach 🙂


Ansible – Using dictionary to deploy pem certificates

When automating certificate deployments I wanted to have smart way of deploying them. So I went ahead and decided to use dictionaries.

For this example my variables looked more like as following :

      owner: haproxy
      group: haproxy
      mode: "u=r,go="
      certificate: |
                                              -----BEGIN CERTIFICATE-----
                                              < ..................... bogus info uno ...................... >
                                                -----END CERTIFICATE-----
      key: |
                                              -----BEGIN PRIVATE KEY-----
                                              < ..................... bogus info uno ...................... >
                                              -----END PRIVATE KEY-----
      owner: haproxy
      group: haproxy
      mode: "u=r,go="
      certificate: |
                                              -----BEGIN CERTIFICATE-----
                                              < ..................... bogus info duo ...................... >
                                                -----END CERTIFICATE-----
      key: |
                                              -----BEGIN PRIVATE KEY-----
                                              < ..................... bogus info duo ...................... >
                                              -----END PRIVATE KEY-----


Once we have that within our playbook we will be using the following actions to create ourselves pem files

       - name: SSL certificates Web | Create certificate key files
           dest: "{{web_ssl_folder}}/{{ item.key.replace('_','.') }}.pem"
           content: "{{ item.value.certificate + '\n' + item.value.key }}"
           owner: "{{ item.value.owner }}"
           group: "{{ item.value.group }}"
           mode: "{{ item.value.mode }}"
         with_dict: ssl_certificates
         no_log: true


Now when we run our playbook what will happen is we will get within folder defined under web_ssl_folder  new certificates called respectively domain.uno.com.pem and domain.duo.com.pem.

Of course if you add more entries you will get more created. So for you the only thing to change from here is the owner and possibly the rights ( although think twice 🙂 )


Ansible role for Redhat 7 CIS baseline

A Compliance fuel gauge with needle pointing to Follow the Rules to illustrate being compliant with regulations, guidelines and standards


If you are working with environments where certain policies and rules needs to be applied something like CIS baselines will be well known to you.

So it works on basis where you define which points you will apply to your system and from that point onwards you are expected to deliver proof that this is how ur systems are now compliant (or not ) and if you do not apply certain settings what is the reason for it .

However the problem comes when you need to enforce this compliancy on multiple systems and make sure they are all happily running this policies.


And here comes the really good part – where you take a configuration management tool like Ansible and create a reusable piece of code which defines your infrastructure. Although looking at CIS baseline documents – if you are to start from zero that would be a lot of work … but …. good friend of mine has spent his time preparing CIS baseline for Redhat 7 which is no available on github in his repository HERE 🙂


And for much more interesting info you can always look at his blog under https://blog.verhaar.io


Screenshot 2016-03-22 23.07.16






Ansible – IP addresses of all nodes in group

I have been searching this for a while especially when I was setting up GlusterFS. Challenge of getting all IPs of hosts within my group of ansible.

Maybe not the prettiest and elegant solution however does perfectly what is it expected from. Sets variable of IP addresses ( in my example I’m using eth0 address of IPv4 ) and join them into comma seperated result.



If you have a better approach – please leave a comment as I’m quite interested to read how you tackle this challenge 🙂



Ansible – ‘DEFAULT_DOCKER_API_VERSION’ is not defined

Working on daily basis with DevOps causes you to automate a lot of work. Now one of recent orchestration tools by me is Ansible. I’m not saying THIS IS THE TOOL to go :) but it for sure have a lot of potential.

So I decided to use it to deploy services also leveraging docker … but then I received error message :


NameError: global name ‘DEFAULT_DOCKER_API_VERSION’ is not defined

  - name: install the required packages
    apt: name=python-pip state=present update_cache=yes
  - name: Install docker-py as a workaround for Ansible issue
    pip: name=docker-py version=1.2.3