Re: Vulnerabilities Patches
On 11/6/23 5:21 PM, Nithiyanandam BALASUBRAMANIYAN (Oneberry) wrote: I am using Tomcat Apache Version 8.5.94 in Windows server 2012. Recently received following vulnerabilities alert to fix : Short answer: you're already there. And the latest Tomcat 8 (which I just bumped a customer up to) is 8.5.95. On an IBM Midrange box, I just manually copy the keystore, our webapps, and certain configuration settings over from the old version to the new version, then find a good time to switch the customer over (which involves shutting down the old Tomcat, renaming the old and new Tomcat directories, and restarting it with the new version in place. Piece of cake. I understand that Linux, WinDoze, and Mac have ways to bump up the Tomcat version that are even easier. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Verifying Tomcat downloads
On 11/3/23 9:33 AM, Mark Thomas wrote: Alternatively, come along to the next Community Over Code conference, take part in the key signing party and join the web of trust (or just use this as the excuse to come to the conference). And as a final option (I've done it once in 20 years) you can always arrange to meet a release manager face to face to have your own 2-person key signing party. Offers of $beverages can help facilitate this ;) Thanks, Mr. Thomas. Interesting. But I'm nearly a month late for this year's conference, and while I enjoyed the few days I spent in Halifax, as part of a pre-COVID fall vacation in Canada, I haven't left California since the COVID pandemic began. If there's anybody in Orange County, California, who can legitimately get me into the web of trust (I don't have any key of my own to exchange; I've never needed one), I'll be happy to buy that individual lunch sometime. But for now, I'll simply take your word that "the KEYS file is protected to the same degree that the source code is protected." Which is still an improvement over not bothering to verify anything. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Verifying Tomcat downloads
Forgive me if this might be a bit off-topic. But I haven't found a lot of resources on the subject (and that includes a search of List archives). For years now, I've been ignoring the note on the Tomcat download pages to verify the downloads, preferably by their PGP signatures, before putting them into service. This time, though, I decided to follow the instructions. I installed GPG, imported the KEYS file, and checked the signatures. But everything I've read about GPG, and PGP signature checking, says it's meaningless unless the keys are verified as genuine. Is there a procedure for doing this? A few days ago, I privately emailed a well-known Tomcat developer, one who has helped me with technical matters in the past, asking for a fingerprint verification. I've heard nothing back (then again, he hasn't been heard from on-List in a few days, so he may be away). -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
I forget: does Tomcat have any problems with *not* having a ROOT context?
I probably asked the question before, but does Tomcat have any problems with not having a ROOT context? -- James H. H. Lampert Touchtone Corporation - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Java Keystores work. And I don't find them especially difficult to work with (other than new formats not being backward-compatible with older JVMs, and as one who has made a comfortable living banging out code for IBM Midrange boxes for over a quarter century, I am quite familiar with a much worse variation on that theme, namely, unless you explicitly set the TGTRLS parameter (and have the appropriate previous version compiler installed, and don't need to go back more than it will let you), your programs will not even *restore* onto a prior release system. And the one time I attempted to get anything other than a Java Keystore to work in Tomcat, on an IBM Midrange box, I failed miserably. Putting shell-script wrappers around two different versions of keytool on my work Mac, so that "keytool" launches the Java 8 version, and "keytool-default" launches the default version (in the unlikely event that I'd ever need it) was a relatively simple exercise. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Solution to "Invalid keystore format" (cross-posted to Tomcat Users List at Apache, and Java 400 List at Midrange)
Ladies and Gentlemen of Both Lists: Last Friday evening, I ran into a problem updating SSL/TLS keystores on two customer boxes, and spent three hours yesterday, finding the cause, doping out a way to salvage the certs they'd paid for, and doping out a solution to keep it from happening in the future. It seems that with the new keystores (generated on my Mac, initially created with Keytool, and then maintained with Keystore Explorer), they were getting: > Throwable occurred: java.io.IOException: Invalid keystore format > at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source) > at java.security.KeyStore.load(KeyStore.java:414) I put them back on their old keystores, and cycled Tomcat again, to get them back up, and then spent three hours working the problem yesterday (Sunday) afternoon. It turns out that the default keytool on my new Mac is the one from Java 17. And the customer boxes are running Tomcat under much older JVMs, because there's always a significant time lag before any given JVM makes it to an IBM Midrange box. So I was able to salvage one of the certs (and its CA reply, and its chain) by moving the cert to a keystore generated on my *old* Mac (with Java 8 as the default JVM), and then re-signing and re-chaining it in KSE. And I tested the KS on our V6 box, to make *sure* it worked. I then looked for a way, since my new Mac *has* a Java 8 JVM (it's just not the default), to conveniently use that JVM's Keytool, and came up with a wrapper BASH script to do the job. I tested the wrapper script by using it to generate their new keystore. Key takeaway (no pun intended) here: if you get an "Invalid keystore format" in Tomcat (or presumably anything else that uses Java Keystores), when generating a keystore on one box for use on another, *look for a difference in JVM.* -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange problem involving the word "localhost"
On 9/8/23 8:34 AM, Ivano Luberti wrote: I had similar problem with mod_security installed on servers and apache used as proxy. mod_security intercept the request and if considers it suspicious generate a 403 error Found it. It's in the AWS WAF. A rule called "AWS#AWSManagedRulesCommonRuleSet#EC2MetaDataSSRF_BODY" seems to be the problem. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Strange problem involving the word "localhost"
Yesterday, I discovered that our Tomcat-based webapp (running on a Amazon AWS) doesn't like the word "localhost." If I enter it in a text field, through the UI, it won't save the record, and if I feed it into our web services, it comes back with a 403:Forbidden. My primary hypothesis is that the 403 is coming from an AWS firewall rule, because that was the cause of our last 403 problem. But is there anything in Tomcat that could be doing this? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2023-34981 Apache Tomcat - Information disclosure
Funny thing: we recently needed to update a customer's Tomcat because they were complaining about a security issue that had prompted 8.5.88. And by the time we got the update request, 8.5.89 was already out, but we hadn't yet heard of CVE-2023-34981. So we'd already skipped over 8.5.88 before we were even aware that it had a problem. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
keyPass and keystorePass
According to the Tomcat 7 configuration reference, keystorePass, if not specified, defaults to the value (specified or default) of keyPass. The Tomcat 8.5 configuration reference doesn't say this; is it still true? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Too many certificates in chain?!? Help!
On 5/23/23 10:02 AM, Rob Sargent wrote: Does pathLen:0 mean "no limit" or "no go"? Well given that the "Basic Constraints" are exactly the same, across the board, in *both* the keystores that worked fine and the keystore that blew up, I don't think that's a factor. And the fact that the keystore that blew up changed file length on the outbound FTP trip and changed back to the original file length on the inbound binary-mode FTP trip (and is the only time I can recall *ever* seeing a keystore change file length) probably *is* a factor. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Too many certificates in chain?!? Help!
On 5/23/23 8:31 AM, Christopher Schultz wrote: Can you dump the whole cert (e.g. keytool -list -v -alias 'certname') for each cert and see if any of the certificates specify a maximum chain length somewhere? Evidently, it's an extension to the X.509 spec: Comparing one that worked with one that blew up, they have the same values for all of the "basic constraints" sections: the site cert shows BasicConstraints:[ CA:false PathLen: undefined ] the intermediate cert shows BasicConstraints:[ CA:true PathLen:0 ] and the root cert shows BasicConstraints:[ CA:true PathLen: no limit ] As I said last week, given that (1) I could not reproduce the problem in four different attempts, and (2) the file size on the "problem" keystore changed when the keystore was sent to the customer box, *and then changed back* when I sent it back, I'm chalking this up to an extremely freaky fluke. But thanks, Christopher, for taking a look at the problem. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Too many certificates in chain?!? Help!
On 5/18/23 1:57 PM, Thomas Hoffmann (Speed4Trade GmbH) wrote: So the error is raised not by tomcat but by the ibm JDK. Yes. The results reported in my latest email say as much. Those results also say that there's something different -- radically different, judging from the amount of red that showed up in Hex Fiend -- between a keystore signed and chained on my new M2 Mac Mini, and a keystore signed and chained on my old 2017 iMac, both starting from the same original keystore, and the same CA certs, using the same version of KeyStore Explorer. Just now, I thought I'd found something: I thought maybe it was the "Zulu-8" ARM-native Java 8 JVM that is currently the default on the M2 Mini. I temporarily pulled Zulu-8 out, forcing KeyStore Explorer to run under an Intel-native JVM. I tried signing and chaining the keystore, putting it on the customer box, and doing a keytool -list -v on it. It liked it. No out-of-memory, no excessive (and maddeningly unspecified) chain length. And I was immediately certain that it was the Zulu-8. But then I tried putting Zulu-8 back in, and doing the sign-and-chain operation under it. And it passed the keytool test just fine. Twice, with a reboot of my Mini in between. Just for grins, I also ran the keytool test on all five keystore versions on our cloud AS/400 (where it would NOT be good to shut down the Tomcat server). There, too, the *only* one that failed was the one that failed on the customer box. I did, however, notice something else: all five of them are 5486 bytes long at this end. As is the one that I sent back from the customer box. And all of the ones that worked properly are 5486 bytes as received on both remote AS/400s. But the bad one was 5515 bytes long as received on both remote AS/400s! I'm sorely tempted to fire up the local AS/400 I was using earlier today, AGAIN!, and see how big it was, as received (being transferred directly, rather than through a private FTP server). At this point, I'm calling it a fluke. Some freak glitch with that specific sign-and-chain operation, that caused AS/400s to not like it. Unless somebody else has a better explanation. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Too many certificates in chain?!? Help!
Weirder and weirder. (And hopefully, my previous email, with a catalina.out excerpt as an attachment, actually got distributed to the List.) I copied the cert and the unsigned keystore from my new Mac (M2 Mini, running Ventura) to my old Mac (2017 iMac, running Catalina), and signing and chaining it there (again, in KeyStore Explorer). I did a diff on the two signed/chained keystores. The file lengths are the same, but diff found (but didn't specify) the differences. I put the version from the iMac on the customer box, and tried a keytool -list -v on it, from the customer box. It choked on the one from yesterday, signed and chained on the M2 Mini, but it liked the one from today, signed and chained on the 2017 iMac. I installed "Hex Fiend," and did a binary comparison of the two signed, chained keystores. It showed *A LOT* of red. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Too many certificates in chain?!? Help!
On 5/18/23 12:18 AM, Thomas Hoffmann (Speed4Trade GmbH) wrote: Which version of tomcat do you use? Is the stack trace truncated in your mail? Is there a "caused by ..." further down the stacktrace? It looks like the error is thrown deeper in SSLUtil when creating the ssl context. Maybe you can post the full stack trace. It just gets weirder. FYI, The customer box is on Tomcat 8.5.73, running under IBM Java 8.0.7.20 - pap6480sr7fp20-20221020_01(SR7 FP20), under OS/400 V7R3M0. I fired up one of our on-site AS/400s (V6R1M0), with a Tomcat server (7.0.108, running under Java 6), and started plugging in keystores. First, I plugged in the initial self-signed keystore. No problem; launched just fine. Then I plugged in the signed-and-chained keystore. Still no problem; launched just fine. Then I plugged in a copy of the signed-and-chained keystore that I'd sent back from the customer box. STILL no problem! I also did a "keytool -list -v -keystore x.ks" on both the new keystore and the one that worked, on my own Mac. No problems at all, and they looked very similar. But when I tried doing it on the customer AS/400, I got very similar error messages to what's in catalina.out. I don't ordinarily send attachments to list servers, but the "how to ask questions the smart way" said it should be OK, if small and relevant, and stacktraces tend to get a bit garbled if sent inline, so I've attached a brief catalina.out excerpt. -- JHHL17-May-2023 19:33:28.162 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["https-jsse-nio-443"] JVMDUMP039I Processing dump event "systhrow", detail "java/lang/OutOfMemoryError" at 2023/05/17 19:33:32 - please wait. JVMDUMP032I JVM requested System dump using '//core.20230517.193332.26378.0001.dmp' in response to an event JVMDUMP010I System dump written to //core.20230517.193332.26378.0001.dmp JVMDUMP032I JVM requested Heap dump using '//heapdump.20230517.193332.26378.0002.phd' in response to an event JVMDUMP010I Heap dump written to //heapdump.20230517.193332.26378.0002.phd JVMDUMP032I JVM requested Java dump using '//javacore.20230517.193332.26378.0003.txt' in response to an event JVMDUMP010I Java dump written to //javacore.20230517.193332.26378.0003.txt JVMDUMP032I JVM requested Snap dump using '//Snap.20230517.193332.26378.0004.trc' in response to an event JVMDUMP010I Snap dump written to //Snap.20230517.193332.26378.0004.trc JVMDUMP013I Processed dump event "systhrow", detail "java/lang/OutOfMemoryError". 17-May-2023 19:34:12.173 SEVERE [main] org.apache.catalina.core.StandardService.initInternal Failed to initialize connector [Connector[org.apache.coyote.http11.Http11Protocol-443]] org.apache.catalina.LifecycleException: Protocol handler initialization failed at org.apache.catalina.connector.Connector.initInternal(Connector.java:1076) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:552) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:843) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:136) at org.apache.catalina.startup.Catalina.load(Catalina.java:639) at org.apache.catalina.startup.Catalina.load(Catalina.java:662) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:305) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:475) Caused by: java.lang.IllegalArgumentException: Too many certificates in chain at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:246) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1161) at org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:222) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:599) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80) at org.apache.catalina.connector.Connector.initInternal(Connector.java:1074) ... 13 more Caused by: java.io.IOException: Too many certificates in chain at com.ibm.crypto.provider.JavaKeyStore.engineLoad(Unknown Source) at com.ibm.crypto.provider.bg.engineLoad(Unknown Source) at com.ibm.crypto.provider.JavaKeyStore$DualFormatJKS.engineLoad(Unknown Source) at
Re: Too many certificates in chain?!? Help!
On 5/17/23 5:10 PM, Jason Tan wrote: Have a look at this. https://success.qualys.com/discussions/s/question/0D52L4To0DUSAZ/your-ssl-server-test-incorrectly-reports-an-incomplete-chain That's actually my own thread, from a few years ago. The problem here is not an incomplete chain, and neither is it prior problem of the supporting certs being *included* in the keystore, rather than *chained* (a subtlety I didn't understand at the time). That problem caused security scans to raise red flags. This one is keeping Tomcat from opening the port. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Too many certificates in chain?!? Help!
Ladies and Gentlemen: I just had to revert a customer Tomcat server immediately after plugging in a new keystore. It failed in protocol handler initialization. Caused by: java.lang.IllegalArgumentException: Too many certificates in chain at org.apache.tomcat.util.net.AbstractJsseEndpoint.createSSLContext(AbstractJsseEndpoint.java:100) at org.apache.tomcat.util.net.AbstractJsseEndpoint.initialiseSsl(AbstractJsseEndpoint.java:72) at org.apache.tomcat.util.net.NioEndpoint.bind(NioEndpoint.java:246) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:1161) at org.apache.tomcat.util.net.AbstractJsseEndpoint.init(AbstractJsseEndpoint.java:222) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:599) at org.apache.coyote.http11.AbstractHttp11Protocol.init(AbstractHttp11Protocol.java:80) at org.apache.catalina.connector.Connector.initInternal(Connector.java:1074) . . . I've never seen anything like this before. According to KeyStore Explorer 5.4.4, the chain consists of a root, an intermediate, and the signed certificate for the web site. And the root and intermediate are exactly the same root and intermediate as the last good keystore. Can anybody shed any light on what went wrong? Tomorrow morning, I'm going to try plugging the keystore into a Tomcat server on an AS/400 in the office, to see if I can reproduce it. -- James H. H. Lampert - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: catalina.out, was Re: Connector definitions
On 3/8/23 4:06 PM, Christopher Schultz wrote: SOP for systemd is to redirect stdout/stderr for the process into its own logs similar to syslog (but different, of course, because #systemd). This could also happen on Linux is you are using "jsvc" to launch Tomcat. If you use the standard shell scripts to launch Tomcat, you'll get stdout/stderr redirected to catalina.out and it will grow indefinitely. If you use jsvc, you get log-file rotation out of the box. Instead of one giant catalina.out file, you'll get daily catalina-stdout.txt and catalina-stderr.txt files. I'm not sure why you have a zero-length catalina.out in those circumstances. Thank you very much. Especially given that I had no practical reason for knowing the answer, and had asked purely out of morbid curiosity. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: catalina.out, was Re: Connector definitions
On 3/8/23 1:34 PM, Zerro wrote: On the Linux box Tomcat is probably started by systemd, therefore no catalina.out Very likely, but can you elaborate on that? I'm much more of a DOS (to the point of having gone to great lengths to set up a refurbished vintage notebook as a functioning DOSbook) and OS/400 person. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
catalina.out, was Re: Connector definitions
On 3/8/23 11:35 AM, Mark Thomas wrote: Check logging.properties and/or how you have stdout redirected in your start-up scripts. Thanks. All I see different in logging.properties is that on the Midrange box (installed from the ZIP file from Apache's Tomcat site), it has "catalina.org.apache.juli.AsyncFileHandler.maxDays = 90" clauses, whereas on the cloud Linux (probably installed with yum or apt), it doesn't. And if (adopting root authority) I do a "find -name catalina.sh" or a "find -name startup.sh" on a cloud Linux box, I find *nothing.* Which is remarkable in itself. Not that it's of more than academic interest. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector definitions, Re: Tomcat 8 impending EOL -- what's the minimum Java for Tomcat 9?
FYI:
The operating system on IBM Midrange boxes ("AS/400," "iSeries," "IBM
i," or whatever they're calling it this week) is "OS/400," "IBM i," or
whatever they're calling the operating system this week. These machines
are the descendants of the IBM S/3, which IBM Rochester developed in the
late 1960s as a successor to plugboard-programmable unit record machines.
Because of their heritage, IBM Midrange boxes traditionally use a
block-mode, EBCDIC-based terminal protocol called 5250 Data Stream. The
architecture is based on a compiled abstraction layer (the "Machine
Interface") built on top of the hardware; it was doing the "virtual
machine" thing long before the coffee-crazed folks at Sun came up with
the Java Virtual Machine.
At any rate, given that I manage multiple customer installations, I
probably have as much experience installing and running Tomcat on IBM
Midrange boxes as anybody, and I've noticed a number of things that work
differently on that platform than elsewhere. In particular, Tomcat
configuration changes that take effect immediately under Linux require a
Tomcat restart on IBM Midrange boxes. And I have, in turn, developed a
number of IBM-Midrange-centric tools for managing those installations,
most notably, a CL program (CL programs being the platform's *compiled*
command scripts) to launch Tomcat, and another one to shut it down
(forcibly if it fails to respond to a shutdown command in a reasonable
amount of time). And I've noted that when Tomcat is running on an IBM
Midrange box, there are two jobs associated with the server: the
CATALINA job, and a JVM job called "QP0ZSPWT" (I have no idea why, but
at least it's consistent)
And I tend to be very cautious about changes, adopting an "if it ain't
broke, don't fix it" attitude, so I'm not terribly inclined to even
investigate converting to from JSSE to OpenSSL.
Thanks for all the help. This List rivals the IBM Midrange Lists in
terms of having knowlegable people who are eager to help, and blows a
great many other developer/user communities completely out of the water
in that regard.
Curious about one thing: on our IBM Midrange installations, log entries
go into catalina.out. On our Cloud Linux installations, catalina.out is
almost always completely empty, and I have to go into the dated catalina
log files to see any entries. Does anybody have an explanation for this
difference?
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector definitions, Re: Tomcat 8 impending EOL -- what's the minimum Java for Tomcat 9?
Dear Mesrs. Thomas, Schultz, et al.: Changing it to "org.apache.coyote.http11.Http11NioProtocol" did the trick. The Tomcat 9 server launched, on our cloud Midrange box, and both it and the webapp contexts we have running seem to be working. It will, of course, require a bit more exercise before we start switching customer installations over to it. Tomcat 8.5 gives a warning message: 15-Nov-2022 14:12:55.341 WARNING [main] org.apache.coyote.http11.Http11Protocol. The HTTP BIO connector has been removed in Tomcat 8.5.x onwards. The HTTP BIO connector configuration has been automatically switched to use the HTTP NIO connector instead. and so I'm taking that to mean that 8.5 did automatically what I had to do by manually changing the configuration file. Looking at the comparison chart on the protocols, I don't see any difference between NIO and NIO2. Could somebody point me to an explanation of what the difference is between BIO, NIO, and NIO2? (I have the general impression that APR is not an option on IBM Midrange boxes, but I could be mistaken.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector definitions, Re: Tomcat 8 impending EOL -- what's the minimum Java for Tomcat 9?
On 03/03/2023 17:44, I wrote: Ok, another question: will Tomcat 9 accept a "legacy" connector definition in the form as shown below? protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" keystoreFile="/foo/tomcat/bar.ks" keyAlias="baz" clientAuth="false" sslProtocol="TLS" /> To which Mark Thomas replied: Yes. This afternoon, I realized that I had a guinea pig available for testing our webapp under Tomcat 9, on an IBM Midrange box. With a connector defined according to the above form, I tried launching, and got this: 06-Mar-2023 18:42:08.677 SEVERE [main] org.apache.catalina.connector.Connector. Protocol handler instantiation failed java.lang.ClassNotFoundException: org.apache.coyote.http11.Http11Protocol at java.lang.Class.forNameImpl(Native Method) at java.lang.Class.forName(Class.java:339) at org.apache.coyote.ProtocolHandler.create(ProtocolHandler.java:260) . . . So I'm guessing I need to change the class given in the protocol clause. To what? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connector definitions, Re: Tomcat 8 impending EOL -- what's the minimum Java for Tomcat 9?
On 3/3/23 9:51 AM, Mark Thomas wrote: Yes. Thanks. That simplifies things. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Connector definitions, Re: Tomcat 8 impending EOL -- what's the minimum Java for Tomcat 9?
On 3/2/23 3:50 PM, jonmcalexan...@wellsfargo.com.INVALID wrote: Yes, Tomcat9 runs under Java8 and above. Ok, another question: will Tomcat 9 accept a "legacy" connector definition in the form as shown below? protocol="org.apache.coyote.http11.Http11Protocol" maxThreads="150" SSLEnabled="true" scheme="https" secure="true" keystoreFile="/foo/tomcat/bar.ks" keyAlias="baz" clientAuth="false" sslProtocol="TLS" /> -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8 impending EOL -- what's the minimum Java for Tomcat 9?
Am I correct in my understanding of the Tomcat 9 RUNNING.txt, that it will run under Java 8? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
"Reach" blockchain dApps in a Tomcat webapp?
If you haven't heard of the "Reach" blockchain language, this probably isn't worth your time. But. Is there anybody here who has called a Reach dApp from a Tomcat webapp? And if so, what's the most practical way to do it? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Got a customer who's paranoid about Manager
On 2/23/23 9:17 AM, Mark Thomas wrote: You need to remove the error page entry for 404 errors from WEB-INF/web.xml rather than / as well as renaming / removing 404.jsp Delete (or comment out) these lines: 404 /WEB-INF/jsp/404.jsp Thanks. I really wish certain other support lists and boards were as eager to help as you have been. It looks like seeing the effects of this will have to wait for tonight's restart. It seems like when you run Tomcat on an IBM Midrange box, *almost every change* has to wait for a restart. In other news, it appears that updating the Java on that other installation that was going into a runaway state and crashing has solved their problems: heap allocations are topping out, but so far no runaways or crashes. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Got a customer who's paranoid about Manager
On 2/22/23 9:23 AM, Mark Thomas wrote: Alternatively, you can use denyStatus="404" on the RemoteAddrValve. That attribute should be available in all versions of all currently supported Tomcat releases (it was added back in 2011). You can set it to any value valid for use with HttpServletResponse.sendError(int). Now that the customer's Tomcat server has had its nightly restart, I see that adding denyStatus="404" to the RemoteAddrValve does indeed give me a 404 page. But it's a 404 page that still admits to the *existence* of a manager context. I note that if I give it a manifestly nonexistent webapp context, e.g., "/foobar," I get a default 404 page. But if I simply rename /manager/WEB-INF/jsp/404.jsp to 404.jsp.bak, and I (without waiting for a Tomcat restart) go to the manager from an unauthorized URL, I get *nothing* -- in Firefox, I get a blank page, and in Chrome, I get a Chrome-generated message that there is nothing there. Is there a way, short of manually duplicating the default 404 page, that I can have /manager look *exactly* like /foobar to an unauthorized requester? (Or would waiting for the next scheduled Tomcat restart, with the manager's 404 page renamed, give me that result?) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Got a customer who's paranoid about Manager
On 2/22/23 9:23 AM, Mark Thomas wrote: Fire them and hire a security consultant with a proper understanding of risk? Pardon my Yiddish, but "Fun dayn moyl in Gots oyern." (From your mouth to God's ears. Such a colorful language.) But just because you're paranoid doesn't mean they're not out to get you. So just add denyStatus="404" to the RemoteAddrValve? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Got a customer who's paranoid about Manager
We've got a customer -- the same one that was our first test of a working RemoteAddrValve -- whose security consultant is complaining that a potential intruder can confirm the *existence* of the manager context (because it returns a 403, as opposed to, say, a 404). Any ideas? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Having trouble with Tomcat crashes. Interesting memory numbers in Manager
Naturally, I thought about this about 5 seconds after I clicked "Send": It doesn't happen very often, and it usually happens *after* a substantial portion of the heap has been idle for some time. Maybe there's something in there that works somewhat like a disk defragmenter. And when it gets a big chunk of idle heap that's been idle for long enough, and can be returned to the OS with the heap remaining contiguous, it gets returned. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Having trouble with Tomcat crashes. Interesting memory numbers in Manager
It would be unusual for the OS to reclaim any of that memory from the JVM process. Are you looking at OS heap usage, or "JVM heap" usage? From your description above, it's tough to tell. The tool is called WRKJVMJOB so presumably it knows what the heck a JVM is, so maybe you were getting the exact numbers I was recommending. TL;DR: I have seen Java return memory to the OS. I was frankly a little shocked myself when I first saw it yesterday. I was always taught that Java heap, once allocated, remained allocated. But there are a lot of things extraordinary about IBM Midrange boxes. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Having trouble with Tomcat crashes. Interesting memory numbers in Manager
I've obtained some heap and CPU numbers, taking data at 15 minute intervals, heap from WRKJVMJOB and CPU from WRKACTJOB. In two days of this, I didn't witness any crashes; I did witness a near-miss, in which heap-in-use hit 5011.938M (out of 5120). In discussion with our webapp developer (to whom we sent a catalina.out excerpt), he observed that they were running Tomcat on a six-year-old JVM (it identifies in a WRKJVMJOB as "1.8.0_151"; on the Manager page, it identifies as "8.0.5.5 - pap6480sr5fp5-20171114_01(SR5 FP5)") with a known issue (on Github, it's listed as 11493). He suggested that the customer ought to try updating to a more recent Java. I've also asked on the IBM Midrange Java List whether we can go any higher on the heap parameters (currently set at -Xms 4096 -Xmx 5120 for that particular installation). -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: AW: Having trouble with Tomcat crashes. Interesting memory numbers in Manager
Monitored the thing all day, taking the CPU usage (via a WRKACTJOB) and the current heap size and heap-in-use (via option 5 of a WRKJVMJOB) every 15 minutes. Heap size was 4925.375M (out of a maximum of 5120M) at 08:45, and the OS took heap away over the course of the day, until it was down to 4352.0M at 17:30. Heap in use fluctuated; from 11:45 to 13:00 it steadily climbed from 2575.382M to 3668.079M, then by 13:30 it had dropped to 2169.834M. Job CPU hit 35.5% at 09:00; that was the highest I saw it all day. That climb to 3668.079M peak (and I think it went higher, but not on the quarter-hour) had me wondering if I was going to witness a crash. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: Having trouble with Tomcat crashes. Interesting memory numbers in Manager
Thanks, Herr Hoffmann. Your questions were most helpful in determining what information to gather and share. And thanks in advance to anybody else who has any insights. First, I will note that the seemingly non-sequitur nursery-survivor numbers aren't just what we see during a crash; they're what we see when it's running normally. On 2/4/23 6:13 AM, Thomas Hoffmann (Speed4Trade GmbH) wrote: Could you describe "crash" in a bit more detail? Typically, the signed-on users start to get degraded response times, before it becomes completely unresponsive. - does the tomcat / java process run but is unresponsive? Yes. Exactly. And shutting it down (and therefore freeing up the port for a restart) takes a fairly sizeable amount of time, and leaves a core dump of approximately 6G size, a Javacore dump of approximately 4M size, and a JIT dump of approximately 20M size. - does the java process crash itself (then there should be a logfile written)? The job does not generally terminate itself, or even respond to a shutdown request; it has to be forcibly terminated (given that it's running on an AS/400, this would typically be either from WRKACTJOB, or from an ENDJOB command, or from their GUI console equivalents). This may be relevant: even when it is not in this state, the Tomcat server, when being shut down, tends not to respond readily to shutdown requests. - Is there any OOM message in the logfiles? Not out-of-memory, but there are chronic problems with contacting outside web services (many of them involving Oauth2), and with BIRT reporting. Around the time of the shutdown, I typically see stuff like: Unhandled exception Type=Segmentation error vmState=0x J9Generic_Signal_Number=0004 Signal_Number=000b Error_Value= Signal_Code=0032 I am not sure whether this is going into catalina.out before or after the job is forcibly terminated. - Is the process still alive but CPU at 100% ? Yes. We just had a near-miss as I was typing this: CPU pushing up into the high 80s, and the JVM job for Tomcat eating up most of it, but it backed down to something more normal without my having to intervene, and without any sign of anybody else intervening. One of my colleagues managed to get into manager during the near-miss, and took a screen-shot. The "nursery-allocate" Used was at 400.97M (34%), "nursery-survivor" as I described last week, "tenured-LOA" Used was at zero used, and "tenured-SOA" was showing Initial 2918.40M, Total 3648.00M, Maximum 4864.00M, and Used 1997.72M (41%). -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Having trouble with Tomcat crashes. Interesting memory numbers in Manager
One of our customers, one who basically pushes our Tomcat webapp to the limit, is having trouble with crashes. Some interesting numbers are showing up in Server Status, in Manager: nursery-allocate has initial 512M, total 1152M, maximum 1152M, used 587.05M. nursery-survivor has initial 512M, total 128M, maximum 128M, used 128M (how exactly can initial exceed maximum?!?) Everything else looks quite low. They're on 8.5.73, running under Java 8.0.5.5, on an AS/400. Does anybody here have any ideas? Can anybody here explain the odd numbers for nursery-survivor? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Message from a security scan
That I was "shot down in flames" when I tried to get in from my Chromebook, through the hotspot on my cell phone, makes it unlikely that Tomcat is seeing a proxy IP, especially given that (as I understand it) I would have had to authorize the proxy IP to get in from my office IP, and I have no idea what their proxy IP even is. What really puzzles me about the whole thing is that the pen-tester claimed to have gotten a sign-on pane. As I said, this was my first test-case of setting up a working remote address valve, and while I just found and removed two unaccounted-for (probably obsolete) authorized addresses, the odds against the pen-tester trying to get in from one of those addresses were about two billion to one. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Message from a security scan
On 2/1/23 12:06 PM, Mark Thomas wrote: The pen tester requested "/app/..;/manager" The proxy passed that as is to Tomcat since it starts with "/app" Thanks. As it happens, this particular customer was the first one in which I tried putting the only IP addresses with any business accessing manager into its remote address valve, instead of just commenting out the valve. I tried that syntax in a browser, from an IP address that's allowed to access manager, and it got in. I then tried it in a browser on my Chromebook, going through my cell phone's hotspot (which would definitely NOT have a permitted address), and it didn't even get to the sign-on panel before kicking me out with an error message. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Message from a security scan
We got this from a customer who did a security scan: A Tomcat Manager login panel was discovered via path normalization. Normalizing a path involves modifying the string that identifies a path or file so that it conforms to a valid path on the target operating system. QID Detection Logic: This QID sends a HTTP GET request with /..;/ payload and based on the response confirms if the target is vulnerable. Remediation notes Customers are advised to configure the reverse proxy to reject paths that contain the Tomcat path parameter character ; This sounds to me like something external to Tomcat, and external to the box Tomcat is running on. Would that be correct? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat for Apple silicon coming soon?
On 1/18/23 3:11 PM, Christopher Schultz wrote: Tomcat is pure-Java (okay, except for tcnative, which you evidently don't need) and therefore should run on either x86-84 Java via Rosetta 2 or aarch64 Java natively. You do not need any special distribution of Tomcat to run on native aarch64. It also runs very nicely on AS/400s. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: "You don't have permission to access this resource." message on manager
On 11/15/22 9:50 AM, Mark Thomas wrote: . . . Is this from Tomcat, or is it from something else? Lots of guess work here. I think, something else. . . . It *is* from something else. I'd completely forgotten that on that particular box, Tomcat was behind Apache HTTPD, and the relevant .conf file has Require ip 1.2.3.4 5.6.7.8 9.10.11.12 (IP addresses change to protect the innocent). The office fixed IP address is one of the allowed addresses. And my boss's IP address is apparently no longer one of them.) And thanks for the sample allow clause; it will be helpful elsewhere. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
"You don't have permission to access this resource." message on manager
We have Tomcat running on an AWS EC2 linux box. I can get into manager from the office IP address, with the usual prompt for user and password, but the boss, working from home, gets "You don't have permission to access this resource." Is this from Tomcat, or is it from something else? Looking at the context.xml for manager, I see: From what little I know about this, my own ability to get in is more puzzling than my boss's inability to do so. Any insights on that? I never did learn how to write a RemoteAddrValve allow clause (so we've just been disabling it); assuming we want to accept connections from "1.2.3.4" and "5.6.7.8", could somebody show me what the allow clause would look like? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Strange timeout: is it Tomcat, or is it some intermediate stage?
Lately, we've been getting this response to a web service call. The web service is our own, running under Tomcat on an Amazon "beanstalk"; the client is also our own, running on a customer's IBM Midrange box. 504 Gateway Time-out 504 Gateway Time-out nginx/1.20.0 It's a long-running web service call, taking a little over a minute, and we didn't see any response at all until I extended the client-side timeout. Is this coming from Tomcat? Or is it coming from some intermediate stage, maybe the load-balancer on the beanstalk, or something in the customer's netork? Any insights would be appreciated. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have sslProtocol="TLSv1.2"
On 8/10/22 6:50 AM, Brian Wolfe wrote: You can disable the protocols at the java level in the java.security file jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 768, TLSv1, TLSv1.1 I think that's exactly what I did on "Customer Box #1" (and forgot to document having done). Because I dug up the java.security file (I'm really glad there's a "find" command available from QShell and other *nix-style command lines in OS/400), and it has TLSv1 and TLSv1.1 added to it. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: AW: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have sslProtocol="TLSv1.2"
On 8/10/22 8:52 AM, Jason Hall wrote: If you have another network device in front of your server - that could be what is trumping the app server's settings. I'd planned on investigating that as well. But it *looks* like the cert I'm seeing matches the cert in the keystore their Tomcat is using, and I *don't* think an intermediate device would also have that cert. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have sslProtocol="TLSv1.2"
Interesting. The new "protocols" parameter.
Does this work with the traditional syntax? Can "protocols" and
"sslProtocol" coexist in the same Connector?
All our customer installations use JSSE security with a Java Keystore;
I've never configured a successful IBM Midrange installation any other way.
Looking at the "Server Information" on the "Manager" webapp, I see:
The "problem" server ("#2" in the original post) is on 8.5.73, running
under IBM OS/400 Java 8.0.5.25.
The "working" server ("#1" in the original post) is on 8.5.79, running
under IBM OS/400 Java 8.0.6.35.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
SSLLabs scan shows TLSv1.0 and TLSv1.1 even though I have sslProtocol="TLSv1.2"
I think this may have come up before, but I don't recall how it was resolved. On customer box #1, I have: address="" maxThreads="400" SSLEnabled="true" scheme="https" secure="true" keystoreFile="/tomcat/wttomcat.ks" keyAlias="" ciphers="TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,SSL_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384" clientAuth="false" sslProtocol="TLSv1.2" /> and an SSLLabs scan shows it accepting only TLSv1.2, as it should. But on customer box #2, I have: keystoreFile="/tomcat/wttomcat.ks" keyAlias="" clientAuth="false" sslProtocol="TLSv1.2" /> and an SSLLabs scan shows it accepting TLSv1.0, TLSv1.1, and TLSv1.2. What could be wrong here? I vaguely recall seeing something like this before. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
TCP timestamp vulnerability -- any insights on how this relates to Tomcat?
Today is the first time I heard of such a thing as a "TCP timestamp vulnerability." It seems a bit overblown to me, especially for a Tomcat server running on an AS/400. Can anybody share any insights about how this vulnerability relates to Tomcat? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Help with deploying multiple .WAR files in Tomcat
Multiple WAR files work fine for us. But we don't simply "drop [the WAR files] in the webapps folder (and for the most part, that *doesn't* work for us, even with *only one* webapp). We always deploy through the Manager webapp (which we always customize to increase the allowable WAR file size by an order of magnitude, every time we update somebody's Tomcat), and there are plenty of installations where we have multiple nearly-identical contexts based on completely identical WAR files (and note that another customization we make when installing Tomcat is to disable re-expansion of WAR files when Tomcat launches, since that would overwrite parameters manually inserted into the contexts after deployment). -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."
In response to my question about what could cause a system to disregard its own host table, On 4/15/22 11:31 AM, Jack Woehr (of the Midrange List) wrote: Which order the search happens, DNS or hosts table first, is an option in IBM i TCP configuration. CFGTCP option 12. Fascinating. I can't begin to imagine how setting it to "*REMOTE" could possibly be useful (or that the OS would *allow* LOCALHOST or LOOPBACK to be overridden), but I see that at least one other customer box has this setting. I will note that this, by itself, wasn't enough to kill Tomcat. It was a combination of this, and a DNS (presumably a "house DNS" rather than a public one) that recognized LOCALHOST and LOOPBACK, and responded with "LOCALHOST." or "LOOPBACK.," and an address that was something other than 127.0.0.1, that did it. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."
On 4/15/22 10:37 AM, Christopher Schultz (of the Tomcat Users' List) wrote: . . . Try specifying the "address" attribute of along with the port. Give it a concrete IP address instead of "localhost" and see if that improves things. . . . My Dear Mr. Schultz: That did it! Not knowing whether to give it 127.0.0.1 or give it the box's actual IP address, I gave it the former. It works. And the connector is configured to listen on anything, so it came up just fine, and is entirely visible from the outside world. But that still leaves open the question of why an IBM Midrange box would suddenly start disregarding its own host table. I've never heard of a scenario in which *any* box with a TCP stack would disregard its own host table (and indeed, on any box under my control that can browse the Web, in which the host table is user-modifiable, I use host table entries to ensure that I can't be tricked [it's happened, more than once] into accessing Facebook, Twitter, LinkedIn, or a few other noisome domains). What can make a box disregard its own host table? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."
On 4/15/22 10:37 AM, Christopher Schultz (on the Tomcat Users' List) wrote: . . . if "localhost" doesn't resolve to 127.0.0.1 on your system, you may get this error. Can you quickly check it's not a DNS resolution failure? THIS is interesting. If I look at the host table entries, I see ::1 IPV6-LOOPBACK IPV6-LOCALHOST 127.0.0.1 LOOPBACK LOCALHOST Now if I ping '127.0.0.1' on this box, I get a normal response. If I ping localhost on our box, or another customer box, I get Verifying connection to host system LOOPBACK at address 127.0.0.1. followed by a normal response. But if I ping localhost or loopback on this box, I get Verifying connection to host system LOOPBACK. at address . or Verifying connection to host system LOCALHOST. at address . Somehow, this box is DISREGARDING ITS OWN HOST TABLE! -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."
On 4/15/22 9:54 AM, Jim Oberholtzer wrote: On a modern system if you're contemplating stopping/starting TCP you might just as well IPL. Seems like using a nuke when a 100# bomb might work though. Looking at the QSYSOPR messages, I see that the system was taken down to restricted condition at 01:04 this morning, system time, for a backup, which completed at 02:03, with the subsystems, and TCP, starting. Looking at catalina.out for *YESTERDAY* shows Tomcat being shut down at 01:04 yesterday morning, and coming back up at 02:04 that morning, without incident. Today, however, catalina.out shows the same thing up to the point where 8005 shows up as unavailable. Looking back at the QSYSOPR messages, I see TWO OVERLAPPING STRTCPs, initiated within seconds of each other. That doesn't make any sense to me. And yet I see it happening every day this week. So far, nothing is making any sense. TCP can't be in *that bad* of a shape, since I'm able to get terminal sessions via TN5250. And WRKTCPSTS shows 59 servers waiting for connections, and 61 established connections. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."
On 4/15/22 9:39 AM, Jack Woehr wrote: Not sure about the particular pathology in this instance, but it's the Java runtime itself telling you something already has hold of the socket, and it's not lying. But it could be deluded into *thinking* something already has hold of the socket. WRKTCPSTS shows *nothing* on 8005, 8009, 443, or 8443. I've tried changing 8005 to 8009. No joy. I then tried changing 443 to 8443. No joy. I'm seriously considering having them do an ENDTCP followed by a STRTCP (although I haven't a clue how that can even be done on a box that presumably isn't old enough to have Twinax). And if that doesn't work, re-IPL the system. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat 8.5.73 not coming up on customer box. "Bind failed."
On 4/15/22 9:24 AM, James H. H. Lampert wrote: This morning, I arrived at work to find that a customer was complaining about their Tomcat server (running on an IBM Midrange box). It had locked up last night, while being shut down, and now, if you try to start it, it fails . . . I tried changing the port number from 8005 to 8009 (not in use for its usual purpose), since it appears to be specifically failing when trying to open 8005. And it behaves exactly the same: it throws the same error, only this time on 8009. This makes no sense. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.5.73 not coming up on customer box. "Bind failed."
This morning, I arrived at work to find that a customer was complaining about their Tomcat server (running on an IBM Midrange box). It had locked up last night, while being shut down, and now, if you try to start it, it fails with 15-Apr-2022 10:35:34.867 SEVERE [main] org.apache.catalina.core.StandardServer.await StandardServer.await: create[localhost:8005]: java.net.BindException: The socket name is not available on this system. (Bind failed) at java.net.PlainSocketImpl.socketBind(Native Method) at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:417) at java.net.ServerSocket.bind(ServerSocket.java:444) at java.net.ServerSocket.(ServerSocket.java:258) at org.apache.catalina.core.StandardServer.await(StandardServer.java:414) at org.apache.catalina.startup.Catalina.await(Catalina.java:776) at org.apache.catalina.startup.Catalina.start(Catalina.java:722) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:90) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) Catalina.out shows "Starting ProtocolHandler ["https-jsse-nio-443"]," then "Server startup in 20227 ms," then it blows up as above. According to the server.xml, the only ports it is listening on are 8005 and 443. And according to a WRKTCPSTS *CNN (the AS/400 equivalent of a "super netstat"), there is nothing currently grabbing hold of either of those two ports. Any insights as to what could be happening? -- James H. H. Lampert Touchtone Corporation - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Stuff in the "temp" directory within the Tomcat directory
I'm doing some cleanup on a customer box, removing a previous version of Tomcat 8.5 that I'd replaced some time ago, and I'm finding huge amounts of "stuff" in the "temp" directory within the Tomcat directory. Is that stuff Tomcat itself left behind, or stuff our webapp left behind, or both? Assuming any of it is from Tomcat itself, any advice on keeping the contents of that directory down to something reasonable? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
Thanks. I think I understand now. All except for one thing: I can *barely* wrap my mind around the idea of getting executable code from an RMI server, but what legitimate purpose could be served by allowing a *logger* to resolve executable code? -- JHHL (And I have a fair amount of experience writing "solutions looking for a problem" that "seemed like a good idea at the time," but turned out to have no practical use. More experience than I'd like to have, in fact.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
On 12/13/21 10:53 AM, Mark Thomas wrote:
Log4j2 supports a log message format syntax that includes JNDI lookups.
Log4j2 processes log messages repeatedly until it doesn't find any more
format strings. This means the output of one format string can insert a
new format string.
. . .
Thanks. It's starting to make sense to me now, even given that much of
it involves Java functionality I'd never heard of.
After re-reading the Veracode article in light of what you said, I then
found a couple of Wikipedia articles that further clarify things, for me
at least:
https://en.wikipedia.org/wiki/Log4j
https://en.wikipedia.org/wiki/Log4Shell
So it's the ability to resolve stuff of the general format
"${prefix:name}" within a log string, that's the problem.
It's starting to reach a point where I can wrap my 59-year-old little
grey cells around it.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
The thing I'm still utterly unclear about is how simply logging traffic could, by itself, create a vulnerability. In our case, the log entries are not even viewable unless you are signed on to a command line session on the server (ssh for headless Linux; a physical Twinax terminal, or a 5250 emulator of some sort, for IBM Midrange). How can a log entry be executed as a command, anyway? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
CVE-2021-44228 Log4j 2 Vulnerability -- How does this affect Tomcat?
A customer brought this to my attention: https://www.randori.com/blog/cve-2021-44228/ I have no idea how (or if) Tomcat is affected. I have only the vaguest idea what this vulnerability even *is.* Can anybody here shed any light? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Odd messages in catalina.out
On 12/10/21 8:38 AM, Mark Thomas wrote: . . . The messages are there to warn you that you might have a malicious actor trying a brute force attack on your server. Can anybody point me to a good tutorial for constructing a regular expression for RemoteAddrValve? allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1" obviously can't work for a server that's incapable of running a browser, and at any rate, I can't make head or tail of the regular expression syntax in use here. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Odd messages in catalina.out
Could anybody here shed some light on this message? A whole bunch of them appeared in catalina.out. WARNING [https-jsse-nio-443-exec-29] org.apache.catalina.realm.LockOutRealm.filterLockedAccounts An attempt was made to authenticate the locked user [user] -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
One other thing, Re: Updating Tomcat on an Amazon Linux 2 EC2 instance?
Also, based on what "yum check-update" returned, it appears that at the moment, I can only go as far as 8.5.72, rather than 8.5.73. Is there a way to go all the way to 8.5.73 without fundamentally changing how Tomcat is installed on that instance? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Updating Tomcat on an Amazon Linux 2 EC2 instance?
On 12/8/21 9:46 AM, jonmcalexan...@wellsfargo.com.INVALID wrote: I think it's going to come down to how the 8.5.58 was installed. Was it via an rpm or zip file? I have used both methods and you should be able to install the 8.5.73 without affecting the 8.5.58. If you are using a separated CATALINA_BASE and CATALINA_HOME, then updating your configuration should be super simple, especially if using symbolic links to point to your Tomcat binaries. At first, that answer didn't seem like it was telling me much, but then I realized that it was telling me a great deal: First, for some reason, I *thought* that Amazon Linux used apt, rather than yum, but your mention of "rpm" said otherwise, and sure enough, when I looked in the AWS docs, it does indeed use yum. That, in turn, pointed me in the direction of looking up how to use yum. That led me to try "yum check-update," which returned: . . . tomcat.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5 tomcat-admin-webapps.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5 tomcat-el-3.0-api.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5 tomcat-jsp-2.3-api.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5 tomcat-lib.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5 tomcat-servlet-3.1-api.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5 tomcat-webapps.noarch 8.5.72-1.amzn2.0.1 amzn2extra-tomcat8.5 . . . and a bit more digging found "yum list installed," which returned: . . . tomcat.noarch 8.5.58-1.amzn2 @amzn2extra-tomcat8.5 tomcat-admin-webapps.noarch 8.5.58-1.amzn2 @amzn2extra-tomcat8.5 tomcat-el-3.0-api.noarch 8.5.58-1.amzn2 @amzn2extra-tomcat8.5 tomcat-jsp-2.3-api.noarch 8.5.58-1.amzn2 @amzn2extra-tomcat8.5 tomcat-lib.noarch 8.5.58-1.amzn2 @amzn2extra-tomcat8.5 tomcat-servlet-3.1-api.noarch 8.5.58-1.amzn2 @amzn2extra-tomcat8.5 tomcat-webapps.noarch 8.5.58-1.amzn2 @amzn2extra-tomcat8.5 . . . which matches what shows up in Manager. So it does indeed appear that it was installed from an rpm file, via yum. So how do I proceed from here? Would I do a "yum update tomcat.noarch"? And what about the webapp contexts and configuration settings (not to mention the settings to allow me into manager) installed in the existing Tomcat? (For IBM Midrange updates, we have to take care of all that manually, as the update there amounts to a clean installation of the product in a default state.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Updating Tomcat on an Amazon Linux 2 EC2 instance?
We have a Tomcat server running on an Amazon Linux 2 EC2 instance. Off the top of my head, I don't remember how I originally installed it, but it's currently at 8.5.58. I'd like to update it to 8.5.73, but I don't quite know how to do this in Amazon Linux 2 (now if somebody asked about installation or update on an IBM Midrange System, I could practically write a how-to manual). Can somebody relieve my ignorance? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [SECURITY] CVE-2021-42340 Apache Tomcat DoS
On 10/14/21 7:12 AM, Mark Thomas wrote: The fix for bug 63362 introduced a memory leak. The object introduced to collect metrics for HTTP upgrade connections was not released for WebSocket connections once the WebSocket connection was closed. This created a memory leak that, over time, could lead to a denial of service via an OutOfMemoryError. Question: Is this even an issue if the Tomcat is configured to *only* listen on 443, and rejects non-HTTPS connections outright? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question about serving a 404
Our Tomcat team has been struggling with this issue for a few days: If a request comes in for https://foo.com/bar.html, which doesn't exist, then a 404 is returned, and we see a standard Tomcat 404 page. But if a request comes in for https://foo.com/bar.jsp, which also doesn't exist, then our webapp takes control, and returns a 200 with a redirect to a "you are not signed on" page. In the most recent attempt to correct this, they now return a 404 page of their own design for both of the above scenarios. Unfortunately, if the webapp context we're trying to reach is installed as something other than ROOT (i.e., if we call it "baz," then https://foo.com/baz), then even a correct URL still returns a 404 page. Seems to me that there's something wrong with this picture. Seems to me that a request for a nonexistent "bar.jsp" should behave the same as one for a nonexistent "bar.html." Is there something I can pass along to the Tomcat team? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
200 response and redirect for ".../test.jsp"
I could have sworn I asked about this over a year ago, but I can't find any record of having done so. We've got a low-priority complaint about a security scan looking for "test.jsp" on one of our installations, expecting a 404 response, and instead getting a 200 response and a redirect to our own error page. Just a sanity check: this *is* a problem with our ROOT context, not with Tomcat itself, right? And it has to be solved within our ROOT context, right? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Getting some peculiar TLS results in Tomcat 7
While we've been systematically updating our customer boxes, a few of our customer boxes are still on Tomcat 7. I've got the following Connector tag set up in server.xml: compressableMimeType="text/html,text/xml,text/plain,text/css, text/javascript,text/json,application/x-javascript, application/javascript,application/json" /> And yet SSLLabs tells me the box in question is still accepting TLS 1.0 and TLS 1.1. Can anybody shed any light on this? (And yes, I know, "alias" should be "keyAlias," but it's the only chain in the keystore, so it shouldn't make any difference.) - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More information, Re: Tomcat 8.5.68 failing on takeoff!
On 8/9/21 11:33 AM, Mark Thomas wrote: The fix will be in the September releases. Thanks. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More information, Re: Tomcat 8.5.68 failing on takeoff!
On 8/9/21 10:24 AM, Mark Thomas wrote: Future versions of Tomcat won't see this issue but if the customer is prepared to update Tomcat to fix this issue then they might as well just update Java (assuming that is indeed sufficient to fix this). Given that they currently seem to be happy as clams on their currently installed Tomcat 7, and that we've only been updating customers to Tomcat 8 in order to proactively deal with any security complaints that might come up, they can presumably wait for a Tomcat 8 that has the relevant fix. And this customer is not in any particular hurry for updating *anything* (a trait I share). Any idea when a Tomcat 8 with the relevant fix might come out? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More information, Re: Tomcat 8.5.68 failing on takeoff!
On 8/6/21 9:17 AM, Konstantin Kolinko wrote:
Try to find what *.jar file in your system contains the above classes.
E.g. searching for string "crimson" in *.jar files.
That string will be visible in the archive file as it is a name of a directory.
I've learned that QShell (a *nix-like shell that was added with Java
support) on an AS/400 does have both "find" and "grep," so it wasn't
quite so futile as I thought.
If I go into QShell, navigate to the JVM home directory, and do a
"find . -name '*.jar'"
I get
./jre/lib/ppc64/compressedrefs/jclSC180/vm.jar
./jre/lib/ppc64/default/jclSC180/vm.jar
./jre/lib/ext/db2_classes18.jar
./jre/lib/ext/CmpCrmf.jar
./jre/lib/ext/IBMSecureRandom.jar
./jre/lib/ext/cldrdata.jar
./jre/lib/ext/dnsns.jar
./jre/lib/ext/dtfj.jar
./jre/lib/ext/dtfjview.jar
./jre/lib/ext/gskikm.jar
./jre/lib/ext/healthcenter.jar
./jre/lib/ext/ibmcmsprovider.jar
./jre/lib/ext/ibmjcefips.jar
./jre/lib/ext/ibmjceplus.jar
./jre/lib/ext/ibmjceprovider.jar
./jre/lib/ext/ibmkeycert.jar
./jre/lib/ext/ibmpkcs11impl.jar
./jre/lib/ext/ibmsaslprovider.jar
./jre/lib/ext/ibmxmlcrypto.jar
./jre/lib/ext/ibmxmldsigprovider.jar
./jre/lib/ext/ibmxmlencprovider.jar
./jre/lib/ext/jaccess.jar
./jre/lib/ext/localedata.jar
./jre/lib/ext/nashorn.jar
./jre/lib/ext/traceformat.jar
./jre/lib/ext/xmlencfw.jar
./jre/lib/ext/zipfs.jar
./jre/lib/aggressive.jar
./jre/lib/charsets.jar
./jre/lib/dataaccess.jar
./jre/lib/ddr/j9ddr.jar
./jre/lib/deploy.jar
./jre/lib/ibmcertpathfw.jar
./jre/lib/ibmcertpathprovider.jar
./jre/lib/ibmcfw.jar
./jre/lib/ibmjcefw.jar
./jre/lib/ibmjgssfw.jar
./jre/lib/ibmjgssprovider.jar
./jre/lib/ibmjssefw.jar
./jre/lib/ibmjsseprovider2.jar
./jre/lib/ibmorb.jar
./jre/lib/ibmorbapi.jar
./jre/lib/ibmpkcs.jar
./jre/lib/ibmsaslfw.jar
./jre/lib/javaws.jar
./jre/lib/management-agent.jar
./jre/lib/math.jar
./jre/lib/plugin.jar
./jre/lib/resources.jar
./jre/lib/rt.jar
./jre/lib/se-service.jar
./jre/lib/security/US_export_policy_56bit.jar
./jre/lib/security/local_policy_56bit.jar
./jre/lib/security/policy/limited/US_export_policy.jar
./jre/lib/security/policy/limited/local_policy.jar
./jre/lib/security/policy/unlimited/US_export_policy.jar
./jre/lib/security/policy/unlimited/local_policy.jar
./jre/lib/tools/monitoring-api.jar
./jre/lib/xml.jar
./jre/lib/xmldsigfw.jar
./IBMmisc.jar
./lib/dt.jar
./lib/ibmorbtools.jar
./lib/jconsole.jar
./lib/tools.jar
./lib/IBMi5OSJSSE.jar
If I do a "find . -name '*crimson*'", I get nothing.
If I do a "find . -name '*.jar' -exec grep -l 'crimson' {} \;", I also
get nothing.
So unless anybody else has any ideas, I'm once again stuck, at least on
this angle.
Mark Thomas wrote:
Tomcat 7 doesn't have JASPIC support so you'll never see this issue in Tomcat 7.
. . . to which I replied (seriously, rather than flippantly) "What's a
JASPIC?"
I've finally taken a look at what JASPIC is. Interesting. If it's JASPIC
support in Tomcat 8 that is throwing exceptions and killing manager
under this particular Java 8 JVM, is there a way to disable it, at least
until the customer has their PTFs up to date?
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More information, Re: Tomcat 8.5.68 failing on takeoff!
Searching JAR files for "crimson" would likely be an exercise in futility on an AS/400. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: More information, Re: Tomcat 8.5.68 failing on takeoff!
On 8/6/21 1:40 AM, Mark Thomas wrote: Tomcat 7 doesn't have JASPIC support so you'll never see this issue in Tomcat 7. What's a JASPIC? And as to configuration, Mr. Schultz, my usual procedure is to (after commenting out the default 8080 unsecured connector) copy and paste the active secured port 443 connector *directly* from the Tomcat 7 conf/server.xml to the Tomcat 8 conf/server.xml. Ditto for the one user definition in tomcat-users.xml. That particular installation has a note to add this clause birtUseSvg false to the web.xml of *our webapp,* but nothing server-wide. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
More information, Re: Tomcat 8.5.68 failing on takeoff!
I finally had a chance to switch the customer back to the failing Tomcat 8.5.68, and this is what the browser error page shows (with a 500 error): Type Exception Report Message AuthConfigFactory error: java.lang.reflect.InvocationTargetException Description The server encountered an unexpected condition that prevented it from fulfilling the request. Exception java.lang.SecurityException: AuthConfigFactory error: java.lang.reflect.InvocationTargetException javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:85) org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1421) org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1411) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:535) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:698) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:364) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:624) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1651) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.lang.Thread.run(Thread.java:811) Root Cause java.lang.reflect.InvocationTargetException sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83) sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) java.lang.reflect.Constructor.newInstance(Constructor.java:437) javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:76) javax.security.auth.message.config.AuthConfigFactory$1.run(AuthConfigFactory.java:67) java.security.AccessController.doPrivileged(AccessController.java:696) javax.security.auth.message.config.AuthConfigFactory.getFactory(AuthConfigFactory.java:66) org.apache.catalina.authenticator.AuthenticatorBase.findJaspicProvider(AuthenticatorBase.java:1421) org.apache.catalina.authenticator.AuthenticatorBase.getJaspicProvider(AuthenticatorBase.java:1411) org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:535) org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81) org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:698) org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:364) org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:624) org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65) org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:831) org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1651) org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1160) java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) java.lang.Thread.run(Thread.java:811) Root Cause java.lang.SecurityException: org.xml.sax.SAXNotRecognizedException: Feature: http://apache.org/xml/features/allow-java-encodings org.apache.catalina.authenticator.jaspic.PersistentProviderRegistrations.loadProviders(PersistentProviderRegistrations.java:65) org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.loadPersistentRegistrations(AuthConfigFactoryImpl.java:345) org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl.(AuthConfigFactoryImpl.java:68) sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:83) sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:57) java.lang.reflect.Constructor.newInstance(Constructor.java:437)
Re: Tomcat 8.5.68 failing on takeoff!
Mssrs. Kolinko and Schultz said: 2. The stack trace starts with "Bootstrap.main". I.e. it is the thread that starts Tomcat. I.e. this occurs when Tomcat starts up and has nothing to do with your attempt to access the Manager web application. 3. The stack trace contains "org.apache.crimson". Apache Crimson project was retired 11 years ago and should not be used nowadays. https://xml.apache.org/crimson/ https://attic.apache.org/projects/crimson.html You have that library in Tomcat classpath? Where? Why? Good catch. The JVM has been bundled with a SAX parser for ages, now. You might ask your application/engineering team if it's okay to try your application without a bundled XML library. You might also ask why it's being put into CATALINA_BASE/lib (or endorsed-libs?) instead of in the application's WEB-INF/lib where it belongs. A bit more information: Our application isn't even *installed* in the new Tomcat yet. As I said, the *only* context currently in Webapps is manager; everything else was stripped out, including the default ROOT, shortly after I unpacked the Tomcat 8.5.68 ZIP file on the box. Tomcat 7.0.93 continues to run just fine, under the same Java 8, after I swapped it back in (and I'm definitely glad I do updates in a way that makes that easy). Last night, I was a bit lax in proofreading my initial post, and somehow some critical information got left out. The stacktrace included in the post was, of course, from the launch process. When I attempt to connect to manager, I get a "500-Internal Server Error" page, that has a few stacktraces of its own (but adds nothing to Catalina.out). Alas, I didn't save a copy of the error page, and it could be several hours before I can swap the 8.5.68 back in and take down the details. Jon McAlexander suggested a possible bad JVM; while I wonder how that could be, given that Tomcat 7.0.98 runs just fine, I will note that this particular box is on a slightly different Java 8 JVM from what we see on other customer boxes where we already have 8.5.6x running, and I think we've already asked them to check on whether their Java PTFs (analogous to what M$ calls "service packs") are current. The Tomcat 7 manager reports their JVM version as "8.0.5.20 - pap6480sr5fp20-20180802_01(SR5 FP20)" I just checked the Catalina.out of another customer we have on 8.5.68. Nothing at all between 06-Jul-2021 19:11:49.841 INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 3303 ms and 06-Jul-2021 19:11:49.905 INFO [main] org.apache.catalina.core.StandardService.startInternal Starting service [Catalina] Is there any other information I could gather, without having to switch the customer's Tomcat 8 live? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat 8.5.68 failing on takeoff!
This is beyond my pay grade, I'm afraid. Hopefully somebody here has a clue what went wrong. I installed Tomcat 8.5.68 on an AS/400 with Java 8, that had been running Tomcat 7 for years with no problems. On launching Tomcat 8, if I try to connect to "manager" (the only context currently in Webapps), right after: 02-Aug-2021 18:15:11.655 INFO [main] org.apache.catalina.startup.Catalina.load Initialization processed in 3271 ms I'm getting 02-Aug-2021 18:15:11.707 WARNING [main] org.apache.catalina.users.MemoryUserDatabase.open Exception configuring digester to permit java encoding names in XML files. Only IANA encoding names will be supported. org.xml.sax.SAXNotRecognizedException: Feature: http://apache.org/xml/features/allow-java-encodings at org.apache.crimson.parser.XMLReaderImpl.setFeature(XMLReaderImpl.java:213) at org.apache.crimson.jaxp.SAXParserImpl.setFeatures(SAXParserImpl.java:143) at org.apache.crimson.jaxp.SAXParserImpl.(SAXParserImpl.java:126) at org.apache.crimson.jaxp.SAXParserFactoryImpl.newSAXParserImpl(SAXParserFactoryImpl.java:113) at org.apache.crimson.jaxp.SAXParserFactoryImpl.setFeature(SAXParserFactoryImpl.java:141) at org.apache.tomcat.util.digester.Digester.setFeature(Digester.java:526) at org.apache.catalina.users.MemoryUserDatabase.open(MemoryUserDatabase.java:440) at org.apache.catalina.users.MemoryUserDatabaseFactory.getObjectInstance(MemoryUserDatabaseFactory.java:105) at org.apache.naming.factory.FactoryBase.getObjectInstance(FactoryBase.java:96) at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:332) at org.apache.naming.NamingContext.lookup(NamingContext.java:847) at org.apache.naming.NamingContext.lookup(NamingContext.java:157) at org.apache.naming.NamingContextBindingsEnumeration.nextElementInternal(NamingContextBindingsEnumeration.java:115) at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:69) at org.apache.naming.NamingContextBindingsEnumeration.next(NamingContextBindingsEnumeration.java:32) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:131) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.createMBeans(GlobalResourcesLifecycleListener.java:105) at org.apache.catalina.mbeans.GlobalResourcesLifecycleListener.lifecycleEvent(GlobalResourcesLifecycleListener.java:80) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:123) at org.apache.catalina.util.LifecycleBase.setStateInternal(LifecycleBase.java:423) at org.apache.catalina.util.LifecycleBase.setState(LifecycleBase.java:366) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:763) 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:90) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55) at java.lang.reflect.Method.invoke(Method.java:508) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:345) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:476) I can't recall ever seeing anything like this. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Error that only occurs on mobile
First, understand that I have even less involvement in development of our mobile apps than I do in the development of our Tomcat webapp. So I'm grasping at straws here. All I know is that the mobile apps work through the webapp. It seems that at a specific customer installation, when the mobile app (both Apple and Android) tries to access our BIRT-based dashboards, they don't work (the dashboards work fine from a desktop browser). We recently updated that customer from 7.0.93 to 8.5.68, and installed the latest version of our webapp. The error message that appears on Android is in the form: The webpage at https://[very long url omitted] could not be loaded because: net::ERR_BLOCKED_BY_RESPONSE I will note that we do have the httpHeaderSecurity filter enabled, with an antiClickJackingOption of SAMEORIGIN. Does anybody here have any insights that I might pass on to the webapp/mobile team? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: CVE-2021-25329, was Re: Most recent security-related update to 8.5
On 7/2/21 12:02 AM, Mark Thomas wrote: It is an alternative session manager that persists session data via a configured Store. There are two Store implementations provided by default - File and DataSource. You would know if you were using it as it requires explicit configuration. Thanks for the specific documentation link; I would not have known where to look in the docs. My friends and colleagues seem to think I have brilliant research skills; in fact, I simply have no qualms about asking for help. Our webapp totally lacks a "context.xml" (I looked for one) but I see such files, with Manager elements, in the manager and host-manager webapps. Are they affected by CVE-2021-25329/CVE-2020-9484? Incidentally, speaking of those webapps, when installing, we immediately jettison all as-shipped webapps *except* manager and host-manager. We use manager all the time, but I'm not even sure what host-manager does. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What is "h2c"? What is CVE-2021-25329? Re: Most recent security-related update to 8.5
On 7/1/21 4:55 PM, in response to: I will note, however, that the Tomcat servers in question are *not* configured to listen on any ports other than HTTPS (either 443, 8443, or something else in that vein) and the shutdown port. Shawn Heisey wrote: In that case, you don't need h2c, and probably don't want it. O. . . . k. That makes sense, so far, but how is it even enabled? Is there some way I could have h2c enabled, with the situation I described (no HTTP at all, not even as a redirect), and not *know* I have it enabled? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
What is "h2c"? What is CVE-2021-25329? Re: Most recent security-related update to 8.5
On 6/21/21 9:42 AM, Christopher Schultz wrote: If you are using h2c, you'll definitely want to 8.5.63 or later, as there is a critical fix there. My understanding, based on what I looked up a week and a half ago, is that we're not using h2c, but at the same time, don't think I fully understand what "h2c" is. I will note, however, that the Tomcat servers in question are *not* configured to listen on any ports other than HTTPS (either 443, 8443, or something else in that vein) and the shutdown port. Also, I've got somebody complaining about CVE-2021-25329. I'm not sure I understand what CVE-2021-25329 is, or what the underlying CVE-2020-9484 is. And https://nvd.nist.gov/vuln/detail/CVE-2020-9484 doesn't exactly help a whole lot: it talks about "PersistenceManager," and I'm not entirely sure what that even *is.* -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Most recent security-related update to 8.5? And setting up access to Manager?
On 6/21/21 9:42 AM, Christopher Schultz wrote: I think it depends upon your environment, honestly. There were many organizations where the "AJP endpoint is trusting, because that's what it's for" announcement was a real surprise and represented a must-fix issue immediately. That was not the case for my $work, where we were already protecting our AJP connections and not allowing just anyone to connect. If you are using h2c, you'll definitely want to 8.5.63 or later, as there is a critical fix there. We don't, so far as I'm aware, use AJP or h2c. The only enabled connectors are HTTPS (still coded as a Tomcat 7.0 connector and using a Java Keystore) and Shutdown. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Most recent security-related update to 8.5? And setting up access to Manager?
We are finally migrating customer installations from 7 to 8.5. Would anybody happen to know, off the top of his or her head, what the most recent security-related update to 8.5 is? I know that 68 is the most recent release, but what's the most recent one that addresses a significant security issue? Also, while I'm here, can somebody point me to an example of how to code the Manager's RemoteAddrValve setting to allow access from, say, two or three arbitrary IP addresses? (And yes, this is also an excuse to double-check that my List traffic is getting through with DMARC enforcement turned on.) -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Heap allocations when switching from Tomcat 7 to Tomcat 8
We are beginning to migrate some of our customers from Tomcat 7 to Tomcat 8.5. Some of them have performance issues even with heap allocations of -Xms4096m -Xmx5120m Would it be necessary to go even bigger with Tomcat 8.5? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: What exactly does the AJP connector on 8009 do?
On 4/6/21 9:11 AM, Olaf Kock wrote: *Everybody* has a dedicated testing system. Always! *Some* are lucky that they have a completely separate production system. We expect disk drives to fail. So we plan for it, using some form of RAID (full mirroring in my case). And so the power supply fails instead. Also: The likelihood of a power supply failure is inversely proportional to its maintenance accessibility. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: What exactly does the AJP connector on 8009 do?
On 4/5/21 1:22 PM, Christopher Schultz wrote: If you are not running a reverse-proxy in front of Tomcat, then it does absolutely nothing for you. If you *are* running a reverse-proxy in front of Tomcat, then it *may* do something for you, depending upon what software you are using and what its configuration is. Thanks. Hmm. We have *something* on one of our cloud servers, that has Tomcat sitting behind httpd (on the same box), and we have load balancing (through a couple of AWS Beanstalks) on our cloud-based product, but I don't know if the AJP port is involved in any of that. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
What exactly does the AJP connector on 8009 do?
We've just gotten a complaint about a vulnerability involving AJP (to something called "Ghostcat") from a customer. The report from the security consultant recommends updating to a more recent version of Tomcat, and I note that we've already started rolling out 7.0.108 to customers. Looking at server.xml, the only reference to AJP is in relation to port 8009, and that this connector is commented out in 108, but not in 93. So what exactly *is* this connector, and what purpose does it serve? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing
Thanks to all, for both satisfying my morbid curiosity and verifying that it's the customer's problem, not mine. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing
On 1/6/21 3:46 PM, Robert Turner wrote: You'll want to set the protocols, ciphers, and honorCipherOrder ... The precise wording in the error message is: . . . but the server presented a certificate signed using a weak signature algorithm (such as SHA-1). . . . Which is to say, it doesn't sound like a cipher or protocol problem, or anything else that's actually under Tomcat's control. But I figured somebody here might know something about it. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Browser complains of "weak signature algorithm" in cert on a new Tomcat installation. Does anybody here know anything about that sort of thing
We just had our first Tomcat 8.5 installation on a customer's AS/400. The customer apparently has his own CA (they're a big company), and when I installed SSL in their Tomcat, and tested it with a browser, it complained, something to the general effect of "weak signature algorithm." While it's not really my problem (and is only connected to Tomcat by virtue of it happening with a Tomcat server), I'm curious about what's up with it, if anybody here is able and willing to explain it. Of course, a customer that's big enough to run a private CA in production is already doing things beyond my pay grade. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Manager setup in Tomcat 8
On 12/22/20 10:51 AM, Christopher Schultz wrote: I would try to lock-down that IP range as much as you can, rather than either removing the Valve (which would allow connections from anywhere) or specifying something like ".*" in the "allow" attribute (which is a regular expression which will be applied to the remote-user's IP address, either IPv4 or IPv6 as the case may be). Dear Mr. Schultz: Thanks. Very much applicable to the EC2 instance (and I recall doing just that, although I'd have to look at what I did to recall exactly how), and to most customer boxes, but not necessarily so much for this particular customer: they've got everything locked down in the tightest VPN I've ever seen. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Manager setup in Tomcat 8
A few months back, as I recall, I ran into some "gotchas" in connection with the manager context, while setting up Tomcat 8.5 on one of our AWS EC2 instances. As I recall, I had to do something special, somthing I don't have to do with Tomcat 7, in order to make the manager context reachable from the outside. Very shortly, I'll be setting up Tomcat 8.5 for the first time on an AS/400, and like the EC2, it can't exactly browse itself, so it, too, will need to have the manager context reachable from the outside world. Can somebody remind me of what it is I had to do, that I don't have to do for Tomcat 7? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange crash-on-takeoff, Tomcat 7.0.104
Ladies and Gentlemen: The same customer installation that required 104 (but with the 103 catalina.sh, to avoid Bug 64501) back in June is now demanding an update to 106 because of the CVE-2020-13935 vulnerability. Two questions: 1. Is the problem from June fixed in 106? 2. Does 106 take care of CVE-2020-13935? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
On 8/21/20 1:02 PM, logo wrote:
From my experience I have excluded .well-known from the redirect.
That appears to be the correct answer. I probably didn't see that line
back in August, or I probably would have replied by asking something
like, "Ok, and how do I do that?"
Be that as it may, Andrew Schulman came up with an answer on my
ServerFault thread (https://serverfault.com/a/1041882/498231) to the
effect of changing the rewrite block from:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
to:
RewriteEngine on
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteCond %{REQUEST_URI} !^/\.well-known/acme-challenge/
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L,QSA]
While I'm not going to be certain until December, when the cached
challenge expires, it certainly seems to work: if I go to
http://sub.domain.com, it immediately redirects me to
https://sub.domain.com, and I get the Tomcat server, whereas if I try to
go to http://sub.domain.com/.well-known/acme-challenge/foo, it remains
http, and gives me the expected "Not Found" error.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Something I still don't quite understand, Re: Let's Encrypt with Tomcat behind httpd
On 8/24/20 9:57 AM, Christopher Schultz wrote: So your RewriteCond[ition] is expected to always be true? Okay. Maybe remove it, then? BTW I think your rewrite will strip query strings and stuff like that. Maybe you just want RedirectPermanent instead of Rewrite(Cond|Rule)? Ladies and Gentlemen: This past Friday, the cached challenge result expired, and so this past Monday, I ran another certbot test. With the rewrite in place for our "subdomain of interest," the cert covering everything else served by the httpd server renewed without incident, but the separate cert covering this subdomain failed completely. I commented out the rewrite, and ran the test again, and both renewed without incident. I posted a redacted version of the complete VirtualHost blocks back on August 24th. And after I'd run my tests this week, I've also posted it to ServerFault, at https://serverfault.com/q/1041047/498231 I'm intrigued by Mr. Schultz's suggestion of Maybe you just want RedirectPermanent instead of Rewrite(Cond|Rule)? Would that make a difference? Or is it just a matter of altering the RewriteCond clause to specifically ignore anything that looks like a Let's Encrypt challenge? Or is there something I can put on the default landing page for the subdomain, rather than in the VirtualHost, to cause the redirection? As I recall (unless there's a way to force-expire the cached challenge result on a certbot call), I have to wait until December to run another test. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Our webapp is running very slowly on one particular customer box
First, thanks once again, Mr. Schultz, for getting back to me. I noticed something rather promising: it seems that maxThreads for the Port 443 connector were set at 150 for System "A" (problem box), but 400 for System "J" (box that's quite happy). I've restarted Tomcat with the maxThreads bumped up to 400, and so far, it seems much happier than it was. That could have been the problem all along. My colleagues and I also observed that yesterday, when we did *not* shut down and restart, the slowdown and the nearly-full "tenured-SOA" portion of the heap eventually resolved itself, which suggests that it wasn't a memory leak in any even remotely conventional sense of the term. The page-faulting is a virtual memory term: on an AS/400, the entire combined total of main storage and disk is addressable (the concept is called "Single-Level Store"), and virtual storage paging is built into the OS at a very low level; a "page fault" is when a process finds tries to access something that's been paged out to disk. As to the private memory pool, it's not that the subsystem is restricted to its private pool; rather, everything else is kept *out* of that private pool. It still has full access to the "Machine" and "Base" shared pools. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Our webapp is running very slowly on one particular customer box
This is related to my query (thanks, Mr. Gregg) about "Tenured SOA." It seems that on one of our customer installations, our webapp gets into a state of running very slowly, and the dedicated subsystem it's running in is showing massive levels of page-faulting. I've compared the GC stats of the "problem" system with one that's actually got more users connected, but isn't experiencing performance issues. It seems that they're both going to GC about every 30-50 seconds, but GC on the "problem" system appears to be somewhat less effective. Also, I've looked at the threads on both. On the system that is behaving normally, the "GC Slave" threads (7 of them) are showing total CPU (at this moment) of around 150 seconds each, and Aux I/O of mostly zero, with one showing 1 and one showing 3. Conversely, on the "problem" system, I'm seeing 15(!) GC Slave threads, each with total CPU under 6 seconds each, but Aux I/O ranging from 5800 to over 8000. I'm not sure what to make of this. In both cases, Tomcat's JVM is running in a subsystem of its own, with a private memory pool of around 7G, and they're both running with -Xms4096m -Xmx5120m. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
What exactly is "tenured-SOA"?
In at least two of our Tomcat installations, the Server Status page of Manager is showing "tenured-SOA" around 3G, while the other pools are showing much lower. What exactly *is* "tenured-SOA," and should this be cause for alarm? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
