Hi Boris,
On Wed, Aug 5, 2020 at 2:16 PM Boris Behrens via FreeIPA-users
<freeipa-users(a)lists.fedorahosted.org> wrote:
Hello François,
thank you for your answer. As you may have guessed I am very new to freeIPA, so please
don't get annoyed. If you point me to the documentation for a topic I can begin to
work with that.
Don't worry too much, and noted.
Am Mi., 5. Aug. 2020 um 13:49 Uhr schrieb François Cami
<fcami(a)redhat.com>:
>
> Hi,
>
> On Wed, Aug 5, 2020 at 1:34 PM Boris Behrens via FreeIPA-users
> <freeipa-users(a)lists.fedorahosted.org> wrote:
> > I have two freeipa servers which are running on an old operating system
(Fedora26) and I want to migrate it to centos8.
>
> Are these two hosts identical in terms of roles? E.g. if you use the
> integrated CA, do you have the CA installed on both?
Yes, both IPA servers hold the CA. AFAIK both system work in a master-master construct.
OK.
> > Because there are not enough resources in our mgmt cluster I
need to shut one of them down and reinstall with the new OS (while keeping the name), let
them sync and so on.
>
> Keeping the name will probably not work as-is. You would need to
> remove it from the cluster first and make sure you have no objects in
> the LDAP tree referencing it before adding a new one with the same
> name.
Oh, that sounds not that easy, but I think it is doable for me.
* "remove it from the cluster" is "ipa-server-install --uninstall"
* then search the ldap tree using ldapsearch with admin creds.
> However, it is dangerous to remove one of your two servers
before
> having added a complete third member for data loss reasons: having a
> single copy of your data at any point in time is not reasonable.
This is one of my troubling points, but I think I could take the risk. Both are KVM
virtualized, so I could create regular snapshots of the qemu image and move it elsewhere.
There aren't many changes. We use it primarily for SSSD authentication dns DNS.
Ideally then, do a cold copy of the images or cold snapshots at the
same time (e.g. shut them both down at the same time).
> > But here is the issue: We have systems that talk only to
ipa1 and systems that talk only to ipa2. I would like to add the IP address of ipa2 to
ipa1 and then proceed with the migration.
>
> I don't think this would work OOTB for the reason you expose below.
>
> > There is no option to make changes to those systems. They will get removed from
our infrastructure but this may take another year, and I don't want to wait any longer
with the migration.
>
> "to those systems" = to the client systems right?
yes.
> > Is this even possible? I can think of problems with certificates that say
"I am ipa1" when a systems asks expects ipa2 to answer.
> >
> > I would be really nice if someone could help me solve the problem.
>
> Your constraints are too strict for this migration.
Pardon? I don't understand? My constraints are:
* ipa1 and ipa2 need to be reachable while we migrate (the could live on one single
instance for the migration time)
* I have not enough hardware to afford another IPA VM with 8GB RAM (you wouldn't
believe how tight the mgmt hardware is packed)
Sorry, that was not clear enough: the second constraint is the one
that makes everything hard, especially since you have clients
configured for ipa1, and others for ipa2, without the usual failover
sssd mechanism.
> First, do you have full backups (ipa-backup) of both replicas?
Not yet. This is something I plan to implement ASAP.
Please.
> ipa-restore cannot restore these on anything but identical OS
images
> than the backup they were taken on, but this would add some safety to
> what you will be attempting.
It would if it could. It would make the migration super easy, if I understand it
correctly.
Not really. But having (verified) backups would help you feel better
about this as you could always restore from them.
I should mention documentation links now.
Planning:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
Disaster recovery documentation lives at:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
> Then, to do this safely you will have to add a new CentOS8
replica
> (ipa3) to your cluster, make sure it has all the roles (CA, KRA if
> you're using it, DNS, etc), promote the new replica's CA to Renewal
> and CRL Master, then remove one of the Fedora 26 replicas, replace it
> with a CentOS8 replica, same with the last Fedora 26 instance. Thus
> you would end up with ipa1 and ipa2 again, plus ipa3 if you care to
> keep it. If you do not, remember to promote the new ipa1 to Renewal
> and CRL Master first.
Is it possible to rename the IPA server afterwards?
No. Each IPA server is tied to its FQDN for everything. This is why
the above procedure does not use renaming ; it replaces the servers
instead.
Maybe I could shrink the memory size from 8GB to 4GB while I am
migrating. This would solve some of the "not enough hardware"-issues. A
colleague told me that IPA is very memory hungry, and in fact it uses the whole memory the
VM provides.
Make sure you have enough swap enabled (I'd say at least 8GB) and
monitor memory usage for a while. That would give you enough data to
understand how much you could save, however installing a replica can
lead to resource usage spikes on both sides.
François
> But you probably knew that and it is not the "help" you
were looking
> for, considering your hardware constraints.
:-)
_______________________________________________
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://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...