Geek Alert for this post.
I’m running a web server app on my computer, which I can address by http://localhost:8080/webapp, where “webapp” is the app.
It works fine, but in theory, I should be able to access it from another machine on the network via http://localhostIP:8080/webapp, where “localhostIP” is the IP address of my machine, but I can’t. It just times out.
I’ve even installed Apache on the machine, and I’ve set up a reverse proxy in the Apache config file per the following:
ProxyRequests On
Order deny,allow
Deny from all
Allow from 192.168
#Set up reverse proxy for Webapp server
ProxyPass /webapp/ http://localhost:8080/webapp/
ProxyPassReverse /webapp/ http://localhost:8080/webapp/
ProxyPreserveHost On
Again, where “webapp” is the actual webserver that I’m trying to access remotely.
When I try to access this from either a remote, or my local machine, by http://localhostIP/webapp, I get the message: “The requested URL /webapp was not found on this server.”
Any Apache gurus who can tell me what the problem might be? I’ve opened up firewall to both http and https.
[Update Friday morning]
Problem solved. As noted in comments, it was a combination of allowed ports and SELinux.
Try this:
Assuming you are running the apache web server on your machine (the one where the webapp resides):
You should be able to do (on that machine)
http://localhost:8080
and get the apache welcome page which verifies that the apache server is running on that machine. Then you should be able to go to the other machine and do
http://localhostIP:8080
and see the same thing. If you can, this tells you that the apache web server is runnin (on the first machine) and is accessible from the second, so the problem (in that case) isn’t the apache web server. If you do this you can figure out if the problem is something in the webapp or the server. My bet would be the web app.
A common issue I’ve run into when doing/developing web apps is that something inside the web app makes a reference to a file or url or something which works when I am running the web app on the same machine as the server, but doesn’t work from a remote location. A simple example would be if the web app tries to access a file using a file system path–the path doesn’t exist on the remote machine. To get around this last you can usually use relative paths in the web app. These are fun to debug. I’ve often resorted to putting lots of alerts in javascript in my web app so I can pin down exactly where it’s bailing. Firebug helps a lot too. And I don’t think I’m a very advanced web app developer.
Assuming you are running the apache web server on your machine (the one where the webapp resides):
You should be able to do (on that machine)
http://localhost:8080
and get the apache welcome page which verifies that the apache server is running on that machine.
Nope, when I do that, I get the webapp…
A common issue I’ve run into when doing/developing web apps is that something inside the web app makes a reference to a file or url or something which works when I am running the web app on the same machine as the server, but doesn’t work from a remote location. A simple example would be if the web app tries to access a file using a file system path–the path doesn’t exist on the remote machine. To get around this last you can usually use relative paths in the web app. These are fun to debug.
I assume that last sentence is meant ironically. It’s an open-source app, but I dread the debugging. I don’t know why it doesn’t work according to the instructions. I guess this is why they charge thousands a year for support…
I should say, though, that I can’t even get it to run right on the same machine. When I try http://localhost/webapp, I get the error message. It’s not just from the remote machine.
I should add that Apache is running fine, when I access it with http://localhost, from either local or remote machine.
So the webapp is hijacking the port…?
I’m going to guess you have a network issue if it works exactly as you say. “localhost” gets mapped to the special address 127.0.0.1 and is handled by the loopback interface (lo). Something that needs to come in from the local network needs to be handled by an actual ethernet interface, e.g. eth0. It’s quite easy to have lo working fine but eth0 gronked.
(1) Are you sure the two machines can talk to each other at all? For example, can you ping locahostIP from the other machine? Make an ssh connection? If not, then you have a general networking issue unrelated to Apache.
(2) What does the Apache error log say? If it says nothing at all, then the request isn’t even being handed to the Apache server, which points either again to network issues or to a local problem with binding Apache to the correct local port. (Don’t neglect firewall and NAT issues, of course.)
(3) If, on the other hand, the Apache error log has some entries that are related to your attempts, there’s some chance you’ll find something useful in there about *why* it won’t respond to the HTTP request.
A couple of thoughts:
– It would be helpful to see the entire Apache configuration file(s). Depending upon how you have virtual hosts/server name set up, the behavior you are seeing may be completely expected.
– Are there any firewalls in the way, including local ones like iptables (assuming this is Linux)?
– You are redirecting to port 8080 (tomcat?), is the app server set up to allow connections from from other hosts?
Feel free to email any additional details you like.
Are you sure the two machines can talk to each other at all?
Yes, the other machine sees Apache, when it’s not directed to port 8080.
You are redirecting to port 8080 (tomcat?), is the app server set up to allow connections from from other hosts?
I’m guess that is the problem (it is tomcat). Where would I look to fix?
Make sure the server is listening on address 0.0.0.0, not the 192.168 address of the machine.
The output of “netstat -an” would be quite useful in debugging this problem.
The output of “netstat -an” would be quite useful in debugging this problem.
OK, you asked for it:
Rand, this is a firewall issue. You opened your firewall for http (port 80) and https (port 443); but your service is on port 8080. The apache service looks like it is set up correctly.
Just open up port 8080 manually, and it should work just fine!
I admit that this is all above my paygrade, but I agree that the problem is probably with a firewall. What happens when you try to telnet localhost:8080 and telnet localhostIP:8080?
Port 80 is open. Does that not include 8080?
What happens when you try to telnet localhost:8080 and telnet localhostIP:8080?
If you think I’m going to allow telnet to this machine, you’re insane.
But, OK, just for grins, I’ve enabled port 8080 for both tcp and udp.
Nope, when I do that, I get the webapp…
Do you get the webapp both locally and remotely using the url http://localhostIP:8080?
You don’t have to allow telnet. Just telnet to that port. For a text based protocol you should get something useful. (Telnet to port 25 to see what your email says, for example.) And two ports with different numbers are completely different: from the computer’s perspective, 80 and 8080 are no more alike than 80 and 7351.
Do you get the webapp both locally and remotely using the url
No, only locally.
You don’t have to allow telnet. Just telnet to that port. For a text based protocol you should get something useful.
I can get Apache remotely. I can’t get the web app remotely. I don’t see how testing with telnet will help in diagnosing.
If you can get apache remotely than I suspect it is a configuration problem. Have you checked your httpd.conf file to ensure the app is configured for remote access?
Have you checked your httpd.conf file to ensure the app is configured for remote access?
No, I have encountered no information in this supposedly “open source” software as to how to do that. I guess that little tidbits like this is how they make their money, for those who don’t want to dig through the “open” source…
The reason you can locally access the app at the root url (http://localhostIP:8080) is because you used the default Apache deployment. Very simple configuration options will enable you to access the app at any url you wish.
For netstat, try using “netstat -a -n –tcp” which should give a more relevant list.
I suspect that a previous commenter was correct, that port 8080 isn’t permitted on the target system (so such packets are dropped). Testing with telnet localHostIP 8080 will indicate if you have a network (probably firewall) problem, or an Apache configuration problem. If the telnet times out, then it’s a network problem. If it connects, it’s an Apache configuration problem. Apache can’t tell the difference between a web browser connect and a telnet connet, it’s just a TCP network connection. The identity of the program making the connection isn’t available.
You might want to try WireShark, which lets you look at the actual packets on the wire. You could run it on the webhost and see if any port 8080 packets arrive.
How could I forget wget? That’s a very handy utility for this kind of thing, especially if you set debugging on.
By “telnet” we mean the telnet client, not the telnet server.
None of that is necessary since he can access the web server remotely via http://localhostIP:8080. It’s a configuration issue.
@gedaliya Really? That’s good to hear!
I guess that little tidbits like this is how they make their money
Too often and with no apologizes. I have no respect for crappy programmers that expect the customer to pay for their mistakes and laziness. Even among programmers I’ve never handed off a piece of code as bad as what I’ve had handed to me. This has handicapped me because I wont sell the kind of crap others do. I’m currently working on code I plan to throw away after perhaps a year of work because its purpose is just to validate the db structure.
Not a Linux or network guy, I do find this thread fascinating. I hope you find your solution.
It sounds very much like you simply haven’t opened up the port at 8080. You indicate that http and https are open, but those are 80 and 443. 8080 needs to be opened up explicitly.
And the point of using telnet to access that port is specifically to see if it open and listening. If you telnet to that port and get rejected (or get nothing at all), then it is a good sign that you still have to open it up.
telnet 192.168.0.100 8080
Trying 192.168.0.100…
Connected to 192.168.0.100.
Escape character is ‘^]’.
I assume from the last post that this isn’t resolved?
Can I review the facts and you correct me?
1. You are running a web application on machine1 on port 8080 called “webapp” (you never said in Apache; I’m guessing Tomcat or Coldfusion or some kind of application server)
2. You can access this from machine1 at http://localhost:8080/webapp.
3. You have opened the firewall on machine1 to include 8080.
4. You can telnet from machine “proxy” to machine “machine1” at port 8080.
5. You have configured the proxy settings in Apache in what look pretty good; I haven’t really looked in detail.
Q1. Can you now access http://machine1:8080/webapp from proxy?
Q2. Do you have SELinux running on “proxy” (I ran into SELinux problems when I set this up last week. See /var/log/httpd/error_some_log_file and http://www.techiegyan.com/2008/08/31/http-proxy-problem-permission-denied-proxy-http-attempt-to-connect-to-1270018080/)
I’d answer Q1 in the affirmative first then check the second.
Q1. Can you now access http://machine1:8080/webapp from proxy?
Q2. Do you have SELinux running on “proxy”
Yes, I can now, perhaps because I opened 8080, which actually solves most of my problem. I was really just trying to be able to access the server, and don’t care whether or not it is proxied.
Q2. Do you have SELinux running on “proxy”
That I don’t know. It’s not obvious how to administrate SELinux in Fedora 14. I’ll have to research that.
Here is my current SELinux configuration:
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing – SELinux security policy is enforced.
# permissive – SELinux prints warnings instead of enforcing.
# disabled – SELinux is fully disabled.
#SELINUX=enforcing
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted – Only targeted network daemons are protected.
# strict – Full SELinux protection.
SELINUXTYPE=targeted
It looks to me like it’s not enabled.
The default value of SELINUX= is “enforcing”. So, yes, it’s enabled. The OS that I just configured in a similar way is Fedora Core 15, so I don’t imagine it’s too different.
The symptom of the SELinux problem is that you can connect from machine “proxy” and there are lines in your file /var/log/httpd/error_log that say:
[Wed Aug 17 02:04:18 2011] [error] (13)Permission denied: proxy: HTTP: attempt to connect to 107.x.xx.xxxx:8081 (xxx.mydomain.com) failed
When you connect through the URL http://proxy/path
The solution is at those links I sent, if that’s your problem.
This and other problems have led me to the extremely not-recommended solution of disabling SELinux on my machine. There were other issues like not being able to run PHP scripts in another app even though the apache user had permissions, because the request came from the httpd process specifically, so the problem was also about impossible to debug. I have been saying for about 7 years that some day I’ll learn it, but I keep turning it off in systems I own.
Well, ‘/usr/sbin/setsebool httpd_can_network_connect 1’ did it.
Thanks.
Good. I feel like the two days last week figuring this out for me were well-spent. 🙂
This and other problems have led me to the extremely not-recommended solution of disabling SELinux on my machine.
I’ve never had anything but trouble from SELinux. I strongly suspect that it does a heck of a lot more harm than good for most users.
Congrats on getting that fixed!