Handling Upgrades

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Handling Upgrades

Darryl Philip Baker
Until recently most of our Tomcat installations were using the Red Hat distributed version. A version of Tomcat7 with Red Hat backporting security and important break fixes. Red Hat has moved their redistribution of Tomcat to another package other than the OS. A package that it has been decided not to buy. This means I have to support a number of applications that have upgraded to Tomcat9 and are using the Apache-Tomcat binary distribution. This presents me with a problem of how to remain current for security and break-fix updates without spending a lot of people’s time, mine included, regression testing applications.

Is there a long-term support version (LTS) where only break-fix and security changes are made, and feature enhancements go into the next LTS?

Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL  60201-3715
[hidden email]<mailto:[hidden email]>
(847) 467-6674

Reply | Threaded
Open this post in threaded view
|

Re: Handling Upgrades

markt
On 14/09/2020 17:44, Darryl Philip Baker wrote:
> Until recently most of our Tomcat installations were using the Red Hat distributed version. A version of Tomcat7 with Red Hat backporting security and important break fixes. Red Hat has moved their redistribution of Tomcat to another package other than the OS. A package that it has been decided not to buy. This means I have to support a number of applications that have upgraded to Tomcat9 and are using the Apache-Tomcat binary distribution. This presents me with a problem of how to remain current for security and break-fix updates without spending a lot of people’s time, mine included, regression testing applications.
>
> Is there a long-term support version (LTS) where only break-fix and security changes are made, and feature enhancements go into the next LTS?

Sorry, no.

Mark


>
> Darryl Baker, GSEC  (he/him/his)
> Sr. System Administrator
> Distributed Application Platform Services
> Northwestern University
> 1800 Sherman Ave.
> Suite 6-600 – Box #39
> Evanston, IL  60201-3715
> [hidden email]<mailto:[hidden email]>
> (847) 467-6674
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Handling Upgrades

Christopher Schultz-2
In reply to this post by Darryl Philip Baker
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Darryl,

On 9/14/20 12:44, Darryl Philip Baker wrote:

> Until recently most of our Tomcat installations were using the Red
> Hat distributed version. A version of Tomcat7 with Red Hat
> backporting security and important break fixes. Red Hat has moved
> their redistribution of Tomcat to another package other than the
> OS. A package that it has been decided not to buy. This means I
> have to support a number of applications that have upgraded to
> Tomcat9 and are using the Apache-Tomcat binary distribution. This
> presents me with a problem of how to remain current for security
> and break-fix updates without spending a lot of people’s time, mine
> included, regression testing applications.
Maybe you can get some mileage out of EPEL?

https://fedoraproject.org/wiki/EPEL#What_is_Extra_Packages_for_Enterpris
e_Linux_.28or_EPEL.29.3F

I think I recently installed it on Amazon Linux to get some obvious
package that was missing for some unknown reason.

> Is there a long-term support version (LTS) where only break-fix
> and security changes are made, and feature enhancements go into the
> next LTS?
As Mark has already said, no, such a package doesn't exist. Tomcat
releases, however, are usually very stable and rarely break things.

I feel comfortable upgrading Tomcat to the latest version in our
development environments and then pushing to production once we've had
it there for a short period of time (maybe 3 weeks).

- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fvA0ACgkQHPApP6U8
pFg0yRAAueoQLlWXX0JSnokgvGeTtPLTuNpjPSCS0QnDg8wxfRuCG5CfEtfHgeJp
/ixC8HhVcJBSaoiG32KDXBCJLRt4Q0wlWdOQchQeTMW1ESHLrYg8EiKsBGsCU6RV
sleMstFFyRYB3nvpxIELAz9/X7XeDolpk4GCKJSzr4RFrH+0oEBweCKgUzBT9/mg
1d5rVO6xXqhKAUwDp77CgnVfFCAaDNelRwlmIzvXBsbbOFdo1ULsy3rLU/oq4+QL
b23WUewvk3dgZ8zoy8e7WWf4y4ZwDzEp/vTlcIqWxx/ntSf8PieiCTdRpj4A7R6N
3VML4XUllQGi1ayJPs3uAq9rDKHi8lSt/D9qBDkIQUag4ywCVsKAOmWsSBehVRHs
g5/QjzMfZshgJ/g7/HsF48Asns6w+58zRvqxtL4Z/7xQIgp3Gez1DG+ZsCrzY5Hl
1pWcvQkTjOZ4VcrIffx1bwoPSw9nrz/KqLmrtD0CtOkJX4lCIlZulOdirUn7P7JM
hUB+SsCcrFoNfeDGbTYX05HJaoqAmV1Qtd09wNoo19yruTO9sq54bK9UWF/7MSX/
dag8o8WMZttZfvjQyNkidfVF7z9q4oJOd5iuk/lnsqK7cZqN7+5pAbOw9YgnqEFT
ESSVO3XRiclAhU+kREu3nG9+09Qxf7ucqo81IRhZ0b1JhsZMMNg=
=/5Gy
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]