openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 03 Jun '13

03 Jun '13

Howard Chu <hyc(a)symas.com>: > The patch changes much more than your bug report mentions. The error > message you provide is pretty ambiguous, in particular you haven't > mentioned exactly which markup element is out of order. Without this > information we can't confirm what you're fixing. Globally, I'm trying to fix up the entire Linux manual page corpus so it can be automatically lifted to clean HTML. I've been working in this intermittently since 2002, and am not far from the goal. In approximately 12,000 pages carried in stock Ubuntu, 94% now lift without errors or warnings. For all but 17 of the 6% remaining I have fix patches which I'm trying to get merged upstream. I entered one of those patches in your bugtracker, but failed to notice that the error code in my bug database entry for slapd.conf.5 was incorrect (failed to match the patch). I apologize for this; full explanation follows. My conversion tool is doclifter, which you can read about at <http://www.catb.org/~esr/doclifter/>. It lifts manual pages to XML-DocBook, which in turn is very easily rendered to HTML. This sequence produces better-quality HTML than tools like man2html can generate, because of the amount of content analysis done in the doclifter intermediate step. There are some legal troff constructions that doclifter cannot parse well. These are the same sorts of things that any man-page renderer other than groff itself is likely to get wrong; thus, they are likely to confuse tools such as XMan, TkMan, and Rosetta as well as doclifter. Thhe patch I sent you introduces an .EX/.EE macro pair for framing code examples, a common extension often found on older Unix manual pages (I believe it originated in DEC Ultrix). This macro encapsulates a bunch of low-level troff operations that are hard to lift well in isolation. There's a ruleset in doclifter that recognizes .EX/.EE, analyzes the example content, and generates <programlisting> or <literallayout> tags as appropriate. In some cases .EX/.EE replaces .RS/.RE pairs; in others it replaces .nf/.fi pairs, in still others it replaces .TP, and I think there are a couple of odd combinations of .RS/.RE with .TP in there too. The fact that it has to mess with all of these is what makes the patch so complex. But the result is simple: to express the "example" intention better so it can be structurally translated. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

1 0

Re: (ITS#7615) NetBSD sem_open limited to 14 characters
by hyc＠symas.com 03 Jun '13

03 Jun '13

Greg(a)Akua.com wrote: > Full_Name: Greg Kerr > Version: 2.4.35 > OS: NetBSD & FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (50.88.130.68) > > > MDB is not usable on NetBSD because mdb.c has > > sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); > > To create the semaphore name. > > This results in a 21 character name which is beyond the 14 allowed per "man > sem_open" That's unfortunate. In Linux this limit is 251 characters. Seems you'd need to use the btoa algorithm to safely fit a hash into this size limit. Pretty sure we've tested successfully on FreeBSD and MacOSX already, so apparently they don't suffer from this same limit. > "less than 14 characters in length not including the terminating null > character." > > I will make a local patch ... and maybe it's a NetBSD bug - or at least the > package maintainers ... I will report to him. > > At any rate, the failure of mdb with result code 63 (name too long) was very > confusing ... better error reporting in this file would be nice. > > -- -- 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 03 Jun '13

03 Jun '13

esr(a)thyrsus.com wrote: > Full_Name: Eric S. Raymond > Version: > OS: Linux > URL: http://www.catb.org/~esr/doclifter/prepatch/slapd.conf.5.patch > Submission from: (NULL) (2001:470:e34c:0:226:18ff:fea6:dca4) > > > List syntax error. This means .IP, .TP or .RS/.RE markup is garbled. > Common causes include .TP just before a section header, .TP entries > with tags but no bodies, and mandoc lists with no trailing .El. > These confuse doclifter, and may also mess up stricter man-page > browsers like Xman and Rosetta. > > Fix patch at link. The patch changes much more than your bug report mentions. The error message you provide is pretty ambiguous, in particular you haven't mentioned exactly which markup element is out of order. Without this information we can't confirm what you're fixing. -- -- 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#7615) NetBSD sem_open limited to 14 characters
by Greg＠Akua.com 03 Jun '13

03 Jun '13

Full_Name: Greg Kerr Version: 2.4.35 OS: NetBSD & FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.88.130.68) MDB is not usable on NetBSD because mdb.c has sprintf(env->me_txns->mti_wmname, "/MDBw%s", hexbuf); To create the semaphore name. This results in a 21 character name which is beyond the 14 allowed per "man sem_open" "less than 14 characters in length not including the terminating null character." I will make a local patch ... and maybe it's a NetBSD bug - or at least the package maintainers ... I will report to him. At any rate, the failure of mdb with result code 63 (name too long) was very confusing ... better error reporting in this file would be nice.

1 0

(ITS#7614) Markup error in slapd.conf.5
by esr＠thyrsus.com 02 Jun '13

02 Jun '13

Full_Name: Eric S. Raymond Version: OS: Linux URL: http://www.catb.org/~esr/doclifter/prepatch/slapd.conf.5.patch Submission from: (NULL) (2001:470:e34c:0:226:18ff:fea6:dca4) List syntax error. This means .IP, .TP or .RS/.RE markup is garbled. Common causes include .TP just before a section header, .TP entries with tags but no bodies, and mandoc lists with no trailing .El. These confuse doclifter, and may also mess up stricter man-page browsers like Xman and Rosetta. Fix patch at link.

1 0

Re: (ITS#7594) incomplete MDB subdb cursor cleanup
by h.b.furuseth＠usit.uio.no 02 Jun '13

02 Jun '13

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. One partial fix: Instead return a new error code MDB_BAD_CURSOR or maybe MDB_UNSPECIFIED. Also make mdb_cursor_<next/prev>() less forgiving of errors, otherwise the user gets different success results for the two cursors again. Branch mdb/its7594 in <http://folk.uio.no/hbf/OpenLDAP/openldap.git> does this. I did not look at how to get the cursors return the same result. 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. 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); -- Hallvard

1 0

(ITS#7612) {CLEARTEXT} password scheme broken
by wferi＠niif.hu 31 May '13

31 May '13

Full_Name: Ferenc Wágner Version: 2.4.31 OS: Debian GNU/Linux squeeze URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.101.52.7) I'm trying to store the hypothetical password "{SSHA}" in cleartext, but slappasswd refuses to help: $ /usr/sbin/slappasswd -s {SSHA} -h {CLEARTEXT} Password verification failed. On #openldap hbf suggested that I file an ITS ("work" in the following means allowing binding): hbf: Looks like {CLEARTEXT} itself is broken. I think "userPassword: {CLEARTEXT}secret" should work, and so that slappasswd -h {CLEARTEXT} -s secret can output {CLEARTEXT}secret and userPassword: {CLEARTEXT}{SSHA} would be valid. As I agree with him, here it is.

1 0

Re: (ITS#7611) [Patch] Fix loglevel2bvarray
by hyc＠symas.com 29 May '13

29 May '13

jsynacek(a)redhat.com wrote: > Full_Name: Jan Synacek > Version: master > OS: Linux - Fedora 18 > URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-loglevel2bvarray.patch > Submission from: (NULL) (209.132.186.34) > > > When using slaptest to convert a slapd.conf file to the new DIT integrated > configuration (-f and -F options), the directive 'loglevel 0' is not converted > to 'olcLogLevel: 0' in file cn=config.ldif. > > The 'loglevel 0' seems to be a special case, so this patch treats it as such. > > Original report: https://bugzilla.redhat.com/show_bug.cgi?id=918637 Thanks for the patch, committed to master. -- -- 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#7611) [Patch] Fix loglevel2bvarray
by jsynacek＠redhat.com 29 May '13

29 May '13

Full_Name: Jan Synacek Version: master OS: Linux - Fedora 18 URL: http://jsynacek.fedorapeople.org/openldap/0001-Fix-loglevel2bvarray.patch Submission from: (NULL) (209.132.186.34) When using slaptest to convert a slapd.conf file to the new DIT integrated configuration (-f and -F options), the directive 'loglevel 0' is not converted to 'olcLogLevel: 0' in file cn=config.ldif. The 'loglevel 0' seems to be a special case, so this patch treats it as such. Original report: https://bugzilla.redhat.com/show_bug.cgi?id=918637

1 0

Re: (ITS#7610) scope index isn't used correctly with the filter index
by meike.stone＠googlemail.com 28 May '13

28 May '13

2013/5/28 Howard Chu <hyc(a)symas.com>: > meike.stone(a)googlemail.com wrote: >> >> Full_Name: Meike Stone >> Version: 2.4.33 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (193.200.138.3) >> >> >> I have a directory with about 2,000,000 objects at all. >> >> In one conteiner (basedn for search) are about 84,000 objects >> but only one of this is a person with objectclass=inetOrgperson. >> I have about 420,000 objectclass=inetOrgperson. >> >> The search with the specified basedn where only the one inetOrgperson >> is located needs about 5 minutes ... >> >> see: http://www.openldap.org/lists/openldap-technical/201305/msg00210.html > > > Sorry, digging further into the code I see I was mistaken. The two indices > are being combined correctly and the code works in my own tests. > > The search looks up the scope index (IDs of all the entries in the target > scope) and the filter indices and computes their intersection. Not sure why > this would be so slow in your case. hmm, while search, the one entry with the objectclass is shown immediately, but then, it takes a long time to "recognize" that that is all ... How does the slapd calculate/determine the scope index? Tomorrow I try to check this in test environment .. Are there any special things/hints I can test or see? Thanks Meike

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