On Tue, 2012-11-13 at 23:00 +0100, Martin Kosek wrote:
> On 11/13/2012 08:49 PM, Simo Sorce wrote:
> > On Tue, 2012-11-13 at 18:20 +0100, Martin Kosek wrote:
> >> On 11/13/2012 06:05 PM, Simo Sorce wrote:
> >>> On Tue, 2012-11-13 at 17:46 +0100, Martin Kosek wrote:
> >>>> Index task need to be run for both index updates and new indexes,
> >>>> otherwise some current values may not be indexed and could cause
> >>>> issues when searching LDAP (like fqdn did).
> >>>>
> >>>> https://fedorahosted.org/freeipa/ticket/3253
> >>>>
> >>>> ---
> >>>>
> >>>> This patch should be the only patch in the upcoming FreeIPA 2.2.2 bug fix
> >>>> release (unless we want to backport more patches to 2.2 line). It should 
> >>>> fix a
> >>>> severe issue when SSSD was no longer able to authenticate users against 
> >>>> the
> >>>> update 2.2.1 FreeIPA server.
> >>>>
> >>>> I specifically updated all index updates (even when the index definition 
> >>>> is
> >>>> already in LDAP) to make sure we fix any index that where the upgrade 
> >>>> failed
> >>>> previously due to this bug. FreeIPA 3.0+ packages already contains a 
> >>>> patch
> >>>> (2ecfe571faf9291eab7ffacea2a1e94d5be0d689) to run index task for really
> >>>> new/updated indexes only, but I would not backport that patch due to 
> >>>> messed
> >>>> fqdn index in 2.2.1.
> >>>>
> >>>> After the patch, 2.2.0 (2.2.1) -> 2.2.2 upgrade procedure should create 
> >>>> all
> >>>> required indexes, including fqdn index:
> >>>>
> >>>> # rpm -Uvh --force ~/freeipa-2-2-0/dist/rpms/freeipa-*
> >>>> Preparing...                ########################################### 
> >>>> [100%]
> >>>>     1:freeipa-python         ########################################### 
> >>>> [ 17%]
> >>>>     2:freeipa-client         ########################################### 
> >>>> [ 33%]
> >>>>     3:freeipa-admintools     ########################################### 
> >>>> [ 50%]
> >>>>     4:freeipa-server         ########################################### 
> >>>> [ 67%]
> >>>> ipa: INFO: /usr/share/ipa/html/krb.js exists, skipping install of 
> >>>> Firefox extension
> >>>>     5:freeipa-server-selinux ########################################### 
> >>>> [ 83%]
> >>>>     6:freeipa-debuginfo      ########################################### 
> >>>> [100%]
> >>>>
> >>>> # grep "Creating task to index" /var/log/ipaupgrade.log
> >>>> 2012-11-13T16:06:35Z INFO Creating task to index attribute: memberuid
> >>>> 2012-11-13T16:06:41Z INFO Creating task to index attribute: memberOf
> >>>> 2012-11-13T16:06:47Z INFO Creating task to index attribute: memberHost
> >>>> 2012-11-13T16:06:53Z INFO Creating task to index attribute: memberUser
> >>>> 2012-11-13T16:06:59Z INFO Creating task to index attribute: fqdn    
> >>>> <<<<<<
> >>>> 2012-11-13T16:07:05Z INFO Creating task to index attribute: ntUniqueId
> >>>> 2012-11-13T16:07:11Z INFO Creating task to index attribute: 
> >>>> ntUserDomainId
> >>>>
> >>>
> >>> Martin, does this means we run these task for every rpm upgrade
> >>> regardless ? Or do we mark indexes as regenerated and do not repeat on
> >>> the following rpm upgrade ?
> >>>
> >>> Simo.
> >>>
> >>
> >> In FreeIPA 2.* we run these task for every RPM upgrade - regardless to the
> >> update status. I fixed that behavior in FreeIPA 3.0 where we now only run 
> >> the
> >> index task when the index is really updated or added (there is more 
> >> reasoning
> >> above, but I am open to suggestions).
> >
> > Ah as long as it works properly in 3.0 that good enough, I do not think
> > we'll release too many updates to 2.x anymore so it is ok as is.
> >
> > Simo.
> >
> 
> Right. My target was to have a FreeIPA 2.x with valid indexes so that we can 
> use the new index behavior in 3.x which runs indexes only when they are 
> changed 
> (which would otherwise fail in this case when index object in LDAP exists but 
> index task was not run).
> 
> Other option would be to backport this behavior to 2.2.2 but implement 
> routine 
> which would check that at least one index task was run for every index object 
> in LDAP - and if not, it would fire the missing index task. But this may be 
> an 
> overkill for this case.

I think it would be nice to have such a mechanism long term, as it would
help in rare case where update may fail midway but can be restarted.
however not needed right now, might be worth a nice to have ticket for a
future version

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to