Re: [Freeipa-users] migrate-ds aborts
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 lot. 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 group. Can you show an example/LDIF of a group stored in ou=Groups? migrate-ds will search for groups with this default filter BTW: (&(|(objectClass=groupofuniquenames)(objectClass=groupofnames))(cn=*) ) We also do not use this objectClass. I've set: --group-contain="ou=group" --group-objectclass=posixGroup --user-objectclass=foo 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. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] migrate-ds aborts
Quayle, Bill wrote: > We are making progress. ... >> >> The traceback of where the NetworkError is raised should be added to >> /var/log/httpd/error_log. >> > So we have successfully migrated the users and groups. I can't seem to find > any pointers on migrating netgroups and automount maps. Is this done via an > LDIF dump and import? You'd be better off writing some simple scripts using the ipa command-line tool for these. rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] migrate-ds aborts
We are making progress. > -Original Message- > From: Martin Kosek [mailto:mko...@redhat.com] > Sent: Monday, January 19, 2015 2:52 AM > To: Quayle, Bill; Ludwig Krispenz > Cc: 'freeipa-users@redhat.com' > Subject: Re: [Freeipa-users] migrate-ds aborts > > On 01/16/2015 08:21 PM, Quayle, Bill wrote: > > > > > >> -Original Message- > >> From: Martin Kosek [mailto:mko...@redhat.com] > >> Sent: Friday, January 16, 2015 12:51 PM > >> To: Quayle, Bill; Ludwig Krispenz > >> Cc: 'freeipa-users@redhat.com' > >> Subject: Re: [Freeipa-users] migrate-ds aborts > >> > >> On 01/16/2015 04:48 PM, Quayle, Bill wrote: > >>> Thanks for looking into this! > >>> > >>> I was finally able to import all 11811 user records into IPA, but > >>> even now, > >> when I re-run the migrate, I get the same failure. > >> > >> How did you do it in the end? Simply by running migrate-ds command > >> multiple times or did you succeeded with the limits? > >> > > I re-ran migrate-ds about 30 times to complete the migration of users. > > 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. > ... > >>> One thing that is also confusing me, is that I am getting this error: > >>> [Fri Jan 16 09:28:29.007575 2015] [:error] [pid 14924] ipa: WARNING: > >>> GID > >> number 11 of migrated user anyone does not point to a known group. > >> > >> migrate-ds command runs a search against the migrated OpenLDAP > >> database and tries to find a group with gidNumber 11. When it fails > >> to locate it, it reports this error. Do you have all the groups in DN > >> "ou=people,ou=agroup,dc=example,dc=com"? > >> > > Groups are in "ou=groups,ou=agroup,dc=example,dc=com" > > I use --base-dn="ou=agroup,dc=example,dc=com" as an option to > > migrate-ds > > 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 lot. > >> > >>> 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 > group. > Can you show an example/LDIF of a group stored in ou=Groups? > > migrate-ds will search for groups with this default filter BTW: > > (&(|(objectClass=groupofuniquenames)(objectClass=groupofnames))(cn=*) > ) > We also do not use this objectClass. I've set: --group-contain="ou=group" --group-objectclass=posixGroup --user-objectclass=foo And re-run the migrate-ds. It populated my groups! :-) > >> > >> If i crashes during user migration, it won't even continue with > >> groups. I know this is not a proper fix, but you could make sure the > >> user migration part does not find anything (e.g. with > >> --user-objectclass=foo) and using --continue option. Then it will jump > directly to group migration. > >> > > I had actually already tried doing that. I just re-tried using the > > debug=True, > and here's the contents of error_log: > > Ah. Yes, this revealed one error, although this one just means that neither > user or group search did not return any errors. I created a ticket for it: > > https://fedorahosted.org/freeipa/ticket/4846 > > The fix for this will be easy, but it will not fix the actual root cause of > the > migration problems you are hitting > > > [Fri Jan 16 13:07:42.819342 2015] [:error] [pid 15335] ipa: DEBUG: WSGI > wsgi_dispatch.__call__: > > [Fri Jan 16 13:07:42.819462 2015] [:error] [pid 15335] ipa: DEBUG: WSGI > xmlserver_session.__call__: > > [Fri Jan 16 13:07:42.819649 2015] [:error] [pid 15335] ipa: DEBUG: > > found session cookie_id = 7efb4fc24d37b7fe064fa2a4f0af447b [Fri Jan 16 > > 13:07:42.819926 2015] [:error] [pid 15335] ipa: DEBUG: found session > > data in cache with id=7efb4fc24d37b7fe064fa2a4f0af447b > > [Fri Jan 16 13:07:42.820031 2015] [:error] [pid 15335] ipa: DEBUG: > > xmlserver_session.__call__: > > session_id=7efb4fc24d37b7fe064fa2a4f0af447b > > start_timestamp=2015-01-16T13:06:02 > > access_timestamp=2015-01-16T13:07:42 > &g
Re: [Freeipa-users] migrate-ds aborts
On 01/16/2015 11:38 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 01/16/2015 02:21 PM, Quayle, Bill wrote: >>> >>>> -Original Message- >>>> From: Martin Kosek [mailto:mko...@redhat.com] >>>> Sent: Friday, January 16, 2015 12:51 PM >>>> To: Quayle, Bill; Ludwig Krispenz >>>> Cc: 'freeipa-users@redhat.com' >>>> Subject: Re: [Freeipa-users] migrate-ds aborts >>>> >>>> On 01/16/2015 04:48 PM, Quayle, Bill wrote: >>>>> Thanks for looking into this! >>>>> >>>>> I was finally able to import all 11811 user records into IPA, but >>>>> even now, >>>> when I re-run the migrate, I get the same failure. >>>> >>>> How did you do it in the end? Simply by running migrate-ds command >>>> multiple times or did you succeeded with the limits? >>>> >>> I re-ran migrate-ds about 30 times to complete the migration of users. >>>>> I enabled debug in the default.cfg, and this is the tail of the >>>>> httpd error_log: >>>>> >>>>> . >>>>> . >>>>> . >>>>>[Fri Jan 16 09:28:29.046991 2015] [:error] [pid 14924] ipa: >>>>> WARNING: GID >>>> number 11 of migrated user andy does not point to a known group. >>>>> [Fri Jan 16 09:28:29.051353 2015] [:error] [pid 14924] ipa: INFO: >>>>> ad...@idmtest.example.com: migrate_ds(u'ldap://10.x.x.x:389', >>>> u'', >>>> binddn=u'uid=me,ou=people,ou=agroup,dc=example,dc=com', >>>> usercontainer=u'ou=people', groupcontainer=u'ou=groups', >>>> userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', >>>> u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, >>>> groupignoreobjectclass=None, groupignoreattribute=None, >>>> groupoverwritegid=False, schema=u'RFC2307bis', continue=True, >>>> basedn=u'ou=agroup,dc=example,dc=com', compat=False, version=u'2.65', >>>> exclude_groups=None, exclude_users=None): NetworkError [Fri Jan 16 >>>> 09:28:29.051428 2015] [:error] [pid 14924] ipa: DEBUG: response: >>>> NetworkError: cannot connect to 'ldap://10.x.x.x:389': >>>>> [Fri Jan 16 09:28:29.054057 2015] [:error] [pid 14924] ipa: DEBUG: no >>>>> session id in request, generating empty session data with >>>>> id=c0d2c8b3803593b30684e15ff1f57e0e >>>>> [Fri Jan 16 09:28:29.054173 2015] [:error] [pid 14924] ipa: DEBUG: >>>>> store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e >>>>> start_timestamp=2015-01-16T09:28:29 >>>>> access_timestamp=2015-01-16T09:28:29 >>>>> expiration_timestamp=1969-12-31T18:00:00 >>>>> [Fri Jan 16 09:28:29.054395 2015] [:error] [pid 14924] ipa: DEBUG: >>>> finalize_kerberos_acquisition: xmlserver >>>> ccache_name="FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku" >>>> session_id="c0d2c8b3803593b30684e15ff1f57e0e" >>>>> [Fri Jan 16 09:28:29.054463 2015] [:error] [pid 14924] ipa: DEBUG: >>>>> reading >>>> ccache data from file "/run/httpd/krbcache/krb5cc_apache_zTGsku" >>>>> [Fri Jan 16 09:28:29.054851 2015] [:error] [pid 14924] ipa: DEBUG: >>>>> get_credential_times: >>>>> principal=HTTP/myipatestserver.example@idmtest.example.com, >>>>> authtime=01/15/15 16:44:10, starttime=01/15/15 16:44:17, >>>>> endtime=01/16/15 16:44:04, renew_till=12/31/69 18:00:00 [Fri Jan 16 >>>>> 09:28:29.055014 2015] [:error] [pid 14924] ipa: DEBUG: KRB5_CCache >>>>> FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku endtime=1421448244 >>>>> (01/16/15 16:44:04) [Fri Jan 16 09:28:29.055109 2015] [:error] [pid >>>>> 14924] ipa: DEBUG: set_session_expiration_time: >>>>> duration_type=inactivity_timeout duration=1200 max_age=1421447944 >>>>> expiration=1421423309.06 (2015-01-16T09:48:29) [Fri Jan 16 >>>>> 09:28:29.055217 2015] [:error] [pid 14924] ipa: DEBUG: store session: >>>>> session_id=c0d2c8b3803593b30684e15ff1f57e0e >>>>> start_timestamp=2015-01-16T09:28:29 >>>>> access_timestamp=2015-01-16T09:28:29 >>>>> expiration_timestamp=2015-01-16T09:48:29 >>>>> [Fri Jan 16 09:28:29.055806 2015] [:error] [pid 14924] i
Re: [Freeipa-users] migrate-ds aborts
On 01/16/2015 08:21 PM, Quayle, Bill wrote: > > >> -Original Message- >> From: Martin Kosek [mailto:mko...@redhat.com] >> Sent: Friday, January 16, 2015 12:51 PM >> To: Quayle, Bill; Ludwig Krispenz >> Cc: 'freeipa-users@redhat.com' >> Subject: Re: [Freeipa-users] migrate-ds aborts >> >> On 01/16/2015 04:48 PM, Quayle, Bill wrote: >>> Thanks for looking into this! >>> >>> I was finally able to import all 11811 user records into IPA, but even now, >> when I re-run the migrate, I get the same failure. >> >> How did you do it in the end? Simply by running migrate-ds command >> multiple times or did you succeeded with the limits? >> > I re-ran migrate-ds about 30 times to complete the migration of users. 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. ... >>> One thing that is also confusing me, is that I am getting this error: >>> [Fri Jan 16 09:28:29.007575 2015] [:error] [pid 14924] ipa: WARNING: GID >> number 11 of migrated user anyone does not point to a known group. >> >> migrate-ds command runs a search against the migrated OpenLDAP database >> and tries to find a group with gidNumber 11. When it fails to locate it, it >> reports this error. Do you have all the groups in DN >> "ou=people,ou=agroup,dc=example,dc=com"? >> > Groups are in "ou=groups,ou=agroup,dc=example,dc=com" > I use --base-dn="ou=agroup,dc=example,dc=com" as an option to migrate-ds 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. >> >>> 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 group. Can you show an example/LDIF of a group stored in ou=Groups? migrate-ds will search for groups with this default filter BTW: (&(|(objectClass=groupofuniquenames)(objectClass=groupofnames))(cn=*)) >> >> If i crashes during user migration, it won't even continue with groups. I >> know >> this is not a proper fix, but you could make sure the user migration part >> does >> not find anything (e.g. with --user-objectclass=foo) and using --continue >> option. Then it will jump directly to group migration. >> > I had actually already tried doing that. I just re-tried using the > debug=True, and here's the contents of error_log: Ah. Yes, this revealed one error, although this one just means that neither user or group search did not return any errors. I created a ticket for it: https://fedorahosted.org/freeipa/ticket/4846 The fix for this will be easy, but it will not fix the actual root cause of the migration problems you are hitting > [Fri Jan 16 13:07:42.819342 2015] [:error] [pid 15335] ipa: DEBUG: WSGI > wsgi_dispatch.__call__: > [Fri Jan 16 13:07:42.819462 2015] [:error] [pid 15335] ipa: DEBUG: WSGI > xmlserver_session.__call__: > [Fri Jan 16 13:07:42.819649 2015] [:error] [pid 15335] ipa: DEBUG: found > session cookie_id = 7efb4fc24d37b7fe064fa2a4f0af447b > [Fri Jan 16 13:07:42.819926 2015] [:error] [pid 15335] ipa: DEBUG: found > session data in cache with id=7efb4fc24d37b7fe064fa2a4f0af447b > [Fri Jan 16 13:07:42.820031 2015] [:error] [pid 15335] ipa: DEBUG: > xmlserver_session.__call__: session_id=7efb4fc24d37b7fe064fa2a4f0af447b > start_timestamp=2015-01-16T13:06:02 access_timestamp=2015-01-16T13:07:42 > expiration_timestamp=2015-01-16T13:26:02 > [Fri Jan 16 13:07:42.820113 2015] [:error] [pid 15335] ipa: DEBUG: storing > ccache data into file "/var/run/ipa_memcached/krbcc_15335" > [Fri Jan 16 13:07:42.820724 2015] [:error] [pid 15335] ipa: DEBUG: > get_credential_times: > principal=HTTP/testserver.example@idmtest.example.com, authtime=01/15/15 > 16:44:10, starttime=01/15/15 16:44:17, endtime=01/16/15 16:44:04, > renew_till=12/31/69 18:00:00 > [Fri Jan 16 13:07:42.821070 2015] [:error] [pid 15335] ipa: DEBUG: > get_credential_times: > principal=HTTP/testserver.example@idmtest.example.com, authtime=01/15/15 > 16:44:10, starttime=01/15/15 16:44:17, endtime=01/16/15 16:44:04, > renew_till=12/31/69 18:00:00 > [Fri Jan 16 13:07:42.821370 2015] [:error] [pid 15335] ipa: DEBUG: > KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_15335 endtime=1421448244 > (01/16/15 16:44:04) > [Fri Jan 16 13:07:42.821480 2015] [:error] [pid 15335] ipa: DEBUG: > set_session_expiration_time: duration_type=inactivity_timeout duration=1200 > max_age=1421447944 expir
Re: [Freeipa-users] migrate-ds aborts
Dmitri Pal wrote: > On 01/16/2015 02:21 PM, Quayle, Bill wrote: >> >>> -Original Message- >>> From: Martin Kosek [mailto:mko...@redhat.com] >>> Sent: Friday, January 16, 2015 12:51 PM >>> To: Quayle, Bill; Ludwig Krispenz >>> Cc: 'freeipa-users@redhat.com' >>> Subject: Re: [Freeipa-users] migrate-ds aborts >>> >>> On 01/16/2015 04:48 PM, Quayle, Bill wrote: >>>> Thanks for looking into this! >>>> >>>> I was finally able to import all 11811 user records into IPA, but >>>> even now, >>> when I re-run the migrate, I get the same failure. >>> >>> How did you do it in the end? Simply by running migrate-ds command >>> multiple times or did you succeeded with the limits? >>> >> I re-ran migrate-ds about 30 times to complete the migration of users. >>>> I enabled debug in the default.cfg, and this is the tail of the >>>> httpd error_log: >>>> >>>> . >>>> . >>>> . >>>>[Fri Jan 16 09:28:29.046991 2015] [:error] [pid 14924] ipa: >>>> WARNING: GID >>> number 11 of migrated user andy does not point to a known group. >>>> [Fri Jan 16 09:28:29.051353 2015] [:error] [pid 14924] ipa: INFO: >>>> ad...@idmtest.example.com: migrate_ds(u'ldap://10.x.x.x:389', >>> u'', >>> binddn=u'uid=me,ou=people,ou=agroup,dc=example,dc=com', >>> usercontainer=u'ou=people', groupcontainer=u'ou=groups', >>> userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', >>> u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, >>> groupignoreobjectclass=None, groupignoreattribute=None, >>> groupoverwritegid=False, schema=u'RFC2307bis', continue=True, >>> basedn=u'ou=agroup,dc=example,dc=com', compat=False, version=u'2.65', >>> exclude_groups=None, exclude_users=None): NetworkError [Fri Jan 16 >>> 09:28:29.051428 2015] [:error] [pid 14924] ipa: DEBUG: response: >>> NetworkError: cannot connect to 'ldap://10.x.x.x:389': >>>> [Fri Jan 16 09:28:29.054057 2015] [:error] [pid 14924] ipa: DEBUG: no >>>> session id in request, generating empty session data with >>>> id=c0d2c8b3803593b30684e15ff1f57e0e >>>> [Fri Jan 16 09:28:29.054173 2015] [:error] [pid 14924] ipa: DEBUG: >>>> store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e >>>> start_timestamp=2015-01-16T09:28:29 >>>> access_timestamp=2015-01-16T09:28:29 >>>> expiration_timestamp=1969-12-31T18:00:00 >>>> [Fri Jan 16 09:28:29.054395 2015] [:error] [pid 14924] ipa: DEBUG: >>> finalize_kerberos_acquisition: xmlserver >>> ccache_name="FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku" >>> session_id="c0d2c8b3803593b30684e15ff1f57e0e" >>>> [Fri Jan 16 09:28:29.054463 2015] [:error] [pid 14924] ipa: DEBUG: >>>> reading >>> ccache data from file "/run/httpd/krbcache/krb5cc_apache_zTGsku" >>>> [Fri Jan 16 09:28:29.054851 2015] [:error] [pid 14924] ipa: DEBUG: >>>> get_credential_times: >>>> principal=HTTP/myipatestserver.example@idmtest.example.com, >>>> authtime=01/15/15 16:44:10, starttime=01/15/15 16:44:17, >>>> endtime=01/16/15 16:44:04, renew_till=12/31/69 18:00:00 [Fri Jan 16 >>>> 09:28:29.055014 2015] [:error] [pid 14924] ipa: DEBUG: KRB5_CCache >>>> FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku endtime=1421448244 >>>> (01/16/15 16:44:04) [Fri Jan 16 09:28:29.055109 2015] [:error] [pid >>>> 14924] ipa: DEBUG: set_session_expiration_time: >>>> duration_type=inactivity_timeout duration=1200 max_age=1421447944 >>>> expiration=1421423309.06 (2015-01-16T09:48:29) [Fri Jan 16 >>>> 09:28:29.055217 2015] [:error] [pid 14924] ipa: DEBUG: store session: >>>> session_id=c0d2c8b3803593b30684e15ff1f57e0e >>>> start_timestamp=2015-01-16T09:28:29 >>>> access_timestamp=2015-01-16T09:28:29 >>>> expiration_timestamp=2015-01-16T09:48:29 >>>> [Fri Jan 16 09:28:29.055806 2015] [:error] [pid 14924] ipa: DEBUG: >>>> Destroyed connection context.ldap2_140392345753040 [Fri Jan 16 >>>> 09:28:29.056471 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed >>>> connection context.ldap2 >>>> >>>> One thing that is also confusing me, is that I am getting this error: >>>> [Fri Jan 16 09
Re: [Freeipa-users] migrate-ds aborts
On 01/16/2015 02:21 PM, Quayle, Bill wrote: -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Friday, January 16, 2015 12:51 PM To: Quayle, Bill; Ludwig Krispenz Cc: 'freeipa-users@redhat.com' Subject: Re: [Freeipa-users] migrate-ds aborts On 01/16/2015 04:48 PM, Quayle, Bill wrote: Thanks for looking into this! I was finally able to import all 11811 user records into IPA, but even now, when I re-run the migrate, I get the same failure. How did you do it in the end? Simply by running migrate-ds command multiple times or did you succeeded with the limits? I re-ran migrate-ds about 30 times to complete the migration of users. I enabled debug in the default.cfg, and this is the tail of the httpd error_log: . . . [Fri Jan 16 09:28:29.046991 2015] [:error] [pid 14924] ipa: WARNING: GID number 11 of migrated user andy does not point to a known group. [Fri Jan 16 09:28:29.051353 2015] [:error] [pid 14924] ipa: INFO: ad...@idmtest.example.com: migrate_ds(u'ldap://10.x.x.x:389', u'', binddn=u'uid=me,ou=people,ou=agroup,dc=example,dc=com', usercontainer=u'ou=people', groupcontainer=u'ou=groups', userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307bis', continue=True, basedn=u'ou=agroup,dc=example,dc=com', compat=False, version=u'2.65', exclude_groups=None, exclude_users=None): NetworkError [Fri Jan 16 09:28:29.051428 2015] [:error] [pid 14924] ipa: DEBUG: response: NetworkError: cannot connect to 'ldap://10.x.x.x:389': [Fri Jan 16 09:28:29.054057 2015] [:error] [pid 14924] ipa: DEBUG: no session id in request, generating empty session data with id=c0d2c8b3803593b30684e15ff1f57e0e [Fri Jan 16 09:28:29.054173 2015] [:error] [pid 14924] ipa: DEBUG: store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e start_timestamp=2015-01-16T09:28:29 access_timestamp=2015-01-16T09:28:29 expiration_timestamp=1969-12-31T18:00:00 [Fri Jan 16 09:28:29.054395 2015] [:error] [pid 14924] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku" session_id="c0d2c8b3803593b30684e15ff1f57e0e" [Fri Jan 16 09:28:29.054463 2015] [:error] [pid 14924] ipa: DEBUG: reading ccache data from file "/run/httpd/krbcache/krb5cc_apache_zTGsku" [Fri Jan 16 09:28:29.054851 2015] [:error] [pid 14924] ipa: DEBUG: get_credential_times: principal=HTTP/myipatestserver.example@idmtest.example.com, authtime=01/15/15 16:44:10, starttime=01/15/15 16:44:17, endtime=01/16/15 16:44:04, renew_till=12/31/69 18:00:00 [Fri Jan 16 09:28:29.055014 2015] [:error] [pid 14924] ipa: DEBUG: KRB5_CCache FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku endtime=1421448244 (01/16/15 16:44:04) [Fri Jan 16 09:28:29.055109 2015] [:error] [pid 14924] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1421447944 expiration=1421423309.06 (2015-01-16T09:48:29) [Fri Jan 16 09:28:29.055217 2015] [:error] [pid 14924] ipa: DEBUG: store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e start_timestamp=2015-01-16T09:28:29 access_timestamp=2015-01-16T09:28:29 expiration_timestamp=2015-01-16T09:48:29 [Fri Jan 16 09:28:29.055806 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed connection context.ldap2_140392345753040 [Fri Jan 16 09:28:29.056471 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed connection context.ldap2 One thing that is also confusing me, is that I am getting this error: [Fri Jan 16 09:28:29.007575 2015] [:error] [pid 14924] ipa: WARNING: GID number 11 of migrated user anyone does not point to a known group. migrate-ds command runs a search against the migrated OpenLDAP database and tries to find a group with gidNumber 11. When it fails to locate it, it reports this error. Do you have all the groups in DN "ou=people,ou=agroup,dc=example,dc=com"? Groups are in "ou=groups,ou=agroup,dc=example,dc=com" I use --base-dn="ou=agroup,dc=example,dc=com" as an option to migrate-ds 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. If i crashes during user migration, it won't even continue with groups. I know this is not a proper fix, but you could make sure the user migration part does not find anything (e.g. with --user-objectclass=foo) and using --continue option. Then it will jump directly to group migration. I had actually already tried doing that. I just re-tried using the debug=True, and here's the contents of error_log: [Fri Jan 16 13:07:42.819342 2015] [:error] [pid 15335] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Fri Jan 16 13:07:42.819462 2015
Re: [Freeipa-users] migrate-ds aborts
> -Original Message- > From: Martin Kosek [mailto:mko...@redhat.com] > Sent: Friday, January 16, 2015 12:51 PM > To: Quayle, Bill; Ludwig Krispenz > Cc: 'freeipa-users@redhat.com' > Subject: Re: [Freeipa-users] migrate-ds aborts > > On 01/16/2015 04:48 PM, Quayle, Bill wrote: > > Thanks for looking into this! > > > > I was finally able to import all 11811 user records into IPA, but even now, > when I re-run the migrate, I get the same failure. > > How did you do it in the end? Simply by running migrate-ds command > multiple times or did you succeeded with the limits? > I re-ran migrate-ds about 30 times to complete the migration of users. > > > > I enabled debug in the default.cfg, and this is the tail of the httpd > > error_log: > > > > . > > . > > . > > [Fri Jan 16 09:28:29.046991 2015] [:error] [pid 14924] ipa: WARNING: GID > number 11 of migrated user andy does not point to a known group. > > [Fri Jan 16 09:28:29.051353 2015] [:error] [pid 14924] ipa: INFO: > > ad...@idmtest.example.com: migrate_ds(u'ldap://10.x.x.x:389', > u'', > binddn=u'uid=me,ou=people,ou=agroup,dc=example,dc=com', > usercontainer=u'ou=people', groupcontainer=u'ou=groups', > userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', > u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, > groupignoreobjectclass=None, groupignoreattribute=None, > groupoverwritegid=False, schema=u'RFC2307bis', continue=True, > basedn=u'ou=agroup,dc=example,dc=com', compat=False, version=u'2.65', > exclude_groups=None, exclude_users=None): NetworkError [Fri Jan 16 > 09:28:29.051428 2015] [:error] [pid 14924] ipa: DEBUG: response: > NetworkError: cannot connect to 'ldap://10.x.x.x:389': > > [Fri Jan 16 09:28:29.054057 2015] [:error] [pid 14924] ipa: DEBUG: no > > session id in request, generating empty session data with > > id=c0d2c8b3803593b30684e15ff1f57e0e > > [Fri Jan 16 09:28:29.054173 2015] [:error] [pid 14924] ipa: DEBUG: > > store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e > > start_timestamp=2015-01-16T09:28:29 > > access_timestamp=2015-01-16T09:28:29 > > expiration_timestamp=1969-12-31T18:00:00 > > [Fri Jan 16 09:28:29.054395 2015] [:error] [pid 14924] ipa: DEBUG: > finalize_kerberos_acquisition: xmlserver > ccache_name="FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku" > session_id="c0d2c8b3803593b30684e15ff1f57e0e" > > [Fri Jan 16 09:28:29.054463 2015] [:error] [pid 14924] ipa: DEBUG: reading > ccache data from file "/run/httpd/krbcache/krb5cc_apache_zTGsku" > > [Fri Jan 16 09:28:29.054851 2015] [:error] [pid 14924] ipa: DEBUG: > > get_credential_times: > > principal=HTTP/myipatestserver.example@idmtest.example.com, > > authtime=01/15/15 16:44:10, starttime=01/15/15 16:44:17, > > endtime=01/16/15 16:44:04, renew_till=12/31/69 18:00:00 [Fri Jan 16 > > 09:28:29.055014 2015] [:error] [pid 14924] ipa: DEBUG: KRB5_CCache > > FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku endtime=1421448244 > > (01/16/15 16:44:04) [Fri Jan 16 09:28:29.055109 2015] [:error] [pid > > 14924] ipa: DEBUG: set_session_expiration_time: > > duration_type=inactivity_timeout duration=1200 max_age=1421447944 > > expiration=1421423309.06 (2015-01-16T09:48:29) [Fri Jan 16 > > 09:28:29.055217 2015] [:error] [pid 14924] ipa: DEBUG: store session: > > session_id=c0d2c8b3803593b30684e15ff1f57e0e > > start_timestamp=2015-01-16T09:28:29 > > access_timestamp=2015-01-16T09:28:29 > > expiration_timestamp=2015-01-16T09:48:29 > > [Fri Jan 16 09:28:29.055806 2015] [:error] [pid 14924] ipa: DEBUG: > > Destroyed connection context.ldap2_140392345753040 [Fri Jan 16 > > 09:28:29.056471 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed > > connection context.ldap2 > > > > One thing that is also confusing me, is that I am getting this error: > > [Fri Jan 16 09:28:29.007575 2015] [:error] [pid 14924] ipa: WARNING: GID > number 11 of migrated user anyone does not point to a known group. > > migrate-ds command runs a search against the migrated OpenLDAP database > and tries to find a group with gidNumber 11. When it fails to locate it, it > reports this error. Do you have all the groups in DN > "ou=people,ou=agroup,dc=example,dc=com"? > Groups are in "ou=groups,ou=agroup,dc=example,dc=com" I use --base-dn="ou=agroup,dc=example,dc=com" as an option to migrate-ds > > > And it never migrates my groups. The ou=Groups is used in my source > openLDAP tree, so
Re: [Freeipa-users] migrate-ds aborts
On 01/16/2015 04:48 PM, Quayle, Bill wrote: Thanks for looking into this! I was finally able to import all 11811 user records into IPA, but even now, when I re-run the migrate, I get the same failure. How did you do it in the end? Simply by running migrate-ds command multiple times or did you succeeded with the limits? I enabled debug in the default.cfg, and this is the tail of the httpd error_log: . . . [Fri Jan 16 09:28:29.046991 2015] [:error] [pid 14924] ipa: WARNING: GID number 11 of migrated user andy does not point to a known group. [Fri Jan 16 09:28:29.051353 2015] [:error] [pid 14924] ipa: INFO: ad...@idmtest.example.com: migrate_ds(u'ldap://10.x.x.x:389', u'', binddn=u'uid=me,ou=people,ou=agroup,dc=example,dc=com', usercontainer=u'ou=people', groupcontainer=u'ou=groups', userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307bis', continue=True, basedn=u'ou=agroup,dc=example,dc=com', compat=False, version=u'2.65', exclude_groups=None, exclude_users=None): NetworkError [Fri Jan 16 09:28:29.051428 2015] [:error] [pid 14924] ipa: DEBUG: response: NetworkError: cannot connect to 'ldap://10.x.x.x:389': [Fri Jan 16 09:28:29.054057 2015] [:error] [pid 14924] ipa: DEBUG: no session id in request, generating empty session data with id=c0d2c8b3803593b30684e15ff1f57e0e [Fri Jan 16 09:28:29.054173 2015] [:error] [pid 14924] ipa: DEBUG: store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e start_timestamp=2015-01-16T09:28:29 access_timestamp=2015-01-16T09:28:29 expiration_timestamp=1969-12-31T18:00:00 [Fri Jan 16 09:28:29.054395 2015] [:error] [pid 14924] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku" session_id="c0d2c8b3803593b30684e15ff1f57e0e" [Fri Jan 16 09:28:29.054463 2015] [:error] [pid 14924] ipa: DEBUG: reading ccache data from file "/run/httpd/krbcache/krb5cc_apache_zTGsku" [Fri Jan 16 09:28:29.054851 2015] [:error] [pid 14924] ipa: DEBUG: get_credential_times: principal=HTTP/myipatestserver.example@idmtest.example.com, authtime=01/15/15 16:44:10, starttime=01/15/15 16:44:17, endtime=01/16/15 16:44:04, renew_till=12/31/69 18:00:00 [Fri Jan 16 09:28:29.055014 2015] [:error] [pid 14924] ipa: DEBUG: KRB5_CCache FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku endtime=1421448244 (01/16/15 16:44:04) [Fri Jan 16 09:28:29.055109 2015] [:error] [pid 14924] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1421447944 expiration=1421423309.06 (2015-01-16T09:48:29) [Fri Jan 16 09:28:29.055217 2015] [:error] [pid 14924] ipa: DEBUG: store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e start_timestamp=2015-01-16T09:28:29 access_timestamp=2015-01-16T09:28:29 expiration_timestamp=2015-01-16T09:48:29 [Fri Jan 16 09:28:29.055806 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed connection context.ldap2_140392345753040 [Fri Jan 16 09:28:29.056471 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed connection context.ldap2 One thing that is also confusing me, is that I am getting this error: [Fri Jan 16 09:28:29.007575 2015] [:error] [pid 14924] ipa: WARNING: GID number 11 of migrated user anyone does not point to a known group. migrate-ds command runs a search against the migrated OpenLDAP database and tries to find a group with gidNumber 11. When it fails to locate it, it reports this error. Do you have all the groups in DN "ou=people,ou=agroup,dc=example,dc=com"? 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. If i crashes during user migration, it won't even continue with groups. I know this is not a proper fix, but you could make sure the user migration part does not find anything (e.g. with --user-objectclass=foo) and using --continue option. Then it will jump directly to group migration. I am still thinking it would make sense to also check the migrated OpenLDAP logs and see if there is anything interesting when the migration breaks. HTH, Martin Bill -Original Message----- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Friday, January 16, 2015 2:25 AM To: Ludwig Krispenz Cc: Quayle, Bill; 'freeipa-users@redhat.com' Subject: Re: [Freeipa-users] migrate-ds aborts On 01/16/2015 09:14 AM, Ludwig Krispenz wrote: On 01/16/2015 08:43 AM, Martin Kosek wrote: On 01/15/2015 06:31 PM, Quayle, Bill wrote: I am migrating an openLDAP tree into ipa, and when I run ipa migrate-ds, the migration aborts after roughly 36 seconds with: ipa: ERROR: cannot connect to 'ldap://10
Re: [Freeipa-users] migrate-ds aborts
Thanks for looking into this! I was finally able to import all 11811 user records into IPA, but even now, when I re-run the migrate, I get the same failure. I enabled debug in the default.cfg, and this is the tail of the httpd error_log: . . . [Fri Jan 16 09:28:29.046991 2015] [:error] [pid 14924] ipa: WARNING: GID number 11 of migrated user andy does not point to a known group. [Fri Jan 16 09:28:29.051353 2015] [:error] [pid 14924] ipa: INFO: ad...@idmtest.example.com: migrate_ds(u'ldap://10.x.x.x:389', u'', binddn=u'uid=me,ou=people,ou=agroup,dc=example,dc=com', usercontainer=u'ou=people', groupcontainer=u'ou=groups', userobjectclass=(u'person',), groupobjectclass=(u'groupOfUniqueNames', u'groupOfNames'), userignoreobjectclass=None, userignoreattribute=None, groupignoreobjectclass=None, groupignoreattribute=None, groupoverwritegid=False, schema=u'RFC2307bis', continue=True, basedn=u'ou=agroup,dc=example,dc=com', compat=False, version=u'2.65', exclude_groups=None, exclude_users=None): NetworkError [Fri Jan 16 09:28:29.051428 2015] [:error] [pid 14924] ipa: DEBUG: response: NetworkError: cannot connect to 'ldap://10.x.x.x:389': [Fri Jan 16 09:28:29.054057 2015] [:error] [pid 14924] ipa: DEBUG: no session id in request, generating empty session data with id=c0d2c8b3803593b30684e15ff1f57e0e [Fri Jan 16 09:28:29.054173 2015] [:error] [pid 14924] ipa: DEBUG: store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e start_timestamp=2015-01-16T09:28:29 access_timestamp=2015-01-16T09:28:29 expiration_timestamp=1969-12-31T18:00:00 [Fri Jan 16 09:28:29.054395 2015] [:error] [pid 14924] ipa: DEBUG: finalize_kerberos_acquisition: xmlserver ccache_name="FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku" session_id="c0d2c8b3803593b30684e15ff1f57e0e" [Fri Jan 16 09:28:29.054463 2015] [:error] [pid 14924] ipa: DEBUG: reading ccache data from file "/run/httpd/krbcache/krb5cc_apache_zTGsku" [Fri Jan 16 09:28:29.054851 2015] [:error] [pid 14924] ipa: DEBUG: get_credential_times: principal=HTTP/myipatestserver.example@idmtest.example.com, authtime=01/15/15 16:44:10, starttime=01/15/15 16:44:17, endtime=01/16/15 16:44:04, renew_till=12/31/69 18:00:00 [Fri Jan 16 09:28:29.055014 2015] [:error] [pid 14924] ipa: DEBUG: KRB5_CCache FILE:/run/httpd/krbcache/krb5cc_apache_zTGsku endtime=1421448244 (01/16/15 16:44:04) [Fri Jan 16 09:28:29.055109 2015] [:error] [pid 14924] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1421447944 expiration=1421423309.06 (2015-01-16T09:48:29) [Fri Jan 16 09:28:29.055217 2015] [:error] [pid 14924] ipa: DEBUG: store session: session_id=c0d2c8b3803593b30684e15ff1f57e0e start_timestamp=2015-01-16T09:28:29 access_timestamp=2015-01-16T09:28:29 expiration_timestamp=2015-01-16T09:48:29 [Fri Jan 16 09:28:29.055806 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed connection context.ldap2_140392345753040 [Fri Jan 16 09:28:29.056471 2015] [:error] [pid 14924] ipa: DEBUG: Destroyed connection context.ldap2 One thing that is also confusing me, is that I am getting this error: [Fri Jan 16 09:28:29.007575 2015] [:error] [pid 14924] ipa: WARNING: GID number 11 of migrated user anyone does not point to a known group. 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. Bill -Original Message- From: Martin Kosek [mailto:mko...@redhat.com] Sent: Friday, January 16, 2015 2:25 AM To: Ludwig Krispenz Cc: Quayle, Bill; 'freeipa-users@redhat.com' Subject: Re: [Freeipa-users] migrate-ds aborts On 01/16/2015 09:14 AM, Ludwig Krispenz wrote: > > On 01/16/2015 08:43 AM, Martin Kosek wrote: >> On 01/15/2015 06:31 PM, Quayle, Bill wrote: >>> I am migrating an openLDAP tree into ipa, and when I run ipa >>> migrate-ds, the migration aborts after roughly 36 seconds with: >>> >>> ipa: ERROR: cannot connect to 'ldap://10.x.x.x:389': >>> >>> It has transferred 9762 records, but seems to hit a timeout that >>> causes it to stop. >>> >>> I've run it in debug mode, which only provides this: >>> >>> ipa: DEBUG: Starting external process >>> >>> ipa: DEBUG: args=keyctl pupdate 774698354 >>> >>> ipa: DEBUG: Process finished, return code=0 >>> >>> ipa: DEBUG: stdout= >>> >>> ipa: DEBUG: stderr= >>> >>> ipa: DEBUG: Caught fault 907 from server >>> https://foo.example.com/ipa/session/xml: cannot connect to >>> 'ldap://10.x.x.x:389': >>> >>> ipa: DEBUG: Destroyed connection context.xmlclient >>> >>> ipa: ERROR: cannot conn
Re: [Freeipa-users] migrate-ds aborts
On 01/16/2015 09:14 AM, Ludwig Krispenz wrote: On 01/16/2015 08:43 AM, Martin Kosek wrote: On 01/15/2015 06:31 PM, Quayle, Bill wrote: I am migrating an openLDAP tree into ipa, and when I run ipa migrate-ds, the migration aborts after roughly 36 seconds with: ipa: ERROR: cannot connect to 'ldap://10.x.x.x:389’: It has transferred 9762 records, but seems to hit a timeout that causes it to stop. I’ve run it in debug mode, which only provides this: ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl pupdate 774698354 ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Caught fault 907 from server https://foo.example.com/ipa/session/xml: cannot connect to 'ldap://10.x.x.x:389': ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: cannot connect to 'ldap://10.x.x.x:389': Initially, it had transferred 2000 records and stopped, until I set nsslapd-sizelimit in cn=config: nsslapd-sizelimit: 2 I then re-ran the migration a dozen times, each time it would transfer more records, but would always time out at around the 36 second mark. Now that I’m at 9762 records, it seems to have reached a peak. I suspect this is another tunable, but haven’t been able to find it, any document that mentions it, or anyone else hitting this issue. RHEL 7.0 server idM ipa-server-3.3.3-28 source is RHEL 6.5 running openldap-2.4.23-34 command used to migrate: ipa migrate-ds --continue --bind-dn="uid=me,ou=people,ou=foo,dc=example,dc=com" --base-dn="ou=foo,dc=example,dc=com" ldap://10.x.x.x:389 *Cheers,* *-Bill* Ludwig, do you know? I am just thinking it may be also caused by some form of timelimit, as mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html (those apply both for bind DNs and global cn=config). Maybe nsslapd-timelimit could be increased? Although I saw the default is 3600, I assume it means 1 hour, i.e. not being the root cause. we need the access and error logs from DS, if it is a DS limit it should be seen in the err code. +1 Could it be that migrate-ds has it's own limit waiting for a repsponse from DS ? The search itself in migrate-ds is limit-less: try: 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 ) except... Bill, I am wondering, could you add debug=True to /etc/ipa/default.conf on your server, reload the httpd process and re-run the migration? It should print additional debugging information that may help us. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] migrate-ds aborts
On 01/16/2015 08:43 AM, Martin Kosek wrote: On 01/15/2015 06:31 PM, Quayle, Bill wrote: I am migrating an openLDAP tree into ipa, and when I run ipa migrate-ds, the migration aborts after roughly 36 seconds with: ipa: ERROR: cannot connect to 'ldap://10.x.x.x:389’: It has transferred 9762 records, but seems to hit a timeout that causes it to stop. I’ve run it in debug mode, which only provides this: ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl pupdate 774698354 ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Caught fault 907 from server https://foo.example.com/ipa/session/xml: cannot connect to 'ldap://10.x.x.x:389': ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: cannot connect to 'ldap://10.x.x.x:389': Initially, it had transferred 2000 records and stopped, until I set nsslapd-sizelimit in cn=config: nsslapd-sizelimit: 2 I then re-ran the migration a dozen times, each time it would transfer more records, but would always time out at around the 36 second mark. Now that I’m at 9762 records, it seems to have reached a peak. I suspect this is another tunable, but haven’t been able to find it, any document that mentions it, or anyone else hitting this issue. RHEL 7.0 server idM ipa-server-3.3.3-28 source is RHEL 6.5 running openldap-2.4.23-34 command used to migrate: ipa migrate-ds --continue --bind-dn="uid=me,ou=people,ou=foo,dc=example,dc=com" --base-dn="ou=foo,dc=example,dc=com" ldap://10.x.x.x:389 *Cheers,* *-Bill* Ludwig, do you know? I am just thinking it may be also caused by some form of timelimit, as mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html (those apply both for bind DNs and global cn=config). Maybe nsslapd-timelimit could be increased? Although I saw the default is 3600, I assume it means 1 hour, i.e. not being the root cause. we need the access and error logs from DS, if it is a DS limit it should be seen in the err code. Could it be that migrate-ds has it's own limit waiting for a repsponse from DS ? Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] migrate-ds aborts
On 01/15/2015 06:31 PM, Quayle, Bill wrote: I am migrating an openLDAP tree into ipa, and when I run ipa migrate-ds, the migration aborts after roughly 36 seconds with: ipa: ERROR: cannot connect to 'ldap://10.x.x.x:389’: It has transferred 9762 records, but seems to hit a timeout that causes it to stop. I’ve run it in debug mode, which only provides this: ipa: DEBUG: Starting external process ipa: DEBUG: args=keyctl pupdate 774698354 ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Caught fault 907 from server https://foo.example.com/ipa/session/xml: cannot connect to 'ldap://10.x.x.x:389': ipa: DEBUG: Destroyed connection context.xmlclient ipa: ERROR: cannot connect to 'ldap://10.x.x.x:389': Initially, it had transferred 2000 records and stopped, until I set nsslapd-sizelimit in cn=config: nsslapd-sizelimit: 2 I then re-ran the migration a dozen times, each time it would transfer more records, but would always time out at around the 36 second mark. Now that I’m at 9762 records, it seems to have reached a peak. I suspect this is another tunable, but haven’t been able to find it, any document that mentions it, or anyone else hitting this issue. RHEL 7.0 server idM ipa-server-3.3.3-28 source is RHEL 6.5 running openldap-2.4.23-34 command used to migrate: ipa migrate-ds --continue --bind-dn="uid=me,ou=people,ou=foo,dc=example,dc=com" --base-dn="ou=foo,dc=example,dc=com" ldap://10.x.x.x:389 *Cheers,* *-Bill* Ludwig, do you know? I am just thinking it may be also caused by some form of timelimit, as mentioned in https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management-Setting_Resource_Limits_Based_on_the_Bind_DN.html (those apply both for bind DNs and global cn=config). Maybe nsslapd-timelimit could be increased? Although I saw the default is 3600, I assume it means 1 hour, i.e. not being the root cause. Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
