Install rsnapshot on both the remote machine and the backup server:

apt-get install rsnapshot

Save yourself a copy of the default config file if you ever need it:

cp /etc/rsnapshot.conf /etc/rsnapshot.conf.default

On the backup server I create an rsnapshot user:

groupadd -g 3500 rsnapshot
useradd -u 3500 -s /bin/false -d /home/rsnapshot -m -c "rsnapshot" -g rsnapshot rsnapshot

Then prepare the backup server to be able to automatically access the production server using ssh keys:

cd /home/rsnapshot
su -m rsnapshot

With the previous command you become the user rsnapshot on the shell. You could confirm this with:

whoami

The next few commands must be run as user rsnapshot!

Create the keys:

ssh-keygen -t rsa

Hit enter on all prompts. It is important that you do not enter a passphrase otherwise the backup will not work without human interaction, so again hit enter. In the end two files are created: /home/rsnapshot/.ssh/id_rsa and /home/rsnapshot/.ssh/id_rsa.pub.

I’m not completely sure this next step is necessary, but I’m partially working from this guide, so next I create a file /home/rsnapshot/.ssh/config with the following contents:

host yourdomainname_backup
hostname yourdomainname.example.com
user root
identityfile /backup/.ssh/id_rsa
compression yes
cipher blowfish
protocol 2

This next step may be unnecessary, but to be safe:

chmod -R go-rwx /home/rsnapshot/.ssh

Now copy over the public key you just created to your production server:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@yourdomainname.example.com

If your production server to be backed up happens to run Ubuntu, as one of mine did, then you should login to the production server and then do away with it’s silly refusal to have a password for root with:

sudo passwd root

and then you’ll have no trouble with the prior step which copies the public key of the user rsnapshot to the file /root/.ssh/authorized_keys on the production server yourdomainname.example.com.

You can confirm that this worked with:

ssh root@yourdomainname.example.com

That should have logged you in as root on your production server without requiring you to enter a password. Now, on the one hand, this is exactly what we were trying to do, but on the other hand, we don’t want to leave it like this or anyone who gets access to the rsnapshot user on your backup server could be root on your production server. Not good. So next we fix that by taking a look at /root/.ssh/authorized_keys. It should look similar to this:

ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA[...]/zkctw== rsnapshot@backupservername

Now prepend from="1.2.3.4",command="/root/validate-rsync" just before “ssh-rsa” separated only by a single space, all on a single line like so:

from="1.2.3.4",command="/root/validate-rsync" ssh-rsa AAAAB[...]/zkctw== rsnapshot@backupservername

where “1.2.3.4″ is your backup server’s numeric IP address. This change means that user rsnapshot can only login from your backup server’s IP address and can only run a single command, “validate-rsnyc”. We must now create the file /root/validate-rsync with the following content:

#!/bin/sh

case "$SSH_ORIGINAL_COMMAND" in
*\&*)
echo "Rejected"
;;
*\(*)
echo "Rejected"
;;
*\{*)
echo "Rejected"
;;
*\;*)
echo "Rejected"
;;
*\<*)
echo "Rejected"
;;
*\`*)
echo "Rejected"
;;
*\|*)
echo "Rejected"
;;
rsync\ --server*)
$SSH_ORIGINAL_COMMAND
;;
*)
echo "Rejected"
;;
esac

Special thanks to Troy Johnson for this script. Now make the script executable:

chmod u+x validate-rsync

You should now be setup on the production server and can logout and go back to your rsnapshot user on the backup server. Become root on the backup server so you can edit the rsnapshot configuration file, /etc/rsnapshot.conf which you can learn more about at this rsnapshot HOWTO. The main thing to know about this config file is that everything that looks like a space probably should be a TAB instead.

#I suggest the following changes:
snapshot_root /home/rsnapshot/.snapshots/
lockfile      /home/rsnapshot/rsnapshot.pid # user rsnapshot can't write to /var
ssh_args      -o BatchMode=yes

#Uncomment the following:
cmd_cp        /bin/cp
cmd_ssh       /usr/bin/ssh
cmd_du        /usr/bin/du
interval      monthly 3

#Choose some directories to exclude:
exclude       /home/user/JunkThatIDontWant

#And choose some directories to backup:
backup        root@yourdomainname.example.com:/home/user/ yourdomainname.example.com/
backup        root@yourdomainname.example.com:/etc yourdomainname.example.com/
backup        root@yourdomainname.example.com:/var yourdomainname.example.com/
backup        root@yourdomainname.example.com:/usr/local yourdomainname.example.com/

Now you probably put some spaces where there were supposed to be tabs, so check your config file's syntax with this test:

rsnapshot configtest

Once it comes back with "Syntax OK" you are ready to try your first hourly snapshot. Become the rsnapshot user and give it a try with:

cd /home/rsnapshot
su -m rsnapshot
rsnapshot -V hourly

This will give verbose output so you can see that something is really happening. Once you get an hourly snapshot or two to complete successfully, you should automate this with cron. As the rsnapshot user, type:

crontab -e

and choose your schedule, something like:

0 */4 * * * /usr/local/bin/rsnapshot hourly
50 2 * * * /usr/bin/rsnapshot daily
40 2 * * 6 /usr/bin/rsnapshot weekly
30 2 1 * * /usr/bin/rsnapshot monthly

which would do 6 hourly backups a day (once every 4 hours, at 0,4,8,12,16,20)
1 daily backup every day, at 2:50AM
1 weekly backup every week, at 2:40AM, on Saturdays (6th day of week)
1 monthly backup every month, at 2:30AM on the 1st day of the month.

And there you have it! You have automated remote backups of your production server using rsnapshot.

I assume you have ssh or command line access to your host. If not, you could accomplish the same thing using ftp, but you’ll have to pay attention to what directory you upload into:

1. Install Drupal 6.x
2. Download the Drupal WYSIWYG part of FCKeditor from http://drupal.org/project/fckeditor
3. Extract that in sites/all/modules (you may have to create the modules dir) with tar -zvxf fckeditor-6.x-1.4.tar.gz
4. cd to sites/all/modules/fckeditor
5. Download the FCKeditor part of FCKeditor: http://ckeditor.com/download
6. Extract that in sites/all/modules/fckeditor/fckeditor [Yes, seriously.] with tar -zvxf FCKeditor_2.6.5.tar.gz
7. Go enable the FCKeditor module in the drupal admin section, it’ll be down below all the core modules in its own section.

mdadm /dev/md0 -a /dev/sdb1

This is on a software RAID array called /dev/md0 made up of /dev/sda1 and /dev/sdb1.

apt-get install ffmpeg2theora

and then:

ffmpeg2theora vid00001.mp4

That outputs a file called vid00001.ogv and you’re done. Find further information about the fabulous ffmpeg2theora at its website.

grub
grub>device (hd0) /dev/sdb
grub>root (hd0,0)
grub>setup (hd0)
grub>quit

If you’re not familiar with encodings the visual problem one sees is that Firefox displays little black diamonds with question marks inside them for characters it doesn’t understand (I think they’re mostly tabs, spaces, and em-dashes in this case.)

With help from friends and the internet I learned about the GNU/Linux command-line tool iconv which handled this perfectly. Here’s the bash script I used that made it work on the entire directory at once:

#/bin/bash
LIST=`ls *.html`
for i in $LIST;
do iconv -f WINDOWS-1252 -t UTF8 $i -o $i.”utf8″;
mv $i.”utf8″ $i;
done

It seems that iconv requires a new name for the output file, so the above script temporarily names them *.utf and then moves them back over the original .html files. Hopefully this helps someone else.

1. You have a server running at least Debian Etch (or are otherwise able to install the wordpress .deb).

2. Your server has Apache 2, MySQL, and PHP installed.

3. You want to use a single WordPress installation to host multiple blogs across several domains.

Ok, let’s get started.

Step 1: # sudo apt-get install wordpress

Handle a few pesky permissions problems with:

# sudo chown :www-data /etc/wordpress/*
# sudo mkdir /usr/share/wordpress/wp-content/uploads
# sudo chown www-data:www-data /usr/share/wordpress/wp-content/uploads
# sudo chown -R www-data:www-data /usr/share/wordpress/wp-content/themes

Step 2: Set up Apache 2 so that exampledomain.org points to /usr/share/wordpress —Here’s one way, and it also assumes you want www.exampledomain.org to redirect to exampledomain.org. You could modify this to have it redirect to blog.exampledomain.org if you want it to go there instead.


/etc/apache2/sites-available/exampledomain.org

<VirtualHost *:80>
ServerName www.exampledomain.org
DocumentRoot /var/www/www.exampledomain.org/
<Directory /var/www/www.exampledomain.org/>
AllowOverride All
Order Deny,Allow
Allow from all
</Directory>
</VirtualHost>

<VirtualHost *:80>
ServerName exampledomain.org
DocumentRoot /var/www/exampledomain.org/
<Directory /var/www/exampledomain.org/>
AllowOverride All
Order Deny,Allow
Allow from all
</Directory>
</VirtualHost>

# sudo a2ensite exampledomain.org
# sudo /etc/init.d/apache2 reload

# sudo ln -s /usr/share/wordpress /var/www/exampledomain.org

/var/www/www.exampledomain.org/.htaccess
Redirect / http://exampledomain.org

[Go online and confirm the redirect is working—don't worry that you get a WordPress error. It's not supposed to work yet.]

# cd /usr/share/doc/wordpress/examples
# sudo sh setup-mysql -n exampleuser exampledomain.com

Note that the username "exampleuser" must be no more than 16 characters (mysql limitation).

Step 3: Do the normal web-based WordPress install (I suggest going to Options|Miscellaneous and giving each blog a unique subdirectory for its uploads otherwise they’ll all be mixed together) and then repeat step 2 for each additional domain.

You’re done! A single Debian WordPress installation is now hosting multiple blogs!