RE: apache-tomcat-8.5.59 too many open files on Linux 8

[Yeggy Javadi]

Hi,
Below is the nsenter output:

# ps -ef | grep tomcat
root  165217   1  1 10:22 ?00:05:33 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server 
-Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar
 -Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root  167329  167268  0 18:00 pts/100:00:00 grep --color=auto tomcat

# nsenter -t 165217 --net lsof -n -p 165217 |less
COMMANDPID USER   FD  TYPE DEVICE SIZE/OFF NODE NAME
java165217 root  cwd   DIR8,2 4096   157664 
/usr/local/freestor/bin
java165217 root  rtd   DIR8,3 40962 /
java165217 root  txt   REG8,2 8712 8913 
/usr/local/jdk/jre1.8.0_271/bin/java
java165217 root  mem   REG8,2   113371   160881 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-jpa-2.1-api-1.0.0.Final.jar
java165217 root  mem   REG8,2   147874   160802 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activemq-protobuf-1.1.jar
java165217 root  mem   REG8,2   391515   160836 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-queryparser-4.10.4.jar
java165217 root  mem   REG8,2   868615   160813 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-context-3.2.17.RELEASE.jar
java165217 root  mem   REG8,2 9711   160792 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-log4j12-1.6.6.jar
java165217 root  mem   REG8,2   196573   160819 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-expression-3.2.17.RELEASE.jar
java165217 root  mem   REG8,297173   160843 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/lucene-misc-4.10.4.jar
java165217 root  mem   REG8,210074   160872 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-ext-1.11.jar
java165217 root  mem   REG8,262983   160861 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/activation-1.1.jar
java165217 root  mem   REG8,2   371668   160812 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/spring-security-core-3.2.9.RELEASE.jar
java165217 root  mem   REG8,2   645914   160754 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-entitymanager-4.3.5.Final.jar
java165217 root  mem   REG8,2   427030   160753 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-envers-4.3.5.Final.jar
java165217 root  mem   REG8,2   256468   160829 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/barcode4j-2.0.jar
java165217 root  mem   REG8,2   489884   160846 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/log4j-1.2.17.jar
java165217 root  mem   REG8,229257   160798 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/slf4j-api-1.7.7.jar
java165217 root  mem   REG8,2   422612   160783 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-awt-util-1.11.jar
java165217 root  mem   REG8,216519   160796 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/jcl-over-slf4j-1.7.7.jar
java165217 root  mem   REG8,2   322362   160851 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/cglib-nodep-2.2.jar
java165217 root  mem   REG8,2   864598   160848 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/castor-1.2.jar
java165217 root  mem   REG8,2   434678   160748 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/commons-lang3-3.4.jar
java165217 root  mem   REG8,2   325196   160785 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/batik-css-1.11.jar
java165217 root  mem   REG8,2  5230007   160755 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/hibernate-core-4.3.5.Final.jar
java165217 root  mem   REG8,2 14041249   160763 
/usr/local/apache-tomcat-8.5.59/webapps/ROOT/WEB-INF/lib/elasticsearch-1.7.5.jar
java165217 root  mem   REG8,2   206385   160749 

Re: POEditor translations currently corrupted

[Mark Thomas]

On 25/05/2021 18:16, Mark Thomas wrote:

All,

The translations we manage via POEditor are currently corrupted. This is 
entirely my fault. In trying to fix a small bug, I introduced a bigger one.


No translations have been lost. Reverting my fix and re-exporting the 
translations from a clean git checkout will restore everything. However, 
I would still like to fix the small bug so I'll be working on this for 
the next few hours which means the translations will remain corrupted 
for that time.


I'll post again when the translations have been restored. Hopefully with 
the small bug fixed as well.


All fixed.

Mark

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

Re: [External] Re: Zip file upload corruption on Linux

[Christopher Schultz]

Tim,

On 5/25/21 11:22, Scott,Tim wrote:

Hi Chris,


"nah, nobody still uses Struts 1.x".

I wouldn't put it past this 14 year old application ...


:)

Mine is coming up on 20 years old.


But at this point, if you have things working, you can probably
stop.

>

My OCD says No!, but my pragmatic side says "leave it until I
have to change"


But something is *definitely* wrong if changing the default file
encoding causes your files to be corrupted. It is *extraordinarily*
unlikely that Tomcat or Struts is doing this. It is much more
likely to be your application somewhere writing to a Writer instead
of a Stream.


Whilst I haven't explored every class in detail, the classes I have
been working with are the first (of my code) to receive the requests
and the data I'm getting is already corrupted. For example, there's
nothing in my application code which writes to a temporary file as
part of this process. My code writes the data to an Oracle database,
binding as a binary (RAW) value.


The code you posted shows imports and then your interaction with the 
fileupload library. Do you know what else happens before this line of code?


ServletRequestContext requestContext = new ServletRequestContext(/* 
HttpServletRequest  */ request);


If the application calls one of a series of methods on 
HttpServletRequest, it can cause a few things to happen:


1. A "reader" is obtained from the request, which will convert bytes -> 
chars.


2. The "reader" needs to know what character encoding to use. There are 
some rules to determine what encoding that is, but Tomcat itself will 
always fall-back to ISO-8859-1 (per HTTP spec) and that is the encoding 
which does not cause corruption for you.


Can you reproduce this in a testing environment? I'll bet we can write a 
Filter or Valve which can catch this bug red-handed.


-chris

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

POEditor translations currently corrupted

[Mark Thomas]

All,

The translations we manage via POEditor are currently corrupted. This is 
entirely my fault. In trying to fix a small bug, I introduced a bigger one.


No translations have been lost. Reverting my fix and re-exporting the 
translations from a clean git checkout will restore everything. However, 
I would still like to fix the small bug so I'll be working on this for 
the next few hours which means the translations will remain corrupted 
for that time.


I'll post again when the translations have been restored. Hopefully with 
the small bug fixed as well.


Mark

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

Re: apache-tomcat-8.5.59 too many open files on Linux 8

[tomcat/perl]

Hi.
The point is to try to figure out what these thousands of apparently "TCPv6" sockets 
belonging to the tomcat process actually are, so that we can maybe begin to look at where 
they may be coming from.
The trouble is, the lsof output so far did not really tell us what these "sock" things 
might be.


But there may be a clue here :
https://serverfault.com/questions/1000338/in-lsof-output-what-are-those-sock-lines
(about when things run in a container).
Is that your case ?
And if so, could you run the lsof command in the container, as they suggest ?

And the point of forcing a tomcat/JVM GC was this :
When you restart tomcat (actually the JVM which runs tomcat), the OS will clean up *all* 
the file descriptors belonging to that process, including the "legitimate" ones shown by 
netstat, and the "unknown" ones shown in addition by lsof.
Doing a GC, without stopping the JVM, would clean up *only* such sockets/fd that are held 
by objects which are discarded, but still sit on the heap awaiting a GC to really destroy 
them.  If your heap is very large, it may otherwise take a long while before such a GC 
happens, and such sockets could accumulate.
One way to trigger a GC is through JMX, but it takes a bit of additional setup to make 
that work. That's why I was asking if you had some method to do that.

(see : https://code.google.com/archive/p/jmxsh/)
But let's look at the lsof part first.



On 24.05.2021 16:09, Yeggy Javadi wrote:

Hi,
I restarted tomcat so PID has changed to 143152; I do not know how to trigger 
tomcat GC, I just restart it to reset the lsof to 0.
Please see outputs below:

# ps -ef | grep tomcat
root  143152   1  0 May22 ?00:26:44 /usr/local/jre/bin/java 
-Djava.util.logging.config.file=/usr/local/apache-tomcat/conf/logging.properties
 -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -d64 -server 
-Xms1800m -Xmx8192m -XX:MaxMetaspaceSize=1800m 
-Djdk.tls.ephemeralDHKeySize=2048 
-Djava.protocol.handler.pkgs=org.apache.catalina.webresources 
-Dorg.apache.catalina.security.SecurityListener.UMASK=0027 
-Dignore.endorsed.dirs= -classpath 
/usr/local/apache-tomcat/bin/bootstrap.jar:/usr/local/apache-tomcat/bin/tomcat-juli.jar
 -Dcatalina.base=/usr/local/apache-tomcat 
-Dcatalina.home=/usr/local/apache-tomcat 
-Djava.io.tmpdir=/usr/local/apache-tomcat/temp 
org.apache.catalina.startup.Bootstrap start
root  153962  153912  0 10:00 pts/100:00:00 grep --color=auto tomcat

# lsof -p 143152 | wc -l
41043

# lsof -p 143152 | grep "protocol: TCPv6"| wc -l
40487

# netstat -p -a -n --inet6 | grep 143152
tcp6   0  0 :::8443 :::*LISTEN  
143152/java
tcp6   0  0 :::443  :::*LISTEN  
143152/java
tcp6   0  0 127.0.0.1:8005  :::*LISTEN  
143152/java
tcp6   0  0 :::1099 :::*LISTEN  
143152/java
tcp6   0  0 :::80   :::*LISTEN  
143152/java
tcp6   0  0 :::36081:::*LISTEN  
143152/java
tcp6   0  0 10.4.3.55:60736 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60732 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60728 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:8010.197.255.10:55446 ESTABLISHED 
143152/java
tcp6   1  0 10.4.3.55:55958 10.4.3.55:11576 CLOSE_WAIT  
143152/java
tcp6   0  0 10.4.3.55:53682 172.22.21.48:443ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48622 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60748 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   1  0 10.4.3.55:55956 10.4.3.55:11576 CLOSE_WAIT  
143152/java
tcp6   0  0 10.4.3.55:40574 172.22.21.47:443ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48620 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:53782 172.22.21.48:443ESTABLISHED 
143152/java
tcp6   0  1 10.4.3.55:49808 10.12.3.78:443  SYN_SENT
143152/java
tcp6   0  0 10.4.3.55:60730 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60750 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60742 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60746 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 127.0.0.1:48624 127.0.0.1:5432  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60734 10.4.3.55:9300  ESTABLISHED 
143152/java
tcp6   0  0 10.4.3.55:60226 172.22.22.192:443   

Re: Tomcat SSL stops working after an undetermined amount of time

[Ezsra McDonald]

Lots of good information was provided.

This afternoon I plan to test the "sslProtocol"  to "protocols" change in
our lower environments. I will reply back with any findings.

Thank you everyone for your responses.

regards,

-- Ez

On Tue, May 25, 2021 at 10:48 AM Mysore, Raghunath 
wrote:

> Hi Chris,
>
> -Original Message-
> From: Christopher Schultz 
> Sent: Tuesday, May 25, 2021 9:10 AM
> To: users@tomcat.apache.org
> Subject: Re: Tomcat SSL stops working after an undetermined amount of time
>
> Ronald,
>
> On 5/25/21 09:31, Roskens, Ronald wrote:
> >
> >> -Original Message-
> >> From: Christopher Schultz 
> >> Sent: Monday, May 24, 2021 1:56 PM
> >> To: users@tomcat.apache.org
> >> Subject: [EXTERNAL] Re: Tomcat SSL stops working after an
> >> undetermined amount of time
> >>
> >> CAUTION: This email originated from outside of the organization. DO
> >> NOT CLICK on links or open attachments unless you recognize the
> >> sender and know the content is safe.
> >>
> >> Ezsra,
> >>
> >> On 5/24/21 10:30, Ezsra McDonald wrote:
> >>> I am enabling SSL debugging this morning. I did catch this in the
> >>> log for an instance that started erroring out this morning. Seems
> >>> like it may be too generic to help solve my problem. Here it is:
> >>>
> >>> 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
> >>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> >>> java.lang.NullPointerException
> >>> at
> >>> org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
> >>> Source)
> >>> at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown
> >>> Source)
> >>
> >> Oh. You are using BouncyCastle. I've never tried to do that. I'm not
> >> sure how well BC will work with Tomcat. We don't officially support
> >> that configuration, but that doesn't mean we won't try to help.
> >
> > This isn't a Tomcat issue but an interoperability issue between
> BouncyCastle & OpenJDK.
> >
> > *
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> > ub.com%2Fbcgit%2Fbc-java%2Fissues%2F633data=04%7C01%7Crmysore%40v
> > isa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db1
> > c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> > C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000s
> > data=VvFC5V57Cy3iWAqlqBwuXjbQOSpMN2EK9nbangoytsc%3Dreserved=0
> > *
> > https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> > .openjdk.java.net%2Fbrowse%2FJDK-8216039data=04%7C01%7Crmysore%40
> > visa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db
> > 1c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> > MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> > sdata=rqFmFJWSb5zJDkd52jV0PU9FP9%2FNt0k1MInH6pcfBGk%3Dreserved=0
>
> Oh, great. Looks like a BC upgrade will fix the NPE. But possibly
> something downstream will still fail...
>
> Just to add my 2 cents here :
>
> Per the problem posed in the very first email, we see the SSL/TLS issue
> between Oracle JDK 8 and Tomcat 8.5
> Environment:
> OS: CentOS 7
> Apache: apache-tomcat-8.5.65
> Java: jdk1.8.0_281
>
> Note that the following link - talks about issues between OpenJDK 11 and
> BC.
> https://bugs.openjdk.java.net/browse/JDK-8216039.
>
> This morning's suggestion (about changing from "sslProtocol"  to
> "protocols" )  from Christopher Schultz, sounds  promising, in that the
> interaction between the Browser-clients and Tomcat 8.5.x server, will be
> limited only to TLS1.2
> Making this change, will preclude other old protocols - like TLS 1, TLS 11
> etc  in communication between the clients and the Tomcat server.
> We will need tests after making the change to "protocols" attribute in the
> HTTPS connector block.
> In context of the above mentioned change -we may not need any editing of
> "java.security" file contents (discussed last evening).
>
> Thanks,
>  -Raghu
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
>

RE: Tomcat SSL stops working after an undetermined amount of time

[Mysore, Raghunath]

Hi Chris, 

-Original Message-
From: Christopher Schultz  
Sent: Tuesday, May 25, 2021 9:10 AM
To: users@tomcat.apache.org
Subject: Re: Tomcat SSL stops working after an undetermined amount of time

Ronald,

On 5/25/21 09:31, Roskens, Ronald wrote:
> 
>> -Original Message-
>> From: Christopher Schultz 
>> Sent: Monday, May 24, 2021 1:56 PM
>> To: users@tomcat.apache.org
>> Subject: [EXTERNAL] Re: Tomcat SSL stops working after an 
>> undetermined amount of time
>>
>> CAUTION: This email originated from outside of the organization. DO 
>> NOT CLICK on links or open attachments unless you recognize the 
>> sender and know the content is safe.
>>
>> Ezsra,
>>
>> On 5/24/21 10:30, Ezsra McDonald wrote:
>>> I am enabling SSL debugging this morning. I did catch this in the 
>>> log for an instance that started erroring out this morning. Seems 
>>> like it may be too generic to help solve my problem. Here it is:
>>>
>>> 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51] 
>>> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
>>> java.lang.NullPointerException
>>> at 
>>> org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
>>> Source)
>>> at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown
>>> Source)
>>
>> Oh. You are using BouncyCastle. I've never tried to do that. I'm not 
>> sure how well BC will work with Tomcat. We don't officially support 
>> that configuration, but that doesn't mean we won't try to help.
> 
> This isn't a Tomcat issue but an interoperability issue between BouncyCastle 
> & OpenJDK.
> 
> * 
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fbcgit%2Fbc-java%2Fissues%2F633data=04%7C01%7Crmysore%40v
> isa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db1
> c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiM
> C4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000s
> data=VvFC5V57Cy3iWAqlqBwuXjbQOSpMN2EK9nbangoytsc%3Dreserved=0
> * 
> https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs
> .openjdk.java.net%2Fbrowse%2FJDK-8216039data=04%7C01%7Crmysore%40
> visa.com%7C29de4f3283544be589d508d91f8f4728%7C38305e12e15d4ee888b9c4db
> 1c477d76%7C0%7C0%7C637575522499773346%7CUnknown%7CTWFpbGZsb3d8eyJWIjoi
> MC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000
> sdata=rqFmFJWSb5zJDkd52jV0PU9FP9%2FNt0k1MInH6pcfBGk%3Dreserved=0

Oh, great. Looks like a BC upgrade will fix the NPE. But possibly something 
downstream will still fail...

Just to add my 2 cents here :

Per the problem posed in the very first email, we see the SSL/TLS issue between 
Oracle JDK 8 and Tomcat 8.5 
Environment:
OS: CentOS 7
Apache: apache-tomcat-8.5.65
Java: jdk1.8.0_281

Note that the following link - talks about issues between OpenJDK 11 and BC. 
https://bugs.openjdk.java.net/browse/JDK-8216039. 

This morning's suggestion (about changing from "sslProtocol"  to "protocols" )  
from Christopher Schultz, sounds  promising, in that the interaction between 
the Browser-clients and Tomcat 8.5.x server, will be limited only to TLS1.2 
Making this change, will preclude other old protocols - like TLS 1, TLS 11 etc  
in communication between the clients and the Tomcat server. 
We will need tests after making the change to "protocols" attribute in the 
HTTPS connector block. 
In context of the above mentioned change -we may not need any editing of 
"java.security" file contents (discussed last evening). 

Thanks,
 -Raghu 


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

RE: [External] Re: Zip file upload corruption on Linux

[Scott,Tim]

Hi Chris,

> "nah, nobody still uses Struts 1.x".
I wouldn't put it past this 14 year old application ...

> But at this point, if you have things working, you can probably stop. 
My OCD says No!, but my pragmatic side says "leave it until I have to 
change"

> But something is *definitely* wrong if changing the default file encoding 
> causes your files to be corrupted. It is *extraordinarily* unlikely that 
> Tomcat or Struts is doing this. It is much more likely to be your application 
> somewhere writing to a Writer instead of a Stream.

Whilst I haven't explored every class in detail, the classes I have been 
working with are the first (of my code) to receive the requests and the data 
I'm getting is already corrupted. For example, there's nothing in my 
application code which writes to a temporary file as part of this process. My 
code writes the data to an Oracle database, binding as a binary (RAW) value.

Thanks,
Tim


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

Re: Tomcat SSL stops working after an undetermined amount of time

[Christopher Schultz]

Ronald,

On 5/25/21 09:31, Roskens, Ronald wrote:



-Original Message-
From: Christopher Schultz 
Sent: Monday, May 24, 2021 1:56 PM
To: users@tomcat.apache.org
Subject: [EXTERNAL] Re: Tomcat SSL stops working after an undetermined
amount of time

CAUTION: This email originated from outside of the organization. DO NOT
CLICK on links or open attachments unless you recognize the sender and
know the content is safe.

Ezsra,

On 5/24/21 10:30, Ezsra McDonald wrote:

I am enabling SSL debugging this morning. I did catch this in the log
for an instance that started erroring out this morning. Seems like it
may be too generic to help solve my problem. Here it is:

24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.NullPointerException
at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
Source)
at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown
Source)


Oh. You are using BouncyCastle. I've never tried to do that. I'm not
sure how well BC will work with Tomcat. We don't officially support that
configuration, but that doesn't mean we won't try to help.


This isn't a Tomcat issue but an interoperability issue between BouncyCastle & 
OpenJDK.

* https://github.com/bcgit/bc-java/issues/633
* https://bugs.openjdk.java.net/browse/JDK-8216039


Oh, great. Looks like a BC upgrade will fix the NPE. But possibly 
something downstream will still fail...


-chris

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

Re: [External] Re: Zip file upload corruption on Linux

[Christopher Schultz]

Tim,

On 5/25/21 05:03, Scott,Tim wrote:

Hi Mark,


No. You should be able to use HttpServletRequest.getPart()

I've given up on that attempt as I keep getting:
java.lang.AbstractMethodError: Method 
org/apache/struts/upload/MultipartRequestWrapper.getPart(Ljava/lang/String;)Ljavax/servlet/http/Part;
 is abstract

I have my workaround and do not anticipate it worthwhile me spending
any more time on the matter.
You know, it's funny. I use Struts 1.x and in order to use the 
Tomcat-provided multipart handling, you need to do extra work. I thought 
of that when Mark suggested using Tomcat's multipart parsing but then 
thought "nah, nobody still uses Struts 1.x".


Anyway, if you want to disable Struts's multipart handling, you have to 
add this to your  definition for Struts. Note that this may 
break other parts of your application that might depend upon the Struts 
multipart handling. But at this point, it's not working anyway, so you 
are probably okay.


  
action
org.apache.struts.action.ActionServlet



  Disable Struts Multipart Handling
  multipartClass
  none


  1048576
  1049600
  1024

  

Note that you may have to "merge" the above with what you have in your 
WEB-INF/web.xml.


But at this point, if you have things working, you can probably stop. 
But something is *definitely* wrong if changing the default file 
encoding causes your files to be corrupted. It is *extraordinarily* 
unlikely that Tomcat or Struts is doing this. It is much more likely to 
be your application somewhere writing to a Writer instead of a Stream.


-chris

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

Re: [OT] Tomcat SSL stops working after an undetermined amount of time

[Christopher Schultz]

Ed,

On 5/24/21 16:25, Ed Rouse wrote:

This works for me. In server.xml:

 
 
 
 
 


If you really put your server's key into C:\Program
Files\Java\openjdk_1.8.0.242\jre\lib\security\cacerts you are making a
mistake IMHO. That file is supposed to contain the JVM's trust store.
You shouldn't be modifying it at all, let alone to put a private key
into it.

-chris


From: Ezsra McDonald 
Sent: Monday, May 24, 2021 4:10 PM
To: Tomcat Users List 
Subject: Re: Tomcat SSL stops working after an undetermined amount of time

[External email: Use caution! Do not open attachments or click on links from 
unknown senders or unexpected emails.]
Chris,

Thanks for your response.

These Tomcat servers are something I inherited. I do not know what this
bouncycastle.crypto is. If it is making my setup complicated how do I get
around it? Is it part of the org.apache.coyote.http11.Http11NioProtocol?
What would you recommend I use instead? My end goal is to just enable
TLS/SSL on the connectors.

--Ez


On Mon, May 24, 2021 at 1:56 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:


Ezsra,

On 5/24/21 10:30, Ezsra McDonald wrote:

I am enabling SSL debugging this morning. I did catch this in the log for
an instance that started erroring out this morning. Seems like it may be
too generic to help solve my problem. Here it is:

24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
java.lang.NullPointerException
at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
Source)
at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown Source)


Oh. You are using BouncyCastle. I've never tried to do that. I'm not
sure how well BC will work with Tomcat. We don't officially support that
configuration, but that doesn't mean we won't try to help.

There will be a presentation at this year's ApacheCon @Home 2021 about
configuring Tomcat for FIPS and it will include how to configure Tomcat
with BC (including FIPS). Obviously, you don't want to wait around until
the conference to get things working, but perhaps the presenter is
lurking on the list ... ?

I don't have an email address for the presenter, so I can't give you a
reference. :/

-chris

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




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

Re: Tomcat SSL stops working after an undetermined amount of time

[Christopher Schultz]

Ezsra,

On 5/24/21 11:18, Ezsra McDonald wrote:

I was unable to identify the issue with debug enabled. I started looking
closer at the error I was getting in the various browsers. Apparently the
SSL is working. The browsers are blocking it because the server is using
something other than TLSv1.2 or better. I was able to prove this using
Safari. When I enabled the older TLS options I was able to connect.


This is excellent information to have.

Tomcat (or BC) should not be throwing NPE under any circumstances, though.


The odd
thing is that I have the connector configured for TLSv1.2. So, that is
where I need to concentrate my efforts now. Why is tomcat not using the
TLSv1.2 protocol?

As a refresher, I have the following configured for the connector.



Aha. You are using "sslProtocol" which is, unfortunately, a nearly 
worthless configuration attribute and *always* causes confusion for 
anyone who has never had to deal with the JSSE TLS API.


The configuration attribute you really want to use is:

protocols="TLSv1.2"

The default is "all" which means 
"SSLv2Hello,TLSv1,TLSv1.1,TLSv1.2,TLSv1.3", so all protocols should be 
enabled by default.



A SSLscan of the server port shows the following requests were accepted.
Some are TLSv1.2.

sslscan target.host.com:8080|grep Accepted
 Accepted  TLSv1  256 bits  ECDHE-RSA-AES256-SHA
 Accepted  TLSv1  256 bits  DHE-RSA-AES256-SHA
 Accepted  TLSv1  128 bits  ECDHE-RSA-AES128-SHA
 Accepted  TLSv1  128 bits  DHE-RSA-AES128-SHA
 Accepted  TLS11  256 bits  ECDHE-RSA-AES256-SHA
 Accepted  TLS11  256 bits  DHE-RSA-AES256-SHA
 Accepted  TLS11  128 bits  ECDHE-RSA-AES128-SHA
 Accepted  TLS11  128 bits  DHE-RSA-AES128-SHA
 Accepted  TLS12  256 bits  ECDHE-RSA-AES256-GCM-SHA384
 Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA384
 Accepted  TLS12  256 bits  ECDHE-RSA-AES256-SHA
 Accepted  TLS12  256 bits  DHE-RSA-AES256-GCM-SHA384
 Accepted  TLS12  256 bits  DHE-RSA-AES256-SHA256
 Accepted  TLS12  256 bits  DHE-RSA-AES256-SHA
 Accepted  TLS12  128 bits  ECDHE-RSA-AES128-GCM-SHA256
 Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA256
 Accepted  TLS12  128 bits  ECDHE-RSA-AES128-SHA
 Accepted  TLS12  128 bits  DHE-RSA-AES128-GCM-SHA256
 Accepted  TLS12  128 bits  DHE-RSA-AES128-SHA256
 Accepted  TLS12  128 bits  DHE-RSA-AES128-SHA


Most browsers will ignore some subset of the above.

The only "safe" cipher suite listed above is ECDHE-RSA-AES128-GCM-SHA256 
and everyone should support *at least* that for the time being. Hmm.


-chris

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

Re: Tomcat SSL stops working after an undetermined amount of time

[Roskens, Ronald]

> -Original Message-
> From: Christopher Schultz 
> Sent: Monday, May 24, 2021 1:56 PM
> To: users@tomcat.apache.org
> Subject: [EXTERNAL] Re: Tomcat SSL stops working after an undetermined
> amount of time
> 
> CAUTION: This email originated from outside of the organization. DO NOT
> CLICK on links or open attachments unless you recognize the sender and
> know the content is safe.
> 
> Ezsra,
> 
> On 5/24/21 10:30, Ezsra McDonald wrote:
> > I am enabling SSL debugging this morning. I did catch this in the log
> > for an instance that started erroring out this morning. Seems like it
> > may be too generic to help solve my problem. Here it is:
> >
> > 24-May-2021 09:25:44.609 SEVERE [catalina-exec-51]
> > org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun
> > java.lang.NullPointerException
> > at org.bouncycastle.crypto.signers.PSSSigner.generateSignature(Unknown
> > Source)
> > at org.bouncycastle.jce.provider.JDKPSSSigner.engineSign(Unknown
> > Source)
> 
> Oh. You are using BouncyCastle. I've never tried to do that. I'm not
> sure how well BC will work with Tomcat. We don't officially support that
> configuration, but that doesn't mean we won't try to help.

This isn't a Tomcat issue but an interoperability issue between BouncyCastle & 
OpenJDK.

* https://github.com/bcgit/bc-java/issues/633
* https://bugs.openjdk.java.net/browse/JDK-8216039

Ron

Disclaimer

This e-mail message is being sent solely for use by the intended recipient(s) 
and may contain confidential information. Any unauthorized review, use, 
disclosure or distribution is prohibited. 
If you are not the intended recipient, please contact the sender by phone or 
reply by e-mail, delete the original message and destroy all copies. Thank you.

Re: #tomcat on Freenode?

[Coty Sutherland]

On Thu, May 20, 2021 at 1:03 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> Coty,
>
> On 5/19/21 15:28, Coty Sutherland wrote:
> > Hi all,
> >
> > I was just notified about some mess going on with Freenode which has
> > seemingly resulted in a mass exodus of users from the freenode servers.
>
> I read about this last night and I immediately thought "I wonder if Coty
> will say anything about this." :)
>

lol, of course :P


> It's an "interesting" situation, for some values of "interesting."
>
> We (well, Coty) maintains a presence on #freenode because it appears to
> help some people. Probably a very small number of people (relatively
> speaking). Removing that resource may cause some people to fail to get
> help. OTOH, we don't maintain a presence on fb, AIM, or Parler and we
> prefer the mailing list for most interactions for a whole host of reasons.
>

I wasn't exactly proposing that we remove the resource, just that in light
of all the people migrating away from freenode and the likelihood that the
Fedora community will do the same, I won't be available there going forward
(I really only started hanging out on freenode because the Fedora community
communicates there a lot). And since I was basically the only committer
hanging around, I didn't think it was worth keeping a reference on the
project page which makes it look as if the channel was an 'official' place
to get help. I'm equally as OK leaving it, but since I was the only person
paying it any attention I thought it was worth asking how others thought :)


> I don't think there are any people who are using #freenode because they
> don't trust the ASF infrastructure. I think they just want to use IRC.
> (Which, for those who are unfamiliar, is like Slack but without all the
> stupid cat photos.) #freenode was great because you didn't have to pay
> The Man to run an IRC channel/server for you and you also didn't have to
> run it yourself. It was a nice, shared infrastructure. All of that still
> exists. It's just got a bad taste to it because something that was free
> and grassroots is now owned by a corporation and Corporations Are Bad
> m'kay.
>
> If we want to provide support via IRC, there is nothing wrong with
> #freenode in spite of recent events, IMHO.
>
> I think the question should be "is a realtime support system appropriate
> for our community?" I tend to think not, but I'm not the only one here.
>

I wouldn't call what is being provided in #tomcat on freenode "realtime
support" haha There's maybe one question a month there on average (at least
when I'm online during the week), and sometimes they even go unanswered
depending on who is available at the time.


> If we are going to "quit" #freenode, should we put our efforts into
> pointing people to the mailing list(s) instead of pointing them to
> another competing platform? I think we should funnel people to the
> mailing lists. If the mailing list has too high a bar, then I guess we
> can point them to Slack. (Does Slack require an account? Requiring
> signup sucks. At least subscribing to a mailing list doesn't mean you
> need another entry in your password safe.)
>
> Anyhow, I'd love to hear what others think. But I would suggest that you
> consider your motivations before doing anything. Specifically:
>
> 1. Why abandon #freenode?
>
> 2. Why move to anything other than mailing-list?
>

I agree, we should drive everyone to mailing lists but not everyone likes
them so having a few options is good for the community IMO. Also, we aren't
really abandoning anything because we don't really maintain it, it's led by
community folk as far as I know; I'm not a moderator. I was just suggesting
that if it's not a resource we're actively maintaining that we maybe
shouldn't point to it from the project page.


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

RE: [External] Re: Zip file upload corruption on Linux

[Scott,Tim]

Hi Mark,

> No. You should be able to use HttpServletRequest.getPart()
I've given up on that attempt as I keep getting:
java.lang.AbstractMethodError: Method 
org/apache/struts/upload/MultipartRequestWrapper.getPart(Ljava/lang/String;)Ljavax/servlet/http/Part;
 is abstract

I have my workaround and do not anticipate it worthwhile me spending any more 
time on the matter.

Thanks,
Tim


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