Linux - NetworkingThis forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
My server is Slackware 10, sitting on a Verizon DSL. Got the adsl-start stuff working, but Apache doesn't want to listen to the ppp interface for incoming requests. Everything works fine from the local term, but nothing else, and Webmin, SSH, FTP, Sendmail all work fine, just not apache. It's version 2 of Apache.
Doesn't sound stupid at all, it was the first thing I looked for, but then I realized I don't have ipchains compiled in my kernel, so no firewall. And httpd is up and running, I can use lynx and pull up the page locally, but not remotly. I remember a problem with Apache 1.3 and dynamic connections, but that was fixed. I'm wondering, since the ppp connection is virtual (pppoe) if Apache can even detect it.....
I guess we're actually missing the problem.
I have the same setup and works great. Apache doesn't LISTEN to an interface, all interfaces are good for receiving and transmitting data and a virtual interface is just the same as a real interface to the application layer that doesn't even know about interfaces existence.
Mmm... still I can't realize where the problem could be... assuming you can access the internet with no problem and you don't have a firewall, the problem could be apache configuration itself...
You might want to check with Verizon. Some ISPs block incoming request to port 80 and 443 because they do not want their customers running servers. This might be your case and would fit the symptoms.
That just boggles me cause I can pull it up via lynx on the localhost, but no resolution externally. Hmmmmmmmm, It could be the config, but It's fairley straight forward....... Hmmmmmm
Well you may be able to work round that. If your ISP provides you with some webspace as part of your account then you can point your domain name at your webspace at your ISP and insert a 'pass through' page using frames. Something like:
Code:
<html>
<head>
<title>My Homepage</title>
</head>
<frameset rows="100%,*" border="0" frameborder="0" framespacing="0" framecolor="#000000">
<frame src="http://my-local-machines-external-ip-address:8000/" name="local-appache-server">
</frameset>
<noframes>
Your browser doesn't appear to support frames - please click
<a href="my-local-machines-external-ip-address:8000/">here</A> to view the site.
<CENTER></CENTER><EM><EM></EM></EM><B></B></noframes>
</html>
Basically you run apache so that it listens on port 8000 rather than the default port 80. You create one webpage at your ISP webspace that loads your local webpage into a single frame.
This is for a b iz website, so I don't feel comfy with any of the workarounds, so I'm just going to lease a co-located server, which is better in the longrun anyway, and not all that more expensive then a biz class DSL ($149.00/month)
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.