Re: Red Hat / CentOS specific question about certificates

[Daniel Savard]

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. It is up
to you to handle the certificates when they expire unless you have some
other automated way to renew them. Normally, the cacerts file distributed
with Java is a JKS formatted trust store and the certificates it contains
will eventually expire. That's why when Java is updated you may get an
updated cacerts file as well. If you put your own certificates in that file
and it gets updated when Java is updated, obviously you will lost your
certificates. Just make a copy and put your certificates in the copy. In
fact, you may not need the original file at all if only self-signed
certificates are involved. All the certifications authorities in the file
are then useless to you.

Regards,
-
Daniel Savard

Red Hat / CentOS specific question about certificates

[Darryl Philip Baker]

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
Distributed Application Platform Services
Northwestern University
1800 Sherman Ave.
Suite 6-600 – Box #39
Evanston, IL  60201-3715
darryl.ba...@northwestern.edu
(847) 467-6674

Re: Probelm with shutdown script

[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

[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