openldap-devel

openldap-devel@openldap.org

1418 discussions

2.5 build failure on OBS
by Michael Ströder 05 Feb '21

05 Feb '21

HI! As usual I'm using openSUSE Build Service to build openldap2 RPMs. This smoothly works with 2.4.x. But building 2.5 branch snapshot fails. Maybe OBS compiler options are set pretty strict because it outputs: [ 147s] cc1: some warnings being treated as errors [ 147s] make[2]: *** [<builtin>: slapd-watcher.o] Error 1 You can look at the full build log with some warnings here: https://build.opensuse.org/public/build/home:stroeder:branches:home:stroede… Ciao, Michael.

2 2

HAProxy proxy protocol support
by Paul B. Henson 22 Dec '20

22 Dec '20

We currently run our openLDAP service on our campus behind an F5 load balancer which preserves the IP address of the connecting client through to the backend servers, which we rely on for a small amount of IP address based authorization differentiating between on-campus and off-campus access. However, management is strongly pushing us to migrate the service to the Amazon cloud, using Amazon's load balancer. Unfortunately, Amazon's load balancer only supports client NAT for directing connections to the back end servers, so they have no idea who the actual client is, it just appears to be the load balancer itself. Amazon's solution for that is to support HAProxy's proxy protocol in their load balancer: https://www.haproxy.com/blog/haproxy/proxy-protocol/ Basically, this is an in band signaling mechanism that inserts an additional header in the initial connection data containing the original client IP address/source port and destination IP address/source port, allowing the server to utilize that information for the connection rather than the actual details of the network connection from the proxy itself. This requires support from the application running on the server, as it must remove and process that proxy header from the connection data before moving on with whatever data would normally be passed on the connection. There are some fair number of services that support this proxy, including of course HAProxy itself, such as the apache web server and the postfix mail server. openLDAP does not support the protocol, and I was unable to find any past discussion of it. I was wondering if this feature would be something acceptable for inclusion to openLDAP, or if from an architectural perspective it would be considered undesirable. In general, I believe applications listening on a specific port are either expecting the proxy protocol header, or not, I do not think it is dynamically determined. As such, from an implementation perspective, my initial thought is that it would be implemented in terms of configuration as an additional URL specified via the -h option, something like "ldapp://" or "ldap_p://", "ldapsp://" or "ldaps_p://" or whatever seems most desirable. A server might listen on the standard ports accepting only proxied connections, or it might listen for normal connections on the standard ports and for proxy connections on alternative ports. When a connection is accepted on a port marked as requiring the proxy protocol, it would read and process the proxy header to populate the appropriate data structures regarding connection, and then move on as it normally would to deal with the connection. If this feature is of interest, I will probably spend a little time poking at it and seeing how much trouble it will be to implement. Thanks…

6 21

backport ITS#9264 to
by Nikos Voutsinas 06 Dec '20

06 Dec '20

Hello all, The fix for the Issue 9264 (Add lock to slapo-unique to delay new ops until current op is complete) <https://bugs.openldap.org/show_bug.cgi?id=9264> prevents an inconsistent or unexpected behavior of slapd in the case of multiple concurrent modifiers, thus I would suggest to backport the fix to the OPENLDAP_REL_ENG_2_4. The conditions that trigger this is not that rare and we have encountered it multiple times, mostly but not only during batch operations Best Regards, Nikos

1 0

slapo-constraint negated regex
by David Barchiesi 17 Nov '20

17 Nov '20

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 ^.*(a)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? Thanks in advance, David [1] https://stackoverflow.com/questions/55190518/extended-posix-regular-express… [2] https://stackoverflow.com/questions/15377469/posix-regular-expressions-excl… [3] https://stackoverflow.com/questions/38928863/posix-regex-not-match-a-word

2 1

CI/CD on git.openldap.org
by Norbert Klasen 30 Oct '20

30 Oct '20

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%2Fgitl…: dial tcp: lookup docker on 173.255.199.5:53: no such host Regards Norbert -------- Forwarded Message -------- Subject: JLDAP | Pipeline #1219 has failed for maven | 6795ebdf Date: Fri, 30 Oct 2020 08:02:31 +0000 From: GitLab <gitlab(a)git.openldap.org> Reply-To: GitLab <noreply(a)git.openldap.org> JLDAP | Pipeline #1219 has failed for maven | 6795ebdf GitLab ✖ Your pipeline has failed. Project Norbert Klasen <https://git.openldap.org/klasen> / JLDAP <https://git.openldap.org/klasen/jldap> Branch maven <https://git.openldap.org/klasen/jldap/-/commits/maven> Commit 6795ebdf <https://git.openldap.org/klasen/jldap/-/commit/6795ebdf4f091ff4135cb5a671b9…> Delete .gitlab-ci.yml. Re-enable Auto DevOps pi... Commit Author Norbert Klasen <https://git.openldap.org/klasen> Pipeline #1219 <https://git.openldap.org/klasen/jldap/-/pipelines/1219> triggered by Norbert Klasen <https://git.openldap.org/klasen> had 2 failed builds. Failed builds ✖ test code_quality <https://git.openldap.org/klasen/jldap/-/jobs/2594> ✖ build build <https://git.openldap.org/klasen/jldap/-/jobs/2592> GitLab You're receiving this email because of your account on git.openldap.org. Manage all notifications <https://git.openldap.org/profile/notifications> · Help <https://git.openldap.org/help>

2 2

Moving OpenLDAP 2.5 towards release
by Quanah Gibson-Mount 14 Oct '20

14 Oct '20

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&component=build&co…> *) There are about 40 explicit documentation bugs, as found here: <https://bugs.openldap.org/buglist.cgi?component=documentation&list_id=837&p…> 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&bug_status=VERIFI…> 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>

1 1

Re: OpenLDAP 2.4.51 available, LMDB 0.9.26 available
by Clément OUDOT 12 Aug '20

12 Aug '20

Hello, changelog seems not well updated on the website: https://www.openldap.org/software/release/changes.html Clément. Le mer. 12 août 2020 à 07:02, <project(a)openldap.org> a écrit : > > OpenLDAP 2.4.51 is now available for download as detailed on our download page: > > https://www.openldap.org/software/download/ > > and should soon be available on all official mirrors: > > ftp://ftp.openldap.org/pub/OpenLDAP/MIRRORS > > This is a maintenance release and is made available for general use. Users of OpenLDAP Software are encouraged to upgrade. > > Significant contributors are: > > Howard Chu (Symas Corp) > Quanah Gibson-Mount (Symas Corp) > Ondřej Kuzník (Symas Corp) > Ryan Tandy > > OpenLDAP 2.4.51 Release (2020/08/11) > Added slapo-ppolicy implement Netscape password policy controls (ITS#9279) > Fixed libldap retry loop in ldap_int_tls_connect (ITS#8650) > Fixed libldap to use getaddrinfo in ldap_pvt_get_fqdn (ITS#9287) > Fixed slapd to enforce singular existence of some overlays (ITS#9309) > Fixed slapd syncrepl to not delete non-replicated attrs (ITS#9227) > Fixed slapd syncrepl to correctly delete entries on resync (ITS#9282) > Fixed slapd syncrepl to use replace on single valued attrs (ITS#9294, ITS#9295) > Fixed slapd-perl dynamic config with threaded slapd (ITS#7573) > Fixed slapo-ppolicy to expose the ppolicy control (ITS#9285) > Fixed slapo-ppolicy race condition for pwdFailureTime (ITS#9302) > Fixed slapo-ppolicy so it can only exist once per DB (ITS#9309) > Fixed slapo-chain to check referral (ITS#9262) > Build Environment > Fix test064 so it no longer uses bashisms (ITS#9263) > Contrib > Fix default prefix value for pw-argon2, pw-pbkdf2 modules (ITS#9248) > slapo-allowed - Fix usage of unitialized variable (ITS#9308) > Documentation > ldap_parse_result(3) - Document ldap_parse_intermediate (ITS#9271) > > > MD5(openldap-2.4.51.tgz)= 0d2025896cf1c17af7304ecc57ec9531 > SHA1(openldap-2.4.51.tgz)= 4fe7f0e5766d0d9a5431871b581938c05b4eb873 > > LMDB 0.9.26 Release (2020/08/11) > ITS#9278 fix robust mutex cleanup for FreeBSD

2 1

Two new repos
by Ondřej Kuzník 12 Aug '20

12 Aug '20

This is an announcement that two new repositories have just been added on Gitlab: https://git.openldap.org/openldap/syncmonitor This is a project to support real-time monitoring of OpenLDAP's replication. It comes as a Python module using the asyncio library to provide a fully reactive interface. An asyncio wrapper around Michael's python-ldap0 is included for that reason. A sample terminal application is also provided to showcase what is possible. https://git.openldap.org/ondra/pldap (in personal namespace for now) The above mentioned asyncio wrapper is a bit of a break with how traditional python-ldap wrappers are used. This comes out of attempts to use and extend the existing Python LDAP modules to do what I needed them to do and discussions with Michael Ströder, maintainer of python-ldap0, how that might be achieved. In the end I've drafted a new module that has two goals: - explore a new API that can stay mostly uniform across plain Python and async code, where result and intermediate responses are extracted in a more natural way - move towards run-time wrapping of libldap so that the module is immediately usable in environments without the need to compile a native wrapper At some point, this code should either be extended to cover the scope that the other two wrappers (python-ldap and python-ldap0) provide or the approach should be adopted in either. It is my understanding that the OpenLDAP project might be interested in adopting either of the modules at some point (subject to that module adopting the OpenLDAP Public License). In view of the above, I've kept it in my personal namespace for now so as not to give any impression that this the official Python module to use for all things LDAP. At some point, these (just like the mod-harness module published last year) should be the building blocks for the test suite that I hope to build at some point. As such, there are many smaller tools of general utility bundled in there, especially in the syncmonitor repository. Should you find them useful, let's turn them into something more complete. Please review and come back with suggestions or, if you feel so inclined, patches. Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

RE25 make depend
by Michael Ströder 27 Jul '20

27 Jul '20

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? Ciao, Michael. cd back-shell && make -w depend make[3]: Entering directory '/home/michael/src/openldap-git/re25/openldap/servers/slapd/back-shell' make[3]: *** No rule to make target 'Makefile.in', needed by 'Makefile'. Stop. make[3]: Leaving directory '/home/michael/src/openldap-git/re25/openldap/servers/slapd/back-shell' make[2]: *** [Makefile:589: depend-local-srv] Error 1 make[2]: Leaving directory '/home/michael/src/openldap-git/re25/openldap/servers/slapd' make[1]: *** [Makefile:328: depend-common] Error 1 make[1]: Leaving directory '/home/michael/src/openldap-git/re25/openldap/servers' make: *** [Makefile:349: depend-common] Error 1

2 3

bugzilla spam?
by Michael Ströder 26 Jul '20

26 Jul '20

HI! To this seems to be spam: https://bugs.openldap.org/show_bug.cgi?id=6036#c5 Maybe also block the user fieldengineer59(a)yahoo.com? Ciao, Michael.

2 1

← Newer
1
2
3
4
5
6
7
8
...
142
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel