Dear list,

I dug into this a little further. Learned about domain levels and that the procedure to remove replicas depends on those levels. Results appear to be, however, the same:

--- root@o201:~# ipa-replica-manage del poolsrv.example.org 'o201.example.org' has no replication agreement for 'poolsrv.example.org' [when i first tried this, it claimed it had removed the agreement]

root@o201:~# ipa-replica-manage list o201.example.org: master poolsrv.example.org: master o200.example.org: master

root@o201:~# ipa-csreplica-manage del poolsrv.example.org 'o201.example.org' has no replication agreement for 'poolsrv.example.org' [when i first tried this, it claimed it had removed the agreement]

root@o201:~# ipa-csreplica-manage list o201.example.org: master poolsrv.example.org: master o200.example.org: master ---

o201: new 4.4 master poolsrv: old 3.0 master (to be reinstalled as new replica) o200: old 3.0 replica (will be wrecked)

It seems like the new server just won't let me remove old replication agreements. I want to reinstall poolsrv (old master) and use it as (new) replica, but I'm reluctant to do so, because i suspect that replica creation may fail since the new master still has the old replication agreement. poolsrv still shows up in the database:

--- root@o201:~# ldapsearch -Y GSSAPI -H ldap://o201.example.org -D "cn=Directory Manager" -b "cn=config" SASL/GSSAPI authentication started SASL username: admin@EXAMPLE.ORG SASL SSF: 56 SASL data security layer installed. [...] # replica, dc\3Dexample\2Cdc\3Dorg, mapping tree, config dn: cn=replica,cn=dc\3Dexample\2Cdc\3Dorg,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaBindDN: krbprincipalname=ldap/poolsrv.example.org@EXAMPLE.ORG,cn=services,cn=accounts,dc=example,dc=org nsDS5ReplicaId: 6 nsDS5ReplicaName: 1879e115-452011e7-8712f490-137e9691 nsDS5ReplicaRoot: dc=example,dc=org nsDS5ReplicaType: 3 nsState:: BgAAAAAAAACN5i9ZAAAAAAAAAAAAAAAABAAAAAAAAAACAAAAAAAAAA== nsds5ReplicaLegacyConsumer: off nsds5replicabinddngroup: cn=replication managers,cn=sysaccounts,cn=etc,dc=example,dc=org nsds5replicabinddngroupcheckinterval: 60 objectClass: nsds5replica objectClass: top objectClass: extensibleobject nsds5ReplicaChangeCount: 7661 nsds5replicareapactive: 0 [...] ---

I'd really appreciate any hints...

On Wed, 31 May 2017, dbischof--- via FreeIPA-users wrote:

I'm in the process of upgrading my IPA installation (1 master, 1 replica, external DNS) from IPA version 3.0 to 4.4.

I followed the instructions at [1].

Everything worked flawlessly (kudos to all developers and supporters!): My new 4.4 master is up and running.

To my understanding, the last step would be to remove the still existing replication agreements of the old 3.0 master and replica before creating the new 4.4 replica (the new 4.4 master is new hardware with a new hostname, but i want to keep the old hardware and hostname for the 4.4 replica).

My attempt to remove the old servers result in

---

root@o201:~# ipa server-del poolsrv.example.org Removing poolsrv.example.org from replication topology, please wait... ipa: ERROR: an internal error has occurred

---

The error occurs even if i try to remove a non-existing server with --force. Attempts to remove the server via the web interface fail as well.

IPA/OS versions:

---

root@o201:~# cat /etc/redhat-release CentOS Linux release 7.3.1611 (Core)

root@o201:~# rpm -qa | grep -i ipa libipa_hbac-1.14.0-43.el7_3.14.x86_64 python-libipa_hbac-1.14.0-43.el7_3.14.x86_64 ipa-server-common-4.4.0-14.el7.centos.7.noarch python2-ipalib-4.4.0-14.el7.centos.7.noarch ipa-client-4.4.0-14.el7.centos.7.x86_64 ipa-common-4.4.0-14.el7.centos.7.noarch ipa-client-common-4.4.0-14.el7.centos.7.noarch python-ipaddress-1.0.16-2.el7.noarch python2-ipaserver-4.4.0-14.el7.centos.7.noarch sssd-ipa-1.14.0-43.el7_3.14.x86_64 ipa-admintools-4.4.0-14.el7.centos.7.noarch python2-ipaclient-4.4.0-14.el7.centos.7.noarch python-iniparse-0.4-9.el7.noarch ipa-server-4.4.0-14.el7.centos.7.x86_64

---

Something I could try?

[1] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/htm...

Best regards,

--Daniel.

Hi Rob,

On Thu, 1 Jun 2017, Rob Crittenden via FreeIPA-users wrote:

dbischof--- via FreeIPA-users wrote:

...

I dug into this a little further. Learned about domain levels and that the procedure to remove replicas depends on those levels. Results appear to be, however, the same:

---

root@o201:~# ipa-replica-manage del poolsrv.example.org 'o201.example.org' has no replication agreement for 'poolsrv.example.org' [when i first tried this, it claimed it had removed the agreement]

root@o201:~# ipa-replica-manage list o201.example.org: master poolsrv.example.org: master o200.example.org: master

This just lists all the masters not their relationships. You'd need to run on each one "ipa-replica-manage list -v' and note the agreements.

...

root@o201:~# ipa-csreplica-manage del poolsrv.example.org 'o201.example.org' has no replication agreement for 'poolsrv.example.org' [when i first tried this, it claimed it had removed the agreement]

root@o201:~# ipa-csreplica-manage list o201.example.org: master poolsrv.example.org: master o200.example.org: master

Same.

Plus, if it claimed to have removed the agreement perhaps it really did. [...]

yeah, everything is fine now, new master and new replica are working together like a charm. I was over-anxious and also read the wrong documentation (for domain level 1 while operating at 0). Finally, a

--- ipa-replica-manage --force --cleanup del poolsrv.example.org ---

on o201 did the trick. Thanks for your hint and once again: Kudos to all FreeIPA developers and supporters.

Best regards,

--Daniel.