Re: Blocking AJP13 (port 8009) access
Try adding address=127.0.0.1 to the ajp13 connector tag in server.xml, and configuring apache to connect to 127.0.0.1 if you haven't already. This should stop the ajp13 port from being visable to other machines. As far as iptables goes, you probably want -o lo -j ACCEPT at the top of the ruleset, and I'm really not sure why you're using state flags to attempt to block external access to port 8009. Mostly you don't want drop rules to check the state table, though this might be some iptablism, I'm not too familiar with it past basic NAT / port blocking. -Antony On 2/14/06, OG [EMAIL PROTECTED] wrote: Hi, I'm trying to block external access to port 8009 (AJP13), as only my local host really needs to be able to talk to it. I'm wondering if there are any internal/mod_jk mechanisms for that, or if iptables is the best option. I have tried iptables, which did block external requests, but it also got me in a situation where I had a few hundred httpd processes in a SYN_SENT state ( netstat | grep 8009 | grep -c SYN_SENT ) and returning 503s instead of 200s: iptables -A INPUT \ -p TCP --dport 8009 \ -m state --state NEW \ -j DROP iptables -A INPUT \ -p UDP --dport 8009 \ -m state --state NEW \ -j DROP iptables -A OUTPUT -o lo -j ACCEPT iptables -A INPUT -i lo -j ACCEPT If anyone has iptables rules that work, I'd appreciate it if you could share them. I'd also be curious to know whether people use some other mechanisms to prevent evil folks from connecting to your port 8009 from the outsite and consuming your available connections. Thanks, Otis - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problems with Clusters or apache connector not sure which one
I thought you said tomcat ran on 3 different boxes and it was a cluster ? java.io.IOException: Connection reset by peer This means that the tcp connection was severed somehow, this is typically caused by a firewall dropping idle TCP connections, or someone unplugging a network cable, or someone restarting something somewhere. You may want to configure apache to connect to 127.0.0.1 via the workers.properties file if you haven't already, as this will rarely never be firewalled, won't be subject to any link detection scripts, which may mark the interface as down when the link is severed, etc. etc. That's my two cents -Antony On 13/02/06, Randy Paries [EMAIL PROTECTED] wrote: i am the IT, the admin everything. I am a small business owner and i do everything. the apache server and tomcat are on the same box, and there is no firewall involved Is there something that is cluing you into the network problem? Something i should look for? Thanks Randy On 2/13/06, Duan, Nick [EMAIL PROTECTED] wrote: It looks like a network problem to me. Is there any firewall between the apache and your tomcat server? Or did your IT dept reconfigure the network recently? ND -Original Message- From: Randy Paries [mailto:[EMAIL PROTECTED] Sent: Monday, February 13, 2006 9:27 AM To: Tomcat Users List Subject: problems with Clusters or apache connector not sure which one hello, I am running apache-tomcat-5.5.15 on three boxes 2 rh9 and one fedora 4. and they are clustered together I am seeing problems where apache can not longer talk to tomcat. if anyone can point me on how to debug this please help, i am not sure what else i should include as far a conf setups, so please let me know what other details i need to supply so you guys can help Thanks in the log files at the time of the failure i see the following catalina.out ( i will see a bunch of these) Feb 12, 2006 8:25:23 PM org.apache.catalina.cluster.tcp.TcpReplicationThread run SEVERE: TCP Worker thread in cluster caught 'java.io.IOException: Connection reset by peer' closing channel java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcher.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:21) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:233) at sun.nio.ch.IOUtil.read(IOUtil.java:206) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:207) at org.apache.catalina.cluster.tcp.TcpReplicationThread.drainChannel(TcpRep licationThread.java:125) at org.apache.catalina.cluster.tcp.TcpReplicationThread.run(TcpReplicationT hread.java:69) = then in my mod_jk.log i will see = [Sun Feb 12 20:25:10 2006] [jk_ajp_common.c (1303)]: ERROR: Client connection aborted or network problems [Sun Feb 12 20:25:13 2006] [jk_ajp_common.c (1303)]: ERROR: Client connection aborted or network problems [Sun Feb 12 20:25:39 2006] [jk_ajp_common.c (1303)]: ERROR: Client connection aborted or network problems [Sun Feb 12 20:30:00 2006] [jk_ajp_common.c (738)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-104 [Sun Feb 12 20:30:00 2006] [jk_ajp_common.c (1137)]: Error reading reply from tomcat. Tomcat is down or network problems. [Sun Feb 12 20:30:00 2006] [jk_ajp_common.c (1290)]: ERROR: Receiving from tomcat failed, recoverable operation. err=0 [Sun Feb 12 20:30:02 2006] [jk_ajp_common.c (738)]: ERROR: can't receive the response message from tomcat, network problems or tomcat is down. err=-104 [ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: java.lang.Object cannot be resolved
try as root: rpm -e `rpm -q -f /usr/bin/javac` Or something like that. Basically uninstall which ever pitiful excuse for java is installed on your system by default leaving only the sun jdk. Probably a good idea to check that nothing needs it before you do it. On that note, why do certain linux distributions insist on installing bearly usable java versions ? On 13/02/06, Sebastian Funk [EMAIL PROTECTED] wrote: Hi, On Feb 13, 2006, at 5:56 PM, Caldarale, Charles R wrote: From: Sebastian Funk [mailto:[EMAIL PROTECTED] Subject: Re: java.lang.Object cannot be resolved No, simple javac Hello.java doesn't work. Only if I set $CLASSPATH to /usr/lib/jdk/jre/lib/rt.jar or with the -cp-option. Then your JDK installation is broken. Where is javac being executed from? It should be coming from the /usr/lib/jdk/bin directory, and the various pieces of the JVM should be in /usr/lib/jdk/jre/bin and its subdirectories. Is that the case? no, javac was set to /usr/bin/javac but with /usr/lib/jdk/bin/javac ist works fine. Thanks a lot. Greetings, Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: webapp under different URLs with different JSP but same java classes
You could use a javax.servlet.Filter apparently, and say redirect requests
to a particular servername to /jsp_a and redirect the rest to /jsp_b.
basically installing a filter which does the following:
public void doFilter(request,response,chain) {
if(request.getServerName.equals(server1) {
request.getRequestDispatcher(/jsp_a + request.getRequestURI
()).forward(request,response);
} else {
request.getRequestDispatcher(/jsp_b + request.getRequestURI
()).forward(request,response);
}
}
I can't comment if that's the correct way to do it as I'm a little bit new
to filters.
You'd declare it in your web.xml as
filter
filter-namefoobar/filter
filter-classcom.whatever.MyFilter/filter-class
/filter
filter-mapping
filter-namefoobar/filter-name
url-pattern*/url-pattern
/filter-mapping
On 2/10/06, Lothar Krenzien [EMAIL PROTECTED] wrote:
Tomcat Users List users@tomcat.apache.org schrieb am 10.02.0615:14:51:
Duplicate your classes, one copy in each webapp
Of course I did it. But I hoped there is a better way ?
Lothar Krenzien a écrit :
Hi,
I'm not sure whether it is possible or not:
I have a webapp which I want to access under different URL's with
different JSP's but the same java classes. I know that I can define the
context URL in the context.xml But how to define which jsp's to use ?
Example :
Context path=/a docBase=/myapp
/Context
Context path=/b docBase=/myapp
/Context
In myapp I may have a folder jsp_a and jsp_b. Path 'a' should use JSPs
from jsp_a and path 'b' should JSPs from jsp_b. Of course I can set up two
different webapps. But the java classes and so the the content of the
WEB-INF/classes directory will be identically for both webapps. I'm using
Tomcat 5.5 under Windows 2003.
Thanks,
Lothar
__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
__
Verschicken Sie romantische, coole und witzige Bilder per SMS!
Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: pure java mod_rewrite using javax.servlet.Filter
Googles suggested implementation is GPL, which prohibits me from using it, and I'm not paying for the equivalent of mod_rewrite for tomcat. I'd rather write my own and publish it under a less restrictive license. Regards my questions, (1) still stands, (2) I've partially answered for myself, by looking in the servlet 2.4 JSR (notably the dispatcher*/dispatcher web.xml option seems to be missing from the Tomcat docs pages), and RequestDispatcher.forward()/include() does seem to work as expected inside a Filter. (3) I guess I'll try to reproduce this and submit an appropriately carefully worded bug after trawling through the specs myself instead of asking on the mailing list, and having someone read the first two lines and decide that I haven't even tried to use google. On 2/10/06, Bruno Georges [EMAIL PROTECTED] wrote: Hi Antony Such implementation already exist. Google is your friend there. Bruno Georges Glencore International AG Tel. +41 41 709 3204 Fax +41 41 709 3000 - Original Message - From: Antony Riley [EMAIL PROTECTED] Sent: 10.02.2006 14:32 To: users@tomcat.apache.org Subject: pure java mod_rewrite using javax.servlet.Filter Hiya all, I'm looking at writing a Filter class which does request rewriting similar to mod_rewrite in a apache for Tomcat (preferably written so that it will work with any servlets 2.4 compliant server). I'm having a little trouble with regards how filters actually work. The following all happen inside filters (tomcat 5.5, latest stable release): 1) Wrapping the HttpServletRequest with one which modifies request.getRequestURI(), request.getPathInfo() request.getServletPath() does not seem to work, as at this point tomcat seems to have already decided what server will proces the request. 2) using request.getRequestDispatcher(path).forward(request,response) seems to work, however, this does not cause the Filter to be reapplied as I would have expected if called at this stage in the request parsing process. 3) When declaring a filter in a web.xml for an application with a url-mapping of /* seems to break hideously if there is also a default servlet also declared in the web.xml (the application specific web.xml, not the server web.xml) [I can and will probably will have to provide further info on this] seems to break rather horribly causing tomcat to server up unprocessed jsp pages, and fail to do directory indexes, even though without the filter mapping it works correctly. -Antony Riley LEGAL DISCLAIMER. The contents of this e-mail and any attachments are strictly confidential and they may not be used or disclosed by someone who is not a named recipient. If you have received this email in error please notify the sender by replying to this email inserting the word misdirected as the message and delete this e-mail from your system.
