- openldap-bugs - openldap.org

(ITS#7700) DOC: OL AdminGuide not updated
by marco.pizzoli＠gmail.com 19 Sep '13

19 Sep '13

Full_Name: Marco Pizzoli Version: ALL OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) I notice that in the online Admin Guide the syncrepl directive is not updated with the recent addition of "keepalive" and "network-timeout" parameters.

1 0

(ITS#7699) Fixed one assertion failure during slapo_dds start-up
by tedcheng＠symas.com 19 Sep '13

19 Sep '13

Full_Name: Ted C. Cheng Version: HEAD OS: Ubuntu 11.10 URL: https://www.dropbox.com/s/kw5df5z1oxm3hw2/slapo_dds_start_up_assertion_fix.… Submission from: (NULL) (172.250.77.154) dds_db_open() did not enumerate dynamic objects before slapo-dds performed expiration check and purging. As a result, the assert(di->di_num_dynamicObjects > 0) at dds_counter_cb() may crash. The proposed resolution is to move dds_count() before dds_expire(). Please review. Thanks,

1 0

AW: (ITS#7655) segfault during initial mirror of multimaster delta replication
by hans.freitag＠entiretec.com 18 Sep '13

18 Sep '13

Hi, unfortunately i was not able to reproduce the exact problem with the segfault, but, after a few updates, we still have the problem that with replication enabled the slapd freezes during a write operation. SETUP DESCRIPTION: Openldap Version 2.4.36 Back-MDB (we have issues for quite a while, even when we where running on bdb) All write and read requests are directed to the active node, so the passive node is replicating. So, if I did not understand something wrong I have two threads: The main thread, and the one which is doing the replication. Netstat of TCP Replication connections, the second is initiated by the passive system polling from the active tcp 0 53 10.169.127.13:389 10.169.126.13:43340 ESTABLISHED tcp 1905336 0 10.169.127.13:52384 10.169.126.13:389 ESTABLISHED top -H of the LDAP Processes: 7767 ldap 20 0 84.4g 7.1g 6.9g S 1 10.1 1:02.13 slapd 7768 ldap 20 0 84.4g 7.1g 6.9g S 0 10.1 7:54.44 slapd 8023 ldap 20 0 84.4g 7.1g 6.9g S 0 10.1 0:32.31 slapd 7766 ldap 20 0 84.4g 7.1g 6.9g S 0 10.1 0:00.00 slapd 7769 ldap 20 0 84.4g 7.1g 6.9g S 0 10.1 0:32.81 slapd 7770 ldap 20 0 84.4g 7.1g 6.9g S 0 10.1 7:44.94 slapd 8024 ldap 20 0 84.4g 7.1g 6.9g t 0 10.1 0:32.53 slapd PASTEBIN: I Pastebinned all the backtraces to: http://pastebin.com/vVGEqEUt I hope this helps to track back the problem. Kind regards - Mit freundlichen Grüßen i.A. Hans Freitag » Linux Administrator ENTIRETEC AG . Pforzheimer Strasse 33 . 01189 Dresden . Germany T: +49.351.41355.0 . M: . F: +49.351.41355.99 E: hans.freitag(a)entiretec.com ENTIRETEC | http://www.entiretec.com Germany | Switzerland | United Arab Emirates | Malaysia | United States of America ENTIRETEC AG Vorstand: Thomas Herrmann (Vorsitzender), Thomas Wetzel, Carsten Klemm . Aufsichtsratsvorsitzende: Dr. Jutta Horezky Sitz der Gesellschaft: Dresden . Amtsgericht Dresden HRB 24915 . USt-IdNr. DE227705033 > -----Ursprüngliche Nachricht----- > Von: openldap-bugs-bounces(a)OpenLDAP.org [mailto:openldap-bugs- > bounces(a)OpenLDAP.org] Im Auftrag von quanah(a)zimbra.com > Gesendet: Montag, 5. August 2013 05:15 > An: openldap-its(a)openldap.org > Betreff: Re: (ITS#7655) segfault during initial mirror of multimaster > delta replication > > --On Sunday, August 04, 2013 4:27 PM +0000 hans.freitag(a)entiretec.com > wrote: > > > Full_Name: Hans Freitag > > Version: 2.4.35 and 33 > > OS: SLES 11SP2 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (193.200.138.3) > > > > > > I have a Multimaster Delta replication setup here with bdb on a 18 GB > > Database. > > > > After a crash due to a full disk I made a new database on one node > ans > > started over. > > > > The empty node started to replicate, from the full one but after a > while > > (approx. 2GB) it crashed with a segfault: > > > > Aug 4 11:45:32 mhr-dd-lda-01 kernel: [52189.476209] slapd[10158]: > > segfault at 20 ip 00007ff97ebfabc0 sp 00007ff6e57e6b38 error 4 in > > libc-2.11.1.so[7ff97eb79000+155000] > > > > So i thought, maybe it is not e good Idea to put in a package for SP2 > in a > > machine running SP1 so my first attempt to solve was an upgrade. > After the > > upgrade I got this: > > > > Aug 4 12:46:29 mhr-dd-lda-01 kernel: [ 1414.757587] slapd[3704]: > > segfault at 20 ip 00007fc82eee6182 sp 00007fc592e0acf0 error 4 in > > slapd[7fc82ee7a000+1e6000] > > > > So I created a brandnew openldap RPM 2.4.35 rpm to try out if the > problem > > is maybe related to the 2.4.33 version I am running. But fail: > > > > Aug 4 13:47:19 mhr-dd-lda-01 kernel: [ 5063.074410] slapd[8749]: > > segfault at 20 ip 00007fcbc1b537dc sp 00007fc92624fb88 error 4 in > > slapd[7fcbc1ac8000+1ea000] > > > > At the moment I deactivated the accesslogging on the node which seems > to > > work. I will know for sure in a few hours. ;-) I can try to reproduce > > that on a backup node next week. Whenn all the main nodes are up and > > running again. :) > > I would suggest you build with debugging symbols, enable core files, > and > provide a backtrace of the problem. What you have provided does not > give > any useful information for debugging purposes. You also fail to state > the > backend you are using (back-bdb or back-hdb). > > For information on how to provide a backtrace: > > <http://www.openldap.org/faq/data/cache/59.html> > > Regards, > Quanah > > -- > > Quanah Gibson-Mount > Lead Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

Re: (ITS#7698) Multiple Paged search requests on one connection fail
by michael＠stroeder.com 17 Sep '13

17 Sep '13

This is a cryptographically signed message in MIME format. --------------ms070508090701020005010904 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable john.unsworth(a)cp.net wrote: > AFAIK it is not the standard LDAP changelog - let me know if I'm wrong.= We > don't want to write specific code for each LDAP server that doesn't con= form > to the LDAP (draft I know) standard. I presume you're referring to [1] as "the standard LDAP changelog". Note that this is an expired informational Internet draft and not a propo= sed standard. Ciao, Michael. [1] https://tools.ietf.org/html/draft-good-ldap-changelog-04 --------------ms070508090701020005010904 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE3MjA0MjUzWjAj BgkqhkiG9w0BCQQxFgQUEAusugl++MhH733peKnCHcb/Nw4wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAq+P94yAbnCHzS4eSmCAnZ9HB/kitBw++ I3EWNu3OZ+bYst3YHAtwjDLZyHZOy7YreSiznixIR73sM6ZFZji1L11chKnoQyhnb48bOFHC Mc3tY7iR15KZc2kzahw33XfvHv4XKuXNKdFqBbqMJdgSoZ6b9WCKp3vJhi0CexuH64WeJ+iX ZUbOAhkZ9AiSLaK9Ra2wHksEXJvmzexPCM8LnEGbUFbUtf5sVp8lJw/gq4FSSdcQt1GHyw3z AioPL4aqaFm7h6/if7qR0AAMV/W4ssrJvnv7gSNyZWS/FeKn16TU61hZZ9Z5ZenKUnarTYuj tgXfQHxjsQlS3f0R78wU9gAAAAAAAA== --------------ms070508090701020005010904--

1 0

Re: (ITS#7698) Multiple Paged search requests on one connection fail
by michael＠stroeder.com 17 Sep '13

17 Sep '13

This is a cryptographically signed message in MIME format. --------------ms080203050507020908040705 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable John Unsworth wrote: > LDAP servers we connect to typically contain > thousands if not millions of entries. Reading the lot without paging - > although we can do it - is very inefficient both in terms of LDAP resou= rces > and application resources. I really wonder why that is inefficient. I'm also developing custom sync software for large data sets. If stream processing is possible you don't = need much resources. If stream processing is not possible paging does not help= either. > In the case of OpenLDAP there is no LDAP changelog and so the only way = we > have of discovering changes is to read the whole directory and compare = with > what was read last time. Use slapo-accesslog which is more powerful than the old changelog data an= yway. Ciao, Michael. --------------ms080203050507020908040705 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE3MjAzNzMzWjAj BgkqhkiG9w0BCQQxFgQUTyl3bIAh895kSiYoIfJPfdrRbiowbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAm42W7q1EMPcgUQ8jMD560Ml8344oCv8m JeaMH+6k1GjWDfqQkX3qPj2gGbqw27JfHs7lEjMqedyXdFcK0LokVzCsRxbjTwseaq4JX0gl llgHDa/fwF1Et+dcCMFaMMeyo+zeNUnLq46iVhrROtGov67iYKqO7/y0O+YSdVR7z9G2amby nqlxCZhK9gr1IlGHe3hXkWiTIR8ud/6jVLYGhiKS2n8ctpltD2EoJslJFA1Vy7FOPF4ecoN7 IbB6egUHRjsNPp1BO294jPnlLLkLeD/CXrCl7RAEhpVDPeY51nnI8p3isUgqcmO0LR6+f+/j nyHAskCnziCmuzD93wWv5gAAAAAAAA== --------------ms080203050507020908040705--

1 0

Re: (ITS#7698) Multiple Paged search requests on one connection fail
by hyc＠symas.com 17 Sep '13

17 Sep '13

quanah(a)zimbra.com wrote: > --On Tuesday, September 17, 2013 7:52 PM +0000 john.unsworth(a)cp.net wrote: > >> AFAIK it is not the standard LDAP changelog - let me know if I'm wrong. We >> don't want to write specific code for each LDAP server that doesn't >> conform to the LDAP (draft I know) standard. > > Please fix your client to stop top-posting. > > With openldap, you have two choices. I don't know which draft you are > referring to, so I can't say if either conforms with what the other > directory servers do. > > slapo-auditlog > slapo-accesslog accesslog conforms to this draft: http://tools.ietf.org/html/draft-chu-ldap-logschema-00 -- -- Howard Chu CTO, 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#7698) Multiple Paged search requests on one connection fail
by hyc＠symas.com 17 Sep '13

17 Sep '13

John Unsworth wrote: >>> There are no other directory servers in existence that can scale to the > level that OpenLDAP does and perform well at that scale. > > How do you justify/prove that statement? Our (Symas) customers tell us which directory server they're migrating from when they come to us. We perform benchmarks periodically as well. Nothing else comes close. Come to LDAPCon this year, we'll be presenting our latest benchmark results then. > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: 17 September 2013 20:52 > To: john.unsworth(a)cp.net; openldap-its(a)openldap.org > Subject: Re: (ITS#7698) Multiple Paged search requests on one connection > fail > > john.unsworth(a)cp.net wrote: >> Products other than browsers use LDAP servers. Our product is a meta >> directory that watches for changes on multiple data sources (LDAP, >> Databases, SAP, ...) and reconciles any changes across the complete >> set of sources according to data filtering and transformation rules. >> However sometimes it is necessary to read the whole data set - for >> example when a new data server is added, or when changes may have been >> missed for any reason, or when an 'audit' type operation is required >> to ensure that all data sources are consistent. LDAP servers we >> connect to typically contain thousands if not millions of entries. > > OpenLDAP is regularly used in production by large telcos with billions of > entries. There are no other directory servers in existence that can scale to > the level that OpenLDAP does and perform well at that scale. > >> Reading the lot without paging - >> although we can do it - is very inefficient both in terms of LDAP >> resources and application resources. > > That's utter nonsense. The amount of data is the same no matter how many > pieces you slice it into. It is *more* inefficient to slice it into multiple > requests. > >> The directory is read using multiple parallel paged searches across >> different branches on a single connection. Every directory we have >> used except OpenLDAP can manage this effectively. > >> In the case of OpenLDAP there is no LDAP changelog and so the only way >> we have of discovering changes is to read the whole directory and >> compare with what was read last time. > > So you're saying you're connecting to OpenLDAP servers from version 2.1 or > older, from before syncrepl or the accesslog or changelog overlays existed. > >> -----Original Message----- >> From: Michael Ströder [mailto:michael@stroeder.com] >> Sent: 17 September 2013 20:20 >> To: john.unsworth(a)cp.net; openldap-its(a)openldap.org >> Subject: Re: (ITS#7698) Multiple Paged search requests on one >> connection fail >> >> john.unsworth(a)cp.net wrote: >>> I would also be interested to understand why " paged results is >>> inherently flawed". >> >> Although being the author of an interactive LDAP UI client I still >> wonder why people want paged results (or tree browsing). >> >> If you have so many results you should narrow the search criteria. >> Browsing/paging is pretty inefficient working style. >> >> Ciao, Michael. >> >> >> >> >> > > -- -- Howard Chu CTO, 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#7698) Multiple Paged search requests on one connection fail
by quanah＠zimbra.com 17 Sep '13

17 Sep '13

--On Tuesday, September 17, 2013 7:52 PM +0000 john.unsworth(a)cp.net wrote: > AFAIK it is not the standard LDAP changelog - let me know if I'm wrong. We > don't want to write specific code for each LDAP server that doesn't > conform to the LDAP (draft I know) standard. Please fix your client to stop top-posting. With openldap, you have two choices. I don't know which draft you are referring to, so I can't say if either conforms with what the other directory servers do. slapo-auditlog slapo-accesslog Pick your path. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

>> There are no other directory servers in existence that can scale to the level that OpenLDAP does and perform well at that scale. How do you justify/prove that statement? -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: 17 September 2013 20:52 To: john.unsworth(a)cp.net; openldap-its(a)openldap.org Subject: Re: (ITS#7698) Multiple Paged search requests on one connection fail john.unsworth(a)cp.net wrote: > Products other than browsers use LDAP servers. Our product is a meta > directory that watches for changes on multiple data sources (LDAP, > Databases, SAP, ...) and reconciles any changes across the complete > set of sources according to data filtering and transformation rules. > However sometimes it is necessary to read the whole data set - for > example when a new data server is added, or when changes may have been > missed for any reason, or when an 'audit' type operation is required > to ensure that all data sources are consistent. LDAP servers we > connect to typically contain thousands if not millions of entries. OpenLDAP is regularly used in production by large telcos with billions of entries. There are no other directory servers in existence that can scale to the level that OpenLDAP does and perform well at that scale. > Reading the lot without paging - > although we can do it - is very inefficient both in terms of LDAP > resources and application resources. That's utter nonsense. The amount of data is the same no matter how many pieces you slice it into. It is *more* inefficient to slice it into multiple requests. > The directory is read using multiple parallel paged searches across > different branches on a single connection. Every directory we have > used except OpenLDAP can manage this effectively. > In the case of OpenLDAP there is no LDAP changelog and so the only way > we have of discovering changes is to read the whole directory and > compare with what was read last time. So you're saying you're connecting to OpenLDAP servers from version 2.1 or older, from before syncrepl or the accesslog or changelog overlays existed. > -----Original Message----- > From: Michael Ströder [mailto:michael@stroeder.com] > Sent: 17 September 2013 20:20 > To: john.unsworth(a)cp.net; openldap-its(a)openldap.org > Subject: Re: (ITS#7698) Multiple Paged search requests on one > connection fail > > john.unsworth(a)cp.net wrote: >> I would also be interested to understand why " paged results is >> inherently flawed". > > Although being the author of an interactive LDAP UI client I still > wonder why people want paged results (or tree browsing). > > If you have so many results you should narrow the search criteria. > Browsing/paging is pretty inefficient working style. > > Ciao, Michael. > > > > > -- -- Howard Chu CTO, 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#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

AFAIK it is not the standard LDAP changelog - let me know if I'm wrong. We don't want to write specific code for each LDAP server that doesn't conform to the LDAP (draft I know) standard. -----Original Message----- From: Quanah Gibson-Mount [mailto:quanah@zimbra.com] Sent: 17 September 2013 20:49 To: john.unsworth(a)cp.net; openldap-its(a)openldap.org Subject: RE: (ITS#7698) Multiple Paged search requests on one connection fail --On Tuesday, September 17, 2013 7:34 PM +0000 john.unsworth(a)cp.net wrote: > In the case of OpenLDAP there is no LDAP changelog and so the only way > we have of discovering changes is to read the whole directory and > compare with what was read last time. If you think that, then apparently you haven't spent time reading the documentation. OpenLDAP has had a changelog since at least OpenLDAP 2.3, if you enable it. I use it for auditing changes all the time. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7698) Multiple Paged search requests on one connection fail
by hyc＠symas.com 17 Sep '13

17 Sep '13

john.unsworth(a)cp.net wrote: > Products other than browsers use LDAP servers. Our product is a meta > directory that watches for changes on multiple data sources (LDAP, > Databases, SAP, ...) and reconciles any changes across the complete set of > sources according to data filtering and transformation rules. However > sometimes it is necessary to read the whole data set - for example when a > new data server is added, or when changes may have been missed for any > reason, or when an 'audit' type operation is required to ensure that all > data sources are consistent. LDAP servers we connect to typically contain > thousands if not millions of entries. OpenLDAP is regularly used in production by large telcos with billions of entries. There are no other directory servers in existence that can scale to the level that OpenLDAP does and perform well at that scale. > Reading the lot without paging - > although we can do it - is very inefficient both in terms of LDAP resources > and application resources. That's utter nonsense. The amount of data is the same no matter how many pieces you slice it into. It is *more* inefficient to slice it into multiple requests. > The directory is read using multiple parallel > paged searches across different branches on a single connection. Every > directory we have used except OpenLDAP can manage this effectively. > In the case of OpenLDAP there is no LDAP changelog and so the only way we > have of discovering changes is to read the whole directory and compare with > what was read last time. So you're saying you're connecting to OpenLDAP servers from version 2.1 or older, from before syncrepl or the accesslog or changelog overlays existed. > -----Original Message----- > From: Michael Ströder [mailto:michael@stroeder.com] > Sent: 17 September 2013 20:20 > To: john.unsworth(a)cp.net; openldap-its(a)openldap.org > Subject: Re: (ITS#7698) Multiple Paged search requests on one connection > fail > > john.unsworth(a)cp.net wrote: >> I would also be interested to understand why " paged results is inherently >> flawed". > > Although being the author of an interactive LDAP UI client I still wonder > why > people want paged results (or tree browsing). > > If you have so many results you should narrow the search criteria. > Browsing/paging is pretty inefficient working style. > > Ciao, Michael. > > > > > -- -- Howard Chu CTO, 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#7698) Multiple Paged search requests on one connection fail
by quanah＠zimbra.com 17 Sep '13

17 Sep '13

--On Tuesday, September 17, 2013 7:34 PM +0000 john.unsworth(a)cp.net wrote: > In the case of OpenLDAP there is no LDAP changelog and so the only way we > have of discovering changes is to read the whole directory and compare > with what was read last time. If you think that, then apparently you haven't spent time reading the documentation. OpenLDAP has had a changelog since at least OpenLDAP 2.3, if you enable it. I use it for auditing changes all the time. --Quanah -- Quanah Gibson-Mount Lead Engineer Zimbra Software, LLC -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

RE: (ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

Products other than browsers use LDAP servers. Our product is a meta directory that watches for changes on multiple data sources (LDAP, Databases, SAP, ...) and reconciles any changes across the complete set of sources according to data filtering and transformation rules. However sometimes it is necessary to read the whole data set - for example when a new data server is added, or when changes may have been missed for any reason, or when an 'audit' type operation is required to ensure that all data sources are consistent. LDAP servers we connect to typically contain thousands if not millions of entries. Reading the lot without paging - although we can do it - is very inefficient both in terms of LDAP resources and application resources. The directory is read using multiple parallel paged searches across different branches on a single connection. Every directory we have used except OpenLDAP can manage this effectively. In the case of OpenLDAP there is no LDAP changelog and so the only way we have of discovering changes is to read the whole directory and compare with what was read last time. -----Original Message----- From: Michael Ströder [mailto:michael@stroeder.com] Sent: 17 September 2013 20:20 To: john.unsworth(a)cp.net; openldap-its(a)openldap.org Subject: Re: (ITS#7698) Multiple Paged search requests on one connection fail john.unsworth(a)cp.net wrote: > I would also be interested to understand why " paged results is inherently > flawed". Although being the author of an interactive LDAP UI client I still wonder why people want paged results (or tree browsing). If you have so many results you should narrow the search criteria. Browsing/paging is pretty inefficient working style. Ciao, Michael.

1 0

Re: (ITS#7698) Multiple Paged search requests on one connection fail
by michael＠stroeder.com 17 Sep '13

17 Sep '13

This is a cryptographically signed message in MIME format. --------------ms010600090306020303050000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable john.unsworth(a)cp.net wrote: > I would also be interested to understand why " paged results is inheren= tly > flawed". Although being the author of an interactive LDAP UI client I still wonder= why people want paged results (or tree browsing). If you have so many results you should narrow the search criteria. Browsing/paging is pretty inefficient working style. Ciao, Michael. --------------ms010600090306020303050000 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE3MTkyMDAwWjAj BgkqhkiG9w0BCQQxFgQUpv3q6AMfQ1O8+1srFtSPkVL3xygwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAGjYerDwPbwx9TRVxTwWTs+XC+rIW5OBo aslumvg3olNfz8t+Tw+Mjg23Gr9JCoAeJNW3F/YyUnvBD2hiWqDFfG/GJrRoEcpoXTMjNe+k OBjGqU84SK/a8OwFQWgY2FN5pB88Zz56HBqSur7QmXhVu4ijKwGQGlVZxJFJ5JFeoNcKEJfo ln/4LsMgQ8g/ouvokX3tRsbb8u8dT4EaEwN1nyMaLK5el/DhGuVwuwh0tqS6BV82NPG1NRAb YdIs5DQAqrqXJBrFhvABVSwZQ73rzipMZrFXz42uuaG/5ronuSPMFIPAGOxuF4/zUsN5qcq8 AQ7mVAQ37eOdfyhv8jKVFwAAAAAAAA== --------------ms010600090306020303050000--

1 0

RE: (ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

I would also be interested to understand why " paged results is inherently flawed". -----Original Message----- From: John Unsworth [mailto:john.unsworth@cp.net] Sent: 17 September 2013 12:07 To: 'Pierangelo Masarati' Cc: 'openldap-its(a)openldap.org' Subject: RE: (ITS#7698) Multiple Paged search requests on one connection fail Thank you for your reply. >> Technically speaking, paged results consists of perfectly >> independent operations from the protocol point of view Yes but the results have not all been retrieved - only the first page full - and further operations are needed to get the additional results. Hence paged searches are not really independent but are linked by the cookie. The results are supposed to remain available so that additional searches using the same cookie can retrieve them. Every other LDAP server I have come across allows multiple concurrent paged searches on a single connection. The RFC does seem to allow the OpenLDAP behaviour but it seems extremely restrictive to me. It should at least be well documented. -----Original Message----- From: Pierangelo Masarati [mailto:pierangelo.masarati@polimi.it] <snip> No, it's correct (at least, that's the intended behavior). The operation structure is only persistent for the duration of the operation, whereas the connection structure persists for the duration of the connection. Technically speaking, paged results consists of perfectly independent operations from the protocol point of view, so persistent state is saved in the connection structure. Of course, multiple cookies could be stored, but since paged results is inherently flawed, it was decided to handle it this way. Clients need to use a dedicated connection for search operations that use the paged results control. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

RE: (ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

Thank you for your reply. >> Technically speaking, paged results consists of perfectly independent operations from the protocol point of view Yes but the results have not all been retrieved - only the first page full - and further operations are needed to get the additional results. Hence paged searches are not really independent but are linked by the cookie. The results are supposed to remain available so that additional searches using the same cookie can retrieve them. Every other LDAP server I have come across allows multiple concurrent paged searches on a single connection. The RFC does seem to allow the OpenLDAP behaviour but it seems extremely restrictive to me. It should at least be well documented. -----Original Message----- From: Pierangelo Masarati [mailto:pierangelo.masarati@polimi.it] Sent: 17 September 2013 11:54 To: john.unsworth(a)cp.net Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7698) Multiple Paged search requests on one connection fail On 09/17/2013 12:36 PM, john.unsworth(a)cp.net wrote: > Full_Name: John Unsworth > Version: 2.4.34 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.139.153.176) > > > If I issue multiple paged requests on a single connection then when > requesting the second page for the first request I receive 'paged > results cookie is invalid'. I suspect from looking at the code that > only a single paged request is allowed to be active at once on a connection. Can someone confirm please. Confirmed. > > parse_paged_cookie( Operation *op, SlapReply *rs ) > > if ( ps->ps_cookieval.bv_len ) { > ... > } else { > /* we're going to use ps_cookie */ > op->o_conn->c_pagedresults_state.ps_cookie = 0; > > It seems to me that the cookie is held against the connection (o_conn) > and not the operation. Surely this is wrong? No, it's correct (at least, that's the intended behavior). The operation structure is only persistent for the duration of the operation, whereas the connection structure persists for the duration of the connection. Technically speaking, paged results consists of perfectly independent operations from the protocol point of view, so persistent state is saved in the connection structure. Of course, multiple cookies could be stored, but since paged results is inherently flawed, it was decided to handle it this way. Clients need to use a dedicated connection for search operations that use the paged results control. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

Re: (ITS#7698) Multiple Paged search requests on one connection fail
by pierangelo.masarati＠polimi.it 17 Sep '13

17 Sep '13

On 09/17/2013 12:36 PM, john.unsworth(a)cp.net wrote: > Full_Name: John Unsworth > Version: 2.4.34 > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (81.139.153.176) > > > If I issue multiple paged requests on a single connection then when requesting > the second page for the first request I receive 'paged results cookie is > invalid'. I suspect from looking at the code that only a single paged request is > allowed to be active at once on a connection. Can someone confirm please. Confirmed. > > parse_paged_cookie( Operation *op, SlapReply *rs ) > > if ( ps->ps_cookieval.bv_len ) { > ... > } else { > /* we're going to use ps_cookie */ > op->o_conn->c_pagedresults_state.ps_cookie = 0; > > It seems to me that the cookie is held against the connection (o_conn) and not > the operation. Surely this is wrong? No, it's correct (at least, that's the intended behavior). The operation structure is only persistent for the duration of the operation, whereas the connection structure persists for the duration of the connection. Technically speaking, paged results consists of perfectly independent operations from the protocol point of view, so persistent state is saved in the connection structure. Of course, multiple cookies could be stored, but since paged results is inherently flawed, it was decided to handle it this way. Clients need to use a dedicated connection for search operations that use the paged results control. p. -- Pierangelo Masarati Associate Professor Dipartimento di Scienze e Tecnologie Aerospaziali Politecnico di Milano

1 0

RE: (ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

I forgot to mention that the operations are all active at the same time: Issue paged op 1 Receive results for op 1 Issue paged op 2 Issue paged op 3 Request 2nd page for op 1 >From our trace: 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SEARCH one 'ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=5a 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> attribute[0]=1.1 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SendingControl[0]=SimplePaged, Length=7, IsCritical=true 16:45:00.678: [664.6392] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SimplePaged: 30 05 02 01 02 04 00 16:45:00.693: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> ReceivedControl[0]=SimplePaged, Length=11 16:45:00.693: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SimplePaged: 30 09 02 01 00 04 04 04 00 00 00 16:45:00.693: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <56> SEARCH Result OK received=0 total=2 (complete) 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> SEARCH one 'cn=c1,ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=5d 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> attribute[0]=1.1 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> SendingControl[0]=SimplePaged, Length=7, IsCritical=true 16:45:00.700: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <59> SimplePaged: 30 05 02 01 02 04 00 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> SEARCH one 'cn=c2,ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=60 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> attribute[0]=1.1 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> SendingControl[0]=SimplePaged, Length=7, IsCritical=true 16:45:00.719: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5b> SimplePaged: 30 05 02 01 02 04 00 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SEARCH one 'ou=People,dc=maxcrc,dc=com' filter='(objectClass=*)' MsgID=61 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> attribute[0]=1.1 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SendingControl[0]=SimplePaged, Length=11, IsCritical=true 16:45:00.721: [664.6780] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SimplePaged: 30 09 02 01 02 04 04 04 00 00 00 16:45:00.737: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SEARCH Result ERROR='DA_E_PROTOCOL_ERROR' received=0 total=0 (complete) 16:45:00.737: [664.6684] DataAccess: 'LDAP://junsworth-lt4.eu.cp.net:33389' <5c> SEARCH Result Server_Info='paged results cookie is invalid'

1 0

(ITS#7698) Multiple Paged search requests on one connection fail
by john.unsworth＠cp.net 17 Sep '13

17 Sep '13

Full_Name: John Unsworth Version: 2.4.34 OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.139.153.176) If I issue multiple paged requests on a single connection then when requesting the second page for the first request I receive 'paged results cookie is invalid'. I suspect from looking at the code that only a single paged request is allowed to be active at once on a connection. Can someone confirm please. parse_paged_cookie( Operation *op, SlapReply *rs ) if ( ps->ps_cookieval.bv_len ) { ... } else { /* we're going to use ps_cookie */ op->o_conn->c_pagedresults_state.ps_cookie = 0; It seems to me that the cookie is held against the connection (o_conn) and not the operation. Surely this is wrong?

1 0

Re: (ITS#7697) RFE: contrib/slapo-lastbind as an official overlay
by michael＠stroeder.com 17 Sep '13

17 Sep '13

marco.pizzoli(a)gmail.com wrote: > Full_Name: Marco Pizzoli > Version: All > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.11.209.11) > > > I would like to use contrib/slapo-lastbind as I currently do with all official > overlays: > > - main configure option > - cn=config integration > > So my request is to official adopt it. > > Few years ago I asked for another enhancement of this module with ITS#6871. +1, also for ITS#6871. Ciao, Michael.

1 0

(ITS#7697) RFE: contrib/slapo-lastbind as an official overlay
by marco.pizzoli＠gmail.com 17 Sep '13

17 Sep '13

Full_Name: Marco Pizzoli Version: All OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.11.209.11) I would like to use contrib/slapo-lastbind as I currently do with all official overlays: - main configure option - cn=config integration So my request is to official adopt it. Few years ago I asked for another enhancement of this module with ITS#6871. Any hope? Thanks in advance Marco Pizzoli

1 0

Re: (ITS#7693) ProxyCache Problems
by teichler＠message-mobile.de 16 Sep '13

16 Sep '13

Hi Quana, Now i understood what you mean. ;) I'll try it. Thank you Mike -- _____________________________________________________ Message Mobile GmbH Stresemannstr. 6, D-21335 Lüneburg teichler(a)message-mobile.de tel.: +49 (0)4131 24444-234, fax: +49 (0)4131 24444-2349 www.message-mobile.de GF: Dr. Martin Hecker, AG Lüneburg, HRB: 2414 _____________________________________________________

1 0

(ITS#7679)
by a.rossini＠cineca.it 16 Sep '13

16 Sep '13

This is a multipart message in MIME format. ------=_NextPart_000_00FF_01CEB2BE.DC3AE260 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit We have checked our build and it passes test044. I'll open a new discussion on the openldap-technical mailing list. Thanks, Angelo. ------=_NextPart_000_00FF_01CEB2BE.DC3AE260 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta = http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"><meta name=3DGenerator content=3D"Microsoft Word 14 = (filtered medium)"><style></style></head><body lang=3DIT link=3Dblue = vlink=3Dpurple><div class=3DWordSection1>We have checked our build and it passes = test044.<o:p></o:p><o:p> </o:p>I’ll open a new discussion on the openldap-technical mailing = list.<o:p></o:p><o:p> </o:p>Thanks,<o:p></o:p><o:p> </o:p>Angelo.<o:p></o:p><o:p> </o:p><= /p><o:p> </o:p></div></body></html> ------=_NextPart_000_00FF_01CEB2BE.DC3AE260--

1 0

Re: (ITS#7696) FACING ISSUE WHILE ADDING LDAP USER
by michael＠stroeder.com 15 Sep '13

15 Sep '13

This is a cryptographically signed message in MIME format. --------------ms030307080905040004000600 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable cs.sudhan.mca(a)gmail.com wrote: > [root@ldap5 migration]# ldapadd -D "cn=3DManager,dc=3Dlinux,dc=3Dcom" -= W -x -f > user1.ldif > Enter LDAP Password: > adding new entry "uid=3Duser1,ou=3DPeople,dc=3Dlinux,dc=3Dcom" > ldap_add: No such object (32) > matched DN: dc=3Dlinux,dc=3Dcom Likely the superior entry ou=3DPeople,dc=3Dlinux,dc=3Dcom does not exist = yet. You should ask usage questions on the openldap-technical mailing list. Th= e ITS is for reporting bugs only. Ciao, Michael. --------------ms030307080905040004000600 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFfzCC BXswggNjoAMCAQICAwxOfTANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMjEw MDIyMDE3MDlaFw0xNDEwMDIyMDE3MDlaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggFEMIIBQDAMBgNVHRMBAf8EAjAAMFYGCWCGSAGG+EIBDQRJFkdUbyBnZXQgeW91 ciBvd24gY2VydGlmaWNhdGUgZm9yIEZSRUUgaGVhZCBvdmVyIHRvIGh0dHA6Ly93d3cuQ0Fj ZXJ0Lm9yZzAOBgNVHQ8BAf8EBAMCA6gwQAYDVR0lBDkwNwYIKwYBBQUHAwQGCCsGAQUFBwMC BgorBgEEAYI3CgMEBgorBgEEAYI3CgMDBglghkgBhvhCBAEwMgYIKwYBBQUHAQEEJjAkMCIG CCsGAQUFBzABhhZodHRwOi8vb2NzcC5jYWNlcnQub3JnMDEGA1UdHwQqMCgwJqAkoCKGIGh0 dHA6Ly9jcmwuY2FjZXJ0Lm9yZy9yZXZva2UuY3JsMB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ry b2VkZXIuY29tMA0GCSqGSIb3DQEBBQUAA4ICAQC9ouXq3p/bDWMM4tBKgD3tl4HY5H0eECl8 q9/nqk0UL6YeWkrCiQdrDtNPW7DcGqNYtzdgtzmyTr1GhiAX+igrOjdk/ge5NRcQOpONK/4b zrmpQEcIUyxSSDKLWh211/kcFfxxLEiJ5teF4GL8Fc1qbrLP4+DCvJXWfYaaR5NLjZMqm2VP yKTv3qpXWnGohiRkGTwS/11QM2XCfIGdRsQT9a8mO4m2fn2tGPp2TEIoCLrDDrbGVeDWaOWB OIeTrp4wa3Q4OI6yCptJhEqKvjhV96IBRYgM76nTBqsqnDzwxExAyhhWiUS5DunRHOr/+NyF pUpD4883RBLO0g9kUEGOhtZNF1u+8zEL0YgMGvifAom9JEklLOXZuqj0MThypKs/3d/OyOQb 4gURnu6oZwcKZ7LskytWnlRKUxF6o0A8grtmyKkqe14TS7cQbg0NTaIYXPkHR+dfFmb3uEqn BBjvpJXFcEtWI2lQXC/ET+au991pK797ExBOmpQwjIn3SjiW80vw/UoL6DMvqY/6JhVhyNTP MJ2W5AX5kc27DIbVtVGZs8J4AYhuNALJUq9N9Ka7rPRj3RcYDrfehDLOkM5iMnarpmtuOpLK d1SvZhqj/0N/JWGIDpPSTkTFOPP6ZN9I9Rqyf+9NGqb2sjo4DkIiZcHxt735/GJLwus5KLBl 2DGCA6EwggOdAgEBMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93 d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8G CSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wCQYFKw4DAhoFAKCCAfUwGAYJ KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwOTE1MTkxMzIzWjAj BgkqhkiG9w0BCQQxFgQUneiKFZgfezFKbuPAyOqPw6iORi8wbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAGTiZEC0y1XwM2TkuYLmrAj10vLIHF4Jw FHmGeNdvETMVOxMk7RoMxD27gJdXjRdq85QGgXdbxhMsWqfWOSqZphtQ9euuPkgOVIbhGoIO AyNUK09CnHTUKQOGQeBC25dnqMGPUckdkJs+qA8GmhQbdTMg5SxLc9cJNIEzLkv5Bb4nu9AK y5hd9ZxhFEXYFekAh4z6audsR81FZBMWkwIaSQ04Z8J6n7OeFkuxX/Pdu3dHI7mWxXK67vNd tEL1TWNHAODgz4p6RBHEMQJZyKbJfI9bj9XJ9gaIMBuxh+I3ZdNpwl5S2hkX/XqOktu7LxcP 57nxztNqalkCMnXVVVSqEwAAAAAAAA== --------------ms030307080905040004000600--

1 0

(ITS#7696) FACING ISSUE WHILE ADDING LDAP USER
by cs.sudhan.mca＠gmail.com 15 Sep '13

15 Sep '13

Full_Name: HARI HARA SUDHAN S Version: OS: RHEL 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (116.202.144.181) [root@ldap5 migration]# ldapadd -D "cn=Manager,dc=linux,dc=com" -W -x -f user1.ldif Enter LDAP Password: adding new entry "uid=user1,ou=People,dc=linux,dc=com" ldap_add: No such object (32) matched DN: dc=linux,dc=com

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs