Re: Core Dump File Generation

[Olaf Kock]

On 28.02.24 12:03, Chaudhary, Mohit wrote:

Hi,

Java version 1.8.0_121 is running on server.


From the release notes of Java 1.8.0_121
(https://www.oracle.com/java/technologies/javase/8u121-relnotes.html):

The JRE expires whenever a new release with security vulnerability fixes
becomes available. Critical patch updates, which contain security
vulnerability fixes, are announced one year in advance on Critical Patch
Updates, Security Alerts and Third Party Bulletin
. This JRE (version 8u121) will
expire with the release of the next critical patch update scheduled for
April 18, 2017.

Take special note of the year-portion of the mentioned date.

And evaluate what other neglected software you run on a potentially
public-facing server.

Check first if you run into an issue that might have been fixed some
time in the past 7 years already, before debugging /any/ further.

Olaf

Re: Core Dump File Generation

[Olaf Kock]

On 28.02.24 09:57, Chaudhary, Mohit wrote:

Hi All,

We are facing issues on tomcat. Core dump file generating very frequent twice 
to thrice in a month and core file size would be 13GB to 15GB every time 
.Whenever this issue is happening tomcat services stopped automatically. We 
have done analysis of hs_err_pid.log file and based on analysis we have tried 
many thing (such increased tomcat heap memory ) but unable to resolve this 
issue. Please suggest.


There's not much to suggest: A core dump can be analyzed for the root
cause of it being generated. Typically a problem that goes beyond what
Java code itself is capable to do. More often than not, native code - if
there is any involved - would be my first place to look at.

Also, as the JVM is native code itself: Make sure that it's up-to-date.

On top of that: Yes, when a core dump is generated, the process for
which it was generated is indeed stopped. That's what a crash does to
your process (even if core dumps were disabled or went to /dev/null).
You might want to set up your systems for automatic restart, most likely
with alerting someone of the condition and the restart, so that you have
an overview over how often it happens, but generally keep the service up.

Olaf


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

Re: Any way to look-up a session from application?

[Olaf Kock]

Hi Chris

On 27.02.24 15:19, Christopher Schultz wrote:

All,

I'm looking at building some administrative tools into my application,
and I'd like to be able to inspect user sessions for certain attributes.

I know that I can use JMX to make calls to the (session) Manager, but
it looks like the only things really exposed are:

String[] listSessionIds()
String getSessionAttribute(String sessionId, String attributeName)

There are other operations available but they aren't related to what
I'd like to do: get a reference to the Session object itself, so I can
get attributes as their *actual* types and not converted to a String.

Is that possible using existing Tomcat-provided tools?

Another option would be to register an HttpSessionListener /
HttpSessionActivationListener and keep track of all the events so I
have my own "private" set of references to all of those sessions.

Is there a way to do this without writing my own session-tracking
code? The old HttpSessionContext interface has been deprecated for
ages and implementations are required to be no-ops.


I can't really provide a recipe, but have a question for clarification:

As you mention JMX, it sounds like you want to access the session from
out-of-application context? If that is the case, you might have a hard
time getting any session objects, if their classes are private to the
web application's classloader. Strings naturally will work, but for
others you'd need severe class loading or reflection magic to make sense
of them.

HttpSessionListener sounds more "in context", and more doable.

I'm not aware of a way that does not involve custom session tracking
code. But that doesn't mean anything: I can easily be proven wrong :)

Olaf





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

Re: Tomcat 9 release plan

[Olaf Kock]

On 30.01.24 12:10, Kambhapati, Sindhuri wrote:

Hi,

Can you give me link for the tomcat forum please.



https://tomcat.apache.org/lists.html



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

Re: Regarding Tomcat is creating the zombie processes

[Olaf Kock]

On 05.01.24 14:17, Simon Matter wrote:

You will need to provide more details.

A default Tomcat install does not create parent and child processes so
zombie processes cannot occur.


Often, Java-Threads look like child processes in Linux tools.

I'm assuming that the application creates non-daemon threads, that don't 
terminate when they should.


Tomcat itself only creates connector-related threads according to the 
declaration in server.xml, and optionally database pools (or similar), 
also as declared. Other threads /might/ be created by the (custom) 
application that you deploy, and /they/ might prevent tomcat from ever 
exiting cleanly.


My working hypothesis: The reason for the described behavior is 100% on 
the application side, not at all with Tomcat.


As you state exhaustion of system resources: Depending on your use case, 
you might need to make more system resources available - I've seen cases 
where a server ran out of file-descriptors (or similar - this is very 
vague memory).



I'll also note that zombie process do not consume system resources
(apart from a process ID).

Please provide the steps you used to recreate this issue in a clean
installation of a standalone Tomcat instance.

Mark


As an easy start you could provide us with the Tomcat related process tree
and detailed description of how the lifecycle of Tomcat is managed.

I'd recommend analyzing at a thread dump, created before zombification, 
to look at the nature of all of the threads that are running in your 
system before it goes down - or rather before it doesn't go down.


Olaf

Re: Getting False Tomcat Down Alert

[Olaf Kock]

On 03.01.24 15:34, Christopher Schultz wrote:

Olaf,

+1

The regular expression used with grep should be improved a lot.

I would recommend at least the following:

STAT=`netstat -luptn 2>/dev/null | grep '^tcp.*:8080[^:0-9]' | awk 
'{print $6}'`


...or omit the UDP output by using "netstat -lptn" to begin with ;)

The improved regexp will ignore non-TCP ports and will only match on a 
proper port-number by requiring the presence of a : and being followed 
by anything other than a : (which would indicate it's an IPv6 address) 
or more numbers (which could be a port number like 80800 or more of an 
IPv6 address).


wouldn't the :8080[^:0-9] still hit on an IPV6 address /ending/ in 8080? 
Still an improvement, as it'd be 1 false alarm per 4294967296 IPV6 
addresses ;)


netstat is a pretty crude tool to be used, here. Why not just connect 
to the service on port 8080 and see if it responds? The process 
listening on the port doesn't guarantee it's actually able to serve 
any requests...


Now I'm +1'ing, and can add:

As you said this, you triggered my memory: My toolbox has this gem, 
checking for http-status 200:


|#!/bin/bash status_code=$(curl --write-out %{http_code} --silent 
--output /dev/null http://localhost:8080/) if [[ "$status_code" -ne 200 
]] ; then echo "Tomcat Status: $status_code" | mail -s "Tomcat Down?" 
"someb...@example.com" -r "STATUS_CHECKER" else exit 0 fi |


Olaf

Re: Getting False Tomcat Down Alert

[Olaf Kock]

On 03.01.24 10:18, Olaf Kock wrote:

Here's an option:

On 03.01.24 09:41, Chaudhary, Mohit wrote:

Hi,

Please find below script code which has been written.

STAT=`netstat -luptn | grep 8080 | awk '{print $6}'`
if [[ "$STAT" != "LISTEN" ]];
then
echo "Tomcat instance down" >> $MESSAGE
mail -s "Tomcat Instance Down on $HOSTNAME" $mailto < $MESSAGE

Thanks & Regards,
Mohit Chaudhary


netstat -luptn contains the "p" option (which lists the PID/Program 
name). It also contains -u, which includes UDP ports. Both most likely 
not helpful in your case, and a sign that this script was quickly 
gobbled together and not well designed.


grep 8080 does not just match for a port, but will also trigger for 
any listed PID (or other output) containing those 4 characters. As 
you'll also see numeric IPV6 addresses (local or foreign ones) - and 
even local IPV6 addresses can change over time - there's another 
possibility for unintended matches.


So, assuming that there is some other output from netstat that 
somewhere contains "8080", but not "LISTEN" (or maybe if the output is 
multi-line), you'll get a false positive hit.


To validate that you're running into such an issue, you can add the 
grepped netstat output to the mail (before applying awk) - so either 
cache that output, or simply execute it again, piping it to $MESSAGE.



One more nail in the coffin:

Validate by just executing "netstat -luptn | grep 8" on the command line 
(to simulate multiple hits), and look at the output that you (would) get 
from awk: The -u option doesn't even result in netstat to print LISTEN 
in column 6, so awk prints the PID column. And indeed, if multiple lines 
match your grep, you're comparing (e.g.) "LISTEN LISTEN 34523/java" to 
"LISTEN", which obviously does not match.


Which means: Your script is definitely wrong. Tomcat is not to blame.

Best,

Olaf



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

Re: Getting False Tomcat Down Alert

[Olaf Kock]

Here's an option:

On 03.01.24 09:41, Chaudhary, Mohit wrote:

Hi,

Please find below script code which has been written.

STAT=`netstat -luptn | grep 8080 | awk '{print $6}'`
if [[ "$STAT" != "LISTEN" ]];
then
echo "Tomcat instance down" >> $MESSAGE
mail -s "Tomcat Instance Down on $HOSTNAME" $mailto < $MESSAGE

Thanks & Regards,
Mohit Chaudhary


netstat -luptn contains the "p" option (which lists the PID/Program 
name). It also contains -u, which includes UDP ports. Both most likely 
not helpful in your case, and a sign that this script was quickly 
gobbled together and not well designed.


grep 8080 does not just match for a port, but will also trigger for any 
listed PID (or other output) containing those 4 characters. As you'll 
also see numeric IPV6 addresses (local or foreign ones) - and even local 
IPV6 addresses can change over time - there's another possibility for 
unintended matches.


So, assuming that there is some other output from netstat that somewhere 
contains "8080", but not "LISTEN" (or maybe if the output is 
multi-line), you'll get a false positive hit.


To validate that you're running into such an issue, you can add the 
grepped netstat output to the mail (before applying awk) - so either 
cache that output, or simply execute it again, piping it to $MESSAGE.


Olaf



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

Re: Getting False Tomcat Down Alert

[Olaf Kock]

On 03.01.24 07:55, Chaudhary, Mohit wrote:


Hello Team,

We have RHEL 6.10 server and  configured custom script in crontab to 
check 8080 port is up or not, if 8080 is down then getting email 
alert. But some time we are facing the false alert for 2 to 3 min. 
When we are checking the tomcat services it was up and running fine 
and nothing was written in logs also.


So is it possible that 8080 port will be down for few minutes when 
tomcat is facing heavy traffic? Or what will be the reason for facing 
the false alert?.


To me, the question is rather: *How* does your custom script check port 
8080 being up? Because you say that you're checking as well, and this 
result disagrees with the result of the manual check. With two different 
results, I'd first inspect the custom script for its behavior, and 
suspect it to generate a false positive.


It being a script implies that you might be able to share it (or the 
relevant parts of it) here (?)


Olaf

Re: Are there any known class loader leaks in Tomcat 9?

[Olaf Kock]

On 06.11.23 18:55, William Crowell wrote:

Good afternoon,

I am running Tomcat 9.0.78 with JDK 1.8.0_371 (running with G1GC), and I am 
loading some very large Java classes into Metaspace.  I know this is not good 
practice, but I inherited this library.  These classes have business rules and 
are doing some basic primitive and array manipulations, and I am running out of 
native memory.  I don’t think there are any JNI calls in this code base.

Are there anything existing issues with the Tomcat 9 class loader?  I doubt 
there are but wanted to check.


Hi William,

when you say "I am loading some very large Java classes into Metaspace. 
I know this is not good practice" it does not sound like this inherited 
library is using tomcat's standard way of classloading - please clarify.


Also, nothing in that statement points to anything where a leak on 
tomcat's side would make a difference: Are you experiencing problems 
after reloading a webapp, or just in general operation? You might simply 
need to assign more metaspace to the VM for this library to operate 
properly.


So, this boils down to:

* How does this library load the classes into memory?

* Do you redeploy?

* What's your metaspace (and general memory) setting, and what are the 
conditions under which you run out of memory?


* Do you see any log message that hint at classes that won't be garbage 
collected because of stale references? Tomcat issues those warnings, in 
case you (for example) start your own background threads that keep 
holding the memory allocated to them.


Also: I second your doubt about Tomcat's classloader being the cause for 
your problems - unless proven otherwise.


Olaf

Re: [EXTERNAL] - Need help tomcat

[Olaf Kock]

On 02.10.23 10:07, Deepak Lalchandani wrote:

Hi Please advice , Where to send the screenshot


Hi Deepak,

You're dealing with textual messages, right? Just send the text - it's 
easier to read, search for etc anyway.


Olaf


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

Re: OT: hsts in Tomcat 9.0.73

[Olaf Kock]

Am 22.04.23 um 00:48 schrieb jonmcalexan...@wellsfargo.com.INVALID:

Thanks Peter,

I still do not see the hsts header. I'm wondering if this is causing it.

SSL certificate verify result: self signed certificate in certificate chain 
(19), continuing anyway.

I don't know why it's complaining as the certificate for Tomcat is not a 
self-signed certificate.


That's a good guess: Anything self-signed is a problem for HSTS (though 
only curl might see it as that, depending on the root certificate store 
it uses compared to your browser). However, somehow I'd expect the 
server to be ignorant to the level of trust that the client has and send 
the header anyway.


Another aspect to dig into is the explicit nonstandard port number. I 
didn't fully parse the RFC for it, but there are several statements on 
explicit, implicit ports and how they're mapped.


In the end, it might be worth hitting the Tomcat filter in a debugger, 
or inspecting the source - to see if any conditional branches in an 
unexpected fashion, if a different filter than the expected one is 
hitting, or if the URL doesn't match.


Yet one more option: Set some nonstandard header, where no assumption 
can be made in any server- or client-side code, and see if it gets 
through. This way you know that you're hitting the expected filter


I'm typically lazy in all of this setup, as I defer HTTPS/HSTS to a 
reverse proxy (and I'm only setting up demo systems), so I can only make 
wild guesses.


Olaf



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

Re: OT: hsts in Tomcat 9.0.73

[Olaf Kock]

Am 21.04.23 um 07:03 schrieb jonmcalexan...@wellsfargo.com.INVALID:

No, there is no error and no stack trace. Everything works, just the hsts 
header isn't in the list of headers.

The lowest hanging fruit: HSTS is only defined on https - on http it 
doesn't have any meaning and Tomcat would be correct in not sending it 
(I haven't looked at the source if it does, but it should be easy to test)


If you have a reverse proxy handling https & proxying through http, 
Tomcat might not know that it'd be fine to send the header. (If that is 
your case, there is the brute force "secure" attribute on the connector 
- use it only when there's no way to connect through http from anywhere 
but your reverse proxy)


This has bitten me a few times

Olaf


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

Re: Tomcat 8.5.85 and above - Issue with file uploads

[Olaf Kock]

On 13.04.23 22:40, William L. Cunningham wrote:

Environment:  Windows 2019 Standard with latest JDK 17 and Apache Tomcat 8.5.87.

When trying to upload a file to the application running off Tomcat (custom 
software), we are getting the following error since 8.5.85 (works fine on 
8.5.84).

ERROR [2023-04-13 15:20:20]: 
com.company.dataimporter.servlet.FileUpload::doPost::85 Cannot delete 
C:\Program Files\Apache Software Foundation\Tomcat 
8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_44d3_aee6_28d1d7989727_.tmp
java.lang.IllegalStateException: Cannot delete C:\Program Files\Apache Software 
Foundation\Tomcat 
8.5_Tomcat_Prod\work\Catalina\localhost\company\upload_1da07be9_7508_44d3_aee6_28d1d7989727_.tmp
  at 
org.apache.tomcat.util.http.fileupload.disk.DiskFileItem.delete(DiskFileItem.java:428)
 ~[tomcat-coyote.jar:8.5.87]

This same procedure works perfectly fine in 8.5.84.  It was something 
introduced with 8.5.85.  It also works fine on a Linux hosted version (Centos) 
for 8.5.84 and above.  So it appears to be Windows centric.

When I watch the procedure in the Catalina\localhost\company folder on 8.5.84, 
I see the tmp file generated and then immediately deleted (it's a small 
upload).  On 8.5.85 and above, it's locked and can't be deleted.  Thus causing 
the error.



You should not install Tomcat in "C:\Program Files", or at least not run 
it there (e.g. run it with CATALINA_BASE != CATALINA_HOME): Windows 
protects the content of "C:\Program Files\*" in some ways that I can't 
detail - it might very well interfere in the way that you describe. 
Maybe you had installed/run it from another directory earlier, and that 
was changed with the upgrade?


Olaf


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

Re: Java Heap Space Error

[Olaf Kock]

On 14.04.23 04:55, pratik.kulka...@shell.com.INVALID wrote:

Hi All,

Thanks for your quick suggestions.

As Olaf suggested, I tried to set the same values to Xms and Xmx; the 
application immediately crashes after Tomcat restart and I am not able to 
access it. I tried it with different values, but the result is the same. 
Regarding the memory leak, let me check on how to monitor an Oracle Apex 
application running on Tomcat, since this is something I have never done before.


Here are a few ideas for this paragraph:

As your application can't run with -Xms set to the limit, you have 
proven that your computer does not have enough memory to allocate for 
your requirements (maybe due to other applications taking it, maybe it's 
just due to low RAM to begin with. I'm not sure why this would surface 
after upgrading Tomcat, but maybe your settings are different in other 
aspects as well, or other applications now take more memory.


(I'd recommend Xms==Xmx for all Java Server applications, to get the 
OOME quicker, rather than Sunday night at 3am, at random)


If you just connect jconsole, you should be able to see a characteristic 
sawtooth curve of memory, going up, hinting at - not necessarily proving 
- memory leaks (it might also just indicate legitimate memory usage - 
it's a quick check: If the sawtooth is horizontal, you have a strong 
indicator that there's no memory leak)


Typically, I don't really concentrate on the actual stacktrace of the 
OOME, as this is just what happened to require the last bit of memory, 
after everything else has been consumed. This *might* be the guilty 
code, but it might also just be a false positive. To me, OOME 
stacktraces have more often misled me than they pointed to the problem. 
A heapdump, with an indicator of what actually consumes your memory (and 
then judging if it's legit or not) helps a lot more IMHO.


Olaf


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

Re: Java Heap Space Error

[Olaf Kock]

Hi Pratik,

On 13.04.23 11:35, pratik.kulka...@shell.com.INVALID wrote:

Hello,

This email concerns an error I encountered while using Oracle Apex with ORDS 3.0.9 and 
Tomcat 9. Specifically, I receive a "Java heap space" error when accessing the 
application.

To troubleshoot the issue, I have tried to increase the maximum heap size of 
the JVM using the -Xmx option in the CATALINA_OPTS environment variable. I set 
this environment variable in the catalina.bat file and restarted the Tomcat 
service, but the error persisted.

I have also confirmed that the CATALINA_OPTS environment variable is set 
correctly by running echo %CATALINA_OPTS% in the command prompt.

I should note that I have two versions of Tomcat installed on the system - 8.5 and 9. 
Everything works fine on Tomcat 8.5, but the "Java heap space" errors are 
thrown on Tomcat 9.

I would appreciate any insights or guidance you can provide to help me resolve 
this issue. Below are the details of the software I am using,


1. Make sure you have enough memory available (my recommendation is to 
set -Xms to the same value as -Xmx, so that you see *immediately* (on 
startup) if you don't have enough memory available. It doesn't help if 
you need 3 hours or 3 days to run into this condition.


2. Check if your application has a memory leak (e.g. by monitoring the 
memory consumption over time)


Olaf


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

Re: Query: HSTS | Tomcat 9.0.50

[Olaf Kock]

On 17.01.23 13:09, Olaf Kock wrote:


On 17.01.23 11:45, Deepti Sharma S wrote:

Hello,

I have tried with both Chrome and Mozilla in private window where 
information is not cached. HSTS is not working on custom ports.


I'm not confident that HSTS is among those cached values that are not 
shared between normal and incognito mode.


Try curl -v

As far as I know, curl does not save any HSTS state anywhere.

Thomas' suggestion makes the most sense: Once your browser knows 
positively that it absolutely must connect through https on port 443, 
I can easily imagine it never even to attempt to try 8080.


I should have edited ^ this after adding the specs from RFC 6797: Once 
the browser knows that it *must* use https for this host, it will not 
connect through http, no matter which port. The browser keeps records of 
this by domain name, not by name/port.



Also, according to the specs: The browser will - under no 
circumstances - connect to your host through http.


The specs say:

|The UA MUST replace the URI scheme with "https" [RFC2818], and if the 
URI contains an explicit port component of "80", then the UA MUST 
convert the port component to be "443", or>> if the URI contains an 
explicit port component that is not equal to "80", the port component 
value MUST be preserved; otherwise, if the URI does not contain an 
explicit port component, the UA MUST NOT add one. NOTE: These steps 
ensure that the HSTS Policy applies to HTTP over any TCP port of an 
HSTS Host.|


So, if you connect to 8080 from your browser, your browser would try 
to speak https to port 8080 if it has already seen the HSTS header 
before.



Olaf




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

Re: Query: HSTS | Tomcat 9.0.50

[Olaf Kock]

On 17.01.23 11:45, Deepti Sharma S wrote:

Hello,

I have tried with both Chrome and Mozilla in private window where information 
is not cached. HSTS is not working on custom ports.

I'm not confident that HSTS is among those cached values that are not 
shared between normal and incognito mode.


Try curl -v

As far as I know, curl does not save any HSTS state anywhere.

Thomas' suggestion makes the most sense: Once your browser knows 
positively that it absolutely must connect through https on port 443, I 
can easily imagine it never even to attempt to try 8080.


Also, according to the specs: The browser will - under no circumstances 
- connect to your host through http.


The specs say:

|The UA MUST replace the URI scheme with "https" [RFC2818], and if the 
URI contains an explicit port component of "80", then the UA MUST 
convert the port component to be "443", or>> if the URI contains an 
explicit port component that is not equal to "80", the port component 
value MUST be preserved; otherwise, if the URI does not contain an 
explicit port component, the UA MUST NOT add one. NOTE: These steps 
ensure that the HSTS Policy applies to HTTP over any TCP port of an HSTS 
Host.|


So, if you connect to 8080 from your browser, your browser would try to 
speak https to port 8080 if it has already seen the HSTS header before.



Olaf

Re: Query: HSTS | Tomcat 9.0.50

[Olaf Kock]

On 16.01.23 06:57, Deepti Sharma S wrote:

Hello Team,

Can you please help us for below query:

Query : How to enable HSTS in Apache Tomcat on non-default ports?
  We have custom ports for http and https and we want to enable HSTS on 
those custom ports.

Note: We could see HSTS is working with default ports 80/443 though it's not 
working on other custom ports, please let us know if there are different steps 
to enable HSTS on non-default ports.


In order to "work", HSTS *must* be on https, by specification.

When you say you got it working on 80/443, you haven't. You might see 
the headers, but it's not working. Most likely the header is ignored by 
the browser.


Whereever you handle your https termination - that might be on Tomcat, 
or on a reverse proxy that sees traffic before Tomcat does - you'll best 
do the HSTS handling. /That/ server knows it's serving https. And there 
the header actually is valid and working.


If you try to configure a http (not https) connector on Tomcat for 
adding the HSTS headers, it's well within the specification to ignore 
that setting.


Technically you can do some trickery around that, but to make that 
sensible and safely would take more than a quick answer. And leave room 
for misinterpretation and configuration mistakes. So: Configure it 
anyhwere you terminate https, and ignore it on http.


Olaf



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

Re: Having two servers and controlling my secondary server with the primary server

[Olaf Kock]

On 09.01.23 18:12, Mark Thomas wrote:

Your mentor is wrong.

Mark

To elaborate on that: When one server is down, its configuration will be 
inactive as well. There's nothing that this non-running server will be 
able to do for you. You'll need to externalize the decision which 
server's responses to serve to /some/ external entity



Olaf




On 09/01/2023 14:56, Manisha Chermadurai wrote:

Thanks for this.

I have set up the solution for failover using nginx as a proxy server
between my two tomcat servers. But my mentor told with only using tomcat
server's configuration files, you can redirect the requests to another
server if and only if the particular server is down. So I am 
searching for
this solution, and came to know about this group. So I requested 
about this

, may be I will get some ideas.

Really thanks for response.

On Mon, 9 Jan 2023, 8:21 pm Olaf Kock,  wrote:


On 09.01.23 15:22, Manisha Chermadurai wrote:

Good evening Sir,


I am trying to control my secondary server with the primary server of

mine.

Bothe are of versions 9.0. Primary server has been available in my

physical

machine and my secondary server is in virtual machine. Both are of

windows

10. I am connecting the vm's 8080 port through the ip address from

primary

machine. It works fine. But I have a doubt like , Can I create my

secondary
server without allocating port ? I have tried it works fine, but 
there is
no entry point for my server. I have doubt of creating a comnector 
for my
vm's server from my primary server and the condition is also like I 
have

to
create a connector for my secondary server and it can be accessible 
only
when my primary server is down. I have researched and tried many 
things

for

literally 2 weeks. But I got stuck in this. So, once again I repeat my
question,  it's I have to create a connector for my secondary 
server by

my
primary server and it will be only accessible when my primary 
server is
down.So my client won't get chance to connect my secondary server 
through
the ip and port. I have tried failover with nginx. But I want to 
try this

only with my server.xml file.


If I understand your use case correctly, I'd recommend to set up a load
balancer that handles the failover.

Other options depend on the scenario you're looking for: Should your
secondary server be a hot-backup for the primary one (e.g. immediate
failover with no downtime?) or a cold backup that get started only when
some component determines that the primary server went down?

You will need to configure a Connector (with a port) on both servers if
you want to be able to access them.

And I'd recommend to either use some orchestration for it, or just
manually configure your second server. Tomcat itself is not the tool of
choice to configure one server through another one. There are 
components

that allow you to distribute deployed web applications (e.g.
https://tomcat.apache.org/tomcat-9.0-doc/config/cluster-deployer.html),
but that's a different use case than what you're asking for.

If you absolutely want to work around a load balancer, you might be 
able

to do some trickery with firewall-level redirection, but I'd say that
this is less transparent than explicitly configuring a load balancer.

Olaf






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






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



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

Re: Having two servers and controlling my secondary server with the primary server

[Olaf Kock]

On 09.01.23 15:22, Manisha Chermadurai wrote:

Good evening Sir,


I am trying to control my secondary server with the primary server of mine.
Bothe are of versions 9.0. Primary server has been available in my physical
machine and my secondary server is in virtual machine. Both are of windows
10. I am connecting the vm's 8080 port through the ip address from primary
machine. It works fine. But I have a doubt like , Can I create my secondary
server without allocating port ? I have tried it works fine, but there is
no entry point for my server. I have doubt of creating a comnector for my
vm's server from my primary server and the condition is also like I have to
create a connector for my secondary server and it can be accessible only
when my primary server is down. I have researched and tried many things for
literally 2 weeks. But I got stuck in this. So, once again I repeat my
question,  it's I have to create a connector for my secondary server by my
primary server and it will be only accessible when my primary server is
down.So my client won't get chance to connect my secondary server through
the ip and port. I have tried failover with nginx. But I want to try this
only with my server.xml file.


If I understand your use case correctly, I'd recommend to set up a load 
balancer that handles the failover.


Other options depend on the scenario you're looking for: Should your 
secondary server be a hot-backup for the primary one (e.g. immediate 
failover with no downtime?) or a cold backup that get started only when 
some component determines that the primary server went down?


You will need to configure a Connector (with a port) on both servers if 
you want to be able to access them.


And I'd recommend to either use some orchestration for it, or just 
manually configure your second server. Tomcat itself is not the tool of 
choice to configure one server through another one. There are components 
that allow you to distribute deployed web applications (e.g. 
https://tomcat.apache.org/tomcat-9.0-doc/config/cluster-deployer.html), 
but that's a different use case than what you're asking for.


If you absolutely want to work around a load balancer, you might be able 
to do some trickery with firewall-level redirection, but I'd say that 
this is less transparent than explicitly configuring a load balancer.


Olaf






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

Re: setenv.sh not loaded

[Olaf Kock]

On 02.11.22 12:43, Ivano Luberti wrote:
Hi, I have been given an Oracle Linux instance with tomcat 9.0.65 
installed as a service.


Tomcat is running correctly

I have tried to create a setenv.sh file to tune the JVM, but using the 
tomcat manager application and the catalina.log file it seems that my 
java configuration is not loaded.


Any suggestion on how to debug this?


You're saying "installed as a service". This might mean that 
tomcat/bin/catalina.sh is also never executed, or that it has been 
altered from the default.


Ivano's suggestion is great already. On top, you might want to

* check how Tomcat is started by the system (e.g. does it go through 
catalina.sh at all?)


* check if anything in its installation directory is altered from 
default. Just inspect a diff between stock 9.0.65 and what you find in 
your installation.


Olaf








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



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

Re: Help Needed for installation of apache-tomcat-8.5.5

[Olaf Kock]

On 08.10.22 05:09, Verma, Sahil wrote:


Hi Team,

We have a requirement to install Tomcat 8.5.5 version in Linux 
environment. Please help with steps of downloading the package and 
installation steps.


Linux version -  Red Hat Enterprise Linux release 8.6



You have a requirement to install a 6 years old version of a software on 
a current Enterprise-labelled OS?


I'd say: Start with the documentation 
(https://tomcat.apache.org/tomcat-8.5-doc/setup.html), but use the 
current release - if you want to use Tomcat 8.5, use 8.5.82 (at the time 
of writing this)


If you need other steps, please be more specific about what you need.

Olaf

Re: Apache Tomcat 8 - Require Tomcat configuration to restrict exe's from downloading

[Olaf Kock]

On 20.06.22 11:51, bharath Kumar wrote:
> Hi Team,
>
> I am using apache Tomcat 8 version,
>
> *Problem statement: *
>
> My application's accessible  URL format is
> *http:///abc/xyz.exe*

A good way to get the question answered would be to answer the comments
on your identical Stackoverflow post

https://stackoverflow.com/q/72658556/13447

If someone is asking for clarification, that's typically because they
need more information and it typically doesn't help asking elsewhere
without providing that additional information. And abandoning the
original place isn't too helpful as well.

Also: Please don't crosspost without referencing all places where you
posted - otherwise you're just generating duplicate work as nobody knows
what has already been discussed elsewhere.

Thank you,

Olaf



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

Re: Compile JSP pages dynamically using Tomcat 6.0.45

[Olaf Kock]

On 13.06.22 11:48, Pavan Kumar Tiruvaipati wrote:
> Hi,
>
> Our application is running on Tomcat 6.0.45.
>
>
> *Operation System* - Linux & Windows
>
> Due to security reasons, we are replacing JDK 1.8 with JRE 1.8.

If you make a change *for security reasons*, you might want to rather
update Tomcat to a version that was release after February 2016, that
hasn't reached its end-of life in December 2016
(https://tomcat.apache.org/tomcat-60-eol.html).

In general: Yes, Tomcat bundles the eclipse compiler since version 5.5 -
if you really want to make this small step, you might want to post more
information about your particular configuration - e.g. compare your
current installation's configuration with a stock 6.0.45 download. If
you look at a diff between the two, you might see already, what you'd
need to change.

I'd recommend to go with a more current version of Tomcat though -
specifically as you state security reasons for your upgrade. As you
still would compile JSPs, no matter if you use eclipse's or your JDK's
compiler, I don't see a lot of potential security issues being
eliminated by the upgrade that you're planning. Looking at security
fixes in Tomcat since February 2016 likely reveals some issues that
might be a lot easier to exploit.

Olaf

>
> We understand that Tomcat is bundled with Eclipse JDT compiler -
> ecj-4.3.1.jar.
>
> It will take care of dynamic compilation of JSP pages (Correct me if I'm
> wrong)
>
> But It's unable to recompile JSP pages without JDK.
>
>
> Does Tomcat 6.0.45 or any higher version require JDK to compile JSP pages ?
>
> Please let us know if you need any more information.
>
>
> Regards,
>
> Pavan
>

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

Re: SAML SSO Login issue

[Olaf Kock]

On 11.05.22 17:36, harish lal wrote:
> Facing SSO Login issue after upgrade from Tomcat 6.0.33 to Tomcat 7.0.62
>
> We upgraded our application from Tomcat 6.0.33 to Tomcat 7.0.62 due to web
> socket dependency in Tomcat.
> After upgrade , while try to do SAML SSO login from application we are
> facing below issue ,

Do you know that you "upgraded" to a version released in 2015 (see
https://archive.apache.org/dist/tomcat/tomcat-7/), which has seen its
end of life last year (see https://tomcat.apache.org/tomcat-70-eol.html)?

As a quick minimum - if you now have a hard dependency on Tomcat 7, you
should use the end-of-line 7.0.109 - maybe your issue is fixed in that
release already. In general (and if it isn't fixed) I'd recommend to go
to the latest in the 8.5 or 9.0 line and try to reproduce. I doubt
someone will start debugging 7 years old code that explicitly went out
of service more than a year ago. If you're lucky, someone will remember
something.

In case you still can reproduce: I'm quite uncertain what your phrase
"/If we remove only the "JSESSIONID" from the cookie/" means. Also, you
might want to look at all of the redirected requests and identify if
they're identical to each other, or where they're different.

Best,

Olaf

Re: tomcat-10.0.x Problem https multiple IP

[Olaf Kock]

Dear Jaebo,

On 21.01.22 10:29, Jaebo Nah wrote:
>  10.100.142.31  =   two.domain.loc
>
> 
>   address=" two.domain.loc"
>
>   SSLEnabled="true" defaultSSLHostConfigName="10.100.142.32" >
>
>       protocols="TLSv1.2,+TLSv1.1,+TLSv1">
>
>
Above, I only left the lines from your mail that deal with host names
and IP addresses and deleted all others. Note the mismatch between
"two..." refering to "...31" initially, and then you use "...32" later.

Individual IP addresses are no longer needed for https connections to a
server. I'd recommend to either handle them all in a single server, or,
if you need to run multiple tomcats, to handle the correct certificate
choice in a reverse proxy that delegates to the proper Tomcat in the
background.

Olaf

Re: Tomcat dedicated server

[Olaf Kock]

Hi Mark

On 20.01.22 10:18, Mark Thomas wrote:
> On 20/01/2022 08:54, Olaf Kock wrote:
>
>>  My rule of thumb is: The
>> more memory there is to be claimed in GC, the longer a full GC run
>> takes.
>
> Nope.
>
> The time a GC run takes is proportional to the size of objects in
> memory that do not need to be GC'd. GC walks the active object tree so
> it is the active objects that matter.
>
> Generally, the more memory you give the JVM to work with, the lower
> the impact of GC for both pauses and throughput.
>
> A rule of thumb I have seen in the past (may be out of date for
> current JVMs) is that the JVM needs roughly 5x the steady state memory
> requirements for GC to work most efficiently.
>
Thank you for setting my ancient rule of thumb straight - noted and
mentally corrected, this is really useful.

Obviously, the last time that I needed to squeeze the last bit of
performance out of a machine is so old that I never needed to revert
that ancient rule of thumb - now I have a cause to do so.

@Lance: I take it back and claim the opposite :)

Olaf


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

Re: Tomcat dedicated server

[Olaf Kock]

Hi Lance

On 19.01.22 23:35, Campbell, Lance wrote:
> On a Tomcat 9.x dedicated Linux server with 16G of memory, how much memory 
> would you allocate for the OS?
>
> Assume there is no file processing taking place.  Also assume Tomcat is 
> communicating primarily with a PostgreSQL database and Apache web server each 
> running on their own dedicated servers.  The Tomcat application server is the 
> only thing running on the Linux server.

It depends (TM)

Without knowing your application, the load (e.g. number of concurrent
users) and general setup, there's no way to tell. I'd rather handle the
question the other way around: How much memory does (your application
on) Tomcat require. Tomcat itself is happy with just a little bit of
memory, but applications vary widely. Also, some applications are
memory-bound, some are I/O-bound, some are CPU-bound. So memory might
not be your bottleneck to worry about.

You should load-test your application with a realistic load (plus
margin) and keep an eye on memory consumption. But in the end you'll
find out what is the first bottleneck to appear. It might not be memory.

But to come back closer to your original question: I recommend to
deactivate swapspace for production servers, and configure -Xms equal to
-Xmx, so that you find shortages of memory early (when you start the
application) rather than Sunday night at 3am. You might want to leave
1-2G for the OS and start testing this way, or rather test how little
memory your app requires to run and add margin. My rule of thumb is: The
more memory there is to be claimed in GC, the longer a full GC run
takes. Often, many short but frequent GC runs are preferable to fewer
but longer lasting. (I didn't check if this still applies to the newer
generation of garbage collectors, so take this GC-statement with a grain
of salt)

Olaf



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

Re: ClassFileTransformer in Tomcat 10 common classloader

[Olaf Kock]

On 28.12.21 00:36, Chew Kok Hoor wrote:
> We're using the old javax.servlet namespace for compatibility reasons.
>
> Some of our jar files are re-used by different web-apps, therefore we
> placed them in the common classloader.
>
> Is it possible to convert them dynamically, just like how we do it for
> servlets in the per app WEB-INF folder, by using the following in the
> context file:
>
> 

On top of what's already discussed:

You're not giving any indication that you need jakarta-ee at all, so if
you use javax.servlet: Just do it, and deploy on Tomcat 9 - that's a
very good choice that won't go away any time soon. If there's no need
for Tomcat 10, save yourself the hassle - at least for now.

Later on, you might want to divide your webapps into two groups: Those
that don't require any compatibility handling, because they're fully
migrated (or automatically migratable) to jakarta-ee, and those that
don't. Easy setup with a reverse proxy sending the traffic to either of
the two (or multiple) backends.

Olaf




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

Re: Handling database connection pooling outside Java, without DBCP et al?

[Olaf Kock]

I don't have experience with this particular setup, but one sentence (in
fact, one word) caught my attention:

On 23.11.21 14:23, jkla...@iki.fi wrote:
> We're in the process of adopting ProxySQL in front of MySQL, to act as the 
> connection pooler and for separating read and write traffic to different 
> database instances. After this, we have no need for DBCP or any other 
> Java-level pooling – in fact, having two levels of connection pooling would 
> probably be detrimental to performance, and certainly to our ability to 
> diagnose issues.

The keyword here is "probably": I'd say: Finish your migration with all
the current setup, and check if performance is worse than you expect (or
can live with) (and if diagnosis is hindered).

Then, if you /still/ want to eliminate Java pooling: The connection
pooling interfaces aren't that big - I'm not aware of a
non-pooling-connection-pool (or a configuration that disables what the
pool has been written for in the first place), but implementing your own
non-pooling-connection-pool should not be that much work, as you're only
handing out new connections unconditionally, and close them when the app
asks you to close them. And then configure Tomcat to use your
implementation instead of DBCP.

(As of my assumptions about configuration options or available
implementations: I can easily be proven wrong with a link to one of them)


Also, in the beginning you mention Tomcat 8.0 - while you're at it, you
might want to upgrade to one of the versions that still get updates,
e.g. 8.5 or 9.0.

Olaf

Re: tomcat hangs

[Olaf Kock]

On 09.09.21 12:50, Mehrdad Taagholi wrote:
> HiI use apache tomcat 8.0.32 and oracle-jdk-8u66 and redhat 6.After working 
> with the system for a few hours and the load on the system increases, 
> suddenly the tomcat hangs and no logs are printed and it is not possible to 
> connect via jvisualvm and I can not get any dump and I have to reload 
> Tomcat.I have increased maxthreads and use the HttpProtocol protocol.Please 
> suggest a way to fix the my tomact.

Seconding Jason's suggestion to look at your webapps.

However, as you explicitly ask for suggestions to fix your tomcat:
You're running a release from more than 5 years ago, where the general
version 8.0 has reached its end of life 3 years ago
(https://tomcat.apache.org/tomcat-80-eol.html), and are also running on
a JDK that has seen 200 more patch releases.

It's a good idea to keep your installations reasonably current -
specifically when you're looking for bugs in the infrastructure.

Try to reproduce on a current version (of Tomcat and JDK) - and look at
your webapps. As you can reproduce within a few hours, it's also a good
idea to connect a profiler early and check for the applications'
behaviour in the time running up to the problem.

More likely than not, your problem is in your application's code. Or, if
it's in Tomcat, there's a high likelyhood that it has been fixed in the
past 5 years.

Olaf

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

Re: Xms Xmx in JAVA_OPT vs CATALINA_OPTS

[Olaf Kock]

Onno,

On 03.08.21 04:57, Onno van der Straaten wrote:
> Hi, 
> I was looking at a Tomcat deployment and noticed settings in setenv.sh as 
> shown below. I noticed that Xms and Xmx is in JAVA_OPTS and CATALINA_OPTS 
> with the exact same settings. Do these settings make sense? What is the 
> purpose of repeating those settings? 
>
> I understand that JAVA_OPTS is for the JVM and CATALINA_OPTS is specific to 
> Tomcat. How do these settings relate to each other? I am assuming they could 
> be different. 
> Thanks and Regards, 
> Onno 
>
>
> JAVA_HOME="/usr/lib/jvm/jdk11_0411_oj9" 
> JAVA_OPTS="-Xms3000m -Xmx3000m" 
> CATALINA_OPTS="-Dcom.sun.management.jmxremote.port=8375 
> -Dcom.sun.management.jmxremote.ssl=false 
> -Dcom.sun.management.jmxremote.authenticate=false 
> -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true 
> -Dfile.encoding=UTF-8 -Dsun.net.inetaddr.ttl=300 -server 
> -Dorg.apache.tomcat.util.http.Parameters.MAX_COUNT=8192 -Xms3000m -Xmx3000m 
> -XX:MaxPermSize=500m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode 
> -XX:+PrintGCDateStamps -verbose:gc -XX:+PrintGCDetails 
> -Xloggc:"/opt/tomcat/tomcat-9.0.40/logs/garbage.log" 
> -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=10 -XX:GCLogFileSize=100M 
> -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory"
>  

JAVA_OPTS is used for /any/ start of a JVM, including when you run
bin/shutdown.sh, which opens a socket, issues the shutdown command and
terminates. Thus, it's an /absolute/ /overkill/ to set -Xms3000m (or any
memory setting) in JAVA_OPTS.

CATALINA_OPTS is added to these parameers when you start tomcat - thus
this is the right place to configure any memory that you need when you
run the server.

This means that both, JAVA_OPTS and CATALINA_OPTS are used when you run
tomcat. If you have conflicting settings in both: You figure out which
one takes precedence. I choose to not even try to remember which one
takes precedence as I don't trust this to be stable. Your best bet:
Leave any memory setting out of JAVA_OPTS. Most likely you don't need
any custom JAVA_OPTS in setenv.sh, because you're only interested in
configuring settings for the running tomcat. These values safely go into
CATALINA_OPTS.

Prevent ambiguities.

Olaf


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

Re: Ho to upgrade to newest version in tomcat 9

[Olaf Kock]

On 27.07.21 19:01, W wrote:
> Hi,
> I am on Ubuntu with tomcat 9.0.16I tried    sudo apt-get update    sudo 
> apt-get upgradeBut did not work. How to do it?

The distribution packages (here: Debian) typically pick one version and
keep it stable, optionally backporting security fixes to it. Odds are
that you're already not running the same code as in stock 9.0.16, but a
patched version.

If you want to be on the latest version as soon as it's out, you'll
either have to install manually from https://tomcat.apache.org, or find
a repository that you trust, that offers a packaged version.

Olaf



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

Re: Mixing Root Context webapp with other webapps

[Olaf Kock]

On 09.07.21 07:58, Jerry Malcolm wrote:
> I have one webapp that processes REST-style url paths and therefore
> needs to run in the ROOT context.  Is it possible to run other webapps
> in the same host with other non-root contexts?   In other words, when
> resolving a URL to a web app, does it try to map the url to the
> defined context strings first, and then to ROOT if there are no
> matches?  Or does ROOT override everything, and all URLs go to ROOT if
> it's defined?
>
If memory serves me well and this behavior didn't change in the past
decade, then all other web applications have precedence over root. That
is, if you deploy ROOT.war and json.war (and assume the context-path to
be /json), then your root application's /json path would never be reached.

It's easy to visualize this way around, because it's an absolutely
static mapping with the size being "number of webapps", while the other
way around, ROOT could also map /* to one of its servlets and then
determine what to do it. The spec has to means to explicitly hand a
request back to the appserver and every app would rather generate 404
than check if somebody else might be there to handle it.

Olaf



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

Re: Re-Use TCP Source Ports if the Socket is Unique?

[Olaf Kock]

On 25.06.21 14:46, Eric Robinson wrote:
> Olaf and Scott --
>
> Thanks to both of you for your comments. I may have asked my question poorly, 
> since what you both described is the way I understand TCP to work. There is 
> no correlation between an incoming connection to tomcat and its outgoing 
> connection to a database backend, nor would I expect there to be.
>
> Perhaps a simpler way to ask my question is: when a server has multiple IPs, 
> which one does tomcat use as its source IP when it initiates a three-way 
> handshake with a remote machine?
>
> For example, suppose my server has IP addresses 10.0.0.1 and 10.0.0.2, and my 
> tomcat connector looks like this...
>
>  port="8080"
> protocol="HTTP/1.1"
> address="10.0.0.2"
> connectionTimeout="2"
> redirectPort="8443"
>   />
>
> Tomcat is now listening on IP 10.0.0.2.
>
> But here's the question. If tomcat needs to initiate a TCP session to a 
> remote machine (acting as a TCP client), will it use 10.0.0.1 or 10.0.0.2 as 
> the source IP of the outbound connection? I'm assuming it will use the same 
> IP that the connector is configured to listen on.
>
Hi Eric,

again: There's no correlation. Your question boils down to a
context-free "which source IP does tomcat use for outgoing
connections?". In fact, Tomcat doesn't use any. It just asks the runtime
environment (ultimately I'd expect the OS) for a connection to a
particular destination, then it uses that.

How the connection is then established will depend on

* available network adapters
* best route to the target address
* OS or network configuration

It will /not/ depend on any of Tomcat's Connector-configurations whatsoever

Olaf


>> -Original Message-
>> From: Olaf Kock 
>> Sent: Friday, June 25, 2021 3:01 AM
>> To: users@tomcat.apache.org
>> Subject: Re: Re-Use TCP Source Ports if the Socket is Unique?
>>
>>
>> On 25.06.21 05:19, Eric Robinson wrote:
>>> Thanks for the feedback, Daniel.
>>>
>>> I guess the answer depends on whether the socket libraries use the tomcat
>> listening port as the source IP. If you have three tomcat instances 
>> listening on
>> three different IPs, each instance should be able to open a client connection
>> using the same source port, as long as each tomcat uses its listening IP as 
>> the
>> source IP of the socket.
>>> That's the part I'm still not sure about.
>> My expectation is that database connections do not have any correlation
>> with the listening port: Technically, DB connection pools can be shared 
>> across
>> all contained Hosts and Connectors /within a single tomcat/, and when
>> multiple processes are added to the game, it doesn't really change anything.
>>
>> In fact, it's not uncommon that there's a public facing network adapter,
>> where a http-connector listens, but a completely different network adapter
>> for any backend communication - e.g. to the database. All that I expect a
>> database driver to do is to specify where it wants to connect to, and the OS
>> figures out how that connection needs to be routed.
>> That's utterly independent of any http connection that comes in to the same
>> process.
>>
>> So: Don't expect any correlation, and you're safe.
>>
>> (Note: There /may/ be ways to configure a db-driver to specify a source
>> address, but I'd expect that rather to add a potential failure rather than
>> anything that I'd want to control. If you interpret such a situation 
>> differently:
>> Please elaborate)
>>
>> Best,
>>
>> Olaf
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
> Disclaimer : This email and any files transmitted with it are confidential 
> and intended solely for intended recipients. If you are not the named 
> addressee you should not disseminate, distribute, copy or alter this email. 
> Any views or opinions presented in this email are solely those of the author 
> and might not represent those of Physician Select Management. Warning: 
> Although Physician Select Management has taken reasonable precautions to 
> ensure no viruses are present in this email, the company cannot accept 
> responsibility for any loss or damage arising from the use of this email or 
> attachments.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

Re: Re-Use TCP Source Ports if the Socket is Unique?

[Olaf Kock]

On 25.06.21 05:19, Eric Robinson wrote:
> Thanks for the feedback, Daniel.
>
> I guess the answer depends on whether the socket libraries use the tomcat 
> listening port as the source IP. If you have three tomcat instances listening 
> on three different IPs, each instance should be able to open a client 
> connection using the same source port, as long as each tomcat uses its 
> listening IP as the source IP of the socket.
>
> That's the part I'm still not sure about.

My expectation is that database connections do not have any correlation
with the listening port: Technically, DB connection pools can be shared
across all contained Hosts and Connectors /within a single tomcat/, and
when multiple processes are added to the game, it doesn't really change
anything.

In fact, it's not uncommon that there's a public facing network adapter,
where a http-connector listens, but a completely different network
adapter for any backend communication - e.g. to the database. All that I
expect a database driver to do is to specify where it wants to connect
to, and the OS figures out how that connection needs to be routed.
That's utterly independent of any http connection that comes in to the
same process.

So: Don't expect any correlation, and you're safe.

(Note: There /may/ be ways to configure a db-driver to specify a source
address, but I'd expect that rather to add a potential failure rather
than anything that I'd want to control. If you interpret such a
situation differently: Please elaborate)

Best,

Olaf



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

Re: Where does Tomcat 9 (apt managed / standard config) store sessions in Ubuntu 18?

[Olaf Kock]

On 20.06.21 04:54, Gustavo Almeida wrote:
> "Configuration Reference - The Manager Component" says:
> "A Manager element MAY be nested inside a Context component. If it is not
> included, a default Manager configuration will be created automatically"
>
> My Context has no nested Manager element.
>
> So, guessing I'm using by default the Standard Manager Implementation,
> where does it store active sessions, if it does at all?

Without looking it up (thus I could easily be proved wrong): My
assumption is that the active sessions are in memory. Is there any
particular reason why you'd expect them on disk?

Olaf


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

Re: CATALINA_OPTS vs JAVA_OPTS

[Olaf Kock]

Service configurations are service configurations. You won't run the
other options as service, so those are for the JVM that is used for the
service. And I'm not aware that a service is stopped as the command line
version. At least I'd hope so - a standard JVM would be good enough, if
the start/stop mechanism not handled in the windows executable anyway.

Note: This is dangerous half-knowledge. I haven't been on Windows for
ages, just read about it still being around from time to time.

CATALINA_OPTS is utilized by the startup batch/script file, which is not
used for services /at all/.

Olaf

On 16.06.21 20:31, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Ok, so this is a really good explanation. However, when setting up in Windows 
> as a Service, does the JAVA_OPTIONS in the Registry go in as JAVA_OPTS or 
> CATALINA_OPTS? Is there a way to have separate CATALINA_OPTS for Tomcat 
> Windows Services?
>
> Thanks,
>
> Dream * Excel * Explore * Inspire
> Jon McAlexander
> Infrastructure Engineer
> Asst Vice President
>
> Middleware Product Engineering
> Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions
>
> 8080 Cobblestone Rd | Urbandale, IA 50322
> MAC: F4469-010
> Tel 515-988-2508 | Cell 515-988-2508
>
> jonmcalexan...@wellsfargo.com
>
> Upcoming PTO: 10/30/2020, 11/6/2020, 11/13/2020, 11/20/2020, 11/27/2020, 
> 12/2/2020, 12/4/2020, 12/11/2020, 12/18/2020, 12/28/2020, 12/29/2020, 
> 12/30/2020, 12/31/2020
> This message may contain confidential and/or privileged information. If you 
> are not the addressee or authorized to receive this for the addressee, you 
> must not use, copy, disclose, or take any action based on this message or any 
> information herein. If you have received this message in error, please advise 
> the sender immediately by reply e-mail and delete this message. Thank you for 
> your cooperation.
>
>> -Original Message-
>> From: Christopher Schultz 
>> Sent: Wednesday, June 16, 2021 11:14 AM
>> To: users@tomcat.apache.org
>> Subject: Re: CATALINA_OPTS vs JAVA_OPTS
>>
>> Noelette,
>>
>> On 6/16/21 11:29, Noelette Stout wrote:
>>> Thanks! I was mostly trying to figure out if there was precedence or
>>> if it was additive (i.e. 2GB to tomcat itself and another 2GB to the
>>> apps). We're having some resource issues on one of our servers, so I
>>> wanted to make sure I understood how the resources were being
>> allocated.
>>
>> No additivity at all: the last one on the command-line wins. There is no heap
>> separation between Tomcat and the applications: it's one(ish) big, happy
>> heap. :)
>>
>> A note about CATALINA_OPTS versus JAVA_OPTS: when you use the various
>> scripts provided by Tomcat, CATALINA_OPTS is only used when launching a
>> Tomcat instance. JAVA_OPTS is used when launching *any* Java process.
>> There are many Java processes those scripts will launch that aren't actually
>> launching Tomcat. Examples include:
>>
>> 1. catalina.sh configtest
>> 2. catalina.sh stop (also shutdown.sh)
>> 3. catalina.sh version
>> 4. tool-wrapper.sh [anything]
>>
>> In all of those cases, JAVA_OPTS will be passed to the JVM.
>>
>> Do you really need a 2 gig heap to send a "shutdown" command to a running
>> server? Probably not.
>>
>> -chris
>>
>>> On Wed, Jun 16, 2021 at 9:17 AM Rob Sargent 
>> wrote:

 On 6/16/21 9:06 AM, Noelette Stout wrote:
> openjdk version "1.8.0_292"
>
>
> On Wed, Jun 16, 2021 at 9:04 AM Rob Sargent 
 wrote:
>
 Both as for the same minimum so you should get 2G at start up.  I'm
 not sure which has precedency but I would be on java opt.  I don't
 have a catalina env, but you can see how CATALINA_OPTS is used in
 relationship with JAVA_OPTS


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


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

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

Re: Request: Encryption requirements for TLS and SSL for Tomcat

[Olaf Kock]

On 08.06.21 14:10, Emen-Eddine AISSAOUI wrote:
> Hello,
>
> I am contacting you regarding the cipher suite recommandations for TLS and 
> SSL for Tomcat.
>
> Could you please tell us which cipher suites are used and necessary and if 
> there is any particular prequesites regarding TLS and SSL encryption for the 
> proper functioning of Tomcat ?
>
> This is an urgent request for a customer feedback.

Are you asking for the Java prerequisites? Bitsize for keys requirement?
What do you call "proper functioning" of Tomcat? Because it functions
quite properly with any (supported) TLS settings.

In general, the recommendations for ciphers are independent of the app
server, it's rather a common industry standard (changing over time), but
heavily depends on the devices you need to support.

Can't go without this rant with regards to your urgency: If you have
customers paying /you/ for that information, how much of that money are
you willing to share for a quicker answer, /tailored/ to your
(customer's) /exact/ needs? 

Olaf

Re: Question about encrypting database passwords in the context.xml file - Tomcat 9

[Olaf Kock]

On 07.06.21 10:56, xcorpius wrote:
> Hello again!
>
> Checking the documentation ... Tomcat can create an encrypted password with 
> the "digest.sh" tool for application passwords.
>
> But you cannot create an encrypted password for the DB in the context.xml 
> file. The only solution without adding anything is to give restrictive 
> permissions to the context.xml file.
>
> Wouldn't it be the same problem? Why can't I generate an encrypted password 
> for the database with the "digest.sh" tool instead of having to use a 
> customized "factory"?
>
> I think people who develop Tomcat should consider this option.
>
> Thank you very much to all.

Sorry, those are not the same: Digested passwords cannot be undigested,
but any digestion of the same password reveals the same digested result,
so that they can be compared. (read about the difference between hashing
and encryption)

For a database connection, you'll need to undigest (e.g. unencrypt) the
password and get it in clear text. And that's precisely what the FAQ
answers as impossible to do securely (without requiring manual input of
keys at each startup)

There's nothing here to consider that hasn't been considered before.

Olaf

>> Hi,
>> I wanted to ask about how to encrypt database passwords in the
>> context.xml file in Tomcat 9.
> Hi,
> please check this article:
 https://urldefense.com/v3/https://cwiki.apache.org/confluence/display/
 TOMCAT/Password;!!F9svGWnIaVPGSwU!5L0cC3jIaCuRm0q1-FYoVLDsuldYO4StHmkrZWg_Y0z1bdU7NM3IWFdkUykL7W_YAFGN4bM$

> It covers the topic once and for all...
> Olaf

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

Re: Question about encrypting database passwords in the context.xml file - Tomcat 9

[Olaf Kock]

On 26.04.21 13:10, xcorpius wrote:
> Hi,
>
> I wanted to ask about how to encrypt database passwords in the context.xml 
> file in Tomcat 9.
>
Hi,

please check this article:
https://cwiki.apache.org/confluence/display/TOMCAT/Password

It covers the topic once and for all...

Olaf


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

Re: Getting additional attributes for logged on users

[Olaf Kock]

Hi Carsten,

I'll be limiting my answer to the most notable lines and quote only those.

(anybody else reading this without following the mails live: Go to the
archive to see Carsten's full post)


On 08.04.21 22:08, Carsten Klein wrote:
>
> Typically, those desired extra attributes are stored in the user's
> record in the user database. That may be a SQL database or may be an
> Active Directory Server (or any other directory), which is already
> used for authentication and authorization.
>
> Wouldn't it be cool to make the Realm get us that extra information?

It would be cool, absolutely.

Even cooler if "the desired extra attributes" could be agreed upon - or
even what would be desirable in user management (is user + roles enough?
That requires redeployment any time the system gets more picky with
permissions.

Personally, I work with Liferay, where roles are runtime-configurable
and map to permissions. The permissions are what's checked in the
application code, and the applications couldn't care less about number
of roles or path through which a permission is assigned to a user.

> In its simplest form, these Realms get a new configuration property
> 'extraAttributes', which takes a comma separated list of field names
> to retrieve. Implicitly, for an SQL-based Realm, these fields are
> queried from the 'userTable' table. The JNDIRealm tries to find these
> attributes from the user's entry in the directory, of course.
>
> More complex configurations are possible (but likely not needed).

You first state "its simplest form", then state that more complex
solutions are likely not needed.

I'd argue that the current form is "the simplest form", as it provides
identifiers that can be used to look up extra information according to
the application's need.

I don't want to tear down your idea - only reflect that "only a little
bit more" will be barely enough for the next person coming around, and
end up being a really complex beast. And if you look at all the
different available attributes for users that make sense in some, but
not in other countries/cultures, you'll soon be implementing your own
anyway:

* What makes up the name? First/Last Name? Including middle name (common
in US, almost nonsensical in Germany)? There are cultures with just a
single name
* Gender: How many choices and what will they be named (by law, Germany
now has 3 genders)
* Address: I've recently sent out letters to international addresses,
and boy was it hard to ask for the right information to go to the
address sticker.
* Department: Makes sense in a business environment, not at all in a
community environment

While you name some samples that sound agreeable on first sight, I don't
think that they're agreeable enough to impose them on people unless
provided voluntarily and under arbitrary names. Which ends up with the
cost of a huge framework in order to potentially save a single database
request per log in.

E.g.: It would be cool, but I don't see it worth the price.

my 2 (Euro) Cent

Olaf



>
> I'm curious what you think about it :)
>
> Carsten
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>

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

[OT] Re: What exactly does the AJP connector on 8009 do?

[Olaf Kock]

On 06.04.21 11:53, André Warnier (tomcat/perl) wrote:
>
> Shortcut :
> - comment-out the AJP Connector in the tomcat configuration
> - restart tomcat
> - and wait for desperate support calls
>
That reminds me of the common wisdom in System Administration:

*Everybody* has a dedicated testing system. Always!

*Some* are lucky that they have a completely separate production system.


(lost the source)


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

Re: [OT] programming style or mental process ?

[Olaf Kock]

Hi André

On 04.04.21 12:23, André Warnier (tomcat/perl) wrote:
>
>   if (null == request.getCharacterEncoding()) {
>
> as opposed to
>
>   if (request.getCharacterEncoding() == null) {
>
>
> So why do (some) people write it the other way ?
> Is it purely a question of individual programming style ?
> Is there some (temporary ?) fashion aspect involved ?
> Do the people who write this either way really think in a different way ?
> Or is there really something "technical" behind this, which makes one
> or the other way be slightly more efficient (whether to compile, or
> optimise, or run) ?
>
> (*) excepting Yoda of course
>
I can't say I'm always writing Yoda style, but if I stretch my memory,
then the rationale behind this style of comparisons is to have a
constant on the left side, so that you get a compiler error in case
you're using = instead of ==.

In your case, with a function call, this wouldn't make a difference
"if(request.getCharacterEncoding() = null)" would be illegal syntax as
well, but "if(someObject = null)" is perfectly legal, but doesn't
express the author's intent clearly: Is it a smart person who's taking a
shortcut, or a newbie using the wrong operator?

Of course, the style doesn't really help people new to the language, as
they first need to understand that this is something that they might
want to apply to their code. And today, with so many IDE warnings being
flagged while typing, it might be outdated, though it still clearly
expresses the intent to have a real comparison and not an assignment here.

And I agree with the other answer posted already: It makes a lot more
sense in C++ with all the implicit boolean conversions and habits of
outsmarting the code's maintainers with clever expressions.

Olaf



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

Re: Mixed User Session

[Olaf Kock]

On 15.01.21 15:57, juan wrote:
> Hi,
>
> We were running tomcat 8.5.57 on CentOS 7 and together with CAS SSO, we
> have multiple servers behind an AWS load balancer setup with sticky
> sessions. We encountered a weird situation where a user who logged into
> their application was presented with another users profile after login. Has
> anyone encountered something similar to this? Both users hit the same
> tomcat server seconds apart and the user was on his personal computer and
> doesn't know the first user.

I've seen stuff like this happening when a reverse proxy was over-eager
in caching stuff that it saw. 100% of cases where I've seen this
behavior had this as a root cause.

"over-eager" might mean that Tomcat (e.g. your app) doesn't signal the
upstream proxy that the content is private, or the upstream proxy
ignoring such signals.


It's been a long time since I last saw it (and back then I didn't
fix it myself - just provided information like the above) so I barely
remember the key points to configure or look after. Maybe it helps
already, otherwise we'll have to wait for someone to point to the usual
suspects in the individual configurations.

Olaf


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

Re: regarding CVE-2020-8022 applicable to tomcat 8.5.57

[Olaf Kock]

On 02.09.20 10:16, Rathore, Rajendra wrote:
> Please let me know whether CVE-2020-8022 applicable to tomcat 8.5.57 or not, 
> if yes please let me know which release we fixing it.


The CVE states:

"A Incorrect Default Permissions vulnerability in the *packaging of
tomcat* on SUSE Enterprise Storage 5"

i.e. it's rather SUSE's packaging than tomcat itself. Correct me if I'm
wrong.

If you're running any SUSE system, here are the releases that *they*
fixed it: https://www.suse.com/de-de/security/cve/CVE-2020-8022/

I don't expect any update from the generic Apache distribution of Tomcat
for this CVE, unless I've missed some information that was well hidden
in the multitude of mentioned SUSE products in that report.

Olaf



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

Re: Allowing dir listing of root (/) dir of the machine

[Olaf Kock]

On 24.08.20 16:41, Aryeh Friedman wrote:
> On Mon, Aug 24, 2020 at 4:27 AM Mark Thomas  wrote:
>
>> On 23/08/2020 22:05, Aryeh Friedman wrote:
>>> In order to allow my developers to quickly access any temporarily
>> produced
>>> html files created/stored outside of webapps (such as those created by
>> the
>>> jacoco test coverage tool) I want to allow read only access to the root
>>> directory of the development server (firewalled and all access outside of
>>> the LAN is disabled) via tomcat.   I can get it to do any directory
>>> *EXCEPT* / as the docBase but a docBase of "/" returns an empty dir
>> listing
>>
[snip]
>> I'd do this with a ROOT.xml file in
>> $CATALINA_BASE/conf/Catalina/localhost but the above should work.
[snip]


I'd recommend to *not* go this route. Rather google for "java web file
manager" or variations thereof: You'll find several open source projects
that implement a file browser in a deployable web application. You can
apply password protection to it, update/deploy/configure the application
(e.g. to prevent /etc/passwd to be read) and so on.

I'm explicitly not linking any of those applications here, as I can't
recommend any from my own experience. I remember to have worked with one
ages ago that was implemented in a single JSP (great to plant a
debugging backdoor on production servers. But /cough/ who would ever do
that?)

Olaf



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

Re: Patch for Ubuntu 18

[Olaf Kock]

On 20.07.20 15:55, Celestino Federico (ETAS-SEC/ISY-IT) wrote:
>  
>
> Could someone tell me how to find a debdiff for tomcat8 package from
> version *8.5.39-1ubuntu1~18.04.3* (last version available on Ubuntu
> 18) and version *8.5.56*?
>
>
My expectation is that you'll have to create this yourself. In the
Debian world, they typically pick a version of any packaged software and
/might/ backport individual fixes from later releases, but won't update
to a newer minor version in most cases.

I'm not really sure where the sources are kept for the Debian packages,
but there you should be able to see the commit history, and potentially
all fixes that have been backported.

Personally, I find Tomcat releases stable (and backwards-compatible)
enough that I rarely rely on any distribution for Tomcat installations,
but rather take the stock download from tomcat.apache.org and add a
daemon start script.

Olaf

Re: file ownership of webapps and below

[Olaf Kock]

On 14.07.20 11:12, Christoph Kukulies wrote:
> I found there are some mismatches in file ownership from manual installation 
> and moving around webapps  trees from different tomcat versions.
> My current tomcat (9)  runs under user.group tomcat.tomcat. A couple of files 
> have ownership
>
> root.tomcat
> tomcat8.
>
> Would it be ok to chown all files below and including webapps to 
> tomcat.tomcat?

It depends (TM)


There are those who can't operate without tomcat having write access to
its own operations, e.g. because they rely on the manager app for
deployments.

And there are those who prefer Tomcat to not have any write access to
its own applications, as a means of hardening the installation.

My preference is to limit write permissions (and ownership) to temp,
work and logs. Your mileage may vary.


Olaf



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

Re: How to encrypt db password in tomcat context.xml

[Olaf Kock]

On 28.06.20 19:50, Jürgen Weber wrote:
 I would like to know how to encrypt and decrypt the database password in
 context.xml when the application is running which also allow me to change
 the db password for the purpose of security.
>> https://cwiki.apache.org/confluence/display/TOMCAT/Password
> Well, I know a chief open source app server that has the password to
> decrypt all passwords buried in its open source, and I know auditors
> who are good if root cannot read passwords at first sight. The
> reasoning behind that is that running java -jar someappserverlib.jar
> -decrypt is a deliberate act that a god guy root does not do. So a
> hidden password is a step better, even if not in the cryptographic
> sense.

Hi Jürgen,

I don't get your point here. Are you arguing that the linked wiki
article is incorrect, insufficient or invalid?

Because I believe that the article documents how to implement everything
that you describe on your own, and gives arguments for why this is not
implemented out of the box.

Best,

Olaf




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

Re: How to encrypt db password in tomcat context.xml

[Olaf Kock]

On 26.06.20 15:05, FANG YAP wrote:
> Hi Tomcat,
>
> I would like to know how to encrypt and decrypt the database password in
> context.xml when the application is running which also allow me to change
> the db password for the purpose of security.


https://cwiki.apache.org/confluence/display/TOMCAT/Password




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

Re: Cryptominer malware and Tomcat

[Olaf Kock]

Hi Pete,

On 17.06.20 23:44, Pete Helgren wrote:
> I am going to guess that it is one of these two known vulnerabilities:
>
> CST-7111: RCE via JSON deserialization (LPS-88051/LPE-165981)
> The JSONDeserializer of Flexjson allows the instantiation of arbitrary
> classes and the invocation of arbitrary setter methods.
>
> CST-7205: Unauthenticated Remote code execution via JSONWS
> (LPS-97029/CVE-2020-7961)
> The JSONWebServiceActionParametersMap of Liferay Portal allows the
> instantiation of arbitrary classes and invocation of arbitrary setter
> methods.
>
> Found the signature in the logs and it's pretty clear that that is
> what we are up against.  However, if something else comes to mind,
> feel free to post back.  I  did come across a couple of other posts
> where the OP said there was nothing but Tomcat and they also ended up
> with the miner.
>
> I have some updating to do
>
Correct analysis.

What you need is this update
https://liferay.dev/blogs/-/blogs/security-patches-for-liferay-portal-6-2-7-0-and-7-1

And while you're at it: There has been another patch published this
month
https://liferay.dev/blogs/-/blogs/june-2020-security-patches-for-liferay-portal-7-1-and-7-2

Best,

Olaf


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

Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?

[Olaf Kock]

On 15.05.20 13:23, ohaya wrote:
>  Hi,
>
> I just tried adding the secret to the Apache side:
>
> ProxyPass ajp://192.168.218.XXX:8009 secret="123"
> ProxyPassReverse ajp://192.168.218.XXX:8009 secret="123"
>
> and I get an error when I try to start Apache:
>
> AH00526: Syntax error on line 554 of /apps/oracle/apache/conf/httpd.conf:
> ProxyPass unknown Worker parameter
>
> I am currently using Apache 2.4.39. Is there another way to specify the 
> "secret"?

With 9.0.20 you do not yet need to pass a secret - that came along later
(somewhere around 30-33 AFAIR). However, you'll need to make sure that
your AJP port is only available for the reverse proxy and nobody else -
there was a recent security disclosure, which led to the change of many
default settings for the AJP connector in the current releases.

It boils down to the last sentence of my previous answer: I've never
used REMOTE_USER headers for authentication, and there's no indicator in
your setup that you're allowing Tomcat to trust such a header. I might
be completely off here, but as nobody else answered yet, I thought I'd
give it a try.

Olaf

> Thanks,
> Jim
>
>
>  On Friday, May 15, 2020, 07:04:44 AM EDT, ohaya 
>  wrote:  
>  
>   Hi,
>
> The Tomcat version I am using is 9.0.20. I will take a look at the changelog. 
>
> This is the first time I have tried this, and I couldn't find much info, so I 
> appreciate the feedback. I will look for info about "secret". 
>
> I wasn't sure about the format on the Apache side for the 
> ProxyPass/ProxyPassReverse - does what I posted look all right?
>
> Also, when I was searching around for info, I saw some comments that seem to 
> be saying that the "tomcatAuthentication" parameter on the Tomcat connection 
> was no longer supported or something like that?
>
> Also re. "secret" on the Tomcat side: If that is set to, for example, 
> "mysecret", how do I pass that on the Apache side?
>
> Thanks again,
> Jim
>
>
>     On Friday, May 15, 2020, 03:33:19 AM EDT, Olaf Kock  
> wrote:  
>  
>  
> On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote:
>> Hi,
>>
>> I am using an Apache proxy in front of Tomcat 9, and I am using AJP 
>> connection to connect from the Apache to Tomcat, and I have the Apache 
>> sending a username to the Tomcat in a REMOTE_USER header.
>>
>> In the Tomcat server.xml I have:
>>
>>   > tomcatAuthentication="false"/>
>>
>> In the Apache httpd.conf, to test, this I have:
>>
>> 
>> ProxyPass ajp://192.168.218.XX:8009
>> ProxyPassReverse ajp://192.168.XX.224:8009
>> 
>>
>> But when I access the app via the Apache, it is not automatically logging me 
>> into the app.
>>
>> Is there anything else that I have to do to get this to work besides what I 
>> did above?  Is there something that I have to modify in the app itself to 
>> get this to work?
> Hi Jim,
>
> which exact version of Tomcat 9 are you using? Note that there were
> significant changes for the default and required configuration for the
> AJP connector, in order to use it. Best to find all of them: Search for
> AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html
>
> Notable among them: Everything to do with "secret", and the default bind
> address, "localhost", for the AJP connector. i.e. I'd expect this
> configuration to be insufficient for any of the latest releases.
>
> I haven't ever used this REMOTE_USER authentication, but nothing in the
> configuration that you've posted gives any clue about what you do and
> what you send. I would expect Tomcat to *not* blindly accept any
> REMOTE_USER header by default, unless it's whitelisted and explicitly
> asked for - it otherwise would be a great way to exploit servers that
> don't have a remote proxy (or one where the remote proxy is configured
> to remove this header). Nothing in the configuration you post gives me a
> hint about what you do to make tomcat accept and trust this header.
>
> Olaf
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>     

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

Re: Does Tomcat 9 still support AJP connections, REMOTE_USER, and tomcatAuthentication="false"?

[Olaf Kock]

On 15.05.20 09:06, oh...@yahoo.com.INVALID wrote:
> Hi,
>
> I am using an Apache proxy in front of Tomcat 9, and I am using AJP 
> connection to connect from the Apache to Tomcat, and I have the Apache 
> sending a username to the Tomcat in a REMOTE_USER header.
>
> In the Tomcat server.xml I have:
>
>   tomcatAuthentication="false"/>
>
> In the Apache httpd.conf, to test, this I have:
>
> 
> ProxyPass ajp://192.168.218.XX:8009
> ProxyPassReverse ajp://192.168.XX.224:8009
> 
>
> But when I access the app via the Apache, it is not automatically logging me 
> into the app.
>
> Is there anything else that I have to do to get this to work besides what I 
> did above?  Is there something that I have to modify in the app itself to get 
> this to work?

Hi Jim,

which exact version of Tomcat 9 are you using? Note that there were
significant changes for the default and required configuration for the
AJP connector, in order to use it. Best to find all of them: Search for
AJP in the change log tomcat.apache.org/tomcat-9.0-doc/changelog.html

Notable among them: Everything to do with "secret", and the default bind
address, "localhost", for the AJP connector. i.e. I'd expect this
configuration to be insufficient for any of the latest releases.

I haven't ever used this REMOTE_USER authentication, but nothing in the
configuration that you've posted gives any clue about what you do and
what you send. I would expect Tomcat to *not* blindly accept any
REMOTE_USER header by default, unless it's whitelisted and explicitly
asked for - it otherwise would be a great way to exploit servers that
don't have a remote proxy (or one where the remote proxy is configured
to remove this header). Nothing in the configuration you post gives me a
hint about what you do to make tomcat accept and trust this header.

Olaf



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

Re: how do I switch class loaders

[Olaf Kock]

On 08.05.20 19:50, Christopher Schultz wrote:
> Olaf,
>
> On 5/8/20 13:19, Olaf Kock wrote:
>
> > You might want to hunt down duplicate classes in the JAR files on
> > your classpath. Worst case: unpack them all in temporary
> > directories and check for occurrences of the filename. Make sure
> > that one doesn't overwrite the other when unzipping.
>
> Or unpack them all and let the unzipper tell you if there are any
> filename collisions.
>
> Someone has probably written a "classpath scanner" that will just
> unzip everything and look for conflicts.


I've gotten follow up questions on how to use those tools in the past.
Key is to identify all the jars, less the options of the tool, but since
then I've just reverted to mention the low-tech version, and am not even
ashamed ;)

That's not to say that I don't trust Jonathan to use a classpath scanner
- it's just a low-tech-preference out of habit.

Plus, due to this habit, I currently can't come up with a tool's name to
look for :D

Olaf



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

Re: how do I switch class loaders

[Olaf Kock]

On 08.05.20 18:23, Jonathan Yom-Tov wrote:
> Oops, my bad  But that still leaves my original issue: why do I get a
> ClassCastException casting RedissonSessionManager to
> RedissonSessionManager?

The *only* reason that I've ever seen this happens (e.g. a class can't
be typecast to a legitimate superclass or interface): When the
superclass or interface is available through two different classloaders.

The error message omits the classloader, and instead of

  A cannot be cast to B

/should/ read

   A (from classloader X) cannot be cast to B (from classloader Y)

You might want to hunt down duplicate classes in the JAR files on your
classpath. Worst case: unpack them all in temporary directories and
check for occurrences of the filename. Make sure that one doesn't
overwrite the other when unzipping.

Olaf



> On Fri, 8 May 2020, 16:56 Luis Rodríguez Fernández, 
> wrote:
>
>> Hello Jonathan,
>>
>> It is not exactly the same :), look at the "$2" appended at the end.This is
>> an "anonymous inner class" [1]
>>
>> Cheers,
>>
>> Luis
>>
>> [1]
>>
>> https://stackoverflow.com/questions/11388840/java-compiled-classes-contain-dollar-signs
>>
>>
>> El vie., 8 may. 2020 a las 11:52, Jonathan Yom-Tov (<
>> jonathan.yom...@sysaid.com>) escribió:
>>
>>> This is very odd. I ran Tomcat with -verbose:class (see relevant output
>>> below). The class is being loaded twice from the same location, I'm
>>> guessing by two different class loaders. How can that be?
>>>
>>> [Loaded org.redisson.tomcat.RedissonSessionManager from
>>> file:/C:/dev/tomcat.9.0.19/lib/redisson-tomcat-9-3.12.2.jar]
>>> [Loaded org.redisson.tomcat.RedissonSessionManager$2 from
>>> file:/C:/dev/tomcat.9.0.19/lib/redisson-tomcat-9-3.12.2.jar]
>>>
>>> On Fri, May 8, 2020 at 11:04 AM Olaf Kock  wrote:
>>>
>>>> On 08.05.20 09:37, Jonathan Yom-Tov wrote:
>>>>> Thanks Mark. Just tried that. I put the redisson-tomcat jar outside
>> of
>>>>> WEB-INF/lib and added it with scope provided. I get the exact same
>>> issue.
>>>>> What am I doing wrong?
>>>> Make sure, it's actually gone from your webapp. Depending on the
>>>> deployment technique I've seen removed files to persist from previous
>>>> deployments.
>>>>
>>>> You might need to fully undeploy, then deploy the new version without
>>>> the jar in question. But inspect the runtime environment to make sure
>>>> you only have a single library accessible. Having the same class
>>>> available two different ways is a recipe for disaster, don't fix it my
>>>> messing with the classloader: Fix it by eliminating one of them.
>>>>
>>>> You might also check if you're not accessing any wrapped object, e.g.
>> by
>>>> inspecting getManager(session).getClass().getName().
>>>>
>>>> Olaf
>>>>
>>>>
>>>>
>>>>> Here's my code:
>>>>>
>>>>> HttpSession session = httpServletRequest.getSession(false);
>>>>> try {
>>>>> RedissonSessionManager rsm = (RedissonSessionManager)
>>>> getManager(session);
>>>>> } catch (Exception e) {
>>>>> e.printStackTrace();
>>>>> }
>>>>>
>>>>> private Manager getManager(HttpSession session) throws Exception {
>>>>>
>>>>> Field facadeSessionField =
>>>>> StandardSessionFacade.class.getDeclaredField("session");
>>>>> facadeSessionField.setAccessible(true);
>>>>> StandardSession stdSession = (StandardSession)
>>>>> facadeSessionField.get(session);
>>>>>
>>>>> return stdSession.getManager();
>>>>> }
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 7, 2020 at 11:52 PM Mark Thomas 
>> wrote:
>>>>>> On 07/05/2020 21:36, Jonathan Yom-Tov wrote:
>>>>>>> My application uses Redisson (a client which persists the session
>> to
>>>>>>> Redis). There are two Redisson jar files located in
>>> $CATALINA_HOME/lib,
>>>>>> so
>>>>>>> if I understand the docs correctly they're loaded by the common
>> class
>>>>>>> loader.
>>>>>>>
>>>>>>> I want to access the RedissonSessionManager class during a request.
>>> The
>>>>

Re: how do I switch class loaders

[Olaf Kock]

On 08.05.20 09:37, Jonathan Yom-Tov wrote:
> Thanks Mark. Just tried that. I put the redisson-tomcat jar outside of
> WEB-INF/lib and added it with scope provided. I get the exact same issue.
> What am I doing wrong?

Make sure, it's actually gone from your webapp. Depending on the
deployment technique I've seen removed files to persist from previous
deployments.

You might need to fully undeploy, then deploy the new version without
the jar in question. But inspect the runtime environment to make sure
you only have a single library accessible. Having the same class
available two different ways is a recipe for disaster, don't fix it my
messing with the classloader: Fix it by eliminating one of them.

You might also check if you're not accessing any wrapped object, e.g. by
inspecting getManager(session).getClass().getName().

Olaf



> Here's my code:
>
> HttpSession session = httpServletRequest.getSession(false);
> try {
> RedissonSessionManager rsm = (RedissonSessionManager) getManager(session);
> } catch (Exception e) {
> e.printStackTrace();
> }
>
> private Manager getManager(HttpSession session) throws Exception {
>
> Field facadeSessionField =
> StandardSessionFacade.class.getDeclaredField("session");
> facadeSessionField.setAccessible(true);
> StandardSession stdSession = (StandardSession)
> facadeSessionField.get(session);
>
> return stdSession.getManager();
> }
>
>
>
> On Thu, May 7, 2020 at 11:52 PM Mark Thomas  wrote:
>
>> On 07/05/2020 21:36, Jonathan Yom-Tov wrote:
>>> My application uses Redisson (a client which persists the session to
>>> Redis). There are two Redisson jar files located in $CATALINA_HOME/lib,
>> so
>>> if I understand the docs correctly they're loaded by the common class
>>> loader.
>>>
>>> I want to access the RedissonSessionManager class during a request. The
>>> problem is that if I do something like RedissonSessionManager manager =
>>> (RedissonSessionManager) session.getManager() I get a ClassCastException,
>>> presumably because they were loaded by different class loaders.
>>>
>>> Will it help if I somehow access the common class loader for this? If so
>>> how can I do that? If not is there some other way I can achieve this?
>> Make sure you don't have those JARs in your application's WEB-INF/lib as
>> well as $CATALINA_BASE/lib.
>>
>> In any recent version of Tomcat any JAR in $CATALINA_BASE/lib will be
>> visible to your application.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

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

Re: Tomcat 7.0.103

[Olaf Kock]

Hi Greg,

On 21.04.20 04:13, Hebner, Greg D. wrote:
> We are migrating from 7.0.68 to 7.0.103 to close some security 
> vulnerabilities. We are running LDAP authentication via JAAS. Authentication 
> was working normally on 7.0.68. we use scripts to configure Tomcat 
> installations so every install is exactly alike and we get expected results 
> and operation. On version 7.0.103, even though the catalina.out indicates 
> that LDAP authentication succeeded, I am returned to the login page. I have a 
> second authentication mechanism for non-LDAP authentication, and it still 
> operates normally.
>
> Is it possible that some configuration argument has been changed/added that 
> would cause this behavour? When I revert back to the 7.0.68 version, LDAP 
> authentication is restored. Help?

I didn't run into that issue, so can't answer from memory. But
http://tomcat.apache.org/tomcat-7.0-doc/changelog.html might help
identifying - it's a bit of a reading, but might just help you find what
exactly changed and when.

Olaf


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

Re: How to shutdown tomcat

[Olaf Kock]

On 17.04.20 16:55, Blake McBride wrote:
> I suppose, never mind.  I created a startup listener that just does a
> System.exit(0) on contextDestroyed which is what I want - exit.
>
> Thanks.
>
> Blake
>
>
> On Fri, Apr 17, 2020 at 8:53 AM Blake McBride  wrote:
>
>> Greetings,
>>
>> I am running vanilla tomcat 9.0.34 on a 64 bit Linux box.  Short of
>> killall, I can't stop tomcat.  I am trying bin/shutdown.sh.  Sure
>> appreciate some help.

The proper solution is in your log:

"The web application [Kiss] appears to have started a thread named
[Thread-5] but has failed to stop it."

If that's not a daemon thread, the JVM, by design, can't stop.

Instead of calling System.exit(), do the right thing and implement
proper shutdown for all threads that the application starts on its own.
Or, if you don't care about interrupting them at inopportune time (as
you demonstrate with System.exit), simply set their daemon flag and
leave their buggy implementation in place.

By the way: This behavior will keep the application from proper
redeployment. My recommendation: Correct your implementation rather than
nuking it from orbit.

Olaf

>> 17-Apr-2020 08:44:41.745 WARNING [main]
>>  org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
>> web application [Kiss] appears to have started a thread named [Thread-5]
>> but has failed to stop it. This is very likely to create a memory leak.
>> Stack trace of thread:
>>  sun.misc.Unsafe.park(Native Method)
>>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>
>>  
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044)
>>
>>  
>> java.util.concurrent.LinkedBlockingDeque.takeFirst(LinkedBlockingDeque.java:492)
>>  org.kissweb.rest.QueueManager$Dispatcher.run(QueueManager.java:61)
>>  java.lang.Thread.run(Thread.java:748)
>> 17-Apr-2020 08:44:41.745 WARNING [main]
>> org.apache.catalina.loader.WebappClassLoaderBase.clearReferencesThreads The
>> web application [Kiss] appears to have started a thread named
>> [pool-1-thread-1] but has failed to stop it. This is very likely to create
>> a memory leak. Stack trace of thread:
>>  sun.misc.Unsafe.park(Native Method)
>>  java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
>>
>>  
>> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044)
>>
>>  java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
>>
>>  
>> java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1074)
>>
>>  
>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1134)
>>
>>  
>> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>>  java.lang.Thread.run(Thread.java:748)
>> 17-Apr-2020 08:44:41.749 INFO [main]
>> org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler
>> ["http-nio-8080"]
>> 17-Apr-2020 08:44:41.750 INFO [main]
>> org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler
>> ["http-nio-8080"]
>> blake@i9-tower:~/intellijProjects/Kiss/tomcat/logs$
>>

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

Re: learning tomcat 7 on Linux

[Olaf Kock]

On 08.04.20 14:55, Andy Sloane wrote:
> Hi,
> I have set up a Linux CentOS 7 host, and have installed Tomcat 7...
>
> ...
> I would like to learn how to develop webapps.
>
I see no particular reason to start with Tomcat 7. Most of the code that
you will learn will be version independent, and the End of Life for
Tomcat 7 is already set to March 2021. I'd recommend to go with Tomcat
9. Installation - especially for development purposes - will be trivial
and is easier for development anyway.

I'm assuming you're running the old version, because that's what the
CenOS repositories hold. For development: No need to do this.

I don't know Richard's course, but I assume that he'll talk about a
development environment and installing a new dev environment as well:
Use that, rather than whatever comes with CentOS. Access permissions on
the files of a development server are far simpler than on fully
public-server-enabled installs.

Olaf


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

Re: How to increase Memory available to Tomcat?

[Olaf Kock]

On 31.03.20 17:02, o haya wrote:
> Hi,
>
> I am running Tomcat 9.02 under RHEL 7 (under Oracle JDK 1.8), and I would
> like to increase the memory that is available to Tomcat when it is running.
>
> I have tried sourcing the following:
>
> JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \
> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m
> -XX:+DisableExplicitGC \
> -Djava.security.egd=file:/dev/./urandom -d64"

You want to use CATALINA_OPTS for memory settings, not JAVA_OPTS.

JAVA_OPTS are used for every JVM start, including when you run
shutdown.sh - that one needs only a minimal amount of memory for short time.

> and also:
>
> CATALINA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server \
> -Xms4096m -Xmx4096m -XX:NewSize=256m -XX:MaxNewSize=256m
> -XX:+DisableExplicitGC \
> -Djava.security.egd=file:/dev/./urandom"

your CATALINA_OPTS will be combined with the JAVA_OPTS, so that you
configure the memory twice.

But -Xms and -Xmx are the way to configure the memory.

> but even with those, when I check memory using "free", it is only using
> about 1.5GB.
>
> Can someone tell me how I can accomplish this?

Sounds suspiciously like you're running on 32bit, either the OS or JVM.
Upgrade to 64bit to have access to more memory.




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

Re: Does Tomcat/Java get around the problem of 64K maximum client source ports?

[Olaf Kock]

Hi Eric,

On 26.03.20 18:58, Eric Robinson wrote:
> Greetings,
>
> Many people say the maximum number of client ports is 64K. However, TCP 
> connections only require unique sockets, which are defined as...
>
> local_IP:local_port -> remote_ip:remote_port
>
> Theoretically, it is possible for a client process to keep using the same 
> local source port, as long as the connections are to a unique destinations. 
> For example on a local machine, the following connections should be 
> possible...
>
> 192.168.5.100:1400 -> 192.168.5.200:3306
> 192.168.5.100:1400 -> 192.168.5.201:3306
> 192.168.5.100:1400 -> 192.168.5.202:3306
> 192.168.5.100:1400 -> 192.168.5.203:3306
>
> I've seen this demonstrated successfully here:
>
> https://serverfault.com/questions/326819/does-the-tcp-source-port-have-to-be-unique-per-host
>
> As someone on that page pointed out, while it is possible, it does not 
> commonly occur in practice "because most TCP APIs don't provide a way to 
> create more than one connection with the same source port, unless they have 
> different source IP addresses." This leads to the 64K maximum client port 
> range, but it is really a limitation of the APIs, not TCP.
>
> So how does tomcat handle things? Is it limited to a maximum 64K client 
> source ports, or is it 64K per destination, as it should be?

To be honest, I can't remember to have seen a web- or application server
that accepts 64K concurrent connections at all, let alone to a single
client.

I can't come up with any reason to do so, I'd assume that there's a DOS
attack if I get 100 concurrent incoming connections from a single IP,
and a programming error if the server sets up more than 1K outgoing
connections

Maybe I'm missing the obvious, or have only administered meaningless
installations, but I fail to see the real world relevance of this question.



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

Re: Is it possible to programmatically compile jsp files?

[Olaf Kock]

On 25.03.20 15:19, Jonathan Yom-Tov wrote:
> Sounds good. What would be the best way of evaluating the result so I can
> cache it?

Buffer the output (e.g. by providing a buffered stream for the response)

I'm not sure if this means that you'll need to wrap the response object,
of if you could just replace its output stream. But in general: In your
filter, make sure you get hold of the output stream and capture its
content before you pass the request along the filter chain. After
returning, obtain the buffer, save it for future use, then dump it on
the original output stream. The commons project has a couple of nice
options (I vaguely remember a TeeOutputStream or similar, which would
automagically be able to keep your current client happy, while also
filling up the buffer)


Olaf



> On Wed, Mar 25, 2020 at 4:03 PM Olaf Kock  wrote:
>
>> On 25.03.20 14:51, Jonathan Yom-Tov wrote:
>>> I think I phrased my question incorrectly. What I want to do is to cache
>>> the HTML resulting from the JSPs evaluation so I can serve the cached
>>> result. The reason is that I'm working on an application which makes a
>> lot
>>> of requests per page. This makes the page very slow. What I want to do is
>>> to serve some of the requests which build the page out of a cache.
>>> Rewriting the offending endpoints would be a very lengthy process. There
>>> are a lot of them and they're part of a legacy project which is very hard
>>> to get into.
>>>
>>> So is pre-evaluating the JSPs the correct strategy or is there a
>> better way?
>>
>>
>> well, with that, you could either request the JSP yourself and cache the
>> result. To do this transparently, you could implement a ServletFilter
>> that caches the result if it senses a cacheable request and (on
>> subsequent requests) transparently serves the value from cache as long
>> as the criteria ("should re-evaluate") holds.
>>
>> Bonus points for taking care of concurrent requests during
>> re-evaluation, and pause them during the time a re-evaluation is done in
>> a different request.
>>
>> Olaf
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>

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

Re: Is it possible to programmatically compile jsp files?

[Olaf Kock]

On 25.03.20 14:51, Jonathan Yom-Tov wrote:
> I think I phrased my question incorrectly. What I want to do is to cache
> the HTML resulting from the JSPs evaluation so I can serve the cached
> result. The reason is that I'm working on an application which makes a lot
> of requests per page. This makes the page very slow. What I want to do is
> to serve some of the requests which build the page out of a cache.
> Rewriting the offending endpoints would be a very lengthy process. There
> are a lot of them and they're part of a legacy project which is very hard
> to get into.
>
> So is pre-evaluating the JSPs the correct strategy or is there a
better way?


well, with that, you could either request the JSP yourself and cache the
result. To do this transparently, you could implement a ServletFilter
that caches the result if it senses a cacheable request and (on
subsequent requests) transparently serves the value from cache as long
as the criteria ("should re-evaluate") holds.

Bonus points for taking care of concurrent requests during
re-evaluation, and pause them during the time a re-evaluation is done in
a different request.

Olaf




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

Re: Is it possible to programmatically compile jsp files?

[Olaf Kock]

On 24.03.20 15:44, Jonathan Yom-Tov wrote:
> I have a set of jsp files. These jsps' compilation result changes whenever
> a variable in my cache changes. I want to compile them whenever that
> variable changes so they're ready to serve without going through the normal
> pipeline. Is that possible?
>
Sounds a lot like you're runtime-generating JSPs. I'd rather recommend
to implement a taglib or some other means to generate output dependent
on your cache's content.

At least I can't come up with a different idea for why a compilation
result would depend on some runtime data.

With runtime generation, you might easily run into concurrency issues,
e.g. requesting a JSP while it's overwritten, and only half of the file
is generated (or the file is not yet readable). This would leave a
compiler error, and if the timestamp doesn't update any more, leave you
with a weird result.

Is it possible? Sure. Is it likely the right solution to your problem: I
doubt (until proven opposite)

Olaf


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

Re: AW: gostCat patch

[Olaf Kock]

On 23.03.20 15:07, Mark Thomas wrote:
> On 23/03/2020 14:02, Fritze, Florian wrote:
>> Maybe I am making it too easy but if you or another tomcat developer could 
>> prevent the newest Tomcat from throwing this exception: 
>>
>> org.apache.catalina.core.StandardService.startInternal Failed to start 
>> connector [Connector[AJP/1.3-8011]]
>>  org.apache.catalina.LifecycleException: Der Start des 
>> Protokoll-Handlers ist fehlgeschlagen
>>  at 
>> org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
>>  at 
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>  at 
>> org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
>>  at 
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>  at 
>> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
>>  at 
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>  at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
>>  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>  at 
>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>  at 
>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>  at java.lang.reflect.Method.invoke(Method.java:498)
>>  at 
>> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
>>  at 
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
>>  Caused by: java.lang.IllegalArgumentException: The AJP Connector is 
>> configured with secretRequired="true" but the secret attribute is either 
>> null or "". This combination is not valid.
>>  at 
>> org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
>>  at 
>> org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
>>  ... 12 more
>>
>> This could solve the problem for me: Please just let the tomcat run through 
>> and do not let it check for the validation criterion.
> Sorry, no.
>
> Research indicated that a large number of Tomcat users were running an
> AJP connector in an insecure configuration. The Tomcat team made a
> deliberate choice to break those configurations and require users to
> make configuration changes either to secure those configurations or to
> explicitly allow the insecure ones.

I applaude this decision. I believe that the error message is clear
enough to point to the root cause - and with the public awareness of the
Ghostcat vulnerability and necessity to patch, the release notes are
quite clear about the changed defaults.

The only change that I'd assume could help is to add a comment to
server.xml, next to the commented-out AJP-Connector, that states: "This
configuration isn't complete - read the documentation, particularly
'secretRequired', 'secret', ... to learn about the proper settings". But
even if that doesn't go in, the necessary change should be found quickly
given the above error message.

Olaf




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

Re: Security audit raises questions (Tomcat 7.0.93)

[Olaf Kock]

On 18.03.20 01:04, James H. H. Lampert wrote:
> On 3/17/20 3:50 PM, Mark Thomas wrote:
>> The XXS might be valid. I assume the tool provided a sample URL you
>> could use to validate the finding. That should point you in the right
>> direction but feel free to ask here if more help is required.
> Near as I can tell, it did but it didn't provide a sample URL.
>
> Note that *all* I have is a PDF of the report, and I think the URL may
> have gotten mangled by spanning a page-break. I've posted a screenshot
> (with identifying information redacted) of what I'm looking at in the
> report:
>
> https://www.flickr.com/gp/64159238@N03/02i78o
>
This issue, according to that screenshot, seems to be on an error.jsp.
The only error.jsp that I could find in Tomcat 7.0.93 and 7.0.100 is in
webapps/examples/jsp/security/protected/error.jsp, i.e. under
/webapps/examples

Are you sure that this is for tomcat, not for your own application?
Looking at tomcat's jsp, it's as simple as it can be, takes no external
input, and doesn't generate markup as the one you've posted. But just in
case: That examples webapp probably shouldn't be deployed on production
servers anyway (seeing it there, IMHO it'd be a good idea to not package
it in this way in the first place, but that's a different story)

Cheers,

Olaf


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

Re: Tomcat 8.5.51 fails

[Olaf Kock]

On 13.02.20 11:17, Olaf Kock wrote:
> On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote:
>> On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote:
>>> Check in the file (tomcat_dir)/conf/server.xml, the Connector :
>>>
>>>      
>> The setting is the same as mine.
>>
>> I have use server.xml used in 8.5.50. In case of 8.5.50, I have no
>> problem.
>>
>> Please notice, I have been using Tomcat for 5 years with updates.
>> Why this time?
>
> Because this time, security relevant defaults changed: See these recent
> commits on the git mirror:
>
> https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262
>
> https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262

Or, even better digestible (I hit 'send' too early):

Mark's announcement of the availability contained:

> - AJP defaults changed to listen the loopback address, require a
secret and to be disabled in the sample server.xml

And the changelog on
http://tomcat.apache.org/tomcat-8.5-doc/changelog.html for 8.5.51
contains this information on AJP:

  * Update: Disable (comment out in server.xml) the AJP/1.3 connector by
default. (markt)
  * Update: Change the default bind address for the AJP/1.3 connector to
be the loopback address. (markt)
  * Add: Rename the |requiredSecret| attribute of the AJP/1.3 Connector
to |secret| and add a new attribute |secretRequired| that defaults
to |true|. When |secretRequired| is |true| the AJP/1.3 Connector
will not start unless the |secret| attribute is configured to a
non-null, non-zero length String. (markt)
  * Add: Add a new attribute, |allowedRequestAttributesPattern| to the
AJP/1.3 Connector. Requests with unrecognised attributes will be
blocked with a 403. (markt)

There's also a discussion on the "Re: [ANN] Apache Tomcat 9.0.31
available" thread on this changed default that might give you some
background.

I hope, this helps,

Olaf

Re: Tomcat 8.5.51 fails

[Olaf Kock]

On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote:
> On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote:
>> Check in the file (tomcat_dir)/conf/server.xml, the Connector :
>>
>>      
>
> The setting is the same as mine.
>
> I have use server.xml used in 8.5.50. In case of 8.5.50, I have no
> problem.
>
> Please notice, I have been using Tomcat for 5 years with updates.
> Why this time?


Because this time, security relevant defaults changed: See these recent
commits on the git mirror:

https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262

https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262




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

Re: Question on Apache Tomcat Patches

[Olaf Kock]

On 11.02.20 15:39, Walker, Mike (GE Aviation, US) wrote:
> So apache only releases full versions not upgrades?  Does that mean if you 
> run the version 7.99 it will create a new folder under Apache Software 
> Foundation folder for 7.99 files? Since this would imply a change to the path 
> for Tomcat would registry or other tomcat config files need to be modified 
> for the new path? I assume all deployed .war files would need to be 
> re-deployed in the new version also?
>
Simple:

The directory within the zip file will carry the number. Nothing forces
you to continue to use that version numbered directory in your
installation. You're free to move its contents around, rename the
directory etc.

I hope that helps,

Olaf


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

Re: RewriteValve does not work on HTTPS

[Olaf Kock]

On 04.02.20 20:31, Hua Zhang wrote:
> Best tomcat team,
>
> Hereby I have a question about an issue I found by using RewriteValve
> on tomcat 9.30
>
> The rewrite.config is very simple:
>
> /RewriteCond %{HTTP_HOST} =youkoop.com 
> RewriteRule ^.*$ https://www.youkoop.com [R=301,L]
> /
>
> All I want is just redirect a naked root domain to a www domain with
> HTTPS.
>
> The redirection works on HTTP but not HTTPS.
>
> http://youkoop.com => https://www.youkoop.com *works*
>
Note: Images don't get through in this mailing list. I can imagine what
"works" means, but for your next example: Please elaborate what "does
not work" means.
>
> *https*://youkoop.com  =>
> https://www.youkoop.com *does not work*

First thing to test: Does https://youkoop.com work without the redirect,
then with the "wrong" host name? Otherwise it might be as simple as a
misconfigured TLS host that's never invoked because of a certificate
mismatch.

Olaf

Re: Dates on Linux vs. Windows - Resolved

[Olaf Kock]

On 08.01.20 06:05, Jerry Malcolm wrote:
> Just to summarize for anybody who comes along with a similar
> problem I original set the timezone of mySQL RDS instance to
> Central time when I created it months back (unchangable after it's
> set).  I set my Linux timezone to Central as well in order to make my
> log files have entries with the correct timestamps.  But as I
> described earlier, changing the OS timezone made the JVM also go to
> Central as well.  But the JVM apparently assumed the database was in
> GMT so it subtracted 6 more hours off the already-central time from
> the db.  I guess the real error was not initially leaving the MySQL
> RDS in GMT.  But since that's not changeable without recreating a
> whole new RDS instance, the next option is what I did with the jvm.  
> Makes total sense, right???  :-)


That's why my personal general recommendation is to run all server code
and OS, and especially all stored data, in UTC only. Optionally, for
selected output (e.g. website display) have the application explicitly
convert to a timezone, dependent on the current user (see Christopher's
excellent answer). It's work, but it's what needs to be done. There is
no "it just works" when handling time without being explicit -
especially in the web / server world, where people access from different
timezones. Desktop applications can be more relaxed (but shouldn't).

Granted, it's easier for me with UTC being one or two hours off during
the year, but the advantage is: UTC is "forward only" - there's no
daylight saving back and forth, no need to interpret anything, just the
plain timestamp. On the technical side (logs) that's what I want, even
if it requires a bit of mental math.

I'm not always remembering to set all of this right away, but it's the
first thing I retroactively do once I run into those problems.

Olaf


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

Re: Tomcat 9 does not allow to read file in /tmp folder with 777 permission?

[Olaf Kock]

On 04.01.20 15:35, bphamhuu wrote:
> Hello,
>
> I have a java web application by Tomcat 9 servlet container which tries to
> read a file in /tmp folder with 777 permission on Ubuntu 18.04
>
> ls -ltr /tmp/test.txt
> -rwxrwxrwx 1 vagrant vagrant 10 Jan  3 17:03 /tmp/test.txt
>
> The java code is:
>
> try {
> result = FileUtils.readFileToString(new File("/tmp/test.txt"));
> } catch (IOException ex) {
> log.info("# Cannot read file. Reason: " + ex.getMessage());
> }
>
> But it always show the error
>
> # Cannot read file. Reason: File '/tmp/test.txt' does not exist


You're running tomcat on Ubuntu, I'm assuming you use the version from
the Debian repositories, not one that you downloaded from tomcat.apache.org.

Debian's tomcat is sandboxed. Read /usr/share/doc/tomcat9/README.Debian
(or an online version at
https://salsa.debian.org/java-team/tomcat9/blob/master/debian/README.Debian)
for more information (search for "sandboxed" to find the proper place)

Credits: I keep this under my belt since Emmanuel Bourg answered a
similar question on this list a while back.

And don't forget to reset the 777 permissions.

Olaf


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

Re: HSTS not apply to some request URI path on tomcat 8.5.9 Centos 7

[Olaf Kock]

On 26.12.19 11:22, Pattavee Sanchol wrote:
> Dear support team
>
> I config tomcat server to enabled HSTS some request URI path not
> response with Secure heading
>
> ...
>
>
> I some request URI such as http://192.168.1.1/%20 is not response with
> security hedering
>
>
> this is working
>
>
> image.png
> this not working
> image.png
>
Note: Images are stripped from the list, but I hope that I get the
problem: You're trying to deliver the HSTS header for some, but not all
of the requests coming in(?) (Otherwise, please correct)

I believe that this is chasing a ghost: It's a lot of work to make it
happen, but doesn't have any meaningful advantage: If *any* request
states that the server *only* wants to see HTTPS traffic, it doesn't
matter if *more* requests also state the same: The server will need to
provide proper answers to any HTTPS connection. You're basically asking
everybody who ever saw the HSTS header during the last 31536000 seconds
(your configuration) to rewrite a http-URL to a https-URL.

Thus, I'd recommend to just not worry about any specific conditions to
apply for those headers. Just send them - they don't harm, or make any
difference. Or give us some more specific reasons that I might have missed.

Olaf

Re: Exception while starting tomcat version 9.0.29

[Olaf Kock]

On 20.12.19 13:28, Kushagra Bindal wrote:
> Hi,
>
> We are working on upgrading our tomcat version from 8.5.24 to 9.0.29. In
> this process, while starting one of our services we found that while
> starting catalina.out is having some exception.
>
> Note: This exception we are getting before start of tomcat.
>
> 20-Dec-2019 09:52:09.144 WARNING [main]
> org.apache.tomcat.jdbc.pool.DataSourceFactory.getObjectInstance
> org.apache.catalina.UserDatabase is not a valid class name/type for this
> JNDI factory.
> 20-Dec-2019 09:52:09.145 SEVERE [main]
> org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans
> Unexpected error creating MBeans
> java.lang.NullPointerException
> at
> org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:129)
> at
> org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:71)
> ...
> 20-Dec-2019 09:52:09.148 SEVERE [main]
> org.apache.catalina.realm.CombinedRealm.startInternal Failed to start
> [org.apache.catalina.realm.UserDatabaseRealm] realm
> org.apache.catalina.LifecycleException: No UserDatabase component
> found under key [UserDatabase]
> ...
>
> Below is the server.xml file details.
>
>
> --
>
> ...
>type="org.apache.catalina.UserDatabase"
>   description="User database that can be updated and saved"
>   factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
>  
> url="jdbc:postgresql://<>:5444/<>?targetServerType=mastercurrentSchema=common"
>   pathname="conf/tomcat-users.xml" />
>   
> ...
>
>
Phew, that server.xml would have been so much more readable if you'd
removed all the commented xml before posting.

Anyway, I've shortened the log and server.xml in my quote to what I
assume is the cause for the error message. The stock server.xml contains
a MemoryUserDatabaseFactory, while it looks like your declaration is for
a generic JDBC connection.

    

>From the top of my head I can't give you the right class name to use,
but knowing this cause might put you on the right track.

Olaf




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

OT Developer Praise - was Re: EOL for Tomcat 9.X ?

[Olaf Kock]

On 22.10.19 17:56, Michael Osipov wrote:
> Am 2019-10-22 um 16:43 schrieb Christopher Schultz:
>>
>> So Tomcat 9 is looking good for aother 10 years at this point.
>
> ...and this is the reason why I appreciate the Tomcat devs' work. I
> can simply stick to a version and virtually forget about compat issues.
>
For me the reason is that I've never worried which version to pick:
Always picked the latest available and never ran into issues where the
newer version was imposing problems when used instead of the earlier
version. And that includes major version upgrades

Big Thank You!

Olaf


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

Re: Adding the manager app to an existing installation

[Olaf Kock]

On 18.10.19 17:21, Tom Povey wrote:
> Hi,
>
> I’ve been asked to help with an existing Tomcat install which is supporting a 
> live website. When it was installed, it did not have the manager app added. 
> We want to use the manager app now.
>
> I have copied the manager folder from another Tomcat install (same version 
> which is 5.5.36) and updated tomcat-users in the /conf directory but I can’t 
> login to the manager gui. I give the username and password for the 
> manager-gui role but it just comes back and redisplays the login prompt.

tomcat-users.xml, as far as I remember, requires restart of the server
to be taken into account. You didn't mention that you did this. Plus,
you only said "updated": By default there's no account in there, I'm
assuming that you "updated" correctly. You might want to post it here
(bar the actual password).

Plus, your version is 1 day shy of being 7 years old, with the
end-of-life being even a few more days longer in the past (30 Sep 2012)
http://tomcat.apache.org/tomcat-55-eol.html

It's about time to move on...

Olaf


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

Re: EOL for Tomcat 9.X ?

[Olaf Kock]

On 18.10.19 17:25, Robert Hicks wrote:
> Management is asking me if there is an end of life for Tomcat 9 reported. I
> don't see anything on the tomcat web site.

Mark recently answered this to a the same question for Tomcat 8.5:


There is no official date.

The Tomcat project maintains 3 major versions in parallel. Currently
these are:
- 9.0.x
- 8.5.x
- 7.0.x

We always provide at least 12 months notice of EOL.

Major releases are aligned with releases of the Servlet specification.
The current timetable for the next Servlet spec is TBD.

We haven't even announced EOL for 7.0.x yet so you have:
- x years until Tomcat 10 / Servlet 4.next is released
- 1 year for 7.0.x EOL
- y years until Tomcat 11 / Servlet 4.next+1 is released
- 1 year for 8.5.x EOL

Taking low estimates for x and y of 1 and 2 respectively, you have at
least 5 years before 8.5.x is EOL.

Take that figure as an "Engineering Estimate". Also known as a "wild guess".


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

Re: Password encryption in Tomcat 8.5.35

[Olaf Kock]

On 16.09.19 08:24, Olaf Kock wrote:
> If someone has access to the old Wiki's information, it'd be a great
> page to restore.
>
"Do you really want to send this mail?" - "Of course" - "so be it" - m(
Facepalm:

It takes the steps above to think of a way of accessing the old content:
Here it is, courtesy of the wayback machine:
https://web.archive.org/web/20180114041103/https://wiki.apache.org/tomcat/FAQ/Password

Cheers,

Olaf


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

Re: Password encryption in Tomcat 8.5.35

[Olaf Kock]

On 16.09.19 06:05, Mohan T wrote:
> Hi,
>
> We are using tomcat 8.5.35, on Red Hat Enterprise Linux Server release 7.4.
>
> Is it possible to encrypt or mask passwords that is being used in the 
> datasource for connecting to database. I am mentioning the credentials in 
> server.xml

There used to be a dedicated FAQ entry at
http://wiki.apache.org/tomcat/FAQ/Password, but the link is broken.

Currently, the only leftover that I can find is
https://cwiki.apache.org/confluence/display/TOMCAT/Security#, which says

> Why are passwords in plain text?
> We have a page dedicated to this topic. FAQ/Password

...but links to the same page this information is on, so the information
seems to be lost.

If someone has access to the old Wiki's information, it'd be a great
page to restore.

Until then, an option to implement this snake oil is mentioned here:
https://stackoverflow.com/questions/129160

Cheers,

Olaf


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

Re: [ANN] Apache Tomcat 9.0.24 available

[Olaf Kock]

On 20.08.19 21:43, Christopher Schultz wrote:
> Olaf,
>
> On 8/19/19 09:55, Olaf Kock wrote:
>
> > If nothing changed since I looked at it last time, ubuntu didn't
> > update to a new version, but at most backported some fixes while
> > staying on roughly the same version. At least typically.
>
> > I'm looking at the currently available information on the
> > "tomcat9" package in ubuntu 18.04, and I'm seeing version info
> > like "9.0.16-3~18.04.1".
>
> > If you want to be on the latest and greatest tomcat version, you
> > should rather maintain it for yourself. If you want the
> > distribution to maintain your tomcat, you're likely not on the very
> > latest version.
>
> While these two points are entirely accurate, we have two members of
> the Tomcat community who are either package maintainers or who can
> influence those maintainers.
>
> We have Coty from RedHat who rolls some releases for RHEL/CentOS and
> is pretty much up-to-date with all the releases. IIRC, the yum repo
> tracks the "actual" version numbers from ASF while some other package
> maintainers tend to back-port patches...
>
> ... such as Debian (apt), where Emmanuel is (?) the package manager
>
Hi Chris,

Thank you for the reminder - and thank you to the package maintainers
for keeping the versions up to date - one way or another. The quoted
Ubuntu version led me (repeatedly) down the track of assuming that this
is how it's (still) everywhere, but I'm happy to be corrected.

Old habits die slowly, and once you (well, me) have firmly established a
habit, it's hard to revert. I'll work on it - after all, I like the
perspective of not needing to think about most of my installation myself.

Promising to go more pro-distro in the future.

Olaf



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

Re: Tomcat 9 Getting Started

[Olaf Kock]

On 20.08.19 12:28, Enosh Mogire wrote:
> When I execute ls -la /opt/tomcat this is what I get
>
> enosh@hp:~$ ls -la /opt/tomcat
> total 36
> drwxr-xr-x 3 tomcat tomcat 4096 Aug 20 08:55 .
> drwxr-xr-x 7 root   root   4096 Aug 19 10:53 ..
> drwxr-xr-x 9 tomcat tomcat 4096 Aug 14 10:31 apache-tomcat-9.0.22
> -rw-r--r-- 1 tomcat tomcat  220 Apr  4  2018 .bash_logout
> -rw-r--r-- 1 tomcat tomcat 3771 Apr  4  2018 .bashrc
> lrwxrwxrwx 1 tomcat tomcat   32 Aug 13 08:50 latest ->
> /opt/tomcat/apache-tomcat-9.0.14

so indeed you've extracted the archive into a subdirectory: You'll find
/opt/tomcat/apache-tomcat-9.0.22/conf if you're looking for it. You can
move all of the content of the apache-tomcat-9.0.22 folder up one level,
or adjust your chmod command or the cd that you executed before. You'll
just find the content that you expect one folder further down.

Seeing the link in your directory, you should correct it, e.g.

rm /opt/tomcat/latest
ln -s /opt/tomcat/apache-tomcat-9.0.22 /opt/tomcat/latest
cd /opt/tomcat/latest

and continue from there. That directory will have the conf and all of
the other directories you expect.

Olaf


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

Re: Tomcat 9 Getting Started

[Olaf Kock]

On 20.08.19 10:14, Enosh Mogire wrote:
> So after installing and extracting the Tomcat archive file, I needed to set
> the required permissions on the files through the commands bellow
>
> enosh@hp:~$ sudo chgrp -R tomcat /opt/tomcat
> enosh@hp:~$ cd /opt/tomcat/
> enosh@hp:/opt/tomcat$ sudo chmod -R g+r conf
>
> The last command returns an error (chmod: cannot access 'conf': No such
> file or directory) and it is where I am stuck. Please advise accordingly,
> thank you.

What do you see when you execute

ls -la /opt/tomcat

?

It might be that you're just extracting into yet another subdirectory,
e.g. /opt/tomcat/apache-tomcat-9.0.24/

Olaf



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

Re: Tomcat 9 Getting Started

[Olaf Kock]

On 20.08.19 09:44, Enosh Mogire wrote:
> I trust that your week is well and that this email finds you well. My name
> is Enosh and I am a newbie to the system. I recently started a personal
> learning project with DHIS2 and I needed to install the Apache servlet but
> I keep on getting this error(attached screenshot). Please advise
> accordingly on how to solve this issue. Thank you.

Welcome,

please note that this list is read around the world, and people (like
me) might not know acronyms like DHIS2.

To help you, we'll need more details: "the Apache servlet" is not quite
descriptive, and this mailing list strips attachments - as the error
message most likely contains text: Please post the textual error message
here, along with log file contents and steps to reproduce - ideally with
everything required to reproduce the issue you're facing.

Cheers,

Olaf




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

Re: [ANN] Apache Tomcat 9.0.24 available

[Olaf Kock]

On 19.08.19 15:41, John Dale wrote:
> Does this get included in the apt framework for ubuntu automatically?
>
> John
>
>
> On 8/19/19, Mark Thomas  wrote:
>> The Apache Tomcat team announces the immediate availability of Apache
>> Tomcat 9.0.24.

If nothing changed since I looked at it last time, ubuntu didn't update
to a new version, but at most backported some fixes while staying on
roughly the same version. At least typically.

I'm looking at the currently available information on the "tomcat9"
package in ubuntu 18.04, and I'm seeing version info like
"9.0.16-3~18.04.1".

If you want to be on the latest and greatest tomcat version, you should
rather maintain it for yourself. If you want the distribution to
maintain your tomcat, you're likely not on the very latest version.

Olaf




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

Re: AW: Updating tomcat 7 to 9 got problems

[Olaf Kock]

Christopher,

On 07.06.19 16:41, Christopher Schultz wrote:
> Olaf,
>
> On 6/7/19 10:04, Olaf Kock wrote:
> > On 07.06.19 15:30, Support  wrote:
> >> Hi,
> >>
> >> it is not working my folder structure is usr/share/tomcat
>
> > [snip]
>
> > Further, if you've used your distro's packaged Tomcat installation,
> > the best way to get support for it might be through your distro's
> > forums. Tomcat installations from Linux package managers tend to be
> > exploded into a lot of directories that are unexpected in case one
> > is only used to the standard downloaded version and its directory
> > structure.
>
> Keep in mind that RedHat's package maintainer for Tomcat is a member
> of the Tomcat PMC, so asking here is actually likely to yield some
> good results.

That's good news (to me). Must have missed by my attention while reading
along

(Also sorry for misattributing the first quote to Bernd Schatz, I've
been overeagerly removing lines, correcting now)

Re-reading the original post, this was originating at a managed package,
but ended with the updated package installed from the regular distribution.

My main suggestion for this would be:

* Uninstall the package-manager version (7) to make sure not to have any
conflicts.
* Make sure that the permissions are right on the directories and
documented scripts
* and still: Provide more information on *how* it *doesn't* work.

Cheers,

Olaf


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

Re: AW: Updating tomcat 7 to 9 got problems

[Olaf Kock]

On 07.06.19 15:30, bernd.sch...@daimler.com wrote:
> Hi,
>
> it is not working my folder structure is usr/share/tomcat

On top of Bernd's questions: Please provide as much detail as you can.
"It is not working" isn't really helpful for coming up with additional
suggestions. How exactly is it not working? Do you see error messages
(as Bernd asked for the log), does it not start at all? Are the
applications not running, but Tomcat does?

We need to know what you observe, not what you want to observe (e.g.
everything working correctly), only then will we have the opportunity to
provide some help.

Also, note that there was no Tomcat 7.2. There was a 7.0.2 beta (in
2010), so I'm not even really sure where you come from.

Further, if you've used your distro's packaged Tomcat installation, the
best way to get support for it might be through your distro's forums.
Tomcat installations from Linux package managers tend to be exploded
into a lot of directories that are unexpected in case one is only used
to the standard downloaded version and its directory structure.

Best,

Olaf


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

Re: Running sudo from a servlet

[Olaf Kock]

On 22.05.19 18:31, Christopher Schultz wrote:
> Claude,
>
> On 5/21/19 14:20, Claude Brisson wrote:
> > (responding to myself)
>
> > The culprit is the option
>
> > NoNewPrivileges=true
>
> > in the file
> > /etc/systemd/system/multi-user.target.wants/tomcat8.service
>
> > When changed to false, one must also call 'systemctl daemon-reload'
> > and after a tomcat restart, the problem is solved.
>
> I'd seriously consider whether or not you want to actually do this.
>
> It might be better to write a tiny daemon which has elevated
> privileges to perform whatever operation you want and have your web
> application ping it to do some work, rather than making the whole
> Tomcat process able to elevate its privileges.


Seconding this. Running a web-facing daemon with the option of executing
system commands as root is a recipe for disaster. Don't even think of
going there.

There might be rare occasions where there's a good reason for this
architecture, but the keyword here is "rare". It'll need a *very* good
reason. And "how do I enable sudo?" isn't one.

You have been warned, and so has everyone else finding this thread in
future with the intend of making the same architectural decision.

On stackoverflow, this is called the x-y problem
(https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem).
I'd recommend reading a few of those answers and reconsider the
question, to come up with the X instead of the Y.


Olaf




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

Re: Latest Best Practices for Tomcat Tuning

[Olaf Kock]

On 22.05.19 16:36, Louis Zipes wrote:
> Hi Experts,
> I know that if you Google 'Tomcat Tuning' you will get some hits  (ex. 
> https://www.mulesoft.com/tcat/tomcat-performance) but  I would like to see if 
> we can have a discussion of best practices for Tomcat tuning from the group 
> of experts here.  Is there an updated top 10 list or something similar or 
> what people have found have greatly helped their performance.   Note that I 
> have looked through the archives but most of the hits I get date back 10 
> years.
>
> My personal situation is I'm running Tomcat 8.5.x on Windows with a third 
> party application.  Since it is a third party application I feel I can't open 
> up the actual coding itself so I'm left to tune around the margins (ex. 
> Parameters in service.bat, maybe try to switch our odbc.jar to a different 
> one, etc) but maybe I'm wrong.
>
> Basically, is there an updated list of best practices that we can discuss 
> here or is this not the appropriate venue.  I'm looking for a more generic 
> conversation that would benefit all users on this forum and if it helps me 
> personally then of course that is great!
>
> Or is the answer always get the stack dumps and analyze from there.   : )

IMHO the generic answer for tuning problems is always:

(1) Identify the #1 bottleneck
(2) Fix it
(3) Now bottleneck #2 has gotten a promotion: If you still feel the need
to continue tuning, continue at (1)

The bottleneck might be:

# CPU (in which case you might be out of luck with a 3rd party application)
# Memory
# I/O
# Database (a specific case of I/O)
# Network throughput, latency

or anything else, e.g. other backend systems.

Sorry, this is pragmatic, but might not be too helpful. It's the long
form of the consultant's standard answer "it depends".

Olaf


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

Re: Problem in ApacheTomcat - 8.0. 37: Files are not displaying in sorted order.

[Olaf Kock]

On 24.04.19 14:52, Rahul Ranjan wrote:
> Hi Team,
>
> I am facing an issue which is related to ApacheTomcat-8.0.37. I wrote
> a code to display the files/folder in browser. By default it should
> display in alphabetically sorted order. But it's not showing.
> I have migrated my code from Unix to Linux. In Unix system my code was
> working fine. Can you please tell me what could be the problem? 
>
> I am attaching you a screenshot for reference. I will appreciate any
> help.

Note: Attachments are stripped by the mailing list software

As you're asking for code that's not related to tomcat (just happens to
run on it), I'd expect a place like stackoverflow.com to be a better
place for getting debugging help. But either way, here or there: If you
expect anyone to help you debugging your code, you'll need to provide
it. I'm assuming that you didn't attach your code as an image (because
why would you turn perfectly valid characters into a pixellated image?).

Olaf



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

Re: Could not find datasource: java:/comp/env/jdbc/TOPSDB when start Tomcat 9.0.13

[Olaf Kock]

On 25.03.19 03:41, Hua, Gary - Saint Louis, MO - Contractor wrote:
> Hi experts:
> 
> After I deployed my application TOPS to Tomcat server(9.0.13) 
> on Linux box,  and started the server,  I got the following error:
> 
> 
> 1537 [main] FATAL connection.DatasourceConnectionProvider  - Could not find 
> datasource: java:/comp/env/jdbc/TOPSDB
> java.lang.ClassCastException: org.apache.tomcat.dbcp.dbcp2.BasicDataSource 
> cannot be cast to javax.sql.DataSource
> at 
> org.hibernate.connection.DatasourceConnectionProvider.configure(DatasourceConnectionProvider.java>
> ...
> 
> I have tried to put different version of tomcat-dbcp.jar   like 
> tomcat-dbcp-7.0.47.jar/ tomcat-dbcp-8.0.23.jar/ tomcat-dbcp-9.0.13.jar  into 
> /opt/TomCat/apache-tomcat-9.0.13/lib, but not the same error occurred.

One way or another, the last sentence most likely is the most relevant
information, and key to solving your problem: Whenever a Java class
can't be typecast to its legitimate superclass or interface, this is a
clear sign that the superclass or interface can be found twice on the
classpath.

The error message only contains the class name, not the classloader, so
the root cause is effectively hidden. Make sure that
javax.sql.DataSource is nowhere to be found in your app's WEB-INF/lib,
and only once in tomcat's lib directory.

Olaf

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

Re: Default Max response size in Tomcat

[Olaf Kock]

On 20.03.19 12:08, Saurav Sarkar wrote:
> Just to add the stack trace.
> 
> I am getting ClientAbortException "Connection reset by peer" when i am
> trying to write to the response stream
> 
> 2019-03-20T10:32:28.501+ [APP/PROC/WEB/0] ERR
> org.apache.catalina.connector.ClientAbortException: java.io.IOException:
> Connection reset by peer
> 2019-03-20T10:32:28.502+ [APP/PROC/WEB/0] ERR at
> org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:364)
...

> 
> On Wed, Mar 20, 2019 at 3:51 PM Saurav Sarkar 
> wrote:
> 
>> Hi All
>>
>> I have a very basic test application which serves bytes from memory and
>> gives it back to the client.
>>
>> Whenever i try to send the request for byte size which is of over 2 GB i
>> get a connection reset error in my server code and a 502 error in my chrome
>> console. Below 2 GB it is working fine.
>>
>> In my client side i execute java script which i execute from the browser.
>> This basically executes an XMLHTTPRequest , gets the response (stores in
>> browser memory) and asks for a save.
>>
>> I would like to know if there Is there max response size default value
>> which is set in default tomcat configuration. ? or any other hints which
>> you can provide in my use.
>>
>>
>> Thanks and Regards,
>>
>> Saurav
>>
>> Below is the servlet or server side code
>>
>>
>>
>> response.setContentLength((int)length);
>>
>>   }
>>
>>   else
>>
>>   {
>>
>> response.addHeader("Content-Length", Long.toString(length));
>>
>>   }

You don't include the initial condition in your code, but I'm assuming
that the first line is hit: response.setContentLength((int)length);

int in Java is defined to be 32 bit, and always signed. That means that
any value larger than 2^31 or Integer.MAX_VALUE can't be expressed in
int as a positive number. In fact, anything between 2^31 and 2^32 will
be interpreted as a negative number, so you're effectively setting the
content length to be negative.

Note that there's also a setContentLengthLong method
https://docs.oracle.com/javaee/7/api/javax/servlet/ServletResponse.html#setContentLengthLong-long-



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

Re: What is `tomcat7/common/` for?

[Olaf Kock]

On 13.03.19 15:01, Joel Griffith wrote:

> I installed it using Ubuntu's apt-get install, so installing it again
> won't do anything different. Is there a documentation page
> that lists what files are supposed to be there?
> That would help. I can't seem to find one. 

If you installed through apt-get, you're getting some packaged version
that is distributed all over the file system. You can use "apt-file list
tomcat8" to see what's contained and where it will appear.

This is not comparable with the standard tomcat distribution.

The lib directory might be on /usr/share/tomcat8/lib - in my quick check
it wasn't empty.

Olaf


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

Re: What is `tomcat7/common/` for?

[Olaf Kock]

On 13.03.19 14:22, Joel Griffith wrote:
> > I think it was accomplishing something; tomcat7/common/lib/ contained a
> > bunch of .jar files that looked like standard Tomcat installation files
> > (tomcat7-websocket.jar, tomcat-catalina-7.0.68.jar, etc.).  If I switch
> > directories in the deployment script to tomcat8/lib/, which is
> empty, javac
> > complains that it can't find the files to compile.  It looks like
> I'm going
> > to need to go through /usr/share/java/ and find tomcat8 versions of
> all of
> > the .jar files in tomcat7/common/lib/ and symlink those to tomcat8/lib/,
> > unless someone knows a better way.

If your tomcat/lib folder is empty, I suggest to download the
distribution again. It has quite a few files in there. If yours doesn't,
you can either start over, or figure out where they are instead (e.g. if
you're using your Linux distribution's packaged tomcat)

Olaf


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

Re: I'm not able to get acces server status Apache Tomcat/9.0.16

[Olaf Kock]

On 04.03.19 19:06, ITMex wrote:
> Hi everyone, I'm running Apache Tomcat/9.0.16 over CentOS 7 so far is
> okay, but I'm not able to get acces to "server status, Manager App and
> Host Manager" menus, even from localhost I got the following message:
>
>
> HTTP Status 404 – Not Found

Did you deploy the manager app? (check your tomcat's webapps directory)
Are you connecting directly to your Tomcat, or to a local reverse proxy
(e.g. Apache httpd or nginx)?

Also, you'd not "even" get access from localhost, but "only", according
to the standard configuration for the manager app, if it is deployed.


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

Re: Tomcat Apache 7.0.79 upgrade to Latest version

[Olaf Kock]

Hi Nitin,

John gave you a good primer, for almost all of the rest I'll point to
the fine documentation again. Look at a diff between your current
installation and the plain vanilla download of the tomcat version that
you're running.

What I want to comment on is this:

On 20.02.19 15:33, Nitin Kadam wrote:
> I need to know below details.
> 1 How to take a backup before the upgrade (Main files).

My standard recommendation to this is: Do not specifically back up your
production system, do not plan to "maybe" go back. Rather *take your
existing backup* and *restore* it to a new system. Perform a disaster
recovery, as if your production server failed hard and you can't recover
the data. This will make sure that you have a proper system running
until you switch over to the new system.

This way of working has the nice benefit that you'll prove that your
backup is worth its name. If you don't have a backup: You know what to do.

If you follow this advice, you don't need a specific backup before the
migration.

Of course, you'll need to make sure that the applications that you're
running on the new and restored server use their backend storage
properly - but as we don't have a clue what applications you're running
(and the tomcat list is a bad place to get support for random
applications anyway), this exercise is left for you.


In conclusion: Make sure that your existing backup is worth its name.
Then think further. Operate on a restored server, 100% separate of the
production server that continues to run.

And inspect your installation's diff, read the fine documentation

Olaf



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

Re: Tomcat Apache 7.0.79 upgrade to Latest version

[Olaf Kock]

On 20.02.19 14:47, Nitin Kadam wrote:
> Thanks John  for reply..
>
> is there any documentation walkthrough for this upgrade available?
> i am new to Tomcat and e to doing this 1st time, It will be great help if 
> anyone
> provide same.

There's plenty of documentation on https://tomcat.apache.com - start
there and come back here if you don't understand the documentation with
specific questions. We don't know what's configured in your system, thus
can't provide a solution tailored for you.

As John said in a different branch of this thread, upgrading is
typically easy. The less changes you've made to the default
configuration, the easier the migration will be.

Start with the documents I've linked earlier, If you don't understand
parts of it, try to find that section in the regular documentation. If
you still have problems understanding, ask the questions here.

For a "walkthrough" guide for your system, there are plenty of companies
available that provide consulting, as well as training to get you
started. But the documentation is actually quite good.

Olaf



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

Re: Tomcat Apache 7.0.79 upgrade to Latest version

[Olaf Kock]

On 20.02.19 13:57, Nitin Kadam wrote:
> Hello Team,
>
> Can you please guide how we can migrate seamlessly from Tomcat
> apache 7.0.79 to 7.0.92 or any latest version that 8.x or 9.x ( Windows
> 2012 R2 server)escr

7.0 to 8.0: https://tomcat.apache.org/migration-8.html

8.0 to 8.5: https://tomcat.apache.org/migration-85.html

8.x to 9.0: https://tomcat.apache.org/migration-9.html

> the current environment is configured with SSL certificate ( SSL 443) .jks
> store and needs to upgrade same due to security vulnerability detected by
> Qualys scanner.

The documents have TLS documentation chapters. If you run into specific
problems, describe them here.

Olaf


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

Re: Anyway to set more max ram to Tomcat 32bit?

[Olaf Kock]

On 04.01.19 02:46, ark...@tutanota.com wrote:
> Something wierd seems to be going on... I have an application on tomcat that 
> used to be on a physical windows server 2008 standard 32-bit which I p2v'd 
> with vmware converter over as a VM. I'm upgrading the server to windows 
> server 2008 r2 64bit and instead of doing an inplace, I'm just building 
> another one up and doing parallel side by side, and its a fresh VM from the 
> start, no p2v stuff

This has been well answered in your crosspost on stackoverflow
https://stackoverflow.com/questions/54032183/anyway-to-set-more-max-ram-to-tomcat-32bit-why-there-is-hard-wall-limit-at-1gb

Please note that crossposting without linking all posts to each other is
rather considered disrespectful to those who volunteer to help out the
community for free. People might not know that the question is already
answered in the other location and still invest more time into solving a
long solved problem. See
http://meta.stackexchange.com/questions/141823/why-is-cross-posting-wrong-on-an-external-site
for more reasoning

I've already commented with this suggestion on one of your previous
stackoverflow postings (https://stackoverflow.com/questions/53826860),
that seems to have been posted here as your Alter Ego "Bo", who
collected no good karma)



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