Re: Tomcat 8.5.37 is automatically redeploying apps on every Saturday

2021-10-15 Thread Darryl Philip Baker
On 10/15/21, 10:05 AM, "jonmcalexan...@wellsfargo.com.INVALID" 
 wrote:

> -Original Message-
> From: Shekhar Naidu 
> Sent: Friday, October 15, 2021 7:45 AM
> To: users@tomcat.apache.org
> Subject: Tomcat 8.5.37 is automatically redeploying apps on every Saturday
> 
> Hi all,
> 
> > We are seeing a weird behavior in our new Linux environments. Since we
> >> migrated from RHEL6 to 8, we started seeing issue with tomcat. Tomcat
> >> is auto redeploying our apps on every Saturday around 12:20AM.
> >> We don’t have any schedulers running on our machines. We verified
> >> localhost_access.log and found no request to the tomcat manager to do
> >> the redeploy.
> >>
> >> The Catalina.out prints that “ContainerBackgroundProcessor” is doing
> >> the undeploy and deploy of our app.
> >> It does not print any other details like why it is doing that.
> >>
> >> We are basically out of Ideas as where to look as we have looked
> >> everything on the Linux side, crion jobs etc..
> >>
> >> Appreciate your help with this. Thank you in advance.
> >>
> >> Thank you
> >> Shekar
> >>
> > --
> Shekhar
> simplysek...@gmail.com
> shekharna...@gmail.com

I would check /etc/cron.weekly for a restart and your logrotate configuration 
to be sure there isn't a restart that happens as part of the log rotation. 

Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
4th Floor
2020 Ridge Avenue
Evanston, IL  60208-0801
darryl.ba...@northwestern.edu
(847) 467-6674 




Re: Checksum Validation of Release 9.0.53 on a Mac

2021-09-23 Thread Darryl Philip Baker
As I thought I was doing things wrong, thanks.


Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
4th Floor
2020 Ridge Avenue
Evanston, IL  60208-0801
darryl.ba...@northwestern.edu
(847) 467-6674 
 

On 9/23/21, 10:03 AM, "Chris Cheshire"  wrote:


> On Sep 23, 2021, at 10:48 AM, Darryl Philip Baker 
 wrote:
> 
> I am trying to download and validate the binary release 53 file name is 
apache-tomcat-9.0.53.tar.gz using openssl and the SHA256 checksum from the link 
on the download web page. The target system for the installation is running 
RHEL7. The checksums don’t match. I don’t know if I am doing things wrong or 
there is an issue. If I am doing something wrong please let me know.
> 
> Here is what I am doing and the output on my Mac (11.6):
> $ /usr/bin/openssl sha256 apache-tomcat-9.0.53.tar.gz
> SHA256(apache-tomcat-9.0.53.tar.gz)= 
7b3e456ed76b0b42d99767985dc3774b22e2388834994f8539272eb7c05ab6fd
> $
> 
> The displayed checksum from the link on the download page is:
> 
ee731b2d0c3ab7e14fa924dcb8d598707cedf714c9ce1f2c2d907a1fd51e26f7eec1343c3dc39e240ff64dac2e0213f154d23e5f94a430f429165b5df51f786f
> 
Darryl,

The checksums are pgp and sha512.

On my Mac I used

$ shasum -a 512 apache-tomcat-9.0.53.tar.gz

and the checksums match.

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



Checksum Validation of Release 9.0.53 on a Mac

2021-09-23 Thread Darryl Philip Baker
I am trying to download and validate the binary release 53 file name is 
apache-tomcat-9.0.53.tar.gz using openssl and the SHA256 checksum from the link 
on the download web page. The target system for the installation is running 
RHEL7. The checksums don’t match. I don’t know if I am doing things wrong or 
there is an issue. If I am doing something wrong please let me know.

Here is what I am doing and the output on my Mac (11.6):
$ /usr/bin/openssl sha256 apache-tomcat-9.0.53.tar.gz
SHA256(apache-tomcat-9.0.53.tar.gz)= 
7b3e456ed76b0b42d99767985dc3774b22e2388834994f8539272eb7c05ab6fd
$

The displayed checksum from the link on the download page is:
ee731b2d0c3ab7e14fa924dcb8d598707cedf714c9ce1f2c2d907a1fd51e26f7eec1343c3dc39e240ff64dac2e0213f154d23e5f94a430f429165b5df51f786f

Darryl Baker, GSEC  (he/him/his)
Sr. System Administrator
Distributed Application Platform Services
Northwestern University
4th Floor
2020 Ridge Avenue
Evanston, IL  60208-0801
darryl.ba...@northwestern.edu
(847) 467-6674



Handling Upgrades

2020-09-14 Thread Darryl Philip Baker
Until recently most of our Tomcat installations were using the Red Hat 
distributed version. A version of Tomcat7 with Red Hat backporting security and 
important break fixes. Red Hat has moved their redistribution of Tomcat to 
another package other than the OS. A package that it has been decided not to 
buy. This means I have to support a number of applications that have upgraded 
to Tomcat9 and are using the Apache-Tomcat binary distribution. This presents 
me with a problem of how to remain current for security and break-fix updates 
without spending a lot of people’s time, mine included, regression testing 
applications.

Is there a long-term support version (LTS) where only break-fix and security 
changes are made, and feature enhancements go into the next LTS?

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: Red Hat / CentOS specific question about certificates

2020-08-29 Thread Darryl Philip Baker
I will argue that you can use self-signed certificates in production if and 
only if you own and fully control both servers engaged in transaction as well 
as all of the connection fabric between the servers. If these conditions are 
true and someone can execute a man-in-middle attack, I will assert that your 
environment are already so compromised the attack is almost meaningless. On the 
other hand, using a self-signed certificate with an expiry of greater than 398 
days in a situation as this means that you can free up people's time to do 
other work other than maintaining a hidden certificate. And setting up 
automation to renew said certificate such as this, adds an increased level of 
complexity as well as an additional point of failure to the equation.


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
 

On 8/28/20, 7:47 PM, "Daniel Savard"  wrote:

Le ven. 28 août 2020 à 17:19, Darryl Philip Baker <
darryl.ba...@northwestern.edu> a écrit :

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


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



Red Hat / CentOS specific question about certificates

2020-08-28 Thread 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



Tomcat CVE watch

2020-07-25 Thread Darryl Philip Baker
We have switched from using the Red Hat supplied version of Tomcat to the 
Apache supplied binary distribution. My management would like me to follow any 
CVE related to Tomcat. I am wondering if there is a mailing list, I can 
subscribe to that will give me just those items.

I should be following all the CVEs but there are not enough hours in the day to 
do that and stay on top of my assigned duties.

This is on top of designing an update cycle that we can make work. There are 
not enough people cycles to install and regression test every point release 
across every application we have using Tomcat.

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: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-05-01 Thread Darryl Philip Baker
On 5/1/20, 5:07 PM, "André Warnier (tomcat/perl)"  wrote:
   
 I think you may have gotten everyone confused now because

1) you cannot have 2 different tomcat installations under the same 
directory (/opt/tomcat in your above explanation)

I've used this style of parallel installation before.

2) previously, you wrote that the error the two in one case was that you 
got back a 404 error.
Now you are saying that the browser is just waiting and "not returning".

Yes, the results have changed. As I have tried the different 
things suggested.

3) in the diff output below, it seems that you have a line like

 >>   worker.worker1.secret="false"

in one of the "server.xml" files (although it appears to be part of a 
comment).
That is not where such a line belongs.
I Just moved the line out of the syntax block and commented it 
out to keep track of what I have tried in the block below.

Can you be more precise in exactly describing your installation, how you 
are starting one 
tomcat or the other, how you switch between them, and what happens ?

Both installations are in /opt/tomcat. One is in 
/opt/tomcat/apache-tomcat-9.0.20 and the other in 
/opt/tomcat/apache-tomcat-9.0.34. /opt/tomcat/latest is a symbolic link 
I can point to either of the installations. The reason for 
putting the workers.properties file in the apache-tomcat9.0.XX tree is that 
Apache HTTPD can point 
at the workers.properties file as 
/opt/tomcat/latest/conf/jk/workers.properties and the systemd script can use 
the "latest" path to control tomcat. 
That way I can switch between the versions with no 
modifications to Apache HTTPD or the systemd files, just by replacing the 
symbolic link and restarting.

While writing this up I realized I for got one other 
customization is the setenv.sh file. It is the same in both installations but 
maybe it has to be different for the 9.0.34 installation.
It contains -- JAVA_OPTS="$JAVA_OPTS 
-Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true" and I am 
using -- openjdk version "1.8.0_242"

P.S. I would recommend moving your workers.properties file away from the tomcat 
directories, and into some httpd configuration directory, because that file 
has in fact 
nothing to do with tomcat. It is read by the mod_jk module, which is a 
module running in httpd, not tomcat.

I will decline the suggestion as it works for the simple 
flipping between versions as explained above.

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
 

On 5/1/20, 5:07 PM, "André Warnier (tomcat/perl)"  wrote:

On 01.05.2020 20:32, Darryl Philip Baker wrote:
> Continuing the investigation:
> 
> I have the two tomcat installation in /opt/tomcat. Apache HTTPD 
references the worker file using a path that has a symbolic link that "latest" 
I can switch to point to either installation of tomcat. The workers file is 
defined in httpd.conf as "JkWorkersFile 
/opt/tomcat/latest/conf/jk/workers.properties"
> 
> Tomcat 9.0.20 works as expected. Tomcat 9.0.34 fails with just having the 
browser clocking and not returning.

I think you may have gotten everyone confused now because

1) you cannot have 2 different tomcat installations under the same 
directory (/opt/tomcat 
in your above explanation)
2) previously, you wrote that the error in one case was that you got back a 
404 error.
Now you are saying that the browser is just waiting and "not returning".
3) in the diff output below, it seems that you have a line like

 >>   worker.worker1.secret="false"

in one of the "server.xml" files (although it appears to be part of a 
comment).
That is not where such a line belongs.

Can you be more precise in exactly describing your installation, how you 
are starting one 
tomcat or the other, how you switch between them, and what happens ?

P.S. I would recommend moving yourt workers.properties file away from the 
tomcat 
directories, and into some httpd configuration directory, because that file 
has in fact 
nothing to do with tomcat. It is read by the mod_jk module, which is a 
module running in 
httpd, not tomcat.


> 
> Just to give you an idea of the differences in the control files:
> 
> [[root@lmsdevsyncapp7 tomcat]# diff apache-tomcat-9.0.20/conf/server.xml 
apache-tomcat-9.0.34/conf/server.xml
> 79c79
> < >  

Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-05-01 Thread Darryl Philip Baker
Continuing the investigation:

I have the two tomcat installation in /opt/tomcat. Apache HTTPD references the 
worker file using a path that has a symbolic link that "latest" I can switch to 
point to either installation of tomcat. The workers file is defined in 
httpd.conf as "JkWorkersFile /opt/tomcat/latest/conf/jk/workers.properties"

Tomcat 9.0.20 works as expected. Tomcat 9.0.34 fails with just having the 
browser clocking and not returning.

Just to give you an idea of the differences in the control files:

[[root@lmsdevsyncapp7 tomcat]# diff apache-tomcat-9.0.20/conf/server.xml 
apache-tomcat-9.0.34/conf/server.xml
79c79
<   
119d121
< address="127.0.0.1" 
[root@lmsdevsyncapp7 tomcat]# diff 
apache-tomcat-9.0.20/conf/jk/workers.properties 
apache-tomcat-9.0.34/conf/jk/workers.properties
[root@lmsdevsyncapp7 tomcat]# ls -l 
total 8
drwxrwxr-x 9 tomcat tomcat 4096 May 16  2019 apache-tomcat-9.0.20
drwxr-xr-x 9 tomcat tomcat 4096 Apr 28 11:59 apache-tomcat-9.0.34
lrwxrwxrwx 1 root   root 20 Apr 28 15:00 latest -> apache-tomcat-9.0.34
[root@lmsdevsyncapp7 tomcat]#


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
 

On 4/30/20, 5:09 PM, "Darryl Philip Baker"  
wrote:

I am trying to browse to one of the JKmount URLs in this case 
https://myserver.northwestern.edu/LmsSync/. When I point the symbolic link to 
the 9.0.20 installation, it works fine. When I point the symbolic link to the 
9.0.34 installation, it I get a 404 error.

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


On 4/30/20, 3:35 PM, "Christopher Schultz"  
wrote:

-BEGIN PGP SIGNED MESSAGE-
    Hash: SHA256

    Darryl,

On 4/30/20 07:59, Darryl Philip Baker wrote:
> I am trying to upgrade a development environment from 9.0.20 to
> 9.0.34 and I am having issues getting the tomcat-connectors-1.2.46
> (mod_jk) to work in with the new version.

Can you be more specific? What are you trying, and how is it (not)
working, specifically?

> The Apache HTTPD configuration remains unchanged the paths pass
> through a symbolic link I change to switch versions. The
> workers.properties file was copied over and is identical. I added
> the same definition for the AJP connector into server.xml. I will
> place the pieces I modified below.> Server.xml:   protocol="AJP/1.3" redirectPort="443" address="127.0.0.1"
> enableLookups="false" tomcatAuthentication="false"
> secretRequired="false" maxPostSize="10" />
>
> Workers.properties: #define 1st worker using worker1
> worker.list=worker1
>
> #set properties for the worker1 worker worker.worker1.type=ajp13
> worker.worker1.host=127.0.0.1 worker.worker1.port=8009
> worker.worker1.lbfactor=50 worker.worker1.cachesize=10
> worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1
> worker.worker1.recycle_timeout=300

At first glance, this configuration looks fine to me.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - 
https://urldefense.com/v3/__https://www.enigmail.net/__;!!Dq0X2DkFhyF93HkjWTBQKhk!ErC-A5wGkE-dmk8oRBS9gKPW7tZZ497pTwaCVibxsqDMz0KEnkBfwlQXEg7vdkyO3a5lJcl65g$
 

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6rNncACgkQHPApP6U8
pFh5nA//RMgbj+pgTSUqUq7zUaFvzEudyp3kfGDI7As7uvmE2BOwYABPtXjKniRF
2r/whNKQDu8VGOAp1JwTamPGpuNSh9pHW8KVqoTkr3Hg47E9fl86zE3a33/Gzq4G
Q72SZNmIyZtDvkf7autdSUXUeb1DX4KJcX7O42c7TzYp6APb82u/NUwDLRBD24FK
dVkMtkdoUgG19tsjLVNalGRkTgBNHC1ySIFikn0Tsd/28ApxCOtApn5Y85JxkjNh
GwoxbFXjTtGDVVq3Yo039xelALdquk9mm5BdA1UyANTcOx1s2VZozlVy1ayPMHNm
zPgqWLdhgRipAiLqDrPiE4u1R1PQ9wr/klQragHwY5LTzby8x1V7PAn4RZw0BRrt
yPCIAoI+dEnsiMRxfnVuNYHYbqMjTKlEF4M2zBKYuq6bpGKZEw8/IoK86kEAFYR5
trVt3o2uJ/qhn/34m4F30ilTXm7DR389ZaZ83nF4dihsst9aNmZuSUCZ6qEHTbNC
Tk1v7p+GxMJQwLglr63hfhNTij3zJPbZjQ9NXza7UiLYqqkzStXJX9JeUCjHmKsq
V6Ageh0STQm7zjRSsFse0QGP21anIxqmzkD6MmZE85v0Wsbe5gEzHXvGVpb5NdHe
ClWrI8H94YGG9XeZePvD2hlMNwCwATqJlev+IKk5WyPE+zI8BkM=
=NL+W
-END PGP SIGNATURE-



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



Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-04-30 Thread Darryl Philip Baker
I am trying to browse to one of the JKmount URLs in this case 
https://myserver.northwestern.edu/LmsSync/. When I point the symbolic link to 
the 9.0.20 installation, it works fine. When I point the symbolic link to the 
9.0.34 installation, it I get a 404 error.

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
 

On 4/30/20, 3:35 PM, "Christopher Schultz"  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darryl,

On 4/30/20 07:59, Darryl Philip Baker wrote:
> I am trying to upgrade a development environment from 9.0.20 to
> 9.0.34 and I am having issues getting the tomcat-connectors-1.2.46
> (mod_jk) to work in with the new version.

Can you be more specific? What are you trying, and how is it (not)
working, specifically?

> The Apache HTTPD configuration remains unchanged the paths pass
> through a symbolic link I change to switch versions. The
> workers.properties file was copied over and is identical. I added
> the same definition for the AJP connector into server.xml. I will
> place the pieces I modified below.> Server.xml:   protocol="AJP/1.3" redirectPort="443" address="127.0.0.1"
> enableLookups="false" tomcatAuthentication="false"
> secretRequired="false" maxPostSize="10" />
>
> Workers.properties: #define 1st worker using worker1
> worker.list=worker1
>
> #set properties for the worker1 worker worker.worker1.type=ajp13
> worker.worker1.host=127.0.0.1 worker.worker1.port=8009
> worker.worker1.lbfactor=50 worker.worker1.cachesize=10
> worker.worker1.cache_timeout=600 worker.worker1.socket_keepalive=1
> worker.worker1.recycle_timeout=300

At first glance, this configuration looks fine to me.

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6rNncACgkQHPApP6U8
pFh5nA//RMgbj+pgTSUqUq7zUaFvzEudyp3kfGDI7As7uvmE2BOwYABPtXjKniRF
2r/whNKQDu8VGOAp1JwTamPGpuNSh9pHW8KVqoTkr3Hg47E9fl86zE3a33/Gzq4G
Q72SZNmIyZtDvkf7autdSUXUeb1DX4KJcX7O42c7TzYp6APb82u/NUwDLRBD24FK
dVkMtkdoUgG19tsjLVNalGRkTgBNHC1ySIFikn0Tsd/28ApxCOtApn5Y85JxkjNh
GwoxbFXjTtGDVVq3Yo039xelALdquk9mm5BdA1UyANTcOx1s2VZozlVy1ayPMHNm
zPgqWLdhgRipAiLqDrPiE4u1R1PQ9wr/klQragHwY5LTzby8x1V7PAn4RZw0BRrt
yPCIAoI+dEnsiMRxfnVuNYHYbqMjTKlEF4M2zBKYuq6bpGKZEw8/IoK86kEAFYR5
trVt3o2uJ/qhn/34m4F30ilTXm7DR389ZaZ83nF4dihsst9aNmZuSUCZ6qEHTbNC
Tk1v7p+GxMJQwLglr63hfhNTij3zJPbZjQ9NXza7UiLYqqkzStXJX9JeUCjHmKsq
V6Ageh0STQm7zjRSsFse0QGP21anIxqmzkD6MmZE85v0Wsbe5gEzHXvGVpb5NdHe
ClWrI8H94YGG9XeZePvD2hlMNwCwATqJlev+IKk5WyPE+zI8BkM=
=NL+W
-END PGP SIGNATURE-



Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue [EXTERNAL]

2020-04-30 Thread Darryl Philip Baker
Thank you for your suggestions. I don't see any difference in the results. I 
think I have logging turned up all the way but nothing in the way of errors 
from Tomcat. I'm looking at HTTPD now.


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
 

On 4/30/20, 8:43 AM, "Beard, Shawn M."  wrote:

My workers is identical to yours and it works.

Here is our connector config that is working.

Might want to try removing address="127.0.0.1" and/or 
tomcatAuthentication="false"

The fix for the Ghostcat vulnerability created some config challenges on 
the ajp protocol. I'm pretty sure it’s the tomcatAuthentication you need to 
remove.





Shawn Beard
Sr. Systems Engineer
BTS
+1-515-564-2528

-Original Message-
From: Darryl Philip Baker 
Sent: Thursday, April 30, 2020 7:00 AM
To: Tomcat Users List 
Subject: Upgrading from 9.0.20 to 9.0.34 AJP connector issue [EXTERNAL]

** CAUTION: External message


I am trying to upgrade a development environment from 9.0.20 to 9.0.34 and 
I am having issues getting the tomcat-connectors-1.2.46 (mod_jk) to work in 
with the new version. The Apache HTTPD configuration remains unchanged the 
paths pass through a symbolic link I change to switch versions. The 
workers.properties file was copied over and is identical. I added the same 
definition for the AJP connector into server.xml. I will place the pieces I 
modified below.

Server.xml:



Workers.properties:
#define 1st worker using worker1
worker.list=worker1

#set properties for the worker1 worker
worker.worker1.type=ajp13
worker.worker1.host=127.0.0.1
worker.worker1.port=8009
worker.worker1.lbfactor=50
worker.worker1.cachesize=10
worker.worker1.cache_timeout=600
worker.worker1.socket_keepalive=1
worker.worker1.recycle_timeout=300

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<mailto:darryl.ba...@northwestern.edu>
(847) 467-6674

CONFIDENTIALITY NOTICE: This e-mail and the transmitted documents contain 
private, privileged and confidential information belonging to the sender. The 
information therein is solely for the use of the addressee. If your receipt of 
this transmission has occurred as the result of an error, please immediately 
notify us so we can arrange for the return of the documents. In such 
circumstances, you are advised that you may not disclose, copy, distribute or 
take any other action in reliance on the information transmitted.



Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-04-30 Thread Darryl Philip Baker
I am trying to upgrade a development environment from 9.0.20 to 9.0.34 and I am 
having issues getting the tomcat-connectors-1.2.46 (mod_jk) to work in with the 
new version. The Apache HTTPD configuration remains unchanged the paths pass 
through a symbolic link I change to switch versions. The workers.properties 
file was copied over and is identical. I added the same definition for the AJP 
connector into server.xml. I will place the pieces I modified below.

Server.xml:



Workers.properties:
#define 1st worker using worker1
worker.list=worker1

#set properties for the worker1 worker
worker.worker1.type=ajp13
worker.worker1.host=127.0.0.1
worker.worker1.port=8009
worker.worker1.lbfactor=50
worker.worker1.cachesize=10
worker.worker1.cache_timeout=600
worker.worker1.socket_keepalive=1
worker.worker1.recycle_timeout=300

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: Using AJP with 2 versions of Tomcat.

2020-04-21 Thread Darryl Philip Baker
Thank you, Christopher,

I do want to run both versions of the application and tomcat simultaneously. 
The current version of the app on using tomcat7 on the current ports 
8009/8080/8443 I don't think it has 8005 configured. I was thinking I could run 
the newer version of the app on tomcat9 using alternate ports 9009/9080/9443. 
Any reason not to? I wasn't sure if I should different path like 
myserver.example.com/tc9staging/blah or a second virtual host like 
tc9staging.example.com/blah. I do only have one network interface to work with, 
but I could add a CNAME easily. What are the pros and cons of the two methods? 

Yes, there is a workers.properties file. My predecessor used ajp13 as the name 
of the first worker so that was a bit confusing. I thought that was just an 
arbitrary string, thank you for confirming that. If I want both to work 
wouldn't the worker.list parameter look like "worker.list=ajp13,tc9staging"? 

I will rename the workers something more meaningful to help my successor just 
in case I have to leave the project. Even worker1 would have been clearer than 
using a keyword as the worker name. Then the rest of the workers.property file 
will be just the configuration for both workers, two versions of each line, one 
for each worker.

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
 

On 4/21/20, 5:29 PM, "Christopher Schultz"  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darryl,

    On 4/21/20 12:03, Darryl Philip Baker wrote:
> We currently have an application running in Tomcat7 that is
> connected to Apache HTTPD via the mod_jk plugin. I have been asked
> to get a newer version of the same application running on the same
> machine using Tomcat9. I know I will need to use alternate ports
> and paths.

Do you want to run them in parallel, or do you just want to upgrade
Tomcat underneath your application? (Or do you want to have a
"staging" version in parallel with a plan to complete migration once
you have fully tested everything?)

> I am a bit overwhelmed trying to understand how to configure the
> second Tomcat and its workers so the connect to Apache correctly.
I'm going to make a few assumptions and then continue:

1. You want to run these two Tomcats in parallel, with the same
application, on the same machine

2. You are only using one network interface (or "all" network interfaces
)

3. You have a pretty simple AJP configuration mapping httpd -> Tomcat

4. You are using a single virtual host in httpd

This should be fairly straightforward.

First, you'll need to install your new version of Tomcat somewhere
and, probably, drop your WAR file into that new version's ""webapps"
directory. (Here's where I tell you that using a "split" CATALINA_HOME
and CATALINA_BASE can be your friend, but let's keep things simple for
now. After you are all done, go and read the ""advanced" section of
RUNNING.txt to see what I mean).

When you put your WAR file into "webapps", change its name to
something like "tc9staging.war". Just as long as it's not the same
name as the original. (This will come back up, later).

Second, edit your conf/server.xml and configure all the ports:

1. The "shutdown" port (default: 8005)
2. The HTTP port (default: 8080)
3. The AJP port (default: 8009)

Don't overthink these ports. Maybe just add "1" to each one for now?

You might want to configure disabling AJP entirely and using
mod_proxy_http to connect httpd -> Tomcat. For now, let's keep your
AJP connector for simplicity.

Third, launch Tomcat and make sure that (a) there are no obvious
errors in log/catalina.out and (b) your application seems to deploy
properly.

Fourth, connect httpd -> [new] Tomcat.

In httpd.conf (or one of the files it includes, perhaps), you should
have lines like this:

  JkMount /myapp

The text "" may be almost anything. That's the "worker name" and it's
usually defined usually in a file specified by JkWorkersFile. If you
don't have a "JkWorkersFile" directive anywhere, we'll have to dig a
little deeper.

In your jkworkers.properties file, all the workers are defined. We
will need to duplicate those to create new workers pointing to the new
Tomcat. Something like this:

[existing]
worker.list=workerX
worker.workerX.type=ajp13
worker.workerX.host=localhost
worker.workerX.port=8009

We'll add a new worker called tc9staging:

worker.list=tc9staging
worker.tc9staging.type=ajp13

Using AJP with 2 versions of Tomcat.

2020-04-21 Thread Darryl Philip Baker
We currently have an application running in Tomcat7 that is connected to Apache 
HTTPD via the mod_jk plugin. I have been asked to get a newer version of the 
same application running on the same machine using Tomcat9. I know I will need 
to use alternate ports and paths. I am a bit overwhelmed trying to understand 
how to configure the second Tomcat and its workers so the connect to Apache 
correctly.

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: Novice Tomcat Admin Question - Filtering log output

2020-02-24 Thread Darryl Philip Baker
>   > The second reason is we use Splunk as a log aggregator. In Splunk

>> it is easy to filter these out when looking at the log but having

>> all these almost useless messages significantly adds to the

>> activity of the Splunk forwarder on these systems.

>I'm surprised Splunk doesn't have a "drop records matching pattern" or

>something like that, so you can just never ingest them. Maybe that

>would be a feature too easy to exploit.



Chris, that is a great idea. I don't control the aggregator and that may be 
where a filter might be configured. I will check.



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: Novice Tomcat Admin Question - Filtering log output

2020-02-21 Thread Darryl Philip Baker
On 2/21/20, 11:36 AM, "Christopher Schultz"  
wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Darryl,

On 2/21/20 12:15, Darryl Philip Baker wrote:
> I have taken over the administration of several Tomcat instances.
> A number of these are load balanced using an F5 appliance.  The
> org.apache.catalina.values.AccessLogValve log file is filled with
> the F5 polls to see if the application is alive. Under almost all
> circumstances these are useless, I would like to stop logging just
> these requests.
Dumb question: why bother removing them?

Not so dumb a question, I have 2 reasons. First when looking at the raw file on 
the server these poles from the load balancers make it hard to find the useful 
entries. The second reason is we use Splunk as a log aggregator. In Splunk it 
is easy to filter these out when looking at the log but having all these almost 
useless messages significantly adds to the activity of the Splunk forwarder on 
these systems.

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
 


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



Re: Novice Tomcat Admin Question - Filtering log output

2020-02-21 Thread Darryl Philip Baker
On 2/21/20, 11:23 AM, "M. Manna"  wrote:

Hey Darryl,

 I may be mistaken, but It seems you are probably trying to make the
logging coarser. You can take a look at conf/logging.properties for your
tomcat instances to do the adjustments of log levels.

Regards,

Thank you for your reply but no I do not want to reduce the logging level. I 
want every other access logged just not the specific target used by the load 
balancers.


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
 

 


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



Novice Tomcat Admin Question - Filtering log output

2020-02-21 Thread Darryl Philip Baker
I have taken over the administration of several Tomcat instances. A number of 
these are load balanced using an F5 appliance.  The 
org.apache.catalina.values.AccessLogValve log file is filled with the F5 polls 
to see if the application is alive. Under almost all circumstances these are 
useless, I would like to stop logging just these requests. What is the best way 
to stop these entries being written?  I’ve included a sample of the log entries.

10.0.171.163 - - [21/Feb/2020:09:04:11 -0600] "GET /MySite/isAlive.jsp " 200 112
10.0.171.162 - - [21/Feb/2020:09:04:16 -0600] "GET /MySite/isAlive.jsp " 200 112
10.0.171.163 - - [21/Feb/2020:09:04:16 -0600] "GET /MySite/isAlive.jsp " 200 112
10.0.171.162 - - [21/Feb/2020:09:04:21 -0600] "GET /MySite/isAlive.jsp " 200 112
10.0.171.163 - - [21/Feb/2020:09:04:21 -0600] "GET /MySite/isAlive.jsp " 200 112
10.0.171.162 - - [21/Feb/2020:09:04:26 -0600] "GET /MySite/isAlive.jsp " 200 112

The entry for the log file in server.xml is



Darryl Baker
Northwestern University
darryl.ba...@northwestern.edu