Hi Roberto, my skills here are weaker than the actual team here but they are busy so I thought I might be able kick in a little. 

Please do be careful. I recently had a situation where I had a machine crash during initial replication due to a bad CPU. It caused a lot of problems. I did not make a snapshot of the replication target before I did it, and the previously stable master became locked to replication changes, including removing the failed install node. Since I am converting everything to Kubernetes anyway, I just decided to start over. It was a lesson learned. 

Proper snapshots would have meant I could just shut down, roll back, boot up and try again. 

Sent from my iPhone

On Dec 17, 2018, at 20:49, Roberto Cornacchia <roberto.cornacchia@gmail.com> wrote:

Brian, 

Thanks for your suggestions. 
Actually using the Docker image seems very attractive, if it is close to production quality. I can experiment anyway.

What I don't really know is whether I can experiment with creating replicas of the current server. I mean, can creating replicas harm the existing server in any way, in case something goes wrong? 

On Mon, 17 Dec 2018 at 13:17 Brian Topping <brian.topping@gmail.com> wrote:
Have you considered starting to use the docker image? I knew that there was upgrade and it worked very well, completely automated.

Maybe start separate test cluster with older image, then experience the upgrade. When you are satisfied, use the docker image that is the same version as your current cluster, then upgrade it.

Anyway, if that is uncomfortable, try to learn how to verify that the replicas are synchronized with CLI. When you can confirm that the replicas are synchronized, your plan is easier because you can also confirm at the end that they are still synchronized.

I would also do this with three replicas, not two. Then when you shut down A replica, you can confirm B and C are properly replicating as you upgrade before destroying A. If you get stuck, you can still safely start over.

Lastly, if you are using a system that supports snapshots, it’s the best way to keep the original copy of a replica before making changes. In the worst case, you can reset all the snapshots and reboot.

> On Dec 17, 2018, at 6:17 PM, Roberto Cornacchia via FreeIPA-users <freeipa-users@lists.fedorahosted.org> wrote:
>
> Dear all,
>
> Upgrading is always scary, I will appreciate any comment on the following.
>
> Our freeIPA is serving a small number of FC desktops and users (< 10), and is running on a FC 23 server, with packages for ipa versioned 4.2.4-2.fc23.
>
> The simplest thing I can do is of course to upgrade the FC system until the latest, one version at the time. What I probably want to do is actually move to CentOS - I'm fed up with running after FC releases.
>
> In both cases (especially in the second case), I thought it may be wise to make a replica of the ipa server before starting the upgrade.
>
> My plan would be:
> - Have an up-to-date CentOS system (IPA-B), enroll it and promote it to replica of the existing one (IPA-A)
> - [ Question: is it better to have IPA-B on a recent version or on the same version as IPA-A? ]
> - Shut down IPA-A
> - Verify that IPA-B works
> - Wipe out IPA-A, install recent CentOS.
> - Enroll IPA-A
> - Promote it to replica.
> - Enjoy
>
> Am I overlooking something? Could I do something more prudently?
>
> Thanks for your input!
> Roberto
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org