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(a)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(a)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/...
Best regards,
--Daniel.