Hi Florence,
On Wed, 6 Feb 2019, dbischof--- via FreeIPA-users wrote:
> On Wed, 6 Feb 2019, Florence Blanc-Renaud via FreeIPA-users wrote:
>
>> On 2/5/19 4:17 PM, dbischof--- via FreeIPA-users wrote:
>>>
>>> my IPA system consists of 2 masters (ipa1 and ipa2, both on FreeIPA
>>> 4.6.4) with their own self-signed CAs, one of them being the
>>> certificate renewal master (ipa1). The system has been running for
>>> years and has been migrated from an IPA 3 system. Both IPA servers
>>> are on domain level 1.
>>>
>>> Problem: CS replication failed, probably months ago.
>>>
>>> --- ipa1 ---
>>> $ ipa-csreplica-manage -v list
ipa1.example.com
>>>
>>>
ipa2.example.com
>>> last init status: None
>>> last init ended: 1970-01-01 00:00:00+00:00
>>> last update status: Error (-1) Problem connecting to replica -
>>> LDAP
>>> error: Can't contact LDAP server (connection error)
>>> last update ended: 1970-01-01 00:00:00+00:00
>>>
>>> --
>>> $ ipa-csreplica-manage -v list
ipa2.example.com
>>>
>>> [no output]
>>> ----
>>>
>>> Same on ipa2.
>>>
>>> Probably related:
>>>
>>> ---
>>> ERR - slapi_ldap_bind - Error: could not send startTLS request:
>>> error -1
>>> (Can't contact LDAP server) errno 107 (Transport endpoint is not
>>> connected)
>>> ---
>>>
>>> Every 5 mins in /var/log/dirsrv/slapd-EXAMPLE-COM/errors. However,
>>> these
>>> error messages could refer to
ipa3.example.com, a master i deleted
>>> long
>>> (>
>>> 2 years) ago:
>>>
>>> ---
>>> $ ipa-replica-manage list-ruv
>>>
>>> Replica Update Vectors:
>>> ipa2.example.com:389: 10
>>> ipa1.example.com:389: 9
>>> Certificate Server Replica Update Vectors:
>>> ipa2.example.com:389: 11
>>> ipa1.example.com:389: 91
>>> ipa2.example.com:7389: 96
>>> ipa3.example.com:7389: 97
>>> ---
>>>
>>> How do i track this down and resolve the problem?
>>>
>>>
>> please find more information re. 389-ds troubleshooting:
>> https://www.freeipa.org/page/Troubleshooting/Directory_Server
>
> I checked for the common problems described in that page already, but
> to no avail. I did, however, successfully manage to remove replication
> references to ipa3 using "ipa-replica-manage clean-dangling-ruv":
>
> ---
> $ ipa-replica-manage list-ruv
> Replica Update Vectors:
> ipa1.example.com:389: 9
> ipa2.example.com:389: 10
> Certificate Server Replica Update Vectors:
> ipa1.example.com:389: 91
> ipa2.example.com:389: 11
> ---
>
> The error message
>
> ---
> [06/Feb/2019:10:38:52.095489260 +0100] - ERR - slapi_ldap_bind -
> Error: could not send startTLS request: error -1 (Can't contact LDAP
> server) errno 107 (Transport endpoint is not connected)
> ---
>
> on ipa1 is still in the logs. Additionally, while cleaning ruvs:
>
> ---
> [06/Feb/2019:10:32:31.029394375 +0100] - ERR - NSMMReplicationPlugin -
> bind_and_check_pwp -
> agmt="cn=cloneAgreement1-ipa1.example.com-pki-tomcat" (ipa2:7389) -
> Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact
> LDAP server) ()
> ---
>
> The ldapsearch queries described in the above page can be carried out
> successfully on both servers:
>
> ---
> [...]
> # search result
> search: 4
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
> ---
>
> Also, no DNS issues, wrong entries /etc/hosts, time differences or log
> messages related to SASL issues.
>
> Maybe a wrong key or certificate somewhere?
update: ipa-checkcerts.py shows
---
[...]
Failures:
ipa: INFO: Unable to find request for serial 268304391
Unable to find request for serial 268304391
ipa: INFO: Unable to find request for serial 268304394
Unable to find request for serial 268304394
ipa: INFO: Unable to find request for serial 268304393
Unable to find request for serial 268304393
ipa: INFO: Unable to find request for serial 268304392
Unable to find request for serial 268304392
ipa: INFO: Subject
O=EXAMPLE.COM,CN=ipa2.example.com and template
subject
CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57
Subject
O=EXAMPLE.COM,CN=ipa2.example.com and template subject
CN=ipa1.example.com,O=EXAMPLE.COM do not match for serial 57
---
So there is a certificate issue.
Maybe. I haven't gotten confirmation from the dogtag team that these
types of "issues" are actually a problem.
What does ipa-replica-manage list -v `hostname` and ipa-csreplica-manage
list -v `hostname` show?
rob