Building a Server from Scratch, Part 3: Virtualising the Server

I know, I know… you were expecting how to configure a Web server this time. However, the set-up that I described has more than a few glitches. First of all, putting in all the software in one environment can lead to data getting polluted. Second, since I was going to do virtualisation anyway, why just keep it as a role? Why not put it to use? So, anyway…

Pre-summary

• Role: Virtualisation
• Priority: Required
• Dependencies: Basic server
• Features: A VirtualBox server environment with one virtual machine (VM) dedicated to each role. Each VM will be running CentOS 5, a free-of-cost version of Red Hat Enterprise Linux (RHEL) 5 built with the same sources.
• Extensible: Yes
• Ease of set-up: Very easy but needs a lot of patience.
• Software Set: Sun xVM VirtualBox, CentOS 5.2
• Set-up time: 3 hours

A little explaining

Let me explain what we are going to do.

Virtualisation is all about packing more into one. Basically, the kind of virtualisation we are going to do here allows us to install more than one operating system on one computer and then run them simultaneously. For that, we need a hypervisor—a software that manages this virtualisation. Our hypervisor of choice here is the Sun xVM VirtualBox.

Beware! Most distros pack in VirtualBox OSE. The OSE here stands for Open Source Edition. VirtualBox has only been partially open sourced. Some of the advanced features have not been open sourced yet and are not available in this OSE. One of these features is VRDP support, which we need for remote access to our machines. So, we have to use the free (as in free beer) but closed source version of VirtualBox.

Some of you may ask, if we have to use closed source, why not go for VMWare Server? It’s free and it’s made for remote access and administration. We are going to use VirtualBox because VirtualBox is faster and more stable on Linux. Additionally, part of VirtualBox is open source. More specifically, the core engine is open source; only the VRDP bit is closed source.

This brings us to remote access and administration. Unlike VMWare Server, VirtualBox is not specifically meant for servers. It’s a general hypervisor. So it has nothing like VMWare’s Web Interface. On the other hand, it has a very powerful command line interface called VBoxManage, which actually exposes more features than the VirtualBox GUI. So you can SSH into your server from remote terminals and configure virtual machines. And since SSH allows you to run X applications as well, you can use the GUI to configure VMs too.

What about viewing machines? Well, that too is simple. I’ve been ranting all along about VRDP. VRDP (VirtualBox Remote Desktop Protocol) is VirtualBox’s implementation of the Microsoft Remote Desktop Protocol implemented after it had been opened up via MSDN. This feature allows you to use a RDP client like Microsoft Remote Desktop Connection (bundled with Windows) or a desktop on Linux to see a VM’s Desktop.

Now about the guest operating systems…everyone acquainted with servers should know all about RHEL, right? Well, the fact of the matter is, it’s extremely expensive. The CentOS Project (Community Enterprise Operating System) makes use of the free RHEL sources, replaces the RHEL branding with CentOS branding and thus produces completely free binaries, which are a 100 per cent binary compatible with the corresponding RHEL version, thus creating a free RHEL clone.

The CentOS project even publishes the security updates. So, users of CentOS are technically using RHEL, just re-branded to escape licensing issues. By the way, RHEL and CentOS are completely separate entities and are not affiliated to each other in any way.

So let’s get started, shall we?

Preparations for the launch

We need to prepare for our mission. First, there are some prerequisites that you have to set up yourself. Make sure you have a Linux or Windows (preferable) client attached to your server, which can browse the Internet. This is to make sure that the client can communicate with the server, since all Internet bound traffic will have to be NATed by the server. Ping the server if you need more reassurance. Traceroute it if you need still more. I asked for a Windows client to be able to demonstrate the interoperability of the solution, but if you use Linux, it’s just as well. I’ll still give you instructions, don’t worry.

Then, since we were going in a different path earlier and have changed tracks now, you need to change the partitioning scheme. Create a single LVM volume out of all the unused space of your HDD and mount it under /VMSpace. That should do.

Now, let’s do some work.

Installing and configuring VirtualBox CSE

Sadly, CSE stands for closed source edition. But, there’s nothing we can do about it. First of all, we need to remove VirtualBox OSE if it’s there. You can use Synaptic to do it.

Then, run the following command to clean up any stale dependencies:

$ sudo apt-get autoremove

Now point your browser to www.virtualbox.org/wiki/Linux_Downloads and download the VirtualBox package for Ubuntu 8.10 (remember this is the host OS we’ve installed on your server). Once done, install it:

$ sudo dpkg -i virtualbox-2.1_2.1.4-42893_Ubuntu_intrepid_i386.deb

After your installation, issue the following command to resolve all dependencies:

$ sudo apt-get install -f

By the way, here’s one tidbit: the closed source VirtualBox is free for personal use. This may scare you because enterprise use isn’t exactly personal, is it? However, take a look at the VirtualBox Licensing FAQ Point 6, and all your fears will be put to rest. Basically, this is what it says:

“Personal use is when you install the product on one or more PCs yourself and you make use of it (or even your friend, sister and grandmother). It doesn’t matter whether you just use it for fun or run your multi-million Euro business with it. Also, if you install it on your work PC at some large company, this is still personal use. However, if you are an administrator and want to deploy it to the 500 desktops in your company, this would no longer qualify as personal use. Well, you could ask each of your 500 employees to install VirtualBox but don’t you think we deserve some money in this case? We’d even assist you with any issue you might have.”

Now, add the root user to the “vboxusers” group:

$ sudo usermod -G vboxusers root

Since we are using VirtualBox 2.1, we don’t even need to create a network bridge. All we do is plug in our VMs to eth1 (that’s our client interface), and yippee, we are networked. eth1 has DHCP, so the virtual-servers are automatically configured. A word of caution: since we have a DNS system in our network, all our VMs should have good host names. I don’t know what you named your domain, but suppose it’s officenetwork.local, give your database server the name db-server and the mail server the name mail. So we can access them as db-server.officenetwork.local or mail.officenetwork.local.

Note that our architecture does not allow for accessing any of our VMs from outside (more precisely, eth0) our office. So a field officer trying to access his mail, will need to be able to VPN into our server. I’ll set this up at a later stage.

Setting up our first VM: The Web server

First, some disappointing news… We will not set up our Web server now but just prepare it.

VirtualBox 2.1 can run 64-bit guests on a 32-bit host and vice-versa. So, since you have a Q6600 processor, you can seriously consider a 64-bit version of CentOS. And your processor supports hardware assisted virtualisation, so it’s all the better.

First of all, head to centos.org and get yourself all the 5 CDs or the DVD (torrent download only) of the latest version of CentOS. As of now, CentOS 5.3 (corresponding to the RHEL 5.3 release) has not been released, so you’ll have to settle for 5.2. However, CentOS 5.3 may come out any day now. You can upgrade as per your needs, easily.

I assume that you have downloaded the CentOS 5.2 x86_64 DVD and have saved it in /VMSpace/ISOStore.

So open up a terminal and type in the following:

$ sudo mkdir /VMSpace/VDIStore
$ sudo VBoxManage createvm -name WebServer -register
$ sudo VBoxManage createvdi -filename /VMSpace/VDIstore/WebServer.vdi -size 8192 -register
$ sudo VBoxManage modifyvm WebServer -hda /VMSpace/VDIStore/WebServer.vdi
$ sudo VBoxManage modifyvm WebServer -dvd /VMSpace/ISOStore/CentOS-5.2-x86_64-bin-DVD.iso
$ sudo VBoxManage modifyvm WebServer -memory 512M
$ sudo VBoxManage modifyvm WebServer -acpi on -ioapic on -vrdp on -vrdpport 3390
$ sudo VBoxManage modifyvm WebServer -ostype RedHat_64 # change if using 32bit
$ sudo VBoxManage modifyvm WebServer -pae on -hwvirtex on -accelerate3d on

Now, to configure some sophisticated networking. This is possible from the VBoxManage command line as well, but to better understand the procedure, let’s do this from the GUI.

Launch the GUI, select Web Server from the VM list and then click on the networking hyperlink on the right. In the pop-up box, enable Adapter 1. Then, select its type to be “Intel Pro/1000 T Server (82543GC)”. Choose ‘Host Interface’ in the Attached To field. Generate a random MAC address (do not change this in the future) and finally attach the host interface to eth1 (our internal network).

So NASA has just given us the Go-code for the launch! However, you soon abort the launch after noticing a fatal error—it’s impossible to access the Web server from outside (eth0). Well, relax! What are reverse proxies for, anyway? By the way, give nginx a miss; we will set up a different configuration another day.

Fine-tune any settings as you see fit (if you need audio, you can set it to AC’97) and then drop down to the command line. Go to your Windows machine and start up the Microsoft Remote Desktop Connection. On the address field, use the server FQDN (server.officenetwork.local, for example) and append a “:3390” to it. Expand the options button, click on the experience tab and select “LAN (10 Mbps or higher)”. Don’t connect as yet.

Type in the following command at the server console:

$ sudo VBoxManage startvm WebServer -type vrdp

You should get a pop-up window running VBoxHeadless with the VM. Immediately, connect the RDC on the Windows machine. Voila!! You have the Remote Access part of VirtualBox running as expected. Don’t boot up now, abort the GRUB countdown and issue the following:

$ sudo VBoxManage stopvm WebServer

Launch up the GUI, and continue installing CentOS 5.2. Why I told you not to set-up remotely is because X behaves radically if you don’t have the VirtualBox Guest Additions installed.

At this point don’t set up any server tools at all—just set up a basic X desktop environment, preferably GNOME (because it is lighter). Just have one partition (and a swap-space), no LVM (the KiSS strategy). Give it a descriptive hostname (‘web’ would do fine) and set it up to configure its network over DHCP. Oh, and disable SELinux and the firewall in the text-mode part that comes after Anaconda’s finished.

Install all the VirtualBox Guest Additions now. RDP into the machine (no problem if the GUI is running as well; anyone sitting at the GUI will think that a ghost has possessed the VM) and see if it works well. It should.

A SSH server for remote administration

Since VirtualBox does not have a dedicated remote administration tool, we will have to SSH into the machine and use VBoxManage. So, we need to set up an SSH server in our server.

First install the OpenSSH server:

$ sudo apt-get install openssh-server

Now open the /etc/ssh/sshd_config file and make a few changes: Set the port to something non-standard, such as 99; set RSAAuthentication to Yes; set Protocol to 2; PasswordAuthentication to NO (we will set up certification-based authentication); and PermitRootLogin to Yes.

Now we need to set up Public Key authentication. SSH keys are machine-specific, not user specific. So you need to set up one key on each machine that you want to access the server from. From a terminal on a Linux client, type:

$ sudo mkdir ~/.ssh && chmod 700 ~/.ssh
$ sudo ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

Supply a really big passphrase. It can include anything. Just remember this 30 character (optimal) long sentence.

Then secure the files:

$ sudo chmod go-w ~/
$ sudo chmod 700 ~/.ssh
$ sudo chmod go-rwx ~/.ssh/*

You subsequently need to change two lines in the client /etc/ssh/ssh_config file:

• Set IdentityFile to ~/.ssh/id_rsa
• Set Protocol to 2

Repeat this for every Linux client.

In your clients, there will be a ~/.ssh/id_rsa.pub file. This is the public key file. Copy these files, one by one, to your server and append them to the ~/.ssh/authorized_keys file (use the cat command with the >> directive).

Change the server configuration a bit; in the sshd_config file set:

• Protocol to 2
• PubKeyAuthentication to YES
• AuthorizedKeysFile to .ssh/authorized_keys
• PasswordAuthentication to no
• ChallengeResponseAuthentication to no
• UsePAM to no

Now do a /etc/init.d/ssh restart and you should have a fully working SSH environment. Try to log in, with the “PreferredAuthentications=publickey” flag to ssh. You should have it.

For more, consult sial.org/howto/openssh/publickey-auth.

Appendix A: RDP client on Linux

The RDP client on Linux is an X application known as rdesktop. To install it, use:

$ sudo apt-get install rdesktop

…or, on your CentOS VMs:

# yum install rdesktop

You can connect with one simple command:

$ rdesktop server.officenetwork.local:3390 # adjust the hostname and port

For more information, see the man page.

Appendix B: SSHing from Windows

You use a free program called PuTTY for Telnet and SSH on Windows. PuTTY can be downloaded from tartarus.org/~simon/putty-snapshots/x86/putty-installer.exe.

Install this snapshot. There are a few guides to using PuTTY on the Internet. Use the following two websites to work out how to configure Public Key authentication on PuTTY.

• www.ualberta.ca/CNS/RESEARCH/LinuxClusters/pka-putty.html
• Search Enterprise Llinux at Techtarget

Use a 4096 bit SSH2-RSA key pair.

Some notes

1. You must specify a separate VRDP port for every VM. You cannot remote access VMs by name. They must be accessed by port. So maintain a list of names to port number assignments, somewhere.
2. You can use SSH to launch an X application remotely also (you need to use Linux here). Use this link.
3. This one is for creating purely random passphrases and passwords by rolling a dice a number of times: world.std.com/~reinhold/diceware.html. This is highly recommended for security.