Description of problem:
The problem is that when replicating schema, we filter all the attributes
except the "schema interesting attributes, that is to say:
static char *schema_interesting_attr_types[] = {
        "dITStructureRules",
        "nameForms",
        "dITContentRules",
        "objectClasses",
        "attributeTypes",
        "matchingRules",
        "matchingRuleUse",
        "ldapSyntaxes",
        "nsschemacsn",
        NULL
};
So, as modifytimestamp attribute is missing or not up to date, an application which checks schema changes using "modifytimestamp" attribute
is not working as expected.
Note: the priority is low.
How reproducible:
Always
Steps to Reproduce:
1, Add new objectclass to schema in MMR:
ldapmodify -p 1389 ... << EOF
dn: cn=schema
changetype: modify
add: objectclasses
objectclasses: ( mynewobj2-oid NAME 'mynewobj2' DESC '' SUP top STRUCTURAL
X-ORIGIN 'object class' )
EOF
2. Do any other update to allow schema replication:
 ldapmodify -p 1389 ...
dn: cn=user37,ou=people,o=redhat
changetype: modify
replace: sn
sn: newone
modifying entry "cn=user37,ou=people,o=redhat"
3. check schema repl has been done. And check modifytimestamp
# ldapsearch -xLLL  -p 1389 ... -b "cn=schema" objectclasses | grep mynewobj2-oid
objectclasses: ( mynewobj2-oid NAME 'mynewobj2' DESC '' SUP top STRUCTURAL X-O
# ldapsearch -xLLL  -p 2389 ... -b "cn=schema" objectclasses | grep mynewobj2-oid
objectclasses: ( mynewobj2-oid NAME 'mynewobj2' DESC '' SUP top STRUCTURAL X-O
#
# ldapsearch -xLLL -p 2389 -h localhost ... -b "cn=schema" modifytimestamp
dn: cn=schema
modifytimestamp: 20141216123736Z
# ldapsearch -xLLL -p 1389 ... -b "cn=schema" modifytimestamp
dn: cn=schema
modifytimestamp: 20141216125329Z
They are different.
Actual results:
modifytimestamp differs
Expected results:
modifytimestamp should match ?