You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by satish jupalli <ju...@gmail.com> on 2014/02/24 10:20:34 UTC
Tomcat upgrades/security patching best practises
Hi,
What are the best practices for upgrading the tomcat given the fact that
they are no direct security patches available.
Specially with the environments where there are large instances of Tomcat
servers running it is challenging to upgrade these servers manually in all
the systems.
Are there any best practices defined for doing this given the frequency of
security patches being applied on Tomcat (Leave alone JDK patches)
Regards
Satish J
Re: Tomcat upgrades/security patching best practises
Posted by satish jupalli <ju...@gmail.com>.
Thanks Mark. That helped a lot.
On Mon, Feb 24, 2014 at 5:50 PM, Mark Thomas <ma...@apache.org> wrote:
> On 24/02/2014 09:20, satish jupalli wrote:
> > Hi,
> >
> > What are the best practices for upgrading the tomcat given the fact that
> > they are no direct security patches available.
> >
> > Specially with the environments where there are large instances of Tomcat
> > servers running it is challenging to upgrade these servers manually in
> all
> > the systems.
> >
> > Are there any best practices defined for doing this given the frequency
> of
> > security patches being applied on Tomcat (Leave alone JDK patches)
>
> Use a separate $CATALINA_HOME and $CATALINA_BASE.
>
> Upgrading should then be as simple as:
> - modify the init.d script to point to the new $CATALINA_HOME (you can
> safely use the new Tomcat version to stop the old one).
> - stop the instance
> - start the instance
>
> You can use rsync to have multiple servers all pick up the new
> CATALINA_HOME (note you don't want to replace the old one with the new
> one, you need to have multiple CATALINA_HOMEs alongside each another).
>
> You could even use rsync to update the init.d script.
>
> You could probably go further still with the automation and have it
> handle the restart too but how best to do that for your environment (if
> indeed it even makes sense to go further) is going to vary from
> installation to installation.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
Re: Tomcat upgrades/security patching best practises
Posted by Mark Thomas <ma...@apache.org>.
On 25/02/2014 12:58, Paul Beckett wrote:
>> I can't tell how much easier it is to manage Tomcat installations
>> (even small ones) with these two separated: Tomcat base install goes
>> one place, your configuration and everything you need goes another.
>> Upgrades are as simply as changing the CATALINA_HOME path, and
>> downgrades (if necessary) are just as simple.
>
> I've been running my tomcat 7 servers with CATALINA_HOME and CATALINA_BASE separated. However, I've noticed that the majority of dot releases in the 7 series have changes to files in the conf directory. I have therefore always been merging in these changes into my conf directory. Can these conf changes be safely ignored?
It depends on the change. You'd need to look at it on a case by case basis.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat upgrades/security patching best practises
Posted by Daniel Mikusa <dm...@gopivotal.com>.
On Feb 25, 2014, at 7:58 AM, Paul Beckett <pa...@outlook.com> wrote:
>> I can't tell how much easier it is to manage Tomcat installations
>> (even small ones) with these two separated: Tomcat base install goes
>> one place, your configuration and everything you need goes another.
>> Upgrades are as simply as changing the CATALINA_HOME path, and
>> downgrades (if necessary) are just as simple.
>
> I've been running my tomcat 7 servers with CATALINA_HOME and CATALINA_BASE separated. However, I've noticed that the majority of dot releases in the 7 series have changes to files in the conf directory. I have therefore always been merging in these changes into my conf directory.
Sounds like you’re on the right track here.
> Can these conf changes be safely ignored?
In general, I would say no, just to lean on the side of caution. However I suppose it depends on what has been changed. If you’re curious, you could look up the config option that was changed / added / removed, see what it does (in the docs) and perhaps why it was changed (changelog, bugzilla or svn). That could give you enough context to make your own decision about it.
Dan
> Thanks,
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: Tomcat upgrades/security patching best practises
Posted by Paul Beckett <pa...@outlook.com>.
> I can't tell how much easier it is to manage Tomcat installations
> (even small ones) with these two separated: Tomcat base install goes
> one place, your configuration and everything you need goes another.
> Upgrades are as simply as changing the CATALINA_HOME path, and
> downgrades (if necessary) are just as simple.
I've been running my tomcat 7 servers with CATALINA_HOME and CATALINA_BASE separated. However, I've noticed that the majority of dot releases in the 7 series have changes to files in the conf directory. I have therefore always been merging in these changes into my conf directory. Can these conf changes be safely ignored?
Thanks,
Paul
Re: Tomcat upgrades/security patching best practises
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mark,
On 2/24/14, 4:50 AM, Mark Thomas wrote:
> On 24/02/2014 09:20, satish jupalli wrote:
>> Hi,
>>
>> What are the best practices for upgrading the tomcat given the
>> fact that they are no direct security patches available.
>>
>> Specially with the environments where there are large instances
>> of Tomcat servers running it is challenging to upgrade these
>> servers manually in all the systems.
>>
>> Are there any best practices defined for doing this given the
>> frequency of security patches being applied on Tomcat (Leave
>> alone JDK patches)
>
> Use a separate $CATALINA_HOME and $CATALINA_BASE.
+1
I can't tell how much easier it is to manage Tomcat installations
(even small ones) with these two separated: Tomcat base install goes
one place, your configuration and everything you need goes another.
Upgrades are as simply as changing the CATALINA_HOME path, and
downgrades (if necessary) are just as simple.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTC+9KAAoJEBzwKT+lPKRYFTMP/igVwM4G36DJAGuFR264VfL6
T4I+N/XKYlKOBdg0yRO8LBhastCCxFoPd7gvzBuMjrgYqaA6Yfvj5CJ9fJJsSWDW
qT9wh+//b/DY/VWrIFUrT+yBMLWfkVFV2kOiNqTDwhgH9L8YF4WW7PQJlIgl9nhr
duClzSS9ZDNwPbLsyj+xbbUHrF7XjwD02Ofpf7xk/KZp6ihNQNEPavgvMTycKu2W
7BtsfYC+OLBofJi/KFhRAgJd4AtclhHDU42665Fhl7YMyuqcLqvmviY0v190o0m8
jKN/pS2+g2PKdM8Ictq3QVr1PsmjLB5G7MnuroON3210CSVsINTOAjzIW8s3kuWM
CKSJML/rNk6Vz56BTC0qCPPFCceYyVWQbBQy7HL3xE5JZpDV1JpGZg0991omhdD6
Dbto3c/+EHGoo9bjceRYmtHMHO6CHBfa/UtrsTtuiooT16kHyQRbRt1MiB2Mbmqv
3wLx+5fk/mcR8rAqrcnlaB944ybJ0vVtgbxy9V9sUP0YXAejYuMxhV7P2K5Wk/N5
EUJiMK7Qf8ecBwPkHkHRIEjKhzujm9bi8AHcIJDESl07nyEfnYKmYbimCey1+etn
MHQkzz8eDeJovdx4LMpd0b0Jx8Qv2TCy2mn3K3ZLhnY/bO0yw+JDWKK6xa+ckl4L
5Q7pdKUMthLp/osjtJXz
=ds/z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Tomcat upgrades/security patching best practises
Posted by Mark Thomas <ma...@apache.org>.
On 24/02/2014 09:20, satish jupalli wrote:
> Hi,
>
> What are the best practices for upgrading the tomcat given the fact that
> they are no direct security patches available.
>
> Specially with the environments where there are large instances of Tomcat
> servers running it is challenging to upgrade these servers manually in all
> the systems.
>
> Are there any best practices defined for doing this given the frequency of
> security patches being applied on Tomcat (Leave alone JDK patches)
Use a separate $CATALINA_HOME and $CATALINA_BASE.
Upgrading should then be as simple as:
- modify the init.d script to point to the new $CATALINA_HOME (you can
safely use the new Tomcat version to stop the old one).
- stop the instance
- start the instance
You can use rsync to have multiple servers all pick up the new
CATALINA_HOME (note you don't want to replace the old one with the new
one, you need to have multiple CATALINA_HOMEs alongside each another).
You could even use rsync to update the init.d script.
You could probably go further still with the automation and have it
handle the restart too but how best to do that for your environment (if
indeed it even makes sense to go further) is going to vary from
installation to installation.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org