On 01/20/2015 04:49 PM, Quayle, Bill wrote:
Hm, this is definitely not how the migrate-ds is supposed work :-/ I wish we
can find the problem to avoid such difficulties for other users.

As this is an evaluation setup, I can tear-down and rebuild to try to capture 
more data, if you want.

That would be great. Finding the reason why the migration ends with NetworkError would be awesome. So far, my last debugging idea was to see where exactly is the NetworkError thrown:

# cd /usr/lib/python2.7/site-packages/ipaserver/
# rpcserver.py rpcserver.py.orig
# wget http://mkosek.fedorapeople.org/0001-Print-PublicError-traceback-when-in-debug-mode.patch -O /tmp/ipa.patch
# patch -p2 < /tmp/ipa.patch
# service httpd reload

The when server is put in debug=True mode, /var/log/httpd/error_log should contain traceback for the NetworkError. Maybe Rob has also other ideas how to find the root cause.

Right, sorry - I see I mistyped the DN. Does the container then contain a
group with gidNumber 11? It would explain the error you were asking about.

I also mistyped the dn.  We use "group" instead of "groups", which explains a 

And it never migrates my groups.  The ou=Groups is used in my source
openLDAP tree, so I'm not sure why it wouldn't migrate.

Maybe your groups use some scheme that migrate-ds does not recognize as
Can you show an example/LDIF of a group stored in ou=Groups?

migrate-ds will search for groups with this default filter BTW:


We also do not use this objectClass.  I've set:
    --group-contain="ou=group" --group-objectclass=posixGroup 
And re-run the migrate-ds.

It populated my groups!  :-)

Ah, cool! Rob, why is posixGroup missing in the list of possible migrated group objectclass anyway? We only search for groupofuniquenames/groupofnames by default. Adding posixGroup to the default list sounds fine to me.


Manage your subscription for the Freeipa-users mailing list:
Go To http://freeipa.org for more info on the project

Reply via email to