docker-openldap
docker-openldap copied to clipboard
When running as a swarm stack: bind(8) failed errno=99 (Cannot assign requested address)
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 ?
Same here
Same here Today
I just ran into this as well.
Hi all! Any update? Same error here. :(
@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
Sorry was using docker-compose not swarm mode, retrying right now
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
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.
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 abackup.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
This was potentially fixed in 1.4.0, 1.5.0 by b6507a9f1503c5cc33354aac640e6c23f6f3bc8b .