enhanced slapd init script to recover bdb backends before starting slapd: added following lines (see further down for the complete/enhanced init-script): ... for dir in ${BDB_RECOVER}; do if [[ -d ${dir} ]]; then eindent einfo "Running db_recover for ${dir}" /usr/bin/db4.2_recover -h ${dir} test $? || ewarn "db_recover failed for ${dir}" eoutdent else ewarn "bdb backend directory ${dir} does not exist" fi done eindent einfo "Starting slapd process" ... New slapd init script looks like: start() { ebegin "Starting OpenLDAP server" for dir in ${BDB_RECOVER}; do if [[ -d ${dir} ]]; then eindent einfo "Running db_recover for ${dir}" /usr/bin/db4.2_recover -h ${dir} test $? || ewarn "db_recover failed for ${dir}" eoutdent else ewarn "bdb backend directory ${dir} does not exist" fi done eindent einfo "Starting slapd process" eval start-stop-daemon --start --quiet --pidfile /var/run/openldap/slapd.pid --exec /usr/lib/openldap/slapd -- -u ldap -g ldap "${OPTS}" eend $? } stop() { ebegin "Stopping OpenLDAP server" start-stop-daemon --stop --signal 2 --quiet --pidfile /var/run/openldap/slapd.pid eend $? } Reproducible: Always Steps to Reproduce: 1. 2. 3. Actual Results: Works fine here :-) Expected Results: Works fine here :-) The variable "BDB_RECOVER" was introduced into /etc/conf.d/slapd: # Optional blank-seperated list of directories where bdb backends are stored. # For each directory berkeley's db_recover is called before starting slapd. # db_recover asures consistency in case of unclean slapd shutdowns! # This option is only usable in case of openldap bdb backends! BDB_RECOVER="/var/lib/openldap-data/sf.home /var/lib/openldap-data/cms.foobar /var/lib/openldap-data/ph.d"
*** Bug 109479 has been marked as a duplicate of this bug. ***
Created attachment 71072 [details] enhancement of the enhancement: call db_recover as user "ldap" (using su - ldap -c ... ) At system startup init scripts are runned by "root" so recovered backend database files belong to root :-( ==> to make sure user ldap owns recovered databaes files, i updated the enhanced init script to use "su": su - ldap -c "db_recover...."
What happens if you have more than one backend? Wouldn't something like the following be more appropriate? DIR=`grep ^directory /etc/openldap/slapd.conf | sed -e "s/^directory\s*//g"` for ${DIR} ... do your stuff This would make the script backend independant :-)
(In reply to comment #3) > What happens if you have more than one backend? Wouldn't something like the > following be more appropriate? Thats the reason I inserted all bdb-backend-specific directories within /etc/conf.d/slapd (please see above, there are three directories listed) But you are right they are statically included (not an ideal solution!). A dynamic resolution of the bdb-backend directories is very complex in case you don't want to limit or force the admin to: - not use include-statements within slapd.conf (slapd.conf manpage allows it!) - to use *.conf named sub-configuration files (eg. for including many backends) please see below for more details: > > DIR=`grep ^directory /etc/openldap/slapd.conf | sed -e "s/^directory\s*//g"` > for ${DIR} ... do your stuff > > This would make the script backend independant :-) > Your suggestion makes it "far to" backend independant (=> high potentially buggy!) :-( I have not tried it, because I think it will fail in some commonly used slapd.conf-scenarios: You assume all backends are of type bdb. But a backend can be also of type "ldbm" which also uses a "directory /path_to_directory"... statement. I think (have not tested it because I don't use ldbm at all) in case of ldbm the db_recover will probably fail! Another "problem" is this one: I use a very extensive slapd.conf (many different backend definitions). The slapd.conf has some hundred lines of configuration statements. So I "splitted" slapd.conf by using "include /path_to/sub-backend-X.conf" to make it readable more easily. Your above (grep- & sed-) statement will not work with this (widely used and manpage propagated) setup. Conclusion: Of course my db_recover-init-script enhancement can be made more flexible (automatic / generic) but the script needs a lot of more logic to be fool prove without limiting the admin: <begin pseudo-code V.0.0.1alpha> 1.) read slapd.conf grep for "backend" statement 2.) compare backend statement to "bdb" and set a flag for bdb backend 3.) grep directory while the above flag is set ... ==> my first thought, needs to be refined a bit more! <end pseudo-code V.0.0.1alpha> But even refined this way, this methode will not solve the problem of a splitted "slapd.conf" (see above). In case of a splitted slapd.conf (by include statements) there are two possibel work arounds: 1.) read any .conf (*.conf) instead of only "slapd.conf": - problem: the admin has to name his config files "*.conf" - problem: the conf-files can be in any directory on the host (eg. via NFS)! 2.) read the slapd.conf, grep all "include" statement, additionally read the included files, grep the backend definition, set the flag, grep for directory and so on... Regarding the above pitfalls my first suggestion was in my opinion a good tradeoff between flexibility, data-availability and complexity - feel free to adapt it, extend it or even write it from scratch. ;-) Please let me know whether I should do some tests for you... Cheers Daniel
Indeed, most setups are far too complex to do this the way you do here. But why not "stealing" some config parsing code from upstream and build a small tool to do this? Get it working and tell me to include it then, I'll do for sure if it works okay (Reopen this bug then) :) Marking LATER for now
