Re: Best practices question
For applications which require root permissions we do the following: Apache mod_jk (non root) -AJP- Tomcat (non root) -SSL- Tomcat SOAP server (root) Any business logic which requires root permission is implemented as a SOAP web service in the SOAP server which runs as root. That SOAP server is locked down with the SecurityManager and a very strict catalina.policy. The strict policy protects us from root level exploits and from hurting ourselves. i.e. We lock down file permissions to only those files/directories which the SOAP web services need to administer. The SSL connection is further locked down with X509 certificates. Each side of the SSL connection must present a certificate that the other side has the public key for. Also the catalina.policy restricts what IP's it will allow SSL connections from. The SOAP web services also validate all input which comes from the client. Regards, Glenn Qmail List wrote: I have been wondering about this as well. Apache screams and hollers BIG_SECURITY_HOLE if you compile it with the flags allowing it to run as root. That said, I love the fact that Tomcat runs as root. It makes it easy for your webapp to do things admin applications, servers, and networks from a web interface. But at what cost? Of course it would be best to run Tomcat as nobody or tomcat user or whoever, but if your app needs some root permission at the OS level, is it OK to run as root? I'd imagine the root OK concept must be due to the underlying Java, but can't really see why or how. Anyone know? Great product this Tomcat. Kudos to all involved. - Original Message - From: Turner, John [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 1:57 PM Subject: RE: Best practices question I run Tomcat under a separate user account. I avoid running services as root whenever possible. John -Original Message- From: Randy Paries [mailto:randy.paries;unitnet.com] Sent: Thursday, October 17, 2002 1:56 PM To: 'Tomcat Users List' Subject: Best practices question Hello, I was wondering are most people starting tomcat from root, or are they doing it other ways. What is the suggestion for this. How big are the security issues if started by root Would it be ok to start it by user apache? Thanks -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Best practices question
Qmail List wrote: I have been wondering about this as well. Apache screams and hollers BIG_SECURITY_HOLE if you compile it with the flags allowing it to run as root. That said, I love the fact that Tomcat runs as root. It makes it easy for your webapp to do things admin applications, servers, and networks from a web interface. Would you really want to do this? Then any webapp developer could do the same. Not to mention that should some bug in Tomcat/Java with buffer overflow appear, you're looking at a hostile takeover situation. Not as likely as other servers, but generally speaking, it's there. But at what cost? Of course it would be best to run Tomcat as nobody or tomcat user or whoever, but if your app needs some root permission at the OS level, is it OK to run as root? There is SUDO... I'd imagine the root OK concept must be due to the underlying Java, but can't really see why or how. Anyone know? If Apache doesn't need (and doesn't like) being run as root, neither should Tomcat. If there are privileged operations, then access to them must be authenticated. And if some specific user, with a user/pass, can access a privileged operation, so can Tomcat. You should think not in terms of how to hack this in, but in terms of security/service framework. There are some services that are privileged and access to them has certain rules which have to be implemented, not circumvented. Nix. -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
RE: Best practices question
I run Tomcat under a separate user account. I avoid running services as root whenever possible. John -Original Message- From: Randy Paries [mailto:randy.paries;unitnet.com] Sent: Thursday, October 17, 2002 1:56 PM To: 'Tomcat Users List' Subject: Best practices question Hello, I was wondering are most people starting tomcat from root, or are they doing it other ways. What is the suggestion for this. How big are the security issues if started by root Would it be ok to start it by user apache? Thanks -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Best practices question
On Thu, 17 Oct 2002, Qmail List wrote: Date: Thu, 17 Oct 2002 15:03:27 -0400 From: Qmail List [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Best practices question I have been wondering about this as well. Apache screams and hollers BIG_SECURITY_HOLE if you compile it with the flags allowing it to run as root. That said, I love the fact that Tomcat runs as root. It makes it easy for your webapp to do things admin applications, servers, and networks from a web interface. But at what cost? Of course it would be best to run Tomcat as nobody or tomcat user or whoever, but if your app needs some root permission at the OS level, is it OK to run as root? I'd imagine the root OK concept must be due to the underlying Java, but can't really see why or how. Anyone know? Great product this Tomcat. Kudos to all involved. Consider the following JSP page: % Runtime.exec(/sbin/halt); % (or an equivalent servlet, but let's just make it simple for now). If I am able to break in to your system and store a copy of this JSP page in a directory visible through Tomcat (running as root), I can shut your computer down -- even if I broke in to a non-privileged account that cannot execute the command directly. Or, if I was in a nastier mood, think about the impact of rm -R /*. Security is all about maximizing the difficulty of breaking in, and minimizing the impact of what an attacker can do when they succeed (there's no such thing as absolute prevention). Craig -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Best practices question
Mark Eggers wrote: Following that idea, only run Tomcat as root if you are using it as a web server binding to a port less than 1024. Otherwise, run it from a non-privledged account so that if there is a security issue the most it should trash is your web server environment. In addition, it is best to run Tomcat on a non-priviledged port and use your OS' firewalling to redirect port x to port 80. (eg. iptables, etc.) If you must do something as root, such as admin work, I would run a seperate tomcat for those servlets and go learn about using SecurityManagers with Tomcat. A. -- Adam Sherman Software Developer Teach and Travel Inc. +1.613.241.3103 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
RE: Best practices question
Actually, aside from the issue of running on a port under 1024, the idea that Tomcat running as root would make it easy for your webapp to do things admin applications, servers, and networks from a web interface is pretty scary. The last thing I want is some developer writing some code they _think_ is pretty cool, only to have it run amok because it had the permission to do so. Like overwriting something in /proc, for example. I would guess this is also the reason symlinks were turned off by default recently. Having something like Tomcat run in a JVM sandbox, but then allowing a class or JSP page to link out to any other location on a filesystem at will sort of defeats the purpose, especially when Tomcat runs as root. Running everything as root is begging for trouble and a phone call at 2:30 AM because something just got munged up by a rogue process or application. I'll pass. John -Original Message- From: Qmail List [mailto:edahnke;earthlink.net] Sent: Thursday, October 17, 2002 3:03 PM To: Tomcat Users List Subject: Re: Best practices question I have been wondering about this as well. Apache screams and hollers BIG_SECURITY_HOLE if you compile it with the flags allowing it to run as root. That said, I love the fact that Tomcat runs as root. It makes it easy for your webapp to do things admin applications, servers, and networks from a web interface. But at what cost? Of course it would be best to run Tomcat as nobody or tomcat user or whoever, but if your app needs some root permission at the OS level, is it OK to run as root? I'd imagine the root OK concept must be due to the underlying Java, but can't really see why or how. Anyone know? Great product this Tomcat. Kudos to all involved. - Original Message - From: Turner, John [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 1:57 PM Subject: RE: Best practices question I run Tomcat under a separate user account. I avoid running services as root whenever possible. John -Original Message- From: Randy Paries [mailto:randy.paries;unitnet.com] Sent: Thursday, October 17, 2002 1:56 PM To: 'Tomcat Users List' Subject: Best practices question Hello, I was wondering are most people starting tomcat from root, or are they doing it other ways. What is the suggestion for this. How big are the security issues if started by root Would it be ok to start it by user apache? Thanks -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Best practices question
Randy, A general rule of security is permit only what is needed, and deny everything else. Following that idea, only run Tomcat as root if you are using it as a web server binding to a port less than 1024. Otherwise, run it from a non-privledged account so that if there is a security issue the most it should trash is your web server environment. /mde/ just my two cents . . . . __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Best practices question
I have been wondering about this as well. Apache screams and hollers BIG_SECURITY_HOLE if you compile it with the flags allowing it to run as root. That said, I love the fact that Tomcat runs as root. It makes it easy for your webapp to do things admin applications, servers, and networks from a web interface. But at what cost? Of course it would be best to run Tomcat as nobody or tomcat user or whoever, but if your app needs some root permission at the OS level, is it OK to run as root? I'd imagine the root OK concept must be due to the underlying Java, but can't really see why or how. Anyone know? Great product this Tomcat. Kudos to all involved. - Original Message - From: Turner, John [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Thursday, October 17, 2002 1:57 PM Subject: RE: Best practices question I run Tomcat under a separate user account. I avoid running services as root whenever possible. John -Original Message- From: Randy Paries [mailto:randy.paries;unitnet.com] Sent: Thursday, October 17, 2002 1:56 PM To: 'Tomcat Users List' Subject: Best practices question Hello, I was wondering are most people starting tomcat from root, or are they doing it other ways. What is the suggestion for this. How big are the security issues if started by root Would it be ok to start it by user apache? Thanks -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: Best Practices Question
Sun, 29 Sep 2002 22:17:25 -0700 (PDT) Craig R. McClanahan [EMAIL PROTECTED] said: Regarding restarting a webapp without restarting Tomcat, you should read up on the Manager servlet that comes with Tomcat 4.0 and 4.1: http://jakarta.apache.org/tomcat/tomcat-4.1-doc/manager-howto.html If the manager servlet can remove a webapp with a servlet that tries to use 100%CPU and never comes back, then that is it. Perfect. I more than happily withdraw the idea of using Apache as server side proxy to access several independent Tomcats via port 80 in order to reduce downtime. I am sorry I overlooked that until now. Thank you for the pointer. On dealing with rogue (runaway, stuck, ..) servlets: what you mean by this) either way. The only answer is to correct the bugs in your app that are causing the servlet not to complete its responses. Almost agree. But this looks only at the servlet programmers side. As server administrator I also want to minimize the damage a single broken servlet can do. A local problem should stay local. This not a problem in a perfect world. Reality is not always perfect. Recently I had a servlet that worked fine for 9996 times out of 1. In the other 4 cases it would use all CPU it could get until somebody killed Tomcat. That is why I searched quite a while but failed to find a way to monitor and catch individual runaway servlet threads. Being lazy as I am, I would like to be able to set resource ceilings on servlets, forcing servlets to behave and programmers to act, not the server administrator. Thank you again Oskar -- Dr. Oskar Bartenstein [EMAIL PROTECTED] IF Computer Japan http://www.ifcomputer.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Best Practices Question
This has been discussed quite a bit. I can think of dozens of reasons to use Apache, not one of them related to serving simple HTTP/1.1 static content, which is pretty much all that the HTTP connector on Tomcat does. Tomcat cannot do it all. Think outside of the box. John -Original Message- From: V. Cekvenich [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 8:32 PM To: [EMAIL PROTECTED] Subject: Re: Best Practices Question I think there is no reason to use Apache. Tomcat can do it all and it is simpler this way. Plus Tomcat can do JSPs, etc. V. Barry Moore wrote: I have not used Tomacat in a couple years. The last time I used it, our companies policy was to integrate with Apache and get Apache to do the serving duties and just use Tomcat as the jsp processor. With Tomact 4 is this still considered a good practice for high traffic sites? Thanks, Barry __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Best Practices Question
-Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 9:40 PM ... snip... Valid reasons to need it include: * Tomcat standalone is not fast enough (note that this is different from a rule saying select the fastest possible solution -- that turns out not to be a requirement in every scenario). * You need the extra features that Apache provides (such as integration with existing modules). * You need to run on port 80 in an environment that requires root for this. * You already know how to configure it, so there's no extra learning curve. I would include load-balancing as well (multiple Tomcats, one or more Apaches). Blindly installing Apache+Tomcat because that's the thing to do is a waste of effort in many scenarios. Agreed. Craig John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Best Practices Question
What about SSL, is it better/more efficient to allow apache to handle the SSL or to drop apache and allow tomcat to do it all? -Original Message- From: Turner, John [mailto:[EMAIL PROTECTED]] Sent: 30 September 2002 13:39 To: 'Tomcat Users List' Subject: RE: Best Practices Question -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 9:40 PM ... snip... Valid reasons to need it include: * Tomcat standalone is not fast enough (note that this is different from a rule saying select the fastest possible solution -- that turns out not to be a requirement in every scenario). * You need the extra features that Apache provides (such as integration with existing modules). * You need to run on port 80 in an environment that requires root for this. * You already know how to configure it, so there's no extra learning curve. I would include load-balancing as well (multiple Tomcats, one or more Apaches). Blindly installing Apache+Tomcat because that's the thing to do is a waste of effort in many scenarios. Agreed. Craig John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] --- Copyright material and/or confidential and/or privileged information may be contained in this e-mail and any attached documents. The material and information is intended for the use of the intended addressee only. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you may not copy, disclose, distribute, disseminate or deliver it to anyone else or use it in any unauthorised manner or take or omit to take any action in reliance on it. To do so is prohibited and may be unlawful. The views expressed in this e-mail may not be official policy but the personal views of the originator. If you receive this e-mail in error, please advise the sender immediately by using the reply facility in your e-mail software, or contact [EMAIL PROTECTED] Please also delete this e-mail and all documents attached immediately. Many thanks for your co-operation. BMW Financial Services (GB) Limited is registered in England and Wales under company number 01288537. Registered Offices : Europa House, Bartley Way, Hook, Hants, RG27 9UF -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Best Practices Question
On Mon, 30 Sep 2002 [EMAIL PROTECTED] wrote: Date: Mon, 30 Sep 2002 13:39:07 +0100 From: [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: RE: Best Practices Question What about SSL, is it better/more efficient to allow apache to handle the SSL or to drop apache and allow tomcat to do it all? Tomcat standalone can do SSL, so you've still got a choice -- the difference being that the SSL performance of Apache is likely to be faster. Does that matter? *ONLY* if Tomcat standalone is not fast enough to meet your performance requirements by itself. You don't always need fastest possible -- sometimes quickest to set up is the better top priority. Craig -Original Message- From: Turner, John [mailto:[EMAIL PROTECTED]] Sent: 30 September 2002 13:39 To: 'Tomcat Users List' Subject: RE: Best Practices Question -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 9:40 PM ... snip... Valid reasons to need it include: * Tomcat standalone is not fast enough (note that this is different from a rule saying select the fastest possible solution -- that turns out not to be a requirement in every scenario). * You need the extra features that Apache provides (such as integration with existing modules). * You need to run on port 80 in an environment that requires root for this. * You already know how to configure it, so there's no extra learning curve. I would include load-balancing as well (multiple Tomcats, one or more Apaches). Blindly installing Apache+Tomcat because that's the thing to do is a waste of effort in many scenarios. Agreed. Craig John -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] --- Copyright material and/or confidential and/or privileged information may be contained in this e-mail and any attached documents. The material and information is intended for the use of the intended addressee only. If you are not the intended addressee, or the person responsible for delivering it to the intended addressee, you may not copy, disclose, distribute, disseminate or deliver it to anyone else or use it in any unauthorised manner or take or omit to take any action in reliance on it. To do so is prohibited and may be unlawful. The views expressed in this e-mail may not be official policy but the personal views of the originator. If you receive this e-mail in error, please advise the sender immediately by using the reply facility in your e-mail software, or contact [EMAIL PROTECTED] Please also delete this e-mail and all documents attached immediately. Many thanks for your co-operation. BMW Financial Services (GB) Limited is registered in England and Wales under company number 01288537. Registered Offices : Europa House, Bartley Way, Hook, Hants, RG27 9UF -- -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
For a medium to high volume site using Apache to serve static content (static html, images, css, etc.) is: 1. Faster and more reliable (no pauses due to JVM garbage collection, etc.) 2. Takes that load off of Tomcat so it can concentrate on dynamic content. (JSPs/Servlets) 3. Allows you to do load balancing if needed. I use Apache 1.3.26 with mod_jk 1.2 and Tomcat 4.1.12. Regards, Glenn Barry Moore wrote: I have not used Tomacat in a couple years. The last time I used it, our companies policy was to integrate with Apache and get Apache to do the serving duties and just use Tomcat as the jsp processor. With Tomact 4 is this still considered a good practice for high traffic sites? Thanks, Barry __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
Craig R. McClanahan wrote: On Sun, 29 Sep 2002 [EMAIL PROTECTED] wrote: Kent, I think we are on the same track , Apache was designed for that purposes , is more robust and mature and certainly has less security related issues. Regarding maturity, I presume you're talking about 1.3, right? The Apache 2.0 code is quite a lot newer. The latter comment (less security related issues) has not been true lately, if you watch the security bulletins closely. Although Tomcat just had a security update, the problem was exposure of JSP source code -- substantially less of a dangerous problem than the two recent buffer overflow vulnerabilities that Apache has had (both in the last couple of months). The previous Tomcat security problem was also a source exposure issue, and was over a year ago. Thanks primarily to the Java programming language, it's pretty difficult to have the kinds of you can cause the execution of arbitrary code problems that anything written in C (including Apache's httpd server) can be subject to. No such problem has occurred in Tomcat during the four years I've been involved in it, whereas Apache and its associated modules have had several. IMHO, anyone who goes to all the extra effort of configuring Apache+Tomcat, instead of Tomcat alone, is nuts unless they need it. Valid reasons to need it include: * Tomcat standalone is not fast enough (note that this is different from a rule saying select the fastest possible solution -- that turns out not to be a requirement in every scenario). * You need the extra features that Apache provides (such as integration with existing modules). * You need to run on port 80 in an environment that requires root for this. * You already know how to configure it, so there's no extra learning curve. Blindly installing Apache+Tomcat because that's the thing to do is a waste of effort in many scenarios. Blindly using Tomcat to serve static HTTP content for a production system is not the thing to do either. 1. Tomcat running within a JVM is much more brittle than Apache. Apache can run for years w/o a problem. I don't think anyone can say the same for Tomcat, I can't. And this isn't necessarily something specific to Tomcat, it is due to the nature of how the JVM works and how well the applications deployed are written and tested. With Apache in front of Tomcat serving static content, if Tomcat fails (and it will) at least your static pages can still be served. I have never gotten a run time with Tomcat of more than four weeks on a production system before it failed, even with Apache serving static content. 2. Tomcat can cause random latency problems handling requests. Whenever the JVM does garbage collection Tomcat freezes. GC can take only a few seconds now and then on a well tuned system. But that isn't guaranteed, sometimes it can take 10's of seconds. Meanwhile requests are stacking up waiting for Tomcat to serve them. This then causes a cascading effect significantly increasing the number of Processors required and load on the system due to Tomcat. 3. Putting Apache in front to serve static content allows you to take some of the load off of Tomcat, letting it do what it does best, dynamic content. 4. If your site gets hit by the SlashDot affect for a dynamically generated page Tomcat could very easily get overloaded, you could temporarily change that page to a static one served by Apache. (I have had to do this) Apache will handle spikes in traffic much better than Tomcat. 5. And if traffic increases you can setup Apache to do load balancing with multiple Tomcat instances. In the end, it all comes down to testing your site prior to putting it in production and choosing the architecture best suited for your site. It can be very difficult to simulate a production load, and it needs to be done over weeks, not just hours. Regards, Glenn -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
Unequivocally : yes if u r serving up only jsp and servlets ! I use 4.0.4 Barry Moore wrote: I have not used Tomacat in a couple years. The last time I used it, our companies policy was to integrate with Apache and get Apache to do the serving duties and just use Tomcat as the jsp processor. With Tomact 4 is this still considered a good practice for high traffic sites? Thanks, Barry __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
I think there is no reason to use Apache. Tomcat can do it all and it is simpler this way. Plus Tomcat can do JSPs, etc. V. Barry Moore wrote: I have not used Tomacat in a couple years. The last time I used it, our companies policy was to integrate with Apache and get Apache to do the serving duties and just use Tomcat as the jsp processor. With Tomact 4 is this still considered a good practice for high traffic sites? Thanks, Barry __ Do you Yahoo!? New DSL Internet Access from SBC Yahoo! http://sbc.yahoo.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
On Sun, Sep 29, 2002 at 08:31:32PM -0400, V. Cekvenich wrote: I think there is no reason to use Apache. Tomcat can do it all and it is simpler this way. IF you want tomcat running at root, assuming that you want tomcat to answer requests on port 80. I, personally, prefer to have apache on port 80 and use mod_jk to forward requests to tomcat, as necessary. Kent -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
V. Cekvenich wrote: I think there is no reason to use Apache Tomcat can do it all and it is simpler this way. Apache is by far the more mature and robust of the two and was designed with the web in mind. Whereas it is true Tomcat can take over from Apache to some extend it was designed as a servlet (and jsp) container. I believe Tomcat is far less secure in place of Apache. Horses for courses ! -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
Kent Perrier wrote: On Sun, Sep 29, 2002 at 08:31:32PM -0400, V. Cekvenich wrote: I think there is no reason to use Apache. Tomcat can do it all and it is simpler this way. IF you want tomcat running at root, assuming that you want tomcat to answer requests on port 80. I, personally, prefer to have apache on port 80 and use mod_jk to forward requests to tomcat, as necessary. Kent, I think we are on the same track , Apache was designed for that purposes , is more robust and mature and certainly has less security related issues. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
[EMAIL PROTECTED] wrote: Kent Perrier wrote: On Sun, Sep 29, 2002 at 08:31:32PM -0400, V. Cekvenich wrote: I think there is no reason to use Apache. Tomcat can do it all and it is simpler this way. IF you want tomcat running at root, assuming that you want tomcat to answer requests on port 80. I, personally, prefer to have apache on port 80 and use mod_jk to forward requests to tomcat, as necessary. Not to mention the apache:tomcat=many:many load balancing capability. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
On Sun, 29 Sep 2002 [EMAIL PROTECTED] wrote: Kent, I think we are on the same track , Apache was designed for that purposes , is more robust and mature and certainly has less security related issues. Regarding maturity, I presume you're talking about 1.3, right? The Apache 2.0 code is quite a lot newer. The latter comment (less security related issues) has not been true lately, if you watch the security bulletins closely. Although Tomcat just had a security update, the problem was exposure of JSP source code -- substantially less of a dangerous problem than the two recent buffer overflow vulnerabilities that Apache has had (both in the last couple of months). The previous Tomcat security problem was also a source exposure issue, and was over a year ago. Thanks primarily to the Java programming language, it's pretty difficult to have the kinds of you can cause the execution of arbitrary code problems that anything written in C (including Apache's httpd server) can be subject to. No such problem has occurred in Tomcat during the four years I've been involved in it, whereas Apache and its associated modules have had several. IMHO, anyone who goes to all the extra effort of configuring Apache+Tomcat, instead of Tomcat alone, is nuts unless they need it. Valid reasons to need it include: * Tomcat standalone is not fast enough (note that this is different from a rule saying select the fastest possible solution -- that turns out not to be a requirement in every scenario). * You need the extra features that Apache provides (such as integration with existing modules). * You need to run on port 80 in an environment that requires root for this. * You already know how to configure it, so there's no extra learning curve. Blindly installing Apache+Tomcat because that's the thing to do is a waste of effort in many scenarios. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
Sun, 29 Sep 2002 18:39:54 -0700 (PDT) Craig R. McClanahan [EMAIL PROTECTED] said: IMHO, anyone who goes to all the extra effort of configuring Apache+Tomcat, instead of Tomcat alone, is nuts unless they need it. Valid reasons to need it include: I am pondering one more: reducing interruption of service. Tomcat can handle many webapps with ease, and you can allow as many threads as you need to serve your users. But when a single servlet gets stuck, you have to restart the whole Tomcat machinery, taking down all running webapps, possibly loosing session data and certainly interrupting service to all users, including those completely unrelated to the hanging servlet. My experience is based on Tomcat 4.0.3 and 3.x only. I searched quite a while but failed to find a way to monitor and catch individual runaway servlet threads. Please correct me if I am wrong. In that respect, with due appreciation for this great work, I think standalone Tomcat does not scale well. To avoid this, Apache just working as a proxy on port 80 for many independent instances of Tomcat on their own ports seems a feasible solution. From experience, I dislike the idea of going back to Apache+Tomcat. Both are fine by themselves, but the combi is a hassle. Any hints for better alternatives to reduce the impact of stuck servlets? -- Dr. Oskar Bartenstein [EMAIL PROTECTED] IF Computer Japan http://www.ifcomputer.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Best Practices Question
If you have stuck servlets (which I take to mean you've got bugs in your app that causes your servlets to stop responding), how would calling those exact same servlets through Apache be any different? If the problem is really the servlet, it's going to cause runaway threads (without a concise description of what you are really seeing, I don't really know what you mean by this) either way. The only answer is to correct the bugs in your app that are causing the servlet not to complete its responses. Regarding restarting a webapp without restarting Tomcat, you should read up on the Manager servlet that comes with Tomcat 4.0 and 4.1: http://jakarta.apache.org/tomcat/tomcat-4.0-doc/manager-howto.html http://jakarta.apache.org/tomcat/tomcat-4.1-doc/manager-howto.html You should also upgrade to 4.0.5 or 4.1.12 to pick up the most recent bugfixes (and the fix for the recent security vulnerability that was reported against Tomcat versions 4.0.4 (and below) and 4.1.11 (and below). Craig On Mon, 30 Sep 2002, Oskar Bartenstein wrote: Date: Mon, 30 Sep 2002 12:30:40 +0900 From: Oskar Bartenstein [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED], [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: Best Practices Question Sun, 29 Sep 2002 18:39:54 -0700 (PDT) Craig R. McClanahan [EMAIL PROTECTED] said: IMHO, anyone who goes to all the extra effort of configuring Apache+Tomcat, instead of Tomcat alone, is nuts unless they need it. Valid reasons to need it include: I am pondering one more: reducing interruption of service. Tomcat can handle many webapps with ease, and you can allow as many threads as you need to serve your users. But when a single servlet gets stuck, you have to restart the whole Tomcat machinery, taking down all running webapps, possibly loosing session data and certainly interrupting service to all users, including those completely unrelated to the hanging servlet. My experience is based on Tomcat 4.0.3 and 3.x only. I searched quite a while but failed to find a way to monitor and catch individual runaway servlet threads. Please correct me if I am wrong. In that respect, with due appreciation for this great work, I think standalone Tomcat does not scale well. To avoid this, Apache just working as a proxy on port 80 for many independent instances of Tomcat on their own ports seems a feasible solution. From experience, I dislike the idea of going back to Apache+Tomcat. Both are fine by themselves, but the combi is a hassle. Any hints for better alternatives to reduce the impact of stuck servlets? -- Dr. Oskar Bartenstein [EMAIL PROTECTED] IF Computer Japan http://www.ifcomputer.com -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
