- openldap-bugs - openldap.org

(ITS#8237) Crash with MDB_MAXKEYSIZE=1500
by h.b.furuseth＠usit.uio.no 06 Sep '15

06 Sep '15

Full_Name: Hallvard B Furuseth Version: LMDB 0.9.10-0.9.15 OS: Linux x86_64 URL: Submission from: (NULL) (81.191.45.5) Submitted by: hallvard Assertion 'NUMKEYS(mp) > 1' failed in mdb_page_search_root(): #define MDB_MAXKEYSIZE 1500 #include "mdb.c" #include "midl.c" int main(void) { MDB_dbi dbi; MDB_env *env; MDB_txn *txn; int i, rc =DMDB_SUCCESS; mdb_env_create(&env); mdb_env_open(env, "./testdb", MDB_WRITEMAP, 0664); mdb_txn_begin(env, NULL, 0, &txn); mdb_dbi_open(txn, NULL, 0, &dbi); for (i = 0; i < 6 && !rc; i++) { static char buf[1600] = "340215"; DB_v_val key = {1500, buf+i}, data = {500, buf}; mdb_put(txn, dbi, &key, &data, 0); } mdb_txn_abort(txn); mdb_env_close(env); return rc; } Broken by 34459e05856619e8 "ITS#7589 another mdb_page_split fix".

1 0

Re: (ITS#8230) [new PATCHes] totp: bug fixes and improvements
by peter＠adpm.de 06 Sep '15

06 Sep '15

Hi, Please have a look at the improved patch series in https://github.com/marschap/openldap/commits/contrib-totp3 and https://github.com/marschap/openldap/commits/contrib-totp4 They try to address the issues in the previous versions Changes: * contrib/passwd/totp: fix the big-endian case, support 32-bit archs Use memcpy for the WORDS_BIGENDIAN case [much simpler] Use uint64_t for same results in 32- and 64-bit cases * contrib/passwd/totp: support compiling using nettle Fix the botched previous patch. The two branches differ only in that patch, giving the following alternatives: - contrib-totp3 continues to use the HMAC_... macros It still requires the #if...#else...#endif to harmonize the setup in do_hmac() - contrib-totp4 gets rid of the HMAC_... macros It uses the different implementations directly in do_hmac() Of course separated by #if...#else..#endif Functionally both patches are equivalent: in my tests they yield the same results for OpenSSL and GnuTLS. Best PEter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#7889) rwm overlay causes incorrect acl parsing
by ryan＠nardis.ca 06 Sep '15

06 Sep '15

michael(a)stroeder.com wrote: >But could you please check whether this setting helps: > >rwm-drop-unrequested-attrs no It does. This is another case of ITS#6057; the ACL filter can only be evaluated if the filter attribute is included in those passed through by rwm, otherwise it is just skipped. The larger issue (should ACL evaluation assume the whole entry is available?) seems to still be unaddressed. I don't understand yet why rwm filters the attributes on its own by default, but I'm sure there's a reason. alexoz66(a)gmail.com wrote: >modifying entry "olcOverlay={0}rwm,olcDatabase={1}mdb,cn=config" >ldap_modify: Object class violation (65) > additional info: attribute 'olcRwmDropUnrequested' not allowed > >Looking at the schema it seems that the attribute olcRwmDropUnrequested >is not part of the olcRwmConfig object class (or any other object class >for that matter). This is fixed in git master now.

1 0

Re: (ITS#8230) [new PATCH] totp: bug fixes and improvements
by peter＠adpm.de 05 Sep '15

05 Sep '15

Hi, Please have a look at the improved patch series in https://github.com/marschap/openldap/commits/contrib-totp2 It tries to address all the issues highlighted on the first version. https://github.com/marschap/openldap/commit/e4e1045f59368af8d15172ad22fcc0f… contrib/passwd/totp: flexibilize decoding In function totp_b32_pton() - allow lowercase characters in encoded string too - allow padding to be omitted (totally, not only parts) With this added flexibility we can make use of keys encoded by other Base32-encoding implementations. In function chk_totp() determine the space required to hold the decoded key by calling totp_b32_pton() with a NULL argument for the target. Changes to previous version: - toupper()'s argument guarded with a cast to (unsigned char) - added rationale to commit message https://github.com/marschap/openldap/commit/edfa2b0fb3238ca9f231fa75bd452b4… contrib/passwd/totp: fix the big-endian case, support 32-bit archs - reverse tval in the WORDS_BIGENDIAN case before converting it to a string - use uint64_t for tval to have it correctly sized on 32-bit archs too - avoid magic number when converting tval to a string Changes to previous version: - complete rewrite https://github.com/marschap/openldap/commit/24007f02cebb0b7f801288b02d0ac8c… contrib/passwd/totp: fix decoding when padding is used In totp_b32_pton(), correctly count the number of '=' padding chars at the end of the base-32 encoded string: don't count the first padding char char twice. Note: '*str++' evaluates *str first and increases str later! Changes to previous version: - commit message only https://github.com/marschap/openldap/commit/435619ccd8be1b62f86db67643bca77… contrib/passwd/totp: support compiling using nettle Changes to previous version: - rewrite, concentrating the #ifdef's as much as possible Best Peter -- Peter Marschall peter(a)adpm.de

1 0

(ITS#8236) can't add keys to olc config for SSL
by michael.aldridge＠utdallas.edu 03 Sep '15

03 Sep '15

Full_Name: Michael Aldridge Version: @(#) $OpenLDAP: slapd (Ubuntu) (Aug 6 1515 23:14:45) $ buildd@lgw01-54:/build/openldap-VbUBZB/openldap-2.4.41+dfsg/debian/build/servers/slapd OS: Ubuntu 14.04.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.110.157.13) Attempting to add the olc configuration directives for SSL returns a ldap_modify: Other (e.g., implementation specific) error (80). The certs check out and everything make sense from an issuing standpoint, slapd just won't accept the cert configuration. I can provide additional logs or debug information upon request.

1 0

(ITS#8235) compiler warnings in smbk5pwd.c with nettle
by ryan＠openldap.org 02 Sep '15

02 Sep '15

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan smbk5pwd.c: In function 'lmhash': smbk5pwd.c:206:21: warning: passing argument 2 of 'nettle_des_set_key' from incompatible pointer type [-Wincompatible-pointer-types] des_set_key( &ctx, &key ); ^AIAIn file included from smbk5pwd.c:69:0: /usr/include/nettle/des.h:76:1: note: expected 'const uint8_t * {aka const unsigned char *}' but argument is of type 'unsigned char (*)[8]' des_set_key(struct des_ctx *ctx, const uint8_t *key); ^ (and several more) The openssl and gcrypt versions both used "&key" as well. It's correct for openssl, which takes a DES_cblock *. It's ambiguous for gcrypt, which takes a void *. It's wrong for nettle, which expects an unsigned char *. This is not a functional problem, since in all cases the pointer points at the beginning of the array. Fixing the warning does not change the output. smbk5pwd.c: In function 'nthash': smbk5pwd.c:249:36: warning: pointer targets in passing argument 3 of 'nettle_md4_update' differ in signedness [-Wpointer-sign] md4_update( &ctx, passwd->bv_len, passwd->bv_val ); ^ In file included from smbk5pwd.c:70:0: /usr/include/nettle/md4.h:69:1: note: expected 'const uint8_t * {aka const unsigned char *}' but argument is of type 'char *' md4_update(struct md4_ctx *ctx, ^ openssl and gcrypt both use void * here, nettle needs a cast (which should be safe). The remaining warnings are not nettle-specific. smbk5pwd.c: In function 'smbk5pwd_cf_func': smbk5pwd.c:915:14: warning: variable 'db' set but not used [-Wunused-but-set-variable] BackendDB db = *c->be; ^ Added in 29fab9c, apparently never used. Looks like cruft to me. Most likely didn't generate a warning with gcc prior to 4.6, due to the assignment just below. smbk5pwd.c: In function 'smbk5pwd_modules_init': smbk5pwd.c:968:2: warning: variable 'dummy_ad' set but not used [-Wunused-but-set-variable] dummy_ad; ^ The unused-but-set-variable warning is new in gcc 4.6 and there is a different no-op trick to suppress it in a portable way.

1 0

(ITS#8234) ppolicy_get can return a partly-populated struct
by ryan＠openldap.org 02 Sep '15

02 Sep '15

Full_Name: Ryan Tandy Version: master OS: URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan In ppolicy_get, if parsing fails after some attributes have already been loaded, we can return a partly populated structure, while the warning says "using default policy". In this case we should revert the entire structure to defaults before returning, IMO.

1 0

Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by ryan＠nardis.ca 02 Sep '15

02 Sep '15

On Tue, Aug 25, 2015 at 10:00:55PM +0000, ryan(a)nardis.ca wrote: >I reproduced this with current RE24. It seems to be caused by setting >pwdMaxAge to a very large value. ... or any other ppolicy attribute. >It seems like the crash does not happen if I bind as the rootdn, only >when using the admin DN. That was incorrect, bind DN doesn't matter. In ppolicy_get, the defaultpol label skips releasing the entry lock, so if it's called again, it deadlocks.

1 0

(ITS#8233) config parser accepts lines with unbalanced quotes
by hyc＠openldap.org 01 Sep '15

01 Sep '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.232.101.67) Submitted by: hyc We were tripped up by a misbehaving syncrepl consumer, that was always connecting as plain syncrepl even though it was intended to use delta-sync. The config had been pasted out of an email and the mail client had turned some (but not all) ASCII double-quotes into UTF-8 smart quotes. As such, the syncrepl stanza ended at logfilter="xxxxx and this wasn't flagged as an error because 1) the config parser doesn't care if double quotes get terminated or not 2) the syncrepl config parser doesn't look at logfilter if logbase wasn't configured. The logbase token was swallowed up in the logfilter. The parser should be fixed to reject lines with unbalanced quotes.

1 0

Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
by hyc＠symas.com 31 Aug '15

31 Aug '15

Peter Marschall wrote: > Hi, > > On Sunday, 30. August 2015 23:58:09 Howard Chu wrote: >>> Please note the run index i changed direction, which causes different >>> results because of >>=. >>> >>> In my tests [double checked before sending this mail] on an amd64 [little- >>> endian architecture], the patched version converts 0x3837363534333231 to >>> - "87654321" in the !WORDS_BIGENDIAN case [unchanged] >>> - "12345678" in the WORDS_BIGENDIAN case >>> [using the fact that 0x3N = "N" for 0 <= N <=9] >>> To me that looks correct. >>> >>> What issues did you see exactly? >> >> That is exactly wrong. Given any integer input the string should be >> identical regardless of endianness. It should be "87654321" in both cases. >> With your patch, hashes will be incompatible between different machine >> architectures. > > Please read my mail again! > I tested the WORDS_BIGENDIAN case on a *little-endian* architecture using the > same data as the !WORDS_BIGENDIAN case. > > In that case [i.e. testing on the "wrong-endian" architecture] the result *is > expected* to come out in reversed order. > Otherwise it would end-up in wrong order on the "right-endian" architecture. > > Do you agree? The point is that your patch *always* reverses the order of the bytes. On a big-endian machine the code should be a no-op. > > If you don't, please hint me to some code that allows me to check and fix my > code. > > Best > Peter > -- -- 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#8230) [PATCH] totp: bug fixes and improvements
by peter＠adpm.de 31 Aug '15

31 Aug '15

Hi, On Sunday, 30. August 2015 23:58:09 Howard Chu wrote: > > Please note the run index i changed direction, which causes different > > results because of >>=. > > > > In my tests [double checked before sending this mail] on an amd64 [little- > > endian architecture], the patched version converts 0x3837363534333231 to > > - "87654321" in the !WORDS_BIGENDIAN case [unchanged] > > - "12345678" in the WORDS_BIGENDIAN case > > [using the fact that 0x3N = "N" for 0 <= N <=9] > > To me that looks correct. > > > > What issues did you see exactly? > > That is exactly wrong. Given any integer input the string should be > identical regardless of endianness. It should be "87654321" in both cases. > With your patch, hashes will be incompatible between different machine > architectures. Please read my mail again! I tested the WORDS_BIGENDIAN case on a *little-endian* architecture using the same data as the !WORDS_BIGENDIAN case. In that case [i.e. testing on the "wrong-endian" architecture] the result *is expected* to come out in reversed order. Otherwise it would end-up in wrong order on the "right-endian" architecture. Do you agree? If you don't, please hint me to some code that allows me to check and fix my code. Best Peter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
by hyc＠symas.com 31 Aug '15

31 Aug '15

Peter Marschall wrote: >>> For the big-endian case, 'msg' wasn't set from 'tval' in generate(). >> >> This patch is wrong, as I commented on github. > Are you sure? > > Please note the run index i changed direction, which causes different results > because of >>=. > > In my tests [double checked before sending this mail] on an amd64 [little- > endian architecture], the patched version converts 0x3837363534333231 to > - "87654321" in the !WORDS_BIGENDIAN case [unchanged] > - "12345678" in the WORDS_BIGENDIAN case > [using the fact that 0x3N = "N" for 0 <= N <=9] > To me that looks correct. > > What issues did you see exactly? That is exactly wrong. Given any integer input the string should be identical regardless of endianness. It should be "87654321" in both cases. With your patch, hashes will be incompatible between different machine architectures. -- -- 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#8230) [PATCH] totp: bug fixes and improvements
by peter＠adpm.de 30 Aug '15

30 Aug '15

Hi Howard, thanks for the quick response. On Saturday, 29. August 2015 16:43:59 Howard Chu wrote: > > In function totp_b32_pton() > > - allow lowercase characters in encoded string too > > This patch is incorrect. You must guard toupper(), it is not guaranteed not > to distort non-lowercase characters. > > if (islower(x)) x = toupper(x) Thx, will include it in a reworked version. > > - allow padding to be omitted (totally, not only parts) > > Why? To allow using the keys encoded by other implementations that do not generate the padding (e.g. Perl's Convert::Base32). (e.g. in a mass-rollout that sets userPassword using LDIF) > > For the big-endian case, 'msg' wasn't set from 'tval' in generate(). > > This patch is wrong, as I commented on github. Are you sure? Please note the run index i changed direction, which causes different results because of >>=. In my tests [double checked before sending this mail] on an amd64 [little- endian architecture], the patched version converts 0x3837363534333231 to - "87654321" in the !WORDS_BIGENDIAN case [unchanged] - "12345678" in the WORDS_BIGENDIAN case [using the fact that 0x3N = "N" for 0 <= N <=9] To me that looks correct. What issues did you see exactly? > > In totp_b32_pton(), correctly count the number of '=' padding chars > > at the end of the base-32 encoded string. > > > > Note: '*str++' evaluates *str first and increases str later! > > The current code correctly decodes known test data. What is your test case? Hmm, strange. On my 64-bit Linux the original implementation failed to decode keys encoded by the original implementation's encoder. It took me quite some time to find the exact cause. I tested my patch with the official test vectors of chapter 10 of RFC 4648. With my patch the decoding in totp_b32_pton() is symmetric to encoding performed by totp_b32_ntop(), i.e. encoded strings decode to the original. In addition testing reproduced the official RFC4648 test cases in both directions, where the original version miscalculated the number of padding bytes so that "state + i" did not correctly add up to 8 as required for the "good" cases. I double checked before sending this mail: The original implementation fails to decode all test cases that have padding. E.g. BASE32("foo") = "MZXW6===" [RFC4648] In this example it counts the number of passing chars "=" to i = 4, which I do not consider correct. Would you mind posting your test cases? BTW: not insisting on padding would help here too ;-) > > * > > https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b7 > > 7c5ee8bb7b6> > > contrib/passwd/totp: support compiling using nettle > > The proper way to add this support is to add macros to hide all of the > differences in the initial ifdef block and not to add any additional ifdefs > anywhere in the main body of the code. I'll have a closer look. This patch tried to not touch the original OpenSSL version. With a more "homogenous patch" I'll need to make some slight changes to the macros for the OpenSSL version. I hope that's OK. Best PEter -- Peter Marschall peter(a)adpm.de

1 0

Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
by h.b.furuseth＠usit.uio.no 29 Aug '15

29 Aug '15

On 29/08/15 17:44, hyc(a)symas.com wrote: > This patch is incorrect. You must guard toupper(), it is not guaranteed not to > distort non-lowercase characters. Yes it is - for values in the range of unsigned char and EOF. Behavior is undefined for other values. The bug is failing to cast a char arguments to <ctype.h> functions to unsigned char. It's a common bug, so some implementations support char args. They cannot support that fully for (char)EOF, though. > if (islower(x)) x = toupper(x) That might hide the bug at times, maybe that's why you use it. But it's not reliable, islower too expects EOF or unsigned char. Use x = toupper((unsigned char)x).

1 0

(ITS#8232) potential crash from syncprov_op_abandon
by hyc＠openldap.org 29 Aug '15

29 Aug '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (73.15.219.210) Submitted by: hyc If a connection closes while syncprov_search_response is turning the current search op into a detached psearch op, connection_abandon() may get run on the connection while both the original and the detached copy of the op are present on the connection queue. detach_op will append the new copy onto the end of the connection's queue. connection_abandon will find the original op first, and call into syncprov_op_abandon. syncprov_op_abandon will cause the detached copy to be freed from the si->si_ops list (since both copies have same connid and msgid). If there has been no other activity on the connection, then the original op's o_next will be pointing to the detached copy. connection_abandon is using this o_next to iterate thru the connection's queue. After syncprov frees this copy, connection_abandon will probably SEGV. The fix is to prevent connection_abandon from calling abandon handlers on an op that has already been abandoned.

1 0

regression from ITS#8042
by hyc＠openldap.org 29 Aug '15

29 Aug '15

Full_Name: Howard Chu Version: 2.4.41 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (73.15.219.210) Submitted by: hyc presentlist_find() can SEGV if called when si->si_presentlist is NULL.

1 0

Re: (ITS#8230) [PATCH] totp: bug fixes and improvements
by hyc＠symas.com 29 Aug '15

29 Aug '15

peter(a)adpm.de wrote: > Full_Name: Peter Marschall > Version: 2.4.42 > OS: Linux > URL: https://github.com/marschap/openldap/tree/contrib-totp > Submission from: (NULL) (92.211.7.6) > > > Hi, > > I have written some bugfixes & flexibilizations for the TOTP contrib module. > > You can find them in the github branch: > https://github.com/marschap/openldap/tree/contrib-totp > > It differs from today's master by these commits: > * https://github.com/marschap/openldap/commit/d67bffc4a361cecfce69fb4d14edb33… > contrib/passwd/totp: flexibilize decoding key > > In function totp_b32_pton() > - allow lowercase characters in encoded string too This patch is incorrect. You must guard toupper(), it is not guaranteed not to distort non-lowercase characters. if (islower(x)) x = toupper(x) > - allow padding to be omitted (totally, not only parts) Why? > In function chk_totp() determine the space required to hold the decoded > key by calling totp_b32_pton() with a NULL argument for the target. > > * https://github.com/marschap/openldap/commit/435976d4f2468946bd0c5081ce7e2ae… > contrib/passwd/totp: fix the big-endian case > > For the big-endian case, 'msg' wasn't set from 'tval' in generate(). This patch is wrong, as I commented on github. > * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… > contrib/passwd/totp: fix decoding when padding is used > > In totp_b32_pton(), correctly count the number of '=' padding chars > at the end of the base-32 encoded string. > > Note: '*str++' evaluates *str first and increases str later! The current code correctly decodes known test data. What is your test case? > * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… > contrib/passwd/totp: support compiling using nettle The proper way to add this support is to add macros to hide all of the differences in the initial ifdef block and not to add any additional ifdefs anywhere in the main body of the code. > > that change the file > contrib/slapd-modules/passwd/totp/slapd-totp.c | 67 > ++++++++++++++++++B%B++++++++++++++++++++++++++++++++++++------------ > > I'd appreciate if you include them into OpenLDAP. > > The referenced patch files are derived from OpenLDAP Software. > All of the modifications to OpenLDAP Software represented in the following > patch(es) were developedy y Peter Marschall <peter(a)adpm.de>. > I have not assigned rights and/or interest in this work to any party. > > The referenced modifications to OpenLDAP Software are subject to the following > notice: > Copyright 2015 Peter Marschall > Redistribution and use in source and binary forms, with or without > modification, > are permitted only as authorized by the OpenLDAP Public License. > > Thanks in advance > Peter > > -- -- 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#8230) [PATCH] totp: bug fixes and improvements
by peter＠adpm.de 29 Aug '15

29 Aug '15

Full_Name: Peter Marschall Version: 2.4.42 OS: Linux URL: https://github.com/marschap/openldap/tree/contrib-totp Submission from: (NULL) (92.211.7.6) Hi, I have written some bugfixes & flexibilizations for the TOTP contrib module. You can find them in the github branch: https://github.com/marschap/openldap/tree/contrib-totp It differs from today's master by these commits: * https://github.com/marschap/openldap/commit/d67bffc4a361cecfce69fb4d14edb33… contrib/passwd/totp: flexibilize decoding key In function totp_b32_pton() - allow lowercase characters in encoded string too - allow padding to be omitted (totally, not only parts) In function chk_totp() determine the space required to hold the decoded key by calling totp_b32_pton() with a NULL argument for the target. * https://github.com/marschap/openldap/commit/435976d4f2468946bd0c5081ce7e2ae… contrib/passwd/totp: fix the big-endian case For the big-endian case, 'msg' wasn't set from 'tval' in generate(). * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… contrib/passwd/totp: fix decoding when padding is used In totp_b32_pton(), correctly count the number of '=' padding chars at the end of the base-32 encoded string. Note: '*str++' evaluates *str first and increases str later! * https://github.com/marschap/openldap/commit/04c15b7b1e44d4d3167577702a8b77c… contrib/passwd/totp: support compiling using nettle that change the file contrib/slapd-modules/passwd/totp/slapd-totp.c | 67 ++++++++++++++++++B%B++++++++++++++++++++++++++++++++++++------------ I'd appreciate if you include them into OpenLDAP. The referenced patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developedy y Peter Marschall <peter(a)adpm.de>. I have not assigned rights and/or interest in this work to any party. The referenced modifications to OpenLDAP Software are subject to the following notice: Copyright 2015 Peter Marschall Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. Thanks in advance Peter

1 0

Re: (ITS#8229) ldapsearch: report failed search results to stderr even when ldif == 0
by ryan＠nardis.ca 28 Aug '15

28 Aug '15

On Fri, Aug 28, 2015 at 11:23:50PM +0200, Hallvard Breien Furuseth wrote: >We should be wary of changing ldapsearch output, since >people parse it in scripts. Good point. Adding a stderr message to the existing stdout message would safer. Still not as safe as no change, of course. >I do find the output quirky and would have liked it different. >Maybe yet another option could clean it up, or an -o flag similar >to ldif-wrap. Yet another option... :)

1 0

(ITS#8229) ldapsearch: report failed search results to stderr even when ldif == 0
by ryan＠openldap.org 28 Aug '15

28 Aug '15

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Forwarded from a Debian bug report: <https://bugs.debian.org/474021> ldapsearch's error reporting currently does this: $ ldapsearch -x -b dc=nonexistent > /dev/null $ ldapsearch -x -b dc=nonexistent -L > /dev/null No such object (32) $ ldapsearch -x -b dc=nonexistent -LL > /dev/null No such object (32) $ ldapsearch -x -b dc=nonexistent -LLL > /dev/null No such object (32) The submitter would like it to report the failure to stderr in the default case as well. He suggested this change: - if( !ldif ) { - printf( "result: %d %s\n", err, ldap_err2string(err) ); - } else if ( err != LDAP_SUCCESS ) { - fprintf( stderr, "%s (%d)\n", ldap_err2string(err), err ); + if ( err != LDAP_SUCCESS %2%7{ + fprintf( stderr, "Search failed: %s (%d)\n", ldap_err2string(err), err ); + } + + if ( !ldif ) { + printf( "result: %d %s\n", err, ldap_err2string(err) ); } I would probably just flip the cases, and keep the "else" (i.e. not duplicate the output): - if( !ldif ) { - printf( _("result: %d %s\n"), err, ldap_err2string(err) ); - - } else if ( err != LDAP_SUCCESS ) { + if ( err != LDAP_SUCCESS ) { fprintf( stderr, "%s (%d)\n", ldap_r2ststring(err), err ); + } else if( !ldif ) { + printf( _("result: %d %s\n"), err, ldap_err2string(err) ); } Does either of these changes sound appropriate? The submitter also suggested sending the LDAP_SYNC Cancelled message to stderr: if ( cancel_msgid != -1 && cancel_msgid == ldap_msgid( msg ) ) { printf(_("Cancelled \n")); printf(_("cancel_msgid = %d\n"), cancel_msgid); I don't know that area very well, but at a glance it seems like stdout is probably more appropriate (so no change needed). Thanks.

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 28 Aug '15

28 Aug '15

More: MDB_CP_COMPACT would drop a new, empty main DB. (I.e. the main DB would lose its flags.) Compacting can verify that the written metapage claims enough DB pages. But not the opposite - it should not fail if it claims too many pages since that would mean we can't compact a DB which has suffered page leaks. We could detect that and re-write the metas at the end, if the user requests it and the file is seekable.

1 0

(ITS#8228) avoid clobbering a valid pid file
by ryan＠openldap.org 28 Aug '15

28 Aug '15

Full_Name: Ryan Tandy Version: master OS: Debian URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan Forwarding a feature request from <https://bugs.debian.org/375067>: It would be nice if slapd would notice an existing pid file pointing at a live process, and refuse to overwrite it. Starting slapd twice with the same pidfile is certainly user error, but it seems like it should be preventable.

1 0

RE: (ITS#8222) memory administration in ldap_parse_result()
by Lawrence.Newman＠alcatel-lucent.com 27 Aug '15

27 Aug '15

Providing an update: Not surprisingly, the actual memory leak was in our a= pplication software (error message allocated by ldap_parse_result() not fre= ed in unusual case). But our debugging/analysis tools continued to report = memory allocated but not freed even after the problem was fixed, and I beli= eve that was due to the issue I reported with how internal (library) memory= linked to the LDAP structure is allocated/freed by ldap_parse_result() (al= located while processing a response, but not freed until the next time the = connection associated with that LDAP structure is used). Larry Newman IHN 9H-401, x90882 lawrence.newman(a)alcatel-lucent.com -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: Tuesday, August 25, 2015 10:15 AM To: Newman, Lawrence H (Lawrence) Subject: Re: (ITS#8222) memory administration in ldap_parse_result() *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report = has been assigned the tracking number ITS#8222. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunte= ers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue repo= rt, you may do so by replying to this message. Note that any mail sent to = openldap-its(a)openldap.org with (ITS#8222) in the subject will automatically= be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#8222) You may follow the progress of this report by loading the following URL in = a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D8222 Please remember to retain your issue tracking number (ITS#8222) on any furt= her messages you send to us regarding this report. If you don't then you'l= l just waste our time and yours because we won't be able to properly track = the report. Please note that the Issue Tracking System is not intended to be used to se= ek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

Re: Re: (ITS#8223) Replication error when slave is down and insert on master are made
by quanah＠zimbra.com 27 Aug '15

27 Aug '15

--On Thursday, August 27, 2015 11:56 AM +0200 Frank Offermanns <Frank.Offermanns(a)caseris.de> wrote: > Hello, > > I have additional information. The problem is the entryCSN. > User 1, which got replicated has entryCSN: > 20150827083333.751721Z#000000#001#000000 > user 2, which got NOT replicated has entryCSN: > 20150827083333.119585Z#000000#001#000000, which seems to be in the past > user 3, replicated, 20150827083334.847604Z#000000#001#000000 > user 4, not replicated 20150827083334.228113Z#000000#001#000000, which > seems to be in the past > user 5, replicated 20150827083335.588191Z#000000#001#000000 > user 6, replicated 20150827083335.946835Z#000000#001#000000 > user 7 not replicated 20150827083335.282686Z#000000#001#000000, which > seems to be in the past > > So in previous posts I got the answer, that microseconds exact time > synchronization is only important with master master and concurrent > writes. But now it also seems to be important with delta-synrepl. > > So I suppose this ITS can be closed, since it is not a bug, but worked as > designed? > So how to get a good enough time synchronization with windows (since the > normal time synchronization of windows seems to be not enough)? > Of course, if you close the ITS I can ask this question again in the > technical list. Ah, yeah, all replication (delta-sync or regular syncrepl) absolutely requires tight time sync. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8227) syncprov should use more threads
by hyc＠openldap.org 27 Aug '15

27 Aug '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.87.222.79) Submitted by: hyc Currently a single background thread and output queue is used by syncprov to send persist messages to all consumers. A single slow consumer can block messages from being sent to other consumers. syncprov should be enhanced to use a separate queue and thread per consumer.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs