There are a lot of other backup scripts for Drupal on the web, but I promised somebody I'd post mine in response to this week's episode of the Geeks and God podcast. There are variations based on how the different servers are set up, but here's a basic summary of how I do it.

When I started working on what was going to be the fifth installment in this series, I realized that at the end of part two, I'd left you sitting at the console of your shiny new Ubuntu server with no instructions on how to make the jump to the later steps and get you way from that all-to-unfamiliar character interface. You could install some rudimentary X windows system and the Firefox browser on your server, but again, this series is written with a few assumptions in place.

I'm writing this with the assumption that you're working on some kind of existing network, that you have a DHCP server (possibly your home network's Internet router) handing out IP addresses, that you have an existing Windows workstation where you normally work, and that you might even have DNS tied to your DHCP server. The one that might be a stretch is the last one. You might not be able to access your server from your network by name. That's okay, you can do it all by IP address.

In the third part of this series, I left you hanging with some basic Drupal configuration left undone. This will be painfully apparent if you go to your main administration page, where you'll see the lovely pink box alerting you that your site has some problems. Fear not! We're going to take care of these problems, and then do a little more fine tuning before we need to stop and make some decisions about what we want to do with our new site.

In my last post, we finished our basic Ubuntu installation and got our web server ready for Drupal. If you're not installing Drupal on a dedicated server, you can jump into the series here and be fine, but you might have to alter a couple of directory names for this to work out for you.

I'm writing this from the assumption that I control the whole server, and so I'm using /webdocs for my web server's DocumentRoot and /drupal as a place to store all of my files. This will include both a place to sort and store my downloaded core and contributed module files, as well as a place to set up the Drupal files and temp directories.

For example, on the server that hosts this site, I have three web sites running from a single subdirectory of my home directory, each controlled by its own settings.php file, and I store all of the data and downloads in other subdirectories outside of the web root.

If you don't have the ability to store your working directories on the server, you'll have to make some adjustments. I strongly recommend having a development server somewhere. You can either set up a server on VMware, as I mentioned earlier, or you could even get apache, php and mysql running on Windows. (Drupal will run on IIS, but getting Clean URLs working is something I haven't quite mastered yet. I would be hesitant to start my first Drupal site on IIS unless I had no other choice.)

One final note to this already long introduction. You really should go read the Drupal 5 installation guide if you want to know everything you should know before installing Drupal. Having said that, let's begin.

Here is part two of my quick and not very comprehensive series on installing a Ubuntu Linux server and building a Drupal web site on it. In my previous post, I walked you through a couple of potential bumps in the Ubuntu installation process. By now you've rebooted your brand new server for the first time and you have nothing but a bunch of gibberish on your screen. Never fear! I am here to show you how to merrily ignore all of that stuff and get moving on what you really want to do: build a new web server!

Don't get me wrong. I think it's important to learn what you're doing in Linux. In fact, I'm kind of hoping that maybe you know your way around a Linux command line a little, and are taking a bigger plunge on this project. But I'm pretty sure that one of the two people I know who might actually read this are coming in cold, and that's who I'm targeting.

Call this a tutorial for the impatient if you will. If I didn't give you a link to this page personally, then you've already demonstrated your ability to use Google search. I'll give you the steps to follow, but please go research anything that's not clear.

I've decided to start a short series on installing and configuring a Drupal web site. My goal is to take you from bare metal to the point where you have a working web site that you can start exploring. I'll try to add some links to real resources along the way.

There are a lot of other (and better) articles out there on how to do this. I'm writing mostly for my own benefit, because I'll use it as a cheat sheet for future projects, and for the benefit of a couple of people I know, who have taken an interest in Drupal, Ubuntu, or both.

In this first part, I'll cover the basics of getting Ubuntu installed. In the second part, we'll see a Drupal installation and base configuration. From there, I'll cover setting up some useful Drupal modules and touch on a few other quick tips before sending you off to fend for yourself.

I just completed my first physical to virtual (p2v) migration of a Linux server. I used cpio, ssh and a rescue CD to migrate an aging server to VMware. Here's how I did it. (I'll try to leave out the steps that didn't work!)

We recently identified several servers that could be migrated to VMware Server, and the first Linux box to be moved is an old Fedora Core 2 box that runs as an instructional Oracle database server. According to the logs, it hasn't been used for student work since last May, so we may be retiring it, anyway.

I've found a number of documents on Linux p2v. The one that helped me the most was from Phil Windley's Technometria. That one told me what I'd need to do to make my new VM boot, and those instructions helped me decide how to proceed. I also relied heavily on the Understanding CPIO article from ONLamp.com.

I run Fedora Core on the Linux boxen I manage, and in most cases, they're configured for text-only operation. However, there are cases where running X is desirable, but usually remotely and generally not with all the bloat associated with a full desktop installation. (I've got nothing against Gnome or KDE; I just don't need them most of the time.) For this scenario, I generally use Xvnc and the Blackbox Window Manager.

Three instances of Apache JMeter running in a Blackbox/VNC session.