Dear all,
Perhaps someone could shed some light on what is amiss here. I am trying to install a IPA replica to an ancient freeipa server, which has always run standalone.
I have attached the logs for you to read. It seems there is missing something in de ldap tree.
Server and replica-to-be are running Fedora 29, freeipa 4.7.2.
The (i suppose) relevant stacktrace is here:
2019-01-21T13:17:44Z DEBUG [28/41]: setting up initial replication 2019-01-21T13:17:45Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PLATYPUSNET-ORG.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f03f2114710> 2019-01-21T13:17:45Z DEBUG Destroyed connection context.ldap2_139654961964256 2019-01-21T13:17:45Z DEBUG Starting external process 2019-01-21T13:17:45Z DEBUG args=['/bin/systemctl', '--system', 'daemon-reload'] 2019-01-21T13:17:46Z DEBUG Process finished, return code=0 2019-01-21T13:17:46Z DEBUG stdout= 2019-01-21T13:17:46Z DEBUG stderr= 2019-01-21T13:17:46Z DEBUG Starting external process 2019-01-21T13:17:46Z DEBUG args=['/bin/systemctl', 'restart', 'dirsrv@PLATYPUSNET-ORG.service'] 2019-01-21T13:17:51Z DEBUG Process finished, return code=0 2019-01-21T13:17:51Z DEBUG stdout= 2019-01-21T13:17:51Z DEBUG stderr= 2019-01-21T13:17:51Z DEBUG Restart of dirsrv@PLATYPUSNET-ORG.service complete 2019-01-21T13:17:51Z DEBUG Created connection context.ldap2_139654961964256 2019-01-21T13:17:52Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2019-01-21T13:17:52Z DEBUG retrieving schema for SchemaCache url=ldap://starkey.platypusnet.org:389 conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f03f28c7668> 2019-01-21T13:17:52Z DEBUG Successfully updated nsDS5ReplicaId. 2019-01-21T13:17:52Z DEBUG Add or update replica config cn=replica,cn=dc=platypusnet,dc=org,cn=mapping tree,cn=config 2019-01-21T13:17:52Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} 2019-01-21T13:17:52Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/ipapython/ipaldap.py", line 1023, in error_handler yield File "/usr/lib/python3.7/site-packages/ipapython/ipaldap.py", line 1517, in find_entries raise e File "/usr/lib/python3.7/site-packages/ipapython/ipaldap.py", line 1477, in find_entries result = self.conn.result3(id, 0) File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 749, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 756, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 329, in _ldap_call reraise(exc_type, exc_value, exc_traceback) File "/usr/lib64/python3.7/site-packages/ldap/compat.py", line 44, in reraise raise exc_value File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 313, in _ldap_call result = func(*args,**kwargs) ldap.NO_SUCH_OBJECT: {'desc': 'No such object'}
Kind Regards,
Arjen Heidinga
On 1/21/19 4:46 PM, Arjen Heidinga via FreeIPA-users wrote:
Dear all,
Perhaps someone could shed some light on what is amiss here. I am trying to install a IPA replica to an ancient freeipa server, which has always run standalone.
I have attached the logs for you to read. It seems there is missing something in de ldap tree.
Server and replica-to-be are running Fedora 29, freeipa 4.7.2.
The (i suppose) relevant stacktrace is here:
2019-01-21T13:17:44Z DEBUG [28/41]: setting up initial replication 2019-01-21T13:17:45Z DEBUG retrieving schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd-PLATYPUSNET-ORG.socket conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f03f2114710> 2019-01-21T13:17:45Z DEBUG Destroyed connection context.ldap2_139654961964256 2019-01-21T13:17:45Z DEBUG Starting external process 2019-01-21T13:17:45Z DEBUG args=['/bin/systemctl', '--system', 'daemon-reload'] 2019-01-21T13:17:46Z DEBUG Process finished, return code=0 2019-01-21T13:17:46Z DEBUG stdout= 2019-01-21T13:17:46Z DEBUG stderr= 2019-01-21T13:17:46Z DEBUG Starting external process 2019-01-21T13:17:46Z DEBUG args=['/bin/systemctl', 'restart', 'dirsrv@PLATYPUSNET-ORG.service'] 2019-01-21T13:17:51Z DEBUG Process finished, return code=0 2019-01-21T13:17:51Z DEBUG stdout= 2019-01-21T13:17:51Z DEBUG stderr= 2019-01-21T13:17:51Z DEBUG Restart of dirsrv@PLATYPUSNET-ORG.service complete 2019-01-21T13:17:51Z DEBUG Created connection context.ldap2_139654961964256 2019-01-21T13:17:52Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2019-01-21T13:17:52Z DEBUG retrieving schema for SchemaCache url=ldap://starkey.platypusnet.org:389 conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f03f28c7668> 2019-01-21T13:17:52Z DEBUG Successfully updated nsDS5ReplicaId. 2019-01-21T13:17:52Z DEBUG Add or update replica config cn=replica,cn=dc=platypusnet,dc=org,cn=mapping tree,cn=config 2019-01-21T13:17:52Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'} 2019-01-21T13:17:52Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/ipapython/ipaldap.py", line 1023, in error_handler yield File "/usr/lib/python3.7/site-packages/ipapython/ipaldap.py", line 1517, in find_entries raise e File "/usr/lib/python3.7/site-packages/ipapython/ipaldap.py", line 1477, in find_entries result = self.conn.result3(id, 0) File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 749, in result3 resp_ctrl_classes=resp_ctrl_classes File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 756, in result4 ldap_result = self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop) File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 329, in _ldap_call reraise(exc_type, exc_value, exc_traceback) File "/usr/lib64/python3.7/site-packages/ldap/compat.py", line 44, in reraise raise exc_value File "/usr/lib64/python3.7/site-packages/ldap/ldapobject.py", line 313, in _ldap_call result = func(*args,**kwargs) ldap.NO_SUCH_OBJECT: {'desc': 'No such object'}
Kind Regards,
Arjen Heidinga
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
Hi,
this portion of code is checking if the entry is already existing. If yes, the entry is updated, otherwise the entry is created. In the logs, it looks like the entry is not present yet and the replica installer tries to add it. The add fails with OPERATIONS_ERROR. Can you check in 389-ds access and error log if there is any message related to a ADD operation on the entry cn=replica,cn=dc=platypusnet,dc=org,cn=mapping tree,cn=config ?
flo
Op 29-01-19 om 10:28 schreef Florence Blanc-Renaud:
On 1/21/19 4:46 PM, Arjen Heidinga via FreeIPA-users wrote:
2019-01-21T13:17:51Z DEBUG Created connection context.ldap2_139654961964256 2019-01-21T13:17:52Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2019-01-21T13:17:52Z DEBUG retrieving schema for SchemaCache url=ldap://starkey.platypusnet.org:389 conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f03f28c7668> 2019-01-21T13:17:52Z DEBUG Successfully updated nsDS5ReplicaId. 2019-01-21T13:17:52Z DEBUG Add or update replica config cn=replica,cn=dc=platypusnet,dc=org,cn=mapping tree,cn=config 2019-01-21T13:17:52Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'}
Hi,
this portion of code is checking if the entry is already existing. If yes, the entry is updated, otherwise the entry is created. In the logs, it looks like the entry is not present yet and the replica installer tries to add it. The add fails with OPERATIONS_ERROR. Can you check in 389-ds access and error log if there is any message related to a ADD operation on the entry cn=replica,cn=dc=platypusnet,dc=org,cn=mapping tree,cn=config ?
flo
Florence,
Thanks.
I am afraid the error log is silent about this, the access log reports no error. The relevant part is below.
I tried capturing packets, but there was some TLS inssue in my way of reading the info...
Can I increase the logging of the dirsrv, so that I can see what exactly it tries to do?
Further, seem to not know how to query the cn=config root. In the cn=replication,cn=... the nsDS5ReplicaId is 15.
Thanks and regards,
Arjen
[31/Jan/2019:11:46:45.895445398 +0100] conn=9065 op=3 SRCH base="cn=replication,cn=etc,dc=platypusnet,dc=org" scope=0 filter="(objectClass=* )" attrs=ALL [31/Jan/2019:11:46:45.896294824 +0100] conn=9065 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0001390211 [31/Jan/2019:11:46:45.906941102 +0100] conn=9065 op=4 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectCla sses" [31/Jan/2019:11:46:46.159243241 +0100] conn=9065 op=4 RESULT err=0 tag=101 nentries=1 etime=0.0252611273 [31/Jan/2019:11:46:46.304279134 +0100] conn=9065 op=5 MOD dn="cn=replication,cn=etc,dc=platypusnet,dc=org" [31/Jan/2019:11:46:46.338464637 +0100] conn=9065 op=5 RESULT err=0 tag=103 nentries=0 etime=0.0034589580 [31/Jan/2019:11:46:46.438671736 +0100] conn=9063 op=17 UNBIND [31/Jan/2019:11:46:46.438750517 +0100] conn=9063 op=17 fd=151 closed - U1 [31/Jan/2019:11:46:50.733020153 +0100] conn=9065 op=6 UNBIND
On 1/31/19 12:04 PM, Arjen Heidinga via FreeIPA-users wrote:
Op 29-01-19 om 10:28 schreef Florence Blanc-Renaud:
On 1/21/19 4:46 PM, Arjen Heidinga via FreeIPA-users wrote:
2019-01-21T13:17:51Z DEBUG Created connection context.ldap2_139654961964256 2019-01-21T13:17:52Z DEBUG Fetching nsDS5ReplicaId from master [attempt 1/5] 2019-01-21T13:17:52Z DEBUG retrieving schema for SchemaCache url=ldap://starkey.platypusnet.org:389 conn=<ldap.ldapobject.SimpleLDAPObject object at 0x7f03f28c7668> 2019-01-21T13:17:52Z DEBUG Successfully updated nsDS5ReplicaId. 2019-01-21T13:17:52Z DEBUG Add or update replica config cn=replica,cn=dc=platypusnet,dc=org,cn=mapping tree,cn=config 2019-01-21T13:17:52Z DEBUG Unhandled LDAPError: OPERATIONS_ERROR: {'desc': 'Operations error'}
Hi,
this portion of code is checking if the entry is already existing. If yes, the entry is updated, otherwise the entry is created. In the logs, it looks like the entry is not present yet and the replica installer tries to add it. The add fails with OPERATIONS_ERROR. Can you check in 389-ds access and error log if there is any message related to a ADD operation on the entry cn=replica,cn=dc=platypusnet,dc=org,cn=mapping tree,cn=config ?
flo
Florence,
Thanks.
I am afraid the error log is silent about this, the access log reports no error. The relevant part is below.
Hi,
did you check the access log on the master or on the replica being installed? Also keep in mind that the timestamps in 389-ds logs are using the machine's timezone and not UTC time (they may differ from the timestamp in ipareplica-install.log where UTC is used).
I tried capturing packets, but there was some TLS inssue in my way of reading the info...
Can I increase the logging of the dirsrv, so that I can see what exactly it tries to do?
The access log level is set through the attribute nsslapd-accesslog-level in the entry cn=config (see [1]). The error log level is set through the attribute nsslapd-errorlog-level in cn=config (see [2]).
HTH, flo
[1] https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
[2] https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/ht...
Further, seem to not know how to query the cn=config root. In the cn=replication,cn=... the nsDS5ReplicaId is 15.
Thanks and regards,
Arjen
[31/Jan/2019:11:46:45.895445398 +0100] conn=9065 op=3 SRCH base="cn=replication,cn=etc,dc=platypusnet,dc=org" scope=0 filter="(objectClass=* )" attrs=ALL [31/Jan/2019:11:46:45.896294824 +0100] conn=9065 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0001390211 [31/Jan/2019:11:46:45.906941102 +0100] conn=9065 op=4 SRCH base="cn=schema" scope=0 filter="(objectClass=*)" attrs="attributeTypes objectCla sses" [31/Jan/2019:11:46:46.159243241 +0100] conn=9065 op=4 RESULT err=0 tag=101 nentries=1 etime=0.0252611273 [31/Jan/2019:11:46:46.304279134 +0100] conn=9065 op=5 MOD dn="cn=replication,cn=etc,dc=platypusnet,dc=org" [31/Jan/2019:11:46:46.338464637 +0100] conn=9065 op=5 RESULT err=0 tag=103 nentries=0 etime=0.0034589580 [31/Jan/2019:11:46:46.438671736 +0100] conn=9063 op=17 UNBIND [31/Jan/2019:11:46:46.438750517 +0100] conn=9063 op=17 fd=151 closed - U1 [31/Jan/2019:11:46:50.733020153 +0100] conn=9065 op=6 UNBIND
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org
-
Arjen Heidinga -
Florence Blanc-Renaud