openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by hyc＠symas.com 05 Jun '13

05 Jun '13

h.b.furuseth(a)usit.uio.no wrote: > Howard Chu writes: >> h.b.furuseth(a)usit.uio.no wrote: >>> If a cursor is at a clean subDB page, and its current item is deleted >>> by another cursor, then MDB_GET_CURRENT returns the deleted item. >> >> Fixed now in mdb.master. The subcursor on the clean page will be invalidated >> when the page is touched. > > MDB_NEXT/MDB_PREV crash on assert(mc->mc_flags & C_INITIALIZED) > since commit e31c7d3b31d8d5073195e31b283e8ccb46bd13cf, with the > patch below to the test program. OK, I've reverted that commit. > mdb.master output with patched test program: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > a.out: mdb.c:4386: mdb_cursor_next: Assertion `mc->mc_flags & 0x01' failed. No longer asserts. Also, [0] was the wrong result here. Also fixed. > Branch mdb/its7594 output: > > With clean page: > Name: Key -> Data (mv_data[mv_len]): > m2: a[2] -> x[2] > mc/del: a[2] -> [0] > its7594a.c:48: mdb_cursor_get(m2, &key, &data, MDB_NEXT): MDB_BAD_CURSOR: Cursor is unusable > > That assert is OK since it's the test program asserting success. > > --- its7594.c > +++ its7594a.c > @@ -28,4 +28,6 @@ > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("x"), 0)); > E(mdb_cursor_put(mc, STR2VAL("a"), STR2VAL("y"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("b"), STR2VAL("z"), 0)); > + E(mdb_cursor_put(mc, STR2VAL("c"), STR2VAL("w"), 0)); > > if (argc < 2) { > @@ -42,8 +44,8 @@ > > E(mdb_cursor_del(mc, 0)); > - E(mdb_cursor_get(m2, &key, &data, MDB_GET_CURRENT)); > - SHOW("m2/del"); /* Should output the same as... */ > - E(mdb_cursor_get(mc, &key, &data, MDB_GET_CURRENT)); > - SHOW("mc/del"); /* ...this: "a[2] -> [0]". */ > + E(mdb_cursor_get(mc, &key, &data, MDB_NEXT)); > + SHOW("mc/del"); /* Outputs "a[2] -> [0]"... */ > + E(mdb_cursor_get(m2, &key, &data, MDB_NEXT)); > + SHOW("m2/del"); /* ...and this should output the same. */ > > mdb_txn_abort(txn); > -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

Michael Ströder wrote: > hyc(a)symas.com wrote: >> I was considering returning LDAP_BUSY for this case, but it may make more >> sense to return a REFERRAL to the provider instead. (Although again, if we >> have two MMR servers pointed at each other starting at the same time, they >> would just refer to each other and clients would get nowhere until one of them >> finishes its refresh.) > > IMO referrals are harmful. > Just returning LDAP_BUSY seems best to me because if reliable HA is really > important for a deployment you have decent load-balancers in front of your > LDAP server which should do a proper health-check. Agreed. > Just a question: Is this database-specific? Maybe only one of several DBs is > in this initial syncrepl phase and access to others should simply work. Overlays are db-specific. -- -- 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#7616) syncrepl enhancement: defer requests when refreshing
by michael＠stroeder.com 05 Jun '13

05 Jun '13

This is a cryptographically signed message in MIME format. --------------ms020809020606000104080607 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable hyc(a)symas.com wrote: > I was considering returning LDAP_BUSY for this case, but it may make mo= re=20 > sense to return a REFERRAL to the provider instead. (Although again, if= we=20 > have two MMR servers pointed at each other starting at the same time, t= hey=20 > would just refer to each other and clients would get nowhere until one = of them=20 > finishes its refresh.) IMO referrals are harmful. Just returning LDAP_BUSY seems best to me because if reliable HA is reall= y important for a deployment you have decent load-balancers in front of you= r LDAP server which should do a proper health-check. Just a question: Is this database-specific? Maybe only one of several DBs= is in this initial syncrepl phase and access to others should simply work. Ciao, Michael. --------------ms020809020606000104080607 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 KoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjA1MTgxNDAzWjAj BgkqhkiG9w0BCQQxFgQUiEZEhMlpWaio/7q/OgE6XehCSTswbAYJKoZIhvcNAQkPMV8wXTAL BglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGD MIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9y ZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYS c3VwcG9ydEBjYWNlcnQub3JnAgMMTn0wgZMGCyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNV BAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZ Q0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNl cnQub3JnAgMMTn0wDQYJKoZIhvcNAQEBBQAEggEA0dEsxfOK4N2Ee5bXv8bgeDj+DFV5pK4X YH8lJkCSkq9qberav4nqRGq7Ka50HZuIzMmWj2t6JR4Y/gIJfCZpSJ6fGtEMKXmuFmT9Kj8l IwlvnmoVyMnrQYVLXz/pnl1AG7vj0n00eYIe2ZlYYT2mVDT9RwBXe5T1UZoOvRmm4fy6AgSU wlNIuyClUgk/5z4jsYb8bf+abz2MWKwNA3Pv3mwB/pTUMdB90WmgfnKI1u0G5aBIsidLd7Ec aVMirzK3Ur7fNSj59/lQdnZixG2p37F+1ZkFXwtAFub5d01osWoCVePJJF16DUzJVgzZBv3Q wtcP0eJdkAwf3tBY4mkfJgAAAAAAAA== --------------ms020809020606000104080607--

1 0

Re: (ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠symas.com 05 Jun '13

05 Jun '13

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: 2.4.35 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (78.155.233.73) > Submitted by: hyc > > > We've discussed this on -devel a few times in the past. Sometimes it would be > desirable to prevent a consumer from answering client requests if it has just > started up and needs to perform an lengthy refresh. > > In prior discussions, there was a concern that in an MMR situation, two servers > coming up at the same time would deadlock waiting for each other. We can avoid > this problem by allowing any search request with a Sync control to proceed as > normal. Or, any search request with a Sync control and a non-empty, valid > cookie. > > Implementation can be done using an overlay hook. Note that syncrepl already > installs an overlay hook now for delta-mmr, this would just expand the scope of > that internal overlay. I was considering returning LDAP_BUSY for this case, but it may make more sense to return a REFERRAL to the provider instead. (Although again, if we have two MMR servers pointed at each other starting at the same time, they would just refer to each other and clients would get nowhere until one of them finishes its refresh.) -- -- 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

(ITS#7616) syncrepl enhancement: defer requests when refreshing
by hyc＠OpenLDAP.org 05 Jun '13

05 Jun '13

Full_Name: Howard Chu Version: 2.4.35 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.233.73) Submitted by: hyc We've discussed this on -devel a few times in the past. Sometimes it would be desirable to prevent a consumer from answering client requests if it has just started up and needs to perform an lengthy refresh. In prior discussions, there was a concern that in an MMR situation, two servers coming up at the same time would deadlock waiting for each other. We can avoid this problem by allowing any search request with a Sync control to proceed as normal. Or, any search request with a Sync control and a non-empty, valid cookie. Implementation can be done using an overlay hook. Note that syncrepl already installs an overlay hook now for delta-mmr, this would just expand the scope of that internal overlay.

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 04 Jun '13

04 Jun '13

Eric S. Raymond wrote: > You have drastically misunderstood what you saw. This isn't an error > in doclifter, it's a result of a basic ontological mismatch between > the source and target markups that doclifter tries to bridge across. > > There are no line breaks in DocBook's XML, structure-oriented world. > The closest thing to one ia special-purpose <sbr/> tag that is only valid > inside command synoposes. Thus there is no "line break" equivalent > that .br can be mapped to. Nor should there be; that is fundamentally > a presentation-level concept. > > Thus, one of either ignoring the .br or interpreting it as a paragraph > boundary is exactly what doclifter *should* be doing. This is not a > bug, it is correct behavior because those are the only alternatives > XML-DocBook supports. This is absolutely ludicrous. This is like saying "my language processor doesn't support the Addition operator, it only supports multiplcation or division. So when you write 'x+y' in your input a result of either 'x*y' or 'x/y' is *exactly* what it should be doing." The fact that your document language or tool only supports two alternatives doesn't make either one of them correct. If you hadn't caused me to waste this much time on this issue already it would be laughable. -- -- 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#7614) Markup error in slapd.conf.5
by hyc＠symas.com 04 Jun '13

04 Jun '13

Eric S. Raymond wrote: > Howard Chu <hyc(a)symas.com>: >> OK, I ran Docbook 4.5 on the output from doclifter and I see it's >> complaining on one line of slapd.conf.5.xml. It appears doclifter is >> misinterpreting the .br request. Instead of inserting a line break >> it is either ignoring it completely or doing a paragraph break. >> >> I'm going to reject your submitted patch because it is not the >> minimal patch needed to fix the error, nor is the error actually in >> our manpage source, it is in the doclifter tool. > > You have drastically misunderstood what you saw. This isn't an error > in doclifter, it's a result of a basic ontological mismatch between > the source and target markups that doclifter tries to bridge across. > > There are no line breaks in DocBook's XML, structure-oriented world. > The closest thing to one ia special-purpose <sbr/> tag that is only valid > inside command synoposes. Thus there is no "line break" equivalent > that .br can be mapped to. Nor should there be; that is fundamentally > a presentation-level concept. A line-break may well be only a presentation-level concept, but it is also something that a document author explicitly chooses to insert. A tool (or markup language) that ignores an author's explicit wishes is a broken tool. > My patch adds the structural information required for doclifter to > get traction. The requirement for this is rare, and getting more so > as man page maintainers clean up their sources. Please be part of > that solution rather than part of the problem. Your solution is broken or unfit for the purpose if it cannot process simple and correct manpage source. -- -- 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#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 04 Jun '13

04 Jun '13

Howard Chu <hyc(a)symas.com>: > OK, I ran Docbook 4.5 on the output from doclifter and I see it's > complaining on one line of slapd.conf.5.xml. It appears doclifter is > misinterpreting the .br request. Instead of inserting a line break > it is either ignoring it completely or doing a paragraph break. > > I'm going to reject your submitted patch because it is not the > minimal patch needed to fix the error, nor is the error actually in > our manpage source, it is in the doclifter tool. You have drastically misunderstood what you saw. This isn't an error in doclifter, it's a result of a basic ontological mismatch between the source and target markups that doclifter tries to bridge across. There are no line breaks in DocBook's XML, structure-oriented world. The closest thing to one ia special-purpose <sbr/> tag that is only valid inside command synoposes. Thus there is no "line break" equivalent that .br can be mapped to. Nor should there be; that is fundamentally a presentation-level concept. Thus, one of either ignoring the .br or interpreting it as a paragraph boundary is exactly what doclifter *should* be doing. This is not a bug, it is correct behavior because those are the only alternatives XML-DocBook supports. doclifter has to deduce which interpretation is correct by applying certain parsing and pattern-matching rules. Usually it succeeds, but there are rare (single-digit-percentage) cases in which it fails. Yours is one. I repeat: the error is *not in the tool*. It's a result of attempting to deduce structure out of the troff tag soup that the tag soup does not intrinsically possess. After 11 years of development doclifter does a pretty heroic job of this, but a perfect one is not possible - there's too much chaos ot there. My patch adds the structural information required for doclifter to get traction. The requirement for this is rare, and getting more so as man page maintainers clean up their sources. Please be part of that solution rather than part of the problem. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

1 0

Re: (ITS#7614) Markup error in slapd.conf.5
by hyc＠symas.com 04 Jun '13

04 Jun '13

Howard Chu wrote: > Eric S. Raymond wrote: >> Howard Chu <hyc(a)symas.com>: >>> For fear of opening up another can of worms, surely slapd.conf.5 is >>> not the only manpage that needs this patch? Other manpages in the >>> distro also use .nf/.fi and .RS/.RE. >>> >>> We need consistency in our source as well. >> >> Agreed. I have analogous patches for slapd-config.5 and slapo-constraint.5. >> Whatever other OpenLDAP pages are in stock Ubuntu are not throwing >> warnings. How would you like these submitted? >> > I just ran doclifter on all 3 of these man pages and the only warning I got > was about the ../Project file. Please tell me how to reproduce the original > error you're reporting because I'm not seeing it. > > Also, how do we fix it so that the content of ../Project is included as it > should be? > OK, I ran Docbook 4.5 on the output from doclifter and I see it's complaining on one line of slapd.conf.5.xml. It appears doclifter is misinterpreting the .br request. Instead of inserting a line break it is either ignoring it completely or doing a paragraph break. I'm going to reject your submitted patch because it is not the minimal patch needed to fix the error, nor is the error actually in our manpage source, it is in the doclifter tool. -- -- 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#7612) {CLEARTEXT} password scheme broken
by Kurt＠OpenLDAP.org 03 Jun '13

03 Jun '13

On Jun 3, 2013, at 1:08 PM, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: > ...OTOH perhaps it's too late to change {cleartext} now if > it has an established useful meaning. Could introduce a new > scheme called {plaintext} or {raw} instead for this purpose. {CLEARTEXT} isn't an RFC 2307 hash scheme... it's a string used in configuration and command line cases to indicate that no RFC 2307 hash scheme is used, that is, the password is cleartext. In the code, IIRC, it's referred to as pseudo-scheme for this reason. The restrictions on clear text passwords that look like RFC 2307 hashed password exist because of the conflict between standard LDAPv3 behavior and RFC 2307 behavior. Adding some RFC 2307 plain-text hash scheme doesn't remove the conflict between standard LDAPv3 behavior RFC 2307 hashed passwords, so IMO the restriction should remain, at least by default. If such an option were introduced, the documentation should make clear that disabling the check can be problematic if ever stored hash passwords are to restored (on Bind) to LDAPv3 compliant LDAPv3 passwords over a period of time. -- Kurt

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