VectorLinux
October 31, 2014, 10:38:19 pm *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Visit our home page for VL info. To search the old message board go to http://vectorlinux.com/forum1. The first VL forum is temporarily offline until we can find a host for it. Thanks for your patience.
 
Now powered by KnowledgeDex.
   Home   Help Search Login Register  
Please support VectorLinux!
Pages: [1]
  Print  
Author Topic: Trouble with Apache HTTP server  (Read 2679 times)
BGillespie
Member
*
Posts: 4

Where have I known you?


« on: January 08, 2008, 10:00:55 am »

Good afternoon,

First, I'd like to summarize the problem that I'm having, and then I'll provide details on my hardware and software specifications and the steps I've taken so far.

My current goal is to get a minimalistic installation of the Apache HTTP server running on my Slackware machine, and to make it accessible from the internet via a cable modem's IP address.  So far I have successfully:

-- Installed the basic server software from source so that it will serve pages via http on my local machine, and

-- Configured the router/firewall I use to forward requests on port 80 to the correct local address.

However, the server fails to respond to HTTP requests even from machines on my home network.  Specifically, a request to the local IP address results in a timeout error: "The connection has timed out: The server at 192.168.1.6 is taking too long to respond."  In addition, no entries of access attempts by other computers appear in the standard log file.


The system I'm using for this project:

-- Intel Pentium III (Coppermine) processor,
-- Vector Linux 5.8 Standard, Kernel 2.6.18.5, Installed 12-16-2006,

-- Apache HTTP Server (httpd) version 2.2.6,

-- Motorola SB5120 Cable Modem (service via Comcast), connected to
-- Netgear WGT624v3 108 Mbps Wireless Firewall Router, connected to
-- Accton Technology SMC2-1211TX (rev 10) Ethernet Controller (PCI)


At this point, I've considered several possible explanations.  First, I checked if it could be a problem with the main configuration file "apache2/conf/httpd.conf".  However, after reading through documentation on the majority of the directives included in the default configuration file, I've determined that it probably isn't the culprit.  If the problem were in the configuration, it seems that at least an error message of some sort would have been generated, and an entry placed in the log files.

Second, I thought it could be a problem with my ISP, Comcast, which has been known to take liberties with customers' use of networking services.  Sure enough, I discovered that Comcast forbids the use of servers on their residential plans.  However, this does not prove to be a problem if my conscience is okay with sidestepping the letter of the law (it can).  I decided to try a default install of the server on a windows machine of mine, and it worked perfectly without any configuration, both on my local network and from the internet.  From this, it's pretty clear that Comcast is not to blame.

Third, I considered if it could be a problem with compiling from source, so I used Gslapt package manager to install xammp from "http://ftp://ftp.osuosl.org/pub/vectorlinux/veclinux-5.8/extra/".  However, I encountered a similar problem using this approach.  After a long hang time (several minutes), "The connection was reset: The connection to the server was reset while the page was loading."

And that's where I'm stuck.  I've browsed through the forum and searched the internet at large, but I haven't found anything similar that has helped.  I have a vague suspicion that it's either a problem with my hardware or a problem with how Vector Linux is working with my hardware, but I really have no idea how to proceed.

Thank you for any help you can provide.

Yours,
Bryan Gillespie
Logged
rbistolfi
Packager
Vectorian
****
Posts: 2290


« Reply #1 on: January 08, 2008, 10:25:08 am »

Hi Bryan!

First the easiest one. Did you check if the VL firewall is enabled? You can turn it off through vasm, but some issues were reported with it, so the safest way is to 'chmod' the rc.firewall file. Try running chmod -x /etc/rc.d/rc.firewall as root. Please check the path, I am not at my box and I am typing from my memory.
Logged

"There is a concept which corrupts and upsets all others. I refer not to Evil, whose limited realm is that of ethics; I refer to the infinite."
Jorge Luis Borges, Avatars of the Tortoise.

--
Jumalauta!!
newt
Vectorian
****
Posts: 1132



« Reply #2 on: January 08, 2008, 11:41:10 am »

I've had troubles with the firewall in vl58 such that I've had to manually make changes to make them "stick".  Certainly, as rbistolfi suggested, disabling the firewall for the testing phase is an legitimate approach.  If you have success then you can manually adjust your VL firewall to accept port 80 requests.
Logged
bigpaws
Vectorian
****
Posts: 1856


« Reply #3 on: January 08, 2008, 07:22:52 pm »

A couple tests

In a browser try localhost or your ip address

Try nmap localhost to see if port 80 is open.

Bigpaws
Logged
BGillespie
Member
*
Posts: 4

Where have I known you?


« Reply #4 on: January 10, 2008, 01:21:09 pm »

Hey everyone,

Thanks for pointing me in the right direction.  My computer is serving files like a charm.

It was, in fact, the local firewall that was the problem.  It didn't occur to me that the operating system would be providing its own screening for network requests, but in retrospect it makes perfect sense.  After all, network requests are a layer of abstraction on top of the hardware components, and some basic handling at that level is a clear responsibility of the operating system.

As newtor mentioned, opening ports using VASM didn't work.  No buttons were pressed when the dialog was opened, and changes didn't stick.  However, after I used the NEW command to generate a new default firewall, the function seemed to start working as one would expect.  However, the apparent settings still had no effect on the firewall displayed via iptables.

It turns out that the script was actually opening a different firewall (invoked by "service firewall start") rather than using the Vector Linux default.  VASM only changed "/etc/rc.d/rc.firewall", so this firewall service, which calls on "/etc/rc.d/init.d/firewall", was unaffected.  I was able to open the port I needed by manually changing this separate file.

My problem has been resolved, but I wonder if this behavior shows up in the newest versions of Vector Linux?  If it's still in the current releases, it might make sense to look into a couple of changes in VASM and in the default firewall script.

Thanks again,
Bryan
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2013, Simple Machines Valid XHTML 1.0! Valid CSS!