[Date Prev][Date Next] [Chronological] [Thread] [Top]

RFC2589 implementation

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
   is attempted.

what is appropriate here?  I used LDAP_CONSTRAINT_VIOLATION.

(4.2):

   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
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/refreshing_a_dynamic_object.asp>
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
it.

p.



Ing. Pierangelo Masarati
Responsabile Open Solution
OpenLDAP Core Team

SysNet s.n.c.
Via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
------------------------------------------
Office:   +39.02.23998309          
Mobile:   +39.333.4963172
Email:    pierangelo.masarati@sys-net.it
------------------------------------------