[Freeipa-users] ipa migrate-ds failing when more than 1 namingcontext is available

[Dmitri Pal]

On 01/30/2012 10:56 AM, Rob Crittenden wrote:
> Dmitri Pal wrote:
>> On 01/30/2012 09:23 AM, Simo Sorce wrote:
>>> On Mon, 2012-01-30 at 09:06 -0500, Rob Crittenden wrote:
>>>> Like I said, this  error is triggered before ignore is evaluated so
>>>> if
>>>> an unknown binary attribute is getting decoded it will cause this
>>>> failure. The only solutions we have right now is to either load the
>>>> schema into IPA temporarily for the migration, rremove it on the
>>>> remote
>>>> side or you could modify the query we make to find the remote entries
>>>> to
>>>> pull only certain attributes. This last one would be tricky to get
>>>> right.
>>>>
>>>> The code looks like:
>>>>
>>>>                   (entries, truncated) = ds_ldap.find_entries(
>>>>                       search_filter, ['*'],
>>>> search_bases[ldap_obj_name],
>>>>                       ds_ldap.SCOPE_ONELEVEL,
>>>>                       time_limit=0, size_limit=-1,
>>>>                       search_refs=True    # migrated DS may contain
>>>> search references
>>>>                   )
>>>>
>>>> You'd want to replace ['*'] with ['attr1','attr2','attr3',...]. It
>>>> would
>>>> be a rather long list and would need to cover both users and groups.
>>>>
>>> TBH I think we should turn the code around and do this by default.
>>> We have no idea how to manage extra attributes anyway so we shouldn't
>>> get them all, only get those we understand. And turn the exclusion list
>>> into an inclusion list, so that if someone wants to import more data
>>> because they added additional schema to FreeIPA they are free to do so.
>>> The current way looks brittle.
>>>
>>> Simo.
>>>
>> Agree, we need to open a BZ and ticket on this one.
>>
>
> Oh I don't know. The reason we did it this way was to specifically put
> into the user's face those attributes that aren't being migrated. This
> way we don't find out much after the fact that some things weren't
> migrated properly forcing them to re-migrate. I'd certainly rather
> have a little pain at the beginning of the process and know I have
> everything I need rather than days/weeks/months later and realize
> something important was missed.
>
> rob

May be we should have a dry run option then or something like
migrate-ds-test that will return two lists:
List of all attributes detected and the list of attributes that we
actually can migrate.
For the ones we can't migrate we should explain why.
Then migrate-ds should accept the second list as an input overriding the
default "*".
How about that?


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager IPA project,
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/