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

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

Reply via email to