Re: how to upgrade tomcat 8.5.x?

[Mark Eggers]

Chris,

On 5/20/2017 4:37 PM, Christopher Schultz wrote:
> Mark,
> 
> On 5/19/17 3:26 PM, Mark Eggers wrote:
>> GB,
> 
>> On 5/19/2017 8:28 AM, gkk gb wrote:
>>> If my current Tomcat is installed in
>>>
>>>
>>> /home/tomcat/dir1/apache-tomcat-8.5.9
>>>
>>>
>>> and then I install the latest Tomcat in
>>>
>>>
>>> /home/tomcat/dir1/apache-tomcat-8.5.15
>>>
>>>
>>> how does Apache web server know to connect to the newer version
>>> of Tomcat? Is this established by the definition of CATALINA_HOME
>>> in .bash_profile? Or, some other way?
>>>
> 
>> The connection is done (normally) via a port. It's either AJP and
>> the AJP port configured in server.xml, or HTTP (could be HTTPS) and
>> the HTTP (or HTTPS) port configured in server.xml
> 
>> This depends on how your Apache HTTPD server is configured.
> 
>> If you use the same ports, then only one Apache Tomcat can be
>> running at a time (can't have two processes listen on the same port
>> - technically address / port combination).
> 
>>>
>>> Can I install both Tomcat versions side by side and switch
>>> between them to verify everything works fine with the newer
>>> Tomcat before deleting the older Tomcat?
>>>
>>>
> 
>> Yep.
> 
>> 1. Install newer Tomcat 2. Make sure server.xml is set the way you
>> need it to be 3. Copy web applications over to new Tomcat
> 
> I would always recommend using separate CATALINA_HOME and
> CATALINA_BASE directories. You mention this below, but it's worth
> reinforcing the fact that upgrades become even easier once this split
> has been done.
> 
>> 4. Shut down old Tomcat 5. Start up new Tomcat 6. Test
> 
>> Then make a decision. If the your applications have difficulties
>> with the new Tomcat, shut down the new Tomcat, start the old
>> Tomcat, and debug the issues on a development / test environment.
> 
>> I do something similar to upgrade Tomcats, albeit with an Ant
>> script, separate CATALINA_HOME / CATALINA_BASE, and an appBase
>> outside of CATALINA_BASE.
> 
>> This allows me to install new Tomcat versions without taking down
>> the old Tomcat. When it comes time to upgrade, I do the following:
> 
>> 1. Shut down the Tomcat service 2. Move two links to the new Tomcat
>> version (CATALINA_HOME / CATALINA_BASE) 3. Start up the Tomcat
>> service
> 
>> If there are issues, I can easily fall back to the old Tomcat
>> with:
> 
>> 1. Shut down the Tomcat service 2. Move two links to the old Tomcat
>> version 3. Start up the Tomcat service
> 
>> All of the server.xml modification information is kept in a set of 
>> property files which are versioned. The Ant scripts use the
>> property files to configure Tomcat instances.
> 
> This is roughly what we do as well: our ant-based build scripts build
> server.xml (and context.xml for that matter) from a set of properties
> that are specific to the application (and environment).
> 
> And of course Tomcat is started/stopped with those same scripts :)
> 
> Come to think of it... did I give you my Ant scripts ages ago? Or did
> you develop your own? I think I may have promised to publish them, but
> maybe never did.
> 
> -chris

I developed my own. I use the Ant scripts just for customizing Tomcat
installations.

I do have one slight issue with my current Ant scripts. The link task
isn't supposed to create a link if it already exists, but it does, and
actually creates a link inside of the existing link. This means that I
have a manual cleanup step to do, which is annoying.

Also, the Ant xml task doesn't handle namespaces well. I'll have to
figure out how to mangle tomcat-users.xml in a better fashion for the
8.x series.

I use a custom-built init script for starting, stopping, querying, and
getting the version of a Tomcat services. I'll have to build something
soon to handle systemd.

I use Maven, the Tomcat Maven plugin, and Jenkins to customize a WAR
file for a particular environment. Coupled with parallel deployments,
this basically allows us to update with no downtime.

Mark
/mde/



signature.asc
Description: OpenPGP digital signature

Re: how to upgrade tomcat 8.5.x?

[Igal @ Lucee.org]

Chris,

On 5/20/2017 4:37 PM, Christopher Schultz wrote:


This is roughly what we do as well: our ant-based build scripts build
server.xml (and context.xml for that matter) from a set of properties
that are specific to the application (and environment).

And of course Tomcat is started/stopped with those same scripts :)

Come to think of it... did I give you my Ant scripts ages ago? Or did
you develop your own? I think I may have promised to publish them, but
maybe never did.


Can you post those scripts somewhere?  They can benefit many users.

Thanks,


Igal

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat 8.5: wrong classloader used during context startup?

[Mark Thomas]

On 21/05/2017 00:30, Christopher Schultz wrote:
> Mark,
> 
> On 5/19/17 3:45 PM, Mark Thomas wrote:
>> On 19/05/2017 15:25, Christopher Schultz wrote:

>>> Also, for an untrusted application (admittedly a minority use
>>> case), having Tomcat parse the app-provided XML with an
>>> application-provided XML parser might have security
>>> implications.
> 
>> I don't believe it does in this case. The file being parsed is
>> web.xml which is application provided anyway so any manipulation a
>> malicious app could do via the parser could just be done directly
>> in web.xml.
> 
> That's exactly my point: Tomcat is using an untrusted XML parser to
> parse untrusted XML. If the XML parser is trusted, then parsing the
> untrusted XML is safe(r).

I disagree.

> Take for example XML billion laughs or external entity attacks. These
> attacks are typically prevented through disabling external entities or
> DTDs themselves.
> 
> If the XML parser is provided by the application, those capabilities
> can be left enabled even if Tomcat attempts to disable them by setting
> the proper properties on the parser.
> 
> If Tomcat (or the JVM) provides the XML parser, then those security
> precautions can be relied upon to protect the JVM from such an
> application.

The threat being considered here is malicious application code.

The standard protection against malicious application code is running
under a security manager. And even then, there are plenty of things an
application can do to harm the server.

while (true) {
}

being one of the simplest.

What this quickly boils down to is 'Does placing malicious code in the
XML parser enable an attacker to do something they could not otherwise
do?' Does it enable them to bypass any of the security constraints
imposed by the SecurityManager? I believe the answer to that question is
no - hence I believe that using an XML parser provided by the
application is not a security threat.

Keep in mind that this parser is only used for this application and is
only used for web.xml (and fragments).

If there was a single parser shared between all applications then this
would be an issue. We'd have a memory leak as well as the potential for
information disclosure across the web application boundary. We have had
issues like that in the past (CVE-2009-0783) but this bug is not the same.

Note that the previous XXE issues were possible partly because there was
a single container level web.xml parser that executed with container
permissions.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org