At 01:23 PM 12/7/2006, hyc@symas.com wrote:
ghenry@suretecsystems.com wrote:
Full_Name: Gavin Henry Version: 2.3.30 OS: FC6 URL: http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch Submission from: (NULL) (212.159.59.85)
Hi all,
Monitoring section updated. Please review and provide feedback.
Thanks,
Gavin.
(http://www.suretecsystems.com/our_docs/admin-guide-monitoring.patch)
At the moment the only comment I have is regarding back-monitor itself, not the doc: I question the decision to define the monitor info attributes as operational instead of user attributes. Requiring the use of "+" to return all of the monitored info seems pretty unfriendly, particularly since it causes the return of actual operational attributes that are completely irrelevant to the purpose of monitoring. I.e., the monitor info should be considered to be dynamically generated user attributes, not operational attributes.
[moved to devel]
Well, from a data model perspective, the attributes seems to belong to directory system agent, not user applications. Their values do change at the whim of the directory system agent. Also, if they were user applications attributes, they couldn't disallow user modification in their descriptions (modification would have to be denied by other means).
I do note that these attributes really should have usage dSAOperation not directoryOperation.
-- Kurt
--On Thursday, December 07, 2006 2:27 PM -0800 "Kurt D. Zeilenga" Kurt@OpenLDAP.org wrote:
[moved to devel]
Well, from a data model perspective, the attributes seems to belong to directory system agent, not user applications. Their values do change at the whim of the directory system agent. Also, if they were user applications attributes, they couldn't disallow user modification in their descriptions (modification would have to be denied by other means).
I do note that these attributes really should have usage dSAOperation not directoryOperation.
I think one could argue that in this case, slapd is the user application, and this is the data it is maintaining. I also find the marking of them as operational as somewhat misleading.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
At 03:14 PM 12/7/2006, Quanah Gibson-Mount wrote:
--On Thursday, December 07, 2006 2:27 PM -0800 "Kurt D. Zeilenga" Kurt@OpenLDAP.org wrote:
[moved to devel]
Well, from a data model perspective, the attributes seems to belong to directory system agent, not user applications. Their values do change at the whim of the directory system agent. Also, if they were user applications attributes, they couldn't disallow user modification in their descriptions (modification would have to be denied by other means).
I do note that these attributes really should have usage dSAOperation not directoryOperation.
I think one could argue that in this case, slapd is the user application, and this is the data it is maintaining.
One can argue just about anything...
I also find the marking of them as operational as somewhat misleading.
Hmm.. the attribute are in the DsaIT not the DIT, not in a naming context (and cannot be instantitate in the DIT), take values specific to the DSA, have DSA local names, user changes to them impact DSA behavior (like changes to the log level), and are generally maintained by the DSA. I think it would be misleading not to mark them as operational, and specifically dSAOperation.
For monitoring clients (like all LDAP specific-purpose clients), they really should just ask for the particular monitor attributes they support, possibly using the @objectClass mechanism.
For browsing by humans (generally an administrator), the human can just ask for * and +.
--Quanah
-- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html
Quanah Gibson-Mount wrote:
--On Thursday, December 07, 2006 2:27 PM -0800 "Kurt D. Zeilenga" Kurt@OpenLDAP.org wrote:
[moved to devel]
Well, from a data model perspective, the attributes seems to belong to directory system agent, not user applications. Their values do change at the whim of the directory system agent. Also, if they were user applications attributes, they couldn't disallow user modification in their descriptions (modification would have to be denied by other means).
I do note that these attributes really should have usage dSAOperation not directoryOperation.
I think one could argue that in this case, slapd is the user application, and this is the data it is maintaining. I also find the marking of them as operational as somewhat misleading.
When generating schema-based input forms in web2ldap I'm treating operational attributes like not editable (except if relax rules control is in effect). I'd like to keep it that way.
=> +1 for defining monitored attributes as operational
web2ldap also obeys NO-USER-MODIFICATION off course...
Ciao, Michael.
-
Kurt D. Zeilenga -
Michael Ströder -
Quanah Gibson-Mount