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

[Sigbjorn Lie]

I agree with Simo. As far as I understand I dont have a way around this but to change the source. Ok for me but perhaps a bit much for others...

Btw, I haven't had time to test the proposed source changes.


Rgds,
Siggi
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Simo Sorce <simo at redhat.com> wrote:

On Mon, 2012-01-30 at 10:56 -0500, 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.

I understand the intent, but I think the current method causes more pain
then necessary.
If admins have important data they want to preserve they better
explicitly include it in the import list. And check the data was
properly imported.

I do not think we need to make life of good admins difficult in order to
try to salvage bad admins that do not even check the migration imported
all data they needed.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

_____________________________________________

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20120130/86bf164a/attachment.htm>