openldap-devel

openldap-devel@openldap.org

1443 discussions

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 01 Feb '07

01 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 31 Jan '07

31 Jan '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

Re: commit: ldap/servers/slapd schema_init.c
by Kurt Zeilenga 29 Jan '07

29 Jan '07

While not exactly incorrect, I think it best to On Jan 29, 2007, at 3:39 AM, hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > schema_init.c 1.393 -> 1.394 > > Log Message: > ITS#4823 allow zero-length IA5String > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > schema_init.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. >

1 1

sb_sasl_write short-count bug?
by Michael B Allen 28 Jan '07

28 Jan '07

Hi, Consider the sb_sasl_write function: 341 static ber_slen_t 342 sb_sasl_write( Sockbuf_IO_Desc *sbiod, void *buf, ber_len_t len) 343 { <snip> 352 /* Are there anything left in the buffer? */ 353 if ( p->buf_out.buf_ptr != p->buf_out.buf_end ) { 354 ret = ber_pvt_sb_do_write( sbiod, &p->buf_out ); <snip> 391 ret = ber_pvt_sb_do_write( sbiod, &p->buf_out ); 392 393 /* return number of bytes encoded, not written, to ensure 394 * no byte is encoded twice (even if only sent once). 395 */ 396 return len; 397 } This optimistically returns the len supplied. If ber_pvt_sb_do_write returns a short-count then data will be left in the p->buf_out. The remaining data will not be written until the next sb_sasl_write call which may not happen. I have not observed a problem but just from examining the logic I thought I might say something. Is this bug? Would putting ber_pvt_sb_do_write in a loop do any good? Mike

2 1

Re: commit: ldap/tests/scripts test049-sync-config
by Howard Chu 28 Jan '07

28 Jan '07

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/tests/scripts > > Modified Files: > test049-sync-config 1.3 -> 1.4 > > Log Message: > make sure replication finished before comparing data (under valgrind, replication may take ages) I debated adding such a check before. I think the first check you added should be removed. In my initial testing there were timing-dependent errors that cropped up when refreshing was occurring while the ldapadd was running. I think it's important that we continue to test for this case, however crudely it's done. Too bad we don't have a reliable means to notify the test script when the consumer has actually started its work. We could query back-monitor but normally (not under valgrind) the refresh could complete before we got the back-monitor search result. -- -- 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/

2 1

Re: cn=include
by Eric Irrgang 26 Jan '07

26 Jan '07

Since 1) the behavior is different 2) the slapd.conf to cn=config conversion sucks in the relevant information anyway and 3) use of includes is inappropriate under cn=config is it maybe time for the slap* tools stop creating cn=Includes? On Tue, 23 Jan 2007, Howard Chu wrote: > Eric Irrgang wrote: >> Are olcInclude attributes in cn=config honored as per the Admin Guide >> section 5.2.2 or is that documentation misleading? > > Good question. The short answer is - the use of include files is not > recommended for cn=config. They really only work correctly when slapd is using > slapd.conf. > > Keep in mind - in slapd.conf, you can insert include statements anywhere at > all in the config file, you can order them completely arbitrarily, > interleaving them with any other config statements. Under cn=config, all of > the cn=Includes are grouped under one place, they can't have anything else > inserted between them, so if they needed to have other intervening directives > processed first, they would fail. > > Also, the point of using cn=config is to make every part of the configuration > accessible/modifiable using LDAP. slapd.conf-formatted files (e.g. include > files) are not accessible or modifiable using LDAP. > -- > -- 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/ > -- Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342

3 3

Search timeout?
by Pierangelo Masarati 25 Jan '07

25 Jan '07

I'm facing an issue: when a proxy is searching a remote server, and the server does not respond in the sense that it happily accepts a search request but never returns any type of response (a "silly" way of reproducing this issue consists in sending a SIGSTOP to the remote server: it accepts requests but does nothing), right now the proxy honors the timelimit. However, if the search is performed as the rootdn of the proxy, it will last forever. So I'd like to introduce the concept of "search timeout". This differs from the already existing "timelimit" in that it is not a client-requested (or server-imposed) limit on the overall duration of a search operation, but rather a server-imposed limitation on how long the proxy can wait consecutively for any sort of response from a remote server. This should, optionally, apply to the rootdn as well, since it's more about the sanity of the connection than on the properties of the operation. This type of limitation has already been introduced for other operations, including compare and all write operations, for a similar purpose. Comments? p.

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel