openldap-devel

openldap-devel@openldap.org

1416 discussions

RE: Beginner projects
by Lawrence, Andy 15 Jan '18

15 Jan '18

Does OpenLDAP contain an XML parser? Cheers, Andrew -----Original Message----- From: Howard Chu [mailto:hyc@symas.com] Sent: 14 January 2018 18:39 To: Lawrence, Andy (MO MM R&D UK IXL) Subject: Re: Beginner projects Lawrence, Andy wrote: > What is involved in the project "Add DSML capabilities to command line tools". Does this basically involve modifying ldapsearch so that it can produce the results in the DSML XML format and ldapmodify so it can take this format as input? Yes, sounds like it. By the way, please ask these questions on the -devel mailing list so that other people can chime in. > > Andrew > > -----Original Message----- > From: Howard Chu [mailto:hyc@symas.com] > Sent: 14 January 2018 10:52 > To: Lawrence, Andy (MO MM R&D UK IXL) > Subject: Re: Beginner projects > > Lawrence, Andy wrote: >> Hi Howard, >> >> I have been looking at the todo file. >> >> Re the small project "Recode linked-list structs to use <ldap_queue.h> macros", is ldaplist the struct being replaced by the new macros? > > Actually I would ignore that project. I'm not a fan of the ldap_queue.h macros; that was one of Kurt's ideas. >> >> Thanks, >> Andrew >> >> -----Original Message----- >> From: Howard Chu [mailto:hyc@symas.com] >> Sent: 09 January 2018 15:52 >> To: Lawrence, Andy (MO MM R&D UK IXL); openldap-devel(a)openldap.org >> Subject: Re: Beginner projects >> >> Lawrence, Andy wrote: >>> Hi, >> >> Hello, >>> >>> Me and one of my colleagues are interested in contributing to >>> OpenLDAP. Do you have any interesting projects that new comers such as myself could work on? >> >> There's a list in the source tree in doc/devel/todo. You can follow >> the pointers there to other possibilities. Pick whatever looks >> interesting to you and jump in ;) >>> >>> With best regards, >>> Dr Andrew Lawrence >>> >>> Siemens Rail Automation Holdings Limited MO MM R&D UK IXL >>> 17 Langley Park Way >>> Chippenham SN15 1GG, United Kingdom >>> mailto:andrew.lawrence@siemens.com >>> www.siemens.com/rail-automation >>> <http://www.siemens.com/rail-automation> >>> www.siemens.com/ingenuityforlife >>> <https://siemens.com/ingenuityforlife> >>> www.siemens.com/ingenuityforlife >>> Siemens Rail Automation Holdings Limited - registered office: >>> Faraday House, Sir William Siemens Square, Frimley Camberley GU16 8QD. >>> Registered No. 00016033 >>> >> >> > > -- -- 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

release 2.4.46?
by Michael Ströder 10 Jan '18

10 Jan '18

HI! BTW: Happy New Year. What are currently the plans for releasing 2.4.46? It's hanging in branch RE24 for quite while now. Ciao, Michael.

5 7

The Case for Learned Index Structures
by Howard Chu 11 Dec '17

11 Dec '17

This has been making some waves today on social media: https://www.arxiv-vanity.com/papers/1712.01208v1/ For now, it's only a novelty. Just like perfect hash functions. It assumes a static data set being used in read-only fashion, so it's unsuitable for a directory or database that serves ongoing modifications. It also assumes an entire data set fits in RAM, which is generally not true for database applications. In particular, the "fast" case of using highly parallel GPUs assumes everything fits inside GPU RAM, which is even more tightly constrained than server main memory. It's axiomatic that if you have advance knowledge about the shape/characteristics of a dataset, you can construct a dedicated mapping function for that dataset that is perfectly optimal, and outperforms any general-purpose mapping. That's kind of the point of general-purpose mappings - they are general. There are plenty of use cases where this fact may be useful. In LDAP and any database system ingesting data in realtime, these findings are irrelevant since advance knowledge of the dataset doesn't exist. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Approaches to ITS#8772
by Ondřej Kuzník 24 Nov '17

24 Nov '17

If we add an expectation that recursive and simple mutexes can be (un)locked in the same way, we can remove the function aliases without incurring the useless duplication. The only target that would be affected is mach cthreads since it allegedly doesn't support recursive mutexes natively. I don't think it exists as a viable target any more (for instance, there is hardly any documentation to be found about it), so I'm inclined to stop supporting it anymore. So the proposed way to deal with it would be as follows: 1. Remove mach cthreads support 2. Remove the type distinction between the mutex types and drop recursive mutex (un)locking functions 3. Update accesslog to use the above 4. Drop rmutex.c Any objections? -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

ACL checks and slapo-unique
by Michael Ströder 24 Nov '17

24 Nov '17

HI! What really strikes users is the lack of feedback in case a unique constraint or other constraint fails. Let's look at error messages of slapo-unique first. I'm experimenting with a pretty simple patch for returning the effective uniqueness filter in the diagnosticMessage. Example output with this patch (line wrapped): $ ldapadd -f test.ldif adding new entry "uid=foo,ou=Users,dc=example,dc=com" ldap_add: Constraint violation (19) additional info: non-unique attributes found with (|(uid=foo)(uidNumber=20000)) Even this minimum information is already somewhat useful. Of course it would be even more nice to get the list of non-unique attribute values returned. (I vaguely remember some idea for a "What Failed?" response control.) Now formerly one of the arguments against returning more information in the diagnosticMessage was that this would reveal content information to an attacker which is obtained by an internal search with a more privileged authz-ID. Yes, that's right. But this problem exists anyway because an attacker can probe values by adding entries with non-unique attributes and determine whether an attribute value exists or not by distinguishing the result code constraintViolation(19) vs. insufficientAccessRights(50). Even worse this even works in case the attacker does not have read access anywhere! This leads to the question whether some sort of access control or limit check should be applied in unique_search(). What do you think? Ciao, Michael.

2 2

Component Matching, ASN.1 compiler
by Howard Chu 14 Nov '17

14 Nov '17

The component matching feature has been pretty much broken and unmaintained for quite a while. Part of the problem is the existing code uses the eSNACC ASN.1 compiler, which is total abandonware and has been for a long time. It was pointed out to me that the Heimdal project includes a full ASN.1 compiler. Would someone be willing to investigate using theirs to replace eSNACC? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: slapd.backends(5)
by Howard Chu 07 Nov '17

07 Nov '17

Quanah Gibson-Mount wrote: > This man page currently lists hdb as the recommended backend (for both 2.4 and > 2.5/HEAD). > > I think at this point, back-mdb is the recommended backend for 2.4 (and > obviously is for 2.5/HEAD). Any objections to me updating the manpage for > 2.4.46 to reflect this? Go ahead. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

slapd.backends(5)
by Quanah Gibson-Mount 07 Nov '17

07 Nov '17

This man page currently lists hdb as the recommended backend (for both 2.4 and 2.5/HEAD). I think at this point, back-mdb is the recommended backend for 2.4 (and obviously is for 2.5/HEAD). Any objections to me updating the manpage for 2.4.46 to reflect this? --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Persistent sessionlog
by Howard Chu 26 Oct '17

26 Oct '17

Ondřej Kuzník wrote: > ITS#8486 suggests we use a more efficient structure to maintain the > sessionlog in. If we're messing with sessionlog already, we might as > well see if we can address another issue - it is always empty on slapd > startup leading to unnecessary full refreshes happening. > > slapo-accesslog has most of the data we need to support that and is > already sorted in CSN order (much like sessionlog). > > AFAIK, we can't use the accesslog database directly as the database as > we can't efficiently search on a single serverID to get the serverID > set and the oldest CSN for each. We could tweak the overlay to always maintain these in the parent entry (auditContainer). Currently the logpurge always sets the container's entryCSN to the oldest remaining CSN. > There are a few tasks that need to be done in order to achieve this: > - configure syncprov with a suffix that contains the slapo-accesslog > style logs for our DB > - change struct sessionlog to use a more efficient structure that can be > iterated over from any point (only tavl is available at the moment) We've talked about this before, an in-memory B+tree would be better for all of our AVL/TAVL uses. > - on startup: > - iterate through the *last* N entries (filtering on successful write > ops that affect our suffix) and build slog_entry for each of those > - for each entry, insert a new slog_entry and update sl_mincsn > - add a control to hint the database that we require the database to > iterate from the end backward (back-[mhb]db can support this) > - update accesslog to log entryUUID for the entry that has just been > written > - update the test suite to exercise the new failure conditions > > There are some caveats to this still: > - if we aren't guaranteed to receive the accesslog entries in reverse > CSN order, the resulting sessionlog would be quite unsafe to use, we > have to try and detect this and start with an empty sessionlog > instead, resetting sl_mincsn set to match the database contextCSN > - We might find an accesslog entry we can't use (modification that doesn't > have enough information), we should still be able to use whatever we > built until then, but can't continue > -- -- 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 2

ITS#6097 MMR problems with deletes
by Howard Chu 24 Oct '17

24 Oct '17

One of the RedHat talks at LDAPCon noted that OpenLDAP can get inconsistent when conflicting Adds and Deletes are issued. We've had this issue outstanding in ITS since 2009, it's probably time to address it. http://www.openldap.org/its/index.cgi/Development?id=6097 The strategy I outlined in that ITS may not be the best one, we need to evaluate if that approach still makes sense. This also touches on a discussion of ITS#7052 back in 2012. http://www.openldap.org/lists/openldap-devel/201202/msg00010.html We committed a couple changes to fix this, but one of them subsequently had to be reverted. One of the points raised in there was to fully serialize all writes so they always complete in CSN order, and always propagate in CSN order. I believe this is also the approach Leo Yuriev took in ReOpenLDAP. We should look into doing the same. In practice we've already got serialization occurring in accesslog and now in back-mdb too, so we're mostly there already. The syncrepl consumer also needs to be fully serialized, to simplify conflict resolution when conflicting writes are being received from multiple masters at once. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel