- openldap-bugs - openldap.org

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by douglas.royds＠taitradio.com 19 Nov '18

19 Nov '18

URL: ftp://ftp.openldap.org/incoming/douglas-royds-181120.patch On 19/11/18 12:34 PM, Howard Chu wrote: > Thanks. According to this link, we shouldn't even need the date/time portion > of this patch. > > Under the section "Reading the Variable" we have >> gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) > https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8e… > > I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. > > I'm inclined to just tweak WHOWHERE and let gcc handle the rest. Once again, good point. I have removed the date and time changes from the patch, and only kept the WHOWHERE change, still using the existence of a SOURCE_DATE_EPOCH to decide whether to fix the string or not.

1 0

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com 19 Nov '18

19 Nov '18

douglas.royds(a)taitradio.com wrote: > On 17/11/18 11:42 AM, Howard Chu wrote: > >> douglas.royds(a)taitradio.com wrote: >>> URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch >>> >>> This updated patch also sets the date and time strings to the >>> SOURCE_DATE_EPOCH. >> Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer? >> This value format needs to be documented. >> >> Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools >> understand this option. It will fail on other platforms like *BSD, Solaris, that aren't >> using a GNU userland. >> >> Why can't you simply provide an already formatted date & time that can be used >> directly, instead of needing to be reformatted here? > > > URL: ftp://ftp.openldap.org/incoming/douglas-royds-181119.patch > > Good point about BSD, my mistake. I have modified the patch to support > BSD platforms as well, though I don't have access to a BSD platform to > test it. > > I have added a code comment with a link to the SOURCE_DATE_EPOCH > specification: https://reproducible-builds.org/specs/source-date-epoch/ > > A more human-readable description and tips for its use can be found > here: https://reproducible-builds.org/docs/source-date-epoch/ Thanks. According to this link, we shouldn't even need the date/time portion of this patch. Under the section "Reading the Variable" we have > gcc (>= 7, Debian >= 5.3.1-17, Debian >= 6.1.1-1) https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=e3e8c48c4a494d9da741c1c8e… I.e., gcc itself will set __DATE__ and __TIME__ accordingly if SOURCE_DATE_EPOCH is set. I'm inclined to just tweak WHOWHERE and let gcc handle the rest. -- -- 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#8928) Reproducibility: Remove user, hostname, pwd from version string
by douglas.royds＠taitradio.com 19 Nov '18

19 Nov '18

On 17/11/18 11:42 AM, Howard Chu wrote: > douglas.royds(a)taitradio.com wrote: >> URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch >> >> This updated patch also sets the date and time strings to the >> SOURCE_DATE_EPOCH. > Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer? > This value format needs to be documented. > > Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools > understand this option. It will fail on other platforms like *BSD, Solaris, that aren't > using a GNU userland. > > Why can't you simply provide an already formatted date & time that can be used > directly, instead of needing to be reformatted here? URL: ftp://ftp.openldap.org/incoming/douglas-royds-181119.patch Good point about BSD, my mistake. I have modified the patch to support BSD platforms as well, though I don't have access to a BSD platform to test it. I have added a code comment with a link to the SOURCE_DATE_EPOCH specification: https://reproducible-builds.org/specs/source-date-epoch/ A more human-readable description and tips for its use can be found here: https://reproducible-builds.org/docs/source-date-epoch/

1 0

Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
by quanah＠symas.com 18 Nov '18

18 Nov '18

--On Sunday, November 18, 2018 7:20 PM +0100 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: >> since they're working on getting the 2.1.27 release out anytime now >> and this should likely be fixed as a part of that release. > It seems they cut the release yesterday: > > ftp://ftp.cyrusimap.org/cyrus-sasl/ Nice, they said they were going to cut another RC first. Guess that went=20 out the window:=20 <https://lists.andrew.cmu.edu/pipermail/cyrus-devel/2018-November/004383.htm= l> --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#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
by michael＠stroeder.com 18 Nov '18

18 Nov '18

On 11/18/18 7:13 PM, Quanah Gibson-Mount wrote: > --On Sunday, November 18, 2018 5:48 PM +0000 hyc(a)symas.com wrote: >> Sounds like this is an issue for the Cyrus SASL project. Their plugin is >> returning a SASL_BADPROT error code on all failures, instead of a more >> meaningful code like SASL_BADAUTH. > > I opened <https://github.com/cyrusimap/cyrus-sasl/issues/545> Thanks. > since they're working on getting the 2.1.27 release out anytime now > and this should likely be fixed as a part of that release. It seems they cut the release yesterday: ftp://ftp.cyrusimap.org/cyrus-sasl/ Nevermind, I'm not using SASL password mechs for anything serious. Just stumbled across this while implementing a regression test for bad password in ldap0 module which explicitly checks that invalidCredentials(49) is returned. Ciao, Michael.

1 0

Re: (ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
by quanah＠symas.com 18 Nov '18

18 Nov '18

--On Sunday, November 18, 2018 5:48 PM +0000 hyc(a)symas.com wrote: > Sounds like this is an issue for the Cyrus SASL project. Their plugin is > returning a SASL_BADPROT error code on all failures, instead of a more > meaningful code like SASL_BADAUTH. I opened <https://github.com/cyrusimap/cyrus-sasl/issues/545> since they're working on getting the 2.1.27 release out anytime now and this should likely be fixed as a part of that release. --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#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
by hyc＠symas.com 18 Nov '18

18 Nov '18

michael(a)stroeder.com wrote: > Full_Name: > Version: 2.4.46 > OS: openSUSE Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (213.240.182.29) > > > SASL bind with SCRAM-SHA-1 does not return invalidCredentials (49) in case of a > wrong password being used while DIGEST-MD5 and other password mechs works as > expected. > > This might lead to different error handling in client applications if the user > input a wrong password. > > This proves SCRAM-SHA-1 is enabled and working: > > $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w test123 > SASL/SCRAM-SHA-1 authentication started > SASL username: test42 > SASL SSF: 0 > dn:uid=test42,ou=testing,dc=stroeder,dc=de > > But wrong password returns other(80) as result code: > > $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w wrong > SASL/SCRAM-SHA-1 authentication started > ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) > additional info: SASL(-5): bad protocol / cancel: StoredKey mismatch > > Now testing DIGEST-MD5: > > $ ldapwhoami -Y DIGEST-MD5 -U test42 -w test123 > SASL/DIGEST-MD5 authentication started > SASL username: test42 > SASL SSF: 128 > SASL data security layer installed. > dn:uid=test42,ou=testing,dc=stroeder,dc=de > > Wrong password returns invalidCredentials(49) as expected: > > $ ldapwhoami -Y DIGEST-MD5 -U test42 -w wrong > SASL/DIGEST-MD5 authentication started > ldap_sasl_interactive_bind_s: Invalid credentials (49) > additional info: SASL(-13): authentication failure: client response doesn't > match what we generated (tried bogus) Sounds like this is an issue for the Cyrus SASL project. Their plugin is returning a SASL_BADPROT error code on all failures, instead of a more meaningful code like SASL_BADAUTH. Closing this ITS. -- -- 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#8937) Possibly wrong MDB_DUPFIXED flag check
by hyc＠symas.com 18 Nov '18

18 Nov '18

juerg.bircher(a)gmail.com wrote: > Full_Name: Juerg Bircher > Version: LMDB master > OS: macOS > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (178.83.86.107) > > > In mdb_cursor_put the flag MDB_DUPFIXED is checked on line 7628 as follows: > > if ((mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) > == MDB_DUPFIXED) > np->mp_flags |= P_LEAF2; > > Should it not be like this: > if (mc->mc_db->md_flags & MDB_DUPFIXED) > np->mp_flags |= P_LEAF2; No, the code is correct. > According to the documentation: > * <li>#MDB_DUPFIXED > * This flag may only be used in combination with #MDB_DUPSORT. That is documentation for users of the API. It does not dictate what LMDB does internally. > So the expression (mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == > MDB_DUPFIXED) would never match. False. There's no bug here. Closing this ITS. -- -- 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#8937) Possibly wrong MDB_DUPFIXED flag check
by juerg.bircher＠gmail.com 18 Nov '18

18 Nov '18

Full_Name: Juerg Bircher Version: LMDB master OS: macOS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (178.83.86.107) In mdb_cursor_put the flag MDB_DUPFIXED is checked on line 7628 as follows: if ((mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == MDB_DUPFIXED) np->mp_flags |= P_LEAF2; Should it not be like this: if (mc->mc_db->md_flags & MDB_DUPFIXED) np->mp_flags |= P_LEAF2; According to the documentation: * <li>#MDB_DUPFIXED * This flag may only be used in combination with #MDB_DUPSORT. So the expression (mc->mc_db->md_flags & (MDB_DUPSORT|MDB_DUPFIXED)) == MDB_DUPFIXED) would never match.

1 0

(ITS#8936) SASL/SCRAM-SHA-1 bind returns other(80) instead of invalidCredentials (49) in case of wrong password
by michael＠stroeder.com 18 Nov '18

18 Nov '18

Full_Name: Version: 2.4.46 OS: openSUSE Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.240.182.29) SASL bind with SCRAM-SHA-1 does not return invalidCredentials (49) in case of a wrong password being used while DIGEST-MD5 and other password mechs works as expected. This might lead to different error handling in client applications if the user input a wrong password. This proves SCRAM-SHA-1 is enabled and working: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w test123 SASL/SCRAM-SHA-1 authentication started SASL username: test42 SASL SSF: 0 dn:uid=test42,ou=testing,dc=stroeder,dc=de But wrong password returns other(80) as result code: $ ldapwhoami -Y SCRAM-SHA-1 -U test42 -w wrong SASL/SCRAM-SHA-1 authentication started ldap_sasl_interactive_bind_s: Other (e.g., implementation specific) error (80) additional info: SASL(-5): bad protocol / cancel: StoredKey mismatch Now testing DIGEST-MD5: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w test123 SASL/DIGEST-MD5 authentication started SASL username: test42 SASL SSF: 128 SASL data security layer installed. dn:uid=test42,ou=testing,dc=stroeder,dc=de Wrong password returns invalidCredentials(49) as expected: $ ldapwhoami -Y DIGEST-MD5 -U test42 -w wrong SASL/DIGEST-MD5 authentication started ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: SASL(-13): authentication failure: client response doesn't match what we generated (tried bogus)

1 0

Re: (ITS#8935) slapo-ppolicy requires rewrite
by quanah＠symas.com 17 Nov '18

17 Nov '18

--On Saturday, November 17, 2018 11:27 AM +0000 michael(a)stroeder.com wrote: > With such a layout the standard schema shipped with the software is not > part of cn=config but can still be dynamically changed (by directly > modifying subschema subentry). But there's always a way out of trouble > because you can manually fix the separate LDIF schema file(s). You can manually fix the ones stored in cn=config with OpenLDAP now, and you can also change it dynamically. I'm not sure how either of those statements address the problem discussed in this ITS. Quite frankly, I wrote a tool to automatically update the schema stored with cn=config so that it matched whatever was shipped in a given release on upgrade when I worked @ Zimbra: <https://github.com/Zimbra/zm-core-utils/blob/develop/src/libexec/zmldapsche…> I.e., I don't really see what in the above is different from what you can do now, nor do I see how it resolves the issue of a binary compiled file that must have references to valid schema compiled into it. --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#8935) slapo-ppolicy requires rewrite
by quanah＠symas.com 17 Nov '18

17 Nov '18

--On Saturday, November 17, 2018 9:49 AM +0000 michael(a)stroeder.com wrote: > Your conclusion is to hard-code the ppolicy schema into the C code. > If you think this to the end you have to move *all* standard schema > installed to schema_prep.c. The above statement is simply not true. The difference here is the fact that the ppolicy binary has direct references to the schema in its code, which requires it to have matching schema prior to slapd being able to start. You can still start slapd when any schema (outside of the few items hard coded in schema_prep for the same reason) is different. You have the ability at that point to modify slapd via online operations post-upgrade. --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#8935) slapo-ppolicy requires rewrite
by michael＠stroeder.com 17 Nov '18

17 Nov '18

On 11/17/18 11:35 AM, hyc(a)symas.com wrote: > We could instead ship an update.ldif containing the mods between > different schema versions, that must be applied with slapmodify > during the update process... IMO too many prerequisites must be perfectly full-filled and thus is too fragile. That's one of the things where e.g. OpenDS/OpenDJ does a much better job with its cn=config: The schema shipped with the server is stored in various LDIF files in a config directory along with file rootdse.ldif holding cn=config. Schema directly added by modifying cn=schema is sent to a separate user schema file. With such a layout the standard schema shipped with the software is not part of cn=config but can still be dynamically changed (by directly modifying subschema subentry). But there's always a way out of trouble because you can manually fix the separate LDIF schema file(s). Ciao, Michael.

1 0

Re: (ITS#8935) slapo-ppolicy requires rewrite
by hyc＠symas.com 17 Nov '18

17 Nov '18

michael(a)stroeder.com wrote: > The root cause is that updating slapd with its default schema installed > does not update existing content of cn=schema,cn=config. > > You have to tackle this root cause and not only solve it for a > particular overlay. We could instead ship an update.ldif containing the mods between different schema versions, that must be applied with slapmodify during the update process... -- -- 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#8935) slapo-ppolicy requires rewrite
by michael＠stroeder.com 17 Nov '18

17 Nov '18

The root cause is that updating slapd with its default schema installed does not update existing content of cn=schema,cn=config. You have to tackle this root cause and not only solve it for a particular overlay. Your conclusion is to hard-code the ppolicy schema into the C code. If you think this to the end you have to move *all* standard schema installed to schema_prep.c. IMO this is bad design. But I'm not the one to decide on that. :-/ Ciao, Michael.

1 0

Re: (ITS#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by quanah＠symas.com 17 Nov '18

17 Nov '18

--On Saturday, November 17, 2018 12:14 AM +0000 quanah(a)symas.com wrote: > --On Tuesday, August 07, 2018 5:33 AM +0000 sudhir.singam(a)gmail.com wrote: > >> Full_Name: sudhir reddy singam >> Version: master branch >> OS: fedora >> URL: >> Submission from: (NULL) (131.228.66.13) Never mind, I see this is a duplicate of ITS#8847. Please do not file duplicate ITSes for the same issue. --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#8893) New LDAP option to support binding to specific IPv4/IPv6 address at client side
by quanah＠symas.com 17 Nov '18

17 Nov '18

--On Tuesday, August 07, 2018 5:33 AM +0000 sudhir.singam(a)gmail.com wrote: > Full_Name: sudhir reddy singam > Version: master branch > OS: fedora > URL: > Submission from: (NULL) (131.228.66.13) > > > > The attached file is derived from OpenLDAP Software. All of the > modifications to > OpenLDAP Software represented in the following patch(es) were developed by > NOKIA. NOKIA has not assigned rights and/or interest in this work to any > party. I, SINGAM SUDHIR REDDY authorized by NOKIA, my employer, to > release this work under the following terms. > > NOKIA 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. > > **** Hello, There is no patch associated with this ITS. Can you please respond to this email and attach it? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8935) slapo-ppolicy requires rewrite
by quanah＠openldap.org 16 Nov '18

16 Nov '18

Full_Name: Quanah Gibson-Mount Version: OpenLDAP 2.4 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) In OpenLDAP 2.4.43, a new attribute was added to the external ppolicy schema (ITS#8185). While this worked fine with older slapd.conf based configurations where the ppolicy schema file was replaced on upgrade, it was a complete and utter disaster for deployments using cn=config, as the ppolicy overlay references all the attributes defined in external ppolicy schema file. To be able to upgrade without failure, one would have export cn=config, update the binaries, update the ppolicy schema information in the exported cn=config database, re-import cn=config, and then start slapd. This broke the usual ability to do in-place upgrades with cn=config. Instead, the entire contents of the ppolicy.schema file should be internalized to the ppolicy overlay, similar to how the accesslog overlay is written, and the external ppolicy.schema file deleted. This will allow non-breaking upgrades for both slapd.conf and cn=config based configurations.

1 0

Re: (ITS#7578) delta-sync multimaster replication issue
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Friday, April 26, 2013 8:07 PM +0000 afrunning(a)gmail.com wrote: > Full_Name: Al F > Version: 2.4.35 > OS: Redhat 6.4 - x64 > URL: https://dl.dropboxusercontent.com/u/982376/its/al-f-130426.zip > Submission from: (NULL) (74.123.146.10) > > > Hi, I have a multimaster system utilizing delta-sync for replication. The > system is utilizing mdb for both the user and the accesslog data. I have > ppolicy & memberof overlays enabled as well. all of my writes are > directed at a single server using a load balancer. I have found that > when a user has a pwdFailureTime attribute set on their entry, if an > administrator resets the password, "null_callback : error code 0x10" is > produced in the log on the secondary system and the secondary system goes > into refresh mode. Hello, I believe this is the same as ITS#8927, which has been fixed for the upcoming OpenLDAP 2.4.47 release. 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

Re: (ITS#8928) Reproducibility: Remove user, hostname, pwd from version string
by hyc＠symas.com 16 Nov '18

16 Nov '18

douglas.royds(a)taitradio.com wrote: > URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch > > This updated patch also sets the date and time strings to the > SOURCE_DATE_EPOCH. Are you intending a SOURCE_DATE_EPOCH to be a Unix time value? I.e., an integer? This value format needs to be documented. Unfortunately, your use of date -d is nonportable, it appears that only the GNU tools understand this option. It will fail on other platforms like *BSD, Solaris, that aren't using a GNU userland. Why can't you simply provide an already formatted date & time that can be used directly, instead of needing to be reformatted here? > The WHOWHERE string will now be set to simply "openldap" in the case > that a SOURCE_DATE_EPOCH is set. > > Tait Communications Ltd 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. > > > > > -- -- 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#8887) doc/guide/admin/backends.sdf: is is
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Wednesday, August 01, 2018 2:44 AM +0000 dpa-bugs(a)aegee.org wrote: > Full_Name: &#1044;&#1080;&#1083;&#1103;&#1085; > &#1055;&#1072;&#1083;&#1072;&#1091;&#1079;&#1 > 086;&#1074; Version: 2.4 documentation > OS: Linux > URL: > Submission from: (NULL) (103.252.202.53) > > > Consider this change (remove doubled " is is " Thanks for the report! This patch has been applied. --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#8899) SLAPD failed to start after updating openldap 2.4.46
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Friday, August 17, 2018 12:56 PM +0000 muthaiyan1991(a)gmail.com wrote: > Full_Name: Muthaiyan Vel > Version: 2.4.46 > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (116.197.184.12) > > > I have recently updated openldap to version 2.4.46. After upgrading SLAPD > is failed to start. Its showing an error "slap_sasl_init: auxprop add > plugin failed". > I have compiled the openldap with mdb. > > Please help to solve this problem. Hello Muthaiyan, The ITS system is for reporting software bugs. Usage questions such as this belong on the openldap-technical mailing list (<http://www.openldap.org/lists/mm/listinfo/openldap-technical>) and would receive a much quicker response time. I would note that your log was not "full debug" mode as you stated (which would be -d -1), and the warning you encountered is common and not indicative of an actual problem. 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

Re: (ITS#8902) man page update for slapadd(5)
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Friday, November 16, 2018 8:26 PM +0000 quanah(a)symas.com wrote: > The note for the -w argument does not apply to back-mdb, since back-mdb > uses an isolated snapshot of the database when performing the slapcat. > Thus the out of order "hot change" issue does not apply (which is the > problem with using -w with back-bdb/hdb). <https://github.com/quanah/openldap-scratch/tree/its8902> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8902) man page update for slapadd(5)
by quanah＠symas.com 16 Nov '18

16 Nov '18

The note for the -w argument does not apply to back-mdb, since back-mdb uses an isolated snapshot of the database when performing the slapcat. Thus the out of order "hot change" issue does not apply (which is the problem with using -w with back-bdb/hdb). -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8907) Memory leak on mass adding users to ldap
by quanah＠symas.com 16 Nov '18

16 Nov '18

Hi Alexey, If you are using standard syncrepl (rather than delta-syncrepl), I'm not sure what you're reporting is out of the ordinary and is not indicative of a memory link. This is also why the issue "resolves" when ldap2 is stopped. I.e., the issue is related to how syncrepl functions and what it stores in memory while the lagging consumer is pulling down the database. I suggest switching to using delta-syncrepl and seeing if you see the same issue. 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#8921) Content Sync Refresh Required when provider accesslog is empty
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Wednesday, September 26, 2018 8:40 PM +0000 au(a)hcsd.de wrote: > Full_Name: Stephan Austerm.hle > Version: 2.4.46 > messages when the provider has an empty accesslog (because it was freshly > setup and nothing has been added/updated since then). Hi Stephan, Are you positive you tested this with the OpenLDAP 2.4.46 Release? I already reported this issue via ITS#8100, which was explicitly fixed in 2.4.46. 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#8934) Openldap get crashing
by quanah＠symas.com 16 Nov '18

16 Nov '18

--On Thursday, November 15, 2018 6:51 AM +0000 raghavendra.gadiga(a)capgemini.com wrote: Hello, The ITS system is for bug reports. Usage questions, such as how to properly tune OpenLDAP and its data backends belong on the openldap-technical(a)openldap.org project list. Please redirect your questions there. <http://www.openldap.org/lists/mm/listinfo/openldap-technical> 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#8934) Openldap get crashing
by raghavendra.gadiga＠capgemini.com 15 Nov '18

15 Nov '18

Full_Name: Raghavendra Version: 2.4.44 OS: Debian GNU/Linux 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.191.35.25) Hi Team, We have noticed the ldap getting crash. Even the ldap process is running, we cant fetch the data in it, After debugging it we noticed that by removing the DB_CONFIG and restarting the service it started to work. 1) Can you let us know what was the cause. 2) Whats the ideal memory\cpu to be kept for ldap server. 3) Can you suggest tool which we can install to debug more. 4) More details about log setup for ldap. -Raghavendra.Gadiga

1 0

(ITS#8932) Fix slapd-config to honor rdnNormalize return code
by quanah＠openldap.org 09 Nov '18

09 Nov '18

Full_Name: Quanah Gibson-Mount Version: 2.4.46 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.239) When adding a new entry to cn=config, the code path currently does not check the value returned by rdnNoramlize. This needs to be fixed in case of a normalization error.

1 0

Re: (ITS#8878) PBKDF2 Is Broken (1 in 64 hashes)
by quanah＠symas.com 08 Nov '18

08 Nov '18

--On Tuesday, July 17, 2018 5:35 AM +0000 jroose(a)gmail.com wrote: > This is a significant bug in this module, because it causes the hash > algorithm to fail to be replicable by outside hash implementations 1 out > of every 64 hashes on average. Thanks for the report. This is now fixed in git master: - Log ----------------------------------------------------------------- commit d40a832db011985d6a6b787a88dd802b02d5d5dc Author: Ond??ej Kuzn??k <ondra(a)openldap.org> Date: Thu Nov 8 11:09:38 2018 +0000 ITS#8878 Include the first character in the transformation ----------------------------------------------------------------------- --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#8914) OpenLDAP and OpenSSL v1.1.1
by quanah＠symas.com 07 Nov '18

07 Nov '18

--On Friday, September 21, 2018 9:59 PM +0000 quanah(a)symas.com wrote: >>> OpenLDAP will not configure for building against OpenSSL v1.1.1 due to >>> SSLv3 being disabled. Hi Neal, OpenSSL v1.1.1 does not in fact disable SSLv3. I would surmise from your experience that you are using Fedora, which has its own custom build of OpenSSL v.1.1.1 where the developers have disabled SSLv3. You will need to file a bug with them, since this is not an OpenLDAP issue but rather an issue with how Fedora is changing OpenSSL. 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#8927) slapo-ppolicy is destructive to delta-sync replication
by quanah＠symas.com 07 Nov '18

07 Nov '18

--On Tuesday, October 16, 2018 6:59 PM +0000 quanah(a)symas.com wrote: > --On Tuesday, October 16, 2018 1:30 PM +0200 Ond=C5=99ej Kuzn=C3=ADk=20 > <ondra(a)mistotebe.net> wrote: > >>> - test we're a replicated op, not just on shadow >> >> The patch is available here: >> https://github.com/mistotebe/openldap/tree/its8927 > > I still get err 16 with this patch and the servers fall back to REFRESH. Note: Finally fixed with 04a52cef40560b9edec8037b23e444c460fe0d40 in 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#8931) deref'ing non-existent attributes should not result in protocolError
by michael＠stroeder.com 04 Nov '18

04 Nov '18

On 11/4/18 12:16 AM, hyc(a)symas.com wrote: > I don't see this in the deref code. It only returns protocolError if there is > any type of error when parsing the control itself. It was my fault. Sorry for the noise. Please close this ITS. Ciao, Michael.

1 0

Re: (ITS#8931) deref'ing non-existent attributes should not result in protocolError
by hyc＠symas.com 04 Nov '18

04 Nov '18

michael(a)stroeder.com wrote: > Full_Name: > Version: RE24 > OS: > URL: > Submission from: (NULL) (46.183.103.8) > > > In aehostd I try to limit the number of required search requests. Therefore I'm > using the deref control to read group and sudoers entries referenced in service > groups. > > If there are no such references (yet) slapd currently returns protocolError. I don't see this in the deref code. It only returns protocolError if there is any type of error when parsing the control itself. It knows nothing about any referenced entries when it's parsing the control. There are no other instances of protocolError in the overlay. -- -- 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#8931) deref'ing non-existent attributes should not result in protocolError
by michael＠stroeder.com 03 Nov '18

03 Nov '18

Full_Name: Version: RE24 OS: URL: Submission from: (NULL) (46.183.103.8) In aehostd I try to limit the number of required search requests. Therefore I'm using the deref control to read group and sudoers entries referenced in service groups. If there are no such references (yet) slapd currently returns protocolError. IMO this is wrong. It should simply omit the deref response control and the client has to deal with that. (No, to save round-trips, log-space and data traffic I don't want to read the service groups first to determine whether which deref attributes are present.)

1 0

Re: (ITS#8752) MMR delta-sync deadlock using slapd.conf
by hyc＠symas.com 01 Nov '18

01 Nov '18

ondra(a)mistotebe.net wrote: > On Thu, Oct 05, 2017 at 03:32:38AM +0000, quanah(a)openldap.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.45 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (47.208.148.239) >> >> >> There is a reproducible lockup with delta-sync based multimaster replication. >> The more masters exist the easier it is to trigger, with 100% reproducibility at >> 4 masters. >> >> Generally: >> >> Load a database onto a server with no syncprov/accesslog configuration. >> >> Stop slapd >> >> Reconfigure slapd.conf to include syncprov/accesslog overlays, and cn=accesslog >> DB for changes, and replication agreements with other servers >> >> Configure other servers for syncprov/accesslog, but no database >> >> start slapd on all servers >> >> execute a MOD operation sequentially across the servers (1, 2, 3, 4) >> >> slapd will deadlock on server 3 or 4 100% of the time > > This is still an issue at least in master - running the its8752 > regression test often results in the following deadlock: This says that thread 4 is still holding the LMDB writer mutex while running inside the accesslog overlay. Which it should not be, since back-mdb acquires and commits its LMDB transactions before letting any other module have control. > > (gdb) deadlock > Cycles: > Thread #5 (LWP 8024) in mdb_txn_renew0() at ./../../../libraries/liblmdb/mdb.c:2749 > Thread #4 (LWP 8023) in accesslog_op_mod() at accesslog.c:1988 > deadlock from root > Thread #3 (LWP 8022) in mdb_txn_renew0() at ./../../../libraries/liblmdb/mdb.c:2749 > > (gdb) thread apply all bt > > Thread 9 (Thread 0x7f9199ffd700 (LWP 15035)): > #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 > > Thread 8 (Thread 0x7f91a09fa700 (LWP 15034)): > #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 > > Thread 7 (Thread 0x7f91b12b7700 (LWP 8026)): > #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 > > Thread 6 (Thread 0x7f91b1ab8700 (LWP 8025)): > #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 > > Thread 5 (Thread 0x7f91b22b9700 (LWP 8024)): > #0 0x00007f91b5dda352 in __pthread_mutex_lock_full [waiting on thread 4 (LWP 8023)] (mutex=0x7f91b8114040) at ../nptl/pthread_mutex_lock.c:313 > #1 0x000000000051a881 in mdb_txn_renew0 (txn=0x1027ac0) at ./../../../libraries/liblmdb/mdb.c:2749 > #2 0x000000000051afab in mdb_txn_begin (env=0xf24e10, parent=0x0, flags=0, ret=0x7f91b22b7190) at ./../../../libraries/liblmdb/mdb.c:2907 > #3 0x00000000005792f4 in mdb_opinfo_get (op=Modify request = {...}, mdb=0x7f91b543b010, rdonly=0, moip=0x7f91b22b7178) at id2entry.c:740 > #4 0x000000000052f989 in mdb_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at modify.c:584 > #5 0x00000000004f6d65 in overlay_op_walk (op=Modify request = {...}, rs=0x7f91b22b89b8, which=op_modify, oi=0xe29b10, on=0x0) at backover.c:706 > #6 0x00000000004f9d61 in over_op_func (op=Modify request = {...}, rs=0x7f91b22b89b8, which=op_modify) at backover.c:766 > #7 0x00000000004f8fb2 in over_op_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at backover.c:808 > #8 0x0000000000472e4e in fe_op_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at modify.c:307 > #9 0x0000000000471bf5 in do_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at modify.c:177 > #10 0x000000000044e1ce in connection_operation (ctx=0x7f91b22b8b78, arg_v=0x7f919c100fa0) at connection.c:1169 > #11 0x000000000044c3a1 in connection_read_thread (ctx=0x7f91b22b8b78, argv=0xf) at connection.c:1326 > > Thread 4 (Thread 0x7f91b2aba700 (LWP 8023)): > #2 0x00007f91b815f275 in ldap_pvt_thread_mutex_lock [waiting on thread 5 (LWP 8024)] (mutex=0xe7c328) at thr_posix.c:307 > #3 0x00007f91b54fffbc in accesslog_op_mod (op=Modify request = {...}, rs=0x7f91b2ab8bd8) at accesslog.c:1988 > #4 0x00000000004f6cc1 in overlay_op_walk (op=Modify request = {...}, rs=0x7f91b2ab8bd8, which=op_modify, oi=0xe29b10, on=0xe7c0c0) at backover.c:691 > #5 0x00000000004f9d61 in over_op_func (op=Modify request = {...}, rs=0x7f91b2ab8bd8, which=op_modify) at backover.c:766 > #6 0x00000000004f8fb2 in over_op_modify (op=Modify request = {...}, rs=0x7f91b2ab8bd8) at backover.c:808 > #7 0x00000000004ec259 in syncrepl_updateCookie (si=0xe7aa90, op=Modify request = {...}, syncCookie=0x7f91b2ab91f0, save=1) at syncrepl.c:4051 > #8 0x00000000004e978e in do_syncrep2 (op=Modify request = {...}, si=0xe7aa90) at syncrepl.c:1206 > #9 0x00000000004e2556 in do_syncrepl (ctx=0x7f91b2ab9b78, arg=0xe7b030) at syncrepl.c:1604 > > Thread 3 (Thread 0x7f91b32bb700 (LWP 8022)): > #0 0x00007f91b5dda352 in __pthread_mutex_lock_full [waiting on thread 4 (LWP 8023)] (mutex=0x7f91b8114040) at ../nptl/pthread_mutex_lock.c:313 > #1 0x000000000051a881 in mdb_txn_renew0 (txn=0x1027ac0) at ./../../../libraries/liblmdb/mdb.c:2749 > #2 0x000000000051afab in mdb_txn_begin (env=0xf24e10, parent=0x0, flags=0, ret=0x7f91a4001170) at ./../../../libraries/liblmdb/mdb.c:2907 > #3 0x00000000005792f4 in mdb_opinfo_get (op=Search request = {...}, mdb=0x7f91b543b010, rdonly=0, moip=0xe7b348) at id2entry.c:740 > #4 0x000000000057989d in mdb_txn (op=Search request = {...}, txnop=1, ptr=0xe7b348) at id2entry.c:812 > #5 0x00000000004ee059 in syncrepl_entry (si=0xe7b0f0, op=Search request = {...}, entry="dc=example,dc=com", modlist=0x7f91b32ba1a8, syncstate=1, syncUUID=0x7f91b32ba140, syncCSN=0x0) at syncrepl.c:3087 > #6 0x00000000004e8cac in do_syncrep2 (op=Search request = {...}, si=0xe7b0f0) at syncrepl.c:1056 > #7 0x00000000004e2556 in do_syncrepl (ctx=0x7f91b32bab78, arg=0xe7b6d0) at syncrepl.c:1604 > > Thread 2 (Thread 0x7f91b3abc700 (LWP 8021)): > #0 0x00007f91b5d0b207 in epoll_wait (epfd=6, events=0xdebc50, maxevents=1024, timeout=7000) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30 > #1 0x000000000044591a in slapd_daemon_task (ptr=0x1232700) at daemon.c:2745 > > Thread 1 (Thread 0x7f91b5761780 (LWP 8006)): > #1 0x00007f91b815f11d in ldap_pvt_thread_join (thread=140263761364736, thread_return=0x0) at thr_posix.c:208 > #2 0x0000000000443a1b in slapd_daemon () at daemon.c:3157 > #3 0x000000000041ec5b in main (argc=8, argv=0x7ffcee967dc8) at main.c:1018 > -- -- 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#8752) MMR delta-sync deadlock using slapd.conf
by ondra＠mistotebe.net 01 Nov '18

01 Nov '18

On Thu, Oct 05, 2017 at 03:32:38AM +0000, quanah(a)openldap.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.208.148.239) > > > There is a reproducible lockup with delta-sync based multimaster replication. > The more masters exist the easier it is to trigger, with 100% reproducibility at > 4 masters. > > Generally: > > Load a database onto a server with no syncprov/accesslog configuration. > > Stop slapd > > Reconfigure slapd.conf to include syncprov/accesslog overlays, and cn=accesslog > DB for changes, and replication agreements with other servers > > Configure other servers for syncprov/accesslog, but no database > > start slapd on all servers > > execute a MOD operation sequentially across the servers (1, 2, 3, 4) > > slapd will deadlock on server 3 or 4 100% of the time This is still an issue at least in master - running the its8752 regression test often results in the following deadlock: (gdb) deadlock Cycles: Thread #5 (LWP 8024) in mdb_txn_renew0() at ./../../../libraries/liblmdb/mdb.c:2749 Thread #4 (LWP 8023) in accesslog_op_mod() at accesslog.c:1988 deadlock from root Thread #3 (LWP 8022) in mdb_txn_renew0() at ./../../../libraries/liblmdb/mdb.c:2749 (gdb) thread apply all bt Thread 9 (Thread 0x7f9199ffd700 (LWP 15035)): #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 Thread 8 (Thread 0x7f91a09fa700 (LWP 15034)): #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 Thread 7 (Thread 0x7f91b12b7700 (LWP 8026)): #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 Thread 6 (Thread 0x7f91b1ab8700 (LWP 8025)): #3 0x00007f91b815f20d in ldap_pvt_thread_cond_wait (cond=0xe11cb8, mutex=0xe11c90) at thr_posix.c:288 Thread 5 (Thread 0x7f91b22b9700 (LWP 8024)): #0 0x00007f91b5dda352 in __pthread_mutex_lock_full [waiting on thread 4 (LWP 8023)] (mutex=0x7f91b8114040) at ../nptl/pthread_mutex_lock.c:313 #1 0x000000000051a881 in mdb_txn_renew0 (txn=0x1027ac0) at ./../../../libraries/liblmdb/mdb.c:2749 #2 0x000000000051afab in mdb_txn_begin (env=0xf24e10, parent=0x0, flags=0, ret=0x7f91b22b7190) at ./../../../libraries/liblmdb/mdb.c:2907 #3 0x00000000005792f4 in mdb_opinfo_get (op=Modify request = {...}, mdb=0x7f91b543b010, rdonly=0, moip=0x7f91b22b7178) at id2entry.c:740 #4 0x000000000052f989 in mdb_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at modify.c:584 #5 0x00000000004f6d65 in overlay_op_walk (op=Modify request = {...}, rs=0x7f91b22b89b8, which=op_modify, oi=0xe29b10, on=0x0) at backover.c:706 #6 0x00000000004f9d61 in over_op_func (op=Modify request = {...}, rs=0x7f91b22b89b8, which=op_modify) at backover.c:766 #7 0x00000000004f8fb2 in over_op_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at backover.c:808 #8 0x0000000000472e4e in fe_op_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at modify.c:307 #9 0x0000000000471bf5 in do_modify (op=Modify request = {...}, rs=0x7f91b22b89b8) at modify.c:177 #10 0x000000000044e1ce in connection_operation (ctx=0x7f91b22b8b78, arg_v=0x7f919c100fa0) at connection.c:1169 #11 0x000000000044c3a1 in connection_read_thread (ctx=0x7f91b22b8b78, argv=0xf) at connection.c:1326 Thread 4 (Thread 0x7f91b2aba700 (LWP 8023)): #2 0x00007f91b815f275 in ldap_pvt_thread_mutex_lock [waiting on thread 5 (LWP 8024)] (mutex=0xe7c328) at thr_posix.c:307 #3 0x00007f91b54fffbc in accesslog_op_mod (op=Modify request = {...}, rs=0x7f91b2ab8bd8) at accesslog.c:1988 #4 0x00000000004f6cc1 in overlay_op_walk (op=Modify request = {...}, rs=0x7f91b2ab8bd8, which=op_modify, oi=0xe29b10, on=0xe7c0c0) at backover.c:691 #5 0x00000000004f9d61 in over_op_func (op=Modify request = {...}, rs=0x7f91b2ab8bd8, which=op_modify) at backover.c:766 #6 0x00000000004f8fb2 in over_op_modify (op=Modify request = {...}, rs=0x7f91b2ab8bd8) at backover.c:808 #7 0x00000000004ec259 in syncrepl_updateCookie (si=0xe7aa90, op=Modify request = {...}, syncCookie=0x7f91b2ab91f0, save=1) at syncrepl.c:4051 #8 0x00000000004e978e in do_syncrep2 (op=Modify request = {...}, si=0xe7aa90) at syncrepl.c:1206 #9 0x00000000004e2556 in do_syncrepl (ctx=0x7f91b2ab9b78, arg=0xe7b030) at syncrepl.c:1604 Thread 3 (Thread 0x7f91b32bb700 (LWP 8022)): #0 0x00007f91b5dda352 in __pthread_mutex_lock_full [waiting on thread 4 (LWP 8023)] (mutex=0x7f91b8114040) at ../nptl/pthread_mutex_lock.c:313 #1 0x000000000051a881 in mdb_txn_renew0 (txn=0x1027ac0) at ./../../../libraries/liblmdb/mdb.c:2749 #2 0x000000000051afab in mdb_txn_begin (env=0xf24e10, parent=0x0, flags=0, ret=0x7f91a4001170) at ./../../../libraries/liblmdb/mdb.c:2907 #3 0x00000000005792f4 in mdb_opinfo_get (op=Search request = {...}, mdb=0x7f91b543b010, rdonly=0, moip=0xe7b348) at id2entry.c:740 #4 0x000000000057989d in mdb_txn (op=Search request = {...}, txnop=1, ptr=0xe7b348) at id2entry.c:812 #5 0x00000000004ee059 in syncrepl_entry (si=0xe7b0f0, op=Search request = {...}, entry="dc=example,dc=com", modlist=0x7f91b32ba1a8, syncstate=1, syncUUID=0x7f91b32ba140, syncCSN=0x0) at syncrepl.c:3087 #6 0x00000000004e8cac in do_syncrep2 (op=Search request = {...}, si=0xe7b0f0) at syncrepl.c:1056 #7 0x00000000004e2556 in do_syncrepl (ctx=0x7f91b32bab78, arg=0xe7b6d0) at syncrepl.c:1604 Thread 2 (Thread 0x7f91b3abc700 (LWP 8021)): #0 0x00007f91b5d0b207 in epoll_wait (epfd=6, events=0xdebc50, maxevents=1024, timeout=7000) at ../sysdeps/unix/sysv/linux/epoll_wait.c:30 #1 0x000000000044591a in slapd_daemon_task (ptr=0x1232700) at daemon.c:2745 Thread 1 (Thread 0x7f91b5761780 (LWP 8006)): #1 0x00007f91b815f11d in ldap_pvt_thread_join (thread=140263761364736, thread_return=0x0) at thr_posix.c:208 #2 0x0000000000443a1b in slapd_daemon () at daemon.c:3157 #3 0x000000000041ec5b in main (argc=8, argv=0x7ffcee967dc8) at main.c:1018 -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8930) Setting source interface of LDAP session the ldap client uses to connect to server
by ryan＠nardis.ca 29 Oct '18

29 Oct '18

Hello Adrian, I think someone is already working on this feature, please see: ITS#8847 https://openldap.org/its?findid=8847 ITS#8654 https://openldap.org/its?findid=8654 http://www.openldap.org/lists/openldap-devel/201810/msg00008.html

1 0

(ITS#8930) Setting source interface of LDAP session the ldap client uses to connect to server
by ac1471＠att.com 29 Oct '18

29 Oct '18

Full_Name: adrian cepleanu Version: 0.5.3 OS: Ubuntu 16.04LTS URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (144.160.130.91) In a system with multiple interfaces software initiating network connections may choose the source interface (or IP address) that the request is initiated from. I am looking for such a setting in the ldap-auth-client for Linux but cannot find it. Perhaps it doesn't exist. If the latter please advise if there is a way to submit a feature request. thanks

1 0

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message
by michael＠stroeder.com 26 Oct '18

26 Oct '18

On 10/26/18 4:21 PM, Ondřej Kuzník wrote: > Yes, but `key` had already been freed a few lines earlier and using > o_tmpalloc reliably exposes the issue where ch_malloc just masks it. Ouch! > This is now fixed in master. Thanks. Everything now works like a charm also with RE24. Ciao, Michael.

1 0

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message
by ondra＠mistotebe.net 26 Oct '18

26 Oct '18

On Fri, Oct 26, 2018 at 08:12:13AM +0000, michael(a)stroeder.com wrote: > On 10/26/18 4:01 AM, Quanah Gibson-Mount wrote: >> This patch has been applied to OpenLDAP HEAD with a correction to the >> memory allocation functions. I'll discuss with Howard about whether or >> not to add it to 2.4.47. > > With your memory allocation correction, op->o_tmpalloc() and > op->o_tmpfree(), this does not work as expected with 2.4.x. It does > *not* return the filter used for uniqueness check. > (I did not test master yet.) > > [...] > Result with patch backported from git master using op->o_tmpalloc() and > op->o_tmpfree(): > > non-unique attributes found with non-unique attribute > ^^^^^^^^^^^^^^^^^^^^ > Seems to repeat parts of the buffer? > > In my original patch the use of ch_malloc() and ch_free() was simply > copied from other overlay code. There are many occurences of ch_malloc() > and ch_free() throughout the whole code. Yes, but `key` had already been freed a few lines earlier and using o_tmpalloc reliably exposes the issue where ch_malloc just masks it. This is now fixed in master. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message
by michael＠stroeder.com 26 Oct '18

26 Oct '18

On 10/26/18 4:01 AM, Quanah Gibson-Mount wrote: > --On Monday, July 30, 2018 6:58 PM +0000 michael(a)stroeder.com wrote: > >> Can someone correct the subject line of the ticket? >> >> Should of course mention slapo-unique instead of slapo-constraint. > > This patch has been applied to OpenLDAP HEAD with a correction to the > memory allocation functions. I'll discuss with Howard about whether or > not to add it to 2.4.47. With your memory allocation correction, op->o_tmpalloc() and op->o_tmpfree(), this does not work as expected with 2.4.x. It does *not* return the filter used for uniqueness check. (I did not test master yet.) Example for expected diagnostic message (with my original patch applied to 2.4.46): non-unique attributes found with (|(gidNumber=30041)) Result with patch backported from git master using op->o_tmpalloc() and op->o_tmpfree(): non-unique attributes found with non-unique attribute ^^^^^^^^^^^^^^^^^^^^ Seems to repeat parts of the buffer? In my original patch the use of ch_malloc() and ch_free() was simply copied from other overlay code. There are many occurences of ch_malloc() and ch_free() throughout the whole code. Does op->o_tmpalloc() and op->o_tmpfree() work correctly in RE24 branch? Ciao, Michael.

1 0

Re: (ITS#8925) Please remove the entry for mirror.switch.ch from the Download page
by quanah＠symas.com 26 Oct '18

26 Oct '18

--On Thursday, October 18, 2018 10:23 PM -0400 Thomas Lenggenhager <thomas.lenggenhager(a)switch.ch> wrote: > Hello Quanah > > Many thanks for your action and answer. In the mean time I noticed that > in this file > ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS > the mirrors are still listed. Could you please update that as well? Thanks, This is now fixed as well. :) 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

Re: (ITS#8866) RFE: slapo-unique to return filter used in diagnostic message
by quanah＠symas.com 26 Oct '18

26 Oct '18

--On Monday, July 30, 2018 6:58 PM +0000 michael(a)stroeder.com wrote: > Can someone correct the subject line of the ticket? > > Should of course mention slapo-unique instead of slapo-constraint. This patch has been applied to OpenLDAP HEAD with a correction to the memory allocation functions. I'll discuss with Howard about whether or not to add it to 2.4.47. --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#8928) Reproducibility: Remove user, hostname, pwd from version string
by douglas.royds＠taitradio.com 26 Oct '18

26 Oct '18

URL: ftp://ftp.openldap.org/incoming/douglas-royds-181026.patch This updated patch also sets the date and time strings to the SOURCE_DATE_EPOCH. The WHOWHERE string will now be set to simply "openldap" in the case that a SOURCE_DATE_EPOCH is set. Tait Communications Ltd 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.

1 0

Re: (ITS#8929) syncrepl retry parameter ignored
by openldap-its＠plumbe.de 25 Oct '18

25 Oct '18

Am 2018-10-24 15:57, schrieb Quanah Gibson-Mount: > --On Wednesday, October 24, 2018 10:21 AM +0000 openldap-its(a)plumbe.de > wrote: > >> Full_Name: Markus Joosten >> Version: 2.4.44-15.el7 >> OS: CentOS 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (62.8.242.42) >> >> >> Hello, >> >> I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config >> backend. >> My main database dc=example,dc=com is replicated using syncrepl, >> however >> the retry parameter is completely ignored. > > Provide your full configuration minus passwords, as syncrepl is used > extensively in the test suite and does not exhibit this behavior. > > --Quanah > I found my error. Turns out I had a runaway double-quote on the type= parameter like this: type=refreshAndPersist" Funny enough, the only message in my log was regarding the missing retry parameter. The replication itself was created successfully and was also working as expected, only the retry parameter was missing. Regards, Markus

1 0

Re: (ITS#8929) syncrepl retry parameter ignored
by quanah＠symas.com 24 Oct '18

24 Oct '18

--On Wednesday, October 24, 2018 10:21 AM +0000 openldap-its(a)plumbe.de wrote: > Full_Name: Markus Joosten > Version: 2.4.44-15.el7 > OS: CentOS 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (62.8.242.42) > > > Hello, > > I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config backend. > My main database dc=example,dc=com is replicated using syncrepl, however > the retry parameter is completely ignored. Provide your full configuration minus passwords, as syncrepl is used extensively in the test suite and does not exhibit this behavior. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8929) syncrepl retry parameter ignored
by openldap-its＠plumbe.de 24 Oct '18

24 Oct '18

Full_Name: Markus Joosten Version: 2.4.44-15.el7 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (62.8.242.42) Hello, I'm running 2 OpenLDAP servers on CentOS 7 using the cn=config backend. My main database dc=example,dc=com is replicated using syncrepl, however the retry parameter is completely ignored. I'm seeing the following log message every time I recreate the replication: syncrepl rid=001 searchbase="dc=example,dc=com": no retry defined, using default Steps to reproduce: - setup two OpenLDAP servers - create replication with the retry parameter specified - retry parameter will be ignored Regards, Markus

1 0

Re: (ITS#8322) mdb_env_set_mapsize default size mismatch
by myk＠mykzilla.org 19 Oct '18

19 Oct '18

This is a multi-part message in MIME format. --------------D22E8F79C8A3AF5F4EEDBDD5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Here's a patch (in git-format-patch format, per the Guidelines for Contributing) that changes the code comment on mdb_env_set_mapsize to be consistent with the value of DEFAULT_MAPSIZE. https://github.com/LMDB/lmdb/compare/mdb.master...mykmelez:default-mapsize.… (I haven't provided a Notice of Origin nor Rights Statement, as, per the Guidelines for Contributing, this patch doesn't represent "significant blocks of new code (10 lines or greater)." It's a one-line change.) -myk --------------D22E8F79C8A3AF5F4EEDBDD5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit <html><head> <meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body text="#000000" bgcolor="#FFFFFF"> Here's a patch (in git-format-patch format, per the Guidelines for Contributing) that changes the code comment on mdb_env_set_mapsize to be consistent with the value of DEFAULT_MAPSIZE. <a class="moz-txt-link-freetext" href="https://github.com/LMDB/lmdb/compare/mdb.master...mykmelez:default-mapsize.…">https://github.com/LMDB/lmdb/compare/mdb.master...mykmelez:default-mapsize.…</a> (I haven't provided a Notice of Origin nor Rights Statement, as, per the Guidelines for Contributing, this patch doesn't represent "significant blocks of new code (10 lines or greater)." It's a one-line change.) -myk </body> </html> --------------D22E8F79C8A3AF5F4EEDBDD5--

1 0

Re: (ITS#8925) Please remove the entry for mirror.switch.ch from the Download page
by thomas.lenggenhager＠switch.ch 19 Oct '18

19 Oct '18

Hello Quanah Many thanks for your action and answer. In the mean time I noticed that in this file ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS the mirrors are still listed. Could you please update that as well? Kind regards Thomas > Hi Thomas, > > --On Thursday, October 11, 2018 12:08 PM +0000 switchmirror(a)switch.ch wrote: > >> I already sent twice a message to info(a)openldap.org, but no action or >> answer received. > > The ITS system is the correct spot for this request. ;) > >> So I try it on this channel. >> >> Please drop the reference to SWITCH (Switzerland, mirror.switch.ch) on the >> Download web page: >> http://www.openldap.org/software/download/ > > Done. > >> BTW: I noticed that the Austrian mirror on gd.tuwien.ac.at has completely >> disappeared, there is no DNS entry for it anymore. > > Thanks, I removed that one as well. > > Warm regards, > Quanah -- SWITCH Thomas Lenggenhager, Trust & Identity Werdstrasse 2, P.O. Box, 8021 Zurich, SWITZERLAND phone +41 44 268 1505 direct +41 44 268 1541 https://www.switch.ch

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs