Re: SASL Binds and meaning of "users"
--On Tuesday, April 18, 2023 4:43 PM +0200 Ondřej Kuzník wrote: Recently seen a few people assume that authz-regexp search-based mappings enforce that an entry is found or the Bind is failed, which is not the case. Obviously the admin guide[0] should be adjusted not to cause more confusion but the question remains: Should we be able to decide whether an identity should be considered a "user" (Bind succeeds)? I'm generally of the opinion that using "by users X" other than "by users none" is a very bad idea and should be avoided, largely for the issues above. A user is anything that had some sort of success in a BIND operation, whether or not (particularly when dealing with SASL mechanisms) it actually mapped to something in the database. It's only a small step above "by anonymous X". There are valid reasons to allow a SASL bind that doesn't actually map to something in the DB. --Quanah
Re: pcache LDAP_MATCHING_RULE_IN_CHAIN support
--On Saturday, February 18, 2023 10:08 AM +0100 Johan wrote: Le vendredi 10 février 2023, 11:38:02 CET Howard Chu a écrit : > P.S.: Is there a reason mr_passthru is not included to OpenLDAP ? not > even in contrib ? Since no one has contributed it upstream, I have no idea what you're talking about. Ask whoever wrote whatever it is. https://github.com/cbueche/openldap-passthru I found this thread which seem to be the genesis : https://openldap.org/lists/ openldap-technical/201406/msg4.html The OP made an attempt to see it included here https://www.openldap.org/lists/ openldap-technical/201411/msg00123.html, so I would like to renew this call for inclusion upstream. Thank you for your help, which made me realize I need to read more for the pcache patch! Please file a bug in the ITS system so this can be tracked, thanks! (https://bugs.openldap.org) Regards, Quanah
Re: Patch for SSL ctx
--On Saturday, May 21, 2022 1:56 PM +0200 Michael Ströder wrote: HI! Could someone please review whether this patch makes sense? https://build.opensuse.org/package/view_file/home:firstyear:branches:netw ork:ldap/openldap2/0017-Resolve-error-handling-in-new-ctx-when-global.pat ch?expand=1 Other question would be why things like this aren't being submitted back to the project, he has an account with the OpenLDAP gitlab. --Quanah
Re: Fwd: 2.5 deprecated backends
--On Tuesday, August 17, 2021 5:07 PM +0300 Aapo Romu wrote: Hello, Howard I'm sorry that it took so long to respond but we needed to figure out how we will arrange this. So we are going to take a look at the back-sql tickets together with Eetu next Friday and start working from there. At some point (probably at the start of September) a third person will join us in the effort and I will gradually move away from the back-sql stuff. Best regards Aapo Romu Hi Aapo, Do you have any update on this? Unless someone actively steps up to maintain the back-sql backend we're leaning towards removing it, most likely in 2.7. The reported issues with it continue to expand and no one else has expressed any interest in maintaining it. Regards, Quanah
2.6 branch created
The OpenLDAP 2.6 release branch has been created. master is now open for 2.7 development. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Release Maintenance Policy
--On Sunday, August 8, 2021 12:41 PM +0100 Howard Chu wrote: All this nitpicking over *process* is wasting time. It's not nitpicking, it's trying to establish something well written and concise. Clearly all that you feel is relevant is what matters. As an aside, here's an example of a well written release policy that clearly explains not just what the support windows are, but also what alpha, beta, etc, mean. <https://www.openssl.org/policies/releasestrat.html> --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.5 deprecated backends
--On Sunday, August 8, 2021 6:32 PM +0100 Howard Chu wrote: Quanah Gibson-Mount wrote: For 2.5, we deprecated: back-ndb back-sql back-perl Should these be removed for 2.6? I still routinely build back-perl in master. Is there any reason to remove it? Not necessarily, that's why I started the discussion. back-bdb was deprecated with 2.3, but was around for all of 2.4 as well. I see no reason to keep back-ndb around. back-sql has numerous open issues, but I've no real insight into whether it retains any usefulness. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Release Maintenance Policy
--On Sunday, August 8, 2021 3:21 AM +0100 Howard Chu wrote: Quanah Gibson-Mount wrote: --On Saturday, August 7, 2021 1:31 PM +0100 Howard Chu wrote: Also for clarity: We consider "Critical" bugs to include security flaws resulting in unauthorized data disclosure, or unauthorized remote code execution. We do not consider assert() failures or crashes resulting only in Denial of Service as security flaws. That's fine as a general statement, but what we need is an explicit *documented* policy. Likely under "Release Documents" here: <https://www.openldap.org/software/> Sounds like you should open a ticket against the website then. Once we have a clear, concise well formed policy I'll do that. That's backwards. The ticket has to exist before anyone writes a patch/MR for it. As a project, we need to decide on a policy. Once we decide on what that policy is, we can document it. IMHO this list is the best place to have that discussion. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Release Maintenance Policy
--On Saturday, August 7, 2021 1:31 PM +0100 Howard Chu wrote: Also for clarity: We consider "Critical" bugs to include security flaws resulting in unauthorized data disclosure, or unauthorized remote code execution. We do not consider assert() failures or crashes resulting only in Denial of Service as security flaws. That's fine as a general statement, but what we need is an explicit *documented* policy. Likely under "Release Documents" here: <https://www.openldap.org/software/> Sounds like you should open a ticket against the website then. Once we have a clear, concise well formed policy I'll do that. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
ITS#9611
It appears there is an accidental backwards incompatibility with 2.4 where slapd doesn't honor alias names with structural objectClasses. This would be good to fix for 2.5.7 so that it doesn't impact people upgrading from 2.4. It could also cause issues with slapcat of a 2.4 config database with 2.5 slapcat unnecessarily. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Release Maintenance Policy
--On Friday, August 6, 2021 3:11 PM +0100 Howard Chu wrote: Planning to post this to -announce soon, any comments? Just a reminder to everyone: the Project has a long-standing policy of doing active development on only one release version at a time. To allow time for migrations we provide some overlap from one release version to the next. E.g., while 2.5 is active we will still provide critical bugfixes for 2.4. Since 2.4 has been around for something like 14 years now people may have forgotten this policy. This is a heads up that with 2.6 due for release in September, all updates to 2.4 will cease at that time. Likewise, when 2.7 is released next year all updates to 2.5 will cease. Also for clarity: We consider "Critical" bugs to include security flaws resulting in unauthorized data disclosure, or unauthorized remote code execution. We do not consider assert() failures or crashes resulting only in Denial of Service as security flaws. That's fine as a general statement, but what we need is an explicit *documented* policy. Likely under "Release Documents" here: <https://www.openldap.org/software/> Also, I'd like to see explicit terms here. I.e., 2.4 is now in maintenance, which means only critical fixes are applied. 2.5 is active, which means it has an active release schedule and is open for general bug fixes. 2.6 is in development which means that is where all new feature development and distruptive changes are occurring. As a part of that explicit policy and terminology, we need to provide some sort of time table on when a release moves from active to maintenance. Clearly it would not have been fair to move 2.4 to maintenance the moment 2.5 released (for example we've done one non-security based release of 2.4 since 2.5 came out). At this point, I think it's fair for 2.4 to be in maintenance and 2.5 to be the sole active release, however it would generally be unfair to mark 2.5 maintenance the moment 2.6 releases. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
2.5 deprecated backends
For 2.5, we deprecated: back-ndb back-sql back-perl Should these be removed for 2.6? Additionally, I think we should be deleting retired backends out of master. Git is designed for this type of thing, there's no need for them to persist (For example, back-shell). It makes branching new releases a major headache. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: About REP_TEXT_MUSTBEFREED (ITS#6138)
--On Friday, July 30, 2021 6:54 PM +0200 Hallvard Breien Furuseth wrote: Logged in, but my uio.no-address rather than as hallvard@openldap. Could write a comment, but not click to make something happen with it. Err. Might have been an idea to read the gitlab doc first, instead of trying to act like on github. Nevermind. Ok. I would note that your @openldap.org address is already tied to your uio.no address, so it's all the same account. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: About REP_TEXT_MUSTBEFREED (ITS#6138)
--On Friday, July 30, 2021 6:28 PM +0200 Hallvard Breien Furuseth wrote: (I tried to add a comment in Github, but that didn't seem to work, so mailing here instead.) We don't use github. I assume you mean the gitlab instance? What error did you get? Were you logged in? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New OpenLDAP TLS backend? (wolfSSL)
--On Thursday, February 25, 2021 1:53 PM -0600 Hayden Roche wrote: Quanah and Howard, Thanks for your quick replies! I'm glad to hear there's interest in this. I think 2.6 is a more realistic target, as I'll need to get my boss to allocate time for this work amongst other wolfSSL tasks I've been assigned. Look forward to a merge request in the (hopefully near) future! The openldap mainline code branch is now open for 2.6 development, so this would be a good time for work to start on this item for inclusion. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
OpenLDAP 2.5 Release Candidate Testing (OpenLDAP 2.5.4)
This is a testing call for OpenLDAP 2.5 Release Candidate (OpenLDAP 2.5.4) Depending on the results, this may be the only testing call. Generally, get the code for RE25: <https://git.openldap.org/openldap/openldap/-/archive/OPENLDAP_REL_ENG_2_5/openldap-OPENLDAP_REL_ENG_2_5.tar.gz> Extract, configure, and build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Note that there are new features in 2.5, so please examine the options available with configure carefully. Some examples: The new load balancer, which can either be built as a module for slapd (--enable-balancer=mod) or as a standalone server (--enable-balancer=yes) The libargon2 password module (--enable-argon2). Systemd notification support (--with-systemd=yes). Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New OpenLDAP TLS backend? (wolfSSL)
--On Thursday, February 25, 2021 12:38 PM -0600 Hayden Roche wrote: (thanks JoBbZ). I was also pointed to this issue in your issue tracking system, where a developer (Quanah Gibson-Mount) Same person. ;) Is there still interest in getting wolfSSL working with OpenLDAP's latest version and integrated upstream? OpenLDAP 2.4 is closed to development. If you want this in for OpenLDAP 2.5, you'll need to get the work in ASAP, otherwise it will have to wait for 2.6 Generally: Sign up for an account on our gitlab instance: https://git.openldap.org Fork a copy of the openldap repo. Create a branch for ITS9303 and do the work in that branch Push the branch Open a merge request for review Additionally, you'll need to add an IPR statement to ITS#9303 as documented at <https://www.openldap.org/devel/contributing.html#notice> A link to the MR should also be put into the ITS. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: HAProxy proxy protocol support
--On Saturday, December 5, 2020 2:40 PM -0800 Quanah Gibson-Mount wrote: I'd like to backport this to OPENLDAP_REL_ENG_2_4 if/when it's accepted, hopefully that will be ok. Also looks like I need to make further edits to the devel page on submissions, since this info is at the very bottom, and outdated info preceeds it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: HAProxy proxy protocol support
--On Friday, December 4, 2020 5:08 PM -0800 "Paul B. Henson" wrote: I've attached my first pass at adding proxy protocol support to slapd. I haven't updated any documentation/man pages yet, I'll start taking a look at that while you all eviscerate my code and let me know what needs to be fixed before merging :). I'd like to backport this to OPENLDAP_REL_ENG_2_4 if/when it's accepted, hopefully that will be ok. You should: a) sign up for an account in gitlab if you haven't already: https://git.openldap.org b) fork the master OpenLDAP repo c) Create a development branch in your fork, generally named after the ITS. I.e.: git clone -b its# master d) Apply your patch e) Submit a merge request for review. You can mark it WIP if you feel like it may need additional work and is not yet ready for integration. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: slapo-constraint negated regex
--On Saturday, November 7, 2020 6:40 PM + David Barchiesi wrote: Hello, After reading the slapo-constraint man page and searching online for a possible solution it is clear that the overlay doesn't conveniently allow setting a constraint with a negated regex. The root cause is that negative lookahead isn't supported by extended POSIX regex. One could argue that the complement of a regular language is itself regular again and therefore it is certainly possible to write a regex that doesn't allow certain values, however any regex of this sort quickly becomes complex [1][2][3]. Taking grep as an example (i.e. --invert-match), I propose adding a constraint type that allows using a regex in a negated way. When a match is found a constraint error is raised. Looking at the constraint overlay code it seems pretty trivial and I am willing to submit myself a patch that allows setting something like: constraint_attribute mail negregex ^.*@somedomain\.com$ I already have an initial implementation and first tests seem to work as intended. Would such a patch be accepted? If so, could anyone guide me with getting the patch merged? Hi David, The project would be happy to accept such a contribution. The contribution process is generally documented at <https://www.openldap.org/devel/contributing.html> but: a) File an ITS for this new functionality if one does not already exist at <https://bugs.openldap.org> b) Create an account at https://git.openldap.org and fork the OpenLDAP repository c) Create a working branch off of master (i.e., git checkout -b its) d) Commit your work and git push e) Submit an MR f) Ensure you add a rights statement as documented in the contrib web page to the ITS so we have a history of it. Thanks! Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: CI/CD on git.openldap.org
--On Friday, October 30, 2020 9:32 AM -0700 Quanah Gibson-Mount wrote: Hi Norbert, I've disabled CI/CD for the repo. Or, to be clear, for the main JLDAP repo. You'll likely need to disable it for your own fork. Gitlab defaults to automatically enabling CI/CD and will run jobs even if no configuration is found. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: CI/CD on git.openldap.org
--On Friday, October 30, 2020 10:17 AM +0100 Norbert Klasen wrote: Hi, when I pushed a new branch to my fork of the JLDAP repo, this triggered the Auto DevOps CI/CD pipeline. Is that supposed to work on git.openldap.org? From the error messages it seems to me, that it cannot resolve the host "docker": error during connect: Post http://docker:2375/v1.40/auth: dial tcp: lookup docker on 173.255.199.5:53: no such host error during connect: Post http://docker:2375/v1.40/images/create?fromImage=registry.gitlab.com%2Fgi tlab-org%2Fci-cd%2Fcodequality=0.85.10-gitlab.1: dial tcp: lookup docker on 173.255.199.5:53: no such host Hi Norbert, I've disabled CI/CD for the repo. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Moving OpenLDAP 2.5 towards release
With the 2.5.0 alpha release, these links are now as follows: --On Thursday, October 1, 2020 5:37 PM -0700 Quanah Gibson-Mount wrote: A list of issues currently marked as 2.5 (mostly minus doc bugs) can be seen here: <https://bugs.openldap.org/buglist.cgi?component=backends=build =client%20tools=contrib=historical t=libraries=overlays=slapd_id=834=OpenLD AP_format=advanced=---_milestone=2.5.0> <https://bugs.openldap.org/buglist.cgi?component=backends=build=client%20tools=contrib=historical=libraries=overlays=slapd_id=854=OpenLDAP_format=advanced=---_milestone=2.5.1> *) There are about 40 explicit documentation bugs, as found here: <https://bugs.openldap.org/buglist.cgi?component=documentation_id=83 7=OpenLDAP_format=advanced=---_milestone= 2.5.0> <https://bugs.openldap.org/buglist.cgi?component=documentation_id=856=OpenLDAP_format=advanced=---_milestone=2.5.1> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Moving OpenLDAP 2.5 towards release
There's been great and steady progress on getting closer to an official 2.5 release. At this time, I feel that 2.5 is ready for its first alpha. While there are some hard blockers to an official release that still need to be finished, there is plenty of items that are in the 2.5 tree that it would be good to get additional testing on now. One thing that differentiates 2.5 from the time when 2.4 was released is that a substantial portion of the new code has already been being used in the Symas OpenLDAP Gold series which means it has already had extensive testing and production deployment. For those interested in helping getting 2.5 an official release timeframe, the following things would be helpful: *) I've been using Bugzilla's Target milestone to indicate items I'd like to see addressed for 2.5. This does not necessarily mean they will be fixed for 2.5. Many of the items are several years old, and simply need a confirmation as to whether they are still issues or were already fixed. It also may make more sense to push some of these items out to 2.6. I've done that for a number of issues already, so what remains are the ones where I felt I was not able to make that call. Anything I've added the keyword OL_2_5_REQUIRED to is something I think must be done for 2.5, but that's subject to review. A list of issues currently marked as 2.5 (mostly minus doc bugs) can be seen here: <https://bugs.openldap.org/buglist.cgi?component=backends=build=client%20tools=contrib=historical=libraries=overlays=slapd_id=834=OpenLDAP_format=advanced=---_milestone=2.5.0> *) There are about 40 explicit documentation bugs, as found here: <https://bugs.openldap.org/buglist.cgi?component=documentation_id=837=OpenLDAP_format=advanced=---_milestone=2.5.0> It would be great if community members who are familiar with the product could help chip in here, particularly with flushing out the Admin guide. For the man pages, we do have one item that really needs a policy decision that I can't make (ITS#7335), which is how we handle documenting options for slapd.conf vs cn=config. Right now, we are completely inconsistent in this and many relevant man pages are entirely missing anything about how to configure via cn=config. Once that policy is decided, it will unblock a lot of other work. *) Testing -- We need a lot of this. It would be especially helpful if people who have QA/Test/Pre-prod environments were to run 2.5 through known work loads. To this end, Symas is planning on providing pre-compiled binaries for a number of platforms once there is an official alpha release. I still have a bit of work to do on that end, however, so it would not necessarily coincide with the source release. This may be something the LTB project could also participate in as a way to help testing of the 2.5 series. To the above, it may be useful to go over the list of items that are new and changed with 2.5: <https://bugs.openldap.org/buglist.cgi?bug_status=RESOLVED_status=VERIFIED_id=840_format=advanced=FIXED=PARTIAL=TEST_milestone=2.5.0> One area where it would be especially helpful for testing for the *BSD folks out there is the support added for kqueue. I'm hoping the FreeBSD project and similar will be able to participate in this. Another area would be OpenSSL 3.0 testing, since it is nearing completion. It would be helpful if people could build and test the 2.5 branch against their current beta and see if they hit any new/odd issues and open issues on that accordingly if encountered. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: OpenLDAP 2.4.51 available, LMDB 0.9.26 available
--On Wednesday, August 12, 2020 12:31 PM +0200 Clément OUDOT wrote: Hello, changelog seems not well updated on the website: https://www.openldap.org/software/release/changes.html Fixed. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: RE25 make depend
re with --enable-wt to make back_wt make[3]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/servers/slapd/back-wt' cd slapi && make -w depend make[3]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/servers/slapd/slapi' ../../../build/mkdep -l -d "." -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../include -I./.. -I. plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c make[3]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/servers/slapd/slapi' cd overlays && make -w depend make[3]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/servers/slapd/overlays' ../../../build/mkdep -l -d "." -c "cc" -m "-M" -I../../../include -I../../../include -I.. -I./.. overlays.c accesslog.c auditlog.c autoca.c constraint.c dds.c deref.c dyngroup.c dynlist.c memberof.c pcache.c collect.c ppolicy.c refint.c retcode.c rwm.c rwmconf.c rwmdn.c rwmmap.c seqmod.c sssvlv.c syncprov.c translucent.c unique.c valsort.c make[3]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/servers/slapd/overlays' ../../build/mkdep -d "." -c "cc" -m "-M" -I../../include -I. -I./slapi -I. -I../../include main.c globals.c bconfig.c config.c daemon.c connection.c search.c filter.c add.c cr.c attr.c entry.c backend.c result.c operation.c dn.c compare.c modify.c delete.c modrdn.c ch_malloc.c value.c ava.c bind.c unbind.c abandon.c filterentry.c phonetic.c acl.c str2filter.c aclparse.c init.c user.c lock.c controls.c extended.c passwd.c schema.c schema_check.c schema_init.c schema_prep.c schemaparse.c ad.c at.c mr.c syntax.c oc.c saslauthz.c oidm.c starttls.c index.c sets.c referral.c root_dse.c sasl.c module.c mra.c mods.c sl_malloc.c zn_malloc.c limits.c operational.c matchedValues.c cancel.c syncrepl.c backglue.c backover.c ctxcsn.c ldapsync.c frontend.c slapadd.c slapcat.c slapcommon.c slapdn.c slapindex.c slappasswd.c slaptest.c slapauth.c slapacl.c component.c aci.c txn.c slapschema.c slapmodify.c make[2]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/servers/slapd' make[1]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/servers' Entering subdirectory tests make[1]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/tests' Making depend in /home/build/git/openldap-OPENLDAP_REL_ENG_2_5/tests Entering subdirectory progs make[2]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/tests/progs' ../../build/mkdep -d "." -c "cc" -m "-M" -I../../include -I../../include slapd-common.c slapd-tester.c slapd-search.c slapd-read.c slapd-addel.c slapd-modrdn.c slapd-modify.c slapd-bind.c slapd-mtread.c ldif-filter.c make[2]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/tests/progs' make[1]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/tests' Entering subdirectory doc make[1]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc' Making depend in /home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc Entering subdirectory man make[2]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man' Making depend in /home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man Entering subdirectory man1 make[3]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man1' make[3]: Nothing to be done for 'depend'. make[3]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man1' Entering subdirectory man3 make[3]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man3' make[3]: Nothing to be done for 'depend'. make[3]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man3' Entering subdirectory man5 make[3]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man5' make[3]: Nothing to be done for 'depend'. make[3]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man5' Entering subdirectory man8 make[3]: Entering directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man8' make[3]: Nothing to be done for 'depend'. make[3]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man/man8' make[2]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc/man' make[1]: Leaving directory '/home/build/git/openldap-OPENLDAP_REL_ENG_2_5/doc' --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: bugzilla spam?
--On Sunday, July 26, 2020 5:34 PM +0200 Michael Ströder wrote: HI! To this seems to be spam: https://bugs.openldap.org/show_bug.cgi?id=6036#c5 Maybe also block the user fieldenginee...@yahoo.com? I've locked the account. Guessing this is going to be a lot like what is happening with gitlab, where people are getting paid to open accounts and spam systems with messages. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: RE25 make depend
--On Saturday, July 25, 2020 2:27 PM +0200 Michael Ströder wrote: HI! With RE25 branch make depend fails on my system (see below). Find attached my build script which works just fine for RE24. Any changes needed for RE25? <https://bugs.openldap.org/show_bug.cgi?id=9236> Apparently your build script is referencing non-existent backends. cd back-shell && make -w depend -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
ppolicy control exposure in RE24?
Currently the ppolicy overlay does not expose the related control in the supportedControl attribute of the rootDSE. This is due to the general policy that controls for items that are not part of a finalized specification are not published. However, at this point, ppolicy while not finalized, is long established. For 2.5, we will be exposing the control, but I think it could be useful to do this for 2.4.51+ as well. Does anyone have any objections to this change being backported to RE24? <https://bugs.openldap.org/show_bug.cgi?id=9285> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
terminology cleanup
I've done a pass for RE24 at cleaning up terminology around replication which should make things a lot less confusing, as we were using various terms interchangably w/o much explanation. I've put this up for review at <https://git.openldap.org/openldap/openldap/-/merge_requests/82> It'd be great to have a few people look over it as it touches a lot of stuff. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: contrib modules to promote to mainline for 2.5?
--On Wednesday, April 22, 2020 1:04 PM -0700 Philip Guenther wrote: Is there a ticket tracking this where the open question(s) for which a response is needed can be seen? The obvious search of https://bugs.openldap.org/buglist.cgi?quicksearch=bcrypt There wouldn't be, as it requires the author to contribute it as noted in: <https://github.com/wclarie/openldap-bcrypt/issues/1> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: contrib modules to promote to mainline for 2.5?
--On Wednesday, April 22, 2020 8:01 PM +0100 Howard Chu wrote: Michael Ströder wrote: On 4/22/20 6:15 PM, Quanah Gibson-Mount wrote: Are there any contrib modules that we should consider promoting to mainline for the 2.5 series? I.e., sha2, argon2 seem like potential options. +1 for pw-sha2 and pw-argon2. sha2 is already obsolete, for password purposes. I see no reason to promote it. Ok. I would note that the argon2 module adds a dependency on a 3rd party library, so we'd need to add detection for it? That's one reason to keep pw-sha2. It's still better than the default SSHA. Or perhaps to get bcrypt added, if we can ever get a proper response from the author. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
contrib modules to promote to mainline for 2.5?
Are there any contrib modules that we should consider promoting to mainline for the 2.5 series? I.e., sha2, argon2 seem like potential options. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.4 commit review
--On Thursday, April 2, 2020 9:09 PM +0100 Howard Chu wrote: Quanah Gibson-Mount wrote: I think the following ITSes would be good to add for 2.4.50. Any objections? ITS#7074 - Fix olcDatabaseDummy init for windows ITS#9003 - Fix slapd-ldap(5) man page to note idassert-authzfrom policy difference ITS#9181 - Fix race on Windows mutex init ITS#9182 - pcache: fix private DB init Sounds fine, they're simple enough. Did you also pull in the utf8bvnormalize leak patch? I have it queued up for approval in merge request 20, if you want to sign off on it. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
2.4 commit review
I think the following ITSes would be good to add for 2.4.50. Any objections? ITS#7074 - Fix olcDatabaseDummy init for windows ITS#9003 - Fix slapd-ldap(5) man page to note idassert-authzfrom policy difference ITS#9181 - Fix race on Windows mutex init ITS#9182 - pcache: fix private DB init Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back-ndb: retire for 2.5?
--On Tuesday, March 24, 2020 12:55 PM -0700 Quanah Gibson-Mount wrote: On reconsideration, I don't like the churn that "master-only" causes in our autoconf/makefile stuff. Just leave it in the release and default it to disabled. It already defaults to disabled, but it gets picked up when people do things like --enable-backends=mod. How about we remove it from the list of backends in configure.in (thus --enable-backends won't pick it up). Thus someone would have to explicitly do --enable-ndb=XXX to enable it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back-ndb: retire for 2.5?
--On Tuesday, March 24, 2020 7:45 PM + Howard Chu wrote: Ryan Tandy wrote: I'd go further and propose simply deleting back-ndb. Do we know of anyone using it? Unlikely, unless for very very simple use cases. On reconsideration, I don't like the churn that "master-only" causes in our autoconf/makefile stuff. Just leave it in the release and default it to disabled. It already defaults to disabled, but it gets picked up when people do things like --enable-backends=mod. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back-ndb: retire for 2.5?
--On Monday, March 23, 2020 6:03 PM -0700 Ryan Tandy wrote: I'd go further and propose simply deleting back-ndb. Do we know of anyone using it? It's not usable, so no. ;) There's one ITS around it from someone who made the mistake of attempting to use it. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
back-ndb: retire for 2.5?
The back-ndb backend has never been finished, and relies on partnership with a corporation that has no desire to continue the work since it acquired the original entity involved. I would suggest then that it be removed from the 2.5 release tree and left master only. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
back-sql: retire for 2.5?
One thing that came up repeatedly in going through the ITS system is issues with back-sql (A quick count gives me 23). Given that this backend has always been marked experimental and has numerous bugs, I would suggest that unless someone steps up who is willing to support it that it be removed from the 2.5 release series (i.e., make it master only until someone is willing to maintain it). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
CVS... should it stay or should it go now?
One of the things we did not migrate over from Gauss was the old CVS repository. However, there are references in the old -software archives (and possibly -technical as well), and existing bug reports, such as <https://bugs.openldap.org/show_bug.cgi?id=831#c6> which have links that will no longer work without the old CVS repository being present, although all of these changes of course do exist in the git repo, just with git change IDs. Is there anyone who feels it is worthwhile to preserve the old CVS repository so that these references can still be examined directly w/o having to parse through the git history to find them? If so, we can certainly restore the CVS repo on the new system. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
archiving test
just an archiving test, ignore :P -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New logging system ideas
--On Thursday, March 12, 2020 12:35 AM + Howard Chu wrote: Not only does stdout allow you to use native tools such as `journalctl` or `kubectl` out of the box, log aggregation is a completely solved problem in this workflow and is trivial to implement. That being said, persisting logs to disk in a binary format has its merits. Personally, I don't think plain text logs scale all that well. Plaintext logs scale horribly. When you have servers processing hundreds of thousands to millions of queries/sec, you have to rotate log files pretty frequently otherwise your disks get filled. The issue I found, at least with journald, is it deadlocks when subjected to millions of queries/sec environments. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New logging system ideas
--On Friday, March 6, 2020 2:26 PM + Gavin Henry wrote: Hi Howard, This is for slapd to speak to? What's the higher level arch/issue? Several issues: * The sheer volume of log files generated at large sites (i.e., multiple GB/hour) that make log retention difficult, which can cause problems when trying to diagnose issues * syslog being lossy, making it difficult to determine root cause of issues, etc * The significant negative performance impact from logging. Clearly no logging will always be faster than logging enabled, but it should be possible to reduce the impact as compared to the current state. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Two log lines for SRCH parameters?
--On Tuesday, February 11, 2020 3:22 PM +0100 Michael Ströder wrote: Oh, I see [1]. Even in 2009 only a SHOULD for 2048 octets was defined while the MUST minimum was _lowered_ to 480 [2]. Seems to me to be continued support for why we should drop syslog support entirely and move to a more sensible logging framework. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New release policy for OpenLDAP
--On Wednesday, January 29, 2020 10:09 PM +0100 Michael Ströder wrote: On 1/29/20 7:49 PM, Quanah Gibson-Mount wrote: --On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder wrote: On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote: Also, I really really really would like 2.4.49 to be the end of 2.4, outside the possibility of some critical CVEs. But that's just your personal goal which is leaving systems in production unpatched until you feel you're done. IMO that's totally wrong. No, it's the project goal to switch the focus to getting OpenLDAP 2.5 released. At some point, work on 2.4 needs to stop. Unless you'd like to see 2.5 dragged out another decade? Is it realistic to enforce that 2.4.49 will be the final 2.4.x release before we saw at least one 2.5.x release? Sounds really strange to me. I never said it would absolutely be the last release. I said I would really really really like it to be the last release. Please pay attention to what is actually written. If there becomes enough reason to create another 2.4.x release, then clearly one will have to be made. We did this with 2.3 as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New release policy for OpenLDAP
--On Wednesday, January 29, 2020 6:52 PM +0100 Michael Ströder wrote: On 1/28/20 7:45 PM, Quanah Gibson-Mount wrote: Also, I really really really would like 2.4.49 to be the end of 2.4, outside the possibility of some critical CVEs. But that's just your personal goal which is leaving systems in production unpatched until you feel you're done. IMO that's totally wrong. No, it's the project goal to switch the focus to getting OpenLDAP 2.5 released. At some point, work on 2.4 needs to stop. Unless you'd like to see 2.5 dragged out another decade? Of course such a simple assumption is bullshit. To me the list of outstanding unfixed/unreleased issues matters most. Which ties into the above and why 2.4 needs to be sunsetted. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New release policy for OpenLDAP
--On Tuesday, January 28, 2020 7:01 PM +0100 Michael Ströder wrote: Today releasing is already way too slow. And I'm concerned that a release policy with additional constraints, as suggested with odd-/even-numbered releases, will make it even harder to get important fixes out of the door. I don't disagree that our current process is too slow. There's a lot of different gating factors, such as only 3 strongly active project members (Howard, Ondrej, myself), an badly out of date infrastructure, etc. That last bit we're working on addressing, but then it takes time away from getting new releases out in the meantime. Also, I really really really would like 2.4.49 to be the end of 2.4, outside the possibility of some critical CVEs. As for the new release numbering, I've thought about that as well, and was thinking potentially we may skip a release. I.e., go from 2.5.1 to 2.5.3 with no 2.5.2 if we just need to do a bug fix release (or vice versa if we match Gnome's strategy as Ryan brought up. But my point was, I think it's a fallacy to tie software quality and frequency of releases. I encounter way too much software today that releases frequently, but what it releases is poorly (or not at all) QA'd, etc. And it's a nightmare to deal with. I'd rather they slowed down and got their software in better shape than constantly release, well, crap. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New release policy for OpenLDAP
--On Tuesday, January 28, 2020 10:08 AM +0100 Michael Ströder wrote: On 1/27/20 11:17 PM, Quanah Gibson-Mount wrote: --On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder wrote: On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote: To me, frequent releases generally indicate an immature, unstable, and buggy product. ;) Are you sarcastic here? No, not at all. [..] If we release every 2 weeks, but slapd core dumps 90% of the time, is that really better? Sure, the project looks more "active", but I wouldn't see that as a benefit/gain. ITS#9124 is known since almost two months now and there's no upstream release with a fix. (And remember that I've tested RE24 branch revealing that the first fix was seg faulting.) You're switching topics. If you want to have a conversation, please stay on topic. Otherwise it's just a waste of time. The upcoming changes to the entire OpenLDAP project infrastructure have already been discussed, including CI, etc. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New release policy for OpenLDAP
--On Monday, January 27, 2020 10:45 PM +0100 Michael Ströder wrote: On 1/27/20 10:19 PM, Quanah Gibson-Mount wrote: To me, frequent releases generally indicate an immature, unstable, and buggy product. ;) Are you sarcastic here? No, not at all. I would say OpenLDAP has too few releases in a year (only 1-2 currently for most years, unfortunately), so having more frequent releases for it is probably a good thing. But a piece of software in general that is releasing constantly? Not a fan of it at all, and haven't seen it as a good thing as far as softare quality is concerned. There's plenty of software that releases much less frequently than OpenLDAP as well, because there isn't a driving need for it to have a new release. And as Howard noted, there's a balance to strike between stability and feature development. If we release every 2 weeks, but slapd core dumps 90% of the time, is that really better? Sure, the project looks more "active", but I wouldn't see that as a benefit/gain. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: New release policy for OpenLDAP
--On Saturday, January 25, 2020 11:22 PM +1100 Hugh McMaster wrote: As an observer of this project, the length of time between releases in this project makes it seem far less active than other projects. So, I personally would like to see more frequent releases, with a clearer timeline and goals for each release. I've never quite understood this mindset. To me, frequent releases generally indicate an immature, unstable, and buggy product. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
New release policy for OpenLDAP
There's been ongoing discussion about making changes to the current release strategy with OpenLDAP. Traditionally we've (for the most part) kept new features out of the release branch and did our best to primarily focus on bug fixes only. There have clearly been exceptions when warranted (such as support for LMDB, etc). However, this policy has had the effect of keeping significant improvements from being made readily available to end users of the software. To address this, we're looking at implementing the following: Starting with OpenLDAP 2.5, the OpenLDAP project will use a new release process. Odd numbered releases will contain only bug fixes Even numbered releases will allow for minor new features This will allow for end users who want stability to focus on odd numbered releases while allowing those who need/want newer features to be able to make use of them. Constructive responses to the new release strategy welcome. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.4 commit review
--On Saturday, January 11, 2020 10:42 AM +0100 Michael Ströder wrote: There are a few open ITSes that need addressing before I can proceed with a testing call. The fix for ITS#9124 is pretty urgent. So other ITS should not block releasing 2.4.49. Now that ITS#9150 is addressed, which was also rather serious as far as data integrity is concerned, we should be set for a testing call on Monday. I still have a side issue that has no ITS yet that may also go into this release, but we should be set for the testing call. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.4 commit review
--On Friday, January 10, 2020 6:06 PM +0100 Clément OUDOT wrote: Le 01/11/2019 à 17:31, Quanah Gibson-Mount a écrit : A few commits stacking up, so would like to review them for inclusion in an eventual 2.4.49. Hello, I would like to know if there was some date planned for 2.4.49, and if this ITS could be added to this release: http://www.openldap.org/its/index.cgi/Software%20Bugs?id=9146;selectid=91 46 It was already merged into RE24 and added to the CHANGES file for 2.4.49. There are a few open ITSes that need addressing before I can proceed with a testing call. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: dynlist enhancements, ITS#9121
--On Wednesday, December 18, 2019 8:04 AM +0100 Ondřej Kuzník wrote: More like making it no longer an error to load the same schema twice. From the usage cases I've seen, we should be able to support both static groups + old memberOf overlay and dynamic groups + dynamic memberOf concurrently in the deployment. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: dynlist enhancements, ITS#9121
--On Monday, December 16, 2019 11:46 PM +0100 Ondřej Kuzník wrote: On Mon, Dec 16, 2019 at 06:55:56PM +, Howard Chu wrote: The dynlist overlay doesn't define the memberOf attribute schema. Something else needs to do that, either loading it as user-defined schema, or relying on the memberof overlay to already be initialized. This seems like a messy loose end to leave dangling, but not sure what a better approach would be. Suggestions? How about being able to merge identical attribute definitions whether they come from config or directly from code? It would be great along with all of this to finally fix memberOf so it's actually functional (and replication safe) (I.e., can maintain membership regardless of user/group creation order). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.4 commit review
--On Friday, November 22, 2019 9:14 AM +1100 Hugh McMaster wrote: Any chance that ITS#8996 could be included? Back in April, you said pkg-config support would need to wait for a 2.5 release [1], but given the pace of development, that could still be months or years away. Howard, what's your opinion/thought on adding this for master/RE25? Ryan tested it and it worked for him. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.4 commit review
--On Thursday, November 21, 2019 1:32 PM + Howard Chu wrote: Are you OK with the rest of the changes (outside of ITS#8753) then? So totp isn't part of contrib in RE24, so I'll skip those changes and it can go out with the RE25 alpha (Thinking January or so for that). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.4 commit review
--On Tuesday, November 5, 2019 8:12 PM + Howard Chu wrote: Ryan Tandy wrote: ITS#9069 Do not call gnutls_global_set_mutex() Subject to hyc's approval, but I think this could go in. It's been in Debian since 10.0 and Ubuntu since 19.04, no negative feedback. OK, sounds fine then. Are you OK with the rest of the changes (outside of ITS#8753) then? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
2.4 commit review
A few commits stacking up, so would like to review them for inclusion in an eventual 2.4.49. I think all of the following look good for RE24, but wanted to confirm specifically on (a) the GnuTLS changes, (b) the cleaner error handling during connection setup, and (c) the Totp changes. OpenLDAP: ITS#9067 fix syntax evaluation of preferredDeliveryMethod ITS#8753 Set minimum GnuTLS version to 3.2.2 ITS#9071 Document "tls none" for back-ldap ITS#9069 Do not call gnutls_global_set_mutex() ITS#9077 slapo-unique Let the loop finish ITS#9095 insert missing commit at end of slapindex processing ITS#9091 drop attr mappings added in an aborted txn ITS#9100 relax domainScope check for absent value ITS#9112 cleaner error handling during connection setup Contrib: Totp: ITS#9055 Introduce a combined password scheme TotP: ITS#9055 Accept previous token LMDB: ITS#9068 fix backslash escaping Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: git://git.openldap.org down?
--On Wednesday, August 21, 2019 10:49 PM +0200 Michael Ströder wrote: HI! It seems that git://git.openldap.org is not reachable since yesterday. Thanks for the heads up, fixed. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Please review 2.5 plan (non-development items)
--On Tuesday, July 23, 2019 8:57 PM +0300 Alexander Bokovoy wrote: Azure Pipelines give free 10 concurrent runners for open source projects and can connect with GitLab instances for CI/CD. We use it in FreeIPA in our GitHub pull request review process. The runners are fairly easy to configure; they run Ubuntu 16.04 but include Docker so it is possible to do a lot more. FreeIPA runs tests on containerized Fedora 30, for example. And Azure Pipelines also have Windows and macOS runners: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/hosted?vie w=azure-devops If you are interested, I can share my experience on setting it up. I haven't tried Windows images as I didn't need them but the rest is quite well working. Hi Alexander, That would be great, thanks for the offer. :) I currently build on Windows using gcc under MSYS2, which doesn't seem to be an offering from MS (no surprise there). But I do see a project maintaining VC bits for OpenLDAP that perhaps we could leverage (<https://github.com/winlibs/openldap>). Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Please review 2.5 plan (non-development items)
--On Tuesday, July 23, 2019 4:37 PM +0200 Ondřej Kuzník wrote: Hi, I've prepared a plan what the project wants to achieve as part of the 2.5 stream apart from core OpenLDAP development that I intend to send to -technical for wider discussion and as a call for participation. It has been suggested to me that people might want to comment/propose changes to it so attaching a draft here. Please let me know what you think or if you agree in broad terms it is fit to be circulated more widely. Hi Ondrej, Thanks for writing this up! In the section about the bug tracker, I would note that the plan is to use Bugzilla for the tracker (as opposed to gitlab issues) via Gitlab's built in bugzilla integration feature. For contributions, I'd like to see something like <https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-license/> implemented, so it's simply a part of the contribution process rather than us having to constantly bug people about it. I agree with Michael that the FAQ should probably just be migrated to using the Gitlab wiki, since we'll already have that available. On CI/CD, hopefully we can make use of some of the freely available resources, such as <https://build.opensuse.org/>. What we're particularly missing is Windows as a platform for CI/CD, which would have helped us catch the additional bits necessary for ITS#7585 for example. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: libldap cyrus.c and windows (RE24 release candidate)
--On Monday, July 22, 2019 5:55 PM -0700 Quanah Gibson-Mount wrote: --On Monday, July 22, 2019 4:33 PM -0700 Quanah Gibson-Mount wrote: So the limits.h include file should be included. Any thoughts? Ok, it's using a different include path, and HOST_NAME_MAX is definitely not in there. Ok, general issue is that the patch for ITS#7585 is Linux specific, but the patch made no allowance for Windows. I'm testing an ugly patch atm just to see if it'll allow Windows compilation. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: libldap cyrus.c and windows (RE24 release candidate)
--On Monday, July 22, 2019 4:33 PM -0700 Quanah Gibson-Mount wrote: So the limits.h include file should be included. Any thoughts? Ok, it's using a different include path, and HOST_NAME_MAX is definitely not in there. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
libldap cyrus.c and windows (RE24 release candidate)
Having an issue with cyrus.c on windows.
I keep hitting:
openldap/libraries/libldap/cyrus.c: In function 'ldap_int_sasl_bind':
openldap/libraries/libldap/cyrus.c:392:19: error: 'HOST_NAME_MAX'
undeclared (first use in this function); did you mean 'FILENAME_MAX'?
char my_hostname[HOST_NAME_MAX + 1];
^
FILENAME_MAX
Yet this code compiles just fine:
$ cat test.c
#include
void main() {
char my_hostname[HOST_NAME_MAX + 1];
}
In cyrus.c, we have:
#ifdef HAVE_CYRUS_SASL
...
#ifdef HAVE_LIMITS_H
#include
#endif
...
in config.log, it has:
#define HAVE_CYRUS_SASL 1
and
#define HAVE_LIMITS_H 1
So the limits.h include file should be included.
Any thoughts?
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: Drop support for GNUTLS and libnss in 2.5?
--On Monday, July 22, 2019 4:33 PM +0200 Matus Honek wrote: I can confirm RHEL/CentOS nor Fedora downstreams in their most active releases no longer actively use the code from tls_m.c. Therefore its removal should be OK in 2.4 branch, from point of view of these distros. Hi Matúš, We do not plan on removing the moznss support from RE24 as that would be too invasive of a change and the goal really is to wrap up 2.4 and start releasing 2.5. So the plan is to remove the MozNSS support from RE25 prior to it releases. Thanks for the confirmation that RHEL/CentOS and Fedora no longer make use of it. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Sunday, July 21, 2019 10:54 PM +0200 Ondřej Kuzník wrote: On Sun, Jul 21, 2019 at 10:18:37AM -0700, Quanah Gibson-Mount wrote: Now you are providing conflicting answers. The man page for back-ldap makes zero reference to ldap.conf(5). It only mentions slapd.conf(5). The syncrepl section of slapd.conf(5)/slapd-config(5) only mention the network-timeout value being pulled in from ldap.conf(5). So which is it? Do they follow the man page behaviors (which would mean no ldap.conf(5) for slapd-ldap, and only network-timeout for syncrepl), or do they violate the man page description? (replying to the gist of the entire thread) I'm happy with back-ldap, etc. honouring global ldap.conf. Deployments that need to avoid that can and should define LDAPNOINIT. Also AFAIK libldap initialisation happens before any configuration is even parsed so might be a bit harder to avoid it. Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and possibly other paremters) if they are not found in slapd.conf(5). We should document what happens somewhere, definitely. Maybe TLS section of slapd.conf manpage? I'll defer to you where that should happen and hopefully either of also you wants to write it (and the LDAPNOINIT advice) while I work on fixing this :) I'll just tweak things later so the docs fit exactly what happens when it comes to setting up slapd_tls_ld and what the relevant clients (syncrepl and back-ldap) do too. After further discussion with Howard, ITS#8427 is going to get reverted from RE24 for now, and we'll look at getting it fixed fully for 2.4.49. It appears it has introduced a regression with both GnuTLS and OpenSSL. Long term, we need to decide exactly how we want this all to work in RE25 as well. I'm with Michael in that I think slapd should never accept any CAs unless explicitly configured to do so, and right now it appears that without this patch, it can do exactly that with both OpenSSL and GnuTLS, regardless of whether or not an ldap.conf file is in place. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Sunday, July 21, 2019 11:16 PM +0100 Howard Chu wrote: I take this back. Pretty sure we've had this debate before, haven't found it in the list archive. We explicitly create a fresh TLS context in slapd, to eliminate any ldap.conf initialization defaults. Ok, so it's GnuTLS that had broken behavior and it was fixed by ITS#8427. You also noted in IRC that you found the related ITS: <https://www.openldap.org/its/index.cgi/?findid=3109> So GnuTLS actually introduced a regression in behavior. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Sunday, July 21, 2019 10:54 PM +0100 Howard Chu wrote: You claimed it was inconsistent because syncrepl refers to ldap.conf for network timeout settings while back-ldap makes no reference to ldap.conf. No, if you read my email, I was purely noting that again that the man pages make no reference to ldap.conf(5) *outside* of syncrepl's explicit statement about network-timeout. Going back to your statement that the behavior should conform to the man pages for back-ldap and syncrepl. Feel free to add a note to slapd.conf(5) / slapd-config(5) about TLS defaults. I think that's worth doing. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Sunday, July 21, 2019 10:02 PM +0100 Howard Chu wrote: As I already said: there is no reason for the syncrepl consumer and back-ldap to behave identically. The manpages are correct in each case. I've never said they should behave identically, and I do not fathom why you are so focussed on something I never stated. *You* stated: "The behavior is supposed to be exactly as specified in the manpages." The *man page* for back-ldap makes ZERO reference to ldap.conf. It makes ZERO reference to back-ldap being considered an "ldap client". If your statement that they should behave as specified in the man pages is true, then its behavior is incorrect, because PER THE MAN PAGE the TLS settings are either EXPLICIT in the back-ldap configuration OR they are taking from slapd's TLS settings. NOWHERE does it say that if there are no settings in back-ldap OR slapd that it will THEN take the settings from ldap.conf. The *exact same* applies to syncrepl and its TLS settings. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Sunday, July 21, 2019 3:37 PM +0100 Howard Chu wrote: --On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu wrote: The behavior is supposed to be exactly as specified in the manpages. A syncrepl consumer is an LDAP client. A back-ldap backend is an LDAP client. Now you are providing conflicting answers. The man page for back-ldap makes zero reference to ldap.conf(5). It only mentions slapd.conf(5). The syncrepl section of slapd.conf(5)/slapd-config(5) only mention the network-timeout value being pulled in from ldap.conf(5). So which is it? Do they follow the man page behaviors (which would mean no ldap.conf(5) for slapd-ldap, and only network-timeout for syncrepl), or do they violate the man page description? Generally, it seems to me we at the least have a documentation bug, in that back-ldap(5) and the syncrepl section of slapd.conf(5)/slapd-config(5) should note that they will rely on ldap.conf(5) in the absence of TLS (and possibly other paremters) if they are not found in slapd.conf(5). Additionaly, what should we do about ITS#8427? It was clearly fixing a valid bug. Do we revert it? Do we fix the behavior so it fixes the bug reported, but does not introduce a regression? And we need to know the answer to that and have a fix in rather quickly. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Sunday, July 21, 2019 2:51 AM +0100 Howard Chu wrote: The behavior is supposed to be exactly as specified in the manpages. There is no reason to expect back-ldap and syncrepl to be exactly alike; they perform different functions. You missed the point. It wasn't about syncrepl vs back-ldap, it was about whether or not *anything* used in slapd should ever pull in data from ldap.conf. The *only* thing I can find that pulls in anything from ldap.conf (per the man pages) is syncrepl. Which seems rather odd, particularly since it's only for one specific value. Especially given that ldap.conf(5) specifies it is only for ldap clients. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Saturday, July 20, 2019 8:43 PM +0100 Howard Chu wrote: As documented in slapd-ldap(5) The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand". If that no longer works, then we have yet another regression. I guess the underlying question is, if they aren't in slapd.conf, where do slapd clients (syncrepl, back-ldap, etc) get them from? For example, syncrepl is clearly designed to get at least one setting from ldap.conf: The network-timeout parameter sets how long the consumer will wait to establish a network connection to the provider. Once a connection is established, the timeout parameter determines how long the consumer will wait for the initial Bind request to complete. The defaults for these parameters come from ldap.conf(5). So is it supposed to be that the configuration levels are: slapd client (syncrepl, back-ldap specific parameters) override slapd configuration (slapd.conf(5), slapd-config(5) parameters) Or is it supposed to be: slapd client (syncrepl, back-ldap specific parameters) override slapd configuration (slapd.conf(5), slapd-config(5) parameters) override ldap.conf(5) If it's the former, then syncrepl should not pull anything from ldap.conf. If it's the latter, then we have a clear regression. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: back_ldap / TLS Issues with OPENLDAP_REL_ENG_2_4_48
--On Saturday, July 20, 2019 3:55 PM +0300 Nikos Voutsinas wrote: I am using the ldap.conf TLS params to provide the path to CAs. That's the default way for Debian. It works with 2.4.47, it also works for the 2.4.48 openldap client utils) as I mentioned earlier. ldap.conf is only for client utilities. This is clearly described in the ldap.conf(5) man page. This sounds more to me like we've closed a bug with the GnuTLS implementation. From ldap.conf(5): The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Drop support for GNUTLS and libnss in 2.5?
--On Saturday, July 20, 2019 1:13 PM +0200 Michael Ströder wrote: The support for libnss was done by RedHat for the unified crypto project which is AFAICS obsolete. Does anybody maintain the stuff? There's already an ITS for removing the MozNSS bits from 2.5 somewhere, IIRC. But yes, that's the plan for that portion. As Ryan already noted, there are issues with OpenSSL moving to the Apache License that may actually make it harder for us to get rid of GnuTLS support. I argued heavily with the OpenSSL folks against using Apache because of its GPLv2 incompatibilities, but unfortunately that went nowhere (I suggested the MPLv2 instead, since it has patent protections (which is what they're looking for) and is compatible with the GPLv2). Oh well. :/ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Issues ISC dhcpd using libldap of OpenLDAP 2.4.48
--On Wednesday, July 17, 2019 8:19 PM +0200 Michael Ströder wrote: On 7/17/19 4:41 PM, Howard Chu wrote: strace is not useful here. Pretty sure we've stated this many times before. Sorry. Indeed ltrace output is more helpful. Hm, does reverting any of these four ITSes allow it to work? Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326) (33945aeb96124f5956c0657b41bb68ca29fab66c) Fixed libldap to correctly disable IPv6 when configured to do so (ITS#8754) (c4f55cea87880ca8c14b559bd77bcea19ad615cd) Fixed libldap race condition in ldap_int_initialize (ITS#7996, ITS#8450) (cde56fad154fcd25e351c3cd84d8173d263b0a01, 877faea723ecc5721291b0b2f53e34f7921e0f7c) Fixed libldap return code in ldap_create_assertion_control_value (ITS#8674) (8e6d1b8b81e94f89027a120ea862bd5938e953c6) Those items are the ones that stand out to me in the change log that have the highest possibilty of affecting things. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Current RE24 status (2.4.48)
Ondrej is looking at a few different issues related to replication w/ syncrepl, including cn=config. Additionally, the fix applied for ITS#8427 has broken back-ldap with ldaps. For the last item, one option would be to revert ITS#8427, although I'd prefer to see a fix rather than a revert. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Persistent failures of test050
--On Thursday, June 27, 2019 1:09 PM +0200 Ondřej Kuzník wrote: Not sure the above is the same failure I'm seeing, so will outline mine (reproduced on master+ITS#9043 logging): I was just badly summarizing our earlier discussions, it was the same thing. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Persistent failures of test050
--On Tuesday, June 25, 2019 5:45 PM -0700 Quanah Gibson-Mount wrote: Problem #2) If a MMR node is processing a change during which a slapd shutdown is initiated, it will update the contextCSN of the database but LOSE the related change (at least with a delete op), resulting in a database difference. This is reproducible in 2.4.47 as well (so this is not a regression). Ok, this is just a timing issue, the ldapsearch to generate the DB data to compare was generated before all the nodes had finished processing the changes involved. It might be better to do something like get the contextCSN from the initial master after the change has completed, and ensure that the remaining nodes have the same contextCSN value before generating the LDIF for comparison. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Persistent failures of test050
--On Saturday, June 22, 2019 2:06 PM -0700 Quanah Gibson-Mount wrote: [build@freebsd12 ~/git/openldap-2-4/tests/testrun]$ diff -u server1.out server3.out --- server1.out 2019-06-22 18:23:54.93360 + +++ server3.out 2019-06-22 18:23:55.049209000 + @@ -1,3 +1,8 @@ +dn: cn=Add-Mod-Del,dc=example,dc=com +cn: Add-Mod-Del +objectClass: organizationalRole +description: guinea pig + There appears to be two separate problems happening in test050. Problem #1) Null cookie is generated, causing catastrophic database loss across the entire MMR cluster (they all lose all their data). This is new with 2.4.48, perhaps related to the revert of part of ITS#8281 when ITS#9015 was fixed (purely speculation on my part at the moment). This appears to be a major/significant regression. Problem #2) If a MMR node is processing a change during which a slapd shutdown is initiated, it will update the contextCSN of the database but LOSE the related change (at least with a delete op), resulting in a database difference. This is reproducible in 2.4.47 as well (so this is not a regression). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
--On Tuesday, June 25, 2019 9:30 AM -0700 Quanah Gibson-Mount wrote: --On Monday, June 24, 2019 9:33 AM +0200 Armin Tüting wrote: Starting test065-proxyauthz for mdb... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com Refresh failed Hi Armin, Thanks for the report, I'm testing to see if I can reproduce this result. I've run the test 2,000 times with zero failures. If you still have the testrun directory available from this failed run, it may be worthwhile to examine the slapd log file, etc, to see what it reported. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
--On Monday, June 24, 2019 9:33 AM +0200 Armin Tüting wrote: Starting test065-proxyauthz for mdb... Starting master slapd on TCP/IP port 9011... Using ldapsearch to check that master slapd is running... Using ldapadd to populate the master directory... Starting proxy cache on TCP/IP port 9012... Using ldapsearch to check that proxy slapd is running... Making queries on the proxy cache... Query 1: cn=James A Jones 1,ou=Alumni Association,ou=People,dc=example,dc=com Refresh failed Hi Armin, Thanks for the report, I'm testing to see if I can reproduce this result. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: libldap 2.4.48 compability (was: RE24 testing call)
--On Tuesday, June 25, 2019 5:16 PM +0200 Michael Ströder wrote: Any idea how I could find out what's going wrong? dhcpd seems to dynamically link libldap 2.4.48 but fails to properly use it. Can you step through it with something like gdb? Looking at the CHANGES file, I don't see anything obvious, unless you disabled IPv6 during compilation and its trying to use an IPv6 address (ITS#8754) or AI_ADDRCONFIG does odd things on your system (ITS#7326). --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: Persistent failures of test050
--On Sunday, June 23, 2019 12:59 AM +0200 Michael Ströder wrote: On 6/22/19 10:06 PM, Quanah Gibson-Mount wrote: I've noticed that when running test050 in a loop, it often fails, even after increasing the sleep timeout defaults. Where it fails in the test is inconsistent and which servers differ is inconsistent as well. I can confirm that it fails on my system too. Thanks Michael. There's definitely a bug here, Ondrej will be filing an ITS on it this week or next as he gets more details on what's occurring. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
--On Saturday, June 22, 2019 11:24 AM +0200 Michael Ströder wrote: Furthermore I've generated RPM packages of this snapshot [1] and did some short tests with Æ-DIR which uses a combination of many different overlays. For now it seems to work just fine. Thanks for the extended testing Michael! Would you be able to do some loops of test050 and see if you can reproduce the issue I just reported? Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Persistent failures of test050
I've noticed that when running test050 in a loop, it often fails, even after increasing the sleep timeout defaults. Where it fails in the test is inconsistent and which servers differ is inconsistent as well. I'm concerned we may have a regression or perhaps long standing issue here that needs addressing. I'll continue to investigate and see if I can get more details on what the issue(s) are. In my latest run I see: . Using ldapmodify to add/modify/delete entries from server 1... iteration 1 iteration 2 iteration 3 iteration 4 iteration 5 iteration 6 iteration 7 iteration 8 iteration 9 iteration 10 Waiting 10 seconds for servers to resync... Using ldapsearch to read all the entries from server 1... Using ldapsearch to read all the entries from server 2... Using ldapsearch to read all the entries from server 3... Using ldapsearch to read all the entries from server 4... Comparing retrieved entries from server 1 and server 2... Comparing retrieved entries from server 1 and server 3... test failed - server 1 and server 3 databases differ Failed after 3 of 500 iterations [build@freebsd12 ~/git/openldap-2-4/tests/testrun]$ diff -u server1.out server3.out --- server1.out 2019-06-22 18:23:54.93360 + +++ server3.out 2019-06-22 18:23:55.049209000 + @@ -1,3 +1,8 @@ +dn: cn=Add-Mod-Del,dc=example,dc=com +cn: Add-Mod-Del +objectClass: organizationalRole +description: guinea pig + dn: cn=All Staff,ou=Groups,dc=example,dc=com member: cn=Manager,dc=example,dc=com member: cn=Barbara Jensen,ou=Information Technology Division,ou=People,dc=exam --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
--On Friday, June 21, 2019 3:56 PM -0700 Quanah Gibson-Mount wrote: --On Friday, June 21, 2019 7:19 AM -0700 Quanah Gibson-Mount wrote: This is expected to be the final testing call for 2.4.48, with an anticipated release, depending on feedback, during the week of 2019/06/24. ITS#7585 needs a further fix for FreeBSD12, working on it. Proposed patch, not sure if it should come before or after the #ifdef HAVE_CYRUS_SASL: diff --git a/libraries/libldap/cyrus.c b/libraries/libldap/cyrus.c index f292527de..4d90120e6 100644 --- a/libraries/libldap/cyrus.c +++ b/libraries/libldap/cyrus.c @@ -29,6 +29,10 @@ #include #endif +#if !defined(HOST_NAME_MAX) && defined(_POSIX_HOST_NAME_MAX) +#define HOST_NAME_MAX _POSIX_HOST_NAME_MAX +#endif + #include "ldap-int.h" #ifdef HAVE_CYRUS_SASL --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
--On Friday, June 21, 2019 7:19 AM -0700 Quanah Gibson-Mount wrote: This is expected to be the final testing call for 2.4.48, with an anticipated release, depending on feedback, during the week of 2019/06/24. ITS#7585 needs a further fix for FreeBSD12, working on it. --Quanah
RE24 testing call (2.4.48) LMDB RE0.9 testing call (0.9.24)
This is expected to be the final testing call for 2.4.48, with an anticipated release, depending on feedback, during the week of 2019/06/24. Generally, get the code for RE24: <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs/heads/OPENLDAP_REL_ENG_2_4;sf=tgz> Configure & build. Execute the test suite (via make test) after it is built. Optionally, cd tests && make its to run through the regression suite. Thanks! OpenLDAP 2.4.48 Engineering Added libldap OpenSSL Elliptic Curve support (ITS#7595) Added libldap Expose OpenLDAP specific interfaces via openldap.h (ITS#8671) Added slapd-monitor support for slapd-mdb (ITS#7770) Fixed liblber leaks (ITS#8727) Fixed liblber with partial flush (ITS#8864) Fixed libldap ASYNC TLS so it works (ITS#8957,ITS#8980) Fixed libldap ASYNC connections with Solaris 10 (ITS#8968) Fixed libldap with SASL_NOCANON=on and ldapi connections (ITS#7585) Fixed libldap to use AI_ADDRCONFIG when available (ITS#7326) Fixed libldap to be able to unset syncrepl TLS options (ITS#7042) Fixed libldap race condition in ldap_int_initialize (ITS#7996, ITS#8450) Fixed libldap return code in ldap_create_assertion_control_value (ITS#8674) Fixed libldap to correctly disable IPv6 when configured to do so (ITS#8754) Fixed libldap to correctly close TLS connection (ITS#8755) Fixed libldap_r handling of deprecated OpenSSL function (ITS#8353) Fixed liblunicode case correspondance (ITS#8508) Fixed slapd with an idletimeout of less than four seconds (ITS#8952) Fixed slapd config parser variable for Windows64 (ITS#9012) Fixed slapd syncrepl fallback handling with delta-syncrepl (ITS#9015) Fixed slapd telephoneNumberNormalize, cert DN validation (ITS#8999) Fixed slapd syncrepl for relax with delta-syncrepl (ITS#8037) Fixed slapd TLS settings on reconnection (ITS#8427) Fixed slapd to restrict rootDN proxyauthz to its own databases (ITS#9038) Fixed slapo-accesslog with SLAP_MOD_SOFT modifications (ITS#8990) Fixed slapd-ldap starttls connections timeout behavior (ITS#8963) Fixed slapd-ldap TLS settings on reconnection (ITS#8427) Fixed slapd-ldap segfault when entry result doesn't match filter (ITS#8997) Fixed slapd-meta conversion from slapd.conf to cn=config (ITS#8743) Fixed slapd-meta TLS settings on reconnection (ITS#8427) Fixed slapd-meta assertion when network interface goes down (ITS#8841) Fixed slapd-mdb fix bitshift integer overflow (ITS#8989) Fixed slapd-mdb index cleanup with cn=config (ITS#8472) Fixed slapo-accesslog possible assert with exops (ITS#8971) Fixed slapo-chain to correctly reject multiple chaining URIs (ITS#8637) Fixed slapo-chain conversion from slapd.conf to cn=config (ITS#8799) Fixed slapo-memberof conversion from slapd.conf to cn=config (ITS#8663) Fixed slapo-memberof for group name change to itself (ITS#9000) Fixed slapo-ppolicy behavior when pwdInHistory is changed (ITS#8349) Fixed slapo-rwm to not free original filter (ITS#8964) Fixed slapo-syncprov contextCSN generation (ITS#9015) Build Environment Fixed slapd to only link to BDB libraries with static build (ITS#8948) Fixed libldap implicit declaration with LDAP_CONNECTIONLESS (ITS#8794) Documentation General - Fixed minor typos (ITS#8764, ITS#8761) admin24 - Miscellaneous updates promoting mdb and fixing examples (ITS#9031) slapd.access(5) - Note MDB is the primary backend (ITS#8881) slapd.backends(5) - Note MDB is the recommended backend (ITS#8771) slapd-ldap(5) - Document starttls parameter (ITS#8693) Contrib Added slapo-lastbind capability to forward authTimestamp updates (ITS#7721) LMDB 0.9.24 Engineering ITS#8969 Tweak mdb_page_split ITS#8975 WIN32 fix writemap set_mapsize crash ITS#9007 Fix loose pages in WRITEMAP --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: ITS#8286 continued
--On Tuesday, June 18, 2019 7:28 PM +0100 Howard Chu wrote: for the matching rule. Anyone have an opinion for caseIgnoreMatch being better? Looks like the values are schema keywords, they should be caseIgnoreMatch. Great, thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
ITS#8286 continued
I found a few stray items that still need matching rules. All were
trivially straight forward except one for slapo-chain:
{ "chain-chaining", "args",
2, 4, 0, ARG_MAGIC|ARG_BERVAL|CH_CHAINING, chain_cf_gen,
"( OLcfgOvAt:3.1 NAME 'olcChainingBehavior' "
"DESC 'Chaining behavior control parameters
(draft-sermersheim-ldap-chaining)' "
"SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL },
At the moment, based on the man page description, I was thinking:
"EQUALITY caseExactMatch "
for the matching rule. Anyone have an opinion for caseIgnoreMatch being
better?
Thanks,
Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
Re: ITS review 6/14/2019
--On Monday, June 17, 2019 2:23 PM +0100 Howard Chu wrote: The following ITSes have a patch or have been committed already. --- ITS#7721 - contrib/lastbind - allow authtimestamp forwarding with updateref (44e9bda0e42f40e0baf0a2c0ef733eb757abd366) This is an enhancement, not a bugfix. Generally we've allowed that for contrib modules. ITS#7770 - back-monitor - Add mdb_stat info (e19c683c41e14365d28e82278eec1d8b12c71d4c , 6e2bac6465bb81a8c1aeb083b6dc497eb4187264 ) This is also an enhancement, not a bugfix. Already discussed adding #7770 to RE24, seems like a good idea. Are we allowing other enhancements into RE24? We've done a few: back-sock enhancements in 2.4.47, for example, support for OpenSSL 1.1.0+ in 2.4.45, support for "nordahead" flag in 2.4.37 with back-mdb. So it's your call. ITS#8695 - slapd - "sleep" is deprecated (WINDOWS ONLY) (has patch, IPR OK) Needs version checks. Ok, will work on that bit. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
ITS review 6/14/2019
Thanks to Ondrej, this list is a bit shorter now. :) The following ITSes have a patch or have been committed already. --- ITS#7721 - contrib/lastbind - allow authtimestamp forwarding with updateref (44e9bda0e42f40e0baf0a2c0ef733eb757abd366) ITS#7770 - back-monitor - Add mdb_stat info (e19c683c41e14365d28e82278eec1d8b12c71d4c , 6e2bac6465bb81a8c1aeb083b6dc497eb4187264 ) ITS#8037 - slapd - Fix delta-syncrepl with relax (cb9a4d01bc1ecf1eeb3fb7ef39067b2b30b6c545) ITS#8349 - Fix ppolicy behavior with pwdHistory ITS#8508 - liblunicode - Fix ucgendat (cc99da182f53d3d4f3874703643b23717af3) ITS#8637 - slapd-ldap - Correctly reject invalid config with slapd-config (has patch, IPR OK) ITS#8671 - libldap - ldap_init_fd() in ldap.h (6a5e30674b63b17587738ba9a3d1ea3633c33fb1) ITS#8695 - slapd - "sleep" is deprecated (WINDOWS ONLY) (has patch, IPR OK) ITS#8755 - libldap - leaking file descriptor when closing connection (has patch, IPR OK) ITS#8794 - libraries/libldap - Fix implicit declaration (has minor patch) ITS#8799 - back-chain - Fix conversion from slapd.conf (has patch, IPR OK) ITS#8864 - liblber - fix ber_flush (fb49d486a35fd4b2e993398c1eea0c8f7bc6ac40) ITS#8875 - back-mdb - fix performance problems with large DIT and many aliases (has patch, RE25 only) ITS#8997 - slapd-ldap - Fix segfault (Howard already wrote the patch, just needs to be committed) ITS#9000 - slapo-memberof - Fix group rename issue (Ondrej has already written the patch, just needs to be committed?) -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: ITS review 6/4/2019
--On Thursday, June 13, 2019 7:47 PM +0200 Ondřej Kuzník wrote: ITS#9001 - libraries/libldap - Use new Tavl bits to reduce search time (has patch, IPR OK) This one isn't ready yet, might not belong to 2.4 anyway, also pending answer on https://www.openldap.org/lists/openldap-devel/201903/msg00011.html Yep, that was in there by mistake. :) I've removed it from my ITS document. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: 2.4.48
--On Tuesday, June 04, 2019 9:22 AM +0200 Michael Ströder wrote: HI! Any blockers for releasing 2.4.48? Ciao, Michael. I need to circle around back on the list of items I had, I'll do that this week. We may simply have to punt on some of them, as much as I'd rather not. ;) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Farewell BerkeleyDB we hardly knew ye
As of today, the two BerkeleyDB based backends (back-bdb, back-hdb) are removed from OpenLDAP head as part of the preparations for OpenLDAP 2.5. RIP! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: anyone on this list who might have a contact for the LDAP Tool Box (LTB) mailing lists?
--On Monday, May 06, 2019 12:15 PM -0400 Brian Reichert wrote: I apologize for utilizing this forum for this, but does anyone here have contact with someone who runs the LDAP Tool Box (LTB) mailing lists? Please contact me off-list; I'm having difficulty getting mail delivered to the LTB mail server. They're active members of the openldap-technical list. You could start with Clément OUDOT I believe. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
ITS#7770 and test056
In looking at test056, which specifically queries the BDB based attributes from back-monitor (olmBDBEntryCache olmBDBDNCache olmBDBIDLCache), shouldn't it be updated to do something similar for back-mdb's monitored attributes? olmMDBPagesMax olmMDBPagesUsed olmMDBPagesFree olmMDBReadersMax olmMDBReadersUsed olmDbDirectory --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
Re: ITS 8996
--On Tuesday, April 23, 2019 9:47 AM +1000 Hugh McMaster wrote: On that point, are there any plans/ideas to move to bugzilla or even github/gitlab for development? The ITS isn't the most user friendly platform around. Yes, the plan is to move off of jitterbugs and onto another platform. It's largely dependent on me having the time to sit down and finish migrating the OpenLDAP services onto a new system. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>
