[Date Prev][Date Next]
Re: denyop (Was: commit: ldap/servers/slapd/back-monitor back-monitor.h database.c init.c proto-back-monitor.h)
- To: "Kurt D. Zeilenga" <Kurt@OpenLDAP.org>
- Subject: Re: denyop (Was: commit: ldap/servers/slapd/back-monitor back-monitor.h database.c init.c proto-back-monitor.h)
- From: Pierangelo Masarati <email@example.com>
- Date: Sat, 01 May 2004 12:21:02 +0200
- Cc: hyc@OpenLDAP.org, OpenLDAP Commit <openldap-devel@OpenLDAP.org>
- References: <200404262356.i3QNucuB084559@cantor.openldap.org> <firstname.lastname@example.org>
- User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003
Kurt D. Zeilenga wrote:
As I noted in denyops discussions, we should allow the
restrict op flags to be individually set. That is,
'readonly on' should be complemented by:
If we do that, then it seems odd to have readOnly boolean
in back-monitor. Maybe we should have a multi-valued
(the last is food for thought)
I would separate the two issues based on the context they may be used.
This would clarify that both attributes (at least both principles) are
useful. The "denyop" approach should be intended as a means to
fine tuning what operations a database can be used for; the "readOnly"
apporach would be rather administrative, i.e. used by an administrative
entity to operate temporary mode changes, e.g. right before changing
the configuration in a way that requires disabling of write operations
(e.g. the schema is being changed, a replica is being added or so).
In this sense, "denyop" would be nearly permamnent, and fine tuning
is desirable; "readOnly" would be mostly temporary, and coarse but
quick'n'easy write disabling would be preferable. In this sense I'm in
favour of a multi-valued "denyOp" attribute, plus a boolean "readOnly"
that, when set, overrides the write "denyOp" values (simply, it's honored
before "denyOp" is checked).