Accessing a web site on a VM

Question

I am trying to use a VM to allow me and some other people in the company to test-drive changes to a Magento store. The VM is out of my control (mostly) and is hosted on a Windows Server box on our intranet. I don't know the version details or the actual VM used, but I can probably get this info if needed. I created an Ubuntu VM, installed Magento (v1.8). I backed up from my web store and restored to this VM. It all works (good enough for what I'm doing) if I stay within the VM.

The problem is that I cannot access the store hosted on the VM from outside the VM.

The location /var/www contains the default apache index.html. The store is located at .../var/www/magento

If I just point a browser (from outside the VM) to the IP address of the VM I get apache's default index.html. If I look into the apache access.log I see the normal messages you would expect to see. Great! If I point the browser to "/magento" I get the VM hosts' IIS default web page! The apache access log shows that it returned some redirection (301, 302) error codes (I am not very familiar with this).

Oh, and I did try moving apache's DocumentRoot to /var/www/magento and got a host of other problems, so I put it back.

If this is a problem with the VM host, can you give me pointers so I can get the proper people involved? What am I doing wrong?

apache2ctl -S output (server names masked):

VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:80                   is a NameVirtualHost
         default server example.com (/etc/apache2/sites-enabled/000-default:1)
         port 80 namevhost example.com (/etc/apache2/sites-enabled/000-default:1)

Output of cat /proc/version:

Linux version 3.2.0-77-generic (buildd@toyol) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #112-Ubuntu SMP Tue Feb 10 15:22:48 UTC 2015

Answer 1

I do this all the time for work successfully on different OS / VM / Server combinations.

There doesn't seem to be anything wrong with your Apache itself so ignore the Apache config for now. You need to test the entire network path and think about how a request will travel across the network from your coworkers' computer to your Apache process. Generally, the request will go:

Coworker -> Corporate Intranet -> Your Host OS -> VM Software -> VM Guest OS -> Apache

Subdividing the network topology is the first step in solving your problem because you have to find where a request is getting blocked. Here are some instructions for doing this:

1. Starting w/ the corporate intranet your Host computer sits on, make sure your coworkers can physically access your machine at your intranet IP. Find your ip address using ipconfig /all (windows) or ifconfig (linux). From another computer, use the ping tool to see if your computer is reachable. Do not proceed to step 2 until you figure out how to reach your computer from another via ping.

2. I understand you can reach http://[guest-ip-address], but can you access your VM website from http://127.0.0.1? If you can't, see Step 3 to configure the VM software that runs the VM. Otherwise, continue to Step 4.

3. VM software manages a virtual network layer between Host OS and Guest OS. It will likely have a NAT port forwarding system that can translate TCP traffic between Host port 80 and Guest port 80. However, port 80 is often protected by supervisor privilege at the Host OS level. This makes it a bit tricky to tell the VM software to bind port 80, so I recommend using port 8080 instead because it is unprotected. Setup NAT Port Forwarding between Host port 8080 and Guest port 80. Verify you can reach your web site @ http://127.0.0.1:8080. You maybe be tempted to set Apache to use port 8080, but that is not necessary. The VM software running your Guest OS can translate Host port 8080 to Guest port 80. Play with VM network configuration until you get http://127.0.0.1:8080.

4. Verify you can hit your web server from your Host OS @ http://[your-host-ip]:8080. If you can't, check to see if you have a firewall running on your OS. Start by disabling it completely temporarily, and test again. If you still can't hit the web site, go back to Step 3. If you can, re-enable the firewall but be sure to give your VM software an exclusion, or open port 8080.

5. Verify you can hit your web server from your the site from another computer on your coporate network @ http://[your-host-ip]:8080. If you can't, there may be a corporate firewall between you and your coworkers. Bummer. It could also be your OS firewall, do Step 4 again.

By the end of this, your coworkers should be able to reach the site running on your VM.

Answer 2

Well I found out part of the answer.

It's not a problem with networking. I used a packet sniffer to find out that the redirect issued from apache contains the address "localhost/magento", so my web browser dutifully queried my own Windows machine which returned the IIS error page, not the VM's Host's IIS. One mystery solved.

Following the lead of @RVT I used telnet and netcat and was able to GET individual files from the site.

I then re-installed a fresh copy of Magento and noticed that the default location that Magento installs to is the folder /var/www/magento. For other reasons I remember that I installed the original to /var/www. So there was some mis-match between what magento wanted for the root folder and what I installed it to. The re-install (to .../magento) works perfectly.

The real answer probably has to do with changes to Magento's System->General->Web->Unsecure Base URL settings, and also maybe the System->General->Web->Url Option settings. For completeness when I find out I will update this answer.

Answer 3

Since I can't (yet) comment to ask more illuminating questions, I'll have to post this as an answer...

First off, make sure you're VM has a bridged connection... in short, its own IP address on your local network segment. From your description, it sounds as-if it's either behind a shared or proxied connection, and your VM server may be serving up its own IIS service.

Additionally, it'd be useful to see the logfiles from the VM's apache server... the 3xx messages are important (ie. it basically means that the VM is sending your traffic elsewhere - could it be that it's redirecting back to the VM server, itself?).

Lastly, you might try coming in from both the VM and from an external host... you can telnet in to port 80... and issue commands similar to:

GET /magento HTTP/1.0
Hostname: yourhost.domain.com
\r\n

Note that you should translate yourhost.domain.com in to the name of the server, and use a double linefeed/carriage return following the hostname line (ie. the \r\n). The most important part of the return message should follow that request (ie. the Apache headers). That should be pretty illuminating as to what the server is actually doing, here.