Hi,
On Wed, Jun 4, 2008 at 2:20 PM, Hallvard B Furuseth
h.b.furuseth@usit.uio.no wrote:
I haven't follwed this ITS, but a few notes anyway:
unix.gurus@gmail.com writes:
monitorCounter
monitorCounter does not have an equality matching rule,
Yes it does. back-monitor/init.c line 1710. What are you looking at?
(Hmm, I too had the impression it had no EQUALITY rule...)
I'm working with OpenLDAP 2.4.9.
You're right. integerMatch has an equality rule but no normalizing
function. The logic that determines whether a normalized value should
exist says:
have_norm = a->a_desc->ad_type->sat_equality != NULL &&
a->a_desc->ad_type->sat_equality->smr_normalize != NULL;
...
new_nval = nvals != NULL;
...
if ( have_norm != new_nval ) {
assert()
So we don't need nvals for integers. For this reason I was right to
remove the nval for monitorCounter, monitorOpInitiated,
monitorOpCompleted, but my reasoning was wrong.
monitorOpCompleted
monitorOpInitiated
These attributes do not have equality matching rules,
These do too, inherited from monitorCounter.
See above.
it doesn't work right in 2.3 however:
ldapsearch -LLL -bcn=monitor -s one '(monitorCounter=0)' monitorCounter
dn: cn=Operations,cn=Monitor
monitorOpInitiated: 231542983
monitorOpCompleted: 231542982
I wonder if val is being maintained and nval is being left at 0. The
code at the end of monitor_subsys_ops_update() maintains a_vals but
not a_nvals, so that is probably the problem:
/* NOTE: no minus sign is allowed in the counters... */
UI2BV( &a->a_vals[ 0 ], nInitiated );
ldap_pvt_mp_clear( nInitiated );
...
/* NOTE: no minus sign is allowed in the counters... */
UI2BV( &a->a_vals[ 0 ], nCompleted );
ldap_pvt_mp_clear( nCompleted );
namingContexts
configContext
dynamicSubtrees
These attributes do not have equality matching rules, but probably
should. I add 'EQUALITY distinguishedNameMatch' to them in
schema_prep.c.
No, that breaks the definitions in the RFCs they come from. (See their
DESC strings.) I don't know why they lack EQUALITY rules, maybe we just
forgot when we defined them, but that's the way it is. Same with
supportedControl.
Ok, so we should not define nvals for them?
monitorContext, readOnly and the olc* attributes are defined by OpenLDAP
(their OIDs start with 1.3.6.1.4.1.4203) and can be modified if we feel
like it. Personally I prefer attrs to have the matching rules they can
have unless there is a reason not to, but I didn't write these modules
so I don't know if there _is_ a reason not to.
--
Thanks,
Sean Burford