----- Original Message -----
On Sun, Sep 07, 2014 at 11:29:35PM -0400, Yassir Elley wrote:
> Hi,
>
> The attached patch fixes ticket #2431 (offline gpo processing yields
> incorrect results if "tattooing" occurs).
>
>
https://fedorahosted.org/sssd/ticket/2431.
>
> Regards,
> Yassir.
The patch works as expected, but:
1) When removing a GPO fails, do you think we should fail or try to
continue?
We exclusively rely on the contents of the sysdb cache only when we are in offline mode.
As such, if removing a GPO fails, it has no effect on the current (online) transaction,
since
we already know the applicable GPOs directly from the LDAP server. However, if we go
offline, and
there are still "stale" gpo cache entries in the sysdb cache (i.e. entries that
should have been removed),
then the gpo code will incorrectly continue to enforce those "stale" gpos.
Of course, if the current online transaction fails to delete a stale GPO, but a subsequent
online transaction
succeeds in deleting the GPO (before we have gone offline), then there is no problem.
However, since we can't
predict that this will happen, I think the appropriate thing to ensure correct behavior is
to fail if we are
unable to remove a stale GPO.
2) Why did you decide to remove stale entries instead of removing all
and then storing the ones you found?
I tried to remove all entries initially, but soon realized that the gpo code relies on the
cached gpoVersion
and gpoPolicyFileTimeout attributes as part of its online processing. If all entries are
initially removed,
then clearly these attributes will also be removed, rendering them useless, and doing away
with the performance
benefits that they offer.
3) While looking at the way we store the GPOs I realized we might not be
very effective. We should look into only using one sysdb transaction for
the whole operation of modifying the cache. This clearly needs to be
done in a separate commit, though.
The logic for the gpo-ldap code returns a set of applicable gpos.
Each gpo is then processed in turn, where such per-gpo processing includes:
* fork/exec'ing a gpo_child for the current_gpo
* interacting with the gpo_child for smb transactions related to the current_gpo
* storing the current_gpo's sysvol_gpt_version in the sysdb cache (returned by the
gpo_child)
* enforcing the current_gpo's policy settings
If there is concern about the performance hit of multiple sysdb transactions, this logic
will need to be modified.
One solution would be to send all applicable gpo's to the child in one go (rather than
one-by-one). This would also
allow a single gpo_child process to be used (rather than a separate gpo_child process per
gpo, as is currently implemented).
Regards,
Yassir.