Appreciate the response.
Unfortunately, I’ve got the hand i’ve been deal with. Our machines normally have 1-2 but
if someone hardcodes a single DNS it’s probably going to the main server. The systems
using DHCP would be fine…but for the ones that aren’t it will just all break.
No matter, to me this seems all very complicated. In my eyes it would be way more fragile
than a single dot version upgrade. Is FreeIPA that sensitive going from 4.5 to 4.6?
Is FreeIPA really this fragile? I’ve honestly been nervous with this mess because I feel
if something fails, I’ll never get it back running properly as it’s less like a “ok let’s
reset and start over”.
Honestly what I feel like my quickest and best approach is to snapshot all of the IPA
systems, pick one to run yum update on and see what happens. If it breaks, simply revert
all of them back. Would this be a really bad idea?
-Kevin
> On Feb 8, 2023, at 8:59 PM, Jernej Jakob <jernej.jakob(a)abak.si> wrote:
>
> I forgot one more option. Since the first server is older than the
> other 2, you could not upgrade it but just shut it down. Follow the
> procedures: promote one of the two newer servers to CA renewal master,
> follow steps to decomission/remove the server from the domain, remove
> DNS SRV and A/AAAA records. Remove RUVs pointing to it. Then change the
> IP of that server's NIC to something else, and assign its IP(s) to one
> of the other 2 servers (add alias/es). So requests for DNS will then
> hit one of the remaining servers. Someone more knowledgeable can
> confirm if this is a good option - I personally did this and it worked
> (temporarily until I can change the DNS settings on all machines with
> static config).
>
>> On Thu, 9 Feb 2023 03:44:35 +0100
>> Jernej Jakob via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
>> wrote:
>>
>> On Wed, 8 Feb 2023 09:53:35 -0600
>> Kevin Vasko via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org>
>> wrote:
>>
>>> Thanks Rafael.
>>>
>>> I was hoping to do it in place if at all possible because where things get
>>> complicated is the 4.5.4 server is also the internal DNS server that
>>> everyone utilizes (we have multiple but people just use the 1 mainly). It
>>> really was their "main" server. I added the other two replicas a
few years
>>> ago to make sure we had something. They contacted me and wanted help to
>>> upgrade everything so here I am. Making any modifications to it will
>>> probably make everything go heywire (or at least break DNS for everyone).
>>> That is unless I get it back immediately by
>>>
>>> 1. adding a 4th server
>>> 2. promoting the 4th server to master
>>> 3. decommission the 4.5.4 server
>>> 4. reassign the 4th server the same IP as the old 4.5.4 server?
>>> 5. upgrade rest of servers
>>>
>>> Any thoughts? recommendations?
>>>
>>
>> IMO they really should be using at least 2, if not all 3, of those as
>> DNS servers. Then even if the primary is down, they should fail over to
>> the secondary or tertiary (with the only symptom being slow resolving,
>> so users will notice it, but will still be able to work).
>> I've only noticed one thing in my network not failing over to secondary
>> as it should, docker. If primary from resolv.conf is down, it will fail
>> over to Google's 8.8.8.8 instead of your secondary.
>> The other possibility is that you configure your firewall to DNAT
>> all requests on UDP/TCP port 53 to the other, working server. But this
>> will only work for requests coming from other networks which pass
>> through your router. It's why I use lots of VLANs, I have all the IPA
>> servers in their own VLAN so I could do this. But if you have other
>> machines in the same network they won't be passing through the router
>> so that won't be possible.
>> The third possibility is that you set up DNAT with masquerading on the
>> IPA server you will be upgrading, to translate packets to the other
>> server, masquerade to make the reply packets go back through the same
>> path (otherwise they may be dropped due to source IP mismatch). This
>> will work for all requests including those not passing the router, but
>> will only work while the OS is booted. So you can shut down IPA and it
>> will work but if you need to restart the OS it will also go down.
>>
>>>
>>>> On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman <rjeffman(a)redhat.com>
wrote:
>>>
>>>>
>>>>
>>>> On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
>>>> freeipa-users(a)lists.fedorahosted.org> wrote:
>>>>>
>>>>> We have a set of 3x freeIPA servers that have outdated (everything)
in a
>>>> development/test environment that need to be updated.
>>>>>
>>>>> It seems that 4.6.8-5.el7.centos.12 is the latest version available
on
>>>> CentOS 7?
>>>>>
>>>>> We are at on the 3 servers:
>>>>> 4.5.4-10.el7.centos.4.4
>>>>> 4.6.4-10-el7.centos.6
>>>>> 4.6.4-10-el7.centos.6
>>>>>
>>>>> For the two 4.6.4 installs, that seems relatively simple upgrade as
we
>>>> would only be going to a different dot release and a simple "yum
update
>>>> ipa-server" should handle this? Is there any advisement for/against
doing a
>>>> full "yum update" on the entire system to get everything
updated?
>>>>>
>>>>> For the 4.5.4 system, is there much of a concern going straight from
>>>> 4.5.4 to 4.6.8 straight? I assume the concern would be jumping major
>>>> versions and going from say 4.5 to 4.9?
>>>>>
>>>>> My current plan is to stop at CentOS 7.9 and latest FreeIPA 4.6
release
>>>> on CentOS 7.9. But for my own knowledge if I was going to 4.10
wouldn't the
>>>> recommendation path to upgrade to 4.10, to install CentOS Stream 9 on a
new
>>>> server, enroll it, make 4.10 the master and then remove the CentOS 7
>>>> instances?
>>>>>
>>>>
>>>> Assuming you can't have a 4th server, Is it possible for you to have
only
>>>> 2 replicas for some time? If so, you can remove the 4.5.4 server, fully
>>>> (cleanly?) upgrade it, add it back, set it as CA master, and repeat the
>>>> procedure with the other servers.
>>>>
>>>> As you are upgrading the whole OS, this would be more in line with the
>>>> current recommendation (see
>>>>
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/...
>>>> ).
>>>>
>>>> Rafael
>>>>
>>>>> -Kevin
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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...
>>>>> Do not reply to spam, report it:
>>>>
https://pagure.io/fedora-infrastructure/new_issue
>>>>
>>>>
>>>>
>>>> --
>>>> Rafael Guterres Jeffman
>>>> Senior Software Engineer
>>>> FreeIPA - Red Hat
>>>>
>> _______________________________________________
>> 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...
>> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue