- openldap-bugs - openldap.org

(ITS#4835) dyngroup.schema needs clarification
by hyc＠OpenLDAP.org 07 Feb '07

07 Feb '07

Full_Name: Howard Chu Version: 2.3/HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc Our current schema definition defines groupOfURLs as a structural objectclass. This matches the definition used by Netscape, where this schema originates. However, the published documentation describes it as an auxiliary objectclass, and indeed the Netscape/iPlanet/Sun/FDS/RHDS servers use it as if it were an auxiliary. http://www.redhat.com/docs/manuals/dir-server/schema/6.1/oc_dir.htm#1316814 This ambiguity arises because Netscape/iPlanet/Sun/FDS/RHDS don't actually implement the LDAP/X.500 data model correctly. There are many areas where they fail to implement the model, but in this specific case they simply don't enforce schema definitions. http://forum.java.sun.com/thread.jspa?threadID=5016864&messageID=9034636 And it appears that their developers didn't consider this a problem worthy of attention. But it's creating confusion for other users. http://www.openldap.org/lists/openldap-software/200609/msg00121.html I think the right thing to do here is change our definition to AUXILIARY since that matches its actual usage. It won't match the published definitions, but those definitions are demonstrably wrong.

1 0

ITS#4556 ditStructureRules
by hyc＠symas.com 07 Feb '07

07 Feb '07

I've often thought about adding support here, but it looks like an all-or-nothing proposition. I.e., when you have a server that uses ditStructureRules, you must actually define a full set of rules otherwise you cannot add any user entries to the directory at all. This would be a pretty drastic change for people accustomed to the current behavior, where you can put any entry you like anywhere you like. Beginners have a hard enough time just getting their first two entries into the directory; requiring the use of ditStructureRules would seem to just make a bad situation worse. Possibly we could make it a configurable option - enable them with a per-database setting, defaulting to off to preserve the current behavior. Fully aligning with X.500 practices would have to wait for a new generation of server. E.g., we currently support the use of subdatabases using subordinate/glue. These provide some of the notion of X.500 Administrative Areas, except their definitions reside in the cn=config tree, not as subentries of the main DIT. Providing full subentry-based administration would be a major change in how the server is operated and how the DIT is administered. Something for OpenLDAP 3.0. -- -- 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/

1 0

Re: (ITS#4833) Back-config chokes when adding database
by rhafer＠suse.de 07 Feb '07

07 Feb '07

Tested, seems to work correctly now. Thanks. On Wednesday 07 February 2007 16:18, Howard Chu wrote: > Thanks, fixed. -- Ralf

1 0

Re: (ITS#4833) Back-config chokes when adding database
by hyc＠symas.com 07 Feb '07

07 Feb '07

Thanks, fixed. rhafer(a)suse.de wrote: > Full_Name: Ralf Haferkamp > Version: HEAD > OS: - > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.166.144.248) > > > When adding a database without an explicit index set olcDatabase-Attribute slapd > crashes (find stack backtrace below). > > This is the LDIF I tried to add: > > dn: olcDatabase=ldap,cn=config > objectclass: olcDatabaseConfig > objectclass: olcldapconfig > olcDatabase: ldap > olcsuffix: cn=test > olcrootdn: cn=admin,cn=test > olcrootpw: secret > olcdburi: ldap://my.ldap.server > > When using the correct index, '{1}' in my case it works as expected. I suspect > something's wrong the special handling of the {-1} index of frontendDB, but > wasn't able to track it down completely. > > Here's the backtrace: -- -- 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/

1 0

Re: (ITS#4834) DN matching rules should be indexed
by h.b.furuseth＠usit.uio.no 07 Feb '07

07 Feb '07

Suggestion: Generalize a bit and support the slapd.conf statement index attr :matchingRule Can be used with the extended filter (attr:matchingRule:=foo), or with e.g. (attr=foo) when matchingRule is the EQUALITY rule. -- Regards, Hallvard

1 0

(ITS#4834) DN matching rules should be indexed
by hyc＠OpenLDAP.org 07 Feb '07

07 Feb '07

Full_Name: Howard Chu Version: 2.3, HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.168.84.21) Submitted by: hyc The dnSubtreeMatch, dnOneLevelMatch, dnSubordinateMatch, and dnSuperiorMatch matching rules added in OpenLDAP 2.3 can be used in extended filter clauses to get finer control over the scope of a search. Currently back-bdb/back-hdb don't do any indexing for extended filters, which can make these filters pretty expensive to evaluate. But these specific rules can take advantage of the dn2id index, which already maintains all the necessary index information. If these extensions are going to be used frequently, we should add index support here.

1 0

(ITS#4833) Back-config chokes when adding database
by rhafer＠suse.de 07 Feb '07

07 Feb '07

Full_Name: Ralf Haferkamp Version: HEAD OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.144.248) When adding a database without an explicit index set olcDatabase-Attribute slapd crashes (find stack backtrace below). This is the LDIF I tried to add: dn: olcDatabase=ldap,cn=config objectclass: olcDatabaseConfig objectclass: olcldapconfig olcDatabase: ldap olcsuffix: cn=test olcrootdn: cn=admin,cn=test olcrootpw: secret olcdburi: ldap://my.ldap.server When using the correct index, '{1}' in my case it works as expected. I suspect something's wrong the special handling of the {-1} index of frontendDB, but wasn't able to track it down completely. Here's the backtrace: #0 0x0000000000415083 in config_add_internal (cfb=0x7f11c0, e=0x88af68, ca=0x40fff6c0, rs=0x41000cb0, renum=0x41000884, op=0x8ad530) at bconfig.c:4385 #1 0x00000000004156a7 in config_back_add (op=0x8ad530, rs=0x41000cb0) at bconfig.c:4523 #2 0x000000000043057b in fe_op_add (op=0x8ad530, rs=0x41000cb0) at add.c:330 #3 0x000000000042feaf in do_add (op=0x8ad530, rs=0x41000cb0) at add.c:182 #4 0x00000000004276db in connection_operation (ctx=0x41000de0, arg_v=0x8ad530) at connection.c:1129 #5 0x0000000000427bb9 in connection_read_thread (ctx=0x41000de0, argv=0xc) at connection.c:1257 #6 0x000000000053d552 in ldap_int_thread_pool_wrapper (xpool=0x85e630) at tpool.c:704 #7 0x00002b374570309e in start_thread () from /lib64/libpthread.so.0 #8 0x00002b37459d94cd in clone () from /lib64/libc.so.6 #9 0x0000000000000000 in ?? ()

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

syncrepl.c rev 1.310 Provided a successful test: Cleaning up test run directory leftover from previous run. Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... Waiting 10 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received config changes... Adding schema and databases on producer... Using ldapadd to populate producer... Waiting 20 seconds for syncrepl to receive changes... Using ldapsearch to check that syncrepl received database changes... Using ldapsearch to read config from the producer... Using ldapsearch to read config from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved configs from producer and consumer... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... >>>>> Test succeeded Many thanks, Gavin.

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

(gdb) attach 15790 Attaching to process 15790 Reading symbols from /anything/src/openldap-devel/servers/slapd/.libs/lt-slapd...done. Using host libthread_db library "/lib/libthread_db.so.1". Reading symbols from /anything/src/openldap-devel/libraries/libldap_r/.libs/libldap_r-2-devel.so.0...done. Loaded symbols for /anything/src/openldap-devel/libraries/libldap_r/.libs/libldap_r-2-devel.so.0 Reading symbols from /anything/src/openldap-devel/libraries/liblber/.libs/liblber-2-devel.so.0...done. Loaded symbols for /anything/src/openldap-devel/libraries/liblber/.libs/liblber-2-devel.so.0 Reading symbols from /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so...done. Loaded symbols for /usr/local/BerkeleyDB.4.2/lib/libdb-4.2.so Reading symbols from /usr/lib/libsasl2.so.2...done. Loaded symbols for /usr/lib/libsasl2.so.2 Reading symbols from /lib/libssl.so.6...done. Loaded symbols for /lib/libssl.so.6 Reading symbols from /lib/libcrypto.so.6...done. Loaded symbols for /lib/libcrypto.so.6 Reading symbols from /lib/libresolv.so.2...done. Loaded symbols for /lib/libresolv.so.2 Reading symbols from /usr/lib/libltdl.so.3...done. Loaded symbols for /usr/lib/libltdl.so.3 Reading symbols from /lib/libdl.so.2...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /usr/lib/libwrap.so.0...done. Loaded symbols for /usr/lib/libwrap.so.0 Reading symbols from /lib/libpthread.so.0...done. [Thread debugging using libthread_db enabled] [New Thread -1208633664 (LWP 15790)] [New Thread -1210299504 (LWP 15804)] Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /usr/lib/libcrypt.so.1...done. Loaded symbols for /usr/lib/libcrypt.so.1 Reading symbols from /usr/lib/libgssapi_krb5.so.2...done. Loaded symbols for /usr/lib/libgssapi_krb5.so.2 Reading symbols from /usr/lib/libkrb5.so.3...done. Loaded symbols for /usr/lib/libkrb5.so.3 Reading symbols from /lib/libcom_err.so.2...done. Loaded symbols for /lib/libcom_err.so.2 Reading symbols from /usr/lib/libk5crypto.so.3...done. Loaded symbols for /usr/lib/libk5crypto.so.3 Reading symbols from /usr/lib/libz.so.1...done. Loaded symbols for /usr/lib/libz.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /lib/libnsl.so.1...done. Loaded symbols for /lib/libnsl.so.1 Reading symbols from /usr/lib/libkrb5support.so.0...done. Loaded symbols for /usr/lib/libkrb5support.so.0 Reading symbols from /usr/lib/sasl2/libanonymous.so.2...done. Loaded symbols for /usr/lib/sasl2/libanonymous.so.2 Reading symbols from /usr/lib/sasl2/libsasldb.so.2...done. Loaded symbols for /usr/lib/sasl2/libsasldb.so.2 Reading symbols from /usr/lib/sasl2/libcrammd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libcrammd5.so.2 Reading symbols from /usr/lib/sasl2/libdigestmd5.so.2...done. Loaded symbols for /usr/lib/sasl2/libdigestmd5.so.2 Reading symbols from /usr/lib/sasl2/liblogin.so.2...done. Loaded symbols for /usr/lib/sasl2/liblogin.so.2 Reading symbols from /usr/lib/sasl2/libplain.so.2...done. Loaded symbols for /usr/lib/sasl2/libplain.so.2 Reading symbols from /usr/lib/sasl2/libntlm.so.2...done. Loaded symbols for /usr/lib/sasl2/libntlm.so.2 Reading symbols from /usr/lib/sasl2/libgssapiv2.so.2...done. Loaded symbols for /usr/lib/sasl2/libgssapiv2.so.2 0x007de402 in __kernel_vsyscall () (gdb) n Single stepping until exit from function __kernel_vsyscall, which has no line number information. [Switching to Thread -1208633664 (LWP 15790)] 0x008554b7 in pthread_join () from /lib/libpthread.so.0 (gdb) n Single stepping until exit from function pthread_join, which has no line number information. [New Thread -1220789360 (LWP 15865)] [New Thread -1231279216 (LWP 15873)] Error while mapping shared library sections: ../../../servers/slapd/overlays/.libs/syncprov-2-devel.so.0: No such file or directory. Error while reading shared library symbols: ../../../servers/slapd/overlays/.libs/syncprov-2-devel.so.0: No such file or directory. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1220789360 (LWP 15865)] 0x080c12ed in syncrepl_del_nonpresent (op=0xb73c2ec8, si=0x81ecdb0, uuids=0x0, cookiecsn=0x81eca98) at syncrepl.c:2225 2225 csn = si->si_syncCookie.ctxcsn[0]; (gdb) bt #0 0x080c12ed in syncrepl_del_nonpresent (op=0xb73c2ec8, si=0x81ecdb0, uuids=0x0, cookiecsn=0x81eca98) at syncrepl.c:2225 #1 0x080c7028 in do_syncrep2 (op=0xb73c2ec8, si=0x81ecdb0) at syncrepl.c:818 #2 0x080c961c in do_syncrepl (ctx=0xb73c3238, arg=0x81ecf90) at syncrepl.c:1107 #3 0x00d3cf00 in ldap_int_thread_pool_wrapper (xpool=0x81cc150) at tpool.c:704 #4 0x008543db in start_thread () from /lib/libpthread.so.0 #5 0x005bf26e in clone () from /lib/libc.so.6 (gdb) p si->si_syncCookie $1 = {ctxcsn = 0x0, octet_str = {bv_len = 7, bv_val = 0x81f8d90 "rid=001"}, rid = 1, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} (gdb) frame 1 #1 0x080c7028 in do_syncrep2 (op=0xb73c2ec8, si=0x81ecdb0) at syncrepl.c:818 818 syncrepl_del_nonpresent( op, si, NULL, (gdb) p syncCookie $4 = {ctxcsn = 0x81eca90, octet_str = {bv_len = 52, bv_val = 0x81fa810 "rid=001,csn=20070206232910.544649Z#000000#000#000000"}, rid = 1, sid = -1, numcsns = 1, sids = 0x81eca50, sc_next = {stqe_next = 0x0}} (gdb) p syncCookie{ A syntax error in expression, near `{'. (gdb) print syncCookie_req $5 = {ctxcsn = 0x0, octet_str = {bv_len = 7, bv_val = 0x81f8da0 "rid=001"}, rid = 1, sid = 0, numcsns = 0, sids = 0x0, sc_next = {stqe_next = 0x0}} (gdb) p m $6 = 1 Thanks. -- 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/

1 0

Re: (ITS#4832) Segmentation fault with test049-sync-config
by hyc＠symas.com 06 Feb '07

06 Feb '07

ghenry(a)suretecsystems.com wrote: > Full_Name: Gavin Henry > Version: HEAD > OS: Fedora Core 6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (212.159.59.85) > > >>>>>> Starting test049-sync-config ... > running defines.sh > Starting producer slapd on TCP/IP port 9011... > Using ldapsearch to check that producer slapd is running... > Inserting syncprov overlay on producer... > Starting consumer slapd on TCP/IP port 9012... > Using ldapsearch to check that consumer slapd is running... > Configuring syncrepl on consumer... > ./scripts/test049-sync-config: line 164: 28156 Segmentation fault $SLAPD -F > ./slapd.d -h $URI2 -d $LVL $TIMING >../$LOG2 2>&1 (wd: > /src/openldap-devel/tests/testrun/con) > Waiting 10 seconds for syncrepl to receive changes.. > > Logs at: > > http://www.perl.me.uk/test49/slapd.1.log > http://www.perl.me.uk/test49/slapd.2.log > http://www.perl.me.uk/test49/test.out We also need a stack trace from the crash. Set your coresize to unlimited so that crashes will generate a core file. -- -- 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/

1 0

(ITS#4832) Segmentation fault with test049-sync-config
by ghenry＠suretecsystems.com 06 Feb '07

06 Feb '07

Full_Name: Gavin Henry Version: HEAD OS: Fedora Core 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) >>>>> Starting test049-sync-config ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... Starting consumer slapd on TCP/IP port 9012... Using ldapsearch to check that consumer slapd is running... Configuring syncrepl on consumer... ./scripts/test049-sync-config: line 164: 28156 Segmentation fault $SLAPD -F ./slapd.d -h $URI2 -d $LVL $TIMING >../$LOG2 2>&1 (wd: /src/openldap-devel/tests/testrun/con) Waiting 10 seconds for syncrepl to receive changes.. Logs at: http://www.perl.me.uk/test49/slapd.1.log http://www.perl.me.uk/test49/slapd.2.log http://www.perl.me.uk/test49/test.out Was trying to test test050, but died on 049. Is it possible to just run this test? I can't seem to figure out how, without doing a "make test" again. Gavin.

1 0

Re: (ITS#4626) "glue" objectclass in syncrepl consumer
by hyc＠symas.com 05 Feb '07

05 Feb '07

ahasenack(a)terra.com.br wrote: > On Fri, Sep 22, 2006 at 07:48:33PM +0000, hyc(a)symas.com wrote: >> Yes, this makes sense. >> >> Since all of the CSNs under ou=global are greater than any CSN under >> dc=example,dc=com, none of those entries are sent. In server B your >> consumer should be configured on dc=example,dc=com, with a searchbase of >> ou=global,dc=example,dc=com. That will allow the server B provider to >> stay in sync with its consumer. > > With this change, the replication is better, but the B server cannot be > written to anymore: moving the syncrepl directive to the > dc=example,dc=com database makes it read-only because it is then > considered a consumer. This portion of your report is the same as ITS#4623. The fix for ITS#4623 is in HEAD and probably will only be in 2.4. The other part of the problem, where objects get turned into glue objects, is fixed by ITS#4813. This fix is in RE23 and will be in 2.3.34. I'm closing this ITS, you can followup to #4623 or #4813 if you need to make any further comments. -- -- 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/

1 0

Re: (ITS#4623) syncprov and glued databases: findbase failed
by hyc＠symas.com 05 Feb '07

05 Feb '07

ahasenack(a)terra.com.br wrote: > Full_Name: Andreas Hasenack > Version: REL_ENG_2_3 (2.3.24+) > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (200.140.247.99) > > > I have a provider with two databases glued together: > dc=example,dc=com > ou=global,dc=example,dc=com > > One consumer has the syncrepl base search pointing to ou=global on the > provider. > The slapd.conf(5) manpage says that in this scenario, one should load the > overlays at the provider in this order: > > overlay glue > overlay syncprov > > If my provider config is as follows, however, I get a "findbase failed! 32" > error at the provider: The docs were wrong in this case; the required hooks for the overlay support here were not implemented. These hooks have been added to CVS HEAD and this configuration works correctly there. The changes will be part of 2.4. I don't think they'll be backported for 2.3. > I was under the impression (caused by the slapd.conf(5) manpage) that one should > only need to load the syncprov overlay once, right after glue, and it would > attend to both databases. But if I do that, then I get the error I mentioned > above when attempting to replicate the subordinate database. Right, that was the intent, but because of the missing hooks, it couldn't work. -- -- 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/

1 0

Re: (ITS#4656) Enhancement: again on Netscape style changelog
by sebastian.rieger＠gwdg.de 05 Feb '07

05 Feb '07

This is a multi-part message in MIME format. ------=_NextPart_000_0018_01C7492A.5D6431D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Great work! I submitted a patch to update the old overlay of Neil Dunbar = to OpenLDAP 2.3. It works for our identity management (using Novell IDM = 3.01) - see ITS#4685. As my patch needs cleanup to get into OpenLDAP HEAD I = would like to ask, wether this patch (ITS#4656) is likely to be accepted in = the near future. In this case I won't maintain a separate overlay. But it doesn't seem to be in HEAD, for now? -- MfG Sebastian Rieger Gesellschaft f=FCr wissenschaftliche Datenverarbeitung mbH G=F6ttingen=20 Am Fassberg - 37077 G=F6ttingen Fon: +49 551 201 1878 -- Fax: +49 551 201 2150 Die digitale Unterschrift dieser Mail kann anhand des Zertifikats des = DFN =FCberpr=FCft werden: = https://ca.gwdg.de/certs/root-classic/root-ca-cert.der ------=_NextPart_000_0018_01C7492A.5D6431D0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXujCCBHUw ggNdoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1W ZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNVBAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMg LSBHMDEwHhcNMDUwMjI4MDAyOTM3WhcNMTMwNDI4MDAyOTM3WjBbMQswCQYDVQQGEwJERTETMBEG A1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQ Q0EgQ2xhc3NpYyAtIEcwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAOvNTUXjQCVx w87yo/67c+J0bhhl6sfVNVO87Jk2WMY/lPC/E1cmq6iOAe2fV10FhexSG2zIp8XqbrlPNN7s3sy/ 0jUQfHegDqWWuCDQfWLkdWHTiDhIfhcCTdLaXDRshAxE18zDJzKPu3EMeU/N5dju7/azQVi2wkzM fM9I5aARVcrYVH+OanfQo1+yCoQupE9XaGpZRCr2w1X6pf1v0JcqakuC/LBX9uk0IPtMz9Y6frOP AvCldCn8pWNdQrT6VPmJpI7zDCm6/PCAZy82cImzkfbxGpMVxNBxC3Zwgc4zT9Cn22e0Hms8Q3cm cr8hbFb3icuGnMGKp50e9L2eOokCAwEAAaOCAUIwggE+MB0GA1UdDgQWBBSDrjvMk+EkUnrpIE+D cKIq3XsvATAfBgNVHSMEGDAWgBSDrjvMk+EkUnrpIE+DcKIq3XsvATAPBgNVHRMBAf8EBTADAQH/ MIHHBgNVHR8Egb8wgbwwXKBaoFiGVmh0dHA6Ly9jZHAxLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0 aWZpY2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMFygWqBY hlZodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2Rmbi1wa2kvY2VydGlmaWNhdGlvbi94NTA5L2NsYXNz aWMvZzEvZGF0YS9jcmxzL3Jvb3QtY2EtY3JsLmNybDAOBgNVHQ8BAf8EBAMCAQYwEQYJYIZIAYb4 QgEBBAQDAgAHMA0GCSqGSIb3DQEBBQUAA4IBAQDaFaWOgZRQO/CaU+xUQPj3mgnJ5MJug0ad1d+L k+K1iTUp8r9fLxnamypzVeVrHFbtC5zk9lxx8qDMiDc6sd9HYRJNikJUme/EfHPkzlbn6hTXuL6+ ZKdCeK3qQHnltEjg/NLUIaU/bukFmhOk6NrnU5XNTKcEeOJ47t0K2EWWZ6rN3Ji0FU444hGO73tl C5t1ACWaMYFakmylmagwdZPIVnA3qKFmVRTPcz3Cel56UyA2U6n9qQR8zZzkltIwx2/6SHt2EqQN u3g6iDyOWzIfsb0bRVHmvHQx3KCUZb5JNy3iue8yIB6WMbKZ+eJuwZl1Q0PJ87BjsHYglO3JX+Oy MIIFhjCCBG6gAwIBAgIEBnsYQDANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJERTETMBEGA1UE ChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTElMCMGA1UEAxMcREZOLVZlcmVpbiBQQ0Eg Q2xhc3NpYyAtIEcwMTAeFw0wNTA0MTIwOTUzNTRaFw0wOTA0MTIwOTUzNTRaMIGcMQswCQYDVQQG EwJERTFCMEAGA1UEChM5R2VzZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52 ZXJhcmJlaXR1bmcgbWJIMQswCQYDVQQLEwJDQTEcMBoGA1UEAxMTR1dERy1DQSBFYmVuZSAxIEcw MjEeMBwGCSqGSIb3DQEJARYPZ3dkZy1jYUBnd2RnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA3y/2S6yGKZhpv+DwWTSH4/szbEB2yPEJUgZz5kaVId/17wKdRNKd9el03skx/ind 1IJ27YaoOybmRp5pwuNSAL7SEC2neEKcLCqkV+jDcLusV2mQ/ykgMs7No5csyhS6FxuUwBK18BlF E7tfraK3J6iyOJxzjFKB+3/ZWhasXnwEtzOUc5hRry9bTNYpyLueUa5DLR5nqIRwk1OWbx3IARbC RKrxdAupzwEAjWwz8ar2aDHgsBH41D7sfDY9wRxH04sW6K9D0BANEx+o8KhbsPQv6l0HQE7p0n6Y XQhUo5QhZ8GMfEiIh39sE1turDLut7I4bCZwrIjPT9gJqhFMWwIDAQABo4ICDjCCAgowHQYDVR0O BBYEFPP+0UOeITsrZQ3Y8arSBsKbVgajMB8GA1UdIwQYMBaAFIOuO8yT4SRSeukgT4Nwoirdey8B MA8GA1UdEwEB/wQFMAMBAf8wgccGA1UdHwSBvzCBvDBcoFqgWIZWaHR0cDovL2NkcDEucGNhLmRm bi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY3Jscy9yb290 LWNhLWNybC5jcmwwXKBaoFiGVmh0dHA6Ly9jZHAyLnBjYS5kZm4uZGUvZGZuLXBraS9jZXJ0aWZp Y2F0aW9uL3g1MDkvY2xhc3NpYy9nMS9kYXRhL2NybHMvcm9vdC1jYS1jcmwuY3JsMIHcBggrBgEF BQcBAQSBzzCBzDBkBggrBgEFBQcwAoZYaHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZm4tcGtpL2Nl cnRpZmljYXRpb24veDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDBk BggrBgEFBQcwAoZYaHR0cDovL2NkcDIucGNhLmRmbi5kZS9kZm4tcGtpL2NlcnRpZmljYXRpb24v eDUwOS9jbGFzc2ljL2cxL2RhdGEvY2VydHMvcm9vdC1jYS1jZXJ0LmNydDAOBgNVHQ8BAf8EBAMC AQYwDQYJKoZIhvcNAQEFBQADggEBADFx3Ji676DYFd/XIY9KcsNopLqtgF5Ixr2irPOPpZ/X/zta Gss3l18EdKCCBFqhwCrd2lFOfowbxnWZ1L+WRS/+0x4a8MZoAUWyfk+pLLgv3OucY4ZhAGP5F0XJ wLRlskcnLVvt3HFQ9JsEjHo45u/QiKbZJGFPVZb5elpphRtAVTiRisw5UTiV57m07vcJhUtrt6wh 7389cz2aYYdlViMZtuaE0Z+LlSElAe4/U6tOowoR+06qDjjFNLjQ1P3fnmBPRo2zWidaLiZcfD3f qjxBgJolgeS+gS3YePj2M6NAUTu+1XKAbrFJUyrCI+qPkEcVq3yK6FkZbbhla+BKQrcwggZUMIIF PKADAgECAgou6MIgAAAAAASaMA0GCSqGSIb3DQEBBQUAMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEVi ZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFm dCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMC REUxCjAIBgNVBAUTATIwHhcNMDYxMTA5MTMzNDU3WhcNMDcwOTIwMTA1ODAwWjCBvjELMAkGA1UE BhMCREUxFjAUBgNVBAgTDU5pZWRlcnNhY2hzZW4xEzARBgNVBAcTCkdvZXR0aW5nZW4xPjA8BgNV BAoTNUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5n MRkwFwYDVQQDExBTZWJhc3RpYW4gUmllZ2VyMScwJQYJKoZIhvcNAQkBFhhzZWJhc3RpYW4ucmll Z2VyQGd3ZGcuZGUwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN+JMyvFWWLIl0gDV5t9edUF qJCNFHH/aDm40I6MZLkYZ6eyLpRVmvIQ1+KBLP8Qjagiz1HwEqwMBDNPABq50yYCHpLmKFy+BCEH r4Cjoz2AhSm4BqUhjy/XnFOqeAReo9MJfrJeslCPbfaqVV7APQl4VqALnxnDJl/1PJ4++CiLAgMB AAGjggL9MIIC+TALBgNVHQ8EBAMCBaAwNgYJKoZIhvcNAQkPBCkwJzANBggqhkiG9w0DAgIBODAN BggqhkiG9w0DBAIBODAHBgUrDgMCBzApBgNVHSUEIjAgBggrBgEFBQcDAgYIKwYBBQUHAwQGCisG AQQBgjcKAwQwHQYDVR0OBBYEFMxqWUeIRKOu1OVQe7WDZwKzQJlGMB8GA1UdIwQYMBaAFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGvBgNVHR8EgacwgaQwgaGggZ6ggZuGTmh0dHA6Ly91c2VyLWNhLmd3 ZGcuZGUvQ2VydEVucm9sbC9HV0RHLUNBJTIwRWJlbmUlMjAyJTIwR2VuZXJpYy1DQSUyMEcwMi4x LmNybIZJaHR0cDovL3BjYS5nd2RnLmRlL2NybC9nd2RnLWNhL2ViZW5lMi9nMDIuMS9nd2RnLWNh LWViZW5lMi1nZW5lcmljLWNhLmNybDCB0wYIKwYBBQUHAQEEgcYwgcMwagYIKwYBBQUHMAGGXmh0 dHA6Ly91c2VyLWNhLmd3ZGcuZGUvQ2VydEVucm9sbC91c2VyLWNhLmd3ZGcuZGVfR1dERy1DQSUy MEViZW5lJTIwMiUyMEdlbmVyaWMtQ0ElMjBHMDIuMS5jcnQwVQYIKwYBBQUHMAGGSWh0dHA6Ly9w Y2EuZ3dkZy5kZS9jcmwvZ3dkZy1jYS9lYmVuZTIvZzAyLjEvZ3dkZy1jYS1lYmVuZTItZ2VuZXJp Yy1jYS5jcnQwPAYJKwYBBAGCNxUHBC8wLQYlKwYBBAGCNxUIhZ2OO4GrnU+tkQWF84sDhK7MIS2H kIMrg8myPwIBZAIBAzBKBgNVHSAEQzBBMD8GCysGAQQBgZ1IMgEBMDAwLgYIKwYBBQUHAgEWImh0 dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG0wNQYJKwYBBAGCNxUKBCgwJjAKBggrBgEF BQcDAjAKBggrBgEFBQcDBDAMBgorBgEEAYI3CgMEMA0GCSqGSIb3DQEBBQUAA4IBAQCASq3lwDZ/ o7RuoZxqmuGCZPKlVuoBsQGaNJnoGUMBoq/7UBHRym4EpMuB8wf+NxPxhcSOxUR3UwDKE3p0VnVE O//hD6CFwbed83Wn6nv4O4jHJDxTAs0JJGomtrNxFxa5NwSUHq8ujf0DSr2Zn+yq8KzmNVjuANNe sbxvtvO3rr8pLh66m4QsgvOtGZpDeeJRpJM8eN9hf9HcIrtnCNP/KN8HGESiozUB0h0ZasH9yTQZ f/K0VCTTttPnXg3cF+g+bWMc0gGQzR40oVzTt4ggC0G68gRh2yTlQxRjMxZBS7vkWBGhEYoJoLHE TQv5oNafPL4UZGIW4SjLjWiR5mUZMIIHWzCCBkOgAwIBAgIBAjANBgkqhkiG9w0BAQUFADCBnDEL MAkGA1UEBhMCREUxQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hl IERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UECxMCQ0ExHDAaBgNVBAMTE0dXREctQ0EgRWJl bmUgMSBHMDIxHjAcBgkqhkiG9w0BCQEWD2d3ZGctY2FAZ3dkZy5kZTAeFw0wNTA5MjAxMDU4MDBa Fw0wNzA5MjAxMDU4MDBaMIGVMSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBH MDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFm dGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATIwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC62IidFd5KC11HewNoQh8DG8jcJI1fdNIf/ETt d4vOMZRRQG5+WhETBhH0d6pXjZ+V8dhlMiekFq2RpFYPictQFnEt5M49iGfX6V3PIKkaFtFTIZj0 QbGN7BWTpcCfTw6L9VwPA3olG1QYABl16Ea9mHT6nGfvwYyiadnzHCAI1XTFeF1UzOKM8EemZvGa oQncG8QUt1uqskfcLJ18ASM6GY/C108p0E9hUx2V24BQDdLdCUB6BzcW/SQdBqjRaW51mPPMxn/p bqXWrgUwkiYJOqkDY6qVUtvKGCZIumQdKxnoSB5X7tna2widH50xNX5VdMe/qnYZPLuEnbzrkOo5 AgMBAAGjggOrMIIDpzAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjBuBglghkgBhvhCAQ0E YRZfU3Vib3JkaW5hdGUgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHZXNlbGxzY2hhZnQgZnVl ciB3aXNzZW5zY2hhZnRsaWNoZSBEYXRlbnZlcmFyYmVpdHVuZyBtYkgwHQYDVR0OBBYEFENS2L3V sDi5Z+Q7/gMbGR0jhO5IMIGGBgNVHSMEfzB9gBTz/tFDniE7K2UN2PGq0gbCm1YGo6FfpF0wWzEL MAkGA1UEBhMCREUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJTAjBgNV BAMTHERGTi1WZXJlaW4gUENBIENsYXNzaWMgLSBHMDGCBAZ7GEAwGgYDVR0RBBMwEYEPZ3dkZy1j YUBnd2RnLmRlMAkGA1UdEgQCMAAwQgYJYIZIAYb4QgEEBDUWM2h0dHA6Ly9jYS5nd2RnLmRlL2Ny bC9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNybDBCBglghkgBhvhCAQMENRYzaHR0cDovL2Nh Lmd3ZGcuZGUvY3JsL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3JsMIGABgNVHR8EeTB3MDmg N6A1hjNodHRwOi8vY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5jcmww OqA4oDaGNGh0dHA6Ly9wY2EuZ3dkZy5kZS9jcmwvZWJlbmUxL2cwMi9nd2RnLWNhLWViZW5lMS5j cmwwgZcGCCsGAQUFBwEBBIGKMIGHMEEGCCsGAQUFBzAChjVodHRwOi8vY2EuZ3dkZy5kZS9jZXJ0 cy9lYmVuZTEvZzAyL2d3ZGctY2EtZWJlbmUxLmNydDBCBggrBgEFBQcwAoY2aHR0cDovL3BjYS5n d2RnLmRlL2NlcnRzL2ViZW5lMS9nMDIvZ3dkZy1jYS1lYmVuZTEuY3J0MCAGCWCGSAGG+EIBAgQT FhFodHRwOi8vY2EuZ3dkZy5kZTAyBglghkgBhvhCAQgEJRYjaHR0cDovL2NhLmd3ZGcuZGUvcG9s aWN5L2luZGV4Lmh0bWwwTQYDVR0gBEYwRDBCBg0rBgEEAYGdSDIBAwEBMDEwLwYIKwYBBQUHAgEW I2h0dHA6Ly9jYS5nd2RnLmRlL3BvbGljeS9pbmRleC5odG1sMA0GCSqGSIb3DQEBBQUAA4IBAQBj KNeFKWGSWFjcy1fR1UHC5+MdmiTUfzHVeRbLuoGOTkbjYEbjE3+FNhGgRJJwKoDU1jQXLGGBzLQT dZcZj3QO0926SpshKNmW0zVIwf9gbAzFZ17Zgfns/BenJ7hTRl4m5aHTodkmJSKNvqwWOCFTTX9H RYRiSuDC10QYRH6S7MqyZ5Gkhtdq9iLVik8Q2RIS7OIoJgYUkLOG+tZ1rtQmWb3U6p/WwF4t5CAp ErqoJ1f427lLOj0EPOsXJUcwf+km6kkcIrKopv63HTWw7HmQHLGXajf5KbZXumwcG0Z2RCZN4OE2 yfQgRi8wmhj3pSKE4ylcz7Y9ExWdWh5YJAfMMYIDhzCCA4MCAQEwgaQwgZUxKTAnBgNVBAMTIEdX REctQ0EgRWJlbmUgMiBHZW5lcmljLUNBIEcwMi4xMQswCQYDVQQLEwJjYTFCMEAGA1UEChM5R2Vz ZWxsc2NoYWZ0IGZ1ZXIgd2lzc2Vuc2NoYWZ0bGljaGUgRGF0ZW52ZXJhcmJlaXR1bmcgbWJIMQsw CQYDVQQGEwJERTEKMAgGA1UEBRMBMgIKLujCIAAAAAAEmjAJBgUrDgMCGgUAoIICODAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wNzAyMDUxMjM0MzBaMCMGCSqGSIb3 DQEJBDEWBBRzZWbcdY18vGBBk12AP1Flv0chJTBnBgkqhkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMH MA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDAH BgUrDgMCGjAKBggqhkiG9w0CBTCBtQYJKwYBBAGCNxAEMYGnMIGkMIGVMSkwJwYDVQQDEyBHV0RH LUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2ExQjBABgNVBAoTOUdlc2Vs bHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJiZWl0dW5nIG1iSDELMAkG A1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowgbcGCyqGSIb3DQEJEAILMYGnoIGkMIGV MSkwJwYDVQQDEyBHV0RHLUNBIEViZW5lIDIgR2VuZXJpYy1DQSBHMDIuMTELMAkGA1UECxMCY2Ex QjBABgNVBAoTOUdlc2VsbHNjaGFmdCBmdWVyIHdpc3NlbnNjaGFmdGxpY2hlIERhdGVudmVyYXJi ZWl0dW5nIG1iSDELMAkGA1UEBhMCREUxCjAIBgNVBAUTATICCi7owiAAAAAABJowDQYJKoZIhvcN AQEBBQAEgYBDAP54LC4wafAmgrYjD6sC+pMKai6fgCmLMrECkBQXB9rlGKryTaDSPUzh3SGrY+/h V08OQW2Il+H1y8GqqQz4U4VvMauOiLR5i7HrDFcRPYQsJ5tS2dpgYwvtHKrjwOl3mM5kOP2UnAMG G7AbGU4201tBu44H9EbaWLA/jfgIdgAAAAAAAA== ------=_NextPart_000_0018_01C7492A.5D6431D0--

1 0

Re: (ITS#4831) dynlist returns bad data
by ando＠sys-net.it 03 Feb '07

03 Feb '07

quanah(a)stanford.edu wrote: > > --On Friday, February 02, 2007 8:26 PM +0000 quanah(a)stanford.edu wrote: > >> Full_Name: Quanah Gibson-Mount >> Version: 2.3.33 >> OS: Linux 2.6 (64-bit) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (171.64.19.81) >> >> >> In doing a base query of a dynamic group I had created, I found that the >> information returned when using the dynlist overlay is bogus. > > And what I expected to see was something more along the lines of: > > dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu > objectClass: groupOfURLs > cn: registry-consult > memberURL: > ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=value:value2) One of the distinguishing features of the dynlist overlay is that it can actually __create__ a dynamic view of the listed data by collecting all values of all attributes (honoring few constraints, like all additional values of single-valued attributes get discarded; I believe in HEAD code it also avoids merging other structural objectClasses unless they fit into the hierarchy of the current structuralObjectClass). To limit this, you can use the <attrs> field of the URL, so that only the listed attrs are actually merged. Or, if you want it to behave exactly like a group, you should configure it with the <member-ad> field: dynlist-attrset <group-oc> <URL-ad> [<member-ad>] The value <group-oc> is the name of the objectClass that trig- gers the dynamic expansion of the data. The value <URL-ad> is the name of the attributeDescription that cointains the URI that is expanded by the overlay; if none is present, no expansion occurs. If the intersection of the attributes requested by the search operation (or the asserted attribute for compares) and the attributes listed in the URI is empty, no expansion occurs for that specific URI. It must be a subtype of labeledURI. The value <member-ad> is optional; if present, the overlay behaves as a dynamic group: this attribute will list the DN of the entries resulting from the internal search. In this case, the <attrs> portion of the URI must be absent, and the DNs of all the entries resulting from the expansion of the URI are listed as values of this attribute. Compares that assert the value of the <member-ad> attribute of entries with <group-oc> objectClass apply as if the DN of the entries resulting from the expansion of the URI were present in the <group-oc> entry as values of the <member-ad> attribute. To see what you expect, you need to add the manageDSAit control (I believe this is undocumented; I'll fix it in a moment). 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 ------------------------------------------

1 0

Re: (ITS#4831) dynlist returns bad data
by quanah＠stanford.edu 02 Feb '07

02 Feb '07

--On Friday, February 02, 2007 8:26 PM +0000 quanah(a)stanford.edu wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.3.33 > OS: Linux 2.6 (64-bit) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.64.19.81) > > > In doing a base query of a dynamic group I had created, I found that the > information returned when using the dynlist overlay is bogus. And what I expected to see was something more along the lines of: dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu objectClass: groupOfURLs cn: registry-consult memberURL: ldap:///cn=people,dc=stanford,dc=edu??sub?(suprivilegegroup=value:value2) --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4831) dynlist returns bad data
by quanah＠stanford.edu 02 Feb '07

02 Feb '07

Full_Name: Quanah Gibson-Mount Version: 2.3.33 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In doing a base query of a dynamic group I had created, I found that the information returned when using the dynlist overlay is bogus. ldapsearch -LLL -Q -h ldap-dev1 -s base -b "cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu" | more was the query run. It returns: dn: cn=registry-consult,cn=groups,cn=applications,dc=stanford,dc=edu objectClass: groupOfURLs objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: suPerson cn: registry-consult cn: member A's cn cn: member B's cn ..... description: member A's description description: member B's description ...... displayName: member A's displayName givenName: member A's givenName givenName: member B's givenName .... etc, for every populated attribute in the *objects of the members*. This seems horribly broken to me. Note that this is an unmodified version of dynlist (pure 2.3.33) --Quanah

1 0

(ITS#4830) test030-relay fails with back-meta
by ahasenack＠terra.com.br 02 Feb '07

02 Feb '07

Full_Name: Andreas Hasenack Version: 2.3.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (200.140.247.99) Hello, while running make test on a 2.3.33 build, I get an error in test030-relay when using the meta backend: (...) Using meta backend... Starting slapd on TCP/IP port 9011... Using ldapsearch to check that slapd is running... Using ldapadd to populate the database... Searching base="dc=example,dc=com"... Searching base="o=Example,c=US"... Search failed (255)! ./scripts/relay: line 78: kill: (31577) - Processo inexistente >>>>> ./scripts/test030-relay failed (exit 255) make: ** [bdb-yes] Erro 255 The log shows: $ tail testrun/slapd.1.log conn=3 op=1 >>> meta_search_dobind_init[0] conn=3 op=1 <<< meta_search_dobind_init[0]=1 ==> rewrite_context_apply [depth=1] string='o=Example,c=US' ==> rewrite_rule_apply rule='((.+),)?o=Example,[ ]?c=US$' string='o=Example,c=US' [1 pass(es)] ==> rewrite_context_apply [depth=1] res={0,'dc=example,dc=com'} [rw] searchBase: "o=Example,c=US" -> "dc=example,dc=com" ==> rewrite_context_apply [depth=1] string='(objectClass=*)' ==> rewrite_context_apply [depth=1] res={0,'NULL'} [rw] searchFilter: "(objectClass=*)" -> "(objectClass=*)" /home/andreas/updates-svn/openldap/BUILD/openldap-2.3.33/servers/slapd/.libs/lt-slapd: symbol lookup error: +../servers/slapd/back-meta/.libs/back_meta-2.3.so.0: undefined symbol: ldap_back_proxy_authz_ctrl

1 0

(ITS#4829) slapd-config should create olcDbDirectory
by ghenry＠suretecsystems.com 02 Feb '07

02 Feb '07

Full_Name: Gavin Henry Version: N/A OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.159.59.85) Dear All, If we are to suppose that slapd-config is to provide 100% remote configuration, then directories should be created as set in: olcDbDirectory set_lg_dir Questions/Needs: 1. How to handle existing directories on mkdir? 2. Some global cn=config setting to say what cn=config is allowed to do 3. Plus many more I'm sure. 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/

1 0

syncrepl only works as rootdn
by Christopher Cowart 02 Feb '07

02 Feb '07

Hello, I have 3 installations of openldap-server-2.3.33 running on FreeBSD 6.1-REL: ldap-master, ldap1, ldap2. I am using syncrepl to replicate ldap-master to ldap1 and ldap2. The replicated directory is missing entire ou branches in my tree. I have created the following objects in my directory: cn=syncrepl-ldap1,dc=example,dc=com cn=syncrepl-ldap2,dc=example,dc=com I've made the following configurations on the provider: | access to * | by dn.regex="cn=syncrepl-(ldap1|ldap2),dc=example,dc=com" read | by * break | | # More ACLs Follow | | # For Sync Replication | overlay syncprov | syncprov-checkpoint 100 10 | syncprov-sessionlog 100 And on the consumer (ldap1): | # Sync Replication | syncrepl rid=001 | provider=ldaps://ldap-master.example.com/ | type=refreshAndPersist | interval=00:01:00:00 | searchbase="dc=example,dc=com" | scope=sub | schemachecking=off | bindmethod=simple | binddn="cn=syncrepl-ldap1,dc=example,dc=com" | credentials=supersecret Now, when I query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap1.example.com/' '(ou=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services You'll notice that the "System Accounts" and "System Groups" ou's are not visible in the replicated directory. Odd. Next, I run the query: $ ldapsearch -D 'cn=admin,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services | ou: System Accounts | ou: System Groups But the syncrepl process is binding as "cn=syncrepl-ldap1": $ ldapsearch -D 'cn=syncrepl-ldap1,dc=example,dc=com' -Wx -H \ 'ldaps://ldap-master.example.com/' '(objectClass=*)' ou | grep '^ou' | ou: People | ou: Roaming | ou: Group | ou: Reshall People | ou: Reshall Group | ou: Services So, if I configure the consumer to bind as my rootdn (cn=admin), the entire directory gets replicated (as the final ldapsearch's would imply). My question is how do I properly configure the ACLs here? Shouldn't the 'read *' at the beginning of my ACL declarations match? I'm attaching the full list of my ACLs to the message. Thanks for any help or pointers you can offer. -- Chris Cowart Network and Infrastructure Systems Administrator RSSP-IT, UC Berkeley "May all your pushes be popped"

2 1

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > hyc(a)symas.com wrote: >> Howard Chu wrote: >>> michael.stroeder(a)t-systems.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD >>>> OS: opensuse Linux 10.2 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.124.17.145) >>> Hmm, all tests are passing for me right now. >>> >> Never mind. I just refreshed back-ldap and back-meta and test032 is failing >> for me now too. > > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Looks fine now, 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/

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

ando(a)sys-net.it wrote: > I've recently added some diagnostics messages to proxy failures, to > indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts > to contact the remote target. Apparently, slapo-chain(5) leaves 'round > some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. Fixed in HEAD, please test. BTW, the bug showed up essentially because the output was sort of incorrectly diverted to the file that gets checked. Generally speaking, it might impact re23 as well, although that test is currently succeeding. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by ando＠sys-net.it 01 Feb '07

01 Feb '07

hyc(a)symas.com wrote: > Howard Chu wrote: >> michael.stroeder(a)t-systems.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: opensuse Linux 10.2 >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.124.17.145) >> Hmm, all tests are passing for me right now. >> > Never mind. I just refreshed back-ldap and back-meta and test032 is failing > for me now too. I've recently added some diagnostics messages to proxy failures, to indicate the reason of returning LDAP_UNAVAILABLE upon failed attempts to contact the remote target. Apparently, slapo-chain(5) leaves 'round some sr_text while setting sr_err to LDAP_SUCCESS. I'll check it. p.

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

Howard Chu wrote: > michael.stroeder(a)t-systems.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: opensuse Linux 10.2 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.124.17.145) > > Hmm, all tests are passing for me right now. > Never mind. I just refreshed back-ldap and back-meta and test032 is failing for me now too. -- -- 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/

1 0

Re: (ITS#4828) test032-chain failed: comparison failed - chained search didn't succeed
by hyc＠symas.com 01 Feb '07

01 Feb '07

michael.stroeder(a)t-systems.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: opensuse Linux 10.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.124.17.145) Hmm, all tests are passing for me right now. -- -- 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/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs