Bug 181336 - slapd won't start on new install even after hacking init script
slapd won't start on new install even after hacking init script
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: openldap (Show other bugs)
4
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-02-13 10:56 EST by Bill Uhl
Modified: 2014-08-31 19:28 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-14 08:22:41 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill Uhl 2006-02-13 10:56:48 EST
Description of problem:
I've been trying to get ldap working using this update with no success. My
process takes the latest updates and merges them into the original FC4
distribution tree before doing a new install using kickstart. Currently, I am
installing with the latest rpm's from the updates/4/i386/ tree as of Feb. 12,
2006 overlaid on top of a fc4 distribution image from the dvd .iso file. As
such, there is no existing ldap database when I go to configure and start ldap.
Previous experience indicated that slapd would create the db files automatically
behind the scenes.

I have problems with the init script complaining that the slapd.conf file is not
configured correctly. In the init script, slaptest -u ends up giving a failed
message. Meanwhile, when run manually, slaptest says the file is fine. One item
to note is that this version of slaptest spits out a message on STDERR even when
the file is ok. This seems to interfere with the action() function in
/etc/rc.d/init/functions. I see there is discussion re: the init scripts on
bugzilla.

When I hack the init script to get past the slaptest part, slapd fails to start.
I don't really get any useful information on the screen. I do get the following
error messages in /var/log/messages...

Feb 13 00:41:02 buildme1 slapd[15399]: sql_select option missing
Feb 13 00:41:02 buildme1 slapd[15399]: auxpropfunc error no mechanism available

I am not sure what these mean, but maybe there is an unresolved dependency?

For the moment, I am rolling back to the openldap version from the original FC4
release. I wanted to update you so that hopefully, a new update may be forthcoming.

Version-Release number of selected component (if applicable):
openldap-2.2.29-1.FC4

How reproducible:
Every time

Steps to Reproduce:
1. create updated fc4 distrib. using latest rpms from updates/4/i386 tree
2. install updated fc4
3. configure /etc/openldap/slapd.conf
4. service ldap start

  
Actual results:
this is from the hacked init script. the call to configtest has been commented
out and -x was added to the #!/bin/bash at the top of the script. following is
the script output.

+ . /etc/init.d/functions
++ TEXTDOMAIN=initscripts
++ umask 022
++ PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
++ export PATH
++ '[' -z '' ']'
++ COLUMNS=80
++ '[' -z '' ']'
+++ /sbin/consoletype
++ CONSOLETYPE=pty
++ '[' -f /etc/sysconfig/i18n -a -z '' ']'
++ . /etc/sysconfig/i18n
+++ LANG=en_US.UTF-8
+++ SYSFONT=latarcyrheb-sun16
++ '[' pty '!=' pty ']'
++ '[' -n '' ']'
++ export LANG
++ '[' -z '' ']'
++ '[' -f /etc/sysconfig/init ']'
++ . /etc/sysconfig/init
+++ BOOTUP=color
+++ GRAPHICAL=yes
+++ RES_COL=60
+++ MOVE_TO_COL='echo -en \033[60G'
+++ SETCOLOR_SUCCESS='echo -en \033[0;32m'
+++ SETCOLOR_FAILURE='echo -en \033[0;31m'
+++ SETCOLOR_WARNING='echo -en \033[0;33m'
+++ SETCOLOR_NORMAL='echo -en \033[0;39m'
+++ LOGLEVEL=3
+++ PROMPT=yes
++ '[' pty = serial ']'
++ '[' color '!=' verbose ']'
++ INITLOG_ARGS=-q
+ '[' -r /etc/sysconfig/network ']'
+ . /etc/sysconfig/network
++ NETWORKING=yes
++ HOSTNAME=buildme1.greenlightnet.gln
+ '[' yes = no ']'
+ '[' -r /etc/sysconfig/ldap ']'
+ slapd=/usr/sbin/slapd
+ slurpd=/usr/sbin/slurpd
+ slaptest=/usr/sbin/slaptest
+ '[' -x /usr/sbin/slapd ']'
+ '[' -x /usr/sbin/slurpd ']'
+ RETVAL=0
+ case "$1" in
+ start
+ user=ldap
++ basename /usr/sbin/slapd
+ prog=slapd
++ mktemp /tmp/start-slapd.XXXXXX
+ wrapper=/tmp/start-slapd.i17790
+ harg=ldap:///
+ grep -q '^TLS' /etc/openldap/slapd.conf
+ test x = xyes
+ test x = xyes
+ test -z /tmp/start-slapd.i17790
+ cat
+ chmod u+x /tmp/start-slapd.i17790
+ trap 'rm -f /tmp/start-slapd.i17790' EXIT
+ echo -n 'Starting slapd: '
Starting slapd: + daemon --check=slapd /tmp/start-slapd.i17790
+ local gotbase= force=
+ local base= user= nice= bg= pid=
+ nicelevel=0
+ '[' --check=slapd '!=' -check=slapd ']'
+ case $1 in
+ base=slapd
+ gotbase=yes
+ shift
+ '[' /tmp/start-slapd.i17790 '!=' /tmp/start-slapd.i17790 ']'
+ '[' -z yes ']'
+ '[' -f /var/run/slapd.pid ']'
+ '[' -n '' -a -z '' ']'
+ ulimit -S -c 0
+ '[' -n '' ']'
+ '[' color = verbose -a -z '' ']'
+ '[' -z '' ']'
+ /tmp/start-slapd.i17790
+ '[' 1 -eq 0 ']'
+ failure 'slapd startup'
+ rc=1
+ '[' color '!=' verbose -a -z '' ']'
+ echo_failure
+ '[' color = color ']'
+ echo -en '\033[60G'
                                                           + echo -n '['
[+ '[' color = color ']'
+ echo -en '\033[0;31m'
+ echo -n FAILED
FAILED+ '[' color = color ']'
+ echo -en '\033[0;39m'
+ echo -n ']'
]+ echo -ne '\r'
+ return 1
+ '[' -x /usr/bin/rhgb-client ']'
+ /usr/bin/rhgb-client --details=yes
+ '[' -w /var/gdm/.gdmfifo ']'
+ return 1
+ RETVAL=1
+ echo

+ '[' 1 -eq 0 ']'
+ '[' 1 -eq 0 ']'
+ return 1
+ exit 1
+ rm -f /tmp/start-slapd.i17790

after this failure, tail /var/log/messages and see this...
Feb 13 09:13:00 buildme1 slapd[17794]: sql_select option missing
Feb 13 09:13:00 buildme1 slapd[17794]: auxpropfunc error no mechanism available


Expected results:
ldap should have started

Additional info:
Contents of slapd.conf
======================

#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema

# Allow LDAPv2 client connections.  This is NOT the default.
# GLN commented out for now
#allow bind_v2

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral       ldap://root.openldap.org

pidfile         /var/run/slapd.pid
argsfile        /var/run/slapd.args

# Load dynamic backend modules:
# modulepath    /usr/sbin/openldap
# moduleload    back_bdb.la
# moduleload    back_ldap.la
# moduleload    back_ldbm.la
# moduleload    back_passwd.la
# moduleload    back_shell.la

# The next three lines allow use of TLS for encrypting connections using a
# dummy test certificate which you can generate by changing to
# /usr/share/ssl/certs, running "make slapd.pem", and fixing permissions on
# slapd.pem so that the ldap user or group can read it.  Your client software
# may balk at self-signed certificates, however.
# TLSCACertificateFile /usr/share/ssl/certs/ca-bundle.crt
# TLSCertificateFile /usr/share/ssl/certs/slapd.pem
# TLSCertificateKeyFile /usr/share/ssl/certs/slapd.pem

# Sample security restrictions
#       Require integrity protection (prevent hijacking)
#       Require 112-bit (3DES or better) encryption for updates
#       Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#       Root DSE: allow anyone to read it
#       Subschema (sub)entry DSE: allow anyone to read it
#       Other DSEs:
#               Allow self write access
#               Allow authenticated users read access
#               Allow anonymous users to authenticate
#       Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
# access to *
#       by self write
#       by users read
#       by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################
#
#database       bdb
#suffix         "dc=my-domain,dc=com"
#rootdn         "cn=Manager,dc=my-domain,dc=com"
## Cleartext passwords, especially for the rootdn, should
## be avoided.  See slappasswd(8) and slapd.conf(5) for details.
## Use of strong authentication encouraged.
## rootpw               secret
## rootpw               {crypt}ijFYNcSNctBYg
#
## The database directory MUST exist prior to running slapd AND
## should only be accessible by the slapd and slap tools.
## Mode 700 recommended.
#directory      /var/lib/ldap
#
## Indices to maintain for this database
#index objectClass                       eq,pres
#index ou,cn,mail,surname,givenname      eq,pres,sub
#index uidNumber,gidNumber,loginShell    eq,pres
#index uid,memberUid                     eq,pres,sub
#index nisMapName,nisMapEntry            eq,pres,sub
#
## Replicas of this database
##replogfile /var/lib/ldap/openldap-master-replog
##replica host=ldap-1.example.com:389 starttls=critical
##     bindmethod=sasl saslmech=GSSAPI
##     authcId=host/ldap-master.example.com@EXAMPLE.COM

##################################################################
# GLN cn=root backend db definition
##################################################################

# tried both of these backends. same error regardless
#database       bdb
database        ldbm
suffix          "cn=root"
rootdn          "cn=N0mksdkkk,cn=root"

rootpw          {SSHA}2NdbtF... (truncated for posting)

directory       /srv/gln/ldap/root

index   objectClass,uid,uidNumber,gidNumber     eq
index   cn,mail,surname,givenname               eq,subinitial
Comment 1 Jay Fenlason 2006-02-13 13:56:11 EST
I see that you're using a non-standard directory for the slapd database files.  
Do you have SELinux enabled?  Ifso, have you made sure /srv/gln/ldap/root has 
the correct security context? 
Comment 2 Bill Uhl 2006-02-13 15:39:13 EST
SELinux is anabled. I am new to using it. Following one of the answers in the
selinux faq, I was able to change the policy to permissive.

(status after reboot)
[root@buildme1 ~]# sestatus -v
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 20
Policy from config file:        targeted

I ran
service ldap start
and still get the same thing.

[root@buildme1 ~]# service ldap start
+ . /etc/init.d/functions
++ TEXTDOMAIN=initscripts
++ umask 022
++ PATH=/sbin:/usr/sbin:/bin:/usr/bin:/usr/X11R6/bin
++ export PATH
++ '[' -z '' ']'
++ COLUMNS=80
++ '[' -z '' ']'
+++ /sbin/consoletype
++ CONSOLETYPE=pty
++ '[' -f /etc/sysconfig/i18n -a -z '' ']'
++ . /etc/sysconfig/i18n
+++ LANG=en_US.UTF-8
+++ SYSFONT=latarcyrheb-sun16
++ '[' pty '!=' pty ']'
++ '[' -n '' ']'
++ export LANG
++ '[' -z '' ']'
++ '[' -f /etc/sysconfig/init ']'
++ . /etc/sysconfig/init
+++ BOOTUP=color
+++ GRAPHICAL=yes
+++ RES_COL=60
+++ MOVE_TO_COL='echo -en \033[60G'
+++ SETCOLOR_SUCCESS='echo -en \033[0;32m'
+++ SETCOLOR_FAILURE='echo -en \033[0;31m'
+++ SETCOLOR_WARNING='echo -en \033[0;33m'
+++ SETCOLOR_NORMAL='echo -en \033[0;39m'
+++ LOGLEVEL=3
+++ PROMPT=yes
++ '[' pty = serial ']'
++ '[' color '!=' verbose ']'
++ INITLOG_ARGS=-q
+ '[' -r /etc/sysconfig/network ']'
+ . /etc/sysconfig/network
++ NETWORKING=yes
++ HOSTNAME=buildme1.greenlightnet.gln
+ '[' yes = no ']'
+ '[' -r /etc/sysconfig/ldap ']'
+ slapd=/usr/sbin/slapd
+ slurpd=/usr/sbin/slurpd
+ slaptest=/usr/sbin/slaptest
+ '[' -x /usr/sbin/slapd ']'
+ '[' -x /usr/sbin/slurpd ']'
+ RETVAL=0
+ case "$1" in
+ start
+ user=ldap
++ basename /usr/sbin/slapd
+ prog=slapd
++ mktemp /tmp/start-slapd.XXXXXX
+ wrapper=/tmp/start-slapd.Ps3085
+ harg=ldap:///
+ grep -q '^TLS' /etc/openldap/slapd.conf
+ test x = xyes
+ test x = xyes
+ test -z /tmp/start-slapd.Ps3085
+ cat
+ chmod u+x /tmp/start-slapd.Ps3085
+ trap 'rm -f /tmp/start-slapd.Ps3085' EXIT
+ echo -n 'Starting slapd: '
Starting slapd: + daemon --check=slapd /tmp/start-slapd.Ps3085
+ local gotbase= force=
+ local base= user= nice= bg= pid=
+ nicelevel=0
+ '[' --check=slapd '!=' -check=slapd ']'
+ case $1 in
+ base=slapd
+ gotbase=yes
+ shift
+ '[' /tmp/start-slapd.Ps3085 '!=' /tmp/start-slapd.Ps3085 ']'
+ '[' -z yes ']'
+ '[' -f /var/run/slapd.pid ']'
+ '[' -n '' -a -z '' ']'
+ ulimit -S -c 0
+ '[' -n '' ']'
+ '[' color = verbose -a -z '' ']'
+ '[' -z '' ']'
+ /tmp/start-slapd.Ps3085
+ '[' 1 -eq 0 ']'
+ failure 'slapd startup'
+ rc=1
+ '[' color '!=' verbose -a -z '' ']'
+ echo_failure
+ '[' color = color ']'
+ echo -en '\033[60G'
                                                           + echo -n '['
[+ '[' color = color ']'
+ echo -en '\033[0;31m'
+ echo -n FAILED
FAILED+ '[' color = color ']'
+ echo -en '\033[0;39m'
+ echo -n ']'
]+ echo -ne '\r'
+ return 1
+ '[' -x /usr/bin/rhgb-client ']'
+ /usr/bin/rhgb-client --details=yes
+ '[' -w /var/gdm/.gdmfifo ']'
+ return 1
+ RETVAL=1
+ echo

+ '[' 1 -eq 0 ']'
+ '[' 1 -eq 0 ']'
+ return 1
+ exit 1
+ rm -f /tmp/start-slapd.Ps3085


Is this permissive enough or do I need to make other changes to open it up further?
Comment 3 Jay Fenlason 2006-02-13 16:06:39 EST
I'm unable to reproduce the problem on my fc4 box using your slapd.conf, so 
I'm thinking it must be something unique to your setup.  Have you added a line 
like 
local4.* /var/log/ldap.log 
to your /etc/syslog.conf 
created /var/log/ldap.log 
and reloaded syslog?  This will make syslog keep any messages slapd logs when 
it starts up.  You might also want to try starting slapd by hand with 
debugging to see what it says. 
try 
/usr/sbin/slapd -d 1 -u ldap 
and see what it says. 
 
Also, for program output and configuration files, it's much better to attach 
them to the bug using the "Create a new attachment" dialog below instead of 
pasting them inline. 
Comment 4 Bill Uhl 2006-02-14 08:21:34 EST
Ok. Rebuilt with old ldap. Changed selinux to permissive. rechecked file and
directory permissions. slapd started w/o a problem.

Rebuilt system with current ldap. Kept selinux at permissive. rechecked file and
directory permissions. slapd started and runs.

Still get the following messages in /var/log/messages...
Feb 14 08:08:47 buildme1 slaptest: sql_select option missing
Feb 14 08:08:47 buildme1 slaptest: auxpropfunc error no mechanism available
Feb 14 08:08:47 buildme1 slapd[2428]: sql_select option missing
Feb 14 08:08:47 buildme1 slapd[2428]: auxpropfunc error no mechanism available

Assuming these are not to be worried about, ldap seems to be up and running. Did
not have to make any changes to startup scripts this time.

While I would like to know if the messages above represent a problem, the server
seems to be working at this point so I'm moving on. Thanks for your help and
suggestions.

Note You need to log in before you can comment on or make changes to this bug.