0

I have a docker-compose.yml file that defines the services I need for my development environment. Recently, I have been focusing on setting up two services, that is, the osixia/openldap:1.5.0 and osixia/phpldapadmin:0.9.0 images.

The issues I have are:

  • Instead of the LDAP service being UP, it keeps on restarting
  • Within the log files of the LDAP service two errors are visible, and not-so-obvious
  • The phpLDAPAdmin doesn't seem to be able to connect with the LDAP service citing, Can't contact LDAP server (-1) for user

On the first point, I wondered for a while, whether the issue was not with my service definition entry, that is, restart: unless-stopped|no|never. I played around with the acceptable values and got no different behavior.

Then I went on to investigate the second point as I believed it might have an effect on the first issue. Upon inspecting my service's log file two issues came to light. Below are the two errors as they partially appear on the log file itself.

***  DEBUG  | 2023-10-27 19:15:01 | LDAP_TLS_KEY_FILENAME = ldap.key

***  DEBUG  | 2023-10-27 19:15:01 | LDAP_TLS_VERIFY_CLIENT = never

***  DEBUG  | 2023-10-27 19:15:01 | PATH = /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

***  DEBUG  | 2023-10-27 19:15:01 | SSL_HELPER_AUTO_RENEW_SERVICES_IMPACTED = slapd

***  DEBUG  | 2023-10-27 19:15:01 | ------------------------------------------

***  ERROR  | 2023-10-27 19:15:01 | /container/run/startup/slapd failed with status 1


***  DEBUG  | 2023-10-27 19:15:01 | Run commands before finish...

***  INFO   | 2023-10-27 19:15:01 | Killing all processes...

***  INFO   | 2023-10-27 19:15:01 | openldap user and group adjustments

***  INFO   | 2023-10-27 19:15:01 | get current openldap uid/gid info inside container

***  INFO   | 2023-10-27 19:15:01 | -------------------------------------

***  INFO   | 2023-10-27 19:15:01 | openldap GID/UID

***  INFO   | 2023-10-27 19:15:01 | -------------------------------------

***  INFO   | 2023-10-27 19:15:01 | User uid: 911

***  INFO   | 2023-10-27 19:15:01 | User gid: 911

***  INFO   | 2023-10-27 19:15:01 | uid/gid changed: false

***  INFO   | 2023-10-27 19:15:01 | -------------------------------------

***  INFO   | 2023-10-27 19:15:01 | updating file uid/gid ownership

***  ERROR  | 2023-10-27 19:15:01 | Error: the config directory (/etc/ldap/slapd.d) is empty but not the database directory (/var/lib/ldap)

On the second point, I had an idea of mounting a config.php file into the Container's slapd directory. The problem is that I have no idea how this file should look like.

Furthermore, I have made sure that within my service I add the LDAP_BASE_DN which equals dc=coolstuff-enterprise,dc=org for coolstuff-enterprise.org domain set.

  • Is dc=coolstuff-enterprise,dc=org the correct value to use as a username?
  • What possible issues there are if slapd errors with status 1?

enter image description here

I might be experiencing issues with the LDAP Admin system due to the fact I do not apprehend what username I should be using to access the LDAP service.

Below is my docker-compose.yml file with the relevant service definitions, network and volumes.

version: '3.8'

networks:
  coolstuff-enterprise-network:
    name: coolstuff-enterprise-network
    driver: bridge

volumes:
  
  openldap_data:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: '${HOME}/server/openldap/data'

  openldap_config:
    driver: local
    driver_opts:
      type: 'none'
      o: 'bind'
      device: '${HOME}/server/openldap/config'

services:

  openldap:
    image: osixia/openldap:1.5.0
    mem_limit: 128m
    container_name: coolstuff-ldap
    restart: unless-stopped
    volumes:
      - openldap_data:/var/lib/ldap
      - openldap_config:/var/lib/ldap/slapd.d
    environment:
      LDAP_ORGANISATION: CoolStuff Enterprise
      LDAP_DOMAIN: coolstuff-enterprise.org
      LDAP_BASE_DN: "dc=coolstuff-enterprise,dc=org"
      LDAP_ADMIN_PASSWORD: admin
      LDAP_CONFIG_PASSWORD: config
      LDAP_ROOT_PASSWORD: root
      LDAP_RFC2307BIS_SCHEMA: "true"
      LDAP_REMOVE_CONFIG_AFTER_SETUP: "true"
      LDAP_TLS_VERIFY_CLIENT: never
    command:
      - "--copy-service"
      - "--loglevel=debug"
    ports:
      - 9008:389
      - 7636:636
    networks:
      coolstuff-enterprise-network:
        aliases:
          - ldap-directory-service

  openldap-admin:
    image: osixia/phpldapadmin:0.9.0
    container_name: coolstuff-ldap-admin
    restart: "no"
    environment:
      PHPLDAPADMIN_LDAP_HOSTS: openldap
      PHPLDAPADMIN_HTTPS: "false"
    depends_on:
      - openldap
    ports:
      - 9007:80
      - 4443:443
    networks:
      coolstuff-enterprise-network:
        aliases:
          - openladp-admin

Lastly, below I show my docker-compose ps command output:

┌─[MacBook-Pro][~/devhouse/support/coolstuff-enterprise][feature/ladp-integration 😱]
└──╼ docker-compose ps
             Name                           Command                 State                          Ports
-----------------------------------------------------------------------------------------------------------------------------
coolstuff-admin                  docker-php-entrypoint php-fpm    Up           9000/tcp
coolstuff-admin-nginx            /docker-entrypoint.sh ngin ...   Up           0.0.0.0:9001->80/tcp
coolstuff-admin-rdbms            docker-entrypoint.sh mysqld      Up           0.0.0.0:9006->3306/tcp, 33060/tcp
coolstuff-broadcaster            node /app/bin/server.js start    Up           0.0.0.0:6001->6001/tcp, 0.0.0.0:9601->9601/tcp
coolstuff-idp-service-provider   docker-php-entrypoint apac ...   Up           80/tcp, 0.0.0.0:9002->8080/tcp
coolstuff-ldap                   /container/tool/run --copy ...   Restarting
coolstuff-ldap-admin             /container/tool/run              Up           0.0.0.0:4443->443/tcp, 0.0.0.0:9007->80/tcp
coolstuff-rdbms-admin            /docker-entrypoint.sh apac ...   Up           0.0.0.0:9004->80/tcp
coolstuff-smtp                   MailHog                          Up           0.0.0.0:8025->1025/tcp, 0.0.0.0:9005->8025/tcp

All services share the same coolstuff-enterprise-network.

What have I done wrong for my setup not to come to the party? Is there something I am missing with all these puzzle pieces?

1 Answer 1

1

On the first point, I wondered for a while, whether the issue was not with my service definition entry, that is, restart: unless-stopped|no|never. I played around with the acceptable values and got no different behavior.

That's not the problem. The problem isn't that your service is being restarted – that's good – the problem is that the service keeps exiting or crashing, which is actually why it's being restarted. The definition only controls how the system reacts to the service crash.

Within the log files of the LDAP service two errors are visible, and not-so-obvious

The first error, I highly suspect, happens when the container tries to call slapd to convert slapd.conf into the new config format (a separate step before slapd is started as an actual service).

The second error is most likely just fallout from the first one (i.e. config directory is empty because config conversion failed).

The phpLDAPAdmin doesn't seem to be able to connect with the LDAP service citing, Can't contact LDAP server (-1) for user

Yes, because there is no LDAP service yet. Ignore phpLDAPAdmin** until you've worked out why the service won't start – until then it's pointless to focus on the connection.

Is dc=coolstuff-enterprise,dc=org the correct value to use as a username?

Yes, if you want to log in as the "rootDN" (i.e. the built-in account that has unlimited access to the main database), then the username (bind DN) is usually the database's root DN.

The Docker image will most likely create a separate admin account, however (one that also has configuration access), but in the end all usernames in OpenLDAP are in DN form.

What possible issues there are if slapd errors with status 1?

Hundreds; too many to enumerate. It could be just a syntax error when the Docker image generates a slapd.conf, or something. You'll probably need to find where it puts the rest of slapd logs, and/or make it run slapd with an appropriate -d (debug) option.

I might be experiencing issues with the LDAP Admin system due to the fact I do not apprehend what username I should be using to access the LDAP service.

No, you're experiencing these issues because your LDAP service isn't even running yet.

Sign up to request clarification or add additional context in comments.

Comments

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.