Tomcat 7.0.39 - Embedded Tomcat within Eclipse Juno doesn’t pick assets from DOC ROOT
Hi, I have developed Struts 2 application which is deployed on Tomcat. I am using Eclipse to do the coding and configured Tomcat with Eclipse to deploy the war from Eclipse itself. My requirement is that all static assets should be served from Apache HTTP Server because in our production environment that will be the set up. As a result, I have configured image URLS like – The assumpition is common folder will be the present in the doc root. I have copied common folder in the ROOT of Tomcat so that it can be accessed from /common in the URL. However, my images are not getting picked with the above URL. However, if I create a war file using Maven and deploy it on the server, /common works. So I think it may be the problem wuth embedded tomcat instance within eclipse for which may be ROOT is not the doc root. Can anyone suggest how can it work i.e. deploying application from eclipse to a configured tomcat instance in eclipse ? Thanks. Regards, SAURABH AGRAWAL Manager Technology — SapientNitro Aachvis Softech Private Limited SEZ, “Oxygen”, (Tower C), Ground – 3rd Floor, Plot No. 7, Sector 144 Expressway, Noida 201 304, Uttar Pradesh, India desk +91 (120) 479 5000 mobile +91 981 866 4383 fax +91 (120) 479 5001 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
A Couple of 8.0.0 WebSocket Questions
Dear all, 1. I see how to close a session from either end of the connection. That, of course, leaves the underlying endpoint intact. Is there a way to un-deploy an entire server endpoint so that no new connections can be made to it? If so, will it close existing sessions? 2. Is there a way to query the ServerContainer for deployed endpoints? I'd like to do that to check that there isn't already one at a given path. The only solution I've found so far is to try to deploy it and, if the generic DeploymentException is thrown, parse the error message. Not great. 3. What's the recommended way of binding an HTTP session to a Websocket one? I was able to get this to work by using a custom ServerEndpointConfig.Configurator class that augments the base modifyHandshake() method by stashing the HTTP session in a ThreadLocal variable. Seems like the linkage between the WebSocket session and the HTTP session is so basic that perhaps there's a more straightforward way to do this? Many thanks in advance and apologies if this has been covered on this list or I'm overlooking it in the docs. -Igor.
Cannot create tomcat-6.0.29 daemon
I have successfully installed tomcat-6.0.29 on ubuntu-12.04. Never had problem starting from /opt/tomcat-6.0.29/bin/startup.sh. I had no error on the first part. I'm stuck on this part. CATALINA_BASE=$CATALINA_HOME cd $CATALINA_HOME >>when I issue this command it goes to my root folder instead of going to my tomcat folder which is /opt/tomcat-6.0.29. >>my workaround i skip cd $CATALINA_HOME and just stay on my /opt/tomcat-6.0.29 >>folder ./bin/jsvc \ >>when I run this using the cd $CATALINA_HOME, It will give me an error that no >>such file or directory >>my workaround never issue the cd $CATALINA_HOME -classpath $CATALINA_HOME/bin/bootstrap.jar \ -outfile $CATALINA_BASE/logs/catalina.out \ -errfile $CATALINA_BASE/logs/catalina.err \ >>Gives an error no such file or directory, not present in the $CATALINA_HOME -Dcatalina.home=$CATALINA_HOME \ -Dcatalina.base=$CATALINA_BASE \ -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ -Djava.util.logging.config.file=$CATALINA_BASE/conf/logging.properties \ org.apache.catalina.startup.Bootstrap >>20568 jsvc error: no classpath specified >>20568 jsvc error: Cannot parse command line arguments
Re: Tomcat & ipv6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Olivier, Please do not hijack threads by replying to an existing message on the list. Instead, start a completely new message with the desired subject. - -chris On 8/9/13 2:46 PM, olivier giorgi wrote: > Hello to all, > > How to configure Tomcat in ipv6 ? > > What are the corresponding changes to be done in server.xml ? > > Is there a specific JVM argument ? > > Thanks in advance. Best regards Olivier. > -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBUqVAAoJEBzwKT+lPKRYMVoQAJUwhCsW84lxm1CvWdD5nkOe X4yiAsj/R0ZEiD/mDZ9OvGHXqD38fOHbdZXlliwvj5m6M+/csQ8rw7sKhon0shK3 nUVfiXSnfgwhGihu/G3JVnNba67FlFlceDWCgRnwxbPtIIIWE0Wt3AMgwmM1Cskm CfF49M59XHp7wKpEUUUyhqrwGUoRd2fJeONZ7vtwpl4CktH8WOwJMXRmco4CVP2f s6vRUA+SwEl0SQnin0TbJY/PQpjh/1d5UARPMI/rKN8aECc00IVflG6f354u++Cj uRYoOwsf3u6Vkssv6nFHXWH9mzfEPsiYGacbqFY+HqT8AXlYVHXi4Kq6mxQURETz iG3QoX7y/E6d/t2LbNR3kUnJrSbIR83DUaGoUVS2FmRhOq2DkT3JtueezuMAFiXq K4ww6Lt/HkJ9XRs9Pk4lxT1z4Ve6bP0/42KfhiDHoCjEKvhp2pT2VCulSvBmWbOi OgCrA1Em8UIQX2gyVXmUKZJSl3JfQ6++YBL/p0wW3nIPIb3iHSE5TsIBqTsTWYeL 2B9hv8ncprlbi0MMykJ82iCflruWmiY5sbRuhMO5qKBaBtDVBSFDMAG6kVaVTZPZ 7gpYrkx+QD4+K6NDz3DAIRKZLE+B0x6T/edHN4tzewPL4ZCjcvjFFgBPZ6DG3g31 AfzCSmYGujYN9R1zB5lY =7eI6 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Tomcat & ipv6
Hello to all, How to configure Tomcat in ipv6 ? What are the corresponding changes to be done in server.xml ? Is there a specific JVM argument ? Thanks in advance. Best regards Olivier.
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 12:17 PM, Mark Eggers wrote: > On 8/9/2013 8:10 AM, Mark Thomas wrote: >> On 09/08/2013 15:28, Christopher Schultz wrote: >>> Mark, >>> >>> On 8/9/13 9:14 AM, Mark Thomas wrote: On 09/08/2013 14:50, Christopher Schultz wrote: >>> > It's too bad it took a researcher a year to figure out > that compression of any kind makes encryption (where the > attacker can force random probing attacks) weak. It's not > like SSL+compression and SSL-compression+compression is > that different. >>> It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. >>> >>> I wouldn't say this constitutes a "fuss". >> >> "fuss" was a reference to how some folks are reacting to this >> "new" attack, "BREACH". First it isn't new, second it isn't (in >> my view) practical. >> The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. >>> >>> Coffee shop + XSS? Perhaps a stretch. >> >> To succeed, the attacker requires: >> >> a) The victim is using a site that uses HTTP-level compression >> on responses b) The site echoes user input in HTTP response >> bodies c) The response bodies contain a constant secret (eg. CSRF >> token) >> >> So far, not too hard. c) is a little unusual. Session IDs are >> normally in cookie headers, CSRF tokens should change on every >> request. That said, there are plenty of sites that meet a) to >> c). >> >> d) The attacker has the ability to view the victim's encrypted >> traffic. e) The attacker has the ability to cause the victim to >> send HTTP requests to the vulnerable web server. >> >> e) is where I think this attack becomes impractical. This may >> change over time but at the moment the coffee shop scenario would >> require social engineering the victim or subverting the router if >> the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin >> is another option with mixed HTTP/HTTPS. > > I was reading about the pineapple wifi mark iv the other day. It > looks to be a particularly powerful piece of pen testing equipment. > This tool in a coffee shop would probably be all you need to have a > good chance at e). > > In short, don't do banking (or other sensitive work) at a coffee > shop when the pages are a mix of HTTP and HTTPS. Lots of people will stupidly connect to any unencrypted WiFi when they are out and about. I'd say this is a fairly plausible attack vector. Note that unencrypted + encrypted traffic is not necessary. You can just look over someone's shoulder to see what bank they're using. These days in the US most people use one of only like 5 banks. (It's kind of sad.) Once you know the site that is being used, just browse there yourself and attempt to login: you can probably see what kind of authentication / session tracking is being used without tricking the target into revealing that kind of information to you via HTTP (i.e. without HTTPS). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRr1AAoJEBzwKT+lPKRYxHwP/2WZmt7P+gtsiZ2Qx/S+idmr xN+k/XHS4kaxWOBdo8sK3lzZYE9mB5ROtsuVYQQZ1WRJaQS0Vb09/VCJ4GnpOSFf SR9aThyAXCxnnxF2vviTZUL93Dwh0LM/HwbRGpjYy5Tns0+qXATwm1IBNK3jzarF Mvx2SOrMAGqiTEet9CqW/7yYQV31kFpLaZGiDsdJT6FM+mBG8OrVcYstBr0b6qXF LC2IILQshvHvcAUmAEDDPO8NRfgxCY+4uzY9M028DromKeliAQ7PO0KD4E3nErZZ xL5ysEgSKSahd+0a1QJRXvLccb4XRLL9GCcSP9/TvUzqbOahWUDrIHgLGJWZYAfS ql4nO2QLtVDfTdtgBUyuNQsn+AlJZHR96g/N7lHuxZU8fap5Auir8xFijWDRWrdn LfykGonHPZ75UDlOFQmMUPM/8H6AFbymw9R8ZhpbCMwEPAU/SqVARbCLAThIVQWN zrroWjVqMLdUTbdqvT3Xi9EnmXkPuszHGjqQRtVgt60MRRZ63bkM8+F2hnJGlSId VpUFi6RrK0wM4TFd2viGlW7SbSbl/vSHAPruAYzwAJvkI+g2QduW8HVV4lESyZ+T C9vVnz59BJwsokc5H3ykNCcnurkaWCBwEm70LTc9MQKlS8ICyOtKX31TugZvzPKv EiJZhuKGsOZR/+lf3ser =98t0 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 8/9/2013 8:10 AM, Mark Thomas wrote: On 09/08/2013 15:28, Christopher Schultz wrote: Mark, On 8/9/13 9:14 AM, Mark Thomas wrote: On 09/08/2013 14:50, Christopher Schultz wrote: It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. I wouldn't say this constitutes a "fuss". "fuss" was a reference to how some folks are reacting to this "new" attack, "BREACH". First it isn't new, second it isn't (in my view) practical. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. I was reading about the pineapple wifi mark iv the other day. It looks to be a particularly powerful piece of pen testing equipment. This tool in a coffee shop would probably be all you need to have a good chance at e). In short, don't do banking (or other sensitive work) at a coffee shop when the pages are a mix of HTTP and HTTPS. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. Indeed. If only everyone was approaching this with the same sense of perspective. I agree the attacks will only get better / easier / more practical but right now there are some big obstacles and I don't see any obvious roots to getting over them. Mark I'm not a security person, nor do I play one online. . . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrade to Tomcat 7 Issues
On 8/9/2013 8:46 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 8/9/13 10:08 AM, Caldarale, Charles R wrote: From: Seema Patel [mailto:seema...@hotmail.com] Subject: RE: Upgrade to Tomcat 7 Issues In my WEB-INF/lib I have the following (sorry the list is quite long): activation.jar In Tomcat7.0/lib directory I have (I have grouped them alphabetically so it doesn't make the list too long downwards, like the above list) activation.jar j2ee.jar You must never, never, never have the same class files in multiple locations in the class loader hierarchy (e.g., activation.jar and several others). I don't think "activation" is something provided by servlet containers. I don't see it in a stock Tomcat, for example. JavaBeans activation framework (activation.jar) was required for Java mail when running on older versions of the JRE. It has been included since JRE 6 (can't remember the minor version). Since the original poster has upgraded to JRE 7, there should be no need for this JAR either in $CATALINA_HOME/lib or WEB-INF/lib of the application. Also, j2ee.jar must never be present anywhere in any Tomcat installation. I'm not sure what's in this particular j2ee.jar, but you're probably right that it does not belong. The container should provide all services to the webapp. If you want a more fully-functional J2EE container, consider Apache TomEE. You need to start over, not adding anything to Tomcat's lib directory, and try running your webapp. Absolutely. - -chris . . . . just my two cents. /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Upgrade to Tomcat 7 Issues
> From: Christopher Schultz [mailto:ch...@christopherschultz.net] > Subject: Re: Upgrade to Tomcat 7 Issues > I don't think "activation" is something provided by servlet > containers. I don't see it in a stock Tomcat, for example. It's not provided by Tomcat, but that's not the relevant point. The problem was that it was placed in _both_ Tomcat's lib directory and the webapp's WEB-INF/lib directory - an absolute no-no. It can be in each webapp's WEB-INF/lib directory (since the relevant class loaders can't see each other), or possibly in Tomcat's lib directory (although it might cause other problems there, depending on how it's coded). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrade to Tomcat 7 Issues
On 8/9/2013 11:46 AM, Christopher Schultz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 8/9/13 10:08 AM, Caldarale, Charles R wrote: From: Seema Patel [mailto:seema...@hotmail.com] Subject: RE: Upgrade to Tomcat 7 Issues In my WEB-INF/lib I have the following (sorry the list is quite long): activation.jar In Tomcat7.0/lib directory I have (I have grouped them alphabetically so it doesn't make the list too long downwards, like the above list) activation.jar j2ee.jar You must never, never, never have the same class files in multiple locations in the class loader hierarchy (e.g., activation.jar and several others). I don't think "activation" is something provided by servlet containers. I don't see it in a stock Tomcat, for example. It's not; it's part of the mail package. But the OP still has it in multiple places. Probably placed in Tomcat7.0/lib manually, and in WEB-INF/lib automatically. Also, j2ee.jar must never be present anywhere in any Tomcat installation. I'm not sure what's in this particular j2ee.jar, but you're probably right that it does not belong. The container should provide all services to the webapp. If you want a more fully-functional J2EE container, consider Apache TomEE. You need to start over, not adding anything to Tomcat's lib directory, and try running your webapp. Absolutely. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBQ7bAAoJEBzwKT+lPKRYz0MQAJ95UbypXpJfS/a9DcqtgB+Z VL4mVwtrKZfNRAK+vyP8yg/N3FYi+KIFPslZlYUj4/lH49srTQewlYkfw3Z9CaPR aySxb/UN1EOnTyoW3jGzATC2u8+W8lMSDj6w8nBsefPoAkiQqrsaHpeUtvms+BJG W3GRUwaTxIjo3J8anoCSea+LMTjYHROQeuECk+eXCMkm0hHC6KYAxKNB3cc2sqiP zLkh2H8FalQORizUI43XC2H9R+deno8W6HtGnFowOcWIkZIQOok7V1GZGjNrPkB4 VEDQYn0tLvWMH9TpDpU8F3L0h2WedrX4LPVk+iYPI0jbuH2iFmtk8hCvVKv5LZ3O teA7axTtOTm2LrkAA8luNWNyPVdMlr8dphKpIFQHVytq8EQNAEx3W5LBlYc1hKb9 WpML80J7BIEhJjkuB4rzX1BRqd8tmF7c1LBAl77QgDhkD8Hk66+lLKdsSo9T/B8t 6c2L+/RIpDl2H5ru3oCWlHRw3LF5I4qyh/qSEdqU0udrj+rGMAOP+qIFLhndRKSO hb4sYipTlplI9Q1pI9skOTNQOFN5ThBjU4WoRnsbvQtjXnmEoR0lV3eUKkPBRuQS chjmbfw1YdygMNIZEw36dclkPG4Vt3XjQZ8EudAb226BUDF5khpSlooDLEajMiXy 1lAcbwTnbcvjFKXyScTi =CKJe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 11:10 AM, Mark Thomas wrote: > On 09/08/2013 15:28, Christopher Schultz wrote: >> Mark, >> >> On 8/9/13 9:14 AM, Mark Thomas wrote: >>> On 09/08/2013 14:50, Christopher Schultz wrote: >> It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. >> >>> It didn't. The original CRIME presentation covered this topic. >>> I fail to understand why such a fuss is being made of this >>> re-hashing. >> >> I wouldn't say this constitutes a "fuss". > > "fuss" was a reference to how some folks are reacting to this > "new" attack, "BREACH". First it isn't new, second it isn't (in my > view) practical. Fair enough. >>> The original CRIME presentation also (correctly) pointed out >>> that any attack based on this is entirely theoretical and not >>> currently at all practical. >> >> Coffee shop + XSS? Perhaps a stretch. > > To succeed, the attacker requires: > > a) The victim is using a site that uses HTTP-level compression on > responses b) The site echoes user input in HTTP response bodies c) > The response bodies contain a constant secret (eg. CSRF token) > > So far, not too hard. c) is a little unusual. Session IDs are > normally in cookie headers, CSRF tokens should change on every > request. That said, there are plenty of sites that meet a) to c). > > d) The attacker has the ability to view the victim's encrypted > traffic. e) The attacker has the ability to cause the victim to > send HTTP requests to the vulnerable web server. > > e) is where I think this attack becomes impractical. This may > change over time but at the moment the coffee shop scenario would > require social engineering the victim or subverting the router if > the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is > another option with mixed HTTP/HTTPS. I tend to agree: being able to both remotely monitor the victim's traffic *and* remotely-control the browser means that you already have quite a bit of control over the situation. Perhaps decrypting the SSL stream isn't the worst thing an attacker in such a position can accomplish. >> The point is that folks are starting to chip-away at certain >> aspects of TLS. Just like they did with hashing algorithms. MD5 >> was great when it came out. So was SSL. There's nothing wrong >> with looking toward the future, even if the current crop of >> problems aren't exactly catastrophic. > > Indeed. If only everyone was approaching this with the same sense > of perspective. I agree the attacks will only get better / easier / > more practical but right now there are some big obstacles and I > don't see any obvious roots to getting over them. Agreed. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBRAUAAoJEBzwKT+lPKRYKMsP/3ye2X1m8oZGMxDfjhOxLr+B xRS1SycborjXnEhAXnGAx+U1jFDzKPWQ0AdDMd2o4NKPqS6jWJTQ37CBeXN+25y2 0+FxZKP9FwrY94qY/dCNHK70nuUda6hpcGcpWRc78swh+hUnBzB0ue52WaaWjTJH DfTPcRu1zvIeXj1zylIG4GebqKOH1+5P+NgL37+hnzoIwGmsgJ2FeVpAXELrrtZJ wOcYguKLv0NrqkAx7CvZDmtr6a4ZpZvmyXpVGJlaoi/ejmQzDvtZDOFlsBaYOMwc 4HsweP4mEi7Ms3QYBzn9naVFXr1x+saaoO75F0jnRGE9yLJXbkhGgmpLM/+arnhO /laV3ZMqHLXZYu+cmZvD/JsdL2liAaMPcwEB3c1ebFuTI8ro7+/7qlVx+H2inGew 2DIvWePjAXyKuudL8GqqHTcsbe6nrbpB41fqRyWCBSxtZwLbUfxgfjfXRQOfkX5e 88f2FmL7/BHq7YgO368rreZWx+RVze2SVv7nGm20M7LzEP6Dd2k7etca+K+KdS9L ndNs4yHAtK8328dPsCsIYwcI767Y/5qTV3UIV0Bz8YDfjSYZvDQYVlCQRHs1VA/A xisZptwRA1jZro3WrTlgzjdHfTOcxIYDaL65eZUXcjGgXB2T9YeIAfguf7PFK5wC I6LlkxLa23oMvDL7Z2+c =RJjz -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrade to Tomcat 7 Issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chuck, On 8/9/13 10:08 AM, Caldarale, Charles R wrote: >> From: Seema Patel [mailto:seema...@hotmail.com] Subject: RE: >> Upgrade to Tomcat 7 Issues > >> In my WEB-INF/lib I have the following (sorry the list is quite >> long): activation.jar > >> In Tomcat7.0/lib directory I have (I have grouped them >> alphabetically so it doesn't make the list too long downwards, >> like the above list) > >> activation.jar j2ee.jar > > You must never, never, never have the same class files in multiple > locations in the class loader hierarchy (e.g., activation.jar and > several others). I don't think "activation" is something provided by servlet containers. I don't see it in a stock Tomcat, for example. > Also, j2ee.jar must never be present anywhere in any Tomcat > installation. I'm not sure what's in this particular j2ee.jar, but you're probably right that it does not belong. The container should provide all services to the webapp. If you want a more fully-functional J2EE container, consider Apache TomEE. > You need to start over, not adding anything to Tomcat's lib > directory, and try running your webapp. Absolutely. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBQ7bAAoJEBzwKT+lPKRYz0MQAJ95UbypXpJfS/a9DcqtgB+Z VL4mVwtrKZfNRAK+vyP8yg/N3FYi+KIFPslZlYUj4/lH49srTQewlYkfw3Z9CaPR aySxb/UN1EOnTyoW3jGzATC2u8+W8lMSDj6w8nBsefPoAkiQqrsaHpeUtvms+BJG W3GRUwaTxIjo3J8anoCSea+LMTjYHROQeuECk+eXCMkm0hHC6KYAxKNB3cc2sqiP zLkh2H8FalQORizUI43XC2H9R+deno8W6HtGnFowOcWIkZIQOok7V1GZGjNrPkB4 VEDQYn0tLvWMH9TpDpU8F3L0h2WedrX4LPVk+iYPI0jbuH2iFmtk8hCvVKv5LZ3O teA7axTtOTm2LrkAA8luNWNyPVdMlr8dphKpIFQHVytq8EQNAEx3W5LBlYc1hKb9 WpML80J7BIEhJjkuB4rzX1BRqd8tmF7c1LBAl77QgDhkD8Hk66+lLKdsSo9T/B8t 6c2L+/RIpDl2H5ru3oCWlHRw3LF5I4qyh/qSEdqU0udrj+rGMAOP+qIFLhndRKSO hb4sYipTlplI9Q1pI9skOTNQOFN5ThBjU4WoRnsbvQtjXnmEoR0lV3eUKkPBRuQS chjmbfw1YdygMNIZEw36dclkPG4Vt3XjQZ8EudAb226BUDF5khpSlooDLEajMiXy 1lAcbwTnbcvjFKXyScTi =CKJe -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 09/08/2013 15:28, Christopher Schultz wrote: > Mark, > > On 8/9/13 9:14 AM, Mark Thomas wrote: >> On 09/08/2013 14:50, Christopher Schultz wrote: > >>> It's too bad it took a researcher a year to figure out that >>> compression of any kind makes encryption (where the attacker can >>> force random probing attacks) weak. It's not like SSL+compression >>> and SSL-compression+compression is that different. > >> It didn't. The original CRIME presentation covered this topic. I >> fail to understand why such a fuss is being made of this >> re-hashing. > > I wouldn't say this constitutes a "fuss". "fuss" was a reference to how some folks are reacting to this "new" attack, "BREACH". First it isn't new, second it isn't (in my view) practical. >> The original CRIME presentation also (correctly) pointed out that >> any attack based on this is entirely theoretical and not currently >> at all practical. > > Coffee shop + XSS? Perhaps a stretch. To succeed, the attacker requires: a) The victim is using a site that uses HTTP-level compression on responses b) The site echoes user input in HTTP response bodies c) The response bodies contain a constant secret (eg. CSRF token) So far, not too hard. c) is a little unusual. Session IDs are normally in cookie headers, CSRF tokens should change on every request. That said, there are plenty of sites that meet a) to c). d) The attacker has the ability to view the victim's encrypted traffic. e) The attacker has the ability to cause the victim to send HTTP requests to the vulnerable web server. e) is where I think this attack becomes impractical. This may change over time but at the moment the coffee shop scenario would require social engineering the victim or subverting the router if the site mixed HTTP and HTTPS. A malicious ISP / $work sysadmin is another option with mixed HTTP/HTTPS. > The point is that folks are starting to chip-away at certain aspects > of TLS. Just like they did with hashing algorithms. MD5 was great when > it came out. So was SSL. There's nothing wrong with looking toward the > future, even if the current crop of problems aren't exactly catastrophic. Indeed. If only everyone was approaching this with the same sense of perspective. I agree the attacks will only get better / easier / more practical but right now there are some big obstacles and I don't see any obvious roots to getting over them. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Upgrade to Tomcat 7 Issues
Ok thanks for the help. I'll redo it again. If I get any further errors I'll post a new question. Thanks again. Seema > From: chuck.caldar...@unisys.com > To: users@tomcat.apache.org > Date: Fri, 9 Aug 2013 09:08:55 -0500 > Subject: RE: Upgrade to Tomcat 7 Issues > > > From: Seema Patel [mailto:seema...@hotmail.com] > > Subject: RE: Upgrade to Tomcat 7 Issues > > > In my WEB-INF/lib I have the following (sorry the list is quite long): > > activation.jar > > > In Tomcat7.0/lib directory I have (I have grouped them alphabetically > > so it doesn't make the list too long downwards, like the above list) > > > activation.jar > > j2ee.jar > > You must never, never, never have the same class files in multiple locations > in the class loader hierarchy (e.g., activation.jar and several others). > Also, j2ee.jar must never be present anywhere in any Tomcat installation. > You need to start over, not adding anything to Tomcat's lib directory, and > try running your webapp. If it fails, determine why, and decide where the > necessary .jar file should go (the answer is almost always WEB-INF/lib, > except for JDBC drivers when Tomcat is handling the connection pooling). > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY > MATERIAL and is thus for use only by the intended recipient. If you received > this in error, please contact the sender and delete the e-mail and its > attachments from all computers. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
RE: Upgrade to Tomcat 7 Issues
> From: Seema Patel [mailto:seema...@hotmail.com] > Subject: RE: Upgrade to Tomcat 7 Issues > In my WEB-INF/lib I have the following (sorry the list is quite long): > activation.jar > In Tomcat7.0/lib directory I have (I have grouped them alphabetically > so it doesn't make the list too long downwards, like the above list) > activation.jar > j2ee.jar You must never, never, never have the same class files in multiple locations in the class loader hierarchy (e.g., activation.jar and several others). Also, j2ee.jar must never be present anywhere in any Tomcat installation. You need to start over, not adding anything to Tomcat's lib directory, and try running your webapp. If it fails, determine why, and decide where the necessary .jar file should go (the answer is almost always WEB-INF/lib, except for JDBC drivers when Tomcat is handling the connection pooling). - Chuck THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Upgrade to Tomcat 7 Issues
In my WEB-INF/lib I have the following (sorry the list is quite long):
activation.jar
axis.jar
BTDslCheckerLib.jar (this is one of our java projects)
commons-beanutils.jar
commons-codec-1.3.jar
commons-collections.jar
commons-digester.jar
commons-discovery-0.2.jar
commons-fileupload.jar
common-httpclient-3.0.1.jar
commons-logging-1.0.4.jar
commons-validator.jar
ditchnet-tabs-taglib.jar
itext-1.4.jar
jaxen-core.jar
jaxen-jdom.jar
jaxrpc.jar
jbossall-client.jar
jcifs-1.2.17dynamic-dc.jar
jcifs-1.3.17.jar
jdom.jar
jstl.jar
log4j-1.2.13.jar
mail.jar
poi-2.5.1-final-20040804.jar
poi-3.7-20101029.jar
poi-contrib-2.5.1-final-20040804.jar
saaj.jar
saxpath.jar
SOPortalCommon.jar (this is one of our java projects)
standard.jar
struts.jar
struts-el.jar
commonlib.jar (this is one of our java projects)
portalcommonlib.jar (this is one of our java projects)
wsclients.jar (this is one of our java projects)
wsdl4j-1.5.1.jar
yahoo-toolkit.jar (this is one of our java projects that uses the yahoo toolkit
yui stuff)
In terms of upgrading, I downloaded jre7 and installed it, changed the projects
to use jre7 and in eclipse I pointed the installed JREs to use jre7.
I then downloaded Tomcat7, changed the server.xml file to have the Resource
tags/elements in GlobalNamingResources tag to point to my databases (9 Resource
tags in total, all taken from the server.xml file in Tomcat 5.5). In Service
tag/element, I have added the following:
I have commented out:
In the Engine tag/element I have added:
ldap://xxx:3268";
connectionName="xxx@xxx.local" connectionPassword="xxx"
referrals="follow" userBase="dc=xxx,dc=local"
userSearch="(sAMAccountName={0})" userSubtree="true"
roleBase="dc=xxx,dc=local" roleSearch="(member={0})"
roleName="cn" roleSubtree="true" />
which is just before the Host tag/element.
In Tomcat7.0/lib directory I have (I have grouped them alphabetically so it
doesn't make the list too long downwards, like the above list) (some of which I
have added, but not sure if they're needed):
activation.jar, annotations-api.jar
catalina.jar, catalina-ant.jar, catalina-ha.jar, catalina-tribes.jar
ecj-4.2.2.jar, el-api.jar
j2ee.jar
jasper.jar, jasper-el.jar
jaxen-core.jar, jaxen-jdom.jar, jdom.jar, jsp.jar, jtds-1.2.jar
log4j-1.2.13.jar
mysql-connector-java-5.0.8-bin.jar
naming-factory.jar, naming-facotry-dbcp.jar, naming-resources.jar
servlet-api.jar
tomcat-api.jar, tomcat-coyote.jar, tomcat-dbcp.jar, tomcat-i18n-es.jar,
tomcat-i18n-fr.jar, tomcat-i18n-ja.jar, tomcat-jdbc.jar, tomcat-util.jar
xmlrpc-1.2-b1.jar
I believe that's everything I have done, but I may have left something out, as
I have been trying to get it working for the pass 2 days and may have changed
something that I don't remember. If there is anything more you need to know
then please let me know.
Thanks
Seema
> Date: Fri, 9 Aug 2013 09:07:48 -0400
> From: ch...@christopherschultz.net
> To: users@tomcat.apache.org
> Subject: Re: Upgrade to Tomcat 7 Issues
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Seema,
>
> On 8/9/13 5:17 AM, Seema Patel wrote:
> > I've upgraded my tomcat from 5.5 to 7.0. I've also upgraded the jre
> > from 1.5 to 7.
> >
> > I'm trying to get my existing struts/servlets projects to run, but
> > I'm getting the following error when running tomcat in my
> > tomcat7-stderr...log file:
> >
> > INFO: Deploying configuration descriptor C:\Tomcat
> > 7.0\conf\Catalina\localhost\common.xml 09-Aug-2013 10:11:44
> > org.apache.catalina.core.ContainerBase addChildInternal SEVERE:
> > ContainerBase.addChild: start:
> > org.apache.catalina.LifecycleException: Failed to start component
> > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/common]]
> >
> >
> at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
> > at
> > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
> >
> >
> at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
> > at
> > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633)
> >
> >
> at
> org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656)
> > at
> > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1635)
> >
> >
> at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
> > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at
> > java.util.concurrent.FutureTask.run(Unknown Source) at
> > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
> > Source) at
> > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
> > at java.lang.Thread.run(Unknown Source) Caused by:
> > java.lang.NoSuchMethodError:
> > javax.servlet.ServletContext.getSessionCookieConfig()Ljavax/servlet/SessionCookieConfig;
> >
> >
> at org.apache.catalina.deploy.WebXml.configureContext(WebXml.java:1374)
> > at
> > org.apache.catalina.star
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Mark, On 8/9/13 9:14 AM, Mark Thomas wrote: > On 09/08/2013 14:50, Christopher Schultz wrote: > >> It's too bad it took a researcher a year to figure out that >> compression of any kind makes encryption (where the attacker can >> force random probing attacks) weak. It's not like SSL+compression >> and SSL-compression+compression is that different. > > It didn't. The original CRIME presentation covered this topic. I > fail to understand why such a fuss is being made of this > re-hashing. I wouldn't say this constitutes a "fuss". > The original CRIME presentation also (correctly) pointed out that > any attack based on this is entirely theoretical and not currently > at all practical. Coffee shop + XSS? Perhaps a stretch. The point is that folks are starting to chip-away at certain aspects of TLS. Just like they did with hashing algorithms. MD5 was great when it came out. So was SSL. There's nothing wrong with looking toward the future, even if the current crop of problems aren't exactly catastrophic. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBO5wAAoJEBzwKT+lPKRYxakP/2PXSoCBrzgvVjkKrmvOh2Ag 5IVuP5eoIVpTT/ud6d8/uYDnSVSA/OI64lFZqZDwuiu11XnMC/uxDc/O4cfbCxA4 AYu0BgY/NDPUCAyPIcjujP22oBZibvYVr9RFrTFHdtmAaVT7KiLglCUaJzxuZtt7 6/A1+y4Q5X+g40fukNtIbwW7Of3hA2KNPeWt5s6aivYaUdQDfdYfMYh+kED+JMhS HKpmaEBoj0KwOAv5iKbWaVphe+ZuFuqnLJq82GbJqWsiwQ3uykK0x/gAI9tmWe4D SwpSszi5jwyv8SAoewyNLQr0ojNlzwkftVOrBEFyijfCAhu86xPHGDn1QghFQEpg ALXn0oMQkeP7zVfxv4f2ID/u5iOtkT2O8G/jeq3jA08Ide7qi1+kNsWZyrvGS9r7 qkCoE9GayRgGKIEAS+mJLMhJ28ttJ4wvugSpsaSSNOu6CTWIY5mnlovbpPir18GN uZCKMofeIn/fHAROFiHyFudP00z/uxX8r//gCCo0rcwcXRMUS/lxHZJNjYDL+ACA QFiSWvgAlm8JWEpgF2DjckIND5ZoFvBS5KztkLlbZCeqzw9iSA/FY4r7EqfbQ0Rj Nr9yvDGONDzgUp2BwHJIcYKIB5QQnSD1JfshVn//hv7Cm7v1GoA0b71Kkb2V+3s+ wZQf5DcDObBEck5VG2qE =xEbv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat shutdown behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Vimal, On 8/9/13 1:01 AM, Vimal Jain wrote: > I am using tomcat-6 on my Ubuntu 13.10 desktop. My question is :- > When i run shutdown script of tomcat , does tomcat wait for > currently running threads to complete before shutting down ? Do you mean "does Tomcat complete all in-progress requests before shutting down"? Honestly, I get horribly confused whenever I try to read the Connector/Processor/Protocol/Lifecycle/etc. code (as I just did, again), but it looks like Tomcat closes the ServerSocket (which will drop any request that hasn't yet been accepted -- those in the TCP accept queue) immediately. I have to imagine that any in-progress non-asynchronous requests that have been assigned threads will complete successfully, since they threads are being managed by a thread pool. I'm not sure what happens to asynchronous requests that are still in mid-flight. Note that running 'bin/catalina.sh stop' does not stop Tomcat before it exists. That command merely sends a "SHUTDOWN" command to Tomcat via a socket (under the default configuration) or sends a signal to the process (if you have changed the default). In the former case (SHUTDOWN command), your shutdown-request completes almost immediately, while the true server process goes through an orderly shutdown process as (lightly) described above. In the latter case (signal), a KILL signal is sent and your JVM might not shutdown in an orderly way -- and you may destroy in-process requests. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBO1YAAoJEBzwKT+lPKRYXMEQALpeFF12SE3Cm9DoVwtjlgKb MFef+u54uzRqyRufoamHnO6rbqLd4OPNQIiSbx/eJ2Xr3QQhhF5THRSfQY6hJpxN phxKRWoPVQiEGffo/qXFOmGM10tUbTe1BTD2ZKfUoqy6N4G1EDeUhuEBke2yaBga G5CUcjSYAPqRUMHcQi+EH+8oVGAB3TFXkQAl9a2zz4CqLi8fP/GVeMl8DAN91kCG 0IV6qSw8s6TdC5f3HXtOrp1fEhS15PPdF6gPfBFpKII2IFddGfDwghDhSaabWBrV Q1rMqngNKLArTcXOv4ahXsBAykNaUq2MLLFs2NW2Giy61q9LZ5W5Ip1sa7TqEAU6 hiZU7VDkbrjz3iMLe2UvfoiIi+6P5CAfTL1tKVdGkAo4bN1EwZDShD9hQjvLnJFU 9ScaHfsor0iTwu1UvKjOWER8jids3ntju8kXsGs+WA4SOn517q7Ni0/3DPYkTZQL idQHx8VC0GaENkPQfWRU+CCH73GuWuSKmgWrDnL3mxFNoCPZLFix7fwYBk+5OOSn PeIs0OYhWlMyWj+wNtp7hqx4Bk7XvNKxwpCID+keB8Ffj8JR5hKyKBbJBzCw3RRa YLSaqjCvsq0Ab7k9IyDntH9lVPLRvpxb/d16PZw11IvMlQsbg5KZRSXnXZNabkSf atnhsLEmjGu3fPs8+Ror =ZQGX -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
On 09/08/2013 14:50, Christopher Schultz wrote: > It's too bad it took a researcher a year to figure out that > compression of any kind makes encryption (where the attacker can force > random probing attacks) weak. It's not like SSL+compression and > SSL-compression+compression is that different. It didn't. The original CRIME presentation covered this topic. I fail to understand why such a fuss is being made of this re-hashing. The original CRIME presentation also (correctly) pointed out that any attack based on this is entirely theoretical and not currently at all practical. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Upgrade to Tomcat 7 Issues
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Seema, On 8/9/13 5:17 AM, Seema Patel wrote: > I've upgraded my tomcat from 5.5 to 7.0. I've also upgraded the jre > from 1.5 to 7. > > I'm trying to get my existing struts/servlets projects to run, but > I'm getting the following error when running tomcat in my > tomcat7-stderr...log file: > > INFO: Deploying configuration descriptor C:\Tomcat > 7.0\conf\Catalina\localhost\common.xml 09-Aug-2013 10:11:44 > org.apache.catalina.core.ContainerBase addChildInternal SEVERE: > ContainerBase.addChild: start: > org.apache.catalina.LifecycleException: Failed to start component > [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/common]] > > at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) > > at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) > > at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656) > at > org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1635) > > at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) > at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at > java.util.concurrent.FutureTask.run(Unknown Source) at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown > Source) at > java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) > at java.lang.Thread.run(Unknown Source) Caused by: > java.lang.NoSuchMethodError: > javax.servlet.ServletContext.getSessionCookieConfig()Ljavax/servlet/SessionCookieConfig; > > at org.apache.catalina.deploy.WebXml.configureContext(WebXml.java:1374) > at > org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1346) > > at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878) > at > org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:376) > > at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) > at > org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) > > at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) > > ... 11 more > > Any ideas? Have I missed something? Sounds like you have a library in your WEB-INF/lib directory that you should not have. Can you give us a listing of what you have there? Tomcat should be protecting itself against loading javax.servlet.* classes from your webapp, but that sure looks like what is happening. Or maybe you copied old (Tomcat) libraries from your Tomcat 5.5 install to Tomcat 7.0? Can you tell us exactly how you upgraded from one to another (be as specific as possible without writing a 50-page description). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBOmkAAoJEBzwKT+lPKRYBkcP/j3SfgL5v0KbZa37blpSu3pt 9yUsosdIcy36baBdxefOZKyRhLVSQusdm7egj3SbY2O7/GofcoCPrU17iF4jltqL S0czwXKFItmX+H+44siEJO295oC91GF6ogBQPdOveJXI96bbZo1DTs/TqeFVK66R x6MO0Xp/KYBYYx06bLU/kqbUA1WpvZ47x5y69JCJ88beCvhFjixFIKNJmlxZ6xLZ hxUjery+59Ao/lVKSRhVsY5ytuI66rKgaCwYEsO57c+gBkO0Ex8QCdOUFIBYuj8/ AXOOuyElbxri1jAnoaqG81nVPK1KdPkNAlueYBt1ke0j+bxl/H+VOjz2siyjJB3j o4Uag/z8e5APLautD+0b37TjMZWrxy7sm5AMrKCsSgYEuX88VU26kpkFlqTy6OQI BDqqvnTf0mHFfQPO96+vOnhpGKRkXFxORAfGynixeoKw8n13YKdyV6wxKfLne6gc cbR01SRMXe3O71o5+jH1PB6ZhGh9PRA4wgUDuUuht96Jdv6lmizOpl8ZZWHIRtjU v4KQu6X9akHLNM29JWVD/6XuhwD7Tr4tiHHQHHR8ozLt6hg7SdAiDSUBQw7RkF6s NUK2FkUDUA6ICncZ61TiHkaxyH+SCh4c5Z6ThP8pvbUTmWV2UZ1VLJ/6T9GvCyPY 5+XsswfHm40lBbprZn2F =7d1+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Downgrade Tomcat7 to Tomcat6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Sumilang, On 8/9/13 5:53 AM, Sumilang Plucena wrote: > When I installed tomcat6 through the repository then tried > upgrading it from the shell it's possible but when I tried doing > the same process through manual installation gave me an error that > tomcat6 is not installed. Is there a more detailed and friendlier > instruction on how to install tomcat6 on linux other than the link > I tried to follow and ended up using other website for > instruction. That was a terrible mistake. If you are going to use the package-manager, stick with the package manager. If you want to do a manual install, do it separately. You can mix-and match any of the following: 1. Tomcat 6 via package-manager 2. Tomcat 6 via tomcat.apache.org 3. Tomcat 7 via package-manager 4. Tomcat 7 via tomcat.apache.org Most folks recommend you go with #2 and #4 because we (on the mailing list) can be the most helpful. My experience is that apt-based packages for Tomcat are fairly reasonable to deal with. If you'd prefer to use a package-manager version of Tomcat, go for it. Just understand that these things are usually woefully out of date. For some reason, Tomcat patches simply don't make it into package-manager repositories. I think it's because Tomcat doesn't produce actual patches like the httpd team does. So, it's much more difficult for package-managers to consume individual fixes for e.g. security fixes while keeping the package itself as super-stable as they like things to be (at least I think this is what the Debian folks do). > About the second question. I upgraded tomcat6 my first > uninstalling it then installing tomcat7 from the repository. You probably didn't need to do that: you should be able to have both Tomcat 6 and Tomcat 7 installed simultaneously (and switch between them). - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBOkFAAoJEBzwKT+lPKRYt1QP/RATe3Ampd/96GiIZ0KWieTF nMFswHzlEqV5LyZmUmirXg4xLoNh+cXDA14JpmrNM6YSZp80mEpSq5vxpbIKIIFv V3VEfrG4+eWz+A4HA6Y/bNJomyaobZ77JdUj0+3uQnvvOUU2kg2ZKdA/qAE6xFC7 miswbpxkGFJLKmGyG2NyxCSFjo/HbqwOy8MkYA4Qbm6kJvCcS672q78qWJj2J9o4 UEUYka/6XtXtZ4WP2X3Dy/5H4z5wOUXIJjQfzxCWat8w68CvOigCHJO5Bzlp98zX dd6J985rlW6IoUW9+W7hSuASYkhyfVAmqnERd6L1MvtVzLQU1uCt0+YidLqky1ve pc+3ihF1K4pXPkdN3B9MYtiaRpbqaxzMnzzAreKewJZ86vfb1QcDBdZMkFG0aV/5 di7xknieLyqbY3go8ALF0vrh71JkEIvjv1u8j1Zz0V0xPSTrMfvOf2WoDGNl/05b VtSFvJa3hPvVKw3Dphr9BFyPZNiraYjycIN3Aq2kPRNIit8XGPf+ndlxW6BXlnLr Sl56gwGJU9mLEQPePMDZpUpYcWsUEE263QXYEE9kSuFT/+fpUKP2wFFeP3LT2CYj Pgk0K1WjRoHGlksFQIjk8o3K6Z+QRYWRZmz8RHaoADvuFMBXnGTNzXIH5Gow0C2U o4hmiIB5x1eY1Axy0nqs =Q/mm -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Martin, On 8/8/13 8:20 PM, Martin Gainty wrote: > as earlier mentioned > > chrome is the only browser that supports compression on SSL > streams Mozilla Firefox had implemented TLS+compression for SPDY requests, and thus was vulnerable. Since CRIME, both browsers have disabled compression for TLS. Disabling TLS compression whilst enabling gzip compression merely re-enables a similar attack that had been mitigated by disabling SSL compression in the first place. So, it doesn't matter what browser you use, since you can usually bet that the client supports gzip and/or deflate compression for Content-Encoding. (Well, you don't have to bet, since the client advertises that fact via Accept-Encoding). The point is that this is not something most people are safe from due to their browsers' inabilities. On the contrary: swapping TLS compression with "regular" compression has given this attack much wider applicability. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBOeeAAoJEBzwKT+lPKRY4GEQAJb9odexFRiOncyPUJpoW/Cr yhQGyrDD606jcfhtv029BWw8RB2fRK0Efo03+0LJ8auGA9jPdD/u/aZYWBmzUcm6 w7fNR+zk288OjHpfU0PQ0c7ypK1vcEpVw57+f6aqMsdw/MaSlhQLX9ducsUZRzu2 TrHBlJPngu17HK9y5jg9i0YHJ6wMbvfD+8Dk17NoabthxgO3An9CNznp7IYSCyx2 9Y8dVT6d6W538JMgm+Ov+iAYwoZNslnKDo46bqHXbeuLo5VAn8wmisY+tW9QmbdP cVsl6I+E2WGKGt2TvWGYwODKDCyxgDkLXjFRp13vpkpFTmYsvLSbiajJsur/kO1H qcTq0ygdtoMe8waiB/eXbZx0aWVsfG90R7SaiUsznR3lTJfFPrDst3IuOJgafLIw t1KvU3p1AcbFhAXZG3Oo9Ltwm3rxYvNuGi4eD8Khq8JOiMk4P+hhQwN30jCno7X6 0bV/tbIlp1SfU3SNFjUESIG4GIJGNUIOVuW8Ga1s1/8HQhMVnjHDG6eapeW0OS1h srC3RKmPvWo0BEs4XmDanmssGqeOBZmhgO1SDGi/aY9Jl/NQVkBApzfdaJ1eDUB2 PfTzSOUz2SFEJy5nwkWR0y0S4hoN4i8sVgrqtUtmRZIzuqFr+SJlaIxfujzNWaxS 3X77ZRaLZXxUdEEV1HKR =44Ps -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Tomcat config question: 'compression' versus 'SSLDisableCompression'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 David, On 8/8/13 5:47 PM, David Landis wrote: > On Thu, Aug 8, 2013 at 5:19 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> >> ... and the SSLDisableCompression setting (when set to "false") >> is intended to mitigate the CRIME attack against SSL/TLS >> compression. Feel free to read online all about the CRIME >> attack. >> > > That was what I was hoping it did when I asked the original > question :) > > >> I haven't really done any analysis of SSL compression (that is, >> compression as implemented by the TLS/SSL layer) alone versus >> compression-less-SSL + gzip, but I suspect that any combination >> of compression and encryption can lead to CRIME-like attacks ... > > > That seems to be true since there is now the BREACH attack: > > http://arstechnica.com/security/2013/08/gone-in-30-seconds-new-attack-plucks-secrets-from-https-protected-pages/ > > which (I think) is compression-less-SSL + gzip. It is compression + deflate as explained in the article, but gzip basically works the same way (LZ77 + Huffman). It's too bad it took a researcher a year to figure out that compression of any kind makes encryption (where the attacker can force random probing attacks) weak. It's not like SSL+compression and SSL-compression+compression is that different. - -chris -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.14 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJSBOWnAAoJEBzwKT+lPKRYuMoP/0cFjaVbiLs+Qw3QQS/z/A0p mq/5QTNhsUqSsRmhnjAThGSBZPCpXB9We9ecTqV1moxR9iG94x/oya/3yToYmJ1r Msat1HB97YRotPxyWCweZ2nllTPshlkyTnhojcD18csnA0pAfn/LzqimRXFelX2f Vnkgoygb6qL5f6fIMpVVWrjzn1BsAGQxjNQwJtteimLC1GE7sYOarQ4MuqMrQzM2 /5tqOpJQnVgZRL+IdqNLHpYWGx8FhonV6KDXlVTAkl6LOgTWpVlWNrHzq8/wFpxO 3XssLKcO2oHm2mGvD8c6ivRwvVjvZlQd1VapamJpIxGl+ezlbyLwPx0USiIUrcNO m6uyO1I9Zq9Vw63VMwbatYqA3nTqNwKhdaMl3H7jj4KJDxVyr/0RUNIuUu4+yECZ XLUpSucIluDL90BrXfvYaSf8yCbkRBhk5fW9IgzDOOgXFlQNsYdb5RGtFxksIb24 irmiv4naxNKqBdyvVPDvib7hXwAAX4K8xhYitv7gakpCS7JPZrWA7hFl5YCdt7H7 pnCGLXTiyMpTRhQ7WNDm7sCFLD1YL67axRHBm1nMSbxOBwR3CiZ5UINOlqyj3Wp7 ZDZQNkdF0NBK9XL5J4fyapXDGYX+N6y0ikK1bR24qncrPuVq6RNkpJ04UlWWENq9 wzgcOoLG/iO4WpuAcoJC =iH73 -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Downgrade Tomcat7 to Tomcat6
On Aug 9, 2013, at 5:53 AM, Sumilang Plucena wrote: > Installed tomcat6 through the repository Uninstall this. See reasons listed in my previous email. > and by manual configuration. I tried following the manual installation from > this resource http://tomcat.apache.org/tomcat-6.0-doc/setup.html but end up > following from another website > http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/. and what happened? Did it work? > When I installed tomcat6 through the repository then tried upgrading it from > the shell it's possible Forget about the repository. See reasons listed in my previous email. > but when I tried doing the same process through manual installtion gave me an > error that tomcat6 is not installed. Upgrades are easy. You just download and install the new version along side your existing version, migrate your config from the old to new version (use a diff tool or [1]) and deploy your apps to the new instance. More info on upgrades can be found here [2]. While it's a bit more complicated to initially setup, you can streamline the upgrade process further by using separate CATALINA_HOME and CATALINA_BASE environment variables. For more info on how to do this, see the "Advanced Configuration - Multiple Tomcat Instances" in RUNNING.txt. [1] - https://tomcat.apache.org/migration-6.html#Upgrading_6.0.x [2] - https://tomcat.apache.org/migration.html > Is there a more detailed and friendlier instruction on how to install tomcat6 > on linux other than the link I tried to follow and ended up using other > website for instruction. You should look at RUNNING.txt [3]. It's not a pretty HTML page, but it says exactly what you need to know about installing. The only part missing from RUNNING.txt would be instructions for installing as init.d script to start on boot. This is documented here [4]. [3] - https://tomcat.apache.org/tomcat-6.0-doc/RUNNING.txt [4] - https://tomcat.apache.org/tomcat-6.0-doc/setup.html#Unix_daemon Finally, if you have any specific questions about installing or upgrading, or encounter any problems while trying, just ask on the list. For best results, include as much detail about your question / problem as possible. Include OS, full Tomcat version, logs, full error message or anything else relevant to the problem. Dan > About the second question. I upgraded tomcat6 my first uninstalling it then > installing tomcat7 from the repository. > > Thanks for the reply. > > > > On Thu, 8/8/13, Daniel Mikusa wrote: > > Subject: Re: Downgrade Tomcat7 to Tomcat6 > To: "Tomcat Users List" > Date: Thursday, August 8, 2013, 2:25 PM > > On Aug 7, 2013, at 9:53 PM, Sumilang > Plucena > wrote: > >> I have a development server Ubuntu12.10 and > Tomcat-7.0.30. > > Are you installing from the Ubuntu repository or from the > tomcat.apache.org download? > > If you're installing from an Ubuntu repository, I'd suggest > that you don't. The versions there are always way > behind and install files into distro specific locations > (which makes it harder for us, the tomcat mailing list, to > support). > > Installation from the zip / tar.gz on tomcat.apache.org is > quite simple and give you more control over the version you > install (i.e. you can get all the latest security fixes) and > where you install the files. In fact, when you use > this method you can even install multiple versions on the > same machine at the same time, which makes upgrades a bit > easier. > >> But prior to upgrading Tomcat7 from Tomcat-6.0.29 we > never had problem with our website. > > You're going from one major version of Tomcat to another, > which means you could see some differences with your > applications. Please checkout the migration guide for > more information about what has changed. > >https://tomcat.apache.org/migration-7.html > >> I would like to know how I can go about downgrading > Tomcat7 without affecting applications hosted by tomcat7. > > I'd suggest just fixing the issue that you are seeing with > Tomcat 7 (feel free to post another thread asking for help > with that), but if you *really* want to downgrade I suppose > it should be possible. First, how did you upgrade from > Tomcat 6 to Tomcat 7? What steps did you take? > > Dan > - > 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 > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Downgrade Tomcat7 to Tomcat6
Installed tomcat6 through the repository and by manual configuration. I tried following the manual installation from this resource http://tomcat.apache.org/tomcat-6.0-doc/setup.html but end up following from another website http://www.howtogeek.com/howto/linux/installing-tomcat-6-on-ubuntu/. When I installed tomcat6 through the repository then tried upgrading it from the shell it's possible but when I tried doing the same process through manual installtion gave me an error that tomcat6 is not installed. Is there a more detailed and friendlier instruction on how to install tomcat6 on linux other than the link I tried to follow and ended up using other website for instruction. About the second question. I upgraded tomcat6 my first uninstalling it then installing tomcat7 from the repository. Thanks for the reply. On Thu, 8/8/13, Daniel Mikusa wrote: Subject: Re: Downgrade Tomcat7 to Tomcat6 To: "Tomcat Users List" Date: Thursday, August 8, 2013, 2:25 PM On Aug 7, 2013, at 9:53 PM, Sumilang Plucena wrote: > I have a development server Ubuntu12.10 and Tomcat-7.0.30. Are you installing from the Ubuntu repository or from the tomcat.apache.org download? If you're installing from an Ubuntu repository, I'd suggest that you don't. The versions there are always way behind and install files into distro specific locations (which makes it harder for us, the tomcat mailing list, to support). Installation from the zip / tar.gz on tomcat.apache.org is quite simple and give you more control over the version you install (i.e. you can get all the latest security fixes) and where you install the files. In fact, when you use this method you can even install multiple versions on the same machine at the same time, which makes upgrades a bit easier. > But prior to upgrading Tomcat7 from Tomcat-6.0.29 we never had problem with our website. You're going from one major version of Tomcat to another, which means you could see some differences with your applications. Please checkout the migration guide for more information about what has changed. https://tomcat.apache.org/migration-7.html > I would like to know how I can go about downgrading Tomcat7 without affecting applications hosted by tomcat7. I'd suggest just fixing the issue that you are seeing with Tomcat 7 (feel free to post another thread asking for help with that), but if you *really* want to downgrade I suppose it should be possible. First, how did you upgrade from Tomcat 6 to Tomcat 7? What steps did you take? Dan - 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
Upgrade to Tomcat 7 Issues
Hi, I've upgraded my tomcat from 5.5 to 7.0. I've also upgraded the jre from 1.5 to 7. I'm trying to get my existing struts/servlets projects to run, but I'm getting the following error when running tomcat in my tomcat7-stderr...log file: INFO: Deploying configuration descriptor C:\Tomcat 7.0\conf\Catalina\localhost\common.xml 09-Aug-2013 10:11:44 org.apache.catalina.core.ContainerBase addChildInternal SEVERE: ContainerBase.addChild: start: org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/common]] at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:633) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:656) at org.apache.catalina.startup.HostConfig$DeployDescriptor.run(HostConfig.java:1635) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.NoSuchMethodError: javax.servlet.ServletContext.getSessionCookieConfig()Ljavax/servlet/SessionCookieConfig; at org.apache.catalina.deploy.WebXml.configureContext(WebXml.java:1374) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1346) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:878) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:376) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5322) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150) ... 11 more Any ideas? Have I missed something? Thanks Seema
