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.