Re: Tomcat 8.5.51 fails
Thank you for your links. Now, I fully understand what I should make a change to server.xml. Thank you. Yours truly, Kazuhiko Kohmoto On 2020/02/13 19:17, Olaf Kock wrote: On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote: On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote: Check in the file (tomcat_dir)/conf/server.xml, the Connector : The setting is the same as mine. I have use server.xml used in 8.5.50. In case of 8.5.50, I have no problem. Please notice, I have been using Tomcat for 5 years with updates. Why this time? Because this time, security relevant defaults changed: See these recent commits on the git mirror: https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262 https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262 - 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: Tomcat 8.5.51 fails
Thank you for your kind response to my mail. I read the changinglog. I might understand the contents. Thank you. Yours truly, Kazuhiko Kohmoto On 2020/02/13 19:26, Olaf Kock wrote: On 13.02.20 11:17, Olaf Kock wrote: On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote: On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote: Check in the file (tomcat_dir)/conf/server.xml, the Connector : The setting is the same as mine. I have use server.xml used in 8.5.50. In case of 8.5.50, I have no problem. Please notice, I have been using Tomcat for 5 years with updates. Why this time? Because this time, security relevant defaults changed: See these recent commits on the git mirror: https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262 https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262 Or, even better digestible (I hit 'send' too early): Mark's announcement of the availability contained: - AJP defaults changed to listen the loopback address, require a secret and to be disabled in the sample server.xml And the changelog on http://tomcat.apache.org/tomcat-8.5-doc/changelog.html for 8.5.51 contains this information on AJP: * Update: Disable (comment out in server.xml) the AJP/1.3 connector by default. (markt) * Update: Change the default bind address for the AJP/1.3 connector to be the loopback address. (markt) * Add: Rename the |requiredSecret| attribute of the AJP/1.3 Connector to |secret| and add a new attribute |secretRequired| that defaults to |true|. When |secretRequired| is |true| the AJP/1.3 Connector will not start unless the |secret| attribute is configured to a non-null, non-zero length String. (markt) * Add: Add a new attribute, |allowedRequestAttributesPattern| to the AJP/1.3 Connector. Requests with unrecognised attributes will be blocked with a 403. (markt) There's also a discussion on the "Re: [ANN] Apache Tomcat 9.0.31 available" thread on this changed default that might give you some background. I hope, this helps, Olaf - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.51 fails
Dear André Warnier, Thank you for the following-up. I now am understanding what I should make a change on server.xml. Thank you for your kind response and Tomcat Users List's conversation. Yours truly, Kazuhiko Kohmoto PS. Sorry, not response to you quickly, because in Japan time was night. Thank you. On 2020/02/13 20:21, André Warnier (tomcat/perl) wrote: In any case, it seems that for now, you will have to modify the AJP Connector configuration in server.xml, to make it work with 8.5.51 and above, and add an explicit - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: JVM job for Tomcat taking lots and lots of CPU
Last night, we switched the customer box in question from running Tomcat under Java 7 (64-bit) to Java 8 (64-bit), and all day today, the processor load from the Tomcat server has been dramatically lighter. I haven't seen the overall CPU over around 70% today, and haven't seen the Tomcat's JVM job usage over 30% (as I type this, the overall is at 48.1%, of which the JVM job is a mere 7.8%), where before, it was peaking at full saturation, with the Tomcat JVM job alone accounting for as much as 90% or more. I am cautious about this, but I think maybe just the switch to Java 8 alone has solved the problem. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
EOL of Apache Tomcat 9
Team, What is the EOL Date for Apache Tomcat 9? Best Regards, Reneesh K
Re: [ANN] Apache Tomcat 9.0.31 available
Stafan, On 2/13/20 14:56, Stefan Mayr wrote: Hi Chris, Am 13.02.2020 um 15:31 schrieb Christopher Schultz: [snip] The answer to the question "why change the default?" is: "because the default was essentially insecure, in a way that wasn't obvious to someone who wasn't paying close attention." So we are forcing users to pay closer attention. If you want to open your AJP instance to the "whole world", then you can explicitly bind to 0.0.0.0/:: just as the previous default. Similarly, if you don't want to use the "secret" setting, then you can explicitly disable it. But the defaults will no longer let you be "insecure" without knowing it . Obviously, there are ways to have a "secure" installation while using 0.0.0.0/:: and/or secretRequired="false". But having those things in the configuration right in front of you make it clear that some decision has been made, rather than hiding (potential) danger behind insecure defaults. Okay, security is important. I'm a huge fan of secure by default and minimal default setups instead all features enabled. But I still don't understand what makes makes the AJP connector or the protocol itself so insecure. I really don't know much about it. So far this has been a technology that just works for me. Is really AJP the culprit or are you just closing all windows on the "house of tomcat" so everybody has to use the "front door" http? If you use the HTTP connector, you can use TLS. There is no TLS equivalent for AJP. If you have your proxy on localhost, then there is minimal danger (and you can bind to 127.0.0.1 safely, so no problem). If your proxy is elsewhere, you *really should* be using HTTPS (for HTTP) or something like stunnel. If you are using stunnel, then localhost binding is again what you want. It's much more obvious when you look at the HTTP connector and say "hey, that doesn't gave any TLS config on it -- let's fix that". AJP is a magic mystery to lots of people and they may think that because it's binary, it's secure. It is not. Because if having an open connector is really the argument the http connector would also (by default) have to bind to localhost only. Same as with AJP: you have to make a clear decision in the configuration to open it to the public. Is this something we have to expect in the future? The AJP connector also trusts the incoming connection in a way that the HTTP connectors do not. For example, you need to configure the RemoteIPValve[1] if you want to inherit the client's IP address for things like log files when using HTTP, but you get it "for free" with AJP. Making the decision to add the RemoteIPValve is a security choice that you don't get to make with AJP -- that choice is made for you and you can't turn it off. So it's best to force users to make security choices that they actually know about, instead of us making those choices for them in ways that can be potentially harmful. Maybe not hideously harmful... wrong IPs in your log file? Maybe not a huge deal for you. But for others, it may cause a violation of a required security control. Will this disrupt some environments? Yes, it will. But the path to fixing it is to make one (or two) small edits to your configuration files which are surely under revision-control and automatically pushed-out to these hundreds-of-nodes clusters everyone is worried about, right? Well, then, change your configs and push them out there along with your upgrade of Tomcat and all will be well. [snip] Automation is the right keyword. Sometimes it is a solution, sometimes this also causes additional problems. In our specific case the configuration management system generates server.xml from templates. Currently it can only use different templates for different major versions (7,8 or 9). Not having tried that yet I would add the new ajp connector parameters in those templates to reflect the old defaults. That would us gain some time to change the configuration management while rolling out new Tomcat versions without breaking things. Now the critical question: will this break the previous versions or will they just ignore unkown parameters? It's safe to put it in now, in preparation for a future upgrade. -chris [1] http://tomcat.apache.org/tomcat-9.0-doc/config/valve.html#Remote_IP_Valve - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 19:56, Stefan Mayr wrote: > Hi Chris, > > Am 13.02.2020 um 15:31 schrieb Christopher Schultz: >> [snip] >> The answer to the question "why change the default?" is: "because the >> default was essentially insecure, in a way that wasn't obvious to >> someone who wasn't paying close attention." >> >> So we are forcing users to pay closer attention. If you want to open >> your AJP instance to the "whole world", then you can explicitly bind >> to 0.0.0.0/:: just as the previous default. Similarly, if you don't >> want to use the "secret" setting, then you can explicitly disable it. >> But the defaults will no longer let you be "insecure" without knowing it >> . >> >> Obviously, there are ways to have a "secure" installation while using >> 0.0.0.0/:: and/or secretRequired="false". But having those things in >> the configuration right in front of you make it clear that some >> decision has been made, rather than hiding (potential) danger behind >> insecure defaults. > > Okay, security is important. I'm a huge fan of secure by default and > minimal default setups instead all features enabled. > But I still don't understand what makes makes the AJP connector or the > protocol itself so insecure. I really don't know much about it. So far > this has been a technology that just works for me. Is really AJP the > culprit or are you just closing all windows on the "house of tomcat" so > everybody has to use the "front door" http? AJP is fundamentally different to HTTP. AJP assumes that the client is trusted (and by implication that the network connection between the client and the server is secure). HTTP does not. There has been some discussion around the topic "Should we deprecate support for AJP?" but I don't think we are close to consensus on that. My own view is that while you can use either AJP or HTTP in any situation, there are some situations where one is better suited that the other and for that reason I see us keeping both for now. Might that position change in the future? Maybe, but it looks to be at least a couple of major versions away if it happens at all. > Because if having an open connector is really the argument the http > connector would also (by default) have to bind to localhost only. Same > as with AJP: you have to make a clear decision in the configuration to > open it to the public. Is this something we have to expect in the future? I don't see similar changes ever being made to the HTTP Connector. >> [snip] >> >> Will this disrupt some environments? Yes, it will. But the path to >> fixing it is to make one (or two) small edits to your configuration >> files which are surely under revision-control and automatically >> pushed-out to these hundreds-of-nodes clusters everyone is worried >> about, right? Well, then, change your configs and push them out there >> along with your upgrade of Tomcat and all will be well. >> [snip] > > Automation is the right keyword. Sometimes it is a solution, sometimes > this also causes additional problems. In our specific case the > configuration management system generates server.xml from templates. > Currently it can only use different templates for different major > versions (7,8 or 9). Not having tried that yet I would add the new ajp > connector parameters in those templates to reflect the old defaults. > That would us gain some time to change the configuration management > while rolling out new Tomcat versions without breaking things. Now the > critical question: will this break the previous versions or will they > just ignore unkown parameters? You should see a warning about the unrecognised attribute but it should otherwise be ignored. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
Hi Chris, Am 13.02.2020 um 15:31 schrieb Christopher Schultz: > [snip] > The answer to the question "why change the default?" is: "because the > default was essentially insecure, in a way that wasn't obvious to > someone who wasn't paying close attention." > > So we are forcing users to pay closer attention. If you want to open > your AJP instance to the "whole world", then you can explicitly bind > to 0.0.0.0/:: just as the previous default. Similarly, if you don't > want to use the "secret" setting, then you can explicitly disable it. > But the defaults will no longer let you be "insecure" without knowing it > . > > Obviously, there are ways to have a "secure" installation while using > 0.0.0.0/:: and/or secretRequired="false". But having those things in > the configuration right in front of you make it clear that some > decision has been made, rather than hiding (potential) danger behind > insecure defaults. Okay, security is important. I'm a huge fan of secure by default and minimal default setups instead all features enabled. But I still don't understand what makes makes the AJP connector or the protocol itself so insecure. I really don't know much about it. So far this has been a technology that just works for me. Is really AJP the culprit or are you just closing all windows on the "house of tomcat" so everybody has to use the "front door" http? Because if having an open connector is really the argument the http connector would also (by default) have to bind to localhost only. Same as with AJP: you have to make a clear decision in the configuration to open it to the public. Is this something we have to expect in the future? > [snip] > > Will this disrupt some environments? Yes, it will. But the path to > fixing it is to make one (or two) small edits to your configuration > files which are surely under revision-control and automatically > pushed-out to these hundreds-of-nodes clusters everyone is worried > about, right? Well, then, change your configs and push them out there > along with your upgrade of Tomcat and all will be well. > [snip] Automation is the right keyword. Sometimes it is a solution, sometimes this also causes additional problems. In our specific case the configuration management system generates server.xml from templates. Currently it can only use different templates for different major versions (7,8 or 9). Not having tried that yet I would add the new ajp connector parameters in those templates to reflect the old defaults. That would us gain some time to change the configuration management while rolling out new Tomcat versions without breaking things. Now the critical question: will this break the previous versions or will they just ignore unkown parameters? Regards, Stefan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 15:31, Christopher Schultz wrote: My question would be "why do so many have AJP connectors where no 'address' attribute was specifically configured?" The answer to the question "why change the default?" is: "because the default was essentially insecure, in a way that wasn't obvious to someone who wasn't paying close attention." So we are forcing users to pay closer attention. If you want to open your AJP instance to the "whole world", then you can explicitly bind to 0.0.0.0/:: just as the previous default. Similarly, if you don't want to use the "secret" setting, then you can explicitly disable it. But the defaults will no longer let you be "insecure" without knowing it . Obviously, there are ways to have a "secure" installation while using 0.0.0.0/:: and/or secretRequired="false". But having those things in the configuration right in front of you make it clear that some decision has been made, rather than hiding (potential) danger behind insecure defaults. Why make this change in a point-release and not a major one? Because we felt it was important enough to do so. Will this disrupt some environments? Yes, it will. But the path to fixing it is to make one (or two) small edits to your configuration files which are surely under revision-control and automatically pushed-out to these hundreds-of-nodes clusters everyone is worried about, right? Well, then, change your configs and push them out there along with your upgrade of Tomcat and all will be well. - -chris Thank you Christopher for those complements. And thank you all for your disponibility. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Peter, On 2/13/20 5:05 AM, logo wrote: > > > 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. My question would be "why do so many have AJP connectors where no 'address' attribute was specifically configured?" The answer to the question "why change the default?" is: "because the default was essentially insecure, in a way that wasn't obvious to someone who wasn't paying close attention." So we are forcing users to pay closer attention. If you want to open your AJP instance to the "whole world", then you can explicitly bind to 0.0.0.0/:: just as the previous default. Similarly, if you don't want to use the "secret" setting, then you can explicitly disable it. But the defaults will no longer let you be "insecure" without knowing it . Obviously, there are ways to have a "secure" installation while using 0.0.0.0/:: and/or secretRequired="false". But having those things in the configuration right in front of you make it clear that some decision has been made, rather than hiding (potential) danger behind insecure defaults. Why make this change in a point-release and not a major one? Because we felt it was important enough to do so. Will this disrupt some environments? Yes, it will. But the path to fixing it is to make one (or two) small edits to your configuration files which are surely under revision-control and automatically pushed-out to these hundreds-of-nodes clusters everyone is worried about, right? Well, then, change your configs and push them out there along with your upgrade of Tomcat and all will be well. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5FXaMACgkQHPApP6U8 pFgTYw/+IjsZW/64GZlOTuH2AcQALHGXrEfjSxQqmtG40DefwJegg6PbxwZFenJg b9lns+vgq7SGmVWbOG8loVJg4yos6d5B2dIkwTD9KFIJU14xygSCkEMwLimP7Syi lyFR90wH5+2rI5bpP1Iir9Ybt2+GBGPjzkcmRHNb+5E3xikfpZ3g5kE41mey+Y/A Zx/R8CAqnSw161JMKysRrV4Jm+a30r3YQyll5m2CiGvP2zEc6gt4loQVXG0/ngQH qUQOk1FMyUdRFgg6fKrm0uHaWyUxt+kNXkEC9d6oEAVziftGKmn91qkb+ywRFgme hI/JJK+d2OKqXlj2OLHuZLPTojodOEckRzy4vArbSTnAAYO9f3xkb/DBqxYQSOk+ WFFbGYvgGtuwzmu3lliAPVNvUwMLqyu7aBfxDEugttHiwPh4bZUK7CxSoStHhda2 w8qqldItJC3dsxUw+u8czP/JSb1JR93lwo3/ryWIMJHMC0aECdv3W+Um87kjrGF9 FdNgevEmrhNlCBzARK/xJaVb3oHclHi6HRg7nIGdSsvNrrOqTgRCaAVQD/TFSYWh Ej5x10Ai0MPZfy+4xqiedpc4Tw7sj6JLNBoXDxwlOhZhX4en31p0xuDdgqs6ScWS ostbxlUJtQHVTa53mFca/yzj0OTDs8Xq/dNOr0y0hnl2UIR9IKY= =0DJu -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [ANN] Apache Tomcat 9.0.31 available
From: Mark Thomas mailto:ma...@apache.org>> Date: Thursday, Feb 13, 2020, 7:38 AM To: users@tomcat.apache.org mailto:users@tomcat.apache.org>> Subject: Re: [ANN] Apache Tomcat 9.0.31 available On 13/02/2020 12:42, jonmcalexan...@wellsfargo.com.INVALID wrote: > Can you still use a shared secret, if desired, while “ > You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour > of listening on any address > “ >Yes. >Use (or not) of a secret is independent of the listening address. >Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org Thanks!
Re: Potential bug in StandardSession and DeltaSession
Hi, forget about the potential bug. Sorry for taking your time. Seems like that WriteAbortedException is thrown when reading object data occasionally. AFAIK I understand it, it's just like a container exception; the actual error is stored in the exception's cause. Uh... that's odd... Carsten Hi there, Chris, thanks for your fast GIT introduction :) I took this as a (mental) starting point for developing the new 'persistAuthentication' option of the Managers (Standard and Persistent). Almost there... I will push this branch to my GitHub fork as soon as possible (tomorrow?). Maybe you (and also Mark) could have a look at it before I open a Bugzilla enhancement? During that, I may have found a bug in both StandardSession and DeltaSession. In both classes, there is a doReadObject method, which loads the session from storage. When reading session attributes, the code expects de-serialization failures for attribute values. Although each class does this a bit differently, both classes do catch a WriteAbortedException and log/continue if that exception's getCause() returns an instance of NotSerializableException. For any other cause, the WriteAbortedException gets re-thrown. AFAIK, those exceptions are never thrown when reading from an ObjectInputStream. Maybe that's a copy and paste bug? Method readObject should throw ClassNotFoundException and any subclass of ObjectStreamException except WriteAbortedException and NotSerializableException. Carsten - 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: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 12:42, jonmcalexan...@wellsfargo.com.INVALID wrote: > Can you still use a shared secret, if desired, while “ > You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour > of listening on any address > “ Yes. Use (or not) of a secret is independent of the listening address. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Potential bug in StandardSession and DeltaSession
Hi there, Chris, thanks for your fast GIT introduction :) I took this as a (mental) starting point for developing the new 'persistAuthentication' option of the Managers (Standard and Persistent). Almost there... I will push this branch to my GitHub fork as soon as possible (tomorrow?). Maybe you (and also Mark) could have a look at it before I open a Bugzilla enhancement? During that, I may have found a bug in both StandardSession and DeltaSession. In both classes, there is a doReadObject method, which loads the session from storage. When reading session attributes, the code expects de-serialization failures for attribute values. Although each class does this a bit differently, both classes do catch a WriteAbortedException and log/continue if that exception's getCause() returns an instance of NotSerializableException. For any other cause, the WriteAbortedException gets re-thrown. AFAIK, those exceptions are never thrown when reading from an ObjectInputStream. Maybe that's a copy and paste bug? Method readObject should throw ClassNotFoundException and any subclass of ObjectStreamException except WriteAbortedException and NotSerializableException. Carsten - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Error: Cannot start container [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: Deployable [http://localhost:2990/cargocpc/index.html] failed to finish deploying with
On Thu, Feb 13, 2020, 05:17 wrote: > I am trying to run one new plugin of jira using tomcat. But tomcat is not > getting started due to below error. Can you please let me know how this > error can be resolved? > > I am using Apache Tomcat Version 8.5.35. > > Error is as below. > > [ERROR] Failed to execute goal > com.atlassian.maven.plugins:amps-dispatcher-maven-plugin:8.0.2:run > (default-cli) on project newplugin05: Cannot start container > [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: > Deployable [http://localhost:2990/cargocpc/index.html] failed to finish > deploying within the timeout period [60]. The Deployable state is thus > unknown. -> [Help 1 > (Crosspost removed). This is not a Tomcat issue, ie, this particular error could be seen on any other app server. The issue is with AMPS starting other processes - something *else* is causing the slow startup (which is 600,000 millis here), thus the Atlassian SDK (AMPS) cannot fully complete startup. Check the other Atlassian related servers to see if there are any CPU intensive tasks running which would throttle startup.
RE: [ANN] Apache Tomcat 9.0.31 available
From: Mark Thomas mailto:ma...@apache.org>> Date: Thursday, Feb 13, 2020, 5:41 AM To: users@tomcat.apache.org mailto:users@tomcat.apache.org>> Subject: Re: [ANN] Apache Tomcat 9.0.31 available On 13/02/2020 09:57, Olivier Jaquemet wrote: > 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. > > 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 ? >You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour of listening on any address. >Mark > > (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 > Can you still use a shared secret, if desired, while “ You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour of listening on any address “ Sent with IPhone@Work - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 12:04, Olivier Jaquemet wrote: > > On 13/02/2020 12:41, Mark Thomas wrote: >> On 13/02/2020 09:57, Olivier Jaquemet wrote: >>> 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. >>> >>> [...] >> You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour >> of listening on any address. >> >> Mark > > Thank you Mark. This should address this use case. > > Would you consider adding this binding information to the documentation > (in the documentation of the address attribute) ? The migration guide might be a better place for that sort of thing. Care to suggest a suitable change to this section: http://tomcat.apache.org/migration-9.html#Tomcat_9.0.x_noteable_changes (we can copy the text to the equivalent sections for 8.5.x and 7.0.x)? > To sum up : > When migrating to Tomcat 8.5.51, 9.0.31 (and probably the next 7.0.x as > I saw you had also backported this change to the 7.0.x branch), Correct. > if your server architecture is to expose tomcat with an AJP connector, > to a remote distant front server, you can : > > either, *secure your installation* (obviously the recommended way on > untrusted network) : > > - by specifying the valid IP address on which the connector must bind; > This is done with address attribute of the AJP connector. > > - by specifying a shared secret between the front server and the > connector ; This is done with the secret attribute of the AJP connector > > > or else, if you want your server.xml to be agnostic to the running host > and remote front server, change your configuration back to the previous > behavior, *BUT ONLY IF AND ONLY IF you are on trusted network* : > > - by removing explicit bind of AJP connector, by specifying "0.0.0.0" > (IPv4) or "::" (IPv6) in the address attribute of the AJP connector > > - by removing need for shared secret between front and tomcat ; This is > done with the secretRequired="false" attribute of the AJP connector. Correct. Nice summary. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On Thu, Feb 13, 2020 at 1:04 PM Olivier Jaquemet < olivier.jaque...@jalios.com> wrote: > > On 13/02/2020 12:41, Mark Thomas wrote: > > On 13/02/2020 09:57, Olivier Jaquemet wrote: > >> 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. > >> > >> [...] > > You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour > > of listening on any address. > > > > Mark > > Thank you Mark. This should address this use case. > > Would you consider adding this binding information to the documentation > (in the documentation of the address attribute) ? > I would say no. These special address values are not specific to Tomcat, it's like documenting 127.0.0.1 is the IPv4 loopback address [I guess it's more well known ? hopefully ?]. The address specified on the Connector element goes through InetAddress.getByName so it's very flexible, it allows more than simple IP addresses. Rémy > > > To sum up : > When migrating to Tomcat 8.5.51, 9.0.31 (and probably the next 7.0.x as > I saw you had also backported this change to the 7.0.x branch), > if your server architecture is to expose tomcat with an AJP connector, > to a remote distant front server, you can : > > either, *secure your installation* (obviously the recommended way on > untrusted network) : > > - by specifying the valid IP address on which the connector must bind; > This is done with address attribute of the AJP connector. > > - by specifying a shared secret between the front server and the > connector ; This is done with the secret attribute of the AJP connector > > > or else, if you want your server.xml to be agnostic to the running host > and remote front server, change your configuration back to the previous > behavior, *BUT ONLY IF AND ONLY IF you are on trusted network* : > > - by removing explicit bind of AJP connector, by specifying "0.0.0.0" > (IPv4) or "::" (IPv6) in the address attribute of the AJP connector > > - by removing need for shared secret between front and tomcat ; This is > done with the secretRequired="false" attribute of the AJP connector. > > Olivier > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 12:41, Mark Thomas wrote: On 13/02/2020 09:57, Olivier Jaquemet wrote: 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. [...] You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour of listening on any address. Mark Thank you Mark. This should address this use case. Would you consider adding this binding information to the documentation (in the documentation of the address attribute) ? To sum up : When migrating to Tomcat 8.5.51, 9.0.31 (and probably the next 7.0.x as I saw you had also backported this change to the 7.0.x branch), if your server architecture is to expose tomcat with an AJP connector, to a remote distant front server, you can : either, *secure your installation* (obviously the recommended way on untrusted network) : - by specifying the valid IP address on which the connector must bind; This is done with address attribute of the AJP connector. - by specifying a shared secret between the front server and the connector ; This is done with the secret attribute of the AJP connector or else, if you want your server.xml to be agnostic to the running host and remote front server, change your configuration back to the previous behavior, *BUT ONLY IF AND ONLY IF you are on trusted network* : - by removing explicit bind of AJP connector, by specifying "0.0.0.0" (IPv4) or "::" (IPv6) in the address attribute of the AJP connector - by removing need for shared secret between front and tomcat ; This is done with the secretRequired="false" attribute of the AJP connector. Olivier - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Error: Cannot start container [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: Deployable [http://localhost:2990/cargocpc/index.html] failed to finish deploying with
Hi Mark, Thanks for your reply. Jira is properly installed and does not have any issue. Error is only coming when running it with tomcat. This issue is specific when deploying application using Tomcat. Kindly let me know how this issue can be resolved. Regards, Prasanna -Original Message- From: Mark Thomas Sent: Thursday, February 13, 2020 5:07 PM To: users@tomcat.apache.org Subject: Re: Error: Cannot start container [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: Deployable [http://localhost:2990/cargocpc/index.html] failed to finish deploying within the timeout period [60]. [External] Please do not cross-post to multiple lists. Usage questions belong on the users list. In this instance, since your issue is with Atlassian Jira, you'll need to contact Atlassian support. Mark On 13/02/2020 11:17, prasanna.mahap...@cognizant.com wrote: > Dear Team, > > I am trying to run one new plugin of jira using tomcat. But tomcat is not > getting started due to below error. Can you please let me know how this error > can be resolved? > If this is not the correct email id for this kind of help, then please route > me to the correct email id or support team. > > I am using Apache Tomcat Version 8.5.35. > > Error is as below. > [ERROR] Failed to execute goal > com.atlassian.maven.plugins:amps-dispatcher-maven-plugin:8.0.2:run > (default-cli) on project newplugin05: Cannot start container > [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6 > abca7a6]: Deployable [http://localhost:2990/cargocpc/index.html] > failed to finish deploying within the timeout period [60]. The > Deployable state is thus unknown. -> [Help 1] > > Thank in advance for your help. > > Best Regards, > Prasanna Mahapure > This e-mail and any files transmitted with it are for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. If you are not the intended recipient(s), please reply to the > sender and destroy all copies of the original message. Any unauthorized > review, use, disclosure, dissemination, forwarding, printing or copying of > this email, and/or any action taken in reliance on the contents of this > e-mail is strictly prohibited and may be unlawful. Where permitted by > applicable law, this e-mail and other e-mail communications sent to and from > Cognizant e-mail addresses may be monitored. This e-mail and any files > transmitted with it are for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the intended > recipient(s), please reply to the sender and destroy all copies of the > original message. Any unauthorized review, use, disclosure, dissemination, > forwarding, printing or copying of this email, and/or any action taken in > reliance on the contents of this e-mail is strictly prohibited and may be > unlawful. Where permitted by applicable law, this e-mail and other e-mail > communications sent to and from Cognizant e-mail addresses may be monitored. > B‹CB•È [œÝXœØÜšX™KK[XZ[ ˆ]‹][œÝXœØÜšX™P ÛXØ] ˜\XÚK›Ü™ÃB‘›ÜˆY][Û˜[ÛÛ[X[™ ËK[XZ[ ˆ]‹Z[ ÛXØ] ˜\XÚK›Ü™ÃBƒB This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 09:57, Olivier Jaquemet wrote: > 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. > > 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 ? You can specify "0.0.0.0" (IPv4) or "::" (IPv6) to restore the behaviour of listening on any address. Mark > > (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
Re: Error: Cannot start container [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: Deployable [http://localhost:2990/cargocpc/index.html] failed to finish deploying with
Please do not cross-post to multiple lists. Usage questions belong on the users list. In this instance, since your issue is with Atlassian Jira, you'll need to contact Atlassian support. Mark On 13/02/2020 11:17, prasanna.mahap...@cognizant.com wrote: > Dear Team, > > I am trying to run one new plugin of jira using tomcat. But tomcat is not > getting started due to below error. Can you please let me know how this error > can be resolved? > If this is not the correct email id for this kind of help, then please route > me to the correct email id or support team. > > I am using Apache Tomcat Version 8.5.35. > > Error is as below. > [ERROR] Failed to execute goal > com.atlassian.maven.plugins:amps-dispatcher-maven-plugin:8.0.2:run > (default-cli) on project newplugin05: Cannot start container > [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: > Deployable [http://localhost:2990/cargocpc/index.html] failed to finish > deploying within the timeout period [60]. The Deployable state is thus > unknown. -> [Help 1] > > Thank in advance for your help. > > Best Regards, > Prasanna Mahapure > This e-mail and any files transmitted with it are for the sole use of the > intended recipient(s) and may contain confidential and privileged > information. If you are not the intended recipient(s), please reply to the > sender and destroy all copies of the original message. Any unauthorized > review, use, disclosure, dissemination, forwarding, printing or copying of > this email, and/or any action taken in reliance on the contents of this > e-mail is strictly prohibited and may be unlawful. Where permitted by > applicable law, this e-mail and other e-mail communications sent to and from > Cognizant e-mail addresses may be monitored. This e-mail and any files > transmitted with it are for the sole use of the intended recipient(s) and may > contain confidential and privileged information. If you are not the intended > recipient(s), please reply to the sender and destroy all copies of the > original message. Any unauthorized review, use, disclosure, dissemination, > forwarding, printing or copying of this email, and/or any action taken in > reliance on the contents of this e-mail is strictly prohibited and may be > unlawful. Where permitted by applicable law, this e-mail and other e-mail > communications sent to and from Cognizant e-mail addresses may be monitored. >
Re: [ANN] Apache Tomcat 9.0.31 available
On 13.02.2020 11:05, logo wrote: 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. For info, there is also another thread entitled "Re: Tomcat 8.5.51 fails", which seems relevant to this discussion. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.51 fails
On 13.02.2020 10:36, kohm...@iris.eonet.ne.jp wrote: On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote: Check in the file (tomcat_dir)/conf/server.xml, the Connector : The setting is the same as mine. I have use server.xml used in 8.5.50. In case of 8.5.50, I have no problem. Please notice, I have been using Tomcat for 5 years with updates. Why this time? Yes, you are right, and I am sorry for my previous short answer. (I thought that you were a "newbie" installing tomcat 8.5 for the firdst time, and that you had just not configured the Connector correctly.) But Remy's answer, and the other thread "Re: [ANN] Apache Tomcat 9.0.31 available" seems to indicate that this was due to a *change* in behaviour between 8.5.50 and 8.5.51. In any case, it seems that for now, you will have to modify the AJP Connector configuration in server.xml, to make it work with 8.5.51 and above, and add an explicit secretRequired="false" attribute. And maybe also an explicit listening address.. It looks like these changes are documented here : http://tomcat.apache.org/tomcat-8.5-doc/changelog.html --> Coyote Update: Disable (comment out in server.xml) the AJP/1.3 connector by default. (markt) Update: Change the default bind address for the AJP/1.3 connector to be the loopback address. (markt) Add: Rename the requiredSecret attribute of the AJP/1.3 Connector to secret and add a new attribute secretRequired that defaults to true. When secretRequired is true the AJP/1.3 Connector will not start unless the secret attribute is configured to a non-null, non-zero length String. (markt) I think that the first change above is ok, because it only affects the distribution of newly-downloaded server.xml files. But the other two also impact existing installations just being updated, and in a way that is not very clearly indicated in the on-line documentation. That looks a bit more iffy.. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Error: Cannot start container [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: Deployable [http://localhost:2990/cargocpc/index.html] failed to finish deploying within t
Dear Team, I am trying to run one new plugin of jira using tomcat. But tomcat is not getting started due to below error. Can you please let me know how this error can be resolved? If this is not the correct email id for this kind of help, then please route me to the correct email id or support team. I am using Apache Tomcat Version 8.5.35. Error is as below. [ERROR] Failed to execute goal com.atlassian.maven.plugins:amps-dispatcher-maven-plugin:8.0.2:run (default-cli) on project newplugin05: Cannot start container [org.codehaus.cargo.container.tomcat.Tomcat8xInstalledLocalContainer@6abca7a6]: Deployable [http://localhost:2990/cargocpc/index.html] failed to finish deploying within the timeout period [60]. The Deployable state is thus unknown. -> [Help 1] Thank in advance for your help. Best Regards, Prasanna Mahapure This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored.
Re: Tomcat 8.5.51 fails
On 13.02.20 11:17, Olaf Kock wrote: > On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote: >> On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote: >>> Check in the file (tomcat_dir)/conf/server.xml, the Connector : >>> >>> >> The setting is the same as mine. >> >> I have use server.xml used in 8.5.50. In case of 8.5.50, I have no >> problem. >> >> Please notice, I have been using Tomcat for 5 years with updates. >> Why this time? > > Because this time, security relevant defaults changed: See these recent > commits on the git mirror: > > https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262 > > https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262 Or, even better digestible (I hit 'send' too early): Mark's announcement of the availability contained: > - AJP defaults changed to listen the loopback address, require a secret and to be disabled in the sample server.xml And the changelog on http://tomcat.apache.org/tomcat-8.5-doc/changelog.html for 8.5.51 contains this information on AJP: * Update: Disable (comment out in server.xml) the AJP/1.3 connector by default. (markt) * Update: Change the default bind address for the AJP/1.3 connector to be the loopback address. (markt) * Add: Rename the |requiredSecret| attribute of the AJP/1.3 Connector to |secret| and add a new attribute |secretRequired| that defaults to |true|. When |secretRequired| is |true| the AJP/1.3 Connector will not start unless the |secret| attribute is configured to a non-null, non-zero length String. (markt) * Add: Add a new attribute, |allowedRequestAttributesPattern| to the AJP/1.3 Connector. Requests with unrecognised attributes will be blocked with a 403. (markt) There's also a discussion on the "Re: [ANN] Apache Tomcat 9.0.31 available" thread on this changed default that might give you some background. I hope, this helps, Olaf
Re: Tomcat 8.5.51 fails
On 13.02.20 10:36, kohm...@iris.eonet.ne.jp wrote: > On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote: >> Check in the file (tomcat_dir)/conf/server.xml, the Connector : >> >> > > The setting is the same as mine. > > I have use server.xml used in 8.5.50. In case of 8.5.50, I have no > problem. > > Please notice, I have been using Tomcat for 5 years with updates. > Why this time? Because this time, security relevant defaults changed: See these recent commits on the git mirror: https://github.com/apache/tomcat/commit/b962835f98b905286b78c414d5aaec2d0e711f75#diff-8dc0090e11bd1ca2caa389bb79d52262 https://github.com/apache/tomcat/commit/2becbfd3228942a18b663ca715ee9c9b80743120#diff-8dc0090e11bd1ca2caa389bb79d52262 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
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
Re: [ANN] Apache Tomcat 9.0.31 available
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. 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 ? (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
Re: [ANN] Apache Tomcat 9.0.31 available
On 2020/02/13 18:32, Rémy Maucherat wrote: 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. The documentation for the new attributes and updated defaults is here: http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Standard_Implementations Thank you for your advice. Your advice seems to relate to 9.0 though, could this advice be true rative to 8.5? Thank you. Yours truly, Kazuhiko Kohmoto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.51 fails
On 2020/02/13 18:22, Rémy Maucherat wrote: need to adjust your server.xml to that I think this time problem seems not due to server.xml. The server.xml works well with 8.5.50. Thank you. Yours truly, Kazuhiko Kohmoto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.51 fails
On 2020/02/13 18:25, André Warnier (tomcat/perl) wrote: Check in the file (tomcat_dir)/conf/server.xml, the Connector : The setting is the same as mine. I have use server.xml used in 8.5.50. In case of 8.5.50, I have no problem. Please notice, I have been using Tomcat for 5 years with updates. Why this time? Thank you. Yours truly, Kazuhiko Kohmoto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On Thu, Feb 13, 2020 at 9:33 AM Olivier Jaquemet < olivier.jaque...@jalios.com> wrote: > On 13/02/2020 01:02, Stefan Mayr wrote: > > Hi, > > > >> - AJP defaults changed to listen the loopback address, require a secret > >>and to be disabled in the sample server.xml > > What was the motivation behind this breaking change to require a secret > > or to explitly disable it? What makes an open AJP connector more unsafe > > than an open HTTP connector? > > > > We have hundreds of Tomcats behind Apache httpd with mod_jk. My > > interpretation is that upgrading Tomcat 8.5 or 9.0 will break that setup > > until we disable the secret in all of them (or add a secret in mod_jk > > and Tomcat). > > I would understand that for a new major version 10.x but not in the > > lifecycle of an existing major version. > > Hi, > > I second those questions. > > We also have many tomcat instances behind Apache HTTPD, most of them are > not the same server. > It is my understanding that the new default listening behavior on the > loopback address would break our installation, as the AJP connector > would no longer be reachable to our remote Apache HTTP server. It would > requires that we update all our tomcat's server.xml configuration to > explicitely listen to an additional address by specifying the "address" > attribute of the AJP connector. > 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. The documentation for the new attributes and updated defaults is here: http://tomcat.apache.org/tomcat-9.0-doc/config/ajp.html#Standard_Implementations Rémy
Re: Tomcat 8.5.51 fails
On 13.02.2020 10:13, kohmoto wrote: Hi, I have install Tomcat 8.5.51 today and found something wrong. I have been using tomcat for last 5 years and never met this kind of problem. It would be appreciated if I could be advised. Thank you. System: CentOS 7.7.1908 httpd 2.4.41 (community version) httpd.conf: (LoadModule proxy_ajp_module lib64/httpd/modules/mod_proxy_ajp.so) httpd-proxy.conf: ProxyPass ajp://localhost:8009/manager/ tomcat 8.5.* error log--- 13-Feb-2020 17:13:12.523 重大 [main] org.apache.catalina.core.StandardService.startInternal Failed to start connector [Connector[AJP/1.3-8009]] org.apache.catalina.LifecycleException: プロトコルハンドラの起動に失敗しました ( 'fail to start protocolhandler' in English ) 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 java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) 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 Hi. The log message above : 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. seems pretty clear. Check in the file (tomcat_dir)/conf/server.xml, the Connector : and the associated on-line documentation : http://tomcat.apache.org/tomcat-8.5-doc/config/ajp.html search for "secretRequired". - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.51 fails
On Thu, Feb 13, 2020 at 10:13 AM kohmoto wrote: > Hi, > > I have install Tomcat 8.5.51 today and found something wrong. > > I have been using tomcat for last 5 years and never met this > kind of problem. > > It would be appreciated if I could be advised. > Ok, so ... > 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. > > The error message gives the explanation. The AJP defaults changed so you need to adjust your server.xml to that. Rémy
Tomcat 8.5.51 fails
Hi, I have install Tomcat 8.5.51 today and found something wrong. I have been using tomcat for last 5 years and never met this kind of problem. It would be appreciated if I could be advised. Thank you. System: CentOS 7.7.1908 httpd 2.4.41 (community version) httpd.conf: (LoadModule proxy_ajp_module lib64/httpd/modules/mod_proxy_ajp.so) httpd-proxy.conf: ProxyPass ajp://localhost:8009/manager/ tomcat 8.5.* error log--- 13-Feb-2020 17:13:12.523 重大 [main] org.apache.catalina.core.StandardService.startInternal Failed to start connector [Connector[AJP/1.3-8009]] org.apache.catalina.LifecycleException: プロトコルハンドラの起動に失敗しました ( 'fail to start protocolhandler' in English ) 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 java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:567) 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 Yours truly, Kazuhiko Kohmoto - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [ANN] Apache Tomcat 9.0.31 available
On 13/02/2020 01:02, Stefan Mayr wrote: Hi, - AJP defaults changed to listen the loopback address, require a secret and to be disabled in the sample server.xml What was the motivation behind this breaking change to require a secret or to explitly disable it? What makes an open AJP connector more unsafe than an open HTTP connector? We have hundreds of Tomcats behind Apache httpd with mod_jk. My interpretation is that upgrading Tomcat 8.5 or 9.0 will break that setup until we disable the secret in all of them (or add a secret in mod_jk and Tomcat). I would understand that for a new major version 10.x but not in the lifecycle of an existing major version. Hi, I second those questions. We also have many tomcat instances behind Apache HTTPD, most of them are not the same server. It is my understanding that the new default listening behavior on the loopback address would break our installation, as the AJP connector would no longer be reachable to our remote Apache HTTP server. It would requires that we update all our tomcat's server.xml configuration to explicitely listen to an additional address by specifying the "address" attribute of the AJP connector. Am I correct ? Why such a change ? Why no bugzilla issue for proper tracking and context ? What are your recommendations regarding AJP connector configuration ? Olivier - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
AW: JVM job for Tomcat taking lots and lots of CPU
Dear James, Dear others, I just get notice of this long thread. Sorry, if already give this suggestion. But James: If it's possible, you may use (J)VisualVM with the "VisualGC" Plugin to get some live impressions of "what's going on" with the heaps. To my experience this visual perceptions is much easy to comprehend as a long list of numbers. If JMX is enabled to use remotely, you may even run the VisualVM-Tool on a different machine. Maybe some JVM-Options like -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime -XX:+PrintAdaptiveSizePolicy -XX:+PrintTenuringDistribution -XX:+PrintStringDeduplicationStatistics may help you to let write down a log of GC activities. with greetings Guido - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
