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
_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
