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(a)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(a)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(a)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(a)lists.fedorahosted.org
> > To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...