As the title implies (I hope) this post is a quick guide on how to set up a database server in a virtual machine with the aid of VMWare Server. The nice thing about Server is that it runs as a service, so our virtual server can continue running even after we shut down the console. In this example, I will use FreeBSD though you can use anything you want from Linux distro du jour, to OpenBSD, to Solaris, or even to Windows. On top of this fine OS, you will need to run some database system. I can't make an example out of nothing, so I chose PostgreSQL. If you have never heard of it, it is, featurewise, the most advanced OSS RDBMS.
What is the motivation behind this little excercise? Well, using VMWare Server in this manner can help with testing so that you can run your apps against a server and get a little closer to real-life. You can also use it to run web apps that you may want to use personally (like a personal bug tracker), but don't want the world to see. Finally, it is an opportunity to try something new if you haven't done it before. So, let's get to it, then!
The first thing you will need to do, if you haven't done it already, is install VMWare Server. It is a free download, though it will need to register (again, free) for a serial number. So, if applicable, saunter over to http://www.vmware.com/ and let them be your guide.
Done? Okay. Next, we will need to spawn off a new virtual machine. Log into VMWare and, on the home tab, select "Create New Virtual Machine". While your mileage may vary, I chose the following options:
OS: Other -> FreeBSD
RAM: 160 MB
Hard Drive: 8GB, Not allocated, split into 2GB (mandated by the fact that I put the VM on a FAT32 external hard drive)
Network Card: NAT (this will change later).
and defaults for the rest. The VM we just created is, obviously, completely blank. So, go to http://www.freebsd.org/ and download the disc 1 ISO (we shall not need disc 2 for this tutorial).
Once that is finished, go back to the VMWare Server Console. Select the FreeBSD machine, then click VM->Settings. Set the CD drive to point to the ISO you just downloaded. Click OK and power up the virtual machine. The machine should boot straight up to the FreeBSD installer.
From here, do a standard FreeBSD install. I will leave the explanation of that to the FreeBSD project's quite good documentation (or, perhaps at a later date, a different tutorial). As an FYI, due to the limited use towards this VM will be put, I elected not to install ports. While useful in general, it is hard drive space wasted here. If you kept it simple, the install should finish pretty quickly. When the prompt shows up asking you if wish to reboot, switch out of the machine (Ctrl+Alt) and switch the CD back to the physical drive so that the VM will not boot to the installer again. Then choose yes. The system will reboot and bring you to a simple login prompt. Login as root with no password. Now the fun begins.
The software that we will want on this box is simple: SSH and Postgres. Postgres was the whole point in doing this and having SSH for "remote" administration is both cool and useful. While, in eventuality, we want to make this a private server, we will need to download the software off the web. Keep the networking card set to NAT (or whatever you use to connect directly to the web). Once logged in, you can determine what device equates to your "card" by looking at /var/run/dmesg.boot In the case of my VM (and therefore, probably yours as well), the card was lnc0 and to get an IP run:
# dhclient /dev/lnc0
In FreeBSD, there are two "software worlds": ports and packages. Ports is similar to Gentoo's portage (in fact, it is the progenitor of it) in that it is an automated build system. Packages is more similar to a basic Debian or RPM system: it downloads compressed binaries and installs them on the system. For simplicity and speed, I will use packages here. The basic way to add packages is:
# pkg_add package.tbz
In order for this to work, package.tbz must exist in the current path. Fortunately, for some packages, there is the nifty little short cut
# pkg_add -r package
Which will both download and install the specified package. Like I said, this doesn't work, out of the box, for everything. So, let's just use it to get what we need to do the rest. Wget is a cool utility that runs on *NIX systems. It can be used to download files from the command line. So, grab it as above:
# pkg_add -r wget
This will download and install wget in /usr/local/bin. Add this to your path by adding the following to your .cshrc:
set PATH=${PATH}":/usr/local/bin"
Then run:
source .cshrc
Now we can use wget in all its glory. Go to FreeBSD's website and go to ports. Search for postgresql. A quick look at the latest version tells us that, in addition to postgresql-server, we will also need gettext, gmake, libiconv, postgresql-client. Fortunately, libiconv and gettext were installed with wget. So, look at the URL for the package and, for each of the remaining, run:
# wget URL
When done, you should have TBZ's for all of the packages you need. Install gmake, then postgresql-client, and finally postgresql-server.
Almost home free, we just need to do some more configuration on both the client side and in VMWare to finish up. First we need to initialize Postgres's various settings. We do this with the following command:
# /usr/local/etc/rc.d/postgresql initdb
Then we start the server itself:
# /usr/local/etc/rc.d/postgresql start
We will want Postgres to start up whenever we start the machine, so, using good or not so good old vi add the following line to /etc/rc.conf:
postgresql_enable="YES"
We will also need to create a database and db users. To create a DB nice and quick, log in as pgsql (a user installed by Postgres) and run
# createdb xyz
and voila! you have a database you can log in to.
Test everything to make sure it is working right, but at this point you should have FreeBSD running PostgreSQL just fine. The next step is to put this on a private subnet and make sure that we can access it from our host system (note: to help test, installing the PostgreSQL client on the host is recommended).
Now for the host-only part. Go to VM->Removable Devices->Ethernet Card 1->Edit and change the setting from NAT to Host Only. Then return to the guest machine and rerun dhclient. If successful, the VM will have acquired an IP on the private subnet. In the prompt, enter this command:
# ifconfig
Your card should be shown on the list with a fresh IP. Next, we need to make sure that PostgreSQL will actually listen on the port. First, edit the file /usr/local/pgsql/data/postgresql.conf. Set the following lines accordingly:
listen_addresses = '*'
port = 5432
This tells PostgreSQL to listen on all addresses (note that this does not have to be so, it just makes life easier in this scenario) on port 5432 (which is the client's default). Next, edit the file /usr/local/pgsql/data/pg_hba.conf (HBA = Host Based Authentication). This file acts as Postgres's private firewall (kind of). The rules in this file are evaluated to determine whether a given incoming connection will be permitted. I added this line to mine:
host all all 0.0.0.0 0.0.0.0 password
host refers to any SSL or non SSL port, the second field is the databases to be allowed (which can be set to a delimited list), the users that will be allowed (which again, can be specified) the IP address and mask (setting to 0.0.0.0 allows anything; think of a zero in any given portion of the address as a wildcard), and finally the type of authentication (password sets it to the good old fashioned password-based authentication; PostgreSQL has many options). Finally, go ahead and restart the PostgreSQL server with this command:
# /usr/local/etc/rc.d/postgresql restart
That's it! Fire up a client on the host's side and run it, specifying the IP address of the VM.
A few parting notes. I intentionally set security quite lax. Why? This is a virtual machine, not a real one, first, and secondly the only permitted connections will be off the private host machine. Be much more conscientious if this is for something remotely related to production! Secondly, while this article goes into detail only on the installation of PostgreSQL, the same lessons and principles can be applied to just about anything else.
References: