ldap startup failure with FC3

[Phil Savoie]

Hi All

I am trying to get ldap to start and am having trouble.  I am finding error 
messages in the /var/log/messages file such as:

Jan  2 16:31:41 server1 ldap: slapd shutdown failed
Jan  2 16:31:41 server1 slaptest: sql_select option missing
Jan  2 16:31:41 server1 slaptest: auxpropfunc error no mechanism available
Jan  2 16:31:42 server1 ldap:  succeeded
Jan  2 16:31:42 server1 slapd[3494]: sql_select option missing
Jan  2 16:31:42 server1 slapd[3494]: auxpropfunc error no mechanism 
available
Jan  2 16:31:42 server1 ldap: slapd startup succeeded

Not sure what to make of it and am hoping someone could point me in the right 
direction, please.

Thank you,

Phil

[Craig White]

On Mon, 2006-01-02 at 19:48 -0500, Phil Savoie wrote:
> Hi All
>
> I am trying to get ldap to start and am having trouble.  I am finding error 
> messages in the /var/log/messages file such as:
>
> Jan  2 16:31:41 server1 ldap: slapd shutdown failed
> Jan  2 16:31:41 server1 slaptest: sql_select option missing
> Jan  2 16:31:41 server1 slaptest: auxpropfunc error no mechanism available
> Jan  2 16:31:42 server1 ldap:  succeeded
> Jan  2 16:31:42 server1 slapd[3494]: sql_select option missing
> Jan  2 16:31:42 server1 slapd[3494]: auxpropfunc error no mechanism 
> available
> Jan  2 16:31:42 server1 ldap: slapd startup succeeded
>
> Not sure what to make of it and am hoping someone could point me in the right 
> direction, please.

----
I wouldn't know if those errors are from you sasl configuration or if
you are trying to use back-sql but from the quoted stuff, ldap started.

You might want to post...

- what isn't working (i.e. what you are trying to do that failed)
- your slapd.conf
- what you are using as reference

Craig

[Phil Savoie]

On January 2, 2006 19:57, Craig White wrote:
> On Mon, 2006-01-02 at 19:48 -0500, Phil Savoie wrote:
> > Hi All
> >
> > I am trying to get ldap to start and am having trouble.  I am finding
> > error messages in the /var/log/messages file such as:
> >
> > Jan  2 16:31:41 server1 ldap: slapd shutdown failed
> > Jan  2 16:31:41 server1 slaptest: sql_select option missing
> > Jan  2 16:31:41 server1 slaptest: auxpropfunc error no mechanism
> > available Jan  2 16:31:42 server1 ldap:  succeeded
> > Jan  2 16:31:42 server1 slapd[3494]: sql_select option missing
> > Jan  2 16:31:42 server1 slapd[3494]: auxpropfunc error no mechanism
> > available
> > Jan  2 16:31:42 server1 ldap: slapd startup succeeded
> >
> > Not sure what to make of it and am hoping someone could point me in the
> > right direction, please.
>
> I wouldn't know if those errors are from you sasl configuration or if
> you are trying to use back-sql but from the quoted stuff, ldap started.
>
> You might want to post...
> what isn't working (i.e. what you are trying to do that failed)
> your slapd.conf
> what you are using as reference
>
> Craig

Hi Craig,

Thank you for responding.  Although the messages file *said* it started it 
didn't start at all.  When I do a "service ldap restart" it always fails on 
the shutdown:

[root@server1 ldap]# service ldap restart
Stopping slapd:                                            [FAILED]
Checking configuration files for slapd: config file testing succeeded
Starting slapd:                                            [  OK  ]
[root@server1 ldap]#

My slapd.conf follows:

[root@server1 ldap]# cd /etc/openldap/
[root@server1 openldap]# cat 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.
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

TLSCertificateFile /etc/openldap/server.crt
TLSCertificateKeyFile /etc/openldap/server.key
TLSCipherSuite HIGH
security ssf=128

# 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!
access to dn.base=""
        by * read

access to dn.base="cn=Subschema"
        by * read

access to attr=userPassword,userPKCS12
        by self write
        by * auth

access to attr=shadowLastChange
        by self write
        by * read

access to dn.regex="uid=(.*),ou=.*,dc=com" 
attr=sn,givenName,homePhone,homePostalAddress,mobile
        by self write
        by users read

access to dn.regex="uid=.*,dc=com" attr=mail
        by users read
        by * none

access to *
        by * read

#######################################################################
# ldbm and/or bdb database definitions
#######################################################################

database        bdb
suffix          "dc=example,dc=com"
rootdn          "cn=Manager,dc=example,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

rootpw          secret-ldap-pass

# 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/[e-mail]
[root@server1 openldap]#

Hope this sheds more light on it for you.

Phil

[Craig White]

On Mon, 2006-01-02 at 20:16 -0500, Phil Savoie wrote:
> On January 2, 2006 19:57, Craig White wrote:
> > On Mon, 2006-01-02 at 19:48 -0500, Phil Savoie wrote:
> > > Hi All
> > >
> > > I am trying to get ldap to start and am having trouble.  I am finding
> > > error messages in the /var/log/messages file such as:
> > >
> > > Jan  2 16:31:41 server1 ldap: slapd shutdown failed
> > > Jan  2 16:31:41 server1 slaptest: sql_select option missing
> > > Jan  2 16:31:41 server1 slaptest: auxpropfunc error no mechanism
> > > available Jan  2 16:31:42 server1 ldap:  succeeded
> > > Jan  2 16:31:42 server1 slapd[3494]: sql_select option missing
> > > Jan  2 16:31:42 server1 slapd[3494]: auxpropfunc error no mechanism
> > > available
> > > Jan  2 16:31:42 server1 ldap: slapd startup succeeded
> > >
> > > Not sure what to make of it and am hoping someone could point me in the
> > > right direction, please.
> >
> > I wouldn't know if those errors are from you sasl configuration or if
> > you are trying to use back-sql but from the quoted stuff, ldap started.
> >
> > You might want to post...
> > what isn't working (i.e. what you are trying to do that failed)
> > your slapd.conf
> > what you are using as reference
> >
> > Craig
>
> Hi Craig,
>
> Thank you for responding.  Although the messages file *said* it started it 
> didn't start at all.  When I do a "service ldap restart" it always fails on 
> the shutdown:
>
> [root@server1 ldap]# service ldap restart
> Stopping slapd:                                            [FAILED]
> Checking configuration files for slapd: config file testing succeeded
> Starting slapd:                                            [  OK  ]
> [root@server1 ldap]#
>
> My slapd.conf follows:
>
> [root@server1 ldap]# cd /etc/openldap/
> [root@server1 openldap]# cat 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.
> 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
>
> TLSCertificateFile /etc/openldap/server.crt
> TLSCertificateKeyFile /etc/openldap/server.key
> TLSCipherSuite HIGH
> security ssf=128
>
> # 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!
> access to dn.base=""
>         by * read
>
> access to dn.base="cn=Subschema"
>         by * read
>
> access to attr=userPassword,userPKCS12
>         by self write
>         by * auth
>
> access to attr=shadowLastChange
>         by self write
>         by * read
>
> access to dn.regex="uid=(.*),ou=.*,dc=com" 
> attr=sn,givenName,homePhone,homePostalAddress,mobile
>         by self write
>         by users read
>
> access to dn.regex="uid=.*,dc=com" attr=mail
>         by users read
>         by * none
>
> access to *
>         by * read
>
> #######################################################################
> # ldbm and/or bdb database definitions
> #######################################################################
>
> database        bdb
> suffix          "dc=example,dc=com"
> rootdn          "cn=Manager,dc=example,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
>
> rootpw          secret-ldap-pass
>
> # 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

----
try chown -R ldap:ldap /var/lib/ldap

add "loglevel 256" to slapd.conf

echo "local4.*                  /var/log/slapd.log" > /etc/syslog.conf

service syslog restart

This will direct all ldap logging to /var/log/slapd.log so you can get a
better idea

My guess is the first line will solve it...most ldap newbies run slapadd
as root and thus the data files are owned root:root and ldap will not
run.

Craig

[Alexander Dalloz]

Am Di, den 03.01.2006 schrieb Craig White um 2:24:
> try chown -R ldap:ldap /var/lib/ldap
>
> add "loglevel 256" to slapd.conf

"256" is the default log level value. Under normal circumstances this is
enough verbosity.

http://www.zytrax.com/books/ldap/ch6/#loglevel
> echo "local4.*                  /var/log/slapd.log" > /etc/syslog.conf

Attention! Hope it is not too late already: do not run this command
unchecked! It will override your existing syslog configuration with just
a single line. Use ">>" instead of the ">" to just append the new log
instruction.
> service syslog restart
> Craig

Alexander

[Phil Savoie]

On January 2, 2006 21:16, Alexander Dalloz wrote:
> Am Di, den 03.01.2006 schrieb Craig White um 2:24:
> > try chown -R ldap:ldap /var/lib/ldap
> >
> > add "loglevel 256" to slapd.conf
>
> "256" is the default log level value. Under normal circumstances this is
> enough verbosity.
>
> http://www.zytrax.com/books/ldap/ch6/#loglevel
> > echo "local4.*                  /var/log/slapd.log" > /etc/syslog.conf
>
> Attention! Hope it is not too late already: do not run this command
> unchecked! It will override your existing syslog configuration with just
> a single line. Use ">>" instead of the ">" to just append the new log
> instruction.
> > service syslog restart
> >
> > Craig
>
> Alexander

Thanks Alexander,

I caught it.  Will try this now Craig. Thank you.

Phil

[Phil Savoie]

On January 2, 2006 20:24, Craig White wrote:
> try chown -R ldap:ldap /var/lib/ldap
>
> add "loglevel 256" to slapd.conf
>
> echo "local4.*                  /var/log/slapd.log" > /etc/syslog.conf
>
> service syslog restart
>
> This will direct all ldap logging to /var/log/slapd.log so you can get a
> better idea
>
> My guess is the first line will solve it...most ldap newbies run slapadd
> as root and thus the data files are owned root:root and ldap will not
> run.
>
> Craig

Hi Again,

Did what you asked and this is the resulted entries in the /var/log/slapd:

[root@server1 openldap]# tail /var/log/slapd.log
Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): Ignoring log 
file: /var/lib/ldap/log.0000000001: magic number 0, not 40988
Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): Invalid log file: 
log.0000000001: Invalid argument
Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): PANIC: Invalid 
argument
Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): PANIC: 
DB_RUNRECOVERY: Fatal error, run database recovery
Jan  2 21:30:48 server1 slapd[4404]: bdb_db_open: dbenv_open failed: 
DB_RUNRECOVERY: Fatal error, run database recovery (-30978)
Jan  2 21:30:48 server1 slapd[4404]: backend_startup: bi_db_open(0) failed! 
(-30978)
Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): txn_checkpoint 
interface requires an environment configured for the transaction subsystem
Jan  2 21:30:48 server1 slapd[4404]: bdb_db_destroy: txn_checkpoint failed: 
Invalid argument (22)
Jan  2 21:30:48 server1 slapd[4404]: slapd stopped.
Jan  2 21:30:48 server1 slapd[4404]: connections_destroy: nothing to destroy.
[root@server1 openldap]#

Don't understand this magic number business...  Should I rm the log file and  
touch another?  What db file is it referencing?  This is the listing 
of /var/lib/ldap:

[root@server1 ldap]# ls -lR /var/lib/ldap
/var/lib/ldap:
total 20
-rw-------  1 ldap ldap 460613 Jan  2 16:13 log.0000000001
drwxr-xr-x  2 ldap ldap   4096 Jan  2 16:41 replica

/var/lib/ldap/replica:
total 8
-rw-r--r--  1 ldap ldap 0 Jan  2 16:41 slurpd.status
-rw-r--r--  1 ldap ldap 0 Jan  2 16:43 slurpd.status.lock
[root@server1 ldap]#

I don't see a db here but I guess there should be one?  As you can tell, I am 
quit new to this.

Phil

[Craig White]

On Mon, 2006-01-02 at 21:42 -0500, Phil Savoie wrote:
> On January 2, 2006 20:24, Craig White wrote:
> > try chown -R ldap:ldap /var/lib/ldap
> >
> > add "loglevel 256" to slapd.conf
> >
> > echo "local4.*                  /var/log/slapd.log" > /etc/syslog.conf
> >
> > service syslog restart
> >
> > This will direct all ldap logging to /var/log/slapd.log so you can get a
> > better idea
> >
> > My guess is the first line will solve it...most ldap newbies run slapadd
> > as root and thus the data files are owned root:root and ldap will not
> > run.
> >
> > Craig
>
> Hi Again,
>
> Did what you asked and this is the resulted entries in the /var/log/slapd:
>
> [root@server1 openldap]# tail /var/log/slapd.log
> Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): Ignoring log 
> file: /var/lib/ldap/log.0000000001: magic number 0, not 40988
> Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): Invalid log file: 
> log.0000000001: Invalid argument
> Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): PANIC: Invalid 
> argument
> Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): PANIC: 
> DB_RUNRECOVERY: Fatal error, run database recovery
> Jan  2 21:30:48 server1 slapd[4404]: bdb_db_open: dbenv_open failed: 
> DB_RUNRECOVERY: Fatal error, run database recovery (-30978)
> Jan  2 21:30:48 server1 slapd[4404]: backend_startup: bi_db_open(0) failed! 
> (-30978)
> Jan  2 21:30:48 server1 slapd[4404]: bdb(dc=example,dc=com): txn_checkpoint 
> interface requires an environment configured for the transaction subsystem
> Jan  2 21:30:48 server1 slapd[4404]: bdb_db_destroy: txn_checkpoint failed: 
> Invalid argument (22)
> Jan  2 21:30:48 server1 slapd[4404]: slapd stopped.
> Jan  2 21:30:48 server1 slapd[4404]: connections_destroy: nothing to destroy.
> [root@server1 openldap]#
>
> Don't understand this magic number business...  Should I rm the log file and  
> touch another?  What db file is it referencing?  This is the listing 
> of /var/lib/ldap:
>
> [root@server1 ldap]# ls -lR /var/lib/ldap
> /var/lib/ldap:
> total 20
> -rw-------  1 ldap ldap 460613 Jan  2 16:13 log.0000000001
> drwxr-xr-x  2 ldap ldap   4096 Jan  2 16:41 replica
>
> /var/lib/ldap/replica:
> total 8
> -rw-r--r--  1 ldap ldap 0 Jan  2 16:41 slurpd.status
> -rw-r--r--  1 ldap ldap 0 Jan  2 16:43 slurpd.status.lock
> [root@server1 ldap]#
>
> I don't see a db here but I guess there should be one?  As you can tell, I am 
> quit new to this.

----
the db will be there as soon as you slapadd/ldapadd some data

I would say that the best thing to do would be to stop ldap and remove
the log file and minimally populate it.

Are you using something as a reference?

if not, I would suggest using...

http://www.openldap.org/doc/admin22/

As you would need to populate it to have any db files

and I'm sorry about the recommendation to echo
echo "local4.*             /var/log/slapd.log" > /etc/syslog.conf # NO
which Alexander caught and should have been...
echo "local4.*             /var/log/slapd.log" >> /etc/syslog.conf #YES

I didn't however see any reference to checkpoints or logs in the
slapd.conf that you posted nor any references to DB_CONFIG files

Craig

[Phil Savoie]

On Monday 02 January 2006 22:27, Craig White wrote:
> the db will be there as soon as you slapadd/ldapadd some data
>
> I would say that the best thing to do would be to stop ldap and remove
> the log file and minimally populate it.
>
> Are you using something as a reference?
>
> if not, I would suggest using...
>
> http://www.openldap.org/doc/admin22/
>
> As you would need to populate it to have any db files
>
> and I'm sorry about the recommendation to echo
> echo "local4.*             /var/log/slapd.log" > /etc/syslog.conf # NO
> which Alexander caught and should have been...
> echo "local4.*             /var/log/slapd.log" >> /etc/syslog.conf #YES
>
> I didn't however see any reference to checkpoints or logs in the
> slapd.conf that you posted nor any references to DB_CONFIG files
>
> Craig

Hi Craig,

I have it solved.  What I had to do was rm the files in /var/lib/ldap leaving 
the replica dir intact and slapadd the files manually.  The setup should have 
been done through a script in a customized rpm file but had failed.

Thank you for all of your help as it was sincerely appreciated.

Phil

[Alexander Dalloz]

Am Di, den 03.01.2006 schrieb Phil Savoie um 1:48:
> I am trying to get ldap to start and am having trouble.  I am finding error 
> messages in the /var/log/messages file such as:
>
> Jan  2 16:31:41 server1 ldap: slapd shutdown failed
> Jan  2 16:31:41 server1 slaptest: sql_select option missing
> Jan  2 16:31:41 server1 slaptest: auxpropfunc error no mechanism available
> Jan  2 16:31:42 server1 ldap:  succeeded
> Jan  2 16:31:42 server1 slapd[3494]: sql_select option missing
> Jan  2 16:31:42 server1 slapd[3494]: auxpropfunc error no mechanism 
> available
> Jan  2 16:31:42 server1 ldap: slapd startup succeeded
> Phil

slaptest -v -d 256

might be more verbose (or increase the debug verbosity by giving a
different debug level number like i.e. 265).

Alexander