October 2008 - openldap-devel

by Rein Tollevik

I've been trying to figure out why syncrepl used on a backend that is subordinate to a glue database with the syncprov overlay should save the contextCSN in the suffix of the glue database rather than the suffix of the backend where syncrepl is used. But all I come up with are reasons why this should not be the case. So, unless anyone can enlighten me as to what I'm missing, I suggest that this be changed. The problem with the current design is that it makes it impossible to reliably replicate more than one subordinate db from the same remote server, as there are now race conditions where one of the subordinate backends could save an updated contextCSN value that is picked up by the other before it has finished its synchronization. An example of a configuration where more than one subordinate db replicated from the same server might be necessary is the central master described in my previous posting in http://www.openldap.org/lists/openldap-devel/200806/msg00041.html My idea as to how this race condition could be verified was to add enough entries to one of the backends (while the consumer was stopped) to make it possible to restart the consumer after the first backend had saved the updated contextCSN but before the second has finished its synchronization. But I was able to produce it by simply add or delete of an entry in one of the backends before starting the consumer. Far to often was the backend without any changes able to pick up and save the updated contextCSN from the producer before syncrepl on the second backend fetched its initial value. I.e it started with an updated contextCSN and didn't receive the changes that had taken place on the producer. If syncrepl stored the values in the suffix of their own database then they wouldn't interfere with each other like this. There is a similar problem in syncprov, as it must use the lowest contextCSN value (with a given sid) saved by the syncrepl backends configured within the subtree where syncprov is used. But to do that it also needs to distinguish the contextCSN values of each syncrepl backend, which it can't do when they all save them in the glue suffix. This also implies that syncprov must ignore contextCSN updates from syncrepl until all syncrepl backends has saved a value, and that syncprov on the provider must send newCookie sync info messages when it updates its contextCSN value when the changed entry isn't being replicated to a consumer. I.e as outlined in the message referred to above. Neither of these changes should interfere with ordinary multi-master configurations where syncrepl and syncprov are both use on the same (glue) database. I'll volunteer to implement and test the necessary changes if this is the right solution. But to know whether my analysis is correct or not I need feedback. So, comments please? -- Rein Tollevik Basefarm AS

13 years, 6 months

2
6
0 / 0

dITStructureRules/nameForms in subschema subentry for informational purpose

by Michael Ströder

HI! Discussed this very briefly with Howard at LDAPcon 2007 based on an idea of Steve: Support for dITStructureRules and nameForms is still in OpenLDAP's TODO. In the meanwhile slapd could accept definitions for both in slapd.conf and simply pass them on to a schema-aware LDAP client for informational purpose without enforcing them. Same function like rootDSE <file> in slapd.conf. Opinions? Ciao, Michael. -- Michael Ströder E-Mail: michael(a)stroeder.com http://www.stroeder.com

14 years, 2 months

2
4
0 / 0

IDL bit vectors

by Howard Chu

Seems like I keep poking at this idea again every couple years. If we use a <base,vector> we can cover a much wider range without losing any precision. For a 32 bit machine, 32 bits per word would cover 5 bits worth of entry IDs. So 27 bits would comprise the base, and the next 32 bits would represent up to 32 entry IDs. To avoid wasting those 5 unneeded bits in the base, we could use them as a run-length counter and use multiple vectors per base. But it might be better to slide things over and use just a 24 bit base, and use the bottom 8 bits of the word as a bitmask to represent which following vectors are present. E.g. ......01 means 1 vector follows, representing base+ 0-31. ......02 means 1 vector follows, representing base+32-63. ......05 means 2 vectors follow, base+0-31 then base+64-95. That allows us to represent up to 256 entryIDs in only 288 bits (instead of the 16384 bits we currently need). That would allow us to track about 1.86M entryIDs in the same space we currently use to track only 64K entryIDs. It seems we would still need some kind of range representation to handle IDLs with more than 1.86M entries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 6 months

3
5
0 / 0

Re: commit: ldap/servers/slapd/back-ldif ldif.c

by Hallvard B Furuseth

hyc(a)OpenLDAP.org writes: > ldif.c 1.86 -> 1.87 > ITS#5774 blind fix for Windows, please test Another question - does strerror(errno) get the right error message after MoveFileEx()? The errno == ENOENT test can go away, we need to pre-check that the directory exists anyway. But the debug message currently printed by the caller should report what is wrong. The Microsoft doc shows a horrible call to FormatMessage() at <http://msdn.microsoft.com/en-us/library/ms679351(VS.85).aspx> except that produces a wide string, not a plain string. -- Hallvard

14 years, 7 months

1
0
0 / 0

Re: commit: ldap/servers/slapd limits.c

by Hallvard B Furuseth

hallvard(a)OpenLDAP.org writes: > limits.c 1.83 -> 1.84 > More ITS#5734: Handle empty o_req_ndn. (...) This gets somewhat inconsistent: dn.this.<subtree or exact>="" now matches target DN "". However, to preserve backwards compatibility, dn.<subtree or exact>="" does not match anonymous binding. OTOH, limits dn.<anything>=* becomes limits *, again preserving backwards compatibility. However dn.<onelevel or children>=* should not match empty target DN/anonymous connections. Should we leave it as it is? Or change the old behavior? And if so, does an anonymous connection have a DN so it should match "", or not? Or we could make them errors to avoid admins seeing unexpected behavior for a config which slapd accepts. These cases seem fairly useless, but could arise from something like an auto-generated config files when the admin inputs suffix "". -- Hallvard

14 years, 7 months

2
1
0 / 0

Re: commit: ldap/include portable.hin ldap.h

by Howard Chu

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/include > > Modified Files: > portable.hin 1.44 -> 1.45 > ldap.h 1.337 -> 1.338 > > Log Message: > add support for (experimental) dereference control (ITS#5768); need to re-run autoconf (and autoheader?) portable.hin is generated by autoheader, so you ordinarily should leave that commit until after autoheader is rerun. No big deal... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

14 years, 7 months

2
1
0 / 0

Dereference Control (Was: How to implement Extended DNs for Samba4?)

by Pierangelo Masarati

Howard, this is where I got so far with the specification (and the code :) /* * request: * * controlValue ::= SEQUENCE OF DerefSpec * * DerefSpec ::= SEQUENCE { * derefAttr AttributeDescription, * attributes AttributeList } * * AttributeList ::= SEQUENCE OF attr AttributeDescription * * * response: * * controlValue ::= SEQUENCE OF DerefRes * * DerefRes ::= SEQUENCE { * spec DerefSpec, * vals DerefVals } * * DerefVals ::= SEQUENCE OF DerefVal * * DerefVal ::= SEQUENCE { * derefSpecVal AttributeValue, * attrSets AttrSets } * * AttrSets ::= SEQUENCE of attrSet AttributeValues * * AttributeValues ::= SET OF value AttributeValue * * * example request: * * { { member, { GUID, SID } }, { memberOf, { GUID, SID } } } * * example response: * * { { { memberOf, { GUID, SID } }, * { { "cn=abartlet,cn=users,dc=abartlet,dc=net", * { { "0bc11d00-e431-40a0-8767-344a320142fa" }, * { "S-1-2-3-2345" } } }, * { "cn=ando,cn=users,dc=sys-net,dc=it", * { { "0bc11d00-e431-40a0-8767-344a320142fb" }, * { "S-1-2-3-2346" } } } } } } */ I designed the response this way, because it'd allow to make it as compact as possible while allowing for multiple as well as missing attribute values in each attrSet. However I'm facing two issues, which I can't solve directly since I don't have X.690 handy right now: - does BER allow to have an empty set/sequence? Apparently, I'm unable to set an empty set using ber_printf("[]"). - does it make sense to have a structured response like this, where the attribute types are listed first, and aggregate values follow, so that the order of the value sets (including empty sets, if allowed) matches the order of the attributes? I mean: { member, { cn, uid, drink } } is supposed to match { "cn=Ando,dc=sys-net,dc=it", { [ "Ando", "Pierangelo Masarati" ], [ "ando" ], [] } } such that set #0 ([ "Ando", "Pierangelo Masarati" ]) refers to attr #0 (cn), set #1 ([ "ando" ]) refers to attr #1 (uid), and set #2 ([]) refers to attr #2 (drink). In fact, one could argue that the order in attrSets needs not necessarily be the same of the attributes in spec. This would require to use an alternative definition like /* * response: * * controlValue ::= SEQUENCE OF DerefRes * * DerefRes ::= SEQUENCE { * derefAttrVal DerefAttrVal, * attrsVals SEQUENCE OF attrVals DerefAttrsVals } * * DerefAttrVal ::= SEQUENCE { * attr AttributeDescription, * val AttributeValue } * * DerefAttrVals ::= SEQUENCE { * attr AttributeDescription, * vals SET OF val AttributeValue } */ which implies a repetition of all the attribute descriptions for each derefAttrVal. Comments? 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 Fax: +39 0382 476497 Email: ando(a)sys-net.it -----------------------------------

14 years, 7 months

3
5
0 / 0

Re: Dereference Control

by Raphaël Ouazana-Sustowski

Hi, Le Mer 22 octobre 2008 16:36, Pierangelo Masarati a écrit : > * 2.1 Example > * > * 2.1.1 Request > * > * { { member, { GUID, SID } }, { memberOf, { GUID, SID } } } > * > * 2.1.2 Response > * > * { { memberOf, "cn=abartlet,cn=users,dc=abartlet,dc=net", > * { GUID, [ "0bc11d00-e431-40a0-8767-344a320142fa" ], > * SID, [ "S-1-2-3-2345" ] } }, > * { memberOf, "cn=ando,cn=users,dc=sys-net,dc=it", > * { GUID, [ "0bc11d00-e431-40a0-8767-344a320142fb" ], > * SID, [ "S-1-2-3-2346" ] } } } > * > * 2.2 Example > * > * 2.2.1 Request > * > * { { member, { cn, uid, drink } } } > * > * 2.2.2 Response > * > * { { member, "cn=ando,cn=users,dc=sys-net,dc=it", > * { cn, [ "ando", "Pierangelo Masarati" ], > * uid, [ "ando" ] } } } Sorry if I'm completly misunderstanding, but would not it be more simple and user friendly if the attributes were directly returned to the user, like do many overlays ? Ideally this could be : member/cn: ando member/cn: Pierangelo Masarati member/uid: ando But to be more LDAP-friendly, we could see something like: cn;member: ando cn;member: Pierangelo Masarati uid;member: ando Or maybe I'm totally missing a point :) Regards, Raphael Ouazana.

14 years, 7 months

2
1
0 / 0

Re: commit: ldap/servers/slapd/back-null null.c

by Hallvard B Furuseth

ando(a)OpenLDAP.org writes: > null.c 1.25 -> 1.26 > declare support for read controls (ITS#5757) Hold on. LDAP_CONTROL_PAGEDRESULTS requires to be sent LDAP_CONTROL_PAGEDRESULTS in the search response. Does the frontend do that? back-bdb does it "by hand". Clients may use LDAP_CONTROL_ASSERT to check something they want to know, not just to ensure they don't update entries with unexpected contents. I suppose we could evaluate the filter against an empty entry with just the DN filled in - as if the rest were hidden by access controls. Though since back-null is a liar - it cannot present a consistent view of whether data are present or not - it may be better to be conservative and always return Assertion Failed. I don't know the requirements of the other controls/extensions. -- Hallvard

14 years, 7 months

2
1
0 / 0

Managing multiple regex matches

by manu＠netbsd.org

Let us imagine an ACL like this: access to dn.regex="^uid=.*,ou=(.*)" attrs=foo val.regex="^(.*)$/" ... We would like to use $1 (ou's value) and $2 (foo's value) in the <who> field. For now this is not possible, because slap_access_allowed() collect a single set of regmatch_t. If the <what> field of an ACL has multiple regex matches, the last one only will be retained. I suggest the following change: 1) In slap_access_allowed(), we would keep track of multiple set of regmatch_t. matches would become something such as: typedef struct AclRegexMatches { regmatch_t dn[MAXREMATCHES]; regmatch_t val[MAXREMATCHES]; } AclRegexMatches; In slap_acl_get(), the two regexec() calls would be done with matches.dn or matches.val, depending on the situation. 2) In acl_string_exapand(), we would replace $1, $2, $3 by values from matches.dn, therefore providing backward compatibility. And we would replace ${v1}, ${v2}, ${v3}... by values from matches.val and ${d1}, ${d2}, ${d3}... by values from matches.dn There is a problem with my proposal, on dynaic ACL. We cannot provide them values from attribute value without changing the API. I suggest we stick with the current API for now and improve that later if needed. Opinions? Did I miss something? -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

14 years, 7 months

2
2
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel October 2008