[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#4770) monitoringslapd.sdf patch
<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".
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?
>
> 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?
If so;
What attributes can be written to?
What are their purpose/effects?
What ACL example can we show to protect them?
Are they used by any overlays/backends?
>
> Sorry I haven't time to go into too much detail. Anyway, it seems
> you're doing a great job.
>
> Thanks, p.
>
Your thanks is much appreciated.
Gavin.
--
Kind Regards,
Gavin Henry.
Managing Director.
T +44 (0) 1224 279484
M +44 (0) 7930 323266
F +44 (0) 1224 824887
E ghenry@suretecsystems.com
Open Source. Open Solutions(tm).
http://www.suretecsystems.com/