Re: [Freeipa-devel] limiting SyncRepl's scope
On Wed, Dec 16, 2015 at 09:26:11AM +0100, Sumit Bose wrote: > On Wed, Dec 16, 2015 at 08:49:04AM +0100, Petr Spacek wrote: > > On 15.12.2015 19:10, Christian Heimes wrote: > > > Hi, > > > > > > in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has > > > suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes > > > vault-archive fails because of a failed write to the Retro Changelog. > > > The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967 > > > for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal > > > circumstances because 389 doesn't use SyncRepl for replication. In #3967 > > > Nathan has expressed his concerns for possible performance issues, too. > > > > > > Petr, Ludwig, > > > would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than > > > excluding o=ipaca? The plugin supports both includes and exclude, > > > http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html. > > > > >From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX. > > > > One other thing to consider is theoretical use of SyncRepl for future > > versions > > of slapi-nis, Alexander can tell you more about it. > > > > In any case, if we decide to limit scope where SyncRepl is applicable, I > > would > > like to see checks in SyncRepl plugin which will ensure that error > > UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a > > 'wrong' scope. > > > > There are discussions about using SyncRepl in SSSD as well which would > include users, groups, sudo and HBAC rules, trusted domains, ... But > afaik no work in the direction has been started yet, so it might be ok > to limit the scope for now and add it when there are patches for SSSD > which really try to use it. The more I was looking into the sssd performance problems in the last couple of weeks, the more I think we don't actually need syncrepl on the clients, maybe only in server mode sssd.. Even the refreshOnly mode has cost associated (IIRC Ludwig told me the server has to check all changelog entries since the cookie) and I think on the clients we could improve performance with looking up entries as we do now, checking if the modifyTimestamp has changed and if not, avoid the cache write as we discussed over the phone the other day. For server mode sssd, syncrepl might be interesting, yes. But as you said, so far I only looked into issues that would also benefit the pure client case. -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] limiting SyncRepl's scope
On Wed, Dec 16, 2015 at 08:49:04AM +0100, Petr Spacek wrote: > On 15.12.2015 19:10, Christian Heimes wrote: > > Hi, > > > > in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has > > suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes > > vault-archive fails because of a failed write to the Retro Changelog. > > The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967 > > for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal > > circumstances because 389 doesn't use SyncRepl for replication. In #3967 > > Nathan has expressed his concerns for possible performance issues, too. > > > > Petr, Ludwig, > > would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than > > excluding o=ipaca? The plugin supports both includes and exclude, > > http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html. > > >From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX. > > One other thing to consider is theoretical use of SyncRepl for future versions > of slapi-nis, Alexander can tell you more about it. > > In any case, if we decide to limit scope where SyncRepl is applicable, I would > like to see checks in SyncRepl plugin which will ensure that error > UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a > 'wrong' scope. > There are discussions about using SyncRepl in SSSD as well which would include users, groups, sudo and HBAC rules, trusted domains, ... But afaik no work in the direction has been started yet, so it might be ok to limit the scope for now and add it when there are patches for SSSD which really try to use it. bye, Sumit -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] limiting SyncRepl's scope
On 12/16/2015 08:49 AM, Petr Spacek wrote: On 15.12.2015 19:10, Christian Heimes wrote: Hi, in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes vault-archive fails because of a failed write to the Retro Changelog. The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967 for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal circumstances because 389 doesn't use SyncRepl for replication. In #3967 Nathan has expressed his concerns for possible performance issues, too. Petr, Ludwig, would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than excluding o=ipaca? The plugin supports both includes and exclude, http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html. From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX. One other thing to consider is theoretical use of SyncRepl for future versions of slapi-nis, Alexander can tell you more about it. In any case, if we decide to limit scope where SyncRepl is applicable, I would like to see checks in SyncRepl plugin which will ensure that error UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a 'wrong' scope. yes, that makes sense -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
Re: [Freeipa-devel] limiting SyncRepl's scope
On 15.12.2015 19:10, Christian Heimes wrote: > Hi, > > in ticket https://fedorahosted.org/freeipa/ticket/5538 Ludwig has > suggested to exclude Dogtag's o=ipaca tree from the changelog. Sometimes > vault-archive fails because of a failed write to the Retro Changelog. > The RetroCL was enabled in https://fedorahosted.org/freeipa/ticket/3967 > for the bind-dyndb-ldap plugin. Otherwise it is not needed under normal > circumstances because 389 doesn't use SyncRepl for replication. In #3967 > Nathan has expressed his concerns for possible performance issues, too. > > Petr, Ludwig, > would it makes sense to restrict RetroCL to cn=dns,$SUFFIX rather than > excluding o=ipaca? The plugin supports both includes and exclude, > http://directory.fedoraproject.org/docs/389ds/design/retrocl-scoping.html. >From IPA DNS perspective it is okay to limit SyncRepl to cn=dns,$SUFFIX. One other thing to consider is theoretical use of SyncRepl for future versions of slapi-nis, Alexander can tell you more about it. In any case, if we decide to limit scope where SyncRepl is applicable, I would like to see checks in SyncRepl plugin which will ensure that error UNWILLING_TO_PERFORM is returned when somebody attempts to use SyncRepl in a 'wrong' scope. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
