Hi Alex, Alex Karasulu schrieb: > Hi Stefan, > > I specifically had worked a JIRA issue to make sure the modify timestamp on > the > schema subentry at cn=schema was modified when there were any changes to > schema entries made via cn=schema modifs or changes made directly on schema > entries under ou=schema. However I may have botched this. I'm very > interested > in finding out if the timestamp update is failing. > > Alex >
The good news: timestamp update works fine. However I found the reason why LS fails to detect if the schema was modified. When connecting to the directory LS requests the attributes modifyTimestamp and createTimestamp by its names from the server, but they aren't returned: -------------------------------------------------------------- $ ldapsearch -x -h localhost -p 10389 -D "uid=admin,ou=system" -w "secret" -s base -b "cn=schema" "(objectClass=subschema)" modifyTimestamp # schema dn: 2.5.4.3=schema -------------------------------------------------------------- However when requesting *all* operational attributes the timestamps are returned: -------------------------------------------------------------- ldapsearch -x -h localhost -p 10389 -D "uid=admin,ou=system" -w "secret" -s base -b "cn=schema" "(objectClass=subschema)" "+" | grep "modifyTimestamp:" modifyTimestamp: 20070425172817Z -------------------------------------------------------------- I verified that with both 1.5.0 and the current trunk. Should I file a Jira? But also LS executes on invalid search resquest. RFC4512 specifies that the client must use the search filter "(objectClass=subschema)", LS sends "(objectClass=*)". It isn't a big deal to change that. Regards, Stefan Seelmann
