openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#7864) slapo-translucent should honour the manageDSAit control
by michael＠stroeder.com 29 May '14

29 May '14

This is a cryptographically signed message in MIME format. --------------ms080107050802050209040602 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> This is a cryptographically signed message in MIME format. >=20 >> jkozyra(a)gmail.com wrote: >>> ManageDSAit is honoured by other overlays like dynlist, retcode, and = un=3D >> ique. The >>> translucent overlay should add this functionality. >> >> Can your please elaborate on the semantics you want to have when using= >> ManageDSAit control. >> >> Originally ManageDSAit control was only meant to manage referral entri= es.=3D >=20 >> It was (ab)used for some other purposes especially *before* Relax Rule= s >> control was defined/implemented. >=20 > In particular, the control changes search behavior to return the actual= entry=20 > for a referral entry, instead of returning a searchReference. In the ot= her=20 > overlays, e.g. dynlist, the control changes search behavior to return t= he=20 > actual entry, instead of trying to expand the list of dynamic members. >=20 > For translucent, the control should return the actual local entry, inst= ead of=20 > trying to return the result of merging local and remote data. I thought the Proxy cache privateDB control (1.3.6.1.4.1.4203.666.11.9.5.= 1) should be used for that. CIao, Michael. --------------ms080107050802050209040602 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNTI5MTM1MzM5WjAj BgkqhkiG9w0BCQQxFgQUHudXKkMwDWUJD1r/NhU+1GGT2vQwbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEAdkiNkhBAipUQ1XBLmnIEzrcs+AC5V2WE 0MiMn7MmAL2072PBLWnF6Bei2CdM3F9E608yBBM9seU1FQsxXf2fnzUd3PUqVvuQpFvbiJVG sDgggrDV2FZocvkYcBLhgBhEaUJ2zSVHofqWfWScgEz9jwUFbq2n8W9NpkBpbSMG+JdUAq6u stXKZ+oXybqFvwUybP/0qPfjvFOFF/w7wOUdk7heDUNsMXMydil0fptIIOop9r29fLqK3fLo tFHB9QNG7PTy1ZoBh/5WM6891WSWtJm1RWvstb8XIMEvg2MC2a3+au2I0lPX7UwNO3Bglw7F D3cADleduhU/HrUmNItKvQAAAAAAAA== --------------ms080107050802050209040602--

1 0

Re: (ITS#7864) slapo-translucent should honour the manageDSAit control
by hyc＠symas.com 29 May '14

29 May '14

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > jkozyra(a)gmail.com wrote: >> ManageDSAit is honoured by other overlays like dynlist, retcode, and un= > ique. The >> translucent overlay should add this functionality. > > Can your please elaborate on the semantics you want to have when using > ManageDSAit control. > > Originally ManageDSAit control was only meant to manage referral entries.= > It was (ab)used for some other purposes especially *before* Relax Rules > control was defined/implemented. In particular, the control changes search behavior to return the actual entry for a referral entry, instead of returning a searchReference. In the other overlays, e.g. dynlist, the control changes search behavior to return the actual entry, instead of trying to expand the list of dynamic members. For translucent, the control should return the actual local entry, instead of trying to return the result of merging local and remote data. The use case is the same as for the other overlays - make sure we get actual entries as they are stored in the server, as opposed to some dynamically transformed version of the entries. -- -- 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#7864) slapo-translucent should honour the manageDSAit control
by michael＠stroeder.com 29 May '14

29 May '14

This is a cryptographically signed message in MIME format. --------------ms060706000808070704030900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable jkozyra(a)gmail.com wrote: > ManageDSAit is honoured by other overlays like dynlist, retcode, and un= ique. The > translucent overlay should add this functionality. Can your please elaborate on the semantics you want to have when using ManageDSAit control. Originally ManageDSAit control was only meant to manage referral entries.= It was (ab)used for some other purposes especially *before* Relax Rules control was defined/implemented. Ciao, Michael. --------------ms060706000808070704030900 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNTI5MTMyNzQ4WjAj BgkqhkiG9w0BCQQxFgQUJIQoNlQKKPgKvV8M4xsguOfuEdowbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEABbo93P/6Q2VvX6dwtrFbLYvubeU/Z7OE BzNu7KxeeDNYKW5l9Lht8IyMtaAg/Mb48EK+IsZw0TGmbLSty4kzDxjXc+ELAi8/S5lAF+Rt 5F+aNXZmMpSuMdes/Ei0mJtf6lmzTiGJNOiOMkxHkutL4AbV+kkbfaydK/yQTa9ZV6fL8nJU IqvRm63excncCpKsc75kTzVwOERtkMvOz6BvI9N+C07hFTI8Oi+S+Ibc8OR1zUGvPYJrGEzx At+EH69piRP4PEeIOXHGkU7ILDhCQN8ucta+eeTISxZMMI6xs4YBdUcnjhpuViVyLVRAPEG9 q3sD8vmGwPvMgEgYU/3TiwAAAAAAAA== --------------ms060706000808070704030900--

1 0

(ITS#7864) slapo-translucent should honour the manageDSAit control
by jkozyra＠gmail.com 29 May '14

29 May '14

Full_Name: Jillian Kozyra Version: 2.4.39 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.234.81) ManageDSAit is honoured by other overlays like dynlist, retcode, and unique. The translucent overlay should add this functionality.

1 0

Re: (ITS#7862) slapd crash on modifications after host hard reset (in mdb)
by hyc＠symas.com 29 May '14

29 May '14

Michael.Levitin(a)billing.ru wrote: > --_000_6D4FA1DFD570AD4CBACDA9117C4A2125024BF1C541SRVEXCHMBX1bi_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > "What health status? The mdb_stat command will return info about the DB." > mdb_stat returns segmentation fault. Guess it's not sufficient info. > The question is - is there any method to check file consistence ? ( i.e. fi= > le structure is not corrupted during power reset.) No. If you want protection from power reset, you must use regular synchronous writes. > Thanks. > > Mikhail > > > > --_000_6D4FA1DFD570AD4CBACDA9117C4A2125024BF1C541SRVEXCHMBX1bi_ > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > <html> > <head> > <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= >> > <meta name=3D"Generator" content=3D"Microsoft Exchange Server"> >  > <style></style> > </head> > <body> > <font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;"> > <div>“What health status? The mdb_stat command will return info about= > the DB. “</div> > <div>mdb_stat returns segmentation fault. Guess it's not sufficient info.</= > div> > <div>The question is – is there any method to check file consistence = > ? ( i.e. file structure is not corrupted during power reset.)</div> > <div> </div> > <div>Thanks.</div> > <div> </div> > <div>Mikhail</div> > <div> </div> > <div> </div> > </span></font> > </body> > </html> > > --_000_6D4FA1DFD570AD4CBACDA9117C4A2125024BF1C541SRVEXCHMBX1bi_-- > > > -- -- 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#7862) slapd crash on modifications after host hard reset (in mdb)
by Michael.Levitin＠billing.ru 29 May '14

29 May '14

--_000_6D4FA1DFD570AD4CBACDA9117C4A2125024BF1C541SRVEXCHMBX1bi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable "What health status? The mdb_stat command will return info about the DB. " mdb_stat returns segmentation fault. Guess it's not sufficient info. The question is - is there any method to check file consistence ? ( i.e. fi= le structure is not corrupted during power reset.) Thanks. Mikhail --_000_6D4FA1DFD570AD4CBACDA9117C4A2125024BF1C541SRVEXCHMBX1bi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Exchange Server">  <style></style> </head> <body> <font face=3D"Calibri" size=3D"2"><span style=3D"font-size:11pt;"> <div>“What health status? The mdb_stat command will return info about= the DB. “</div> <div>mdb_stat returns segmentation fault. Guess it's not sufficient info.</= div> <div>The question is – is there any method to check file consistence = ? ( i.e. file structure is not corrupted during power reset.)</div> <div> </div> <div>Thanks.</div> <div> </div> <div>Mikhail</div> <div> </div> <div> </div> </span></font> </body> </html> --_000_6D4FA1DFD570AD4CBACDA9117C4A2125024BF1C541SRVEXCHMBX1bi_--

1 0

Re: (ITS#7861) Wrong entry count with MDB_DUPSORT databases
by hbf＠mail.uio.no 29 May '14

29 May '14

> mdb_cursor_put() now tracks data items instead of keys in > md_entries, broken by 13d6d59c512065db3741c20c65b4d9928b986968. oops, that was backwards. Changed to tracking keys from data items.

1 0

Re: (ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by hyc＠symas.com 29 May '14

29 May '14

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD and RE24 > OS: Linux > URL: > Submission from: (NULL) (212.227.35.93) > > > It seems that modify requests which failed due to Invalid DN syntax (34) are not > written to accesslog-DB. I guess that those requests get abandoned by the > frontend and never reach the backend at all. Correct. > It would be handy to see the invalid modify request in the accesslog-DB though. > > Any chance to achieve this? Not likely. The frontend must call select_backend() based on the incoming DN to determine which backend to invoke, and thus which stack of overlays are involved. If the DN is invalid, no selection can occur. -- -- 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#7861) Wrong entry count with MDB_DUPSORT databases
by hbf＠mail.uio.no 29 May '14

29 May '14

More: mdb_cursor_put() now tracks data items instead of keys in md_entries, broken by 13d6d59c512065db3741c20c65b4d9928b986968. mdb_cursor_del(, MDB_NODUPDATA) is off-by-one for sub-DBs: It subtracts subDB.md_entries, then mdb_cursor_del0() subtracts 1. Fixing.

1 0

(ITS#7863) Invalid DN syntax (34) not written by slapo-accesslog
by michael＠stroeder.com 28 May '14

28 May '14

Full_Name: Michael Ströder Version: HEAD and RE24 OS: Linux URL: Submission from: (NULL) (212.227.35.93) It seems that modify requests which failed due to Invalid DN syntax (34) are not written to accesslog-DB. I guess that those requests get abandoned by the frontend and never reach the backend at all. It would be handy to see the invalid modify request in the accesslog-DB though. Any chance to achieve this?

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs