| Summary: | net-nds/openldap - /etc/init.d/slapd should check owner of /var/lib/openldap-data/* files et cetera | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sergey S. Starikoff <Ikonta> |
| Component: | Current packages | Assignee: | Gentoo LDAP project <ldap-bugs> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | henson |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Sergey S. Starikoff
2014-02-27 06:46:47 UTC
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 |
