[Date Prev][Date Next]
Re: (ITS#4770) monitoringslapd.sdf patch
> Gavin Henry wrote:
>> <quote who="Pierangelo Masarati">
>>> from the preamble, one may infer that monitoring is optional in the
>>> sense it can be optionally built. That's how it used to be;
>> In 2.3. I see. Thanks.
>>> however, in
>>> 2.4, it is always enabled, but it still must be explicitly exposed in
>>> slapd.conf/slapd.d by using "database monitor".
>> Ah, understood.
>>> I would replace
>>> "enabled" with "exposed", and possibly explicitly indicate that in 2.4
>>> it is no longer an option to build the monitor interface.
>> Yes, that sounds fine.
>>> No global directive should occur after "database monitor", as it
>>> represents a database instantiation like any other. Although most
>>> global directives wouldn't complain if appearing __after__ a database
>>> instantiation, such use should be considered at least "bad practice".
>> OK. But I was right with the fact you can put rootpw directly beneath
>> or is that what you are saying about bad practices?
> "rootdn" and "rootpw" are per-database directives. They __have__ to go
> there. What I call "bad practice" is, say, putting a "threads"
> directive inside a database. It will be handled as expected, i.e. it
> impacts the whole instance of slapd, but it appears like it were for
> that database only!
Ah yes! ;-) Agreed and now understood.
>>> About access control, it may be worth stressing that some attributes
>>> actually be written; this requires to protect them and, at the same
>>> time, to grant the desired identities write privileges on them.
>> Only with the rootpw defined?
> back-monitor honors access control much like any other database (at
> least it should; if it doesn't, then it's a bug).
> So any ACL applies (should apply) and as such there's much freedom in
> defining who has access to what under which circumstances. So I don't
> see any need to write any specific information about access control, as
> soon as the administrator is warned that access control needs to be
> taken into account for that database as well.
>> If so;
>> What attributes can be written to?
> AFAIR: managedInfo and derived attrs are writable; practically, they can
> only be written whenever a modify hook is defined for that subsystem,
> and constraints may be present.
> managedInfo can be written in "cn=Log,cn=Monitor" but it can only take
> the values that are allowed as loglevels (see loglevel in slapd.conf(5),
> but note that in HEAD, and possibly in 2.3 as well, I don't remember,
> modules can add further log levels).
OK. This should be all documented! ;-)
> readOnly can be written in each database entry (those residing below
> I'm not sure there' any more in stock back-monitor; but beware that
> back-monitor can be extended by modules through an API, so there might
> be more. In general, look for any modify hook in the definition of each
Modules, as in overlays? That was what my last question was really asking.
For example, how accesslog is used by Delta-Syncrepl. I was merely trying
to understand if, when some other feature gets enabled, it relies on
back-monitor to work properly.
>> What are their purpose/effects?
> perform non-persistent state changes (i.e. changes that are not
> reflected in back-config and don't et to the persistent storage on disk
> when the system is arrested.
>> What ACL example can we show to protect them?
> I don't think anything relevant is needed; in case, something like
> # only let the manager rite managed info (add further modifiable attrs)
> access to attrs=managedInfo
> by dn.exact="cn=Manager" write
> by * read
> # only let the manager read connections data (may be sensible)
> access to dn.children="cn=Connections,cn=Monitor"
> by dn.exact="cn=Manager" read
> by * none
> # allow read access to anything else
> access to *
> by * read
> unless there's anything else worth protecting.
Looks standard enough.
>> Are they used by any overlays/backends?
> Not sure I got the point.
See my above comment regarding accesslog.
Thanks for your time.
> Ing. Pierangelo Masarati
> OpenLDAP Core Team
> SysNet s.n.c.
> Via Dossi, 8 - 27100 Pavia - ITALIA
> Office: +39.02.23998309
> Mobile: +39.333.4963172
> Email: firstname.lastname@example.org