openldap-devel

openldap-devel@openldap.org

1416 discussions

ldap0 does not work with RE24
by Michael Ströder 03 Jan '20

03 Jan '20

HI! It seems I'm experiencing a regression when running tests of python-ldap0 with current RE24 which does not fail with 2.4.48: test016_cancel (__main__.Test00_LDAPObject) ... munmap_chunk(): invalid pointer ERROR There was this change for ITS#9124. So I guess it's causing this regression. Could someone look into this? Ciao, Michael.

2 5

dynlist enhancements, ITS#9121
by Howard Chu 18 Dec '19

18 Dec '19

There's some ambiguities that still need to be resolved, around the memberOf functionality. The dynlist code only adds memberOf values for dynamic groups. It doesn't do anything about static group memberships. This implies that you still need to use the memberOf overlay too, if you want to also support static groups. 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? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

4 10

Re: 2.4 commit review
by Hugh McMaster 24 Nov '19

24 Nov '19

Hi Quanah, On Sat, 2 Nov 2019 at 03:32, Quanah Gibson-Mount wrote: > > A few commits stacking up, so would like to review them for inclusion in an > eventual 2.4.49. 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. Thanks, Hugh [1] http://www.openldap.org/lists/openldap-devel/201904/msg00012.html

3 9

Session tracking control
by Howard Chu 05 Nov '19

05 Nov '19

It looks like we currently parse this control, but only to allow logging its contents, and nothing more. Seems like it would be useful to carry the parsed info along with the o_authz struct, and make it usable in the ACL engine. This would allow setting ACLs that can distinguish between different applications acting on behalf of a given user (or service). Any security downside to this? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

2 1

Curious "missing parent" check in mdb_idscopes(), how may this occur?
by Konstantin Andreev 30 Oct '19

30 Oct '19

Hi, I am contemplating the mdb search mechanics, and puzzled by "missing parent" check in mdb_idscopes(): | /* If we didn't advance, some parent is missing */ | if ( id == prev ) | return MDB_NOTFOUND; where "id" and "prev" are parent and child ids that come from the same "UP" ( child -> parent ) record of "dn2id" table. Here is a source code approximation for easier reading: | MDB_val key = { sizeof(ID), & id }, data; | mdb_cursor_get( "dn2id", key, data, MDB_SET ); | // reading last sizeof(ID) bytes of data.mv_data | ID prev = *(ID *)(data.mv_data + data.mv_size - sizeof(ID)); IIUC, there is no records in "dn2id" where parent and child ids are the same. There is no by construction, except "super-root", where both ids are zeros, but zero id doesn't follow this execution path. So, how may [id == prev] occur? Could you, please, explain? The check came from 5a08b661 and 437f21b commits (ITS#7705,#7800 fix ...), I have read both, but they haven't helped either. Regard, Konstantin.

2 2

Please review 2.5 plan (non-development items)
by Ondřej Kuzník 24 Sep '19

24 Sep '19

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. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

6 7

STRERROR(e) vs AC_STRERROR_R(e,b,l)
by Ryan Tandy 16 Sep '19

16 Sep '19

I'm working on adding debug logging for GnuTLS errors. I'd like to add a strerror() inside tlsg_getfile() as part of this. First question: I found STRERROR(e) and AC_STRERROR_R(e,b,l). It looks like AC_STRERROR_R should be preferred for new code. Is that correct? Second question: I noticed that STRERROR(e) triggers deprecation warnings on my system: .../libraries/libldap/os-ip.c:248: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead .../libraries/libldap/os-ip.c:248: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead Is replacing occurrences of STRERROR with AC_STRERROR_R a worthwhile cleanup? (cf. 62da0b673, ba749eb79, bfd09a16a) Are there cases where AC_STRERROR_R would be inappropriate? (where the non-threadsafe strerror() fallback would be totally unacceptable?) Thanks.

1 0

git://git.openldap.org down?
by Michael Ströder 21 Aug '19

21 Aug '19

HI! It seems that git://git.openldap.org is not reachable since yesterday. Ciao, Michael.

2 1

Test suite overhaul
by Ondřej Kuzník 25 Jul '19

25 Jul '19

This is a follow-up to my email to -technical, this time more into the future of OpenLDAP's test suite and tools we could build to make managing OpenLDAP deployments much easier for everyone. Historically, there has been a decent coverage in the test suite and that's what's being run before anyone pushes, but it's not been enough to capture some of the issues. It also takes ages to finish, and is very limited in what can be tested, mostly because we can only rely on POSIX shell and command line tools. That means a lot of boilerplate (and since shell functions are not available, that boilerplate has to be copy-pasted everywhere) and we can never actively do two things at the same time, let alone submit several operations over the same connection. There is no way we can get notified when things happen (servers have started up, all members think they're in sync, ...) so we have to rely on polling and manual delays which slows it down significantly, or introduces false positives on hosts where these delays are too short. The tests can't be run in parallel either, not from the same build environment. None of the above can be resolved without a major overhaul. I've been thinking about all of that for a while now and want to get started improving the situation. If we switched to an actual programming language to write the tests in, something like Python 3, Golang or Rust, we could build a support library including a harness to manage slapd through, tools to configure and interact with the server in a high level way (continue as soon as the server has started up, or once an MMR environment settles, ...). All of this should then make it much easier to write new tests and maintain and understand existing ones. I have already started the part that people without intimate experience with OpenLDAP internals would struggle with - a loadable module that knows how to connect back to the program that started it and informs it of the port it's listening on and when it has become ready to process traffic. That code is here: https://github.com/mistotebe/openldap/tree/mod_harness To see it in action, just run `nc -l -p <port>`, then start slapd with `-h ldap://localhost:0` (yes, an explicit zero) and make sure this is in slapd's configuration: ``` moduleload path/to/mod_harness backend harness host localhost port <your port above> ``` I would appreciate if people joined to help define the testing infrastructure. My preference is Python 3 as the host language, but anything that can express concurrency well and has a good LDAP client implementation should be acceptable if there are enough volunteers. We will also have to look into defining the protocol the test suite would use to communicate with the slapd module as the existing plain text protocol is just a placeholder for easy experimentation. This would do well for testing in the 2.5 lifecycle. In the future, I want to extend this to support fine grained testing where the inner workings of slapd are much more transparent to the test code. Eventually going as far as making it possible to unit-test any OpenLDAP code. The first step in that direction is probably going to be learning how to host a C compiler within the loadable module so we can compile, link and inject code and callbacks into slapd as and when needed to meld the test suite with the server much better. Clang (the LLVM C/C++ compiler) seems to be capable of this. All of the above will introduce new helper APIs, so in the end it will overlap with efforts to develop new user-facing tools to configure, monitor and manage OpenLDAP deployments: - user friendly tools to manage cn=config - high-level tools to set up and manage common replication topologies - tools to monitor replication progress - many more as we progress with making OpenLDAP user friendly... (Please don't turn this thread into another flame war on slapd.conf vs. cn=config, start another one if you really can't resist.) Again, thanks for being brave and getting this far, let us know what you think. This is mostly vaporware yet, giving everyone a great opportunity to shape the project and leave their mark - remember that without your help, it will take a long while before it's ready! Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

2 2

libldap cyrus.c and windows (RE24 release candidate)
by Quanah Gibson-Mount 22 Jul '19

22 Jul '19

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 <limits.h> void main() { char my_hostname[HOST_NAME_MAX + 1]; } In cyrus.c, we have: #ifdef HAVE_CYRUS_SASL ... #ifdef HAVE_LIMITS_H #include <limits.h> #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>

2 3

← Newer
1
...
5
6
7
8
9
10
11
...
142
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel