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 [email protected] https://www.redhat.com/mailman/listinfo/freeipa-users
