On 11/13/2012 02:01 PM, Martin Kosek wrote:
> On 11/12/2012 05:44 PM, Anthony Messina wrote:
>> On Monday, November 12, 2012 09:51:14 AM Anthony Messina wrote:
>>> On Monday, November 12, 2012 09:17:17 AM Anthony Messina wrote:
>>>>>> I also find that when I do a manual ldapsearch for the
>>>>>> non-upgraded clients as >
>>>>>>
>>>>>> follows:
>>>>>>
>>>>>>
>>>>>> ldapsearch -x -D "cn=directory manager" -W -b 
>>>>>> cn=accounts,dc=messinet,dc=com  "(&(objectClass=ipaHost)(fqdn=*))"
>>>>>> dn
>>>>>>
>>>>>>
>>>>>>
>>>>>> the non-upgraded clients DO NOT appear in the list, but if I do
>>>>>> the
>>>>
>>>>
>>>>
>>>> following:
>>>>>>
>>>>>>
>>>>>> ldapsearch -x -D "cn=directory manager" -W -b 
>>>>>> cn=accounts,dc=messinet,dc=com  "(&(objectClass=ipaHost))" dn
>>>>>>
>>>>>>
>>>>>>
>>>>>> the non-upgraded clients DO appear in the list.  Somehow the
>>>>>> addition of the  fqdn=* in the filter
>>>>>> "(&(objectClass=ipaHost)(fqdn=*))" prevents them from being
>>>>>> displayed.
>>>>>>
>>>>>>
>>>>>>
>>>>>> There were no errors on any of the servers or clients during the 
>>>>>> upgrade.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Your help is appreciated.  I've tried to get this corrected all
>>>>>> day without  success.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks in advance.  -A
>>>>>
>>>>>
>>>>>
>>>>> Hi,
>>>>>
>>>>>
>>>>>
>>>>> the SSSD depends on the fqdn attribute being present for the access 
>>>>> control mechanism. Also, the SSSD searches the directory
>>>>> anonymously, so in order to get the same results, you should simply
>>>>> search the directory with anonymous bind. Can you check on the
>>>>> server how the host entries look like?
>>>>>
>>>>>
>>>>>
>>>>> For example: ipa host-show ds.messinet.com --all --raw
>>>>>
>>>>>
>>>>>
>>>>> Is the FQDN attribute present in the directory at all?
>>>>
>>>>
>>>>
>>>> Yes it is present.  The entry seems to appear similar to other 
>>>> entries.  I'm  wondering if for some reason it wasn't indexed (I
>>>> don't know much about indexing), but only the hosts that are
>>>> re-enrolled after the update are displayed with the above search.  I'm
>>>> thinking this may be related to 
>>>> http://git.fedorahosted.org/cgit/freeipa.git/commit/?h=ipa-2-2&id=ce11a7c0
>>>>
>>>>
> e
>>>> 22ee8f70e14c43419f20be70176fe8c
>>>>
>>>>
>>>>
>>>> Is there a way to re-index the fqdn attribute?
>>>
>>> While this may be a red herring, I also do not find in my
>>> ipaupgrade.log any  attempt to re-index the fqdn attribute.  These are
>>> the only entries for which tasks are created.
>>>
>>> 2012-11-11T13:25:39Z INFO Creating task to index attribute: memberuid 
>>> 2012-11-11T13:25:45Z INFO Creating task to index attribute: memberOf 
>>> 2012-11-11T13:25:51Z INFO Creating task to index attribute: memberHost 
>>> 2012-11-11T13:25:57Z INFO Creating task to index attribute: memberUser 
>>> 2012-11-11T13:26:03Z INFO Creating task to index attribute: ntUniqueId 
>>> 2012-11-11T13:26:09Z INFO Creating task to index attribute:
>>> ntUserDomainId
>>
>> This in fact was the issue for SSSD: while indexes were added to 389 for
>> the fqdn attribute, there was no index task created, so previous entries
>> were not indexed, as new hosts were.  Running the following "fixed" the
>> issue and SSSD- based logins resumed immediately:
>>
>>
>> ~]# cat fqdn_index_task.ldif dn: cn=indextask_fqdn, cn=index, cn=tasks,
>> cn=config objectclass: top objectclass: extensibleObject cn:
>> indextask_fqdn nsInstance: userRoot nsIndexAttribute: fqdn
>>
>> ~]# ldapadd -vvv -x -D "cn=directory manager" -W -f fqdn_index_task.ldif
>>
>> See https://fedorahosted.org/freeipa/ticket/3253
>>
> 
> Thanks Anthony for this bug report! I added some info to the Trac ticket, but
> I will rather repeat here:
> 
> This is indeed a bug in a code processing index updates. Index task is
> supposed to be created automatically for every new or updated index (i.e. the
> referred patch is OK), but it is unfortunately only processed in the update
> code path.
> 
> To workaround the issue, one can either fire the index task manually as you
> did or simply run the FreeIPA LDAP upgrade procedure manually after
> freeipa-server package update. This will fire an index task too:
> 
> # ipa-ldap-updater --upgrade
> # grep "Creating task to index" /var/log/ipaupgrade.log
> 2012-11-13T12:17:23Z INFO Creating task to index attribute: memberuid
> 2012-11-13T12:17:29Z INFO Creating task to index attribute: memberOf
> 2012-11-13T12:17:35Z INFO Creating task to index attribute: memberHost
> 2012-11-13T12:17:41Z INFO Creating task to index attribute: memberUser
> 2012-11-13T12:17:47Z INFO Creating task to index attribute: fqdn         <<<<
> 2012-11-13T12:17:53Z INFO Creating task to index attribute: ntUniqueId
> 2012-11-13T12:17:59Z INFO Creating task to index attribute: ntUserDomainId
> 
> After this command is run, the issue will be fixed.
> 
> Martin
> 

I just released FreeIPA with a fix for this issue to Fedora 17:

https://admin.fedoraproject.org/updates/freeipa-2.2.1-2.fc17

The build should hit updates-testing repo soon. Upgrading 2.2.0 (or 2.2.1-1) to
2.2.1-2 should be now flawless.

Martin

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

Reply via email to