dbischof--- via FreeIPA-users wrote:
> 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

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.

rob

> ---
> 
> 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: ad...@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....@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/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrate-6-to-7.html
>>
> 
> 
> Best regards,
> 
> --Daniel.
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to