On 2006-08-09 19:20:31, Ralf S. Engelschall wrote: > On Wed, Aug 09, 2006, Joergen Hermanrud Fjeld wrote: > > ...where each overlay is a separate option. > > If I understand the overlay concept of OpenLDAP correctly, it is some > sort of backend data processing filters. Correct. To find out which overlays are available, that is loaded at run-time: ldapsearch -x -h localhost -D 'cn=manager,dc=domain' -w secret -s base -b 'cn=Overlays,cn=Monitor' monitoredInfo To find the overlays activated for the diffirent databases: ldapsearch -x -h localhost -D 'cn=manager,dc=domain' -w secret -s sub -b 'cn=Databases,cn=Monitor' '(monitorOverlay=*)' monitorOverlay
> So, I also think it makes sense > to support them in the OpenPKG "openldap" package. Good :-) > But the question for > me is whether we really need an %option for each one of them or whether > we instead couldn't just _build_ all of them and rely perhaps on some > sort of configuration to really _enable_ them? For an overlay to be activated, it must be turned specifically on for a database with for instance "overlay refint" in slapd.conf. The only reason I made the patch for each option was the observation that the current OpenPKG openldap package builds with some, but not all, overlays, and I assumed that was for some unknown, but valid, reason, so you would probably like to have the same behaviour as before, hence the patch would preserve previous behaviour, and allow exact requirements. > One possibility would be > the --enable-xxx=mod" feature which builds each overlay as a DSO. But is > it also possible to build _all_ into slapds statically without harm and > still let the user _enable_ them via configuration? Yes, as far as I know this is the case. The question that remains is wether there is some slowdown by including the code, even if it is not activated. As far as I can determine, after browsing the openldap faq and archives, there is negligable overhead associated with including the overlays statically. They only drawback I can see is size of the slapd binary, however I expect the memory allocated for this code to be shared between threads, so it should not matter that much? Just for fun: Suse 9.3, openldap 2.3.21 with DSO overlays -rwxr-xr-x 1 root root 1.6M May 10 14:36 /usr/lib/openldap/slapd Debain with openldap 2.3.24 with DSO overlays -rwxr-xr-x 1 root root 919K Jun 1 21:31 /usr/sbin/slapd OpenPKG, openldap 2.3.11 with a few static overlays -rwxr-xr-x 1 kolab kolab 3.3M Aug 4 09:47 /kolab/libexec/openldap/slapd I assume static linking causes most size increase, and may shadow the effect of linking in overlays. Anyway, I have attached a small patch that enables overlays. -- Sincerely | Homepage: Jørgen | http://www.hex.no/jhf | Public GPG key: | http://www.hex.no/jhf/key.txt I will follow the good side right to the fire, but not into it if I can help it. -- Michel Eyquem de Montaigne
--- openldap.spec.orig 2006-08-10 12:39:53.000000000 +0000 +++ openldap.spec 2006-08-10 13:13:16.000000000 +0000 @@ -41,6 +41,7 @@ %option with_sasl no %option with_perl no %option with_odbc no +%option with_overlays yes # list of sources Source0: ftp://ftp.openldap.org/pub/openldap/openldap-release/openldap-%{version}.tgz @@ -117,8 +118,6 @@ ARGS="$ARGS --enable-dnssrv" ARGS="$ARGS --enable-null" ARGS="$ARGS --enable-shell" - ARGS="$ARGS --with-dyngroup" - ARGS="$ARGS --with-proxycache" ARGS="$ARGS --enable-slurpd" # configuration: force to use OSSP fsl @@ -157,6 +156,10 @@ ARGS="$ARGS --enable-sql" %endif + # configuration: overlay support +%if "%{with_overlays}" == "yes" + ARGS="$ARGS --enable-overlays=yes" +%endif # configuration: special platform support case "%{l_platform -t}" in *-sunos* ) CFLAGS="$CFLAGS -D_AVL_H"; LIBS="$LIBS -lrt" ;;
signature.asc
Description: Digital signature
