[bitnami/openldap] Multimaster Replication with TLS

[mohjam2004]

Name and Version

bitnami/openldap:2.6.6

What architecture are you using?

amd64

What steps will reproduce the bug?

I have 2 VMs and I have setup ldap container on both VMs. The docker-compose file to start ldap container is as follows: (container_name for the second server is ldap2)

[root@docker1 ~]# cat docker-compose.yml
version: '3'
services:
  openldap:
    image: bitnami/openldap:2.6.6
    #network_mode: host
    container_name: ldap1
    ports:
     - "389:1389"
     - "636:1636"
    environment:
      - LDAP_EXTRA_SCHEMAS=yes
      - LDAP_EXTRA_SCHEMAS=cosine,inetorgperson,nis,ppolicy
      - LDAP_CONFIGURE_PPOLICY=yes
      - LDAP_ENABLE_SYNCPROV=yes
      - LDAP_ENABLE_TLS=yes
      - LDAP_REQUIRE_TLS=yes
      - LDAP_TLS_CERT_FILE=/opt/bitnami/openldap/certs/server.crt
      - LDAP_TLS_KEY_FILE=/opt/bitnami/openldap/certs/server.key
      - LDAP_TLS_CA_FILE=/opt/bitnami/openldap/certs/server.crt
      - LDAP_CUSTOM_LDIF_DIR=/bitnami/openldap/config.ldif

    volumes:
      - /data/openldap/openldap-data:/bitnami/openldap/
      - /data/openldap/certs:/opt/bitnami/openldap/certs
      - /etc/hosts:/etc/hosts:ro

but the configuration doesn't apply.

I have added hosts file to resolve host to ip address: /etc/hosts:/etc/hosts:ro

I have added base dn, admin user/pass in config.ldif file: /bitnami/openldap/config.ldif

What is the expected behavior?

I expect that multimaster replication works fine and when i add ldif config/user and config/users apparears on both ldap servers the same.

What do you see instead?

[root@docker1 ~]# docker logs -f ldap1
 15:01:55.76 INFO  ==> ** Starting LDAP setup **
 15:01:55.81 INFO  ==> Validating settings in LDAP_* env vars
 15:01:55.82 INFO  ==> Initializing OpenLDAP...
 15:01:55.83 INFO  ==> Creating LDAP online configuration
 15:01:55.84 INFO  ==> Creating slapd.ldif
 15:01:55.87 INFO  ==> Starting OpenLDAP server in background
 15:01:56.88 INFO  ==> Configure LDAP credentials for admin user
 15:01:56.90 INFO  ==> Adding LDAP extra schemas
 15:02:15.77 INFO  ==> ** Starting LDAP setup **
 15:02:15.81 INFO  ==> Validating settings in LDAP_* env vars
 15:02:15.82 INFO  ==> Initializing OpenLDAP...
 15:02:15.84 INFO  ==> Using persisted data
 15:02:15.84 INFO  ==> ** LDAP setup finished! **
 15:02:15.88 INFO  ==> ** Starting slapd **
65996b77.35823019 0x7f62abe99740 @(#) $OpenLDAP: slapd 2.6.6 (Aug 18 2023 23:33:58) $
        @a67812f7d14b:/bitnami/blacksmith-sandox/openldap-2.6.6/servers/slapd
65996b77.3636fb28 0x7f62abe99740 slapd starting

---

root@e4d5b8e0e817:/# ldapsearch -x -H ldapi://
# extended LDIF
#
# LDAPv3
# base <> (default) with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 32 No such object

# numResponses: 1
root@e4d5b8e0e817:/#

---

Even in ldap server 1, I can't find users and settings I have imported as config.ldif file. how can i configure multimaster with TLS by bitnami/openldap container?

Additional information

No response

[javsalgar]

Hi,

As far as I know, the container does not contain env vars for auto-configuring multi-master replication. At the moment we do not have plans to add support to this feature, but if you want you can submit a PR adding support for it and the team will review it.

[zerowebcorp]

@mohjam2004 I am on the same boat. I was researching on a way to get multi-master replication working with bitnami openldap image, but it doesn't support it at this time.

I see osixia docker-openldap image supports it out of the box with a simple configuration https://github.com/osixia/docker-openldap/blob/master/image/environment/default.startup.yaml#L46C1-L46C29

This should have been easy to add in the bitnami image by the upstram maintainer, but I am not sure why it wasn't planned.

[github-actions[bot]]

This Issue has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thanks for the feedback.

[github-actions[bot]]

Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Issue. Do not hesitate to reopen it later if necessary.