[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: backend overlays

Howard Chu wrote:

Pierangelo Masarati wrote:

If this is completely off-topic, please disregard.

Let me try again... The proxycache overlay sits on top of (e.g.) back-ldap. It also creates an instance of back-bdb for its local storage. This instance of back-bdb is totally private to the proxycache overlay, it is completely invisible to the rest of slapd so you can't configure anything special on top of it. The first question in my mind was "would you ever need to put another overlay on top of this private back-bdb?"

Obviously one way to do so would be to add config mechanisms to proxycache so that its private database can be explicitly configured.

The other thought that occurred to me was to declare overlays in the backend-specific config directives. Then whenever a backend of that type is used, it has these other overlays already included. The problem of course is that if the overlay needs any suffix-dependent configuration, there's no way to automate that.

I see another problem: in this case, all instances of that backend would get that certain stack of overlays, which might be undesirable. I'd consider providing a mechanism (e.g. a sort of generalization of backover.c) that allows those overlays that use internal databases and are willing to allow overlay stacking to inject a slap_overinfo structure in place of the original BackendInfo; then, something like

proxycache-overlay syncprov
proxycache-syncprov-sessionlog 100

could be used to access the configuration of that overlay. By using a hierarchical configuration directive pattern we should be able to propagate this to an arbitrary number of layers. The directives would look quite odd, but at least we don't need to change the style of the configuration; of course, nested parentheses would be a big plus:

database ldap
overlay proxycache {
   proxycache hdb ...
   overlay syncprov {
       sessionlog 100


SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497