Your message dated Mon, 11 Feb 2008 12:43:24 +0530
with message-id <[EMAIL PROTECTED]>
and subject line Re: Bug#464937: slapd fails with sasl errors
has caused the Debian Bug report #464937,
regarding slapd fails with sasl errors
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [EMAIL PROTECTED]
immediately.)
--
464937: http://bugs.debian.org/cgi-bin//464937
Debian Bug Tracking System
Contact [EMAIL PROTECTED] with problems
--- Begin Message ---
Package: slapd
Version: 2.4.7-4
Severity: important
This is what happens during start
7 20 Feb 10 04:21:09 learner slapd[1036]: daemon: shutdown requested and
initiated.
7 20 Feb 10 04:21:09 learner slapd[1036]: slapd shutdown: waiting for 0
threads to terminate
7 20 Feb 10 04:21:09 learner slapd[1036]: slapd stopped.
7 20 Feb 10 04:21:09 learner slapd[1439]: @(#) $OpenLDAP: slapd 2.4.7
(Jan 26 2008 03:21:30) [EMAIL PROTECTED]:/build/buildd/openldap2.3-2.4.7/d
ebian/build/servers/slapd
7 20 Feb 10 04:21:09 learner slapd[1439]: daemon_init: listen on
ldap://127.0.0.1:389/
7 20 Feb 10 04:21:09 learner slapd[1439]: daemon_init: 1 listeners to
open...
7 20 Feb 10 04:21:09 learner slapd[1439]: daemon: listener initialized
ldap://127.0.0.1:389/
7 20 Feb 10 04:21:09 learner slapd[1439]: daemon_init: 1 listeners opened
7 20 Feb 10 04:21:09 learner slapd[1439]: slapd init: initiated server.
3 4 Feb 10 04:21:09 learner slapd[1439]: auxpropfunc error invalid
parameter supplied
7 4 Feb 10 04:21:09 learner slapd[1439]: _sasl_plugin_load failed on
sasl_auxprop_plug_init for plugin: ldapdb
7 20 Feb 10 04:21:09 learner slapd[1439]: slap_sasl_init: initialized!
7 20 Feb 10 04:21:09 learner slapd[1441]: slapd starting
So, sasl is initialized. The _sasl_plugin_load error started only after
I installed the libsasl2-modules-ldap hoping that that might solve the
problem. But no, it didn't.
Now what I connect to the server using my addressbook client (KDE
Addressbook LDAP Resource), I get the following errors.
7 20 Feb 10 04:22:51 learner slapd[1441]: SASL [conn=6] Error: unable to
open Berkeley db /etc/sasldb2: No such file or directory
7 20 Feb 10 04:22:51 learner slapd[1441]: last message repeated 2 times
7 20 Feb 10 04:22:51 learner slapd[1441]: SASL [conn=6] Failure: no
secret in database
3 4 Feb 10 04:22:51 learner [kdeinit] ldap
/tmp/ksocket-rrs/klauncherYPhlab.s: attempting client step after doneflag
7 20 Feb 10 04:22:51 learner slapd[1441]: connection_operation: error:
SASL bind in progress (tag=66).
7 20 Feb 10 04:22:52 learner slapd[1441]: SASL [conn=7] Error: unable to
open Berkeley db /etc/sasldb2: No such file or directory
7 20 Feb 10 04:22:52 learner slapd[1441]: last message repeated 2 times
7 20 Feb 10 04:22:52 learner slapd[1441]: SASL [conn=7] Failure: no
secret in database
3 4 Feb 10 04:22:52 learner [kdeinit] ldap
/tmp/ksocket-rrs/klauncherYPhlab.s: attempting client step after doneflag
7 20 Feb 10 04:22:52 learner slapd[1441]: connection_operation: error:
SASL bind in progress (tag=66).
There is no folder named /etc/sasldb2 on my system.
How am I supposed to create it ?
Is it correct for slapd to look at that path ?
There is no document much about ldap in /usr/share/doc/slapd/
Ritesh
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (600, 'unstable'), (150, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.24-1-686 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages slapd depends on:
ii adduser 3.105 add and remove users and groups
ii coreutils 5.97-5.3 The GNU core utilities
ii debconf [debconf-2.0] 1.5.19 Debian configuration management sy
ii libc6 2.7-6 GNU C Library: Shared libraries
ii libdb4.2 4.2.52+dfsg-4 Berkeley v4.2 Database Libraries [
ii libgnutls13 2.0.4-1 the GNU TLS library - runtime libr
ii libldap-2.4-2 2.4.7-4 OpenLDAP libraries
ii libltdl3 1.5.24-2 A system independent dlopen wrappe
ii libperl5.8 5.8.8-12 Shared Perl library
ii libsasl2-2 2.1.22.dfsg1-16 Cyrus SASL - authentication abstra
ii libslp1 1.2.1-7.1 OpenSLP libraries
ii libwrap0 7.6.dbs-14 Wietse Venema's TCP wrappers libra
ii perl [libmime-base64-per 5.8.8-12 Larry Wall's Practical Extraction
ii psmisc 22.6-1 Utilities that use the proc filesy
ii unixodbc 2.2.11-16 ODBC tools libraries
Versions of packages slapd recommends:
ii libsasl2-modules 2.1.22.dfsg1-16 Cyrus SASL - pluggable authenticat
-- debconf information:
* shared/organization: researchut
slapd/upgrade_slapcat_failure:
* slapd/backend: HDB
* slapd/allow_ldap_v2: false
* slapd/no_configuration: false
* slapd/move_old_database: true
slapd/suffix_change: false
slapd/dump_database_destdir: /var/backups/slapd-VERSION
* slapd/domain: ldap.researchut.com
slapd/password_mismatch:
slapd/invalid_config: true
slapd/slurpd_obsolete:
slapd/dump_database: when needed
slapd/migrate_ldbm_to_bdb: false
* slapd/purge_database: true
--- End Message ---
--- Begin Message ---
Re-installing the slapd package solved the problem.
I don't know what really to say now. Bad Bug Report.
Ritesh
On 2/11/08, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Sun, Feb 10, 2008 at 01:01:03PM +0530, Ritesh Raj Sarraf wrote:
> > On Sunday 10 February 2008, Steve Langasek wrote:
> > > Is this an upgrade from a previous version of slapd where you had SASL
> > > auth
> > > working? Or is this a new install?
>
> > No. It is a fresh install. I have never used slapd before.
> > Does slapd work without SASL ?
>
> Yes, if you use simple binds.
>
> > > If you haven't configured SASL, then you should not be doing SASL binds to
> > > the LDAP server, you should be doing simple binds instead. If you have
> > > configured SASL and had it working before, we would need to know the
> > > details of your configuration (starting with the non-sensitive parts of
> > > /etc/ldap/slapd.conf) to try to reproduce this problem. But, AFAIK all
> > > SASL auth requires configuring the Cyrus SASL library to specify which
> > > mechanisms should be used and with what passwords.
>
> > Here's an output:
> > [EMAIL PROTECTED]:~$ ldapsearch -x -b '' -s base '(objectclass=*)'
> > namingContexts
> > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
>
> > This is what the manpage is saying for -x
> > -x Use simple authentication instead of SASL.
>
> Please capture the output of this command running with full debugging
> enabled (ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts -d16383)
>
> The above doesn't indicate a SASL error at all. The most obvious
> explanation for the above is that there's no ldap server running at the
> default URI configured in /etc/ldap/ldap.conf.
>
> --
> Steve Langasek Give me a lever long enough and a Free OS
> Debian Developer to set it on, and I can move the world.
> Ubuntu Developer http://www.debian.org/
> [EMAIL PROTECTED] [EMAIL PROTECTED]
>
--
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."
--- End Message ---
