Hi Boris, On Wed, Aug 5, 2020 at 2:16 PM Boris Behrens via FreeIPA-users <[email protected]> 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 <[email protected]>: >> >> Hi, >> >> On Wed, Aug 5, 2020 at 1:34 PM Boris Behrens via FreeIPA-users >> <[email protected]> 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/html/planning_identity_management/index Disaster recovery documentation lives at: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/performing_disaster_recovery_with_identity_management/index >> 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]
