Hi Stefan, On 4/25/07, Stefan Seelmann <[EMAIL PROTECTED]> wrote:
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.
Oh coolio! 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.
Hmm this is a tough one. Really (objectClass=*) is a relaxed form of the (objectClass=subschema) so why should it not return (I know I coded it to return only when you ask for subschema). I wonder if the RFC allows for the * version? Unfortunately I'm taking care of some last minute errands today but I will investigate this later. Perhaps a JIRA is in order just so we can come to a conclusion on this and change either LS or ApacheDS to suite the proper behavoir. Thanks for the investigation, Alex
