Your message dated Wed, 5 Aug 2009 12:24:41 +0100
with message-id <[email protected]>
and subject line Re: slapd-ldap failure
has caused the Debian Bug report #444936,
regarding slapd-ldap failure
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.)
--
444936: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=444936
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: slapd
Version: 2.3.38-1
Severity: important
Preface: I've tried to verify this as an actual bug, but my scope
of knowledge here is somewhat lacking - so it is entirely possible
I am just brain-dead... If that is indeed the case, feel free to
lower the severity and lart the reporter appropriately.
For performance, and management reasons, I'm using the local slapd
as a proxy for some remote databases, as well as serving its own data.
- it will eventually cache some of the upstream data.
After setting up a minimal re-write setup (it will be fleshed out
later):
suffix "ou=bluepages"
rwm-suffixmassage "ou=bluepages" "ou=bluepages,o=ibm.com"
uri "ldaps://bluepages.ibm.com/"
protocol-version 3
rebind-as-user yes
I find that some local requests(bind) work fine, and some (search)
hang for quite some time... making its use for authentication problematic -
as pam_ldap does search to find the dn, then bind on the resultant dn.
Here is the failing testcase run against the upstream server:
--------------------------------------------------------------------------
$time ldapsearch -x -P3 -Hldap://bluepages.ibm.com/ \
-b'c=us,ou=bluepages,o=ibm.com' \
'(&(objectClass=ibmPerson)(notesShortName=cowboy))' dn
# extended LDIF
#
# LDAPv3
# base <c=us,ou=bluepages,o=ibm.com> with scope subtree
# filter: (&(objectClass=ibmPerson)(notesShortName=cowboy))
# requesting: dn
#
# 677990897, us, bluepages, ibm.com
dn: uid=677990897,c=us,ou=bluepages,o=ibm.com
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
real 0m10.257s
user 0m0.003s
sys 0m0.000s
--------------------------------------------------------------------------
Here is the same testcase run against the localhost, proxy server:
--------------------------------------------------------------------------
$time ldapsearch -x -P3 -Hldapi:/// \
-b'c=us,ou=bluepages' \
'(&(objectClass=ibmPerson)(notesShortName=cowboy))' dn
# extended LDIF
#
# LDAPv3
# base <c=us,ou=bluepages> with scope subtree
# filter: (&(objectClass=ibmPerson)(notesShortName=cowboy))
# requesting: dn
#
^C
real 0m31.375s
user 0m0.000s
sys 0m0.003s
--------------------------------------------------------------------------
In attempt to see what was going on, I ran wireshark and noticed that
the filter strings were being re-written (even without any rules on my
part), and my specified filters were being replaced with garbage !
The filter string passed to the upstream server is actually:
(&(!(objectclass=*))(!(objectClass=*)))
If I only use the specific filter notesShortName=cowboy, then it gets
re-written to: (!(objectclass=*)
Google has not been overly helpful, but I can't imagine that this
feature is widely used either.
-- System Information:
Debian Release: lenny/sid
APT prefers testing-proposed-updates
APT policy: (500, 'testing-proposed-updates'), (500, 'proposed-updates'),
(500, 'unstable'), (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.22.4 (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.4 The GNU core utilities
ii debconf [debconf-2.0] 1.5.14 Debian configuration management sy
ii libc6 2.6.1-5 GNU C Library: Shared libraries
ii libdb4.2 4.2.52+dfsg-4 Berkeley v4.2 Database Libraries [
ii libiodbc2 3.52.5-1+b1 iODBC Driver Manager
ii libldap-2.3-0 2.3.38-1 OpenLDAP libraries
ii libltdl3 1.5.24-1 A system independent dlopen wrappe
ii libperl5.8 5.8.8-11 Shared Perl library
ii libsasl2-2 2.1.22.dfsg1-15 Authentication abstraction library
ii libslp1 1.2.1-6.2 OpenSLP libraries
ii libssl0.9.8 0.9.8e-9 SSL shared libraries
ii libwrap0 7.6.dbs-14 Wietse Venema's TCP wrappers libra
ii perl [libmime-base64-per 5.8.8-11 Larry Wall's Practical Extraction
ii psmisc 22.5-1 Utilities that use the proc filesy
Versions of packages slapd recommends:
ii libsasl2-modules 2.1.22.dfsg1-15 Pluggable Authentication Modules f
-- debconf information:
slapd/internal/adminpw: (password omitted)
* slapd/password1: (password omitted)
* slapd/password2: (password omitted)
slapd/fix_directory: true
shared/organization: svl.ibm.com
slapd/upgrade_slapcat_failure:
slapd/backend: BDB
slapd/allow_ldap_v2: false
slapd/no_configuration: false
slapd/move_old_database: true
slapd/suffix_change: false
slapd/slave_databases_require_updateref:
slapd/dump_database_destdir: /var/backups/slapd-VERSION
slapd/autoconf_modules: true
slapd/domain: svl.ibm.com
slapd/password_mismatch:
slapd/invalid_config: true
slapd/upgrade_slapadd_failure:
slapd/dump_database: when needed
slapd/migrate_ldbm_to_bdb: true
slapd/purge_database: false
--- End Message ---
--- Begin Message ---
Upstream has commented to the effect that this is a configuration error
rather than a bug; closing accordingly.
--
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]
--- End Message ---
