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

Re: resynchronizing partial replica after ACL change

Howard Chu wrote:
> Ferenc Wagner wrote:
>> Howard Chu <hyc@symas.com> writes:
>>> Ferenc Wagner wrote:
>>>> I'm running a couple of partial replicas, where the replicated content
>>>> is narrowed by provider ACLs.  All is fine.  Now, I need to extend the
>>>> replicas with a new attribute, so I extend the ACL to allow reading of
>>>> this attribute as well.  How can I get the replicas synchronize this new
>>>> attribute without downtime?  Is forcing a full reload by slapd -c rid=1
>>>> a good solution?
>>> That should work, for a standard provider/consumer replication.
>> Pretty standard, I guess.  But for the future: where's the catch?  For what
>> setups would this fail to work?
> In MMR, updates whose entryCSN match the entry's existing entryCSN will be
> ignored, so a resync attempt like this won't change anything.
>> Also, this slapd restart mean at least some downtime.  Is there a way to
>> trigger such resync online, without slapd being stopped at all?  If not,
>> is there a fundemental problem stopping the implementation of such a
>> feature?
> Submit an enhancement request to the ITS, find someone interested in coding it.

I vaguely remember that Kurt once had the idea of "touching" an entry by
sending a modify request with empty modlist.

If this "touch" would update 'entryCSN' it would be a better approach than
full re-sync in case of fairly small count of affected entries.
Or maybe better use an extended control for this to avoid interop issues with
broken clients accidently sending such a empty modify list.

Since such a functionality would be also interesting for other LDAP server
implementations discussion on ldapext mailing list / WG ;-) would be appropriate.

Ciao, Michael.

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature