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
> < >  >  
> 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.proper

Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-05-01 Thread calder 
On Fri, May 1, 2020, 13:32 Darryl Philip Baker <
darryl.ba...@northwestern.edu> wrote:

> Continuing the investigation:
>
> I have the two tomcat installation in /opt/tomcat.


I assume  /opt/tomcat  is the BASE subdirectory path, where two different
versions are installed under that named BASE. something like

/opt/tomcat/tomcat9020
/opt/tomcat/tomcat9034


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"
>

So "latest" eventually points to either "20" or "34"


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

Here you state, basically, there's no response at the browser, but
eventually it should, upon timeout.

However the above statement contradicts the "404" statement below.

>

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.


This contradicts the above "no response" statement

Here's a test I always request a client to perform during troubleshooting :

"remove the redirector from the equation and test again" .. any issue
now?(ie, go to each Tomcat directly - works?   Yes? Then it's an issue
with the redirector config).

Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

2020-05-01 Thread tomcat/perl 

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
< 

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

Re: Upgrading from 9.0.20 to 9.0.34 AJP connector issue

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

Darryl,

On 5/1/20 14: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.
>
> 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.xm
l
> 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]#

Something seems fishy.

First, your workers.properties files should not have had to change at
all. Were there any changes made, there?

Second, you have a diff of the server.xml files with virtually no
changes and yet 9.0.20 did NOT have a "secretRequired" attribute
available (it was introduced in 9.0.31). So why does your 9.0.20
installation have secretRequired="false" in it?

Finally, there was another change in 9.0.31 that changed the way the
connector binds to network interfaces. Your old interface specified
"127.0.0.1" (shown in the diff) and the new one does not specify
anything (except, oddly, you quoted that in your original message as
saying it DOES have address="127.0.0.1" so it's really difficult what
is real and what is not real, here. If you aren't specifying an
"address", then you are getting whatever Java finds when it looks-up
"localhost". That will either be an IPv4 or IPv6 interface. We have
seen some problems where httpd and Java come to different conclusions
as to which interface to use. It's best to specify exactly which
interface you want to use *by IP address* and not by hostname. So, if
you want to use IPv4, then use 127.0.0.1 in both places
(workers.properties and server.xml).

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl6sj3kACgkQHPApP6U8
pFgPJQ//Su/qv/PEYohk6lzma8kiyAC2+6+zo4LsIxq2yu9SKlz357rIxstFQgfd
Zdsuhs/QHZA8elpGbo3ecMZ4BikAAFHfwmXK4fEUBqSejCcdI2VY7bBumpYPIrYG
zTaOSBfX5UNA+IgWSoQvbtUutnoGIrg+cPSR+eJz/NOl87xiM2fwWaMlZFqGw5Qv
pnEpvtfljQtTiG7TC1KX8Ys91uWoiaF8SLrqW4KGdTQpkBQwMwmUFCpS0UksTnoR
jhUqb+Wxav+sjLpazwiZP0mwCx2liVKAv4TQOOMjSHU16eQRDK81HzpeZytl9A0V
qYIl3d6+d+P6+TSW0z9t1enIp6BMcl05G9g6ONUvxMsRsTaIV5UiT5iKhUP7BRHF
D0CXphFJy+4I8LSNvrjgKt0laneSF0R8JHtH5aRdsQkalJxEr4filQXSdgcwcQ2v
GhtUU5MBe56HPijml+S5v6CZ8C7SG1UhZxeVTS0jxsrQhkCPBFCVseKq5Wfsj6v3
VAJxUBBUm2eL4APBvDB24dpqY3Uiycj2yW89vY/lG93wq8fF8F9pnra4XkAIxa2N
HwQnNO508TAHULGT9fqp7mCMnTHfKeoqtY+6I1wMOV4YS8kI1wsvMtkaBnE4pweS
2dyKGnoqEZCpkK0slXHaJXX+dttVMMKFWl/JQC5pcIvfaVAhLI0=
=J0sn
-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-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 tomcat/perl 

On 01.05.2020 00:09, 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.


Ah, here may be a clue : the 404 error page returned by Apache httpd looks significantly 
different from the 404 error page returned by Tomcat (in look). Which one are you getting ?
If you get the Apache httpd version, then the problem is that Apache httpd/mod_jk is not 
even trying to forward the call to Tomcat, and tries to map it locally to the Apache 
document space.
Conversely, if you get the Tomcat version, then it means that the call /is/ forwarded by 
httpd/mod_jk to Tomcat, but that it is tomcat somehow which does not find anything in its 
URL space that matches the forwarded link URL.




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-


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




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

Re: 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

2020-04-30 Thread Christopher Schultz 
-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-

-
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 [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.

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

2020-04-30 Thread Beard, Shawn M. 
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: AW: AW: AJP Connector issue

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

RK,

On 3/20/20 13:33, RK Ashburn wrote:
> thanks Chirs. fixed it to an real ip,

In many cases, 0.0.0.0 is basically the same as binding to the
interface which represents the outside world (e.g. eth0, etc.).

See my other reply in this thread to see what I would recommend in
terms of a secure deployment of AJP.

- -chris

> On Fri, Mar 20, 2020 at 12:40 PM Christopher Schultz <
> ch...@christopherschultz.net> wrote:
>
> RK,
>
> On 3/20/20 09:57, RK Ashburn wrote:
>>>> I have tested r successful AJP connector with apache proxy
>>>> on (tomcat 7)
>>>>
>>>> 1. For AJP connector adding  secretRequired="false" and
> address="0.0.0.0"
>>>> resolved my connectivity issue. I suspect the issue you are
>>>> having (with 403)  is more like a permissions issue on the
>>>> site the request is
> trying to
>>>> reach, than a AJP connector configuration issue.
>
> binding to "all interfaces" may work, but it's not terribly
> secure. Are you really expecting an AJP connection from anywhere in
> the world?
>
> -chris
>
>>>> On Fri, Mar 20, 2020 at 8:50 AM Fritze, Florian <
>>>> florian.fri...@irb.fraunhofer.de> wrote:
>>>>
>>>>> Just to make it clear what from my opinion the problem is:
>>>>>
>>>>> SCHWERWIEGEND [main]
>>>>> org.apache.catalina.core.StandardService.startInternal
>>>>> Failed to start connector [Connector[AJP/1.3-8011]]
>>>>> org.apache.catalina.LifecycleException: Der Start des
>>>>> Protokoll-Handlers ist fehlgeschlagen at
>>>>>
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1
05
>
>
7)
>>>>> at
>>>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:18
3)
>>>>>
>>>>>
>
>>>>>
at
>>>>>
> org.apache.catalina.core.StandardService.startInternal(StandardService
.j
>
>
ava:440)
>>>>> at
>>>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:18
3)
>>>>>
>>>>>
>
>>>>>
at
>>>>>
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.j
av
>
>
a:766)
>>>>> at
>>>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:18
3)
>>>>>
>>>>>
>
>>>>>
at
>>>>> org.apache.catalina.startup.Catalina.start(Catalina.java:688)
>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
>>>>> Method) at
>>>>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
av
>
>
a:62)
>>>>> at
>>>>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
or
>
>
Impl.java:43)
>>>>> at java.lang.reflect.Method.invoke(Method.java:498) at
>>>>> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
>>>>>
>>>>>
at
>>>>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
>>>>>
>>>>>
Caused by: java.lang.IllegalArgumentException: The AJP
> Connector
>>>>> is configured with secretRequired="true" but the secret
>>>>> attribute
> is either
>>>>> null or "". This combination is not valid. at
>>>>>
> org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.ja
va
>
>
:274)
>>>>> at
>>>>>
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1
05
>
>
5)
>>>>> ... 12 more
>>>>>
>>>>> This new "secretRequired" attribute prevents the Tomcat
>>>>> from starting flawlessly. It was first introduced with the
>>>>> Ghostcat release. So this is a wish from me to the Tomcat
>>>>> developers: Please set this new attribute not mandatory but
>>>>> optional. So that I can run the newest
> Tomcat
>>>>> without this attribute which I do now with the
>>>>> pre-Ghostcat releases.
>>>>>
>>>>> Have a nice weekend Florian Fritze
>>>>>
>>>>> -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum
>>>>> und Bau IRB Competence Center Research Services & Open
>>>>> Science Nobelstr. 12, 70569 Stuttgart, Germany Telefon +49
>>>>> 711 970-2

Re: AW: AW: AJP Connector issue

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

Jon,

On 3/20/20 13:28, jonmcalexan...@wellsfargo.com.INVALID wrote:
> Christopher,
>
> Is there an entry that can go in the AJP connector to restrict
> what
addresses it will listen to requests from? Meaning you can list the IP
addresses of the web servers?

Tomcat has no knowledge of your web servers. But presumably YOU know
where your web servers are and how they should be connecting. If they
are on different hosts, using AJP means that you are communicating
over an insecure channel over a network. Is that acceptable to you? IF
not, you need to either switch protocols (e.g. HTTPS) or tunnel AJP
through something like stunnel.

IMO, if you want to use AJP then you need to do this:

client
 |
 | HTTP
 \/
web server
 |
 | AJP-over-TLS (stunnel)
 |
 |
 \/
app server:8010
 |
 | stunnel unwraps AJP
 |
 \/
app server:8009

In this scenario, Tomcat listens on 127.0.0.1:8009 and stunnel listens
on the public interface and requires mutual TLS in order to connect.
You can also use IP whitelisting if you want to be even more paranoid.

> I know I'm top replying, but Outlook sucks with this. :-(

Just go to the bottom of the message and start typing instead of
typing at the top :)

- -chris

> -Original Message- From: Christopher Schultz
>  Sent: Friday, March 20, 2020 11:40
> AM To: users@tomcat.apache.org Subject: Re: AW: AW: AJP Connector
> issue
>
> RK,
>
> On 3/20/20 09:57, RK Ashburn wrote:
>> I have tested r successful AJP connector with apache proxy on
>> (tomcat 7)
>
>> 1. For AJP connector adding  secretRequired="false" and
> address="0.0.0.0"
>> resolved my connectivity issue. I suspect the issue you are
>> having (with 403)  is more like a permissions issue on the site
>> the request is
> trying to
>> reach, than a AJP connector configuration issue.
>
> binding to "all interfaces" may work, but it's not terribly
> secure. Are you really expecting an AJP connection from anywhere in
> the world?
>
> -chris
>
>> On Fri, Mar 20, 2020 at 8:50 AM Fritze, Florian <
>> florian.fri...@irb.fraunhofer.de> wrote:
>
>>> Just to make it clear what from my opinion the problem is:
>>>
>>> SCHWERWIEGEND [main]
>>> org.apache.catalina.core.StandardService.startInternal Failed
>>> to start connector [Connector[AJP/1.3-8011]]
>>> org.apache.catalina.LifecycleException: Der Start des
>>> Protokoll-Handlers ist fehlgeschlagen at
>>>
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1
05
>
>
7)
>>> at
>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>>
>>>
>
>>>
at
>>>
> org.apache.catalina.core.StandardService.startInternal(StandardService
.j
>
>
ava:440)
>>> at
>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>>
>>>
>
>>>
at
>>>
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.j
av
>
>
a:766)
>>> at
>>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>>
>>>
>
>>>
at
>>> org.apache.catalina.startup.Catalina.start(Catalina.java:688)
>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>>> at
>>>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.j
av
>
>
a:62)
>>> at
>>>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccess
or
>
>
Impl.java:43)
>>> at java.lang.reflect.Method.invoke(Method.java:498) at
>>> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
>>>
>>>
at
>>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
>>> Caused by: java.lang.IllegalArgumentException: The AJP
> Connector
>>> is configured with secretRequired="true" but the secret
>>> attribute
> is either
>>> null or "". This combination is not valid. at
>>>
> org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.ja
va
>
>
:274)
>>> at
>>>
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1
05
>
>
5)
>>> ... 12 more
>>>
>>> This new "secretRequired" attribute prevents the Tomcat from
>>> starting flawlessly. It was first introduced with the Ghostcat
>>> release. So this is a wish from me to the Tomcat developers:
>>> Please set this new attribute not mandatory but optional. So
>>> that I can run the newest
> Tomcat
>>> without this attribute whic

Re: AW: AW: AJP Connector issue

2020-03-20 Thread RK Ashburn 
thanks Chirs. fixed it to an real ip,





On Fri, Mar 20, 2020 at 12:40 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> RK,
>
> On 3/20/20 09:57, RK Ashburn wrote:
> > I have tested r successful AJP connector with apache proxy on
> > (tomcat 7)
> >
> > 1. For AJP connector adding  secretRequired="false" and
> address="0.0.0.0"
> > resolved my connectivity issue. I suspect the issue you are having
> > (with 403)  is more like a permissions issue on the site the
> > request is
> trying to
> > reach, than a AJP connector configuration issue.
>
> binding to "all interfaces" may work, but it's not terribly secure.
> Are you really expecting an AJP connection from anywhere in the world?
>
> - -chris
>
> > On Fri, Mar 20, 2020 at 8:50 AM Fritze, Florian <
> > florian.fri...@irb.fraunhofer.de> wrote:
> >
> >> Just to make it clear what from my opinion the problem is:
> >>
> >> SCHWERWIEGEND [main]
> >> org.apache.catalina.core.StandardService.startInternal Failed to
> >> start connector [Connector[AJP/1.3-8011]]
> >> org.apache.catalina.LifecycleException: Der Start des
> >> Protokoll-Handlers ist fehlgeschlagen at
> >>
> org.apache.catalina.connector.Connector.startInternal(Connector.java:105
> 7)
> >> at
> >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> >>
> >>
> at
> >>
> org.apache.catalina.core.StandardService.startInternal(StandardService.j
> ava:440)
> >> at
> >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> >>
> >>
> at
> >>
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.jav
> a:766)
> >> at
> >> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> >>
> >>
> at
> >> org.apache.catalina.startup.Catalina.start(Catalina.java:688) at
> >> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> >>
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
> a:62)
> >> at
> >>
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
> Impl.java:43)
> >> at java.lang.reflect.Method.invoke(Method.java:498) at
> >> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
> >> at
> >> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
> >> Caused by: java.lang.IllegalArgumentException: The AJP
> Connector
> >> is configured with secretRequired="true" but the secret
> >> attribute
> is either
> >> null or "". This combination is not valid. at
> >>
> org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java
> :274)
> >> at
> >>
> org.apache.catalina.connector.Connector.startInternal(Connector.java:105
> 5)
> >> ... 12 more
> >>
> >> This new "secretRequired" attribute prevents the Tomcat from
> >> starting flawlessly. It was first introduced with the Ghostcat
> >> release. So this is a wish from me to the Tomcat developers:
> >> Please set this new attribute not mandatory but optional. So that
> >> I can run the newest
> Tomcat
> >> without this attribute which I do now with the pre-Ghostcat
> >> releases.
> >>
> >> Have a nice weekend Florian Fritze
> >>
> >> -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum und
> >> Bau IRB Competence Center Research Services & Open Science
> >> Nobelstr. 12, 70569 Stuttgart, Germany Telefon +49 711 970-2713
> >> florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de
> >>
> >>
> >> -Ursprüngliche Nachricht- Von: André Warnier
> >> (tomcat/perl)  Gesendet: Freitag, 20. März 2020
> >> 13:34 An: users@tomcat.apache.org Betreff: Re: AW: AW: AJP
> >> Connector issue
> >>
> >> Ok, so it looks like : - the request is effectively reaching
> >> tomcat, and that it is tomcat sending back the 403 response. -
> >> the URL is "/", so presumably it is "well-formed" etc.
> >>
> >> Furthermore, according to something you wrote below, both Apache
> httpd and
> >> tomcat are running on the same Linux host.
> >>
> >> This reminds me vaguely of some issue previously (and recently)
> discussed
> >> on the list, with some request attributes which tomcat d

RE: AW: AW: AJP Connector issue

2020-03-20 Thread jonmcalexander 
Christopher,

Is there an entry that can go in the AJP connector to restrict what addresses 
it will listen to requests from? Meaning you can list the IP addresses of the 
web servers?

I know I'm top replying, but Outlook sucks with this. :-(

Thanks,


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

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

Upcoming PTO: 11/8, 11/11, 11/15, 11/22, 11/28, 11/29, 12/2, 12/6, 12/13, 12/20 
– 12/31

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: Christopher Schultz  
Sent: Friday, March 20, 2020 11:40 AM
To: users@tomcat.apache.org
Subject: Re: AW: AW: AJP Connector issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

RK,

On 3/20/20 09:57, RK Ashburn wrote:
> I have tested r successful AJP connector with apache proxy on (tomcat 
> 7)
>
> 1. For AJP connector adding  secretRequired="false" and
address="0.0.0.0"
> resolved my connectivity issue. I suspect the issue you are having 
> (with 403)  is more like a permissions issue on the site the request 
> is
trying to
> reach, than a AJP connector configuration issue.

binding to "all interfaces" may work, but it's not terribly secure.
Are you really expecting an AJP connection from anywhere in the world?

- -chris

> On Fri, Mar 20, 2020 at 8:50 AM Fritze, Florian < 
> florian.fri...@irb.fraunhofer.de> wrote:
>
>> Just to make it clear what from my opinion the problem is:
>>
>> SCHWERWIEGEND [main]
>> org.apache.catalina.core.StandardService.startInternal Failed to 
>> start connector [Connector[AJP/1.3-8011]]
>> org.apache.catalina.LifecycleException: Der Start des 
>> Protokoll-Handlers ist fehlgeschlagen at
>>
org.apache.catalina.connector.Connector.startInternal(Connector.java:105
7)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>
>>
at
>>
org.apache.catalina.core.StandardService.startInternal(StandardService.j
ava:440)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>
>>
at
>>
org.apache.catalina.core.StandardServer.startInternal(StandardServer.jav
a:766)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>
>>
at
>> org.apache.catalina.startup.Catalina.start(Catalina.java:688) at 
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:62)
>> at
>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
>> at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
>> Caused by: java.lang.IllegalArgumentException: The AJP
Connector
>> is configured with secretRequired="true" but the secret attribute
is either
>> null or "". This combination is not valid. at
>>
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java
:274)
>> at
>>
org.apache.catalina.connector.Connector.startInternal(Connector.java:105
5)
>> ... 12 more
>>
>> This new "secretRequired" attribute prevents the Tomcat from starting 
>> flawlessly. It was first introduced with the Ghostcat release. So 
>> this is a wish from me to the Tomcat developers:
>> Please set this new attribute not mandatory but optional. So that I 
>> can run the newest
Tomcat
>> without this attribute which I do now with the pre-Ghostcat releases.
>>
>> Have a nice weekend Florian Fritze
>>
>> -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum und Bau 
>> IRB Competence Center Research Services & Open Science Nobelstr. 12, 
>> 70569 Stuttgart, Germany Telefon +49 711 970-2713 
>> florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de
>>
>>
>> -Ursprüngliche Nachricht- Von: André Warnier
>> (tomcat/perl)  Gesendet: Freitag, 20. März 2020
>> 13:34 An: users@tomcat.apache.org Betreff: Re: AW: AW: AJP Connector 
>> issue
>>
>> Ok, so it looks lik

Re: AW: AW: AJP Connector issue

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

RK,

On 3/20/20 09:57, RK Ashburn wrote:
> I have tested r successful AJP connector with apache proxy on
> (tomcat 7)
>
> 1. For AJP connector adding  secretRequired="false" and
address="0.0.0.0"
> resolved my connectivity issue. I suspect the issue you are having
> (with 403)  is more like a permissions issue on the site the
> request is
trying to
> reach, than a AJP connector configuration issue.

binding to "all interfaces" may work, but it's not terribly secure.
Are you really expecting an AJP connection from anywhere in the world?

- -chris

> On Fri, Mar 20, 2020 at 8:50 AM Fritze, Florian <
> florian.fri...@irb.fraunhofer.de> wrote:
>
>> Just to make it clear what from my opinion the problem is:
>>
>> SCHWERWIEGEND [main]
>> org.apache.catalina.core.StandardService.startInternal Failed to
>> start connector [Connector[AJP/1.3-8011]]
>> org.apache.catalina.LifecycleException: Der Start des
>> Protokoll-Handlers ist fehlgeschlagen at
>>
org.apache.catalina.connector.Connector.startInternal(Connector.java:105
7)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>
>>
at
>>
org.apache.catalina.core.StandardService.startInternal(StandardService.j
ava:440)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>
>>
at
>>
org.apache.catalina.core.StandardServer.startInternal(StandardServer.jav
a:766)
>> at
>> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
>>
>>
at
>> org.apache.catalina.startup.Catalina.start(Catalina.java:688) at
>> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
>>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.jav
a:62)
>> at
>>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessor
Impl.java:43)
>> at java.lang.reflect.Method.invoke(Method.java:498) at
>> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
>> at
>> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
>> Caused by: java.lang.IllegalArgumentException: The AJP
Connector
>> is configured with secretRequired="true" but the secret
>> attribute
is either
>> null or "". This combination is not valid. at
>>
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java
:274)
>> at
>>
org.apache.catalina.connector.Connector.startInternal(Connector.java:105
5)
>> ... 12 more
>>
>> This new "secretRequired" attribute prevents the Tomcat from
>> starting flawlessly. It was first introduced with the Ghostcat
>> release. So this is a wish from me to the Tomcat developers:
>> Please set this new attribute not mandatory but optional. So that
>> I can run the newest
Tomcat
>> without this attribute which I do now with the pre-Ghostcat
>> releases.
>>
>> Have a nice weekend Florian Fritze
>>
>> -- Florian Fritze M.A. Fraunhofer-Informationszentrum Raum und
>> Bau IRB Competence Center Research Services & Open Science
>> Nobelstr. 12, 70569 Stuttgart, Germany Telefon +49 711 970-2713
>> florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de
>>
>>
>> -Ursprüngliche Nachricht- Von: André Warnier
>> (tomcat/perl)  Gesendet: Freitag, 20. März 2020
>> 13:34 An: users@tomcat.apache.org Betreff: Re: AW: AW: AJP
>> Connector issue
>>
>> Ok, so it looks like : - the request is effectively reaching
>> tomcat, and that it is tomcat sending back the 403 response. -
>> the URL is "/", so presumably it is "well-formed" etc.
>>
>> Furthermore, according to something you wrote below, both Apache
httpd and
>> tomcat are running on the same Linux host.
>>
>> This reminds me vaguely of some issue previously (and recently)
discussed
>> on the list, with some request attributes which tomcat did not
>> like.. But I do not remember ptecisely what the issue was, and it
>> also
seems to
>> me that this concerned an IIS front-end, not Apache httpd.
>>
>> Perhaps someone else on the list has a better idea.
>>
>>
>> Incidentally, it also seems that you are, in httpd, proxying
>> *all* requests to tomcat. Which raises the question of why you
>> have a httpd front-end in the
first
>> place. (But that's a later discussion maybe, let's first see why
>> "/"
doesn't work)
>>
>>
>> On 20.03.2020 11:07, Fritze, Florian wrote:
>>> Here is the additional information:
>>>
>>> The

Re: AW: AW: AW: AJP Connector issue

2020-03-20 Thread tomcat/perl 

Hi Florian.

The log below shows clearly "The AJP Connector is configured with 
secretRequired="true"".
This probably comes from the fact that in your AJP Connector configuration, you 
either
- have an explicit secretRequired="true" attribute
or
- you do not mention this attribute, and it defaults to "true"

To get the previous behaviour (without secret), you now *must* specify : 
secretRequired="false".
This is one of the changes in the latest tomcat versions compared to the previous one, and 
this was motivated by security reasons.

So I doubt that there is any chance for that change to be reversed.


On 20.03.2020 13:49, Fritze, Florian wrote:

Just to make it clear what from my opinion the problem is:

SCHWERWIEGEND [main] org.apache.catalina.core.StandardService.startInternal 
Failed to start connector [Connector[AJP/1.3-8011]]
org.apache.catalina.LifecycleException: Der Start des 
Protokoll-Handlers ist fehlgeschlagen
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
Caused by: java.lang.IllegalArgumentException: The AJP Connector is configured with 
secretRequired="true" but the secret attribute is either null or "". This 
combination is not valid.
at 
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
... 12 more

This new "secretRequired" attribute prevents the Tomcat from starting 
flawlessly. It was first introduced with the Ghostcat release.
So this is a wish from me to the Tomcat developers: Please set this new 
attribute not mandatory but optional. So that I can run the newest Tomcat 
without this attribute which I do now with the pre-Ghostcat releases.

Have a nice weekend
Florian Fritze

--
Florian Fritze M.A.
Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713
florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de


-Ursprüngliche Nachricht-
Von: André Warnier (tomcat/perl) 
Gesendet: Freitag, 20. März 2020 13:34
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AJP Connector issue

Ok, so it looks like :
- the request is effectively reaching tomcat, and that it is tomcat sending 
back the 403 response.
- the URL is "/", so presumably it is "well-formed" etc.

Furthermore, according to something you wrote below, both Apache httpd and 
tomcat are running on the same Linux host.

This reminds me vaguely of some issue previously (and recently) discussed on 
the list, with some request attributes which tomcat did not like..
But I do not remember ptecisely what the issue was, and it also seems to me 
that this concerned an IIS front-end, not Apache httpd.

Perhaps someone else on the list has a better idea.


Incidentally, it also seems that you are, in httpd, proxying *all* requests to 
tomcat.
Which raises the question of why you have a httpd front-end in the first place.
(But that's a later discussion maybe, let's first see why "/" doesn't work)


On 20.03.2020 11:07, Fritze, Florian wrote:

Here is the additional information:

The error page looks like Tomcat:

HTTP Status 403 – Forbidden

_

Type Status Report

Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine 
Autorisierung.

_

Apache Tomcat/8.5.53

The Apache HTTPD log file says:

- "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0 
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 
Edg/80.0.361.69"

- "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.

Re: AW: AW: AJP Connector issue

2020-03-20 Thread RK Ashburn 
I have tested r successful AJP connector with apache proxy on (tomcat 7)

1. For AJP connector adding  secretRequired="false" and address="0.0.0.0"
resolved my connectivity issue. I suspect the issue you are having (with
403)  is more like a permissions issue on the site the request is trying to
reach, than a AJP connector configuration issue.


On Fri, Mar 20, 2020 at 8:50 AM Fritze, Florian <
florian.fri...@irb.fraunhofer.de> wrote:

> Just to make it clear what from my opinion the problem is:
>
> SCHWERWIEGEND [main]
> org.apache.catalina.core.StandardService.startInternal Failed to start
> connector [Connector[AJP/1.3-8011]]
> org.apache.catalina.LifecycleException: Der Start des
> Protokoll-Handlers ist fehlgeschlagen
> at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
> at
> org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
> at
> org.apache.catalina.startup.Catalina.start(Catalina.java:688)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
> Caused by: java.lang.IllegalArgumentException: The AJP Connector
> is configured with secretRequired="true" but the secret attribute is either
> null or "". This combination is not valid.
> at
> org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
> at
> org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
> ... 12 more
>
> This new "secretRequired" attribute prevents the Tomcat from starting
> flawlessly. It was first introduced with the Ghostcat release.
> So this is a wish from me to the Tomcat developers: Please set this new
> attribute not mandatory but optional. So that I can run the newest Tomcat
> without this attribute which I do now with the pre-Ghostcat releases.
>
> Have a nice weekend
> Florian Fritze
>
> --
> Florian Fritze M.A.
> Fraunhofer-Informationszentrum Raum und Bau IRB
> Competence Center Research Services & Open Science
> Nobelstr. 12, 70569 Stuttgart, Germany
> Telefon +49 711 970-2713
> florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de
>
>
> -Ursprüngliche Nachricht-
> Von: André Warnier (tomcat/perl) 
> Gesendet: Freitag, 20. März 2020 13:34
> An: users@tomcat.apache.org
> Betreff: Re: AW: AW: AJP Connector issue
>
> Ok, so it looks like :
> - the request is effectively reaching tomcat, and that it is tomcat
> sending back the 403 response.
> - the URL is "/", so presumably it is "well-formed" etc.
>
> Furthermore, according to something you wrote below, both Apache httpd and
> tomcat are running on the same Linux host.
>
> This reminds me vaguely of some issue previously (and recently) discussed
> on the list, with some request attributes which tomcat did not like..
> But I do not remember ptecisely what the issue was, and it also seems to
> me that this concerned an IIS front-end, not Apache httpd.
>
> Perhaps someone else on the list has a better idea.
>
>
> Incidentally, it also seems that you are, in httpd, proxying *all*
> requests to tomcat.
> Which raises the question of why you have a httpd front-end in the first
> place.
> (But that's a later discussion maybe, let's first see why "/" doesn't work)
>
>
> On 20.03.2020 11:07, Fritze, Florian wrote:
> > Here is the additional information:
> >
> > The error page looks like Tomcat:
> >
> > HTTP Status 403 – Forbidden
> >
> >_
> >
> > Type Status Report
> >
> > Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine
> Autorisierung.
> >
> >_
> >
> > Apache Tomcat/8.5.53
> >
> > The Apache HTTPD log

AW: AW: AW: AJP Connector issue

2020-03-20 Thread Fritze, Florian 
Just to make it clear what from my opinion the problem is:

SCHWERWIEGEND [main] org.apache.catalina.core.StandardService.startInternal 
Failed to start connector [Connector[AJP/1.3-8011]]
org.apache.catalina.LifecycleException: Der Start des 
Protokoll-Handlers ist fehlgeschlagen
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1057)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardService.startInternal(StandardService.java:440)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at 
org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:766)
at 
org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183)
at org.apache.catalina.startup.Catalina.start(Catalina.java:688)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:343)
at 
org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:474)
Caused by: java.lang.IllegalArgumentException: The AJP Connector is 
configured with secretRequired="true" but the secret attribute is either null 
or "". This combination is not valid.
at 
org.apache.coyote.ajp.AbstractAjpProtocol.start(AbstractAjpProtocol.java:274)
at 
org.apache.catalina.connector.Connector.startInternal(Connector.java:1055)
... 12 more

This new "secretRequired" attribute prevents the Tomcat from starting 
flawlessly. It was first introduced with the Ghostcat release.
So this is a wish from me to the Tomcat developers: Please set this new 
attribute not mandatory but optional. So that I can run the newest Tomcat 
without this attribute which I do now with the pre-Ghostcat releases.

Have a nice weekend
Florian Fritze

--
Florian Fritze M.A.
Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713
florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de


-Ursprüngliche Nachricht-
Von: André Warnier (tomcat/perl)  
Gesendet: Freitag, 20. März 2020 13:34
An: users@tomcat.apache.org
Betreff: Re: AW: AW: AJP Connector issue

Ok, so it looks like :
- the request is effectively reaching tomcat, and that it is tomcat sending 
back the 403 response.
- the URL is "/", so presumably it is "well-formed" etc.

Furthermore, according to something you wrote below, both Apache httpd and 
tomcat are running on the same Linux host.

This reminds me vaguely of some issue previously (and recently) discussed on 
the list, with some request attributes which tomcat did not like..
But I do not remember ptecisely what the issue was, and it also seems to me 
that this concerned an IIS front-end, not Apache httpd.

Perhaps someone else on the list has a better idea.


Incidentally, it also seems that you are, in httpd, proxying *all* requests to 
tomcat.
Which raises the question of why you have a httpd front-end in the first place.
(But that's a later discussion maybe, let's first see why "/" doesn't work)


On 20.03.2020 11:07, Fritze, Florian wrote:
> Here is the additional information:
> 
> The error page looks like Tomcat:
> 
> HTTP Status 403 – Forbidden
> 
>_
> 
> Type Status Report
> 
> Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine 
> Autorisierung.
> 
>_
> 
> Apache Tomcat/8.5.53
> 
> The Apache HTTPD log file says:
> 
> - "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0 
> (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
> Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69"
> 
> - "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 885 
> "https://dev-fordatis.fraunhofer.de/"; "Mozilla/5.0 (Windows NT 10.0; Win64; 
> x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 
> Safari/537.36 Edg/80.0.361.69"
> 
> 
> 
> The Tomcat says:
> 
> - - [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 630
> 
> - - [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 630
> 
> 
> 
> The server on which all is running is:
> 
> Linux 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 
> 2020

Re: AW: AW: AJP Connector issue

2020-03-20 Thread tomcat/perl 

Ok, so it looks like :
- the request is effectively reaching tomcat, and that it is tomcat sending back the 403 
response.

- the URL is "/", so presumably it is "well-formed" etc.

Furthermore, according to something you wrote below, both Apache httpd and tomcat are 
running on the same Linux host.


This reminds me vaguely of some issue previously (and recently) discussed on the list, 
with some request attributes which tomcat did not like..
But I do not remember ptecisely what the issue was, and it also seems to me that this 
concerned an IIS front-end, not Apache httpd.


Perhaps someone else on the list has a better idea.


Incidentally, it also seems that you are, in httpd, proxying *all* requests to 
tomcat.
Which raises the question of why you have a httpd front-end in the first place.
(But that's a later discussion maybe, let's first see why "/" doesn't work)


On 20.03.2020 11:07, Fritze, Florian wrote:

Here is the additional information:

The error page looks like Tomcat:

HTTP Status 403 – Forbidden

   _

Type Status Report

Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine 
Autorisierung.

   _

Apache Tomcat/8.5.53

The Apache HTTPD log file says:

- "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0 
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 
Edg/80.0.361.69"

- "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 885 
"https://dev-fordatis.fraunhofer.de/"; "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 
(KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69"



The Tomcat says:

- - [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 630

- - [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 630



The server on which all is running is:

Linux 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux



There is no new entry in the Apache HTTPD error.log concering these requests.



Help is appreciated

Florian Fritze

--

Florian Fritze M.A.

Fraunhofer-Informationszentrum Raum und Bau IRB

Competence Center Research Services & Open Science

Nobelstr. 12, 70569 Stuttgart, Germany

Telefon +49 711 970-2713

florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de





-----Ursprüngliche Nachricht-
Von: André Warnier (tomcat/perl) 
Gesendet: Freitag, 20. März 2020 10:14
An: users@tomcat.apache.org
Betreff: Re: AW: AJP Connector issue



On 20.03.2020 08:23, Fritze, Florian wrote:


Hello Chris,







thanks for the reply. Maybe I am doing something wrong, but setting



secretRequired="false" does not solve my issue. Let me show you what I



did and experience: I added 


redirectPort="8443" secretRequired="false" /> to the Tomcat



configuration and the ajp connector on the Apache HTTPD side connects



to 8011. When I now visit my website I got HTTP Status 403 – Forbidden




And just to make diagnosis a bit quicker : does that 403 error page look like 
an Apache httpd page, or a tomcat page ? (they look quite differemt in style).



Also, can you check both the httpd logs, and the tomcat logs for that request, 
and check what they say ?  (compare by timestamnp and URI)



Also, under what OS does your front-end httpd run ?








I attached also the error page as a screenshot to this mail. This



behaviour exists only sice the Ghostcat fix release (I know that this



has nothing to do with security fix but probably with the release itself).







Thanks in advance



Florian







--



Florian Fritze M.A.



Fraunhofer-Informationszentrum Raum und Bau IRB Competence Center



Research Services & Open Science Nobelstr. 12, 70569 Stuttgart,



Germany Telefon +49 711 970-2713 
florian.fri...@irb.fraunhofer.de<mailto:florian.fri...@irb.fraunhofer.de> |



www.irb.fraunhofer.de<http://www.irb.fraunhofer.de>







-Ursprüngliche Nachricht-----



Von: Christopher Schultz 
mailto:ch...@christopherschultz.net>>



Gesendet: Donnerstag, 19. März 2020 20:14



An: users@tomcat.apache.org<mailto:users@tomcat.apache.org>



Betreff: Re: AJP Connector issue







-BEGIN PGP SIGNED MESSAGE-



Hash: SHA256







Florian,







On 3/19/20 07:43, Fritze, Florian wrote:



since the Tomcat release with the Ghostcat security fix (Tomcat



8.5.51) me as an admin have the problem using the



https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to



connect the Apache HTTPD with the Tomcat running on localhost. The



attribute secretRequired must be set to „true“ or „false“ with



„false“ set the connection is not possible between Tomcat and Apache HTTPD.







When you have set secretRequired="false", it's not possible to

AW: AW: AJP Connector issue

2020-03-20 Thread Fritze, Florian 
Here is the additional information:

The error page looks like Tomcat:

HTTP Status 403 – Forbidden

  _

Type Status Report

Beschreibung Der Server hat die Anfrage verstanden, verbietet aber eine 
Autorisierung.

  _

Apache Tomcat/8.5.53

The Apache HTTPD log file says:

- "" [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 1042 "-" "Mozilla/5.0 
(Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) 
Chrome/80.0.3987.149 Safari/537.36 Edg/80.0.361.69"

- "" [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 885 
"https://dev-fordatis.fraunhofer.de/"; "Mozilla/5.0 (Windows NT 10.0; Win64; 
x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.149 Safari/537.36 
Edg/80.0.361.69"



The Tomcat says:

- - [20/Mar/2020:10:56:24 +0100] "GET / HTTP/1.1" 403 630

- - [20/Mar/2020:10:56:24 +0100] "GET /favicon.ico HTTP/1.1" 403 630



The server on which all is running is:

Linux 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 
x86_64 x86_64 x86_64 GNU/Linux



There is no new entry in the Apache HTTPD error.log concering these requests.



Help is appreciated

Florian Fritze

--

Florian Fritze M.A.

Fraunhofer-Informationszentrum Raum und Bau IRB

Competence Center Research Services & Open Science

Nobelstr. 12, 70569 Stuttgart, Germany

Telefon +49 711 970-2713

florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de





-Ursprüngliche Nachricht-
Von: André Warnier (tomcat/perl) 
Gesendet: Freitag, 20. März 2020 10:14
An: users@tomcat.apache.org
Betreff: Re: AW: AJP Connector issue



On 20.03.2020 08:23, Fritze, Florian wrote:

> Hello Chris,

>

> thanks for the reply. Maybe I am doing something wrong, but setting

> secretRequired="false" does not solve my issue. Let me show you what I

> did and experience: I added  redirectPort="8443" secretRequired="false" /> to the Tomcat

> configuration and the ajp connector on the Apache HTTPD side connects

> to 8011. When I now visit my website I got HTTP Status 403 – Forbidden



And just to make diagnosis a bit quicker : does that 403 error page look like 
an Apache httpd page, or a tomcat page ? (they look quite differemt in style).



Also, can you check both the httpd logs, and the tomcat logs for that request, 
and check what they say ?  (compare by timestamnp and URI)



Also, under what OS does your front-end httpd run ?



>

> I attached also the error page as a screenshot to this mail. This

> behaviour exists only sice the Ghostcat fix release (I know that this

> has nothing to do with security fix but probably with the release itself).

>

> Thanks in advance

> Florian

>

> --

> Florian Fritze M.A.

> Fraunhofer-Informationszentrum Raum und Bau IRB Competence Center

> Research Services & Open Science Nobelstr. 12, 70569 Stuttgart,

> Germany Telefon +49 711 970-2713 
> florian.fri...@irb.fraunhofer.de<mailto:florian.fri...@irb.fraunhofer.de> |

> www.irb.fraunhofer.de<http://www.irb.fraunhofer.de>

>

> -----Ursprüngliche Nachricht-

> Von: Christopher Schultz 
> mailto:ch...@christopherschultz.net>>

> Gesendet: Donnerstag, 19. März 2020 20:14

> An: users@tomcat.apache.org<mailto:users@tomcat.apache.org>

> Betreff: Re: AJP Connector issue

>

> -BEGIN PGP SIGNED MESSAGE-

> Hash: SHA256

>

> Florian,

>

> On 3/19/20 07:43, Fritze, Florian wrote:

>> since the Tomcat release with the Ghostcat security fix (Tomcat

>> 8.5.51) me as an admin have the problem using the

>> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to

>> connect the Apache HTTPD with the Tomcat running on localhost. The

>> attribute secretRequired must be set to „true“ or „false“ with

>> „false“ set the connection is not possible between Tomcat and Apache HTTPD.

>

> When you have set secretRequired="false", it's not possible to

> connect? When you try to connect, what DOES happen?

>

>> With „true“ the Apache development is not ready in the current

>> version to work with the „secret“ attribute. Only the next version of

>> Apache

>> 2.4 supports this attribute.

> Correct. Support for secret= in mod_proxy_ajp was evidently never

> really a priority for anybody until now.

>

>> So I want to use the newest Tomcat version and an AJP connector but

>> after the Ghostcat fix release there is this attribute which does not

>> work in my configuration.

>>

>> Are there any suggestions or solutions available that you can deliver

>> me (links or documentation, etc.)

>

> secretRequired="false" should be all you need.

>

> Of course, to

Re: AW: AJP Connector issue

2020-03-20 Thread tomcat/perl 

On 20.03.2020 08:23, Fritze, Florian wrote:

Hello Chris,

thanks for the reply. Maybe I am doing something wrong, but setting
secretRequired="false" does not solve my issue. Let me show you what I did
and experience: I added  to the Tomcat configuration
and the ajp connector on the Apache HTTPD side connects to 8011. When I now
visit my website I got HTTP Status 403 – Forbidden


And just to make diagnosis a bit quicker : does that 403 error page look like an Apache 
httpd page, or a tomcat page ? (they look quite differemt in style).


Also, can you check both the httpd logs, and the tomcat logs for that request, and check 
what they say ?  (compare by timestamnp and URI)


Also, under what OS does your front-end httpd run ?



I attached also the error page as a screenshot to this mail. This behaviour
exists only sice the Ghostcat fix release (I know that this has nothing to
do with security fix but probably with the release itself).

Thanks in advance
Florian

--
Florian Fritze M.A.
Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713
florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de

-Ursprüngliche Nachricht-
Von: Christopher Schultz 
Gesendet: Donnerstag, 19. März 2020 20:14
An: users@tomcat.apache.org
Betreff: Re: AJP Connector issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Florian,

On 3/19/20 07:43, Fritze, Florian wrote:

since the Tomcat release with the Ghostcat security fix (Tomcat
8.5.51) me as an admin have the problem using the
https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to
connect the Apache HTTPD with the Tomcat running on localhost. The
attribute secretRequired must be set to „true“ or „false“ with „false“
set the connection is not possible between Tomcat and Apache HTTPD.


When you have set secretRequired="false", it's not possible to connect? When
you try to connect, what DOES happen?


With „true“ the Apache development is not ready in the current version
to work with the „secret“ attribute. Only the next version of Apache
2.4 supports this attribute.

Correct. Support for secret= in mod_proxy_ajp was evidently never really a
priority for anybody until now.


So I want to use the newest Tomcat version and an AJP connector but
after the Ghostcat fix release there is this attribute which does not
work in my configuration.

Are there any suggestions or solutions available that you can deliver
me (links or documentation, etc.)


secretRequired="false" should be all you need.

Of course, to be truly secure, you need to make sure that not just anybody
can make requests through your AJP interface. Have you secured that
interface from potential evildoers?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxHsACgkQHPApP6U8
pFjf7Q/+Ixbc10KYI07Wb1pdzQajVtw88BcfSZ3dfam2Q9aj2IhZJD5GUTzszAGC
bs6eySKEh5vqaHq+oy2ZOuv2f1xxukPQ3/XfmIEUb83G7QScwlMf0r5dth9uslcq
cUgHFkpGhSQghB2yhZSzKMzF7gjRY9QI0S5EpEHTQ45CUvREWr4GRyLndkjTbu2C
rhdB+8ud4iErWJe1Er0NEqOgoVL8Ceed4BGRYzoT7+lN1dRE4MFIn8ALdVzAvo4L
9ZIm+zawSkx7jUTAGDi4wHd2KrewR9kqJybovZaACx/yc6IF1Sv+DaWlTUDdabE2
qrSl45mA4EdLCeH1wfbZ62IhErbxvLahygAwgYSeMfhv02vzBbmn8bXY4yg359ln
aO2AV3xNbxFrF56XatRGIJ+3/ETh2oIv0PLnJEr8xc3CcwdJ+rn8c9i84ZZLnHb6
iTl+Gx9pCUbtH0qCILzLzj7Js9yl13o9AVu3UQ9UxY9BNxkFiKKBe4YfGUev2iiB
Vx1Zw6S6/ByjhUpzaSEciSYCkr+pR61iOJpCN9B3tnpv4cRgkqwPWEPgMFDtvFT9
ciwpDuN+O2YPPE0Z39tSy64Ge2QWyPkvb8hVZUEZGVMRmQ1W5LhDJhNxECklxKOh
sZPFkji5aVOxj6TT5vwqQDov+FyU2pV5/HRD4fe/vr8vdKj+vec=
=CYi0
-END PGP SIGNATURE-

-
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

AW: AJP Connector issue

2020-03-20 Thread Fritze, Florian 
Hello Chris,

thanks for the reply. Maybe I am doing something wrong, but setting
secretRequired="false" does not solve my issue. Let me show you what I did
and experience: I added  to the Tomcat configuration
and the ajp connector on the Apache HTTPD side connects to 8011. When I now
visit my website I got HTTP Status 403 – Forbidden

I attached also the error page as a screenshot to this mail. This behaviour
exists only sice the Ghostcat fix release (I know that this has nothing to
do with security fix but probably with the release itself).

Thanks in advance
Florian

--
Florian Fritze M.A.
Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713
florian.fri...@irb.fraunhofer.de | www.irb.fraunhofer.de

-Ursprüngliche Nachricht-
Von: Christopher Schultz  
Gesendet: Donnerstag, 19. März 2020 20:14
An: users@tomcat.apache.org
Betreff: Re: AJP Connector issue

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Florian,

On 3/19/20 07:43, Fritze, Florian wrote:
> since the Tomcat release with the Ghostcat security fix (Tomcat
> 8.5.51) me as an admin have the problem using the 
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to 
> connect the Apache HTTPD with the Tomcat running on localhost. The 
> attribute secretRequired must be set to „true“ or „false“ with „false“ 
> set the connection is not possible between Tomcat and Apache HTTPD.

When you have set secretRequired="false", it's not possible to connect? When
you try to connect, what DOES happen?

> With „true“ the Apache development is not ready in the current version 
> to work with the „secret“ attribute. Only the next version of Apache 
> 2.4 supports this attribute.
Correct. Support for secret= in mod_proxy_ajp was evidently never really a
priority for anybody until now.

> So I want to use the newest Tomcat version and an AJP connector but 
> after the Ghostcat fix release there is this attribute which does not 
> work in my configuration.
>
> Are there any suggestions or solutions available that you can deliver 
> me (links or documentation, etc.)

secretRequired="false" should be all you need.

Of course, to be truly secure, you need to make sure that not just anybody
can make requests through your AJP interface. Have you secured that
interface from potential evildoers?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxHsACgkQHPApP6U8
pFjf7Q/+Ixbc10KYI07Wb1pdzQajVtw88BcfSZ3dfam2Q9aj2IhZJD5GUTzszAGC
bs6eySKEh5vqaHq+oy2ZOuv2f1xxukPQ3/XfmIEUb83G7QScwlMf0r5dth9uslcq
cUgHFkpGhSQghB2yhZSzKMzF7gjRY9QI0S5EpEHTQ45CUvREWr4GRyLndkjTbu2C
rhdB+8ud4iErWJe1Er0NEqOgoVL8Ceed4BGRYzoT7+lN1dRE4MFIn8ALdVzAvo4L
9ZIm+zawSkx7jUTAGDi4wHd2KrewR9kqJybovZaACx/yc6IF1Sv+DaWlTUDdabE2
qrSl45mA4EdLCeH1wfbZ62IhErbxvLahygAwgYSeMfhv02vzBbmn8bXY4yg359ln
aO2AV3xNbxFrF56XatRGIJ+3/ETh2oIv0PLnJEr8xc3CcwdJ+rn8c9i84ZZLnHb6
iTl+Gx9pCUbtH0qCILzLzj7Js9yl13o9AVu3UQ9UxY9BNxkFiKKBe4YfGUev2iiB
Vx1Zw6S6/ByjhUpzaSEciSYCkr+pR61iOJpCN9B3tnpv4cRgkqwPWEPgMFDtvFT9
ciwpDuN+O2YPPE0Z39tSy64Ge2QWyPkvb8hVZUEZGVMRmQ1W5LhDJhNxECklxKOh
sZPFkji5aVOxj6TT5vwqQDov+FyU2pV5/HRD4fe/vr8vdKj+vec=
=CYi0
-END PGP SIGNATURE-

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



smime.p7s
Description: S/MIME cryptographic signature

Re: AJP Connector issue

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

André,

On 3/19/20 10:57, André Warnier (tomcat/perl) wrote:
> For example : - if all your pairs of httpd server/tomcat server are
> running on the same host, then you do not really have a security
> issue, and adding a secret will not really bring any additional
> security - if all your pairs of httpd server/tomcat server are
> communicating only over an internal (presumed to be fairly safe)
> network, then you do have a limited security issue (limited by how
> "safe" your internal network really is), and a secret may help a
> bit in reducing this already limited security issue - if you have
> pairs of httpd/tomcat which communicate over a public network, then
> you do have a security issue, and adding a secret will help, but it
> is not going to make that security issue really disappear (*).

If you have naked AJP traversing a public network then you are very
much doing it wrong and have zero privacy or security. Adding a secret
will only expose the secret to anyone who cares to look.

> (*) the secret, if correctly implemented, will block any other host
> than your own hosts from connecting to the tomcat AJP Connector,
> and thus from "abusing" your tomcats by sending them invalid or
> malicious requests.

AJP allows the client to present a secret to the server, but it does
so insecurely. Any attacker who can see your AJP traffic can also see
the secret. So adding a secret doesn't really add security in any
meaningful way. Instead of adding a door lock, it instead adds a note
saying "please don't open this door unless you are allowed to do so."

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxW8ACgkQHPApP6U8
pFgjyQ//ZrfYJS2LtqKBrZt0Zj3UlzuclNkZJ+48hcbKuaNo9oUHoUS9HtJG+vqv
id2kwQZYfgWXtsJiEGLqPL6OytULqTMYW7TOj5WqxIqYtlIvwMis4eB8qvql3W08
cQex0qpGWIaxmw05hxN8hg8VABpG5blKmQfTJ6KyDY0G5xSHZXBMyXn0WMth6zNp
xgNXksTEu/CMWOr8rgIH5x6+0/mjv5XM7VA4mBxUuk6HZhJ1+62GMR7Ame5pjbKF
lyT85eU4Qhe1zZPyMoVbabLvNg2U44iC3rAqXGgQ5ZEr/Ky8EQMePQazgDpBKeG0
Kpsxb7HY3Z/O6+kY3S15tbt2b/A9DgbR41MJnw3KcUzR0/3wq/5lOHyBSV8N63ug
qvQdycBrb2pxfZPBBGPI0XvG3IqzdKqtWpmQAq6SBmZ0JAHGp2go9l4eE9kDxcDU
h7KeiNrE8LKO6Ijnth4FbmZOWNkMWwF22fAIeDrE1eQJL2SLE3h2+UHbK+qR8Bk3
Sby9FTSZ+2SoIXgSwc+jQyfpn7HtIqmYqPHhzSlIQJtz/ANHkiG59X+g3epgdnn/
GyBTFrOsirWaQGOJHh/nAE/z6YbhHhTl0hmxNKG1EBwyfDH7+zHRtl+E4Nk1Mkzu
dBNGM2clPrGwDLXTEc44OGpsgaU4QZqhGY29g2qt1xN9r0O40A0=
=GSne
-END PGP SIGNATURE-

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

Re: AJP Connector issue

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

Florian,

On 3/19/20 07:43, Fritze, Florian wrote:
> since the Tomcat release with the Ghostcat security fix (Tomcat
> 8.5.51) me as an admin have the problem using the
> https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to
> connect the Apache HTTPD with the Tomcat running on localhost. The
> attribute secretRequired must be set to „true“ or „false“ with
> „false“ set the connection is not possible between Tomcat and
> Apache HTTPD.

When you have set secretRequired="false", it's not possible to
connect? When you try to connect, what DOES happen?

> With „true“ the Apache development is not ready in the current
> version to work with the „secret“ attribute. Only the next version
> of Apache 2.4 supports this attribute.
Correct. Support for secret= in mod_proxy_ajp was evidently never
really a priority for anybody until now.

> So I want to use the newest Tomcat version and an AJP connector
> but after the Ghostcat fix release there is this attribute which
> does not work in my configuration.
>
> Are there any suggestions or solutions available that you can
> deliver me (links or documentation, etc.)

secretRequired="false" should be all you need.

Of course, to be truly secure, you need to make sure that not just
anybody can make requests through your AJP interface. Have you secured
that interface from potential evildoers?

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

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5zxHsACgkQHPApP6U8
pFjf7Q/+Ixbc10KYI07Wb1pdzQajVtw88BcfSZ3dfam2Q9aj2IhZJD5GUTzszAGC
bs6eySKEh5vqaHq+oy2ZOuv2f1xxukPQ3/XfmIEUb83G7QScwlMf0r5dth9uslcq
cUgHFkpGhSQghB2yhZSzKMzF7gjRY9QI0S5EpEHTQ45CUvREWr4GRyLndkjTbu2C
rhdB+8ud4iErWJe1Er0NEqOgoVL8Ceed4BGRYzoT7+lN1dRE4MFIn8ALdVzAvo4L
9ZIm+zawSkx7jUTAGDi4wHd2KrewR9kqJybovZaACx/yc6IF1Sv+DaWlTUDdabE2
qrSl45mA4EdLCeH1wfbZ62IhErbxvLahygAwgYSeMfhv02vzBbmn8bXY4yg359ln
aO2AV3xNbxFrF56XatRGIJ+3/ETh2oIv0PLnJEr8xc3CcwdJ+rn8c9i84ZZLnHb6
iTl+Gx9pCUbtH0qCILzLzj7Js9yl13o9AVu3UQ9UxY9BNxkFiKKBe4YfGUev2iiB
Vx1Zw6S6/ByjhUpzaSEciSYCkr+pR61iOJpCN9B3tnpv4cRgkqwPWEPgMFDtvFT9
ciwpDuN+O2YPPE0Z39tSy64Ge2QWyPkvb8hVZUEZGVMRmQ1W5LhDJhNxECklxKOh
sZPFkji5aVOxj6TT5vwqQDov+FyU2pV5/HRD4fe/vr8vdKj+vec=
=CYi0
-END PGP SIGNATURE-

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

Re: AJP Connector issue

2020-03-19 Thread tomcat/perl 

On 19.03.2020 12:43, Fritze, Florian wrote:

Dear Tomcat users,

since the Tomcat release with the Ghostcat security fix (Tomcat 8.5.51) me as an admin 
have the problem using the https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module 
to connect the Apache HTTPD with the Tomcat running on localhost. The attribute 
secretRequired must be set to „true“ or „false“ with „false“ set the connection is not 
possible between Tomcat and Apache HTTPD. With „true“ the Apache development is not ready 
in the current version to work with the „secret“ attribute. Only the next version of 
Apache 2.4 supports this attribute.


So I want to use the newest Tomcat version and an AJP connector but after the Ghostcat fix 
release there is this attribute which does not work in my configuration.


Are there any suggestions or solutions available that you can deliver me (links or 
documentation, etc.)



Hello.
It all depends on your configuration, and how your front-end Apache httpd server(s) 
connect to your back-end tomcat server(s).

For example :
- if all your pairs of httpd server/tomcat server are running on the same host, then you 
do not really have a security issue, and adding a secret will not really bring any 
additional security
- if all your pairs of httpd server/tomcat server are communicating only over an internal 
(presumed to be fairly safe) network, then you do have a limited security issue (limited 
by how "safe" your internal network really is), and a secret may help a bit in reducing 
this already limited security issue
- if you have pairs of httpd/tomcat which communicate over a public network, then you do 
have a security issue, and adding a secret will help, but it is not going to make that 
security issue really disappear (*).


But if you want to add a secret anyway, then it depends on how httpd communicates with its 
corresponding tomcat, and there are 2 options :

- using the httpd mod_proxy_ajp module
or
- using the httpd mod_jk module

As I understand from your message, the current mod_proxy_ajp module released with the 
current httpd 2.4, does not support that "secret" yet.
But the currently available mod_jk module does support that option, and the current mod_jk 
module is compatible with any httpd 2.4 version.

And, functionally, mod_proxy_ajp and mod_jk can do the same things.
It is just the setup and configuration (at the httpd level) that is somewhat different 
between the two. (there is no difference at the tomcat level).


So if you are currently using mod_proxy_ajp (**), then if you want to implement this 
"secret" option, you would have to change your httpd configuration, to use mod_jk instead 
of mod_proxy_ajp (temporarily, until the appropriate version of mod_proxy_ajp is released).


(*) the secret, if correctly implemented, will block any other host than your own hosts 
from connecting to the tomcat AJP Connector, and thus from "abusing" your tomcats by 
sending them invalid or malicious requests.
But it would not block someone from intercepting the traffic between your httpds and your 
tomcats and reading it, because the AJP protocol is not encrypted, and because there is no 
implementation available that makes this traffic be encrypted.


(**) If you are currently using mod_proxy_ajp, then it is also likely that you are not 
using the option whereby httpd can do the user authentication, and then pass the 
authenticated user-id along to tomcat, for tomcat to use it.

That means that you are already avoiding one possible security issue.


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

AJP Connector issue

2020-03-19 Thread Fritze, Florian 
Dear Tomcat users,

 

since the Tomcat release with the Ghostcat security fix (Tomcat 8.5.51) me
as an admin have the problem using the
https://httpd.apache.org/docs/2.4/mod/mod_proxy_ajp.html module to connect
the Apache HTTPD with the Tomcat running on localhost. The attribute
secretRequired must be set to "true" or "false" with "false" set the
connection is not possible between Tomcat and Apache HTTPD. With "true" the
Apache development is not ready in the current version to work with the
"secret" attribute. Only the next version of Apache 2.4 supports this
attribute.

So I want to use the newest Tomcat version and an AJP connector but after
the Ghostcat fix release there is this attribute which does not work in my
configuration. 

Are there any suggestions or solutions available that you can deliver me
(links or documentation, etc.)

 

Thanks in advance

Florian Fritze

 

--

Florian Fritze M.A.

Fraunhofer-Informationszentrum Raum und Bau IRB
Competence Center Research Services & Open Science
Nobelstr. 12, 70569 Stuttgart, Germany
Telefon +49 711 970-2713

  florian.fri...@irb.fraunhofer.de
|   www.irb.fraunhofer.de

 



smime.p7s
Description: S/MIME cryptographic signature

Re: ajp connector issue - getting "Unable to get the free" in mod_jk.log file.

2006-12-26 Thread Shekar Tippur 

Can anyone throw more light on this issue? We are being plagued by this
problem and the only way we can resolve this is by HUP'ing the thread.

- Shekar

On 12/19/06, Shekar Tippur <[EMAIL PROTECTED]> wrote:


Rainer,

One another change we noticed was that response is cut off for a
particular transaction on a  thread. For every other thread, we see
marshelling and un-marshelling messages in the mod_jk.log file.

There is no issue of load

[Fri Dec 08 01:16:25 2006] [18477:] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (909): 03f032 34 34 35
30 31 26 74 65 72 6D 49 64 3D 37 35  - 244501&termId=75

.. This is where it looks like the response was cut off.  The next
occurance of this process id is a new request! ...

[Fri Dec 08 01:23:03 2006] [18477:] [debug]
map_uri_to_worker::jk_uri_worker_map.c (449): Attempting to map URI
'/ui/ac/loadSummary.do' from 11 maps

Thanks,

Shekar


On 12/19/06, Shekar Tippur <[EMAIL PROTECTED]> wrote:
>
> Rainer,
>
> We upgraded mod_jk to 1.2.19 and we are still getting the same error in
> mod_jk.
>
> [Tue Dec 19 11:35:36 2006] [31691:] [warn]
> ajp_get_endpoint::jk_ajp_common.c (2258): Unable to get the free endpoint
> for worker myWorker from 1 slots
> [Tue Dec 19 11:35:36 2006] [31691:] [info]
> ajp_get_endpoint::jk_ajp_common.c (2272): can't find free endpoint
> [Tue Dec 19 11:35:36 2006] myWorker gorgon 0.99
> [Tue Dec 19 11:35:36 2006] [31691:] [info]  jk_handler::mod_jk.c
> (1986): Service error=0 for worker=myWorker
>
> I would really apperciate if anyone could help me on this.
>
> Shekar
>
> On 12/17/06, Shekar Tippur <[EMAIL PROTECTED] > wrote:
> >
> > Hello,
> >
> > Thanks for replying back.
> >
> > I cannot see any specal requests but there maybe high load. I can see
> > 193 active threads.
> >
> > We are in the process of upgrading mod_jk version to 1.2.19.
> >
> > Here is some of the information you wanted. Please let me know if you
> > need more information.
> >
> > cat /proc/version
> >
> > Linux version 2.6.9-34.ELsmp ([EMAIL PROTECTED] )
> > (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2 ))
> >
> >
> > worker.properties
> >
> > worker.list=jkstatus,consWorker,myWorker
> >
> > # Configure Load Balancer status manager.
> >
> > worker.jkstatus.type=status
> >
> > worker.consWorker.port=8009
> > worker.consWorker.host=localhost
> > worker.consWorker.type=ajp13
> > worker.consWorker.socket_timeout=120
> >
> > # Define first worker for failover
> > worker.myWorker.port=8010
> > worker.myWorker.host=localhost
> > worker.myWorker.type=ajp13
> > worker.myWorker.socket_timeout=120
> >
> >
> >
> > apache_mod_jk.conf file
> >
> >
> > # conf/include/apache_mod_jk.conf
> > # global settings files for the mod jk connector
> >
> > LoadModule jk_module libexec/apache_mod_jk.so
> >
> > # Where to find workers.properties
> > JkWorkersFile /home/apache/conf/apache/mod_include/worker.properties
> >
> > # Where to put jk logs
> > JkLogFile logs/apache/mod_jk.log
> >
> > # Set the jk log level [debug/error/info]
> > JkLogLevel info
> >
> > # Select the log format
> > JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
> >
> > # JkRequestLogFormat set the request format
> > JkRequestLogFormat "%w %V %T"
> >
> > # JkOptions indicate to send SSL KEY SIZE,
> > JkOptions +ForwardURICompat -ForwardDirectories
> >
> > # Configure Load Balancer status manager.
> >
> > #JkWorkerProperties worker.jkstatus.type=status
> >
> > # status for later load balancing
> >
> > 
> > JkMount /jkstatus/*
> > Order deny,allow
> > Deny from all
> > Allow from 127.0.0.1
> > 
> >
> > JkMount /jkmanager/* jkstatus
> >
> > On 12/16/06, Rainer Jung < [EMAIL PROTECTED]> wrote:
> > >
> > > Hi,
> > >
> > > this looks strange. Could you please post your config and give a
> > > couple
> > > of details about your environment (OS+Version). Is there any pattern
> > > related to the problem (special requests, high load, ...)?
> > >
> > > It would be really good, if you could update mod_jk to 1.2.19 or
> > > 1.2.20
> > > which will most likely be available middle of next week.
> > >
> > > Regards,
> > >
> > > Rainer
> > >
> > > Shekar Tippur schrieb:
> > > > Hello
> > > >
> > > > We are getting unable to get the free endpoint and eventually
> > > resulting
> > > > in a 500 (internal server error).
> > > >
> > > > We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to
> > > many
> > > > reasons,
> > > > we are not in a position to upgrade wither of these packages.
> > > >
> > > > [Fri Dec 08 01:34:09 2006] [18477:] [warn]
> > > > ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free
> > > > endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09
> > > 2006]
> > > > [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152):
> > > can't
> > > > find free endpoint [Fri Dec 08 01:34:09 2006]
> > > [18477:]  myWorker
> > > > 0.88
> > > >
> > > > Under these situations, we also see that either jboss threads are
> > > > proces

Re: ajp connector issue - getting "Unable to get the free" in mod_jk.log file.

2006-12-19 Thread Shekar Tippur 

Rainer,

One another change we noticed was that response is cut off for a particular
transaction on a  thread. For every other thread, we see marshelling and
un-marshelling messages in the mod_jk.log file.

There is no issue of load

[Fri Dec 08 01:16:25 2006] [18477:] [debug]
ajp_connection_tcp_send_message::jk_ajp_common.c (909): 03f032 34 34 35
30 31 26 74 65 72 6D 49 64 3D 37 35  - 244501&termId=75

.. This is where it looks like the response was cut off.  The next occurance
of this process id is a new request! ...

[Fri Dec 08 01:23:03 2006] [18477:] [debug]
map_uri_to_worker::jk_uri_worker_map.c (449): Attempting to map URI
'/ui/ac/loadSummary.do' from 11 maps

Thanks,

Shekar


On 12/19/06, Shekar Tippur <[EMAIL PROTECTED]> wrote:


Rainer,

We upgraded mod_jk to 1.2.19 and we are still getting the same error in
mod_jk.

[Tue Dec 19 11:35:36 2006] [31691:] [warn]
ajp_get_endpoint::jk_ajp_common.c (2258): Unable to get the free endpoint
for worker myWorker from 1 slots
[Tue Dec 19 11:35:36 2006] [31691:] [info]
ajp_get_endpoint::jk_ajp_common.c (2272): can't find free endpoint
[Tue Dec 19 11:35:36 2006] myWorker gorgon 0.99
[Tue Dec 19 11:35:36 2006] [31691:] [info]  jk_handler::mod_jk.c
(1986): Service error=0 for worker=myWorker

I would really apperciate if anyone could help me on this.

Shekar

On 12/17/06, Shekar Tippur <[EMAIL PROTECTED] > wrote:
>
> Hello,
>
> Thanks for replying back.
>
> I cannot see any specal requests but there maybe high load. I can see
> 193 active threads.
>
> We are in the process of upgrading mod_jk version to 1.2.19.
>
> Here is some of the information you wanted. Please let me know if you
> need more information.
>
> cat /proc/version
>
> Linux version 2.6.9-34.ELsmp ([EMAIL PROTECTED] )
> (gcc version 3.4.5 20051201 (Red Hat 3.4.5-2 ))
>
>
> worker.properties
>
> worker.list=jkstatus,consWorker,myWorker
>
> # Configure Load Balancer status manager.
>
> worker.jkstatus.type=status
>
> worker.consWorker.port=8009
> worker.consWorker.host=localhost
> worker.consWorker.type=ajp13
> worker.consWorker.socket_timeout=120
>
> # Define first worker for failover
> worker.myWorker.port=8010
> worker.myWorker.host=localhost
> worker.myWorker.type=ajp13
> worker.myWorker.socket_timeout=120
>
>
>
> apache_mod_jk.conf file
>
>
> # conf/include/apache_mod_jk.conf
> # global settings files for the mod jk connector
>
> LoadModule jk_module libexec/apache_mod_jk.so
>
> # Where to find workers.properties
> JkWorkersFile /home/apache/conf/apache/mod_include/worker.properties
>
> # Where to put jk logs
> JkLogFile logs/apache/mod_jk.log
>
> # Set the jk log level [debug/error/info]
> JkLogLevel info
>
> # Select the log format
> JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
>
> # JkRequestLogFormat set the request format
> JkRequestLogFormat "%w %V %T"
>
> # JkOptions indicate to send SSL KEY SIZE,
> JkOptions +ForwardURICompat -ForwardDirectories
>
> # Configure Load Balancer status manager.
>
> #JkWorkerProperties worker.jkstatus.type=status
>
> # status for later load balancing
>
> 
> JkMount /jkstatus/*
> Order deny,allow
> Deny from all
> Allow from 127.0.0.1
> 
>
> JkMount /jkmanager/* jkstatus
>
> On 12/16/06, Rainer Jung < [EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > this looks strange. Could you please post your config and give a
> > couple
> > of details about your environment (OS+Version). Is there any pattern
> > related to the problem (special requests, high load, ...)?
> >
> > It would be really good, if you could update mod_jk to 1.2.19 or
> > 1.2.20
> > which will most likely be available middle of next week.
> >
> > Regards,
> >
> > Rainer
> >
> > Shekar Tippur schrieb:
> > > Hello
> > >
> > > We are getting unable to get the free endpoint and eventually
> > resulting
> > > in a 500 (internal server error).
> > >
> > > We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many
> > > reasons,
> > > we are not in a position to upgrade wither of these packages.
> > >
> > > [Fri Dec 08 01:34:09 2006] [18477:] [warn]
> > > ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free
> > > endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006]
> > > [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't
> > > find free endpoint [Fri Dec 08 01:34:09 2006] [18477:]  myWorker
> > > 0.88
> > >
> > > Under these situations, we also see that either jboss threads are
> > > processing
> > > for a long time OR a particular thread is idle for a relatively long
> > time.
> > >
> > > I would really appreciate if someone can explain why this particular
> > error
> > > occurs and how to remediate the problem. Currently we are restarting
> > both
> > > jboss and apache but we are not able to get to the root cause of the
> >
> > > problem.
> > >
> > > People who have got the same error earlier have suggested that we
> > need
> > > to increase the cachesize OR the connection_pool_si

Re: ajp connector issue - getting "Unable to get the free" in mod_jk.log file.

2006-12-19 Thread Shekar Tippur 

Rainer,

We upgraded mod_jk to 1.2.19 and we are still getting the same error in
mod_jk.

[Tue Dec 19 11:35:36 2006] [31691:] [warn]
ajp_get_endpoint::jk_ajp_common.c (2258): Unable to get the free endpoint
for worker myWorker from 1 slots
[Tue Dec 19 11:35:36 2006] [31691:] [info]
ajp_get_endpoint::jk_ajp_common.c (2272): can't find free endpoint
[Tue Dec 19 11:35:36 2006] myWorker gorgon 0.99
[Tue Dec 19 11:35:36 2006] [31691:] [info]  jk_handler::mod_jk.c (1986):
Service error=0 for worker=myWorker

I would really apperciate if anyone could help me on this.

Shekar

On 12/17/06, Shekar Tippur <[EMAIL PROTECTED]> wrote:


Hello,

Thanks for replying back.

I cannot see any specal requests but there maybe high load. I can see 193
active threads.

We are in the process of upgrading mod_jk version to 1.2.19.

Here is some of the information you wanted. Please let me know if you need
more information.

cat /proc/version

Linux version 2.6.9-34.ELsmp ([EMAIL PROTECTED]) (gcc
version 3.4.5 20051201 (Red Hat 3.4.5-2 ))


worker.properties

worker.list=jkstatus,consWorker,myWorker

# Configure Load Balancer status manager.

worker.jkstatus.type=status

worker.consWorker.port=8009
worker.consWorker.host=localhost
worker.consWorker.type=ajp13
worker.consWorker.socket_timeout=120

# Define first worker for failover
worker.myWorker.port=8010
worker.myWorker.host=localhost
worker.myWorker.type=ajp13
worker.myWorker.socket_timeout=120



apache_mod_jk.conf file


# conf/include/apache_mod_jk.conf
# global settings files for the mod jk connector

LoadModule jk_module libexec/apache_mod_jk.so

# Where to find workers.properties
JkWorkersFile /home/apache/conf/apache/mod_include/worker.properties

# Where to put jk logs
JkLogFile logs/apache/mod_jk.log

# Set the jk log level [debug/error/info]
JkLogLevel info

# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"

# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardURICompat -ForwardDirectories

# Configure Load Balancer status manager.

#JkWorkerProperties worker.jkstatus.type=status

# status for later load balancing


JkMount /jkstatus/*
Order deny,allow
Deny from all
Allow from 127.0.0.1


JkMount /jkmanager/* jkstatus

On 12/16/06, Rainer Jung <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> this looks strange. Could you please post your config and give a couple
> of details about your environment (OS+Version). Is there any pattern
> related to the problem (special requests, high load, ...)?
>
> It would be really good, if you could update mod_jk to 1.2.19 or 1.2.20
> which will most likely be available middle of next week.
>
> Regards,
>
> Rainer
>
> Shekar Tippur schrieb:
> > Hello
> >
> > We are getting unable to get the free endpoint and eventually
> resulting
> > in a 500 (internal server error).
> >
> > We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many
> > reasons,
> > we are not in a position to upgrade wither of these packages.
> >
> > [Fri Dec 08 01:34:09 2006] [18477:] [warn]
> > ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free
> > endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006]
> > [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't
> > find free endpoint [Fri Dec 08 01:34:09 2006] [18477:]  myWorker
> > 0.88
> >
> > Under these situations, we also see that either jboss threads are
> > processing
> > for a long time OR a particular thread is idle for a relatively long
> time.
> >
> > I would really appreciate if someone can explain why this particular
> error
> > occurs and how to remediate the problem. Currently we are restarting
> both
> > jboss and apache but we are not able to get to the root cause of the
> > problem.
> >
> > People who have got the same error earlier have suggested that we need
> > to increase the cachesize OR the connection_pool_size of the worker.
> >
> > but mod_jk documentation says that it is not recommended to use
> > cachesize more than 1 for apache version 1.3.x.
> >
> > I would really appreciate if anyone can suggest a remediation for this
> > issue.
> >
> > Shekar
> >
> > -
> > cachesize
> >
> > This directive has been deprecated since 1.2.16.
> > Cachesize defines the number of connections made to the AJP backend
> > that are maintained as a connection pool. It will limit the number of
> > those connection that each web server child process can make.
> >
> > Cachesize property is used only for multi threaded web servers such as
> > Apache 2.0 (worker), IIS and Netscape. The cachesize property should
> > reflect the number of threads per child process. JK will discover the
> > number of threads per child process on Apache 2 web server with
> > worker-mpm and set its default value to match the ThreadsPerChild
> > Apache directive. For IIS the default value is 10. For other web
> > servers thi

Re: ajp connector issue - getting "Unable to get the free" in mod_jk.log file.

2006-12-17 Thread Shekar Tippur 

Hello,

Thanks for replying back.

I cannot see any specal requests but there maybe high load. I can see 193
active threads.

We are in the process of upgrading mod_jk version to 1.2.19.

Here is some of the information you wanted. Please let me know if you need
more information.

cat /proc/version

Linux version 2.6.9-34.ELsmp ([EMAIL PROTECTED]) (gcc
version 3.4.5 20051201 (Red Hat 3.4.5-2))


worker.properties

worker.list=jkstatus,consWorker,myWorker

# Configure Load Balancer status manager.

worker.jkstatus.type=status

worker.consWorker.port=8009
worker.consWorker.host=localhost
worker.consWorker.type=ajp13
worker.consWorker.socket_timeout=120

# Define first worker for failover
worker.myWorker.port=8010
worker.myWorker.host=localhost
worker.myWorker.type=ajp13
worker.myWorker.socket_timeout=120



apache_mod_jk.conf file


# conf/include/apache_mod_jk.conf
# global settings files for the mod jk connector

LoadModule jk_module libexec/apache_mod_jk.so

# Where to find workers.properties
JkWorkersFile /home/apache/conf/apache/mod_include/worker.properties

# Where to put jk logs
JkLogFile logs/apache/mod_jk.log

# Set the jk log level [debug/error/info]
JkLogLevel info

# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "

# JkRequestLogFormat set the request format
JkRequestLogFormat "%w %V %T"

# JkOptions indicate to send SSL KEY SIZE,
JkOptions +ForwardURICompat -ForwardDirectories

# Configure Load Balancer status manager.

#JkWorkerProperties worker.jkstatus.type=status

# status for later load balancing


   JkMount /jkstatus/*
   Order deny,allow
   Deny from all
   Allow from 127.0.0.1


JkMount /jkmanager/* jkstatus

On 12/16/06, Rainer Jung <[EMAIL PROTECTED]> wrote:


Hi,

this looks strange. Could you please post your config and give a couple
of details about your environment (OS+Version). Is there any pattern
related to the problem (special requests, high load, ...)?

It would be really good, if you could update mod_jk to 1.2.19 or 1.2.20
which will most likely be available middle of next week.

Regards,

Rainer

Shekar Tippur schrieb:
> Hello
>
> We are getting unable to get the free endpoint and eventually resulting
> in a 500 (internal server error).
>
> We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many
> reasons,
> we are not in a position to upgrade wither of these packages.
>
> [Fri Dec 08 01:34:09 2006] [18477:] [warn]
> ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free
> endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006]
> [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't
> find free endpoint [Fri Dec 08 01:34:09 2006] [18477:]  myWorker
> 0.88
>
> Under these situations, we also see that either jboss threads are
> processing
> for a long time OR a particular thread is idle for a relatively long
time.
>
> I would really appreciate if someone can explain why this particular
error
> occurs and how to remediate the problem. Currently we are restarting
both
> jboss and apache but we are not able to get to the root cause of the
> problem.
>
> People who have got the same error earlier have suggested that we need
> to increase the cachesize OR the connection_pool_size of the worker.
>
> but mod_jk documentation says that it is not recommended to use
> cachesize more than 1 for apache version 1.3.x.
>
> I would really appreciate if anyone can suggest a remediation for this
> issue.
>
> Shekar
>
> -
> cachesize
>
> This directive has been deprecated since 1.2.16.
> Cachesize defines the number of connections made to the AJP backend
> that are maintained as a connection pool. It will limit the number of
> those connection that each web server child process can make.
>
> Cachesize property is used only for multi threaded web servers such as
> Apache 2.0 (worker), IIS and Netscape. The cachesize property should
> reflect the number of threads per child process. JK will discover the
> number of threads per child process on Apache 2 web server with
> worker-mpm and set its default value to match the ThreadsPerChild
> Apache directive. For IIS the default value is 10. For other web
> servers this value has to be set manually.
>
> Do not use cachesize with values higher then 1 on Apache 2.x prefork or
> Apache 1.3.x!
>
> ---
>
> Shekar
>

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: ajp connector issue - getting "Unable to get the free" in mod_jk.log file.

2006-12-16 Thread Rainer Jung 
Hi,

this looks strange. Could you please post your config and give a couple
of details about your environment (OS+Version). Is there any pattern
related to the problem (special requests, high load, ...)?

It would be really good, if you could update mod_jk to 1.2.19 or 1.2.20
which will most likely be available middle of next week.

Regards,

Rainer

Shekar Tippur schrieb:
> Hello
> 
> We are getting unable to get the free endpoint and eventually resulting
> in a 500 (internal server error).
> 
> We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many
> reasons,
> we are not in a position to upgrade wither of these packages.
> 
> [Fri Dec 08 01:34:09 2006] [18477:] [warn]
> ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free
> endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006]
> [18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't
> find free endpoint [Fri Dec 08 01:34:09 2006] [18477:]  myWorker
> 0.88
> 
> Under these situations, we also see that either jboss threads are
> processing
> for a long time OR a particular thread is idle for a relatively long time.
> 
> I would really appreciate if someone can explain why this particular error
> occurs and how to remediate the problem. Currently we are restarting both
> jboss and apache but we are not able to get to the root cause of the
> problem.
> 
> People who have got the same error earlier have suggested that we need
> to increase the cachesize OR the connection_pool_size of the worker.
> 
> but mod_jk documentation says that it is not recommended to use
> cachesize more than 1 for apache version 1.3.x.
> 
> I would really appreciate if anyone can suggest a remediation for this
> issue.
> 
> Shekar
> 
> -
> cachesize
> 
> This directive has been deprecated since 1.2.16.
> Cachesize defines the number of connections made to the AJP backend
> that are maintained as a connection pool. It will limit the number of
> those connection that each web server child process can make.
> 
> Cachesize property is used only for multi threaded web servers such as
> Apache 2.0 (worker), IIS and Netscape. The cachesize property should
> reflect the number of threads per child process. JK will discover the
> number of threads per child process on Apache 2 web server with
> worker-mpm and set its default value to match the ThreadsPerChild
> Apache directive. For IIS the default value is 10. For other web
> servers this value has to be set manually.
> 
> Do not use cachesize with values higher then 1 on Apache 2.x prefork or
> Apache 1.3.x!
> 
> ---
> 
> Shekar
> 

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

ajp connector issue - getting "Unable to get the free" in mod_jk.log file.

2006-12-14 Thread Shekar Tippur 

Hello

We are getting unable to get the free endpoint and eventually resulting
in a 500 (internal server error).

We are using apache 1.3.37 and mod_jk version is 1.2.15. Due to many
reasons,
we are not in a position to upgrade wither of these packages.

[Fri Dec 08 01:34:09 2006] [18477:] [warn]
ajp_get_endpoint::jk_ajp_common.c (2138): Unable to get the free
endpoint for worker myWorker from 1 slots [Fri Dec 08 01:34:09 2006]
[18477:] [info] ajp_get_endpoint::jk_ajp_common.c (2152): can't
find free endpoint [Fri Dec 08 01:34:09 2006] [18477:]  myWorker
0.88

Under these situations, we also see that either jboss threads are processing
for a long time OR a particular thread is idle for a relatively long time.

I would really appreciate if someone can explain why this particular error
occurs and how to remediate the problem. Currently we are restarting both
jboss and apache but we are not able to get to the root cause of the
problem.

People who have got the same error earlier have suggested that we need
to increase the cachesize OR the connection_pool_size of the worker.

but mod_jk documentation says that it is not recommended to use
cachesize more than 1 for apache version 1.3.x.

I would really appreciate if anyone can suggest a remediation for this
issue.

Shekar

-
cachesize

This directive has been deprecated since 1.2.16.
Cachesize defines the number of connections made to the AJP backend
that are maintained as a connection pool. It will limit the number of
those connection that each web server child process can make.

Cachesize property is used only for multi threaded web servers such as
Apache 2.0 (worker), IIS and Netscape. The cachesize property should
reflect the number of threads per child process. JK will discover the
number of threads per child process on Apache 2 web server with
worker-mpm and set its default value to match the ThreadsPerChild
Apache directive. For IIS the default value is 10. For other web
servers this value has to be set manually.

Do not use cachesize with values higher then 1 on Apache 2.x prefork or
Apache 1.3.x!

---

Shekar