New container failing to initiliase ldap

osixia / docker-openldap

OpenLDAP container image 🐳🌴

MIT License

4.02k stars 973 forks source link

New container failing to initiliase ldap #468

Open DRCornish opened 4 years ago

DRCornish commented 4 years ago

I am having issues trying to just start a container off of this image. I've used the following docker-compose file section:

` version: "2" services: ldap-server: build: context: $LDAPServerBuildDir args: LDAP_OPENLDAP_GID: $GroupID LDAP_OPENLDAP_UID: $UserID container_name: ldap-server command: --loglevel debug environment:

LDAP_OPENLDAP_UID=$UserID
LDAP_OPENLDAP_GID=$GroupID
LDAP_ORGANISATION=Temp
LDAP_DOMAIN=temp.local
LDAP_ADMIN_PASSWORD=temp volumes:
$AppsDir/swag/keys:/container/service/slapd/assets/certs
$AppsDir/ldap-server/db:/var/lib/ldap
$AppsDir/ldap-server/config:/etc/ldap/slapd.d ports:
3306:3306
636:636
389:389 restart: unless-stopped networks:
media `

On another ticket (Issue #467) I mentioned that on the first run it built correctly and then overrode my uid and gid. Ignoring this I just made the bound folders on a hard drive in the volume section 777 access for now as I thought it was maybe a folder access issue. However it still stalls at the "Init new ldap server..." stage:

` openldap user and group adjustments get current openldap uid/gid info inside container

openldap GID/UID

User uid: 911 User gid: 911 uid/gid changed: false

updating file uid/gid ownership Database and config directory are empty... Init new ldap server... `

daniel-lerch commented 3 years ago

Same problem here. I tried 1.4.0, 1.3.0 and 1.2.5 without success. If you run the container with --loglevel trace you can see that everything run fine until a call to dpkg-reconfigure -f noninteractive slapd. Running top inside of the container show two main processes dpkg-reconfigure and slapd.config which both constantly produce a quite high amount of CPU load. Normally such calls should not take more than 20 minutes on a system which is installed on an SSD.

Maybe there is a loop which retries the same activity again and again with a short timeout (high CPU usage) but fails every time.

daniel-lerch commented 3 years ago

The problem for me was caused by additional double-quotes in environment variables. Maybe you could add a check in startup.sh whether an environment variable contains double quotes instead of running an infinite loop with dpkg-reconfigure.

This compose file did not work:

version: '2'

services:
  image: osixia/openldap:1.4.0
  environment:
    - LDAP_DOMAIN="my.domain.com"
    - LDAP_ORGANISATION="Example Organisation"

But this one works:

version: '2'

services:
  image: osixia/openldap:1.4.0
  environment:
    - LDAP_DOMAIN=my.domain.com
    - LDAP_ORGANISATION=Example Organisation

DRCornish commented 3 years ago

Hi there, thanks for the input. Yeah I saw the some of the others issues when using string markers. Mine don't have string markers in them. It does seem to have started, maybe just very very slow to initialise?

pat-s commented 3 years ago

Thanks @daniel-lerch - got crazy about this.

Blizzke commented 3 years ago

Can confirm that double quotes made mine hang in the dpkg-reconfigure call as well. Removed the double quotes and it started up in 3 seconds flat.

@daniel-lerch seriously: if you lived anywhere nearby I would come over and kiss you (respectfully , not in a #metoo manner :-P ).

roland-d commented 1 year ago

@daniel-lerch What a find !!! Thank you, thank you and a happy new year :)