[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.


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).