Pierangelo Masarati wrote:
For back-meta, I'd like to create children entries for each target; in this case, an overlay with specific per-target behavior, would need to either create a similar tree, or to append entries to targets'. This is really going to mess up back-config. Still, I think having separate entries makes sense. That's how I made, for example, the monitor interface to "foobar" overlay...
Speaking of which, ITS#4789, were you actually suggesting that back-monitor also use olcDatabase={x}foo to name its database entries? That would change its apparent behavior quite a bit from 2.3.
As I mentioned before, I chose not to use a cn=Databases container in back-config because I didn't want to have to deal with creating a lot of do-nothing infrastructure entries. Philosophically I also prefer RDNs that use task-specific attributes; I've always thought cn was too overused... And if we're using olcDatabase, then e.g. olcDatabase={1}foo,cn=databases,cn=monitor is just redundant information, we already know foo is a database so we don't need the container to remind us of that.
Howard Chu wrote:
Pierangelo Masarati wrote:
For back-meta, I'd like to create children entries for each target; in this case, an overlay with specific per-target behavior, would need to either create a similar tree, or to append entries to targets'. This is really going to mess up back-config. Still, I think having separate entries makes sense. That's how I made, for example, the monitor interface to "foobar" overlay...
Speaking of which, ITS#4789, were you actually suggesting that back-monitor also use olcDatabase={x}foo to name its database entries? That would change its apparent behavior quite a bit from 2.3.
As I mentioned before, I chose not to use a cn=Databases container in back-config because I didn't want to have to deal with creating a lot of do-nothing infrastructure entries.
One of the points, in selecting that solution for back-monitor, was to keep homogeneous entries confined; another, was to limit the amount of load when dynamically generating data. If everything is right below cn=monitor, then all entries (right now, more than 100 for a minimal system with most backends and overlays compiled...) need to be re-generated before evaluating filters, so the only way we have to limit the scope of searches is to use base and scope...
Philosophically I also prefer RDNs that use task-specific attributes; I've always thought cn was too overused...
for the rest I agree with you. I used cn because at that time, working at DN string representation, I was biased towards the idea of only using "friendly" attributes in DN, which, all in all, makes sense for those DN that need to be exposed. In some sense, the DN of the monitor tree needs to be exposed, but it's mostly meant to be machine-readable, by scripts, rather than navigated by humans, so using specific attributes may make sense as well. Redesigning back-monitor infrastructure (not contents), having learned from back-config's experience, might be something to consider.
And if we're using olcDatabase, then e.g. olcDatabase={1}foo,cn=databases,cn=monitor is just redundant information, we already know foo is a database so we don't need the container to remind us of that.
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 ------------------------------------------
-
Howard Chu -
Pierangelo Masarati