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
# 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:
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