>From: fedora-list-bounces@xxxxxxxxxx >[mailto:fedora-list-bounces@xxxxxxxxxx]On Behalf Of Craig White >Sent: Saturday, November 19, 2005 6:12 PM >To: For users of Fedora Core releases >Subject: RE: Problem with /etc/init.d/ldap? [temp script provided] > > >On Sat, 2005-11-19 at 16:48 -0800, Daniel B. Thurman wrote: >> >>From: fedora-list-bounces@xxxxxxxxxx >> >>[mailto:fedora-list-bounces@xxxxxxxxxx]On Behalf Of Tony Nelson >> >>Sent: Friday, November 18, 2005 2:34 PM >> >>To: fedora-list@xxxxxxxxxx >> >>Subject: RE: Problem with /etc/init.d/ldap? >> >> >> >> >> >>At 1:24 PM -0800 11/18/05, Daniel B. Thurman wrote: >> >>>>>"Daniel B. Thurman" <dant@xxxxxxxxx> wrote: >> >>> >> >>>>> >> >>>>>Did you say "export KRB5_KTNAME=FILE:/etc/openldap/ldap.keytab"? >> >>>>> ^^^^^ >> >>>> >> >>>>I was told to add the following environment variable >> >>>>to the /etc/sysconfig/ldap file: >> >>>> >> >>>>KRB5_KTNAME=/etc/openldap/ldap.keytab >> >>>> >> >>>>The file: /etc/openldap/ldap.keytab >> >>>>is chmod 640 and chown root:ldap >> >>>> >> >>> >> >>>I read your information carefully and tried >> >>>the following in the /etc/sysconfig/ldap: >> >>> >> >>>1) KRB5_KTNAME=/etc/openldap/ldap.keytab >> >>>2) KRB5_KTNAME="/etc/openldap/ldap.keytab" >> >>>3) export KRB5_KTNAME=/etc/openldap/ldap.keytab >> >>>4) export KRB5_KTNAME="/etc/openldap/ldap.keytab" >> >>>5) export KRB5_KTNAME=FILE:/etc/openldap/ldap.keytab >> >>>6 export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" >> >>> >> >>>None of these worked. >> >> >> >>Not too carefully. Note your use of " in 6, and compare with >> >>what he wrote. >> >>>____________________________________________________________________ >> >>TonyN.:' ><mailto:tonynelson@xxxxxxxxxxxxxxxxx> >> >> ' ><http://www.georgeanelson.com/> >> >> >> > >> >Tony, I have no idea what you are talking about... >> > >> >I have tried everything within the /etc/init.d/ldap >> >script from trying to directly add the environment >> >variable: KRB5_KTNAME within the temporary wrapper >> >file, and even did this: >> > >> >cat >> $wrapper <<- EOF >> >#!/bin/bash -x >> >export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" >> >echo 'KRB5_KTNAME='$KRB5_KTNAME >> >exec ${slapd} -h ${harg} -d ${user} $OPTIONS $SLAPD_OPTIONS >> >EOF >> > >> >And I find it odd that the exporting of KRB5_KTNAME variable >> >does NOT work within the cat construct but placing the export >> >of KRB5_KTNAME outside of this wrapper does work. Hmmm.... >> >well - at least I do know now that /etc/sysconfig/ldap is >> >working within the /etc/init.d/ldap script, however I still >> >do not know for certain that the KRB5_KTNAME is being >> >accepted by the slapd invocation within the wrapper script. >> > >> >I tried Craig's suggestion to add logging information >> >so that I can see if slapd is accepting the KRB5_KTNAME >> >environment variable: >> > >> >===================================================== >> >local4.*<tab>/var/log/slapd.log ==> /etc/syslog.conf >> >loglevel 256 ==> /etc/openldap/slapd.conf >> >===================================================== >> > >> >I was able to get the logging information to work, >> >however, I still was not able to tell if slapd >> >sees the KRB5_KTNAME variable! Does anyone have >> >any suggestions on how to obtain this or can one >> >get it? >> > >> >Also, there was one other thing... I also added: >> >===================================================== >> >svrtab /etc/openldap/ldap.keytab ==> /etc/openldap/slapd.conf >> >===================================================== >> > >> >and this did not work either. >> > >> >Again, as root, I can get slapd working on the >> >command-line and kerberos/LDAPS works well: >> >===================================================== >> >export KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab" >> >slapd -u ldap -h "ldap:/// ldaps:///" >> >===================================================== >> > >> >And even this works: >> >===================================================== >> >export KRB5_KTNAME="/etc/openldap/ldap.keytab" >> >slapd -u ldap -h "ldap:/// ldaps:///" >> > >> >(I don't see at this point why FILE: is even needed) >> >===================================================== >> > >> >At this point I am running LDAP manually until >> >a solution can be found. One thing that nags >> >me however it is *possible* that I may have >> >accidentally hosed my chown/chgrp settings on >> >my /bin, /sbin and may not have gotten all the >> >file permissions correctly set. If anyone can >> >tell me how to ensure the proper ownership/mode >> >settings by running a rpm or some sort of a >> >checking program, please let me know! >> > >> >I noticed this because the slapd log told me >> >that it could not access /etc/sasldb2 so I chgrp >> >ldap this database and the slapd does no longer >> >complains. I hope this is the right thing to do... >> > >> >Man... is something hosed or is it me. It's been a >> >helluva week. >> > >> >Dan >> > >> >> Ok, additional information: >> >> I rewrote the ldap script and I discovered that >> the daemon function is somehow responsible for >> preventing SASL to work. >> >> I am now able to get the following: >> >> 1) PASS: Simple authorization, no encryption >> 2) PASS: Simple authorization, SSL via LDAPS >> 3) PASS: Simple authorization, SSL via StartTLS >> 4) PASS: SASL authorization, no encryption >> 5) PASS: SASL authorization, SSL via LDAPS >> 6) PASS: SASL authorization, SSL via StartTLS >> >> Here is the code rewrite but note!!!!! This is >> a REDUCED code to illustrate the point that the >> original script is not working if you are using >> SASL (kerberos) and a different keytab other than >> the kerberos default locations! This code is a >> stripped down version! >> >> #!/bin/bash >> >> # ================================================= >> # TEMPORARY FIX BY DBT: ORIGINAL IS BROKEN! >> # ================================================= >> >> # Source function library. >> . /etc/init.d/functions >> >> # Source an auxiliary options file if we have one, and pick >up OPTIONS, >> # SLAPD_OPTIONS, SLURPD_OPTIONS, SLAPD_LDAPS, SLAPD_LDAPI, and maybe >> # KRB5_KTNAME. >> if [ -r /etc/sysconfig/ldap ] ; then >> . /etc/sysconfig/ldap >> fi >> >> slapd=/usr/sbin/slapd >> [ -x ${slapd} ] || exit 0 >> >> user=ldap >> url="ldap:/// ldaps:///" >> prog=`basename ${slapd}` >> >> RETVAL=0 >> >> function start() { >> >> # Start daemons. >> echo -n "Starting ${prog} " >> slapd -u ldap -h "ldap:/// ldaps:///" >> [ "$?" -eq 0 ] && success $"$base startup" || failure >$"$base startup" >> RETVAL=$? >> echo >> >> } >> >> function stop() { >> >> killproc ${slapd} >> RETVAL=$? >> echo 'Stopped '${prog} >> >> } >> >> case "$1" in >> start) >> start >> ;; >> stop) >> stop >> ;; >> restart) >> stop >> start >> ;; >> status) >> status ${slapd} >> ;; >> *) >> echo "Usage: $0 {start|stop|restart|status}" >> esac >> >> exit $RETVAL >---- >It's not a bug until it's in bugzilla. > >Craig > > Added to Bugzilla: Bug 173770 Submitted: Bugs in /etc/init.d/ldap - Kerberos/SASL broken Dan -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.362 / Virus Database: 267.13.4/175 - Release Date: 11/18/2005
