openldap-devel October 2006

openldap-devel@openldap.org

7 participants
13 discussions

chroot'd operation, userid
by Howard Chu 31 Oct '06

31 Oct '06

I was reviewing the discussion of ITS#4719 and thinking about some of the options. We could add a setuser/setgroup config directive for the tools to use. It might be confusing since these directives would not replace the need for slapd's -u and -g commandline options. Along those lines, how does anyone use slapd with the -r option? Since no corresponding option exists for the tools, and presumably the pathnames in slapd.conf are absolute paths, I guess you would need an alternate config for running the tools outside the chroot jail, with the full paths to the jailed directories. Seems rather messy. I would expect the more common scenario is to just run slapd using a userID that doesn't have write privileges outside its database directories, and not worry about a chroot jail. We've talked about this in the past - why don't we restructure things so that the user and group are read from the config, along with the listeners? I.e., defer dropping root privs until after the config has been read. -- -- 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 3

[Fwd: BerkeleyDB region size bug]
by Howard Chu 27 Oct '06

27 Oct '06

This is Sleepycat bug #14908. I thought I posted it here before but apparently not. Fixed in current 4.5.20, but still broken in all earlier releases. -------- Original Message -------- Subject: region size bug Re: [BDB-Alpha] Berkeley DB 4.5.8 ALPHA Date: Mon, 10 Jul 2006 13:37:33 -0700 From: Howard Chu <hyc(a)symas.com> To: support(a)sleepycat.com CC: support(a)symas.com References: <45A742B5-7DD5-4512-A204-A10FE8FC5DFC(a)oracle.com> I just ran into this in 4.2.52 but the same calculation occurs in 4.4 and 4.5.8 alpha: This computation gives the wrong results when the number of cache regions is greater than the number of gigabytes (which we encounter on Linux using shared memory regions, which are constrained to much smaller than a gigabyte each). in mp/mp_region.c: roff_t reg_size; /* Figure out how big each cache region is. */ reg_size = (roff_t)(dbenv->mp_gbytes / dbenv->mp_ncache) * GIGABYTE; reg_size += ((roff_t)(dbenv->mp_gbytes % dbenv->mp_ncache) * GIGABYTE) / dbenv->mp_ncache; reg_size += dbenv->mp_bytes / dbenv->mp_ncache; *reg_sizep = reg_size; The first reg_size calculation always goes to zero when mp_ncache > mp_gbytes. This should have been, instead: reg_size = GIGABYTE / dbenv->mp_ncache * dbenv->mp_gbytes; Or in unidiff: --- mp_region.c.O 2006-06-19 08:37:58.000000000 -0700 +++ mp_region.c 2006-07-10 13:36:43.000000000 -0700 @@ -260,9 +260,7 @@ roff_t reg_size; /* Figure out how big each cache region is. */ - reg_size = (roff_t)(dbenv->mp_gbytes / dbenv->mp_ncache) * GIGABYTE; - reg_size += ((roff_t)(dbenv->mp_gbytes % - dbenv->mp_ncache) * GIGABYTE) / dbenv->mp_ncache; + reg_size = GIGABYTE / dbenv->mp_ncache * dbenv->mp_gbytes; reg_size += dbenv->mp_bytes / dbenv->mp_ncache; *reg_sizep = reg_size; -- -- 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/

1 0

Re: ITS#4703 mirrormode hole
by Aaron Richton 26 Oct '06

26 Oct '06

> While we're at it, we should add a consumer option for specifying > additional locations in which to store contextCSNs. This would e.g. > solve ITS#4626 by allowing a consumer in a glued subordinate to keep its > parent context up to date. One thing we've been kicking around lately was a dream-list feature of "throw a contextcsn on any arbitrary entry." Our motivating problem was essentially + dc=syncproved,dc=rutgers,dc=edu + ou=Boot-Time Configuration + ou=Dynamic Configuration We wanted the ability to arbitrarily add a contextcsn attribute into "ou=Boot-Time Configuration,dc=syncproved,dc=rutgers,dc=edu" despite the fact that the suffix/syncprov was on "dc=syncproved,dc=rutgers,dc=edu". This would be combined with, essentially, /* if bootconfig is fresher than we are, reboot to get it */ if (contextcsn(BootConfig) > (``date`-/proc/uptime`)) restart; to get things that can only be configured at boot time. (No, we're not actualy that crazy with our systems, it's just a daemon; but you get the idea.) In the end, we're just searching for entryCSN>=lastRestart with base of ou=Boot-Time. But contextCSN seems more eloquent (only pick up one entry) and this might be (roughly) in line with what you were considering, or give you some ideas (ridiculous though they might be).

1 0

Re: commit: ldap/servers/slapd passwd.c
by Pierangelo Masarati 26 Oct '06

26 Oct '06

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > Tag: OPENLDAP_REL_ENG_2_3 > passwd.c 1.95.2.19 -> 1.95.2.20 > > Log Message: > complete fix to ITS#4665 > Note: what we usually do is append modifications to the end of the orm_modlist, so that they get freed along with the others by the caller. In this case, a modification must go first. As a consequence, it wouldn't be freed really. A cleaner approach would be to register another callback that does cleanup of this modification __after__ it's been used. I guess the current approach is just fine, although a bit involved. 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

manpages in HEAD
by Howard Chu 26 Oct '06

26 Oct '06

The manpages now source a shared file "../Project". Nothing in the makefiles installs this file, so the Acknowledgements sections of each manpage is empty. This shared file seems to need some re-thinking. Nobody is going to want some generically file named "Project" installed into their /usr/man (or whatever) hierarchy. Perhaps it should be man8/ldap_misc.8 or something, so that at least it has an identifiable name and isn't in the .../man directory. -- -- 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 2

OpenLdap & Oracle/XE and threadless stub patch
by R.K. Owen 26 Oct '06

26 Oct '06

I'm trying to use the Oracle10/XE as a backend for the OpenLDAP server, using the back_sql module. I know that the unixodbc interface is working with Oracle because I can access the database with the isql tool and view the test tables. However, when I try to run the slapd daemon I get the following error slapd -d 1 ... ==>backsql_get_db_conn() ==>backsql_open_db_conn(4294967295) backsql_open_db_conn(4294967295): SQLConnect() to database "OracleODBC" failed. Return code: -1 nativeErrCode=0 SQLengineState=IM003[iODBC][Driver Manager]Specified driver could not be loaded msg="[iODBC][Driver Manager]Specified driver could not be loaded" nativeErrCode=0 SQLengineState=00000[iODBC][Driver Manager]/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: undefined symbol: bcuMsgBoxError msg="[iODBC][Driver Manager]/usr/lib/oracle/xe/app/oracle/product/10.2.0/server/lib/libsqora.so.10.1: undefined symbol: bcuMsgBoxError" backsql_get_db_conn(): could not get connection handle -- returning NULL backsql_db_open(): connection failed, exiting backend_startup_one: bi_db_open failed! (1) slapd shutdown: initiated I haven't found where the bcuMsgBoxError symbol is defined (but it shouldn't be needed since /usr/bin/isql works just fine). Anyways, I thought I'd try configuring the anon-CVS source --without-threads and found that the thr_stubs.c needed a do-nothing function to satisfy the references below ... hence the attached patch. connection.o: In function `connection_operation':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1044: undefined reference to `ldap_pvt_thread_pool_tid' connection.o: In function `connection_fake_init':/home/owen/rk/nim/openldap/openldap-cvs/servers/slapd/connection.c:1955: undefined reference to `ldap_pvt_thread_pool_tid' However, any insight on resolving the bcuMsgBoxError problem and getting Oracle to work as the back-end would be greatly appreciated. BTW - I'm using Ubuntu 6.05 Linux. Thanks, R.K. R.K.Owen,PhD rk(a)owen.sj.ca.us LBNL/NERSC rkowen(a)nersc.gov Univ. of California, Berkeley Wrk:(510)486-7556

2 1

HEAD and connection speed
by Quanah Gibson-Mount 16 Oct '06

16 Oct '06

I've been twiddling around with HEAD, since it supports BDB 4.5 and OL 2.3 doesn't, and noticed that when I do speed tests, HEAD is 66% slower than 2.3 (+ my patches from HEAD for connections). This seems interesting to me, since my connection code is largely from HEAD. In 2.3, I get 15,000+ auths/second on my 64 bit test systems, but with straight HEAD code, I only get 5,000 auths/second. In both cases, the lightweight dispatcher code is enabled. Any thoughts on what else may be affecting HEAD? The configuration is very simple, just a small 250k bdb database. --Quanah -- Quanah Gibson-Mount Product Engineer Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 3

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel October 2006