openldap-devel August 2007

openldap-devel@openldap.org

21 participants
48 discussions

Re: commit: ldap/servers/slapd schema_init.c slapadd.c syncrepl.c
by Pierangelo Masarati 26 Aug '07

26 Aug '07

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > schema_init.c 1.407 -> 1.408 > slapadd.c 1.44 -> 1.45 > syncrepl.c 1.345 -> 1.346 > > Log Message: > add support for CSNSIDMatch; use it to set contextCSN as appropriate when slapadd'ing -w OK, I screwed, something similar was sort of already present (but inconsistent) in slapd/ldapsync.c. In fact, the SID portion of a CSN is 3-hex digits (that's how it's printed) but slap_parse_csn_sid() reads it as strtoul(,,10) ! and compares the value with SLAP_SYNC_SID_MAX, which is 4095 !!!. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

A. Changes Since Previous Release
by Gavin Henry 26 Aug '07

26 Aug '07

Dear all, I think this is now almost complete (at least until 2.4 final): http://suretec.org/our_docs/index.html http://suretec.org/our_docs/appendix-changes.html The "New Features and Enhancements in 2.4" section is mainly Howard, Andos and Quanahs words re-worked. I hope you approve. Feedback welcome. You might want to link to this section (when released on openldap.org) when announcing 2.4.5 beta and also mention that the docs are a work in progress, but will be complete for the final release of 2.4 Thanks, Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

6 12

test030 failure in HEAD
by Howard Chu 26 Aug '07

26 Aug '07

The test is failing for back-ldap: Changing password to database "o=Example,c=US"... Passwd ExOp failed (1)! >>>>> ../../head/tests/scripts/test030-relay failed (exit 1) conn=4 op=7 do_extended ber_scanf fmt ({m) ber: ber_scanf fmt (m) ber: conn=4 op=7 EXT oid=1.3.6.1.4.1.4203.1.11.1 do_extended: oid=1.3.6.1.4.1.4203.1.11.1 conn=4 op=7 PASSMOD send_ldap_extended: err=8 oid= len=0 send_ldap_response: msgid=12 tag=120 err=8 * msgid 12, origid 12, status InProgress ber_flush2: 59 bytes to sd 15 outstanding referrals 0, parent count 0 ld 0xcfa440 request count 1 (abandoned 0) ** ld 0xcfa440 Response Queue: Empty ld 0xcfa440 response count 0 conn=4 op=7 RESULT oid= err=8 text=only authenticated users may change passwords ldap_chkResponseList ld 0xcfa440 msgid 12 all 1 ldap_chkResponseList returns ld 0xcfa440 NULL ldap_int_select -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 1

dynamic group caching (was: slapo-dynlist search member=value search?)
by Pierangelo Masarati 25 Aug '07

25 Aug '07

[moved to openldap-devel from openldap-software for discussion] Aleksander Adamowski wrote: > I don't claim it is easy. In fact, I know this problem is quite hard - > that's why I was hesitant to try out dynlist since I didn't expect it > would work this way. The documentation mislead me to think it works, > however. > > OTOH, this functionality would be so useful, that I might give it a shot. > But I didn't work with OpenLDAP codebase yet, so obviously I'll need > some guidance. > > A couple of initial questions spring to my mind: > > 1. I could use the backends' already present indexing mechanism for > doing the hard work, but I need dynlist to be able order the > backend to update indexes on member attribute for specific dynamic > group objects, which could have their member lists changed. Is it > possible with the current overlays/backends architecture? > * Example scenario: > * dynlist detects that a user has his DN changed from > uid=phil,l=Brighton,o=MyOrg to uid=phil,l=London,o=MyOrg > * dynlist determines which dynamic lists can potentially have > him as a member: looks for a logical conjunction of two > conditions: 1) the base DN of a memberURL is a prefix to > either the old DN or new DN of the user, 2) any attribute in > the LDAP filter of that memberURL is present in either the > new or old version of the entry (or both). Such a dynamic > list could either have the entry as a member or could gain > this entry if it didn't have it previously so its member > list needs to be reindexed. > 2. dynlist overlay needs to keep track of base DNs and filter > atrributes of all memberURLs present the backend database in two > (or more) dictionary-type data structures. So it either needs to > store data about memberURL's permanently (not possible for > overlays?), or scan the whole backend's database at each startup > (slow). Is it possible to implement the first variant - permanent > data storage for dynlist overlay? I understand that overlays > cannot assume that they are used by a specific backend (e.g. bdb) > and cannot order the backend to store arbitrary data, AFAIK. Am I > right? > 3. A significant speed optimization could be made if the overlay > could affect backend's indexing operation more directly. I mean, > when changing a potential member entry, for a given potential > dynamic list affected, either only one entry in its member index > is affected (added, removed or DN change), or the index is left > unchanged. If dynlist could simply test if the old and new verions > of the entry matched the memberURL's filter (possibly a "scope > one" search, but for the new verision it should be on a "virtual", > non-existing-yet entry), then it could determine immediately which > kind of low-level index operation needs to be performed - we have > three possible cases that would only affect at most one index > leaf. So the questions are: is it possible for the dynlist overlay > to test filters on the old and new versions of an entry for the > current transaction? Is it possible for the overlay to affect the > backend's indexing operation on single index entry level and would > it give a speed gain? > > > Ad 1. - I'm think that dynlist would have to keep track memberURLs in 2 > dictionaries: one that maps base DN's from memberURL's to objects that > have those memberURLs, second that maps attributes mentioned in filters > to to objects that have those memberURLs. The first dictionary should be > able to effectively search using a reverse-postfix-string match, that is > "find all the keys which are prefixes of the given DN (the predecessors > in LDAP hierarchy)". > > Then to determine whether the memberURL is possibly affected, we have to > determine the intersection of sets that result from lookup in both > dictionaries - which could be implemented quite effectively if the > dictionaries would keep the values ordered. > > Now the answers to Howard Chu: > > Howard Chu wrote: >> If you make the data permanent, then you may as well just use static >> groups. > The difference is, static groups are human-managed (or require a special > application to be written to maintain their definitions algoritmically > and refresh them on a regular basis). > > The data would just be helper data that would let dynlist optimize its > work for speed by eliminating unneeded memberURL tests be deciding which > memberURLs could potentially be affected by a ADD/MOD/MODRDN/DEL operation. > >> Tracking "any memberURL in the directory" is either memory intensive >> and/or CPU intensive. There's no good way to do this without >> sacrificing one or both. > Well, the server administrator should find the information on the speed > sacrifice and decide whether the feature is viable or not. > > I think that my scheme is not so memory intensive (especially if > implemented with an on-disk dictionary structure) and it's CPU intensive > only for worst-case scenarios (memberURL's anchored in directory's base > DN and filtering on objectclass attribute) and only for direcotry update > operations, which are rare for LDAP directories by definition (quoting > IBM's "Understanding LDAP": "One special characteristic of directories > is that they are accessed (read or searched) much more often than they > are updated (written)"). > There would be a warning in the documentation advising to avoid ussage > of too generic LDAP attributes in memberURL filters (e.g. objectClass, > cn) and too short base DNs. > Probably a simpler approach would be to have a different type of dynamic group that's rather a "cachedGroup"; a background thread could take care of keeping it updated by expanding dynamic members into static (and indexed), while direct modifications could be trapped and handled explicitly (e.g. if a memberURL is added/removed). The drawback would be that other updates to the database (like another user entering the scope of a memberURL search) are not immediately reflected in group membership. Static members should also be treated specially; this could be perhaps be done by subtyping the dynamically cached members from the static ones, so that regular searches for the static member attribute find both, but caching operations only deal with the dynamically generated ones. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 1

delta-syncrepl and Multimaster
by Gavin Henry 25 Aug '07

25 Aug '07

Dear all, Just finishing changes section and would like to ask if the delta-syncrepl code has been updated to support multimaster usage? Thanks. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

3 4

Ignoring no-ops changes?
by manu＠netbsd.org 25 Aug '07

25 Aug '07

Hi If I send a MOD operation that will replace an attribute by its same previous values, the directory content is not affected. Despite this, a change is recoreded by slapo-accesslog, slapo-auditlog, and various operational attributes. Is there a way to cause no-ops like this to be just ignored? Fixing the client software is not always an available option... -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

2 1

cn=monitor and timing?
by Quanah Gibson-Mount 25 Aug '07

25 Aug '07

I was wondering if it would be possible in cn=monitor to track the average time it takes slapd to respond to different operations, like ADD, MOD, SEARCH, DELETE. This could provide some useful information on server performance (although full-DB searches would of course add a bit of time to averages. :P ). Maybe something like top does -- Track the 1, 5, and 15 minute averages or something. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Buildbot for our Build Farm (when we get it)
by Gavin Henry 24 Aug '07

24 Aug '07

Hi All, Might be worth a look when we get the resources for the central server: http://buildbot.net/trac Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

1 0

Re: commit: ldap/servers/slapd/overlays dynlist.c
by Pierangelo Masarati 24 Aug '07

24 Aug '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > Modified Files: > dynlist.c 1.35 -> 1.36 > > Log Message: > Add dgIdentity support test044 is now failing in HEAD... I'm investigating. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 2

(Dumb?) X-ORDERED 'VALUES' question
by Pierangelo Masarati 24 Aug '07

24 Aug '07

I'm implementing the Control syntax in draft-chu-ldap-logschema, which is used for the reqControls and reqRespControls as X-ORDERED 'VALUES', and I'm having a little bit of trouble in understanding how I should encode values. Right now, I'm putting the DER encoded controls in the pretty values, and the control OID in the normalized values as per the objectIdentifierFirstComponentMatch equality matching rule. However, it's not clear whether I should put the ordering prefix in either value. If I do, matching fails because test_filter() ignores the fact that an attribute may be ordered; in fact, it uses value_match() instead of ordered_value_match(). I suspect this is a bug, but I might be missing something __really__ obvious... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel August 2007