Re: (ITS#4876) Multiple levels of uniqueness
by hyc＠symas.com
quanah(a)stanford.edu wrote:
> Full_Name: Quanah Gibson-Mount
> Version: 2.3.33
> OS: NA
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (171.64.19.81)
>
>
> In using the uniqueness overlay, I found there are times I want to apply
> uniqueness rules differently based on (sub)tree. For example, I might like
> something along these lines where the db starts at dc=stanford,dc=edu:
The unique overlay in HEAD now supports this functionality. See the
updated manpage. test024 has also been updated accordingly, if you need
examples.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 6 months
(ITS#4892) slapd HEAD crashes with ldapi:// and SASL EXTERNAL
by michael＠stroeder.com
Full_Name: Michael Ströder
Version: HEAD
OS: openSUSE 10.2
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (83.124.31.177)
HI!
slapd.conf contains (identiation and line-wrapping may be screwed up:
# EXTERNAL over Unix Domain socket
authz-regexp
"gidnumber=([0-9]+)\\+uidnumber=([0-9]+),cn=peercred,cn=external,cn=auth"
"ldap:///ou=Users,ou=odd2006,dc=block-floete,dc=de??sub?(&(objectClass=posixAccount)(uidNumber=$2)(gidNumber=$1))"
Ciao, Michael.
$ ldapwhoami -H
ldapi://%2fhome%2fmichael%2fBizness%2fOpenLDAP%2fODD_2006%2fslapd-socket
-Y EXTERNAL
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
16 years, 6 months
(ITS#4891) OpenLDAP with dynlist crash
by socrtp-ldap＠soclab.eu.org
Full_Name: Piotr Stolc
Version: 2.3.34
OS: Gentoo, NetBSD
URL: http://lysergic.soclab.eu.org/dynlist-bug.ldif
Submission from: (NULL) (195.8.99.234)
I found this bug while trying to run OpenLDAP with dynlist overlay and my own
schema. The functionality of dynlist overlay works ok, but when browsing LDAP
tree with PHPLDAPAdmin the server dies. I spent a few hours debugging the
problem (accesslog overlay is cool :)) and created simple sample entries using
default schemas. Here is what I have found:
OpenLDAP server dies on this query:
$ ldapsearch -D cn=Manager,dc=test,dc=pl -W -x -h 10.1.1.15 -b dc=test,dc=pl -s
one dn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=test,dc=pl> with scope oneLevel
# filter: (objectclass=*)
# requesting: dn
#
# Manager, test.pl
dn: cn=Manager,dc=test,dc=pl
# testGroup, test.pl
dn: ou=testGroup,dc=test,dc=pl
ldap_result: Can't contact LDAP server (-1)
It has also problem with another query - one of the slapd processes locks up
with nearly 100% CPU usage:
$ ldapsearch -D cn=Manager,dc=test,dc=pl -W -x -h 10.1.1.15 -b
cn=testList,dc=test,dc=pl -s one mail
The following query works fine and shows that dynlist overlay is working:
$ ldapsearch -D cn=Manager,dc=test,dc=pl -W -x -h 10.1.1.15 -b
cn=testList,dc=test,dc=pl mail
The problem shows up with the latest stable version of OpenLDAP 2.3.34 on Gentoo
Linux and with OpenLDAP 2.3.32 on NetBSD.
I've pasted into URL field link to the LDIF with the sample dc=test,dc=pl
structure that shows the error. Here is the config for "dc=test,dc=pl" I've
used:
database bdb
suffix "dc=test,dc=pl"
rootdn "cn=Manager,dc=test,dc=pl"
rootpw secret
directory /var/lib/openldap-data-test
index cn eq
overlay dynlist
dynlist-attrset groupOfURLs memberURL
16 years, 6 months
(ITS#4890) Enhancement: Default Values overlay (patch)
by docelic＠mail.inet.hr
Full_Name: Davor Ocelic
Version: CVS-HEAD
OS: Linux
URL: http://www.hcoop.net/~docelic/openldap-slapd.overlays.defvals.patch
Submission from: (NULL) (213.147.110.16)
Hello,
Attached is a patch which adds a "Default Attribute Values" functionality
to OpenLDAP. It is implemented as an overlay named "defvals", and the patch
is done against cvs-head of today.
Complete documentation is included in the slapo-defvals(5) manual page.
The overlay code itself is commented as well, as a help for others writing
overlays.
Feel free to trim comments or improve code as you see fit.
Davor Ocelic
16 years, 6 months
Re: (ITS#4888) Enhance back-sql with paged results
by adamson＠andrew.cmu.edu
Hi Pierangelo
> Let me note that the patch doesn't build fine (you need to declare in
> advance the static functions you're only defining at the end), and it
> seems to work incorrectly. By running the simple sql-test000 with mysql
> (which fails because now the order has changed; my fault: should have
> added -S "" to searches), if I search without the control, I correctly
> get 6 entries and a referral; if I search with paged results and a page
> size less than 6, I only get 5 entries. The root entry is missing, but
> I have no idea of the reason, I couldn't infer anything from the code or
> the logs. Can you check?
When I checked on the patch file in my Emacs window this morning I saw the
"modified buffer" flag was still on because I hadn't saved the final
version. Grrrr. It included the function declarations and one last fix.
Sorry about that. When I extract the last ID number from the cookie, I
have to make sure we're in the same objectClass as when the ID number was
saved.
I've replaced the patch file on my web server. If it doesn't fix the
root entry bug you're seeing, could you show me the search you're
performing? I'll have to more closely follow what's happening in the
switch ( bsi.bsi_scope ) {
segment around line 2115 in backsql_search() to see if there is some
special case for the root entry.
-Mark Adamson
Carnegie Mellon
16 years, 6 months
(ITS#4889) Tranlucent Overlay
by ghenry＠suretecsystems.com
Full_Name: Gavin Henry
Version: 2.3.34
OS: FC6
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.229.93.1)
Dear All,
Just been playing iwth slapo-translucent, and ldapmodified an entry on the
remote side successfully. However, when I search for that entry, after the first
or second search, slapd aborts. I merely changed a birthday and title for my own
ghenry entry
Here my slapd.conf:
-------------------------
include /usr/local/etc/openldap/schema/core.schema
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
# Load dynamic backend modules:
modulepath /usr/local/libexec/openldap
moduleload back_bdb.la
moduleload back_ldap.la
moduleload translucent.la
moduleload rwm.la
database bdb
directory /usr/local/var/openldap-data
cachesize 10000
suffix "dc=suretecsystems,dc=com"
rootdn "cn=manager,dc=suretecsystems,dc=com"
rootpw secret
index default eq
index objectClass,uid,dc,o,ou
overlay translucent
overlay rwm
uri ldap://192.168.10.103:389
lastmod off
idassert-bind binddn="cn=manager,dc=suretecsystems,dc=com" credentials=secret
rwm-map objectclass * *
rwm-map attribute * *
-------------------------
Using db-4.2.52 and the 5 patches.
He's a gdb session:
[Thread debugging using libthread_db enabled]
[New Thread -1209051456 (LWP 4529)]
@(#) $OpenLDAP: slapd 2.3.34 (Mar 20 2007 14:53:32) $
ghenry@suretec:/home/ghenry/openldap/openldap-2.3.34/servers/slapd
WARNING: No dynamic config support for database bdb.
WARNING: No dynamic config support for overlay rwm.
WARNING: No dynamic config support for overlay translucent.
bdb_db_open: unclean shutdown detected; attempting recovery.
slapd starting
[New Thread -1547441264 (LWP 4532)]
conn=0 fd=15 ACCEPT from IP=127.0.0.1:33269 (IP=0.0.0.0:389)
[New Thread -1557931120 (LWP 4534)]
conn=0 op=0 BIND dn="" method=128
conn=0 op=0 RESULT tag=97 err=0 text=
[New Thread -1569473648 (LWP 4535)]
conn=0 op=1 SRCH base="dc=suretecsystems,dc=com" scope=2 deref=0
filter="(uid=ghenry)"
request done: ld 0x8e0dd10 msgid 1
request done: ld 0x8e0dd10 msgid 2
conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=0 op=2 UNBIND
conn=0 fd=15 closed
*** glibc detected *** /usr/local/libexec/slapd: corrupted double-linked list:
0x08e19458 ***
======= Backtrace: =========
/lib/libc.so.6[0xb0448b]
/lib/libc.so.6[0xb066f3]
/lib/libc.so.6(__libc_calloc+0x8d)[0xb07bdd]
/lib/libc.so.6(open_memstream+0x5d)[0xafce7d]
/lib/libc.so.6(__vsyslog_chk+0x76)[0xb69656]
/lib/libc.so.6(syslog+0x2a)[0xb69bfa]
/usr/local/libexec/slapd[0x80687e5]
/usr/local/libexec/slapd[0x8068c9c]
/usr/local/lib/libldap_r-2.3.so.0[0x11b56d]
/lib/libpthread.so.0[0xc133db]
/lib/libc.so.6(clone+0x5e)[0xb6d26e]
======= Memory map: ========
00110000-00148000 r-xp 00000000 fd:00 10953537
/usr/local/lib/libldap_r-2.3.so.0.2.22
00148000-0014a000 rwxp 00037000 fd:00 10953537
/usr/local/lib/libldap_r-2.3.so.0.2.22
0014a000-0014f000 rwxp 0014a000 00:00 0
0014f000-0015a000 r-xp 00000000 fd:00 10953351
/usr/local/lib/liblber-2.3.so.0.2.22
0015a000-0015b000 rwxp 0000a000 fd:00 10953351
/usr/local/lib/liblber-2.3.so.0.2.22
0015b000-0015f000 r-xp 00000000 fd:00 11025778
/usr/lib/sasl2/libcrammd5.so.2.0.22
0015f000-00160000 rwxp 00003000 fd:00 11025778
/usr/lib/sasl2/libcrammd5.so.2.0.22
00160000-0023b000 r-xp 00000000 fd:00 11031861
/usr/lib/sasl2/libsasldb.so.2.0.22
0023b000-0023d000 rwxp 000db000 fd:00 11031861
/usr/lib/sasl2/libsasldb.so.2.0.22
0023d000-00251000 r-xp 00000000 fd:00 820357
/usr/local/libexec/openldap/back_ldap-2.3.so.0.2.22
00251000-00253000 rwxp 00013000 fd:00 820357
/usr/local/libexec/openldap/back_ldap-2.3.so.0.2.22
00253000-0025e000 r-xp 00000000 fd:00 2290131
/lib/libgcc_s-4.1.1-20070105.so.1
0025e000-0025f000 rwxp 0000a000 fd:00 2290131
/lib/libgcc_s-4.1.1-20070105.so.1
0027c000-00282000 r-xp 00000000 fd:00 10928729 /usr/lib/libltdl.so.3.1.4
00282000-00283000 rwxp 00005000 fd:00 10928729 /usr/lib/libltdl.so.3.1.4
002e2000-002e9000 r-xp 00000000 fd:00 10929498 /usr/lib/libwrap.so.0.7.6
002e9000-002ea000 rwxp 00007000 fd:00 10929498 /usr/lib/libwrap.so.0.7.6
002ea000-003a5000 r-xp 00000000 fd:00 393521
/usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
003a5000-003a7000 rwxp 000bb000 fd:00 393521
/usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so
003f3000-003fc000 r-xp 00000000 fd:00 2289320 /lib/libnss_files-2.5.so
003fc000-003fd000 r-xp 00008000 fd:00 2289320 /lib/libnss_files-2.5.so
003fd000-003fe000 rwxp 00009000 fd:00 2289320 /lib/libnss_files-2.5.so
004ca000-004ce000 r-xp 00000000 fd:00 11028143
/usr/lib/sasl2/liblogin.so.2.0.22
004ce000-004cf000 rwxp 00003000 fd:00 11028143
/usr/lib/sasl2/liblogin.so.2.0.22
00504000-00528000 r-xp 00000000 fd:00 820345
/usr/local/libexec/openldap/back_bdb-2.3.so.0.2.22
00528000-00529000 rwxp 00024000 fd:00 820345
/usr/local/libexec/openldap/back_bdb-2.3.so.0.2.22
00529000-00535000 rwxp 00529000 00:00 0
00695000-00696000 r-xp 00695000 00:00 0 [vdso]
0071d000-00721000 r-xp 00000000 fd:00 820437
/usr/local/libexec/openldap/translucent-2.3.so.0.2.22
00721000-00722000 rwxp 00003000 fd:00 820437
/usr/local/libexec/openldap/translucent-2.3.so.0.2.22
007fe000-00809000 r-xp 00000000 fd:00 11025782
/usr/lib/sasl2/libdigestmd5.so.2.0.22
00809000-0080a000 rwxp 0000b000 fd:00 11025782
/usr/lib/sasl2/libdigestmd5.so.2.0.22
00916000-00929000 r-xp 00000000 fd:00 2290139 /lib/libnsl-2.5.so
00929000-0092a000 r-xp 00012000 fd:00 2290139 /lib/libnsl-2.5.so
0092a000-0092b000 rwxp 00013000 fd:00 2290139 /lib/libnsl-2.5.so
0092b000-0092d000 rwxp 0092b000 00:00 0
0092f000-0093e000 r-xp 00000000 fd:00 2290132 /lib/libresolv-2.5.so
0093e000-0093f000 r-xp 0000e000 fd:00 2290132 /lib/libresolv-2.5.so
0093f000-00940000 rwxp 0000f000 fd:00 2290132 /lib/libresolv-2.5.so
00940000-00942000 rwxp 00940000 00:00 0
0099a000-0099e000 r-xp 00000000 fd:00 11021253
/usr/lib/sasl2/libanonymous.so.2.0.22
0099e000-0099f000 rwxp 00003000 fd:00 11021253
/usr/lib/sasl2/libanonymous.so.2.0.22
009a5000-009a7000 r-xp 00000000 fd:00 2290133 /lib/libcom_err.so.2.1
009a7000-009a8000 rwxp 00001000 fd:00 2290133 /lib/libcom_err.so.2.1
009aa000-00a2e000 r-xp 00000000 fd:00 10928447 /usr/lib/libkrb5.so.3.2
00a2e000-00a30000 rwxp 00084000 fd:00 10928447 /usr/lib/libkrb5.so.3.2
00a32000-00a39000 r-xp 00000000 fd:00 10928445 /usr/lib/libkrb5support.so.0.1
00a39000-00a3a000 rwxp 00006000 fd:00 10928445 /usr/lib/libkrb5support.so.0.1
00a3c000-00a61000 r-xp 00000000 fd:00 10928446 /usr/lib/libk5crypto.so.3.0
00a61000-00a62000 rwxp 00025000 fd:00 10928446 /usr/lib/libk5crypto.so.3.0
00a83000-00a9c000 r-xp 00000000 fd:00 2289282 /lib/ld-2.5.so
00a9c000-00a9d000 r-xp 00018000 fd:00 2289282 /lib/ld-2.5.so
00a9d000-00a9e000 rwxp 00019000 fd:00 2289282 /lib/ld-2.5.so
00aa0000-00bd7000 r-xp 00000000 fd:00 2289319 /lib/libc-2.5.so
00bd7000-00bd9000 r-xp 00137000 fd:00 2289319 /lib/libc-2.5.so
00bd9000-00bda000 rwxp 00139000 fd:00 2289319 /lib/libc-2.5.so
00bda000-00bdd000 rwxp 00bda000 00:00 0
00c08000-00c0a000 r-xp 00000000 fd:00 2289374 /lib/libdl-2.5.so
00c0a000-00c0b000 r-xp 00001000 fd:00 2289374 /lib/libdl-2.5.so
00c0b000-00c0c000 rwxp 00002000 fd:00 2289374 /lib/libdl-2.5.so
00c0e000-00c21000 r-xp 00000000 fd:00 2289321 /lib/libpthread-2.5.so
00c21000-00c22000 r-xp 00012000 fd:00 2289321 /lib/libpthread-2.5.so
00c22000-00c23000 rwxp 00013000 fd:00 2289321 /lib/libpthread-2.5.so
00c23000-00c25000 rwxp 00c23000 00:00 0
00c27000-00c39000 r-xp 00000000 fd:00 10928409 /usr/lib/libz.so.1.2.3
00c39000-00c3a000 rwxp 00011000 fd:00 10928409 /usr/lib/libz.so.1.2.3
00c49000-00c51000 r-xp 00000000 fd:00 820429
/usr/local/libexec/openldap/rwm-2.3.so.0.2.22
00c51000-00c52000 rwxp 00008000 fd:00 820429
/usr/local/libexec/openldap/rwm-2.3.so.0.2.22
00da4000-00da8000 r-xp 00000000 fd:00 11028147
/usr/lib/sasl2/libplain.so.2.0.22
00da8000-00da9000 rwxp 00003000 fd:00 11028147
/usr/lib/sasl2/libplain.so.2.0.22
06574000-06690000 r-xp 00000000 fd:00 2290134 /lib/libcrypto.so.0.9.8b
06690000-066a2000 rwxp 0011c000 fd:00 2290134 /lib/libcrypto.so.0.9.8b
066a2000-066a6000 rwxp 066a2000 00:00 0
066a8000-066d2000 r-xp 00000000 fd:00 10928450 /usr/lib/libgssapi_krb5.so.2.2
066d2000-066d3000 rwxp 00029000 fd:00 10928450 /usr/lib/libgssapi_krb5.so.2.2
066d5000-06716000 r-xp 00000000 fd:00 2290135 /lib/libssl.so.0.9.8b
06716000-0671a000 rwxp 00040000 fd:00 2290135 /lib/libssl.so.0.9.8b
06aeb000-06af0000 r-xp 00000000 fd:00 2290136 /lib/libcrypt-2.5.so
06af0000-06af1000 r-xp 00004000 fd:00 2290136 /lib/libcrypt-2.5.so
06af1000-06af2000 rwxp 00005000 fd:00 2290136 /lib/libcrypt-2.5.so
06af2000-06b19000 rwxp 06af2000 00:00 0
06dcb000-06de3000 r-xp 00000000 fd:00 10928451 /usr/lib/libsasl2.so.2.0.22
06de3000-06de4000 rwxp 00017000 fd:00 10928451 /usr/lib/libsasl2.so.2.0.22
08048000-0811d000 r-xp 00000000 fd:00 10953555 /usr/local/libexec/slapd
0811d000-08121000 rw-p 000d4000 fd:00 10953555 /usr/local/libexec/slapd
08121000-08124000 rw-p 08121000 00:00 0
08d12000-08e2d000 rw-p 08d12000 00:00 0
a1b00000-a1b21000 rw-p a1b00000 00:00 0
a1b21000-a1c00000 ---p a1b21000 00:00 0
a1c3a000-a1d3b000 rw-p a1c3a000 00:00 0
a1d3b000-a1d3c000 ---p a1d3b000 00:00 0
a1d3c000-a283d000 rw-p a1d3c000 00:00 0
a283d000-a283e000 ---p a283d000 00:00 0
a283e000-a323e000 rw-p a283e000 00:00 0
a323e000-a323f000 ---p a323e000 00:00 0
a323f000-a3c3f000 rw-p a323f000 00:00 0
a3c3f000-a3c45000 rw-s 00000000 fd:00 821479
/usr/local/var/openldap-data/__db.005
a3c45000-a3cb3000 rw-s 00000000 fd:00 821478
/usr/local/var/openldap-data/__db.004
a3cb3000-a3ef3000 rw-s 00000000 fd:00 821477
/usr/local/var/openldap-data/__db.003
a3ef3000-b7ef5000 rw-s 00000000 fd:00 820670
/usr/local/var/openldap-data/__db.002
b7ef5000-b7efa000 rw-p b7ef5000 00:00 0
b7f0e000-b7f12000 rw-s 00000000 fd:00 820669
/usr/local/var/openldap-data/__db.001
b7f12000-b7f13000 rw-p b7f12000 00:00 0
bfe20000-bfe36000 rw-p bfe20000 00:00 0 [stack]
Program received signal SIGABRT, Aborted.
[Switching to Thread -1569473648 (LWP 4535)]
0x00695402 in __kernel_vsyscall ()
(gdb) bt
#0 0x00695402 in __kernel_vsyscall ()
#1 0x00ac8d40 in raise () from /lib/libc.so.6
#2 0x00aca591 in abort () from /lib/libc.so.6
#3 0x00afe33b in __libc_message () from /lib/libc.so.6
#4 0x00b0448b in malloc_consolidate () from /lib/libc.so.6
#5 0x00b066f3 in _int_malloc () from /lib/libc.so.6
#6 0x00b07bdd in calloc () from /lib/libc.so.6
#7 0x00afce7d in open_memstream () from /lib/libc.so.6
#8 0x00b69656 in __vsyslog_chk () from /lib/libc.so.6
#9 0x00b69bfa in syslog () from /lib/libc.so.6
#10 0x080687e5 in connection2anonymous ()
#11 0x08068c9c in connection2anonymous ()
#12 0x0011b56d in ldap_int_thread_pool_wrapper (xpool=0x0) at tpool.c:478
#13 0x00c133db in start_thread () from /lib/libpthread.so.0
#14 0x00b6d26e in clone () from /lib/libc.so.6
Please let me know what else is needed.
Thanks,
Gavin.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry(a)suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/
16 years, 6 months
RE: (ITS#4886) slapd stopping with no error message
by douglas＠gpc.edu
Thanks for the quick reply. I will try to get some things together in
one or more emails.
I got the following:
"Bis Dienstag, den 2. April bin ich leider nicht erreichbar. Sollte Ihr Anliegen nicht so lange warten können, wenden Sie sich bitte
an unsere Hotline unter der Rufnummer 0511-5181188.
---------------------------------------------------------------------
Mit freundlichen Grüßen
Johannes Königsmann
Gutenberg Rechenzentrum
GmbH & Co. KG
System-Management
August-Madsack-Straße 1
30559 Hannover
Tel. : +49 511 518-1107
Fax : +49 511 518-1102
e-Mail: koenigsmann(a)gutenberg-rz.de
Internet: www.gutenberg-rz.de
_________________________________________
Gutenberg Rechenzentrum GmbH & Co. KG
Sitz: Hannover
Handelsregister: Hannover HRA 21 669
Geschäftsführer: Karl-Rüdiger Garbs, Dr. Claudia Hümpel"
I wanted to reply to him letting him know that I did know German (wish I did), but
I was a little hesitant this might not be a legitimate response to my its. Is there
a way I could find out if he is legitimate or if he is not, then I would ignore it.
Thanks for any help with this side question. Thanks!
-----Original Message-----
From: Howard Chu [mailto:hyc@symas.com]
Sent: Thursday, March 22, 2007 4:36 AM
To: douglas(a)gpc.edu
Cc: Kurt Zeilenga
Subject: Re: (ITS#4886) slapd stopping with no error message
Also show the output for
print *ber
at the crash location
Seems like something is bad in your build environment if you can get it
to crash after only one search. Have you run the test suite successfully?
douglas(a)gpc.edu wrote:
> Full_Name: Douglas Jones
> Version: 2.3.34
> OS: RHEL4 (linux)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (168.28.202.22)
>
>
> Without efence, after the server has been runing between 3 and 15 days,
> it varies, the sever just stops. Even using ulimit on core size, I did
> not have luck getting a core file. Per recomendation of the newgroups,
> I used efence and it crashed on the first lookup. I got the following under
> gdb:
>
> (previous -d 1 output cut)
> It did return the names to my client, which was good, but just crashed after
> (during) that. Please let me know if I can do anythin else. Thanks!
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 6 months
Re: (ITS#4888) Enhance back-sql with paged results
by ando＠sys-net.it
hyc(a)symas.com wrote:
> adamson(a)cmu.edu wrote:
>> Full_Name: Mark Adamson
>> Version: HEAD
>> OS: Solaris 2.8
>> URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch
>> Submission from: (NULL) (128.2.234.24)
>>
>>
>> Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS
>> control with the SQL backend. The patch to add this is not hard, and was mostly
>> copied from the back-bdb/search.c file.
>>
>> http://null.andrew.cmu.edu/openldap/sql_paged_results.patch
>>
>> The only challenge was the contents of the cookie that is used to maintain
>> state. The slap.h file defines the PagedResultsCookie type to be an unsigned
>> long, so I wanted to fit everything into that. The design idea was to keep the
>> ldap_entries.id value of the last returned entry in the cookie so that
>> subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to
>> the SQL query. However, the gathering of candidate entries is done across all
>> objectClasses with avl_apply(), so if one OC returns an entry with a high
>> ldap_entries.id, objectClasses that come later in the AVL could miss entries.
>> For this reason, I add the oc_map_id of the last returned entry to the cookie,
>> and I adjusted the avl_apply() call to run through the objectClasses in numeric
>> order. In this way, when subsequent pages of entries are requested, all of the
>> objectClasses that were completed by previous pages can be skipped for the new
>> page. When we get to the objectClass where the previous page left off, we take
>> the ldap_entries.id from the cookie and apply the above mentioned SQL clause.
>
> A more appropriate change would probably be to change the cookie type to
> a berval so that arbitrary data may be used as needed by each backend.
> Then you can set both the oc_map_id and the ldap_entries.id.
>
> Ultimately this sort of thing should be handled almost entirely by the
> frontend, with just a single call in the backend to fill a cookie struct
> for the current search state.
I concur (was about to suggest the same: move parse_paged_cookie() and
send_paged_response() to servers/slapd/result.c, adding as much as
required to customize it from within the backend specific call.
Let me note that the patch doesn't build fine (you need to declare in
advance the static functions you're only defining at the end), and it
seems to work incorrectly. By running the simple sql-test000 with mysql
(which fails because now the order has changed; my fault: should have
added -S "" to searches), if I search without the control, I correctly
get 6 entries and a referral; if I search with paged results and a page
size less than 6, I only get 5 entries. The root entry is missing, but
I have no idea of the reason, I couldn't infer anything from the code or
the logs. Can you check?
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office: +39.02.23998309
Mobile: +39.333.4963172
Email: pierangelo.masarati(a)sys-net.it
------------------------------------------
16 years, 6 months
Re: (ITS#4886) slapd stopping with no error message
by hyc＠symas.com
Also show the output for
print *ber
at the crash location
Seems like something is bad in your build environment if you can get it
to crash after only one search. Have you run the test suite successfully?
douglas(a)gpc.edu wrote:
> Full_Name: Douglas Jones
> Version: 2.3.34
> OS: RHEL4 (linux)
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (168.28.202.22)
>
>
> Without efence, after the server has been runing between 3 and 15 days,
> it varies, the sever just stops. Even using ulimit on core size, I did
> not have luck getting a core file. Per recomendation of the newgroups,
> I used efence and it crashed on the first lookup. I got the following under
> gdb:
>
> (previous -d 1 output cut)
> It did return the names to my client, which was good, but just crashed after
> (during) that. Please let me know if I can do anythin else. Thanks!
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 6 months
Re: (ITS#4888) Enhance back-sql with paged results
by hyc＠symas.com
adamson(a)cmu.edu wrote:
> Full_Name: Mark Adamson
> Version: HEAD
> OS: Solaris 2.8
> URL: http://null.andrew.cmu.edu/openldap/sql_paged_results.patch
> Submission from: (NULL) (128.2.234.24)
>
>
> Here at Carnegie Mellon we had a need to use the LDAP_CONTROL_PAGEDRESULTS
> control with the SQL backend. The patch to add this is not hard, and was mostly
> copied from the back-bdb/search.c file.
>
> http://null.andrew.cmu.edu/openldap/sql_paged_results.patch
>
> The only challenge was the contents of the cookie that is used to maintain
> state. The slap.h file defines the PagedResultsCookie type to be an unsigned
> long, so I wanted to fit everything into that. The design idea was to keep the
> ldap_entries.id value of the last returned entry in the cookie so that
> subsequent searches could add a "AND ldap_entries.id > COOKIEVALUE" clause to
> the SQL query. However, the gathering of candidate entries is done across all
> objectClasses with avl_apply(), so if one OC returns an entry with a high
> ldap_entries.id, objectClasses that come later in the AVL could miss entries.
> For this reason, I add the oc_map_id of the last returned entry to the cookie,
> and I adjusted the avl_apply() call to run through the objectClasses in numeric
> order. In this way, when subsequent pages of entries are requested, all of the
> objectClasses that were completed by previous pages can be skipped for the new
> page. When we get to the objectClass where the previous page left off, we take
> the ldap_entries.id from the cookie and apply the above mentioned SQL clause.
A more appropriate change would probably be to change the cookie type to
a berval so that arbitrary data may be used as needed by each backend.
Then you can set both the oc_map_id and the ldap_entries.id.
Ultimately this sort of thing should be handled almost entirely by the
frontend, with just a single call in the backend to fill a cookie struct
for the current search state.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
Chief Architect, OpenLDAP http://www.openldap.org/project/
16 years, 6 months
