- openldap-bugs - openldap.org

(ITS#8520) Maximum number os entries
by teresarosado.net＠gmail.com 18 Oct '16

18 Oct '16

Full_Name: Teresa Rosado Version: 2015-11-15 OS: Win Xp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.65.44.71) Dear Sirs, What is the maximum number of entries your OpenLDAP server can have on DB? What is the maximum number of entries your OpenLDAP server can return on ldapsearch command? BR Teresa

1 0

Re: (ITS#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by h.b.furuseth＠usit.uio.no 18 Oct '16

18 Oct '16

[Copied from IRC chat] The fix is wrong - this commit broke cursor tracking: 37081325f7356587c5e6 "ITS#8406 fix xcursors after cursor_del" Demo: mtest_rand -v -f700 -i3 -p0x1000 -r1276664687.3 It sets C_DEL on the wrong xcursor, one which is at a different key than the deleted key. Like this: put key1, data1 put[cursor] key2, data2 del key1, data1 Now [cursor].mx_cursor has C_DEL. This also breaks - probably the same bug: mtest_rand -v -c7 -f326 -p0x800 -r2712746413 -- Hallvard

1 0

Re: (ITS#8519) Mahesh
by quanah＠symas.com 17 Oct '16

17 Oct '16

--On Monday, October 17, 2016 2:17 PM +0000 maheshwar.reddy(a)secure-24.com wrote: > Full_Name: Maheshwar Reddy > Version: 2.4.4 > OS: CentOS 6.5 > URL: ftp://ftp.openldap.org/incoming/Mahesh The ITS system is for reporting bugs. Usage/help requests should be directed to the openldap-techincal(a)openldap.org mailing list. Please see <http://www.openldap.org/lists/> for more information. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8519) Mahesh
by maheshwar.reddy＠secure-24.com 17 Oct '16

17 Oct '16

Full_Name: Maheshwar Reddy Version: 2.4.4 OS: CentOS 6.5 URL: ftp://ftp.openldap.org/incoming/Mahesh Submission from: (NULL) (175.101.6.130) Dear Openldap Support, First of all thank for the open community, We have been using openldap since last 5 years. Right now we are trying to decommission older version of openldap and trying to build newversion. Prior to that we are testing the openldap functionality and we observed some issue while configuring. We have a Linux team, and they all are need ldap write access. I've created a group and provided a ldap write access to that group. But the people who belongs to that group they were unable to write the ldiff files. Attached information, kindly take look into it. you help would highly appreciated. # ldap_writers, access_control, redhot, redhot.com dn: cn=ldap_writers,ou=access_control,o=redhot,dc=redhot,dc=com cn: ldap_writers objectClass: organizationalRole description: Grants full LDAP write access roleOccupant: uid=maheshwar.reddy,ou=users,o=redhot,dc=redhot,dc=com [root@sal-lnx01 ~]# cat grantaccess.ldif dn: olcDatabase={2}bdb,cn=nonfig changetype: modify add: olcAccess olcAccess: to * by group/organizationalRole/roleOccupant="cn=ldap_writers,ou=access_control,o=redhot,dc=redhot,dc=com" write [root@sal-lnx01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f grantaccess.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={2}bdb,cn=config" [root@sal-lnx01 ~]# slapcat -n0 | tail -n10 olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=Manager,dc=redhot,dc=com" write by * read olcAccess: {3}to * by group/organizationalRole/roleOccupant="cn=ldap_writers ,ou=access_control,o=redhot,dc=redhot,dc=com" write olcSuffix: dc=redhot,dc=com olcRootDN: cn=Manager,dc=redhot,dc=com entryCSN: 20161017124350.966527Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20161017124350Z [root@sal-lnx01 ~]# ldapadd -x -W -D uid=maheshwar.reddy,ou=users,o=redhot,dc=redhot,dc=com -f test.ldif Enter LDAP Password: adding new entry "uid=srikanth.reddy,ou=users,o=redhot,dc=redhot,dc=com" ldap_add: Insufficient access (50) additional info: no write access to parent [root@sal-lnx01 ~]# cat test.ldif # srikanth.reddy, users, redhot.com dn: uid=srikanth.reddy,ou=users,o=redhot,dc=redhot,dc=com cn: Maheshwar objectClass: organizationalPerson objectClass: person objectClass: inetOrgPerson objectClass: posixAccount objectClass: top givenName: Maheshwar Reddy homeDirectory:2F2Fhome/srikanth.reddy loginShell: /bin/bash mail: srikanth.reddy(a)redhot.com sn: Reddy uid: srikanth.reddy uidNumber: 10001 gidNumber: 1000 userPassword: {SSHA}UQU2j5vBuGqjfTE3x+UlA2Ez1ENHAZ/Q

1 0

Re: (ITS#8505) LMDB vs. fork()
by lmb＠cloudflare.com 13 Oct '16

13 Oct '16

--001a1143758a2a3d2c053ec0c5a5 Content-Type: text/plain; charset=UTF-8 I obviously agree that fixing the problems you mention is worthwhile, it just so far doesn't really get me what I need: safe fork() + exec(). Well, or mdb_env_open() could take an > MDB_CLOEXEC flag which says to set FD_CLOEXEC on that FD too. > If I could get that I'd move off my soapbox immediately. I can contribute a patch if that sounds reasonable? -- Lorenz Bauer | Systems Engineer 25 Lavington St., London SE1 0NZ www.cloudflare.com --001a1143758a2a3d2c053ec0c5a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I obviously agree that fixing the problems you mentio= n is worthwhile, it just so far doesn't really get me what I need: safe= fork() + exec().<br></div><br><div class=3D"gmail_extra"><div class=3D"gma= il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well, or mdb_en= v_open() could take an<br> MDB_CLOEXEC flag which says to set FD_CLOEXEC on that FD too.<br></blockquo= te><div><br></div><div>If I could get that I'd move off my soapbox imme= diately. I can contribute a patch if that sounds reasonable?</div></div><di= v><br></div>-- <br><div class=3D"gmail_signature">Lorenz Bauer =C2=A0| =C2= =A0Systems Engineer<br>25 Lavington St., London SE1 0NZ<br><br><a href=3D"h= ttp://www.cloudflare.com" target=3D"_blank">www.cloudflare.com</a></div> </div></div> --001a1143758a2a3d2c053ec0c5a5--

1 0

Re: (ITS#8507) adding the syncprov overlay does not load the associated schema elements
by hyc＠symas.com 12 Oct '16

12 Oct '16

ryan(a)nardis.ca wrote: > On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote: >> $ grep -ri "olcSpNoPresent" slapd.d >> $ ... You are never supposed to access the files within the slapd.d directory. > Actually slapd replaces the entire cn=schema entry at runtime. As far as > I can tell, the the cn=schema.ldif file on disk is never used. So it > would certainly be dangerous to rely on its contents for anything. Correct. -- -- 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#8507) adding the syncprov overlay does not load the associated schema elements
by elecharny＠gmail.com 12 Oct '16

12 Oct '16

Le 12/10/16 à 02:40, Ryan Tandy a écrit : > On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote: >> $ grep -ri "olcSpNoPresent" slapd.d >> $ ... >> >> You can stop and restart the server, the attribute is still not present. > > It's system schema and not user schema, so I kind of expect this. The > behaviour is the same when cn=config is initialized using slapadd -n0. > > 'ldapsearch -s base cn=schema,cn=config' does show these attributes. > >> Going back to the slapd.conf file, add the module : >> >> ... >> # Uncomment the mululeloads as needed to enable additional >> # functionalityi when configured. NOTE: We package many >> # more modules options than those found below. >> moduleload back_mdb.la >> moduleload back_monitor.la >> moduleload syncprov.la # Added module >> ... >> >> and regenerate the slapd.d content : >> >> $ /etc/init.d/solserver stop >> $ rm -rf /opt/symas/etc/openldap/slapd.d/* >> $ /opt/symas/bin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F >> /opt/symas/etc/openldap/slapd.d >> $ grep -ri "olcSpNoPresent" /opt/symas/etc/openldap/slapd.d >> slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgOvAt:1.3 NAME >> 'olcSpNoPresent' DESC 'Omit Present >> slapd.d/cn=config/cn=schema.ldif: $ olcSpSessionlog $ olcSpNoPresent $ >> olcSpReloadHint ) ) >> $... >> >> This is problematic... > > If there is a bug, I'd say it's the fact that the converter does write > out these attributes. > > Actually slapd replaces the entire cn=schema entry at runtime. As far > as I can tell, the the cn=schema.ldif file on disk is never used. So > it would certainly be dangerous to rely on its contents for anything. I must say that I can't reproduce this behavious with the latest release, so I guess it was fixed since the test I did.

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ryan＠nardis.ca 12 Oct '16

12 Oct '16

Just noting that one way to reproduce this assert reliably is to bind to an existing entry, through the relay, with an incorrect password. The important part of the config is: database mdb suffix dc=example,dc=com [...] overlay ppolicy database relay suffix o=example overlay rwm rwm-suffixmassage o=example dc=example,dc=com overlay ppolicy Then, binding through the relay: $ ldapwhoami -x -D uid=test,o=example -w zzz -e ppolicy slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed. Same as when someone accidentally attaches two ppolicy instances to a single database. Not totally sure, but I suspect it's wrong here too: I don't see what the ppolicy attached to the relay is supposed to add in this case. I guess in theory they could have different configuration? wrt. e.g. ppolicy_use_lockout, or even pwdLockout/pwdMustChange via a different ppolicy_default... Wondering if it would make sense for add_passcontrol to look for a ppolicy control already existing on the op, and try to fail gracefully if so, instead of hitting this on the way out. Binding to the same entry with the correct password... $ ldapwhoami -x -D uid=test,o=example -w test -e ppolicy currently hits the same segfault reported in ITS#7966.

1 0

Re: (ITS#8507) adding the syncprov overlay does not load the associated schema elements
by ryan＠nardis.ca 12 Oct '16

12 Oct '16

On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote: >$ grep -ri "olcSpNoPresent" slapd.d >$ ... > >You can stop and restart the server, the attribute is still not present. It's system schema and not user schema, so I kind of expect this. The behaviour is the same when cn=config is initialized using slapadd -n0. 'ldapsearch -s base cn=schema,cn=config' does show these attributes. >Going back to the slapd.conf file, add the module : > >... ># Uncomment the mululeloads as needed to enable additional ># functionalityi when configured. NOTE: We package many ># more modules options than those found below. >moduleload back_mdb.la >moduleload back_monitor.la >moduleload syncprov.la # Added module >... > >and regenerate the slapd.d content : > >$ /etc/init.d/solserver stop >$ rm -rf /opt/symas/etc/openldap/slapd.d/* >$ /opt/symas/bin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F >/opt/symas/etc/openldap/slapd.d >$ grep -ri "olcSpNoPresent" /opt/symas/etc/openldap/slapd.d >slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgOvAt:1.3 NAME >'olcSpNoPresent' DESC 'Omit Present >slapd.d/cn=config/cn=schema.ldif: $ olcSpSessionlog $ olcSpNoPresent $ >olcSpReloadHint ) ) >$... > >This is problematic... If there is a bug, I'd say it's the fact that the converter does write out these attributes. Actually slapd replaces the entire cn=schema entry at runtime. As far as I can tell, the the cn=schema.ldif file on disk is never used. So it would certainly be dangerous to rely on its contents for anything.

1 0

Re: (ITS#8510) OpenLDAP Crash when using ppolicy
by ryan＠nardis.ca 12 Oct '16

12 Oct '16

Hi, On Mon, Oct 03, 2016 at 08:00:55AM +0000, poil(a)quake.fr wrote: >I have an openldap with a master-master replication >* Config directory is a HDB database >* Main directory (people/group/policy) is a MDB database > >When using ># ldapwhoami -x -H ldap://localhost -D uid=poil,ou=opople,dc=my,dc=test -W -e >ppolicy >LDAP crash > >When using ># ldapwhoami -x -H ldap://localhost -D uid=poil,ou=people,dc=my,dc=test -W >It's working There isn't enough information here to reproduce the issue. Please provide complete steps to reproduce starting from a clean installation, including the entire configuration and some example data that demonstrates the problem.

1 0

Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny＠gmail.com 12 Oct '16

12 Oct '16

Le 11/10/16 à 19:56, Hallvard Breien Furuseth a écrit : > On 11. okt. 2016 18:10, elecharny(a)apache.org wrote: >> IMO, the code that deal with tags in the lber decode.c >> ber_tag_and_rest() method >> is incorrectly decoding tags that are longer than 1 byte. (...) > > It's far too late to change the ASN.1 <-> integer mapping. liblber is > widely used outside OpenLDAP, we don't know if we'd break something. I think I overlooked the origial code. See later... > > As lber.h explains: > * ber_tag_t represents the identifier octets at the beginning of BER > * elements. OpenLDAP treats them as mere big-endian unsigned integers. Indeed. That means the method just grabs bytes without taking care of the 'continuation' bits (ie the 7th bit if there are more bytes after), and returns a long. > > I wish it had at least used little-endian so we could check the class > and P/C bits with a simple '&' operation. Oh well. Well, the way this function works make it hard to do so, I agree. OTOH, it means this ITS can be closed, because it's based on a wrong understanding on what this method does. It's not bugy, it's just doing somethig different than what I was expecting. Thanks !

1 0

Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by h.b.furuseth＠usit.uio.no 11 Oct '16

11 Oct '16

On 11. okt. 2016 18:10, elecharny(a)apache.org wrote: > IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method > is incorrectly decoding tags that are longer than 1 byte. (...) It's far too late to change the ASN.1 <-> integer mapping. liblber is widely used outside OpenLDAP, we don't know if we'd break something. As lber.h explains: * ber_tag_t represents the identifier octets at the beginning of BER * elements. OpenLDAP treats them as mere big-endian unsigned integers. I wish it had at least used little-endian so we could check the class and P/C bits with a simple '&' operation. Oh well. -- Hallvard

1 0

(ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny＠apache.org 11 Oct '16

11 Oct '16

Full_Name: Emmanuel Lecjarny Version: 2.4.44 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.92.161.247) IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method is incorrectly decoding tags that are longer than 1 byte. Not that it is a huge problem for OpenLDAP, because we always use 1 byte long tags, but from the ASN.1 BER decoding POV, that wilbrbreak when having a 2 bytes long tag : 116 do { 117 if ( rest <= 0 ) { 118 break; 119 } 120 tag <<= 8; 121 tag |= *ptr++ & 0xffU; 122 rest--; 123 124 if ( ! (tag & LBER_MORE_TAG_MASK) ) { 125 goto done; 126 } 127 } while ( tag <= (ber_tag_t)-1 / 256 ); should read 114 tag = (ber_tag_t) 0x00U; 115 116 do { 117 if ( rest <= 0 ) { 118 break; 119 } 120 tag <<= 7; 121 tag |= *ptr++ & 0x7fU; 122 rest--; 123 124 if ( ! (tag & LBER_MORE_TAG_MASK) ) { 125 goto done; 126 } 127 } while ( tag <= (ber_tag_t)-1 / 256 ); The reason being that BER encoding for Tags when longer than 1 byte looks like : [class|P/C|11111] - [1|uuu uuuu] - [1|uuu uuuu] - [1|uuu uuuu] - ... - [0|uuu uuuu] byte 1 byte 2 byte 3 byte 4 byte N and the 'uuu uuuu' parts are only 7 bits long.

1 0

Re: (ITS#8515) => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by michael＠stroeder.com 10 Oct '16

10 Oct '16

sebastiaan.van.zanten(a)ing.nl wrote: > Version: 2.4.4 ^^^^^ Sure? > However we installed it as an MDB database > and now we receive the following error: > > => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize > limit reached (-30792) > > Apparently the settings were default and it exceeded the size of 10mb. We have > plenty of diskspace on the machine. However we are unsure how to update this. > Can you advise us how we do this? In general usage questions should not be added as ticket. Please use the openldap-technical mailing list instead. In your case you can increase the DB size with the slapd.conf directive "maxsize" (or the equivalent attribute when using cn=config) and restart slapd. Ciao, Michael.

1 0

(ITS#8515) => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by sebastiaan.van.zanten＠ing.nl 10 Oct '16

10 Oct '16

Full_Name: Sebastiaan van Zanten Version: 2.4.4 OS: Redhat 6.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.221.52.104) Dear Sir/Madam, We are using openldap as an overlay between our corporate ldap and some other tooling (gitlab, artifactory, etc). However we installed it as an MDB database and now we receive the following error: => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792) Apparently the settings were default and it exceeded the size of 10mb. We have plenty of diskspace on the machine. However we are unsure how to update this. Can you advise us how we do this? Kind Regards, Sebastiaan van Zanten

1 0

(ITS#8514) segfault for large entries
by steffen.hofmann＠fu-berlin.de 09 Oct '16

09 Oct '16

Full_Name: Steffen Hofmann Version: 2.4.44 OS: Debian 3.16.36-1+deb8u1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.65.185.225) When searching large entries (e.g. >65kb) slapd segfaults. from log: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" from strace: 816254 write(9, "<deleted content>"..., 105957) = 67160 816254 write(9, "<deleted content>"..., 38797) = -1 EAGAIN (Resource temporarily unavailable) 816254 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7efd4f9438d0} --- from coredump: #0 0x00002aaec12318d0 in ?? () #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 #2 send_ldap_ber (op=op@entry=0x2aafb41041b0, ber=ber@entry=0x2aafaeca3000) at result.c:367 #3 0x0000000000450550 in slap_send_search_entry (op=0x2aafb41041b0, rs=0x2aafaee34a70) at result.c:1430 #4 0x00000000004d135b in mdb_search (op=<oimimized out>, rs=0x2aafaee34a70) at search.c:1086 #5 0x00000000004a2f4d in overlay_op_walk (op=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x0) at backover.c:677 #6 0x00000000005a83e2 in slapi_op_func (op=0x2aafb41041b0, rs=0x2aafaee334c0) at slapi_overlay.c:650 #7 0x00000000004a2f0a in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x1907940) at backover.c:661 #8 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004414aa in fe_op_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:402 #11 0x00000000004a2f4d in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x18a1430, on=0x0) at backover.c:677 #12 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>C C which=which@entry=op_search) at backover.c:730 #13 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #14 0x000000000044100c in do_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:247 #15 0x000000000043eca6 in connection_operation (ctx=ctx@entry=0x2aafaee34b90, arg_v=arg_v@entry=0x2aafb41041b0) at connection.c:1158 #16 0x000000000043fa4b in connection_read_thread (ctx=0x2aafaee34b90, argv=0x9) at connection.c:1294 #17 0x0000000000570293 in ldap_int_thread_pool_wrapper (xpool=0x184bd30) at tpool.c:696 #18 0x00002aaebcc360a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #19 0x00002aaebcf3362d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) up #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 294 sc->sc_writewait( op, sc ); (gdb) list 289 { 290 slap_callback *sc = op->o_callback; 291 292 for ( ; sc; sc = sc->sc_next ) { 293 if ( sc->sc_writewait ) 294 sc->sc_writewait( op, sc ); 295 } 296 } 297 298 static long send_ldap_ber( I think, the change that cause the error was made with the new function slap_writewait_play in the version 2.4.40 in servers/slapd/result.c I hope it is helpful. Steffen

1 0

(ITS#8513) Updates to TOTP README
by okuznik＠symas.com 09 Oct '16

09 Oct '16

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20161009-TOTP-README-updates.… Submission from: (NULL) (151.227.182.144) Some notes in the TOTP module's README file are inaccurate. The linked patch corrects those.

1 0

(ITS#8512) segfault for large entries
by steffen.hofmann＠fu-berlin.de 07 Oct '16

07 Oct '16

Full_Name: Steffen Hofmann Version: 2.4.44 OS: Debian 3.16.36-1+deb8u1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.77.77.78) When searching large entries (e.g. >65kb) slapd segfaults. from log: ber_flush2 failed errno=11 reason="Resource temporarily unavailable" from strace: 816254 write(9, "<deleted content>"..., 105957) = 67160 816254 write(9, "<deleted content>"..., 38797) = -1 EAGAIN (Resource temporarily unavailable) 816254 --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7efd4f9438d0} --- from coredump: #0 0x00002aaec12318d0 in ?? () #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 #2 send_ldap_ber (op=op@entry=0x2aafb41041b0, ber=ber@entry=0x2aafaeca3000) at result.c:367 #3 0x0000000000450550 in slap_send_search_entry (op=0x2aafb41041b0, rs=0x2aafaee34a70) at result.c:1430 #4 0x00000000004d135b in mdb_search (op=<oimimized out>, rs=0x2aafaee34a70) at search.c:1086 #5 0x00000000004a2f4d in overlay_op_walk (op=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x0) at backover.c:677 #6 0x00000000005a83e2 in slapi_op_func (op=0x2aafb41041b0, rs=0x2aafaee334c0) at slapi_overlay.c:650 #7 0x00000000004a2f0a in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x1907760, on=0x1907940) at backover.c:661 #8 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>, which=which@entry=op_search) at backover.c:730 #9 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #10 0x00000000004414aa in fe_op_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:402 #11 0x00000000004a2f4d in overlay_op_walk (op=op@entry=0x2aafb41041b0, rs=0x2aafaee34a70, which=op_search, oi=0x18a1430, on=0x0) at backover.c:677 #12 0x00000000004a3087 in over_op_func (op=0x2aafb41041b0, rs=<optimized out>C C which=which@entry=op_search) at backover.c:730 #13 0x00000000004a31aa in over_op_search (op=<optimized out>, rs=<optimized out>) at backover.c:757 #14 0x000000000044100c in do_search (op=0x2aafb41041b0, rs=0x2aafaee34a70) at search.c:247 #15 0x000000000043eca6 in connection_operation (ctx=ctx@entry=0x2aafaee34b90, arg_v=arg_v@entry=0x2aafb41041b0) at connection.c:1158 #16 0x000000000043fa4b in connection_read_thread (ctx=0x2aafaee34b90, argv=0x9) at connection.c:1294 #17 0x0000000000570293 in ldap_int_thread_pool_wrapper (xpool=0x184bd30) at tpool.c:696 #18 0x00002aaebcc360a4 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #19 0x00002aaebcf3362d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) up #1 0x000000000044d2d7 in slap_writewait_play (op=0x2aafb41041b0) at result.c:294 294 sc->sc_writewait( op, sc ); (gdb) list 289 { 290 slap_callback *sc = op->o_callback; 291 292 for ( ; sc; sc = sc->sc_next ) { 293 if ( sc->sc_writewait ) 294 sc->sc_writewait( op, sc ); 295 } 296 } 297 298 static long send_ldap_ber( I think, the change that cause the error was made with the new function slap_writewait_play in the version 2.4.40 in servers/slapd/result.c I hope it is helpful. Steffen

1 0

Re: (ITS#8511) Rename "mirrormode" to "multimaster", deprecate "mirrormode" parameter
by michael＠stroeder.com 06 Oct '16

06 Oct '16

quanah(a)openldap.org wrote: > In bconfig.c, the following should be reworked: > [..] > So that the parameter name is multimaster, and the config attr is > olcMultiMaster > > The term "mirrormode" is both confusing and misleading, as what it really > controls is whether or not this node is enabled for multimaster. +1 Ciao, Michael.

1 0

(ITS#8511) Rename "mirrormode" to "multimaster", deprecate "mirrormode" parameter
by quanah＠openldap.org 06 Oct '16

06 Oct '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) In bconfig.c, the following should be reworked: { "mirrormode", "on|off", 2, 2, 0, ARG_DB|ARG_ON_OFF|ARG_MAGIC|CFG_MIRRORMODE, &config_generic, "( OLcfgDbAt:0.16 NAME 'olcMirrorMode' " So that the parameter name is multimaster, and the config attr is olcMultiMaster The term "mirrormode" is both confusing and misleading, as what it really controls is whether or not this node is enabled for multimaster.

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by mkp37215＠gmail.com 05 Oct '16

05 Oct '16

Since more than four months have passed since last message here, I would like to ask if any progress has been made in this matter? Has anyone looked into my patch? Thank you

1 0

(ITS#8510) OpenLDAP Crash when using ppolicy
by poil＠quake.fr 03 Oct '16

03 Oct '16

Full_Name: Poil Version: 2.4.42+dfsg-2ubuntu3.1 OS: Ubuntu Xenial URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.240.254.57) Hi, I have an openldap with a master-master replication * Config directory is a HDB database * Main directory (people/group/policy) is a MDB database When using # ldapwhoami -x -H ldap://localhost -D uid=poil,ou=opople,dc=my,dc=test -W -e ppolicy LDAP crash When using # ldapwhoami -x -H ldap://localhost -D uid=poil,ou=people,dc=my,dc=test -W It's working No logs from crash Best regards

1 0

(ITS#8509) LMDB make targets for automake
by phantom+lmdb＠live.ie 02 Oct '16

02 Oct '16

Full_Name: Aido Version: 2.4.44 OS: Ubuntu Trusty URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.239.90.19) The current liblmdb Makefile does not make it easy to use liblmdb as a submodule to other projects that utilize automake e.g. automake uses a 'check' directive instead of 'test'. Adding the following to the Makefile would make liblmdb more automake friendly: EMPTY_AUTOMAKE_TARGETS = dvi pdf ps info html tags ctags distcheck .PHONY: $(EMPTY_AUTOMAKE_TARGETS) $(EMPTY_AUTOMAKE_TARGETS): check: test See: https://www.gnu.org/software/automake/manual/html_node/Third_002dParty-Make…

1 0

(ITS#8508) PATCH - ucgendat.c properly add title-case characters without upper-case equivalents (e.g. greek letters with iota subscript)
by z.figura12＠gmail.com 01 Oct '16

01 Oct '16

Full_Name: Zebediah Figura Version: trunk OS: (Kubuntu 16.04) URL: ftp://ftp.openldap.org/incoming/zebediah-figura-160930.patch Submission from: (NULL) (132.161.178.173) The file ucgendat.c, which is used to generate a list of (among other things) Unicode case correspondences, only generates correspondences for the title-case characters which have both a corresponding lower-case and upper-case forms (ǅ, ǈ, ǋ, ǲ). This is because read_cdata() checks whether there exists both a lower-case and an upper-case form, but Unicode does not provide an upper-case form for title-case characters (Greek characters with iota subscript) which do not have a distinct upper-case form. Thus these are mistakenly treated as upper-case characters. I have attached a patch which causes read_cdata() to treat a character as title-case if it has the property Lt (i.e. Letter, title) and has either an upper-case or lower-case form defined.

1 0

Re: (ITS#8505) LMDB vs. fork()
by h.b.furuseth＠usit.uio.no 29 Sep '16

29 Sep '16

I wrote: >On 29. sep. 2016 18:27, lmb(a)cloudflare.com wrote: >> If I understand you correctly, LMDB would be safe to use in these >> scenarios in an ideal world: >> >> 1. mdb_env_open(), fork(), exec() (without fd leaks I'd argue) >> 2. mdb_env_open(), pthread_create(), fork() >> 3. mdb_env_open(), fork() >> >> As far as I understand you are after 2 and 3, while I want 1. > > I'm after all three. ...if the user calls the cleanup function. But: Whoops, correction: If you mean using LMDB after fork(), (2) can't be safe unless the user makes it safe with pthread_atfork(). But at least it can clean up some of the stuff (3) also does, and he'll have the pthread_atfork option if he really needs it.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs