[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Config keyword selection sequence?
Slapd's configuration has historically been designed to be quite liberal
in what it accepts; global, per-backend and per-database statements
could occur almost in any order, with only last-resort consistency
checks (e.g. using a database specific keyword before any database
definition would have it simply ignored, and only in case handling it
would cause harm it would have been considered an error). Now,
configuration is shifting towards back-config, which means it's much
more structured, and slapd.conf remains mostly a bootstrap and a
transition means to configure the system. However, I see some
inconsistency, or at least some flaw in the way things hare currently
handled. The keyword handling selection needs to consider some cases:
1) global
1.a) global + global overlay(s)
2) per-backend (+ global)
2.a) (2) + (1.a)
3) per-database (+ global); per-backend is prohibited after a database
of that type is instantiated, while it's not entirely clear whether a
global overlay's configuration needs be handled from inside a database block
3.a) per-database + overlay (+ global and so).
Maybe someone can be a bit more precise on what the code actually does
exactly, but that's essentially the overview.
What happens right now is that:
A. in case (1) the global keytable is checked (fine);
A.1. in case (1.a) the global keytable is checked, then that of overlays
is checked
B. in case (2) the global keytable is checked first, then the
per-backend table is checked
B.1. in case (2.a) the global keytable is checked first, then the
per-backend table is checked, and finally that of overlays is checked
C. in case (3) the global keytable is checked first, then per-database
keytable is checked
C.1. in case (3.a) the global keytable is checked first, then
per-database keytable is checked, and finally that of overlays is checked
In general, checking goes from general to specific; if it were to go the
opposite, things would:
- be more consistent; in fact, for example, overlays are checked in
reverse order with respect to their declaration, so the last overlay's
table is checked first; in general, going from spcific to general is the
common rule in most of slapd's design (ACL, for example).
- be more convenient, since databases and overlays could, for example,
intercept global directives if they are supposed to have a special
meaning to them, handle them as appropriate, and then either
short-circuit evaluation, or re-inject them by returning SLAP_CONF_UNKNOWN.
Comments? Am I overlooking anything essential?
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@sys-net.it
------------------------------------------