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