0
votes

I've been successfully using the custom psagers/ansible-ldap module for a while now. Just recently, though, I started running into a problem with it that I can't seem to get past. Anyone know what might cause the following error?

TASK [ldap-server : ldap_entry] ************************************************
fatal: [52.90.82.65]: FAILED! => {"changed": false, "exc": "Traceback (most recent call last):\n File \"/tmp/ansible_arqhOa/ansible_module_ldap_entry.py\", line 133, in main\n LdapEntry(module).main()\n File \"/tmp/ansible_arqhOa/ansible_module_ldap_entry.py\", line 194, in main\n action()\n File \"/tmp/ansible_arqhOa/ansible_module_ldap_entry.py\", line 206, in \n action = lambda: self.connection.add_s(self.dn, modlist)\n File \"/usr/lib/python2.7/dist-packages/ldap/ldapobject.py\", line 194, in add_s\n msgid = self.add(dn,modlist)\n File \"/usr/lib/python2.7/dist-packages/ldap/ldapobject.py\", line 191, in add\n return self.add_ext(dn,modlist,None,None)\n File \"/usr/lib/python2.7/dist-packages/ldap/ldapobject.py\", line 176, in add_ext\n return self._ldap_call(self._l.add_ext,dn,modlist,RequestControlTuples(serverctrls),RequestControlTuples(clientctrls))\n File \"/usr/lib/python2.7/dist-packages/ldap/ldapobject.py\", line 99, in _ldap_call\n result = func(*args,**kwargs)\nPARAM_ERROR: {'matched': 'dc=hhsdevcloud,dc=us', 'desc': 'Bad parameter to an ldap routine'}\n", "failed": true, "msg": "{'matched': 'dc=hhsdevcloud,dc=us', 'desc': 'Bad parameter to an ldap routine'}"}

Seems to be related to moving from Ansible 2.0.1.0 to 2.2.0.0. It's coming from this Ansible task, which hasn't changed (and was working before the Ansible version bump):

- ldap_entry: 
    bind_dn: 'cn=admin,dc=hhsdevcloud,dc=us'
    bind_pw: "{{ ldap_root_password }}"
    dn: 'ou=people,dc=hhsdevcloud,dc=us'
    objectClass: ['organizationalUnit']

If I had to guess, it's related to how this module handles args (e.g. objectClass isn't defined as a module arg, yet the module is designed to find it and use it). Did Ansible change how module args are handled recently?

1

1 Answers

0
votes

Figured it out and fixed it -- it was just a bug with the Ansible module. The module was passing some objects of the wrong type to the python-ldap library that does most of the heavy lifting (but only with Ansible 2.2, for some reason).

I fixed it in my fork of the library here: https://github.com/karlmdavis/ansible-role-ldap.

As an added bonus, that fork now has actual test coverage for the module (courtesy Travis CI).