For some test purposes I've needed to setup OpenLDAP server on my Gentoo workstation (importing initial tree from file) and find very unclear error messages. Remember: # grep ldap /etc/passwd ldap:x:439:439:added by portage for openldap:/usr/lib64/openldap:/sbin/nologin (login for ldap user, required for operational directories, is not permitted) Reproducible: Always Steps to Reproduce: 1. Install net-nds/openldap 2. Change default config accordingly test tree. 3. Import a test tree (from root shell using slapadd utility). 4. Try to start server (i.e. rc-service slapd start) Actual Results: The result is standard openrc error message: # rc-service slapd start * Starting ldap-server ... * start-stop-daemon: failed to start `/usr/lib64/openldap/slapd' [ !! ] * ERROR: slapd failed to start Expected Results: In slapd.log (it's setup is another question) I see the following error message: Feb 26 16:24:38 gentoo slapd[16400]: @(#) $OpenLDAP: slapd 2.4.35 (Feb 25 2014 15:53:54) $ @gentoo:/var/tmp/portage/net-nds/openldap-2.4.35-r1/work/openldap-2.4.35/servers/slapd Feb 26 16:24:38 gentoo slapd[16402]: hdb_db_open: database "dc=su": alock package is unstable. Feb 26 16:24:38 gentoo slapd[16402]: backend_startup_one (type=hdb, suffix="dc=su"): bi_db_open failed! (-1) Feb 26 16:24:38 gentoo slapd[16402]: slapd stopped. (also not clear) Fixing permissions: # chown ldap:ldap /var/lib/openldap-data/* makes issue go away. So, I expect from slapd init script at least warning about operational files (in /var/lib/openldap-data/) are not owned by ldap user, or even forcely set then correct owner:group. Similiar, but with a little bit more informative log message is the issue about owning files in /etc/openldap/slapd.d config directory (created from slapd.conf by slaptest utility) is provided by slapd-ldif backend. Error message in log is: Feb 26 16:22:30 gentoo slapd[16344]: @(#) $OpenLDAP: slapd 2.4.35 (Feb 25 2014 15:53:54) $ @gentoo:/var/tmp/portage/net-nds/openldap-2.4.35-r1/work/openldap-2.4.35/servers/slapd Feb 26 16:22:30 gentoo slapd[16344]: ldif_read_file: Permission denied for "/etc/openldap/slapd.d/cn=config.ldif" Feb 26 16:22:30 gentoo slapd[16344]: slapd stopped. Feb 26 16:22:30 gentoo slapd[16344]: connections_destroy: nothing to destroy. Command to fix: chown -R ldap:ldap /etc/openldap/slapd.d/ Expected behaviour is similiar with main data directory (/var/lib/openldap-data/). At last, the log message at successful slapd start: Feb 26 16:25:23 gentoo slapd[16436]: @(#) $OpenLDAP: slapd 2.4.35 (Feb 25 2014 15:53:54) $ @gentoo:/var/tmp/portage/net-nds/openldap-2.4.35-r1/work/openldap-2.4.35/servers/slapd Feb 26 16:25:23 gentoo slapd[16438]: hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/openldap-data: (2). Expect poor performance for suffix "dc=su". Feb 26 16:25:23 gentoo slapd[16438]: slapd starting At this point I expect init script to perform a check of existance of DB_CONFIG file (/var/lib/openldap-data/DB_CONFIG), and, if missed, duplicate slapd warning to stdout (and rc.log): No DB_CONFIG file found in directory /var/lib/openldap-data. Expect poor performance.
in 2.4.40
First off, this check is broken: themis ~ # /etc/init.d/slapd start [....... sits forever] checkconfig() { # checks requested by bug #502948 for d in `awk '/^directory/{print $2}'`; do The awk command is waiting for stdin, which it's never going to get... I assume that's supposed to be awk '/^directory/{print $2}' /etc/openldap/slapd.conf Second, I disagree with the premise behind these checks. An init script shouldn't necessarily check for such basic admin screwups. The errors are pretty simple to figure out, particularly if you have any experience with managing openldap. Also, if you're using the mdb backend (the preferred backend at this point), there is zero need for a DB_CONFIG, so complaining that one doesn't exist seems less than forward looking. As for: # grep ldap /etc/passwd ldap:x:439:439:added by portage for openldap:/usr/lib64/openldap:/sbin/nologin # su -s /bin/bash ldap ldap@themis /var/lib/openldap-data $ It's a best practice to *always* manipulate your ldap databases as the ldap user, which is trivial to do. The current ebuild is completely broken, and results in a complete inability to start the slapd process. I'd say you should back out this change completely and switch this to RESOLVED WONTFIX 8-/... Thanks...
Just to follow up on this concept of checking for every possible admin mistake, after creating a local ebuild to fix the init script bug I went to start the ldap server I'm building, and it failed: themis ~ # /etc/init.d/slapd start * Starting ldap-server ... * start-stop-daemon: failed to start `/usr/lib64/openldap/slapd' [ !! ] * ERROR: slapd failed to start Oct 24 17:23:22 themis slapd[45732]: @(#) $OpenLDAP: slapd 2.4.40 (Oct 24 2014 17:20:06) $ Oct 24 17:23:22 themis slapd[45732]: main: TLS init def ctx failed: -1 Oct 24 17:23:22 themis slapd[45732]: slapd stopped. Oct 24 17:23:22 themis slapd[45732]: connections_destroy: nothing to destroy. While I immediately realized I'd forgotten to copy the cert in, let's assume I was confused and didn't know what "main: TLS init def ctx failed: -1" meant. Simply running the slapd process in debug mode: themis ~ # /usr/lib64/openldap/slapd -d 1 -u ldap -g ldap -h 'ldaps:// ldap://' [...] TLS: could not use certificate `/etc/openldap/ldap.cpp.edu.cert'. TLS: error:02001002:system library:fopen:No such file or directory bss_file.c:398 TLS: error:20074002:BIO routines:FILE_CTRL:system lib bss_file.c:400 TLS: error:140AD002:SSL routines:SSL_CTX_use_certificate_file:system lib ssl_rsa.c:470 544aeebd main: TLS init def ctx failed: -1 Makes it blindingly obvious what's going on, just as I'm sure running in debug mode would have made the OP's "confusing" errors easy to understand. Should we add another check to the initd that awks out all the TLS config and makes sure if it's there the referenced files exist? Sheesh, no; how about a little personal responsibility and expectation of basic debugging skills? Thanks...
(In reply to Paul B. Henson from comment #2) > I assume that's supposed to be > awk '/^directory/{print $2}' /etc/openldap/slapd.conf For this point I want just to ask: when upstream migrated from flat config files to OLC? My experience points, that not all features works right with flat config. The server may use not only traditional userbase. So it looks better to place (and get) user/group from /etc/conf.d/slapd config. > Second, I disagree with the premise behind these checks. An init script > shouldn't necessarily check for such basic admin screwups. The errors are > pretty simple to figure out, particularly if you have any experience with > managing openldap. I find message: # rc-service slapd start * Starting ldap-server ... * start-stop-daemon: failed to start `/usr/lib64/openldap/slapd' [ !! ] * ERROR: slapd failed to start A little bit not clear. > Also, if you're using the mdb backend (the preferred > backend at this point), there is zero need for a DB_CONFIG, so complaining > that one doesn't exist seems less than forward looking. And what about other points? AFAIR Gentoo supports not all existing back-ends. > # su -s /bin/bash ldap > ldap@themis /var/lib/openldap-data $ > > It's a best practice to *always* manipulate your ldap databases as the ldap > user, which is trivial to do. Right note. (In reply to Paul B. Henson from comment #3) > Just to follow up on this concept of checking for every possible admin > mistake Not "every possible", but most common. Using ldaps to my experience is less common case, than using recommended config back-end. Also: do you remember, that upstream's (i.e. official OpenLDAP) provides just incomplete description (misses in overlay handling seems to be not only in docs). So, I suggest not to continue discuss in tracker make some improvements in docs: https://wiki.gentoo.org/wiki/Centralized_authentication_using_OpenLDAP To my mind this article should be divided into two ones: describing LDAP server setup and using it for authentication purposes. Server setup must be extended at least with description of logging setup (and specific of OpenLDAP logs) and up to date server configuration (OLC). Annotated list of OpenLDAP back-ends with accenting Gentoo-supported ones is the second basic. For SSL I'm really interested in benchmark comparison with basic ldap protocol and switching from password to client-cert based authentication for replication and external administrating. P.S. Reopening bug because of issue decribed in comment #2.
It's fixed already, retest. and include configdir ldif support
(In reply to Sergey S. Starikoff from comment #4) Many of the issues you mention here should be in a new bug, not this bug.
in function checkconfig in openldap-2.4.40-r3 ebuild The line DBDIRS=`eval awk '"/^(directory|olcDbDirectory:)/{print \$2}"' $CONF` does not work for me. > DBDIRS=`eval awk '"/^(directory|olcDbDirectory:)/{print \$2}"' $CONF` > echo $DBDIRS /etc/init.d/slapd start directory /var/lib/openldap-data * Directory directory in config does not exist! * There is a problem with your slapd.conf! * ERROR: slapd failed to start If using DBDIRS=$(eval awk '"/^(directory|olcDbDirectory:)/{print \$2}"' $CONF) /etc/init.d/slapd start /var/lib/openldap-data config file testing succeeded * Starting ldap-server Bash version: app-shells/bash-4.2_p53
> /etc/init.d/slapd start > > directory /var/lib/openldap-data > * Directory directory in config does not exist! > * There is a problem with your slapd.conf! > * ERROR: slapd failed to start > > If using DBDIRS=$(eval awk '"/^(directory|olcDbDirectory:)/{print \$2}"' > $CONF) > Bash version: app-shells/bash-4.2_p53 Runs for me: DBDIRS=$(awk '/^(directory|olcDbDirectory:)/{print $2}' $CONF) # app-shells/bash-4.3_p33-r2
