Hi!
I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree.
Seeing those operational atributes, I noticed that "creatorsName" and "modifiersName" are both present but have an empty value. That doesn't look very nice, especially as createTimestamp and modifyTimestamp do have proper values.
Using monitoredObject for all monitored values gives a unique interface, but having all possible results in monitoredInfo is not very usable, especially if there's no description. For example (some attributes removed for brevity): --- dn: cn=Uptime,cn=Time,cn=Monitor structuralObjectClass: monitoredObject monitoredInfo: 153543 hasSubordinates: FALSE --- It's not clear (denying the obvious) what the units of uptime are: seconds, minutes, etc. It seems to me that "monitoredType" or "monitoredInfoType" and "monitoredUnit" (for measurable infos) are missing.
Shouldn't "monitorCounter" be named "monitoredCounter" to use the same pattern as "monitoredInfo"?
I could not find the schema for the monitoring objects in any file. Can I retrieve a readable schema from openLDAP?
The other thing is that I'm not too happy with are spaces in RDNs, like " cn=Connection 2111,cn=Connections,cn=Monitor", or "cn=Database 2,cn=Databases,cn=Monitor". I'd prefer are more common pattern for IDs like "Connection-2111" or "Connection_2111".
Also: is "cn=Connection 0,cn=Connections,cn=Monitor" a bug? I see it twice: --- dn: cn=Connection 0,cn=Connections,cn=Monitor structuralObjectClass: monitorConnection (...) monitorConnectionNumber: 0 monitorConnectionProtocol: 0 monitorConnectionOpsReceived: 0 monitorConnectionOpsExecuting: 0 monitorConnectionOpsPending: 0 monitorConnectionOpsCompleted: 0 monitorConnectionGet: 0 monitorConnectionRead: 0 monitorConnectionWrite: 0 monitorConnectionMask: L monitorConnectionListener: monitorConnectionPeerDomain: unknown monitorConnectionPeerAddress: unknown monitorConnectionLocalAddress: monitorConnectionStartTime: 19700101000000Z monitorConnectionActivityTime: 19700101000000Z (...) ---
Regards, Ulrich
Am Wed, 27 Nov 2013 09:09:35 +0100 schrieb "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de:
Hi!
I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree.
Seeing those operational atributes, I noticed that "creatorsName" and "modifiersName" are both present but have an empty value. That doesn't look very nice, especially as createTimestamp and modifyTimestamp do have proper values.
RFC-4512 requires that this attributes must be present in every entry.
Using monitoredObject for all monitored values gives a unique interface, but having all possible results in monitoredInfo is not very usable, especially if there's no description. For example (some attributes removed for brevity): --- dn: cn=Uptime,cn=Time,cn=Monitor structuralObjectClass: monitoredObject monitoredInfo: 153543 hasSubordinates: FALSE
It's not clear (denying the obvious) what the units of uptime are: seconds, minutes, etc. It seems to me that "monitoredType" or "monitoredInfoType" and "monitoredUnit" (for measurable infos) are missing.
Shouldn't "monitorCounter" be named "monitoredCounter" to use the same pattern as "monitoredInfo"?
I could not find the schema for the monitoring objects in any file. Can I retrieve a readable schema from openLDAP?
it is in the source code, see openldap/servers/slapd/back-monitor/README and back-monitor.h
[...]
-Dieter
Dieter Klünterdieter@dkluenter.de schrieb am 27.11.2013 um 10:34 in
Nachricht 20131127103401.4123cbab@pink.avci.de:
Am Wed, 27 Nov 2013 09:09:35 +0100 schrieb "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de:
Hi!
I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree.
Seeing those operational atributes, I noticed that "creatorsName" and "modifiersName" are both present but have an empty value. That doesn't look very nice, especially as createTimestamp and modifyTimestamp do have proper values.
RFC-4512 requires that this attributes must be present in every entry.
No problem, but couldn't be the creator's and modifier's names be something like "slapd"?
Using monitoredObject for all monitored values gives a unique interface, but having all possible results in monitoredInfo is not very usable, especially if there's no description. For example (some attributes removed for brevity): --- dn: cn=Uptime,cn=Time,cn=Monitor structuralObjectClass: monitoredObject monitoredInfo: 153543 hasSubordinates: FALSE
It's not clear (denying the obvious) what the units of uptime are: seconds, minutes, etc. It seems to me that "monitoredType" or "monitoredInfoType" and "monitoredUnit" (for measurable infos) are missing.
Shouldn't "monitorCounter" be named "monitoredCounter" to use the same pattern as "monitoredInfo"?
I could not find the schema for the monitoring objects in any file. Can I retrieve a readable schema from openLDAP?
it is in the source code, see openldap/servers/slapd/back-monitor/README and back-monitor.h
I'd prefer it to be in the retrievable schema ;-)
BTW: I noticed that there is no schema for entryCSN neither...
Ulrich
[...]
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E
Ulrich Windl wrote:
BTW: I noticed that there is no schema for entryCSN neither...
See doc/drafts/draft-chu-ldap-csn-xx.txt
Howard Chu wrote:
Ulrich Windl wrote:
BTW: I noticed that there is no schema for entryCSN neither...
See doc/drafts/draft-chu-ldap-csn-xx.txt
This is one of those things a generic LDAP client has to be prepared to handle with some fall-back mechanism.
You can enable this hidden experimental OID .666. schema by compiling with -DSLAP_SCHEMA_EXPOSE compiler flag.
See some notes about it here:
http://www.stroeder.com/download/Presentation_LDAPcon2013_Michael_Stroeder_D...
See my semi-rant years ago:
http://www.mail-archive.com/openldap-its@openldap.org/msg04592.html
Ciao, Michael.
Howard Chu hyc@symas.com schrieb am 27.11.2013 um 17:32 in Nachricht
Ulrich Windl wrote:
BTW: I noticed that there is no schema for entryCSN neither...
See doc/drafts/draft-chu-ldap-csn-xx.txt
ACK! Is there a ready-to-use schema file around? Preferrably one that has all the stuff openLDAP uses, but is missing in the standard schemata. The schemas I have installed are:
amavisd-new.schema collective.schema corba.schema core.schema cosine.schema dnszone.schema duaconf.schema dyngroup.schema inetorgperson.schema java.schema ldapns.schema misc.schema nis.schema openldap.schema pmi.schema ppolicy.schema pureftpd.schema rfc2307bis.schema samba3.schema sudo.schema suse-mailserver.schema yast.schema
Regards, Ulrich
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Am Wed, 27 Nov 2013 09:09:35 +0100 schrieb "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de:
Hi!
I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree.
The other thing is that I'm not too happy with are spaces in RDNs, like " cn=Connection 2111,cn=Connections,cn=Monitor", or "cn=Database 2,cn=Databases,cn=Monitor". I'd prefer are more common pattern for IDs like "Connection-2111" or "Connection_2111".
In fact spaces in a commonName attribute value are in accordance with X.520 practice.
-Dieter
Dieter Klünterdieter@dkluenter.de schrieb am 27.11.2013 um 11:15 in
Nachricht 20131127111527.0e561508@pink.avci.de:
Am Wed, 27 Nov 2013 09:09:35 +0100 schrieb "Ulrich Windl" Ulrich.Windl@rz.uni-regensburg.de:
Hi!
I found out why I never was successful with cn=monitor: By default '*' attributes show almost nothing; you'll have to use '+' attributes (in my version at least). I'm not very happy with the decision, because you'll get the truely operational attributes also. If the whole subtree cn=Monitor is invisible in naming contexts, I see little reason to hide the "normal" attributes as operational in the whole subtree.
The other thing is that I'm not too happy with are spaces in RDNs, like " cn=Connection 2111,cn=Connections,cn=Monitor", or "cn=Database 2,cn=Databases,cn=Monitor". I'd prefer are more common pattern for IDs like "Connection-2111" or "Connection_2111".
In fact spaces in a commonName attribute value are in accordance with X.520 practice.
Hi!
I believe that, but when printed two spaces look very similar to one space, and as I guess every space is significant, you can probably have "Joe OneSpace" and "Joe TwoSpaces" as RDN. I guess you cannot enter Joue Twospaces with just one space, opening a can of worms...
Regards, Ulrich
-Dieter
-- Dieter Klünter | Systemberatung http://dkluenter.de GPG Key ID:DA147B05 53°37'09,95"N 10°08'02,42"E
Ulrich Windl wrote:
Dieter Klünterdieter@dkluenter.de schrieb am 27.11.2013 um 11:15 in
In fact spaces in a commonName attribute value are in accordance with X.520 practice.
Hi!
I believe that, but when printed two spaces look very similar to one space, and as I guess every space is significant, you can probably have "Joe OneSpace" and "Joe TwoSpaces" as RDN.
Read RFC4518, don't guess.
Howard Chu hyc@symas.com schrieb am 27.11.2013 um 17:35 in Nachricht
Ulrich Windl wrote:
Dieter Klünterdieter@dkluenter.de schrieb am 27.11.2013 um 11:15 in
In fact spaces in a commonName attribute value are in accordance with X.520 practice.
Hi!
I believe that, but when printed two spaces look very similar to one
space,
and as I guess every space is significant, you can probably have "Joe
OneSpace"
and "Joe TwoSpaces" as RDN.
Read RFC4518, don't guess.
You mean?
"For instance, the caseIgnoreMatch matching rule may be used to compare whether the commonName attribute contains a particular value without regard for case and insignificant spaces."
"The caseIgnoreMatch matching rule [X.520], for example, is simply defined as being a case-insensitive comparison where insignificant spaces are ignored."
What's an "insignificant space, BTW."?
At some parts that text is quite confusing, like: (2.6.1. Insignificant Space Handling) "If the input string contains no non-space character, then the output is exactly two SPACEs."
Still I wonder whether avoiding a SPACE in the DNs of the monitoring tree would have been the easier approach...
Regards, Ulrich
Ulrich Windl wrote:
Howard Chu hyc@symas.com schrieb am 27.11.2013 um 17:35 in Nachricht
Ulrich Windl wrote:
Dieter Klünterdieter@dkluenter.de schrieb am 27.11.2013 um 11:15 in
In fact spaces in a commonName attribute value are in accordance with X.520 practice.
Hi!
I believe that, but when printed two spaces look very similar to one
space,
and as I guess every space is significant, you can probably have "Joe
OneSpace"
and "Joe TwoSpaces" as RDN.
Read RFC4518, don't guess.
You mean?
"For instance, the caseIgnoreMatch matching rule may be used to compare whether the commonName attribute contains a particular value without regard for case and insignificant spaces."
"The caseIgnoreMatch matching rule [X.520], for example, is simply defined as being a case-insensitive comparison where insignificant spaces are ignored."
What's an "insignificant space, BTW."?
AFAIK leading or trailing spaces are insignificant when matching.
Ciao, Michael.
openldap-technical@openldap.org
-
Dieter Klünter -
Howard Chu -
Michael Ströder -
Ulrich Windl