openldap-devel

openldap-devel@openldap.org

1416 discussions

BDB 4.5 has been released
by Quanah Gibson-Mount 09 Oct '06

09 Oct '06

<http://www.sleepycat.com/update/4.5.20/if.4.5.XX.html> We may want to validate that it there are no OL-specific mods necessary to use it with back-bdb/back-hdb. There weren't in the RCs I used, but there's no telling if they changed something in the 5 releases since then. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

Special identities and connections in proxy backends
by Pierangelo Masarati 09 Oct '06

09 Oct '06

There might have been some confusion recently and not so far in the mind of at least one of the developers of the proxy backends (me). Especially back-ldap allows few slecial identities to be configured, which may serve some of the special purposes this backend is required to implement. One of them is the "acl-bind" identity (see slapd-ldap(5)), which is used for operations that are privileged, meaning internal operations used by special internal features, or operations performed using the rootdn identity. If this is enabled, and an operation occurs on a connection that's authenticated as the rootdn of the database (either because this is true, or because it is pretended by the code that called that operation of back-ldap), binding to the remote server occurs with the identity specified in the "acl-bind" statement, either using SASL or simple bind. Another one is the "idassert-bind" identity. This is used, if configured, whenever an authenticated connection tries to perform an operation thru back-ldap (this was recently added to back-meta as well) and that back-ldap database is not the authorizing database for the connection, and thus there is no other means to inform the remote server that the connection is authenticated. Privileged connections get cached. Connections used for idassert should be cached as well, as they always use the same identity, and typically assert that of the client by way of the proxyAuthz control. The latter didn't quite happen until a recent fix, though. The point is that there used to be (and there is, I haven't committed recent fixes yet, since I'm trying to convince myself that everything is now fixed :) some confusion about those special identities. What I came out so far is that in the internal handling of those special connections: 1) privileged connections are treated some way 2) idassert connections are treated separately 3) in case a connection ought to be privileged, but acl-bind is not set and idassert-bind is set, the latter identity is used for privileged connections as well I'm not 100% convinced about (3), though, because that would obfuscate what identity is used for what purpose. The reason for (3) is that if one doesn't need to have privileged connections, he shouldn't set acl-bind at all; however, there might be cases where one wants to have identity assertion in place, and if acl-bind is not configured, connections as the rootdn wouldn't exploit it (this may happen, for example, when using slapo-chain(5) on top of a database that needs to have the rootdn in place). So the point is: is it preferable to explicitly configure twice the same identity, or have a "sane" default if one only sets idassert-bind and not acl-bind? All in all, the identity that's used for identity assertion is not likely to be more privileged than the privileged one... 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 2

Syncrepl client API
by Pierangelo Masarati 08 Oct '06

08 Oct '06

I've implemented a client API for the LDAP Content Synchronization operation (RFC4533) which basically provides a clean and simple interface to using the operation to sync client's data based on the status of the producer. This is not only intended to provide replication capabilities, but also to implement client-side "persistent search"-like feature based on stock slapd (>= 2.3), without the need to revamp the persistent search IDs and code yet another overlay. The API essentially consists in a data structure that contains data required to initiate/re-initiate the search operation, to keep track of the current state, plus a set of handlers that will be called based on the event that occurs: when a search entry, a search reference, an (already parsed) RFC4533 intermediate response or a search result done message are received, respectively. This frees the client from knowing any of the details of RFC4533, except for a loose knowledge of the type of events that can occur. Its usage is quite simple: set up the structure, including an already initialized connection handler, call ldap_sync_init() specifying the mode (refreshOnly, not implemented yet, or refreshAndPersist). When using refreshOnly, that should be all; call ldap_sync_init repeatedly to refresh. When using refreshAndPersist, repeated calls to ldap_sync_poll(), with different timeout policies, are required to inquire for further responses; the provider or the consumer could decide to restart (or connection to the producer could be lost for some reason; in that case, simply call ldap_sync_init() again. Details about setting up the connection with appropriate data protection and authentication is left to the client, as it's out of the scope of syncrepl. I would like to add this to libldap, as the customer that requested its implementation agreed in open sourcing it. I'll post an ITS about this soon. In the meanwhile, I'd like to hear general comments about the overall design. One relevant point is that it strictly implements RFC4533, so delta syncrepl has not been even considered, as there's no specs for that. Initially, I thought a good place to test and use this API would have been to replace the bundled syncrepl consumer code in slapd, but the absence of delta syncrepl makes this option non feasible. This is a pity, because having it there would have meant lots of bug tracking and support from the community of syncrepl users. Nonetheless, apart from my very limited knowledge of delta syncrepl implementation details, I don't think adding it to this public API would be a good idea, because it seems to imply a bit too much knowledge about its implementation details, like the contents of the sync cookie, and very precise and specific details about the implementation of the changelog database. Either those details are coded in a document like RFC4533 (and freeze), or I would leave that optimization to slapd's internals. 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

Indexing thoughts
by Quanah Gibson-Mount 06 Oct '06

06 Oct '06

Stanford has been looking into implementing the value-sort attributes overlay, and realized some problems with using it, if the attribute to be weighted is also indexed and you will be using weights. Primarily, the problem stems from this: The unweighted form of the data could look like: suaffiliation: stanford:staff suaffiliation: stanford:faculty etc The weighted form of the data looks like: suaffiliation: {2}stanford:staff suaffiliation: {1}stanford:faculty This means if you use the data for indexing (in particular, in my case, eq indexing), it will no longer be possible to use filters of the type (suaffiliation=stanford:staff). Which is problematic when many applications do that very thing (and internal ACL's use it as well). I thought a potential solution (not possible at this time, per Howard) would to be able to support something like multiple indices (sub indices?) that would actually index the data in both its weighted and unweighted form, if the val-sort overlay was present. It is also something I thought could be potentially useful for other overlays (how, I'm not sure). But the ability to have indexing behave differently based on different factors does seem potentially useful. In addition, things get more complicated when telephoneNumber (and things using its syntax) are involved. Mostly because {}'s are not valid characters per its syntax, meaning you can't sort the attribute via weights. The ability to tweak SYNTAX based on overlays I guess would be the solution, but sounds ugly. Anyhow, just a set of thoughts, I don't know how practical implementing such a thing would really be. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

2 1

Re: commit: ldap/servers/slapd/schema core.schema
by Quanah Gibson-Mount 03 Oct '06

03 Oct '06

--On Tuesday, October 03, 2006 7:23 PM +0000 kurt(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/schema > > Modified Files: > core.schema 1.88 -> 1.89 > > Log Message: > Incorporate a bit of text from RFC 4524, just to make a point regarding > ITS#4693. The general problem is that things that are copyrightable are not generally distributable in free distributions (i.e., debian), which means that they then cannot distribute core.schema with the OpenLDAP distribution if you make the copyright statement applicable. They already strip out the RFC's since they also are non-free. --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

2 3

Re: distproc and chaining
by Pierangelo Masarati 03 Oct '06

03 Oct '06

Ralf Haferkamp wrote: > Now I am wondering what would be the best way to inject that original > OperationRequest onto the target server. Currently I initialize a (fake) > connection with connection_fake_init(), register a response_callback and feed > the originalRequest (still undecoded) directly into the do_*() functions > (e.g. in case the originalRequest is of LDAP_REQ_MODIFY I call do_modify() > directly). Is this the correct way of doing things, or am I abusing things > here in ways that they weren't intended for? Is there a better way to feed > the original request into the target server? > > BTW, is somebody else working on that code currently? I'd like try to avoid > double/unneeded work. > Ralf, in principle I should be working at that, but I haven't been able to dedicate any time to it essentially since the time I added distproc.c to back-ldap. Directly calling do_*() functions is what I planned, but I didn't work out yet whether it's just safe to call them that way or not. One issue I wanted to solve at that time was essentially procedural: how much are we supposed to stick with that expired ID? I know the original Author was looking for someone to pick up from where he left, and I had a couple of questions (and suggestions) I'd like to see in place. By now, if you're doing anything you consider "decent", please feel free to commit it. It's not going to get into release any soon, so even things that do not immediately work may be acceptable. I'd be glad of reviewing it, and contribute as much as I can. 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 ------------------------------------------

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel