[PATCH] IPA: lookup idview name even if there is no master domain

[Sumit Bose]

Hi,

these two patches fixes and issue which was reported on
https://www.redhat.com/archives/freeipa-users/2016-February/msg00148.html
and is now tracked in https://fedorahosted.org/sssd/ticket/2960 .

The first patch makes sure the view name is read even if there is an
error with the master domain lookup.

The second patch makes sure that SSSD will pick up the new override data
immediately after the upgrade without additional changes. This change is
needed because currently SSSD assumes that the cache was empty if no
view name was read from the cache and does not cleanup the override
data. But if a version of SSSD with the issue fixed by the first patch
was run before the cache will contain the override data for the default
view which most be removed to make sure SSSD will read the new override
data.

To reproduce use a FreeIPA where ipa-adtrust-install was not run, add a
new idview and assign it to an IPA client. Without the patch the IPA
client will continue to show the default IPA user data and no override
value.

bye,
Sumit

[Jakub Hrozek]

On Mon, Feb 22, 2016 at 06:40:44PM +0100, Sumit Bose wrote:
>  Hi,
>  
>  these two patches fixes and issue which was reported on
>  https://www.redhat.com/archives/freeipa-users/2016-February/msg00148.html
>  and is now tracked in https://fedorahosted.org/sssd/ticket/2960 .
>  
>  The first patch makes sure the view name is read even if there is an
>  error with the master domain lookup.
>  
>  The second patch makes sure that SSSD will pick up the new override data
>  immediately after the upgrade without additional changes. This change is
>  needed because currently SSSD assumes that the cache was empty if no
>  view name was read from the cache and does not cleanup the override
>  data. But if a version of SSSD with the issue fixed by the first patch
>  was run before the cache will contain the override data for the default
>  view which most be removed to make sure SSSD will read the new override
>  data.
>  
>  To reproduce use a FreeIPA where ipa-adtrust-install was not run, add a
>  new idview and assign it to an IPA client. Without the patch the IPA
>  client will continue to show the default IPA user data and no override
>  value.
>  
>  bye,
>  Sumit 
The code looks good to me and applying different views still work fine,
the views are detected and the view data invalidated.

At the moment, my test servers are all trust-enabled, so I would prefer
to test better when we merge the patches that depend on trusts.

But so far tentative ACK..

[Jakub Hrozek]

On Tue, Feb 23, 2016 at 03:26:57PM +0100, Jakub Hrozek wrote:
>  On Mon, Feb 22, 2016 at 06:40:44PM +0100, Sumit Bose wrote:
>  > Hi,
>  > 
>  > these two patches fixes and issue which was reported on
>  > https://www.redhat.com/archives/freeipa-users/2016-February/msg00148.html
>  > and is now tracked in https://fedorahosted.org/sssd/ticket/2960 .
>  > 
>  > The first patch makes sure the view name is read even if there is an
>  > error with the master domain lookup.
>  > 
>  > The second patch makes sure that SSSD will pick up the new override data
>  > immediately after the upgrade without additional changes. This change is
>  > needed because currently SSSD assumes that the cache was empty if no
>  > view name was read from the cache and does not cleanup the override
>  > data. But if a version of SSSD with the issue fixed by the first patch
>  > was run before the cache will contain the override data for the default
>  > view which most be removed to make sure SSSD will read the new override
>  > data.
>  > 
>  > To reproduce use a FreeIPA where ipa-adtrust-install was not run, add a
>  > new idview and assign it to an IPA client. Without the patch the IPA
>  > client will continue to show the default IPA user data and no override
>  > value.
>  > 
>  > bye,
>  > Sumit
>  
>  The code looks good to me and applying different views still work fine,
>  the views are detected and the view data invalidated.
>  
>  At the moment, my test servers are all trust-enabled, so I would prefer
>  to test better when we merge the patches that depend on trusts.
>  
>  But so far tentative ACK.. 
I can confirm the patches work for me fine on a client of a server with
no trust established: ACK

CI: http://sssd-ci.duckdns.org/logs/job/37/78/summary.html

[Jakub Hrozek]

On Thu, Feb 25, 2016 at 11:26:13AM +0100, Jakub Hrozek wrote:
>  On Tue, Feb 23, 2016 at 03:26:57PM +0100, Jakub Hrozek wrote:
>  > On Mon, Feb 22, 2016 at 06:40:44PM +0100, Sumit Bose wrote:
>  > > Hi,
>  > > 
>  > > these two patches fixes and issue which was reported on
>  > > https://www.redhat.com/archives/freeipa-users/2016-February/msg00148.html
>  > > and is now tracked in https://fedorahosted.org/sssd/ticket/2960 .
>  > > 
>  > > The first patch makes sure the view name is read even if there is an
>  > > error with the master domain lookup.
>  > > 
>  > > The second patch makes sure that SSSD will pick up the new override data
>  > > immediately after the upgrade without additional changes. This change is
>  > > needed because currently SSSD assumes that the cache was empty if no
>  > > view name was read from the cache and does not cleanup the override
>  > > data. But if a version of SSSD with the issue fixed by the first patch
>  > > was run before the cache will contain the override data for the default
>  > > view which most be removed to make sure SSSD will read the new override
>  > > data.
>  > > 
>  > > To reproduce use a FreeIPA where ipa-adtrust-install was not run, add a
>  > > new idview and assign it to an IPA client. Without the patch the IPA
>  > > client will continue to show the default IPA user data and no override
>  > > value.
>  > > 
>  > > bye,
>  > > Sumit
>  > 
>  > The code looks good to me and applying different views still work fine,
>  > the views are detected and the view data invalidated.
>  > 
>  > At the moment, my test servers are all trust-enabled, so I would prefer
>  > to test better when we merge the patches that depend on trusts.
>  > 
>  > But so far tentative ACK..
>  
>  I can confirm the patches work for me fine on a client of a server with
>  no trust established: ACK
>  
>  CI: http://sssd-ci.duckdns.org/logs/job/37/78/summary.html 
master:
    b5d48539966aefbea703377ba2ebcb67f9cf88b8
    b25d33b0a775e2337014a334699156ac56b08f9b 
sssd-1-13:
    022e4575980324c2c68a05b3f250bd1a72bc9885
    1d4d3f15b5cb9b9ffad521ddea0b1e3660587816