#2858 replication management between disparate versions
Closed: Fixed None Opened 11 years ago by rcritten.

Investigate replication management between a 2.2 two-instance install and 3.0 single instance install. How is CS replication managed?

Assume that the only way to upgrade from 2.2 to 3.0 is to create a new instance in 3.0, replicate the data, then slowly shut down the 2.2 hosts.


Notes so far:

  1. Going to need to document issues related to enrollment. New clients won't enroll against old servers and old clients won't enroll against new servers (the host_mod to add SSH keys may fail). This can be an issue if there are SRV records for both.

  2. I saw some LDAP Update failures due to schema update problems, ticket #2440.

Filed ticket https://fedorahosted.org/freeipa/ticket/3041 to handle the cause of replica-s4u2proxy.ldif failing to load. It is because it tries to add the cifs principal to the s4u2 proxy config but when upgrading to 3.0 from 2.2 that principal doesn't exist.

A patch is out for #2440 that solves the schema problem, so upgrade issues are otherwise clear.

I installed a 2.2 server, created a 3.0 clone and ran the unit tests against the 3.0 instance and it passed 100%.

I think what we want to prevent is going from a higher version to a lower one, so for example generating a replica file on 3.0 and installing in 2.2. We'll have to live with problems for a while since the 2.x servers aren't going to have a version in the replica file but going forward this should be fine.

ipa-csreplica-manage is bungling the DN entries when managing replicas pretty badly. connect/disconnect doesn't do at all what one would expect.

To test versioning you need to rip apart a prepared file and tweak the version forward or backward.

To do this, do something like:

# gpg -d replica-info-pitbull.example.com.gpg | tar xf -
# edit realm_info/realm_info
# tar cf replica-info-pitbull.example.com realm_info
# gpg --batch --homedir `pwd`/.gnupg --passphrase-fd 0 --yes --no-tty -o replica-info-pitbull.example.com.gpg -c replica-info-pitbull.example.com
<type in DM password>

This ticket has generated two patches:

  1. Add a version to the prepared replica file
  2. Fix ipa-csreplica-manage

While investigating ticket #2751 it was discovered that 2.1 replicas require an ldap password for the kdc. 2.2 and above servers have removed the kdc ldap password because the new ipa kdc driver does not bind with a password. Therefore 2.1 replicas cannot be created from 2.2 or above masters.

While testing ipa-csreplica-manage for this it became clear that parts of it didn't really work at all. It was possible to create agreements that were undeletable because the naming we were using was not consistent, so it couldn't find agreements to delete them. The --force flag was also not honored.

I tested by creating server A and then A->B and A->C. Then I created an agreement from B->C, then deleted A->C, so it looked like A->B->C. IIRC I then played around with other topologies, re-added agreements that had just been deleted, etc.

1051 acked, version is now included in replica info files.

master: 26dfbe6[[BR]]
ipa-3-0: 256bfca

Fix replica management using ipa-csreplica-manage.

master: 2ca7bb3

ipa-3-0: 3bbb697

Metadata Update from @rcritten:
- Issue assigned to rcritten
- Issue set to the milestone: FreeIPA 3.0 GA

7 years ago

Login to comment on this ticket.

Metadata