docker-openldap icon indicating copy to clipboard operation
docker-openldap copied to clipboard

When running as a swarm stack: bind(8) failed errno=99 (Cannot assign requested address)

Open Foxi352 opened this issue 6 years ago • 10 comments

I have running a container for some weeks now with the following startup command:

docker run --name openldap \
	-p 389:389 \
	--volume /var/local/openldap/ldap:/var/lib/ldap \
	--volume /var/local/openldap/slapd.d:/etc/ldap/slapd.d \
	--restart always \
	--hostname openldap \
	--detach \
	osixia/openldap:1.2.0

This works like a charm. Now i want to convert this container to a member service of a swarm stack. I am still on the same docker host. Only that i want to launch it as a service of swarm stack instead of a standard container. I copied the ldap and slapd.d into the new volumes to migrate data. Here is my compose file:

version: '3.2'
services:

    openldap:
        hostname: openldap
        image: osixia/openldap:1.2.0
        command: "--loglevel debug"
        
        ports:
            - '389:389'

        volumes:
            - openldap-db:/var/lib/ldap
            - openldap-slapd:/etc/ldap/slapd.d
            - /etc/localtime:/etc/localtime:ro
            
        environment:
            - LDAP_TLS=False

    phpldapadmin:
        hostname: phpldapadmin
        image: osixia/phpldapadmin:latest

        depends_on:
            - openldap
        
        ports:
            - '8092:80'

        volumes:
            - /etc/localtime:/etc/localtime:ro
        
        environment:
            - PHPLDAPADMIN_LDAP_HOSTS=openldap
            - PHPLDAPADMIN_HTTPS=false

volumes:
    openldap-db:
    openldap-slapd:

openldap doesn't start and in the log i see the following error:

Start OpenLDAP...,
5afaab12 connections_destroy: nothing to destroy.,
Waiting for OpenLDAP to start...,
5afaab12 @(#) $OpenLDAP: slapd  (Aug 10 2017 19:12:46) $,
	Debian OpenLDAP Maintainers <[email protected]>,
5afaab12 daemon: bind(8) failed errno=99 (Cannot assign requested address),
5afaab12 main: TLS init def ctx failed: -1,
5afaab12 slapd stopped.

Netstat shows nothing listening on port 389, and of course i did stop the openldap container before trying to run it as a service. Is this a bug, or did i do something wrong ?

Foxi352 avatar May 15 '18 09:05 Foxi352

Same here

grebois avatar Sep 17 '18 15:09 grebois

Same here Today

kumy avatar Sep 17 '18 16:09 kumy

I just ran into this as well.

icedream avatar Oct 23 '18 12:10 icedream

Hi all! Any update? Same error here. :(

FernandoMorais avatar May 06 '19 18:05 FernandoMorais

@FernandoMorais & all, just tried this both on my MacOSX and Ubuntu Xenial platforms without any issues: I was able to run

ldapsearch -x -H ldap://localhost -b dc=example,dc=org -D "cn=admin,dc=example,dc=org" -w admin from the host and I get the proper outputs

On which kind of OS are you running this ? May be output of docker version and docker-compose version could also help

Can you also try without mounting volumes aka using demo LDAP DB contents to see if this has an impact on your failure ? Many thanks

obourdon avatar May 07 '19 15:05 obourdon

Sorry was using docker-compose not swarm mode, retrying right now

obourdon avatar May 07 '19 15:05 obourdon

works with swarm on my linux box

$ docker service ls ID NAME MODE REPLICAS IMAGE PORTS v7hfbypawi78 ldap_openldap replicated 1/1 osixia/openldap:1.2.0 *:389->389/tcp dqalcswnablu ldap_phpldapadmin replicated 1/1 osixia/phpldapadmin:latest *:8092->80/tcp

netstat -lntp | grep 389 tcp6 0 0 :::389 :::* LISTEN 23720/dockerd

$ docker service logs ldap_openldap 2>&1 | egrep -i 'starting|Waiting|stopped|daemon|errno' ldap_openldap.1.qi3jepnrz8qb@xenial-16-04 | Waiting for OpenLDAP to start... ldap_openldap.1.qi3jepnrz8qb@xenial-16-04 | 5cd1a8dc daemon: bind(8) failed errno=99 (Cannot assign requested address) ldap_openldap.1.qi3jepnrz8qb@xenial-16-04 | 5cd1a8dc slapd starting ldap_openldap.1.qi3jepnrz8qb@xenial-16-04 | 5cd1a8dc daemon: shutdown requested and initiated. ldap_openldap.1.qi3jepnrz8qb@xenial-16-04 | 5cd1a8dc slapd shutdown: waiting for 0 operations/tasks to finish ldap_openldap.1.qi3jepnrz8qb@xenial-16-04 | 5cd1a8dc slapd stopped. ldap_openldap.1.qi3jepnrz8qb@xenial-16-04 | 5cd1a8dd slapd starting

however seems like the startup is stopped and relaunched

but seems to work anyways

obourdon avatar May 07 '19 15:05 obourdon

same. Host system: ubuntu 18.04 docker version: Docker version 19.03.1, build 74b1e89 docker compose version: docker-compose version 1.24.0, build 0aa59064 openldap image: osixia/openldap:1.2.5

Here is my docker-compose.yml:

ldap:
    image: osixia/openldap:1.2.5
    container_name: ldap
    environment:
      LDAP_LOG_LEVEL: "256"
      # LDAP_ORGANISATION: "example"
      # LDAP_DOMAIN: "example.com"
      # LDAP_BASE_DN: ""
      LDAP_ORGANISATION: "Example Inc."
      LDAP_DOMAIN: "example.org"
      LDAP_BASE_DN: ""
      LDAP_ADMIN_PASSWORD: "aa111111"
      LDAP_CONFIG_PASSWORD: "aa111111"
      # LDAP_ADMIN_PASSWORD: "admin"
      # LDAP_CONFIG_PASSWORD: "config"
      LDAP_READONLY_USER: "false"
      #LDAP_READONLY_USER_USERNAME: "readonly"
      #LDAP_READONLY_USER_PASSWORD: "readonly"
      LDAP_RFC2307BIS_SCHEMA: "false"
      LDAP_BACKEND: "mdb"
      LDAP_TLS: "true"
      LDAP_TLS_CRT_FILENAME: "ldap.crt"
      LDAP_TLS_KEY_FILENAME: "ldap.key"
      LDAP_TLS_DH_PARAM_FILENAME: "dhparam.pem"
      LDAP_TLS_CA_CRT_FILENAME: "ca.crt"
      LDAP_TLS_ENFORCE: "false"
      LDAP_TLS_CIPHER_SUITE: "SECURE256:-VERS-SSL3.0"
      LDAP_TLS_PROTOCOL_MIN: "3.1"
      LDAP_TLS_VERIFY_CLIENT: "demand"
      LDAP_REPLICATION: "false"
      #LDAP_REPLICATION_CONFIG_SYNCPROV: "binddn="cn=admin,cn=config" bindmethod=simple credentials=$LDAP_CONFIG_PASSWORD searchbase="cn=config" type=refreshAndPersist retry="60 +" timeout=1 starttls=critical"
      #LDAP_REPLICATION_DB_SYNCPROV: "binddn="cn=admin,$LDAP_BASE_DN" bindmethod=simple credentials=$LDAP_ADMIN_PASSWORD searchbase="$LDAP_BASE_DN" type=refreshAndPersist interval=00:00:00:10 retry="60 +" timeout=1 starttls=critical"
      #LDAP_REPLICATION_HOSTS: "#PYTHON2BASH:['ldap://ldap.example.org','ldap://ldap2.example.org']"
      KEEP_EXISTING_CONFIG: "false"
      LDAP_REMOVE_CONFIG_AFTER_SETUP: "true"
      LDAP_SSL_HELPER_PREFIX: "ldap"
    tty: true
    stdin_open: true
    volumes:
      - ./ldap/var/lib/ldap:/var/lib/ldap
      - ./ldap/etc/ldap/slapd.d:/etc/ldap/slapd.d
      - ./ldap/container/service/slapd/assets/certs/:/container/service/slapd/assets/certs/
    ports:
      - "389:389"
      - "636:636"
    domainname: "example.org" # important: same as hostname
    hostname: "example.org"
    command: --loglevel trace

And error logs:

5d5e577d @(#) $OpenLDAP: slapd  (Feb  9 2019 17:02:42) $
        Debian OpenLDAP Maintainers <[email protected]>
5d5e577d daemon: bind(6) failed errno=99 (Cannot assign requested address)
5d5e577d daemon: bind(6) failed errno=99 (Cannot assign requested address)
5d5e577d slapd stopped.
5d5e577d connections_destroy: nothing to destroy.

chendind avatar Aug 22 '19 09:08 chendind

should use Volumes instead of Bind mounts for persisting data

Volumes are easier to back up or migrate than bind mounts, mounting a directory on a host to a container using bind mounts may cause permission issues, changed the owner of the directory

my working docker-compose.yml is

version: '3.7'

services:
  ldap:
    build: ./openldap
    command: --loglevel debug
    volumes:
      - data-openldap-database:/var/lib/ldap
      - data-openldap-config:/etc/ldap/slapd.d
  backup:
    build:
      context: ../
      dockerfile: avatar/backup/Dockerfile
    volumes:
      - data-openldap-database:/shared-volume/openldap/database
      - data-openldap-config:/shared-volume/openldap/config
      - ~/docker-data:/backup

volumes:
  data-openldap-database:
  data-openldap-config:

refer to Backup, restore, or migrate data volumes to backup or restore volumes

i my case, backup and restore operations are performed in the backup container

  • backup: tars the content of the /shared-volume to a backup.tgz file inside our /backup directory
  • restore: un-tar the backup file in /shared-volume

may fix

  • https://github.com/osixia/docker-openldap/issues/129
  • https://github.com/osixia/docker-openldap/issues/164
  • https://github.com/osixia/docker-openldap/issues/337
  • https://github.com/osixia/docker-openldap/issues/112
  • https://github.com/osixia/docker-openldap/issues/85
  • https://github.com/osixia/docker-openldap/issues/83

jk2K avatar Sep 27 '19 05:09 jk2K

This was potentially fixed in 1.4.0, 1.5.0 by b6507a9f1503c5cc33354aac640e6c23f6f3bc8b .

javabrett avatar May 16 '23 04:05 javabrett