Re: ldap startup failure with FC3

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Current Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]     [Fedora Docs]

  Powered by Linux