in fact, there's no sense to have "two segments" one
from ipa1 <--> ipa2
and other ipa1 --> ipa2.
you should delete the segment that is showing "right-left" connectivity.
ipa: ERROR: Server is unwilling to perform: Removal of Segment disconnects
topology. Deletion not allowed.
---
Tried on both masters.
On Mon, Feb 11, 2019 at 1:47 PM dbischof--- via FreeIPA-users <
freeipa-users(a)lists.fedorahosted.org> wrote:
> On Mon, 11 Feb 2019, German Parente via FreeIPA-users wrote:
>
>> don't forget "-r" to export. If not, replication metadata will not
be
>> exported and after the import, the replicas will not be in sync.
>
> thank you for your hints.
>
> Unfortunately, the replication/topology problem remains unsolved.
>
> Here's what i did:
>
> --- ipa1 (IPA running)
> db2ldif.pl -Z EXAMPLE-COM -D "cn=Directory Manager" -r -w - -n ipaca -a
> /tmp/foo.dif
> ---
>
> Copied the file over to ipa2, then
>
> --- ipa2 (IPA not running)
> ldif2db -Z EXAMPLE-COM -n ipaca -i foo.dif
> ---
>
> Started IPA on ipa2, but still
>
> ---
> $ ipa topologysegment-find ca
> ------------------
> 2 segments matched
> ------------------
> Segment name:
ipa2.example.com-to-ipa1.example.com
> Left node:
ipa2.example.com
> Right node:
ipa1.example.com
> Connectivity: both
>
> Segment name:
ipa1.example.com-to-ipa2.example.com
> Left node:
ipa1.example.com
> Right node:
ipa2.example.com
> Connectivity: left-right
> ----------------------------
> Number of entries returned 2
> ----------------------------
>
> In case there's nothing obvious and easy left to be tried out, I'd
> consider to uninstall IPA on ipa2, reinstall as client and promote ipa2 to
> master again as described in the docs.
>
>> On Thu, Feb 7, 2019 at 3:46 PM dbischof--- via FreeIPA-users <
>> freeipa-users(a)lists.fedorahosted.org> wrote:
>>
>>> On Wed, 6 Feb 2019, German Parente via FreeIPA-users wrote:
>>>
>>>> this is a bug in the product that might have been fixed already:
>>>>
>>>> Connectivity: left-right
>>>>
>>>> we cannot have these sort of connectivity.
>>>>
>>>> In ipa02 there's no replication agreement to ipa01 (for ipaca
>>>> database).
>>>>
>>>> But as in ipa01 we see that the topology is showing "both" in
the
>>>> connectivity, I suggest to do export-import "off line" of the
>>>> database. Then the topology subtree will be set in ipa02, exactly as
>>>> in ipa01, and the topology plugin will create automatically the
>>>> replication agreement that is missing now.
>>>>
>>>> export from ipa01 the backend ipaca and re-import it in ipa02. Then,
>>>> start the server and check if now it's showing "both" in
connectivity
>>>> at ipa02 side.
>>>
>>> thank you for your hints.
>>>
>>> Unfortunately, I never did something like this before (and I can't
>>> access the article you cited below). According to the Directory Manager
>>> docs, it's probably something like
>>>
>>> ---
>>> db2ldif.pl -Z EXAMPLE-COM -D "cn=Directory Manager" -w - -n ipaca
-a /tmp/foo.dif
>>> ---
>>>
>>> to export on running ipa1 and
>>>
>>> ---
>>> ldif2db -Z EXAMPLE-COM -n ipaca -i /tmp/foo.dif
>>> ---
>>>
>>> to import on ipa2 with IPA not running, right? Something else to be
>>> taken into account to not break something (these are production
>>> servers - my group is small but vigorous ;-)
>>>
>>>> On Wed, Feb 6, 2019 at 4:57 PM dbischof--- via FreeIPA-users
>>>> <freeipa-users(a)lists.fedorahosted.org> wrote:
>>>>
>>>>> On Wed, 6 Feb 2019, German Parente via FreeIPA-users wrote:
>>>>>
>>>>>> have you tried to use "ipa-csreplica-manage re-initialize
--from
>>>>>> <replica1>" in replica1 ?
>>>>>
>>>>> Thanks for your answer.
>>>>>
>>>>> I already tried (on ipa2)
>>>>>
>>>>> ---
>>>>> $ ipa-csreplica-manage re-initialize --from
ipa1.example.com
>>>>> ---
>>>>>
>>>>> which failed.
>>>>>
>>>>> Interestingly enough, the error message is
>>>>>
>>>>> ---
>>>>> unexpected error: Replication agreement for
ipa1.example.com
>>>>> not found
>>>>> ---
>>>>>
>>>>> And indeed:
>>>>>
>>>>> ---
>>>>> $ ipa topologysegment-find ca
>>>>> ------------------
>>>>> 2 segments matched
>>>>> ------------------
>>>>> Segment name:
ipa2.example.com-to-ipa1.example.com
>>>>> Left node:
ipa2.example.com
>>>>> Right node:
ipa1.example.com
>>>>> Connectivity: both
>>>>>
>>>>> Segment name:
ipa1.example.com-to-ipa2.example.com
>>>>> Left node:
ipa1.example.com
>>>>> Right node:
ipa2.example.com
>>>>> Connectivity: left-right
>>>>> ----------------------------
>>>>> Number of entries returned 2
>>>>> ----------------------------
>>>>> ---
>>>>>
>>>>> The Web UI topology graph doesn't reflect this, btw.
>>>>>
>>>>> Isn't the 2nd segment obsolete and probably causing my CS
replication
>>>>> issues? Just remove it?
>>>>>
>>>>>> You could also re-init off line by using this article:
>>>>>>
>>>>>>
https://access.redhat.com/solutions/140483
>>>>>>
>>>>>> only for ipaca backend.
>>>>>>
>>>>>> On Wed, Feb 6, 2019 at 11:31 AM dbischof--- via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
>>>>>>
>>>>>>> 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.