[Date Prev][Date Next]
I have a(n almost) fully featured implementation of RFC2589 by means of an
overlay that allows to intermix static and dynamic objects within any
naming context (handled by a backend that supports basic write operations:
add, modify, delete). It has minimal impact on slapd: essentially, I had
to rework the SLAPD_DYNAMIC() macro to also test the BackendDB flags and
not only the BackendInfo ones; plus, some limited work to allow presenting
the "dynamicSubtrees" in the root DSE. I also wrote the family of client
library functions that perform the refresh exop and a comprehensive test,
namely ldap_refresh(), ldap_refresh_s() and ldap_parse_refresh().
It needs some further development in the area of replication (could be
minimal, I haven't looked at it yet because we didn't need it); the
approach might not be the best: it's been designed for a limited number of
dynamic objects but accurate timing, so each object gets an entry in the
runqueue that is in charge of deleting it; a different approach could use
a single periodic thread that cleans up expired objects.
I need some help in cleaning up the exop stuff: I invented the tags for
each component of the request and response data (where am I supposed to
get them from?); also, there are some aspects of the RFC that I consider
flaws (but it might be related to my lack of understanding of the
terminology). For example (3.1, close to the end):
A non-dynamic entry cannot be added subordinate to a dynamic entry:
the server must return an appropriate update or service error if this
what is appropriate here? I used LDAP_CONSTRAINT_VIOLATION.
The responseTtl field is the time in seconds which the server chooses
to have as the time-to-live field for that entry. It must not be any
smaller than that which the client requested, and it may be larger.
However, to allow servers to maintain a relatively accurate
directory, and to prevent clients from abusing the dynamic
extensions, servers are permitted to shorten a client-requested
time-to-live value, down to a minimum of 86400 seconds (one day).
This sounds contradictory, because on the one hand it says the responseTtl
cannot be lower than the requestTtl; on the other hand it says that
servers can limit it to 86400 s; is this to be intended that in the case
the requestTtl is not acceptable the refresh has to be rejected?
I'll submit this feature as a patch shortly (maybe tomorrow); if there is
no objection, I'd like to commit it as soon as possible, because I'm
piling up a number of enhancements that affect the same files, so I'm
getting in trouble in keeping them up to date as HEAD code evolves.
I've seen that in Microsoft's implementation
the refresh can also be obtained by directly modifying the value of the
entryTtl attribute. In my implementation, I turn the refresh exop into an
internal modification of the entryTtl (which is NO-USER-MODIFICATION),
setting to "critical" the manageDIT flag of the internal operation; this
allows to control access to the exop by requiring manage access to the
entryTtl. I think we could also allow that direct operation, based on a
similar approach, i.e. explicitly requiring the manageDIT control and
manage privileges on that attribute, but I don't see an urgent need for
Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team
Via Dossi, 8 - 27100 Pavia - ITALIA