Brian Topping via FreeIPA-users wrote: > 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.
Your best bet IMHO is standing up a new server as a replica with all optional services (CA, DNS, etc) and set it as the renewal master, ensure it has a DNA config (by adding a user or group) and then decommissioning the old server. I mean, you *could* do what you suggested and apply incremental updates but you're looking at upgrading 5 versions minimum (to F28). At a minimum yes, you should setup a replica to ensure that the upgrade doesn't blow your environment up. Be sure to ensure your certificates are in good order before starting (getcert list). We generally recommend at least 2 masters with a CA. I realize this may be a bit overkill in such a small environment, you could easily suffer from single point of failure. rob > > Sent from my iPhone > > On Dec 17, 2018, at 20:49, Roberto Cornacchia > <[email protected] <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 <[email protected] >> <mailto:[email protected]>> 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 -- >> [email protected] >> <mailto:[email protected]> >> > To unsubscribe send an email to >> [email protected] >> <mailto:[email protected]> >> > 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/[email protected] >> > > > _______________________________________________ > FreeIPA-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
