[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check

2023-02-08 Thread Kevin Vasko via FreeIPA-users
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  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/ 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 
>> wrote:
>> 
>> On Wed, 8 Feb 2023 09:53:35 -0600
>> Kevin Vasko via FreeIPA-users 
>> 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  wrote:
>>> 
 
 
 On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
 freeipa-users@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 

[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check

2023-02-08 Thread Jernej Jakob via FreeIPA-users
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/ 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 
wrote:

> On Wed, 8 Feb 2023 09:53:35 -0600
> Kevin Vasko via FreeIPA-users 
> 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  wrote:
> >   
> > >
> > >
> > > On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
> > > freeipa-users@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
> > > 

[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check

2023-02-08 Thread Jernej Jakob via FreeIPA-users
On Wed, 8 Feb 2023 09:53:35 -0600
Kevin Vasko via FreeIPA-users 
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  wrote:
> 
> >
> >
> > On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
> > freeipa-users@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/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating
> > ).
> >
> > Rafael
> >  
> > > -Kevin
> > >
> > >
> > > ___
> > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > > To unsubscribe send an email to  
> > freeipa-users-le...@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.fedorahosted.org
> >   
> > > Do not reply to spam, report it:  
> > https://pagure.io/fedora-infrastructure/new_issue
> >
> >
> >
> > --
> > Rafael Guterres Jeffman
> > Senior Software Engineer
> > FreeIPA - Red 

[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check

2023-02-08 Thread Kevin Vasko via FreeIPA-users
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?


On Wed, Feb 8, 2023 at 5:43 AM Rafael Jeffman  wrote:

>
>
> On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
> freeipa-users@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/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating
> ).
>
> Rafael
>
> > -Kevin
> >
> >
> > ___
> > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> > To unsubscribe send an email to
> freeipa-users-le...@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.fedorahosted.org
> > 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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue


[Freeipa-users] Re: Upgrade outdated FreeIPA sanity check

2023-02-08 Thread Rafael Jeffman via FreeIPA-users
On Tue, Feb 7, 2023 at 6:29 PM Kevin Vasko via FreeIPA-users <
freeipa-users@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/html/migrating_to_identity_management_on_rhel_8/migrate-7-to-8_migrating
).

Rafael

> -Kevin
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
> 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@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue