Re: problems configuring mod_jk
On Fri, 20 Apr 2007, Rainer Jung wrote: Please post the log parts (debug log level) which appear when starting apache. Those are the lines that show, how mod_jk parses your workers.properties, and which internal objects it generates out of it. Hi Rainer, Ok, thanks for your help. This is the portion of the log generated by mod_jk, which I presume is what is relevant. The formatting is not optimal, but I can try to wrap it if desired. Faheem. *** [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] do_shm_open::jk_shm.c (295): Truncated shared memory to 28800 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] do_shm_open::jk_shm.c (327): Initialized shared memory size=28800 free=28672 addr=0x2af709b07000 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] do_shm_open_lock::jk_shm.c (234): Opened shared memory lock /var/log/apache2/jk-runtime-status.lock [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] init_jk::mod_jk.c (2355): Initialized shm:/var/log/apache2/jk-runtime-status [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] uri_worker_map_open::jk_uri_worker_map.c (361): rule map size is 0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] build_worker_map::jk_worker.c (236): creating worker ajp13 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] wc_create_worker::jk_worker.c (141): about to create instance ajp13 of ajp13 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] wc_create_worker::jk_worker.c (154): about to validate and init ajp13 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_validate::jk_ajp_common.c (1842): worker ajp13 contact is 'localhost:8009' [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1965): setting endpoint options: [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1968): keepalive:0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1972): timeout: -1 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1976): buffer size: 0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1980): pool timeout: 0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1984): connect timeout: 0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1988): reply timeout:0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1992): prepost timeout: 0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (1996): recovery options: 0 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_init::jk_ajp_common.c (2000): retries: 2 [Fri Apr 20 11:14:40 2007] [32052:9664] [debug] ajp_create_endpoint_cache::jk_ajp_common.c (1879): setting connection pool size to 25 with min 12 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] do_shm_open::jk_shm.c (295): Truncated shared memory to 28800 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] do_shm_open::jk_shm.c (327): Initialized shared memory size=28800 free=28672 addr=0x2af705d23000 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] do_shm_open_lock::jk_shm.c (234): Opened shared memory lock /var/log/apache2/jk-runtime-status.lock [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] init_jk::mod_jk.c (2355): Initialized shm:/var/log/apache2/jk-runtime-status [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] uri_worker_map_open::jk_uri_worker_map.c (361): rule map size is 0 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] build_worker_map::jk_worker.c (236): creating worker ajp13 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] wc_create_worker::jk_worker.c (141): about to create instance ajp13 of ajp13 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] wc_create_worker::jk_worker.c (154): about to validate and init ajp13 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_validate::jk_ajp_common.c (1842): worker ajp13 contact is 'localhost:8009' [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1965): setting endpoint options: [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1968): keepalive:0 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1972): timeout: -1 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1976): buffer size: 0 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1980): pool timeout: 0 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1984): connect timeout: 0 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1988): reply timeout:0 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1992): prepost timeout: 0 [Fri Apr 20 11:14:40 2007] [32053:9664] [debug] ajp_init::jk_ajp_common.c (1996): recovery options: 0 [Fri Apr 20 11:14:40
Re: problems configuring mod_jk
On Fri, 20 Apr 2007, Mladen Turk wrote: Faheem Mitha wrote: Ok, thanks for your help. This is the portion of the log generated by mod_jk, which I presume is what is relevant. The formatting is not optimal, but I can try to wrap it if desired. The server wide directives: JkWorkersFile, etc must not be defined inside VirtualHost Put those in root. Hi, The relevant section of the apache config file follows. As you can see, everything in currently inside VirtualHost. What directives can be safely left inside VirtualHost? The documentation clearly states that You can use the JkMount directive at the top level or inside VirtualHost sections of your httpd.conf file. Does everything else have to be outside? Thanks for pointing this out. It is so easy to miss the obvious. Faheem. ** VirtualHost 152.3.172.60:443 ServerName dulcicore.dulci.org # Sample mod_jk configuration # for Apache 2 # # for all commands/options available see the manual # provided in libapache-mod-jk-doc package. # The location where mod_jk will find the workers definitions JkWorkersFile /etc/libapache2-mod-jk/workers.properties # The location where mod_jk is going to place its log file JkLogFile /var/log/apache2/mod_jk.log # The log level: # - info log will contain standard mod_jk activity (default). # - warn log will contain non fatal error reports. # - error log will contain also error reports. # - debug log will contain all information on mod_jk activity # - trace log will contain all tracing information on mod_jk activity JkLogLevel debug # Assign specific URLs to Tomcat. In general the structure of a # JkMount directive is: JkMount [URL prefix] [Worker name] # send all requests ending in .jsp to ajp13_worker JkMount /* ajp13_worker #JkMount /* ajp13_worker # send all requests ending /servlet to ajp13_worker #JkMount /*/servlet/ ajp13_worker # JkUnmount directive acts as an opposite to JkMount and blocks access # to a particular URL. The purpose is to be able to filter out the # particular content types from mounted context. # do not send requests ending with .gif to ajp13_worker #JkUnMount /servlet/*.gif ajp13_worker # JkMount / JkUnMount directives can also be used inside VirtualHost # sections of your httpd.conf file. /VirtualHost - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems configuring mod_jk
On Fri, 20 Apr 2007, Mladen Turk wrote: So, have you tried to put the JkWorkersFile outside the vhost? I've moved everything outside except the JkMount stuff. The worker is now seen, and I'm now seeing a different error message, so that's progress. Thanks very much for your help. Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems configuring mod_jk
On Thu, 19 Apr 2007, Rainer Jung wrote: Your worker.list entry is only a comment :( This does look like it in the email, but it is probably some artifact of the cutting and pasting process. To make sure, I've added a blank line after every comment. Anyway, that is not the problem. Any other ideas about this? Debugging strategies? Thanks. Faheem. Faheem Mitha wrote: Hi, I'm trying to set up Apache to talk to Tomcat using the mod_jk connector. However, I get the following error in the log, /var/log/apache2/mod_jk.log jk_handler::mod_jk.c (1986): Could not find a worker for worker name=ajp13_worker Apparently it cannot find the definition (or whatever) for ajp13_worker, but this is defined in /etc/libapache2-mod-jk/workers.properties as far as I can tell. I include the relevant portions of my config below. If anyone can tell me what I'm doing wrong, that would be great. Thanks in advance. Faheem. Relevant portion of apache config LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so VirtualHost x.x.x.60:443 ServerName ... # Sample mod_jk configuration # for Apache 2 # # for all commands/options available see the manual # provided in libapache-mod-jk-doc package. # The location where mod_jk will find the workers definitions JkWorkersFile /etc/libapache2-mod-jk/workers.properties # The location where mod_jk is going to place its log file JkLogFile /var/log/apache2/mod_jk.log # The log level: # - info log will contain standard mod_jk activity (default). # - warn log will contain non fatal error reports. # - error log will contain also error reports. # - debug log will contain all information on mod_jk activity # - trace log will contain all tracing information on mod_jk activity JkLogLevel info # Assign specific URLs to Tomcat. In general the structure of a # JkMount directive is: JkMount [URL prefix] [Worker name] # send all requests ending in .jsp to ajp13_worker JkMount /*.jsp ajp13_worker #JkMount /* ajp13_worker # send all requests ending /servlet to ajp13_worker #JkMount /*/servlet/ ajp13_worker # JkUnmount directive acts as an opposite to JkMount and blocks access # to a particular URL. The purpose is to be able to filter out the # particular content types from mounted context. # do not send requests ending with .gif to ajp13_worker #JkUnMount /servlet/*.gif ajp13_worker # JkMount / JkUnMount directives can also be used inside VirtualHost # sections of your httpd.conf file. /VirtualHost /etc/libapache2-mod-jk/workers.properties # workers.properties - # # This file is a simplified version of the workers.properties supplied # with the upstream sources. The jni inprocess worker (not build in the # debian package) section and the ajp12 (deprecated) section are removed. # # As a general note, the characters $( and ) are used internally to define # macros. Do not use them in your own configuration!!! # # Whenever you see a set of lines such as: # x=value # y=$(x)\something # # the final value for y will be value\something # # Normaly all you will need to do is un-comment and modify the first three # properties, i.e. workers.tomcat_home, workers.java_home and ps. # Most of the configuration is derived from these. # # When you are done updating workers.tomcat_home, workers.java_home and ps # you should have 3 workers configured: # # - An ajp13 worker that connects to localhost:8009 # - A load balancer worker # # # OPTIONS ( very important for jni mode ) # # workers.tomcat_home should point to the location where you # installed tomcat. This is where you have your conf, webapps and lib # directories. # workers.tomcat_home=/usr/share/tomcat5.5 # # workers.java_home should point to your Java installation. Normally # you should have a bin and lib directories beneath it. # workers.java_home=/usr/lib/j2sdk1.5-sun # # You should configure your environment slash... ps=\ on NT and / on UNIX # and maybe something different elsewhere. # ps=/ # #-- ADVANCED MODE #- # # #-- worker list -- #- # # # The workers that your plugins should create and work with # worker.list=ajp13_worker # #-- ajp13_worker WORKER DEFINITION
Re: problems configuring mod_jk
On Thu, 19 Apr 2007, Rainer Jung wrote: Debugging: via JkLogLevel debug, try to check, if your configured objects appear in the debug log and of course you are free to post the log. Hi Rainer, Thanks for your message. The relevant output from /var/log/apache2/mod_jk.log is appended below: * [Thu Apr 19 11:33:34 2007] [23164:18784] [debug] map_uri_to_worker::jk_uri_worker_map.c (508): Attempting to map URI '/' from 1 maps [Thu Apr 19 11:33:34 2007] [23164:18784] [debug] map_uri_to_worker::jk_uri_worker_map.c (520): Attempting to map context URI '/*' [Thu Apr 19 11:33:34 2007] [23164:18784] [debug] map_uri_to_worker::jk_uri_worker_map.c (534): Found a wildchar match ajp13_worker - /* [Thu Apr 19 11:33:34 2007] [23164:18784] [debug] jk_handler::mod_jk.c (1832): Into handler jakarta-servlet worker=ajp13_worker r-proxyreq=0 [Thu Apr 19 11:33:34 2007] [23164:18784] [debug] wc_get_worker_for_name::jk_worker.c (111): did not find a worker ajp13_worker [Thu Apr 19 11:33:34 2007] [23164:18784] [info] jk_handler::mod_jk.c (1986): Could not find a worker for worker name=ajp13_worker ** The relevant output from the tomcat logs is appended below. So, the communication between apache and tomcat is screwed up. Just wondering if the interface that tomcat is listening on is correct, or could this be the problem? INFO: JK: ajp13 listening on /0.0.0.0:8009 Thanks. Faheem. ** Apr 19, 2007 11:36:01 AM org.apache.coyote.http11.Http11BaseProtocol pause INFO: Pausing Coyote HTTP/1.1 on http-core.dulci.org%2F152.3.172.111-443 Apr 19, 2007 11:36:02 AM org.apache.catalina.core.StandardService stop INFO: Stopping service Catalina Apr 19, 2007 11:36:02 AM org.apache.coyote.http11.Http11BaseProtocol destroy INFO: Stopping Coyote HTTP/1.1 on http-core.dulci.org%2F152.3.172.111-443 Apr 19, 2007 11:36:02 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: Failed shutdown of Apache Portable Runtime Apr 19, 2007 11:36:10 AM org.apache.catalina.core.AprLifecycleListener lifecycleEvent INFO: The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /usr/lib/j2sdk1. 5-sun/jre/lib/amd64/server:/usr/lib/j2sdk1.5-sun/jre/lib/amd64 Apr 19, 2007 11:36:10 AM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-core.dulci.org%2F152.3.172.111-443 Apr 19, 2007 11:36:10 AM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1538 ms Apr 19, 2007 11:36:10 AM org.apache.catalina.core.StandardService start INFO: Starting service Catalina Apr 19, 2007 11:36:10 AM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5 Apr 19, 2007 11:36:10 AM org.apache.catalina.core.StandardHost start INFO: XML validation disabled Apr 19, 2007 11:36:13 AM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-core.dulci.org%2F152.3.172.111-443 Apr 19, 2007 11:36:13 AM org.apache.jk.common.ChannelSocket init INFO: JK: ajp13 listening on /0.0.0.0:8009 Apr 19, 2007 11:36:13 AM org.apache.jk.server.JkMain start INFO: Jk running ID=0 time=0/31 config=null Apr 19, 2007 11:36:13 AM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource Apr 19, 2007 11:36:13 AM org.apache.catalina.startup.Catalina start INFO: Server startup in 3243 ms - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems configuring mod_jk
On Thu, 19 Apr 2007, Mladen Turk wrote: Well, will you uncomment the worker.list directive or not? If you choose not to then it will always give you the log like this. The worker.list directive was always uncommented. When I sent the original message, I think there was some kind of error which made it look like it was commented. Anyway, it is definitely uncommented now, but the error persists. Faheem Mitha wrote: wc_get_worker_for_name::jk_worker.c (111): did not find a worker ajp13_worker This means that the ajp13_worker is not listed in worker.list= Could it be anything else? Thanks.Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
problems configuring mod_jk
Hi, I'm trying to set up Apache to talk to Tomcat using the mod_jk connector. However, I get the following error in the log, /var/log/apache2/mod_jk.log jk_handler::mod_jk.c (1986): Could not find a worker for worker name=ajp13_worker Apparently it cannot find the definition (or whatever) for ajp13_worker, but this is defined in /etc/libapache2-mod-jk/workers.properties as far as I can tell. I include the relevant portions of my config below. If anyone can tell me what I'm doing wrong, that would be great. Thanks in advance. Faheem. Relevant portion of apache config LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so VirtualHost x.x.x.60:443 ServerName ... # Sample mod_jk configuration # for Apache 2 # # for all commands/options available see the manual # provided in libapache-mod-jk-doc package. # The location where mod_jk will find the workers definitions JkWorkersFile /etc/libapache2-mod-jk/workers.properties # The location where mod_jk is going to place its log file JkLogFile /var/log/apache2/mod_jk.log # The log level: # - info log will contain standard mod_jk activity (default). # - warn log will contain non fatal error reports. # - error log will contain also error reports. # - debug log will contain all information on mod_jk activity # - trace log will contain all tracing information on mod_jk activity JkLogLevel info # Assign specific URLs to Tomcat. In general the structure of a # JkMount directive is: JkMount [URL prefix] [Worker name] # send all requests ending in .jsp to ajp13_worker JkMount /*.jsp ajp13_worker #JkMount /* ajp13_worker # send all requests ending /servlet to ajp13_worker #JkMount /*/servlet/ ajp13_worker # JkUnmount directive acts as an opposite to JkMount and blocks access # to a particular URL. The purpose is to be able to filter out the # particular content types from mounted context. # do not send requests ending with .gif to ajp13_worker #JkUnMount /servlet/*.gif ajp13_worker # JkMount / JkUnMount directives can also be used inside VirtualHost # sections of your httpd.conf file. /VirtualHost /etc/libapache2-mod-jk/workers.properties # workers.properties - # # This file is a simplified version of the workers.properties supplied # with the upstream sources. The jni inprocess worker (not build in the # debian package) section and the ajp12 (deprecated) section are removed. # # As a general note, the characters $( and ) are used internally to define # macros. Do not use them in your own configuration!!! # # Whenever you see a set of lines such as: # x=value # y=$(x)\something # # the final value for y will be value\something # # Normaly all you will need to do is un-comment and modify the first three # properties, i.e. workers.tomcat_home, workers.java_home and ps. # Most of the configuration is derived from these. # # When you are done updating workers.tomcat_home, workers.java_home and ps # you should have 3 workers configured: # # - An ajp13 worker that connects to localhost:8009 # - A load balancer worker # # # OPTIONS ( very important for jni mode ) # # workers.tomcat_home should point to the location where you # installed tomcat. This is where you have your conf, webapps and lib # directories. # workers.tomcat_home=/usr/share/tomcat5.5 # # workers.java_home should point to your Java installation. Normally # you should have a bin and lib directories beneath it. # workers.java_home=/usr/lib/j2sdk1.5-sun # # You should configure your environment slash... ps=\ on NT and / on UNIX # and maybe something different elsewhere. # ps=/ # #-- ADVANCED MODE #- # # #-- worker list -- #- # # # The workers that your plugins should create and work with # worker.list=ajp13_worker # #-- ajp13_worker WORKER DEFINITION -- #- # # # Defining a worker named ajp13_worker and of type ajp13 # Note that the name and the type do not have to match. # worker.ajp13_worker.port=8009 worker.ajp13_worker.host=localhost worker.ajp13_worker.type=ajp13 # # Specifies the load balance factor when used with # a load balancing worker. # Note: # lbfactor must be 0 # Low lbfactor means less work done by the worker. worker.ajp13_worker.lbfactor=1 # # Specify the size of
Re: running tomcat on a particular network interface and a particular port
On Tue, 17 Apr 2007, David Smith wrote: Ahhh the joy of *nix operating systems. Way back in the distant past of unix systems, someone decided it was a bad idea to allow any user on the system to bind to the well known low ports (1 - 1024) where officially sanctioned services (POP, SMTP, FTP, etc., ...) should be. A great idea except it also required the services to be running as a privileged user to gain access. For a lot of reasons, services should run with the least privilege. A couple of the most common solutions to this problem are: 1. Start tomcat using jsvc. You can get it from the commons-daemon project at http://jakarta.apache.org/commons/daemon 2. Run tomcat on a higher port like 8443 and attempt to use iptables to divert the traffic intended for 443 to tomcat. I'm a bit dubious on if this will work with an SSL connection. You can try it if you like. My vote is for 1. It's easy and tomcat can act as a well behaved, respectable service running with minimum privilege while still capturing a privileged port. I'm inclined to go for 1 too. Are there any drawbacks to this approach besides introducing another piece of software? Also, can anyone recommend a nice simple howto or somesuch? Thanks for the super helpful advice. Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat on a particular network interface and a particular port
On Tue, 17 Apr 2007, Paul Singleton wrote: David Smith wrote: Ahhh the joy of *nix operating systems. Way back in the distant past of unix systems, someone decided it was a bad idea to allow any user on the system to bind to the well known low ports (1 - 1024) where officially sanctioned services (POP, SMTP, FTP, etc., ...) should be. A great idea except it also required the services to be running as a privileged user to gain access. For a lot of reasons, services should run with the least privilege. This kludge was forgiveable on multi-user systems (anyone remember them?) but makes things worse on secure servers; unfortunately you seem to have to recompile the kernel to switch it off... A couple of the most common solutions to this problem are: 1. Start tomcat using jsvc. You can get it from the commons-daemon project at http://jakarta.apache.org/commons/daemon 2. Run tomcat on a higher port like 8443 and attempt to use iptables to divert the traffic intended for 443 to tomcat. I'm a bit dubious on if this will work with an SSL connection. You can try it if you like. It works as well for HTTPS as it does for HTTP (i.e. fine) but you may nevertheless prefer to avoid configuring port redirection into iptables. My vote is for 1. It's easy and tomcat can act as a well behaved, respectable service running with minimum privilege while still capturing a privileged port. I opted for 2 (have used this in production a coupla years now) as it doesn't involve any software you wouldn't have to use anyway (if someone discovers a security vulnerability in jsvc tomorrow I shall be smugly smiling) but realistically there's nothing in it and the choice is yours... I'm inclined to go for 1 if it is simpler. It sounds like it is simpler. However, I'm curious; do you know what kernel flag needs to be recompiled in order to switch this off? Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat on a particular network interface and a particular port
On Tue, 17 Apr 2007, Faheem Mitha wrote: On Tue, 17 Apr 2007, David Smith wrote: Ahhh the joy of *nix operating systems. Way back in the distant past of unix systems, someone decided it was a bad idea to allow any user on the system to bind to the well known low ports (1 - 1024) where officially sanctioned services (POP, SMTP, FTP, etc., ...) should be. A great idea except it also required the services to be running as a privileged user to gain access. For a lot of reasons, services should run with the least privilege. A couple of the most common solutions to this problem are: 1. Start tomcat using jsvc. You can get it from the commons-daemon project at http://jakarta.apache.org/commons/daemon 2. Run tomcat on a higher port like 8443 and attempt to use iptables to divert the traffic intended for 443 to tomcat. I'm a bit dubious on if this will work with an SSL connection. You can try it if you like. My vote is for 1. It's easy and tomcat can act as a well behaved, respectable service running with minimum privilege while still capturing a privileged port. I'm inclined to go for 1 too. Are there any drawbacks to this approach besides introducing another piece of software? Also, can anyone recommend a nice simple howto or somesuch? I just discovered that the latest version of the tomcat 5.5 debian package in unstable (5.5.20-4) uses jsvc. So I happily installed it, only to discover that it is buggy, and does not appear to run correctly. The version 5.5.20-2 in etch works fine, but does not use jsvc. This is a major drag. I don't feel competent to mess around with init scripts and so forth, so I'd much rather use the Debian package. Does anyone have a locally fixed version or have other suggestions about what to do? Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat on a particular network interface and a particular port
On Tue, 17 Apr 2007, Faheem Mitha wrote: On Tue, 17 Apr 2007, Faheem Mitha wrote: On Tue, 17 Apr 2007, David Smith wrote: Ahhh the joy of *nix operating systems. Way back in the distant past of unix systems, someone decided it was a bad idea to allow any user on the system to bind to the well known low ports (1 - 1024) where officially sanctioned services (POP, SMTP, FTP, etc., ...) should be. A great idea except it also required the services to be running as a privileged user to gain access. For a lot of reasons, services should run with the least privilege. A couple of the most common solutions to this problem are: 1. Start tomcat using jsvc. You can get it from the commons-daemon project at http://jakarta.apache.org/commons/daemon 2. Run tomcat on a higher port like 8443 and attempt to use iptables to divert the traffic intended for 443 to tomcat. I'm a bit dubious on if this will work with an SSL connection. You can try it if you like. My vote is for 1. It's easy and tomcat can act as a well behaved, respectable service running with minimum privilege while still capturing a privileged port. I'm inclined to go for 1 too. Are there any drawbacks to this approach besides introducing another piece of software? Also, can anyone recommend a nice simple howto or somesuch? I just discovered that the latest version of the tomcat 5.5 debian package in unstable (5.5.20-4) uses jsvc. So I happily installed it, only to discover that it is buggy, and does not appear to run correctly. The version 5.5.20-2 in etch works fine, but does not use jsvc. This is a major drag. I don't feel competent to mess around with init scripts and so forth, so I'd much rather use the Debian package. Does anyone have a locally fixed version or have other suggestions about what to do? I discovered a local fix (use cronolog) to 5.5.20-4 in Debian bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=402603 I just applied the diff that Adrian Bridgett supplied. a) use cronolog and alter init.d (see attached diff) Pro: simple Con: end up with two logs I don't really have a clear idea what is going on here, but tomcat is now working, and I can run on port 443. I did have to install cronolog, of course. Just thought I'd send this in here in case it was helpful for someone. Presumably the Debian package will be fixed eventually. One question I do have is whether there are any restrictions using tomcat in this way (with jsvc). For example, I think the plan is to use tomcat with something called shibboleth. I'm just doing the installing here, not anything else. Comments? Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
running tomcat on a particular network interface and a particular port
Hello everyone, I have a machine on which I want to run both apache (2.2) and tomcat (5.5) simultaneously and independently, both at port 443. To be more precise, say I have a machine with the two IP names foo.org and bar.org Then I want to run apache at foo.org:443, and tomcat at bar.org:443. I believe this will work if apache and tomcat are configured to only listen respectively at the network interfaces foo.org:443 and bar.org:443. I have already set up apache to listen only to foo.org:443, and I want to set up tomcat to listen only to bar.org:443. I'm using the official Debian etch packages for apache and tomcat. I'm happy to get pointers to offical documentation, though I would be even happier to get precise instructions how to do this. :-) The most important piece of information I am looking for is confirmation that setting up tomcat to listen at a particular network interface and a particular port is indeed possible. Thanks in advance. Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat on a particular network interface and a particular port
On Mon, 16 Apr 2007, David Smith wrote: If you add the address attribute to your tomcat connectors in server.xml, tomcat will bind specifically to those interfaces. See http://tomcat.apache.org/tomcat-5.5-doc/config/http.html for documentation on this. --David Hi, Thanks to David and others for the tomcat configuration information. I have earlier heard references made to the tomcat connector. Just to be clear, is this a separate piece of sofware or part of tomcat? Furthermore, is this something to be used for connecting to other pieces of software like apache? I'm looking to configure tomcat to run in standalone mode, and not connect it to apache at all. Does this seem reasonable? Oh, and just to be clear, this machine has two network cards and two ip addresses corresponding to the two ip names. Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: running tomcat on a particular network interface and a particular port
Hi, I can now get tomcat to run an ssl connector at port 8443 (Debian default), but doesn't work if I try to run it at 443. The log says: Apr 17, 2007 12:31:19 AM org.apache.catalina.startup.Catalina start SEVERE: Catalina.start: LifecycleException: service.getName(): Catalina; Protocol handler start failed: java.net.BindExc eption: Permission denied:443 at org.apache.catalina.connector.Connector.start(Connector.java:1096) at org.apache.catalina.core.StandardService.start(StandardService.java:459) at org.apache.catalina.core.StandardServer.start(StandardServer.java:709) at org.apache.catalina.startup.Catalina.start(Catalina.java:551) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432) My server.xml config now says !-- Define a SSL HTTP/1.1 Connector on port 443 -- Connector address=core.dulci.org port=443 maxHttpHeaderSize=8192 maxThreads=150 minSpareThreads=25 maxSpareThreads=75 enableLookups=false disableUploadTimeout=true acceptCount=100 scheme=https secure=true clientAuth=false sslProtocol=TLS / Any idea what I am missing? I don't think the problem is that apache is blocking 443, because when I turn off apache, I get the same error. In any case, I have configured apache to listen only at the florence.dulci.org:443 interface. Is there an easy way to discover what is listening on a particular port on a particular IP address? Thanks.Faheem. - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
