Re: Pausing all thread but one.

2020-10-29 Thread Christopher Schultz

Tullio,

On 10/29/20 04:42, Tullio Bettinazzi wrote:

OK tks for the X-Y explanation.
I need to reload a few caches and when theese caches are reloaded nobody 
can access them.

This is my problem.


Your caches must be thread-safe, otherwise you would have serious 
problems. (You might want to go check on that, now.)


The solution is simple: in your cache-reload thread, just loop through 
your caches, locking each one, emptying it, re-filling it, and then 
unlocking it. All will be well, and you don't have to pause any threads.


What will happen is any in-flight requests will simply pause waiting for 
you, which is exactly how they would have behaved if you had "paused" 
the threads and then let them go.


So the user's experience is the same, and your code is simpler and safer.

-chris


- Messaggio Originale -
Da: "Christopher Schultz" 
A: users@tomcat.apache.org
Inviato: 28/10/2020 20:13
Oggetto: Re: Pausing all thread but one.

Tullio,

On 10/28/20 06:27, Tullio Bettinazzi wrote:
 > I need to perform some maintenance operations pausing all user thread
 > for a small but meaningfull time (say 30 secs).

Ugh. Why? What do you need to do that can't be handled with "proper"
synchronization?

 > Is it possible to pause all user threads ?

Maybe. It's very dangerous, though.

https://urlsand.esvalabs.com/?u=https%3A%2F%2Fdocs.oracle.com%2Fjavase%2F8%2Fdocs%2Ftechnotes%2Fguides%2Fconcurrency%2FthreadPrimitiveDeprecation.html=af66902b=887af54c=y=n

 > How ?

I'll leave that as an exercise for the reader at this point.

 > Any suggestion ?

Yes: think if a better way to do what you are trying to do.

This sounds like an X-Y problem[1]. You are trying to do X and you have
decided that you need to do Y in order to accomplish X. So you are
asking about Y.

Why not just ask about X instead?

-chris

[1] 
https://urlsand.esvalabs.com/?u=http%3A%2F%2Fxyproblem.info%2F=af66902b=9b6e4fa6=y=n


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


--
This message has been checked by Libraesva ESG and is found to be clean.
Follow this link to mark it as spam:
https://gw1.idrnet.it/action/B465842741.A19C7/learn-spam


-
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: NGINX + tomcat 8.0.35 (110: Connection timed out)

2020-10-29 Thread Christopher Schultz

Ayub,

On 10/28/20 23:28, Ayub Khan wrote:

During high load of 16k requests per minute, we notice below error in log.

  [error] 2437#2437: *13335389 upstream timed out (110: Connection timed
out) while reading response header from upstream,  server: jahez.net,
request: "GET /serviceContext/ServiceName?callback= HTTP/1.1", upstream: "
http://127.0.0.1:8080/serviceContext/ServiceName

Below is the flow of requests:

cloudflare-->AWS ALB--> NGINX--> Tomcat-->Elastic-search


I'm curious about why you are using all of cloudflare and ALB and nginx. 
Seems like any one of those could provide what you are getting from all 
3 of them.



In NGINX we have the below config

location /serviceContext/ServiceName{

 proxy_pass  http://localhost:8080/serviceContext/ServiceName;
proxy_http_version  1.1;
 proxy_set_headerConnection  $connection_upgrade;
 proxy_set_headerUpgrade $http_upgrade;
 proxy_set_headerHost  $host;
 proxy_set_headerX-Real-IP  $remote_addr;
 proxy_set_headerX-Forwarded-For $proxy_add_x_forwarded_for;


 proxy_buffers 16 16k;
 proxy_buffer_size 32k;
}


What is the maximum number of simultaneous requests that one nginx 
instance will accept? What is the maximum number of simultaneous proxied 
requests one nginx instance will make to a back-end Tomcat node? How 
many nginx nodes do you have? How many Tomcat nodes?



below is tomcat connector config




50,000 threads is a LOT of threads.


We monitor the open file using *watch "sudo ls /proc/`cat
/var/run/tomcat8.pid`/fd/ | wc -l" *the number of tomcat open files keeps
increasing slowing the responses. the only option to recover from this is
to restart tomcat.


So this looks like Linux (/proc filesystem). Linux kernels have a 16-bit 
pid space which means a theoretical max pid of 65535. In practice, the 
max pid is actually to be found here:


$ cat /proc/sys/kernel/pid_max
32768

(on my Debian Linux system, 4.9.0-era kernel)

Each thread takes a pid. 50k threads means more than the maximum allowed 
on the OS. So you will eventually hit some kind of serious problem with 
that many threads.


How many fds do you get in the process before Tomcat grinds to a halt? 
What does the CPU usage look like? The process I/O? Disk usage? What 
does a thread dump look like (if you have the disk space to dump it!)?


Why do you need that many threads?

-chris

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



Re: mod_jk "Can not determine the proper size for pid_t" on macOS 10.15.7

2020-10-29 Thread Christopher Schultz

Brian,

On 10/28/20 21:24, Paquin, Brian wrote:

Chris,


On Oct 27, 2020, at 12:31 PM, Christopher Schultz 
 wrote:

Brian

On 10/26/20 15:33, Paquin, Brian wrote:

I’m trying to build httpd and mod_jk for the first time on a macOS 10.15.7 box. 
XCode 12.1 is installed and I was able to compile OpenSSL 1.1.1g.
I got an error “Can not determine the proper size for pid_t” when compiling 
httpd (v2.4.46) with included apr (v1.7.0).
This issue 
https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbz.apache.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D64753data=04%7C01%7Cbrian.paquin%40yale.edu%7C4a009b9f4c19439afc4708d87a95d92e%7Cdd8cbebb21394df8b4114e3e87abeb5c%7C0%7C0%7C637394131299938700%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=WdzfXIIBvFQzON0aA2Q3EHqNyHK2bFqXpGYm2aEyi1A%3Dreserved=0
 provided a diff patch that adds “#include ” in a number of locations.
Applying this patch allowed me to compile httpd!


Weird. pid_it is defined in  and yet the patch adds  to 
fix it.

I don't have access to my Catalina machine right now, but my clang-based Mojave machine still 
says to use  when you "man getpid":

"
GETPID(2)   BSD System Calls Manual

NAME
 getpid, getppid -- get parent or calling process identification

SYNOPSIS
 #include 

 pid_t
 getpid(void);
"

$ cc --version
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin


Now I am trying to compile mod_jk (v1.2.48), and I get the same error.
Does someone have a patch file I can use to get around this issue?
$ ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' 
--with-apxs=/usr/local/apache2/bin/apxs

$ make

Making all in common
/usr/local/apache-2.4.46/build/libtool --silent --mode=compile gcc -I. 
-I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -arch x86_64  
-DHAVE_APR  -I/usr/local/apache-2.4.46/include 
-I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -DDARWIN 
-DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -c jk_ajp12_worker.c -o 
jk_ajp12_worker.lo
In file included from jk_ajp12_worker.c:25:
In file included from ./jk_ajp12_worker.h:26:
In file included from ./jk_logger.h:26:
In file included from ./jk_global.h:340:
./jk_types.h:56:2: error: Can not determine the proper size for pid_t
#error Can not determine the proper size for pid_t
  ^
./jk_types.h:62:2: error: Can not determine the proper size for pthread_t
#error Can not determine the proper size for pthread_t
  ^
2 errors generated.
make[1]: *** [jk_ajp12_worker.lo] Error 1
make: *** [all-recursive] Error 1
$


I'm sorry, I have no idea how configure does its magic. The auto-generated 
jk_types.h looks like a hand-wavy template to me.

You can probably hack it briefly by running "configure" (which you already did) 
and then hand-editing include/jk_types.h (ignoring the warning NOT to hand-edit it!) and 
manually adding:

#include 

to the top.


I added the line above to 
./tomcat-connectors-1.2.48-src/native/common/jk_types.h and tried running make 
again but got the same error. I do not have an include directory in 
./tomcat-connectors-1.2.48-src/native/.

Any other suggestions?


Sorry, native/common/jk_types.h was the file I meant.

Can you just post the whole content of that file? I'm guessing that you 
have something like:


typedef jk_pid_t @pid_t@ ;

leftover from 'configure' not finding the right definition. We may have 
to adjust that line, too.


-chris

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



Re: Our webapp is running very slowly on one particular customer box

2020-10-29 Thread Christopher Schultz

James,

On 10/28/20 16:40, James H. H. Lampert wrote:

First, thanks once again, Mr. Schultz, for getting back to me.

I noticed something rather promising: it seems that maxThreads for the 
Port 443 connector were set at 150 for System "A" (problem box), but 400 
for System "J" (box that's quite happy).


I've restarted Tomcat with the maxThreads bumped up to 400, and so far, 
it seems much happier than it was. That could have been the problem all 
along.


Hmm. That doesn't sound very satisfying to me, honestly. Allowing *more* 
load uses *less* GC and/or fewer page-faults? Seems fishy.


My colleagues and I also observed that yesterday, when we did *not* shut 
down and restart, the slowdown and the nearly-full "tenured-SOA" portion 
of the heap eventually resolved itself, which suggests that it wasn't a 
memory leak in any even remotely conventional sense of the term.


That's a Good Thing, but also not very satisfying when you just want it 
to stop sucking and let your users get work done :)


The page-faulting is a virtual memory term: on an AS/400, the entire 
combined total of main storage and disk is addressable (the concept is 
called "Single-Level Store"), and virtual storage paging is built into 
the OS at a very low level; a "page fault" is when a process finds tries 
to access something that's been paged out to disk.


Yes, this is the common definition of a page-fault, not just an AS/400 
thing. Good to know for sure that AS/400 doesn't re-define that term, 
though :)


How long has the process on System J been running? How about System A 
(before you restarted the JVM)?


As to the private memory pool, it's not that the subsystem is restricted 
to its private pool; rather, everything else is kept *out* of that 
private pool. It still has full access to the "Machine" and "Base" 
shared pools.



Okay, so it's like a guaranteed-minimum memory space?

-chris

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



Re: Enable Logging to Print Max Threads

2020-10-28 Thread Christopher Schultz

Aquib,

On 10/28/20 08:31, Aquib Khan wrote:

Hi,

We are using Tomcat Version : 8.5.53.

OS Name:    Linux

OS Version: 3.10.0-1127.18.2.el7.x86_64

We have a requirement where we wanted a logger to get printed in 
Catalina.out when Tomcat reaches it’s max thread limit.


We reduced values of properties : /minSpareThreads, maxThreads and 
acceptCount/ in server.xml. Also changed logging level to ALL/DEBUG in 
logging.properties.


When we made higher number of requests to tomcat we face 
*/java.net.SocketTimeoutException: Read timed out/ *Exception on client 
side but no Log or Exception on Tomcat side.


What change we have to perform, so that tomcat indicates it’s thread 
limit has reached or it is about to reach that limit.


Tomcat doesn't bother to log when it hits its maximum thread limit 
because it's an unremarkable event. Who cares that you've hit your max?


Well, obviously YOU care.

The MXBeans for thread pools, etc. don't have any subscribable events. 
Theoretically, you could listen for attribute change notifications from 
an MXBean but none have been programmed into Tomcat.



Attaching screenshot of server.xml and Logging.properties.


Screenshots don't make it to this list. You gotta use text to communicate.

If it's not important to know the exact moment you hit your high-water 
mark, you could poll Tomcat via JMX to find out what the current 
max-threads is and the current active-threads. If you have 
active-threads=max-threads=max-max-threads then you know that your 
server is saturated.


-chris

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



Re: Pausing all thread but one.

2020-10-28 Thread Christopher Schultz

Tullio,

On 10/28/20 06:27, Tullio Bettinazzi wrote:
I need to perform some maintenance operations pausing all user thread 
for a small but meaningfull time (say 30 secs).


Ugh. Why? What do you need to do that can't be handled with "proper" 
synchronization?



Is it possible to pause all user threads ?


Maybe. It's very dangerous, though.

https://docs.oracle.com/javase/8/docs/technotes/guides/concurrency/threadPrimitiveDeprecation.html


How ?


I'll leave that as an exercise for the reader at this point.


Any suggestion ?


Yes: think if a better way to do what you are trying to do.

This sounds like an X-Y problem[1]. You are trying to do X and you have 
decided that you need to do Y in order to accomplish X. So you are 
asking about Y.


Why not just ask about X instead?

-chris

[1] http://xyproblem.info/

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



Re: Our webapp is running very slowly on one particular customer box

2020-10-28 Thread Christopher Schultz

James,

On 10/27/20 16:20, James H. H. Lampert wrote:

This is related to my query (thanks, Mr. Gregg) about "Tenured SOA."

It seems that on one of our customer installations, our webapp gets into 
a state of running very slowly, and the dedicated subsystem it's running 
in is showing massive levels of page-faulting.


I've compared the GC stats of the "problem" system with one that's 
actually got more users connected, but isn't experiencing performance 
issues. It seems that they're both going to GC about every 30-50 
seconds, but GC on the "problem" system appears to be somewhat less 
effective.


Also, I've looked at the threads on both. On the system that is behaving 
normally, the "GC Slave" threads (7 of them) are showing total CPU (at 
this moment) of around 150 seconds each, and Aux I/O of mostly zero, 
with one showing 1 and one showing 3. Conversely, on the "problem" 
system, I'm seeing 15(!) GC Slave threads, each with total CPU under 6 
seconds each, but Aux I/O ranging from 5800 to over 8000.


I'm not sure what to make of this. In both cases, Tomcat's JVM is 
running in a subsystem of its own, with a private memory pool of around 
7G, and they're both running with -Xms4096m -Xmx5120m.


If you expect the service to be long-running, definitely set Xms=Xmx. 
There's no reason to artificially restrict the heap "early" in the 
process's lifetime only to completely re-size and re-organize the heap 
over time. You may as well allocate the maximum right up front and leave 
it that way.


The problem system certainly appears to be thrashing its GC. Are there 
any environmental differences that you notice about the two systems? For 
a JVM with a maximum heap of ~5GiB, I think that a 7GiB private memory 
space (this is an AS/400 thing isn't it?) isn't large enough. The heap 
space is just the "Java heap" and there are other things that need 
memory, sometimes ~= to the heap size. It's sometimes surprising how 
much "native" memory a JVM needs. Is the kernel+userspace running in 
that "subsystem" as well? Or just the JVM process?


I'm guessing that your comment about page-faulting and "Aux I/O rang[es] 
from 5800 - 8000 [sec]" means that you are actually paging the heap to 
the disk. What happens if you shrink your max-heap to 2GiB and change 
nothing else? This should make sure that your heap + native memory fits 
into physical memory and that thrashing should stop.


Maybe you *do* need a 5GiB heap, though. In that case, if the 
heap-shrink works but you get OOMEs under load, then I think that simply 
increasing the memory allocated to the "subsystem" should help a lot.


How much (real) memory does the system report is being used by the JVM 
process? I think you'll find it much larger than 5GiB.


-chris

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



Re: mod_jk "Can not determine the proper size for pid_t" on macOS 10.15.7

2020-10-27 Thread Christopher Schultz

Brian

On 10/26/20 15:33, Paquin, Brian wrote:

I’m trying to build httpd and mod_jk for the first time on a macOS 10.15.7 box. 
XCode 12.1 is installed and I was able to compile OpenSSL 1.1.1g.
I got an error “Can not determine the proper size for pid_t” when compiling 
httpd (v2.4.46) with included apr (v1.7.0).
This issue https://bz.apache.org/bugzilla/show_bug.cgi?id=64753 provided a diff patch 
that adds “#include ” in a number of locations.
Applying this patch allowed me to compile httpd!


Weird. pid_it is defined in  and yet the patch adds 
 to fix it.


I don't have access to my Catalina machine right now, but my clang-based 
Mojave machine still says to use  when you "man getpid":


"
GETPID(2)   BSD System Calls Manual

NAME
 getpid, getppid -- get parent or calling process identification

SYNOPSIS
 #include 

 pid_t
 getpid(void);
"

$ cc --version
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin


Now I am trying to compile mod_jk (v1.2.48), and I get the same error.
Does someone have a patch file I can use to get around this issue?

$ ./configure CFLAGS='-arch x86_64' APXSLDFLAGS='-arch x86_64' 
--with-apxs=/usr/local/apache2/bin/apxs

$ make

Making all in common
/usr/local/apache-2.4.46/build/libtool --silent --mode=compile gcc -I. 
-I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -arch x86_64  
-DHAVE_APR  -I/usr/local/apache-2.4.46/include 
-I/usr/local/apache-2.4.46/include -arch x86_64 -DHAVE_CONFIG_H -DDARWIN 
-DSIGPROCMASK_SETS_THREAD_MASK -DDARWIN_10 -c jk_ajp12_worker.c -o 
jk_ajp12_worker.lo
In file included from jk_ajp12_worker.c:25:
In file included from ./jk_ajp12_worker.h:26:
In file included from ./jk_logger.h:26:
In file included from ./jk_global.h:340:
./jk_types.h:56:2: error: Can not determine the proper size for pid_t
#error Can not determine the proper size for pid_t
  ^
./jk_types.h:62:2: error: Can not determine the proper size for pthread_t
#error Can not determine the proper size for pthread_t
  ^
2 errors generated.
make[1]: *** [jk_ajp12_worker.lo] Error 1
make: *** [all-recursive] Error 1
$


I'm sorry, I have no idea how configure does its magic. The 
auto-generated jk_types.h looks like a hand-wavy template to me.


You can probably hack it briefly by running "configure" (which you 
already did) and then hand-editing include/jk_types.h (ignoring the 
warning NOT to hand-edit it!) and manually adding:


#include 

to the top.

Give that a try and see if it works.

-chris

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



Re: [OT] SSLException after Java upgrade

2020-10-26 Thread Christopher Schultz

Steve,

On 10/26/20 13:02, Steve Sanders wrote:

We ran into similar issues when upgrading to latest JDK 8 (and 11). We
found that the fix was to add the sun.security.ec.SunEC as a security
provider in java.security like so:

security.provider.9=sun.security.ec.SunEC


I'll have to try that. I can easily use my SSLTest tool[1] to test 
various permutations.



After adding this we were able to continue using our current certificates
and communicate with services using the updated ciphers. Depending on the
version / flavor of JDK you're using you may also need to apply the
unlimited strength JCE policy patch found here:
https://www.oracle.com/java/technologies/javase-jce8-downloads.html


If you still need this, then you really need to upgrade your Java. Java 
8 no longer requires application of a separate, "unlimited" policy file 
since u162, released January 2018.


-chris

[1] https://github.com/ChristopherSchultz/ssltest
[2] 
https://golb.hplar.ch/2017/10/JCE-policy-changes-in-Java-SE-8u151-and-8u152.html


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



[OT] SSLException after Java upgrade

2020-10-26 Thread Christopher Schultz

All,

(Note that this has nothing whatsoever to to with Apache Tomcat. These 
connections are between services running on Tomcat and others, but 
Tomcat's TLS code or configuration is in no way involved.)


I recently upgraded my OpenJDK Java 8 installations on a few servers and 
started getting this error when connecting between two services 
involving a specific server:


javax.net.ssl.SSLException: No preferred signature algorithm for 
CertificateVerify


I believe I have tracked this back to the fact that this server's client 
key/cert was using the secp256k1 curve instead of the more 
widely-supported secp256r1 curve (this is the "NIST P-256" curve). I 
think Java dropped support for the non-NIST curves at some point yet the 
documentation says that they are supported for compatibility[1].


I founds a bug in the JDK listed here [2] which may or may not be related.

There is a workaround mentioned in the bug report:

"
Configure server so that supported_signature_algorithms prefers 
signature algorithms supported by the SunPKCS11 provider 
(RSA_PKCS1_SHA256, RSA_PKCS1_SHA384, RSA_PKCS1_SHA_512, RSA_SHA224, 
RSA_PKCS1_SHA1).

"

I don't think this will apply to me, since this is all about RSA 
signatures, but I suppose it could be adapted to the EC signature 
algorithms (e.g. EC_PKCS1_SHA256 or whatever).


Does anyone know how to "configure [...] 
supported_signature_algorithms"? I've never heard of that setting before 
and some web searching isn't coming up with much for me.


Back to the deprecated curves. I can't find any reference to them being 
disabled by default, and the java.security file contains a disabled 
algorithms setting that doesn't mention EC crypto at all:


jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
EC keySize < 224, 3DES_EDE_CBC, anon, NULL

and also:

jdk.tls.legacyAlgorithms= \
K_NULL, C_NULL, M_NULL, \
DH_anon, ECDH_anon, \
RC4_128, RC4_40, DES_CBC, DES40_CBC, \
3DES_EDE_CBC

The documentation for legacyAlgorithms says that they will only be 
negotiated when there are no other (non legacy) options available. In my 
case, it was a complete failure.


I minted a new certificate using P-256 and I was able to make a 
connection again. So the certificate key algorithm was indeed the problem.


I finally found the reference I was looking for regarding Java actually 
disabling those curves[3]. It happened in Java 8 u231 about a year ago[4].


One can re-enable the negotiation of these algorithms by setting the 
system property "jdk.tls.namedGroups" to an appropriate setting.


This issue must have happened due to the upgrade of my Debian openjdk-8 
package, which finally included the (default) disabling of those algorithms.


I started this post to ask some questions from the community but I think 
it's turning out to be a little bit of a PSA because I ended up finding 
just about everything I needed to recover.


I'm still curious about the supported_signature_algorithms thing, though.

Thanks,
-chris

[1] 
https://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#legacy-curves-retained-for-compatibility

[2] https://bugs.openjdk.java.net/browse/JDK-8223940
[3] https://java.com/en/configure_crypto.html#DisablenonNIST
[4] https://java.com/en/jre-jdk-cryptoroadmap.html

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



Re: tomcat http error code 502

2020-10-22 Thread Christopher Schultz
Jason,

On 10/22/20 01:36, Jason Wee wrote:
> using tomcat 8.5.42 and have the following questions
> 
> * will tomcat log http error 502 in accesslog?

I don't see why not.

> * under what situation will tomcat return 502?

I do not see any code in Tomcat which responds with SC_BAD_GATEWAY (or
502 without using the constant).

If you are seeing thism, I would first investigate:

1. Any proxy or load-balancer you have between the client and the Tomcat
node
2. Any application deployed on that Tomcat node that may be returning a
502 response

-chris

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



Re: FW: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)

2020-10-21 Thread Christopher Schultz
Arshiya,

On 10/21/20 00:34, Arshiya Shariff wrote:
> Hi,
> 
> Christopher, Please find the answer in-line:
> How... exactly?
> private String getRequestBody(HttpServletRequest request) throws IOException
>   {
>   StringBuilder sb = new StringBuilder();
>   BufferedReader reader = request.getReader();
>   try
>   {
>   String line;
>   while( ( line = reader.readLine() ) != null )
>   {
>   sb.append( line ).append( '\n' );

Note that this may modify the incoming request. Are you sure you want to
return a value which does not match the exact POST body?

>   }
>   }
>   finally
>   {
>   reader.close();
>   }
>   return sb.toString();
>   }   
>  

Is that method run from within the asynchronous context or before you
begin async processing? I'm not an expert at servlet-async, but I think
you should be reading the request entirely before entering the async
context. Reading the request from async may cause problems.

Instead of using blocking reads of the request bbody in asynchronous
mode, you should do this:

request.getInputStream().setReadListener(new ReadListener() {
  public void onoAllDataRead() { ... }
  public void onDataAvailable() { ... }
  public void onError(Throwable t) { ... }
});


> I am trying to reproduce the StackOverflowError with a sample
> application , Once it is reproduced I will share it across.

See https://www.slideshare.net/SimoneBordet/servlet-31-async-io

Specifically slides 43-53.

-chris

> -Original Message-
> From: Christopher Schultz  
> Sent: Thursday, October 15, 2020 12:01 AM
> To: users@tomcat.apache.org
> Subject: Re: FW: HTTP2: memory filled up fast on increasing the connections 
> to 1000/2000 (Embedded tomcat 9.0.38)
> 
> Arshiya,
> 
> On 10/14/20 01:23, Arshiya Shariff wrote:
>> Please find the answers in-line Mark.
>>
>> Http2 requests with message payload of  34KB are pumped from JMeter at 
>> 20 TPS with 700 connections to an application with Embedded tomcat
>> - 9.0.39 (max-Threads : 200, all other values are the tomcat
>> defaults)
>>
>>> What does that URL do with the POSTed content? Ignore it? Read it 
>>> from an InputStream? Read it via getParameter()?
>>
>> The posted content is read via BufferedReader reader =
>> request.getReader() and processed asynchronously
> How... exactly?
>> Is JMeter run on the same machine as Tomcat?
>> JMeter is run from a different machine.
>>
>> Do you use the JMeter GUI or the command line?
>> Launched via Command line (JMeter heap increased to 10 GB )
>>
>> What are the specs of the server(s) being used?
>> The server is a VM with 12 CPUs and 120 GB RAM
>>
>> Please let us know  if you require more details.
> 
> This would probabyl be easier if you'd just provide a test-case: a sample 
> (simple!) web application which reproduces what you are reporting.
> 
> -chris
> 
>> -Original Message-
>> From: Mark Thomas 
>> Sent: Monday, October 12, 2020 7:28 PM
>> To: users@tomcat.apache.org
>> Subject: Re: HTTP2: memory filled up fast on increasing the 
>> connections to 1000/2000 (Embedded tomcat 9.0.38)
>>
>> On 12/10/2020 08:02, Arshiya Shariff wrote:
>>> Hi Mark ,
>>>
>>> The issue is reproduced with version 9.0.39 as well. Max threads in Tomcat 
>>> is 200.
>>>
>>> Please find the case:
>>> Client:JMeter 5.2.1 (With http2 plugin)
>>> TPS: around 20
>>> No of users from JMeter : 700
>>> Message payload size: 6 KB to 34 KB
>>> Loop: Infinite
>>> We let the loop run infinitely and see the java.lang.StackOverflowError 
>>> trace printed multiple times in the log within few minutes of starting the 
>>> test.
>>
>> POSTing to what URL?
>>
>> What does that URL do with the POSTed content? Ignore it? Read it from an 
>> InputStream? Read it via getParameter()?
>>
>> Is JMeter run on the same machine as Tomcat?
>>
>> Do you use the JMeter GUI or the command line?
>>
>> What are the specs of the server(s) being used?
>>
>> You need to provide the exact steps to recreate this issue on a clean 
>> install of Tomcat 9.0.39 as provided by the ASF.
>>
>> Mark
>>
>>
>>> Please help us with this . What is the impact of StackOverflowError ?
>>>
>>> Thanks and Regards
>>> Arshiya Shariff
>>>
&

Re: Recent Tomcat crash produced error messages I've never seen before

2020-10-20 Thread Christopher Schultz
James,

On 10/20/20 16:39, James H. H. Lampert wrote:
> On 10/20/20 1:26 PM, Christopher Schultz wrote:
>> Theoretically, it should not be possible to cause a JVM to crash with
>> pure Java code.
> 
> Thanks.
> 
> Of course, we all know that while theory and practice are the same in
> theory, they aren't always in practice. ;-P

Exactly. But my point is that if your Java code is causing the JVM to
crash, it's not your Java code's fault.

-chris

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



Re: Recent Tomcat crash produced error messages I've never seen before

2020-10-20 Thread Christopher Schultz
James,

On 10/20/20 13:35, James H. H. Lampert wrote:
> We had a Tomcat crash on a customer box, a few hours ago (a simple
> restart got them back up and running), and it produced a whole bunch of
> errors in the general vein of
>>
>> *** Invalid JIT return address 0006E2E2E400 in 0001A83C5210

Yikes.

> before finally failing with a null pointer exception, and producing a
> Java dump, a Snap dump, and a JIT dump, all over the course of a couple
> of seconds.
> 
> Prior to that, our webapp was having a great deal of trouble accessing
> Office365.

Via HTTP(S) or via some native API?

> Other than that it's almost certainly our webapp, rather than Tomcat
> itself, that caused the "Invalid JIT return address" messages, does
> anybody here have any insights? I've literally never seen messages of
> this type before.

It's more likely to be a JVM bug than anything in your code.
Theoretically, it should not be possible to cause a JVM to crash with
pure Java code.

-chris

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



Re: Virtual event focussed on Tomcat Security

2020-10-20 Thread Christopher Schultz
Mark,

On 10/15/20 14:01, Mark Thomas wrote:
> On 29/09/2020 12:25, Mark Thomas wrote:
>> Hi all,
>>
>> We (the Tomcat community) have some funding from Google to help us
>> improve Tomcat security. Our original plan was to use the funding to
>> support an in-person security focussed hackathon. As you would expect,
>> those plans are on hold for now. We would, therefore, like to explore
>> the possibility of doing something virtually.
>>
>> The purpose of this email is to gather input from the community about
>> what such an event should look like. With that input we can put together
>> a plan for the event. So, over to you. What would your ideal virtual
>> event focussed on Tomcat Security look like?
> 
> Summarising the suggestions so far:
> - application security / OWASP
> - making HTTP requests *from* Tomcat
>  - SSO / SAML / OpenIDConnect
> 
> The first two are more application security focused and would not have
> to be Tomcat specific.
> 
> The third is more likely to Tomcat specific depending on the extent to
> which the SSO mechanism ties into Tomcat's internals.

I've built incoming single-legged SAML SSO into my own application
without any external libraries, so I could led a group to work on this
kind of thing.

> All the suggestions so far have been for conference like presentations
> (if I am reading them correctly).
> 
> Other possibilities:
> - hackathon to implement (with support from committers) new security
>   features (no idea what these might be - suggestions welcome)
> 
> - hackathon to run $tool_of_choice against Tomcat code base, review the
>   results and fix (with committer support) those that need fixing.
>   Suggestions as to tools to use welcome*
> 
> Anything else you'd like to suggest that is related to Tomcat and security.
> 
> There hasn't been any thought given to timing yet.
> 
> Mark
> 
> 
> 
> * I'll note that over the years most if not all of the major static
> analysis tools have been run against the Tomcat code base and the
> results have been very heavy on the false positives. Most of the work is
> likely to be separating the few useful results from a lot of noise.

+1

It's worth running new tools against Tomcat and then having many eyes
look at the list to determine false-positives.

-chris

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



Re: [OT] Custom protocol implementation not found

2020-10-15 Thread Christopher Schultz
Maarten,

On 10/14/20 16:21, Maarten Van Den Broek wrote:
> 
> 
>> Op 14 okt. 2020 om 21:09 heeft Christopher Schultz 
>>  het volgende geschreven:
>>
>> Maartin,
>>
>>> On 10/14/20 09:07, Maarten van den Broek wrote:
>>> Op 14-10-2020 om 14:10 schreef Rémy Maucherat:
>>>> On Wed, Oct 14, 2020 at 11:38 AM Maarten van den Broek <
>>>> mbr...@messagedesign.nl> wrote:
>>>>
>>>>> I use tomcat 9.0.33 with windows10 home and amazon corretto
>>>>> jdk1.8.0_212.
>>>>>
>>>>> Below a snapshot of two different Connector definitions in server.xml
>>>>>
>>>>>   >>>>  maxThreads="150" SSLEnabled="true" scheme="https"
>>>>> secure="true"
>>>>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol"
>>>>>
>>>>>  clientAuth="false" sslEnabledProtocols="TLSv1.2"
>>>>>  minSpareThreads="5"
>>>>>  enableLookups="true" disableUploadTimeout="true"
>>>>> keystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks"
>>>>> keystorePass="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3"
>>>>>  />
>>>>>
>>>>>   >>>> disableUploadTimeout="true" enableLookups="true" maxThreads="150"
>>>>> minSpareThreads="5" port="443"
>>>>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol"
>>>>>
>>>>> SSLEnabled="true" scheme="https" secure="true">
>>>>>   
>>>>>   >>>> certificateKeystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks"
>>>>>
>>>>>
>>>>> certificateKeystorePassword="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3"
>>>>> certificateKeystoreType="JKS"/>
>>>>>   
>>>>>   
>>>>>
>>>>> Using the first Connector everything is working fine. Debugging the
>>>>> setKeystorePass method of the class
>>>>> nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol in the
>>>>> protocol attribute shows that the encrypted password gets decrypted.
>>>>>
>>>>> Using the second connector with the SSLHostConfig element instead of the
>>>>> deprecated attributes debugging shows that the setKeystorePass method is
>>>>> not called and I get errors for the incorrect password of the keystore.
>>>>>
>>>>> What am I doing wrong in migrating to the configuration with the
>>>>> SSLHostConfig element?
>>>>>
>>>>> Sincerely yours,Maarten van den Broek
>>>>>
>>>> If you simply want to obfuscate server.xml attributes, you should look
>>>> into
>>>> the digester property sources instead of engaging in this sort of stuff.
>>>> One such property source out there:
>>>> https://github.com/web-servers/tomcat-vault
>>>>
>>>> Note: This capability is not included directly into Tomcat itself because
>>>> it provides no actual extra security.
>>>>
>>>> Rémy
>>>
>>> Dear Rémy,
>>>
>>> Thank you for your swift response.
>>>
>>> Customers are happy with this solution because they only need to provide
>>> these passwords during the first installation and it can be done by the
>>> owner of the certificate. The key for the en/decryption is in a keystore
>>> with a password, that can only be obtained by debugging the code.
>>
>> So you have the password for the keystore hard-coded into your Java
>> code? Doesn't that mean it's in revision-control?
>>
>>> In a production environment this is in most cases impossible. This
>>> mechanism is also used to encrypt columns in the database and it is
>>> easy to reuse for the encryption of the keystore passwords. I prefer
>>> this over the use of a tomcat vault, because there is increased
>>> complexity installing tomcat. Alas, it may break with major releases
>>> and then you have to fix it again, but with your swift help it is no
>>> problem.
>>
>> -chris
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
> Hello Chris,
> 
> The password is generated with an algoritm that can only be cracked 
> by reverse engineering the code from a seed given by the user unknown
> to the makers of the code. So only reverse engineering the code is a
> liability.

Beware:
https://en.wikipedia.org/wiki/Kerckhoffs%27s_principle

-chris

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



Re: OpenSSL prompts for key password

2020-10-15 Thread Christopher Schultz
Michael,

On 10/15/20 08:12, Michael Osipov wrote:
>> Michael,
>>
>> On 10/14/20 12:46, Michael Osipov wrote:
>>> Folks,
>>>
>>> I have recently upgrade a cert and left out the last char of the key
>>> password by accident.
>>>
 # /sbin/init.d/tomcat-smartld start
 Starting Apache Tomcat 8.5...
 Using CATALINA_BASE:   /var/opt/tomcat-smartld
 Using CATALINA_HOME:   /opt/ports/apache-tomcat-8.5.57
 Using CATALINA_TMPDIR: /var/opt/tomcat-smartld/temp
 Using JRE_HOME:    /opt/java8
 Using CLASSPATH:  
 /opt/ports/apache-tomcat-8.5.57/bin/bootstrap.jar:/opt/ports/apache-tomcat-8.5.57/bin/tomcat-juli.jar

 Tomcat started.
 Apache Tomcat 8.5 started.
 # Some of your private key files are encrypted for security reasons.
 In order to read them you have to provide the pass phrases.
 Enter password :
  
>>>
>>> I have seen similar with HTTPd in the past. Since the start is async I
>>> have no option to react on that and it will block the entire config. I
>>> looked briefly in the OpenSSL API, but wasn't really able to find a flag
>>> to inhibit the interactive prompt.
>>>
>>> Does someone know whether we can make this better with libtcnative?
>>
>> What kind of behavior were you hoping for? I'm assuming that some kind
>> of exception would be best for this case (incorrect password).
> 
> Correct. As long as stdin is is not attached to a tty, this must be
> non-interactive.
> 
>> Suppressing the interactive prompt is likely to simply cause the
>> connector to fail to initialize; basically the same thing as throwing an
>> exception in the above case.
> 
> Correct.
> 
>> I searched the Tomcat code and I don't see that sting anywhere, so I
>> suspect it's coming directly from OpenSSL (which is very weird IMHO).
> 
> It comes from us (tomcat-native/native/include/ssl_private.h):
>> #define SSL_DEFAULT_PASS_PROMPT "Some of your private key files are 
>> encrypted for security reasons.\n"  \
>> "In order to read them you have to provide 
>> the pass phrases.\n" \
>> "Enter password :"

*facepalm* I was only looking at the Java code.

> Used by us in SSL_password_prompt() called by SSL_password_callback().
> I haven't yet found out which object is called to obtain the password.

It seems reasonable that when we *know* that we are supplying a
password, we should install a null-callback for that and let OpenSSL's
engine fail to initialize.

>> mod_ssl has a configurable way to gather this passphrase, presumably to
>> pass it into OpenSSL's read-key function. It would surprise me greatly
>> if an incorrect passphrase would cause the same kind of prompt in httpd.
> 
> It does when your don't provide a method how you will supply the password.
> See SSLPassPhraseDialog builtin in
>> ./modules/ssl/ssl_engine_config.c ./modules/ssl/ssl_engine_pphrase.c
> 
> See also Javadoc of SSLContext#setCertificate(long, String, String, String, 
> int)
> 
>> What version of OpenSSL are you using? Have you tried any other versions?
> 
> I am on
>> # openssl version
>> OpenSSL 1.1.1d  10 Sep 2019
> 
> supplied by HPE on HP-UX.
> 
> A change in OpenSSL version won't make a difference because this is how it is
> configured from tcnative for now.

+1

> I will file an issue to track this, especially because it is not documented
> compared to SSLPassPhraseDialog.

+1

I didn't even know that tcnative would prompt for a password, *ever*.

-chris

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



Re: [OT] Custom protocol implementation not found

2020-10-14 Thread Christopher Schultz
Maartin,

On 10/14/20 09:07, Maarten van den Broek wrote:
> Op 14-10-2020 om 14:10 schreef Rémy Maucherat:
>> On Wed, Oct 14, 2020 at 11:38 AM Maarten van den Broek <
>> mbr...@messagedesign.nl> wrote:
>>
>>> I use tomcat 9.0.33 with windows10 home and amazon corretto
>>> jdk1.8.0_212.
>>>
>>> Below a snapshot of two different Connector definitions in server.xml
>>>
>>>   >>  maxThreads="150" SSLEnabled="true" scheme="https"
>>> secure="true"
>>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol"
>>>
>>>  clientAuth="false" sslEnabledProtocols="TLSv1.2"
>>>  minSpareThreads="5"
>>>  enableLookups="true" disableUploadTimeout="true"
>>> keystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks"
>>> keystorePass="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3"
>>>  />
>>>
>>>   >> disableUploadTimeout="true" enableLookups="true" maxThreads="150"
>>> minSpareThreads="5" port="443"
>>> protocol="nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol"
>>>
>>> SSLEnabled="true" scheme="https" secure="true">
>>>   
>>>   >> certificateKeystoreFile="C:/Users/Maarten/Certificaten/gm_messagedesign_nl2020.jks"
>>>
>>>
>>> certificateKeystorePassword="ZURV/6aoh/mLRxJGFhnvEpVZ7PoL72h3"
>>> certificateKeystoreType="JKS"/>
>>>   
>>>   
>>>
>>> Using the first Connector everything is working fine. Debugging the
>>> setKeystorePass method of the class
>>> nl.messagedesign.tomcatlib.EncryptedPassword_Http11Nio2Protocol in the
>>> protocol attribute shows that the encrypted password gets decrypted.
>>>
>>> Using the second connector with the SSLHostConfig element instead of the
>>> deprecated attributes debugging shows that the setKeystorePass method is
>>> not called and I get errors for the incorrect password of the keystore.
>>>
>>> What am I doing wrong in migrating to the configuration with the
>>> SSLHostConfig element?
>>>
>>> Sincerely yours,    Maarten van den Broek
>>>
>> If you simply want to obfuscate server.xml attributes, you should look
>> into
>> the digester property sources instead of engaging in this sort of stuff.
>> One such property source out there:
>> https://github.com/web-servers/tomcat-vault
>>
>> Note: This capability is not included directly into Tomcat itself because
>> it provides no actual extra security.
>>
>> Rémy
> 
> Dear Rémy,
> 
> Thank you for your swift response.
> 
> Customers are happy with this solution because they only need to provide
> these passwords during the first installation and it can be done by the
> owner of the certificate. The key for the en/decryption is in a keystore
> with a password, that can only be obtained by debugging the code.

So you have the password for the keystore hard-coded into your Java
code? Doesn't that mean it's in revision-control?

> In a production environment this is in most cases impossible. This
> mechanism is also used to encrypt columns in the database and it is
> easy to reuse for the encryption of the keystore passwords. I prefer
> this over the use of a tomcat vault, because there is increased
> complexity installing tomcat. Alas, it may break with major releases
> and then you have to fix it again, but with your swift help it is no
> problem.

-chris

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



Re: Tomcat SecurityListener

2020-10-14 Thread Christopher Schultz
Shawn,

On 10/12/20 15:59, Beard, Shawn wrote:
> Tomcat 9.0.31.0 loads a org.apache.catalina.security.SecurityListener by
> default in the catalina.sh file.

This comes from server.xml, and it's not "on" by default.

> This SecurityListener also sets the UMASK of files to 0027. This has the
> effect of any file tomcat creates or the app running in tomcat creates
> with permissions or -rw-r-

This is untrue: SecurityListener does not set any umask (nor can it). It
simply checks the effective umask (as passed into the JVM as a system
property) against a configured minimum.

> This is causing a problem for us as it prevents certain people from
> being able to read log files or read any file the application might
> create. Putting these users in the group of the user that tomcat runs as
> is not an option.

:(

> I’ve tried changing the catalina.sh to set the UMASK to something like
> 0022 but that prevents tomcat from starting with an error that it has to
> me at least as restrictive as 0027.

Do not change catalina.sh. Instead, use $CATALINA_BASE/setenv.sh to set
the UMASK environment variable (which should work).

> I’ve also tried setting the UMASK to 0022 in the setenv.sh with same
> results.

Good. Well, not good. But I mean, good that you are using setenv.sh.

> I’m hesitant to comment out the loading of the security listener in
> catalina.sh as I don’t want to disable anything else important that it
> may be doing from a security standpoint.

It's verifying the minimum umask and that you aren't running as any of
the configured OS usernames (default: "root").

I suspect if you disable the SecurityListener you will find that nothing
changesL: your umask will still be ignored for some reason.

> Does anyone have any ideas as to a workaround?

How are you launching Tomcat?

-chris

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



Re: OpenSSL prompts for key password

2020-10-14 Thread Christopher Schultz
Michael,

On 10/14/20 12:46, Michael Osipov wrote:
> Folks,
> 
> I have recently upgrade a cert and left out the last char of the key
> password by accident.
> 
>> # /sbin/init.d/tomcat-smartld start
>> Starting Apache Tomcat 8.5...
>> Using CATALINA_BASE:   /var/opt/tomcat-smartld
>> Using CATALINA_HOME:   /opt/ports/apache-tomcat-8.5.57
>> Using CATALINA_TMPDIR: /var/opt/tomcat-smartld/temp
>> Using JRE_HOME:    /opt/java8
>> Using CLASSPATH:  
>> /opt/ports/apache-tomcat-8.5.57/bin/bootstrap.jar:/opt/ports/apache-tomcat-8.5.57/bin/tomcat-juli.jar
>>
>> Tomcat started.
>> Apache Tomcat 8.5 started.
>> # Some of your private key files are encrypted for security reasons.
>> In order to read them you have to provide the pass phrases.
>> Enter password :
>>  
> 
> I have seen similar with HTTPd in the past. Since the start is async I
> have no option to react on that and it will block the entire config. I
> looked briefly in the OpenSSL API, but wasn't really able to find a flag
> to inhibit the interactive prompt.
> 
> Does someone know whether we can make this better with libtcnative?

What kind of behavior were you hoping for? I'm assuming that some kind
of exception would be best for this case (incorrect password).

Suppressing the interactive prompt is likely to simply cause the
connector to fail to initialize; basically the same thing as throwing an
exception in the above case.

I searched the Tomcat code and I don't see that sting anywhere, so I
suspect it's coming directly from OpenSSL (which is very weird IMHO).

mod_ssl has a configurable way to gather this passphrase, presumably to
pass it into OpenSSL's read-key function. It would surprise me greatly
if an incorrect passphrase would cause the same kind of prompt in httpd.

What version of OpenSSL are you using? Have you tried any other versions?

-chris

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



Re: FW: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)

2020-10-14 Thread Christopher Schultz
Arshiya,

On 10/14/20 01:23, Arshiya Shariff wrote:
> Please find the answers in-line Mark.
> 
> Http2 requests with message payload of  34KB are pumped from JMeter
> at 20 TPS with 700 connections to an application with Embedded tomcat
> - 9.0.39 (max-Threads : 200, all other values are the tomcat
> defaults)
> 
>> What does that URL do with the POSTed content? Ignore it? Read it 
>> from an InputStream? Read it via getParameter()?
>
> The posted content is read via BufferedReader reader =
> request.getReader() and processed asynchronously
How... exactly?

> Is JMeter run on the same machine as Tomcat?
> JMeter is run from a different machine.
> 
> Do you use the JMeter GUI or the command line?
> Launched via Command line (JMeter heap increased to 10 GB )
> 
> What are the specs of the server(s) being used?
> The server is a VM with 12 CPUs and 120 GB RAM
> 
> Please let us know  if you require more details.

This would probabyl be easier if you'd just provide a test-case: a
sample (simple!) web application which reproduces what you are reporting.

-chris

> -Original Message-
> From: Mark Thomas  
> Sent: Monday, October 12, 2020 7:28 PM
> To: users@tomcat.apache.org
> Subject: Re: HTTP2: memory filled up fast on increasing the connections to 
> 1000/2000 (Embedded tomcat 9.0.38)
> 
> On 12/10/2020 08:02, Arshiya Shariff wrote:
>> Hi Mark ,
>>
>> The issue is reproduced with version 9.0.39 as well. Max threads in Tomcat 
>> is 200.
>>
>> Please find the case:
>> Client:JMeter 5.2.1 (With http2 plugin)
>> TPS: around 20
>> No of users from JMeter : 700
>> Message payload size: 6 KB to 34 KB
>> Loop: Infinite
>> We let the loop run infinitely and see the java.lang.StackOverflowError 
>> trace printed multiple times in the log within few minutes of starting the 
>> test.
> 
> POSTing to what URL?
> 
> What does that URL do with the POSTed content? Ignore it? Read it from an 
> InputStream? Read it via getParameter()?
> 
> Is JMeter run on the same machine as Tomcat?
> 
> Do you use the JMeter GUI or the command line?
> 
> What are the specs of the server(s) being used?
> 
> You need to provide the exact steps to recreate this issue on a clean install 
> of Tomcat 9.0.39 as provided by the ASF.
> 
> Mark
> 
> 
>> Please help us with this . What is the impact of StackOverflowError ?
>>
>> Thanks and Regards
>> Arshiya Shariff
>>
>> -Original Message-
>> From: Mark Thomas 
>> Sent: Friday, October 9, 2020 5:31 PM
>> To: users@tomcat.apache.org
>> Subject: Re: HTTP2: memory filled up fast on increasing the 
>> connections to 1000/2000 (Embedded tomcat 9.0.38)
>>
>> On 09/10/2020 12:32, Arshiya Shariff wrote:
>>> Hi,
>>>
>>> Mark , with the test runs that I performed over clean 9.0.x branch I was 
>>> not able to reproduce this.
>>
>> Good. But I'd really like to understand why...
>>
>>> But with 9.0.38 and the jars built from 9.0.x with hash: 
>>> c8ec2d4cde3a31b0e9df9a30e7915d77ba725545  , with 700 or 1000 users 
>>> (connections) and on sending 1000 Requests per second (or even lesser) , 
>>> payload of 16K  from JMeter I can see that this Exception occurs within few 
>>> minutes of starting the test . The maxThreads configured in tomcat is 200 .
>>>
>>> How often do you see these errors in your test run?
>>> Randomly, at times 2 or 3 such traces.
>>
>> OK. Definitely a timing issue then.
>>
>>> Do you have the other end of that stack trace?
>>> It is only the two lines that is recursively printed till the end about  
>>> ~500 times in one trace  :
>>> at 
>>> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1511)
>>> at
>>> org.apache.tomcat.util.net.SocketWrapperBase$VectoredIOCompletionHand
>>> l
>>> er.completed(SocketWrapperBase.java:1100)
>>
>> Doesn't tell me much unfortunately.
>>
>>> I see the trace starting with :
>>> Exception in thread "http-nio-x.y.z-1090-exec-107" 
>>> java.lang.StackOverflowError 
>>> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:446)
>>> at org.apache.tomcat.util.net.NioChannel.read(NioChannel.java:174)
>>> at 
>>> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1468)
>>> at
>>> org.apache.tomcat.util.net.SocketWrapperBase$VectoredIOCompletionHand
>>> l
>>> er.completed(SocketWrapperBase.java:1100)
>>>
>>> (OR)
>>>
>>> Exception in thread "http-nio-x.y.z-1090-exec-87" 
>>> java.lang.StackOverflowError
>>> at sun.nio.ch.IOVecWrapper.get(IOVecWrapper.java:96)
>>> at sun.nio.ch.IOUtil.read(IOUtil.java:240)
>>> at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:440)
>>> at org.apache.tomcat.util.net.NioChannel.read(NioChannel.java:174)
>>> at 
>>> org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper$NioOperationState.run(NioEndpoint.java:1468)
>>> at 
>>> 

Re: Deploying war, Negative Date exception

2020-10-12 Thread Christopher Schultz
Mark,

On 10/12/20 09:50, Mark Thomas wrote:
> On 12/10/2020 13:53, Mark Thomas wrote:
>> On 12/10/2020 12:49, Mark Thomas wrote:
>>> On 12/10/2020 12:19, Peter Henderson wrote:
 Hello fellow tomcat users.

 My environment.
 Tomcat: 9.0.39
 Java: openjdk 11.0.8 2020-07-14
 OS: Ubuntu 18.04.5 LTS

 Source code [0]

 When deploying this war [1], by copying it into the webapps directory,
 I get this exception. [2]
 java.lang.IllegalArgumentException: Negative time


 I only started seeing this exception when I upgraded my projects build tool
 version
 from
 sbt.version=1.3.10
 to
 sbt.version=1.4.0


 Is this a tomcat bug, a build tool bug or most likely something I'm doing
 wrong?
>>>
>>> Looks like an issue with the dates of files in the WAR.
>>>
>>> If you look at the dates of the files in the WAR nearly all of them are
>>> in the future (07 Feb 2106, 06:28).
>>>
>>> It looks like something is overflowing but a Java long shouldn't do that.
>>>
>>> Need to dig into exactly what is going on as this looks like it should
>>> work - even if the WAR contains files created almost a century in the
>>> future.
>>
>> Hmm. I see the 2106 date on the file system and with Java 8 but with
>> Java 11 I see 1969-dec-31 23:00 which gives -360 which triggers the
>> exception.
>>
>> The root cause appears to be in the JRE at this point. Whether it is in
>> the JRE used to create the WAR or the JRE reading the WAR is TBD.
>>
>> I think I am going to have to look at the raw bytes and the zip file
>> spec to figure out where the root cause is.
> 
> That was fun.
> 
> Per the zip spec, the last modified time on those files is:
> 
> 1969-Dec-31 23:00:00 UTC
> 
> i.e. 1 hour before the Epoch at 1970-Jan-01 00:00:00 UTC
> 
> It is stored as a signed 32-bit int (F1F0) which is -3600 (zip
> timestamps are in seconds since the Epoch).
> 
> Java 8 reads this incorrectly as an unsigned int (4294963696) which,
> when taken as seconds since Epoch, gives 2016-Feb-07 05:28:16 UTC.

Underflow! :(

> (Incidently the archiver that ships with Ubuntu appears to make the same
> error)
> 
> Java 11 reads this correctly but Java does not let you set times before
> the Epoch so the exception is triggered.
> 
> The short version is that the modification times of the files in the WAR
> are being set to "1969-Dec-31 23:00:00 UTC" which Java doesn't like.
> 
> Tomcat could handle this more gracefully but the end result will be the
> same - the WAR isn't going to deploy. I'm not convinced it is worth
> doing anything here.
> 
> It looks like the fix will be somewhere in the build system used to
> create the WAR.

There is already a check for -1 for the last-modified time for the file
in the ZIP archive. Also for 0 for some reason (sorry, Brian Kernighan,
you can't store your first file in a ZIP file!).

I think that any negative value should be ignored, so the expanded-file
on the disk should get "now" as its last-updated time. So just change
the comparison to:

  if(lastModified > 0) {
expandedFile.setLastModified(lastModified);
  }

-chris

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



Re: Sporadic failure of load a servlet filter

2020-10-09 Thread Christopher Schultz
Nancy,

On 10/9/20 16:12, BOSECKER Nancy wrote:
> I have a servlet that loads when Tomcat is started. It's loaded from xml:
>   privileged="true"
>  antiResourceLocking="false"
>  unpackWAR="true"
>  swallowOutput="false">
> 
> 
> There isn't anything special about this particular one, but I've noticed that 
> Tomcat fails to load it sporadically with:
> 
> 2020-10-09 13:04:40,250 [org.apache.catalina.core.StandardContext 
> startInternal  ] SEVERE  - One or more Filters failed to start. Full 
> details will be found in the appropriate container log file 
> 2020-10-09T13:04:40.250217-07:00[America/Los_Angeles]
> 2020-10-09 13:04:40,251 [org.apache.catalina.core.StandardContext 
> startInternal  ] SEVERE  - Context [/xx] startup failed due to 
> previous errors 2020-10-09T13:04:40.251213700-07:00[America/Los_Angeles]
> 
> Sometimes, shutting down Tomcat and restarting is enough, or shutting down 
> and waiting a few minutes and restarting works.
> I'm using 8.5.5 on Windows when I see this.

Have you looked at the log file to see why the filter is failing?

-chris

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



Re: Tomcat 9.0.37 Clustered DeltaManager Duplicates Session And Loses Session Attributes

2020-10-09 Thread Christopher Schultz
Tim,

On 10/9/20 02:18, Tim N wrote:
>> The second seems to the result of a cluster message received which seems
>> odd on the machine where the session is being created

I was going to ask about that registration process. It looks like each
machine on the cluster registers every machine in the cluster *including
itself*.

If the current member thinks that there is another static member in the
cluster which is also itself, then it will send updates to itself which
... is not what you want.

> I think this was the issue. I've changed:
> 
> StaticMembershipInterceptor interceptor = new StaticMembershipInterceptor();
> int clusterMemberCount =
> Integer.parseInt(serverProperties.getProperty("tomcat-clusterMemberCount"));
> {
>   StaticMember localMember = new StaticMember();
>   localMember.setPort(port);
>   localMember.setSecurePort(-1);
>   localMember.setHost(serverProperties.getProperty("tomcat-clusterAddress"));
>   localMember.setDomain("publish-cluster");
>   
> localMember.setUniqueId(serverProperties.getProperty("tomcat-clusterMemberUniqueId"));
>   interceptor.setLocalMember(localMember);
>   interceptor.addStaticMember(localMember);//Removed
> }
> 
> ...to...
> 
> StaticMembershipInterceptor interceptor = new StaticMembershipInterceptor();
> int clusterMemberCount =
> Integer.parseInt(serverProperties.getProperty("tomcat-clusterMemberCount"));
> {
>   StaticMember localMember = new StaticMember();
>   localMember.setLocal(true);//Added
>   localMember.setPort(port);
>   localMember.setSecurePort(-1);
>   localMember.setHost(serverProperties.getProperty("tomcat-clusterAddress"));
>   localMember.setDomain("publish-cluster");
>   
> localMember.setUniqueId(serverProperties.getProperty("tomcat-clusterMemberUniqueId"));
>   interceptor.setLocalMember(localMember);
> }
> 
> ...and it seems to be fine now.

That would do it.

-chris

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



Re: Tomcat 8.5 RequestDumperFilter

2020-10-08 Thread Christopher Schultz
Wolfeman,

On 10/8/20 10:33, Wolfeman wrote:
> Hi,
> I am trying to debug some requests coming into an application we have
> running on tomcat. I was hoping to be able to print all of the request data
> specifically post data to a debug file and this seemed like a good
> solution. However I have followed the tomcat documentation for tomcat 7 and
> tomcat 8, which is basically the same.
> 
> I added the following to logging.properties
> handlers = 1catalina.org.apache.juli.AsyncFileHandler,
> 2localhost.org.apache.juli.AsyncFileHandler,
> 3manager.org.apache.juli.AsyncFileHandler,
> 4host-manager.org.apache.juli.AsyncFileHandler,
> java.util.logging.ConsoleHandler,
> 5request-dumper.org.apache.juli.FileHandler
> 
> # To this configuration >elow, 1request-dumper.org.apache.juli.FileHandler
> # also -eeds to be added to the handlers property near the top of the file
> 5request-dumper.org.apache.juli.FileHandler.level = INFO
> 5request-dumper.org.apache.juli.FileHandler.directory =
> ${catalina.base}/logs
> 5request-dumper.org.apache.juli.FileHandler.prefix = request-dumper.
> 5request-dumper.org.apache.juli.FileHandler.encoding = UTF-8
> 5request-dumper.org.apache.juli.FileHandler.formatter =
> org.apache.juli.VerbatimFormatter
> 
> org.apache.catalina.filters.RequestDumperFilter.level = INFO
> org.apache.catalina.filters.RequestDumperFilter.handlers =
> 5request-dumper.org.apache.juli.FileHandler
> 
> And I added this to the both the web.xml in the conf directory and the
> web.xml in my application. I tried one, the other and both at the same time.

Definitely remove everything you added from conf/web.xml. That will be a
disaster.

> 
> requestdumper
> 
> org.apache.catalina.filters.RequestDumperFilter
> 
> 
> 
> requestdumper
> *
> 
> 
> 
> When I start tomcat it creates the log file, however nothing ever gets
> printed in it. So it isn't working. I must be missing something. Is this
> the right way to do this?

What if you use "/*" as your url-pattern instead of "*"?

-chris

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



Re: Fwd: Re: At least one JAR was scanned for TLDs yet contained no TLDs.

2020-10-08 Thread Christopher Schultz
Raivo,

On 10/8/20 07:22, Raivo Rebane wrote:
> Hello
> 
> if I start standalone tomcat program looks like:
> 
> 17868 ?    Sl 0:02 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true
> -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M
> -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath
> /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar
> -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest
> -Djava.io.tmpdir=/opt/tomcat/latest/temp
> org.apache.catalina.startup.Bootstrap start
> 
> No jars is added to classpath

Please read the replies to this question you got two days ago. The
classpath does not matter.

-chris

> On 08.10.20 13:59, Raivo Rebane wrote:
> 
>>
>>
>>
>>  Forwarded Message 
>> Subject: Re: At least one JAR was scanned for TLDs yet contained
>> no TLDs.
>> Date: Thu, 8 Oct 2020 13:37:49 +0300
>> From: Raivo Rebane 
>> To: Martin Grigorov ,
>> users-get.123_...@tomcat.apache.org
>>
>>
>>
>> Hello
>>
>> I debaged the jars list and got following:
>>
>> 08-Oct-2020 13:27:07.240 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-parser.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-transcoder.jar].
>> Consider adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-gui-util.jar].
>> Consider adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-svggen.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-xml.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.241 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-awt-util.jar].
>> Consider adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-util.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-script.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-bridge.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> [file:/opt/tomcat/apache-tomcat-9.0.38/lib/batik-dom.jar]. Consider
>> adding the JAR to the
>> tomcat.util.scan.StandardJarScanFilter.jarsToSkip property in
>> CATALINA_BASE/conf/catalina.properties file.
>> 08-Oct-2020 13:27:07.242 FINE [main]
>> org.apache.jasper.servlet.TldScanner$TldScannerCallback.scan No TLD
>> files were found in
>> 

Re: Static context from server.xml no longer working after upgrade to tomcat 9.0.37

2020-10-08 Thread Christopher Schultz
Linda,

On 10/7/20 10:36, Haddix, Linda wrote:
> We are in the process of upgrading from Tomcat 8.0.36 to Tomcat 9.0.37
> for the samesite cookie issue.  We found very few differences in the
> version except for
> 
> a context (static)  in server.xml for static content now gives a 404 in
> tomcat.  I have checked the logs and it is getting past apache 2.4 to
> tomcat.
> 
> I have tried adding crossContext=”true” to all applications including
> static but it did not help.

You shouldn't need crossContext="true" unless your application includes
code like this:

  req.getRequestDispatcher("/otherapp/resource").forward(req,rsp);

> The only change made to server.xml is secretRequired=”false”

This should not affect anything about the context deployments, etc.

> I have seen a number of posts where other people have the same issue but
> I have not found any replies to the question.

I don't recall any such questions. References?

> Tomcat logs
> 
> 172.24.30.28 - - [07/Oct/2020:09:59:13 -0400] "GET
> /static/bp_images/5013678_RH.gif HTTP/1.1" 404 790
> 
> 172.24.30.28 - - [07/Oct/2020:09:59:13 -0400] "GET
> /static/bp_images/5013682_RH.gif HTTP/1.1" 404 790
> 
> 172.24.30.28 - - [07/Oct/2020:09:59:13 -0400] "GET
> /static/bp_images/5013936_RH.gif HTTP/1.1" 404 790

What does "DIR I:\" show?

> From server.xml
> 
>   autoDeploy="false" deployOnStartUp="true" >
> 
>     

Do you have another application deployed? You may want to use
 in the application instead of a whole extra 
just for this static content. It will be more flexible in the long run.

How are you launching Tomcat? Are you using a Windows Service or are you
running bin\startup.bat or similar?

If you are using the Windows Service, you should check the effective
service user and the permissions for I:\

This item appears in the changelog for Tomcat 9.0.23 (and 8.5.44):

"
Update: 63310: Update to Commons Daemon 1.2.0. This provides improved
support for Java 11. This also changes the user configured by the
Windows installer for the Windows service from Local System to the lower
privileged Local Service. (markt)
"

This item is unfortunately not present in the Migration Guide(s), but
probably should be.

-chris

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



Re: Is Tomcat7 supports HTTP2

2020-10-08 Thread Christopher Schultz
Martin,

On 10/8/20 02:35, Martin Grigorov wrote:
> Hi,
> 
> On Thu, Oct 8, 2020 at 9:32 AM Tosh, Bibhuti Bhusan (Bibhuti) <
> bt...@avaya.com> wrote:
> 
>> HI All,
>> I am an user of tomcat7 version. I wanted to know this version tomcat
>> 7.0.105 supports HTTP2 and CVE-2020-11996 is still applicable to tis
>> version. I did not any reference of tomcat7 supporting HTTP2 and so asking
>> this questions to community. Thanks in advance.
>>
> 
> No, HTTP/2 is available in 8.5.+

Notably, CVE-2020-11996 does not claim that Tomcat 7 is affected. CVEs
don't usually mention products that have already been EOL'd which is why
Tomcat 8.0 (for example) isn't mentioned. But Tomcat 7 is still
supported and isn't mentioned in the tracker, therefore it is not
vulnerable.

-chris

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



Re: completely automated (for real) Let's Encrypt on embedded Tomcat

2020-10-08 Thread Christopher Schultz
Garret,

On 10/7/20 13:12, Garret Wilson wrote:
> As always thanks for the discussion, Chris. More replies and a new idea
> below:
> 
> On 10/6/2020 2:45 PM, Christopher Schultz wrote:
>> …
>> What if your Docker container would just run certbot on launch?
> 
> But then I'm back to being a sysadmin, because the Docker container is
> like a little OS and I have to set up the OS, update it, install certbot
> if needed (based on the OS version!), ensure it's the certbot that has
> the bugfixes I want and behaves as I expect, install Tomcat on the OS,
> etc. I have to set up certbot with systemd or or whatever to run
> periodically. All that stuff goes into my Dockerfile. So I'm really
> doing the same thing as I would on a VM, except that Docker makes it
> easier to reproduce. But it's conceptually not much different than being
> sysadmin on a VM, then freezing the VM and duplicating that.

Building a Dockerfile makes you a sysadmin. If you were deploying a WAR
file into Elastic Beanstalk I might have more sympathy for your situation.

>> If you build the keystore in-memory, I'm not exactly sure what you'd
>> need to do in order to get Tomcat to bounce the SSLSocketFactory in that
>> way.
> 
> OK, I'll look into it. But it boggles my mind that an SSLSocketFactory
> would have a harder time using actual bytes of a certificate than it
> would loading it from disk.

I didn't say that. I said that Tomcat's reload() method re-reads the
configuration. If you use Tomcat embedded, then there is no
configuration, and therefore reload() has nothing to reload. You will
have to see what needs to be done, there. Perhaps you can re-set the
SSLSocketFactory and then call reload() which will re-build the
SSLContext, etc. and all will be well. I'm just not making any promises.

> Because once it loads it from disk, it has
> the bytes in memory, no? So the only problem would be the API—whether it
> was built to unnecessarily require disk storage, or if it allows a
> "hook" to provide the bytes at the point in the logic between
> loading-from-disk and using-the-cert.

Right.

>>> I have no idea what a PEM-encoded DER file is, but I'll certainly learn.
>> This:
>>
>> -BEGIN CERTIFICATE-
>> stuff
>> -END CERTIFICATE-
>>
> Ooh, that stuff. Yeah, I've definitely used that. I just never knew what
> it was. I never really got into the deep murky depths of certificates,
> but I guess now I'll have, seeing as that no one else in the last 20
> years has really made this easy.
> 
>>> I still don't get why files have to be involved. I pulled a DER file
>>> from S3.
>> Sorry. I think of that as a "file".
> 
> Ah, there's an important distinction to be made here. As developers we
> often say "file" when we talk about a bunch of bytes that has some
> coherent format — a JPEG file, an Ogg Vorbis file, a JSON file. But (and
> the specs only really started making this clear around the time XML
> became a spec, as least as far as I know) from another view it's only a
> file if it's stored in a file system. (I'll explain why below.) So
> really we can talk about an "XML document", for example, that may never
> be stored in a file — we may construct an XML DOM tree completely in
> memory and pass it to some other method.
> 
>>
>> So your web server is S3.
> 
> Ah, no!
> 
> S3 is a database. It could be PostgreSQL or Cassandra. It's a data
> store. In particular it's a key-value store. It stores things. It has a
> feature that allows you to set a configuration so that some web server
> will automatically serve the BLOBs from the S3 data store, along with
> some metadata. But is the web server "part of" S3? I'll bet not.

S3 has a web interface, so it's definitely a web server. You can say
it's a key-value store (which it is), but because you fetch objects from
it using HTTP GET, it's also a web server.

> Surely there is some pool of workers that pull data from the S3 data
> store and serves the data. I could probably write my own web server
> to do the same thing. But AWS makes it transparent; it's part of the
> infrastucture. I just provide the data and declaratively tell it what
> I want served. Then it is served. I don't have to configure a server.
> There is some server in the cloud.
> 
> But there's actually another step! Since I'm serving the site via
> CloudFront, the CloudFront layer (servers around the world in different
> countries!) actually connects to the web site serving the S3 data and
> /copies it to CloudFront/! So my data is actually being served to the
> end user by some CloudFront server, in some country closest to the user.
> Is this Tomcat? Is it NGINX? Is it Apache? I

Re: completely automated (for real) Let's Encrypt on embedded Tomcat

2020-10-06 Thread Christopher Schultz
James,

On 10/5/20 19:59, James H. H. Lampert wrote:
> I'm coming into this conversation late, so what I say could be
> completely irrelevant, but when I recently set up an independent (i.e.,
> not behind httpd) Tomcat server on one of our AWS EC2 instances, and
> could not get certbot to function at all, to save my life, I ended up
> using something called "LEGO."

Thanks for mentioning LEGO. Any time I've been mentioning certbot, you
can replace that with $your-favorite-acme-client.

> It *does* require one to shut the Tomcat server down during the
> renewal process (because it has to take over the port briefly), but
> it also *does* play nicely with a Tomcat server that's doing its own
> SSL.

You *should* be able to do this without stopping Tomcat, but it might
end up complicating other things. If you have a reverse proxy server,
this is trivial to avoid. If you are binding Tomcat directly to port 80,
this is not so easy.

Another option is to use DNS-based authentication where your web server
isn't involved.

-chris

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



Re: completely automated (for real) Let's Encrypt on embedded Tomcat

2020-10-06 Thread Christopher Schultz
Garret,

On 10/5/20 19:45, Garret Wilson wrote:
> On 10/5/2020 2:42 PM, Christopher Schultz wrote:
>> …
>> Sure, it can contain S3 credentials and you can pick-up your key and
>> certificate (or, better yet, the whole keystore) there, but at that
>> point you have "moved" the problem outside of Tomcat, right?
> 
> No, not at all. The major problems are:
> 
> 1. Generating the certificate automatically.
> 2. Feeding the certificate to Tomcat automatically.
> 
> If the "extra" thing I have to do is specify an environment variable
> with the name of the S3 bucket to use as a certificate state, then that
> is a teeny, tiny problem. That is not really even a problem.
> 
> Can you imagine if in my spring boot application I could run it using
> "java -jar my-app.jar --cert-work-bucket my-bucket" and it would just go
> get a certificate automatically?

What if your Docker container would just run certbot on launch?

>> You can have a "certificate renewal service" that writes to S3.
> 
> I want it built into my application as a module. You just include the
> module, specify the domain name (and maybe a couple of other details
> needed by RFC 8555, such as a contact email), and boom, it all happens
> automatically.
>
> Why does it have to be more difficult than that? It shouldn't be.

Fair enough.

>> I suppose you could put that directly into Tomcat, but Tomcat is not
>> likely to ship with an Amazon-specific feature built-into it.
> 
> 
> Read my original email. I never intended to put this directly into
> standalone Tomcat (although if you want to put it into Tomcat you're
> welcome to). I want to use this with an application running on embedded
> Tomcat. Spring Boot is a prime example. I'll just extend the Spring Boot
> embedded Tomcat module and extend/modify that as needed. If that
> requires modifying Tomcat code, fine.
> 
>> Another idea would be to use embedded Tomcat (or, at your suggestion,
>> Spring Boot) and fetch the keystore from some "standard" location of
>> your choosing. Again, that would be (appropriately, IMO) outside Tomcat
>> code.
> 
> That was always the intention. In my introduction to my original email I
> explained that the modern approach is moving away from something like
> standalone Tomcat to self-contained executables that run their own
> servers, whether embedded Tomcat or whatever. (I was late to the party,
> and even two years ago I wasn't getting it.)

I'm not sure I'd say "modern approach". It's certainly popular these
days, for sure.

>> 1. Does acme4j allow me to verify my certificate behind another port?
>>     (e.g. ElasticBeanstalk deploys a JAR behind NGINX port 5000 by
>>     default. I'm still reading RFC 8555 to find out if the ACME server
>>     has to connect back on a certain port for verification.)
>> 2. Once I have the Let's Encrypt certificate, can I convert to PKCS12
>>     for Tomcat completely in the application without shelling out to
>>     openssl or keytool? I'm hoping Bouncy Castle and/or acme4j-util will
>>     allow me to do that.
>> This can be done, but it's non-trivial. For example, Tomcat contains
>> code to package PEM-encoded DER files (good old OpenSSL-style =BEGIN
>> CERTIFICATE= things) into an in-memory keystore to configure JSSE.
>> It seems like it would be straightforward, but it turns out not to be in
>> all cases. YMMV.
> 
> Non-trivial as it may be, it /only needs to be done once/. If I have a
> converter, then I can use it a thousand times. A million times. And
> suddenly the deployment becomes a piece of cake.
> 
> In reality, today's style of handling SSL is what matches your
> description of "It seems like it would be straightforward, but it turns
> out not to be …". So why do we keep doing all this difficult, manual,
> tedious, not-trivial stuff to deploy certificates the hard way, when we
> could put our efforts into a single no-trivial task of making a
> converter so that Tomcat can use the Let's Encrypt certificates
> directly? We do it once. It's hard, but then everything else is easy. I
> don't get why we want to spend another decade doing it the hard way when
> we can spend one year on a different hard task and then do SSL the easy
> way for the other nine.
> 
> (The frustration isn't directed at you. It's just in general in software
> development I see the industry—why does the most basic of things have to
> be so difficult?)
> 
>> 3. Once I have the PKCS12, how do I feed it to the embedded Tomcat?
>> If it's a file on the disk, it's easy: just use the path.
> 
> Can I pass it in memory? If not, why not? How is memory l

Re: tomcat9 classpath

2020-10-06 Thread Christopher Schultz
Raivo,

Please don't email directly. Use the mailing list instead. (Apologies if
I emailed both you AND the list.)

On 10/6/20 14:59, Raivo Rebane wrote:
> How I undrestand is that these files is added to tomcat common classpath
> or does there are several classpaths ?

In Java there can be many ClassLoaders. Each ClassLoader has a
"classpath" of sorts: a list of places where it can load classes. The
word "classpath" is usually reserved for the classpath handed to the JVM
when it launches.

> if I add following line into catalina.properties file:
>
> shared.loader="/opt/tomcat/latest/lib/*.jar"
> Nothing changes

Nothing you add or remove from catlaina.properties will change what is
shown when you run "ps" and look at the command-line used to launch the JVM.

Fortunately, it doesn't matter. Tomcat will configure the "common" and
"shared" ClassLoaders with the correct list of JARs you specify in
catalina.properties, and those libraries will be available to the server
and/or your application(s). The fact that they are not in the "ps"
output for "-classpath [stuff]" does not matter.

-chris

> On 06.10.20 21:36, Christopher Schultz wrote:
>> Raivo,
>>
>> On 10/6/20 12:27, Raivo Rebane wrote:
>>> Hello
>>>
>>> I have following line in catalina.properties file where I want to add
>>> /opt/tomcat/latest/lib/*.jar to classpath
>>>
>>> But If I start Tomcat9 no jars appear in classpath.
>> Which classpath?
>>
>>> and line in catalina.properties is following:
>>>
>>> common.loader="/opt/tomcat/latest/lib/*.jar","/opt/tomcat/latest/bin/*.jar"
>>>
>>>
>>> Tomcat runs without a;most jars
>>>
>>> 21307 ?    Sl 0:02 /usr/lib/jvm/default-java/bin/java
>>> -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties
>>>
>>> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
>>> -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true
>>> -Djdk.tls.ephemeralDHKeySize=2048
>>> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
>>> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M
>>> -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath
>>> /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar
>>>
>>> -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest
>>> -Djava.io.tmpdir=/opt/tomcat/latest/temp
>>> org.apache.catalina.startup.Bootstrap start
>> Are you talking about the -classpath specified in the JVM launch? This
>> is entirely expected.
>>
>> Once Tomcat starts up, another ClassLoader is initialized with the JAR
>> files in common.loader in it. You won't see that on the command-line.
>>
>>> The list of directory /opt/tomcat/latest/lib/*.jar is here:
>>>
>>> -rw-r-x--- 1 tomcat tomcat   13342 sept  10 11:23
>>> /opt/tomcat/latest/lib/annotations-api.jar*
>>> -rw-r-x--- 1 tomcat tomcat   54652 sept  10 11:23
>>> /opt/tomcat/latest/lib/catalina-ant.jar*
>>> -rw-r-x--- 1 tomcat tomcat  124406 sept  10 11:23
>>> /opt/tomcat/latest/lib/catalina-ha.jar*
>>> -rw-r-x--- 1 tomcat tomcat 1699600 sept  10 11:23
>>> /opt/tomcat/latest/lib/catalina.jar*
>>> -rw-r-x--- 1 tomcat tomcat   63246 sept  10 11:23
>>> /opt/tomcat/latest/lib/catalina-ssi.jar*
>>> -rw-r-x--- 1 tomcat tomcat   78788 sept  10 11:23
>>> /opt/tomcat/latest/lib/catalina-storeconfig.jar*
>>> -rw-r-x--- 1 tomcat tomcat  347015 sept  10 11:23
>>> /opt/tomcat/latest/lib/catalina-tribes.jar*
>>> -rw-r-x--- 1 tomcat tomcat 2989263 sept  10 11:23
>>> /opt/tomcat/latest/lib/ecj-4.15.jar*
>>> -rw-r-x--- 1 tomcat tomcat   91104 sept  10 11:23
>>> /opt/tomcat/latest/lib/el-api.jar*
>>> -rw-r-x--- 1 tomcat tomcat  171308 sept  10 11:23
>>> /opt/tomcat/latest/lib/jasper-el.jar*
>>> -rw-r-x--- 1 tomcat tomcat  564673 sept  10 11:23
>>> /opt/tomcat/latest/lib/jasper.jar*
>>> -rw-r-x--- 1 tomcat tomcat   28549 sept  10 11:23
>>> /opt/tomcat/latest/lib/jaspic-api.jar*
>>> -rw-r-x--- 1 tomcat tomcat   63811 sept  10 11:23
>>> /opt/tomcat/latest/lib/jsp-api.jar*
>>> -rw-r-x--- 1 tomcat tomcat  283767 sept  10 11:23
>>> /opt/tomcat/latest/lib/servlet-api.jar*
>>> -rw-r-x--- 1 tomcat tomcat   11649 sept  10 11:23
>>> /opt/tomcat/latest/lib/tomcat-api.jar*
>>> -rw-r-x--- 1 tomcat tomcat  908183 sept  10 11:23
>>> /opt/tomcat/latest/li

Re: Some functions not working when using a particular dns after tomcat upgrade from 6.x to 8.5.x

2020-10-06 Thread Christopher Schultz
Larvi,

On 10/6/20 14:36, Larvi wrote:
> Chris,
> 
> I know this issue is strange and I too dont know what exactly is going on,
> for now I am only able to replicate this issue and find a workaround for
> this, so let me explain how I am able to replicate this issue.
> 
> Case 1:
> When I login to the application using the dns for the first time it works
> fine

What does "login to the application using the dns" mean?

I usually use something like username+password to login to an application.

> as for the first time we redirect to another login application that
> after authentication redirect us to our direct url( which works fine).

So... single-sign-on or something like that?

What application / API / technology are you using for this
authentication hand-off?

> But when I open the application again using the same dns url it picks
> up data from cookies and some of the functionality does not work.

Which cookies?

> Case 2:
> When I login to another application which uses the same login application
> as I use, and then open our application from the dns url then this issue
> occurs.
> 
> I would also like to add that when I use the other dns url

What "other dns url"? Please be very specific.

> for the same application it works fine for both the cases I mentioned
> above. And we tried to clear our browser cache, cookies and also
> tomcat's work/Catalina/localhost directories then rebouncing the
> tomcat. But we still are having this issue.
Cookies are usually only sent by the browser if everything matches.

Try showing the developer console in your web browser and going through
the login process. Check each request for request and response headers,
checking to see that the cookies and other stuff you expect are in
there. Also look at the "console", as you might see some warnings.

I'm specifically thinking of an incorrect "samesite" cookie configuration.

-chris

> On Tue, Oct 6, 2020, 23:45 Christopher Schultz 
> wrote:
> 
>> Larvi,
>>
>> On 10/6/20 03:28, Larvi wrote:
>>> Can you please help me with this.
>>
>> Can you give some examples? It's not easy to understand what you are
>> doing and what is happening to you.
>>
>> -chris
>>
>>> On Tue, Sep 29, 2020 at 11:51 AM Larvi Boy  wrote:
>>>
>>>> Hi Chris,
>>>>
>>>> Yes, When I did $ host [hostname], I get the IP address that I am trying
>>>> to use.
>>>>
>>>> Below are the Engine and Host configurations from server.xml.
>>>>
>>>> 
>>>>
>>>>   
>>>>   
>>>>
>>>>   
>>>>   
>>>> 
>>>> >>>    resourceName="UserDatabase"/>
>>>>   
>>>>
>>>>   >>> unpackWARs="true" autoDeploy="true">
>>>>
>>>> 
>>>> 
>>>>
>>>> 
>>>> >>> directory="logs"
>>>>prefix="localhost_access_log" suffix=".txt"
>>>>pattern="%v %h %l %S %u %t %r %s %b" />
>>>>
>>>>   
>>>> 
>>>>
>>>> On Mon, Sep 28, 2020 at 8:41 PM Christopher Schultz <
>>>> ch...@christopherschultz.net> wrote:
>>>>
>>>>>> Larvi,
>>>>>>
>>>>>> On 9/28/20 10:04, Larvi Boy wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> When I try to login to out web gui via direct link, it is working
>> fine
>>>>> but
>>>>>>> when I used the dns url, for first time it works fine as for the
>> first
>>>>> time
>>>>>>> we are redirected to our login page which redirects us back to my
>>>>> direct
>>>>>>> link, but if we create another window with same dns link, some
>> buttons
>>>>> in
>>>>>>> the jsp are not working. We cleared the cache but didn't help.
>>>>>>>
>>>>>>> I checked the application logs but there were no logs for the actions
>>>>> that
>>>>>>> should occur after click and I checked tomcat catalina.out and
>>>>> localhost
>>>>>>> logs and there is no error there.
>>>>>>>
>>>>>>> We have 2 dns urls but we are not facing this issue with the other
>> dns
>>>>> url.
>>>>>>>
>>>>>>> Can you please help me on this.
>>>>>>>
>>>>>>> Please ask if more information is needed.
>>>>>>
>>>>>> Can you give some examples? What happens if you:
>>>>>>
>>>>>>> $ host [hostname]
>>>>>>
>>>>>> Do you get the same IP address that you are trying to use?
>>>>>>
>>>>>> Please post your  and  configuration from server.xml.
>>>>>> Remove any secrets you may have in there.
>>>>>>
>>>>>> -chris
>>>>>
>>>>>
>>> Thanks,
>>> Larvi
>>>
>>
>> -
>> 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: tomcat9 classpath

2020-10-06 Thread Christopher Schultz
Raivo,

On 10/6/20 12:27, Raivo Rebane wrote:
> Hello
> 
> I have following line in catalina.properties file where I want to add
> /opt/tomcat/latest/lib/*.jar to classpath
> 
> But If I start Tomcat9 no jars appear in classpath.

Which classpath?

> and line in catalina.properties is following:
> 
> common.loader="/opt/tomcat/latest/lib/*.jar","/opt/tomcat/latest/bin/*.jar"
> 
> Tomcat runs without a;most jars
> 
> 21307 ?    Sl 0:02 /usr/lib/jvm/default-java/bin/java
> -Djava.util.logging.config.file=/opt/tomcat/latest/conf/logging.properties
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true
> -Djdk.tls.ephemeralDHKeySize=2048
> -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
> -Dorg.apache.catalina.security.SecurityListener.UMASK=0027 -Xms512M
> -Xmx1024M -server -XX:+UseParallelGC -Dignore.endorsed.dirs= -classpath
> /opt/tomcat/latest/bin/bootstrap.jar:/opt/tomcat/latest/bin/tomcat-juli.jar
> -Dcatalina.base=/opt/tomcat/latest -Dcatalina.home=/opt/tomcat/latest
> -Djava.io.tmpdir=/opt/tomcat/latest/temp
> org.apache.catalina.startup.Bootstrap start

Are you talking about the -classpath specified in the JVM launch? This
is entirely expected.

Once Tomcat starts up, another ClassLoader is initialized with the JAR
files in common.loader in it. You won't see that on the command-line.

> The list of directory /opt/tomcat/latest/lib/*.jar is here:
> 
> -rw-r-x--- 1 tomcat tomcat   13342 sept  10 11:23
> /opt/tomcat/latest/lib/annotations-api.jar*
> -rw-r-x--- 1 tomcat tomcat   54652 sept  10 11:23
> /opt/tomcat/latest/lib/catalina-ant.jar*
> -rw-r-x--- 1 tomcat tomcat  124406 sept  10 11:23
> /opt/tomcat/latest/lib/catalina-ha.jar*
> -rw-r-x--- 1 tomcat tomcat 1699600 sept  10 11:23
> /opt/tomcat/latest/lib/catalina.jar*
> -rw-r-x--- 1 tomcat tomcat   63246 sept  10 11:23
> /opt/tomcat/latest/lib/catalina-ssi.jar*
> -rw-r-x--- 1 tomcat tomcat   78788 sept  10 11:23
> /opt/tomcat/latest/lib/catalina-storeconfig.jar*
> -rw-r-x--- 1 tomcat tomcat  347015 sept  10 11:23
> /opt/tomcat/latest/lib/catalina-tribes.jar*
> -rw-r-x--- 1 tomcat tomcat 2989263 sept  10 11:23
> /opt/tomcat/latest/lib/ecj-4.15.jar*
> -rw-r-x--- 1 tomcat tomcat   91104 sept  10 11:23
> /opt/tomcat/latest/lib/el-api.jar*
> -rw-r-x--- 1 tomcat tomcat  171308 sept  10 11:23
> /opt/tomcat/latest/lib/jasper-el.jar*
> -rw-r-x--- 1 tomcat tomcat  564673 sept  10 11:23
> /opt/tomcat/latest/lib/jasper.jar*
> -rw-r-x--- 1 tomcat tomcat   28549 sept  10 11:23
> /opt/tomcat/latest/lib/jaspic-api.jar*
> -rw-r-x--- 1 tomcat tomcat   63811 sept  10 11:23
> /opt/tomcat/latest/lib/jsp-api.jar*
> -rw-r-x--- 1 tomcat tomcat  283767 sept  10 11:23
> /opt/tomcat/latest/lib/servlet-api.jar*
> -rw-r-x--- 1 tomcat tomcat   11649 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-api.jar*
> -rw-r-x--- 1 tomcat tomcat  908183 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-coyote.jar*
> -rw-r-x--- 1 tomcat tomcat  322469 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-dbcp.jar*
> -rw-r-x--- 1 tomcat tomcat   69258 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-cs.jar*
> -rw-r-x--- 1 tomcat tomcat   75197 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-de.jar*
> -rw-r-x--- 1 tomcat tomcat  104921 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-es.jar*
> -rw-r-x--- 1 tomcat tomcat  165365 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-fr.jar*
> -rw-r-x--- 1 tomcat tomcat  187546 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-ja.jar*
> -rw-r-x--- 1 tomcat tomcat  188011 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-ko.jar*
> -rw-r-x--- 1 tomcat tomcat   50041 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-pt-BR.jar*
> -rw-r-x--- 1 tomcat tomcat   38857 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-ru.jar*
> -rw-r-x--- 1 tomcat tomcat  171815 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-i18n-zh-CN.jar*
> -rw-r-x--- 1 tomcat tomcat  149747 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-jdbc.jar*
> -rw-r-x--- 1 tomcat tomcat   36339 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-jni.jar*
> -rw-r-x--- 1 tomcat tomcat  196936 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-util.jar*
> -rw-r-x--- 1 tomcat tomcat  224527 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-util-scan.jar*
> -rw-r-x--- 1 tomcat tomcat  232989 sept  10 11:23
> /opt/tomcat/latest/lib/tomcat-websocket.jar*
> -rw-r-x--- 1 tomcat tomcat   39727 sept  10 11:23
> /opt/tomcat/latest/lib/websocket-api.jar*
> 
> Looking forwrd

These JAR files should be visible to the "common" ClassLoader you have
defined.

It sounds like you are having some other problem and have decided it is
a problem with the classpath. Instead of debugging the "classpath
problem", why not describe the actual problem you are having?

-chris

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

Re: Some functions not working when using a particular dns after tomcat upgrade from 6.x to 8.5.x

2020-10-06 Thread Christopher Schultz
Larvi,

On 10/6/20 03:28, Larvi wrote:
> Can you please help me with this.

Can you give some examples? It's not easy to understand what you are
doing and what is happening to you.

-chris

> On Tue, Sep 29, 2020 at 11:51 AM Larvi Boy  wrote:
> 
>> Hi Chris,
>>
>> Yes, When I did $ host [hostname], I get the IP address that I am trying
>> to use.
>>
>> Below are the Engine and Host configurations from server.xml.
>>
>> 
>>
>>   
>>   
>>
>>   
>>   
>> 
>> >resourceName="UserDatabase"/>
>>   
>>
>>   > unpackWARs="true" autoDeploy="true">
>>
>> 
>> 
>>
>> 
>>     > directory="logs"
>>prefix="localhost_access_log" suffix=".txt"
>>pattern="%v %h %l %S %u %t %r %s %b" />
>>
>>   
>> 
>>
>> On Mon, Sep 28, 2020 at 8:41 PM Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
>>>> Larvi,
>>>>
>>>> On 9/28/20 10:04, Larvi Boy wrote:
>>>>> Hi,
>>>>>
>>>>> When I try to login to out web gui via direct link, it is working fine
>>> but
>>>>> when I used the dns url, for first time it works fine as for the first
>>> time
>>>>> we are redirected to our login page which redirects us back to my
>>> direct
>>>>> link, but if we create another window with same dns link, some buttons
>>> in
>>>>> the jsp are not working. We cleared the cache but didn't help.
>>>>>
>>>>> I checked the application logs but there were no logs for the actions
>>> that
>>>>> should occur after click and I checked tomcat catalina.out and
>>> localhost
>>>>> logs and there is no error there.
>>>>>
>>>>> We have 2 dns urls but we are not facing this issue with the other dns
>>> url.
>>>>>
>>>>> Can you please help me on this.
>>>>>
>>>>> Please ask if more information is needed.
>>>>
>>>> Can you give some examples? What happens if you:
>>>>
>>>>> $ host [hostname]
>>>>
>>>> Do you get the same IP address that you are trying to use?
>>>>
>>>> Please post your  and  configuration from server.xml.
>>>> Remove any secrets you may have in there.
>>>>
>>>> -chris
>>>
>>>
> Thanks,
> Larvi
> 

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



Re: completely automated (for real) Let's Encrypt on embedded Tomcat

2020-10-05 Thread Christopher Schultz
Garret,

On 10/5/20 12:21, Garret Wilson wrote:
> Thank you so much for replying, Chris. Responses below.
> 
> On 10/5/2020 8:53 AM, Christopher Schultz wrote:
>> Microservices won't work the way you want with Let's Encrypt. You have
>> two options:
>>
>> 1. Hit Let's Encrypt every time you launch a new instance of the
>> microservice to deploy a new certificate
>>
>> 2. Handle the certificate provisioning elsewhere (e.g. ELB)
>>
>> #1 just won't work. LE won't re-issue a certificate more frequently than
>> every 6 weeks or something like that. So that really leaves you with #2.
> 
> It's good to know about the six-week limit, but you discarded #1 too
> quickly. Can't the microservice simply store the credentials in S3 or
> one of a hundred other data stores? (Note that I care less about
> "microservices" as such at the moment. I just want a turnkey deployment
> of a single application for now. But the idea is the same.)

Sure, it can contain S3 credentials and you can pick-up your key and
certificate (or, better yet, the whole keystore) there, but at that
point you have "moved" the problem outside of Tomcat, right?

You can have a "certificate renewal service" that writes to S3.

I suppose you could put that directly into Tomcat, but Tomcat is not
likely to ship with an Amazon-specific feature built-into it.

I could imagine a LifecycleListener which has been written with this
kind of thing in mind. (I'm not sure that a LifecycleListener would be
able to intervene early enough in the process of a non-embedded Tomcat
startup to do this, btw; just an idea.)

Another idea would be to use embedded Tomcat (or, at your suggestion,
Spring Boot) and fetch the keystore from some "standard" location of
your choosing. Again, that would be (appropriately, IMO) outside Tomcat
code.

>> What you really want is for the orchestrator to provide the certificate
>> and key to the nodes as they come on-line.
> 
> Look these "orchestrators" are a configuration nightmare at the moment.
> They end up being worse than my just configuring a CentOS machine from
> scratch. Plus I have to pay for all those extra services. Read
> https://leebriggs.co.uk/blog/2019/04/13/the-fargate-illusion.html and
> try not to shudder.
> 
>> So instead of trying to get LE to work with Tomcat (which does work, but
>> requires some care and feeding), maybe we should try to get Tomcat to
>> load its crypto material from other places.
> 
> There is already a Java library (https://github.com/shred/acme4j) for
> talking to Let's Encrypt. It sounds like it does everything I need. I'll
> need to investigate more, but here are my initial doubts:
> 
> 1. Does acme4j allow me to verify my certificate behind another port?
>    (e.g. ElasticBeanstalk deploys a JAR behind NGINX port 5000 by
>    default. I'm still reading RFC 8555 to find out if the ACME server
>    has to connect back on a certain port for verification.)
> 2. Once I have the Let's Encrypt certificate, can I convert to PKCS12
>    for Tomcat completely in the application without shelling out to
>    openssl or keytool? I'm hoping Bouncy Castle and/or acme4j-util will
>    allow me to do that.

This can be done, but it's non-trivial. For example, Tomcat contains
code to package PEM-encoded DER files (good old OpenSSL-style =BEGIN
CERTIFICATE= things) into an in-memory keystore to configure JSSE.
It seems like it would be straightforward, but it turns out not to be in
all cases. YMMV.

> 3. Once I have the PKCS12, how do I feed it to the embedded Tomcat?

If it's a file on the disk, it's easy: just use the path.

> Chris, where can I get more information on the latter questions about
> getting this certificate to Tomcat once I have it?

This mailing list is a good place to start (and likely finish).

>> One way to do that would be with e.g. Amazon's key storage service. I'm
>> not familiar with that. I know it can store various types of keys; not
>> sure about certificates and if we can pull a private key out of it.
> 
> I think your idea of storing this stuff elsewhere is a good first
> stepping stone to get to where I want to go.
> 
> Just to get the ball rolling, I could manually run some Let's Encrypt
> client, and then store the certificate in S3. Then the first component I
> would write would be steps #2 and #3 above. I am already familiar with
> the AWS Java library, so I could quickly figure out how to pull the
> certificates off S3. But I need your help in finding out how to convert
> them to PKCS12 (or whatever; this is new territory for me) on the fly
> and feed them to the embedded Tomcat.

Go back to my presentation on Let's Encrypt and you'll see how to use
openssl to convert to a keystore 

Re: completely automated (for real) Let's Encrypt on embedded Tomcat

2020-10-05 Thread Christopher Schultz
Garret,

On 10/4/20 14:04, Garret Wilson wrote:
> Hi, everyone. I'm back already. (I had intended to leave the list to
> focus my efforts elsewhere, but … here I am again.)
> 
> I just realized there is a big SSL problem for small applications, and I
> want to fix it. First a little review of where we are.
> 
> Servlet containers are becoming less important and less desirable in
> today's world, because we don't want to deploy and maintain some sort of
> high-level container infrastructure (in the Java EE container sense, not
> the Docker sense) just to deploy an application in it. Modern
> distributed micrososervice applications have a bunch of
> service/worker/agent application that are identical and redundant. You
> spin up as many as you need; if some go down, you (or an orchestrator)
> spins up others.

Microservices won't work the way you want with Let's Encrypt. You have
two options:

1. Hit Let's Encrypt every time you launch a new instance of the
microservice to deploy a new certificate

2. Handle the certificate provisioning elsewhere (e.g. ELB)

#1 just won't work. LE won't re-issue a certificate more frequently than
every 6 weeks or something like that. So that really leaves you with #2.

What you really want is for the orchestrator to provide the certificate
and key to the nodes as they come on-line. This represents a bit of a
security issue, but not any moreso than any node trying to connect to
the orchestrator in the first place IMHO.

So instead of trying to get LE to work with Tomcat (which does work, but
requires some care and feeding), maybe we should try to get Tomcat to
load its crypto material from other places.

One way to do that would be with e.g. Amazon's key storage service. I'm
not familiar with that. I know it can store various types of keys; not
sure about certificates and if we can pull a private key out of it.

Honestly, your best bet would probably be to use ELB and just pay for
it. You only pay for data-transfer, so a dormant ELB costs you virtually
nothing.

Instead of spinning-up an EC2 instance for your service, maybe you
should be looking at Lambda instead. You can probably get your costs
down more that way than trying to eliminate the ELB.

BTW, if your instance isn't running at all (e.g. the orchestrator has
decided that zero nodes are required), what do clients contact to make
that initial connection for the orchestrator to spin-up that first instance?

> For this reason libraries like Spring Boot allow you to deploy your Java
> application as a standalone JAR with embedded Tomcat. The JAR represents
> the completely independent application. You just throw it on a node and
> it runs and provides a web server or whatever. So we we should be able
> to throw a Spring Boot JAR on something like AWS Elastic Beanstalk and
> it just runs. I found out it is far from that simple, and SSL is one of
> the major problems.
> 
> There seem to be two ways to get SSL support. On something like AWS
> Elastic Beanstalk, you deploy a load balancer in front of your EC
> instances. Elastic Beanstalk will (using the AWS Route 53 DNS) configure
> SSL to the load balancer, spin up EC instances as needed (each running
> your standalone JAR), and connect the load balancer to the EC instances,
> all in a (sort of) automated fashion. But note that the SSL endpoint is
> the load balancer, and the load balancer costs money! Even if you're
> just running just a single standalone JAR instance requiring a single EC
> instance, that load balancer sits there and drains cash. Significant
> cash if you just want to run a little program with SSL support.
> 
> What's the other option to deploy a standalone JAR? Configure an AWS EC
> instance (or a VM with another provider), configure certbot, configure
> Tomcat, save some files locally on the machine, etc. All this manual
> work. I just want to run the standalone JAR! In short, if I have a
> standalone program I want to run, I either have to configure and
> maintain a VM like I did in the year 2000, or get into the nightmare of
> Kubernetes-like orchestration with the endless configurations and/or the
> high costs.
> 
> I propose to create a module that integrates with embedded Tomcat that:
> 
> 1. You indicate what domain you're hosting for (as part of the
>    application configuration or as an environment variable when
>    deployed, for example).
> 2. When your application starts running, it automatically connects to
>    Let's Encrypt using RFC 8555 (or whatever is needed) and requests a
>    certificate, based upon the IP address it's running on.
> 3. The module exposes the correct HTTP paths and/or connects to a
>    configured DNS as needed for validation.
> 4. The module receives the certificates and caches them in memory or in
>    a temporary file as needed and provides them to Tomcat; Tomcat now
>    is serving using SSL/TLS.
> 5. If the application dies, who cares? You start up another one. It
>    automatically does the same thing (on 

Re: File size truncated at 1.4GB during download from Tomcat WebApp

2020-10-03 Thread Christopher Schultz
Mauro,

On 10/3/20 08:47, Mauro Tridici wrote:
> Dear Users,
> 
> I’m struggling with the problem mentioned in this mail subject.
> When I try to download a 5GB sized file using two different tomcat web
> applications on two different virtual machines, I noticed that the
> browser download window shows a wrong file size (please take a look to
> the attached picture).
> Download starts regularly but it never ends.
> 
> I tried to download different files using different web browsers, but
> nothing changed.
> It seems that this problem is not related to the web applications (as I
> said, I’m testing two applications) and it is not related to a specific
> tomcat version.
> 
> I’m a “tomcat newbie”, could you please help me to understand the cause
> of this issue?
> You can find below some additional information about virtual machines,
> os and tomcat.
> 
> *1) virtual machine “serverA"*
> 
> OS: CentOS Linux release 7.8.2003
> 
> TOMCAT: 
> Server version: Apache Tomcat/7.0.76
> Server built:   Mar 17 2020 23:48:55 UTC
> Server number:  7.0.76.0
> OS Name:        Linux
> OS Version:     3.10.0-1127.8.2.el7.x86_64
> Architecture:   amd64
> JVM Version:    1.8.0_252-b09
> JVM Vendor:     Oracle Corporation
> 
> *2) virtual machine “serverB”*
> 
> OS: CentOS Linux release 7.8.2003
> 
> TOMCAT:
> Server version: Apache Tomcat/8.5.56
> Server built:   Jun 3 2020 20:18:30 UTC
> Server number:  8.5.56.0
> OS Name:        Linux
> OS Version:     3.10.0-1127.8.2.el7.x86_64
> Architecture:   amd64
> JVM Version:    1.8.0_252-b09
> JVM Vendor:     Oracle Corporation
> 
> 
> Thank you in advance,
> Mauro

Can you observe the HTTP response headers sent by the server along with
the file?

Also, how are you sending the file(s) from the application to the
client? Are you using sendfile? Are you using the DefaultServlet? Or do
you have your own code which reads the file and writes it to the client?

Does the download always stop at the same point (byte count), or it is
different each time?

My guess is:

1. The code is in your application (or at least, not using Tomcat's code
at all)

2. The code uses "int" variable to track the file size / set
Content-Length response header

3. The file size is 5.4GiB

4. 5.4 GiB will overflow a 32-bit int by 3.4GiB resulting in a value of
+1.4GiB final value

5. This value is being send to the client in the Content-Length header

6. The client is terminating the download after 1.4GiB (respecting the
Content-Length header)

-chris

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



Re: Virtual event focussed on Tomcat Security

2020-10-01 Thread Christopher Schultz
Raghu,

On 9/30/20 10:35, Mysore, Raghunath wrote:
> This plan about Tomcat security is very nice. We look forward to the 
> meetings. 
>
> Could we have a session related to " Best practices for using  Tomcat
> +  (Apache Web Server) Forward Proxy (FP) combo in a real production
> environment "  where an application hosted in Tomcat (web) container,
> targets a  destination system in the internet, through the FP ?
There are some presentations already on our "presentations" page that
might address some of your questions. Is there something specific that
is missing?

http://tomcat.apache.org/presentations.html

> The application communicates with the destination system on a TLS
> channel. The FP is placed in a perimeter zone.   The role of FP is to
> route the intranet traffic to the destination system in internet.

This sounds like a fairly specific use-case. Are you looking for help in
building such a system, or some suggestions for making sure that it's
secure, high-performance, etc.?

> Is there any generalized document that makes assessment (and
> recommendations) of a Tomcat plus a Forward Proxy combo, in a real
> word set up ?
No, but it would probably be an interesting subject for a presentation.
Maybe you could work with others in the community to develop such a
presentation and in fact present it at an upcoming conference!

-chris

> -Original Message-
> From: Maarten van Hulsentop  
> Sent: Wednesday, September 30, 2020 3:10 AM
> To: Tomcat Users List 
> Subject: Re: Virtual event focussed on Tomcat Security
> 
> Hi Mark,
> 
> This sounds like a great idea to me. Security is a very important topic, and 
> the maturity of the Tomcat makes it a very secure choice for users. I am sure 
> a lot of people will be interested to join in.
> 
> What is not completely clear to me on this event; would this event be 
> focussed on improving the security of Tomcat from within (as a Hackathon 
> suggests)? Like trying to find security flaws/improvements and get them fixed.
> or is this meant to be an educational event where information is shared about 
> secure setups/hardening of the Tomcat in production systems? Or a little of 
> both?
> 
> For the educational/hardening aspect, it could be nice to team up 
> with/involve OWASP?
> 
> I am surely interested to pitch in on this topic!
> 
> Kind regards,
> 
> Maarten van Hulsentop
> 
> Op di 29 sep. 2020 om 13:26 schreef Mark Thomas :
> 
>> Hi all,
>>
>> We (the Tomcat community) have some funding from Google to help us 
>> improve Tomcat security. Our original plan was to use the funding to 
>> support an in-person security focussed hackathon. As you would expect, 
>> those plans are on hold for now. We would, therefore, like to explore 
>> the possibility of doing something virtually.
>>
>> The purpose of this email is to gather input from the community about 
>> what such an event should look like. With that input we can put 
>> together a plan for the event. So, over to you. What would your ideal 
>> virtual event focussed on Tomcat Security look like?
>>
>> Thanks,
>>
>> 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
> 

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



Re: Append content to OutputStream after RequestDispatcher#forward

2020-09-29 Thread Christopher Schultz
Nicolò,

On 9/29/20 05:31, Nicolò Boschi wrote:
> I would like to know how to append (or prepend) some content in a Servlet,
> after RequestDispatcher#forward is called.
> 
> Example code:
> 
> class MyServlet extends HttpServlet {
> 
> 
> @Override
> public void doGet(HttpServletRequest request, HttpServletResponse
> response)
> throws ServletException, IOException {
> 
> final String finalUri = ... // compute some resource URI;
> RequestDispatcher resource = request.getRequestDispatcher(finalUri);
> 
> response.getWriter().append("prepend string");
> resource.forward(request, response);
> }
> 
> }

If you want to add content before/after the target, why not use
include() instead of forward()?

-chris

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



Re: HTTP2: memory filled up fast on increasing the connections to 1000/2000 (Embedded tomcat 9.0.38)

2020-09-28 Thread Christopher Schultz
Arshiya,

On 9/28/20 12:58, Arshiya Shariff wrote:
> With 200 threads(users) , ramp up duration of 2 seconds , loop count
> 80 and by sending 1000 http2 requests/sec from JMeter Client to an
> embedded tomcat application we did not observe any memory issue , but
> on sending 1000 http2 requests/sec with 2000 or 1000 users from
> JMeter , the application's heap space of 20 GB is occupied in 2
> minutes and after 2 full GCs the memory clears and comes down to 4GB
> (expected) .

So a full GC releases the memory?

> Embedded tomcat Version:9.0.38
> Max Threads : 200
> All other properties are the tomcat defaults.
> 
> Why is tomcat not able to process many connections ?

What evidence is there that Tomcat cannot process that many connections?
You said above the only concern was used-heap space.

If you have 200 threads, then you can only handle 200 active requests at
a time. If you need to process 2000 requests *simultaneously*, then you
need 2000 threads.

If you only need 2000 *users* at the "same time", then 200 threads
should be able to handle the load, depending upon the application's
performance characteristics.

> Why is the memory filled when the connections are increased, are
> there any parameters to tune connections ?

Are you using HttpSessions?

-chris

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



Re: Some functions not working when using a particular dns after tomcat upgrade from 6.x to 8.5.x

2020-09-28 Thread Christopher Schultz
Larvi,

On 9/28/20 10:04, Larvi Boy wrote:
> Hi,
> 
> When I try to login to out web gui via direct link, it is working fine but
> when I used the dns url, for first time it works fine as for the first time
> we are redirected to our login page which redirects us back to my direct
> link, but if we create another window with same dns link, some buttons in
> the jsp are not working. We cleared the cache but didn't help.
> 
> I checked the application logs but there were no logs for the actions that
> should occur after click and I checked tomcat catalina.out and localhost
> logs and there is no error there.
> 
> We have 2 dns urls but we are not facing this issue with the other dns url.
> 
> Can you please help me on this.
> 
> Please ask if more information is needed.

Can you give some examples? What happens if you:

$ host [hostname]

Do you get the same IP address that you are trying to use?

Please post your  and  configuration from server.xml.
Remove any secrets you may have in there.

-chris

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



Re: Connection header override

2020-09-28 Thread Christopher Schultz
Mark,

On 9/28/20 03:48, Mark Thomas wrote:
> On 28/09/2020 08:33, Mark Thomas wrote:
>> On 27/09/2020 00:07, Pawel Veselov wrote:
>>> Hello!
>>>
>>> Tomcat 9.0.x
>>>
>>> I'd like to force connection closure on some endpoints.
>>
>> Why? Generally, this is something that should not be an application concern.
>>
>>> I'm trying this on a simple JSP page.
>>> If I call response.setHeader("Connection","close"), I see that the
>>> response has "Connection: close, keep-alive".
>>> I assume Tomcat inserts the keep-alive part. It looks like the browsers
>>> still close the connection based on this, but I was wondering if it's
>>> possible to have Tomcat honor the header value set by the application.
>>
>> The most recent discussion on this topic was whether or not Tomcat
>> should block any attempt by an application to manipulate the Connection
>> header. The consensus was leaning towards implementing a block but
>> no-one has implemented it yet.
>>
>> See https://github.com/apache/tomcat/pull/277
>>
>> I did wonder if this was a regression introduced by some clean-up in the
>> handling of the Connection header a little while ago but it appears not.
>> Note that Tomcat will only add this header for HTTP/1.0 requests.
>> Separately, you may also see a "Keep-Alive" header for HTTP/1.1 requests.
> 
> Testing shows that isn't right - I was mis-reading the code. You will
> see this with HTTP/1.1 requests where the client explicitly sends a
> "Connection: keep-alive header".
> 
> I'm currently working on expanding the unit tests to cover this
> (although I'd still like to know why the app needs to close the connection).

One reason may be to "punish" a client for misbehaving in some way (e.g.
lots of failed logins, etc.). It's not much of a punishment, but forcing
a fresh TCP/IP and TLS handshake will slow down a brute-force script a bit.

-chris

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



Re: Adding regular expression support to CORS filter

2020-09-27 Thread Christopher Schultz
Carsten,

On 9/27/20 05:53, Carsten Klein wrote:
> Any comments on that? Is it worth preparing a PR?

Regular expressions are fairly expensive.

If there is a way to build the code such that some subset of wildcards
can be serviced without regex (and of course exact matches without using
regex), then I'm at least a +0 on this.

It may seem like over-engineering, but maybe creating a Matcher
interface and a Factory (I know, I know) which produces Matchers which
implement the optimal strategy for a particular value would be a good
way to do this.

A single matcher could be used for really simple values and maybe a
MultipleMatcher could be used for multiple different value-checks.
Something like that will likely lead to the highest-performing filter
processing.

-chris

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



Re: Connection header override

2020-09-27 Thread Christopher Schultz
Pawel,

On 9/26/20 19:07, Pawel Veselov wrote:
> Hello!
> 
> Tomcat 9.0.x
> 
> I'd like to force connection closure on some endpoints.
> I'm trying this on a simple JSP page.
> If I call response.setHeader("Connection","close"), I see that the
> response has "Connection: close, keep-alive".
> I assume Tomcat inserts the keep-alive part. It looks like the browsers
> still close the connection based on this, but I was wondering if it's
> possible to have Tomcat honor the header value set by the application.

Are you sure your application isn't issuing both headers? Or maybe a
proxy in between Tomcat and the browser?

> I was also wondering what does it mean - when multiple connection tokens
> are specified for a connection header. Breezing through the RFCs I can't
> find a clear statement on that except that multiple connection tokens are
> allowed in the header...

While it doesn't really make any sense to have the header value be
"close, keep-alive", it's a valid header value. The Connection header
requires at least one value, but can accept any number of them.

A reasonable client should expect that any "close" present means that
the connection should be closed after the response has completed.

-chris

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



Re: Tomcat's support for path parameters can expose resources despite reverse proxy access restrictions

2020-09-24 Thread Christopher Schultz
Nils,

On 9/24/20 13:29, Nils Breunese wrote:
> Christopher Schultz  wrote:
> 
>> On 9/24/20 07:46, Nils Breunese wrote:
>>> Mark Thomas  wrote:
>>>
>>>> On 24/09/2020 11:02, Nils Breunese wrote:
>>>>
>>>> 
>>>>
>>>>> - Envoy allows the request based on the /v1/* rule, because it 
>>>>> does not support path parameters, because they are not part of
>>>>> any recent standard (RFC 2396 dropped them in 1998 [1])
>>>>
>>>> Envoy does support path parameters and is correctly doing so in this
>>>> case as an HTTP reverse proxy by passing them through to the back-end.
>>>> From an HTTP perspective "/bar" and "/foo/..;a=1/bar" are completely
>>>> different URIs. Envoy's behaviour as an HTTP reverse proxy is correct.
>>>
>>> I wasn’t suggesting that Envoy should modify the URL that it passes 
>>> to the backend, but when doing its path-based access checks, I think
>>> it should ignore path parameters and normalize the path, otherwise it
>>> is trivial to get around these access restrictions.
>>>
>>> When only allowing /v1/* Envoy won’t allow /v1/../internal/secrets,
>>> because it normalises that to /internal/secrets and then sees it
>>> doesn’t mach the access rule, but it will allow
>>> /v1/..;color=red/internal/secrets because there is nothing to
>>> normalize as far as it’s concerned.
>> That seems inconsistent to me. If you remove the path parameter, you get
>> /v1/../internal/secrets which would be normalized to /internal/secrets
>> and therefore not allowed.
> 
> I’m not sure what you think is inconsistent. That is indeed what would happen 
> if Envoy would ignore the path parameter when doing the check, but it doesn’t 
> do that, because it doesn’t understand path parameters.
> 
>> But as a proxy, it should be forwarding the URLs as-is and may have
>> different normalization behavior in that case.
> 
> I guess we were indeed operating under the assumption that URLs are URLs, but 
> apparently different systems deal with them differently, which can cause 
> unexpected behaviour and even security vulnerabilities. This was news to us.
> 
>> Honestly, if you want Envoy to enforce this kind of protection, it is
>> Envoy you will need to configure properly. For example, if
>> path-parameters are not used in your environment, consider simply
>> rejecting any request that contains one and then your security layer
>> will work as (otherwise) expected.
> 
> This is indeed the workaround we decided to go with, but it feels weird that 
> we had to do this. I expect there are many other insecure setups around 
> because of the different ways URLs are handled by various systems.
> 
> If Envoy would ‘understand’ path parameters and that they should be 
> considered insignificant when doing path-based access checks, we would have 
> been fine. But it seems Envoy and Tomcat don’t agree on whether path 
> parameters are a thing or not. We’ll also talk to the Envoy people again 
> about this.
> 
>>> We currently have a policy to not secure the applications themselves
>>
>> Wow.
> 
> Ok, a little nuance: when it comes to path-based access restrictions.
> 
>>> , but handle this via generic access controls that can be centrally
>>> audited and configured independently of what language or server is
>>> used to implement the application.
>> Okay. It looks like those generic access controls need a significant
>> upgrade, then.
> 
> Well yeah, it’s not like Envoy is a super niche proxy. We also found
> the exact same issue in two other proxies in our network by the way.
> Any proxy that does not consider path parameters when doing
> path-based access control will have this issue when combined with a
> server that does support them.
This statement can be generalized to the following:

"When HTTP proxies and origin-servers disagree about how to process
requests (specifically their URLs), Bad Things can happen."

I would expect most proxies to behave the way that Envoy evidently does:
pass-through the URL in the request to the origin server. It's kind of a
requirement of the HTTP spec(s).

On the other hand, if you are applying a security-constraint at the
proxy layer, I would expect that the server would at least explain how
path-parameters are handled/normalized/removed/resolved/etc. Either
Envoy doesn't publish that information, or you didn't read that section
of the manual.

There may even be a setting like
normalize-URLs-to-be-proxied-for-authorization-checks or something like
that. Or maybe not.

Tomcat has a suite of settings in that same vein with all the defaults
being (a) (reasonably) spec-compliant and (b) safe.

But again, if the proxy and origin disagree, you'd better know the
details and plan for them.

-chris

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



Re: Tomcat's support for path parameters can expose resources despite reverse proxy access restrictions

2020-09-24 Thread Christopher Schultz
Mark,

On 9/24/20 12:41, Mark Thomas wrote:
> On 24/09/2020 17:28, Christopher Schultz wrote:
> 
> 
> 
>> Tomcat will only use path parameters in the final segment of a URL e.g.
>> https://www.example.com/app/servlet;jsessionid=ABCD1234?q=search
> 
> Not quite. Tomcat will only *add* the jsessionid at the end but it will
> accept it on any segment.

Good point, but I would expect applications don't generally /move/ that
path parameter for any reason, so a deny rule for such things should
probably be both effective and otherwise benign.

> Internally, Tomcat has an API to access path parameters but it only
> tracks name and value (as that is all that is required to extract
> jsesisonid). It would be trivial to extend it to include path
> information as well.

I hadn't thought of that, but it's obvious when looking at the API. a
change to that API to make it "better" would probably be weird.
Something like this maybe:

URL: /a;x=1/b;y=2/c;z=2;q=4

request.getPathParameter("x") -> "1"
request.getPathParameters() -> [ x=1, y=2, z=2, q=4 ]
request.getPathParameters("/a") -> [ x=1 ]
request.getPathParameters("/a/b") -> [ y=2 ]
request.getPathParameters("/a/b/c") -> [ z=2, q=4 ]

>> Assuming your application doesn't use path-parameters for anything else,
>> you should be able to detect and block any non-terminal path-segment
>> which contains a parameter and simply refuse the request with 400 or
>> something similar.
> 
> That is probably the simplest option in this case.

It's what I would do if I (a) wanted to host secret and non-secret stuff
on the same backend server and (b) didn't feel like securing my
application(s).

-chris

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



Re: Tomcat's support for path parameters can expose resources despite reverse proxy access restrictions

2020-09-24 Thread Christopher Schultz
Nils,

On 9/24/20 07:46, Nils Breunese wrote:
> Mark Thomas  wrote:
> 
>> On 24/09/2020 11:02, Nils Breunese wrote:
>>
>> 
>>
>>> - Envoy allows the request based on the /v1/* rule, because it 
>>> does not support path parameters, because they are not part of
>>> any recent standard (RFC 2396 dropped them in 1998 [1])
>> 
>> Envoy does support path parameters and is correctly doing so in this
>> case as an HTTP reverse proxy by passing them through to the back-end.
>> From an HTTP perspective "/bar" and "/foo/..;a=1/bar" are completely
>> different URIs. Envoy's behaviour as an HTTP reverse proxy is correct.
> 
> I wasn’t suggesting that Envoy should modify the URL that it passes 
> to the backend, but when doing its path-based access checks, I think
> it should ignore path parameters and normalize the path, otherwise it
> is trivial to get around these access restrictions.
> 
> When only allowing /v1/* Envoy won’t allow /v1/../internal/secrets,
> because it normalises that to /internal/secrets and then sees it
> doesn’t mach the access rule, but it will allow
> /v1/..;color=red/internal/secrets because there is nothing to
> normalize as far as it’s concerned.
That seems inconsistent to me. If you remove the path parameter, you get
/v1/../internal/secrets which would be normalized to /internal/secrets
and therefore not allowed.

But as a proxy, it should be forwarding the URLs as-is and may have
different normalization behavior in that case.

Honestly, if you want Envoy to enforce this kind of protection, it is
Envoy you will need to configure properly. For example, if
path-parameters are not used in your environment, consider simply
rejecting any request that contains one and then your security layer
will work as (otherwise) expected.

>> Clearly there is scope for more education and documentation on this
>> issue. The (very) short version is when using a reverse proxy in front
>> of Tomcat:
>> 1. Ideally don't rely on the reverse proxy to limit access to resources
>> on Tomcat. Secure Tomcat as if everything was accessible.
> 
> We currently have a policy to not secure the applications themselves

Wow.

> , but handle this via generic access controls that can be centrally
> audited and configured independently of what language or server is
> used to implement the application.
Okay. It looks like those generic access controls need a significant
upgrade, then.

>> 2. If you can't do 1, use mod_jk or the ISAPI redirector as they should
>> map URIs to proxy targets using the same mapping rules as Tomcat (and if
>> they don't we'll almost certainly treat that as a security issue).
> 
> Istio on Kubernetes uses Envoy as a proxy. I don’t think Envoy provides 
> something like this.
> 
>> 3. If you can't do 1 or 2 you can try and block potentially malicious
>> URIs in the reverse proxy but this is hard (need to think about "/../"
>> and "/./" sequences, path parameters, %nn encoding and combinations of
>> all three.
>>
>> If you get as far as option 3, you really need to go back and
>> re-consider option 1 or 2 as the chances of getting 3 100% right are slim.
> 
> AFAIK Envoy does normalize path traversal sequences like /../, but
> path parameters can break these sequences, and Envoy currently doesn’t
> ignore those, like the /v1/..;color=red/internal/secrets example.

Again, there might be a difference in normalization when it's being used
as a proxy.

Tomcat will only use path parameters in the final segment of a URL e.g.
https://www.example.com/app/servlet;jsessionid=ABCD1234?q=search

Assuming your application doesn't use path-parameters for anything else,
you should be able to detect and block any non-terminal path-segment
which contains a parameter and simply refuse the request with 400 or
something similar.

-chris

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



Re: SSL certificate makes site dont work

2020-09-22 Thread Christopher Schultz
Carles,

On 9/22/20 08:57, Carles Franquesa wrote:
> Trying to install an SSL certificate on 8.5.57.
> 
> Once created the cert files, and with a jks available, and set in a
> connector into server.xml file, cannot connect to the page.
> 
> The connectors code is
> 
> '''
> 
>  protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150"
> SSLEnabled="true"
> scheme="https"
> secure="true"
> clientAuth="false"
> sslProtocol="TLS"
> keystoreFile="/opt/tomcat/certificat/app.aprenonline.eu.jks"
> keystoreType="JKS" keystorePass="***"/>
> 
> 
> 
> '''
> 
> When trying to connect from the browser, the status bar says "trying to
> make a secure connection..." but it hangs at this pont.

What URL is showing in the browser?

Are there any errors or warnings during startup in the log files?

-chris

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



Re: Truststore in HTTPS Connector does not work with Linux

2020-09-18 Thread Christopher Schultz
David,

On 9/17/20 11:31, David Weisgerber wrote:
> I think I was able to figure out the problem (more or less):
>
> Using two distinct keystores for trusted certificates and server keys
> solves the problem. But don't ask me why there is a difference
> between Windows and Linux on this topic.
That *is* odd.

> It also does not work to use an empty keystore (on Linux).

That would never be expected to work, as the secure connector requires a
key to start successfully.

I think it's worth filing a bug to see if there is a way to get that
handled via Tomcat. There is no conceptual reason you should be unable
to use the same foostore as both keystore and truststore. It's just
uncommon because the keystore is usually considered a high-security
asset from a "read" perspective while the truststore should really only
be protected from a "write" perspective.

I never put trusted certificates into a keystore mostly because I don't
want to bugger-up my keystore and break the server itself. (I also
happen to hate keystores, but that's kind of beside the point.)

-chris

> -Original Message-
> From: David Weisgerber  
> Sent: Thursday, 17 September 2020 09:29
> To: Tomcat Users List 
> Subject: RE: Truststore in HTTPS Connector does not work with Linux
> 
> Hi,
> 
>> Ugh. That *does* point toward a bug in Tomcat itself or something odd with 
>> the JVM.
> 
> Yep.
> 
>>> No, we automatically ship the latest 8.5 tomcat version. However for 
>>> our docker based distribution I was sure that this feature worked at 
>>> some time (I think I used tomcat 8.0 for this). I tried it with the 
>>> latest 8.5.57 on Windows, there everything works correctly. I just 
>>> checked all the versions to see when the "bug"
>>> was introduced.
> 
>> Did you find it? I took a quick look at the 8.5.x changelog and nothing 
>> jumped-out at me.
> 
> I think it is
> Fix:  Refactor the JSSE client certificate validation so that the 
> effectiveness of the certificateVerificationDepth configuration attribute 
> does not depend on the presence of a certificate revocation list. (markt) 
> From the 8.5.5 changelog
> 
> Shall I file a bug? Are there any other people that can confirm this? I guess 
> client certificates is a more rarely used feature.
> 
> Best regards,
> David
> B CB  
> [  X  ܚX KK[XZ[
>  \ \  ][  X  ܚX P X ]
>  \X K ܙ B  ܈Y][ۘ[  [X[  K[XZ[
>  \ \  Z[ X ]
>  \X K ܙ B 
> 
> -
> 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: [OT] RE: How to get the tag name from within a taglib class ?

2020-09-16 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 9/15/20 13:18, Berneburg, Cris J. - US wrote:
> CS> IMO, the JSP effort was a stepping-stone on a path to better
> CS> technologies like Velocity, FreeMarker, and others. If I were
> CS> king, JSP would just go away. Just my POV of course [...]
>
> cjb> what do you like better about Velocity, FreeMarker, etc. cjb>
> more than JSP?
>
> CS> I started using Velocity years ago [...] It definitely has its
> CS> warts but it's relatively actively maintained, and anything I
> CS> need I can get in and do myself, submit patches, etc. CS> CS>
> Advantages over JSP (IMHO): CS> CS> - Can't execute direct Java
> code, ever CS> - Non-verbose syntax CS> - No limit on template
> length [...] CS> - Easy to install POJO "tools" which just expose
> Java objects CS>   to the runtime so you can $tool.doSomething()
> [...] CS> - Can load templates from anywhere (disk, DB, URL, etc.)
>
> Good to know!  I also see that it is an ASF project.
>
> Is Velocity interpreted or compiled like JSP?  I'm thinking of
> performance impacts, like during loops.
>
> Answering my own question, the Velocity FAQ says, "Velocity
> doesn't compile your templates. They are parsed into an AST
> (abstract syntax tree) and that is what gets cached."
Right. It's not really interpreted OR compiled. But it's not re-parsed
on every request unless you configure it to do that. I've never had
any performance complaints myself.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9ip94ACgkQHPApP6U8
pFhooxAAifqd19yhLdxBAdDJY1ttX0CWB3/F3PUZ0qf6NoHU/kN7tLi5oejQpJ2a
YTeml+vO/jI/c6sF5A/6rPdKyx6rjiUercUFP6efMJH6z4zVitgGfshWiAwWiBur
SkDGtWsFUnco1fFOcSB2mD42amOl6JVEmpUyjMdlBw3wxjUY+fofKLD5/H1u2gb0
IqBmpZr7gPnhOK03Iti2zdaUCAf+iAJ+rgjnuo/iXpDRIa2s3JFxdbY0192id5sv
bMPzO4hwU7aaR7qARXY+LBMFrJyuh2ICfIaz9s5uR+S20fSipcGkVSDl9OqATEls
pHM/ff8d7fLuozj6JgVR1jDfQLOHEYwMktgJ9I1Lst4C+FaHsWoShm0mailYxHf6
FvF/XCaCxQ1mgwslnbfXBV65tU6okOMnkmZDCG8otxT/KMyhTgtSyfj80ft2x4Tq
0IvPWm8ztwj3Tr/P7Vg2T4RX46ESHQ20i0CtcGtMaaWRlVdTcBRYSR/JRsa+Hrdq
W0SJ2PTO7stjuPDYTSog/wrprwS2QwKrpkj7RVgVXsOUShHTV9aswIWZjW+jiJyA
3DlsmBMeXhLdrlMTw8i1/fvHa+TtPjHoFvSH6sAHs3xX+QbLV3+bJ6/Z3+BU0V3N
H76kobuPTXwEZXJ4y5TgY4Q8Jj/NQDwbnL+Si1Ut+gCpNlaD+B8=
=O8Ce
-END PGP SIGNATURE-

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



Re: Changing the keystore alias of the _default_ SSLHostConfig while running.

2020-09-16 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 9/16/20 09:37, Daniel Skiles wrote:
> In case anyone finds this thread in a search engine in a few
> years,
I was
> able to get this to work.   Here are some notes if you are using
> JSSE.
>
> * The operation is addSslHostConfig on the ProtocolHandler Mbean. *
> You must have org.apache.tomcat:tomcat-coyote on your classpath. *
> You must create both an SSLHostConfig and SSLHostConfigCertificate
object.
> * Use the SSLHostConfigCertificate constructor that takes the
SSLHostConfig
> as an argument. * You must call addCertificate(...) on
> SSLHostConfig after
configuring both
> objects, before calling the operation.

Glad you got it working.

Exposing an addSslHostConfig() method via JMX which takes a large
number of String (or other) values would surely be convenient for you,
but kind of a pain in the neck to support alongside the existing
mechanisms.

- -chris

> On Mon, Sep 14, 2020 at 9:22 AM Daniel Skiles
 wrote:
>
>>> Did you try it?
>>
>> I've been unable to try it through JConsole or Visual VM.
>> JConsole
throws
>> an error indicating that it can't load the remote class, and
>> Visual VM disables the method.  It looks like it takes a complex
>> object, and
I do not
>> have enough experience with Tomcat, or MBeans in general, to
>> even
know what
>> to start googling to find a solution to that.
>>
>> Is it something I can do programmatically, and pull Tomcat
>> classes
onto my
>> local  classpath to get around that issue?
>>
>> On Mon, Sep 14, 2020 at 9:08 AM Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
> Daniel,
>
> On 9/11/20 17:06, Daniel Skiles wrote:
>>>>> I've gotten my _default_ SNI SSLHostConfig working.  Thank
>>>>> you for the help.
>
> Excellent.
>
>>>>>> Perhaps that method could have a better name, like
>>>>>> reinitializeSSLHostConfigs. "reload" implies that it
>>>>>> re-reads the server.xml which is not the case. At least
>>>>>> the documentation should probably be better.
>>>>>
>>>>> If the server.xml isn't actually read during the
>>>>> reloadSslHostConfigs operation, is there a way to add an
>>>>> SSLHostConfig at runtime?  I see addSslHostConfig on
>>>>> ProtocolHandler, but I'm not certain that it will do what I
>>>>> think it will do.
> Did you try it?
>
> -chris
>
>>>>> On Fri, Sep 11, 2020 at 9:52 AM Daniel Skiles
>  wrote:
>>>>>
>>>>>>> In your case, where did you rediscover
>>>>>>> reloadSslHostConfigs?
>>>>>>
>>>>>> To be honest, I wandered around in the JMX console until
>>>>>> I found
> something
>>>>>> that looked promising.
>>>>>>
>>>>>>> You'll want to "set" the value of the attribute
>>>>>>> "certificateKeyAlias".
>>>>>>
>>>>>> Thank you for your help.  I'll give that a try.
>>>>>>
>>>>>> On Fri, Sep 11, 2020 at 9:44 AM Christopher Schultz <
>>>>>> ch...@christopherschultz.net> wrote:
>>>>>>
>>>>> Daniel,
>>>>>
>>>>> On 9/10/20 16:39, Daniel Skiles wrote:
>>>>>>>>>> Also note that calling reloadSslHostConfigs does
>>>>>>>>>> NOT re-read server.xml. It re-initializes the
>>>>>>>>>> existing in-memory configuration. If you want to
>>>>>>>>>> e.g. change the key alias, you'll have to make a
>>>>>>>>>> JMX call to update the alias and THEN call
>>>>>>>>>> reloadSslHostConfigs.>
>>>>>>>>> *THAT *is probably my problem.
>>>>>
>>>>> Perhaps that method could have a better name, like
>>>>> reinitializeSSLHostConfigs. "reload" implies that it
>>>>> re-reads the server.xml which is not the case. At least the
>>>>> documentation should probabyl be better.
>>>>>
>>>>> In your case, where did you rediscover
>>>>> reloadSslHostConfigs?
>>>>>
>>>>>>>>> Do you know which MBean and operation that is?
>>>>>
>>>>> It's this (you'll have to interpolate a bit of this to fir
>>>>> your environment):
>>>>>
&

Re: Low throughput with HTTP2

2020-09-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martin,

On 9/15/20 07:37, Martin Grigorov wrote:
> I am running some load tests on Tomcat and I've noticed that when
> HTTP2 is enabled the throughput drops considerably.
>
> Here are the steps to reproduce:
>
> 1) Enable HTTP2, e.g. by commenting out this connector:
> https://github.com/apache/tomcat/blob/d381d87005fa89d1f19d9091c0954f31
7c135d9d/conf/server.xml#L103-L112
>
>  2) Download Vegeta load tool from:
> https://github.com/tsenart/vegeta/releases/
>
> 3) Run the load tests:
>
> 3.1) HTTP/1.1 echo -e '{"method": "GET", "url":
> "http://localhost:8080/examples/"}' | vegeta attack -format=json
> -rate=0 -max-workers=1000 -duration=10s | vegeta encode >
> /tmp/http1.json; and vegeta report -type=json /tmp/http1.json | jq
> .
>
> 3.2) HTTP2 echo -e '{"method": "GET", "url":
> "https://localhost:8443/examples/"}' | vegeta attack -format=json
> -http2 -rate=0 -max-workers=1000 -insecure -duration=10s | vegeta
> encode > /tmp/http2.json; and vegeta report -type=json
> /tmp/http2.json | jq .

You are using HTTP with 1.1 and HTTPS with h2. Maybe you are seeing
CPU slowdown for the (probably double encryption) taking place on the
same host?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9gyyIACgkQHPApP6U8
pFiNUxAAnUQVU73nNitIyn6zD9t4JfkLIv/AKTlds4/W/p6TRtIQgTX7nIJjGDfw
BOKznCHmieMJon4rMZ3d8GFhmUP8CawQlJHpqABeITBzLZZ5x9fuOf22G6HJb3r+
+k0qDoKzFTWlJuWLwaLZHy6fO9ugi4OPAW0G0efa2T6sTDZzImGnjmoZ5PWBExoz
mXmYWnZeP7R+3QkAWUYArJh9yPEJyIb9nFX1YKZ1l5Erzrn0F9uEYFgWT/UkQoKM
L65AMh/qEvzJhP2wHOLm4NfAiNO4OgTmo+nm4F/SIMGFNURPFi2sl/jTUHVAzEa4
mAqlJqX1swimyjjsunlfhbU/bApvVFsYSPuSYcZmLN1lkmaQOAuWHnZdd4e9h+tt
rhoKXipk8OairYzwQsPVnzCTHaiAhOXJ3MSE966YwlvhSMOoqDsN3y7ySrboresD
iC0cDo+43/wR3IQlOJYFxcFX+tI2Y29ZjrX/IwnJXuVyU095YZWmRFC2JgRfzBtI
toM2ofpqnSBaS22ZBTbqp+q1QxRZfC3r0vuvuiXK620QRcbk1Ya0+U17LOIEYnuY
URY94kL80upiADQMIdryq4ubRAma2t0s5c6JuO/QqsXVjJfawlRGQA5arORgfE2J
yDCscyyFCHitEGTglIJUXW/KfFPtraWnON3TSCm7dQ55EmInxpc=
=76Zf
-END PGP SIGNATURE-

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



Re: [OT] RE: How to get the tag name from within a taglib class ?

2020-09-15 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Cris,

On 9/14/20 15:04, Berneburg, Cris J. - US wrote:
> Hey Chris
>
> CS> IMO, the JSP effort was a stepping-stone on a path to better
> CS> technologies like Velocity, FreeMarker, and others. If I were
> CS> king, JSP would just go away. Just my POV of course, you are
> CS> welcome to fall in love with JSP. :)
>
> Seeing as I am ever on the trailing edge of learning new or even
> dated technologies, what do you like better about Velocity,
> FreeMarker, etc. more than JSP?

I started using Velocity years ago because it was bundled with Turbine
which was being used by a project I got pulled-into. We eventually
ripped everything else out, but Velocity survived.

I looked at FreeMarker when doing a book review for Apache Struts 2
and it looked very interesting, but I discovered that the guy running
the project was ... difficult to work with. SO I've stuck with
Velocity for a long time.

It definitely has its warts but it's relatively actively maintained,
and anything I need I can get in and do myself, submit patches, etc.

Advantages over JSP (IMHO):

- - Can't execute direct Java code, ever
- - Non-verbose syntax
- - No limit on template length (JSP eventually hits the "Method too
long" problem which is very inconvenient)
- - Easy to install POJO "tools" which just expose Java objects to the
runtime so you can $tool.doSomething() and it'll do whatever that is,
converting the result to a String and dropping it into the output
- - Can load templates from anywhere (disk, DB, URL, etc.)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9gyksACgkQHPApP6U8
pFi2og//TI//2oxfo4iE3q0B1f4sMN8fT8K9EVT89EME1jfUHontVRXtrX+tke2f
t/3Os9veBJROAO5jOJvBCkefq7V2Lqij2289Vc7qVuuap+UqO/a+UCyOjxmVAHGh
TrMeuxRLV8V1GPhDo0pftoJEWXg6SnDEqo7TF/1kGAmcaHEkWUEYrOPLfE92GbHJ
8bNySZFEleXX3decZj1mBdAoL+SMV7jbSvONGrMDds0saAddUmYMpdP9VPnCnKfG
YS5Ec1Hx/1hshUisC1qOuarNCXH+84MLV98yM1pECoYCzx+2rTZ9RdoLwDnHjJB2
wJrc66P0yHOXyBfMamfpaxsUvTj2PON6RwBcbC7gaDMLIefGWM8TUROXMf7Odd40
TDZ+uJvyZBApeCnHkKrY/ipEvT4qb5sF0pVZTV9N6EBfqhKwBXgNqxTpCnAOkYFq
egXYO1JGShxCdnHfAgNHyMoZ61PLltwe5msW6ZTlAqex3teZkmIrVfXXINy/JEbs
lcRxe/V1EPBk9JxPJMy+hgDx4RBk6/ocepJbT2BR8nA9R1LBvA5h7wMr9iQw091S
pbBr7xuKnIncMuCqTTyjiPZV/+7fBRYZgGAqZX+2pNGJkZ+kNMm3FAPqz9pjw/LD
2DZyK7gqXmFCWGGdlWxLfPOpNb6ajv3slc3fMXxvdBNNpW1AYg8=
=AwcX
-END PGP SIGNATURE-

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



Re: Handling Upgrades

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darryl,

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

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

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

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

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

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

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

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



Re: Any update on 9.0.38 release plan

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 9/14/20 12:21, Mark Thomas wrote:
> On 14/09/2020 16:57, Christopher Schultz wrote:
>> Arshiya,
>>
>> On 9/14/20 10:54, Arshiya Shariff wrote:
>>> Can we please get a tentative release date for 9.0.38 .
>>
>> The vote was started on 2020-09-11 and usually stays open for at
>> least 3 days. There are enough votes for the release-vote to pass
>> and there have been no reports of any problems, and no "NO"
>> votes.
>>
>> So I suspect you'll have an official 9.0.38 sometime this week.
>>
>> If you'd like to follow-along, you can subscribe to the dev@
>> mailing list where all the votes are publicly-held. You can look
>> at the archives if you want to see the vote(s) but don't want to
>> subscribe.
>
> And I'll add that if, as it appears, that the 9.0.38 is important
> to you then the most useful thing you can do is test the release
> candidate *before* the release vote completes and, ideally, report
> back to the community.

Duh; I should have specifically mentioned this!

Thanks for rm'ing btw.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fuxMACgkQHPApP6U8
pFjB4Q/+NIreTaP2t/XlnKEbPSjQyqZhrJZV07yuIMUFknKPMMLnY5MxlOnpJXJx
rYMdLxjrd1JSZFFrUUx9aBxV6K4LV+a/ODvruER1jDZ/27CCyqwU2vO/QnP4VhyY
VxMZnzeG5QixtWE/cdyEoKLH3Vgd9jOP5V8EOITk5eJ7MGSGhIHdcR7KSwkhM/BV
80mKGMVfHhXmCFxwO7WB4EWVmS07F7BpvWiJYWnYyPVPIDqn4bf2KPmsDw76+qPX
eJMMDaO/vv4fsollJae+8JaSFs/duOiSM5LTJg07nH1knZTUbXHhXAhfkwF/a7Qt
CyZkuzSCDjLo+ynJIX9nDO1bV52/9FUoZkQQxpoOC0pNuOtnVXlAeeFiURlZPvGP
Wt/q3e6ffogLroSP7b9dV3qReWyqKn1/QUnSVyoMRXtPMvWvsUTKV8tHiZEh+2Iy
8Bi1i+GNtQ3q1qxzaKIJDBosqW+TQq10hZ+6egZdbI6D/AkwwIVerLuQtjIHTUZv
5qopIo1Lz3WRwdnzU2I9ZNGEiij/xfwW9d0zLemB43qmYqZaaBssBsb1uEm2+4/f
6np2S85jXTHoJWFidXd/eaRNEwHB15pUkrXd1QSqJbLEeMQfqC8R8YGIf6HfojCg
BNHR8p2FTcZgIP99PJUutCRnHsbsluADdN/B+4rd2YlWdHHHy5s=
=7H2N
-END PGP SIGNATURE-

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



Re: Any update on 9.0.38 release plan

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Arshiya,

On 9/14/20 10:54, Arshiya Shariff wrote:
> Can we please get a tentative release date for 9.0.38 .

The vote was started on 2020-09-11 and usually stays open for at least
3 days. There are enough votes for the release-vote to pass and there
have been no reports of any problems, and no "NO" votes.

So I suspect you'll have an official 9.0.38 sometime this week.

If you'd like to follow-along, you can subscribe to the dev@ mailing
list where all the votes are publicly-held. You can look at the
archives if you want to see the vote(s) but don't want to subscribe.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fkwEACgkQHPApP6U8
pFjK1xAAhKJ77lp4OSYs7nDct9NTry+ZlcbLlsM9wUvK0j7NdyrOX4G8a/YICdL+
YHQYRHQ4VDIj0UyB2nXLYA2mpSnqowcWfSWs8/Os4N2cjovkrhGGLBotZORePHjc
mhj+oX5Be4FDE5rOMLdi6IkElKOSj5fRKwDu7JSEqJ95VY3MIikqttQPeQOQOZ7O
cXKwHnJryR/JPtqAx04paUBKO/hyHmxBoasNam/bhA+FUX8fpECq2iurZ6D6Ayh4
u1Ptmo1A4Qju18Hg51gYp7wTTKzveqUzwqbYHpHgYGE2YMlaS1tgwyawXDtWU0bH
cmkOenyKgLIpFegb0WTqmQm+WbwDU7SFhWxyPcnS/LTlkvYZOBSo2iLc8s/TdxeO
r8X+fB9eAb+3T1dzNr8jS1IS6mv62mTL0KlhBK4sofUcNqMZan5bTsopaSYHBWgw
upoCydA1RG7GpzfDZ+cTA/Sr1Ir2SF45OgSL6sUfluhEtPEwC4BZI0tftjnbB8k7
FWWbieZWRwDBeEKilwJUDQ2PJkROHOtGyA0yLaUQ1SkUX5nxFZwc33q9BX6DL8YW
J160qAD0OI0aMZCB/lsPrH/raAbZRsI20FCEAnnWI499ccO4NFJ0b3xeCEZyH0oE
leTeKeaWrE927ykdwkHRcDHx+Liu/66OkVmvwU4JifypBHPPGNY=
=bTA+
-END PGP SIGNATURE-

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



Re: AW: Track native memory of a Tomcat application

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Andreas,

On 9/14/20 05:03, Döscher, Andreas (ESI) wrote:
> Moin, ah! The no-xmx-mistake! If you ommit the memory limitation,
> java uses (on server-class machines) as default 1/4 of the
> physical memory. (I found this blog entry
>
https://blog.openj9.org/2020/04/30/default-java-maximum-heap-size-is-cha
nged-for-java-8/)

It's more complicated than that, but yes, Arshiya I believe what you are
seeing is completely normal. When there is no memory pressure, the GC
won't actually do anything for a lng time. And you'll see the
maximum heap space used. Since you didn't pick a maximum heap space on
startup, the JVM picked a "reasonable" one for you. Its definition of
"reasonable" may not match yours. :)

Try adding this to whatever launches your JVM:

  -Xmx32M

That's usually enough to run Tomcat and an application that doesn't
need very much memory. I've been able to get an application to run in
12MiB before, but IIRC it required disabling a few things Tomcat does
out-of-the-box to fully-adhere to the servlet and other specifications.

- -chris

> -Ursprüngliche Nachricht- Von: Arshiya Shariff
>  Gesendet: Montag, 14.
> September 2020 10:17 An: Tomcat Users List
>  Betreff: RE: Track native memory of a
> Tomcat application
>
> Hi All,
>
> Thank you for the response Christopher .
>
> * A single request, or a single *type* of request? A single
> request (http/https) that is hit once per day
>
> * Does it increase as the request is processed, or does the JVM
> take
that 4GiB immediately upon startup?
> The tomcat process was started 3 months back , but the memory has
increased gradually to 4GB though it does not process requests
continuously (one request per day).
>
> * The first thing to do would be to post the effective
> command-line
options that are being used when launching your JVM. One of the
easiest ways to do that is to run "ps | grep catalina" which will give
you the full command-line for the process.
> There is no Xmx set: ogw  30853  0.1  3.1 22048736 2068856 ? Sl
> Jun09 154:10
/opt/java//jdk1.8.0_201-amd64/bin/java
- -Djava.util.logging.config.file=/opt/webstart//conf/logging.properties
- -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
- -Djdk.tls.ephemeralDHKeySize=2048
- -Djava.protocol.handler.pkgs=org.apache.catalina.webresources
- -Dorg.apache.catalina.security.SecurityListener.UMASK=0027
- -Dorg.apache.catalina.connector.CoyoteAdapter.ALLOW_BACKSLASH=false
- -Dorg.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=false
- -Dorg.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER=false
- -Dorg.apache.catalina.connector.RECYCLE_FACADES=false
- -Dignore.endorsed.dirs= -classpath
/opt/webstart//bin/bootstrap.jar:/opt/webstart//bin/tomcat-juli.jar
- -Dcatalina.base=/opt/webstart/ -Dcatalina.home=/opt/webstart/
- -Djava.io.tmpdir=/opt/webstart//temp
org.apache.catalina.startup.Bootstrap start
>
> Thanks and Regards Arshiya Shariff
>
>
> -Original Message- From: Christopher Schultz
>  Sent: Friday, September 11, 2020
> 10:54 PM To: users@tomcat.apache.org Subject: Re: Track native
> memory of a Tomcat application
>
> Arshiya,
>
> On 9/11/20 13:06, Arshiya Shariff wrote:
>> We have a standalone tomcat web application(Version 9.0.22)
>> which runs on Linux . The application is used to process only  a
>> single http request.
>
> A single request, or a single *type* of request?
>
>> But the physical memory usage of the application has increased
>> to 4GB (output from the "top" command of Linux) , of which the
>> heap has only 16 MB of live data.
>
> Does it increase as the request is processed, or does the JVM take
> that 4GiB immediately upon startup?
>
> Remember that the heap is only a part of the JVM's memory usage.
> Examples of things that don't go into the heap are the native
> memory used by the JVM itself (thinking of the JVM itself as a
> usual OS process), stacks for each native thread, compiled Java
> code produced by the JIT, and various I/O buffers.
>
>> Is there a way to track the native memory of a tomcat process ?
>
> The native memory of a Java application is very difficult to
> inspect, etc. unless you are *very* familiar with JVMs, the memory
> manager being used by your JVM, and the platform and architecture
> on which the JVM is running.
>
> The first thing to do would be to post the effective command-line
> options that are being used when launching your JVM. One of the
> easiest ways to do that is to run "ps | grep catalina" which will
> give you the full command-line for the process.
>
> That will show any memory parameters you may have specified on the
> JVM at launch time, which will definitely affect the 

[OT] Decent OAuth libraries?

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

All,

I'm looking at implementing OAuth/OAuth2 on the server for both
incoming and outgoing SSO with other systems. It doesn't look like
rocket surgery, but I figure: why reinvent the wheel?

Has anyone had any experiences in particular they'd like to share? I
think I'd prefer something that was explicitly geared-towards OAuth
and not something more general like Apache CXF, unless CXF is *super
good* as doing OAuth and also provides some other great thing that
maybe I didn't know I needed.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fcjgACgkQHPApP6U8
pFiRcxAAtZ+rmO2i4PrFCRMPcEBWP6Z4z7IeBQUPfiotz5c84IvjOIqnJHyIx6RW
Qyy7uy/7lHXMeu5xw/4DFx4qFxdG/O1+B7mekkxBrRnDFxOFByZS5RjVo0c8SFjo
xiXvyeEy+/ucZb7Ca1M5Xryo5aIaTjXP8DSVkUWIfMqVyc9COrKt9Ds6gy/0xAll
OcUj7CrRW1LiCoZmIPhXkabHqsxHofu5oEGHzcFE1tdsFr9L8JEfAPAhSgGJnDky
yqW9P5LD8vH+34gVMqKCOOtHGVdNug7F4GTz+4z/ScHLhAcR/giRi/05ydigGvyL
umux/QLzj1C5y1Nu+7jkBGz7QnokzsMMOjHH5n29/dIBOz/LS+6P7BidKLVgycdu
HLomJpfmKRJaj6VHofMczYo6oCzGzrwdpeWBBvWwLE733CUU3IqQskUHvqIGj66C
fopFuTk0Uyeizh7TY2+NyIAdcGdQyNjb+qYHYoN19Td8V/eAM3HjcJsxC9j0WRlT
Sx16g0pMDLu36IjO2C4ltE7mUcKbD8yTZkTcs6ORTBX/88Kbj6dfymHj13DUUz5H
+d2PbLlm8NNz530OmSJ0FopnM6afjCRzlE/tfQUOmCnGyxKjo+piqnBLws6no7NB
4+I9auIX0gmXygc/h/S2e8SH4sElCNfgRj9Cw8sgK7znc6wKTpc=
=pwRm
-END PGP SIGNATURE-

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



Re: [OT] Replacing the standard JspWriter

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Adam,

On 9/11/20 19:30, Adam Rauch wrote:
> I have implemented a custom JspWriter and registered it for use by
> our JSPs using the approach described here:
> https://stackoverflow.com/questions/29508245/jsp-using-a-delegate-for-
out-jspwriter-with-jsp-includes-to-change-the-beh
>
>
>
> I created a custom JspFactory that returns a custom JspContext
> that returns my custom JspWriter. I then replaced the standard
> JspFactory by calling JspFactory.setDefaultFactory(). This works,
> though it results in some undesired behavior. I also note that the
> setDefaultFactory() JavaDoc seems to claim that my approach is
> "illegal".
>
> So, is there a preferred way for my web application to provide a
> custom JspWriter for my JSPs to use?
>
> (If you're curious, our JspWriter HTML encodes all strings that
> aren't designated as safe-to-render, like React and other modern
> JavaScript frameworks do. The usual JSP approach is too susceptible
> to XSS vulnerabilities, IMO.)

Really?

Seems like  should work just fine. You prefer
this?

<%= myVar %>

How do you mark variables as being "HTML-safe"?

If you don't trust your JSP programmers to do this correctly, maybe
JSP isn't the right technology for your team. (I happen to think that
JSP needs to go away, but that's just me).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fbeQACgkQHPApP6U8
pFi2gg/7BpbFf3+QXlr78ZjIHYB2C2x0+VF9mX4pKwiOmp2y6q70tWGExCOaEYId
vSNYMUjL0PwsCEVZDmX4roAT+Ep2VeqR+opvRf9JU8SuVkAlgplXg7nePRPnCRq6
hlf0NgrZ6U5WM3wxvpH8uFroarTSym6T/fEjdR3Ff7AjSE7v23VUvmW5bCxQ/M/u
1hEZPXpOfCjJZRkJynu0etF1GnhgjFPsbsvW7IPFsKLKgApYPVY5uytJSGeshtU4
/l612ZHO0618vI53jP/JmOPCQrdjLTY7YNFHwh0j+QCykSYTk7rpI46JFfD/wmJ/
/JsrUH7Dy+qrmZJzh9hCF1q4ITRddhUhK5ztNYpOiOFDAr+urz+QEaeThsSohOvt
k86X8Jivhn2TB4Mtb4vb/MEEvzRVC+Fjj3QXEzP4GY3SJpvTDB+wVIQq59IvH9Em
+iDnLeJBWHzHx1ZS/XyUUW1ZKIvNEQ1qKXqw95uHk0mvCKsVMkHThQ71h+g7Ooc2
z/ubrBy2yxJrzhELk+oDUQwd82YdEksZ9CGgXvj+JPpdNqAWpf5C2W2Sjwv2cvTj
z38bBFyk1mKC1B90KslEZjmIPCYgPFfZGV9Ro6vg7VcH/yOFIGXOvaLBh2apx4xs
m6ADTFP+PBIiAJ5glrvhfJHvYpMssy68vDnThKbjfon+vE1tu1I=
=zEGy
-END PGP SIGNATURE-

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



Re: Microsoft Edge (Chromium based) not prompting for logons

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave,

On 9/11/20 16:29, Dave Ford wrote:
> We've set up out Tomcat Manager to use LDAP for authentication -
> (note, this is not MS AD, but linux-based LDAP server). The OS our
> tomcat servers are running on is Linux and they're not intergrated
> with our AD domain in any way at all.
>
> Our users have been happily logging into the Tomcat manager app
> using various web browsers for some time - they get prompted for a
> username and password, they provide their credentials (which is the
> same user name and password as they're currently logged onto
> windows with, but with no domain\ or @domain info in the username),
> they're checked against LDAP servers, and are let into the app
> assuming they're allowed.
>
> However, we've recently received reports that some of our users
> who have had their Windows machines copies of Edge upgraded to the
> latest version are no longer being prompted for credentials.
> Instead, they're directly immediately to a 401 unauthorised
> message. Other browsers, including Chrome, still prompt.
>
> We've changed nothing at the tomcat end, so this is clearly a
> problem with the behaviour of Edge - but I'm keep to try and
> understand it.

Are you using HTTP or HTTPS?

> I can't find any useful information in the tomcat logs - is it
> possible to turn up the logging for the manager app to see exactly
> what credentials (well, username) is being passed by Edge to it?

This may be a bug in Edge or something having to do with
authentication policies. Microsoft has been actively trying to kill
HTTP Basic authentication for a while.

https://answers.microsoft.com/en-us/microsoftedge/forum/all/latest-versi
on-of-edge-no-longer-shows-basic/3601252b-e56b-46c0-a088-0f6084eabe47

TLDR: visit edge://policy in Edge and look for AuthSchemes. If the
value doesn't include "basic", add it and re-try.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9fbDkACgkQHPApP6U8
pFh4pQ/9HtWwtRtewO0l6pvR2voItW6CUwHBm/pag4O2KuyjGzkjEgV+WIOaOGGO
GHy/e9TaxQL97elFXbenbcT+/5dTmYWJtodBuBACD927AqdNKRygDiAig2xfmkBT
DryhT6BHuHV3XkQmdIPDCHc/Vqw5UJ+6Wzz5iehCroQ+FPi2XrOHGCyEjUtokoiB
dt7acgo6ElDf7k/YSXIdfJD+EEs/JNSx5ufEW/Jid4LPCTkUCxVrK3Nu6kdt5JRv
24udU+Any2Cw/O0iDSjhcGBM2nDl8nP2rtdiwfyqxbsJMxIi/yhLfECsWzXzkjBY
jVBYFiYprN7wc8227DDlu/GR5K2CjqSSr/Dl185mQkrHNAXCCM9PEFAk1bJE0H2b
uEewE0ZOLAYvSViC655uKDXDxh8i6UIG9n685YAMqeIByNPbrNF/2JLvzTN7gjxE
qChWIrOqZnDC2ZSb5sTt5oFSZ3zgzXMe5+alZKOAgffBoyWHM43OExdTa33YQ3xS
GslTxjxbD+aI73mNINTjpPxe4l41s4mnOiylG/4uIk88Eh+bS8SnHF0YYi5oAxO+
oEegLBKK/eGBaZ4F7JoUFu29EPW4A5g+NEekLSoELUVYph5Hpbb9v9OdSL1ou/K0
z69wt7gORqGo3NpAWUJhPC8VQOWtM+BZLUb+Q3cy/Jqn5EJF8AU=
=9X49
-END PGP SIGNATURE-

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



Re: Changing the keystore alias of the _default_ SSLHostConfig while running.

2020-09-14 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 9/11/20 17:06, Daniel Skiles wrote:
> I've gotten my _default_ SNI SSLHostConfig working.  Thank you for
> the help.

Excellent.

>> Perhaps that method could have a better name, like
>> reinitializeSSLHostConfigs. "reload" implies that it re-reads the
>>  server.xml which is not the case. At least the documentation
>> should probably be better.
>
> If the server.xml isn't actually read during the
> reloadSslHostConfigs operation, is there a way to add an
> SSLHostConfig at runtime?  I see addSslHostConfig on
> ProtocolHandler, but I'm not certain that it will do what I think
> it will do.
Did you try it?

- -chris

> On Fri, Sep 11, 2020 at 9:52 AM Daniel Skiles
 wrote:
>
>>> In your case, where did you rediscover reloadSslHostConfigs?
>>
>> To be honest, I wandered around in the JMX console until I found
something
>> that looked promising.
>>
>>> You'll want to "set" the value of the attribute
>>> "certificateKeyAlias".
>>
>> Thank you for your help.  I'll give that a try.
>>
>> On Fri, Sep 11, 2020 at 9:44 AM Christopher Schultz <
>> ch...@christopherschultz.net> wrote:
>>
> Daniel,
>
> On 9/10/20 16:39, Daniel Skiles wrote:
>>>>>> Also note that calling reloadSslHostConfigs does NOT
>>>>>> re-read server.xml. It re-initializes the existing
>>>>>> in-memory configuration. If you want to e.g. change the
>>>>>> key alias, you'll have to make a JMX call to update the
>>>>>> alias and THEN call reloadSslHostConfigs.>
>>>>> *THAT *is probably my problem.
>
> Perhaps that method could have a better name, like
> reinitializeSSLHostConfigs. "reload" implies that it re-reads the
> server.xml which is not the case. At least the documentation
> should probabyl be better.
>
> In your case, where did you rediscover reloadSslHostConfigs?
>
>>>>> Do you know which MBean and operation that is?
>
> It's this (you'll have to interpolate a bit of this to fir your
> environment):
>
> Catalina:type=SSLHostConfigCertificate,ThreadPool="https-[cryptoimpl]-
[i
>
>
oimpl]-[addr]-[port]",Host="[host]",name=[cert-type]
>
> My test one was:
> Catalina:type=SSLHostConfigCertificate,ThreadPool="https-jsse-nio-127.
0.
>
>
0.1-12345",Host="_default_",name=EC
>
> Attach to Tomcat using VisualVM or your JMX browser of choice and
> have a look at what's there. You'll want to "set" the value of the
> attribute "certificateKeyAlias", then call reloadSslHostConfigs.
>
> -chris
>
>>>>> On Thu, Sep 10, 2020 at 4:00 PM Christopher Schultz <
>>>>> ch...@christopherschultz.net> wrote:
>>>>>
>>>>> Daniel,
>>>>>
>>>>> On 9/10/20 13:33, Daniel Skiles wrote:
>>>>>>>> In this case, I didn't remove every certificate, but
>>>>>>>> I did remove the certificate that was originally
>>>>>>>> being referenced after adding a new certificate under
>>>>>>>> a new alias.
>>>>>>>>
>>>>>>>> Original Keystore: Alias A Server.xml _default_
>>>>>>>> SSLHostConfig points to Alias A
>>>>>>>>
>>>>>>>> After Modification: Alias B Server.xml _default_
>>>>>>>> SSLHostConfig points to Alias B
>>>>>>>>
>>>>>>>>  
>>>>>>>>
>>>>>>>> If that's not supported, I'll see if I can keep the
>>>>>>>> aliases stable somehow.  If there is a way to do it,
>>>>>>>> I'd be interested in hearing
>>>>> what it
>>>>>>>> is.
>>>>>
>>>>> What are the real alias names? If you don't specify the key
>>>>> alias, Tomcat will use the first private key it finds in
>>>>> the file (which is essentially random, as Java keystores do
>>>>> not guarantee any kind of read-ordering).
>>>>>
>>>>> What does your  look like in server.xml?
>>>>>
>>>>> Can you also post the actual error and complete stack trace
>>>>> you get?
>>>>>
>>>>> If you change the key's alias, you'll need to change the
>>>>> alias listed in the  unless you are using the
>>>>> default first-key behavior 

Re: How to get the tag name from within a taglib class ?

2020-09-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Rony,

On 9/11/20 10:28, Rony G. Flatscher (Apache) wrote:
> While exploring, experimenting with creating a taglib (implementing
> the BodyTag interface) I would have a need to find out the tag name
> that caused the tagclass to run.
>
> Is this possible? If so, how would one be able to get at that tag
> name (any brief hints would suffice) ?
>
> ---rony
>
> P.S.: If possible I would like to write a single tagclass, but use
> it for two or more different tags, as the implementation would
> share quite a lot of code. Besides, it might be helpful for
> debugging.

It seems like this is the wrong approach, unless you just want to use
this for something like logging.

I you want the tags to behave differently, then you should have
separate tag implementations. Feel free to build a base class with the
shared code and then implement the differences in subclasses.

It's been a lng time since I wrote a custom tag library but I do
remember that the whole process was very painful and despite the
flexibility allowed by the API, lots of common things (like getting
the tag name!) were either awkward or impossible.

IMO, the JSP effort was a stepping-stone on a path to better
technologies like Velocity, FreeMarker, and others. If I were king,
JSP would just go away. Just my POV of course, you are welcome to fall
in love with JSP. :)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9btG8ACgkQHPApP6U8
pFiYyhAAxG/8tTbGEp9pN3RvxjvRQXf+UupG4S3CXQNoNeVr4ffpWWii0kLHLLpj
YoBpqNUjsl4Uki2jLADPioUHKdLOmVSlL6NTEcgMyEdIrCsI1A49okpnAIIX5EVB
SRbfiUnv+37zQrKn3HbNnW8p6OoANHaEpGyfP6ylv6nj85nm9eAmXeKy/BcQLrI3
qRPD4migbvxGSU5M36YbT74q4azYV0bXEDh/9M3+Ky6iuPGGe0H+Y6V/JoERQt6d
X3+QFxNWPxWW/BEoWkNjKfLHJgbYWQC5mgk7kK3u82DUV6fqGE95tiimhmSQwz8t
qfeS/nDVVCh2c2hARneHriD8LV7ve62gjfY0y6BfXJG8Jl0vg6kokgdGu9hABLDG
bj/BYjznC8qipN2I/X7Rn5eEr7RzxmMN3WigOFjsh4fUWNzcT6EP2CIphnmifPFx
gIwj7SPuWmB8itN2MV4EouF+MkEB9LSPQGeDxYn+hTnfucbVjlH9QVJ5vQDGyGkr
ZbmMB7HdriDj1CRWO22y2sxGHkKjRTb/uzkfy0XDNCJpw1SswaVcm9lep+aVq1zc
ocKGS8PTbFiSKGLHt+ythKqTcwWhFjStXgGxPVntw/aBzlfIfIUlA8bsteWAH6Ic
Go27fA6u0bBp+afq6gYbkTtGSY/leaFi1xfwX0G5uAT/AAVdObc=
=2h8G
-END PGP SIGNATURE-

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



Re: Track native memory of a Tomcat application

2020-09-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Arshiya,

On 9/11/20 13:06, Arshiya Shariff wrote:
> We have a standalone tomcat web application(Version 9.0.22) which
> runs on Linux . The application is used to process only  a single
> http request.

A single request, or a single *type* of request?

> But the physical memory usage of the application has increased to
> 4GB (output from the "top" command of Linux) , of which the heap
> has only 16 MB of live data.

Does it increase as the request is processed, or does the JVM take that
4GiB immediately upon startup?

Remember that the heap is only a part of the JVM's memory usage.
Examples of things that don't go into the heap are the native memory
used by the JVM itself (thinking of the JVM itself as a usual OS
process), stacks for each native thread, compiled Java code produced
by the JIT, and various I/O buffers.

> Is there a way to track the native memory of a tomcat process ?

The native memory of a Java application is very difficult to inspect,
etc. unless you are *very* familiar with JVMs, the memory manager being
used by your JVM, and the platform and architecture on which the JVM is
running.

The first thing to do would be to post the effective command-line
options that are being used when launching your JVM. One of the
easiest ways to do that is to run "ps | grep catalina" which will give
you the full command-line for the process.

That will show any memory parameters you may have specified on the JVM
at launch time, which will definitely affect the amount of native
memory your JVM process might end up taking up.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9bsqoACgkQHPApP6U8
pFhfOA//cb427EP07vqPihuQUNWZtbfRyiDn+9B1AWEXLxKChpomSznUDmZWXs/t
w7YE6v6h741M8MiHKCJeUNz537DRxzMMCdoIlFFE48mZ/SFrg6xPgpMr2wQksz5S
zyKmInSXRmjKFfv1VUZ1tS6nF8dSxC+iSgC+axyBxU3cywVdJ/hCq8ylgq1mc9F7
JllfyxpQ2cRyioYkJWSR04BVDtXMFlyIhuBat8/OrXAEtsqhXCDXvM3cp8RvcIp6
Sg05MCb3nNM2495xt/m8jc1ffcyho5S4CDD1mfNfTLGG5vie5D81i95ExkPt6Voj
8TTI+Yk9MhauSyeroAX67SVJaTDMPqK3fUMuz+IX31tFo/5YMaQAMIe+XF+LW6Kz
EsbSDMRB460j8zAigPIt/9KTSfA8xT8R0t3dMPZytaB01tZZi7atq89QcoR+irrP
bFiFmErEcTdtyNZWWFeBQiEy1qZ+0J5GZSr7+6ZUwED20RNeWeZ1czHy/JaAsXMQ
kNZqx3iXDWbYq6yTTPdC2tJkl5TST+TW62zdJqpjh7L7hh7P9hJSwjwcDvyOdrXD
0uTaU8j+4b2W7Ex7DPO7XVVaYnhFMRJPc0cgKHXyrlz8/5HOTNDxLafHyPXS7dya
ffdyNz0k88OawGKXlWrvDQggi82tVInsEJoJID56qEp7x9tUuyQ=
=MuBQ
-END PGP SIGNATURE-

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



Re: Changing the keystore alias of the _default_ SSLHostConfig while running.

2020-09-11 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 9/10/20 16:39, Daniel Skiles wrote:
>> Also note that calling reloadSslHostConfigs does NOT re-read
>> server.xml. It re-initializes the existing in-memory
>> configuration. If you want to e.g. change the key alias, you'll
>> have to make a JMX call to update the alias and THEN call
>> reloadSslHostConfigs.>
> *THAT *is probably my problem.

Perhaps that method could have a better name, like
reinitializeSSLHostConfigs. "reload" implies that it re-reads the
server.xml which is not the case. At least the documentation should
probabyl be better.

In your case, where did you rediscover reloadSslHostConfigs?

> Do you know which MBean and operation that is?

It's this (you'll have to interpolate a bit of this to fir your
environment):

Catalina:type=SSLHostConfigCertificate,ThreadPool="https-[cryptoimpl]-[i
oimpl]-[addr]-[port]",Host="[host]",name=[cert-type]

My test one was:
Catalina:type=SSLHostConfigCertificate,ThreadPool="https-jsse-nio-127.0.
0.1-12345",Host="_default_",name=EC

Attach to Tomcat using VisualVM or your JMX browser of choice and have
a look at what's there. You'll want to "set" the value of the
attribute "certificateKeyAlias", then call reloadSslHostConfigs.

- -chris

> On Thu, Sep 10, 2020 at 4:00 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Daniel,
>
> On 9/10/20 13:33, Daniel Skiles wrote:
>>>> In this case, I didn't remove every certificate, but I did
>>>> remove the certificate that was originally being referenced
>>>> after adding a new certificate under a new alias.
>>>>
>>>> Original Keystore: Alias A Server.xml _default_
>>>> SSLHostConfig points to Alias A
>>>>
>>>> After Modification: Alias B Server.xml _default_
>>>> SSLHostConfig points to Alias B
>>>>
>>>>  
>>>>
>>>> If that's not supported, I'll see if I can keep the aliases
>>>> stable somehow.  If there is a way to do it, I'd be
>>>> interested in hearing
> what it
>>>> is.
>
> What are the real alias names? If you don't specify the key alias,
> Tomcat will use the first private key it finds in the file (which
> is essentially random, as Java keystores do not guarantee any kind
> of read-ordering).
>
> What does your  look like in server.xml?
>
> Can you also post the actual error and complete stack trace you
> get?
>
> If you change the key's alias, you'll need to change the alias
> listed in the  unless you are using the default
> first-key behavior .
>
> Also note that calling reloadSslHostConfigs does NOT re-read
> server.xml. It re-initializes the existing in-memory configuration.
> If you want to e.g. change the key alias, you'll have to make a JMX
> call to update the alias and THEN call reloadSslHostConfigs.
>
> -chris
>
>>>> On Thu, Sep 10, 2020 at 11:34 AM Christopher Schultz <
>>>> ch...@christopherschultz.net> wrote:
>>>>
>>>> Daniel,
>>>>
>>>> On 9/10/20 09:09, Daniel Skiles wrote:
>>>>>>> Is it possible to change the keystore alias of the
>>>>>>> _default_ SSLHostConfig's certificate while tomcat is
>>>>>>> running?
>>>>>>>
>>>>>>> At present, I'm trying to move the _default_
>>>>>>> certificate from one certificate in my keystore, to
>>>>>>> another.  I modify the server.xml, then I call the
>>>>>>> reloadSslHostConfigs MBean operation.  The operation
>>>>>>> throws an error that boils down to a
>>>>>>> jsse.alias_no_key_entry error that comes back from the
>>>>>>> JVM.
>>>>>>>
>>>>>>> Is this a technical limitation on SNI/SSLHostConfig, or
>>>>>>> am I missing something here?
>>>>
>>>> Did you remove all server certificates from your keystore and
>>>> then try to bounce the connector? That's not going to work
>>>> because the connector requires a server key and certificate.
>>>>
>>>> Instead of "moving" the cert, consider copying the
>>>> certificate instead.
>>>>
>>>> -chris
>>>>>
>>>>> --
- ---
>>>>>
>>>>>
>
>>>>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>>>>> For ad

Re: Tomcat Processing Timer Question

2020-09-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eric,

On 9/10/20 15:29, Eric Robinson wrote:
> Chris --
>
>
>> You should also look at worker-thread availability. When you see
>>  these "high latency" (which is usually a term reserved for I/O
>> characterization) events, do you have:>> 1. Available worker
>> threads (from the executor thread pool) 2. Any other
>> shared/limited resource (e.g. DB connection pool)
>>
>
> Good thought. I should mention that the hosted application is
> canned, and is the same for all tomcat instances, with only minor
> variations in version between them. User workflow is also similar.
> Over the years we've developed a good feel for expected
> performance and resource utilization based on the user count per
> instance. So when one instance exhibits anomalous performance, we
> tend to go right to networking issues.
>
>> Also, are you seeing the otherwise unexpected slowness on each
>> Tomcat node, or are you seeing it at the
>> load-balancer/multiplexer level?
>>
>
> We run multi-tenanted servers, with many instances of tomcat on
> each server. We've never seen issues at the load-balancer.

What I mean is, are you measuring the request at the Tomcat level, or at
the load-balancer level? If you are watching at the lb, then your lb
might pick a "busy" Tomcat and the request has to "wait in line" before
processing even begins. If you sample at the Tomcat level, you'll see no
discernible slowdown because the time "waiting in line" does not count.

> Very occasionally, there might be a problem at the server level.
> When that happens, all instances on that server may become
> sluggish. What I'm talking about in this thread are cases where
> only one instance on a server is showing slowness in its jasper
> logs. Also, we typically do not see the same slowness when we test
> the application locally from the same network. I've had my eye on
> TCP retransmits as a possible culprit for a while, but I just
> didn't know for sure if my understanding of the tomcat processing
> timer is correct.
I hope we've cleared that up for you, then.

You might also want to read about "buffer bloat" if you aren't already
familiar with that term.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9aiH4ACgkQHPApP6U8
pFiFfBAAvuUbRXK+iDDy7lLsw6eplMFrXXDbkxzwtSNafvdGlDWmcPWwdazZwhQ+
TJ0pzkUwf3/RBslu/oORJYelYKhpUJLodj0Y85ZtbuKBcU2JpKk1uueJ/aqnmVFK
9yep3ReYdggEXQ3JNb1VeI4ASdEhFWoFw8pc6DAcJZ4K2JaUtGKrtoWG8n+oEXos
kmthl9Dm9ge3edLimd7TPTx11iODi6pX3ddJ+uRh7qmvXZp4wVyX8W+hkKiOhUQM
hokUd8RruXQm6wut5m+JSO6eLHqkKUBiLspzlz1x/Y4cuaqAlC8Pl5y9NFTuLK3e
gFJeDmBUthN2y5h9KNKW5r+Gf9bKpuv1+kw7CIaNoFv2JxCGTmfL3VKM+Bp/rh7J
1SbshsTW6ffo5hKRNJUJKvxry3uUvzrss0AYe338tJ1QA+sHuXHsN8ZVtY3b+51O
HBOYf3pgIPsSd6zXkjaSRoOAhVc9G5sbJHx8ycQt+yAyVvXEUwrqeeRbsJeADk2s
reaizm9WvO2kHSqP93ANNYe1QJ+rw9b5og0uoCE8x9eO+czRHbJ7LFF6/rvX+6Pn
TIYB7AHyV8P3PHpHtBGIgaNfnvIYbqx/hzxJpLlpNEcS2zARfi1YCnuNtbiH0KU/
AKkBx5FnZvwclCA3qK2oqBnSEcBUFz2yobq4wAy//qwgL2gEFNc=
=mcpm
-END PGP SIGNATURE-

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



Re: 400 error when upgrading tomcat

2020-09-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian,

On 9/10/20 13:13, Brian Harris wrote:
> We’re having an issue when upgrading Tomcat from 8.5.50 to 8.5.51.
> Since moving to this version, requests sent to the http port are
> failing with a 400 error code(bad request).  The server.xml is
> configured to redirect the http port to the https port.  This has
> worked for years and did not start failing until the upgrade.
> Below is the connector config and the java class used to send a
> test transaction to the server.
>
> I’ve searched the change log and the only change I can see that
> might cause this is the Bug fix for bug 63966 – Charset of TLS
> message is hard coded to ISO-8859-1.  This bug fix was introduced
> into 8.5.51.  The reason I believe this might be the reason is when
> we would send this request to tomcat 8.5.50 the reply Content-Type
> would look like this:
>
>
>
> Content-Type: text/plain;charset=ISO-8859-1
>
>
>
> With tomcat 8.5.51, I get this:
>
> Content-Type: text/html;charset=utf-8
>
>
>
> Any ideas why I’m getting the 400 error when upgrading to 8.5.51
> and beyond ?
>
>
>
> Connector config:
>
>
>
> 
> connectionTimeout="2"
>
> redirectPort=""
>
> />
>
>
>
> 
> scheme="https" secure="true"
> ciphers="TLS_DHE_DSS_WITH_AES_128_GCM_SHA256,TLS_DHE_DSS_WITH_AES_256_
GCM_SHA384,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_256_
GCM_SHA384,TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_ECDSA_WITH_AE
S_256_GCM_SHA384,TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDH_RSA_WITH_
AES_256_GCM_SHA384,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECD
SA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECD
HE_RSA_WITH_AES_256_GCM_SHA384"
>
>  clientAuth="false" sslProtocol="TLS"
> sslEnabledProtocols="TLSv1.2"
>
> keyAlias="myKey"
>
> keystore="NONE"
>
> keystorePass="password"
>
> keystoreType="PKCS11"
>
> keystoreProvider="myprovider"
>
> enableLookups="false"
>
> server="server"
>
> "/>
>
>
>
>
>
> Java class used to send the test transaction:
>
>
>
> package com.testing;
>
>
>
> import java.io.*;
>
> import java.net.*;
>
> import java.util.Date;
>
> import java.text.DateFormat;
>
> import java.text.SimpleDateFormat;
>
>
>
> public class RunTestTran{
>
>
>
> public  RunTestTran() {
>
> }
>
>
>
> public static void main(String [] args){
>
> RunTestTran recordProcessorTest = new RunTestTran();
>
> recordProcessorTest.runTran("localhost", ,
> "/requestProcessor/rp");
>
> }
>
>
>
> private void runTran(String ip, int port, String appName){
>
> Socket socket = null;
>
> PrintWriter out = null;
>
> BufferedReader in = null;
>
> String dataToSend = "";
>
>
>
> //Create socket connection
>
> try {
>
> socket = new Socket(ip, port);
>
> out = new PrintWriter(socket.getOutputStream(), true);
>
> in = new BufferedReader(new
> InputStreamReader(socket.getInputStream()));
>
> } catch  (Exception e) {
>
> System.out.println("Exception:" + e.toString() );
>
> System.exit(1);
>
> }
>
>
>
> DateFormat dateFormat = new SimpleDateFormat("MMddHHmmsss");
>
> //get current date time with Date() to create a 11 digit tran id
>
> Date date = new Date();
>
> String tranId = dateFormat.format(date);
>
> String PRIMER_TRAN = " V " + tranId + "990JANE
> DOE 100 Redwood Shores Pkwy Redwood City
> CA94065000  PRIMER TRAN";
>
>
>
>
>
> try{
>
> dataToSend = URLEncoder.encode("inputRecord", "UTF-8") + "=" +
> URLEncoder.encode(PRIMER_TRAN, "UTF-8");
>
>
>
> }catch(Exception e){
>
> System.out.println("Exception caught!" + e.toString());
>
> }
>
> // send message
>
> StringBuffer sb = new StringBuffer();
>
> sb.append("POST /" + appName + "/wrp HTTP/1.1\r\n");
>
> // Try connection close-- see if it does close
>
> sb.append("Connection: close\r\n");
>
> sb.append("Accept: image/gif, image/x-xbitmap, image/jpeg,
> image/pjpeg, application/vnd.ms-powerpoint,
> application/vnd.ms-excel, application/msword\n");
>
> sb.append("Accept-Language: en-us\n");
>
> sb.append("Accept-Encoding: gzip, deflate\n");
>
> sb.append("User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows
> NT 5.0)\n");
>
> // Authorization
>
> sb.append("Authorization: Basic DK34a3RvbWVydGVzddkK7WCx\n");
>
> sb.append("Host: " + ip + ":" + port + "\n");
>
> sb.append("Content-Length: " + dataToSend.length() + "\r\n");
>
> sb.append("Content-Type: application/x-www-form-urlencoded\r\n");
>
> sb.append("\r\n");
>
> sb.append(dataToSend);
>
> // Send data
>
> String text = sb.toString();
>
> out.println(text);
>
>
>
> System.out.println("\nText sent " + text.length() + " bytes:");
>
> System.out.println(text + "\n\n");
>
>
>
> try{
>
> String gotBack1 = in.readLine();
>
> System.out.println("Text received:" + gotBack1 );
>
> String gotBack = null;
>
> while (  (gotBack = in.readLine()) != null){
>
> System.out.println("Text received:" + gotBack );
>
> if ( (gotBack.indexOf("TQ!") != -1)){
>
> break;
>
> }
>
> }
>
> } catch (Exception e){
>
> System.out.println("Read 

Re: Changing the keystore alias of the _default_ SSLHostConfig while running.

2020-09-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 9/10/20 13:33, Daniel Skiles wrote:
> In this case, I didn't remove every certificate, but I did remove
> the certificate that was originally being referenced after adding a
> new certificate under a new alias.
>
> Original Keystore: Alias A Server.xml _default_ SSLHostConfig
> points to Alias A
>
> After Modification: Alias B Server.xml _default_ SSLHostConfig
> points to Alias B
>
>  
>
> If that's not supported, I'll see if I can keep the aliases stable
> somehow.  If there is a way to do it, I'd be interested in hearing
what it
> is.

What are the real alias names? If you don't specify the key alias,
Tomcat will use the first private key it finds in the file (which is
essentially random, as Java keystores do not guarantee any kind of
read-ordering).

What does your  look like in server.xml?

Can you also post the actual error and complete stack trace you get?

If you change the key's alias, you'll need to change the alias listed
in the  unless you are using the default first-key behavior
.

Also note that calling reloadSslHostConfigs does NOT re-read
server.xml. It re-initializes the existing in-memory configuration. If
you want to e.g. change the key alias, you'll have to make a JMX call
to update the alias and THEN call reloadSslHostConfigs.

- -chris

> On Thu, Sep 10, 2020 at 11:34 AM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> Daniel,
>
> On 9/10/20 09:09, Daniel Skiles wrote:
>>>> Is it possible to change the keystore alias of the _default_
>>>> SSLHostConfig's certificate while tomcat is running?
>>>>
>>>> At present, I'm trying to move the _default_ certificate from
>>>> one certificate in my keystore, to another.  I modify the
>>>> server.xml, then I call the reloadSslHostConfigs MBean
>>>> operation.  The operation throws an error that boils down to
>>>> a jsse.alias_no_key_entry error that comes back from the
>>>> JVM.
>>>>
>>>> Is this a technical limitation on SNI/SSLHostConfig, or am I
>>>> missing something here?
>
> Did you remove all server certificates from your keystore and then
> try to bounce the connector? That's not going to work because the
> connector requires a server key and certificate.
>
> Instead of "moving" the cert, consider copying the certificate
> instead.
>
> -chris
>>
>> -
>>
>>
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@tomcat.apache.org
>>
>>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9ahc4ACgkQHPApP6U8
pFi2eRAAjhoX34ml8l52UTxCc0TdjcX9trDPqKLqceFLmaMLvW58F8xmDVcLCMtS
qJTbHeQZepnDq4H/knG5YqYvI10zVshdY94vb2QdPEp6bS8zXpFYPZ96/E1T8CKA
bMvhmITskOdeIVeV4dZbSDM/JvrUtoPe4cfWzzP8QLTXOfN2DgdH3wYmuivZjQXR
b86fTfzB4jwF96uDANV6TMmw5q7TNgvxwBllVnCuuv1Scoqdy3cNt10N6X2zCSPc
+cA5VETPeAwl8q+j9UPJr21kDzcny0nUhC1s+mkuiSAdMEiPaByeV2VbuqYhD3/7
2df/f7ssMaGP6XT76LqjpINmxuTEXngRl+FPXwE76+Q/PqBpkZnaqq8d2koRGum+
scTK9sQkwzZzaLKtTH+9gMgozEup6SmowHKIcqifE+2IUcoH03bwbv16ulwQkqHZ
XidNj370sJkFVQpm8DUsMhUvL2s+znWusyZza7KWzgWvZdO0XVFn/1dvxB/NGB8E
3wiRs6TVWyndZYV91k++mp3iYigDSmIwljd2gzLrZUJ1S5m7+NWT1hkpY7vxYWZ5
6l9hWmy6r3iVSnP4Oy+OedPC6RA08mXPhNAZEfyBNq/cfrfrXJLPaXItxS6dRPWv
81J6z7r7RFJeeJLgqa0yTj9zasHZ6acgswWOg2I6/B6gVsJ5SVY=
=Uu1T
-END PGP SIGNATURE-

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



Re: Changing the keystore alias of the _default_ SSLHostConfig while running.

2020-09-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 9/10/20 09:09, Daniel Skiles wrote:
> Is it possible to change the keystore alias of the _default_
> SSLHostConfig's certificate while tomcat is running?
>
> At present, I'm trying to move the _default_ certificate from one
> certificate in my keystore, to another.  I modify the server.xml,
> then I call the reloadSslHostConfigs MBean operation.  The
> operation throws an error that boils down to a
> jsse.alias_no_key_entry error that comes back from the JVM.
>
> Is this a technical limitation on SNI/SSLHostConfig, or am I
> missing something here?

Did you remove all server certificates from your keystore and then try
to bounce the connector? That's not going to work because the
connector requires a server key and certificate.

Instead of "moving" the cert, consider copying the certificate instead.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9aR2MACgkQHPApP6U8
pFjomg/9FqiIt/N4Ap/2SfpupzkHdzUQGwTvCXEXDZl8Z+jMrr1TaMjUGgIjOgFk
MUbNxrQRxfV0Mc1aipE0doU8/5Ps9rmluceC8SLkrmf7+ir9YnRXYYfYt1EV1Y+o
Bcb1/ZoRXayImZntEH8+J/8qbg58wk/xlLalPsjDgJ3MOJrw/AD7A1caBUuLCnxc
ZZWGCm6skRoCKZuVQWfEVU2c02gv2K2ga7TLQ68MJUv1/qH40escUIGgdTReYYIV
vxZ/3L/Nab9055ZCDriSn3HPTt2CD/4na7fgYVjAP5TntX6nfIiXvAA0h/Tba6KY
iYgPm0tv7M+nXqWDUSpi5IKQ3rSCpHgRhjq9wqii18SvKpYk0JbYxSMZIJtz9PVQ
uBdYUFOZadchcp9KASDEd7WUeKnmxYsX4Qn7NVtVgrrwYewj33ETlUoB5zFzmYMI
8+K0g+b9/AhWtVLOMFcL+kCKWjwpANu9wvHWUnOS7urZVPQ7i/5yCt0N8fNsmCYj
m5SPYXwExOzYBy4esH+3za9qSC//GxB+xW9lJHCZMaZmx4LClq2qC2EXXpSAm/WO
Pz25gGaQog5dNvf0AN/y7u7od3QTQmNqOYS3S6cRPkadlRt25QocgQV4gVulRDY1
kjnJ1Tf5p1v/Y/SqD6k2NOwXeiNUC/AOm/+8LLQgxAjn1zMVJUg=
=MuZ9
-END PGP SIGNATURE-

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



Re: Tomcat Processing Timer Question

2020-09-10 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eric,

On 9/9/20 20:42, Eric Robinson wrote:
> Hi Chris --
>
>> Are you have any specific problem you are trying to diagnose or
>> fix? Or are you just academically interested in what conditions
>> might
cause "slow"
>> request processing?
>
> A little of both. We've been running about 1500 instances of
> tomcat for the past 15 years. We're not tomcat experts by any
> means, but we're always looking to refine our understanding of
> tomcat performance. Like many people, we have custom scripts (ours
> are in python) that parse the jasper logs and produce a report
> that summarizes responsiveness and helps us isolate underperforming
> tomcat instances and JSP calls. Occasionally, we see evidence of
> chronic high latency in processing time when there is no indication
> of bottlenecks or problems in the servers themselves or the
> database back-ends. We theorize that client connectivity could be
> responsible.
That is a reasonable conclusion.

You should also look at worker-thread availability. When you see these
"high latency" (which is usually a term reserved for I/O
characterization) events, do you have:

1. Available worker threads (from the executor thread pool)
2. Any other shared/limited resource (e.g. DB connection pool)

Also, are you seeing the otherwise unexpected slowness on each Tomcat
node, or are you seeing it at the load-balancer/multiplexer level?

- -chris

>> -Original Message- From: Christopher Schultz
>>  Sent: Wednesday, September 9, 2020
>> 7:41 AM To: users@tomcat.apache.org Subject: Re: Tomcat
>> Processing Timer Question
>>
> Eric,
>
> On 9/8/20 17:29, Eric Robinson wrote:
>>>> Got it. So TCP retransmits can impact tomcat processing time
>>>> under certain conditions, more likely due to issues with
>>>> receiving requests from the client than sending responses.
> Well... buffering can happen either during the client-write phase
> or the server-read phase or both.
>
> Imagine a slow network like EDGE or something similar where the
> first byte arrives at Tomcat's poller and it handed-off to the
> request-processor (t=0 as far as Tomcat is concerned) and uploads a
> large image over that EDGE connection. The OS won't allocate an
> infinite input buffer, so at some point the Poller will get byte 0
> when the client hasn't uploaded the complete request. It may still
> take several seconds to upload all those bytes.
>
> Imagine that the response is a transformed image so the response is
> also large. The OS won't allocate an infinite output buffer, so at
> some point the bytes will start streaming to the client (at a slow
> rate). When the output buffer fills, your request-processing thread
> will stall when calling ServletOutputStream.write() to write those
> image bytes.
>
> If your image transform is instantaneous, your access log will
> report that the request took "a long time" relative to the amount
> of time spent actually processing the request. Basically, you are
> just waiting on I/O the entire time.
>
> Are you have any specific problem you are trying to diagnose or
> fix? Or are you just academically interested in what conditions
> might cause "slow" request processing?
>
> Hope that helps, -chris
>
>>>>> -Original Message- From: Mark Thomas
>>>>>  Sent: Tuesday, September 8, 2020 4:05 PM
>>>>> To: users@tomcat.apache.org Subject: Re: Tomcat Processing
>>>>> Timer Question
>>>>>
>>>>> On 08/09/2020 21:46, Eric Robinson wrote:
>>>>>> Hi Mark --
>>>>>>
>>>>>> "If the request is split across multiple packets the
>>>>>> timer starts when Tomcat
>>>>> reads the first byte of the request from the first packet.
>>>>>> Tomcat stops the timer on a request after the last byte
>>>>>> of the response has
>>>>> been accepted by the network stack."
>>>>>>
>>>>>> Now we're getting somewhere. If tomcat starts its timer
>>>>>> when it reads the
>>>>> first byte of the client's request, and the request is
>>>>> split into multiple packets, doesn't it stand to reason
>>>>> that the timer would run longer when there are TCP
>>>>> retransmits?
>>>>>
>>>>> For the request, it depends. If the retransmit is for part
>>>>> of the request body and Tomcat hasn't read that far yet (or
>>>>> starting reading at all) then it probably won't impact the
>>>>> pro

Re: HTTP2: Connections abruptly closed by sending GOAWAY

2020-09-09 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Arshiya,

On 9/9/20 08:30, Arshiya Shariff wrote:
> Can you please help us understand this behavior .
>
> The following is the sequence of events that is happening for a
> few streams .

Your images were stripped from the list. Can you use text to describe
the situation? Or if it must be an image, post the image somewhere
public and post a link to the list.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9Yz6YACgkQHPApP6U8
pFhz1Q/+JH0kJalYAG/dUTX+mn/LloB2jo4Ae8Iq651voey4VHTWquBQNayn3QiK
o+6ZUZopb4UqkcGduXXdfqce/8v/WqOVXGtHOkHhpYQ0DwTHBY00yfWDnLJMaAbm
hqZ/d+k9zaQK2i1F4jPJrGHKjgrhI0lLXMZR/BQ4Nevjh6VOarSWw44o/wL/Lol3
XdQiDX5BHfSjYUbWhVWp45UDGYBWoF4EBeiFVqLUe/NRrj+8GjIQPLVPnhTN1xKi
G+LMaES6KWGX2AhDPpatbs8PXrmvBzEhKEK+Z7qRHdKiiwJ4MaSSsfW+MuwW94Dc
kTotzKDhw+VA1N8NqLFsS1KUkrhKv4nnYJ7tUpuaQU5eCZajvWwGGp26jAhl23MJ
RJHpwNCj2T6an68IEjV8QqdbnxGBGLd0PzXJvyzyfQsiRxeTXlUEClaeuG7OCQod
KlN4boOESPQysQ5c79yl8Ihyac5E+XbGtqkuSZNE1hO4AcFZyHim0uF6xWKMijen
kCmJob2eIvEjqWr29z8GKDjmU8xc6ypWsCH9Lvo7rLLustlz4PT6T47j0AskPxg6
+5GsN+if5Aeh7ezamxK1jUjB8oj2N5etYEkYiVDtZas+NY+4+h0dgf/l4tK3En5b
EgAh0qDUpLc7pYFbSwdDVh+WezHewI/NPjQPk6FLQ6vEb5K3tKE=
=T1B+
-END PGP SIGNATURE-

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



Re: Truststore in HTTPS Connector does not work with Linux

2020-09-09 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 9/9/20 02:46, David Weisgerber wrote:
> Hi Christopher,
>
>> This should be okay, though it is a little unusual to use the
>> same keystore for both "keys" and "trusted certs". Can you
>> confirm the contents + types of everything in the keystore?
>
> After your approach from the end of your response, I exported the
> certificate of main and stored it as dummy:
> root@d3bf84b82698:/diagdata# keytool -list -keystore keystore.jks
> Enter keystore password: Keystore type: PKCS12 Keystore provider:
> SUN
>
> Your keystore contains 2 entries
>
> dummy, Sep 9, 2020, trustedCertEntry, Certificate fingerprint
> (SHA-256):
> 07:C1:D4:06:AC:0E:55:C2:25:41:FE:0E:35:9D:9C:8C:03:42:E4:D2:AA:74:1E:0
E:21:11:3A:97:CE:A2:AD:22
>
>
main, Sep 8, 2020, PrivateKeyEntry,
> Certificate fingerprint (SHA-256):
> 07:C1:D4:06:AC:0E:55:C2:25:41:FE:0E:35:9D:9C:8C:03:42:E4:D2:AA:74:1E:0
E:21:11:3A:97:CE:A2:AD:22
>
>
root@d3bf84b82698:/diagdata#
>
> This gives me the same error message as before.

Ugh. That *does* point toward a bug in Tomcat itself or something odd
with the JVM.

>> Are you really using Tomcat 8.5.4 and 8.5.5? If so, you are like
>> 4 years out of date and there are published security
>> vulnerabilities affecting your Tomcat version. Can you try with
>> 8.5.latest which is currently 8.5.57?
>
> No, we automatically ship the latest 8.5 tomcat version. However
> for our docker based distribution I was sure that this feature
> worked at some time (I think I used tomcat 8.0 for this). I tried
> it with the latest 8.5.57 on Windows, there everything works
> correctly. I just checked all the versions to see when the "bug"
> was introduced.

Did you find it? I took a quick look at the 8.5.x changelog and
nothing jumped-out at me.

>>> Is this a Linux specific bug?
>
>> That would be unusual, but certainly possible. Are you *sure*
>> this works with no other changes other than:
>>
>> 1. Switching to Windows or 2. Switching to Tomcat 8.5.4?
>>
>> My guess is that the keystore is not bit-for-bit identical to
>> your Windows or Tomcat 8.5.4 environments.
>
> Yes, I copied the keystore that works for Windows and copied it to
> the docker test environment. The windows keystore gives me the
> same error message.
Rats. Thanks for confirming.

>> $ keytool -exportcert -alias 'www.example.com' -rfc -keystore
>> /diagdata/keystore.jks BEGIN CERTIFICATE= blah blah blah
>> =END CERTIFICATE=
>>
>> $ keytool -importcert -alias 'dummy' -keystore
>> /diagdata/keystore.jks [paste cert here]
>
> I tried this but it did not help...

Grr. The good news is that the latest version does work, so it must
have been fixed at some point. :)

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9Yz04ACgkQHPApP6U8
pFhHBg//fZf2gI1jEa4r4aXeBOu+i1B2cSwUUChQACPWw6wVFf2KbP8K2XNpz3Dh
f3eEk1QQ8ApeZUDq2FfdT9twH4tTfzuYPJZF44Mzig/CNF9hR8VB18hGt+ezuIdk
pqGcoYECM6OnE2B1wKwFm18NZkyZ87XKXOgMCqjkApH/KgmzYgLnbSw7ZnoH9lZG
hhBYKS1pqcDOgfIbFgV7TS9LnooJlkr2f2IXzx5ohXeAbBQ7/uSWZJ3KmZa/eXIk
lquqCgluuPh21vlhhXDERS0I+Eogto8BNpIQZaRnjsv4SAXu4VnhV7RGB4n4RhjW
v9bowgAqR4El4UI+CXhE5UJnxAtmXQ3LvEyAtLQ53BEDNiLpHl1Gub/u14QDbHUW
3dXXGNhpWTB7TVm3ILmRFFQWLTmPFgMSwplWSB3Z9goHsshy6PgVTx/aUkPdUOLS
6f9A5pBAfG0PvaGxUEgfvvrMGX3uDYu9yFtnQmoX1ooDCOdGOvGWJDXpb6uf3Byg
n/vHSjpaFGqnNm9uRVcT01sqEt5sBBRO/m8oIQJK7sSV8kGojaYRTDlE0zOX0Ydd
E5h0B7sp4CKhfCLBH88/SUoP1V2/o5Z1VwyquqW6+UsmI/nsaopIe0A/jmT8eDcI
2YavTgS9OdKZRFYOeed1IzWU0VKsog2TWmJT5s7Vuj29SBHknP0=
=j+Ie
-END PGP SIGNATURE-

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



Re: Tomcat Processing Timer Question

2020-09-09 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eric,

On 9/8/20 17:29, Eric Robinson wrote:
> Got it. So TCP retransmits can impact tomcat processing time under
> certain conditions, more likely due to issues with receiving
> requests from the client than sending responses.
Well... buffering can happen either during the client-write phase or
the server-read phase or both.

Imagine a slow network like EDGE or something similar where the first
byte arrives at Tomcat's poller and it handed-off to the
request-processor (t=0 as far as Tomcat is concerned) and uploads a
large image over that EDGE connection. The OS won't allocate an
infinite input buffer, so at some point the Poller will get byte 0
when the client hasn't uploaded the complete request. It may still
take several seconds to upload all those bytes.

Imagine that the response is a transformed image so the response is
also large. The OS won't allocate an infinite output buffer, so at
some point the bytes will start streaming to the client (at a slow
rate). When the output buffer fills, your request-processing thread
will stall when calling ServletOutputStream.write() to write those
image bytes.

If your image transform is instantaneous, your access log will report
that the request took "a long time" relative to the amount of time
spent actually processing the request. Basically, you are just waiting
on I/O the entire time.

Are you have any specific problem you are trying to diagnose or fix?
Or are you just academically interested in what conditions might cause
"slow" request processing?

Hope that helps,
- -chris

>> -Original Message- From: Mark Thomas 
>> Sent: Tuesday, September 8, 2020 4:05 PM To:
>> users@tomcat.apache.org Subject: Re: Tomcat Processing Timer
>> Question
>>
>> On 08/09/2020 21:46, Eric Robinson wrote:
>>> Hi Mark --
>>>
>>> "If the request is split across multiple packets the timer
>>> starts when Tomcat
>> reads the first byte of the request from the first packet.
>>> Tomcat stops the timer on a request after the last byte of the
>>> response has
>> been accepted by the network stack."
>>>
>>> Now we're getting somewhere. If tomcat starts its timer when it
>>> reads the
>> first byte of the client's request, and the request is split into
>> multiple packets, doesn't it stand to reason that the timer would
>> run longer when there are TCP retransmits?
>>
>> For the request, it depends. If the retransmit is for part of the
>> request body and Tomcat hasn't read that far yet (or starting
>> reading at all) then it probably won't impact the processing
>> time. If Tomcat is performing a read and waiting for that packet
>> then it will.
>>
>> For the response, not unless the response is sfficiently big and
>> the retransmit sufficiently earlier in the response that the TCP
>> buffers fill and Tomcat is blocked from further writes.
>>
>> Mark
>>
>>
>>>
>>> --Eric
>>>
>>>> -Original Message- From: Mark Thomas
>>>>  Sent: Tuesday, September 8, 2020 3:34 PM
>>>> To: users@tomcat.apache.org Subject: Re: Tomcat Processing
>>>> Timer Question
>>>>
>>>> On 08/09/2020 21:19, Eric Robinson wrote:
>>>>> Hi Mark and Christopher,
>>>>>
>>>>> For clarification, suppose a client sends and HTTP POST
>>>>> request which
>>>> is bigger than the PMTU and has to be broken into multiple
>>>> packets. It sounds like you're saying that the request is
>>>> buffered by the network stack, and the stack does not send it
>>>> up to tomcat until the full
>> request is received.
>>>> That would make sense if every HTTP request is encapsulated
>>>> in its own separate TCP connection. Most of the time, that is
>>>> not the case. A single connection is held open and used for
>>>> multiple HTTP requests. The network stack has no
>>>> understanding of anything above TCP, so it does not know when
>>>> an HTTP request complete. It must therefore deliver whatever
>>>> it has, and it would be up to tomcat to decide when the HTTP
>>>> request is complete, wouldn't it?
>>>>>
>>>>> If that is the case, tomcat could receive a partial HTTP
>>>>> request and
>>>> would have to wait for the rest before processing it. So when
>>>> does tomcat start its processing timer?
>>>>
>>>> Tomcat starts the processing timer as soon as Tomcat
>>>> processes the first bytes of the request. In p

Re: Tomcat Processing Timer Question

2020-09-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eric,

On 9/8/20 13:46, Eric Robinson wrote:
> It is my understanding that the AccessLogValve %D field records the
>  time from when the last byte of the client's request is received
> to when the last byte of the server's response is placed on the
> wire. Is that correct? If so, would TCP retransmissions impact the
> timer?

I'm not positive, but I believe Tomcat has zero visibility into that
level of detail.

> If there are connectivity issues between the client and server,
> resulting in TCP retransmits, could that appear as higher response
>  times in the localhost_access logs?

This would only happen if the re-transmissions were to cause network
buffering in the OS such that the stream writes (at the Java level) were
to block (and therefore "take time" instead of being essentially
instantaneous).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9XyvUACgkQHPApP6U8
pFi2PQ/9Er4fN490tP2Fq911WSX7+wQnnRwE9w5JWx36b++DtFAWxKJTpQGg0Dl2
pyP/1vVPB6ZHVPdVEUUvYPAzhDAVWJVrIdXUvcaMg2tKpb5zzERhdxpG2vEHQykb
YaRTPqu0QHNySjMyQ9yT3Q8YDSObvXAYnR+7f1aT1g9UOma63z4mKE11RuQloXGz
SqjiLzHjDQmehplDjTXTSwRxcjnJftCKG0Jwin4f8Kto6tJ/AJdTxaWmwXeSiRcn
QN8b586DpyS/k0hgkJ0bOWhbxVsy4aUhM+PeyjN4AXufzSjymY4hv4hpOO+37woT
SRj3rTd2LtS8h5v4VVSIFXTeL+kEwjo3iya/Komd4Z7Pu+qw91ZLy7LIrZfV4MHp
8me2jLobBiosIlXSAAxVjY3zOVlzqEOIjOL+t/Qwhn+CM/nDLfuhtwdfuu+KGpNs
/u18gauI4eb4MtoSETcvb5OaFHdkrmInCD3BXz9ZZRrnVCL9r9SLPN1yxENerdVq
RJrvJMItb5tLf0XcK7Wvm+lJIdArEkSCzZ3o3uDWbiRkN0hKU5R/Jndr/qfL12dj
/knGWyED0UGaY58TgOMAN6veMO991/PTL6to5Xr6RTivEQO+6YYS1zj1uGPc5p/n
gGnJ9b9VWeZBvlyDb7H9CxOvvkdJzMum6WaagIvmR5zi8ZZx3do=
=QoNs
-END PGP SIGNATURE-

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



Re: Truststore in HTTPS Connector does not work with Linux

2020-09-08 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 9/8/20 03:58, David Weisgerber wrote:
> I have some weird problem or bug with the HTTPS Connector. In our
> product, that ships with tomcat we want to achieve the following:
>
> There is one keystore where the customer puts its server
> certificate for HTTPs as well as (if intended) zero or one
> certificate for client authentication. The certificate for client
> authentication can be self-signed and the customer can setup its
> own certificate authority for this.
>
> For this I put the following code for configuring the connector in
> the server.xml:>  protocol="org.apache.coyote.http11.Http11NioProtocol"
> maxThreads="150" SSLEnabled="true" scheme="https" secure="true"
> bindOnInit="false" clientAuth="false" sslProtocol="TLS"
> keystoreFile="/diagdata/keystore.jks" keystorePass="custo1234"
> keyAlias="main" truststoreFile="/diagdata/keystore.jks"
> truststorePassword="custo1234" />

This should be okay, though it is a little unusual to use the same
keystore for both "keys" and "trusted certs".

Can you confirm the contents + types of everything in the keystore?

> (The real clientAuth is done in the deployed application because it
> is more complicated, I just need the feature to be enabled). This
> gives me the following error:
> org.apache.catalina.LifecycleException: Protocol handler start
> failed <2>at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1
038)
>
>
<2>at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2>at
> org.apache.catalina.core.StandardService.startInternal(StandardService
.java:438)
>
>
<2>at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2>at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.j
ava:930)
>
>
<2>at
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> <2>at
> org.apache.catalina.startup.Catalina.start(Catalina.java:633) <2>
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method) <2>at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeM
ethodAccessorImpl.java:62)
>
>
<2>at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Deleg
atingMethodAccessorImpl.java:43)
> <2>at
> java.base/java.lang.reflect.Method.invoke(Method.java:564) <2>
> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
> <2>at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:478)
> <2>Caused by: java.lang.IllegalArgumentException: the trustAnchors
> parameter must be non-empty <2>at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
actJsseEndpoint.java:99)
>
>
<2>at
org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJs
seEndpoint.java:71)
> <2>at
> org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:217)
> <2>at
> org.apache.tomcat.util.net.AbstractEndpoint.bindWithCleanup(AbstractEn
dpoint.java:1141)
>
>
<2>at
org.apache.tomcat.util.net.AbstractEndpoint.start(AbstractEndpoint.java:
1227)
> <2>at
> org.apache.coyote.AbstractProtocol.start(AbstractProtocol.java:592)
>
>
<2>at
org.apache.catalina.connector.Connector.startInternal(Connector.java:103
5)
> <2>... 12 more <2>Caused by:
> java.security.InvalidAlgorithmParameterException: the trustAnchors
> parameter must be non-empty <2>at
> java.base/java.security.cert.PKIXParameters.setTrustAnchors(PKIXParame
ters.java:200)
>
>
<2>at
java.base/java.security.cert.PKIXParameters.(PKIXParameters.java:1
57)
> <2>at
> java.base/java.security.cert.PKIXBuilderParameters.(PKIXBuilderP
arameters.java:130)
>
>
<2>at
org.apache.tomcat.util.net.SSLUtilBase.getParameters(SSLUtilBase.java:49
4)
> <2>at
> org.apache.tomcat.util.net.SSLUtilBase.getTrustManagers(SSLUtilBase.ja
va:425)
>
>
<2>at
org.apache.tomcat.util.net.SSLUtilBase.createSSLContext(SSLUtilBase.java
:247)
> <2>at
> org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(Abstr
actJsseEndpoint.java:97)
>
>
<2>... 18 more
>
> The error goes away when I remove truststoreFile and
> truststorePassword. Now comes the interesting part: The same
> configuration works under Windows (with other paths of course)
> using the Windows-Store as truststore for HTTPS connections to
> other servers. The same configuration worked with Tomcat 8.5.4 and
> the error just popped up from version 8.5.5. The error also seems
> not to be based on the java version, I tried it with Java 8 and
> Java 14. Under Windows we use Java 9...

Are you really using Tomcat 8.5.4 and 8.5.5? If so, you are like 4
years out of date and there are published security vulnerabilities
affecting your Tomcat version. Can you try with 8.5.latest which is
currently 8.5.57?

> Is this a Linux specific bug?

That would be unusual, but certainly possible. Are you *sure* this
works with no other changes other than:

1. Switching to 

Re: SV: [OT Upgrade: tomcat8w.exe //ES//example - dump Java Options and other information to tomcat9

2020-09-04 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hans,

On 9/4/20 07:08, Hans Schou wrote:
>
>> On Tue, Aug 4, 2020 at 2:18 PM Christopher Schultz wrote:
>>
>> So how do you switch Java versions?
>
> In case anyone care to know...
>
> I have a directory called C:\Java Here we have 
> jdk1.8.0_25  jdk1.8 [jdk1.8.0_25] And
> JAVA_HOME=C:\Java\jdk1.8
>
> And upgrade is then performed with: Unzip jdk1.8.0_211.zip Rmdir
> jdk1.8 Mklink /D jdk1.8 jdk1.8.0_211 And then all tomcat instances
> has to be restartet.
>
> A Tomcat minor upgrade is done in a similar way. We have a symlink
> like C:\Apache\tomcat-9.0 which point to
> C:\Apache\apache-tomcat-9.0.36 and we unzip a new version and
> change the symlink.

This obviously works, but requires that you have set things up this
way in advance. The discussion here was about upgrading your
Tomcat-based service if you had only used the standard installer in
the past without any "tricks" like you show, here.

For those interested, I'm presenting "Split your Tomcat Installation
for Easier Upgrades" at this year's ApacheCon @Home conference.
Registration/attendance is 100% free free for all. You can find the
Tomcat track schedule here:
https://www.apachecon.com/acah2020/tracks/tomcat.html

And there are a whole bunch of other tracks for those interested in
other Apache-related topics.

I could mention this kind of technique as well as the new tomcatXw.exe
feature of being able to dump the configuration to a
service-re-creation script as a part of this work. (Since it doesn't
really take 30 minutes to explain the difference between CATALINA_HOME
and CATALINA_BASE). :)

I was already expecting to talk about Windows Service installation,
anyway.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9SZ2wACgkQHPApP6U8
pFjBRQ/8DUor+8sQ7DTLoCDNsD67/G0kzMpn1DWgAxy61PzYZh21v4ycIB5O8dP2
64Xm9dw6hnYo5AfLuiLahZHBIH8KVdRramKIeIejWFZuKwrUGu0r2TtIfCIE9ZKy
5ZUquMFsLdR91OcWlieIGjMLaUMIau6ONSuQDpILs/6BprGHxZiG/WoUtNNigd7o
Q7Oa/oZSk4U32MIqjWiYXKYWQgH72Wz4LVZufRJx6BJA7CXYwqUeAPz3oF8FI5oa
EupKkvunh16SP8DhdRXTuWTfTH68j++9cttavJ2fBned3LIAKUhZJro1FF35ZoPS
X+h2JNYDbI7Mg1cyttYZNjqsLeJUfU1p842xUCkyfebdNx9w9El1v1xuXr6JAMWz
HqyYoF8gmS7ONBWv+wg+H6dBwnlYU0Knd9n5UGxWUEWH3jOMPLsj0MT19itPubje
6D/1VelnRoXXNlUvTNcA5MfKE/PU0SyctgJcYy+idliL1dnpubgOrc3AnM6nI+7O
L116cZ61MM7AFeC/dIOLyIVC613kdmDCHcL1/Nu5MXt806SK1TDnsFK+hw0PgPvx
SEWgocRNazXQQaTMxoTlQTQPLkaxwPWfdM5B/AMUmdiR/2lKbS3vgTgJcKCuzQpA
zKG2kPznrwlEEXTZmu3cLtHrJycabZu7/qOh0QkgcDO5Yx4as8Q=
=0+7/
-END PGP SIGNATURE-

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



Re: Native question (using Tomcat 8.5 and 9.0 on the same machine)

2020-09-02 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Brian,

On 9/2/20 11:39, Paquin, Brian wrote:
> I have a macOS device with Tomcat 8.5 and Native 1.2.23. I have
> been asked to add Tomcat 9.0 which has Native 1.2.24. In my setup
> documents, I copy “.libs/libtcnative-1.0.dylib” to
> /Library/Java/Extensions/ after compiling Native.
>
> When running Tomcat 8.5 and 9.0 on the same device, are there any
> issues using the newer dylib from Native 1.2.24 with the older
> Tomcat instances?

Usually no, and I don't think there are any issues with the
combinations you list above. Sometimes the answer is "yes", so it's
generally best to use the version of tcnative that comes with your
version of CHADIS.

There is no particular reason to require the same version of the
library to be used by both Tomcat 8.5 and Tomcat 9.0 processes. You
will have to build them both, of course, which may be a minor pain for
you.

I'm not sure I'd copy those native libraries into /Library/Java/etc...
after you build them. Tomcat will already automatically add the
CATALINA_HOME/lib/ directory to the java.library.path system property,
so if you build your .dyibs and put them into CATALINA_HOME/lib/ for
each (separate) version then you should be good. And there will be no
need to "pollute" your global Java extentions directory with
tcnative/APR/OpenSSL, etc.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9QSF0ACgkQHPApP6U8
pFgk3A//T8ClPJdUx3aV8CBkXdcd+yDJPt9QzYkgNVU+0+8N0lXifCKDUskuvmmR
bhNyzZ6P0PN+5MO7Pwn++LZDEM+YDG9RnnG+kJwLSVE1GSv3MVxIVmwhYON1EEjV
sAfKiq7wUA0HQETq+iERATi12gPc2H3eqx6tP/OfMk5GW2UNUyK45cPZIDREKVf6
9QeWHxOVR3DlRvyMJRRKDlB9kZ8fopyVD+L9LH8nXQCHjXZA6Myp2080p7MnqVfl
chgmMkSQ5Wqp7erFjHCqH0orwSHxEAB/+sxIP+zwsXeij0DnNd0ox5CQHQ4xIf7B
8h5fzzQ5xsYcKKEbB/toatcqaA+ed1/OrKyQ5NQH52dy7hOoduysJlLMSQTyakJG
FDNsrrNr8Kcmj8xNHMDWHXDKv4ATI/08JgEcTkXY5lM1Aif5QNj0wR003DhcVMPO
cPtEvQJI/1iERK4k9D/cukGCSpjcpxxjDC2MBqTsyMLX9cG9CH/X69y/80zbuqNx
W5CinzgVyYjZQC8NOYliRjnwpxm5LBaJeZOZuRxKAgN6JaWVCm95kEyAYXhNhy28
qnpT4y1pmFgNIoWmMc+4OKqslC/zVK/OxL3AAn8tt0GEXaP1Ph9QfHl7E6oHzI+t
xx+phQoaqubD8FrqLeX68FkEL5NKyBmSVyUTPVdIPjZcNk6AdUw=
=4qf0
-END PGP SIGNATURE-

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



Re: Class loader does not find class in WEB-INF/classes

2020-09-01 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Carles,

On 9/1/20 14:08, Carles Franquesa wrote:
> This message is a reply to those that asked me for uploading a
> simple version of my webapp reproducing the problem of not finding
> classes when a JSP is inside a subfolder, thus not hanging directly
> from web root directly.
>
> I have slimmed down the code as much as possible. You'll see is
> almost nothing.
>
> algorismes.zip
> 
>
>
>
> So, the project's became very simple, but the problem is there:
>
> Built with NetBeans 8.0.2 on Windows 10 Tested on local host (so
> tomcat running on windows), it works My VPS holds a public web
> domain called algosismes.cat. Tested on my VPS, it depends.
>
> Once deploy's done with tomcat 8.5.57 manager app, clicking on its
> list of sites, it works, since the browser is connecting to the
> ip:port/algorismes.
>
> Setting directly "algorismes.cat" in the browser url, the error is
> found. Just click to go to the level2.jsp.
>
> Lervel2.jsp is a blank page that just declares ann object of class
> Student to show the problem.
>
> Anybody can explain to me what am i doing wrong?

The ZIP file does not contain a build web application. Can you publish
your WAR file instead of mixed source/resources?

It's pretty important how you build the WAR, which is why I'm asking
for it.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9OkbIACgkQHPApP6U8
pFg7dg/6AmyQSP5Xuz8p8gwgyvZ5Sysn7oa+7TNqRQ0Q5PGdEC+7AbIb9B8k99cB
ESzJIH5k7AeacTFmhwlUxEs76slnpn/MshYLhfpWXjcYEDcnKA+Q5vBIKQiEzbGP
PsGS8lHJzSHgBM0XDjxIrnMKjSgWGIVeibiSecHv10DayUC/jY6HohSqexdZtGk4
dTH8LrUdAvbIhNp0CaT1CNlE0MaMu80tJJs1ENETlHYesywx1OVMIPE+GcPC/EC3
jEyBHEXTgvUWBXWh2xom8Jb70gvaSXr6Q3f2C9OgOWZcVB8e/3y6pLwc82AawHoq
tkr69sjOqUgp/EqUsFatD+8xUtly6ip14pzW5+8dCWBvNQYQiAgzRcP85SNBsTN6
+bThfsD29aMNZ0nRYYELihq0RprG+gNgU6wLqeM5g7VpOi2D9EqCJMLOR47XzHAQ
aiaTHhao2r2Z+tzl0BlYfsVws08SL+lLkUxlHF0g3obigRg8DXE7ouOam4w4SB54
bbjHldgvAvRGahsbHNmUBh4tsh53mFud+OuFMgDw8g5urV+FqAqlviktDsGolVwv
C8yUkMUOklx/R5uPKCIoxTnkl0nV5fUd90YdpkKPg7bnd3XHBrauRlEyrZUk34Oo
Kt0LmpyiolI+eYL4ZdwMqDQLNjx8jTQTiGqn+stgOf3PvdzMjFU=
=ZVdV
-END PGP SIGNATURE-

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



Re: Release date of latest Tomcat version - 9.0.38

2020-09-01 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Arshiya,

On 9/1/20 08:13, Arshiya Shariff wrote:
> Hi all,
>
> The following reported issue - "HTTP/2 Stream.receivedData method
> throwing continuous NullPointerException in the logs" has been
> fixed in the latest tomcat.
> https://bz.apache.org/bugzilla/show_bug.cgi?id=64671
>
> Can you please share us the release date of tomcat version 9.0.38
> . We are waiting for the release dates so we can plan accordingly.
There are no promises about release schedule.

Mark, however, has fairly consistently been rolling releases around
the beginning of each month. If you read the developers list, you'll
see there was a conversation started last week about the next batch of
releases.

Once a release candidate has been announced (look for [VOTE] threads),
you can help by testing the release:

  1. Run the test suite (ant test)
  2. Run the release-candidate on your own application

Your vote is not binding, but if you find a problem, we will likely
stop the release to fix it.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9ORigACgkQHPApP6U8
pFh1Og//dU8ExH5HO1xKGsJvf7t+hwnmi2rulOFZW7UkkY27D0GY+NqA3uzrUh1o
9rySFQ+SxTFNDt++GvYkVu4IQUObK5GYC7dvOlxeay0EaZYEz5yKMYtjWvCzgWXZ
/3rCLkG445CCfzcOuudeItdUy/MvIoig9NvulrFxCfeqtU6+KO+coXA9l86FoO38
kwYLzEKgO2zXApfm/FceAbeY1Jqu4CTr+0yH1NhcpjzV1B2g4fm6V6t00J4umPSA
SCLPYD+BK5/oBz3AkJKEicV9nlBpOfYRulPgsQdU4fBAmj62ERpPjs/N5d8wL1sH
JF9qd6RFHfDNlQ7/SjzrSiVhwnauZgqxjq33BYIxXCU5nEw8yEa6gOZTyo37N5vd
plwIv1xKnIoBZpzG0OxG5e5xSdyMxfkszTjxSC26tE07AVhiJnLOOtGC1o8Hv1Im
qlrRJTX+RCIzjFsAmA7sUMVrnF4qcIC6vdXP92xlrPDGD5X62BXRPZb6kmIX/DOl
in0/Exhl7CLywqzuoJWr3be+S/ASdV6gNGU8lT8wR/XrkF0FLvNysfps5QL5ToUL
ArUiFg9/51UM3/nmn0DHpfjrgZiuZxJtotIu64ROSCIbnBRdb5hNowfHCRI3Vy09
7F7TQzf+D9cHODR2T+DG22MqX4OBPw4BT9qqxAkAKgez2n+E9nU=
=tiRA
-END PGP SIGNATURE-

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



Re: [OT] Red Hat / CentOS specific question about certificates

2020-08-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 8/31/20 16:28, Christopher Schultz wrote:
> Daniel,
>
> On 8/31/20 11:36, Daniel Savard wrote:
>> Le lun. 31 août 2020 à 11:13, Christopher Schultz <
>> ch...@christopherschultz.net> a écrit :
>
>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>>
>>>
>>> Daniel,
>>>
>>> On 8/28/20 20:46, Daniel Savard wrote:
>>>> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
>>>> darryl.ba...@northwestern.edu> a écrit :
>>>>
>>>>> I am having an issue that I don’t understand.  On
>>>>> RHEL6/CentOS and earlier my predecessors would put
>>>>> self-signed certificates they wanted to trust in
>>>>> /etc/pki/ca-trust/extracted/java/cacerts and it was good
>>>>> for the life of the machine. On RHEL7 and I assume CentOS7
>>>>> that file is part of a package that is getting updated as
>>>>> part of the regular patches. That wipes out our
>>>>> self-signed certificates. The way I understand the
>>>>> directions from Red Hat we should put the certificate in
>>>>> pem format in the directory
>>>>> /etc/pki/ca-trust/source/anchors and run update-ca-trust
>>>>> extract and that will update the all the appropriate files.
>>>>> Including the cacerts file. That does not seem to happen.
>>>>> What is the proper way of handling self-signed certificates
>>>>> you want tomcat to trust?
>>>>>
>>>>> Off topic but you are folks who might know: On a related
>>>>> note I have the same issue with Java applications not
>>>>> running in Tomcat that use the same file
>>>>> /etc/pki….java/cacerts. Am I understanding the PKI update
>>>>> process correctly? Am I putting the self-signed certificate
>>>>> pem format file in the correct place?
>>>>>
>>>>> Darryl Baker, GSEC  (he/him/his) Sr. System Administrator
>>>>> (...)
>>>>>
>>>>>
>>>> You can put your certificates and truststore wherever you
>>>> want as long as you tell Tomcat where they are in the
>>>> conf/server.xml configuration file when you configure the
>>>> connector using them.
>>>>
>>>> Self-signed certificates should never be used on a
>>>> production server, they are not secure.
>>> What makes you say that?
>>>
>>> - -chris (...)
>
>
>
>> https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-
a
>
>>
re-turning-strength-into-a-vulnerability
>
> This
>
> article is talking about securing miscreants' communications. It
> really has nothing to do with self-signed certificates. It has to
> do with users blindly "trusting" anything which claims to be
> trustworthy just because it's encrypted.

I've re-read this article and also read their linked article on
Heartbleed, and I have come to the conclusion that the writers do not
have any clue what they are talking about.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NYTEACgkQHPApP6U8
pFgDwQ/+J1fhYRIMEjcDOhYmdtX6d3cid7pQ9pjBq3LePbeT+KrFWn7GbJcSU3Bg
SpBzZJUg2KB1EzMaZFmXd/OBpdrq+1a08fdjvwnDB1nSmznuIpgRbagm6MWigFlm
ghW5+96nQ/6L3a8LTZrjCkO7jxwuIMISYSOLvm9d9m7IHpgKWRl5UjBC/EuWpof6
blApEICEh4sWE9ZEBSYsphba3wP9nAFEKIb0/7ORRvQqkYZtSe/cQsTNXVOTQ9GF
nBcT40jMnG3pvEKzz7Gjk+OXhe3tAATBMdCvwzGtmct4QKI7T1B1FWHKZod1zgne
FqkX2ryRoq8F8MgDMkamzAQsW+n9WYVfQYDCaLMmoE2x3D3lulOUngL6g4qaA95u
TGdeggVgIaOmeJclImbuvE/X2fA89D90sc0XuGbUcXa4uvm8l13RDZVRyuntoXMQ
puMXypG0wRqlqfvA3ab4K+gI0AHjZ5tCJeqKMpUV+yOKDlB5ii0YBp6nB21x7C+4
afi4LXgIJsmXMpUp0ggjBmshrJ0KM5rnIdlpCdRKpuKic3Wy+C7sV0FxwOtx5bhj
JI/Er4uVeBpXh0gWYpTko+3SqpEPOkdFlCNbPBUZ0UtdeK8BWbQPTpi4evumMj8Z
WgLZ+FRS7mD3NAIRERrDKpAsKQK1vmU9t6OfZXV+zE+sZ3n6ap0=
=4OMv
-END PGP SIGNATURE-

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



Re: shared.loader classpaths

2020-08-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Carles,

On 8/31/20 12:45, Carles Franquesa wrote:
> Thank you Chris, for keeping on the problem. I don't know if you
> saw the last mail sent by me to the list.
>
> The thing was resolved by placing all the JSP referencing those
> classes at the web root folder. I did that, and it worked. That's
> why I hung my solution in the list.

Moving the JSPs will not have had any effect on being able to locate the
.class files. You must have changed something else.

> Nevertheless, Mark Thomas told me I was wrong. What I supposed that
>  was the problem, and the solution was wrong. He told me JSPs may
> go everywhere in the folder structure. And asked me for giving a
> simple example of my error.
Only if you want to actually solve your real problem.

> Anyway, by then my app worked already, so I put off to make the
> example until today. And certainly, I can't reproduce it. Mark is
> right, of course. I am new in all this. Now, my last chance to
> have the example is starting from a new copy of what is now going
> on, recover the old hierarchy of JSP ant try to reproduce the
> error. I am in> Thanks again for you help, Chris.

You are welcome, any time. It wasn't clear to me that your more recent
post was in reference to this one.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NXv0ACgkQHPApP6U8
pFjY+Q/9HUHitx0LWtW5w85qdGk9WksWXHXH5DWo4Mjx9uqsWoYeKqUDmaqDIMDh
2e1P4C2OBKli1toYU3mc9WWrtJmJV+b3ADiJGdaWjaPdHABFoTWQhFofH3WGi9+B
D3hxNBTlVY8dHnnDH0gvADFRsgJ7j1p4nTTM3krnDJW1KVH558CYE1G/9d3WcJV7
J66O3GAvyNG6LLQ7liUsr8dr+b7mVvpci/0b4I6LWmALQUqPGuCLKoZEkpZWOpA8
2b5Eq4cEGcYLCjv9LcZ3xocelTXHwxPNQDjZpFWXYqw7wYP9VnLLPwrkXlN4aRh5
O/1/aNALVLr6neDi4XCoCDFkMfPJpL2zwGHlrDfSqgtyQpQ0Gw1Xyh7dHoLM+RrK
n4WMbKXdCpB0QiFBw2inwk+pSWnN5aINUnK2V0w73pXTwVqKSOTzpFlwXlxP3DDp
OgcC+JYgkdcHYLUZFblrMesU/wEN8sQiV3dTTn8RsX3OGy3vfIPM2gc0/Z+JPSny
8b9+AkS/trv8FQRq8vXMQINesDoyFxjJZLCxb+/psCj6obePzl4QE/N3OHFZUxjM
6Y+TVXj3E9ogOnT3sOyapmaZfjySdhjXUw7AFKtDy4SABzNnL9rJEPUkt+9Zdjm6
fJE8FPnNquYxtr3IoznWCN47EJd1rImGW3WwOIRI9/QLe8r2uk8=
=8jqr
-END PGP SIGNATURE-

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



Re: [OT] Red Hat / CentOS specific question about certificates

2020-08-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Daniel,

On 8/31/20 11:36, Daniel Savard wrote:
> Le lun. 31 août 2020 à 11:13, Christopher Schultz <
> ch...@christopherschultz.net> a écrit :
>
>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA256
>>
>>
>> Daniel,
>>
>> On 8/28/20 20:46, Daniel Savard wrote:
>>> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
>>> darryl.ba...@northwestern.edu> a écrit :
>>>
>>>> I am having an issue that I don’t understand.  On
>>>> RHEL6/CentOS and earlier my predecessors would put
>>>> self-signed certificates they wanted to trust in
>>>> /etc/pki/ca-trust/extracted/java/cacerts and it was good for
>>>> the life of the machine. On RHEL7 and I assume CentOS7 that
>>>> file is part of a package that is getting updated as part of
>>>> the regular patches. That wipes out our self-signed
>>>> certificates. The way I understand the directions from Red
>>>> Hat we should put the certificate in pem format in the
>>>> directory /etc/pki/ca-trust/source/anchors and run
>>>> update-ca-trust extract and that will update the all the
>>>> appropriate files. Including the cacerts file. That does not
>>>> seem to happen. What is the proper way of handling
>>>> self-signed certificates you want tomcat to trust?
>>>>
>>>> Off topic but you are folks who might know: On a related note
>>>> I have the same issue with Java applications not running in
>>>> Tomcat that use the same file /etc/pki….java/cacerts. Am I
>>>> understanding the PKI update process correctly? Am I putting
>>>> the self-signed certificate pem format file in the correct
>>>> place?
>>>>
>>>> Darryl Baker, GSEC  (he/him/his) Sr. System Administrator
>>>> (...)
>>>>
>>>>
>>> You can put your certificates and truststore wherever you want
>>> as long as you tell Tomcat where they are in the
>>> conf/server.xml configuration file when you configure the
>>> connector using them.
>>>
>>> Self-signed certificates should never be used on a production
>>> server, they are not secure.
>> What makes you say that?
>>
>> - -chris (...)
>
>
>
> https://www.venafi.com/blog/self-signed-certificates-cyber-criminals-a
re-turning-strength-into-a-vulnerability

This
>
article is talking about securing miscreants' communications. It
really has nothing to do with self-signed certificates. It has to do
with users blindly "trusting" anything which claims to be trustworthy
just because it's encrypted.

Self-signed certificates by definition are not signed by a CA, so they
are not globally-trusted (or even semi-globally-trusted). "Trusting
All" certificates is a terrible mistake and the only way that
self-signed certificates can be a problem, whether used on an
"internal" network or exposed to the outside network.

> Never may be exaggerated in my post. But in general, you should
> avoid them.
Meh.

> But it all depends on your organization as well, mine is signing
> internal certificates and managing to include itself in the
> browsers of all the thousands employees.
This is a good technique IMO.

> In a small business, it may not be possible and the number of
> self-signed certificates may be low. In our organization, in the
> past we have seen people setting up their own self-signed
> certificates with too short keys to be secured by today's
> standards.
Well, that's obviously a mistake.

Especially if you aren't talking about browser-trust, I think
self-signed (or local-CA-signed) certificates are a good thing.
Services ought to be individually-trusting service certificates and
not even accepting all globally-recognized CAs because a compromised
CA or middle-box can intercept communications without a problem.

Self-signed certificates offer isolation from CAs and can therefore be
*more* secure for service-level certificates precisely because they
require special deployment.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NXWQACgkQHPApP6U8
pFicIxAAj04SbtcGa7UuCb65EvME1XAqRRwmsHVBGhLxBK/Nr3g+hDZ9xFd9Yo4i
5iuQ0yat4lD2y8BH1YF+EHrygfIp86EoDUKKukjuoAVQ4cgHFM6T2aoM8sWJR1CJ
xoxbA+dWnYL12BZR6jRj2k5vcOvs/UYkz4A6dp9X2N1LaQHMw5/orrqLPwN/BxiZ
qTzeEKqMAhLsfGVZVs9VGZPMLZYL6TvMkca22IltK1Z3dDkalijwyL83Q7vVGEvm
38qamO3FkgnfjZPgufkVoxfEKkG3lmMY7kpzxvGeoaPaH3he3tljXXVGbKxfSAuX
NFYj1CciL2fJCGm0roIB/9kPvG3Eoiq96ubUwbpl2fIciMA+XFJ6nUDj0ogdHzl1
yYbAowAXN4YR7azmmhwSUzgUsaw5itAQxiQpb0A7G3yxmTt52xv62aV5PhDw0lsN
HULi7GFm6JoeuzaGW6KBcOfBu+hZpek1Jqujn/Y435jIU5otE9R+yYDtdonLD0W3
ssWGdZRP6/Rgu41BEMPpdCgb+lDWBH/EkuTFHDerX2u9kpjALuJTTPRyt2REpOqY
Oflifwm2f9R77J3LNK8CNqC9d1BtUJqwSJ5/u+dRpkExYzTf37mHkt2kmdDlZJYi
mpjJUuoyEZnxhltyrp8Wn5bWNnA6P4kzVcPGqbG3MM/1KIHs++k=
=kmkH
-END PGP SIGNATURE-

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



Re: shared.loader classpaths

2020-08-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Carles,

On 8/29/20 15:13, Carles Franquesa wrote:
> Is anybody out there that could explain to me the way to know
> which classpath is being used by shared.loader. Or better, for any
> loader.

http://tomcat.apache.org/tomcat-9.0-doc/class-loader-howto.htmlv

> My problem is the tomcat does not find a class that certainly is
> in WEB-INF/classes.

What is the path of the file in WEB-INF/classes?

What is the name of the package+class of the class?

> I tried to set explicitly in all loaders by editing
> catalina.properties.

Do not do that. It's almost never necessary.

> My last test has been giving the folders to the common.loader,
> this way:
>
>
> *common.loader="${catalina.base}/lib","${catalina.base}/lib/*.jar","${
catalina.home}/lib","${catalina.home}/lib/*.jar","${catalina.base}/apren
online/WEB-INF/classes/lib","${catalina.base}/aprenonline/WEB-INF/classe
s/model","${catalina.base}/aprenonline/WEB-INF/classes/servlets","${cata
lina.base}/aprenonline/WEB-INF/lib/*.jar"*

This
>
will cause endless problems if you try to deploy more than one
application at a time. It will probably also cause weird problems even
with a single application deployed.

> But no way. Tomcat keeps on failing when JSP files try to make use
> of those classes.

Please post the <%@page> directive from a sample JSP file.

> In all Tomcat manuals say that webapp's classes should be placed
> in WEB-INF/classes when the WAR file is build.

This is the correct way to do things.

> And certainly, they are.

Either the class files are not in the right place, or you are not
referencing them correctly.

> But error continues. I also found some people that had this
> problem in the past, and by then, it was resolved updating to new
> versions. I tried with Tomcat 8 and 9.
I don't know of any version of Tomcat where the ClassLoaders didn't work
.

> Already spent four days in this, and I am totally stuck.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NF3MACgkQHPApP6U8
pFisnA/+Ly+r1R1HrHkKA1YHZVC72H8SS15AXJ+Twly/dH3QJ4HbMyX2tdBnSXOS
DKC0fsmKDUG7fLg1yKPAKYbnbQHoZEo6yfboMTuVrIG5sshVvdTqX/xfjN3V29D3
jYr1CIb/4esLCBg2Wq2DIck6mrJtg7ko95WYQnaMXODMJYf/KjZu8c/hoPSn70B7
+qYr+9GNO5qo6dTXcbaSFql4uex+c8NYyDMLZNDPml7Ub76aDAWJ2YOpxozzpftF
KYnGWdwhCXWtGOKrmhJ6WwEmK36unlJyq3BY12t+0hHP4aLg1ObcqiUtiiUrcO/D
saK5yF/JmSa5N6d+RpfNPvXe/zNUpnOm8/HlOZyWm23szWfNHLH27VMQfN8vPoSP
IjyXe/+eMSoRil5pnfeMKmTlU6ic9Om+abL0Wjva/v/MxS6HTbf1tJxAPxFkLpY5
dkI3R1YiqZwHpVPNlWiRpMgm39MSzphEy3vRpAxyEw/MWese4ZA/VS1CoZHK9fc8
jGigahmx5XS8X0c5y7AndwoD3iQ+mhQjOkNkexDqc9tTbzIcyg1hRJyHxsSV1iBk
Fdv8JrLORRyCymN6j2WIdDDbESeHTSDnHTKGc8C2/489eFVcsFip8EKW0oxbhqQp
nfHqrHvfPaGy9cNSRzWFis7OWvnBQpf78VIbYjxmi4o3Mu36ioQ=
=6UY2
-END PGP SIGNATURE-

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



Re: Implications of setting createDirs attribute on host declarations to false in Tomcat

2020-08-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Paul,

On 8/31/20 05:36, Paul wrote:
> Hello,
>
> When running Tomcat in a Docker container as non-root, I'm getting
> an error entry in the logs:
>
> Unable to create directory for deployment:
> [/usr/local/tomcat/conf/Catalina/localhost] I traced this down to
> the aforementioned directory not being there when Tomcat gets
> launched and the user running Tomcat does not having the
> permissions to create the directory.
>
> I also traced where this error message is coming from and its due
> to the createDirs attribute on the host declaration in server.xml
> not being set to false. The docs for the createDirs property states
> that if its set to true (the default) it'll attempt to create some
> directories, log an error when it fails, but the failure wont stop
> the startup of Tomcat.
>
> But what I cannot find anywhere is why those directories are
> created in the first place and what the ramifications are of them
> not being created when createDirs is set to false.

You are deploying a WAR file, right?

If you don't set createDirs="true" then Tomcat will not be able to
unpack WAR files for you.

> This question is for Tomcat docker images in general (in order to
> determine whether generic Tomcat Docker images should do something
> different to prevent these Errors in the logs), in my specific
> scenario however I'm running one webapp: an exploded WAR in the
> webapps/ROOT directory, which comes with its on context.xml in
> /webapps/ROOT/META-INF/context.xml

If webapps/ already exists, what directory is Tomcat trying to create?
conf/[engine]/[host]?

Can you arrange for conf/[engine]/[host] (usually
conf/Catalina/localhost) to exist so that the setting for createDirs
doesn't matter?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NFjoACgkQHPApP6U8
pFi/7xAAs6Rg39EWDFLkL2DutF4sGu6MeB9lwaRxq/OmsubS5X44+w+kFGha05fx
wHYFe6vhl6WL+UEIo/bja+JRgQCTCDTYf6fMmPYvJ6am/b2Ew0GmtjQlU6eimH2y
uGM/sfT0No+FYRpAxW9mbsh86H6rYMBNvj+dNWeusSkS/3uX2cELm/WwDKnOQb9I
bX5ZxgsA2DlXP37Zn+Q3G1bjP71Wbx1C/pbiXCYL3tGq3RLalBY3Y++GoTjAtEkX
4/jBNqLGBwgmFKQY0pfEc9iNCgwbgMh85zAvvUkzIxt+oKxYQLWPDwjs5Krfu2ZK
/pUIFey33rqAO9Vo2iuyX8W03kU0hhAK0PIXimPW8H3848o4Qe+5mJt46jrcpAb7
DFGZUiwS7plD9UrTZpY4UGfWtwAx1GwD9Db/l50Ru32mVtbYgvfzYKqKfZKe7hbI
gOUjIu+5jk0cgUE8d+bK2kiTnX5CQJNHT2N44y1/HLRBtuS7RX5e7yLuQfLZ6yeI
YpmQAr5oxccQ4XSbL9XQMtckG46JqSL1GwbejMT4n0pMzj7zI8J2Eeh3hCsov5bL
trDml0upYcWFoLNUJhFn+Lo1a0ujqOlH2iKS0xg+RU37t0mH0U8/ys77ZS12cnk8
bbwztsxUVPHKc2VjKOMhn47v+cmeGhAP6zeB2ZZ7O9fv3Si9xOQ=
=g5QV
-END PGP SIGNATURE-

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



Re: Probelm with shutdown script

2020-08-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/29/20 20:28, Mark Thomas wrote:
> On 28/08/2020 20:54, Christopher Schultz wrote:
>> Calder,
>>
>> On 8/27/20 18:23, calder wrote:
>>> On Thu, Aug 27, 2020, 16:16 Christopher Schultz <
>>> ch...@christopherschultz.net> wrote:
>>
>>> [ snip ]
>>
>>> If you want to *kill* the application and it won't shut down
>>> on its
>>>> own, SIGKILL is the answer. But that's not a great way to
>>>> shut down an application /in general/ because the application
>>>> might want/need to do something convenient on shutdown (flush
>>>> caches, save state, etc.).
>>
>>
>>
>>> SIGTERM is the polite way to ask an application to shut down. A
>>> JVM will respond to this signal. (SIGHUP will also initiate a
>>> shut down, but TERM is preferred).  Using TERM will cause the
>>> shutdown hooks to initiate.
>>
>>> As Chris states, SIGKILL is a last resort (hooks are not
>>> called).
>>
>> If you send a SIGTERM to a Tomcat process, your application's
>> ServletContextListeners and stuff like that will not run.
>
> Yes it will. Tomcat will shutdown cleanly (after cleanly shutting
> down any running web applications).

Oh really? How does that work? Oh, right. A shutdown-hook. :)

>> Sure, you can register shutdown-hook, but ... eew. That's like,
>> AWFUL, man.
>
> You mean like Tomcat already does? Applications don't/shouldn't do
> this because Tomcat has already done so.

Exactly. Shutdown hooks from web applications should never be done. I
don't think of Tomcat as an "application". It does make sense for
containers to register such things.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NFU0ACgkQHPApP6U8
pFjL3g/8DDOQDPdx+tuPw1ecd98u5YEuotkZXfFxl9u266up9fmBG8XubDRS85bX
60etRvJCmcH5lXCsBCmmnrDyK/KaxPDpM4OOMwnuEIfQOrQDN4uA3pz5FncAL1sO
VC3XJg9u341M2CHyw4yC0uqshSSWXXAhum3VoKBR82iHMQmlxu8bStwep1V39irS
rb4hqUIMi2puIXb8TJXln4oUSh+dL37Y5ksSc+0bk4+xiJF4KwevRbdp8AzoSFMO
H85W6Oafzj6R6mWbs2OL09PCxC05A5UqR5BlfspJWTHwT3hq8NeVIlDBWX3tzK8n
L5M8gKwjL0UdXmINwJbsjPdesDrQdVwjvqZrIvYFCKl0SIaG2q0vRr2Qi+RmaNIC
zG7+U1SR1WQ8nVTnynvo3xP36eXnmyLNFG/4sXvxG30VpiLatpoCMZnNfb7ChtMC
waX68CREil12sNgLXP+GGfbWFhxnnBrMoaGI/6/+9Ed8DBwGwGRiOcbN0mxgAOQy
09dpMXsx4bgUTfmYd/GI2bWQW5XoJfz9Z3xzq9UvMsd1RaHSHIFRwxRvQYkw0HZm
eKhUYq198FrxR9l+IJirKsZBwgIqYUFHc1p1pdCF14R7l2w94ofHPAEL/Q7Nj1ce
SdYsNq73dfaaW+fWwj8t3MLuDjqtQv+gwWQwV+0KzjjZ5wvCIHM=
=zfLt
-END PGP SIGNATURE-

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



Re: [OT] Red Hat / CentOS specific question about certificates

2020-08-31 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Daniel,

On 8/28/20 20:46, Daniel Savard wrote:
> Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
> darryl.ba...@northwestern.edu> a écrit :
>
>> I am having an issue that I don’t understand.  On RHEL6/CentOS
>> and earlier my predecessors would put self-signed certificates
>> they wanted to trust in /etc/pki/ca-trust/extracted/java/cacerts
>> and it was good for the life of the machine. On RHEL7 and I
>> assume CentOS7 that file is part of a package that is getting
>> updated as part of the regular patches. That wipes out our
>> self-signed certificates. The way I understand the directions
>> from Red Hat we should put the certificate in pem format in the
>> directory /etc/pki/ca-trust/source/anchors and run
>> update-ca-trust extract and that will update the all the
>> appropriate files. Including the cacerts file. That does not seem
>> to happen. What is the proper way of handling self-signed
>> certificates you want tomcat to trust?
>>
>> Off topic but you are folks who might know: On a related note I
>> have the same issue with Java applications not running in Tomcat
>> that use the same file /etc/pki….java/cacerts. Am I
>> understanding the PKI update process correctly? Am I putting the
>> self-signed certificate pem format file in the correct place?
>>
>> Darryl Baker, GSEC  (he/him/his) Sr. System Administrator (...)
>>
>>
> You can put your certificates and truststore wherever you want as
> long as you tell Tomcat where they are in the conf/server.xml
> configuration file when you configure the connector using them.
>
> Self-signed certificates should never be used on a production
> server, they are not secure.
What makes you say that?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9NE5wACgkQHPApP6U8
pFg57BAAl6VNkfGacih8/Uxn1tiyEbDkGAvcFpxbJkhcS1q4yTR171cGaKE50z1l
1GIWiiRdTdFCwI3SlCdQySKDZa4kCDPscv24zcPAIhVJ/1WKJ9PC/mLFZuRzR+3R
u2yYb5tUFcG7rESOf2WWgdB9uQrd/WMigr6qaLYIZFdOSKJ1xT1ujMMNUrFzleUw
FveFimPKg7MkMgCYKJWmH28dUKOICIGdL2hmq7gAsT161XCwFVcjHRT/lKRpnIlD
Mg1KTG6qTxMXSyBI4IopA8VRWAdjM6JaTyD65q4jjyeKTglklzmnU3WhFO4F1Jl2
vFlimBs0aNoRmNIuFfvQGyf5u7DKAdSYqrFk44atZQ2MNw5+Z6EDCtelLT/rneTf
xyYTkwqKgt7MRngTsJZ5w8T7exd7ZjhFSnwAs4ekohbh9sUTsd0DadTM6XbGsacL
p4c5aHrV9yYrye3RSfTEbwOr5FWR1G0VIMgONKdZA+BgNhm9CqdtoT04DA0iRY++
DskueqaKKEzEwV3P4/NYFKGj2nKtTMpYfrB6IUFghjMs/z29PYLgVVk/WVIEbLan
w3Er4oa/6r3C1ltq3EevvMbthww4nMf/cZqMRpG8ilIR4wn7t+IqfBGTJN9Ox4pj
Ik3pdWXw+5XoVaOqafUfhzc5Q1n6XSnTB5/yZifDhnsz/jzELIM=
=4pHT
-END PGP SIGNATURE-

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



Re: Probelm with shutdown script

2020-08-28 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Calder,

On 8/27/20 18:23, calder wrote:
> On Thu, Aug 27, 2020, 16:16 Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> [ snip ]
>
> If you want to *kill* the application and it won't shut down on
> its
>> own, SIGKILL is the answer. But that's not a great way to shut
>> down an application /in general/ because the application might
>> want/need to do something convenient on shutdown (flush caches,
>> save state, etc.).
>
>
>
> SIGTERM is the polite way to ask an application to shut down. A JVM
> will respond to this signal. (SIGHUP will also initiate a shut
> down, but TERM is preferred).  Using TERM will cause the shutdown
> hooks to initiate.
>
> As Chris states, SIGKILL is a last resort (hooks are not called).

If you send a SIGTERM to a Tomcat process, your application's
ServletContextListeners and stuff like that will not run. Sure, you
can register shutdown-hook, but ... eew. That's like, AWFUL, man.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9JYPgACgkQHPApP6U8
pFjIxhAAiqinCiRXer/BSW51oMvzCsGPqSXkNCLodYSBgC0FICBco5ZQBcCsYzIK
AOKM4v8vwnjR4uF9Sb1wETj9OqkgLUXseb2w6XKzOXA1xE6KK0m5UM2JMnY+XBeA
KQtUgzeRlKDtYZ801q2FLvOTSqFgF0NirUu9fQhR96fSWDFIH3uimqLb00WeUtfT
mlxHZufuJcwp+cZVW5CXH8qzUvDgAMCsnf7lV70Y3e1oEUuUE04PdtWfAyjoIsN6
3tguqfgAbSXfA6S4b+Q7hsnzu2ncYnJzvl6nj0Lp2+fMacl6wL5DwFIkHJBbru4Q
Fv0wMSFDwVx1nNIR+Mr6JOnxtnmERiDVDDdQE+FAGDuQFysrODJjmcmC1nb23/Db
kQGTBoIXk7W6Rn1n3hT13WAJmlQIrgDETxaswEI3nON7JC5nmPG7G28aI/66mMLb
ozyrmkrFHRd1oeXasgkTGZa3mvR8kwy85IqmGt3QNbWBa68VPZRQaUp96lkj1qiI
PVDo5CQAJxfTOnq5t7PZixq8uc1zIBu3besOP7vgVz2TgmXHF1Zrk/BaUoZYy+5H
VFTog7JjhIZnUBNp7uoq0SsCXfXvrC0dCGkVF5rLE3nxtjkas7LlhmZf4E4QD5zJ
jdI9Mt+keR0CHOyaeGK9P13N/S+EN2qTuwPdoCsDv66ulZtpwds=
=pzzj
-END PGP SIGNATURE-

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



Re: Tomcat 9.0.29 - HTTPS threads age, max connections reached, Tomcat not responding on 8443

2020-08-28 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 8/27/20 18:14, David wrote:
>> I used the http to 8080 in order to read the Tomcat webmanager
>> stats.   I originally had issues with the JVM being too small,
>> running out of memory, CPU spiking, threads maxing out, and
>> whole system instability.  Getting more machine memory and upping
>> the JVM allocation has remedied all of that except for apparently
>> the thread issue.
What is the memory size of the server and of the JVM?

>> I'm unsure that they were aging at that time as I couldn't get
>> into anything, but with no room for GC to take place it would
>> make sense that the threads would not be released.

That's not usually an issue, unless the application is being a
significant amount of memory during a request and then releasing it
after the request has completed.

>> My intention was to restart Tomcat nightly to lessen the chance
>> of an occurrence until I could find a way to restart Tomcat based
>> on the thread count and script a thread dump at the same time,
>> (likely through Solarwinds).  Now that you've explained that the
>> NIO threads are a part of the system threads, I may be able to
>> script something like that directly on the system, with a
>> chrontab to check count, if
> 295 contains NIO dump thread to / systemctl stop-start tomcat.

I wouldn't do that. Just because the threads exist does not mean they
are stuck. They may be doing useful work or otherwise running just
fine. I would look for other ways to detect problems.

>> That's very warming as it seems a viable way to get the data I
>> need without posing much impact to users.   Your explanation of
>> threads leads me to believe that the nightly restart may be
>> rather moot as it could likely be exhaustion on the downstream
>> causing the backup on the front end.  I didn't see these
>> connected in this way and assumed they were asynchronous and
>> independent processes.  There are timeouts configured for all the
>> DB2 backend connections, and I was in the mindset of the least
>> timeout would kill all connections upstream/downstream by
>> presenting the application a forcibly closed by remote host or a
>> timeout.

If you can suffer through a few more incidents, you can probably get a
LOT more information about the root problem and maybe even get it
solved, instead of just trying to stop the bleeding.

>> I greatly appreciate the assistance, In looking through various
>> articles none of this was really discussed because either
>> everyone knows it, or maybe it was discussed on a level where I
>> couldn't understand it, there certainly doesn't seem to be any
>> other instances of connections being open for 18-45minutes or if
>> there is it's not an issue for them.

If you have a load-balancer (which you do), then I'd expect HTTP
keep-alived to keep those connections open literally all day long,
only maybe expiring when you have configured them to expire "just in
case" or maybe after some amount of inactivity. For a lb-environment,
I'd want those keep-alive timeouts to be fairly high so you don't
waste any time re-constructing sockets between the lb and the app server
.

When an lb is NOT in the mix, you generally want /low/ keep-alive
timeouts because you can't rely on clients sticking around for very
long and you want to get them off your doorstep ASAP.

>> During a normal glance at the manager page, there are no
>> connections and maybe like 5 empty lines in a "Ready" stage,
>> even if I spam the server's logon landing page I can never see a
>> persistent connection, so it baffled me as to how connections
>> could hang and build up, so I'm thinking something was perhaps
>> messed up with the backend.

If by "backend" you mean like databasse, etc. then that is probably
the issue. The login page is (realtively) static, so it's very
difficult to put Tomcat under such load that it's hosing just giving
you that same page over and over again.

I don't know what your "spamming" strategy is, but you might want to
use a real load-generating tool like ApacheBench (ab) or, even better,
JMeter which can actually swarm among several machines to basically
DDoS your internal servers, which can be useful sometimes for
stress-testing. But your tests really do have to comprise a realistic
scenario, not just hammering on the login page all day.

>> The webapp names /URL's for the oldest connections didn't
>> coincide between the two outages, so I kind of brushed it off as
>> being application specific, however it may still be.
>
>> I need it to occur again and get some dumps!

Unfortunately, yes.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9JYLIACgkQHPApP6U8
pFgE6w//YnYR85ETrZJ6jvV0+jGM0qHeZeIz7tP49MZfp5fczPoYb93vrxeQ8W2T
TaoiJCYpyN37w9IAZo4cxuIGaaF/j10OY2sLAqB+Ogu6FRYXmWLvzqkO+fpX6Kw+
/KKjl3cru0XKQqYpYXpfAl99G0EAFOAeT8r43guBjeF5vyqfZyaQJC/YyfEfFL9R

Re: Tomcat 9.0.29 - HTTPS threads age, max connections reached, Tomcat not responding on 8443

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 8/27/20 17:14, David wrote:
> Thank you all for the replies!
>
> On Thu, Aug 27, 2020 at 3:53 PM Christopher Schultz
>  wrote:
>>
> David,
>
> On 8/27/20 13:57, David wrote:
>>>> On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
>>>>  wrote:
>>>>>
>>>> David,
>>>>
>>>> On 8/27/20 10:48, David wrote:
>>>>>>> In the last two weeks I've had two occurrences where a
>>>>>>> single CentOS 7 production server hosting a public
>>>>>>> webpage has become unresponsive. The first time, all
>>>>>>> 300 available "https-jsse-nio-8443" threads were
>>>>>>> consumed, with the max age being around 45minutes, and
>>>>>>> all in a "S" status. This time all 300 were consumed in
>>>>>>> "S" status with the oldest being around ~16minutes. A
>>>>>>> restart of Tomcat on both occasions freed these threads
>>>>>>> and the website became responsive again. The
>>>>>>> connections are post/get methods which shouldn't take
>>>>>>> very long at all.
>>>>>>>
>>>>>>> CPU/MEM/JVM all appear to be within normal operating
>>>>>>> limits. I've not had much luck searching for articles
>>>>>>> for this behavior nor finding remedies. The default
>>>>>>> timeout values are used in both Tomcat and in the
>>>>>>> applications that run within as far as I can tell.
>>>>>>> Hopefully someone will have some insight on why the
>>>>>>> behavior could be occurring, why isn't Tomcat killing
>>>>>>> the connections? Even in a RST/ACK status, shouldn't
>>>>>>> Tomcat terminate the connection without an ACK from the
>>>>>>> client after the default timeout?
>>>>
>>>> Can you please post:
>>>>
>>>> 1. Complete Tomcat version
>>>>> I can't find anything more granular than 9.0.29, is there
>>>>> a command to show a sub patch level?
>
> 9.0.29 is the patch-level, so that's fine. You are about 10
> versions out of date (~1 year). Any chance for an upgrade?
>
>> They had to re-dev many apps last year when we upgraded from I
>> want to say 1 or 3 or something equally as horrific.  Hopefully
>> they are forward compatible with the newer releases and if not
>> should surely be tackled now before later, I will certainly bring
>> this to the table!

I've rarely been bitten by an upgrade from foo.bar.x to foo.bar.y.
There is a recent caveat if you are using the AJP connector, but you
are not so it's not an issue for you.

>>>> 2. Connector configuration (possibly redacted)
>>>>> This is the 8443 section of the server.xml *8080 is
>>>>> available during the outage and I'm able to curl the
>>>>> management page to see the 300 used threads, their status,
>>>>> and age* 
>>>>>
>>>>> [snip]
>>>>>
>>>>> >>>> connectionTimeout="2" redirectPort="8443" /> [snip]
>>>>> >>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>> maxThreads="300" SSLEnabled="true" > 
>>>>> >>>> certificateKeystoreFile="/opt/apache-tomcat-9.0.29/redacted.jks"
>>>>>
>>>>>
certificateKeystorePassword="redacted" type="RSA" />
>>>>>   [snip] >>>> port="8443"
>>>>> protocol="org.apache.coyote.http11.Http11NioProtocol"
>>>>> maxThreads="300" SSLEnabled="true" > >>>> protocols="TLSv1.2"> >>>> certificateKeystoreFile="/opt/apache-tomcat-9.0.29/redacted.jks"
>>>>>
>>>>>
certificateKeystorePassword="redacted" type="RSA" />
>>>>>  
>
> What, two connectors on one port? Do you get errors when starting?
>> No errors, one is "with HTTP2" should I delete the other former?

Well, one of them will succeed in starting the and other one should
fail. Did you copy/paste your config without modification? Weird you
don't have any errors. Usually you'll get an IOException or whatever
binding to the port twice.

> I don't see anything obviously problematic in the above
> configuration (o

Re: Probelm with shutdown script

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Roger,

On 8/27/20 14:43, Roger Marquis wrote:
> Mark Thomas wrote:
>> Those are all application issues. The application should shut
>> itself down cleanly. Tomcat is complaining because it hasn't.
>
> I don't know Mark, most Java/Tomcat engineers expect an application
> to shutdown when it's os/container/shell/parent shuts-down.  Can
> you help us understand why Tomcat is different in this respect than
> say Apache httpd?

Along with Mark's reply, there is also the fact that httpd doesn't
really run "applications" per se. If you are using something like
mod_php or CGI, then that's all ephemeral: once the request is done,
the child process dies. Or, more specifically, the child process exits
and that's what causes the response to be sent to the client.

There is little to no notion of cross-request state in httpd.
Requesting httpd to stop sends a signal to the primary httpd process
which tells all its children to stop. If there is a problem with a
child (e.g. it's processing a request, or stuck in some way), the
primary process has to decide what to do about it. It may be able to
SIGKILL it. Maybe not, depending upon process privileges (though the
primary process usually runs as root, so it should be able to do that).

For threaded MPMs, the primary or child process can choose what to do
about killing the threads that appear stuck. The pthreads library has
a pthread_cancel function which requests that the thread be stopped,
but it does not guarantee anything. This is similar to Java, except
that Java has gone so far as to say "the Thread.stop method should not
be used" (because it is not reliable, it causes weirdness in the JVM,
etc.).

If you want to *kill* the application and it won't shut down on its
own, SIGKILL is the answer. But that's not a great way to shut down an
application /in general/ because the application might want/need to do
something convenient on shutdown (flush caches, save state, etc.).

The previous two paragraphs are mostly valid for both httpd AND
Tomcat. The reason httpd is often "cleaner" than Tomcat sometimes is,
is because of the applications running within Tomcat. httpd is really
a web server, and Tomcat is an application container.

Could Tomcat be more aggressive about killing applications when they
aren't behaving appropriately? Maybe. But then you'd never fix your
application, now would you?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9IInAACgkQHPApP6U8
pFi6zw//WBFH087QqzmZbgdQjPxDhZ5f5L9lQmp4VFaw+dOEkP4xNMkGCxWeTq1Z
1nmogFYsZ8vns8z1f8RJ22aDWhdFqCDDHlJkqobR/4d4wiKd0hmjm75s8NH2YeCk
2UwwlStV99n5BNu3/TBTQFyjUv2rhz8cO8tDkztFGS7avXogSm08zeeHgVIC8cWV
tiGBe7QVH/PMeanGl+/1IdWQ5PmpmNpGBv5YGJMYfU9Hmul/GeNW55pLJPSxS7ll
/8thgxDVK4VudnA6MGELVSht56qlEQtlekMJjSUUvagmT94yTDXd7teOagZL9U79
26EL5tOiSkE4GGPoR/jQa0kj0bNMHMUJsBJRoHDCXxQdJhPLTGZNKZM1yMgAlMnc
6D2/acg9TbO6ia0Q1qpQmh2vWUlMPdp4U8X1uP6RdKKQyyjM5Pzinw/ysktgEBpI
lYSI+uz3uG0iJGzqECPaoTpTTtSqdtG68QVqU2Kgv4lHmENNHFWMDKbB3glwqfBN
KLw6fCrKGG6XGdQEcgtR8GjyNNpErLcf7PzIqXtwo9bNoQWNhYF/VjjndRJTTL98
IwoEL9qHXs0hhtKHA4x7kir0OARjwXDNwuJGu9LrKX1qOtzNxUAmjckHtLDjb5m8
nWmsz2zzy1rak1t1EPVsFjfOu5kZL+++IQcXja29uZshuiPcWbI=
=vc24
-END PGP SIGNATURE-

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



Re: Tomcat 9.0.29 - HTTPS threads age, max connections reached, Tomcat not responding on 8443

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Felix,

On 8/27/20 16:09, Felix Schumacher wrote:
>
> Am 27.08.20 um 19:35 schrieb Christopher Schultz:
>> David,
>>
>> On 8/27/20 10:48, David wrote:
>>> In the last two weeks I've had two occurrences where a single
>>> CentOS 7 production server hosting a public webpage has become
>>> unresponsive. The first time, all 300 available
>>> "https-jsse-nio-8443" threads were consumed, with the max age
>>> being around 45minutes, and all in a "S" status. This time all
>>> 300 were consumed in "S" status with the oldest being around
>>> ~16minutes. A restart of Tomcat on both occasions freed these
>>> threads and the website became responsive again. The
>>> connections are post/get methods which shouldn't take very long
>>> at all.
>>
>>> CPU/MEM/JVM all appear to be within normal operating limits.
>>> I've not had much luck searching for articles for this behavior
>>> nor finding remedies. The default timeout values are used in
>>> both Tomcat and in the applications that run within as far as I
>>> can tell. Hopefully someone will have some insight on why the
>>> behavior could be occurring, why isn't Tomcat killing the
>>> connections? Even in a RST/ACK status, shouldn't Tomcat
>>> terminate the connection without an ACK from the client after
>>> the default timeout?
>>
>> Can you please post:
>>
>> 1. Complete Tomcat version 2. Connector configuration (possibly
>> redacted)
>>
>>> Is there a graceful way to script the termination of threads
>>> in case Tomcat isn't able to for whatever reason?
>>
>> Not really.
>
> (First look at Marks response on determining the root cause)
>
> Well, there might be a way (if it is sane, I don't know). You can
> configure a valve to look for seemingly stuck threads and try to
> interrupt them:
>
> http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Stuck_Thread
_Detection_Valve
>
>  There are a few caveats there. First it is only working, when
> both conditions are true
>
> * the servlets are synchronous * the stuck thread can be "freed"
> with an Interrupt
>
> But really, if your threads are stuck for more than 15 minutes, you
> have ample of time to take a thread dump and hopefully find the
> root cause, so that you don't need this valve.

This is a good idea as a band-aid, but the reality is that if you need
the StuckThreadDetectionValve then your application is probably broken
and needs to be fixed.

Here are things that can be broken which might cause thread exhaustion:

1. Poor resource management. Things like db connections pools which
can leak and/or not be refilled by the application. Everything stops
when the db pool dries up.

2. Failure to set proper IO timeouts. Guess what the default read
timeout is on a socket? Forever! If you read from a socket you might
never hear back. Sounds like a problem. Set your read timeouts, kids.
You might need to do this on your HTTP connections (and pools, and
factories, and connection-wrappers like Apache http-client), your
database config (usually in the config URL), and any remote-API
libraries you are using (which use e.g. HTTP under the hood).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9IICoACgkQHPApP6U8
pFgkuQ/+NE7tC+wWXoP2Ntv0yljJHyasRY/3dVewoNUxfO4CwcEkhSpK5YEkiHd3
sE7jygxEn3SHtHJ0WQPBWMAzL9RoLnglbAsxVXuWCzbQzd3tGCKOxQevCN3y+2ft
jffqMEqOCgrN4kvKivj75V3alFQotT+jbZm1nJEwuQCLSJCqiHWcyCLlJF9Y6axn
Thvsv40bnTKCPgqezo/0AYiYjQ9xIatTC3QDw129E7bofNKPBLk7LWcbg9CQBu+T
iboA8IIxFgrOFYn66Mgx4kcJcQTRJ2XgdJ1v8p+mSITWH3UkLa5OhZeTqU6x2LDl
LPuY8eC6y9QUqpFeEtaL72ZpDdYAn7Vcu4B3+D4Oobh7o2EJNQijIQ6A2QKIFw6e
eBACKL0JJMwvfxVnp3nKIuoB3yOemMGZ8NpqUNcEn5mjmZubRWXXJXjtjjF5pGYW
RRbMXvs3tFhLGsqnjVHQ/AV5MyuYKfl4Tqhvrz0u2oh0A8uo5Kq3CuHBDcLhLjs1
RkDiZuSdVugRFeq6hcQAyqO6LQ/QRhqtQ1hscecr9Iv8grvs8gzi4PvlurgBFqEF
AuWe0V2WY0IJ9S7BqUUDr3Ij+0CQgxeQ70yyOztWjsT0B6ZPdOChm5Meu1+qi2ni
EuT6Q5Lo2KHTqhrvi/RbTUXs+D6LSNFN6QFOzWtKWAr+gyrQjKg=
=Ew/J
-END PGP SIGNATURE-

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



Re: Tomcat 9.0.29 - HTTPS threads age, max connections reached, Tomcat not responding on 8443

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 8/27/20 13:57, David wrote:
> On Thu, Aug 27, 2020 at 12:35 PM Christopher Schultz
>  wrote:
>>
> David,
>
> On 8/27/20 10:48, David wrote:
>>>> In the last two weeks I've had two occurrences where a
>>>> single CentOS 7 production server hosting a public webpage
>>>> has become unresponsive. The first time, all 300 available
>>>> "https-jsse-nio-8443" threads were consumed, with the max age
>>>> being around 45minutes, and all in a "S" status. This time
>>>> all 300 were consumed in "S" status with the oldest being
>>>> around ~16minutes. A restart of Tomcat on both occasions
>>>> freed these threads and the website became responsive again.
>>>> The connections are post/get methods which shouldn't take
>>>> very long at all.
>>>>
>>>> CPU/MEM/JVM all appear to be within normal operating limits.
>>>> I've not had much luck searching for articles for this
>>>> behavior nor finding remedies. The default timeout values are
>>>> used in both Tomcat and in the applications that run within
>>>> as far as I can tell. Hopefully someone will have some
>>>> insight on why the behavior could be occurring, why isn't
>>>> Tomcat killing the connections? Even in a RST/ACK status,
>>>> shouldn't Tomcat terminate the connection without an ACK from
>>>> the client after the default timeout?
>
> Can you please post:
>
> 1. Complete Tomcat version
>> I can't find anything more granular than 9.0.29, is there a
>> command to show a sub patch level?

9.0.29 is the patch-level, so that's fine. You are about 10 versions
out of date (~1 year). Any chance for an upgrade?

> 2. Connector configuration (possibly redacted)
>> This is the 8443 section of the server.xml *8080 is available
>> during the outage and I'm able to curl the management page to see
>> the 300 used threads, their status, and age* > name="Catalina">
>>
>> [snip]
>>
>> > connectionTimeout="2" redirectPort="8443" /> [snip]
>> > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> maxThreads="300" SSLEnabled="true" > 
>> > certificateKeystoreFile="/opt/apache-tomcat-9.0.29/redacted.jks"
>> certificateKeystorePassword="redacted" type="RSA" />
>>   [snip] > protocol="org.apache.coyote.http11.Http11NioProtocol"
>> maxThreads="300" SSLEnabled="true" > > protocols="TLSv1.2"> > certificateKeystoreFile="/opt/apache-tomcat-9.0.29/redacted.jks"
>> certificateKeystorePassword="redacted" type="RSA" />
>>  

What, two connectors on one port? Do you get errors when starting?

I don't see anything obviously problematic in the above configuration
(other than the double-definition of the 8443 connector).

300 tied-up connections (from your initial report) sounds like a
significant number: probably the thread count.

Mark (as is often the case) is right: take some thread dumps next time
everything locks up and see what all those threads are doing. Often,
it's something like everything is awaiting on a db connection and the
db pool has been exhausted or something. Relatively simple quick-fixes
are available for that, and better, longer-term fixes as well.

> Do you have a single F5 or a group of them?
>> A group of them, several HA pairs depending on internal or
>> external and application.  This server is behind one HA pair and
>> is a single server.

Okay. Just remember that each F5 can make some large number of
connections to Tomcat, so you need to make sure you can handle them.

This was a much bigger deal back in the BIO days when thread limit =
connection limit, and the thread limit was usually something like 250
- - 300. NIO is much better, and the default connection limit is 10k
which "ought to be enough for anyone"[1].

- -chris

[1] With apologies to Bill gates, who apparently never said anything
of the sort.
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9IHUYACgkQHPApP6U8
pFgcMhAAsN/Fc0nG4EJ/aaxZtj46g7FW2UDLa3HcGI+r8mvI5pYlCxWO0Cm4oDHn
PAEUsjNgDcyLbWPa+hIfTWZ2v594w8ACrprpdNWHoPhZ316LudpG3G8RWwrIVsOa
pn6MmX79rvds1Htl2cbsZkaaNCg/3+dx5VgyQtexHopSP9FpU1swDwex4fIf/pFz
jcl4SB6eMnKxHwf/avwEy6sfdN05ALCl6KfJBCA6vnRvMT8hYVGs5B/bDdPRU5zL
0cNIAlNaxrcw0G13cuOhg5KYG+eeKBKl2R/OiSmyn4+Xp7zzbl3G3i4GvfbYrwqe
BFTcTGT3cTE3vwMcHmsskh2soxYcH3etWtJ2/XsrKoKdRqXpWybVyNEvHcUwhxdP
h7SAN5V8D2+9a8Hhh8y/hUCHBOT70THUyBipYweV26wUj4ipOAiYiJ2UaCATwNzf
E7Giv6D4Y9WQCU119HaQ65TLmvGTtfzctM5pJzrnRbI7LOpuo9/bNYxkYNoU8U9r
sAgY4t3kvKNttetFnwdY5+JTM+yrFolYFkYMFv8vpaVyiumP4+dpbkniRAmLabWl
O0kIn/bRTkek4ic/qCuawBi1Rc1hV1/1uUE1+t8XHG7Sfdd0vwUabZ8ZRxNUBWcc
EliCfzyMosWcsgU2puNduPyXDeRxKb5gfe4VdfaH5xvfdqIpfgw=
=SesB
-END PGP SIGNATURE-

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



Re: Tomcat JDBC Pool Cleaner Deadlock Problem

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gokhan,

On 8/27/20 05:47, Gokhan Akgul wrote:
> Hi ,
>
> I have been facing the deadlock issue for the last 2 months  about
> JDBCPoolCleaner Thread .
>
> Following config set in context.xml
>
>  type="javax.sql.DataSource"
> factory="org.apache.tomcat.jdbc.pool.DataSourceFactory"
> driverClassName="com.mysql.jdbc.Driver"
> url="jdbc:mysql://adress:3306/db?useUnicode=truecharacterEncoding
=latin5characterResultSet=latin5zeroDateTimeBehavior=convertTo
NullautoReconnect=trueinteractiveClient=true"
>
>
username="user"
> password="pass" initialSize="10" maxActive="30" maxIdle="15"
> minIdle="10" maxWait="3" timeBetweenEvictionRunsMillis="5000"
> minEvictableIdleTimeMillis="6" removeAbandonedTimeout="600"
> removeAbandoned="true" logAbandoned="false" testWhileIdle="true"
> testOnBorrow="true" testOnReturn="false" validationQuery="/* ping
> */ SELECT 1" validationInterval="3" jmxEnabled="true"
> jdbcInterceptors="ConnectionState;StatementFinalizer;ResetAbandonedTim
er;SlowQueryReport"
>
>
/>
>
>
>
> Thread dump
>
> Tomcat JDBC Pool Cleaner[63445188:1598345711425] id=16
> state=BLOCKED - waiting to lock <0x57dcb0b7> (a
> com.mysql.jdbc.JDBC4PreparedStatement) owned by
> http-nio-8080-exec-8 id=25 at
> com.mysql.jdbc.PreparedStatement.realClose(PreparedStatement.java:3078
)
>
>
at
com.mysql.jdbc.ConnectionImpl.closeAllOpenStatements(ConnectionImpl.java
:1584)
> at
> com.mysql.jdbc.ConnectionImpl.realClose(ConnectionImpl.java:4364)
> at com.mysql.jdbc.ConnectionImpl.close(ConnectionImpl.java:1556) at
> org.apache.tomcat.jdbc.pool.PooledConnection.disconnect(PooledConnecti
on.java:388)
>
>
at
org.apache.tomcat.jdbc.pool.PooledConnection.release(PooledConnection.ja
va:618)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.release(ConnectionPool.java
:612)
>
>
at
org.apache.tomcat.jdbc.pool.ConnectionPool.abandon(ConnectionPool.java:5
69)
> at
> org.apache.tomcat.jdbc.pool.ConnectionPool.checkAbandoned(ConnectionPo
ol.java:999)
>
>
at
org.apache.tomcat.jdbc.pool.ConnectionPool$PoolCleaner.run(ConnectionPoo
l.java:1468)
> at java.util.TimerThread.mainLoop(Timer.java:555) at
> java.util.TimerThread.run(Timer.java:505)
>
> Locked synchronizers: count = 1 -
> java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@58039868
>
>
>
>
> http-nio-8080-exec-8 id=25 state=BLOCKED - waiting to lock
> <0x42de9995> (a com.mysql.jdbc.JDBC4Connection) owned by Tomcat
> JDBC Pool Cleaner[63445188:1598345711425] id=16 at
> com.mysql.jdbc.ConnectionImpl.useAnsiQuotedIdentifiers(ConnectionImpl.
java:5435)
>
>
at
com.mysql.jdbc.DatabaseMetaData.getIdentifierQuoteString(DatabaseMetaDat
a.java:3269)
> at
> com.mysql.jdbc.DatabaseMetaData.(DatabaseMetaData.java:675)
> at
> com.mysql.jdbc.JDBC4DatabaseMetaData.(JDBC4DatabaseMetaData.java
:39)
>
>
at sun.reflect.GeneratedConstructorAccessor24.newInstance(Unknown Source
)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo
nstructorAccessorImpl.java:45)
>
>
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
> at com.mysql.jdbc.Util.handleNewInstance(Util.java:411) at
> com.mysql.jdbc.DatabaseMetaData.getInstance(DatabaseMetaData.java:657)
>
>
at com.mysql.jdbc.ConnectionImpl.getMetaData(ConnectionImpl.java:3064)
> at
> com.mysql.jdbc.ConnectionImpl.getMetaData(ConnectionImpl.java:3056)
>
>
at
com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:231
5)
> at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orImpl.java:43)
>
>
at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.tomcat.jdbc.pool.interceptor.AbstractQueryReport$StatementP
roxy.invoke(AbstractQueryReport.java:210)
>
>
at com.sun.proxy.$Proxy44.executeQuery(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orImpl.java:43)
>
>
at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.tomcat.jdbc.pool.interceptor.AbstractQueryReport$StatementP
roxy.invoke(AbstractQueryReport.java:210)
>
>
at com.sun.proxy.$Proxy44.executeQuery(Unknown Source)
> at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
orImpl.java:43)
>
>
at java.lang.reflect.Method.invoke(Method.java:606)
> at
> org.apache.tomcat.jdbc.pool.StatementFacade$StatementProxy.invoke(Stat
ementFacade.java:114)
>
>
at com.sun.proxy.$Proxy44.executeQuery(Unknown Source)
> at
> org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:2
08)
>
>
at org.hibernate.loader.Loader.getResultSet(Loader.java:1953)
> at org.hibernate.loader.Loader.doQuery(Loader.java:802) at
> org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loa
der.java:274)
>
>
at org.hibernate.loader.Loader.doList(Loader.java:2542)
> at
> 

Re: Apache 8.5.57 shared class loader does not find its default classpath

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Carles,

On 8/27/20 12:19, Carles Franquesa wrote:
> Hi Everybody!, Just got in the list :)
>
> I am developing a webapp with Netbeans 8.0.2, and deploying it as a
> WAR file with Apache 8.5.57 Tomcat Manager onto my VPS where a
> mydomain.com is publically mapped on the DNS.
>
> It works fine in localhost, and even at the VPS when the IP and
> path is set in the url browser: http://ip:port/myapp. Then, it
> works.
>
> When trying to connect via my registered domain in the browser
> url, astonishingly, the index.jsp is correctly shown, but none of
> its links to other JSPs are going on. The first one is called
> cursos.jsp.

Do you mean that the links don't work (the browser won't follow them),
or you get an error when you click on those links because of the JSP
compilation errors?

> The included file before the  tag is the same in index.jsp as
> in cursos.jsp, located in webapps/myapp/cursos/cursos.jsp which
> produces the error.

Your attachment was stripped from your message, but I don't think it
is really necessary to understand what's going on.

> The begining of both files is:
>
> --
- -
>
>
<%@page session="true" %>
> <%@page import="lib.Text"%>
> --
- 
>
>
I also have been looking at stackoverflow, and found some amazing
> solutions, like ending the import with a semicolon. But it neither
> worked at all.
>
> My purpose is to make it work on mydomain.eu that I have already
> registered and mapped in the DNS.
>
> The error message given by any browser is printed next.
> --
- 
>
>
Tipo Informe de Excepción
>
> mensaje Unable to compile class for JSP
>
> Descripción El servidor encontró un error interno que hizo que no
> pudiera rellenar este requerimiento.
>
> excepción
>
> org.apache.jasper.JasperException: Unable to compile class for
> JSP:
>
> An error occurred at line: [14] in the generated java file:
> [/opt/tomcat/work/Catalina/
> mydoamin.com/cursos/org/apache/jsp/cursos_jsp.java] Only a type can
> be imported. lib.Text resolves to a package
>
> ... and here, error is repeated for several classes
> --
- 
>
>  So, it seems that the class loader does not find the classes
> located at its default repository.
>
> I have been looking for the way tomcat uses classpaths. In
> particular, the role of its class loaders. And specifically, the
> "shared.loader" class loader.
>
> I even tried to set the value "webapps/myapp/WEB-INF/classes" in
> the catalina.properties file (even though it is not supposed to be
> needed).
>
> I have been looking for this in
> http://tomcat.apache.org/tomcat-8.5-doc/class-loader-howto.html.
> There, learned about the four loaders of tomcat. And as long as I
> understood, the classes repository should be located at
> ${CATALINA_HOME}/webapps/myapp/WEB-INF/classes. The place where
> Tomcat Manager leaves it when the WAR is uploaded.
>
> Ultimately, the
> ${CATALINA_HOME}/webapps/myapp/WEB-INF/classes/lib/Text.class
> certainly exists!, so I am stuck in telling the loader where the
> classes are.

You shouldn't have to mess around with class loaders or anything,
though that was good information for you to read. And you have
understood it correctly!

Can you take the WAR file you have deployed on the server and run this
on it?

$ unzip -v my.war

Can you post the contents? It should contain, among other things:
WEB-INF/classes/lib/Text.class

I'm wondering if the WAR file isn't including something that is
present on your local system when you test (and where it works properly)
.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9H8DcACgkQHPApP6U8
pFg2FA/9Hxn/yJOxRWch+8tAYZsLvcuCF+aynod0BdDso1wyhVWmv44JDNgwcDbA
Q6VQH0KclheiGlZmfH59y1RTxeNUUYOw22wbr7qyoKq/ShsDxvmEEiRdq1hDrqVS
v6gnb7XMrtYIhPhRJDnOhm+vD4KmK28szSvTFRXvTUaENjFBGVFHc8AkDldRy7Df
g9F/VUadiKuO2D/z7RxbiHzDYt3yCgGCAq9+6pch5LoUQ3W0Bmg6+NYXxdXylRQh
EDVd6vhxrc/kFqbTFcP7Wmc/HJ9Y3mYQ2AYANQRO/9tmSYjaXqNXrITczLsltbU5
Z6M/1pw3flTycGjEA6ycLBP3CNTKykB1Ygda3plf7Zsf+m3w/4Mt6RYbsGPzOis0
/E4o5QPpdnIfWcXjU6Ivgdtk6q1z5QFBNehsJscXtNK93Y5tEas5Z3ldLBRh1+ZK
Oe9mcyNY70rrtAvT+2/QVJoYV6Z0nZmEKti+wnDY2NCX7UoS72FqN1ENHhOM/uPj
2Gc9gY0t3tAxjWvKjhQi5b9LaqW6tSm3o3xhD109u2Fck9Gr5NOz6Lf9LHWkYxHn
fLPmzgic5vp6VyceWq/F+zwQElnHwELBz1LR1lrX3kCKmxsHqsqjvLp2HK7Wt4us
f67rukAYn1Gl4l3lCTorSpRXTKBXE8Wc9c4z02BftLAhWMpDQqA=
=nSg9
-END PGP SIGNATURE-

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

Re: Tomcat 9.0.29 - HTTPS threads age, max connections reached, Tomcat not responding on 8443

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

David,

On 8/27/20 10:48, David wrote:
> In the last two weeks I've had two occurrences where a single
> CentOS 7 production server hosting a public webpage has become
> unresponsive. The first time, all 300 available
> "https-jsse-nio-8443" threads were consumed, with the max age being
> around 45minutes, and all in a "S" status. This time all 300 were
> consumed in "S" status with the oldest being around ~16minutes. A
> restart of Tomcat on both occasions freed these threads and the
> website became responsive again. The connections are post/get
> methods which shouldn't take very long at all.
>
> CPU/MEM/JVM all appear to be within normal operating limits. I've
> not had much luck searching for articles for this behavior nor
> finding remedies. The default timeout values are used in both
> Tomcat and in the applications that run within as far as I can
> tell. Hopefully someone will have some insight on why the behavior
> could be occurring, why isn't Tomcat killing the connections? Even
> in a RST/ACK status, shouldn't Tomcat terminate the connection
> without an ACK from the client after the default timeout?

Can you please post:

1. Complete Tomcat version
2. Connector configuration (possibly redacted)

> Is there a graceful way to script the termination of threads in
> case Tomcat isn't able to for whatever reason?

Not really.

> My research for killing threads results in system threads or
> application threads, not Tomcat Connector connection threads, so
> I'm not sure if this is even viable. I'm also looking into ways to
> terminate these aged sessions via the F5. At this time I'm open to
>  any suggestions that would be able to automate a resolution to
> keep the system from experiencing downtime, or for any insight on
> where to look for a root cause. Thanks in advance for any guidance
> you can lend.
It might actually be the F5 itself, especially if it opens up a large
number of connections to Tomcat and then tries to open additional ones
for some reason. If it opens 300 connections (which are then e.g.
leaked by the F5 internally) but the 301st is refused, then your
server is essentially inert from that point forward.

NIO connectors default to max 10k connections so that's not likely the
actual problem, here, but it could be for some configurations.

Do you have a single F5 or a group of them?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9H7tIACgkQHPApP6U8
pFjR1hAAldbVnHDrV0W4aPLvcDwO/zi7qvrCscNjnJWhmR1m9TrevlrSb0EZvCJo
gTl7DXYEiZ9sBEdgs6AavHlk8jQ+ZbXbp8lsMElW5X9QoxxUD3YyJEpDSeHOG7/S
2CyCYGzAQER0RlzBn9w97bCKWvUWoWDeLApd/pwdATjAo53hDtdNGdz6WdNLEzKm
g/BCZP0ynHZu7pMzSeZsOUBUXEKhDwHU+71fJo+WIJ4Gtiyb4xf2qkewvjQtuOGl
o/yESHNCJy09JAs3xK9W6eEVp981/Fuo4qDH32MJaXXbZRaNk32AwqngXKUhTW2l
BBl0jHoFIj+YJYc6AgVlv0la5qDIqP2VTv4ujOLBeF/95oP4sVRobIN4TiFyH6vv
ImvvRq55ML5NvKJv8g9Tj0aY5PusfwxcwyMCVovIof49vQXJUy7SbtgRB3eqgT8W
WwdBiGNsyWZpVjpr/CGBkBZmuR4wckeq0J5O/XGRFS9pK1jXH4gPnxe58vJmjA+P
RiSdp3SsU0P94SuF843CW+vmWyUu6SApCybUTwo5yiFXP2e/1+M9/fUGsykXpszU
zUvMcj9LWJ1QR3TbvEnwilsge4HKbUM3ZsFaujDjAVy6TAOgGS/dtVZ2UyMcrlOd
JMe3GeaOdM+ej27l5D8Eq6jaQcCfy+Mg9HxsYsbyrgrw3AhBhmo=
=eVIu
-END PGP SIGNATURE-

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



Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-08-27 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Merka,

On 8/27/20 06:32, Phoenix, Merka wrote:
> I think what the Qualys scan is trying to flag is that the server
> (Tomcat) is listening for both secured and unsecured traffic on
> the _same_ TCP port when the server should be listening for just
> one of the two options (unsecured or secured), not both.
This actually might be a semi-legitimate test. If the client says "Our
policy is to only communicate using encrypted connections" and the
test says "well, here's a non-encrypted connection right here!" then
it makes some small amount of sense. In that case, it's all driven by
policy, and the policy can say "we have a carve-out for TLS handshake
failures" and then allow that particular test to pass.

> The error message returned by the Tomcat service, while certainly
> helpful to the remote client, is returning more information than
> it should (from a security-viewpoint).
Not really.

> If the default behavior for Tomcat is to return this "helpful"
> message for misconfigured clients, would it be reasonable for the
> Connector to have an option (attribute) for turning off this
> feature and simply reject with a TLS error any unsecured traffic on
> the port? This would address the security concern without imposing
> too much "bloat" to the Tomcat side.
I think this might actually be better/easier than implementing a
redirect. It's a simple flag that says "return nice errors on
plaintext-over-TLS connection attempts" (or similar) and the only
thing that changes is that we STOP trying to be nice to the client if
the setting is set to "fail" versus "be-nice".

> For most other web servers (Apache httpd, NGINX, etc.) that offer
> https, the normal behavior is that when an http client tries to
> speak http to server expecting https, the client sees some garbled
> text (the server's TLS response to the connection attempt).
This wasn't the case for httpd for many years. I don't know what it
does these days, but it used to reply with a nice "400 Bad Request"
error just like Tomcat is doing. The difference is that httpd has rich
configuration options to allow you to override that behavior.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9H7ZkACgkQHPApP6U8
pFgOng/8DtMJkQc+MYLRm1iuCD7GZ2f2S7oQ59vFeCGAbmkiUjESvQ42QRGqIMy8
47giFc3ERm84DxyyyU7O/YDFxinOnCrC/v9A6RzpYKlZBSOq9Oy6732xTUAqGGIw
+3QGPXvyjE2Vcg1iavW+7cUKN1Q9R1NGcDRRBpBL0KRQMA3NV9pxGU71/In8TQvi
VZ51f7VTNXaJ2l+w6G23XBJkKQk3csFixevVzr4Xr56FLfqPxUc3m6QNu4BaHmgb
c95hceV/N7tkR9yHdaRtahpZq0lhGqXbNXfqjf7kElSkRmeAZ3MSsdnFD4fBHThn
xvz204xffSE71Z4W24W9gx23+Bg0y2EfPRo1CWC93rEvNRKMK6ILzLczTRA0w6QW
9zP1XC+VwC25LQOGFDgFukQVupPYiMoNSb6DRey5ZUhur6v25nevwbhM0QsAm/oO
oZpreKaUMy+ZoixwGhaZ+UFiZRav7DRLSj85BjK9PqcP4VdPzFR9MarvMqLPxRoq
YxL/jNet4L+29Z2tDkZv4gfGJqI7oWkfXUsBFBjj5JgXrqE94Q8PzAK87pLeU80y
p3IL4krovHbu01j1fE3/aDotEvBu/wxWTCWze9+vL09a82PuTT2pihyCVqFuP9rS
kP0DtVTfbaUMyD2dryjyw4q1NdLYht4y/HHkyU/3cPopCbxEopU=
=4F4z
-END PGP SIGNATURE-

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



Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-08-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/26/20 13:59, Mark Thomas wrote:
> On 26/08/2020 17:50, Christopher Schultz wrote:
>> On 8/26/20 05:27, Mark Thomas wrote:
>>> On 26/08/2020 08:14, Martin Grigorov wrote:
>>>> Hi,
>>>>
>>>> On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha
>>>>  wrote:
>>>>
>>>>> Thanks for reply,
>>>>>
>>>>> Hi Peter - it complains on port 8443 which belongs to
>>>>> Tomcat.
>>>>>
>>>>> Hi Mark - Yes. making HTTP request on HTTPS is wrong. But
>>>>> this security vulnerability is given to us by Qualys scan.
>>>>> It tries to post plain HTTP request on HTTPS port and then
>>>>> gets error message "Bad Request. This combination of host
>>>>> and port requires TLS." which is security loop hole for
>>>>> Qualys.
>>
>>> On what basis?
>>
>>> I fail to see any security issue here other than "Qualys says
>>> so" which is not a valid description of a security
>>> vulnerability.
>>
>> My guess is that this is some form of "server fingerprinting"
>> that they are claiming, like "Zomg! It says Server:
>> Apache-Coyote/1.1! You are $uper vulnerable to 0days, now!".
>
> The entire response, including headers is,
>
> = HTTP/1.1 400 Content-Type: text/plain;charset=UTF-8
> Connection: close
>
> Bad Request This combination of host and port requires TLS. =
>
>> Pratik, can you please be very clear about what the actual
>> complaint is? Are they objecting to one or more of the
>> following:
>>
>> 0. Any legible response at all (meaning they just want a
>> connection-drop response) 1. Server: Apache-Coyote/1.1 response
>> header 2. Predictable / stock text (e.g. "Bad Request. This
>> combination of host and port requires TLS." identifies the server
>> as Tomcat v.x.y or later) 3. Actual Tomcat version number in
>> response
>>
>>> Absent a description of how this can be exploited (and I'll be
>>> very surprised if this can be exploited), there is no security
>>> issue here and Tomcat will not be making any changes.
>>
>> It seems reasonable to (configurably) strip-out version
>> information if there is anything in there... which there probably
>> is not.
>
> Correct, there isn't.
>
>> I'm interested in having Tomcat be able to pass these
>> (admittedly stupid) security requirements,
>
> I have no interest in adding bloat to Tomcat so it can pass so
> called security requirements that have no relevance to actual
> security. Those sort of changes are the sort that get me starting
> to think about using a veto.

Understood. But what does the OP have in terms of options at this point?

1. Ignore the complaint (probably not possible)
2. Request a waiver for this issue (probably not possible, or at least
would require 10 years of red tape)
3. Front the server with httpd + "ErrorDocument 400" (which ... I
think will *also* reply with a plaintext response, right?)
4. Switch to Jetty

I'm trying to avoid "the easiest thing" which is probably to switch to
Jetty. I know our "customers" don't pay for Tomcat, but losing a
"customer" sucks.

>> so maybe we could have a setting on the  that can
>> allow ERR_EMPTY_RESP to be sent if the handshake fails due to
>> probably-not-encrypted just like older versions of Tomcat> did.
>
> That sounds suspiciously like bloat to me.

How about being able to specify the response text, possibly blank?

I think "ErrorDocument 400" with nothing else might mean the same
thing as [[ErrorDocument 400 ""]] meaning that the response will
include NO CONTENT. Maybe that's what Qualys is looking for.

> I've never been particularly convinced by the fingerprinting
> argument. Either you are running a version without any published
> security vulnerabilities that affect you (in which case
> fingerprinting doesn't help the attacker) or you are running a
> version with published security vulnerabilities that do affect you
> and you are relying on security by obscurity - which is no security
> at all.

Yes, "obscurity" doesn't count as a meaningful "security layer", but
you usually can't argue with "industry best practices" and "security
audits".

(I once had a security auditor tell me that we weren't ever allowed to
have an encryption key and encrypted data in the same place at the
same time, because that would be a violation of a security control.)

>> IMO, being able to repl

Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-08-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jon,

On 8/26/20 14:01, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Did Qualsys include a QID with their report?

No, but the OP did include this:

"
Insecure transport
Group: Information Disclosure
CWE CWE-319
OWASP A3 Sensitive Data Exposure
WASC WASC-4 INSUFFICIENT TRANSPORT LAYER PROTECTION
"

Upon further inspection, I think this might actually be "zomg! We got
a non-encrypted response to an encrypted message! Teh site is
insecurez!!eleven"

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9GudkACgkQHPApP6U8
pFjroRAAoIW4n0WRzoK9xFsjhCq2/c6NqTY8q4AD2jypsjBnYfBNJK9AwCGsHRTH
l830zC5KvHn9Qw42wdXdKhBDzLvBovG4TkeYbsTVXtNj3wowhihytahUmZYqwWem
bV3YXQGMDVaCkUHDD0gN8y8NhWk3IE/JwSwmFKEURkR+Tz5nHmUjwEN1A/fhFyj2
Ab3/pKdiyz4vSVec4SxZ8MUQQi0bmueiR4PRpKg7IUESSIp5rjp6wY22IG9VyWoc
jxN3xmCmYUaYqxLQufQY8xgbUtCgKZzX56UM0DpuvneZIImZX1quj3KXnSkwBPAi
ei/bZmnCmz7p7Wukt9nykExPGm/Mvbkhf11k2cdwxdHdkOwNN2rF/ynuAlnyzJdV
Oy1wMgkKTGDb6UahDexeAia4L248jSIn4kC+6T71ppwbLfbVMlkAuEBVjAAQMHOy
YRit5qk4aJh94MSX6M3k12MYwR018SoxSX2RccSYx+S6odN0pKYt4OxVvcOVgWkT
y2ilwPNcVDY8/wkGz4aeMK9kLlstw3K279d9R/cfCFHCko32dnct6rCkUZm4+nqS
W+SaobV6VUcCWVQLTaURaT18hyeohJOHYonkAM6vGERkVoez5xYgQwRfu4tL3mud
76vgLTiGHvVh4fi3wnI99rIYXKvZW7B/SC/WJLFJY7n/Xa5hgjM=
=cDjm
-END PGP SIGNATURE-

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



Re: Tomcat v9 - Insecure transport vulnerability reported by Qualys

2020-08-26 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Mark,

On 8/26/20 05:27, Mark Thomas wrote:
> On 26/08/2020 08:14, Martin Grigorov wrote:
>> Hi,
>>
>> On Wed, Aug 26, 2020 at 7:53 AM Pratik Shrestha
>>  wrote:
>>
>>> Thanks for reply,
>>>
>>> Hi Peter - it complains on port 8443 which belongs to Tomcat.
>>>
>>> Hi Mark - Yes. making HTTP request on HTTPS is wrong. But this
>>> security vulnerability is given to us by Qualys scan. It tries
>>> to post plain HTTP request on HTTPS port and then gets error
>>> message "Bad Request. This combination of host and port
>>> requires TLS." which is security loop hole for Qualys.
>
> On what basis?
>
> I fail to see any security issue here other than "Qualys says so"
> which is not a valid description of a security vulnerability.

My guess is that this is some form of "server fingerprinting" that
they are claiming, like "Zomg! It says Server: Apache-Coyote/1.1! You
are $uper vulnerable to 0days, now!".

Pratik, can you please be very clear about what the actual complaint
is? Are they objecting to one or more of the following:

0. Any legible response at all (meaning they just want a
connection-drop response)
1. Server: Apache-Coyote/1.1 response header
2. Predictable / stock text (e.g. "Bad Request. This
combination of host and port requires TLS." identifies the server as
Tomcat v.x.y or later)
3. Actual Tomcat version number in response

> Absent a description of how this can be exploited (and I'll be
> very surprised if this can be exploited), there is no security
> issue here and Tomcat will not be making any changes.

It seems reasonable to (configurably) strip-out version information if
there is anything in there... which there probably is not.

I'm interested in having Tomcat be able to pass these (admittedly
stupid) security requirements, so maybe we could have a setting on the
 that can allow ERR_EMPTY_RESP to be sent if the handshake
fails due to probably-not-encrypted just like older versions of Tomcat
did.

IMO, being able to reply in plaintext like this is a *feature* (one
that I personally and specifically lobbied to have added to Tomcat)
and shouldn't be removed. If it's not the end of the world to add an
option to disable it, though, I think we ought to do it.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9GkuAACgkQHPApP6U8
pFiGYRAAtvVTw1CKi+epZULpmSHDuO9ipm+I37a6eKMufhIUevCl6MfBQN0kgrfu
Hfh9ByaLIN2JogyCuMehhZv5McGpKT7i9t0OWV9eLzlSvmVh+wzDUvAR83bj8Qk4
woOaiU23DM0jZTfPPtsCGGkJ6FGTzNuwrYzIyjQ8f4OKYopkHffeJ59fQoqmlKeW
hA0+m4xcKgvmRjPmbE+4E5gpV8ylYAyAxQYdpVESpWI4pXViqwn2QfrWMgFZGEE3
7NTTAlQLB3N0jgJCt9dvi4aFzKZOLdYEQ0ooCP34EqfU6S/WQGfR6BZxbcQSyzMa
qOBLnTfe9LBC9DIVQAKenDkkDCWen+7e/EEcRmaAvrlbD9ZfCJ/pNl5WlzymkXfq
y2W6laFR985am5RTAZIfiiOYX2wBW1kna0q7tpDji7wtTag+ZbrqdcFQF3FH3/+u
5l9RWWIMhasQPtC0YiEyeDvCR9iwpjyB6kqIOpMYPR8CCnpq4qtRtbLFpXqXT4QF
MxKNcssX0sZFzsqz/j7VGafg2fq545vCkZFb13HG3Fp0xeNgnwz4WC5yzEHtUWMq
EEacHJaHDusgyjn9Mk5+kT0NNPaerIA/mZEKhjQAORqJPMHRxHGgRN1A4H49SQvL
b7jrlkZc55XqCV5dq+/eR8XIKuXemWKKb4bp0BT9c0WR3mE0FtM=
=HTAL
-END PGP SIGNATURE-

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



Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd

2020-08-25 Thread Christopher Schultz
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 8/24/20 13:24, James H. H. Lampert wrote:
> On 8/24/20 9:57 AM, Christopher Schultz wrote:
>> So your RewriteCond[ition] is expected to always be true? Okay.
>> Maybe remove it, then? BTW I think your rewrite will strip query
>> strings and stuff like that. Maybe you just want
>> RedirectPermanent instead of Rewrite(Cond|Rule)?
>>
>> Okay, so everyone gets redirected from http://exmaple.com/ to
>> https://example.com/. If LE requests
>> http://example.com/.well-known/uherfhuerhfiu then it will be
>> redirected to https://example.com/.well-known/uherfhuerhfiu,
>> presumably locate the correct file and authorize the certificate
>> request, right?
>>
>> But you have said that "everything is unconditionally passed to
>> Tomcat". You posted some config that definitely passes some
>> things to Tomcat, but without seeing the rest of the
>>  configuration it's not possible to know for sure
>> nothing else is going on.
>
> Ok. In the original post, I posted the virtual host configuration
> as it was at the time, with meaningful domain names and IP
> addresses redacted, and some commented-out, abandoned-in-place
> lines removed.
>
> Here is what I currently have in place, albeit with names and IP
> addresses "changed to protect the innocent." I'm sending you the
> uncensored version off-List.
>
>  ServerName foo.frobozz.com # ServerAlias
> bar.frobozz.com DocumentRoot /var/www/html/test ServerAdmin
> i...@frobozz.com  AllowOverride All
>  RewriteEngine on RewriteCond %{HTTP_HOST} !^www\.
> [NC] RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI}
> [R=301,L] 
>
>   ServerName
> foo.frobozz.com # ServerAlias bar.frobozz.com DocumentRoot
> /var/www/html/test ServerAdmin i...@frobozz.com #  /var/www/html/test> # AllowOverride All #  #  "https://foo.frobozz.com/manager/html/*;> #  Require ip
> aa.bb.cc.dd #  #  "https://bar.frobozz.com/manager/html/*;> #  Require ip
> aa.bb.cc.dd #Require ip aa.bb.cc.dd
> ww.xx.yy zz pp.dd.qq.xx  
> Require ip aa.bb.cc.dd ww.xx.yy zz pp.dd.qq.xx 
> ProxyPass "/" "http://127.0.0.1:8080/; ProxyPassReverse "/"
> "http://127.0.0.1:8080/; ProxyRequests Off Include
> /etc/letsencrypt/options-ssl-apache.conf SSLCertificateFile
> /etc/letsencrypt/live/foo.frobozz.com/fullchain.pem
> SSLCertificateKeyFile
> /etc/letsencrypt/live/foo.frobozz.com/privkey.pem 
> 

Yeah... that''s pretty straightforward. Hmm.

No other VirtualHosts? Non other web servers in the mix (e.g.
load-balancer which alreaddy redirects to HTTPS), etc.?

That seems pretty mysterious to me, too.

Are you using VH-based authentication with LE? Meaning, you aren't
using DNS authentication or anything like that?

I think once you have configured the server once with an LE
certificate, renewals can use the existing certificate as
proof-of-ownership without having to put the file into /.well-known.
Or something. I have forgotten the details.

So maybe that's it: you've already bootstrapped the process and so
it's smoother, now. Maybe?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl9FHD0ACgkQHPApP6U8
pFi58xAAvux94C7QCOUkLj8MLGiQV57/ImcTa85nMme2H2ywpZ7JQozlssU6CSpH
FAYFCOP3U3EH6A9AzFeSZhW+sKMeBt6uF3QR/2QF3vGmg5/KcB0srcdBcn6eejVc
KrUnVKx5lcK+hmyXPlIVdGb+koiDl1D1omkeOxdQOaniNfGvW1LgUxouRXpUBTfJ
JK5oe7yV5U8Ge5Wm+pOIrpf/4Y0JqluNJplQIEVWv3x7EsJtSKVKIoCXfPyGf36g
aGmFRsh6XvndllaV/FBxx/K9zh5TG1GijkfO+vsl4l3ZXnljJm1h4Vx/1Y6KEUbM
x9Zv8QgNpXsmZ+ylfi3hK0l9V7rkUB6ZX5mYJa9ABPXYtkE/rvCpG6RijVgY9WA4
4LXKW74+QR9R352OLBCgvE2gjRgVTX/KmoGasBrB3mDYd+vELkBCcXlHAQkYBVqw
KL4UIL3SUEnV4jDfrJ/g2ujyPKd9+ED7EECM91lWg6Lcunc5865qJfPvykIDaBnZ
kASElxqRGqmTUEi57z+BKJNRBs+ME9f7JOlT8iaoB2wKJC8CrUnGNtrFpvBxhehb
GY4uPrUZro7NjuJ/jALnb1CeedeL9+OohxqbTYECaoeS4Op8vNNU6/FtUH9BTjWD
mlaXkhrGr7puf4AjPg9geE/0h5Bg+ltTh8yrK1o+4jrct34S438=
=6dbK
-END PGP SIGNATURE-

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



  1   2   3   4   5   6   7   8   9   10   >