- openldap-bugs - openldap.org

Re: (ITS#8997) openldap-nssov/back ldap segfault
by hyc＠symas.com 28 Mar '19

28 Mar '19

This is a multi-part message in MIME format. --------------23850F02105CA62A388BCB06 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Pallissard, Matthew wrote: >> Actually now that I'm looking more closely at this output; the last line below looks interesting. >> >> (I probably should have tacked this on the backtrace) >> >> Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7ffff0c7c700 (LWP 341)] >> nssov_dn2uid (op=0x7ffff0c7b730, ni=0x555555a24420, dn=0x7fffe811eab0, uid=0x7fffe8002450) at passwd.c:137 >> 137 passwd.c: No such file or directory. >> > > Sorry, that was from the wrong output, see below for the correct snippet. > > Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff277f700 (LWP 170)] > nssov_dn2uid (op=0x7ffff277e730, ni=0x555555a24420, dn=0x7fffe4128430, uid=0x7fffe4002430) at passwd.c:137 > 137 passwd.c: No such file or directory. > > Matt Pallissard > Thanks that was a crucial piece. Please try this patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------23850F02105CA62A388BCB06 Content-Type: text/plain; charset=UTF-8; name="dif.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dif.txt" diff --git a/servers/slapd/back-ldap/search.c b/servers/slapd/back-ldap/search.c index 63345aed22..82e72aa8a7 100644 --- a/servers/slapd/back-ldap/search.c +++ b/servers/slapd/back-ldap/search.c @@ -1006,6 +1006,7 @@ retry: e = ldap_first_entry( lc->lc_ld, result ); if ( e == NULL ) { /* the entry exists, but it doesn't match the filter? */ + rc = LDAP_NO_RESULTS_RETURNED; goto cleanup; } --------------23850F02105CA62A388BCB06--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 28 Mar '19

28 Mar '19

--mb3a5envygzqum4d Content-Type: text/plain; charset=us-ascii Content-Disposition: inline > Actually now that I'm looking more closely at this output; the last line below looks interesting. > > (I probably should have tacked this on the backtrace) > > Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff0c7c700 (LWP 341)] > nssov_dn2uid (op=0x7ffff0c7b730, ni=0x555555a24420, dn=0x7fffe811eab0, uid=0x7fffe8002450) at passwd.c:137 > 137 passwd.c: No such file or directory. > Sorry, that was from the wrong output, see below for the correct snippet. Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff277f700 (LWP 170)] nssov_dn2uid (op=0x7ffff277e730, ni=0x555555a24420, dn=0x7fffe4128430, uid=0x7fffe4002430) at passwd.c:137 137 passwd.c: No such file or directory. Matt Pallissard --mb3a5envygzqum4d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJzYtgAKCRB1uof+t048 ST8nAP9UWBuG0358vqbQnGRxp4y4YMol81iU7UJswPBjPaBzgwD9HNk+aOAJJ1rn Czboi8ftlPsM0xnB34jmHtIYLz6EWww= =Vmu0 -----END PGP SIGNATURE----- --mb3a5envygzqum4d--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 28 Mar '19

28 Mar '19

--vpit5odwafhd55ju Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2019-03-28T06:54:35, Pallissard, Matthew wrote: > On 2019-03-21T15:13:30, Pallissard, Matthew wrote: > > On 2019-03-20T22:01:40, Howard Chu wrote: > > > matt(a)pallissard.net wrote: > > > > > > > 2. Turning the log level to 0 /seems/ to make the issue go away. I'= ll report > > > > back once I can confirm that. >=20 > Follow up, turning the log level to 0 does *not* prevent these segfaults. >=20 > Matt Pallissard Actually now that I'm looking more closely at this output; the last line be= low looks interesting. (I probably should have tacked this on the backtrace) =20 Thread 4 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff0c7c700 (LWP 341)] nssov_dn2uid (op=3D0x7ffff0c7b730, ni=3D0x555555a24420, dn=3D0x7fffe811eab0= , uid=3D0x7fffe8002450) at passwd.c:137 137 passwd.c: No such file or directory. Matt Pallissard --vpit5odwafhd55ju Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJzXNQAKCRB1uof+t048 SXioAQDKoJWdiIpuasjmkaDnSI/bPGhCdBEXuYQfyZV5pqe++AD9GvYTSddxicKP wD0noDfTRI7oS5heRZHOnYO/ZK83RQc= =djIS -----END PGP SIGNATURE----- --vpit5odwafhd55ju--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 28 Mar '19

28 Mar '19

--dtfibegrdp7hfoq4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2019-03-21T15:13:30, Pallissard, Matthew wrote: > On 2019-03-20T22:01:40, Howard Chu wrote: > > matt(a)pallissard.net wrote: > > > > > 2. Turning the log level to 0 /seems/ to make the issue go away. I'll report > > > back once I can confirm that. Follow up, turning the log level to 0 does *not* prevent these segfaults. Matt Pallissard --dtfibegrdp7hfoq4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJzSGQAKCRB1uof+t048 SWYnAQDjIXjPORzGof/8TpqzansV7PXn5pdMnRxU14gqMcXsrwD+LS2nEqUmslpE T4PWgWNKb0AY0eWcSNAj+klqAkolcAs= =8ONg -----END PGP SIGNATURE----- --dtfibegrdp7hfoq4--

1 0

(ITS#9000) memberOf value is lost when group DN is modified with only case change
by clement.oudot＠worteks.com 27 Mar '19

27 Mar '19

Full_Name: Clement OUDOT Version: 2.4.47 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.250.130.213) We use a very standard configuration with memberof overlay. The issue is very easy to reproduce : * Create a group with a user in an OpenLDAP server using memberof overlay * The user should now have the group DN in memberOf attribute * Rename the group to change its case, for example uppercase the first letter * The group has be renamed but was removed form user memberOf attribute The OpenLDAP log is the following: 5c9ba447 conn=1000 op=23 MODRDN dn="cn=memberoftest,ou=groups,dc=example,dc=com" 5c9ba447 conn=1000 op=23: memberof_value_modify DN="uid=coudot,ou=users,dc=example,dc=com" add memberOf="cn=memberofTEST,ou=groups,dc=example,dc=com" failed err=20 Seems it is because memberof try to add the new value before deleting the old one. As the values are the same when ignoring the case, the modification is rejected. I would say that doing the LDAP_SLIST_REMOVE before the LDAP_SLIST_INSERT_HEAD in memberof.c should be enough but I don't know if this is safe.

1 0

Re: (ITS#8999) telephoneNumberMatch crashed slapd
by hyc＠symas.com 26 Mar '19

26 Mar '19

thomassiegmund(a)gmx.de wrote: > Full_Name: Thomas Siegmund > Version: 2.4.47 > OS: OpenBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (2a02:8106:22a:4b02:e76f:90a1:5b27:161e) > > > When importing/saving the following certificate as a userCertificate;binary, > slapd crashes when calling dnX509Normalize. > > Files: > telephoneNumberMatch.der > telephoneNumberMatch.ldif > telephoneNumberMatch.llog > > Thanks for the report. Fixed now in git 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#8999) telephoneNumberMatch crashed slapd
by thomassiegmund＠gmx.de 26 Mar '19

26 Mar '19

Full_Name: Thomas Siegmund Version: 2.4.47 OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2a02:8106:22a:4b02:e76f:90a1:5b27:161e) When importing/saving the following certificate as a userCertificate;binary, slapd crashes when calling dnX509Normalize. Files: telephoneNumberMatch.der telephoneNumberMatch.ldif telephoneNumberMatch.llog

1 0

(ITS#8998) ldapi:// with SASL_NOCANON -> Local error (-2)
by michael＠stroeder.com 25 Mar '19

25 Mar '19

Full_Name: Michael Str.der Version: 2.4.47 OS: openSUSE Tumbleweed URL: Submission from: (NULL) (213.240.182.56) Adding line SASL_NOCANON on to my ~/.ldaprc causes ldapwhoami to fail like this: $ ldapwhoami -H ldapi:// -Y EXTERNAL ldap_sasl_interactive_bind_s: Local error (-2) Using the full LDAPI path name just works as expected: $ ldapwhoami -H ldapi://%2frun%2fslapd%2fldapi -Y EXTERNAL SASL/EXTERNAL authentication started SASL username: gidNumber=1000+uidNumber=1000,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn:cn=michael,dc=example,dc=com

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 25 Mar '19

25 Mar '19

--On Monday, March 25, 2019 9:51 PM +0530 abhishek negi <abhisheknegi684(a)gmail.com> wrote: > > > Hi Quanah, > > > We tried with 2.4.47 as well. Unfortunately still getting the same issue. You will need to provide the full configurations for each node, minus passwords to look any further. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 25 Mar '19

25 Mar '19

--0000000000008204140584ecc1ed Content-Type: text/plain; charset="UTF-8" Hi Quanah, We tried with 2.4.47 as well. Unfortunately still getting the same issue. Any further suggestions, please support On Mon 25 Mar, 2019, 7:11 PM Quanah Gibson-Mount <quanah(a)symas.com wrote: > --On Monday, March 25, 2019 2:55 PM +0530 abhishek negi > <abhisheknegi684(a)gmail.com> wrote: > > > > > Hi Team, > > > > > > I tried replication with version 2.4.44 and still facing the same issue. > > Can you help me with it. > > I clearly stated to use the latest release, which as of this moment is > 2.4.47. There was a major focus on fixing replication related bugs in the > 2.4.45 and 2.4.46 releases. You need to upgrade further. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --0000000000008204140584ecc1ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Hi Quanah,</div><div dir=3D"auto"> </div><div dir= =3D"auto">We tried with 2.4.47 as well. Unfortunately still getting the sam= e issue.</div><div dir=3D"auto"> </div><div dir=3D"auto">Any further sug= gestions, please support <div class=3D"gmail_quote" dir=3D"auto"><di= v dir=3D"ltr">On Mon 25 Mar, 2019, 7:11 PM Quanah Gibson-Mount <<a href= =3D"mailto:quanah@symas.com">quanah(a)symas.com</a> wrote: </div><blockquo= te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so= lid;padding-left:1ex">--On Monday, March 25, 2019 2:55 PM +0530 abhishek ne= gi <<a href=3D"mailto:abhisheknegi684@gmail.com" target=3D"_blank" rel=3D"n= oreferrer">abhisheknegi684(a)gmail.com</a>> wrote: > > Hi Team, > > > I tried replication with version 2.4.44 and still facing the same issu= e. > Can you help me with it. I clearly stated to use the latest release, which as of this moment is 2.4.47.=C2=A0 There was a major focus on fixing replication related bugs in= the 2.4.45 and 2.4.46 releases.=C2=A0 You need to upgrade further. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">http://www.symas.com</a>> </blockquote></div></div></div> --0000000000008204140584ecc1ed--

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 25 Mar '19

25 Mar '19

--On Monday, March 25, 2019 2:55 PM +0530 abhishek negi <abhisheknegi684(a)gmail.com> wrote: > > Hi Team, > > > I tried replication with version 2.4.44 and still facing the same issue. > Can you help me with it. I clearly stated to use the latest release, which as of this moment is 2.4.47. There was a major focus on fixing replication related bugs in the 2.4.45 and 2.4.46 releases. You need to upgrade further. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 25 Mar '19

25 Mar '19

--000000000000c9eebd0584e6f502 Content-Type: text/plain; charset="UTF-8" Hi Team, I tried replication with version 2.4.44 and still facing the same issue. Can you help me with it. On Tue 19 Mar, 2019, 11:58 PM abhishek negi <abhisheknegi684(a)gmail.com wrote: > Okay. > Thanks for the help and support. > Hope issue gets resolve after upgradation. > > Thanks, > Abhishek > > On Tue 19 Mar, 2019, 11:10 PM Quanah Gibson-Mount <quanah(a)symas.com wrote: > >> --On Tuesday, March 19, 2019 3:33 PM +0530 abhishek negi >> <abhisheknegi684(a)gmail.com> wrote: >> >> > >> > Hi Quanah, >> > >> > >> > If want to replicate Production (DC) site with Recovery (DR) site at >> real >> > time without any time lag which replication,DB and openldap verison >> would >> > be best to implement. >> >> I've already stated you need to upgrade to the current OpenLDAP release. >> I >> do not know how to make that any clearer. Additionally, it would >> literally >> defy physics to have instantaneous replication. There will always be >> some >> amount of delay. >> >> I would generally recommend the current OpenLDAP release using back-mdb >> as >> the database engine and delta-syncrepl using refreshAndPersist. >> >> --Quanah >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> >> >> --000000000000c9eebd0584e6f502 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hi Team,<div dir=3D"auto"> </div><div dir=3D"auto">I t= ried replication with version 2.4.44 and still facing the same issue.</div>= <div dir=3D"auto">Can you help me with it.</div></div> <div class=3D"gma= il_quote"><div dir=3D"ltr">On Tue 19 Mar, 2019, 11:58 PM abhishek negi <= <a href=3D"mailto:abhisheknegi684@gmail.com">abhisheknegi684(a)gmail.com</a> = wrote: </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e= x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"auto"><div>Okay.= </div><div dir=3D"auto">Thanks for the help and support.</div><div dir=3D"a= uto">Hope issue gets resolve after upgradation.</div><div dir=3D"auto"> = </div><div dir=3D"auto">Thanks,</div><div dir=3D"auto">Abhishek</div><div d= ir=3D"auto"> <div class=3D"gmail_quote" dir=3D"auto"><div dir=3D"ltr">On= Tue 19 Mar, 2019, 11:10 PM Quanah Gibson-Mount <<a href=3D"mailto:quana= h(a)symas.com" target=3D"_blank" rel=3D"noreferrer">quanah(a)symas.com</a> wrot= e: </div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo= rder-left:1px #ccc solid;padding-left:1ex">--On Tuesday, March 19, 2019 3:3= 3 PM +0530 abhishek negi <<a href=3D"mailto:abhisheknegi684@gmail.com" rel=3D"noreferrer noreferr= er" target=3D"_blank">abhisheknegi684(a)gmail.com</a>> wrote: > > Hi Quanah, > > > If want to replicate Production (DC) site with Recovery (DR) site at r= eal > time without any time lag which replication,DB and openldap verison wo= uld > be best to implement. I've already stated you need to upgrade to the current OpenLDAP release= .=C2=A0 I do not know how to make that any clearer.=C2=A0 Additionally, it would lite= rally defy physics to have instantaneous replication.=C2=A0 There will always be = some amount of delay. I would generally recommend the current OpenLDAP release using back-mdb as = the database engine and delta-syncrepl using refreshAndPersist. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com" rel=3D"noreferrer noreferrer noreferre= r" target=3D"_blank">http://www.symas.com</a>> </blockquote></div></div></div> </blockquote></div> --000000000000c9eebd0584e6f502--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 21 Mar '19

21 Mar '19

--hs6rsxv3pygoehyq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On 2019-03-20T22:01:40, Howard Chu wrote: > matt(a)pallissard.net wrote: > > > 2. Turning the log level to 0 /seems/ to make the issue go away. I'll report > > back once I can confirm that. > > That would imply the SEGV is specifically due to a NULL pointer being passed in a Debug message. > If that's true, you should be able to reproduce this using whatever accounts aren't fully populated > with POSIX attributes. > > > A note on this; We do have a good handful of 'service accounts' that don't > > have all of the posix attributes in active directory. As such those entries do > > spam the logs a bit. I have a backtrace I can submit. What's the proper way of doing so? As there is ldap info in it I'd rather not have it publicly accessable. Matt Pallissard --hs6rsxv3pygoehyq Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQTvIUMPApUGn6YFkXl1uof+t048SQUCXJQMhgAKCRB1uof+t048 SbqCAQDSEgiivcwR6cztHGogp+hn5+2pikvZ/djpH5XVkRBD7gD9EhqWRSW8QOeY yPjj8smWGuoO+nbF8VIoGm3Mtw4PCA8= =cG48 -----END PGP SIGNATURE----- --hs6rsxv3pygoehyq--

1 0

Re: (ITS#8997) openldap-nssov/back ldap segfault
by hyc＠symas.com 20 Mar '19

20 Mar '19

matt(a)pallissard.net wrote: > 2. Turning the log level to 0 /seems/ to make the issue go away. I'll report > back once I can confirm that. That would imply the SEGV is specifically due to a NULL pointer being passed in a Debug message. If that's true, you should be able to reproduce this using whatever accounts aren't fully populated with POSIX attributes. > A note on this; We do have a good handful of 'service accounts' that don't > have all of the posix attributes in active directory. As such those entries do > spam the logs a bit. -- -- 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#8997) openldap-nssov/back ldap segfault
by matt＠pallissard.net 20 Mar '19

20 Mar '19

Full_Name: Matthew Pallissard Version: 2.4.47 OS: Archlinux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (185.236.200.195) Hi, We're seeng a lot of segfaults on some of our busier HPC machines. These typically have hundreds of jobs landing on them at a given time. We use back-ldap with an nssov-overlay and pcache in front of Active Directory. This is Authorization only, authentication is handled via krb5. The relevant bits of slightly scrubbed config are at the bottom of this message. We notice two things; 1. this can be replicated semi-consistently; 1. stop slapd, ensure cache is empty 2. do something dumb like this > for i in {1..100}; do ./dumb.sh &; done > #!/bin/bash > # dumb.sh > while [[ 1 -ne 2 ]]; do > for i in $(getent passwd | cut -f 1 -d ':'); do > time id ${i} > done > done 3. start slapd 2. Turning the log level to 0 /seems/ to make the issue go away. I'll report back once I can confirm that. A note on this; We do have a good handful of 'service accounts' that don't have all of the posix attributes in active directory. As such those entries do spam the logs a bit. # config 2.4.47 dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib/openldap olcModuleLoad: pcache olcModuleLoad: nssov olcModuleLoad: back_ldap olcModuleLoad: back_mdb dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: dc=ad,dc=domain,dc=edu olcAddContentAcl: FALSE olcLastMod: FALSE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcRootDN: cn=ldap_rootdn,cn=config olcDbURI: "ldap://ad.domain.edu" olcDbStartTLS: none starttls=no olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="" crede ntials="" keepalive=0:0:0 olcDbIDAssertBind: mode=none flags=prescriptive,proxy-authz-non-critical bin dmethod=simple timeout=0 network-timeout=0 binddn="" credentials="" keepalive=0:0:0 olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: FALSE olcDbChaseReferrals: FALSE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 structuralObjectClass: olcLDAPConfig dn: olcOverlay={0}nssov,olcDatabase={1}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcNssOvConfig olcOverlay: {0}nssov olcNssSsd: group ldap:///dc=ad,dc=domain,dc=edu??sub?(objectClass=posi xGroup) olcNssSsd: passwd ldap:///dc=ad,dc=domain,dc=edu??sub?(objectClass=pos ixAccount) olcNssSsd: shadow ldap:///dc=ad,dc=domain,dc=edu??sub?(objectClass=sha dowAccount) olcNssMap: group uniqueMember member olcNssMap: passwd gecos title olcNssMap: passwd homeDirectory unixHomeDirectory olcNssPam: uid2dn olcNssPamMinUid: 0 olcNssPamMaxUid: 0 structuralObjectClass: olcNssOvConfig dn: olcOverlay={1}pcache,olcDatabase={1}ldap,cn=config objectClass: olcOverlayConfig objectClass: olcPcacheConfig olcOverlay: {1}pcache olcPcache: mdb 1000000 30 1000000 3600 olcPcacheAttrset: 0 uid userPassword uidNumber gidNumber gecos cn homeDirectory loginShell objectClass olcPcacheAttrset: 1 cn userPassword gidNumber memberUid objectClass member olcPcacheTemplate: "(&(objectclass=)(|(memberuid=)(member=)))" 1 3600 olcPcacheTemplate: "(&(objectclass=)(|(memberuid=)(uniquemember=)))" 1 3600 olcPcacheTemplate: "(&(objectclass=)(gidnumber=))" 1 3600 olcPcacheTemplate: "(&(objectclass=)(uidnumber=))" 0 3600 olcPcacheTemplate: "(&(objectclass=)(uid=))" 0 3600 olcPcacheTemplate: "(objectclass=)" 0 3600 olcPcacheTemplate: "(objectclass=)" 1 3600 olcPcachePosition: head olcPcacheMaxQueries: 10000000 olcPcachePersist: FALSE olcPcacheValidate: FALSE olcPcacheOffline: TRUE dn: olcDatabase={0}mdb,olcOverlay={1}pcache,olcDatabase={1}ldap,cn=config objectClass: olcMdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}mdb olcDbDirectory: /var/lib/openldap/openldap-data olcDbNoSync: FALSE olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber eq olcDbIndex: gidNumber eq olcDbIndex: memberUid eq olcDbIndex: sn pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: uniqueMember eq

1 0

(ITS#8996) Please supply a pkg-config file for libldap
by hugh.mcmaster＠outlook.com 20 Mar '19

20 Mar '19

Full_Name: Hugh McMaster Version: 2.4.47 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (60.224.220.43) Dear maintainer, Automated detection of openldap (libldap) is more laborious than it needs to be. pkg-config is comfortably available everywhere these days, making it very attractive for easier development and detection of headers and libraries. It would be very helpful if openldap could supply a pkg-config (.pc) files for libldap. If you need a patch for this, please let me know. Thank you

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 19 Mar '19

19 Mar '19

--000000000000e3b1ea058476ad43 Content-Type: text/plain; charset="UTF-8" Okay. Thanks for the help and support. Hope issue gets resolve after upgradation. Thanks, Abhishek On Tue 19 Mar, 2019, 11:10 PM Quanah Gibson-Mount <quanah(a)symas.com wrote: > --On Tuesday, March 19, 2019 3:33 PM +0530 abhishek negi > <abhisheknegi684(a)gmail.com> wrote: > > > > > Hi Quanah, > > > > > > If want to replicate Production (DC) site with Recovery (DR) site at real > > time without any time lag which replication,DB and openldap verison would > > be best to implement. > > I've already stated you need to upgrade to the current OpenLDAP release. > I > do not know how to make that any clearer. Additionally, it would > literally > defy physics to have instantaneous replication. There will always be some > amount of delay. > > I would generally recommend the current OpenLDAP release using back-mdb as > the database engine and delta-syncrepl using refreshAndPersist. > > --Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> > > --000000000000e3b1ea058476ad43 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div>Okay.</div><div dir=3D"auto">Thanks for the help and= support.</div><div dir=3D"auto">Hope issue gets resolve after upgradation.= </div><div dir=3D"auto"> </div><div dir=3D"auto">Thanks,</div><div dir= =3D"auto">Abhishek</div><div dir=3D"auto"> <div class=3D"gmail_quote" di= r=3D"auto"><div dir=3D"ltr">On Tue 19 Mar, 2019, 11:10 PM Quanah Gibson-Mou= nt <<a href=3D"mailto:quanah@symas.com">quanah(a)symas.com</a> wrote: <= /div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le= ft:1px #ccc solid;padding-left:1ex">--On Tuesday, March 19, 2019 3:33 PM +0= 530 abhishek negi <<a href=3D"mailto:abhisheknegi684@gmail.com" target=3D"_blank" rel=3D"n= oreferrer">abhisheknegi684(a)gmail.com</a>> wrote: > > Hi Quanah, > > > If want to replicate Production (DC) site with Recovery (DR) site at r= eal > time without any time lag which replication,DB and openldap verison wo= uld > be best to implement. I've already stated you need to upgrade to the current OpenLDAP release= .=C2=A0 I do not know how to make that any clearer.=C2=A0 Additionally, it would lite= rally defy physics to have instantaneous replication.=C2=A0 There will always be = some amount of delay. I would generally recommend the current OpenLDAP release using back-mdb as = the database engine and delta-syncrepl using refreshAndPersist. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">http://www.symas.com</a>> </blockquote></div></div></div> --000000000000e3b1ea058476ad43--

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 19 Mar '19

19 Mar '19

--On Tuesday, March 19, 2019 3:33 PM +0530 abhishek negi <abhisheknegi684(a)gmail.com> wrote: > > Hi Quanah, > > > If want to replicate Production (DC) site with Recovery (DR) site at real > time without any time lag which replication,DB and openldap verison would > be best to implement. I've already stated you need to upgrade to the current OpenLDAP release. I do not know how to make that any clearer. Additionally, it would literally defy physics to have instantaneous replication. There will always be some amount of delay. I would generally recommend the current OpenLDAP release using back-mdb as the database engine and delta-syncrepl using refreshAndPersist. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 19 Mar '19

19 Mar '19

--00000000000026eeeb05846ec7bd Content-Type: text/plain; charset="UTF-8" Hi Quanah, If want to replicate Production (DC) site with Recovery (DR) site at real time without any time lag which replication,DB and openldap verison would be best to implement. Earlier in version 2.4.38 , we used syncrepl +mirror mode replication but getting some time-lag. Please suggest On Mon 18 Mar, 2019, 7:18 PM Quanah Gibson-Mount <quanah(a)symas.com wrote: > --On Monday, March 18, 2019 2:24 PM +0000 abhisheknegi684(a)gmail.com wrote: > > > Full_Name: abhishek negi > > Version: 2.4.38 > > Hello, > > The 2.4.38 release is over 5 years old. There have literally been > hundreds > of bugs fixed with replication since that time. Please upgrade to a > current, modern release. No replication related issues will be examined > around such an ancient build of OpenLDAP. > > <https://www.openldap.org/software/release/changes.html> > > 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> > > --00000000000026eeeb05846ec7bd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto">Hi Quanah,<div dir=3D"auto"> </div><div dir=3D"auto">I= f want to replicate Production (DC) site with Recovery (DR) site at real ti= me without any time lag which replication,DB and openldap verison would be = best to implement.</div><div dir=3D"auto"> </div><div dir=3D"auto">Earli= er in version 2.4.38 , we used syncrepl +mirror mode replication but gettin= g some time-lag.</div><div dir=3D"auto"> </div><div dir=3D"auto">Please = suggest</div></div> <div class=3D"gmail_quote"><div dir=3D"ltr">On Mon 1= 8 Mar, 2019, 7:18 PM Quanah Gibson-Mount <<a href=3D"mailto:quanah@symas= .com">quanah(a)symas.com</a> wrote: </div><blockquote class=3D"gmail_quote= " style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">-= -On Monday, March 18, 2019 2:24 PM +0000 <a href=3D"mailto:abhisheknegi684@= gmail.com" target=3D"_blank" rel=3D"noreferrer">abhisheknegi684(a)gmail.com</= a> wrote: > Full_Name: abhishek negi > Version: 2.4.38 Hello, The 2.4.38 release is over 5 years old.=C2=A0 There have literally been hun= dreds of bugs fixed with replication since that time.=C2=A0 Please upgrade to a <= br> current, modern release.=C2=A0 No replication related issues will be examin= ed around such an ancient build of OpenLDAP. <<a href=3D"https://www.openldap.org/software/release/changes.html" rel= =3D"noreferrer noreferrer" target=3D"_blank">https://www.openldap.org/softw= are/release/changes.html</a>> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <<a href=3D"http://www.symas.com" rel=3D"noreferrer noreferrer" target= =3D"_blank">http://www.symas.com</a>> </blockquote></div> --00000000000026eeeb05846ec7bd--

1 0

Re: (ITS#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by quanah＠symas.com 18 Mar '19

18 Mar '19

--On Monday, March 18, 2019 2:24 PM +0000 abhisheknegi684(a)gmail.com wrote: > Full_Name: abhishek negi > Version: 2.4.38 Hello, The 2.4.38 release is over 5 years old. There have literally been hundreds of bugs fixed with replication since that time. Please upgrade to a current, modern release. No replication related issues will be examined around such an ancient build of OpenLDAP. <https://www.openldap.org/software/release/changes.html> 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#8995) OpenLdap (SyncRepl + Mirror Mode) issue
by abhisheknegi684＠gmail.com 18 Mar '19

18 Mar '19

Full_Name: abhishek negi Version: 2.4.38 OS: Linux 6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (182.77.13.52) PLease suggest a way to rectify the delay observed while replication. Below are the details: Replication used: SyncRepl + Mirror Mode (active-active setup) Replication Issue summary: Replication from DC-->DR is working fine with no time-lag b/w the packets/data. Facing issue with replication from DR--x-->DC setup. Sometimes, data/packets from DR flows with a delay to DC. This case doesn't follow any pattern, the setup works perfectly fine for 4-5 days, then suddenly packets/data flows with delay/time-lag. This delay is only observed from DR to DC. syncrepl rid=841 provider=ldap://<DC-IP>:389 bindmethod=simple binddn="cn=root,ou=test,o=test1,c=in" credentials=XXXXXXXXXXX searchbase="ou=test,o=test1,c=in" schemachecking=on attrs=* interval=00:00:00:10 type=refreshAndPersist retry="5 5 300 5" syncrepl rid=842 provider=ldap://<DR-IP>:389 bindmethod=simple binddn="cn=root,ou=test,o=test1,c=in" credentials=XXXXXXXXXXX searchbase="ou=test,o=test1,c=in" schemachecking=on attrs=* interval=00:00:00:10 type=refreshAndPersist retry="5 5 300 5" index entryCSN eq index entryUUID eq mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100

1 0

Re: (ITS#8992) LDAP Over TLS causing reload
by quanah＠symas.com 14 Mar '19

14 Mar '19

--On Thursday, March 14, 2019 10:47 AM +0000 soneshkumar.patel(a)tcs.com wrote: > Full_Name: Sonesh Patel > Version: 2.4.46 > OS: FreeBSD > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (45.249.219.13) > > > Hi, > > We have introduced LDAP client using OpenLDAP 2.4.46 on FreeBSD server > and we are using LibreSSL 2.3.6 to perform SSL operations. We are using > SSL_CTX_add_extra_chain_cert API to add CA certificate into SSL context > and connection to LDAP server is successful. OpenLDAP does not support LibreSSL. Any build of OpenLDAP compiled against LibreSSL was hacked into place and is not supported by the OpenLDAP project. If you can reproduce the same behavior using a supported TLS library (OpenSSL or GnuTLS), feel free to follow up. > We already sent mail to the forum (openldap-its(a)openldap.org) dated Fri 7 > Dec, 2018 but no response till now. The list is for traffic regarding existing ITSes. It is not a general email list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8992) LDAP Over TLS causing reload
by soneshkumar.patel＠tcs.com 14 Mar '19

14 Mar '19

Full_Name: Sonesh Patel Version: 2.4.46 OS: FreeBSD URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (45.249.219.13) Hi, We have introduced LDAP client using OpenLDAP 2.4.46 on FreeBSD server and we are using LibreSSL 2.3.6 to perform SSL operations. We are using SSL_CTX_add_extra_chain_cert API to add CA certificate into SSL context and connection to LDAP server is successful. But when client initiate 100 parallel secure connection per second towards LDAP server by calling ldap_start_tls_s() API. FreeBSD server is going for Reload due to software exception reported from SSL library. We are using blocking socket to send and receive LDAP queries. With non-secure LDAP connection, client able to initiate 900 parallel connection towards LDAP server per second, but with secure LDAP connection, FreeBSD server is going for reload at 100 parallel connection per second itself. Does anyone observed similar issues with secure LDAP connection? We already sent mail to the forum (openldap-its(a)openldap.org) dated Fri 7 Dec, 2018 but no response till now. Appreciate for your response on above query. Regards, Sonesh

1 0

Re: (ITS#8991) Error while trying to create database with attribute olcSuffix in internationalized UTF-8 DN format.
by hyc＠symas.com 13 Mar '19

13 Mar '19

uneex(a)ya.ru wrote: > Full_Name: Varnava Sergey > Version: openldap-sasl-server-2.4.47 > OS: FreeBSD 12.0-RELEASE > URL: > Submission from: (NULL) (86.62.75.82) > > > slapd configured to use cn=config > > I'm trying to create database under cn=config with olcSuffix attribute set to DN > with international UTF-8 characters. > > `cat adddb.ldif` > dn: olcDatabase=mdb > objectClass: olcDatabaseConfig > objectClass: olcMdbConfig > olcDatabase: mdb > olcSuffix:: ZGM90KHQvtC70L3Ri9GI0LrQvixkYz3QlNGD0YDQlNC+0LwK > olcRootDN:: Y2490JTQuNGA0LXQutGC0L7RgCxkYz3QodC+0LvQvdGL0YjQutC+LGRjPdCU0YPRgNCU0L7QvAo= > olcRootPW:: e1NTSEF9ZHVyc2VjcmV0Cg== > olcDbIndex: objectClass eq > olcDbDirectory: /var/db/openldap-data > > When doing `ldapadd -x -w secret -f /root/adddb.ldif` > I'm getting this error: > > adding new entry "olcDatabase=mdb" > ldap_add: Invalid syntax (21) > additional info: olcSuffix: value #0 invalid per syntax Your DN is using "dc" attribute, whose syntax doesn't allow the characters you're using. This is not an OpenLDAP bug, this ITS will be closed. -- -- 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#8991) Error while trying to create database with attribute olcSuffix in internationalized UTF-8 DN format.
by uneex＠ya.ru 13 Mar '19

13 Mar '19

Full_Name: Varnava Sergey Version: openldap-sasl-server-2.4.47 OS: FreeBSD 12.0-RELEASE URL: Submission from: (NULL) (86.62.75.82) slapd configured to use cn=config I'm trying to create database under cn=config with olcSuffix attribute set to DN with international UTF-8 characters. `cat adddb.ldif` dn: olcDatabase=mdb objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcSuffix:: ZGM90KHQvtC70L3Ri9GI0LrQvixkYz3QlNGD0YDQlNC+0LwK olcRootDN:: Y2490JTQuNGA0LXQutGC0L7RgCxkYz3QodC+0LvQvdGL0YjQutC+LGRjPdCU0YPRgNCU0L7QvAo= olcRootPW:: e1NTSEF9ZHVyc2VjcmV0Cg== olcDbIndex: objectClass eq olcDbDirectory: /var/db/openldap-data When doing `ldapadd -x -w secret -f /root/adddb.ldif` I'm getting this error: adding new entry "olcDatabase=mdb" ldap_add: Invalid syntax (21) additional info: olcSuffix: value #0 invalid per syntax Some debug from log file: ... Mar 13 20:32:00 ldap slapd[2181]: send_ldap_result: conn=1004 op=0 p=3 Mar 13 20:32:00 ldap slapd[2181]: send_ldap_response: msgid=1 tag=97 err=0 Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on: Mar 13 20:32:00 ldap slapd[2181]: 13r Mar 13 20:32:00 ldap slapd[2181]: Mar 13 20:32:00 ldap slapd[2181]: daemon: read activity on 13 Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: connection_get(13): got connid=1004 Mar 13 20:32:00 ldap slapd[2181]: connection_read(13): checking for input on id=1004 Mar 13 20:32:00 ldap slapd[2181]: op tag 0x68, time 1552498320 Mar 13 20:32:00 ldap slapd[2181]: conn=1004 op=1 do_add Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: waked Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: >>> dnPrettyNormal: <olcDatabase=mdb> Mar 13 20:32:00 ldap slapd[2181]: <<< dnPrettyNormal: <olcDatabase=mdb>, <olcDatabase=mdb> Mar 13 20:32:00 ldap slapd[2181]: >>> dnPretty: <dc=Солн<D1>M-^K<D1>M-^Hко,dc=<D0>M-^T<D1>M-^C<D1>M-^@<D0>M-^Tом > Mar 13 20:32:00 ldap slapd[2181]: send_ldap_result: conn=1004 op=1 p=3 Mar 13 20:32:00 ldap slapd[2181]: send_ldap_response: msgid=2 tag=105 err=21 Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on: Mar 13 20:32:00 ldap slapd[2181]: 13r Mar 13 20:32:00 ldap slapd[2181]: Mar 13 20:32:00 ldap slapd[2181]: daemon: read activity on 13 Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: connection_get(13): got connid=1004 Mar 13 20:32:00 ldap slapd[2181]: connection_read(13): checking for input on id=1004 Mar 13 20:32:00 ldap slapd[2181]: op tag 0x42, time 1552498320 Mar 13 20:32:00 ldap slapd[2181]: ber_get_next on fd 13 failed errno=0 (No error: 0) Mar 13 20:32:00 ldap slapd[2181]: connection_read(13): input error=-2 id=1004, closing. Mar 13 20:32:00 ldap slapd[2181]: connection_closing: readying conn=1004 sd=13 for close Mar 13 20:32:00 ldap slapd[2181]: connection_close: deferring conn=1004 sd=13 Mar 13 20:32:00 ldap slapd[2181]: conn=1004 op=2 do_unbind Mar 13 20:32:00 ldap slapd[2181]: connection_resched: attempting closing conn=1004 sd=13 Mar 13 20:32:00 ldap slapd[2181]: connection_close: conn=1004 sd=13 Mar 13 20:32:00 ldap slapd[2181]: daemon: removing 13 Mar 13 20:32:00 ldap slapd[2181]: daemon: activity on 1 descriptor Mar 13 20:32:00 ldap slapd[2181]: daemon: waked Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=6 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=7 active_threads=0 tvp=NULL Mar 13 20:32:00 ldap slapd[2181]: daemon: select: listen=8 active_threads=0 tvp=NULL ... Is it possible to solve this problem?

1 0

(ITS#7770) mdb_stat in cn=monitor
by michael＠stroeder.com 12 Mar '19

12 Mar '19

I'm currently testing this feature back-ported to RE24 branch. I noticed that these attributes are set to empty values: creatorsName: modifiersName: Rest of entry looks good: dn: cn=Database 1,cn=Databases,cn=Monitor objectClass: monitoredObject objectClass: olmMDBDatabase structuralObjectClass: monitoredObject cn: Database 1 creatorsName: modifiersName: createTimestamp: 20190312102553Z modifyTimestamp: 20190312102553Z monitoredInfo: mdb monitorIsShadow: FALSE namingContexts: cn=accesslog readOnly: FALSE monitorOverlay: noopsrch seeAlso: cn=Overlay 1,cn=Overlays,cn=Monitor seeAlso: cn=Backend 2,cn=Backends,cn=Monitor olmMDBPagesMax: 97656 olmMDBPagesUsed: 33695 olmMDBPagesFree: 88 olmMDBReadersMax: 126 olmMDBReadersUsed: 3 olmDbDirectory: /var/lib/ldap/accesslog/ entryDN: cn=Database 1,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE

1 0

(ITS#8990) accesslog overlay misses SLAP_MOD_SOFT mod ops
by hyc＠openldap.org 11 Mar '19

11 Mar '19

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.37.163) Submitted by: hyc The delta-sync consumer turns incoming delete modops with no value into Soft deletes, to avoid the need for an error check. The accesslog overlay is ignoring these modops.

1 0

Re: (ITS#8987) Dirty compile without -Wall and friends
by hyc＠symas.com 10 Mar '19

10 Mar '19

noloader(a)gmail.com wrote: > Full_Name: JW > Version: 2.4.47 > OS: Linux (Fedora 29, x86_64, fully patched) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (151.196.22.177) >=20 >=20 > I'm building OpenLDAP 2.4.47 from sources on Fedora 29, x86_64. These l= ook like > a valid complaints: All of these are already fixed in git. Most as part of ITS#8890, some fro= m other commits. >=20 > cc -g2 -O2 -fsanitize=3Dundefined -march=3Dnative -fPIC -I../../../inc= lude > -I../../../include -I.. -I./.. -I/usr/local/include -DNDEBUG -c ldif.c = -o > ldif.o > bconfig.c: In function =E2=80=98config_rename_one=E2=80=99: > bconfig.c:4487:38: warning: passing argument 3 of =E2=80=98ldap_bv2rdn=E2= =80=99 from > incompatible pointer type [-Wincompatible-pointer-types] > rc =3D ldap_bv2rdn( &e->e_name, &rDN, &text, LDAP_DN_FORMAT_LDAP ); > ^~~~~ > In file included from ../../include/portable.h:1171, > from bconfig.c:21: > ../../include/ldap.h:1711:9: note: expected =E2=80=98char **=E2=80=99 b= ut argument is of type > =E2=80=98const char **=E2=80=99 > char **next, > ~~~~~~~^~~~ > ../../include/ldap_cdefs.h:32:25: note: in definition of macro =E2=80=98= LDAP_P=E2=80=99 > # define LDAP_P(protos) protos > ^~~~~~ >=20 >=20 >=20 > bconfig.c: In function =E2=80=98config_build_entry=E2=80=99: > bconfig.c:6505:31: warning: passing argument 3 of =E2=80=98ldap_bv2rdn=E2= =80=99 from > incompatible pointer type [-Wincompatible-pointer-types] > rc =3D ldap_bv2rdn( rdn, &rDN, &text, LDAP_DN_FORMAT_LDAP ); > ^~~~~ > In file included from ../../include/portable.h:1171, > from bconfig.c:21: > ../../include/ldap.h:1711:9: note: expected =E2=80=98char **=E2=80=99 b= ut argument is of type > =E2=80=98const char **=E2=80=99 > char **next, > ~~~~~~~^~~~ > ../../include/ldap_cdefs.h:32:25: note: in definition of macro =E2=80=98= LDAP_P=E2=80=99 > # define LDAP_P(protos) protos > ^~~~~~ >=20 >=20 > cc -g2 -O2 -fsanitize=3Dundefined -march=3Dnative -fPIC -I../../include= -I. > -I./slapi -I. -I../../include -I/usr/local/include -DNDEBUG -c -o > backends.o backends.c > backend.c: In function =E2=80=98fe_acl_group=E2=80=99: > backend.c:1503:56: warning: comparison between pointer and zero charact= er > constant [-Wpointer-compare] > if ( ludp->lud_filter !=3D NULL && ludp->lud_filter !=3D '\0') { > ^~ > backend.c:1503:39: note: did you mean to dereference the pointer? > if ( ludp->lud_filter !=3D NULL && ludp->lud_filter !=3D '\0') { > ^ >=20 >=20 > cc -g2 -O2 -fsanitize=3Dundefined -march=3Dnative -fPIC -I../../../inc= lude > -I../../../include -I.. -I./.. -I. -I./../back-bdb -I/usr/local/include= -DNDEBUG > -c tools.c -o tools.o > In file included from ../../../include/portable.h:1171, > from init.c:17: > init.c: In function 'hdb_db_open': > ../back-bdb/proto-bdb.h:22:35: warning: passing argument 2 of > 'db->bdi_db->set_dup_compare' from incompatible pointer type > [-Wincompatible-pointer-types] > #define BDB_SYMBOL(x) LDAP_CONCAT(hdb_,x) > ^~~~ >=20 >=20 >=20 > syntax.c: In function =E2=80=98syn_add=E2=80=99: > syntax.c:222:33: warning: comparison between pointer and zero character= constant > [-Wpointer-compare] > if ( (*lsei)->lsei_values[0] =3D=3D '\0' > ^~ > syntax.c:222:9: note: did you mean to dereference the pointer? > if ( (*lsei)->lsei_values[0] =3D=3D '\0' > ^ > syntax.c:223:32: warning: comparison between pointer and zero character= constant > [-Wpointer-compare] > || (*lsei)->lsei_values[1] !=3D '\0' ) > ^~ > syntax.c:223:8: note: did you mean to dereference the pointer? > || (*lsei)->lsei_values[1] !=3D '\0' ) > ^ >=20 >=20 >=20 > cc -g2 -O2 -fsanitize=3Dundefined -march=3Dnative -fPIC -I../../include > -I../../include -I/usr/local/include -DNDEBUG -c -o slapd-addel.o > slapd-addel.c > slapd-addel.c: In function =E2=80=98main=E2=80=99: > slapd-addel.c:176:36: warning: comparison between pointer and zero char= acter > constant [-Wpointer-compare] > if (( attrs =3D=3D NULL ) || ( *attrs =3D=3D '\0' )) { > ^~ >=20 >=20 >=20 >=20 --=20 -- 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#8989) Undefined Behavior in id2entry.c
by hyc＠symas.com 10 Mar '19

10 Mar '19

noloader(a)gmail.com wrote: > Full_Name: JW > Version: 2.4.47 > OS: Linux (Fedora 29, x86_64, fully patched) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (151.196.22.177) > > > CFLAGS includes -fsanitize=undefined. These can be cleared with 1U << 31. > > id2entry.c:622:9: runtime error: left shift of 1 by 31 places cannot be > represented in type 'int' > id2entry.c:691:11: runtime error: left shift of 1 by 31 places cannot be > represented in type 'int' > id2entry.c:708:22: runtime error: left shift of 1 by 31 places cannot be > represented in type 'int' > id2entry.c:709:20: runtime error: left shift of 1 by 31 places cannot be > represented in type 'int' Fixed in git -- -- 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#8989) Undefined Behavior in id2entry.c
by noloader＠gmail.com 07 Mar '19

07 Mar '19

Full_Name: JW Version: 2.4.47 OS: Linux (Fedora 29, x86_64, fully patched) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.196.22.177) CFLAGS includes -fsanitize=undefined. These can be cleared with 1U << 31. id2entry.c:622:9: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' id2entry.c:691:11: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' id2entry.c:708:22: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' id2entry.c:709:20: runtime error: left shift of 1 by 31 places cannot be represented in type 'int'

1 0

(ITS#8988) Undefined Behavior in slapadd
by noloader＠gmail.com 07 Mar '19

07 Mar '19

Full_Name: JW Version: 2.4.47 OS: Linux (Fedora 29, x86_64, fully patched) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.196.22.177) I added -fsanitize=undefined to CFLAGS. >>>>> Starting test001-slapadd for mdb... running defines.sh Running slapadd to build slapd database... ../../../libraries/liblmdb/mdb.c:7544:26: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7545:3: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6046:8: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:2418:7: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6938:10: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6939:6: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6939:6: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7287:6: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7303:18: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7303:18: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7306:6: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7335:11: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7339:12: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7341:20: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7342:15: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 66 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7343:15: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7343:15: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7346:9: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7349:6: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7357:6: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6050:9: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6054:11: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6069:25: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 52 00 52 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6286:26: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6288:9: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6290:6: runtime error: member access within misaligned address 0x0000023fe67a for type 'struct MDB_page', which requires 8 byte alignment 0x0000023fe67a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ id2entry.c:622:9: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' ../../../libraries/liblmdb/mdb.c:6071:11: runtime error: member access within misaligned address 0x7f4a33564f9a for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a33564f9a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6075:13: runtime error: member access within misaligned address 0x7f4a33564f9a for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a33564f9a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6164:6: runtime error: member access within misaligned address 0x7f4a33564f9a for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a33564f9a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6242:9: runtime error: member access within misaligned address 0x0000024240f2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024240f2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6248:6: runtime error: member access within misaligned address 0x0000024240f2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024240f2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6785:19: runtime error: member access within misaligned address 0x00000242417a for type 'struct MDB_page', which requires 8 byte alignment 0x00000242417a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6786:6: runtime error: member access within misaligned address 0x00000242417a for type 'struct MDB_page', which requires 8 byte alignment 0x00000242417a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6681:7: runtime error: member access within misaligned address 0x00000242417a for type 'struct MDB_page', which requires 8 byte alignment 0x00000242417a: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:6712:10: runtime error: member access within misaligned address 0x00000242417a for type 'struct MDB_page', which requires 8 byte alignment 0x00000242417a: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 52 00 14 00 00 00 00 00 00 00 36 00 ^ ../../../libraries/liblmdb/mdb.c:7553:25: runtime error: member access within misaligned address 0x00000242313c for type 'struct MDB_page', which requires 8 byte alignment 0x00000242313c: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 00 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7291:9: runtime error: member access within misaligned address 0x00000242313c for type 'struct MDB_page', which requires 8 byte alignment 0x00000242313c: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 00 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7298:16: runtime error: member access within misaligned address 0x00000242313c for type 'struct MDB_page', which requires 8 byte alignment 0x00000242313c: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7298:16: runtime error: member access within misaligned address 0x00000242313c for type 'struct MDB_page', which requires 8 byte alignment 0x00000242313c: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7299:16: runtime error: member access within misaligned address 0x00000242313c for type 'struct MDB_page', which requires 8 byte alignment 0x00000242313c: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 12 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7299:16: runtime error: member access within misaligned address 0x00000242313c for type 'struct MDB_page', which requires 8 byte alignment 0x00000242313c: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 12 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:5172:34: runtime error: load of misaligned address 0x00000242314c for type 'size_t', which requires 8 byte alignment 0x00000242314c: note: pointer points here 12 00 2a 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 6d 70 6c 65 2c 64 63 3d 63 6f 6d 00 ^ ../../../libraries/liblmdb/mdb.c:5173:27: runtime error: load of misaligned address 0x00000242314c for type 'size_t', which requires 8 byte alignment 0x00000242314c: note: pointer points here 12 00 2a 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 6d 70 6c 65 2c 64 63 3d 63 6f 6d 00 ^ ../../../libraries/liblmdb/mdb.c:6087:34: runtime error: member access within misaligned address 0x7f4a3356bf12 for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a3356bf12: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6089:13: runtime error: member access within misaligned address 0x7f4a3356bf12 for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a3356bf12: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6093:15: runtime error: member access within misaligned address 0x7f4a3356bf12 for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a3356bf12: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:5282:10: runtime error: member access within misaligned address 0x7f4a3356bf12 for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a3356bf12: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:5288:8: runtime error: member access within misaligned address 0x7f4a3356bf12 for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a3356bf12: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:5302:6: runtime error: member access within misaligned address 0x7f4a3356bf12 for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a3356bf12: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:5322:11: runtime error: member access within misaligned address 0x7f4a3356bf12 for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a3356bf12: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6794:13: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6825:22: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6826:24: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6827:24: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6832:29: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6831:68: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6833:61: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6833:46: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:6834:18: runtime error: member access within misaligned address 0x0000024210c2 for type 'struct MDB_page', which requires 8 byte alignment 0x0000024210c2: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 42 00 14 00 00 00 00 00 00 00 26 00 ^ ../../../libraries/liblmdb/mdb.c:7336:31: runtime error: member access within misaligned address 0x000002421064 for type 'struct MDB_page', which requires 8 byte alignment 0x000002421064: note: pointer points here 00 00 00 00 0f 00 00 00 00 00 00 00 00 00 52 00 14 00 44 00 72 00 44 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7336:18: runtime error: member access within misaligned address 0x000002421064 for type 'struct MDB_page', which requires 8 byte alignment 0x000002421064: note: pointer points here 00 00 00 00 0f 00 00 00 00 00 00 00 00 00 52 00 14 00 44 00 72 00 44 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6778:17: runtime error: member access within misaligned address 0x000002422104 for type 'struct MDB_page', which requires 8 byte alignment 0x000002422104: note: pointer points here 9b ee 35 5f 10 00 00 00 00 00 00 00 08 00 72 00 14 00 24 00 02 00 00 00 00 00 00 00 03 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6779:10: runtime error: member access within misaligned address 0x000002422104 for type 'struct MDB_page', which requires 8 byte alignment 0x000002422104: note: pointer points here 9b ee 35 5f 10 00 00 00 00 00 00 00 08 00 72 00 14 00 24 00 02 00 00 00 00 00 00 00 03 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6779:10: runtime error: member access within misaligned address 0x000002422104 for type 'struct MDB_page', which requires 8 byte alignment 0x000002422104: note: pointer points here 9b ee 35 5f 10 00 00 00 00 00 00 00 08 00 72 00 14 00 24 00 02 00 00 00 00 00 00 00 03 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6829:41: runtime error: member access within misaligned address 0x000002429dd4 for type 'struct MDB_page', which requires 8 byte alignment 0x000002429dd4: note: pointer points here 00 96 de fd 0a 00 00 00 00 00 00 00 08 00 72 00 20 00 20 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6829:57: runtime error: member access within misaligned address 0x000002429dd4 for type 'struct MDB_page', which requires 8 byte alignment 0x000002429dd4: note: pointer points here 00 96 de fd 0a 00 00 00 00 00 00 00 08 00 72 00 20 00 20 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:5346:8: runtime error: member access within misaligned address 0x7f4a33565aaa for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a33565aaa: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 08 00 52 00 16 00 16 00 96 00 56 00 16 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:5347:11: runtime error: member access within misaligned address 0x7f4a33565aaa for type 'struct MDB_page', which requires 8 byte alignment 0x7f4a33565aaa: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 08 00 52 00 16 00 16 00 96 00 56 00 16 00 00 00 00 00 00 00 ^ Starting slapd on TCP/IP port 9011... Using ldapsearch to retrieve all the entries... Filtering ldapsearch results... Filtering original ldif used to create database... Comparing filter output... Running slapadd with unordered LDIF... ../../../libraries/liblmdb/mdb.c:7544:26: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7545:3: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6046:8: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:2418:7: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6938:10: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6939:6: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6939:6: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7287:6: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7303:18: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7303:18: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7306:6: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7335:11: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7339:12: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7341:20: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7342:15: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 76 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7343:15: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7343:15: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 10 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7346:9: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7349:6: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7357:6: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6050:9: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6054:11: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6069:25: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 12 00 62 00 62 00 00 00 00 00 00 00 00 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6286:26: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6288:9: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6290:6: runtime error: member access within misaligned address 0x0000020d339a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d339a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ id2entry.c:622:9: runtime error: left shift of 1 by 31 places cannot be represented in type 'int' ../../../libraries/liblmdb/mdb.c:6071:11: runtime error: member access within misaligned address 0x7f30b251af8a for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b251af8a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6075:13: runtime error: member access within misaligned address 0x7f30b251af8a for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b251af8a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6164:6: runtime error: member access within misaligned address 0x7f30b251af8a for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b251af8a: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6242:9: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6248:6: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6785:19: runtime error: member access within misaligned address 0x0000020f84ca for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f84ca: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6786:6: runtime error: member access within misaligned address 0x0000020f84ca for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f84ca: note: pointer points here 00 00 00 00 03 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6681:7: runtime error: member access within misaligned address 0x0000020f84ca for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f84ca: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:6712:10: runtime error: member access within misaligned address 0x0000020f84ca for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f84ca: note: pointer points here 00 00 00 00 0a 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 62 00 14 00 00 00 00 00 00 00 46 00 ^ ../../../libraries/liblmdb/mdb.c:7553:25: runtime error: member access within misaligned address 0x0000020f74ec for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74ec: note: pointer points here 9b ee 35 5f 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 00 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7291:9: runtime error: member access within misaligned address 0x0000020f74ec for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74ec: note: pointer points here 9b ee 35 5f 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 00 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7298:16: runtime error: member access within misaligned address 0x0000020f74ec for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74ec: note: pointer points here 9b ee 35 5f 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7298:16: runtime error: member access within misaligned address 0x0000020f74ec for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74ec: note: pointer points here 9b ee 35 5f 0b 00 00 00 00 00 00 00 08 00 72 00 10 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7299:16: runtime error: member access within misaligned address 0x0000020f74ec for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74ec: note: pointer points here 9b ee 35 5f 0b 00 00 00 00 00 00 00 08 00 72 00 12 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:7299:16: runtime error: member access within misaligned address 0x0000020f74ec for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74ec: note: pointer points here 9b ee 35 5f 0b 00 00 00 00 00 00 00 08 00 72 00 12 00 30 00 01 00 00 00 00 00 00 00 01 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:5172:34: runtime error: load of misaligned address 0x0000020f74fc for type 'size_t', which requires 8 byte alignment 0x0000020f74fc: note: pointer points here 12 00 2a 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 74 2c 64 63 3d 65 78 61 6d 70 6c 65 ^ ../../../libraries/liblmdb/mdb.c:5173:27: runtime error: load of misaligned address 0x0000020f74fc for type 'size_t', which requires 8 byte alignment 0x0000020f74fc: note: pointer points here 12 00 2a 00 01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 74 2c 64 63 3d 65 78 61 6d 70 6c 65 ^ ../../../libraries/liblmdb/mdb.c:6778:17: runtime error: member access within misaligned address 0x0000020f74c4 for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74c4: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 14 00 24 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6779:10: runtime error: member access within misaligned address 0x0000020f74c4 for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74c4: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 14 00 24 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6779:10: runtime error: member access within misaligned address 0x0000020f74c4 for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f74c4: note: pointer points here 00 96 de fd 0b 00 00 00 00 00 00 00 08 00 72 00 14 00 24 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6087:34: runtime error: member access within misaligned address 0x7f30b2525eee for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b2525eee: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6089:13: runtime error: member access within misaligned address 0x7f30b2525eee for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b2525eee: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6093:15: runtime error: member access within misaligned address 0x7f30b2525eee for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b2525eee: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:5282:10: runtime error: member access within misaligned address 0x7f30b2525eee for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b2525eee: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:5288:8: runtime error: member access within misaligned address 0x7f30b2525eee for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b2525eee: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:5302:6: runtime error: member access within misaligned address 0x7f30b2525eee for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b2525eee: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:5322:11: runtime error: member access within misaligned address 0x7f30b2525eee for type 'struct MDB_page', which requires 8 byte alignment 0x7f30b2525eee: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6794:13: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6825:22: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6826:24: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6827:24: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6832:29: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6831:68: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6833:61: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6833:46: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:6834:18: runtime error: member access within misaligned address 0x0000020f842e for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f842e: note: pointer points here 00 00 00 00 0e 00 00 00 00 00 00 00 00 00 52 00 14 00 14 00 46 00 14 00 00 00 00 00 00 00 2a 00 ^ ../../../libraries/liblmdb/mdb.c:7336:31: runtime error: member access within misaligned address 0x0000020f833a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f833a: note: pointer points here 00 00 00 00 04 00 00 00 00 00 00 00 00 00 52 00 14 00 42 00 74 00 42 00 00 00 00 00 00 0b 6f 75 ^ ../../../libraries/liblmdb/mdb.c:7336:18: runtime error: member access within misaligned address 0x0000020f833a for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f833a: note: pointer points here 00 00 00 00 04 00 00 00 00 00 00 00 00 00 52 00 14 00 42 00 74 00 42 00 00 00 00 00 00 0b 6f 75 ^ ../../../libraries/liblmdb/mdb.c:7365:5: runtime error: null pointer passed as argument 2, which is declared to never be null ../../../libraries/liblmdb/mdb.c:6829:41: runtime error: member access within misaligned address 0x0000020d33a4 for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d33a4: note: pointer points here 00 96 de fd 08 00 00 00 00 00 00 00 08 00 72 00 18 00 18 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:6829:57: runtime error: member access within misaligned address 0x0000020d33a4 for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d33a4: note: pointer points here 00 96 de fd 08 00 00 00 00 00 00 00 08 00 72 00 18 00 18 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:5304:10: runtime error: member access within misaligned address 0x0000020d335c for type 'struct MDB_page', which requires 8 byte alignment 0x0000020d335c: note: pointer points here 00 96 de fd 0a 00 00 00 00 00 00 00 08 00 72 00 18 00 38 00 01 00 00 00 00 00 00 00 02 00 00 00 ^ ../../../libraries/liblmdb/mdb.c:5346:8: runtime error: member access within misaligned address 0x0000020f64bc for type 'struct MDB_page', which requires 8 byte alignment 0x0000020f64bc: note: pointer points here 00 96 de fd 09 00 00 00 00 00 00 00 08 00 72 00 1e 00 26 00 01 00 00 00 00 00 00 00 02 00 00 00 ^

1 0

(ITS#8987) Dirty compile without -Wall and friends
by noloader＠gmail.com 07 Mar '19

07 Mar '19

Full_Name: JW Version: 2.4.47 OS: Linux (Fedora 29, x86_64, fully patched) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (151.196.22.177) I'm building OpenLDAP 2.4.47 from sources on Fedora 29, x86_64. These look like a valid complaints: cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../../include -I../../../include -I.. -I./.. -I/usr/local/include -DNDEBUG -c ldif.c -o ldif.o bconfig.c: In function config_rename_one: bconfig.c:4487:38: warning: passing argument 3 of ldap_bv2rdn from incompatible pointer type [-Wincompatible-pointer-types] rc = ldap_bv2rdn( &e->e_name, &rDN, &text, LDAP_DN_FORMAT_LDAP ); ^~~~~ In file included from ../../include/portable.h:1171, from bconfig.c:21: ../../include/ldap.h:1711:9: note: expected char ** but argument is of type const char ** char **next, ~~~~~~~^~~~ ../../include/ldap_cdefs.h:32:25: note: in definition of macro LDAP_P # define LDAP_P(protos) protos ^~~~~~ bconfig.c: In function config_build_entry: bconfig.c:6505:31: warning: passing argument 3 of ldap_bv2rdn from incompatible pointer type [-Wincompatible-pointer-types] rc = ldap_bv2rdn( rdn, &rDN, &text, LDAP_DN_FORMAT_LDAP ); ^~~~~ In file included from ../../include/portable.h:1171, from bconfig.c:21: ../../include/ldap.h:1711:9: note: expected char ** but argument is of type const char ** char **next, ~~~~~~~^~~~ ../../include/ldap_cdefs.h:32:25: note: in definition of macro LDAP_P # define LDAP_P(protos) protos ^~~~~~ cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../include -I. -I./slapi -I. -I../../include -I/usr/local/include -DNDEBUG -c -o backends.o backends.c backend.c: In function fe_acl_group: backend.c:1503:56: warning: comparison between pointer and zero character constant [-Wpointer-compare] if ( ludp->lud_filter != NULL && ludp->lud_filter != '\0') { ^~ backend.c:1503:39: note: did you mean to dereference the pointer? if ( ludp->lud_filter != NULL && ludp->lud_filter != '\0') { ^ cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../../include -I../../../include -I.. -I./.. -I. -I./../back-bdb -I/usr/local/include -DNDEBUG -c tools.c -o tools.o In file included from ../../../include/portable.h:1171, from init.c:17: init.c: In function 'hdb_db_open': ../back-bdb/proto-bdb.h:22:35: warning: passing argument 2 of 'db->bdi_db->set_dup_compare' from incompatible pointer type [-Wincompatible-pointer-types] #define BDB_SYMBOL(x) LDAP_CONCAT(hdb_,x) ^~~~ syntax.c: In function syn_add: syntax.c:222:33: warning: comparison between pointer and zero character constant [-Wpointer-compare] if ( (*lsei)->lsei_values[0] == '\0' ^~ syntax.c:222:9: note: did you mean to dereference the pointer? if ( (*lsei)->lsei_values[0] == '\0' ^ syntax.c:223:32: warning: comparison between pointer and zero character constant [-Wpointer-compare] || (*lsei)->lsei_values[1] != '\0' ) ^~ syntax.c:223:8: note: did you mean to dereference the pointer? || (*lsei)->lsei_values[1] != '\0' ) ^ cc -g2 -O2 -fsanitize=undefined -march=native -fPIC -I../../include -I../../include -I/usr/local/include -DNDEBUG -c -o slapd-addel.o slapd-addel.c slapd-addel.c: In function main: slapd-addel.c:176:36: warning: comparison between pointer and zero character constant [-Wpointer-compare] if (( attrs == NULL ) || ( *attrs == '\0' )) { ^~

1 0

(ITS#8986) [PATCH] Fix union semun undefined from FreeBSD 12 onward
by khng300＠gmail.com 05 Mar '19

05 Mar '19

Full_Name: Ka Ho Ng Version: mdb.master OS: FreeBSD 12.0-RELEASE URL: ftp://ftp.openldap.org/incoming/Ka-Ho-Ng-190306.patch Submission from: (NULL) (2001:470:fa95:1300::1) Starting from __FreeBSD_version 1200059 union semun definition was removed from userspace headers in order to comply with POSIX. In order to resurrect the defintion we need to define _WANT_SEMUN before including sys/sem.h for __FreeBSD_version >= 1200059. I tried to touch as small amount of code as possible here to avoid interfering with other platforms I do not use.

1 0

Re: (ITS#8973) Error with domainScope control when using C# LDAP API
by clement.oudot＠worteks.com 05 Mar '19

05 Mar '19

Le 06/02/2019 à 14:16, clement.oudot(a)worteks.com a écrit : > Le 06/02/2019 Ã 12:57, hyc(a)symas.com a Ã©critÂ : >> hyc(a)symas.com wrote: >>> clement.oudot(a)worteks.com wrote: >>>> Full_Name: Clement OUDOT >>>> Version: 2.4.47 >>>> OS: GNU/Linux >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (81.250.130.213) >>>> >>>> >>>> Hello, >>>> >>>> after upgrading from 2.4.46 to 2.4.47, this C# code does not work anymore : >>> The code in controls.c is correct. The DomainScope control does not take a value, >>> so the value is required to be NULL. >> Microsoft spec https://msdn.microsoft.com/en-us/library/cc223348.aspx >> >> "When sending this control to the DC, the controlValue field of the Control structure is omitted." >> > Thanks a lot for your feedback, I will try to understand with the C# > code is sending a value inside the control. For the record, the bug seems to be inside powershell and the API "system.DirectoryServices.DirectorySearcher" which is sending the control. To solve this, you need to use another API: "System.DirectoryServices.Protocols" See https://docs.microsoft.com/fr-fr/dotnet/api/system.directoryservices.protoc… -- Clément Oudot | Identity Solutions Manager clement.oudot(a)worteks.com Worteks | https://www.worteks.com

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by quanah＠symas.com 28 Feb '19

28 Feb '19

--On Wednesday, February 20, 2019 2:30 PM -0500 Vern Smith <vsmith(a)interlinknetworks.com> wrote: > > The attached files are derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following patch(es) > were developed by Interlink Networks LLC. Interlink Networks LLC has not > assigned rights and/or interest in this work to any party. I, Vernon > Smith am authorized by Interlink Networks LLC, my employer, to release > this work under the following terms. Thanks! This has been applied to git master. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8985) Fix of an assertion error in back-asyncmeta during restart of remote target
by quanah＠symas.com 28 Feb '19

28 Feb '19

--On Thursday, February 28, 2019 5:00 PM +0000 nivanova(a)symas.com wrote: > Full_Name: Nadezhda Ivanova > Version: 2.5 > OS: Ubuntu 18.04 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (93.152.142.241) > > > The attached patches provide a fix for a problem, reported by a customer: Thanks for the report, applied to git master. Warm 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#8985) Fix of an assertion error in back-asyncmeta during restart of remote target
by nivanova＠symas.com 28 Feb '19

28 Feb '19

Full_Name: Nadezhda Ivanova Version: 2.5 OS: Ubuntu 18.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.152.142.241) The attached patches provide a fix for a problem, reported by a customer: Occasionally, when the remote target of an asyncmeta database is restarted, slapd crashes with assertion error in connection_init: assert( c->c_struct_state == SLAP_C_UNUSED ); The issue occurs very rarely, but I managed to reproduce it. It was caused by the fact that on socket error, try_read1msg would close the LDAP connection (ld) to that target, making the fd available to be used again for another connection. Asyncmeta is not aware of that, so it doesn't stop the listener on the corresponding Connection. If a new LDAP connection is opened to a different, active target using the same fd, asyncmeta would call connection_init on an already used Connection, which causes the assertion failure. The fix consists of three separate patches: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228_2.patch This moves initizalization of c_mutex to connections_init, and therefore any further access to a Connection can be synchronized, eliminating some race conditions. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228_3.patch This adds the LDAP_OPT_KEEPCONN option, which instructs try_read1msg that the connection will be freed by the client. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228_4.patch This updates asyncmeta to make use of LDAP_OPT_KEEPCONN. IPR: The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2019 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by quanah＠symas.com 28 Feb '19

28 Feb '19

--On Thursday, February 28, 2019 4:06 PM +0000 nivanova(a)symas.com wrote: > A new version of the patch has been uploaded at > ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228.patch Thanks! Applied to git master. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova＠symas.com 28 Feb '19

28 Feb '19

A new version of the patch has been uploaded at ftp://ftp.openldap.org/incoming/nadezhda-ivanova-190228.patch The patch has been integrated with master and tested. It includes all the changes necessary to fix back-asyncmeta issues discovered during on-site testing since the start of 2016. These include: Issues with stability - crashes and assertion failures Incorrect behavior during unstable network conditions, such as inability to reset connections or process responses, or "hanging" to wait for a response that would never be received. Memory leaks and memory management fixes - major redesign of the way back-asyncmeta works with memory contexts. Rewrite was replaced with suffix-massage in configuration, and the network-timeout value was changed to milliseconds. Incorrect behavior when SASL is used to bind to a target. Many problems caused by race conditions Fixes for compiler warnings, and tests. Cleanup of unused code. Nadezhda Ivanova Software Engineer Symas Corporation http://www.symas.com

1 0

(ITS#8984) Issue with socket buffer assertion failed
by gandhali.atre＠plantronics.com 25 Feb '19

25 Feb '19

Full_Name: Gandhali Atre Version: 2.4.44 OS: Android URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (140.242.26.200) Hi, I have a product that allows to configure LDAP servers. Looks like when changing the configurations or doing some search 1/10 times there is a crash and below are the crash details. messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046):Abort message '../../../libraries/liblber/sockbuf.c:89: ber_sockbuf_ctrl: assertion "SOCKBUF_VALID( sb )" failed' messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) r0 00000000 r1 000011bb r2 00000006 r3 00000008 messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) r4 00001176 r5 000011bb r6 ed27df1c r7 0000010c messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) r8 00000000 r9 ed27f290 sl 025b6410 fp ed27ef64 messages 2019-02-22 22:11:38.543 logcat:DEBUG(6046) ip 00000000 sp ed27df08 lr ef37c7f3 pc ef376774 cpsr 20000030 messages 2019-02-22 22:11:38.545 logcat:DEBUG(6046) messages 2019-02-22 22:11:38.545 backtrace messages 2019-02-22 22:11:38.545 logcat:DEBUG(6046) #00 pc 0001a774 /system/lib/libc.so (abort+63) messages 2019-02-22 22:11:38.548 logcat:DEBUG(6046) #01 pc 0001a963 /system/lib/libc.so (__assert2+22) messages 2019-02-22 22:11:38.548 logcat:DEBUG(6046) #02 pc 0000a860 /system/lib/liblber-2.4.so.2 (ber_sockbuf_ctrl+188) I read about some fixes already made for this assertion failures. Looks like it isn't working or this is something new. Any help with this would be appreciated., Thanks.

1 0

(ITS#8983) Implement old Persistent Search draft in libldap
by hyc＠openldap.org 25 Feb '19

25 Feb '19

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.233.42.124) Submitted by: hyc Sun/Netscape-based servers provide this https://tools.ietf.org/html/draft-ietf-ldapext-psearch-03 Definitions have been present in <ldap.h> for years, but no implementation in libldap was ever provided.

1 0

RE: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB failssometimes
by kriszyp＠gmail.com 21 Feb '19

21 Feb '19

--_36998F79-0E7E-483F-8FFD-6401D532832A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I see it now! I really did check even earlier this morning and wasn=E2=80= =99t there until recently! Anyway, thank you, sorry for the noise. Thanks, Kris From: Quanah Gibson-Mount Sent: February 21, 2019 10:12 AM To: kriszyp(a)gmail.com; openldap-its(a)OpenLDAP.org Subject: Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB failssom= etimes Hi, It is literally the first set of commits listed at that URL, so it's=20 clearly already there. Hope that helps! --Quanah --On Thursday, February 21, 2019 4:45 PM +0000 kriszyp(a)gmail.com wrote: > --0000000000000dacee05826a34a9 > Content-Type: text/plain; charset=3D"UTF-8" > > Thank you, I appreciate it! Do you know how often or when this will get > into the github mirror https://github.com/LMDB/lmdb/commits/mdb.RE/0.9 (o= r > if I am misunderstanding how the branches are synced)? > > On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <hyc(a)symas.com> wrote: > >> kriszyp(a)gmail.com wrote: >> > Full_Name: Kristopher William Zyp >> > Version: LMDB 0.9.23 >> > OS: Windows Server 2012 R2, Windows 10 >> > URL: >> https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45b >> d32ab4e8e1f2.patch >> > Submission from: (NULL) (71.199.6.148) >> > >> >> Thanks for the report and patch, added to mdb.RE/0.9 >> >> > Calling mdb_env_set_mapsize to increase the map size, when a DB is als= o >> in use >> > by other processes, when MDB_WRITEMAP is enabled (and the db file has >> been >> > opened with PAGE_READWRITE access), on Windows, will occasionally >> > (seems >> like >> > about 1/100 attempts fails) produce an error "The requested operation >> cannot be >> > performed on a file with a user-mapped section open", or segfaults. Th= e >> error >> > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map tha= t >> is >> > performed to increase the allocated file size to the map size, prior t= o >> > CreateFileMapping. >> > >> > As it turns out this is pretty easy to solve, because manually >> > expanding >> the >> > file size is not necessary when calling CreateFileMapping with >> PAGE_READWRITE >> > access, as Windows will automatically expand the file size for us, whe= n >> opened >> > with the page write access enabled. Of course, this means all processe= s >> must be >> > consistent in use of MDB_WRITEMAP, but the documentation already makes >> this >> > explicit and clear. >> > >> > I believe this can be fixed by simply adding a check for MDB_WRITEMAP >> > in >> the if >> > statement that calls SetFilePointer: >> > >> > if (!(flags & MDB_WRITEMAP) && >> > (SetFilePointer(env->me_fd, >> sizelo, &sizehi, 0) >> > !=3D (DWORD)sizelo >> > || !SetEndOfFile(env->me_fd) >> > || SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0= )) >> > return ErrCode(); >> > >> > The attached URL has the change as a patch/diff as applied to our node >> package. >> > >> > I am certainly happy to just keep this change on our own branches. >> > There >> may be >> > nuances of this that I might not be aware of, but it seems to be >> > working >> great >> > for us and I have tested this with MDB_WRITEMAP enabled and disabled. >> > So >> I >> > thought I would offer/suggest this change, as it seems like it is >> > straightforward change to improve stability. Thank you! >> > >> > >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > --0000000000000dacee05826a34a9 > Content-Type: text/html; charset=3D"UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D3D"ltr"><div dir=3D3D"ltr">Thank you, I appreciate it! Do you = know > h=3D ow often or when this will get into the github mirror <a > href=3D3D"https://gi=3D > thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB/lmdb/commi > ts=3D /mdb.RE/0.9</a> (or if I am misunderstanding how the branches are > synced)?<=3D /div></div> <div class=3D3D"gmail_quote"><div dir=3D3D"lt= r" > class=3D3D"gmail_a=3D ttr">On Sun, Feb 10, 2019 at 3:14 AM Howard Chu &lt= ;<a > href=3D3D"mailto:hyc@s=3D ymas.com">hyc(a)symas.com</a>> > wrote: </div><blockquote class=3D3D"gmail_=3D quote" style=3D3D"margin= :0px > 0px 0px 0.8ex;border-left:1px solid rgb(204,204,=3D > 204);padding-left:1ex"><a href=3D3D"mailto:kriszyp@gmail.com" > target=3D3D"_blan=3D k">kriszyp(a)gmail.com</a> wrote: > > Full_Name: Kristopher William Zyp > > Version: LMDB 0.9.23 > > OS: Windows Server 2012 R2, Windows 10 > > URL: <a > href=3D3D"https://github.com/kriszyp/node-lmdb/commit/6df903907f=3D > 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D3D"noreferrer" > target=3D3D"_blank">=3D > https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd > 32=3D ab4e8e1f2.patch</a> > > Submission from: (NULL) (71.199.6.148) > > > > Thanks for the report and patch, added to mdb.RE/0.9 > > > Calling mdb_env_set_mapsize to increase the map size, when a DB is > als=3D o in use > > by other processes, when MDB_WRITEMAP is enabled (and the db file > has =3D been > > opened with PAGE_READWRITE access), on Windows, will occasionally > (see=3D ms like > > about 1/100 attempts fails) produce an error "The requested > opera=3D tion cannot be > > performed on a file with a user-mapped section open", or > segfault=3D s. The error > > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map > tha=3D t is > > performed to increase the allocated file size to the map size, prior > t=3D o > > CreateFileMapping. > > > > As it turns out this is pretty easy to solve, because manually > expandi=3D ng the > > file size is not necessary when calling CreateFileMapping with > PAGE_RE=3D ADWRITE > > access, as Windows will automatically expand the file size for us, > whe=3D n opened > > with the page write access enabled. Of course, this means all > processe=3D s must be > > consistent in use of MDB_WRITEMAP, but the documentation already > makes=3D this > > explicit and clear. > > > > I believe this can be fixed by simply adding a check for > MDB_WRITEMAP =3D in the if > > statement that calls SetFilePointer: > > > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0if (!(flags > &amp=3D ; MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, > &size=3D hi, 0) > > !=3D3D (DWORD)sizelo > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3D =3DC2=3DA0 =3DC2=3DA0|| !SetEndOfFile(env->me_fd) > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3D =3DC2=3DA0 =3DC2=3DA0|| SetFilePointer(env->me_fd, 0, NULL, 0) != =3D3D 0)) > >=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 > =3D =3DC2=3DA0 =3DC2=3DA0return ErrCode(); > > > > The attached URL has the change as a patch/diff as applied to our > node=3D package. > > > > I am certainly happy to just keep this change on our own branches. > The=3D re may be > > nuances of this that I might not be aware of, but it seems to be > worki=3D ng great > > for us and I have tested this with MDB_WRITEMAP enabled and > disabled. =3D So I > > thought I would offer/suggest this change, as it seems like it is<br= > > > straightforward change to improve stability. Thank you! > > > > > > > -- > =3DC2=3DA0 -- Howard Chu > =3DC2=3DA0 CTO, Symas Corp.=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0<a > href=3D3D"=3D http://www.symas.com" rel=3D3D"noreferrer" > target=3D3D"_blank">http://www.symas=3D .com</a> > =3DC2=3DA0 Director, Highland Sun=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0<a > href=3D3D"http://highland=3D sun.com/hyc/" rel=3D3D"noreferrer" > target=3D3D"_blank">http://highlandsun.com/h=3D yc/</a> > =3DC2=3DA0 Chief Architect, OpenLDAP=3DC2=3DA0 <a > href=3D3D"http://www.openldap.org/p=3D roject/" rel=3D3D"noreferrer" > target=3D3D"_blank">http://www.openldap.org/proje=3D ct/</a> > </blockquote></div> > > --0000000000000dacee05826a34a9-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> --_36998F79-0E7E-483F-8FFD-6401D532832A_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"><head><meta ht= tp-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"><meta name= =3DGenerator content=3D"Microsoft Word 15 (filtered medium)"><style></style></head><body lang=3DEN-CA link=3Dblue vlink=3D"#954F72"><div cla= ss=3DWordSection1>I see it now! I really did check eve= n earlier this morning and wasn=E2=80=99t there until recently! Anyway, tha= nk you, sorry for the noise.<o:p> </o:p><= p class=3DMsoNormal>Thanks, Kris<o:p> </o:= p><div style=3D'mso-element:para-border-div;border:none;border-top:soli= d #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'>From: <a href=3D"mailto:quanah@symas.com">Qua= nah Gibson-Mount</a> Sent: February 21, 2019 10:12 AM To: <= /b><a href=3D"mailto:kriszyp@gmail.com">kriszyp(a)gmail.com</a>; <a href=3D"m= ailto:openldap-its@OpenLDAP.org">openldap-its(a)OpenLDAP.org</a> Subjec= t: Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB failssomet= imes</div><o:p> </o:p>Hi,<o:p> </o:p>It = is literally the first set of commits listed at that URL, so it's clearly already there.<o:p> <= /o:p>Hope that helps!<o:p= > </o:p>--Quanah<o:p= > </o:p>--On Thursday, February 21, 2019 4:45= PM +0000 kriszyp(a)gmail.com wrote:<o:p> </o:p= >> --0000000000000dacee05826a34a9> Content-Type: text/plain; charset=3D"UTF-8"= ><o:p> </o:p>> Tha= nk you, I appreciate it! Do you know how often or when this will get> into the github mirror https://github.com/LMDB/lmdb/= commits/mdb.RE/0.9 (or> if I am misunderstandin= g how the branches are synced)?><o:p> </o:= p>> On Sun, Feb 10, 2019 at 3:14 AM Howard Chu = <hyc(a)symas.com> wrote:><o:p> </o:p><= /p>>> kriszyp(a)gmail.com wrote:>> > Full_Name: Kristopher William Zyp>> > Version: LMDB 0.9.23>> &gt= ; OS: Windows Server 2012 R2, Windows 10>> &= gt; URL:>> https://github.com/kriszyp/node-l= mdb/commit/6df903907f5516320e9a8afce45b>> d3= 2ab4e8e1f2.patch>> > Submission from: (NU= LL) (71.199.6.148)>> >>><o:p> </o:p>>> Thanks for= the report and patch, added to mdb.RE/0.9>>= <o:p> </o:p>>> > Calling mdb_env_set= _mapsize to increase the map size, when a DB is also>> in use>> > by other processes,= when MDB_WRITEMAP is enabled (and the db file has= >> been>> > opened with PAGE_READWR= ITE access), on Windows, will occasionally>>= > (seems>> like= >> > about 1/100 attempts fails) produce an error "The reques= ted operation>> cannot be>> > performed on a file with a user-mapped section open&quo= t;, or segfaults. The>> error>> > occurs in the SetFilePointer (or SetEndOfFile) call= in mdb_env_map that>> is>> > performed to increase the allocated file size to the ma= p size, prior to>> > CreateFileMapping.</= p>>> >>> > = As it turns out this is pretty easy to solve, because manually>> > expanding>> the</= p>>> > file size is not necessary when callin= g CreateFileMapping with>> PAGE_READWRITE</p= >>> > access, as Windows will automatically e= xpand the file size for us, when>> opened</p= >>> > with the page write access enabled. Of = course, this means all processes>> must be</= p>>> > consistent in use of MDB_WRITEMAP, but= the documentation already makes>> this<= p class=3DMsoNormal>>> > explicit and clear.>> >>> > I believe this can b= e fixed by simply adding a check for MDB_WRITEMAP&= gt;> > in>> the if>> > statement that calls SetFilePointer:>> >>> >=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (!(fl= ags & MDB_WRITEMAP) &&>> >=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 (SetFilePointer(env->me_fd,>> size= lo, &sizehi, 0)>> > !=3D (DWORD)sizel= o>> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 || !SetEndOfFile(env->me_fd)>> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= || SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0))>> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= return ErrCode();>> >>> > The attached URL has the change as a patch/diff as appl= ied to our node>> package.>> >>> > I am certainly h= appy to just keep this change on our own branches.= >> > There>> may be>> > nuances of this that I might not be aware of, but it= seems to be>> > working>> great>> > for us and I h= ave tested this with MDB_WRITEMAP enabled and disabled.>> > So>> I>> > thought I would offer/suggest this change, as it seems = like it is>> > straightforward change to = improve stability. Thank you!>> >>> >>><o:p> <= /o:p>>><o:p> </o:p>>> -->>=C2=A0=C2=A0 -- Howard Chu= >>=C2=A0=C2=A0 CTO, Symas Corp.=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 http://www.symas.com<p= class=3DMsoNormal>>>=C2=A0=C2=A0 Director, Highland Sun=C2=A0=C2=A0= =C2=A0=C2=A0 http://highlandsun.com/hyc/>>= =C2=A0=C2=A0 Chief Architect, OpenLDAP=C2=A0 http://www.openldap.org/projec= t/>><o:p> </o:p>><o:p> </o:p>> --0000000000000dacee05= 826a34a9> Content-Type: text/html; charset=3D&q= uot;UTF-8"> Content-Transfer-Encoding: quo= ted-printable><o:p> </o:p>> <div dir=3D3D"ltr"><div dir=3D3D"ltr&= quot;>Thank you, I appreciate it! Do you know&g= t; h=3D ow often or when this will get into the github mirror <a> href=3D3D"https://gi=3D= > thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB= /lmdb/commi> ts=3D /mdb.RE/0.9</a> (or if= I am misunderstanding how the branches are> sy= nced)?<=3D /div></div> <div class=3D3D"gmail_q= uote"><div dir=3D3D"ltr"> = class=3D3D"gmail_a=3D ttr">On Sun, Feb 10, 2019 at 3:14 AM How= ard Chu &lt;<a> href=3D3D"mailto:hy= c@s=3D ymas.com">hyc(a)symas.com</a>&gtm</a>&gt;> wrote: </div><blockquote class=3D3D"gmail= _=3D quote" style=3D3D"margin:0px> 0p= x 0px 0.8ex;border-left:1px solid rgb(204,204,=3D&= gt; 204);padding-left:1ex"><a href=3D3D"mailto:kriszyp@gmai= l.com"> target=3D3D"_blan=3D k"&= gt;kriszyp(a)gmail.com</a> wrote: &gt= ; &gt; Full_Name: Kristopher William Zyp > &gt; Version: LMDB 0.9.23 &g= t; &gt; OS: Windows Server 2012 R2, Windows 10 > &gt; URL: <a> href=3D3D&q= uot;https://github.com/kriszyp/node-lmdb/commit/6df903907f=3D> 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D3D"= noreferrer"> target=3D3D"_blank"= >=3D> https://github.com/kriszyp/node-lmdb/c= ommit/6df903907f5516320e9a8afce45bd> 32=3D ab4e= 8e1f2.patch</a> > &gt; Submi= ssion from: (NULL) (71.199.6.148) > &a= mp;gt; > > Thanks for the report and patch, added to mdb.RE/0.9 <= /p>> > &g= t; Calling mdb_env_set_mapsize to increase the map size, when a DB is<p= class=3DMsoNormal>> als=3D o in use &= gt; &gt; by other processes, when MDB_WRITEMAP is enabled (and the db f= ile> has =3D been > &gt; opened with PAGE_READWRITE access), on Windows, will occ= asionally> (see=3D ms like > &gt; about 1/100 attempts fails) produce an error &a= mp;quot;The requested> opera=3D tion cannot be&= lt;br>> &gt; performed on a file with a = user-mapped section open&quot;, or> segfaul= t=3D s. The error > &gt; occurs in= the SetFilePointer (or SetEndOfFile) call in mdb_env_map> tha=3D t is > &gt; per= formed to increase the allocated file size to the map size, prior> t=3D o > &gt; = CreateFileMapping. > &gt; <br&g= t;> &gt; As it turns out this is pretty eas= y to solve, because manually> expandi=3D ng the= > &gt; file size is not necessary= when calling CreateFileMapping with> PAGE_RE= =3D ADWRITE > &gt; access, as Wind= ows will automatically expand the file size for us,> whe=3D n opened > &gt; with = the page write access enabled. Of course, this means all> processe=3D s must be > &am= p;gt; consistent in use of MDB_WRITEMAP, but the documentation already<= p class=3DMsoNormal>> makes=3D=C2=A0 this > &gt; explicit and clear. &gt= ; &gt; > &gt; I believe this = can be fixed by simply adding a check for> MDB_= WRITEMAP =3D in the if > &gt; stat= ement that calls SetFilePointer: > &am= p;gt; > &gt;=3DC2=3DA0 =3DC2=3DA0= =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0if (!(fla= gs> &amp=3D ; MDB_WRITEMAP) &amp;&a= mp; (SetFilePointer(env-&gt;me_fd, sizelo,>= &amp;size=3D hi, 0) > &gt; != =3D3D (DWORD)sizelo > &gt;=3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0> =3D =3DC2=3DA0 =3D= C2=3DA0|| !SetEndOfFile(env-&gt;me_fd) > &gt;=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2= =3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0&= gt; =3D =3DC2=3DA0 =3DC2=3DA0|| SetFilePointer(env-&gt;me_fd, 0, NULL, = 0) !=3D3D 0)) > &gt;=3DC2=3DA0 =3D= C2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 = =3DC2=3DA0 =3DC2=3DA0> =3D =3DC2=3DA0 =3DC2=3DA= 0return ErrCode(); > &gt; <br&g= t;> &gt; The attached URL has the change as= a patch/diff as applied to our> node=3D=C2=A0 = package. > &gt; > &gt; I am certainly happy to just keep this chang= e on our own branches.> The=3D re may be<br&= gt;> &gt; nuances of this that I might not = be aware of, but it seems to be> worki=3D ng gr= eat > &gt; for us and I have teste= d this with MDB_WRITEMAP enabled and> disabled.= =3D So I > &gt; thought I would o= ffer/suggest this change, as it seems like it is > &gt; straightforward change to improve stability. Thank yo= u! > &gt; > &gt; > <br&g= t;> > -- = > =3DC2=3DA0 -- Howard Chu <= /p>> =3DC2=3DA0 CTO, Symas Corp.=3DC2=3DA0 =3DC2=3D= A0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0<a> href=3D3D"=3D http://www.symas.com" rel=3D3D"noreferre= r"> target=3D3D"_blank">http:= //www.symas=3D .com</a> > =3DC2= =3DA0 Director, Highland Sun=3DC2=3DA0 =3DC2=3DA0 =3DC2=3DA0<a> href=3D3D"http://highland=3D sun.com/hyc/" re= l=3D3D"noreferrer"> target=3D3D"= _blank">http://highlandsun.com/h=3D yc/</a> > =3DC2=3DA0 Chief Architect, OpenLDAP=3DC2=3DA0 <a<= /p>> href=3D3D"http://www.openldap.org/p=3D ro= ject/" rel=3D3D"noreferrer"> tar= get=3D3D"_blank">http://www.openldap.org/proje=3D ct/</a&gt= ; > </blockquote></div></p= >><o:p> </o:p>> --= 0000000000000dacee05826a34a9--><o:p> </o:p= >><o:p> </o:p>&gt= ;<o:p> </o:p><o:p> </o:p><o:p> </o:p><o:p> </o:p><p= class=3DMsoNormal>--<o:p> </o:p>Quanah Gibson-MountProduct Architect<= /p>Symas CorporationPackaged,= certified, and supported LDAP solutions powered by OpenLDAP:<http://www.symas.com><o:p>&nbs= p;</o:p><o:p> </o:p></div></body></html>= --_36998F79-0E7E-483F-8FFD-6401D532832A_--

1 0

Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB fails sometimes
by quanah＠symas.com 21 Feb '19

21 Feb '19

Hi, It is literally the first set of commits listed at that URL, so it's clearly already there. Hope that helps! --Quanah --On Thursday, February 21, 2019 4:45 PM +0000 kriszyp(a)gmail.com wrote: > --0000000000000dacee05826a34a9 > Content-Type: text/plain; charset="UTF-8" > > Thank you, I appreciate it! Do you know how often or when this will get > into the github mirror https://github.com/LMDB/lmdb/commits/mdb.RE/0.9 (or > if I am misunderstanding how the branches are synced)? > > On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <hyc(a)symas.com> wrote: > >> kriszyp(a)gmail.com wrote: >> > Full_Name: Kristopher William Zyp >> > Version: LMDB 0.9.23 >> > OS: Windows Server 2012 R2, Windows 10 >> > URL: >> https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45b >> d32ab4e8e1f2.patch >> > Submission from: (NULL) (71.199.6.148) >> > >> >> Thanks for the report and patch, added to mdb.RE/0.9 >> >> > Calling mdb_env_set_mapsize to increase the map size, when a DB is also >> in use >> > by other processes, when MDB_WRITEMAP is enabled (and the db file has >> been >> > opened with PAGE_READWRITE access), on Windows, will occasionally >> > (seems >> like >> > about 1/100 attempts fails) produce an error "The requested operation >> cannot be >> > performed on a file with a user-mapped section open", or segfaults. The >> error >> > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map that >> is >> > performed to increase the allocated file size to the map size, prior to >> > CreateFileMapping. >> > >> > As it turns out this is pretty easy to solve, because manually >> > expanding >> the >> > file size is not necessary when calling CreateFileMapping with >> PAGE_READWRITE >> > access, as Windows will automatically expand the file size for us, when >> opened >> > with the page write access enabled. Of course, this means all processes >> must be >> > consistent in use of MDB_WRITEMAP, but the documentation already makes >> this >> > explicit and clear. >> > >> > I believe this can be fixed by simply adding a check for MDB_WRITEMAP >> > in >> the if >> > statement that calls SetFilePointer: >> > >> > if (!(flags & MDB_WRITEMAP) && >> > (SetFilePointer(env->me_fd, >> sizelo, &sizehi, 0) >> > != (DWORD)sizelo >> > || !SetEndOfFile(env->me_fd) >> > || SetFilePointer(env->me_fd, 0, NULL, 0) != 0)) >> > return ErrCode(); >> > >> > The attached URL has the change as a patch/diff as applied to our node >> package. >> > >> > I am certainly happy to just keep this change on our own branches. >> > There >> may be >> > nuances of this that I might not be aware of, but it seems to be >> > working >> great >> > for us and I have tested this with MDB_WRITEMAP enabled and disabled. >> > So >> I >> > thought I would offer/suggest this change, as it seems like it is >> > straightforward change to improve stability. Thank you! >> > >> > >> >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/project/ >> > > --0000000000000dacee05826a34a9 > Content-Type: text/html; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > <div dir=3D"ltr"><div dir=3D"ltr">Thank you, I appreciate it! Do you know > h= ow often or when this will get into the github mirror <a > href=3D"https://gi= > thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB/lmdb/commi > ts= /mdb.RE/0.9</a> (or if I am misunderstanding how the branches are > synced)?<= /div></div> <div class=3D"gmail_quote"><div dir=3D"ltr" > class=3D"gmail_a= ttr">On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <<a > href=3D"mailto:hyc@s= ymas.com">hyc(a)symas.com</a>> > wrote: </div><blockquote class=3D"gmail_= quote" style=3D"margin:0px > 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= > 204);padding-left:1ex"><a href=3D"mailto:kriszyp@gmail.com" > target=3D"_blan= k">kriszyp(a)gmail.com</a> wrote: > > Full_Name: Kristopher William Zyp > > Version: LMDB 0.9.23 > > OS: Windows Server 2012 R2, Windows 10 > > URL: <a > href=3D"https://github.com/kriszyp/node-lmdb/commit/6df903907f= > 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D"noreferrer" > target=3D"_blank">= > https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd > 32= ab4e8e1f2.patch</a> > > Submission from: (NULL) (71.199.6.148) > > > > Thanks for the report and patch, added to mdb.RE/0.9 > > > Calling mdb_env_set_mapsize to increase the map size, when a DB is > als= o in use > > by other processes, when MDB_WRITEMAP is enabled (and the db file > has = been > > opened with PAGE_READWRITE access), on Windows, will occasionally > (see= ms like > > about 1/100 attempts fails) produce an error "The requested > opera= tion cannot be > > performed on a file with a user-mapped section open", or > segfault= s. The error > > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map > tha= t is > > performed to increase the allocated file size to the map size, prior > t= o > > CreateFileMapping. > > > > As it turns out this is pretty easy to solve, because manually > expandi= ng the > > file size is not necessary when calling CreateFileMapping with > PAGE_RE= ADWRITE > > access, as Windows will automatically expand the file size for us, > whe= n opened > > with the page write access enabled. Of course, this means all > processe= s must be > > consistent in use of MDB_WRITEMAP, but the documentation already > makes= this > > explicit and clear. > > > > I believe this can be fixed by simply adding a check for > MDB_WRITEMAP = in the if > > statement that calls SetFilePointer: > > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!(flags > &amp= ; MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, > &size= hi, 0) > > !=3D (DWORD)sizelo > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = =C2=A0 =C2=A0|| !SetEndOfFile(env->me_fd) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = =C2=A0 =C2=A0|| SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0)) > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 > = =C2=A0 =C2=A0return ErrCode(); > > > > The attached URL has the change as a patch/diff as applied to our > node= package. > > > > I am certainly happy to just keep this change on our own branches. > The= re may be > > nuances of this that I might not be aware of, but it seems to be > worki= ng great > > for us and I have tested this with MDB_WRITEMAP enabled and > disabled. = So I > > thought I would offer/suggest this change, as it seems like it is > > straightforward change to improve stability. Thank you! > > > > > > > -- > =C2=A0 -- Howard Chu > =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a > href=3D"= http://www.symas.com" rel=3D"noreferrer" > target=3D"_blank">http://www.symas= .com</a> > =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a > href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" > target=3D"_blank">http://highlandsun.com/h= yc/</a> > =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a > href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" > target=3D"_blank">http://www.openldap.org/proje= ct/</a> > </blockquote></div> > > --0000000000000dacee05826a34a9-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8975) Calling mdb_env_set_mapsize on a shared DB fails sometimes
by kriszyp＠gmail.com 21 Feb '19

21 Feb '19

--0000000000000dacee05826a34a9 Content-Type: text/plain; charset="UTF-8" Thank you, I appreciate it! Do you know how often or when this will get into the github mirror https://github.com/LMDB/lmdb/commits/mdb.RE/0.9 (or if I am misunderstanding how the branches are synced)? On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <hyc(a)symas.com> wrote: > kriszyp(a)gmail.com wrote: > > Full_Name: Kristopher William Zyp > > Version: LMDB 0.9.23 > > OS: Windows Server 2012 R2, Windows 10 > > URL: > https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd32… > > Submission from: (NULL) (71.199.6.148) > > > > Thanks for the report and patch, added to mdb.RE/0.9 > > > Calling mdb_env_set_mapsize to increase the map size, when a DB is also > in use > > by other processes, when MDB_WRITEMAP is enabled (and the db file has > been > > opened with PAGE_READWRITE access), on Windows, will occasionally (seems > like > > about 1/100 attempts fails) produce an error "The requested operation > cannot be > > performed on a file with a user-mapped section open", or segfaults. The > error > > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map that > is > > performed to increase the allocated file size to the map size, prior to > > CreateFileMapping. > > > > As it turns out this is pretty easy to solve, because manually expanding > the > > file size is not necessary when calling CreateFileMapping with > PAGE_READWRITE > > access, as Windows will automatically expand the file size for us, when > opened > > with the page write access enabled. Of course, this means all processes > must be > > consistent in use of MDB_WRITEMAP, but the documentation already makes > this > > explicit and clear. > > > > I believe this can be fixed by simply adding a check for MDB_WRITEMAP in > the if > > statement that calls SetFilePointer: > > > > if (!(flags & MDB_WRITEMAP) && (SetFilePointer(env->me_fd, > sizelo, &sizehi, 0) > > != (DWORD)sizelo > > || !SetEndOfFile(env->me_fd) > > || SetFilePointer(env->me_fd, 0, NULL, 0) != 0)) > > return ErrCode(); > > > > The attached URL has the change as a patch/diff as applied to our node > package. > > > > I am certainly happy to just keep this change on our own branches. There > may be > > nuances of this that I might not be aware of, but it seems to be working > great > > for us and I have tested this with MDB_WRITEMAP enabled and disabled. So > I > > thought I would offer/suggest this change, as it seems like it is > > straightforward change to improve stability. Thank you! > > > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --0000000000000dacee05826a34a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr">Thank you, I appreciate it! Do you know h= ow often or when this will get into the github mirror <a href=3D"https://gi= thub.com/LMDB/lmdb/commits/mdb.RE/0.9">https://github.com/LMDB/lmdb/commits= /mdb.RE/0.9</a> (or if I am misunderstanding how the branches are synced)?<= /div></div> <div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_a= ttr">On Sun, Feb 10, 2019 at 3:14 AM Howard Chu <<a href=3D"mailto:hyc@s= ymas.com">hyc(a)symas.com</a>> wrote: </div><blockquote class=3D"gmail_= quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,= 204);padding-left:1ex"><a href=3D"mailto:kriszyp@gmail.com" target=3D"_blan= k">kriszyp(a)gmail.com</a> wrote: > Full_Name: Kristopher William Zyp > Version: LMDB 0.9.23 > OS: Windows Server 2012 R2, Windows 10 > URL: <a href=3D"https://github.com/kriszyp/node-lmdb/commit/6df903907f= 5516320e9a8afce45bd32ab4e8e1f2.patch" rel=3D"noreferrer" target=3D"_blank">= https://github.com/kriszyp/node-lmdb/commit/6df903907f5516320e9a8afce45bd32= ab4e8e1f2.patch</a> > Submission from: (NULL) (71.199.6.148) > Thanks for the report and patch, added to mdb.RE/0.9 > Calling mdb_env_set_mapsize to increase the map size, when a DB is als= o in use > by other processes, when MDB_WRITEMAP is enabled (and the db file has = been > opened with PAGE_READWRITE access), on Windows, will occasionally (see= ms like > about 1/100 attempts fails) produce an error "The requested opera= tion cannot be > performed on a file with a user-mapped section open", or segfault= s. The error > occurs in the SetFilePointer (or SetEndOfFile) call in mdb_env_map tha= t is > performed to increase the allocated file size to the map size, prior t= o > CreateFileMapping. > > As it turns out this is pretty easy to solve, because manually expandi= ng the > file size is not necessary when calling CreateFileMapping with PAGE_RE= ADWRITE > access, as Windows will automatically expand the file size for us, whe= n opened > with the page write access enabled. Of course, this means all processe= s must be > consistent in use of MDB_WRITEMAP, but the documentation already makes= this > explicit and clear. > > I believe this can be fixed by simply adding a check for MDB_WRITEMAP = in the if > statement that calls SetFilePointer: > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0if (!(flags &amp= ; MDB_WRITEMAP) && (SetFilePointer(env->me_fd, sizelo, &size= hi, 0) > !=3D (DWORD)sizelo >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|| !SetEndOfFile(env->me_fd) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0|| SetFilePointer(env->me_fd, 0, NULL, 0) !=3D 0)) >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0return ErrCode(); > > The attached URL has the change as a patch/diff as applied to our node= package. > > I am certainly happy to just keep this change on our own branches. The= re may be > nuances of this that I might not be aware of, but it seems to be worki= ng great > for us and I have tested this with MDB_WRITEMAP enabled and disabled. = So I > thought I would offer/suggest this change, as it seems like it is > straightforward change to improve stability. Thank you! > > -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a> </blockquote></div> --0000000000000dacee05826a34a9--

1 0

RE: (ITS#8970) bind fails when length value is multi-byte
by quanah＠symas.com 21 Feb '19

21 Feb '19

Decoded message: frame captures follow. Ldap message begins at offset 0x36 (after ethernet, ip, tcp headers) success: 00 FF 06 16 E6 E1 00 FF 05 16 E6 E1 08 00 45 00 00 53 6B FE 40 00 80 06 4F F4 0A 01 28 2A 0A 78 02 10 D5 08 01 85 32 FB 2B E6 50 15 47 F1 50 18 01 00 90 48 00 00 30 29 02 01 01 60 24 02 01 03 04 19 63 6E 3D 55 73 65 72 31 2C 64 63 3D 6D 61 78 63 72 63 2C 64 63 3D 63 6F 6D 80 04 69 6E 69 74 failure: 00 FF 06 16 E6 E1 00 FF 05 16 E6 E1 08 00 45 00 00 5B 05 3A 40 00 80 06 B7 E2 0A 01 28 2A 0A 01 01 55 D6 0A 01 85 4F 4D F1 F0 57 2F 51 3C 50 18 01 00 19 06 00 00 30 84 00 00 00 2D 02 01 01 60 84 00 00 00 24 02 01 03 04 19 63 6E 3D 75 73 65 72 31 2C 64 63 3D 6D 61 78 63 72 63 2C 64 63 3D 63 6F 6D 80 04 69 6E 69 74 For your convenience (not needed?), here is the network monitor UI labeling for each frame (starting at ldap message) success: Frame: Number = 118, Captured Frame Length = 97, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-FF-06-16-E6-E1],SourceAddress:[00-FF-05-16-E6-E1] + Ipv4: Src = 10.1.40.42, Dest = 10.120.2.16, Next Protocol = TCP, Packet ID = 27646, Total IP Length = 83 + Tcp: Flags=...AP..., SrcPort=54536, DstPort=LDAP(389), PayloadLen=43, Seq=855321574 - 855321617, Ack=1343571953, Win=256 (scale factor 0x8) = 65536 Ldap: Bind Request, MessageID: 1, Version: 3 - LDAPMessage: Bind Request, MessageID: 1 - ParserHeader: - AsnId: Sequence and SequenceOf types (Universal 16) - LowTag: Class: (00......) Universal (0) Type: (..1.....) Constructed TagValue: (...10000) 16 - AsnLen: Length = 41, LengthOfLength = 0 Length: 41 bytes, LengthOfLength = 0 - MessageID: 1 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 1 (0x1) - OperationHeader: Bind Request, 0(0) - AsnId: Application Constructed Tag (0) - LowTag: Class: (01......) Application (1) Type: (..1.....) Constructed TagValue: (...00000) 0 - AsnLen: Length = 36, LengthOfLength = 0 Length: 36 bytes, LengthOfLength = 0 - BindRequest: Version:3, Name:cn=User1,dc=maxcrc,dc=com, UserName: init, Authentication type = simple - Version: 3 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 3 (0x3) - Name: cn=User1,dc=maxcrc,dc=com - AsnOctetStringHeader: - AsnId: OctetString type (Universal 4) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00100) 4 - AsnLen: Length = 25, LengthOfLength = 0 Length: 25 bytes, LengthOfLength = 0 OctetStream: cn=User1,dc=maxcrc,dc=com - Authentication: UserName: init, Authentication type = simple - AuthenticationTypeHeader: Authentication type = simple - AsnId: Context Specific Primitive Tag (0) - LowTag: Class: (10......) ConText specific (2) Type: (..0.....) Primitive TagValue: (...00000) 0 - AsnLen: Length = 4, LengthOfLength = 0 Length: 4 bytes, LengthOfLength = 0 SimpleAuthentication: init failure: Frame: Number = 30, Captured Frame Length = 105, MediaType = ETHERNET + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-FF-06-16-E6-E1],SourceAddress:[00-FF-05-16-E6-E1] + Ipv4: Src = 10.1.40.42, Dest = 10.1.1.85, Next Protocol = TCP, Packet ID = 1338, Total IP Length = 91 + Tcp: Flags=...AP..., SrcPort=54794, DstPort=LDAP(389), PayloadLen=51, Seq=1330508272 - 1330508323, Ack=1462718780, Win=256 (scale factor 0x8) = 65536 Ldap: Bind Request, MessageID: 1, Version: 3 - LDAPMessage: Bind Request, MessageID: 1 - ParserHeader: - AsnId: Sequence and SequenceOf types (Universal 16) - LowTag: Class: (00......) Universal (0) Type: (..1.....) Constructed TagValue: (...10000) 16 - AsnLen: Length = 45, LengthOfLength = 4 LengthType: LengthOfLength = 4 Length: 45 bytes - MessageID: 1 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 1 (0x1) - OperationHeader: Bind Request, 0(0) - AsnId: Application Constructed Tag (0) - LowTag: Class: (01......) Application (1) Type: (..1.....) Constructed TagValue: (...00000) 0 - AsnLen: Length = 36, LengthOfLength = 4 LengthType: LengthOfLength = 4 Length: 36 bytes - BindRequest: Version:3, Name:cn=user1,dc=maxcrc,dc=com, UserName: init, Authentication type = simple - Version: 3 - AsnIntegerHeader: - AsnId: Integer type (Universal 2) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00010) 2 - AsnLen: Length = 1, LengthOfLength = 0 Length: 1 bytes, LengthOfLength = 0 AsnInt: 3 (0x3) - Name: cn=user1,dc=maxcrc,dc=com - AsnOctetStringHeader: - AsnId: OctetString type (Universal 4) - LowTag: Class: (00......) Universal (0) Type: (..0.....) Primitive TagValue: (...00100) 4 - AsnLen: Length = 25, LengthOfLength = 0 Length: 25 bytes, LengthOfLength = 0 OctetStream: cn=user1,dc=maxcrc,dc=com - Authentication: UserName: init, Authentication type = simple - AuthenticationTypeHeader: Authentication type = simple - AsnId: Context Specific Primitive Tag (0) - LowTag: Class: (10......) ConText specific (2) Type: (..0.....) Primitive TagValue: (...00000) 0 - AsnLen: Length = 4, LengthOfLength = 0 Length: 4 bytes, LengthOfLength = 0 SimpleAuthentication: init --On Monday, February 04, 2019 4:29 AM +0000 lit(a)CBORD.com wrote: > ZnJhbWUgY2FwdHVyZXMgZm9sbG93LiAgTGRhcCBtZXNzYWdlIGJlZ2lucyBhdCBvZmZzZXQgM > Hgz > NiAoYWZ0ZXIgZXRoZXJuZXQsIGlwLCB0Y3AgaGVhZGVycykNCnN1Y2Nlc3M6DQowMCBGRiAwN > iAx > NiBFNiBFMSAwMCBGRiAwNSAxNiBFNiBFMSAwOCAwMCA0NSAwMCAwMCA1MyA2QiBGRSA0MCAwM > CA4 > MCAwNiA0RiBGNCAwQSAwMSAyOCAyQSAwQSA3OCAwMiAxMCBENSAwOCAwMSA4NSAzMiBGQiAyQ > iBF > NiA1MCAxNSA0NyBGMSA1MCAxOCAwMSAwMCA5MCA0OCAwMCAwMCAzMCAyOSAwMiAwMSAwMSA2M > CAy > NCAwMiAwMSAwMyAwNCAxOSA2MyA2RSAzRCA1NSA3MyA2NSA3MiAzMSAyQyA2NCA2MyAzRCA2R > CA2 > MSA3OCA2MyA3MiA2MyAyQyA2NCA2MyAzRCA2MyA2RiA2RCA4MCAwNCA2OSA2RSA2OSA3NCANC > g0K > ZmFpbHVyZToNCjAwIEZGIDA2IDE2IEU2IEUxIDAwIEZGIDA1IDE2IEU2IEUxIDA4IDAwIDQ1I > DAw > IDAwIDVCIDA1IDNBIDQwIDAwIDgwIDA2IEI3IEUyIDBBIDAxIDI4IDJBIDBBIDAxIDAxIDU1I > EQ2 > IDBBIDAxIDg1IDRGIDREIEYxIEYwIDU3IDJGIDUxIDNDIDUwIDE4IDAxIDAwIDE5IDA2IDAwI > DAw > IDMwIDg0IDAwIDAwIDAwIDJEIDAyIDAxIDAxIDYwIDg0IDAwIDAwIDAwIDI0IDAyIDAxIDAzI > DA0 > IDE5IDYzIDZFIDNEIDc1IDczIDY1IDcyIDMxIDJDIDY0IDYzIDNEIDZEIDYxIDc4IDYzIDcyI > DYz > IDJDIDY0IDYzIDNEIDYzIDZGIDZEIDgwIDA0IDY5IDZFIDY5IDc0IA0KDQpGb3IgeW91ciBjb > 252 > ZW5pZW5jZSAobm90IG5lZWRlZD8pLCBoZXJlIGlzIHRoZSBuZXR3b3JrIG1vbml0b3IgVUkgb > GFi > ZWxpbmcgZm9yIGVhY2ggZnJhbWUgKHN0YXJ0aW5nIGF0IGxkYXAgbWVzc2FnZSkNCg0Kc3VjY > 2Vz > czoNCiAgRnJhbWU6IE51bWJlciA9IDExOCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gOTcsI > E1l > ZGlhVHlwZSA9IEVUSEVSTkVUDQorIEV0aGVybmV0OiBFdHlwZSA9IEludGVybmV0IElQIChJU > HY0 > KSxEZXN0aW5hdGlvbkFkZHJlc3M6WzAwLUZGLTA2LTE2LUU2LUUxXSxTb3VyY2VBZGRyZXNzO > lsw > MC1GRi0wNS0xNi1FNi1FMV0NCisgSXB2NDogU3JjID0gMTAuMS40MC40MiwgRGVzdCA9IDEwL > jEy > MC4yLjE2LCBOZXh0IFByb3RvY29sID0gVENQLCBQYWNrZXQgSUQgPSAyNzY0NiwgVG90YWwgS > VAg > TGVuZ3RoID0gODMNCisgVGNwOiBGbGFncz0uLi5BUC4uLiwgU3JjUG9ydD01NDUzNiwgRHN0U > G9y > dD1MREFQKDM4OSksIFBheWxvYWRMZW49NDMsIFNlcT04NTUzMjE1NzQgLSA4NTUzMjE2MTcsI > EFj > az0xMzQzNTcxOTUzLCBXaW49MjU2IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkY > XA6 > IEJpbmQgUmVxdWVzdCwgTWVzc2FnZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlO > iBC > aW5kIFJlcXVlc3QsIE1lc3NhZ2VJRDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzb > klk > OiBTZXF1ZW5jZSBhbmQgU2VxdWVuY2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gT > G93 > VGFnOiANCiAgICAgICBDbGFzczogICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgI > CAg > VHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uL > jEw > MDAwKSAxNg0KICAgLSBBc25MZW46IExlbmd0aCA9IDQxLCBMZW5ndGhPZkxlbmd0aCA9IDANC > iAg > ICAgIExlbmd0aDogNDEgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAtIE1lc3NhZ2VJR > Dog > MQ0KICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgK > FVu > aXZlcnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uL > i4p > IFVuaXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlD > Qog > ICAgICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gM > Swg > TGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlb > md0 > aCA9IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kI > FJl > cXVlc3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoM > CkN > CiAgICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb > 24g > KDEpDQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUY > WdW > YWx1ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mT > GVu > Z3RoID0gMA0KICAgICAgTGVuZ3RoOiAzNiBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogI > C0g > QmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tL > CBV > c2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgLSBWZXJza > W9u > OiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc25JZDogSW50ZWdlciB0e > XBl > IChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoM > DAu > Li4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFBya > W1p > dGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KICAgICAtIEFzbkxlbjogT > GVu > Z3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlbmd0aDogMSBieXRlcywgT > GVu > Z3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNCiAgIC0gTmFtZTogY249V > XNl > cjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpbmdIZWFkZXI6IA0KICAgI > CAt > IEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNCiAgICAgIC0gTG93VGFnO > iAN > CiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgI > FR5 > cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wM > DEw > MCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0aE9mTGVuZ3RoID0gMA0KI > CAg > ICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9IDANCiAgICAgIE9jdGV0U > 3Ry > ZWFtOiBjbj1Vc2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1dGhlbnRpY2F0aW9uOiBVc > 2Vy > TmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZQ0KICAgIC0gQXV0aGVud > Glj > YXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc2ltcGxlDQogICAgIC0gQ > XNu > SWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNCiAgICAgIC0gTG93VGFnO > iAN > CiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc3BlY2lmaWMgKDIpDQogI > CAg > ICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgICAgICAgIFRhZ1ZhbHVlO > iAo > Li4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsIExlbmd0aE9mTGVuZ3RoI > D0g > MA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ3RoID0gMA0KICAgICAgU > 2lt > cGxlQXV0aGVudGljYXRpb246IGluaXQNCg0KDQpmYWlsdXJlOg0KDQogIEZyYW1lOiBOdW1iZ > XIg > PSAzMCwgQ2FwdHVyZWQgRnJhbWUgTGVuZ3RoID0gMTA1LCBNZWRpYVR5cGUgPSBFVEhFUk5FV > A0K > KyBFdGhlcm5ldDogRXR5cGUgPSBJbnRlcm5ldCBJUCAoSVB2NCksRGVzdGluYXRpb25BZGRyZ > XNz > OlswMC1GRi0wNi0xNi1FNi1FMV0sU291cmNlQWRkcmVzczpbMDAtRkYtMDUtMTYtRTYtRTFdD > Qor > IElwdjQ6IFNyYyA9IDEwLjEuNDAuNDIsIERlc3QgPSAxMC4xLjEuODUsIE5leHQgUHJvdG9jb > 2wg > PSBUQ1AsIFBhY2tldCBJRCA9IDEzMzgsIFRvdGFsIElQIExlbmd0aCA9IDkxDQorIFRjcDogR > mxh > Z3M9Li4uQVAuLi4sIFNyY1BvcnQ9NTQ3OTQsIERzdFBvcnQ9TERBUCgzODkpLCBQYXlsb2FkT > GVu > PTUxLCBTZXE9MTMzMDUwODI3MiAtIDEzMzA1MDgzMjMsIEFjaz0xNDYyNzE4NzgwLCBXaW49M > jU2 > IChzY2FsZSBmYWN0b3IgMHg4KSA9IDY1NTM2DQogIExkYXA6IEJpbmQgUmVxdWVzdCwgTWVzc > 2Fn > ZUlEOiAxLCBWZXJzaW9uOiAzDQotIExEQVBNZXNzYWdlOiBCaW5kIFJlcXVlc3QsIE1lc3NhZ > 2VJ > RDogMQ0KICAtIFBhcnNlckhlYWRlcjogDQogICAtIEFzbklkOiBTZXF1ZW5jZSBhbmQgU2Vxd > WVu > Y2VPZiB0eXBlcyAoVW5pdmVyc2FsIDE2KQ0KICAgIC0gTG93VGFnOiANCiAgICAgICBDbGFzc > zog > ICAgKDAwLi4uLi4uKSBVbml2ZXJzYWwgKDApDQogICAgICAgVHlwZTogICAgICguLjEuLi4uL > ikg > Q29uc3RydWN0ZWQNCiAgICAgICBUYWdWYWx1ZTogKC4uLjEwMDAwKSAxNg0KICAgLSBBc25MZ > W46 > IExlbmd0aCA9IDQ1LCBMZW5ndGhPZkxlbmd0aCA9IDQNCiAgICAgIExlbmd0aFR5cGU6IExlb > md0 > aE9mTGVuZ3RoID0gNA0KICAgICAgTGVuZ3RoOiA0NSBieXRlcw0KICAtIE1lc3NhZ2VJRDogM > Q0K > ICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAtIEFzbklkOiBJbnRlZ2VyIHR5cGUgKFVua > XZl > cnNhbCAyKQ0KICAgICAtIExvd1RhZzogDQogICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pI > FVu > aXZlcnNhbCAoMCkNCiAgICAgICAgVHlwZTogICAgICguLjAuLi4uLikgUHJpbWl0aXZlDQogI > CAg > ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMTApIDINCiAgICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgT > GVu > Z3RoT2ZMZW5ndGggPSAwDQogICAgICAgTGVuZ3RoOiAxIGJ5dGVzLCBMZW5ndGhPZkxlbmd0a > CA9 > IDANCiAgICAgQXNuSW50OiAxICgweDEpDQogIC0gT3BlcmF0aW9uSGVhZGVyOiBCaW5kIFJlc > XVl > c3QsIDAoMCkNCiAgIC0gQXNuSWQ6IEFwcGxpY2F0aW9uIENvbnN0cnVjdGVkIFRhZyAoMCkNC > iAg > ICAtIExvd1RhZzogDQogICAgICAgQ2xhc3M6ICAgICgwMS4uLi4uLikgQXBwbGljYXRpb24gK > DEp > DQogICAgICAgVHlwZTogICAgICguLjEuLi4uLikgQ29uc3RydWN0ZWQNCiAgICAgICBUYWdWY > Wx1 > ZTogKC4uLjAwMDAwKSAwDQogICAtIEFzbkxlbjogTGVuZ3RoID0gMzYsIExlbmd0aE9mTGVuZ > 3Ro > ID0gNA0KICAgICAgTGVuZ3RoVHlwZTogTGVuZ3RoT2ZMZW5ndGggPSA0DQogICAgICBMZW5nd > Gg6 > IDM2IGJ5dGVzDQogIC0gQmluZFJlcXVlc3Q6IFZlcnNpb246MywgTmFtZTpjbj11c2VyMSxkY > z1t > YXhjcmMsZGM9Y29tLCBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpb > XBs > ZQ0KICAgLSBWZXJzaW9uOiAzDQogICAgLSBBc25JbnRlZ2VySGVhZGVyOiANCiAgICAgLSBBc > 25J > ZDogSW50ZWdlciB0eXBlIChVbml2ZXJzYWwgMikNCiAgICAgIC0gTG93VGFnOiANCiAgICAgI > CAg > IENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhbCAoMCkNCiAgICAgICAgIFR5cGU6ICAgI > CAo > Li4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgVGFnVmFsdWU6ICguLi4wMDAxMCkgMg0KI > CAg > ICAtIEFzbkxlbjogTGVuZ3RoID0gMSwgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICAgIExlb > md0 > aDogMSBieXRlcywgTGVuZ3RoT2ZMZW5ndGggPSAwDQogICAgICBBc25JbnQ6IDMgKDB4MykNC > iAg > IC0gTmFtZTogY249dXNlcjEsZGM9bWF4Y3JjLGRjPWNvbQ0KICAgIC0gQXNuT2N0ZXRTdHJpb > mdI > ZWFkZXI6IA0KICAgICAtIEFzbklkOiBPY3RldFN0cmluZyB0eXBlIChVbml2ZXJzYWwgNCkNC > iAg > ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMDAuLi4uLi4pIFVuaXZlcnNhb > CAo > MCkNCiAgICAgICAgIFR5cGU6ICAgICAoLi4wLi4uLi4pIFByaW1pdGl2ZQ0KICAgICAgICAgV > GFn > VmFsdWU6ICguLi4wMDEwMCkgNA0KICAgICAtIEFzbkxlbjogTGVuZ3RoID0gMjUsIExlbmd0a > E9m > TGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDI1IGJ5dGVzLCBMZW5ndGhPZkxlbmd0aCA9I > DAN > CiAgICAgIE9jdGV0U3RyZWFtOiBjbj11c2VyMSxkYz1tYXhjcmMsZGM9Y29tDQogICAtIEF1d > Ghl > bnRpY2F0aW9uOiBVc2VyTmFtZTogaW5pdCwgQXV0aGVudGljYXRpb24gdHlwZSA9IHNpbXBsZ > Q0K > ICAgIC0gQXV0aGVudGljYXRpb25UeXBlSGVhZGVyOiBBdXRoZW50aWNhdGlvbiB0eXBlID0gc > 2lt > cGxlDQogICAgIC0gQXNuSWQ6IENvbnRleHQgU3BlY2lmaWMgUHJpbWl0aXZlIFRhZyAoMCkNC > iAg > ICAgIC0gTG93VGFnOiANCiAgICAgICAgIENsYXNzOiAgICAoMTAuLi4uLi4pIENvblRleHQgc > 3Bl > Y2lmaWMgKDIpDQogICAgICAgICBUeXBlOiAgICAgKC4uMC4uLi4uKSBQcmltaXRpdmUNCiAgI > CAg > ICAgIFRhZ1ZhbHVlOiAoLi4uMDAwMDApIDANCiAgICAgLSBBc25MZW46IExlbmd0aCA9IDQsI > Exl > bmd0aE9mTGVuZ3RoID0gMA0KICAgICAgICBMZW5ndGg6IDQgYnl0ZXMsIExlbmd0aE9mTGVuZ > 3Ro > ID0gMA0KICAgICAgU2ltcGxlQXV0aGVudGljYXRpb246IGluaXQNCiAgDQoNCi0tLS0tT3JpZ > 2lu > YWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIb3dhcmQgQ2h1IDxoeWNAc3ltYXMuY29tPiANClNlb > nQ6 > IFN1bmRheSwgRmVicnVhcnkgMywgMjAxOSAxMDoyNSBQTQ0KVG86IExlbyBUb2hpbGwgPGxpd > EBD > Qk9SRC5jb20+OyBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3JnDQpTdWJqZWN0OiBSZTogKElUU > yM4 > OTcwKSBiaW5kIGZhaWxzIHdoZW4gbGVuZ3RoIHZhbHVlIGlzIG11bHRpLWJ5dGUNCg0KbGl0Q > GNi > b3JkLmNvbSB3cm90ZToNCj4gRnVsbF9OYW1lOiBMZW8gVG9oaWxsDQo+IFZlcnNpb246IDIuN > C4z > MA0KPiBPUzogV2luZG93cyAxMA0KPiBVUkw6IA0KPiBodHRwczovL2RvY3MuZ29vZ2xlLmNvb > S9k > b2N1bWVudC9kLzEwdUtnOU5oM0hMaXVPelRiTGZpNlo3YkNmVWI4eF9BaTZXDQo+IEs1THFOe > mJ3 > QS9lZGl0P3VzcD1zaGFyaW5nDQo+IFN1Ym1pc3Npb24gZnJvbTogKE5VTEwpICg3NC43OS44L > jQx > KQ0KPiANCj4gDQo+IFN1bW1hcnk6IG9wZW5sZGFwIDIuNC4zMCBkb2VzIG5vdCBhY2NvbW1vZ > GF0 > ZSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZSANCj4gb24gYmluZCByZXF1ZXN0Lg0KPiANCj4gD > Qo+ > IEZpcnN0LCBJJ2xsIGFkbWl0IHRoYXQgSSdtIG91dCBvZiBteSBkZXB0aCBoZXJlLCBJJ20gc > nVu > bmluZyBhIG9sZGVyIA0KPiB2ZXJzaW9uLCBJJ20gb24gV2luZG93cywgYW5kIG15IHBhY2thZ > 2Ug > d2FzIGJ1aWx0IGJ5IEkgZG9uJ3Qga25vdy4gIA0KPiBCdXQgSSB3b3JrZWQgaGFyZCBlbm91Z > 2gg > dG8gdHJhY2sgdGhpcyBkb3duIHRoYXQgSSB3YW50IHlvdSB0byBrbm93IA0KPiB3aGF0IEkgZ > m91 > bmQuICBJIG1pZ2h0IHVwZ3JhZGUsIGJ1dCB0aGF0J3MgcHJvYmxlbWF0aWMuDQo+IA0KPiBBd > CBz > b21lIHBvaW50IG15IGJpbmRpbmdzIGZyb20gLm5ldCBiZWdhbiBmYWlsaW5nIHdpdGggInRoZ > SB1 > c2VybmFtZSANCj4gb3IgcGFzc3dvcmQgaXMgaW5jb3JyZWN0IiBCdXQgdGhleSB3ZXJlIGNvc > nJl > Y3QuICBJIGNvdWxkIGNvbmZpcm0gd2l0aCB2YXJpb3VzIG90aGVyIHRvb2xzLg0KPiBJIGNhc > HR1 > cmVkIHRoZSB3aXJlIHRyYWZmaWMgdG8gaXNvbGF0ZSB0aGUgcHJvYmxlbS4gSXQgdHVybnMgb > 3V0 > IHRoYXQgDQo+IFdpbmRvd3MgZm9ybXMgdGhlIGJpbmRpbmcgcmVxdWVzdCB1c2luZyAgYSBtd > Wx0 > aS1ieXRlIGxlbmd0aCBpbmRpY2F0b3IgaW4gdGhlIHJlcXVlc3QuDQo+IE9wZW5MZGFwIGFwc > GFy > ZW50bHkgZG9lcyBub3QgYWNjb21tb2RhdGUgdGhpcy4gIEkgY29tcGFyZWQgdG8gYSANCj4gc > mVx > dWVzdCBnZW5lcmF0ZWQgYnkgIGxkYXBzZWFyY2guZXhlLiAgVGhhdCByZXF1ZXN0LCB3aGlja > CBz > dWNjZWVkcywgIA0KPiB2YXJpZXMgb25seSBieSB1c2luZyBhIHNpbmdsZS1ieXRlIGxlbmd0a > CBp > bmRpY2F0b3IuDQo+IA0KPiBUaGUgbXVsdGktYnl0ZSBsZW5ndGggdmFsdWUgc2hvdWxkIGJlI > GFs > bG93ZWQsIHJpZ2h0PyAgSXNuJ3QgaXQgDQo+IHBvc3NpYmxlIHRvIGhhdmUgYSBiaW5kIHJlc > XVl > c3QgZGF0YSBwYWNrZXQgb2YgbGVuZ3RoID4gMTI3PyAgV2hpY2ggDQo+IHdvdWxkIHJlcXVpc > mUg > YSBtdWx0aS1ieXRlIGxlbmd0aCB2YWx1ZS4gIFBlcmhhcHMgdGhpcyB3YXMgZml4ZWQgaW4gY > SBs > YXRlciB2ZXJzaW9uLg0KPiANCj4gU2NyZWVuc2hvdHMgb2YgdGhlIHdpcmUgY2FwdHVyZSBoZ > XJl > OiANCj4gDQo+IGh0dHBzOi8vZG9jcy5nb29nbGUuY29tL2RvY3VtZW50L2QvMTB1S2c5TmgzS > Exp > dU96VGJMZmk2WjdiQ2ZVYjh4X0FpNlcNCj4gSzVMcU56YndBL2VkaXQ/dXNwPXNoYXJpbmcNC > g0K > VGhpcyBVUkwgaXMgaW5hY2Nlc3NpYmxlLCBwZXJtaXNzaW9uIGRlbmllZC4NCg0KSnVzdCBjb > 3B5 > IGhleCBkdW1wcyBvZiBib3RoIHJlcXVlc3RzIGhlcmUgaW4gdGV4dC4NCg0KLS0NCiAgLS0gS > G93 > YXJkIENodQ0KICBDVE8sIFN5bWFzIENvcnAuICAgICAgICAgICBodHRwOi8vd3d3LnN5bWFzL > mNv > bQ0KICBEaXJlY3RvciwgSGlnaGxhbmQgU3VuICAgICBodHRwOi8vaGlnaGxhbmRzdW4uY29tL > 2h5 > Yy8NCiAgQ2hpZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vc > mcv cHJvamVjdC8NCg== > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8970) bind fails when length value is multi-byte
by lit＠CBORD.com 21 Feb '19

21 Feb '19

--_000_BN8PR04MB619684C2863825C59B475C24BC7E0BN8PR04MB6196namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, any chance somebody could take a look at this? --_000_BN8PR04MB619684C2863825C59B475C24BC7E0BN8PR04MB6196namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:o=3D"urn:schemas-microsoft-com:office:office" xmlns:w=3D"urn:sc= hemas-microsoft-com:office:word" xmlns:m=3D"http://schemas.microsoft.com/of= fice/2004/12/omml" xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"#954F72"> <div class=3D"WordSection1"> <o:p> </o:p> Hello, any chance somebody could take a look at this= ? <o:p> </o:p> <o:p> </o:p> </div> </body> </html> --_000_BN8PR04MB619684C2863825C59B475C24BC7E0BN8PR04MB6196namp_--

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by vsmith＠interlinknetworks.com 20 Feb '19

20 Feb '19

<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Interlink Networks LLC. Interlink Networks LLC has not assigned rights and/or interest in this work to any party. I, Vernon Smith am authorized by Interlink Networks LLC, my employer, to release this work under the following terms. Interlink Networks LLC hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. Thanks, Vern <div class="moz-cite-prefix">On 2/20/2019 9:42 AM, Quanah Gibson-Mount wrote: </div> <blockquote type="cite" cite="mid:8A8B819A395EEAE290F20248@[192.168.1.39]">--On Tuesday, February 19, 2019 2:41 PM +0000 <a class="moz-txt-link-abbreviated" href="mailto:quanah@symas.com">quanah(a)symas.com</a> wrote: <blockquote type="cite">--On Tuesday, February 19, 2019 2:12 AM -0500 Vern Smith <a class="moz-txt-link-rfc2396E" href="mailto:vsmith@interlinknetworks.com"><vsmith(a)interlinknetworks.com></a> wrote: <blockquote type="cite">ITS#8957 and ITS#8968 are my submits and I was using those changes. ITS#8963 is for OpenLDAP servers and I only an using the libraries so it does not apply to my updates. </blockquote> Please keep replies to the ITS system. </blockquote> Hi, Although each change is individually tiny, the sum of changes is not. Can you please add an IPR to this ITS, as documented at <a class="moz-txt-link-rfc2396E" href="https://www.openldap.org/devel/contributing.html#notice"><https://www.openldap.org/devel/contributing.html#notice></a> Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <a class="moz-txt-link-rfc2396E" href="http://www.symas.com"><http://www.symas.com></a> </blockquote> </body> </html>

1 0

Re: (ITS#8980) Async mode and TLS Non-Blocking Issue
by quanah＠symas.com 20 Feb '19

20 Feb '19

--On Tuesday, February 19, 2019 2:41 PM +0000 quanah(a)symas.com wrote: > --On Tuesday, February 19, 2019 2:12 AM -0500 Vern Smith > <vsmith(a)interlinknetworks.com> wrote: > >> ITS#8957 and ITS#8968 are my submits and I was using those changes. >> ITS#8963 is for OpenLDAP servers and I only an using the libraries so it >> does not apply to my updates. > > Please keep replies to the ITS system. Hi, Although each change is individually tiny, the sum of changes is not. Can you please add an IPR to this ITS, as documented at <https://www.openldap.org/devel/contributing.html#notice> Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8982) Fix OpenLDAP headers so they're useful for development
by hyc＠symas.com 20 Feb '19

20 Feb '19

quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: RE25 > OS: N/A > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > It's currently difficult for downstream packagers to create a working > development package as some items required to build external modules are only > included what are considered "private" headers, such as slap.h (See ITS#7283). > SLAP_CB_{BYPASS,CONTINUE} are examples of items that are contained in slap.h > that are potentially required for building external modules. > > IIRC, it's also been discussed previously to rename "ldap_pvt.h" to "openldap.h" > to indicate it's ok to package this header file in a -devel package (I could > have the initial header name incorrect, it's been a while). This discussion is a bit awkward. OpenLDAP is an open source project. What we provide is a distribution of source code. It was never intended to be sliced and diced into individual binary packages. If you're developing modules for OpenLDAP, you're expected to have a complete OpenLDAP build tree in which your modules reside. Modules meant to run inside slapd are by definition *internal* - they are running inside slapd after all. The fact that they're written and maintained by 3rd parties doesn't change this. Header files marked "private" mean they're only for internal use within an OpenLDAP build tree. Applications that are generic LDAP clients should only use the public APIs. We can still discuss formally making some OpenLDAP-specific APIs public, but that should probably be done on a case by case basis. LDAP is supposed to be interoperable; we should not encourage broader use of OpenLDAP-specific APIs that rely on details of OpenLDAP's internal implementation. If they have no particular dependency on internals, then we may safely expose them. -- -- 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#8982) Fix OpenLDAP headers so they're useful for development
by quanah＠openldap.org 20 Feb '19

20 Feb '19

Full_Name: Quanah Gibson-Mount Version: RE25 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) It's currently difficult for downstream packagers to create a working development package as some items required to build external modules are only included what are considered "private" headers, such as slap.h (See ITS#7283). SLAP_CB_{BYPASS,CONTINUE} are examples of items that are contained in slap.h that are potentially required for building external modules. IIRC, it's also been discussed previously to rename "ldap_pvt.h" to "openldap.h" to indicate it's ok to package this header file in a -devel package (I could have the initial header name incorrect, it's been a while).

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs