tiredofit / docker-openldap Goto Github PK

Dockerized LDAP server with many customizable options

License: MIT License

docker openldap zabbix replication tls ssl alpine ppolicy

docker-openldap's Introduction

github.com/tiredofit/docker-openldap

This as a Dockerfile to build a OpenLDAP server for maintaining a directory. Upon starting this image it will give you a ready to run server with many configurable options.

Tracks latest release
Compiles from source
Multiple backends (bdb, hdb, mdb, sql)
All overlays compiled
Supports TLS encryption
Supports Replication
Scheduled Backups of Data
Ability to choose NIS or rfc2307bis Schema
Additional Password Modules (Argon, SHA2, PBKDF2)
Two Password Checking Modules - check_password.so and ppm.so
Zabbix Monitoring templates included

Maintainer

Dave Conroy

See individual branches

docker-openldap's People

Contributors

Stargazers

Watchers

docker-openldap's Issues

Certificates should not be unconditionally chown'ed

[cont-init.d] 10-openldap: executing...
chown: changing ownership of '/assets/slapd/certs/<name>': Read-only file system
chown: changing ownership of '/assets/slapd/certs/<name>': Read-only file system
.. etc
chown: changing ownership of '/assets/slapd/certs': Read-only file system
[cont-init.d] 10-openldap: exited 1.
[cont-init.d] 99-container: executing...
**********************************************************************************************************************
**********************************************************************************************************************
****                                                                                                              ****
****       ERROR - Some initialization scripts haven't completed - All services are now halted                    ****
****             - The following scripts in '/etc/cont-init.d' did not pass their completion check                ****
****                                                                                                              ****
**********************************************************************************************************************
**********************************************************************************************************************

10-openldap

These certificates are shared amongst a few containers on this host, and they do not need to be modified. They are mounted read-only inside the container and this causes the startup to fail

Offending chown:

docker-openldap/install/etc/cont-init.d/10-openldap

Line 164 in 4b51edb

chown -R ldap:ldap /assets/slapd

[Info] how to use docker-openldap with remote client

I'm running docker ldap server on an IBM instance and I'm trying to access it from my local machine. I setup the Openldap -client on my local machine. I can access the ldap-server without TLS option but When I'm trying to access it by enforcing STARTTLS then I'm getting ldap_start_tls: Connect error (-11) on my local machine and below logs on ldap-server.

5ed8f60e conn=1008 fd=13 ACCEPT from IP=157.38.X.X:24007 (IP=0.0.0.0:389)
5ed8f60e conn=1008 op=0 EXT oid=1.3.6.1.4.1.1466.20037
5ed8f60e conn=1008 op=0 STARTTLS
5ed8f60e conn=1008 op=0 RESULT oid= err=0 text=
TLS: can't accept: error:140260FC:SSL routines:ACCEPT_SR_CLNT_HELLO:unknown protocol.
5ed8f60e conn=1008 fd=13 closed (TLS negotiation failure)

/etc/ldap/ldap.conf file on local machine

#
# LDAP Defaults
#

# See ldap.conf(5) for details
# This file should be world readable but not world writable.

#BASE   dc=example,dc=com
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666

#SIZELIMIT      12
#TIMELIMIT      15
#DEREF          never

# TLS certificates (needed for GnuTLS)
TLS_CACERT   /home/alpha/GoWorkspace/src/github.com/docker-openldap/install/assets/ssl-tools/default-ca/default-ca.pem

Please help.

6.9.0 seem not to load defaults/10-openldap and fails when TLS_ENFORCE="true"

Trying to deploy with TLS_ENFORCE: "true" will fail to launch ldap.

It seems that the defaults/10-openldap that is supposed to set some vars is not actually loaded, because WAS_STARTED_WITH_REPLICATION seems empty, since touch complains.

Also, I have noticed that dhparam.pem file is created in the root of the container, as I did not specify the path, just the name, assuming the defaults. This is another clue.

Maybe this is not yet working.

Log

[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 00-functions: applying...
[fix-attrs.d] 00-functions: exited 0.
[fix-attrs.d] 01-s6: applying...
[fix-attrs.d] 01-s6: exited 0.
[fix-attrs.d] 02-zabbix: applying...
[fix-attrs.d] 02-zabbix: exited 0.
[fix-attrs.d] 03-logrotate: applying...
[fix-attrs.d] 03-logrotate: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 00-startup: executing...
[cont-init.d] 00-startup: exited 0.
[cont-init.d] 01-timezone: executing...
[NOTICE] ** [timezone] Setting timezone to 'Etc/GMT'
[cont-init.d] 01-timezone: exited 0.
[cont-init.d] 02-permissions: executing...
[cont-init.d] 02-permissions: exited 0.
[cont-init.d] 03-zabbix: executing...
[cont-init.d] 03-zabbix: exited 0.
[cont-init.d] 04-cron: executing...
[cont-init.d] 04-cron: exited 0.
[cont-init.d] 05-smtp: executing...
[NOTICE] ** [smtp] Disabling SMTP Features
[cont-init.d] 05-smtp: exited 0.
[cont-init.d] 09-nginx: executing...
/var/run/s6/etc/cont-init.d/09-nginx: line 4: prepare_service: command not found
[cont-init.d] 09-nginx: exited 0.
[cont-init.d] 10-openldap: executing...
[INFO] ** [openldap] Starting OpenLDAP Initialization Sequence
[INFO] ** [openldap] Waiting for OpenLDAP to be ready
[INFO] ** [openldap] Starting TLS configuration. Please wait...
/var/run/s6/etc/cont-init.d/10-openldap: line 344: $WAS_STARTED_WITH_TLS: ambiguous redirect
/var/run/s6/etc/cont-init.d/10-openldap: line 345: $WAS_STARTED_WITH_TLS: ambiguous redirect
/var/run/s6/etc/cont-init.d/10-openldap: line 346: $WAS_STARTED_WITH_TLS: ambiguous redirect
/var/run/s6/etc/cont-init.d/10-openldap: line 347: $WAS_STARTED_WITH_TLS: ambiguous redirect
[NOTICE] ** [openldap] Adding TLS enforcement
[INFO] ** [openldap] Configuring replication
/var/run/s6/etc/cont-init.d/10-openldap: line 394: $WAS_STARTED_WITH_REPLICATION: ambiguous redirect
[INFO] ** [openldap] Finished OpenLDAP Initialization
[INFO] ** [openldap] Configuring ldap client
[NOTICE] ** [openldap] Ready to start OpenLDAP
touch: missing file operand
Try 'touch --help' for more information.
[cont-init.d] 10-openldap: exited 0.
[cont-init.d] 99-container: executing...
[cont-init.d] 99-container: exited 0.
[cont-init.d] done.
[services.d] starting services
[INFO] ** [zabbix] Starting Zabbix Agent
[services.d] done.

In my opinion, if ldap is failing to start, the whole container should fail.

How to bootstrap custom ldif

2 questions please

Is it possible to update the documentation to include how to bootstrap a custom ldif file?
Will mounting a local folder containing a custom ldif file to this folder
in the container: /assets/slapd/config/bootstrap/ldif/ do the trick?

BASE_DN is wrongly generated

Summary

BASE_DN is wrongly generated from DOMAIN

Steps to reproduce

Specify DOMAIN as a.b.c
Leave BASE_DN to blank

BASE_DN is inferred as dc=c,dc=a

What is the expected correct behavior?

BASE_DN should be dc=c,dc=b,dc=a

Relevant logs and/or screenshots

Environment

Image version / tag: 2.6
Host OS: Ubuntu Server 22.04

Any logs | docker-compose.yml

Possible fixes

Fix install/assets/functions/10-openldap

sed in replication setup wrong in image: tiredofit/openldap-fusiondirectory:2.6-1.4

the replacement of the replica hosts in
/assets/slapd/config/replication/replication-enable.ldif
seem to be wrong -

+ sed -i -e 's|{{REPLICATION_HOSTS}}|olcServerID: 2 ldap://ldap4.xxx.xxx\n{{REPLICATION_HOSTS}}|g' -e 's|{{REPLICATION_HOSTS_CONFIG_SYNC_REPL}}|olcSyncRepl: rid=002 provider=ldap://ldap4xxx.xxx binddn="cn=admin,dc=elternserver,dc=de" bindmethod=simple credentials="xxxxxxxx" searchbase="cn=config" type=refreshAndPersist retry="60 +" timeout=1\n<REPLICATION_HOSTS_CONFIG_SYNC_REPL>|g' -e 's|{{REPLICATION_HOSTS_DB_SYNC_REPL}}|olcSyncRepl: rid=102 provider=ldap://ldap4.xxx.xxx binddn="cn=admin,dc=xxxx,dc=de" bindmethod=simple credentials="xxxxxxxx" searchbase="dc=xxxx,dc=de" type=refreshAndPersist interval=00:00:00:10 retry="60 +" timeout=1\n<REPLICATION_HOSTS_DB_SYNC_REPL>|g' /assets/slapd/config/replication/replication-enable.ldif

afterwards the file looks like:

# Load syncprov module
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

# Set server ID
dn: cn=config
changeType: modify
add: olcServerID
<REPLICATION_HOSTS>

# Add syncprov on config
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

# Add sync replication on config
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
<REPLICATION_HOSTS_CONFIG_SYNC_REPL>
-
add: olcMultiProvider
olcMultiProvider: TRUE

# Add syncprov on backend
dn: olcOverlay=syncprov,olcDatabase={1}mdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

# Add sync replication on backend
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcSyncRepl
<REPLICATION_HOSTS_DB_SYNC_REPL>
-
add: olcMultiProvider
olcMultiProvider: TRUE

the parameters didn't find their way into the ldif.

add X509v3 Subject Alternative Name

please add the X509v3 Subject Alternative Name to the certificate:

X509v3 Subject Alternative Name:
    DNS:<myFQDN.com>

S3 Backups Broken

There are several issues with trying to use S3 Backups.

Environment

Using the docker-compose file provided

Issues

Setting Backups to S3

In order to set the backups to S3, the env variable BACKUP_TYPE needs to be set to S3, not BACKUP_LOCATION.
This can be seen at /etc/services.available/20-openldap-backup/run line 17

S3 Environment variables are incorrect

The S3 variable do not want BACKUP_ in front of them, as can be seen at starting at [/etc/services.available/20-openldap-backup/run line 128] (

docker-openldap/install/etc/services.available/20-openldap-backup/run

Line 128 in 1fd264d

"S3" | "s3" | "MINIO" | "minio" )

)
The S3_HOSTNAME is not correct, the script wants S3_HOST

Missing libressl

Don't know if it is related or not

++ libressl md5 -binary
/etc/services.available/20-openldap-backup/run: line 149: libressl: command not found

Missing libsasl2 in 2.6-7.6.8

Summary

The container failed to run the latest commit 9b99554 with the default out-of-the-box configuration.

Steps to reproduce

Pull the 2.6-7.6.8 image tag

docker pull tiredofit/openldap:2.6-7.6.8

Run the docker image

docker run -it tiredofit/openldap:2.6-7.6.8

What is the expected correct behavior?

Expected the container to run normally with no additional configuration.

Relevant logs and/or screenshots

                                                                       ,---.
,--------.,--.                 ,--.            ,---.    ,--. ,--------.|   |
'--.  .--'`--',--.--. ,---.  ,-|  |     ,---. /  .-'    |  | '--.  .--'|  .'
   |  |   ,--.|  .--'| .-. :' .-. |    | .-. ||  `-,    |  |    |  |   |  |
   |  |   |  ||  |   \   --.\ `-' |    ' '-' '|  .-'    |  |.--.|  |   `--'
   `--'   `--'`--'    `----' `---'      `---' `--'      `--''--'`--'   .--.
                                                                       '--'
Image:  tiredofit/openldap | Version  2.6-7.6.8 Type 'image_changelog' for details
Repository/Documentation: https://github.com/tiredofit/docker-openldap/

If this image provides you value  - Consider sponsoring my work for continued
development, timely updates, and feature requests. Commercial support available.

                    More Info:  https://www.tiredofit.ca

2024-05-23.04:51:40 [NOTICE] ** [monitoring] Container configured for monitoring with 'zabbix modern'
2024-05-23.04:51:40 [NOTICE] ** [scheduling] Container configured for scheduled tasks with 'cron'
2024-05-23.04:51:40 [NOTICE] ** [messaging] Container configured to route mail via SMTP to 'postfix-relay'
2024-05-23.04:51:40 [NOTICE] ** [openldap] Setting up directories
2024-05-23.04:51:40 [NOTICE] ** [openldap] Configuring OpenLDAP server
ls: unrecognized option: I
BusyBox v1.36.1 (2024-05-21 13:38:37 UTC) multi-call binary.

Usage: ls [-1AaCxdLHRFplinshrSXvctu] [-w WIDTH] [FILE]...

List directory contents

        -1      One column output
        -a      Include names starting with .
        -A      Like -a, but exclude . and ..
        -x      List by lines
        -d      List directory names, not contents
        -L      Follow symlinks
        -H      Follow symlinks on command line
        -R      Recurse
        -p      Append / to directory names
        -F      Append indicator (one of */=@|) to names
        -l      Long format
        -i      List inode numbers
        -n      List numeric UIDs and GIDs instead of names
        -s      List allocated blocks
        -lc     List ctime
        -lu     List atime
        --full-time     List full date/time
        -h      Human readable sizes (1K 243M 2G)
        --group-directories-first
        -S      Sort by size
        -X      Sort by extension
        -v      Sort by version
        -t      Sort by mtime
        -tc     Sort by ctime
        -tu     Sort by atime
        -r      Reverse sort order
        -w N    Format N columns wide
        --color[={always,never,auto}]
ls: unrecognized option: I
BusyBox v1.36.1 (2024-05-21 13:38:37 UTC) multi-call binary.

Usage: ls [-1AaCxdLHRFplinshrSXvctu] [-w WIDTH] [FILE]...

List directory contents

        -1      One column output
        -a      Include names starting with .
        -A      Like -a, but exclude . and ..
        -x      List by lines
        -d      List directory names, not contents
        -L      Follow symlinks
        -H      Follow symlinks on command line
        -R      Recurse
        -p      Append / to directory names
        -F      Append indicator (one of */=@|) to names
        -l      Long format
        -i      List inode numbers
        -n      List numeric UIDs and GIDs instead of names
        -s      List allocated blocks
        -lc     List ctime
        -lu     List atime
        --full-time     List full date/time
        -h      Human readable sizes (1K 243M 2G)
        --group-directories-first
        -S      Sort by size
        -X      Sort by extension
        -v      Sort by version
        -t      Sort by mtime
        -tc     Sort by ctime
        -tu     Sort by atime
        -r      Reverse sort order
        -w N    Format N columns wide
        --color[={always,never,auto}]
2024-05-23.04:51:40 [WARN] ** [openldap] First time install detected
2024-05-23.04:51:40 [NOTICE] ** [openldap] Using NIS schema type
Error loading shared library libltdl.so.7: No such file or directory (needed by /usr/sbin/slappasswd)
Error loading shared library libsasl2.so.3: No such file or directory (needed by /usr/sbin/slappasswd)
Error loading shared library libuuid.so.1: No such file or directory (needed by /usr/sbin/slappasswd)
Error loading shared library libsasl2.so.3: No such file or directory (needed by /usr/lib/libldap.so.2)
Error relocating /usr/lib/libldap.so.2: sasl_set_mutex: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_client_step: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_version: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_decode: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_client_init: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_dispose: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_errstring: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_encode: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_errdetail: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_getprop: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_global_listmech: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_setprop: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_client_start: symbol not found
Error relocating /usr/lib/libldap.so.2: sasl_client_new: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_server_start: symbol not found
Error relocating /usr/sbin/slappasswd: prop_request: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_listmech: symbol not found
Error relocating /usr/sbin/slappasswd: uuid_generate: symbol not found
Error relocating /usr/sbin/slappasswd: uuid_unparse_lower: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_set_mutex: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_auxprop_getctx: symbol not found
Error relocating /usr/sbin/slappasswd: lt_dlopenext: symbol not found
Error relocating /usr/sbin/slappasswd: lt_dlexit: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_version: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_dispose: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_setpass: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_seterror: symbol not found
Error relocating /usr/sbin/slappasswd: prop_set: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_checkpass: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_done: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_errdetail: symbol not found
Error relocating /usr/sbin/slappasswd: lt_dlclose: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_getprop: symbol not found
Error relocating /usr/sbin/slappasswd: lt_dlerror: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_auxprop_add_plugin: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_server_new: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_server_step: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_setprop: symbol not found
Error relocating /usr/sbin/slappasswd: sasl_server_init: symbol not found
Error relocating /usr/sbin/slappasswd: prop_getnames: symbol not found
Error relocating /usr/sbin/slappasswd: lt_dlsym: symbol not found
Error relocating /usr/sbin/slappasswd: lt_dlinit: symbol not found
Error relocating /usr/sbin/slappasswd: lt_dlsetsearchpath: symbol not found

Environment

Image version / tag: 2.6-7.6.8
Host OS: ubuntu/linux/amd64

Possible fixes

Possible bash script failure in tiredofit/alpine:3.20. Reverting base image to tiredofit/alpine:3.19 as a temporary fix.

openldap waiting for pid

@tiredofit

I am similar behavior to another issue about "waiting to start" with externally resolvable DNS to a publically reachable POC. I am able to start the example without issue. Thanks in advance for your assist!

Related Logs

openldap-app    | 5ceee165 @(#) $OpenLDAP: slapd 2.4.47 (May  2 2019 19:03:59) $
openldap-app    | 	@eeb43f157a45:/tiredofit/openldap:6.4/servers/slapd
openldap-app    | 5ceee165 daemon: bind(8) failed errno=2 (No such file or directory)
openldap-app    | 5ceee165 slapd stopped.
openldap-app    | 5ceee165 connections_destroy: nothing to destroy.
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'

Directory Tree

├── backup
├── certs
│   ├── cert.pem -> ../../nginx-certbot/data/certbot/conf/live/ldap.cpc.ctl.io/cert.pem
│   ├── chain.pem -> ../../nginx-certbot/data/certbot/conf/live/ldap.cpc.ctl.io/chain.pem
│   ├── fullchain.pem -> ../../nginx-certbot/data/certbot/conf/live/ldap.cpc.ctl.io/fullchain.pem
│   └── privkey.pem -> ../../nginx-certbot/data/certbot/conf/live/ldap.cpc.ctl.io/privkey.pem
├── config
│   ├── cn=config
│   │   ├── cn=module{0}.ldif
│   │   ├── cn=schema
│   │   │   ├── cn={0}core.ldif
│   │   │   ├── cn={1}cosine.ldif
│   │   │   ├── cn={2}inetorgperson.ldif
│   │   │   └── cn={3}nis.ldif
│   │   ├── cn=schema.ldif
│   │   ├── olcDatabase={0}config.ldif
│   │   ├── olcDatabase={-1}frontend.ldif
│   │   ├── olcDatabase={1}mdb.ldif
│   │   └── olcDatabase={2}monitor.ldif
│   └── cn=config.ldif
├── data
├── docker-compose.yml

Docker Compose

version: '2'
services:
  openldap-app:
    hostname: ldap.cpc.ctl.io
    domainname: cpc.ctl.io
    container_name: openldap-app
    image: tiredofit/openldap
    ports:
      - 636:636
      - 389:389
    environment:
      - HOSTNAME=ldap.cpc.ctl.io
      - BACKEND=mdb
      - LOG_LEVEL=256
      - DOMAIN=cpc.ctl.io
      - ADMIN_PASS=admin
      - CONFIG_PASS=config
      - ENABLE_NGINX=false

      - BASE_DN=dc=cpc,dc=ctl,dc=io
      - ENABLE_READONLY_USER=false
      - READONLY_USER_USER=reader
      - READONLY_USER_PASS=reader

      - ENABLE_TLS=true
      - TLS_CRT_FILENAME=cert.pem
      - TLS_KEY_FILENAME=privkey.pem
      - TLS_CA_CRT_FILENAME=chain.pem
      - TLS_ENFORCE=false
      - TLS_CIPHER_SUITE=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:-DHE-DSS:-RSA:!aNULL:!MD5:!DSS:!SHA
      - TLS_VERIFY_CLIENT=never
      - SSL_HELPER_PREFIX=ldap

      - ENABLE_REPLICATION=false
      - REMOVE_CONFIG_AFTER_SETUP=false
      - DEBUG_MODE=TRUE

      - BACKUP_CONFIG_CRON_PERIOD=0 4 * * *
      - BACKUP_DATA_CRON_PERIOD=0 4 * * *
      - BACKUP_TTL=15

      - ZABBIX_HOSTNAME=ldap.cpc.ctl.io
    volumes:
      - ./backup:/data/backup
      - ./data:/var/lib/openldap
      - ./config:/etc/openldap/slapd.d
      - ./certs:/assets/slapd/certs
    restart: always

Full docker log with debugging

openldap-app    | [s6-init] making user provided files available at /var/run/s6/etc...exited 0.
openldap-app    | [s6-init] ensuring user provided files have correct perms...exited 0.
openldap-app    | [fix-attrs.d] applying ownership & permissions fixes...
openldap-app    | [fix-attrs.d] 01-run: applying... 
openldap-app    | [fix-attrs.d] 01-run: exited 0.
openldap-app    | [fix-attrs.d] 01-s6: applying... 
openldap-app    | [fix-attrs.d] 01-s6: exited 0.
openldap-app    | [fix-attrs.d] 02-zabbix: applying... 
openldap-app    | [fix-attrs.d] 02-zabbix: exited 0.
openldap-app    | [fix-attrs.d] 03-logrotate: applying... 
openldap-app    | [fix-attrs.d] 03-logrotate: exited 0.
openldap-app    | [fix-attrs.d] done.
openldap-app    | [cont-init.d] executing container initialization scripts...
openldap-app    | [cont-init.d] 01-permissions: executing... 
openldap-app    | + DEBUG_PERMISSIONS=FALSE
openldap-app    | + ENABLE_PERMISSIONS=TRUE
openldap-app    | + '[' TRUE = TRUE ']'
openldap-app    | + varenvusername=(`env | grep USER_ | awk -F= '{print tolower($1)}' | awk -F_ '{print $2}'`)
openldap-app    | ++ env
openldap-app    | ++ awk -F= '{print tolower($1)}'
openldap-app    | ++ grep USER_
openldap-app    | ++ awk -F_ '{print $2}'
openldap-app    | + varenvuid=(`env | grep USER_ | awk -F= '{print tolower($2)}'`)
openldap-app    | ++ env
openldap-app    | ++ grep USER_
openldap-app    | ++ awk -F= '{print tolower($2)}'
openldap-app    | ++ echo 'user user'
openldap-app    | ++ sed 's/ /\\|/g'
openldap-app    | + strusers='user\|user'
openldap-app    | + [[ ! -z user\|user ]]
openldap-app    | + varpassuser=(`cat /etc/passwd | grep ^"$strusers" | awk -F: '{print $1}'`)
openldap-app    | ++ cat /etc/passwd
openldap-app    | ++ grep '^user\|user'
openldap-app    | ++ awk -F: '{print $1}'
openldap-app    | + varpassuserid=(`cat /etc/passwd | grep ^"$strusers" | awk -F: '{print $3}'`)
openldap-app    | ++ cat /etc/passwd
openldap-app    | ++ grep '^user\|user'
openldap-app    | ++ awk -F: '{print $3}'
openldap-app    | + '[' FALSE = TRUE ']'
openldap-app    | + '[' FALSE = true ']'
openldap-app    | + '[' TRUE = TRUE ']'
openldap-app    | + echo '**** [permissions] [debug] Users (varenvusername) from Docker env are: user user'
openldap-app    | + echo '**** [permissions] [debug] UIDs (varenvuid) from Docker env are: reader reader'
openldap-app    | + echo '**** [permissions] [debug] The string (strusers) used to grep the users is: user\|user'
openldap-app    | + echo '**** [permissions] [debug] Users (varpassuser) from /etc/passwd are: '
openldap-app    | + echo '**** [permissions] [debug] UIDs (varpassuserid) from /etc/passwd are: '
openldap-app    | + counter=0
openldap-app    | + for i in ${!varenvusername[*]}
openldap-app    | + for i in ${!varenvusername[*]}
openldap-app    | + '[' 0 -gt 0 ']'
openldap-app    | + counter=0
openldap-app    | + varenvgroupname=(`env | grep ^GROUP_ | grep -v GROUP_ADD_  | awk -F= '{print tolower($1)}' | awk -F_ '{print $2}'`)
openldap-app    | ++ env
openldap-app    | ++ grep '^GROUP_'
openldap-app    | ++ awk -F_ '{print $2}'
openldap-app    | ++ grep -v GROUP_ADD_
openldap-app    | ++ awk -F= '{print tolower($1)}'
openldap-app    | + varenvgid=(`env | grep ^GROUP_ | grep -v GROUP_ADD_ | awk -F= '{print tolower($2)}'`)
openldap-app    | ++ env
openldap-app    | ++ grep -v GROUP_ADD_
openldap-app    | ++ grep '^GROUP_'
openldap-app    | **** [permissions] [debug] Users (varenvusername) from Docker env are: user user
openldap-app    | **** [permissions] [debug] UIDs (varenvuid) from Docker env are: reader reader
openldap-app    | **** [permissions] [debug] The string (strusers) used to grep the users is: user\|user
openldap-app    | **** [permissions] [debug] Users (varpassuser) from /etc/passwd are: 
openldap-app    | **** [permissions] [debug] UIDs (varpassuserid) from /etc/passwd are: 
openldap-app    | ++ awk -F= '{print tolower($2)}'
openldap-app    | ++ echo ''
openldap-app    | ++ sed 's/ /\\|/g'
openldap-app    | + strgroups=
openldap-app    | + [[ ! -z '' ]]
openldap-app    | + '[' FALSE = TRUE ']'
openldap-app    | + '[' FALSE = true ']'
openldap-app    | + '[' TRUE = TRUE ']'
openldap-app    | + echo '**** [permissions] [debug] Group names (varenvgroupname) from Docker environment settings are: '
openldap-app    | + echo '**** [permissions] [debug] GIDs (grvarenvgid) from Docker environment settings are: '
openldap-app    | + echo '**** [permissions] [debug] The string (strgroup) used to grep the groups is: '
openldap-app    | + echo '**** [permissions] [debug] Group names (vargroupname) from /etc/group are: '
openldap-app    | + echo '**** [permissions] [debug] GIDs (vargroupid) from /etc/group are: '
openldap-app    | + '[' 0 -gt 0 ']'
openldap-app    | + counter=0
openldap-app    | + varenvuser2add=(`env | grep ^GROUP_ADD_ | awk -F= '{print $1}' | awk -F_ '{print tolower($3)}'`)
openldap-app    | **** [permissions] [debug] Group names (varenvgroupname) from Docker environment settings are: 
openldap-app    | **** [permissions] [debug] GIDs (grvarenvgid) from Docker environment settings are: 
openldap-app    | **** [permissions] [debug] The string (strgroup) used to grep the groups is: 
openldap-app    | **** [permissions] [debug] Group names (vargroupname) from /etc/group are: 
openldap-app    | **** [permissions] [debug] GIDs (vargroupid) from /etc/group are: 
openldap-app    | ++ env
openldap-app    | ++ grep '^GROUP_ADD_'
openldap-app    | ++ awk -F= '{print $1}'
openldap-app    | ++ awk -F_ '{print tolower($3)}'
openldap-app    | + varenvdestgroup=(`env | grep ^GROUP_ADD_ | awk -F= '{print tolower($2)}'`)
openldap-app    | ++ env
openldap-app    | ++ grep '^GROUP_ADD_'
openldap-app    | ++ awk -F= '{print tolower($2)}'
openldap-app    | + '[' FALSE = TRUE ']'
openldap-app    | + '[' FALSE = true ']'
openldap-app    | + '[' TRUE = TRUE ']'
openldap-app    | + echo '**** [permissions] [debug] Users (varenvuser2add) to add to groups are: '
openldap-app    | + echo '**** [permissions] [debug] Groups (varenvdestgroup) to add users are: '
openldap-app    | + mkdir -p /tmp/state
openldap-app    | **** [permissions] [debug] Users (varenvuser2add) to add to groups are: 
openldap-app    | **** [permissions] [debug] Groups (varenvdestgroup) to add users are: 
openldap-app    | ++ basename /var/run/s6/etc/cont-init.d/01-permissions
openldap-app    | + touch /tmp/state/01-permissions-init
openldap-app    | [cont-init.d] 01-permissions: exited 0.
openldap-app    | [cont-init.d] 02-zabbix: executing... 
openldap-app    | [cont-init.d] 02-zabbix: exited 0.
openldap-app    | [cont-init.d] 03-cron: executing... 
openldap-app    | **** [cron] Enabling Cron
openldap-app    | [cont-init.d] 03-cron: exited 0.
openldap-app    | [cont-init.d] 04-smtp: executing... 
openldap-app    | **** [smtp] [debug] SMTP Mailcatcher Enabled at Port 1025, Visit http://127.0.0.1:8025 for Web Interface
openldap-app    | **** [smtp] Disabling SMTP Features
openldap-app    | [cont-init.d] 04-smtp: exited 0.
openldap-app    | [cont-init.d] 09-nginx: executing... 
openldap-app    | [cont-init.d] 09-nginx: exited 0.
openldap-app    | [cont-init.d] 10-openldap: executing... 
openldap-app    | + set -e
openldap-app    | + set -o pipefail
openldap-app    | + ulimit -n 1024
openldap-app    | + '[' -d /var/lib/openldap ']'
openldap-app    | + '[' -d /etc/openldap/slapd.d ']'
openldap-app    | + '[' -d /assets/state ']'
openldap-app    | + chown -R ldap:ldap /var/lib/openldap
openldap-app    | + chown -R ldap:ldap /etc/openldap
openldap-app    | + chown -R ldap:ldap /assets/slapd
openldap-app    | + FIRST_START_DONE=/assets/state/slapd-first-start-done
openldap-app    | + WAS_STARTED_WITH_TLS=/etc/openldap/slapd.d/docker-openldap-was-started-with-tls
openldap-app    | + WAS_STARTED_WITH_TLS_ENFORCE=/etc/openldap/slapd.d/docker-openldap-was-started-with-tls-enforce
openldap-app    | + WAS_STARTED_WITH_REPLICATION=/etc/openldap/slapd.d/docker-openldap-was-started-with-replication
openldap-app    | + TLS_CA_CRT_PATH=/assets/slapd/certs/chain.pem
openldap-app    | + TLS_CRT_PATH=/assets/slapd/certs/cert.pem
openldap-app    | + TLS_KEY_PATH=/assets/slapd/certs/privkey.pem
openldap-app    | + TLS_DH_PARAM_PATH=/assets/slapd/certs/dhparam.pem
openldap-app    | + '[' '!' -e /assets/state/slapd-first-start-done ']'
openldap-app    | + NEW_INSTALL=false
openldap-app    | ++ ls -A -I lost+found /var/lib/openldap
openldap-app    | + '[' -z '' ']'
openldap-app    | ++ ls -A -I lost+found /etc/openldap/slapd.d
openldap-app    | + '[' -z '' ']'
openldap-app    | + NEW_INSTALL=true
openldap-app    | + echo '** [openldap] First time install detected'
openldap-app    | + '[' nis = rfc2307bis ']'
openldap-app    | + '[' nis = RFC2307BIS ']'
openldap-app    | + echo '** [openldap] Using NIS schema type'
openldap-app    | + SCHEMA_TYPE=nis
openldap-app    | + get_ldap_base_dn
openldap-app    | + '[' -z dc=cpc,dc=ctl,dc=io ']'
openldap-app    | + cat
openldap-app    | ** [openldap] First time install detected
openldap-app    | ** [openldap] Using NIS schema type
openldap-app    | ++ slappasswd -s config
openldap-app    | ++ slappasswd -s admin
openldap-app    | + set +e
openldap-app    | + /usr/bin/schema2ldif /etc/openldap/schema/core.schema
openldap-app    | + /usr/bin/schema2ldif /etc/openldap/schema/cosine.schema
openldap-app    | + /usr/bin/schema2ldif /etc/openldap/schema/inetorgperson.schema
openldap-app    | + /usr/bin/schema2ldif /etc/openldap/schema/nis.schema
openldap-app    | + silent slapadd -n 0 -F /etc/openldap/slapd.d -l /tmp/slapd.ldif
openldap-app    | + '[' TRUE = TRUE ']'
openldap-app    | + slapadd -n 0 -F /etc/openldap/slapd.d -l /tmp/slapd.ldif
openldap-app    | + rm -rf /tmp/slapd.ldif
openldap-app    | + set -e
openldap-app    | + chown -R ldap:ldap /etc/openldap
openldap-app    | + '[' mdb = mdb ']'
openldap-app    | + '[' -e '/etc/openldap/slapd.d/cn=config/olcDatabase={1}hdb.ldif' ']'
openldap-app    | + '[' '' == true ']'
openldap-app    | + PREVIOUS_HOSTNAME_PARAM=
openldap-app    | + '[' -e /etc/openldap/slapd.d/docker-openldap-was-started-with-replication ']'
openldap-app    | + '[' -e /etc/openldap/slapd.d/docker-openldap-was-started-with-tls ']'
openldap-app    | + set +e
openldap-app    | ++ grep -o -h 'provider=ldap.*//.*.' '/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif' '/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif' '/etc/openldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif' '/etc/openldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif'
openldap-app    | ++ awk -F binddn '{ print $1 }'
openldap-app    | ++ awk -F '[//]' '{ print $3 }'
openldap-app    | ++ awk '!a[$0]++'
openldap-app    | ++ tr '\n' ' '
openldap-app    | ++ awk '!a[$0]++'
openldap-app    | ++ sed 's/  / /g'
openldap-app    | + replhosts_sanity=
openldap-app    | + '[' '!' -z '' ']'
openldap-app    | + echo '** [openldap] Starting OpenLDAP Initialization Sequence'
openldap-app    | + echo '** [openldap] Waiting for OpenLDAP to be ready'
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1
openldap-app    | + silent slapd -h 'ldap://ldap.cpc.ctl.io ldapi:///' -u ldap -g ldap -d 256
openldap-app    | + '[' TRUE = TRUE ']'
openldap-app    | + slapd -h 'ldap://ldap.cpc.ctl.io ldapi:///' -u ldap -g ldap -d 256
openldap-app    | ** [openldap] Starting OpenLDAP Initialization Sequence
openldap-app    | ** [openldap] Waiting for OpenLDAP to be ready
openldap-app    | 5ceee472 @(#) $OpenLDAP: slapd 2.4.47 (May  2 2019 19:03:59) $
openldap-app    | 	@eeb43f157a45:/tiredofit/openldap:6.4/servers/slapd
openldap-app    | 5ceee472 daemon: bind(8) failed errno=2 (No such file or directory)
openldap-app    | 5ceee472 slapd stopped.
openldap-app    | 5ceee472 connections_destroy: nothing to destroy.
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1
openldap-app    | + '[' '!' -e /run/openldap/slapd.pid ']'
openldap-app    | + sleep 0.1

chown missing on TLS_CA_CRT_FILENAME

Summary

When ENABLE_TLS is TRUE, we get a permission denied on TLS_CA_CRT_FILENAME loading during TLS negociation.

Steps to reproduce

Set ENABLE_TLS to TRUE, make sure you have your certificates on the server, run a ldapsearch on ldaps

What is the expected correct behavior?

Succesful ldapsearch

Relevant logs and/or screenshots

Sorry, no logs.

Environment

Image version / tag: tiredofit/openldap version 7.1.16
Host OS: CentOS 8

Possible fixes

A possible workaround is to run "docker exec -it openldap chown ldap:ldap $TLS_CA_CRT_FILENAME" right after container startup.

Replication not working

Hi,

I setup my 2 ldap servers with replication but it does not work (if I create a new entry in the first ldap, it's not replicated in the second one).

Could you tell me what to check and how to debug it please ?

I'm sorry to ask such a question here but I don't know where to ask for your wonderful images usage.

Here are the options that I have for the containers:

      - HOSTNAME=ldap.gnubila.fr
      - BACKEND=mdb
      - LOG_LEVEL=256
      - DOMAIN=maatg.fr
      - BASE_DN=dc=maatg,dc=fr
      - ADMIN_PASS=xxxxxxxxxxxxx
      - CONFIG_PASS=config

      - FUSIONDIRECTORY_ADMIN_USER=xxxxxxxxxxxxxxx
      - FUSIONDIRECTORY_ADMIN_PASS=xxxxxxxxxxxxxx
      - ORGANIZATION=Gnubila France

      - ENABLE_READONLY_USER=false
      - READONLY_USER_USER=reader
      - READONLY_USER_PASS=xxxxxxxxxxxx

      - ENABLE_TLS=true
      - TLS_CRT_FILENAME=cert.pem
      - TLS_KEY_FILENAME=key.pem
      - TLS_CA_CRT_FILENAME=ca.pem
      - TLS_ENFORCE=false
      - TLS_CIPHER_SUITE=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:-DHE-DSS:-RSA:!aNULL:!MD5:!DSS:!SHA
      - TLS_VERIFY_CLIENT=never
      - SSL_HELPER_PREFIX=ldap

      - ENABLE_REPLICATION=true
      - REPLICATION_CONFIG_SYNCPROV=binddn="cn=admin,cn=config" bindmethod=simple credentials="admin" searchbase="cn=config" type=refreshAndPersist retry="60 +" timeout=1
      - REPLICATION_DB_SYNCPROV=binddn="cn=admin,dc=maatg,dc=fr" bindmethod=simple credentials="admin" searchbase="dc=maatg,dc=fr" type=refreshAndPersist interval=00:00:00:10 retry="60 +" timeout=1
      - REPLICATION_HOSTS=ldap.gnubila.fr ldap2.gnubila.fr
      - REMOVE_CONFIG_AFTER_SETUP=false

      - BACKUP_CONFIG_CRON_PERIOD=0 4 * * *
      - BACKUP_DATA_CRON_PERIOD=0 4 * * *
      - BACKUP_TTL=15

      - ZABBIX_HOSTNAME=openldap-fusiondirectory-app

      - REAPPLY_PLUGIN_SCHEMAS=TRUE
      - PLUGIN_SYSTEMS=TRUE
      - PLUGIN_ARGONAUT=TRUE
      - PLUGIN_USER_REMINDER=TRUE
      - PLUGIN_PPOLICY=TRUE
      - PLUGIN_SSH=TRUE
      - PLUGIN_SUDO=TRUE
      - PLUGIN_MAIL=TRUE
      - PLUGIN_DNS=TRUE

Thanks a lot.
Jerome

TLS_DH_PARAM_PATH & TLS_DH_PARAM_FILENAME options don't work

It seems like in tls-enable.ldif and 10-openldap, the variables are mistakenly called ..._DH_PARAM_... and ..._DHPARAM_... in such an infortunate way that it will always use the default values.

ENABLE_NGINX=false breaks the container

Hi,

In this case, in /etc/cont-init.d/09-nginx, the liftoff function is not called and the /etc/cont-init.d/99-container stop everything as the state file is not created.

Best,
Jerome

docker-compose combined file

After so many attempts to make it work I always come up with same results and nothing works.
Even though this looks promising I suspect its extremely complicated.
From my personal experience I always avoid s6 for multi-process containers.

To conclude and get to end my frustration.
I would appreciate it if you could share a simple and working docker-compose.yml combined file for both services ldap and fusiond with just the basic modules for domain example.org or whatever!

Kind regards,
Harry.

Wrong OpenLDAP configuration for TLS

Hey there!

I have a working ldap configuration (without TLS) and I'm now trying to add TLS authentication, which sadly doesn't work. After a bit of investigation i think i discovered a bug with the OpenLDAP initialization of this container.

Here is my docker-compose:

version: '3.7'

volumes:
  backup: {}
  data: {}
  config: {}

services:
  ldap:
    hostname: ldap.example.com
    image: tiredofit/openldap-fusiondirectory:latest
    container_name: ldap
    security_opt:
      - no-new-privileges:true
      - label:disable
    expose:
      - 389
      - 636
    volumes:
      - backup:/data/backup:rw,z
      - data:/var/lib/openldap:rw,z
      - config:/etc/openldap/slapd.d:rw,z
      - /etc/nginx/certs/ldap.tirion.org:/assets/slapd/certs:z
    environment:
      HOSTNAME: ldap.example.com
      BACKEND: mdb
      LOG_LEVEL: 256
      DOMAIN: example.com
      ADMIN_PASS_FILE: /run/secrets/LDAP_ADMIN_PASSWORD
      CONFIG_PASS_FILE: /run/secrets/LDAP_CONFIG_PASSWORD

      FUSIONDIRECTORY_ADMIN_USER: admin
      FUSIONDIRECTORY_ADMIN_PASS_FILE: /run/secrets/FD_ADMIN_PASSWORD
      ORGANIZATION: Example

      BASE_DN: "dc=example,dc=com"
      ENABLE_READONLY_USER: "TRUE"
      READONLY_USER_USER: readonly
      READONLY_USER_PASS_FILE: /run/secrets/LDAP_READONLY_USER_PASSWORD

      ENABLE_TLS: "TRUE"
      TLS_CRT_FILENAME: "cert.pem"
      TLS_KEY_FILENAME: "key.pem"
      TLS_CA_CRT_FILENAME: "fullchain.pem"
      TLS_ENFORCE: "FALSE"
      TLS_CIPHER_SUITE: SECURE256:+SECURE128:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-DHE-DSS:-CAMELLIA-128-CBC:-CAMELLIA-256-CBC
      TLS_DH_PARAM_KEYSIZE: 4096
      TLS_VERIFY_CLIENT: try
      SSL_HELPER_PREFIX: ldap
      #TLS_RESET_PERMISSIONS: "FALSE"

      ENABLE_REPLICATION: "false"
      REMOVE_CONFIG_AFTER_SETUP: "false"

      ENABLE_ZABBIX: "FALSE"

      PLUGIN_ALIAS: "TRUE"
      PLUGIN_ARGONAUT: "FALSE"
      PLUGIN_AUDIT: "TRUE"
      PLUGIN_DSA: "FALSE"
      PLUGIN_LDAPDUMP: "TRUE"
      PLUGIN_LDAPMANAGER: "TRUE"
      PLUGIN_MAIL: "TRUE"
      PLUGIN_PERSONAL: "TRUE"
      PLUGIN_PPOLICY: "TRUE"
      PLUGIN_SSH: "TRUE"
      PLUGIN_SUDO: "FALSE"
      PLUGIN_SOGO: "FALSE"
      PLUGIN_SYSTEMS: "FALSE"
      PLUGIN_WEBSERVICE: FALSE"
      PLUGIN_GPG: "TRUE"

      BACKUP_CONFIG_CRON_PERIOD: 0 4 * * *
      BACKUP_DATA_CRON_PERIOD: 0 4 * * *
      BACKUP_TTL: 15

      LETSENCRYPT_HOST: ldap.example.com
      LETSENCRYPT_EMAIL: [email protected]
    networks:
      - ldap
    restart: always

I'm using Let's Encrypt for my certificates.

When I'm now trying to check the TLS authentication (just using portainer for this) it fails with the following untypical log entry: TLS: could not load verify locations (file:"/assets/slapd/certs',dir:"'). So it seem that OpenLDAP is looking for a file but only a path is given.

After looking into /etc/openssl/ldap.conf of my ldap container i noticed this line: TLS_CACERT /assets/slapd/certs. But after the documentation of OpenLDAP, TLS_CACERT should point to the file not the path.

So i propose to change the line

docker-openldap/install/etc/cont-init.d/10-openldap

Line 476 in b80882c

echo "TLS_CACERT ${TLS_CA_CRT_PATH}" >> /etc/openldap/ldap.conf

to
echo "TLS_CACERTDIR ${TLS_CA_CRT_PATH}" >> /etc/openldap/ldap.conf

Access forbidden when pulling from URL in readme

docker pull registry.selfdesign.org/docker/openldap
Using default tag: latest

Error response from daemon: Get https://registry.selfdesign.org/v2/docker/openldap/manifests/latest: denied: access forbidden

docker pull tiredofit/openldap worked however :)

Bug in /usr/local/bin/slapd-restore

Summary

/usr/local/bin/slapd-restore is wrong.

Steps to reproduce

Try to restore a db archive: slapd-restore-data your_db_archive.gz

What is the expected correct behavior?

Data restoration should work.

Relevant logs and/or screenshots

Sorry, no logs.

Environment

Image version / tag: tiredofit/openldap version 7.1.16
Host OS: CentOS 8

Possible fixes

I fixed it like this:

#!/usr/bin/with-contenv bash
set -x

This file overwrite the original slapd-restore that comes with the container

and that is buggy

source /assets/functions/00-container
source /assets/defaults/10-openldap

Usage: /sbin/slapd-restore dbnum file

dbnum=$1
file=$2

backupPath="/data/backup"
file="$backupPath/$file"

stop slapd

s6-svc -d /var/run/s6/services/10-openldap
pkill slapd

sleep 5
ps aux

TEMP_FILE=$(mktemp)
gunzip -c $file > $TEMP_FILE
chown ldap:ldap $TEMP_FILE

if [ "$1" = "0" ]; then
rm -rf ${CONFIG_PATH}/slap.d/*
fi

if [ "$1" = "1" ]; then
rm -rf ${DB_PATH}/*
fi

sudo -u ldap slapadd -c -F /etc/openldap/slapd.d -n $dbnum -l $TEMP_FILE

restart slapd

s6-svc -u /var/run/s6/services/10-openldap

rm $TEMP_FILE

exit 0

Please fix the image so that it does not store passwords in clear text

This image stores passwords as clear text. Could this be fixed please so that passwords are stored as {SSHA}?

fwiw we modified the config to add olcPasswordHash: {SSHA} per this but it does not have any effect.

before:

$ cat config/cn=config/olcDatabase={-1}frontend.ldif
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 caf1c0c0
dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by self write by users read by anonymous auth
structuralObjectClass: olcDatabaseConfig
entryUUID: 315ac7fd-f18d-4dae-bad4-a4bb13bdac67
creatorsName: cn=config
createTimestamp: 20190429193904Z
entryCSN: 20190429193904.019284Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20190429193904Z

after:

bash-4.4# cat /etc/openldap/slapd.d/'cn=config'/'olcDatabase={-1}frontend.ldif'
# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 648305b0
dn: olcDatabase={-1}frontend
objectClass: olcDatabaseConfig
objectClass: olcFrontendConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by self write by users read by anonymous auth
structuralObjectClass: olcDatabaseConfig
entryUUID: b5e993b8-588e-4442-8b6e-184bc4b83544
creatorsName: cn=config
createTimestamp: 20190430195010Z
olcPasswordHash: {SSHA}
entryCSN: 20190430204532.177131Z#000000#000#000000
modifiersName: cn=admin,cn=config
modifyTimestamp: 20190430204532Z

but passwords continue to be stored in clear text (base64 encoded).

ReadOnly user does not work

Heho
The ReadOnly User can't be created:

2023-04-24.17:18:21 [NOTICE] ** [openldap] Adding read only (DSA) user
ldap_sasl_interactive_bind: Server is unwilling to perform (53)
	additional info: authentication required

This is on initial run with ENV:

      - ENABLE_READONLY_USER=TRUE
      - READONLY_USER_USER=readonly
      - READONLY_USER_PASS=password

BASE_DN is ignored

Commit 9000a6c (2019-12-30) introduced a problem during container initialization, starting from line 53 of /etc/cont-init.d/10-openldap:

  IFS='.' read -a domain_elems <<< "${DOMAIN}"
  SUFFIX=""
  ROOT=""

  for elem in "${domain_elems[@]}" ; do
      if [ "x${SUFFIX}" = x ] ; then
          SUFFIX="dc=${elem}"
          ROOT="${elem}"
      else
          BASE_DN="${SUFFIX},dc=${elem}"
      fi
  done

This snippet overwrites the BASE_DN environment variable, and that loop does not build it correctly from DOMAIN for a domain bigger than two components (e.g. my.example.org will end in BASE_DN=dc=my,dc=org).

Bug aside, this image is very handy, thank you for your work.

Init with ENABLE_READONLY_USER not working in latest version

Summary

When trying to deploy a new instance with ENABLE_READONLY_USER set to true it fails in the init script with command not found

Steps to reproduce

Spin up a new container with ENABLE_READONLY_USER set to true

What is the expected correct behavior?

Go through the init without issues.

Relevant logs and/or screenshots

The relevant log of the container:

2023-11-16.15:49:53 [NOTICE] ** [openldap] Adding default top level data configuration
/assets/slapd/config/bootstrap/default/default.sh: line 35: READONLY_USER_PASS: command not found
2023-11-16.15:49:53 [NOTICE] ** [openldap] Adding read only (DSA) user
ldap_sasl_interactive_bind: Server is unwilling to perform (53)
additional info: authentication required

The complete log:

2023-11-16.15:49:11 [NOTICE] ** [monitoring] Container configured for monitoring with 'zabbix modern'
2023-11-16.15:49:11 [NOTICE] ** [scheduling] Container configured for scheduled tasks with 'cron'
2023-11-16.15:49:12 [NOTICE] ** [messaging] Container configured to route mail via SMTP to 'postfix-relay'
2023-11-16.15:49:12 [NOTICE] ** [openldap] Setting up directories
2023-11-16.15:49:12 [NOTICE] ** [openldap] Configuring OpenLDAP server
2023-11-16.15:49:12 [WARN] ** [openldap] First time install detected
2023-11-16.15:49:12 [NOTICE] ** [openldap] Using NIS schema type
2023-11-16.15:49:14 [NOTICE] ** [openldap] Converting schemas to LDIF
2023-11-16.15:49:14 [NOTICE] ** [openldap] Adding converted schemas
2023-11-16.15:49:14 [NOTICE] ** [openldap] Setting Security and ACLs
2023-11-16.15:49:14 [NOTICE] ** [openldap] Add bootstrap LDIFs
2023-11-16.15:49:14 [NOTICE] ** [openldap] Starting TLS configuration. Please wait
2023-11-16.15:49:15 [NOTICE] ** [openldap] Certificates: DH Param - Creating '/certs//dhparam.pem'
2023-11-16.15:49:53 [NOTICE] ** [openldap] Adding default top level data configuration
/assets/slapd/config/bootstrap/default/default.sh: line 35: READONLY_USER_PASS: command not found
2023-11-16.15:49:53 [NOTICE] ** [openldap] Adding read only (DSA) user
ldap_sasl_interactive_bind: Server is unwilling to perform (53)
additional info: authentication required
2023-11-16.15:49:53 [NOTICE] ** [openldap] Configuring LDAP client
2023-11-16.15:49:53 [NOTICE] ** [openldap] Enabling OpenLDAP scheduled backup routines
2023-11-16.15:49:53 [NOTICE] ** [openldap] Configuring PPolicy check modules
2023-11-16.15:49:53 [STARTING] ** [openldap] [1] Starting OpenLDAP 2.6.6
65563a21.2e039be0 0x7f5c2d426b48 @(#) $OpenLDAP: slapd 2.6.6 (Jul 31 2023 22:34:30) $
@buildkitsandbox:/tiredofit/openldap:2.6-7.6.3/servers/slapd
65563a21.2e86a550 0x7f5c2d426b48 slapd starting
2023-11-16.15:49:53 [STARTING] ** [monitoring] [1] Starting Zabbix Agent (modern) 6.4.2
2023-11-16.15:49:53 [STARTING] ** [scheduling] [1] Starting cron
date: invalid date ‘202311160400’
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Next Backup at 1970-01-02 00:00:00 GMT
sleep: invalid option -- '1'
Try 'sleep --help' for more information.
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Backing up configuration schemas
2023-11-16.15:49:58 [INFO] ** [openldap-backup] OpenLDAP Backup of 'config' completed successfully
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Backing up user data
2023-11-16.15:49:58 [INFO] ** [openldap-backup] OpenLDAP Backup of 'data' completed successfully
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Compressing backup with zstd
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Generating MD5 for '20231116-154958-openldap_openldap-65fd576b7f-cxm7n.tar.zst'
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Backup of 20231116-154958-openldap_openldap-65fd576b7f-cxm7n.tar.zst created with the size of 8881 bytes
2023-11-16.15:49:58 [INFO] ** [openldap-backup] Backup routines finish time: 2023-11-16 15:49:58 GMT with overall exit code 0
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Backup routines time taken: Hours: 0 Minutes: 00 Seconds: 00
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Sending Backup Statistics to Zabbix
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Cleaning up old backups
2023-11-16.15:49:58 [NOTICE] ** [openldap-backup] Sleeping for another 86400 seconds. Waking up at 2023-11-17 15:49:58 GMT

Environment

Image version / tag: tiredofit/openldap:2.6
Host OS: Kubernetes Cluster on Debian Nodes

Possible fixes

It seems to me that this may be a simple typo. The error states:
/assets/slapd/config/bootstrap/default/default.sh: line 35

This is the relevant code:

transform_file_var \
                ADMIN_PASS \
                READONLY_USER_USER
                READONLY_USER_PASS

Probably adding a \ to line 34 may solve the problem:

transform_file_var \
                ADMIN_PASS \
                READONLY_USER_USER \
                READONLY_USER_PASS

[Feature Request][PR] Add contrib/autogroup overlay for dynamic group setups

Hi!

Thanks for the helpful image!

As dynlist ist not yet compatible with memberOf in openldap 2.4 (but judging from the docs might be in 2.5) autogroup is the only solution for using dynamic URL group expansion.

The overlay still compiles flawlessly, so I submitted a PR ( #37 ) if you like to add this functionality to your image.

Cheers,

Jörn

How to use existing certificate and key? Starup script seems to always try to create a self-signed certificate

Summary

I'm using tiredofit/openldap-fusiondirectory:1.4-7.1.4 image.

I'm mapping existing certificate and key into /certs directory as a read-only volume, startup fails when 10-openldap script always try to create self-signed certificate and private key and overwrite existing files.

Steps to reproduce

I have a certificate with the private key in /etc/letsencrypt/live/ldap.example.com:

cert.pem  chain.pem  fullchain.pem  privkey.pem  README

In docker-compose.yml, I have:

    volumes:
      - /etc/letsencrypt/live/ldap.example.com:/certs:ro

And TLS-related env vars:

      - TLS_CREATE_CA=FALSE
      - TLS_CRT_PATH=/certs
      - TLS_CRT_FILENAME=fullchain.pem
      - TLS_KEY_PATH=/certs
      - TLS_KEY_FILENAME=privkey.pem
      - TLS_DH_PARAM_PATH=/certs
      - TLS_ENFORCE=TRUETLS_CIPHER_SUITE=ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:-DHE-DSS:-RSA:!aNULL:!MD5:!DSS:!SHA

What is the expected correct behavior?

The container should start succesfully and use the existing certificate and private key.

Relevant logs and/or screenshots

openldap-fusiondirectory-app    | 2021-09-12-07:57:12 [NOTICE] /etc/cont-init.d/10-openldap ** [openldap] Starting TLS configuration. Please wait
openldap-fusiondirectory-app    | + certificates /certs/fullchain.pem
openldap-fusiondirectory-app    | + case "$1" in
openldap-fusiondirectory-app    | + var_true TRUE
openldap-fusiondirectory-app    | + '[' TRUE = TRUE ']'
openldap-fusiondirectory-app    | + certificates_check_certificates /certs/fullchain.pem
openldap-fusiondirectory-app    | + print_debug 'Certificates: Checking existence of /certs/fullchain.pem'
openldap-fusiondirectory-app    | + output_off
openldap-fusiondirectory-app    | + '[' TRUE = TRUE ']'
openldap-fusiondirectory-app    | + set +x
openldap-fusiondirectory-app    | 2021-09-12-07:57:12 [DEBUG] /etc/cont-init.d/10-openldap ** [openldap] Certificates: Checking existence of /certs/fullchain.pem
openldap-fusiondirectory-app    | + '[' '!' -f /certs/fullchain.pem ']'
openldap-fusiondirectory-app    | ++ dirname /certs/fullchain.pem
openldap-fusiondirectory-app    | + mkdir -p /certs
openldap-fusiondirectory-app    | + certificates_create_certificate /certs/fullchain.pem
openldap-fusiondirectory-app    | + '[' /certs/fullchain.pem '!=' '' ']'
openldap-fusiondirectory-app    | + var_true FALSE
openldap-fusiondirectory-app    | + '[' FALSE = TRUE ']'
openldap-fusiondirectory-app    | + '[' FALSE = true ']'
openldap-fusiondirectory-app    | + '[' FALSE = YES ']'
openldap-fusiondirectory-app    | + '[' FALSE = yes ']'
openldap-fusiondirectory-app    | + CERT_SUBJECT=/C=XX/ST=LDAP/L=LDAP/O=LDAP/CN=ldap.internetapi.cn
openldap-fusiondirectory-app    | + var_true FALSE
openldap-fusiondirectory-app    | + '[' FALSE = TRUE ']'
openldap-fusiondirectory-app    | + '[' FALSE = true ']'
openldap-fusiondirectory-app    | + '[' FALSE = YES ']'
openldap-fusiondirectory-app    | + '[' FALSE = yes ']'
openldap-fusiondirectory-app    | + '[' '!' -f /certs/privkey.pem ']'
openldap-fusiondirectory-app    | + print_debug 'Certificates: Creating Certificate: /certs/fullchain.pem'
openldap-fusiondirectory-app    | + output_off
openldap-fusiondirectory-app    | + '[' TRUE = TRUE ']'
openldap-fusiondirectory-app    | + set +x
openldap-fusiondirectory-app    | 2021-09-12-07:57:12 [DEBUG] /etc/cont-init.d/10-openldap ** [openldap] Certificates: Creating Certificate: /certs/fullchain.pem
openldap-fusiondirectory-app    | + silent eval 'openssl req                 -new -x509 -nodes -days 3650                 -config /etc/ssl/openssl.cnf
  -out /certs/fullchain.pem                 -keyout /certs/privkey.pem'
openldap-fusiondirectory-app    | + '[' TRUE = TRUE ']'
openldap-fusiondirectory-app    | + eval 'openssl req                 -new -x509 -nodes -days 3650                 -config /etc/ssl/openssl.cnf                 -out /certs/fullchain.pem                 -keyout /certs/privkey.pem'
openldap-fusiondirectory-app    | ++ openssl req -new -x509 -nodes -days 3650 -config /etc/ssl/openssl.cnf -out /certs/fullchain.pem -keyout /certs/privkey.pem
openldap-fusiondirectory-app    | Generating a RSA private key
openldap-fusiondirectory-app    | .................................+++++
openldap-fusiondirectory-app    | ....................................+++++
openldap-fusiondirectory-app    | writing new private key to '/certs/privkey.pem'
openldap-fusiondirectory-app    | req: Can't open "/certs/privkey.pem" for writing, No such file or directory
openldap-fusiondirectory-app    | [cont-init.d] 10-openldap: exited 1.
openldap-fusiondirectory-app    | [cont-init.d] 99-container: executing...
openldap-fusiondirectory-app    | + PROCESS_NAME=container
openldap-fusiondirectory-app    | + var_false FALSE
openldap-fusiondirectory-app    | + '[' FALSE = FALSE ']'
openldap-fusiondirectory-app    | + output_off
openldap-fusiondirectory-app    | + '[' TRUE = TRUE ']'
openldap-fusiondirectory-app    | + set +x
openldap-fusiondirectory-app    | **********************************************************************************************************************
openldap-fusiondirectory-app    | **********************************************************************************************************************
openldap-fusiondirectory-app    | ****                                                                                                              ****
openldap-fusiondirectory-app    | ****       ERROR - Some initialization scripts haven't completed - All services are now halted                    ****
openldap-fusiondirectory-app    | ****             - The following scripts in '/etc/cont-init.d' did not pass their completion check                ****

Environment

Image version / tag: tiredofit/openldap-fusiondirectory:1.4-7.1.4
Host OS: Centos 7.6

Any logs | docker-compose.yml

Possible fixes

Errors in ./run but ldapd seems started

When the openldap starts, I get those errors in the logs:

openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | [INFO] ** [openldap] Starting OpenLDAP 
openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | ./run: line 17: unexpected EOF while looking for matching `"'
openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | ./run: line 19: syntax error: unexpected end of file
openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | 5e0dcb45 @(#) $OpenLDAP: slapd 2.4.48 (Jan  1 2020 04:50:13) $
openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | 	@48f7866aff2f:/tiredofit/openldap:6.6.1/servers/slapd
openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | ./run: line 17: unexpected EOF while looking for matching `"'
openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | ./run: line 19: syntax error: unexpected end of file
openldap-fusiondirectory_openldap-fusiondirectory.1.lp8ifqeq7h9a@swarm2-node2.gnubila.fr    | 5e0dcb45 slapd starting

Is it a configuration issue on my side ?
Best,
Jerome

Waiting for OpenLDAP to be ready

tried this image and output is stuck at Waiting for OpenLDAP to be ready

$ docker logs -f jnj-ldap-server
[s6-init] making user provided files available at /var/run/s6/etc...exited 0.
[s6-init] ensuring user provided files have correct perms...exited 0.
[fix-attrs.d] applying ownership & permissions fixes...
[fix-attrs.d] 01-run: applying... 
[fix-attrs.d] 01-run: exited 0.
[fix-attrs.d] 01-s6: applying... 
[fix-attrs.d] 01-s6: exited 0.
[fix-attrs.d] 02-zabbix: applying... 
[fix-attrs.d] 02-zabbix: exited 0.
[fix-attrs.d] 03-logrotate: applying... 
[fix-attrs.d] 03-logrotate: exited 0.
[fix-attrs.d] done.
[cont-init.d] executing container initialization scripts...
[cont-init.d] 01-permissions: executing... 
[cont-init.d] 01-permissions: exited 0.
[cont-init.d] 02-zabbix: executing... 
[cont-init.d] 02-zabbix: exited 0.
[cont-init.d] 03-cron: executing... 
**** [cron] Enabling Cron
[cont-init.d] 03-cron: exited 0.
[cont-init.d] 04-smtp: executing... 
**** [smtp] Disabling SMTP Features
[cont-init.d] 04-smtp: exited 0.
[cont-init.d] 09-nginx: executing... 
[cont-init.d] 09-nginx: exited 0.
[cont-init.d] 10-openldap: executing... 
** [openldap] First time install detected
** [openldap] Using NIS schema type
** [openldap] Starting OpenLDAP Initialization Sequence
** [openldap] Waiting for OpenLDAP to be ready

script 10-openldap fails if 79 character line wrap occurs

Summary

The slapd server won't start if the replhosts_sanity can't be resolved to an ip address. This happens, because the fqdn of the hostname behind the provider label is wrapped to the next line.

Steps to reproduce

I configured replication and used a long fqdn (Kubernetes StatefulSet Service) which will be wrapped by the slapd automatically.

What is the expected correct behavior?

Start of the slapd without an error

Relevant logs and/or screenshots

+ var_true FALSE
+ '[' FALSE = TRUE ']'
+ '[' FALSE = true ']'
+ '[' FALSE = YES ']'
+ '[' FALSE = yes ']'
+ '[' -e /etc/openldap/slapd.d/docker-openldap-was-started-with-replication ']'
+ set +e
++ grep -o ++ awk -h -F '[//]' '{ print $3 }'
'provider=ldap.*//.*.' '/etc/openldap/slapd.d/cn=config/olcDatabase={-1}frontend.ldif' '/etc/openldap/slapd.d/cn=config/olcDatabase={0}config.ldif' '/etc/openldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif' '/etc/openldap/slapd.d/cn=config/olcDatabase={2}monitor.ldif'
++ awk -F binddn '{ print $1 }'
++ awk '!a[$0]++'
++ sed 's/  / /g'
++ ++ tr '\n' ' '
awk '!a[$0]++'
+ replhosts_sanity='openldap-0.openldap-headless.startse openldap-1.openldap-headless.startse '
+ '[' '!' -z 'openldap-0.openldap-headless.startse openldap-1.openldap-headless.startse ' ']'
+ for sanity_host in $replhosts_sanity
+ [[ openldap-0.openldap-headless.startse =~ ^[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+$ ]]
++ getent hosts openldap-0.openldap-headless.startse
++ awk '{ print $1 }'
+ sanity_ip=
+ '[' -z '' ']'
+ exit 1
[cont-init.d] 10-openldap: exited 1.

Environment

Image version / tag: 7.0.3
Host OS: ubuntu 18.04 / kubernetes 1.19.10

Example ldif file in the /etc/openldap/slap.d/cn=config directory:

olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcDbIndex: objectClass eq
olcAccess: {0}to attrs=userPassword,shadowLastChange by self =xw by dn="cn=a
 dmin,dc=xxxxxxxxx,dc=xx,dc=com" write by anonymous auth by * none
olcAccess: {1}to * by self write by dn="cn=admin,dc=xxxxxxxxx,dc=xx,dc=com" 
 write by * read
olcAccess: {2}to * by self read by dn="cn=admin,dc=xxxxxxxxx,dc=xx,dc=com" w
 rite by dn="cn=reader,dc=xxxxxxxxx,dc=xx,dc=com" read by * none
olcSyncrepl: {0}rid=101 provider=ldap://openldap-0.openldap-headless.startse
 ite.svc.cluster.local binddn="cn=admin,dc=xxxxxxxxx,dc=xx,dc=com" bindmetho
 d=simple credentials=PASSWORD1 searchbase="dc=xxxxxxxxx,dc=xx,dc=com" type=
 refreshAndPersist interval=00:00:00:10 retry="60 +" timeout=1 tls_reqcert=n
 ever
olcSyncrepl: {1}rid=102 provider=ldap://openldap-1.openldap-headless.startse
 ite.svc.cluster.local binddn="cn=admin,dc=xxxxxxxxx,dc=xx,dc=com" bindmetho
 d=simple credentials=PASSWORD1 searchbase="dc=xxxxxxxxx,dc=xx,dc=com" type=
 refreshAndPersist interval=00:00:00:10 retry="60 +" timeout=1 tls_reqcert=n
 ever
olcMirrorMode: TRUE
entryCSN: 20210507110835.079923Z#000000#002#000000
modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth

Possible fixes

The lines have to be joined before trying to grep the content or the regex has to be extended so that multiple lines are joined correctly.

I found the following as a description how openldap actually splits the lines automatically:

OpenLDAP deletes the first white space of a continuation line and joins all lines.

s3 backup error : curl: (3) URL using bad/illegal format or missing URL

When using the S3 Backup, receiving the following error:

curl: (3) URL using bad/illegal format or missing URL

Possible Cause

The bucket name is ldap01.localdomain which has a .. When I run curl manually, this works fine, however i wonder if with the escaping it is causing an issue.

Config

The following environmental variables are set in my docker-compose file.

      - ENABLE_BACKUP=TRUE
      - BACKUP_INTERVAL=1440
      - BACKUP_RETENTION=10080
      - BACKUP_COMPRESSION=BZ
      - BACKUP_COMPRESSION_LEVEL
      - BACKUP_TYPE=S3
      - S3_BUCKET='ldap01.localdomain'
      - S3_HOST='s3.localdomain'
      - S3_KEY_ID="ldap01"
      - S3_KEY_SECRET="BIGPASSWORDHERE"
      - S3_PATH='openldap-backup'
      - S3_PROTOCOL='https'
      - S3_URI_STYLE='PATH'

Logs

[DEBUG] /etc/services.available/20-openldap-backup/run ** [openldap-backup] Uploading 20210316-162253_openldap_data.bz2.md5 to S3
+ curl -T /tmp/backups/20210316-162253_openldap_data.bz2.md5 ''\''https'\''://'\''s3.localdomain'\''/'\''ldap01.localdomain-backup'\''/'\''openldap-backup'\''/20210316-162253_openldap_data.bz2.md5' -H 'Date: ' -H 'Authorization: AWS "ldap01":PASSWORd' -H 'Content-Type: application/octet-stream' -H 'Content-MD5: <MD5HASH>'
curl: (3) URL using bad/illegal format or missing URL

Password policy parameters

Password policy values will overwrite the default /etc/openldap/check_password.,conf values but fail to overwrite the /etc/openldap/ppm.conf.

ulimit 1024 iset in start script

Hi,

I am running into a connection limit. I tried to set ulimit(nofile - soft and hard) in my docker-compose file, but ulimit of the slapd process is still set to 1024.

I found that you have hardcoded the ulimit -n call in the /etc/s6/services/10-openldap/run file. Could you please either remove that line or make that parameter configurable.

In my case it would be enough to set a global ulimit nofile in my docker config. I don't need a specific config value for the slapd process itself.

Thanks,
David Ecker

cp: cannot stat '/assets/slapd/config/bootstrap/scfhema/rfc2307bis/rfc2307bis.schema': No such file or directory

Thanks for your work!
There is a typo in the line:

docker-openldap/install/assets/functions/10-openldap

Line 708 in e65c56c

 cp -R /assets/slapd/config/bootstrap/scfhema/rfc2307bis/rfc2307bis.schema /etc/openldap/schema/ 

scfhema should be schema.

TLS/startTLS encryption not stable

Hi,

Does anybody already faced the same issue than me. I setup this image (actually, the fusiondirectory one but I think that this comes from this base image) to use Let'sencrypt certificates (externally managed).

WHen I start the image, everything works as expected but after a couple of hours the TLS/startTLS encryption seems to stop working... again, after some hours more, everything is back to normal. This Let'sencrypt certificates are not modified during that time and the container does not restart or whatever.

I have for instance a process which query the ldap every minute: everything worked this night and since this morning, I have the following issue:

ldap_start_tls: Connect error (-11)
	additional info: Public key signature verification has failed.
ldap_result: Can't contact LDAP server (-1)

The error server side is:

TLS: can't accept: error:1403710B:SSL routines:ACCEPT_SR_KEY_EXCH:wrong version number.
openldap-fusiondirectory_openldap-fusiondirectory.1.c574qn099eaa@xxxxxxxx.gnubila.fr    | 5db7e51b conn=30845 fd=18 closed (TLS negotiation failure)

As I said, even without touching anything, it will work again in a couple of hours but of course, if I restart the container now everything works for some hours...

I really don't understand what could be the problem. Do you have an idea please ?

Best,
Jerome

Add documentation to zabbix configuration

Description of the feature

Add documentation to have a better understanding of how to use it
Benftits of feature

User can easy set zabbix monitoring

chmod for custom scripts fails on read-only file systems

I was attempting to use your wonderful image in my k8s deployment by mounting my custom startup script directly under /assets/custom-scripts/ from a configMap resource. I had been careful to ensure my file was mounted as executable using defaultMode. Unfortunately, startup fails due the chmod command which attempts to modify the file which in a read-only file system:

docker-openldap/install/assets/functions/10-openldap

Lines 551 to 559 in cc7c325

 ## Execute Custom Scripts (To be used for example for tiredofit/openldap-fusiondirectory) 

 if [ -d /assets/custom-scripts/ ]; then 

 print_notice "Found custom scripts to execute" 

 for f in $(find /assets/custom-scripts/ -name \*.sh -type f); do 

 print_debug "Running Script ${f}" 

 chmod +x ${f} 

 ${f} 

 done 

 else

I would argue that it should be the user's responsibility to ensure scripts are executable and not the startup script. The chmod command assumes the file system is writable, which forces a much more complex deployment approach.

Initialization script bails mid-way through first launch

Summary

When launching the container for the first time, the 10-openldap initialization script appears to fail at the "converting schemas to LDIF" part and stop running at that point. The server still seems to launch and function (which actually seems to contradict the message it says where "all services are now halted"?), but looking into the server shows there are things missing that would otherwise be there.

This issue disappears when using the 7.1.22 image.

Steps to reproduce

Launch a brand-new container on the 7.2.0 (or latest) tag.
Watch logs and notice that slaptest fails, causing 10-openldap to exit uncleanly.

What is the expected correct behavior?

The openldap initialization script completes its tasks and exits normally.

Relevant logs and/or screenshots

+ print_notice 'Converting schemas to LDIF'
+ output_off
+ '[' TRUE = TRUE ']'
+ set +x
2021-11-12-23:26:28 [NOTICE] /etc/cont-init.d/10-openldap ** [openldap] Converting schemas to LDIF
+ schemas=
++ find /assets/slapd/config/bootstrap/schema -not -path '/assets/slapd/config/bootstrap/schema/rfc2307bis/*' -name '*.schema' -type f
+ schema2ldif ''
+ schemas=
+ '[' nis = rfc2307bis ']'
+ '[' nis = RFC2307BIS ']'
+ SCHEMA_TYPE=nis
++ mktemp -d
+ tmpd=/tmp/tmp.BhUKtNHFTB
+ pushd /tmp/tmp.BhUKtNHFTB
+ echo 'include /etc/openldap/schema/core.schema'
+ echo 'include /etc/openldap/schema/cosine.schema'
+ echo 'include /etc/openldap/schema/nis.schema'
+ echo 'include /etc/openldap/schema/inetorgperson.schema'
+ silent slaptest -f convert.dat -F .
+ '[' TRUE = TRUE ']'
+ slaptest -f convert.dat -F .
config_setup_ldif: expected directory . to be empty!
slaptest: bad configuration directory!
[cont-init.d] 10-openldap: exited 1.
[cont-init.d] 99-container: executing... 
+ PROCESS_NAME=container
+ var_false FALSE
+ '[' FALSE = FALSE ']'
+ output_off
+ '[' TRUE = TRUE ']'
+ set +x
**********************************************************************************************************************
**********************************************************************************************************************
****                                                                                                              ****
****       ERROR - Some initialization scripts haven't completed - All services are now halted                    ****
****             - The following scripts in '/etc/cont-init.d' did not pass their completion check                ****
****                                                                                                              ****
**********************************************************************************************************************
**********************************************************************************************************************

10-openldap


**********************************************************************************************************************
**********************************************************************************************************************
****                                                                                                              ****
****       This could have happened for a variety of reasons. Please make sure you have followed the README       ****
****       relating to this image and have proper configuration such as environment variables and volumes set     ****
****                                                                                                              ****
****       If you feel that you have encountered a bug, please submit an issue on the revision control system     ****
****       and provide full debug logs by setting the environment variable 'DEBUG_MODE=TRUE'                      ****
****                                                                                                              ****
**********************************************************************************************************************
**********************************************************************************************************************
[cont-init.d] 99-container: exited 1.
[cont-init.d] done.
[services.d] starting services
[services.d] done.

Environment

Image version / tag: latest
Host OS: Ubuntu 20.04 LTS

Any logs | docker-compose.yml

Possible fixes

It seems like there was a change to slaptest where it requires the destination config directory to be empty, but that directory is also where the file with the schemas to be converted are located. I haven't tested it myself, but I wonder if making a new directory within the temp directory and using that for the destination config directory would resolve the issue.

ldapmodify run too early ?

Hi,

Since a couple of days now, I have this issue when I start the openldap:

openldap-fusiondirectory_openldap-fusiondirectory.1.q4foxiznvu1o@XXXXXXXXXXXXX    | + silent ldapmodify -Y EXTERNAL -Q -H ldapi:/// -f /assets/slapd/config/tls/tls-enable.ldif
openldap-fusiondirectory_openldap-fusiondirectory.1.q4foxiznvu1o@XXXXXXXXXXXXX    | + '[' TRUE = TRUE ']'
openldap-fusiondirectory_openldap-fusiondirectory.1.q4foxiznvu1o@XXXXXXXXXXXXX    | + ldapmodify -Y EXTERNAL -Q -H ldapi:/// -f /assets/slapd/config/tls/tls-enable.ldif
openldap-fusiondirectory_openldap-fusiondirectory.1.q4foxiznvu1o@XXXXXXXXXXXXX    | ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
openldap-fusiondirectory_openldap-fusiondirectory.1.q4foxiznvu1o@XXXXXXXXXXXXX    | [cont-init.d] 10-openldap: exited 255.

But, in fact, if I login into the container and run the same command it works:

bash-5.0#  cat /run/openldap/slapd.pid
695
bash-5.0# ps aux |grep 695
  695 ldap      0:01 slapd -h ldap://ldap2.gnubila.fr ldapi:/// -u ldap -g ldap -d 256
 1591 root      0:00 grep 695
bash-5.0# ldapmodify -Y EXTERNAL -Q -H ldapi:/// -f /assets/slapd/config/tls/tls-enable.ldif
modifying entry "cn=config"

bash-5.0#

I suspect that the ldap server is not properly started before ldapmodify run the first time. Is it possible ? Do you have a solution ?

Best,
Jerome

Do not see any search results

we don't see any search results using this image. here is what we did:

Started the server by running following command:

docker run -p 636:636 -p 389:389 --name jnj-ldap-server --env BACKEND=mdb --env ENABLE_TLS=false --env BASE_DN=dc=jnj,dc=com --env TLS_VERIFY_CLIENT=never --env TLS_ENFORCE=false --env HOSTNAME=localhost --env DOMAIN=jnj.com --env ADMIN_PASS=superman --env CONFIG_PASS=spiderman --env 'ORGANIZATION=Johnson & Johnson' --env LOG_LEVEL=1 --log-opt max-file=3 --log-opt max-size=10m --detach tiredofit/openldap

Make a query by running following commands:

$ export BASE_DN=dc=jnj,dc=com
$ export ADMIN_PASS=superman
$ ldapsearch -x -h localhost -p 389 -b $BASE_DN -D "cn=admin,dc=jnj,dc=com" -w $ADMIN_PASS

Expected: Result for the admin user

Observed:

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

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

# numResponses: 1

Server log can be found here. Is there something wrong that we are doing?

Envrionment Variable ADD_DEFAULT_DATA is not documented

Summary

Environment Variable ADD_DEFAULT_DATA is not documented

Steps to reproduce

Search ADD_DEFAULT_DATA in README.md -> Not found

What is the expected correct behavior?

Add documentation for ADD_DEFAULT_DATA

Relevant logs and/or screenshots

Environment

Image version / tag:
Host OS:

Any logs | docker-compose.yml

We should document that if custom script exists, ADD_DEFAULT_DATA is ignored as well as ENABLE_READONLY_USER

Possible fixes

Add documentation
Execute ADD_DEFAULT_DATA and ENABLE_READONLY_USER sequence even if we have custom scripts

	## Execute Custom Scripts (To be used for example for tiredofit/openldap-fusiondirectory)
	if [ -d /assets/custom-scripts/ ]; then
	print_notice "Found custom scripts to execute"
	for f in $(find /assets/custom-scripts/ -name \*.sh -type f); do
	print_debug "Running Script ${f}"
	chmod +x ${f}
	${f}
	done
	else

tiredofit / docker-openldap Goto Github PK

docker-openldap's Introduction

github.com/tiredofit/docker-openldap

Maintainer

See individual branches

docker-openldap's People

Contributors

Stargazers

Watchers

Forkers

docker-openldap's Issues

Log

2 questions please

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

Environment

Issues

Setting Backups to S3

S3 Environment variables are incorrect

Missing libressl

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

This file overwrite the original slapd-restore that comes with the container

and that is buggy

Usage: /sbin/slapd-restore dbnum file

stop slapd

restart slapd

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

Possible Cause

Config

Logs

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes

Summary

Steps to reproduce

What is the expected correct behavior?

Relevant logs and/or screenshots

Environment

Possible fixes