My question is not well-posed. It should be clear that as soon as another
instance of the same overlay is pushed onto the overlay stack of a
database, this will intercept all the configuration directives of that
overlay type. As such, the earlier instances will be unreachable. This
is not a problem per se: I could well use
suffix "dc=com"
# ...
overlay rwm
rewriteEngine on
rewriteContext default
rewrite "(.+,)?c=IT$" "\1c=US" "@:"
rewriteContext searchEntryDN
rewrite "(.+,)?c=IT$" "\1dc=com" "@:"
# ...
overlay rwm
rewriteEngine on
rewriteContext default
rewrite "(.+,)?dc=com$" "\1c=IT" "@:"
rewriteContext searchEntryDN
rewrite "(.+,)?c=US$" "\1c=IT" "@:"
to map from "dc=com" to "c=IT" and then from "c=IT" to "c=US", i.e.
concentrate all the directives below the appropriate "overlay rwm"
directive, but I don't really see the need. So I guess a uniqueness check
should be advisable, and uniqueness should be enforced by default. My
only concern is about the opportunity to allow exceptions.
p.
> I'm facing the opportunity to consider whether an instance of an overlay
> should eb unique or not for a given database. Currently, we can load how
> many instances of an overlay on the stack of a database. It is the
> administrator's duty to make sure the same overlay is not loaded multiple
> times. However, for some reason, specific databases may need an overlay
> whenever some feature is requested. A clean solution would be to move the
> configuration directive from the database to the overlay; for some reason,
> currently there are a couple backends (ldap, relay) that directly
> instantiate the "rwm" overlay when some configuration directive is
> present. I was thinking about adding some flag argument to
> overlay_config, to specify whether that overlay must be unique or not,
> and, in case, if multiple instantiation should be treated as an error or
> be ignored. This is not a priority, because back-relay can live without
> it (it's clearly specified in the man page how the rwm overlay should or
> should not be used), while in back-ldap this would be required only to
> allow existing configurations to use the new back-ldap + rwm without
> changes.
>
> See http://www.openldap.org/lists/openldap-bugs/200411/msg00049.html and
> follow-ons for details.
>
> Comments?
>
> p.
>
> --
> Pierangelo Masarati
> mailto:pierangelo.masarati@sys-net.it
>
>
> SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497
>
>
--
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497