openldap-devel

openldap-devel@openldap.org

1418 discussions

syncrepl
by Howard Chu 07 Feb '07

07 Feb '07

ITS#4618, 4623, 4626 and 4703 all basically have to do with trying to use multiple replication contexts with a single provider. This is a behavior that the 2.3 syncprov implementation just wasn't designed for; it was meant to handle only a single context. Looking at the ideas in 2.2's syncrepl, it might have gone in the direction of solving these problems if it weren't weighed down by so many insurmountable design and implementation flaws. 2.2 probably tried to do too much too soon, and got waylaid by the devil in the details. At this point, this solution for multiple contexts presents itself: 1) We assign distinct searchbases to each context. 2) Every distinct source of changes must have its own unique rid. E.g., if a database is a provider for a context, it must have an rid. Every consumer within its namingContext must have their own rid's just as before. (The new requirement here is assigning rid's to providers that are masters of their data.) 3) Currently the provider hands a consumer a cookie consisting of the rid that the consumer supplied, plus a single contextCSN from the provider. This single contextCSN is inadequate for accurately capturing all of the changes that may come from multiple sources in a namingContext. Instead, the provider will send out a cookie consisting of multiple rid,CSN pairs - one for every rid of the provider's that resides in the consumer's search space. This is the only reliable way to make sure that all changes are tracked and propagated. This says that in general, rids should not need to be configured on consumers - they should be dictated solely by the providers. It may be a good idea to allow them to be configured on consumers as an override, but for now that seems unimportant. So: 1) the provider must have its own unique rid configured 2) the consumer's rid is optional 3) the provider must be told about all of the consumers living under it 4) the provider must aggregate all of the consumer cookies under it with its own context info when generating a cookie for its own consumers Currently slapd treats an entire database as read-only when it has a consumer configured on it. This raises the question of how to allow multiple consumers in a single context - should we allow multiple consumers per DB, as 2.2 tried (and failed) to do, or should we continue with the current approach of one consumer per DB, and use glue to collect multiple consumers under one roof? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

3 9

slapo-dynlist desgin question(s)
by Quanah Gibson-Mount 07 Feb '07

07 Feb '07

Stanford is looking at implementing groups into our LDAP servers, and in particular, looking at using slapo-dynlist. However, it does not behave as I expected it to. Basically, it uses the credentials of whomever bound to determine the membership list. This means I would have to give access to a privileged attribute to those who wished to use groups, which is exactly what I'm trying to avoid. What I wanted to do, was specifically control the access to the group objects themselves. If an entity has access to the group object, they would then be able to see all current members of the group. I believe this would mean adding functionality to slapo-dynlist to where it uses the rootdn to perform the internal search instead of the credentials. Would it be possible to have this sort of addition? --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

3 34

Re: (ITS#4832) Segmentation fault with test049-sync-config
by Gavin Henry 06 Feb '07

06 Feb '07

> Is it possible to just run this test? I can't seem to figure out how, > without > doing a "make test" again. Figured it out: cd tests; ./scripts/defines.sh ./run test049-sync-config Thanks.

2 1

Re: commit: ldap/libraries/libldap result.c
by Pierangelo Masarati 06 Feb '07

06 Feb '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > result.c 1.149 -> 1.150 > > Log Message: > Fairly sure this is what the TIMEOUT option should always have been for Not strictly related, but does it make sense to have a malloc for a struct timeval in global/per handler data? Wouldn't it be any better to use tv_sec = -1 to indicate no timeout? We should be able to change that, since the struct is opaque... p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. 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 7

Re: commit: ldap/tests/scripts test050-syncrepl-multimaster
by Gavin Henry 06 Feb '07

06 Feb '07

<quote who="hyc(a)OpenLDAP.org"> > Update of /repo/OpenLDAP/pkg/ldap/tests/scripts > > Modified Files: > test050-syncrepl-multimaster 1.2 -> 1.3 > > Log Message: > Additional syncrepl timeouts needed > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/tests/scripts/ > http://www.openldap.org/devel/cvsweb.cgi/tests/scripts/test050-syncrepl-mul… > Nice! But I'm confused. I thought we didn't use the multimaster name, but MirrorMode instead? 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/

2 3

RE24
by Howard Chu 02 Feb '07

02 Feb '07

OK, if no new issues are reported against HEAD in the next 24 hours then I think tomorrow we should kick out a new 2.4alpha. Offhand it looks to me like syncrepl enhancements are the only thing missing for a Beta. Anyone else have a list of items they want to resolve for 2.4? -- -- 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/

4 4

modifyTimestamp resolution
by Howard Chu 02 Feb '07

02 Feb '07

In preparation for the upcoming syncrepl changes, I've updated liblutil to generate CSNs with microseconds in the timestamp. Currently slapd copies the entryCSN timestamp to the createTimestamp and modifyTimestamp attributes when generating these attributes. Anyone have any thoughts on whether it would be a too-surprising change for these attributes to now have higher resolution? Should we keep truncating them to 1-second resolution? -- -- 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/

2 2

libsasl alternatives: dovecot, tsasl, ...
by Michael B Allen 02 Feb '07

02 Feb '07

On Mon, 29 Jan 2007 16:38:02 +0000 Gavin Henry <ghenry(a)suretecsystems.com> wrote: > On Sun, 28 Jan 2007 15:38:54 -0800 > Howard Chu <hyc(a)symas.com> wrote: > > We've talked about jettisoning Cyrus SASL in favor of "something else" > > but there haven't been any other implementations worth considering. Feel > > free to continue this conversation on the openldap-devel mailing list if > > you want to pursue it further. > > Timo from dovecot, uses his own version, and has talked before about > breaking it out. Might be worth a browse of the latest Dovecot RC. I just inquired about Heimdal's "tsasl" (not currently included in Heimdal). They are interested in a simpler sasl solutions as well. He also mentioned dovecot. Mike

2 1

Re: commit: ldap/servers/slapd syncrepl.c
by Howard Chu 01 Feb '07

01 Feb '07

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > syncrepl.c 1.296 -> 1.297 > > Log Message: > plug one-time leaks related to configuration This commit changed something like 180 lines of code, mostly for minor formatting. A diff of such size makes it hard to identify the actual bugfix. It really should have been two separate commits. -- -- 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 0

GSS-SPNEGO Protocol Details
by Michael B Allen 30 Jan '07

30 Jan '07

Hello, I've implemented SASL binds for GSSAPI and GSS-SPNEGO using a Sockbuf_IO_Desc handler instead of libsasl. Everything works great but I've noticed some behavior from the server I'm using that is not consistent with the available documentation (RFC 2222 and draft-ietf-sasl-gssapi-03 by Melnikov). Would anyone happen to know where I might ask about GSS-SPNEGO protocol details? Is there an IETF mailing list somewhere? There are three issues: 1) GSS-SPNEGO search replies are sealed even though the request was not and a capture of another client talking to the same server shows replies as integ-only. A examination of the captures of my code and the other client shows the packets are identical (minus ber encoding differences and encrypted krb5 bits). 2) GSS-SPNEGO does not appear to use the additional bind exchange to negotiate the security-layer bit mask like GSSAPI does. 3) GSSAPI can use what is apparently the DN of an account called the "authorization identity". The actual values for this field do not appear to be documented anywhere. I don't suppose I should care since the code works fine but I do. Any pointers are appreciated. Mike

3 6

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