openldap-devel

openldap-devel@openldap.org

1443 discussions

slurpd in RE24
by Howard Chu 09 Apr '07

09 Apr '07

Since we haven't been fixing any slurpd bugs lately, it doesn't seem like a good idea to continue releasing it. I'd like to cvs rm it from HEAD and RE24. Comments? -- -- 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/

6 13

Re: commit: ldap/servers/slapd/overlays unique.c
by Hallvard B Furuseth 09 Apr '07

09 Apr '07

hyc(a)OpenLDAP.org wrote: > unique.c 1.24 -> 1.25 > Enhanced unique configuration The unique_modify() change is wrong. Originally noticed it because gcc -Wformat complained, but there is more. Two sprintfs without the destination buffer argument, presumably it should be 'kp'. You initialize kp after a sprintf statement which I assume uses it. And the statements seem in wrong order. A suggested patch is appended - though note that I haven't actually looked at the logic of the function, just a brief glance on what seems to make the filter creation code look sensible. -- Regards, Hallvard --- servers/slapd/overlays/unique.c~ +++ servers/slapd/overlays/unique.c @@ -1143,7 +1143,7 @@ key = op->o_tmpalloc(ks, op->o_tmpmemctx); - if ( uri->filter && uri->filter->bv_len ) - kp += sprintf ("(&(%s)", uri->filter->bv_val); kp = key + sprintf(key, "(|"); + if ( uri->filter && uri->filter->bv_len ) + kp += sprintf(kp, "(&(%s)", uri->filter->bv_val); for(m = op->orm_modlist; m; m = m->sml_next) @@ -1157,7 +1157,7 @@ op->o_tmpmemctx ); - kp += sprintf (kp, ")"); if ( uri->filter && uri->filter->bv_len ) kp += sprintf (kp, ")"); + kp += sprintf (kp, ")"); rc = unique_search ( op, @@ -1260,7 +1260,7 @@ key = op->o_tmpalloc(ks, op->o_tmpmemctx); - if ( uri->filter && uri->filter->bv_len ) - kp += sprintf ("(&(%s)", uri->filter->bv_val); kp = key + sprintf(key, "(|"); + if ( uri->filter && uri->filter->bv_len ) + kp += sprintf(kp, "(&(%s)", uri->filter->bv_val); for ( i=0; newrdn[i]; i++) { @@ -1274,7 +1274,7 @@ } - kp += sprintf(kp, ")"); if ( uri->filter && uri->filter->bv_len ) kp += sprintf (kp, ")"); + kp += sprintf(kp, ")"); rc = unique_search ( op,

1 0

Please test RE23
by Howard Chu 06 Apr '07

06 Apr '07

I'd like us to get 2.3.35 out soon. And send an email if you know of any outstanding bugs in ITS that aren't yet in RE23 that you think should be. Thanks. -- -- 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/

3 2

Re: (ITS#4879) URL parse/unparse troubles
by Howard Chu 03 Apr '07

03 Apr '07

Howard Chu wrote: >> The RFCs 4516/2255 hostport part has grammar [host [":" port]], >> but ldap_url_desc2str() produces [host][":" port]. >> >> ldap:// -> host NULL, port 389 -> >> ldap://:389/??base >> >> That's OK as an ldap_url_parse() OpenLDAP extension, but not as >> ldap_url_desc2str() output given to non-OpenLDAP applications. > > This is a mess. The ldap: scheme definition has always been broken, and > it certainly does not conform to the basic URI syntax in RFC3986 section > 3. In particular, RFC3986 forbids a URI from containing "//" when the > authority component is absent. Looks like RFC4516 should not have been > approved in its current state. Stupid little things like this make me wonder WTF were they smoking when they created LDAP. I no longer ask myself wtf they were thinking, because clearly they weren't... DNs should have been left in canonical filesystem order, like X.500 tools used. Then we could just treat LDAP URLs like every other hierarchical URL namespace, with relative paths and all the other associated conveniences, and use a single generic parser to handle it all. It's all so damned moronic. It's almost aggravating enough to make me switch to pure DAP and leave all of this cruft behind. Mebbe it's time to add a config switch somewhere to set all of slapd and the libraries to default to DCE/X.500 format DNs, and define a new "xdap" URL scheme to go with it. -- -- 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 1

Re: commit: ldap/servers/slapd bconfig.c
by Howard Chu 30 Mar '07

30 Mar '07

ralf(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > bconfig.c 1.267 -> 1.268 > > Log Message: > Add operational Attributes when creating frontend and config database entries. > (Otherwise test049-sync-config fails) > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/bconfig.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. > . > Most of the code in this checkin is a duplicate of slap_add_opattrs(). Any reason you didn't use that? -- -- 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

back-config and slapadd
by Ralf Haferkamp 29 Mar '07

29 Mar '07

Hi, I am currently trying to initialize the back-config database by slapadd-ing a small ldif-File (based on the slapd.ldif from CVS HEAD). However I ran into various issues with regard to the ordering of the different database objects and it unclear to me how exactly this is supposed to work. The sample slapd.ldif from CVS does not contain any ordering information (the "{digit}" string). It can be slapadd-ed it with out any problem. But after starting slapd (or any slaptool) I see some strange effects, e.g. I suddenly have two frontend-databases in back-config (one with index -1 and the other without any index). In order to try to fix this I'd like to find out how slapadd-ing back-config databases is supposed to work. 1. Should slapadd work with LDIF files that do not have any ordering numbers for the databases in them? 2. Should slapadd work with LDIF files that does not explicitly contain the mandatory cn=frontend and cn=config databases? I'd assume yes as the answer for both questions. The current code however shows all kinds of weird behaviour with regard to both points and I'd like to fix that. -- Ralf

2 3

eXtreme customization of slapd
by Pierangelo Masarati 25 Mar '07

25 Mar '07

I have some requests for further slapd customization opportunities. Some of the customizations are really "custom", in the sense that they could break syntax and schema checking the way it is done now. In some cases even decoding the packet could break, so I'm a bit hesitant and I'd like, if possible, to be able to design custom code as little intrusive and as advantageous for OpenLDAP as possible, even at the cost of heavy slapd rewriting that is of general usefulness. First idea: instead of calling do_*(), add yet another pseudo-database layer, much like the "frontend" database, called the "decoding layer" database, which could be replaced (rather than augmented) by other analogous components. In this case, the custom slapd could do almost everything to an incoming packet, as soon as it is presented to the frontend and to the backends in a consistent manner. Advantages: total freedom; disadvantages: risks lots of code duplication and so. Second idea: "staggerize" packet decoding. For example, when a request comes in, just decode the DN; "sanitize" (i.e. parse and validate) it as little as possible; then pass control to an intermediate layer, which could actually be an overlay, right after database selection. At this point, it would be up to some code at this layer to do the rest of the decoding, including relaxing some checks or allowing some violations (I believe this is part of some requests from the Samba developers, and similar issues were raised by Luke Howard with respect to compatibility with some M$ "extensions"). Advantages: could be a first step towards per-database schema; potential for less code duplication. Disadvantages: could need extensive work to split current code as required. 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 ------------------------------------------

2 1

Re: commit: ldap/libraries/libldap gnutls.c getdn.c tls.c
by Howard Chu 23 Mar '07

23 Mar '07

hyc(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > getdn.c 1.136 -> 1.137 > tls.c 1.146 -> 1.147 > Added Files: > gnutls.c NONE -> 1.1 > > Log Message: > Preliminary GNUtls support. gnutls.c will merge back into tls.c later. The basic functionality is all working; if you replace tls.c with gnutls.c in the Makefile everything builds and runs. I decided to move the ldap_X509dn2bv() function into tls.c for now, since there's a different version for GNUtls. (I have not added gnutls.c to the Makefile, you can set it manually if you feel like testing this.) The GNUtls version parses the DER certificate directly, using liblber. I think this may be the best way to go moving forward. I intend to remove the OpenSSL-specific DN parser in favor of this approach. This also means we can replace the OpenSSL-dependent code in slapd/schema_init.c for the certificate validator and normalizer with generic liblber stuff. If any 3rd party code is using ldap_X509dn2bv() they're going to break. I suppose we could keep the old API around and use a new function name instead... There's still a few missing pieces in the GNUtls support: I haven't tested any Diffie-Hellman exchanges yet. There is no support for session caching yet. GNUtls needs to read CRLs from a file, you can't just point it at a directory - so we need a config directive for this. (this also means that the TLSCACertificatePath directive doesn't work) GNUtls doesn't provide any API for parsing cipher suites/algorithm names. At present I have no idea how to make these end-user configurable, will probably have to write a patch for GNUtls. There's no API equivalent to the RandFile option; I have no idea how to seed GNUtls's PRNG. Since most platforms just use /dev/urandom this isn't a big deal. Certificate verification isn't present yet. Wondering if we should silently accept the no-op directives or error out on them (TLSCACertificatePath, TLSRandFile). Just ignoring them for now. -- -- 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

Expected behavior of mirrormode
by Jesse W. Hathaway 22 Mar '07

22 Mar '07

I am testing the new mirromode feature in 2.4.4alpha and have run into some unexpected behavior: 1) If mirrormode is on in the config when slapd starts it fails to synchronize with the producer, this is unexpected behavior syncrepl rid=545 provider=ldap://ns3 type=refreshAndPersist searchbase="dc=chappy,dc=com" schemachecking=off bindmethod=simple binddn="cn=admin,dc=chappy,dc=com" credentials=secret mirrormode on 2) If mirrormode is off in the config when the consumer slapd starts the consumer slapd synchronizes with the producer, if mirrormode is then turned on dynamically, synchronization continues and the consumer is writable by anyone, this is expected behavior 3) After mirror mode is set dynamically, if the consumer slapd is restarted, then the consumer will no longer sync with the producer, this is unexpected behavior Are these bugs or by design? thanks, Jesse

1 0

back-sql - table lock
by marek-openldap 21 Mar '07

21 Mar '07

Hi I successfuly created connection from OpenLDAP to my Informix database. I can see everything in LDAP Browser:) I have noticed that when slapd is running I cannot insert data into table using sql client. I get error from my db: 243: Could not position within a table (user). 113: ISAM error: the file is locked. Is there any lock or transaction isolation level problem? Regards Marek

1 0

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