Am 2020-02-13 10:57, schrieb Olivier Jaquemet:
On 13/02/2020 10:32, Rémy Maucherat wrote:
On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet wrote:
On 13/02/2020 01:02, Stefan Mayr wrote:
- AJP defaults changed to listen the loopback address, require a
secret
and to be disabled in the sample server.xml
[snip]
Am I correct ? Why such a change ? Why no bugzilla issue for proper
tracking and context ?
What are your recommendations regarding AJP connector configuration ?
It is obviously best to keep default configurations as stable as
possible.
But sometimes things have to change ... As a result, you'll indeed
need to
adjust your server.xml according to your deployment and AJP usage.
Thank you Rémy for taking the time to answer.
I understand the need to introduce a "secured by default" AJP
configuration.
However, I question one choice that was made for this change : the
default behavior of the AJP connector to listen only on the loopback
address.
+1
This is the change which is, to me, the most questionable one. Because
to my understanding, any architecture in which a remote Apache HTTPD
is being used will require a *specific IP address of the current host*
to be specified in the address attribute of the AJP connector. A
specific IP address means that the server.xml is no longer agnostic to
the platfom it is being hosted on. Prior to this, a server.xml file
could be configured in such way that it would never contain any hard
coded value related to the current host. With this change it is no
longer possible. (unless I'm missing something). For large deployment
configuration, this does seems a bit problematic.
Do you understand my concern ? Is there any way to address this ?
That's really difficult. Specifically in container environments where
the container is started dynamically and the ip address shifts
frequently. Access is done through dns or labels.
(The secret attribute is less of a problem, because as stated in the
documentation there is an alternative : secretRequired can be set fo
false "when the Connector is used on a trusted network".)
Make that such a breaking change in a minor maintenance update is
quite touchy. I have never seen such drastic change in my usage
history of Tomcat.
Olivier
---------------------------------------------------------------------
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
