Re: mod_jk on Mac OS X 10.10 (Yosemite)
Chris On 12 Nov 2014, at 5:13am, Christopher Schultz ch...@christopherschultz.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 William, On 11/11/14 6:41 AM, William Moore wrote: It turns out this was happening because the upgrade to Yosemite had deleted all the files in /usr/include. I removed the replaced the folder /usr/include with a link to /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include and then configure and make both worked. I think you probably wanted to reinstall Xcode's command-line utilities instead of the above hack. You’re correct - I did need to install the command line tools again. Perhaps there is a different way to tell configure and make to use an additional include folder, but I don’t know how to do that (I work on Java mostly, not this stuff). You can use the CFLAGS environment variable, like this: $ CFLAGS=-I/path/to/include/files ./configure --options ... It may or may not work... specifying the CC environment variable works for configure and build, but not libtool which ignores the CC setting used during configure. I think that's a problem with the mod_jk build process, but I'm not good enough at configure/make/libtool to know how to fix it. I'll work with Rainer to solve that... he knows a lot more than I do about the Apache toolchain… I’ll try that next time I need to rebuild mod_jk, although that is not likely to be in the near future. - -chris Thank you William - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[ANN] Apache Tomcat 8.0.15 available
The Apache Tomcat team announces the immediate availability of Apache Tomcat 8.0.15. Apache Tomcat 8 is an open source software implementation of the Java Servlet, JavaServer Pages, Java Unified Expression Language and Java WebSocket technologies. Apache Tomcat 8.0.15 includes numerous fixes for issues identified in 8.0.14 as well as a number of other enhancements and changes. The notable changes since 8.0.14 include: - Add support for RFC6265 cookie parsing and generation. This is currently disabled by default and may be enabled via the CookieProcessor element of a Context. - Add pluggable password derivation support to the Realms via the new CredentialHandler interface. - Add support for TLSv1.1 and TLSv1.2 for APR connector. Based upon a patch by Marcel Šebek. This feature requires Tomcat Native library 1.1.32 or later. - Disable SSLv3 by default for all HTTPS connectors Please refer to the change log for the complete list of changes: http://tomcat.apache.org/tomcat-8.0-doc/changelog.html Downloads: http://tomcat.apache.org/download-80.cgi Migration guides from Apache Tomcat 5.5.x, 6.0.x and 7.0.x: http://tomcat.apache.org/migration.html Enjoy! - The Apache Tomcat team - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Unable to disable SSL in Tomcat 6 for poodle Vulnerability!
Ignoring the option to upgrade to Tomcat 7, i tried to configure server.xml in several differrent ways, but yet SSL protocol was enable. I see below update on Tomcat site ( http://ci.apache.org/projects/tomcat/tomcat6/docs/changelog.html ) about poodle fixes. Disable SSLv3 by default for the APR/native HTTPS connector. Disable SSLv3 by default (along with SSLv2 which was already disabled by default) in light of the recently announced POODLE vulnerability Are these being worked upon. Can you please tell me Changelog*Tomcat 6.0.43 (markt)* *Catalina* [image: fix] Assert that mapping result object is empty before performing mapping work in Mapper. (kkolinko) *Coyote* [image: fix] 53952 http://issues.apache.org/bugzilla/show_bug.cgi?id=53952: Add support for TLSv1.1 and TLSv1.2 for APR connector. Based upon a patch by Marcel Šebek. (schultz/jfclere) [image: fix] 57102 http://issues.apache.org/bugzilla/show_bug.cgi?id=57102: Fix bug that meant sslEnabledProtocols setting was not recognised for the HTTPS NIO connector. (markt) [image: add] Disable SSLv3 by default for the APR/native HTTPS connector. (markt/schultz) [image: fix] Do not increase remaining counter at end of stream in IdentityInputFilter. (kkolinko) [image: fix] Disable SSLv3 by default (along with SSLv2 which was already disabled by default) in light of the recently announced POODLE vulnerability (CVE-2014-3566). (markt) On Sun, Nov 2, 2014 at 11:56 PM, Hassan Schroeder hassan.schroe...@gmail.com wrote: On Sun, Nov 2, 2014 at 10:09 AM, Utkarsh Dave utkarshkd...@gmail.com wrote: Is there any other way to disable SSL in Tomcat 6. How many ways do you need? The process described in this thread works as indicated with 6.0.37. -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Connection count explosion due to thread http-nio-80-ClientPoller-x death
On 10/11/2014 09:57, Lars Engholm Johansen wrote: Hi Mark, I looked into our javax.websocket.Endpoint implementation and found the following suspicious code: When we need to close the WebSocket session already in .onOpen() method (rejecting a connection), we are calling session.close() asynchronously after 1 second via a java.util.Timer task. This was due to bug https://issues.apache.org/bugzilla/show_bug.cgi?id=54716, that I can see should be fixed long time ago (thanks). Can this cause the selector's keyset to be accessed by more than one thread? I don't see how. I've just double checked the NIO Poller code and the only places the keyset is used is in Poller.run() and Poller.timeout() - both of which are only ever accessed from the Poller thread. I've also looked over the run() and timeout() methods and haven't yet found anything that could trigger this. There are multiple Pollers but each Poller has a distinct set of sockets to manage. I'm beginning to wonder if there is a JVM bug here. Which JVM are you using? Mark Best regards, Lars Engholm Johansen On Mon, Oct 6, 2014 at 2:14 PM, Mark Thomas ma...@apache.org wrote: On 06/10/2014 10:11, Lars Engholm Johansen wrote: Hi all, I have good news as I have identified the reason for the devastating NioEndpoint.Poller thread death: In rare circumstances a ConcurrentModification can occur in the Poller's connection timeout handling called from OUTSIDE the try-catch(Throwable) of Poller.run() java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.nextEntry(HashMap.java:922) at java.util.HashMap$KeyIterator.next(HashMap.java:956) at java.util.Collections$UnmodifiableCollection$1.next(Collections.java:1067) at org.apache.tomcat.util.net.NioEndpoint$Poller.timeout(NioEndpoint.java:1437) at org.apache.tomcat.util.net.NioEndpoint$Poller.run(NioEndpoint.java:1143) at java.lang.Thread.run(Thread.java:745) Somehow the Poller's Selector object gets modified from another thread. Any idea how? I've been looking through that code for some time now (this stack trace appears to be from 7.0.55 for those that want to look at this themselves) and I can't see anywhere where the selector's keyset is accessed by more than one thread. As a remedy until fixed properly by the Tomcat team, I have added a try-catch(ConcurrentModificationException) surrounding the for loop in Poller.timeout(). That way, in case of the rare problem, a full iteration of the Selector will be retried in the next call to Poller.timeout(). That seems like a reasonable work-around but before we start making changes to the Tomcat code I'd really like to understand the root cause(s) of the issue else we might not be fixing the actual issue and could make it worse for some folks. Mark I am really happy now as all our production servers have been rock stable for two weeks now. Best regards to all, Lars Engholm Johansen On Thu, Sep 18, 2014 at 7:03 PM, Filip Hanik fi...@hanik.com wrote: Thanks Lars, if you are indeed experiencing a non caught error, let us know what it is. On Thu, Sep 18, 2014 at 2:30 AM, Lars Engholm Johansen lar...@gmail.com wrote: Thanks guys for all the feedback. I have tried the following suggested tasks: - Upgrading Tomcat to the newest 7.0.55 on all our servers - Problem still persists - Force a System.gc() when connection count is on the loose - Connection count is not dropping - Lowering the log level of NioEndpoint class that contains the Poller code - No info about why the poller thread exits in any tomcat logs - Reverting the JVM stack size per thread to the default is discussed previously - Problem still persists I have now checked out the NioEndpoint source code and recompiled it with a logging try-catch surrounding the whole of the Poller.run() implementation as I noticed that the outer try-catch here only catches OOME. I will report back with my findings as soon as the problem arises again. /Lars On Fri, Jun 27, 2014 at 9:02 PM, Christopher Schultz ch...@christopherschultz.net wrote: Filip, On 6/27/14, 11:36 AM, Filip Hanik wrote: Are there any log entries that would indicate that the poller thread has died? This/these thread/s start when Tomcat starts. and a stack over flow on a processing thread should never affect the poller thread. OP reported in the initial post that the thread had disappeared: On 6/16/14, 5:40 AM, Lars Engholm Johansen wrote: We have no output in tomcat or our logs at the time when this event occurs. The only sign is when comparing full java thread dump with a dump from a newly launched Tomcat: One of http-nio-80-ClientPoller-0 or http-nio-80-ClientPoller-1 is missing/has died. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For
Re: Tomcat NIO broken connections
On 10/11/2014 11:53, Jan Dosoudil wrote: Hi, we have web application running MyFaces, Richfaces (+ Atmosphere 1.0.18) on Tomcat 7.0.55, Oracle JDK 7u67. Tomcat is configured to use Nio connector: Connector URIEncoding=UTF-8 acceptCount=150 compressableMimeType=text/html,text/xml,text/css,text/javascript compression=on compressionMinSize=2048 connectionTimeout=6 disableUploadTimeout=true enableLookups=false maxHttpHeaderSize=8192 maxThreads=150 noCompressionUserAgents=gozilla, traviata port=8090 protocol=org.apache.coyote.http11.Http11NioProtocol socket.bufferPool=0 useBodyEncodingForURI=true/ Problem is that user opens application in browser and sometimes sees only blank page and spinning load indicator, indefinitely. It's caused by one or more css/javascript resources in page that didn't load. Browser console shows that request has been sent and it is waiting for response. Using apache-bench and wireshark I found that tomcat sends RST packet, here are related log items: snip/ Do you have any idea how to debug this or whether It is known bug or there is some workaroud? It doesn't match any known bugs I am familiar with. My best guess is that something is retaining a reference to an async object longer than is should. Tomcat recycles that object to re-use it and then you get a conflict between the new and old users of that object. Enabling debug level logging for protocol might shed some light. Something to consider (as a change in Tomcat) would be using a facade around the SocketWrapper so that when the SocketWrapper is recycled it can be nulled out in the facade. Given the increasing use of async and non-blocking this could be something that would be generally useful. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Question about Windows Auth howto
I am looking at implementing AD authentication for Tomcat. Being new to Tomcat, I am trying to check the information before setting this up. The how to shows one part being done on the AD Domain controller and the other being done on the tomcat server. This seems to infer that I would also need to install tomcat on the domain controller to perform the needed steps on the DC. I would prefer not to do that unless there is no other choice. Since the server that tomcat is running on is a member server in the domain, can I do the steps in the howto on the tomcat member server instead ? http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html I have been looking for other information on this but havent had a lot of luck. I have this working with secure ldap but have been told to go with native AD instead. Ron
Re: Question about Windows Auth howto
On 12/11/2014 16:50, Nutter, Ronald wrote: I am looking at implementing AD authentication for Tomcat. Being new to Tomcat, I am trying to check the information before setting this up. The how to shows one part being done on the AD Domain controller and the other being done on the tomcat server. This seems to infer that I would also need to install tomcat on the domain controller to perform the needed steps on the DC. What makes you think that? I would prefer not to do that unless there is no other choice. Since the server that tomcat is running on is a member server in the domain, can I do the steps in the howto on the tomcat member server instead ? You can try it but it has only been tested with running those commands on the domain controller. They might work on a server that is a domain member. Mark http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html I have been looking for other information on this but havent had a lot of luck. I have this working with secure ldap but have been told to go with native AD instead. Ron - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question about Windows Auth howto
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, November 12, 2014 11:46 AM To: Tomcat Users List Subject: Re: Question about Windows Auth howto On 12/11/2014 16:50, Nutter, Ronald wrote: I am looking at implementing AD authentication for Tomcat. Being new to Tomcat, I am trying to check the information before setting this up. The how to shows one part being done on the AD Domain controller and the other being done on the tomcat server. This seems to infer that I would also need to install tomcat on the domain controller to perform the needed steps on the DC. What makes you think that? RN Since the Domain Controller is specifically called out by role I would prefer not to do that unless there is no other choice. Since the server that tomcat is running on is a member server in the domain, can I do the steps in the howto on the tomcat member server instead ? You can try it but it has only been tested with running those commands on the domain controller. They might work on a server that is a domain member. Mark RN Will try it on the server running tomcat which is a member of the domain. Just wanted to check to be on the safe side. I try not to install anything on the domain controllers, just to be on the safe side. Ron - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Question about Windows Auth howto
On 12/11/2014 18:26, Nutter, Ronald wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, November 12, 2014 11:46 AM To: Tomcat Users List Subject: Re: Question about Windows Auth howto On 12/11/2014 16:50, Nutter, Ronald wrote: I am looking at implementing AD authentication for Tomcat. Being new to Tomcat, I am trying to check the information before setting this up. The how to shows one part being done on the AD Domain controller and the other being done on the tomcat server. This seems to infer that I would also need to install tomcat on the domain controller to perform the needed steps on the DC. What makes you think that? RN Since the Domain Controller is specifically called out by role Again, where does it say you need to install Tomcat on the domain controller? Mark I would prefer not to do that unless there is no other choice. Since the server that tomcat is running on is a member server in the domain, can I do the steps in the howto on the tomcat member server instead ? You can try it but it has only been tested with running those commands on the domain controller. They might work on a server that is a domain member. Mark RN Will try it on the server running tomcat which is a member of the domain. Just wanted to check to be on the safe side. I try not to install anything on the domain controllers, just to be on the safe side. Ron - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Question about Windows Auth howto
-Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, November 12, 2014 12:28 PM To: Tomcat Users List Subject: Re: Question about Windows Auth howto On 12/11/2014 18:26, Nutter, Ronald wrote: -Original Message- From: Mark Thomas [mailto:ma...@apache.org] Sent: Wednesday, November 12, 2014 11:46 AM To: Tomcat Users List Subject: Re: Question about Windows Auth howto On 12/11/2014 16:50, Nutter, Ronald wrote: I am looking at implementing AD authentication for Tomcat. Being new to Tomcat, I am trying to check the information before setting this up. The how to shows one part being done on the AD Domain controller and the other being done on the tomcat server. This seems to infer that I would also need to install tomcat on the domain controller to perform the needed steps on the DC. What makes you think that? RN Since the Domain Controller is specifically called out by role Again, where does it say you need to install Tomcat on the domain controller? Mark I had not seen these commands before so I got the impression that they were something that was installed as a part of Tomcat. Will proceed without that impression and see what happens. Ron RN Since the section is titled Domain Controller, that indicated to me that in order to I would prefer not to do that unless there is no other choice. Since the server that tomcat is running on is a member server in the domain, can I do the steps in the howto on the tomcat member server instead ? You can try it but it has only been tested with running those commands on the domain controller. They might work on a server that is a domain member. Mark RN Will try it on the server running tomcat which is a member of the domain. Just wanted to check to be on the safe side. I try not to install anything on the domain controllers, just to be on the safe side. Ron - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Feature suggestion: excludeCiphers
Tomcat has been one of my favorite pieces of software for about a decade. Thanks to all your generous contributions it just keeps getting better! I appreciate the focus on security in Tomcat 8. Suggestion: = Instead of specifying allowed ciphers in the Connector node of server.xml, I'd like to specify dis-allowed/excluced ciphers so that as new, better cipher suites become available we won't have to do anything. Maybe an excludeCiphers attribute? Background: = We're getting an 'A' on the Qualys TLS test with stand-alone Tomcat, which is pretty cool: https://www.ssllabs.com/ssltest/index.html Mostly, that's because of the following settings (in case this helps anyone): Connector port=8443 protocol=org.apache.coyote.http11.Http11NioProtocol maxThreads=150 SSLEnabled=true scheme=https secure=true clientAuth=false sslEnabledProtocols=TLSv1,TLSv1.1,TLSv1.2 compression=on disableUploadTimeout=true connectionTimeout=18 URIEncoding=UTF-8 keystorePass=notTheRealPassword ciphers=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA256, TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA / It seems like just a few years ago there were about 50 cipher suites to choose from. Now there are 12 that work with TLS. Eight of those have Forward Security (the 8 listed above). Presumably those eight will also become outdated over time and new ones will be added to replace them. The problem with specifying ciphers as above is that someone will have to know when and how to manually update the cipher list. With each upgrade of Java, we need to remember to do something like the following: - Delete the ciphers attribute - Restart tomcat - Test here: https://www.ssllabs.com/ssltest/index.html - Copy the list of cipher suites - Delete any that don't support Forward Security - Make a new ciphers attribute. - Verify that the browsers and devices we support will still work. To be honest, I'm not sure if that needs to be done with each Java patch release, or only when Java 9 comes out. If instead of specifying valid ciphers, I specified invalid ones, then the new ones would just flow through the system and become available without me doing anything! Thank you in advance for considering this suggestion. @GlenKPeterson - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
