I have recently installed the Apache Tomcat 7 on a Windows XP machine that is connected to a Windows 2003 network. If I start the Tomcat server from a command console window using the startup.bat file, I am able to access the default web page and any other sites that are hosted the tomcat server from a separate PC (not the local host) on the network. If however, I run the Tomcat application as a service, then I am only able to access the sites from the local host PC, i.e. the PC that is hosting the Apache Tomcat application. This appears to be the case with the Apache Server 2.2 as well although I do not seem to have a way of starting that application any other way than as a service. Can somebody tell me what I need to do to make these server applications accessible to other PCs on the network when they are being ran as a service?

Thank you.
Back to top

Running apache on windows.... well, ok, I guess some people have to do that for whatever horrible reason they have to deal with. For apache to be seen on the network, first of all, you need to make sure the ports are listening, port 80, or whatever you use locally. That's in the apache config file, but it's been so long since I've really touched or used apache windows I can't give any specific details.

However I don't recollect apache running as a service as ever being an issue on windows, as long as the config files are set correctly.

Again, keeping in mind that I have no idea of the current windows syntax, on unix/linux, the configs are like this:

/etc/apache2/apache2.conf
## ports called here:
# Include ports listing
Include /etc/apache2/ports.conf

##and
/etc/apache2/ports.conf
is this


then say, the /etc/apache2/sites-available/default
starts with:
<VirtualHost *:80>

or:
<VirtualHost 127.0.0.1:80>
for a real site in virtual hosts.

But again, I really have literally only seen apache2 one time in the last 5 years for Windows, so the configs I'm sure are different, but the ideas are not.

Listening outside the network is just a matter of directing the router ports to the machine, and making sure that apache is listening on those ports.

Hopefully you aren't setting up a windows server to listen to WAN accessible ports, well, unless you want to create a honeypot or something, lol.... so I assume you're only wanting LAN access, in which case the port listen 80 is the only one you need. And if memory serves me, you'd replace <VirtualHost 127.0.0.1:80> with the machine actual IP address.

It's a lot easier to set up a linux box with apache though for local dev, everything works as expected, and the configs are nice and portable to any other system, with a few tweaks and changes.

Here's a real example of a virtual hosted local site, examplified:



Note that for windows, the paths require: ".;/www/mysites/site1/includes" that is, a ';' instead of a ':'. Why? Who knows. Also note that the use of port 7999 for example is only for WAN access in testing situations, in your case that would be port 80.

Oh, yeah, I forgot, you have to make sure the windows firewall isn't blocking requests as well, of course. But i assume you know that. First test for that, before any of the above: turn OFF windows firewall on the server, ensure it has a static ip, then try accessing the default page from a remote machine.
Back to top

Thank you for taking the time to reply to my question. Unfortunately, there appears to a significant difference between the configuration files for Linux and the configuration files for Windows. I did manage to identify all of the files that have the keyword Listen in them (see below).

httpd.conf C:\Apache\WebServer\conf
httpd-ssl.conf C:\Apache\WebServer\conf\extra\
httpd.conf C:\Apache\WebServer\conf\original\
httpd-ssl.conf C:\Apache\WebServer\conf\extra\


Here is a snippet from the httpd.conf file:

#
# Listen: Allows you to bind Apache to specific IP addresses and/or
# ports, instead of the default. See also the <VirtualHost>
# directive.
#
# Change this to Listen on specific IP addresses as shown below to
# prevent Apache from glomming onto all bound IP addresses.
#
#Listen 12.34.56.78:80
Listen 8080


Here is a snippet from the httpd-ssl.conf file:

#
# When we also provide SSL we have to listen to the
# standard HTTP port (see above) and to the HTTPS port
#
# Note: Configurations that use IPv6 but not IPv4-mapped addresses need two
# Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443"
#
Listen 443


This is the file that I ran to install the Apache Server httpd-2.2.19-win32-x86-no_ssl.msi file.

One thing I feel I should reiterate, if I download the zip file for the Apache Tomcat and run the startup batch file in the \bin directory, then I am able to access the Tomcat web server from a different PC. If however, I shut down the Tomcat server and then restart it as a service, it will once again be unavailable to an outside PC. It's always available on the localhost no matter which way I start it
Back to top

You have to read the batch file, it will show what it's doing clearly, it's not a binary, it's a text file. DO NOT OPEN WITH WINDOWS NOTEPAD, that's toxic for all configuration and programming files and should never be used for anything by anyone for any reason when it comes to production work.

If you are using: Listen 8080

then all incoming requests need to be in the form of: 12.34.56.78:8080

not just the ip address. It's easier to use port 80 only in the LAN if it's not going to be accessed.

You didn't respond to the firewall question however, that's front and center with xp and vista/7. Always disable all firewalls when debugging until you know that's setup correctly, then proceed to the more complicated stuff.

Also ignore tomcat since you can't get apache2 itself to be seen by other machines on the network, that just is a further complication, just test with no firewalls, until you can see the apache2 start page from other machines, then add the complicated stuff.

the startup batch file is a script, that script does things, and you can read what it does. It's not magic, it's just some text file commands, which make the thing show on the network, maybe it turns off windows firewall, who knows, this is why I stopped developing on windows years ago, lol, apache/mysql/php run much much better on their native platform.

There's also some weirdnesses that xp can introduce, but I'm not even going to get into those since they should not prevent the initial default page from showing.
Back to top

Also, i assume the ip address you had there was a sample, and that the LAN box has a typical IP address, like 192.168.1.3 or whatever, and that you are targetting the lan request to that ip address. This is all starting to remind me forcefully of why I stopped using windows for servers and dev work, thanks, heh.... in linux/unix this stuff is all out in the open, easy, and straight ahead, in windows you have to dig in to find it all.
Back to top

Well the issue I have with the firewall portion is I would think that if the firewall was causing the problem, then it wouldn't matter whether I was running the Apache server from the command console or a service as they're still using the same configuration files. Well, that's the case with the Apache Tomcat anyway. I've never had the opportunity with Apache server to find out how it would work if it was not being ran as a service.
Back to top

You'll have to do the tests I suggested, further chat is rather pointless.

Remember, Windows XP is NOT a server OS, so making any assumptions at all about what's going on is poorly advised. Neither is Vista or Win7.

The way to solve empirical failures is not to speculate or think, but to test and verify. The first test I already suggested, as the most obvious and required, the firewall. If the firewall is on no other machine can access the server, that's pretty basic networking, so assuming or thinking there is a bad idea, you should know, ie you should be able to state categorically: I have tested this setup with windows xp firewall, and all other firewalls, turned off, and the problem a: persists b: vanishes.

It sounds to me like you need to really refresh and review your debugging and testing skills before you go any further, if you can't carry out trivially easy tests, then there's really no point in continuing this conversation, nor is there much hope in offering any further suggestion or advice.

Anyway, good luck with your efforts.
Back to top

It always comes down to a simple solution. It's actually kind of embarrassing after I figured out what I did wrong. When I uninstalled the Microsoft ISA 2006 firewall client from the Windows XP PC that I am using for a web server, I figured that would disable the firewall and put the unit in an open unprotected state, i.e firewall disabled. I didn’t know that I still needed to go into the standard Windows XP firewall client and shut it off. DAHHHHHH!!!! After banging my head against the wall a couple of times, I figured I should update this post and let you know that the problem is solved. Thank you again for taking the time to help me with this problem.
Back to top

Oh, so it was the firewall after all, that's what I suspected, thanks for confirming that.
Back to top