Adding LDAP modules with ldap_entry fails when module already exists

[aeneby]

Summary

It is possible to add/load modules in LDAP using ldap_entry. However, it is not idempotent, since subsequent runs fail with "Entry action failed".

This seems to be due to a failure to detect the original entry, after a list order component ("{n}") is added to the DN in the LDAP database by slapd. I am not sure, but it may have something to do with issue #7646, as some code in ldap_entry expects this list component to immediately follow an equals sign, which in the case of LDAP modules, it doesn't. Example:

dn: cn=module{0},cn=config

Issue Type

Bug Report

Component Name

community.general.ldap_entry

Ansible Version

$ ansible --version
ansible 2.10.8
  config file = None
  configured module search path = ['/home/ubuntu/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3/dist-packages/ansible
  executable location = /usr/bin/ansible
  python version = 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0]

Community.general Version

$ ansible-galaxy collection list community.general

# /home/ubuntu/.ansible/collections/ansible_collections
Collection        Version
----------------- -------
community.general 8.0.2

# /usr/lib/python3/dist-packages/ansible_collections
Collection        Version
----------------- -------
community.general 1.3.6

Configuration

$ ansible-config dump --only-changed

OS / Environment

Ubuntu 22.04,

Steps to Reproduce

- name: Demonstrate ldap_entry's inability to detect existing LDAP modules
  hosts: localhost
  connection: local
  tasks:
    - name: Load memberof module
      become: yes
      community.general.ldap_entry:
        dn: cn=module,cn=config
        objectClass:
          - olcModuleList
        attributes:
          cn: module
          olcModuleLoad: memberof
          olcmodulepath: /usr/lib/ldap

First run of the above playbook succeeds, creating the following entry:

dn: cn=module{1},cn=config
objectClass: olcModuleList
cn: module{1}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}memberof
structuralObjectClass: olcModuleList

Subsequent runs produce an error:

PLAY [Demonstrate ldap_entry's inability to detect existing LDAP modules] ********************************

TASK [Gathering Facts] ***********************************************************************************
ok: [localhost]

TASK [Load memberof module] ******************************************************************************
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: ldap.OTHER: {'desc': 'Other (e.g., implementation specific) error', 'info': '<olcModuleLoad> handler exited with 1'}
fatal: [localhost]: FAILED! => {"changed": false, "details": "{'desc': 'Other (e.g., implementation specific) error', 'info': '<olcModuleLoad> handler exited with 1'}", "msg": "Entry action failed."}

PLAY RECAP ***********************************************************************************************
localhost                  : ok=1    changed=0    unreachable=0    failed=1    skipped=0    rescued=0    ignored=0

Modifying the playbook so that dn contains the X order component (i.e. dn: cn=module{1},cn=configproduces the expected behaviour:

PLAY [Demonstrate ldap_entry's inability to detect existing LDAP modules] ********************************

TASK [Gathering Facts] ***********************************************************************************
ok: [localhost]

TASK [Load memberof module] ******************************************************************************
ok: [localhost]

PLAY RECAP ***********************************************************************************************
localhost                  : ok=2    changed=0    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

Expected Results

Ansible detects that the entry already exists, albeit with a list order component in the DN, and continues with the rest of the playbook.

Actual Results

Ansible tries to create the LDAP object and fails due to it already existing.

Code of Conduct

• I agree to follow the Ansible Code of Conduct

[ansibullbot]

Files identified in the description:

• plugins/modules/ldap_entry.py

If these files are incorrect, please update the component name section of the description or use the !component bot command.

click here for bot help

[ansibullbot]

cc @jtyr
click here for bot help

[aeneby]

I'm kind of confused about this. The problem seems to have been addressed in #5450 , but I'm failing to see the expected behaviour. Perhaps I'm misunderstanding something here.

@mrvanes would you have expected the above example to work after your PR?

[mrvanes]

The problem is, since the incarnation of my PR's apparently some changes have been added (I never used regex's and did not introduce xorder_discovery parameter?) so not sure where they stand with this plugin at the moment. I do know it still "works for me", whatever that means for whatever ansible version and tasks we use at the moment?

[felixfontein]

xorder_discovery was introduced in #6109 to fix #6045.