[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4770) monitoringslapd.sdf patch
<quote who="ando@sys-net.it">
> Gavin Henry wrote:
>> <quote who="Pierangelo Masarati">
>>> Gavin,
>>>
>>> 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".
Understood.
>>
>> OK. But I was right with the fact you can put rootpw directly beneath
>> it,
>> 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
>>> can
>>> 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.
OK.
>
>> 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
> "cn=Databases,cn=Monitor")
>
> 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
> subsystem.
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.
OK.
>
>> 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.
Gavin.
>
> 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
> ------------------------------------------
>
>
>