[bitnami/openldap] LDAP_CUSTOM_LDIF_DIR is not loaded correctly.

Grustamli commented 1 year ago

Name and Version

bitnami:openldap:2.6.3

What steps will reproduce the bug?

version: '2'

networks:
  my-network:
    driver: bridge
services:
  openldap:
    image: bitnami/openldap:2.6.3
    ports:
      - '1389:1389'
      - '1636:1636'
    environment:
      - LDAP_ADMIN_USERNAME=admin
      - LDAP_ADMIN_PASSWORD=adminpassword
      - LDAP_CUSTOM_LDIF_DIR=/ldifs
    networks:
      - my-network
    volumes:
      - 'openldap_data:/bitnami/openldap'
      - './ldifs:/ldifs'
  myapp:
    image: 'YOUR_APPLICATION_IMAGE'
    networks:
      - my-network
volumes:
  openldap_data:
    driver: local

./ldifs directory contains test.ldif file:

dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organization
o: Example, Inc

dn: ou=users,dc=example,dc=com
ou: users
objectClass: organizationalunit

dn: cn=Robert Smith,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob smith
sn: smith
uid: rjsmith
userpassword: rJsmitH
mail: r.smith@example.com

When I /bin/bash into the container I can see the /ldifs directory is there as expected containing the test.ldif. And logs show that the CUSTOM_LDIF_DIR is used.

What is the expected behavior?

Expected to load the user data from test.ldif

What do you see instead?

ldapsearch from ldaputils still shows me the default users, user01, user02 and not the users from my test.ldif.

Additional information

This issue is related to the issue: https://github.com/bitnami/bitnami-docker-openldap/issues/107

Grustamli commented 1 year ago

Is there any progress on this?

corico44 commented 1 year ago

Hello @Grustamli, I can't reproduce the error. Could you tell me the ldapsearch command that you are executing to check the added users, please?

Grustamli commented 1 year ago

Hi, @corico44. I am using this command: ldapsearch -x -b "dc=example,dc=com" -H ldap://0.0.0.0:1389. I get this result:

# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

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

iainworkman commented 1 year ago

I am also experiencing the same issue. The container appears to error during start the first time through (e.g. with openldap_data volume empty in the above example), and exits. After that it starts correctly, but does not appear to have loaded the data.

First time log:

identity-ldap-server  |  02:27:28.35 INFO  ==> ** Starting LDAP setup **
identity-ldap-server  |  02:27:28.41 INFO  ==> Validating settings in LDAP_* env vars
identity-ldap-server  |  02:27:28.45 INFO  ==> Initializing OpenLDAP...
identity-ldap-server  |  02:27:28.50 INFO  ==> Creating LDAP online configuration
identity-ldap-server  |  02:27:28.80 INFO  ==> Starting OpenLDAP server in background
identity-ldap-server  |  02:27:29.81 INFO  ==> Configure LDAP credentials for admin user
identity-ldap-server  |  02:27:29.85 INFO  ==> Adding LDAP extra schemas
identity-ldap-server  |  02:27:29.91 INFO  ==> Loading custom LDIF files...
identity-ldap-server  |  02:27:29.91 WARN  ==> Ignoring LDAP_USERS, LDAP_PASSWORDS, LDAP_USER_DC and LDAP_GROUP environment variables...

Then it exits with code 123

iainworkman commented 1 year ago

I appear to have this working, with a few minor tweaks to the docker-compose.yml file, and a caveat:

The trick seemed to be:

Recognizing that the first time run will always crash, but the second time around would have the user's loaded (see the run command at the bottom)
If not using the default LDAP_ROOT in your ldif files, then you'll need to set that in the compose (you use dc=example,dc=com where the default is dc=example,dc=org). This appears to be the case even if you create the org in your import.

The Docker Compose

 version: '2'

 services:
   openldap:
     image: bitnami/openldap:2.6.3
     container_name: openldap
     ports:
       - '1389:1389'
       - '1636:1636'
     environment:
       - LDAP_ROOT=dc=example,dc=com
       - LDAP_ADMIN_USERNAME=admin
       - LDAP_ADMIN_PASSWORD=adminpassword
       - LDAP_CUSTOM_LDIF_DIR=/ldifs
     volumes:
       - 'openldap_data:/bitnami/openldap'
       - './ldifs:/ldifs'

 volumes:
   openldap_data:
     name: openldap_data
     driver: local

Really the only fixing change here is the addition of the LDAP_ROOT

Other changes (to make it easier to play around with, and make the run command below work) were:

Removed the other app, since I was just testing LDAP things,
Removed the network, since I only had one container in the stack,
Gave the volume a name, so I could delete it in my command (the volume has to be empty for the ldif files to be read)

The command I then used to run was:

docker-compose down && docker volume rm openldap_data ; docker-compose up -d && sleep 5 && docker-compose up -d && sleep 5 && docker exec -it openldap bash

This:

stops the stack,
removes the named ldap persistant data volume, if it already exists,
brings up the stack for the first time (this will crash)
sleeps for 5, to allow it time to crash
reloads the container
sleeps for 5 to give it time to get itself together
execs in, so you can run the test command.

Once that's running, the search you provided returned the following:

I have no name!@379263b465e9:/$ ldapsearch -x -b "dc=example,dc=com" -H ldap://0.0.0.0:1389
# extended LDIF
#
# LDAPv3
# base <dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# example.com
dn: dc=example,dc=com
dc: example
objectClass: dcObject
objectClass: organization
o: Example, Inc

# users, example.com
dn: ou=users,dc=example,dc=com
ou: users
objectClass: organizationalUnit

# Robert Smith, users, example.com
dn: cn=Robert Smith,ou=users,dc=example,dc=com
objectClass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob smith
sn: smith
uid: rjsmith
userPassword:: ckpzbWl0SA==
mail: r.smith@example.com

# search result
search: 2
result: 0 Success

# numResponses: 4
# numEntries: 3

Hope that gets you moving.

corico44 commented 1 year ago

@Grustamli, could you confirm that this configuration works correctly for you, please?

Grustamli commented 1 year ago

@corico44, I haven't got a chance to check it yet. But I agree with @iainworkman that the container stops first time after fresh build. I will try it today and write a feedback.

Grustamli commented 1 year ago

Indeed @iainworkman's solution works as expected.

corico44 commented 1 year ago

I'm glad it worked @Grustamli. So, I will close this issue. Feel free to open another issue if you need it.

soullivaneuh commented 1 year ago

@corico44 May we re-open the issue please? I experimented the same things and according to my reading, the only solution is to re-start the container and hope the data will pass.

This is not a solution, this is a workaround.

Also, this workaround is not working on my side. My docker-compose config:

ldap:
  image: ${IMAGE_NAME}/ldap:${IMAGE_TAG}
  build: docker/ldap
  environment:
    - LDAP_ROOT=dc=company,dc=net

The related Dockerfile:

FROM bitnami/openldap:2.6.4
USER root

RUN apt-get update \
    && apt-get install --yes --no-install-recommends shelldap=1.* \
    && rm --recursive --force /var/lib/apt/lists/*

USER 1001
COPY .shelldap.rc /.shelldap.rc
COPY ldifs/test.ldif /ldifs/test.ldif

The related test.ldif file content (basically a copy/paste of @Grustamli sample):

dn: dc=company,dc=net
dc: example
objectClass: dcObject
objectClass: organization
o: Example, Inc

dn: ou=users,dc=company,dc=net
ou: users
objectClass: organizationalunit

dn: cn=Robert Smith,ou=users,dc=company,dc=net
objectClass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob smith
sn: smith
uid: rjsmith
userpassword: rJsmitH
mail: r.smith@example.com

Same situation: It crash the first time (127), then looks to work but without any loaded data.

Update: Same situation with latest 2.6.4 release usage.

soullivaneuh commented 1 year ago

So I did dump the generated /opt/bitnami/openldap/tree.ldif and put it back as a custom file: it works.

After some compare with the previous sample, it looks like the root creation was missing:

dn: dc=company,dc=net
objectClass: dcObject
objectClass: organization
dc: company
o: Company SAS

Here is my complete ldif file as a sample:

version: 1

# Root creation
dn: dc=company,dc=net
objectClass: dcObject
objectClass: organization
dc: company
o: Company SAS

# Domains
dn: ou=domains,dc=company,dc=net
objectClass: organizationalUnit
ou: domains

# Mailboxes
dn: ou=mailboxes,dc=company,dc=net
objectClass: organizationalUnit
ou: mailboxes

# Forwards
dn: ou=forwards,dc=company,dc=net
objectClass: organizationalUnit
objectClass: top
ou: forwards

So solution found for my case, without any restart. However, the issue should be re-open or maybe be a new one to improve the verbosity about the error in my opinion.

ice09 commented 1 year ago

I still have the issue still exactly as described with version 2.6.6. As described the startup is alternating, first it fails with exit code 123 after WARN ==> Ignoring LDAP_USERS, LDAP_PASSWORDS, LDAP_USER_DC and LDAP_GROUP environment variables..., then on down and up it works, then down and up again and it fails, etc.

andresbono commented 1 year ago

In https://github.com/bitnami/containers/issues/15370#issuecomment-1587455587, some details were shared and a solution was found, without any restart. Would that work for you?

github-actions[bot] commented 1 year ago

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] commented 1 year ago

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.

ice09 commented 1 year ago

In #15370 (comment), some details were shared and a solution was found, without any restart. Would that work for you?

No, I couldn't get it running in a stable way. I switched to osixia/openldap which works for me.

lucs-t commented 9 months ago

I think I may have solved the problem.

version: '3'
services:
    openldap:
        image: bitnami/openldap
        container_name: openldap
        ports:
            - 1389:1389
            - 1636:1636
        environment:
            LDAP_ROOT: "dc=example,dc=com"
            LDAP_ADMIN_USERNAME: "admin"
            LDAP_ADMIN_PASSWORD: "123456"
            LDAP_EXTRA_SCHEMAS: "cosine,inetorgperson"
            LDAP_CUSTOM_SCHEMA_FILE: "/etc/schemas.ldif"
            LDAP_CUSTOM_LDIF_DIR: "/ldifs"
        volumes:
            - ./schemas/schemas.ldif:/etc/schemas.ldif
            - ./ldifs:/ldifs

There is only one file init.ldif in the ldifs folder

dn: ou=users,dc=example,dc=com
objectClass: organizationalRole
objectClass: top
ou: users
cn: users

dn: ou=groups,dc=example,dc=com
objectClass: organizationalRole
objectClass: top
ou: groups
cn: groups

hope this helps

tiffmaelite commented 5 months ago

I am also encountering this same infuriating issue with the latest version of bitnami/openldap docker image (2.6.8-0)... I am also strongly in favor of improving the logging verbosity of the LDIF file load.

So I did dump the generated /opt/bitnami/openldap/tree.ldif and put it back as a custom file: it works.

@soullivaneuh there is no generated /opt/bitnami/openldap/tree.ldif file for me. Which content does it have? Should I try copying ldifs/my-ldap.ldif into /opt/bitnami/openldap/tree.ldif? Or was your initial file named tree.ldif?

I think I may have solved the problem.

version: '3'
services:
    openldap:
        image: bitnami/openldap
        container_name: openldap
        ports:
            - 1389:1389
            - 1636:1636
        environment:
            LDAP_ROOT: "dc=example,dc=com"
            LDAP_ADMIN_USERNAME: "admin"
            LDAP_ADMIN_PASSWORD: "123456"
            LDAP_EXTRA_SCHEMAS: "cosine,inetorgperson"
            LDAP_CUSTOM_SCHEMA_FILE: "/etc/schemas.ldif"
            LDAP_CUSTOM_LDIF_DIR: "/ldifs"
        volumes:
            - ./schemas/schemas.ldif:/etc/schemas.ldif
            - ./ldifs:/ldifs

There is only one file init.ldif in the ldifs folder

dn: ou=users,dc=example,dc=com
objectClass: organizationalRole
objectClass: top
ou: users
cn: users

dn: ou=groups,dc=example,dc=com
objectClass: organizationalRole
objectClass: top
ou: groups
cn: groups

hope this helps

@Apang-C Thank you for sharing your solution. Can you state what made the difference? Is it the custom schemas, or the absence of the root in the ldif file?

EDIT: after I deleted container AND volume and restarted it twice, then only did my configuration changes take effect, and the advice found in this issue thread finally revealed a working setup for me. In my case, there was LDAP_ADD_SCHEMAS=no which I needed to remove, since LDAP_ROOT was already defined and the root was already present as well in my ldif file.

bitnami / containers