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

[Bill Stewart]

On Thu, Aug 6, 2020 at 10:18 AM Christopher Schultz wrote:

The problem is that if you don't have your old command-line saved and
> handy, you have to figure out how to re-generate it. Thus, the
> feature-request for procrun to dump the current configuration to a
> script which can re-create itself.
>

I just thought I would also mention that this problem (needing to reproduce
a service configuration) doesn't arise when using my alternative installer
to upgrade a Tomcat instance: An upgrade installs on top of, and replaces,
an older version in-place without modifying the service configuration
details.

Bill

Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

[James H. H. Lampert]

On 8/6/20 10:10 AM, Christopher Schultz wrote:


$ openssl pkcs12 -export \ -in /etc/tomcat8/test.foo.net.crt \
-inkey /etc/tomcat8/test.foo.net.key \ -certfile
/etc/tomcat8/test.foo.net.issuer.crt \ -out
/etc/tomcat8/test.foo.net.p12 \ -chain

Then reconfigure your  to use your keystore.


Dear Mr. Schultz (et al):

It was a bit of a challenge to find out how to use a PKCS12 keystore in 
the Certificate clause, but not that difficult. And the "-chain" was not 
necessary.


At any rate, congratulations, you have just cut my proverbial Gordian knot!

In my case, there's obviously no need for the


curl https://localhost/manager/jmxproxy?invoke=Catalina%3Atype
%3DProtocolHandler%2Cport%3D8443%2Caddress%3D
%22127.0.0.1%22&op=reloadSslHostConfigs


in my renewal script, as given in your presentation, because it's 
already necessary to shut down Tomcat for the renewal: the known-good 
procedure for getting a Let's Encrypt on an Amazon Linux (not "2") 
instance with a Bitnami Trac/SVN stack uses Lego, rather than Certbot, 
and Lego needs to take over all the ports in order to do its magic 
(probably why Lego is not as popular as Certbot).


And likewise, since I'm generating a PKCS12 keystore, rather than using 
the certificate and key files directly, I was able to cut out making 
local copies of those files, and just reference the ones that Lego put 
in /opt/trac-1.2.3-11/letsencrypt/certificates/ directly.


--
James H. H. Lampert

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

Re: Rewritten requests returning 404 in 8.5.57

[Barry Roberts]

On Thu, Aug 6, 2020 at 1:23 PM Christopher Schultz
 wrote:
>
> Are you trying to redirect across contexts (from one web application
> to another)? If so, you need to make sure you are actually doing a
> redirect. Your RewriteRules aren't redirecting.
>
> Try the [R] flag.
>
> - -chris

Actually, no.  We used to have 3 similar but distinct apps deployed at
/apps/iv /ivplugin and /apps/ivplugin. Now the code has converged, and
there's only one app, but for a while we need to continue to use all
the old paths.  The rewrite rules let me deploy one app instead of
deploying the same app 3 times.  And it was working just fine in (at
least) 8.5.51.  We've been using this hack for nearly a year.

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

Logging Rewrite Activity

[Jerry Malcolm]

How do configure TC to log the activities of the RewriteValve?  I added

org.apache.catalina.valves.rewrite.RewriteValve.level = FINE

to logging.properties.  But I'm not seeing any output related to 
rewrite. Do I have the logging config wrong?  Am I looking in the wrong 
place for the log data?


Thx

Jerry


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

Re: Rewritten requests returning 404 in 8.5.57

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Barry,

On 8/6/20 14:36, Barry Roberts wrote:
> On Thu, Aug 6, 2020 at 9:51 AM Mark Thomas 
> wrote:
>>
>>
>> Minimum steps to recreate the issue with an 8.5.57 install of a
>> standard ASF provided distribution?
>>
>> Mark
>>
>
> A minimal example similar to what I'm doing in 8.5.57, the
> redirects work as expected.
>
> I'm at a loss as to what configuration I have that causes a valid
> redirected path (I can copy it from the access log) will 404, but
> if I paste it into my browser, it works.  If anyone has any ideas,
> I'm all ears.
>
> I have:  className="org.apache.catalina.valves.rewrite.RewriteValve" />
>
> in the Host element in my server.xml, and
> conf/Catalina/localhost/rewrite.config contains: RewriteRule
> ^/ivplugin(.*)$ /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]
> RewriteRule ^/apps/ivplugin(.*)$
> /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]

Are you trying to redirect across contexts (from one web application
to another)? If so, you need to make sure you are actually doing a
redirect. Your RewriteRules aren't redirecting.

Try the [R] flag.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sWIoACgkQHPApP6U8
pFj72Q/8DMBohsOQInDOreZVJDCVheOUyEkppWMNI39ZxpO5to5QQTD++06nprvs
+750zX815hcI6XhRqXua85LiUkCCUMyWa8J8SGBotoljG4gNPVqoKA4UI1x1bbgz
ztuoi9wPep5L59FFGRnnESl/l4lWGLWInmcw+2zoMXxorArFzUqOWsuSf+nSDYlJ
lz84AcGlbUZnexEDSRmO7V3+TuXC5lrvxUv62oUJpsDmhNkPvaaaA/cVEBZMQSnD
gxIOlxQeJk7klsYt6hH/2SRZWKeE4KZ8lW1EdkyCq9P+W6oozV2DhCS6F6oM7JDd
yIIoPytdvZkD3UwXgIwT//Af5W6WGbeFJlXGhUiVUx8gvQKRLDE+vtLmEaB1DG7B
kRelvSYkbhjzBtBA1+On8LX1+FxFrXIGMFDBrUqh9AxRSYGehP3uB5273PVrbqu7
Z6oPgqmTM/4c0mHsHKHVMEILcbJryLCvJaysxRg++hgqbicu+6EVtVjG7suvEXFI
i7/nCzBsGGgitLPlRB7OQSfkcB1XnrtNXG29qHZ0UOOVuqnGSNFm8jFQnyh8eZFA
mYmLVc621HbuSuC8vBOQMJDoMm1+dL7gEwrSRpkbcoyQDA68VQdZPsoCwybwGqST
0sir9GgZIGwEchXqXYXRG5fw9IbhGLFT9Y2t80tesneHNxGkM3o=
=q7rx
-END PGP SIGNATURE-

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

Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 8/6/20 14:10, James H. H. Lampert wrote:
> On 8/6/20 9:37 AM, Christopher Schultz wrote:
>> $ openssl pkcs12 -export \ -inkey /etc/tomcat8/test.foo.net.key
>> \ -
>
> Dear Mr. Schultz:
>
> Is there supposed to be something after that last hyphen? When I
> type that command, I just get a terminal window full of helptext.
>
>
> And if I try the second command,
>> $ openssl pkcs12 -export \ -in /etc/tomcat8/test.foo.net.crt \
>> -inkey /etc/tomcat8/test.foo.net.key \ -certfile
>> /etc/tomcat8/test.foo.net.issuer.crt \ -out
>> /etc/tomcat8/test.foo.net.p12 \ -chain
>
> without the first, I get:
>> Error unable to get local issuer certificate getting chain.

The -chain argument doesn't take a filename or anything. It tells
openssl to chain the certs together to make sure everything is okay.

You may not need -chain but I seem to always do it.

My slides for Let's Encrypt + Tomcat say:

$ openssl pkcs12 -export -in [cert] -inkey [key] -certfile [chain]
- -out [p12file]

So maybe you don't need the -chain.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sV+gACgkQHPApP6U8
pFgQmBAAvGp6ve2xFrdEUgyH6I2lqrULcct46j+KTrxRRFg9B9hEuAGh6+BclG+3
EF10QmpsOOWm1UChk9J06bCA0QQNxCpY5QrCebHEdGxn8SRct0UeLGFMsTHhli7R
ZrLkTrleOReMzwv++69S+kastreo/TpqziAtDrvMXXmcEo25YEV8ll7RkP+hhxVC
mTnmGjVtjRMOm9Ujj7LYqtRj/A2HLI3BJp5ZJyQAQm4rSZ+kHkVgExlG0LiZjNnI
ZPJGo394JzzrcjK7szbpcWzQlokHmW96a0vPt0k0DokWc2JM0jLS0aKHL2OTdqV9
gPCgeyVRDgVzdqGVjCpubL4H2kRilBc4vo2H2JtTU+bXJfTr59gfsFybGtRjv2US
KZJDeTjqf++LhsVEoRpKSGCKru7aDS89JZ01F9zGkOGk3DTHJjqNv+gz3p3ilmiS
/DF+EE1JnRiIJ7qE89QxBFKOKWz3TJOsDNYf39S931ZkDbi4wuYh15JZE9DSYOrB
5PoDZC8xWL+EBtLUmCTj3fpuwIvHSvo34TNvsgNcdEHtd4P3pSLhBYTeUsqU8dzh
j3GGn9jLI/zdlQH65bcjC7MY28ut0n2kqqnwu/myjzPlKt0B7KSDAVcoXqHRS5WV
0lLPiOCuwYtDLTf55/1/zDqLGEr8tcTb99VeXe+RvPQEKmRfrjA=
=1ZK9
-END PGP SIGNATURE-

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

Re: Rewritten requests returning 404 in 8.5.57

[Barry Roberts]

On Thu, Aug 6, 2020 at 9:51 AM Mark Thomas  wrote:
>
>
> Minimum steps to recreate the issue with an 8.5.57 install of a standard ASF 
> provided distribution?
>
> Mark
>

A minimal example similar to what I'm doing in 8.5.57, the redirects
work as expected.

I'm at a loss as to what configuration I have that causes a valid
redirected path (I can copy it from the access log) will 404, but if I
paste it into my browser, it works.  If anyone has any ideas, I'm all
ears.

I have:
  

in the Host element in my server.xml, and
conf/Catalina/localhost/rewrite.config contains:
RewriteRule ^/ivplugin(.*)$ /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]
RewriteRule ^/apps/ivplugin(.*)$ /apps/iv$1?XV_ORIG_PATH=%{REQUEST_URI} [QSA,L]

Thanks,
Barry

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

Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

[James H. H. Lampert]

On 8/6/20 9:37 AM, Christopher Schultz wrote:

$ openssl pkcs12 -export \
-inkey /etc/tomcat8/test.foo.net.key \
-


Dear Mr. Schultz:

Is there supposed to be something after that last hyphen? When I type 
that command, I just get a terminal window full of helptext.



And if I try the second command,

$ openssl pkcs12 -export \
  -in /etc/tomcat8/test.foo.net.crt \
  -inkey /etc/tomcat8/test.foo.net.key \
  -certfile /etc/tomcat8/test.foo.net.issuer.crt \
  -out /etc/tomcat8/test.foo.net.p12 \
  -chain


without the first, I get:

Error unable to get local issuer certificate getting chain.


--
JHHL

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

Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 8/6/20 13:03, James H. H. Lampert wrote:
> On 8/6/20 9:37 AM, Christopher Schultz wrote: . . .
>> As a short-term workaround, you can load your stuff into a
>> keystore like this:
>>
>> $ openssl pkcs12 -export \ -inkey /etc/tomcat8/test.foo.net.key
>> \ -
>>
>> $ openssl pkcs12 -export \ -in /etc/tomcat8/test.foo.net.crt \
>> -inkey /etc/tomcat8/test.foo.net.key \ -certfile
>> /etc/tomcat8/test.foo.net.issuer.crt \ -out
>> /etc/tomcat8/test.foo.net.p12 \ -chain
>>
>> Then reconfigure your  to use your keystore.
>
> That could even be a permanent workaround if it can be done
> non-interactively.

It /can/ be done non-interactively. If you see this presentation on
using Let's Encrypt with Tomcat, there are a few slides toward the end
about automation.

http://tomcat.apache.org/presentations.html#latest-lets-encrypt

> How, I wonder, is it that the PEM files work just fine after the
> "unwanted update" that bumped Tomcat up from 40 to 57, and pulled
> in a slightly newer Java 1.8?

Oh. I completely forgot to look at the version numbers. And now I know
what the problem is, and why my mock-up test I just wrote works fine.

See the changelog for 8.5.51:

http://tomcat.apache.org/tomcat-8.5-doc/changelog.html#Tomcat_8.5.51_(ma
rkt)

Specifically, this entry:

Add: Add support for RFC 5915 formatted, unencrypted EC key files when
using a JSSE based TLS connector. (markt)

When using an unencrypted EC key (as it seems you are using), Java
doesn't know how to decode that type of file directly as we can with
e.g. RSA non-encrypted keys. So we have to help it along by
directly-parsing the ASN.1 [1] data and re-writing it into a form Java
can understand.

So you must use Tomcat 8.5.51 or later to use PEM-encoded
non-encrypted Elliptic curve key files (got all that?).

- -chris

[1] There is a special place in hell reserved for everyone responsible
for ASN.1
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sOXoACgkQHPApP6U8
pFjxYxAAxCiE18mXicHQJUUz8PUbhYa/aQEwdaj+IIPUpAhHExcb31Msa9Nw+xiC
YTXHwb5L51Sr/FGKqDfSvl84DQYZipkudwo2uyhIDJR++6+qkbNvMiXlOw757UXi
zkeQv91Cc6Q/rpaxiuifw2kUSejzl/yVxgAWb6XXS1RwRUwq2UEjM+aK3HvCm1C8
6yMkxi5E7ISxiQ1cui1IMGnov4BqIp+tJT+z+PlmtbBJAGHwY/DeW7hU2Yl1rn+B
yI3ydhSxK7cRVzNbvRMrNXjLCF0Lo8S1b0K+lqF85DlO91koQQMMEBrt9X9Q8E5m
xdV161SGfSV5N27JNTdHyI/OjL9ALGXyfBJcENP6J5ZaZ2xouO9XLd+jENyj0zAz
8r5wczDe3uPNiPAIGkm8eAP5O8qz48RZ/N7TKM/kpAlknb4B6zSZN0meteqopWu4
rkCvb4Z2YOU4EiqdtbxyJuoMaFzhgHquDQBZS0aKA56pVjHNi+adML/X9mCsQ+7Z
khZpuSnOcq1pynqW8EuX4L6IZUtqX3K192kLOOvnNnj/Fys5MToj3259hXoz7LYn
2Pncj0E+Y7W3H54CviF0vj6nPmCFkOIaFfQ+/GdLexDrJ34LpNtkMyWAz3LPVYhh
8moCiMTDowX1UGPYmIJ+IlkdhsXBycmqToMBzgPnKlJKHUk5kuM=
=5DNS
-END PGP SIGNATURE-

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

Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

[James H. H. Lampert]

On 8/6/20 9:37 AM, Christopher Schultz wrote:
. . .

As a short-term workaround, you can load your stuff into a keystore
like this:

$ openssl pkcs12 -export \
-inkey /etc/tomcat8/test.foo.net.key \
-

$ openssl pkcs12 -export \
   -in /etc/tomcat8/test.foo.net.crt \
   -inkey /etc/tomcat8/test.foo.net.key \
   -certfile /etc/tomcat8/test.foo.net.issuer.crt \
   -out /etc/tomcat8/test.foo.net.p12 \
   -chain

Then reconfigure your  to use your keystore.


Dear Mr. Schultz:

Thanks.

That could even be a permanent workaround if it can be done 
non-interactively.


How, I wonder, is it that the PEM files work just fine after the 
"unwanted update" that bumped Tomcat up from 40 to 57, and pulled in a 
slightly newer Java 1.8?


--
JHHL

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

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

[Bill Stewart]

On Thu, Aug 6, 2020 at 10:01 AM wrote:

I like what you are showing here, but are you implying a shared
> CATALINA_HOME and CATALINA_BASE?
>

Sorry; I don't understand the question. The alternate installer doesn't set
or use the CATALINA_HOME or CATALINA_BASE environment variables; it uses
procrun (tomcat.exe) with a very long command line to install Tomcat as a
service.

Bill

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

[Bill Stewart]

On Thu, Aug 6, 2020 at 10:18 AM Christopher Schultz wrote:

The problem is that if you don't have your old command-line saved and
> handy, you have to figure out how to re-generate it. Thus, the
> feature-request for procrun to dump the current configuration to a
> script which can re-create itself.
>
> I'm just suggesting that if your installer can dump that kind of thing
> out it might also be handy.
>

I agree that this would be useful. Once it exists in procrun, perhaps the
installer could be extended to take advantage of it.

Bill

Re: Let's Encrypt cert worked fine in 8.5.57, but connector fails in 8.5.40

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 8/5/20 19:46, James H. H. Lampert wrote:
> I've now proceeded to the "real" server, with the Tomcat portion of
> the procedure refined to give me plenty of "undo" capability. And
> it turns out I need it.
>
> It seems that with the unwanted update to 7.0.57 that happened on
> launching the test spot instances, the Let's Encrypt certs worked
> just fine.
>
> But applying the procedure to the *real* development instance
> (7.0.40) blew up in my face, failing to open the connectors. Here
> is an excerpt from catalina.out, showing the stacktraces.
>
>> 05-Aug-2020 23:00:52.189 INFO [main]
>> org.apache.catalina.startup.VersionLoggerListener.log Server
>> version:Apache Tomcat/8.5.40
>>
>> [snip]
>>
>> 05-Aug-2020 23:00:52.195 INFO [main]
>> org.apache.catalina.startup.VersionLoggerListener.log JVM
>> Version:   1.8.0_201-b09
>>
>> [snip]
>>
>> Caused by: java.security.KeyStoreException: Cannot store
>> non-PrivateKeys at
>> sun.security.provider.JavaKeyStore.engineSetKeyEntry(JavaKeyStore.jav
a:261)
>>
>>
>>
at
>> sun.security.provider.JavaKeyStore$JKS.engineSetKeyEntry(JavaKeyStore
.java:56)
>>
>>
>>
at
>> sun.security.provider.KeyStoreDelegator.engineSetKeyEntry(KeyStoreDel
egator.java:117)
>>
>>
>>
at
>> sun.security.provider.JavaKeyStore$DualFormatJKS.engineSetKeyEntry(Ja
vaKeyStore.java:70)
>>
>>
>>
at java.security.KeyStore.setKeyEntry(KeyStore.java:1140)
>> at
>> org.apache.tomcat.util.net.SSLUtilBase.getKeyManagers(SSLUtilBase.jav
a:313)

*sigh*

Okay,
>>
this is a confluence of:

1. You are using PEM files instead of a Java keystore

1a. Tomcat handles this by creating an in-memory KeyStore and loading
your key + certificate into it

2. Java 1.8 doesn't like non-private keys in KeyStores for some reason

2a. Java somehow thinks your key + cert aren't "private" :(

- From your other thread, I think you are doing this:



I think the problem is that there is no "password". Here is the line
of code bombing:

// Switch to in-memory key store
ksUsed = KeyStore.getInstance("JKS");
ksUsed.load(null,  null);
ksUsed.setKeyEntry(keyAlias,
privateKeyFile.getPrivateKey(), keyPass.toCharArray(),
chain.toArray(new Certificate[0]));

It's the call to setKeyEntry which fails. The key alias is "tomcat"
unless you have explicitly set the alias. The cert and key are
obvious, but the keypass is probably empty.. or something.

The default key password is whatever the keystore password is. The
default keystore password is "changeit". So I think this is why we
aren't getting an NPE when we call keyPass.toCharArray.

This works in other scenarios. Not sure what is the exact problem with
yours.

ks.load(null, null) looks suspicious. Maybe it's not okay to use a
non-initialized KeyStore object. But I think maybe it should be:

  ks.load(null, keyPass.toCharArray());

I'll have too play with this a little locally to see what the problem is
.

As a short-term workaround, you can load your stuff into a keystore
like this:

$ openssl pkcs12 -export \
   -inkey /etc/tomcat8/test.foo.net.key \
   -

$ openssl pkcs12 -export \
  -in /etc/tomcat8/test.foo.net.crt \
  -inkey /etc/tomcat8/test.foo.net.key \
  -certfile /etc/tomcat8/test.foo.net.issuer.crt \
  -out /etc/tomcat8/test.foo.net.p12 \
  -chain

Then reconfigure your  to use your keystore.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sMeQACgkQHPApP6U8
pFh4HA/+KZTBU0ghzVqLmalXNJN3P89/FrhJqJWOfQyn3noqUBRhFsyDcOK0z+uR
HxC85OClpZ1LaJwNE4LRArG26chWTGMQm4Z7u1UzhWtz0pIa7wijGj3fQx/EXmQW
ePdOlAcAJnFKUZJr5giDAT+Sl8OC76NbfaN/fz6gqESXxqdxRxHPTrGBVgHol7v1
p4fNiU0T+cw2wQNwq30tHT378wNsC2xozotw/vdr2EQbX7HK/S+tRFJziupUcHzt
cJAWymUiE6Vfw19zSRGF/Fp9s9o/fCaCJKSVl2CEMbR8MdytjmTaQspAK9CXXXpo
Ue8wDuDMNRB6afq3ftoNYJQwfNCvOADTw5L0Xwr5hb+r8xnRBZQQodtBNVznZ1Of
6lnkrqVAYpuUklDCbpWTB52LjE08IRhTaBCJPuueQL9Yxlt4nO2NndJHLTvANB0L
sqEbmRLsROD/eDCaSq7VZzWAnu17C1iO0i7ztsr3JUjregY9EoCs/YOxX71jicHF
10B4HMmqX18DuJtWTSiMQSvy3JqVcCPOIGBRIWxTKS93xGsr5MeAYnBxKrsOJuF1
L+uD56u2pZwkkT3HHiHfXB/db+1mE5GugkY3qBIrOMaTUtS+UPddxpOu59fgPhvC
e9SPhx9pEgUlfuFcFvbWwhv9K1mlAx8PcZMZrwGPEO1ibjfqSaU=
=Fprl
-END PGP SIGNATURE-

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

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

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bill,

On 8/6/20 11:56, Bill Stewart wrote:
> On Thu, Aug 6, 2020 at 9:09 AM Christopher Schultz wrote:
>
> I don't know if you are interested in such things, but being table
> to
>> export a configuration from one machine to another might be
>> useful for your installer, too. Something like "deploy to server
>> A, manually-configure, tweak, test, prove" and then "copy
>> deployment configuration to servers B - Z".
>>
>
> The alternative installer doesn't export a configuration, but it
> does let you repeat an installation using command-line options to
> get a similar effect; e.g.:
>
> apache-tomcat-a.b.c-setup.exe /type=core
> /serviceusername="domain\account"
> /jvmoptions="-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT"
> /jvmms=2048 /jvmmx=2048 /silent
> /log="c:\windows\temp\tomcatinstall.log"
>
> (all on one line of course)

Right, this is what Tomcat's service installer allows (not the actual
installer, but service.bat for example).

The problem is that if you don't have your old command-line saved and
handy, you have to figure out how to re-generate it. Thus, the
feature-request for procrun to dump the current configuration to a
script which can re-create itself.

I'm just suggesting that if your installer can dump that kind of thing
out it might also be handy.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sLUAACgkQHPApP6U8
pFgv9BAAiCiThLhKhb+Yq5iOQ5Qw1sJan6M0PsguEDpd1ogIwvkAcxmS1HnyzU8/
F/uM72BzKk8SaX0e6IeNC4c6kq065EA+yxC7UDk9N2FkWIv9vBxn4IT1Y7eFIzXX
UPwLKYvjDohhy8zwUwbr0/yBcN5sW+5Wu1YC7yY8epWUhmOz8eDXROEapfjDMHQ+
axe8qGBfBHM6ILZX8SJW941QIwCutB6JEJ/uUSgQGFXQ8JgvL3WEXEXK/losEQBi
4XX1q5Afam8P164X9krBuiNKBBtehWkwCEb6TNGPB2elkNGDCRTlG466Qn5ghyye
9UmXrP5Zvm4IGv9OiWEvgabA3XZfuNNJB7iVGx95HcguLTmwev18LiC/5KaehV6Q
gUUlhooMJF4eTYn26MFAUw9RSGDq9pd7/W1Kkq3QDiw6OloQxSLLcwy0XUyeXd9O
17N/Ez9DaW+ENSLdTXVpbi0E8fdE5U6/hYs0sR/1x7N9GOmj5Lxi1V0CQTHoCsYj
Yy/KRs3LUIZqVyzE7FtxkbW5Tw/HKlTiJgX4Sza+OHBeCXcVjlSnZ668IhbNxuFR
wOWgSdzrgUBggCJ9OqY7yF4C5qNgJw12I2rrxxot5v3SsROTw97OO0qhtK5BlVBY
3+Bbb2SeKKbxo9O7UuGGwjQsdHgH2mDNAO3xF6zkEtZGKdG9A7c=
=C9jk
-END PGP SIGNATURE-

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

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

[jonmcalexander]

Sorry for the top posting, outlook and all that.

I like what you are showing here, but are you implying a shared CATALINA_HOME 
and CATALINA_BASE? I find this to be the least desirable configuration, in my 
opinion.


Dream * Excel * Explore * Inspire
Jon McAlexander
Asst Vice President

Middleware Product Engineering
Enterprise CIO | Platform Services | Middleware | Infrastructure Solutions

8080 Cobblestone Rd | Urbandale, IA 50322
MAC: F4469-010
Tel 515-988-2508 | Cell 515-988-2508

jonmcalexan...@wellsfargo.com


This message may contain confidential and/or privileged information. If you are 
not the addressee or authorized to receive this for the addressee, you must not 
use, copy, disclose, or take any action based on this message or any 
information herein. If you have received this message in error, please advise 
the sender immediately by reply e-mail and delete this message. Thank you for 
your cooperation.


-Original Message-
From: Bill Stewart  
Sent: Thursday, August 6, 2020 10:57 AM
To: Tomcat Users List 
Subject: Re: [OT Upgrade: tomcat8w.exe //ES//example - dump Java Options and 
other information to tomcat9

On Thu, Aug 6, 2020 at 9:09 AM Christopher Schultz wrote:

I don't know if you are interested in such things, but being table to
> export a configuration from one machine to another might be useful for 
> your installer, too. Something like "deploy to server A, 
> manually-configure, tweak, test, prove" and then "copy deployment 
> configuration to servers B - Z".
>

The alternative installer doesn't export a configuration, but it does let you 
repeat an installation using command-line options to get a similar effect; e.g.:

apache-tomcat-a.b.c-setup.exe /type=core /serviceusername="domain\account"
/jvmoptions="-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT" /jvmms=2048
/jvmmx=2048 /silent /log="c:\windows\temp\tomcatinstall.log"

(all on one line of course)

For reference:

 /type="core" - installs only the core components (no docs, Manager, Host 
Manager, or examples web apps)

/serviceusername="domain\account" - runs the service using the specified 
account (and also, by default permissions are set on the install directories to 
allow this account to write to the logs, temp, and work
directories)

/jvmoptions="-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT" - tells the Java 
instance running Tomcat to trust the Windows certificate store

/jvmms=2048 /jvmmx=2048 - sets the Java memory pool sizes for the service

/silent - hands-free installation

/log="c:\windows\temp\tomcatinstall.log" - logs to the specified file

See the documentation - https://github.com/Bill-Stewart/ApacheTomcatSetup - for 
further information.

Bill

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

[Bill Stewart]

On Thu, Aug 6, 2020 at 9:09 AM Christopher Schultz wrote:

I don't know if you are interested in such things, but being table to
> export a configuration from one machine to another might be useful for
> your installer, too. Something like "deploy to server A,
> manually-configure, tweak, test, prove" and then "copy deployment
> configuration to servers B - Z".
>

The alternative installer doesn't export a configuration, but it does let
you repeat an installation using command-line options to get a similar
effect; e.g.:

apache-tomcat-a.b.c-setup.exe /type=core /serviceusername="domain\account"
/jvmoptions="-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT" /jvmms=2048
/jvmmx=2048 /silent /log="c:\windows\temp\tomcatinstall.log"

(all on one line of course)

For reference:

 /type="core" - installs only the core components (no docs, Manager, Host
Manager, or examples web apps)

/serviceusername="domain\account" - runs the service using the specified
account (and also, by default permissions are set on the install
directories to allow this account to write to the logs, temp, and work
directories)

/jvmoptions="-Djavax.net.ssl.trustStoreType=WINDOWS-ROOT" - tells the Java
instance running Tomcat to trust the Windows certificate store

/jvmms=2048 /jvmmx=2048 - sets the Java memory pool sizes for the service

/silent - hands-free installation

/log="c:\windows\temp\tomcatinstall.log" - logs to the specified file

See the documentation - https://github.com/Bill-Stewart/ApacheTomcatSetup -
for further information.

Bill

Re: Rewritten requests returning 404 in 8.5.57

[Mark Thomas]

On August 6, 2020 2:37:34 PM UTC, Barry Roberts  wrote:
>I'm having an issue very similar to this one:
>https://marc.info/?l=tomcat-user&m=159171480518941&w=2
>
>The only difference is, I'm upgrading my docker from 8.5.51 to 8.5.57.
>My config adds a parameter in the rewrite rule, so I can see in the
>access log that the rule is rewriting properly.  It just returns a
>404.
>
>I'm using the Dockerfile from here:
>https://github.com/docker-library/tomcat/blob/master/8.5/jdk11/openjdk-slim-buster/Dockerfile
>
>Except, modified to use jdk 10.
>
>Everything has been working great in 8.5.51, and still does, but if I
>upgrade to 8.5.57, all rewritten requests return 404.
>
>I haven't tried 8.5.56.  Is this a known issue with 8.5.57?
>
>Thanks,
>Barry
>
>-
>To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
>For additional commands, e-mail: users-h...@tomcat.apache.org

Minimum steps to recreate the issue with an 8.5.57 install of a standard ASF 
provided distribution?

Mark

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

Re: Connector works fine with Firefox, but not on speaking terms with Chrome!

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 8/5/20 16:39, James H. H. Lampert wrote:
> First, I did a quick SSLLabs scan on the server. That told me that
> "sslEnabledProtocols" in an SSLHostConfig was indeed wrong. And it
> told me that all simulated Chrome handshakes failed, but most other
> simulated handshakes were fine.

If you want something a little more quick-and-dirty than SSLLabs's
test (which is excellent!), you could use this tool:

https://github.com/ChristopherSchultz/ssltest

You will need to compile it; or I can sent you an executable JAR file
if you trust me.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sJY8ACgkQHPApP6U8
pFipSxAAlF0HMCYCHIbnwBF84RmlFPdqAisKsfy8y9ssNQ5pdBzadVasq2NSfVx4
OMNe+7+BWvQApKzL6VN/8joyS2JllIUDhla9Pa2LfgycvxNsy3j3nMA5PpPKipAs
8Ki1b3eNmRr+G7X4yRrccHpragvJeKmLBJz615gNxsjpOvYIwgLNwKcJH1etdpZW
RtjexJictl8KAGf/S5Gzg6ctgHoobTW1+tGohr3/U59WmGdy1rNQQbBuX9OFz3E4
K5PHmJAa7T7u+LLtw/G0SKZ6Uyk/WRrCJVLD3nSa/AmL0D/fJa+l52BMsdhsCJKG
UYE5HSq8ycU2q4ly49EW1SucT0fuBkztUBHNeCKbWH3qb/yan/7QS0ZPsBQd0uI1
mFAr+ErGkuo00sGhU2UrhSQHzQ+xhmX48HebXRWHfzC131cP3t7pYedrF/nNorbh
kPmSODePIWlIMMhbbpIvfsTB33YY/HkZGPhsUONEUltjnB71ljt/0886fFnDfFYp
XNXhTvFVzTmh4qYmXG2YkwsVTCujyBbX68niumuphvkIHhSsF6mBvwLhtDVBPBkG
zvxTamu4e/nUAhAwQeFH3dyP8iCr3MHBo+MRSHiyamU6uup0j2Uley+AoKd0ih6T
+3x3iyD4vCnO9fFRAvbfOCV5vrSviUJjcss4b6PU9BKwAWGwaiQ=
=HHU/
-END PGP SIGNATURE-

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

Re: JMX Insecure Agent.

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Manuel and Kaydo,

On 8/6/20 09:23, Manuel Dominguez Sarmiento wrote:
> JMX is usually setup on port 1099 for monitoring the JVM. It can
> be either secured, or insecure (no password, no encryption) which
> is the default configuration. If you cannot modify the app, then
> the safest bet would probably be to block access to the port with
> the system firewall (for instance, iptables on Linux).
>
> Check the following system properties for clues:
> -Dcom.sun.management.jmxremote.port=
> -Dcom.sun.management.jmxremote.password.file=
> -Dcom.sun.management.jmxremote.access.file=

+1

Unfortunately, iptables and similar can't stop someone on localhost
from hitting that interface. It turns a remote-access issue into a
local-access issue which is arguably more secure.

You might want to determine if you even need access to JMX at all.
This is usually used for remote-monitoring or remote-control of a
server. If you aren't doing those things, you may simply be able to
disable JMX entirely with no replacement.

Another option would be to disable the JMX agent and instead use
Tomcat's JMXProxyServlet from the Manager application. This has the
following advantages:

1. Configuration is easier to understand -- same as application access
control instead of weird system-property-based access control

2. Any number of users can be configured (I think more recent JVMs
allow more nuanced configuration for JMX, but Tomcat's authentication
works no matter what JVM you are using)

3. More secure: TLS config can be tweaked, can filter by IP, etc.
(everything you can do with any other application)

Hope that helps,
- -chris

> On 06/08/2020 10:13, Kaydo Bramble wrote:
>> Hi Everyone,
>>
>>
>> Our security scanner has identified an application that has "Java
>> JMX Agent Insecure Configuration" on one of our Tomcat 8.5
>> servers.  This server was setup by a vendor and I am not sure
>> what JMX is being used for or how it is setup.  Does anyone have
>> any ideas on how to resolve this?  I tried asking the vendor
>> multiple times and they have no clue since 2019.
>>
>>
>> Thanks,
>>
>>
>> Kenrick "Kaydo" Bramble
>>
>> Manager, Databases and Middleware - Enterprise Systems Office of
>> Information Technology  ka...@rice.edu |
>>  713-348-8645
>>
>> Rice University | 6100 Main St. | Houston, TX 77005
>>
>>
>>
>>
>>
>
>
> -
>
>
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/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sI0IACgkQHPApP6U8
pFiHNg//YjsFZgnQe/+U0u3K89zFJVX067w3J+Tsg9a62fxWR8dZuNnEqkmNDxba
v34iCyv0jqLvVwT+JigYmL3DJx52vRvZiZ6k7QCEeNj9fZV4ISf3IAuSqbqd6ZAH
2bQr5FKosF1Fc1RbA7Rm26hDKniEUXTHvJsnaq8IcGUjaqYsqdju0VMLz/WDJBI6
Iclvq+0IMBfbvl9eiIg7PWwx9hpQ4ed1AHJT3phxAmV3MPltejvtxNDOn3/OyhpI
Xm7b6Pk/uE3gcibt9rb4H6mHorINFO74nhjPAjyMuXkAC5FOCwdXe3JepQ7/Rhxh
t9W5q7sxrpxUB66Y/gHaPbMRIvWH2JPzQS92o+kp8/CAWvFAZmO5JIInaouItynm
VWwJ9yFIdraZwzsxYEIFg8/Cfp3BANDwHvR3GoP1KQBQllnTc2X3AWS2ncS19mEJ
MBhRvIAnZ/ZFOxPBZhlpnVuZ/81UUsAfE6B3xQywEk03DHhRWB7FAwOeYFxREt02
U1+lGNG3OuZibQsvNzZb1X4aNrBXtLbkWz1zBMran3/32rRoZ8LY2uF8tnMx5egs
iMamMDFY2q/x5uL0yEyay959vsHvjVZVfR5mIsgL55u+5qDkKrP1NJ8QkwokWgUO
Jo0QEkx1/TZFWNZ3xC1Kua5KNMYWRC0NI5Cb1rr44VRMJCoj1GI=
=oyfp
-END PGP SIGNATURE-

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

Re: Date of EOL and EOS for Tomcat8.5

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Trae,

On 8/6/20 09:14, Trae McCombs wrote:
> Correct me if I'm wrong but 8.5 is really just a forked 9.x so
> wouldn't they both EOL roughly at the same time?

While the history of 8.5 is true, the conclusion is likely not.

The Tomcat committers generally support 3 versions of Tomcat
concurrently. When Tomcat 10.0 is released stable (and it's pretty
stable right now, actually), Tomcat 7 will be EOL'd. That's why the
EOL date for Tomcat 7 has already been announced, because 10.0 stable
is expected soon.

At that time, we'll have 10.0, 9.0, and 8.5 in active support until
it's time for 11.0 at which point we'll do the same process by
announcing 8.5's EOL and so on.

> Also, this question must get asked a lot because I know I asked it
> and I think one other person before this gentleman did.

I think we are pretty good about announcing EOL dates well in advance
for Tomcat versions. If there isn't an EOL-date published, then there
isn't one! :)

Thanks,
- -chris

> On Thu, Aug 6, 2020 at 4:35 AM Martin Grigorov
>  wrote:
>
>> Hi,
>>
>> On Wed, Aug 5, 2020 at 5:59 PM Rajat Gupta
>>  wrote:
>>
>>> Hi,
>>>
>>> Please let us know the date of End Of Service and End Of Life
>>> for Tomcat *8.5*
>>>
>>
>> It is not known yet. At the moment there is a date set only for
>> 7.0.x: https://tomcat.apache.org/tomcat-70-eol.html Newer
>> versions will live several years longer.
>>
>>
>>> Thank you!
>>>
>>
>> Welcome! You have missed to add few mailing lists in CC!
>>
>>
>>>
>>> Best regards, Rajat Gupta
>>>
>>
>
>
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sIboACgkQHPApP6U8
pFg/OA//SEOHI+6ZOnMnf8WH02YkoO9zCg57rYJ5TYd02oduJk4QbOsDHLD0gGmq
00pZQi4Ip814ljW2FhlYDzXvM5uF73uWnf1Yt7iku36YZJcDTBX+vWa8i3Yv3bq6
iez10X+lS+xtx56mcgDk9yPWadsOkngzwhGxG5jgVCYLV5v50l6uuS4V3Cz88oSW
eVfNZyMrhvVU9jrYWxvsarzLYol4GmgC+/DfM4UjQzIuVLA0rQU7apCpIQU0LRqS
ys5lJIBdBRsbz0zkR4x9637hq6U5WLb2j6RKEyG3GmPgQMpE67Ma2/rwbgEMROz+
8lsnHl6gaErXgKbZ9P1RXDsdQ9QH0ldii5a6kUDLB4o5A4s/W4obL8rs6wkPrYhD
B00WZZXR7Vn2Fxpc+RjHWqc3bqb58eX6+oYEyYKbqrHZ2JEGrhu1ddZS0iENpJCz
y7RKwGsFLV8H2K9gcOGtmC6cgBKZz5kr7Mc4pqveXqlYVfDIPBeF84eHUMlv72NM
ELeEXIEQ06KRpvyt/3AEUR6FCWy6BStEv8UMr3MaJw1XLEhHU7nhw3e8t/C7jFqR
VJr/ktGJXOzJVD/0X0QTj18jqOoeTnajbdohrHQaxouQfshLWTT7umL7JGRsiO53
WB01ub4QcVQBaSeTWPk9fT2qJ3wnBNh4VLG3eCeZfTfKmXZLr7I=
=p7y6
-END PGP SIGNATURE-

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

Re: Vulnerability on Apache Tomcat Default Files

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


Fang,

On 8/5/20 22:16, FANG YAP wrote:
> Did that as well, but the scanner still flagged but it is to say is
>  a false positive result in their scan?
Well, they are complaining that Tomcat is revealing its version number
(right?). That's not a false-positive. It's just ... I guess being
picky. I get it: it's best not to reveal anything.

But if their scanner is still finding it, you aren't done yet.

Can they tell you what request causes this "failure" to occur? Maybe
you fixed 404s but not 400s?

Try making a request like this:

$ telnet localhost 8080
GET /foo HTML/4.0
[newline]
[newline]

See what comes back. That should come back as a 400 Bad Request and it
might include Tomcat's version information, etc.

- -chris

> On Wed, 5 Aug 2020, 04:21 Christopher Schultz,

> wrote:
>
> Fang,
>
> On 8/3/20 23:10, FANG YAP wrote:
 I have an issue on the subject mentioned as the vulnerability
 scan flagged out.

 Plugin: 12085 Plugin Text: Apache Tomcat Default Files
 Protocol: TCP Port: 8080

 Apache Tomcat 8.5.55 (x64-bit machines)

 In my app folder (located in the webapp folder) I already had
 the necessary error pages. Also indicated the error jsp file
 in the app's web.xml. How to know what should be shown when
 they(user) enter the wrong site for tomcat?

 Should it be showing this page below or it should show my
 custom error page set in app's web.xml? HTTP 404 No Found The
 webpage cannot be found.. Most likely causes:... - There
 might be a typing error in the address - If you clicked on a
 link, it may be out of date

 What you can try: .
>
> This doesn't look like a vuln to me. Your scanner is being
> overzealous.
>
> But if you want to replace the 404 Not Found page when you request
> /noapp and your application is deployed to /myapp then you can't
> fix the problem in "myapp". You have to make other arrangements.
>
> The easiest thing to do is deploy a ROOT application with all
> errors (including 404) pointing to a custom error page. You can do
> this in your ROOT application's WEB-INF/web.xml file.
>
> -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/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sH7QACgkQHPApP6U8
pFjvkBAAgYz1A1h3Doge7eQXBX04+fOnmg70Dpyj4wCZn5KYyGVD15AYTmNBMgD9
VUOfOQ0TpMnoz+A4KiTovfh9sZL0zk+3iXbzwOLv3WD6XvkAM7KvX9YClASMHZeE
juk/jfcD7J5Af1y+vSkxB8CtrMba2SkouMkRmxwxF9aZzjbHpGFilZ/fNwzSxS5p
npoLpl789kwcopyQy5V21fMgUaCvEtWPcnvZ6T6O59NhRHNAWFFQw00yZS0SUd34
jg7UuojpTn5a+tZXwpPYk93vXoEEkuwla4zoD9zgqMBIqZUL4NXDcdGpUNFvRSke
k8ZS4FMfoahX8RCLD5Sacybtn2qgV5h53ADUY2SXC2mP6lETnhcx7TF/b6Wf4bnK
fPyDCpQw+BN36KWibjLjvMXd7z+SvG7LlBngpn6DthQQWorTomXxRHSvPYXO7W1S
ALVc43cFe0Zv6+RdzJIQd5SKc861+jPNJwWfECfQ8yM4uiXXLj86BtBjETVDnbpx
zOLbnTHBzSCHZNK+HfZmIbTbq8Jj/StQNdnoOc4CDCBOU77U3YOHeVWmN5FCwN5L
gz++VTYAHvWZ9I6ZB5/5+7DRC4ug219uQr6IUO+POsxlFbLu8mV85vJqZ6AWX8vz
Dzch6xmPycXeZFADDgreycFNY9KY+rK/f2i/U3uhaUFw8t+8A2M=
=Ux+M
-END PGP SIGNATURE-

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

Re: Weirdness going on with Tomcat on an AWS instance

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

James,

On 8/4/20 20:20, James H. H. Lampert wrote:
> I am once again attempting to get our development AWS box switched
> over to Let's Encrypt.
>
> This time, I've managed to get the httpd server working with the
> Let's Encrypt cert.

This is far easier than doing it with Tomcat (unfortunately for us).
Before you go too much farther: why not just use httpd and be done
with it?

And if you are going to AWS, you could use an AWS application load
balancer and free auto-renewing certificates from AWS. If you don't
trust AWS's networking to isolate your traffic from lb -> worker
nodes, you can use self-signed certificates with large expiration
dates or something like that.

Just an option for you.

> And this time, I've even managed to get Tomcat 8.5 to use it
> without crashing on takeoff. It's not yet on speaking terms with
> Chrome, but Firefox can access it just fine. And that's when I
> noticed the weirdness:
>
> The mere act of spinning up a spot instance from last night's
> backup caused Tomcat to update itself to the latest version (from
> 8.5.40 to 8.5.57).

That's ... unusual. I can assure you that neither Tomcat nor any Linux
distro I know would auto-upgrade anything like that. Sure you don't
have anything like that installed after-market?

> This would not be a bad thing in and of itself, except for two
> side effects: First, the default ROOT context was overlaid onto our
> ROOT context!

Wah wah.

> Second, Manager was disabled!

Wah wah.

Are you using "split" CATALINA_HOME and CATALINA_BASE?

> I spun up a new spot instance, the same way I did the one I'm using
> for my experiments, and sure enough, the ROOT context was changed:
> eleven files were added, and an undetermined number were changed.
>
> The other contexts appear to all be there, but the "examples"
> context, which we remove from all our working Tomcat installations,
> was added back in.
>
> But our server.xml appears to be completely intact, and so does
> our tomcat-users.xml.
>
> Yet, as I said, Manager is disabled.
>
> Can anybody shed any light on what happened?

Try this:

1. Get your server into a state with the "old" version of Tomcat.

2. Take a snapshot so you can get back here (or prepare to trash the nod
e)

3. Do a "chown -R root:root /path/to/tomcat"

4. Do a "chmod -R a= /path/to/tomcat5

5. Relaunch the instance and look for errors

That might still not do anything if whatever process is upgrading
Tomcat is running as root and "fixes" everything.

You could also look in /etc/init.d/* for interesting things, or
/etc/rc.local, or anything in /etc/systemd depending upon what flavor
of Linux you are running. Those places have scripty-like things which
usually get run on startup. Maybe:

$ grep -i tomcat $( find /etc -type f )

?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sHxgACgkQHPApP6U8
pFhHJQ//WErtFN1kVlMbSQqtNjyYbhfsv7V8CKCYXpsAJ6wAOjIflE2sf3t391s1
0L4uIgFZZWsnPyB96bdzr6lOf4swfPWCwK+thzqcm+vrzPdgFPiwxwL/rhVn99Zf
RxQcC8kgjfI6L9GfDS/m3qJYLMYH+w8+bUn3mlZYCX7GODvmQ/96YE+HMiados/O
XVuGxkDEQMHXL01mqo8NLGTTG2q3FnrSprEAVaxNYV6P3hoQNbcxBDEBS3rS9SXf
y4hTbFm8RtaA73RS5lllh5NTRrM+k5ed6K1Nj4FGwVzHKyXcBdqV7RIKi0bJH4Z0
I/W8GcVtqv5EBS/Ox++yo3yjSIfSv1doOgnQ1wrDxMSDxmUUjhQITR4XF66/HE7H
riD6rIsyIymXKfpbCEnO+EpsnmNJz1sVtP7oWlMiN9TqIoQDKXNMBexYyjGVBN0I
1Mpsl0DvkzS7AqBCUpsMyFpdJr4qVjCIxfPaqV4b56C0QdOWhWDAnz2TKifyS8Dn
+pgU9iL3tWaTi0NL3i2a3ugQHh0BCrgRmM21FBf6bQVeJHSzZ4lvRkRon6q+di0C
7ECztmifIqaNnp4QlCg2s0TzAAyBUw0m3r+Vr61cPBSeU5G3CsXEn+lT/ZZ9rpQe
QbrzFSG+glTiq/OGUFp0AL6tLYiLLSeUlPjxHOB9aXHHiOgcxSc=
=rd2M
-END PGP SIGNATURE-

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

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

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Bill,

On 8/4/20 18:59, Bill Stewart wrote:
> On Tue, Aug 4, 2020 at 4:01 PM Christopher Schultz wrote:
>
> I have a client who runs our product on Windows (we usually run it
> on
>> Linux) and there are 2-4 separate Tomcat-based services on each
>> node, so they have "Tomcat 8.5.x for FOO", "Tomcat 8.5.x for
>> BAR", etc. in their service descriptions. Can they use your
>> installer to upgrade just one of those with a new Tomcat
>> version?
>>
>
> The alternative installer can only upgrade Tomcat instances it
> installs. (It can't upgrade instances installed using Apache's
> installer or manual installations; it doesn't know about those.)
>
> The process in your case would be something like this:
>
> 1. Document the Tomcat service installation details for the
> instance you want to replace and back up its config files.
>
> 2. Remove it (reverse whatever process you used to install, whether
> Apache installer, manual, etc.).

Oh, I wasn't expecting to be able to upgrade the official Tomcat
installer's services. But this is good information for anyone to have.

> 3. Install using alternate installer; e.g.:
>
> apache-tomcat-a.b.c-setup.exe /instance="FOO"
>
> 4. Update the config files, copy application server files, etc.
>
> See the documentation -
> https://github.com/Bill-Stewart/ApacheTomcatSetup - for details.
> (Without /instance it installs a default instance - i.e., default
> directory of "\Program Files\Apache Tomcat", "Apache Tomcat" as
> the service name, etc.)
>
> To upgrade (in general):
>
> 1. Touch (update timestamps of) config files you don't want the
> installer to overwrite.
>
> 2. Run the above install commands with the new version of the
> installer. Don't forget the /instance parameter if you used it to
> install initially (otherwise, the installer will install or upgrade
> the default instance).
>
> Note that each instance installed using the alternate installer
> (default or otherwise) installs to a separate directory and appears
> as a separate entry in the Windows "installed application" list.
> (This is typically the expected behavior for application
> installations on Windows machines.)

Yes, this is exactly what I'd expect.

> I certainly don't claim that the alternative installer is suitable
> for all applications and configurations, but for fairly common use
> cases on Windows machines, the two-step upgrade process noted above
> (I think) is pretty simple.

Definitely. I remember having to upgrade these for my client once and
it was a PITA. We really only do it each time we upgrade Tomcat to a
new major version (when we went from 8.0 -> 8.5). It was a pain
because of all the copy/pasting which would definitely be solved
either with your installer or with a new "dump config to script"
feature on Tomcat's installer.

I don't know if you are interested in such things, but being table to
export a configuration from one machine to another might be useful for
your installer, too. Something like "deploy to server A,
manually-configure, tweak, test, prove" and then "copy deployment
configuration to servers B - Z".

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8sHQ8ACgkQHPApP6U8
pFiEOQ//a4q36Z4zt61C3rgmrXrPTTHfPKi+z+4s5EKvnHGx76kOCM8BugetuDA9
AAsOdU28uOqdsi2t2oLbnEluu3Xy7StS7vakIksH38Vanuhwu1vkTK6hwweeU+fW
JHbG7tIt3AllX8PDqFwE0LXgDOeJ8pRAI6Y2fJUDaPXM7KgmxpifeP0cFxt0N9Qx
/ZH7/VWLs/PbkB/mCZSd8OgFpal7fcDocQfvisOnu/6wGQrYU1z9p56xjaOBLDpc
jSMRCRQUtsSbsWOKmm+SVx15RU5QK0z7S5bzjcPI/Kce6mdOM3hqQUuqM2xcoKwg
lP3M+SvDt1kjtLFp/FEgr1hm6kPDOf2Jb0mV1Zq+2LNaCX1cowAYA2NFdDb7fX/o
XW8zEztINlj9RJZpas15lxameUdjSf5GUWqOqtm9vwj6BIEq55FDBbGMKrSRbP2Q
7GiYI4amHzZgr36hF87UnW65fW+p1eMq03b7dI5mrydcYYGGPUPLzfPv/Ho/EZuR
I1nwYWRzZ9RaiP4QPOthewSiFlDlE21l1zZBqQxNUxWh50BvItzJ1NhGlVQPHoKh
H9AV0+k+BrRLAejHGoG8b04pFI7XHo12LIj6joA+6MUBmioIzy43rKerx1zbojA/
gTN0UD5QR8CqhhelDpOIfpaBnGhzoE93agRMcRFeD2wSrh7OxoM=
=WvXy
-END PGP SIGNATURE-

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

Re: Date of EOL and EOS for Tomcat8.5

[Mark Thomas]

On August 6, 2020 1:14:26 PM UTC, Trae McCombs  wrote:
>Correct me if I'm wrong but 8.5 is really just a forked 9.x so wouldn't
>they both EOL roughly at the same time?

No.

Every major Tomcat version is a fork from the previous version going back to at 
least 4.1.x

The Tomcat teams stated support policy (which apart from an addition to address 
the Java EE / Jakarta EE transition) has been essentially the same since around 
5.5 x (possibly earlier) is:

- major versions if Tomcat are aligned with the Servlet specification 
- we will support (at least) the current and previous 2 major Tomcat versions 
(we typically end up supporting one more version during the transition to a new 
version)
- we don't produce patches, we produce new point releases that include all 
fixes to date
- we will provide at least 12 months notice before we EOL any major version
- in addition to the above, we will support a version of Tomcat that supports 
Java EE 8 for as long as the community has a requirement for it.

>Also, this question must get asked a lot because I know I asked it and
>I
>think one other person before this gentleman did.

We should probably put some version of the above on the Tomcat website. We 
might need to rejig things a bit as historically we have focussed on the EOL 
announcements.

Mark


>
>Thanks!
>Trae
>
>On Thu, Aug 6, 2020 at 4:35 AM Martin Grigorov 
>wrote:
>
>> Hi,
>>
>> On Wed, Aug 5, 2020 at 5:59 PM Rajat Gupta 
>wrote:
>>
>> > Hi,
>> >
>> > Please let us know the date of End Of Service and End Of Life for
>Tomcat
>> > *8.5*
>> >
>>
>> It is not known yet.
>> At the moment there is a date set only for 7.0.x:
>> https://tomcat.apache.org/tomcat-70-eol.html
>> Newer versions will live several years longer.
>>
>>
>> > Thank you!
>> >
>>
>> Welcome!
>> You have missed to add few mailing lists in CC!
>>
>>
>> >
>> > Best regards,
>> > Rajat Gupta
>> >
>>


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

Rewritten requests returning 404 in 8.5.57

[Barry Roberts]

I'm having an issue very similar to this one:
https://marc.info/?l=tomcat-user&m=159171480518941&w=2

The only difference is, I'm upgrading my docker from 8.5.51 to 8.5.57.
My config adds a parameter in the rewrite rule, so I can see in the
access log that the rule is rewriting properly.  It just returns a
404.

I'm using the Dockerfile from here:
https://github.com/docker-library/tomcat/blob/master/8.5/jdk11/openjdk-slim-buster/Dockerfile

Except, modified to use jdk 10.

Everything has been working great in 8.5.51, and still does, but if I
upgrade to 8.5.57, all rewritten requests return 404.

I haven't tried 8.5.56.  Is this a known issue with 8.5.57?

Thanks,
Barry

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

Re: JMX Insecure Agent.

[Manuel Dominguez Sarmiento]

JMX is usually setup on port 1099 for monitoring the JVM. It can be 
either secured, or insecure (no password, no encryption) which is the 
default configuration.
If you cannot modify the app, then the safest bet would probably be to 
block access to the port with the system firewall (for instance, 
iptables on Linux).


Check the following system properties for clues:
-Dcom.sun.management.jmxremote.port=
-Dcom.sun.management.jmxremote.password.file=
-Dcom.sun.management.jmxremote.access.file=

- Manuel Dominguez Sarmiento

On 06/08/2020 10:13, Kaydo Bramble wrote:

Hi Everyone,

  


Our security scanner has identified an application that has "Java JMX Agent
Insecure Configuration" on one of our Tomcat 8.5 servers.  This server was
setup by a vendor and I am not sure what JMX is being used for or how it is
setup.  Does anyone have any ideas on how to resolve this?  I tried asking
the vendor multiple times and they have no clue since 2019.

  


Thanks,

  


Kenrick "Kaydo" Bramble

Manager, Databases and Middleware - Enterprise Systems
Office of Information Technology
   ka...@rice.edu |   713-348-8645

Rice University | 6100 Main St. | Houston, TX 77005



  






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

Re: Date of EOL and EOS for Tomcat8.5

[Trae McCombs]

Correct me if I'm wrong but 8.5 is really just a forked 9.x so wouldn't
they both EOL roughly at the same time?

Also, this question must get asked a lot because I know I asked it and I
think one other person before this gentleman did.

Thanks!
Trae

On Thu, Aug 6, 2020 at 4:35 AM Martin Grigorov  wrote:

> Hi,
>
> On Wed, Aug 5, 2020 at 5:59 PM Rajat Gupta  wrote:
>
> > Hi,
> >
> > Please let us know the date of End Of Service and End Of Life for Tomcat
> > *8.5*
> >
>
> It is not known yet.
> At the moment there is a date set only for 7.0.x:
> https://tomcat.apache.org/tomcat-70-eol.html
> Newer versions will live several years longer.
>
>
> > Thank you!
> >
>
> Welcome!
> You have missed to add few mailing lists in CC!
>
>
> >
> > Best regards,
> > Rajat Gupta
> >
>


-- 
All labor that uplifts humanity has dignity and importance and should be
undertaken with painstaking excellence.
- Martin Luther King, Jr.

JMX Insecure Agent.

[Kaydo Bramble]

Hi Everyone,

 

Our security scanner has identified an application that has "Java JMX Agent
Insecure Configuration" on one of our Tomcat 8.5 servers.  This server was
setup by a vendor and I am not sure what JMX is being used for or how it is
setup.  Does anyone have any ideas on how to resolve this?  I tried asking
the vendor multiple times and they have no clue since 2019.  

 

Thanks,

 

Kenrick "Kaydo" Bramble 

Manager, Databases and Middleware - Enterprise Systems
Office of Information Technology
  ka...@rice.edu |   713-348-8645 

Rice University | 6100 Main St. | Houston, TX 77005



 

Re: Date of EOL and EOS for Tomcat8.5

[Martin Grigorov]

Hi,

On Wed, Aug 5, 2020 at 5:59 PM Rajat Gupta  wrote:

> Hi,
>
> Please let us know the date of End Of Service and End Of Life for Tomcat
> *8.5*
>

It is not known yet.
At the moment there is a date set only for 7.0.x:
https://tomcat.apache.org/tomcat-70-eol.html
Newer versions will live several years longer.


> Thank you!
>

Welcome!
You have missed to add few mailing lists in CC!


>
> Best regards,
> Rajat Gupta
>