Difference between revisions of "Ubuntu Virtual Servers"

Revision as of 22:18, 6 February 2010

The idea is to use a URL (such as www.exampledomain.org or vistaserver1.exampledomain.org) for your site (that is registered on an Internet DNS (Domain Name Server)) to access the VistA server, instead of using the actual IP address of the server. Most configurations involve a LAN, and usually the registered URL will point not to the (LAN) IP address of the VistA server itself (within the LAN), but to the (WAN, or Internet) IP address of the router. Therefore, communications arriving at the router must be forwarded from the router (connected to the Internet) to the server (within the LAN) properly.

NAT

Consumer-grade routers generally use NAT port-forwarding to send traffic that arrives at the router to a specific server within the LAN (such as the one hosting the VistA server). Certain types of traffic can be designated as flowing over "ports" and (in the simplest scenario) a specific server can be designated as the destination on the LAN to which all the traffic over a specific port will be sent.

Your router's configuration utility (often accessible from a web browser) allows you to configure "NAT port forwarding" so that traffic arriving at a certain port (such as port 22) will be "forwarded" to a specific server on the LAN (which will have its own unique IP address within the LAN).

With Astronaut, all communications are sent through a secure SSH tunnel. By convention, SSH communications are usually sent on port 22 (but that can be changed). If you only have one SSH server on your LAN, using port 22 will be fine. However, if there are more than one SSH servers on your LAN, or if you want a modicum of greater security, then a different port can be used for SSH.)

Make sure the firewall (if any) on the Ubuntu Server OS (in which the VistA server is installed) does not block port 22 (or whichever port you have decided to use for SSH traffic)!

Using virtual hosts for the Ubuntu server

Most large networks will have more than one server listening for SSH connections. In general, I recommend merely changing the SSH port number for the VistA server and forwarding that port to the VistA server. Then the configuration is simple. The URL remains the same URL that is used for the entire LAN.

However, you can also use a unique URL exclusively for your VistA Server. It would still use the (WAN) IP address of your LAN (/router) but would advertise itself as waiting specifically for traffic sent to that URL.

For example, let's say that your network has a registered domain name (URL) on the Internet of www.exampledomain.org. Using the first method, you could merely assign port 22144 to be the SSH port for the VistA server on the network and have the router forward port 22144 to the VistA server (whose OpenSSH server has presumably been configured to be listening on that port).

Alternatively, the VistA server could have its own registered URL on the Internet, such as vistaserver1.exampledomain.org. The SSH port could remain at port 22. Even if there are other SSH servers on the network using port 22, the router will shop around for the one advertising itself (through a "virtual host" file) as vistaserver1.exampledomain.org.

Edit the Ubuntu Server Apache2 virtual hosts file

• Copy and edit a configuration file in the Apache2 sites-available folder.

cd /etc/apache2/sites-available
sudo cp default vistaserver1
sudo kate vistaserver1

• Edit the virtual host file so that it looks like:

<VirtualHost *:22>
ServerAdmin webmaster@worldvista.exampledomain.org
DocumentRoot /opt/worldvista/EHR
ServerName vistaserver1.exampledomain.org
ServerAlias www.vistaserver1.exampledomain.org vistaserver1.exampledomain.org
</VirtualHost>

where vistaserver1.exampledomain.org is an example URL for your VistA server (use your own, of course)

• Restart Apache2:

sudo /etc/init.d/apache2 restart

• Troubleshooting

• Make sure your router forwards port 22 to the (static) IP address (on your LAN) at which the computer (or virtual machine) hosting the VistA server resides during testing. If this works then try turning off the port forwarding to see if the virtual host method is functioning.