From wms at igoweb.org Sat Jul 23 00:44:03 2005 From: wms at igoweb.org (William M. Shubert) Date: Fri, 22 Jul 2005 17:44:03 -0700 Subject: TUX not relaying requests? Message-ID: <1122079443.5140.15.camel@desktop.igoweb.org> Hello. I am trying to set up tux with tomcat for the dynamic content. Everything runs great, except that Tux does not forward the requests! I can't figure out why. I tried running a kernel recompiled with debugging for tux turned on, but the kernel started taking panics (I saw in these archives that this is a known issue). I'm hoping somebody will know off the top of their head what is wrong. Here's the details: * FC3, with kernel 2.6.12-1.1372_FC3smp (the latest at the moment) and the tux module that comes with it. When started it identifies itself as "Tux version: 3/0/0", the RPM file for the user space tools is tux-3.2.18-2. * Tux is listening on port 80. "cat /proc/sys/net/tux/clientport" returns 8080 (which is the port where tomcat is running). * "wget http://localhost/gls/glsApplet.jar" is static content, and works perfectly. Tux writes the request result properly into the log, so I'm sure that Tux is handling this one. * "wget http://localhost:8080/gls/userInfo.jsp" is dynamic content, and works perfectly, so I know that Tomcat is properly listening on port 8080 and answering requests. * "wget http://localhost/gls/userInfo.jsp", however, is the problem. It is my understanding that since this file does not exist, tux should relay the request to tomcat. Instead, I get back "404: Not found". The Tomcat logs indicate that it did not see any request come in at all. I've poked everywhere I could. I added "jsp" as a content type with "TUX/redirect" to tux.mime.types, it didn't help. I created files named "userInfo.jsp" in /var/www/html/ tree. This returns the dummy file if "jsp" is *NOT* in tux.mime.types, but returns 404 if "jsp" *IS* set up as redirect in tux.mime.types. I tried binding tomcat's listen port to IP address 127.0.0.1 and leaving it wildcarded; this doesn't change anything. I tried replacing tomcat with apache; again no change. It just really, really, looks like tux isn't even trying to forward the requests to the dynamic content web server. Is there some setting I'm missing that can cause this? Some test I can run that might give more information? Any help is appreciated! From diogenes at xenodochy.org Sat Jul 23 06:32:24 2005 From: diogenes at xenodochy.org (Ralph E. Kenyon, Jr.) Date: Sat, 23 Jul 2005 02:32:24 -0400 Subject: TUX not relaying requests? In-Reply-To: <1122079443.5140.15.camel@desktop.igoweb.org> References: <1122079443.5140.15.camel@desktop.igoweb.org> Message-ID: On Fri, 22 Jul 2005 20:44:03 -0400, William M. Shubert wrote: > Hello. I am trying to set up tux with tomcat for the dynamic content. > Everything runs great, except that Tux does not forward the requests! I > can't figure out why. I tried running a kernel recompiled with debugging > for tux turned on, but the kernel started taking panics (I saw in these > archives that this is a known issue). I'm hoping somebody will know off > the top of their head what is wrong. Here's the details: > * FC3, with kernel 2.6.12-1.1372_FC3smp (the latest at the moment) > and the tux module that comes with it. When started it > identifies itself as "Tux version: 3/0/0", the RPM file for the > user space tools is tux-3.2.18-2. > * Tux is listening on port 80. "cat /proc/sys/net/tux/clientport" > returns 8080 (which is the port where tomcat is running). > * "wget http://localhost/gls/glsApplet.jar" is static content, and > works perfectly. Tux writes the request result properly into the > log, so I'm sure that Tux is handling this one. > * "wget http://localhost:8080/gls/userInfo.jsp" is dynamic > content, and works perfectly, so I know that Tomcat is properly > listening on port 8080 and answering requests. > * "wget http://localhost/gls/userInfo.jsp", however, is the > problem. It is my understanding that since this file does not > exist, tux should relay the request to tomcat. Instead, I get > back "404: Not found". The Tomcat logs indicate that it did not > see any request come in at all. > I've poked everywhere I could. I added "jsp" as a content type with > "TUX/redirect" to tux.mime.types, it didn't help. I created files named > "userInfo.jsp" in /var/www/html/ tree. This returns the dummy file if > "jsp" is *NOT* in tux.mime.types, but returns 404 if "jsp" *IS* set up > as redirect in tux.mime.types. I tried binding tomcat's listen port to > IP address 127.0.0.1 and leaving it wildcarded; this doesn't change > anything. I tried replacing tomcat with apache; again no change. It just > really, really, looks like tux isn't even trying to forward the requests > to the dynamic content web server. > > Is there some setting I'm missing that can cause this? Some test I can > run that might give more information? Any help is appreciated! > > _______________________________________________ > tux-list mailing list > tux-list at redhat.com > https://www.redhat.com/mailman/listinfo/tux-list I'm on Redhat 9 running tux and apache together. Here's what I needed to do to the httpd.config file. Modify file /etc/httpd/conf/httpd.conf # Change this to Listen on specific IP addresses as shown below to # prevent Apache from glomming onto all bound IP addresses (0.0.0.0) # #Listen 12.34.56.78:80 Listen 127.0.0.1:8080 This tells apache to listen on port 8080. Maybe you have something like this for tomcat. Also, tux.mime.types must be told what to redirect File /etc/tux.mime.types # - all extensions listed after TUX/redirect will be redirected # to the secondary server. # - all extensions listed after TUX/CGI will be handled by the # TUX CGI engine directly. # - all extensions listed after TUX/module will be handled by # TUX userspace modules. # # MIME type Extension TUX/redirect shtml html htm php With this setup, Tux serves static context, but passes specific types to Apache on my system. I hope this is helpful. -- Ralph E. Kenyon, Jr. http://www.xenodochy.org/ralph.html 191 White Oaks Road Williamstown, MA 01267-2259 Phone: 413-458-3597 Home pages: http://www.xenodochy.org http://www.ballroomdances.org ------------------------------------------------------- FIGHT SPAM http://www.xenodochy.org/diogenes/antispam.html (If you are thinking about collecting my email address, read the above page first!) ------------------------------------------------------ Plain text markup: *bold*, /italic/, _underline_, LOUD -------------------------------------------------------- Keep our semantic environments and cyberspace clean. Always report errors discovered while surfing the web. ------------------------------------------------------ My favorite saying (from general semantics): It's not that seeing is believing, believing is seeing, and we're much better at believing than we are at seeing. http://www.xenodochy.org/ex/quotes/santayana.html From wms at igoweb.org Sat Jul 23 06:56:04 2005 From: wms at igoweb.org (William M. Shubert) Date: Fri, 22 Jul 2005 23:56:04 -0700 Subject: TUX not relaying requests? (Problem solved!) In-Reply-To: <1122079443.5140.15.camel@desktop.igoweb.org> References: <1122079443.5140.15.camel@desktop.igoweb.org> Message-ID: <1122101764.4678.10.camel@desktop.igoweb.org> First I'd like to thank everybody who took the time to answer. I checked what each person suggested, but in every case my system was set up the way that they recommended. Since none of the "it sounds like..." responses were working out, I took the time to to investigate some more. Since turning on debugging made the kernel panic, I instead added a printk at each juncture where tux was deciding whether or not to forward. Luckily, this did not make any panics, and in fact found the problem. The problem is in these lines of net/tux/redirect.c: if (sk->sk_family != AF_INET) { sock_put(sk); goto out; } It turns out that Java creates IPv6 sockets when possible, giving you an sk_family of AF_INET6 instead of AF_INET! When I tried Apache, that also failed, because the Apache that comes with FC3 is also set up to create IPv6 sockets when possible! I don't know whether or not simpling changing the check to allow AF_INET or AF_INET6 sockets would work - at some level Linux lets IPv6 talk to IPv4, but whether or not the Tux forwarding would work with that, I can't say and I have not tested it. I did find that adding this to my "startup.sh" for tomcat fixed the problem: JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true" I do not know what the corresponding Apache configuration option is, but I suspect that there is one. So again, thanks to everybody who responded. If anybody has a similar problem, take a close look at the output of "netstat --tcp --listen -n" to make sure that your client web server is using IPv4! It would also be nice to get a Tux that would work with IPv6 eventually.