I got this week my new company notebook, a Dell E6500 with an internal UMTS card. As you know me I did at once a dual boot install on it. And the Linux in this case is Kubuntu 9.04 (Jaunty). The installation of the 64bit version (as the notebook has 4GB of RAM) went smooth. So I put an UMTS SIM card into it and went on a trip, as I thought it is easy to setup on the fly. Guess? I was wrong. Surely I got an /dev/ttyACM0 device and I was able to set the PIN but as soon as I send the ATZ command I got an “ERROR” returned.

What you will also recognize is that the UMTS LED (right to the bluetooth LED) stays dark even after sending the PIN. So we’re missing here something. The solution is AT+CFUN=1 which turns the RF Circuit Power on (and lets the LED light 😉 ). I got it running before I went home from the trip, to be exactly I’m on the trip and writing this howto.

Following is the full solution for the problem.

wvdial install: I use wvdial to get into the internet via UMTS. Install the package wvdial like this apt-get install wvdial

Power: Run wvdial on to activate the power and if you’re finished call wvdial off to save battery life.

get online: Wait some seconds after you switched the power on so the card has time to find a base station to connect to. Now type wvdial a1 (replace a1 with your provider name (it needs to the same one as in the config file). If everthing worked and you’re online you get following:
--> Carrier detected. Starting PPP immediately.
--> Starting pppd at Thu Jun 18 21:03:46 2009
--> Pid of pppd: 3993
--> Using interface ppp0
--> local IP address xxx.xxx.xxx.xxx
--> remote IP address xxx.xxx.xxx.xxx
--> primary DNS address xxx.xxx.xxx.xxx
--> secondary DNS address xxx.xxx.xxx.xxx

In my last post I’ve written a howto on installing Xen and OpenVZ on a dedicated root server at a locally well know server ISP. This post is now about the method I use to backup this server on the ISP provided FTP space. The backup solution I use provides following:

Full backup and restore of the whole server or single files

GnuPG encryption of the data on the FTP server

full and incremental backup

open source and free

simple setup and usage

The base of the backup system is duplicity, but I use ftplicity as front-end which makes the interface easier to handle in this special case. As the hardware node of the server is running under CentOS 5, this howto is centered around it, but the basic idea is the same for any distribution.

Repository: We need to add the EPEL5 repository by calling
rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/x86_64/epel-release-5-3.noarch.rpm

Info: Replace x86_64 with i386 if you’ve a 32bit system.

Packages: I did following to update and install the required packages:
yum update
yum install duplicity python-GnuPGInterface

Bug fixing: There is a small bug in the duplicity package (duplicity-0.5.06-1.el5) which leads to some unlovely error messages. You can and should correct them like this:
wget http://savannah.nongnu.org/bugs/download.php?file_id=17304
patch /usr/bin/duplicity duplicity-sys-exit.patch

If the patching worked you should get a output like this:
patching file /usr/bin/duplicity
Hunk #1 succeeded at 589 (offset 2 lines).

ftplicity install: There is currently no package for ftplicity, but as it consists basically only of one bash script that doesn’t really matter. Just use following commands
mkdir ftplicity
cd ftplicity/
wget http://surfnet.dl.sourceforge.net/sourceforge/ftplicity/ftplicity_1.4.2.1.tgz
tar xzf ftplicity_1.4.2.1.tgz
cp ftplicity_1.4.2.1/ftplicity /usr/local/sbin/

to install it.

ftplicity configuration:Everything is now installed and we only need to configure it. The shell script creates its own default config if called like this: ftplicity [profilename] create. Choose a profile name, as ftplicity allows you to use more than one profile (e.g. to backup different stuff to different ftp servers). Now change into the directory /root/.ftplicity/[profilename].
You need now to create a gpg key with gpg --gen-key – use the default options and a complicated pass-phrase. Continue with editing the file conf, by at least setting following variables:
GPG_KEY= to the ID of the key just generated
GPG_PW= to the pass-phrase you just entered
TARGET= to your backup server, use a subdirectory and not / as you may want to backup a second profile or server later and create that subdirectory
TARGET_PW= to the ftp password
SOURCE='/' # as we backup everything

Take also a look at the other parameters but you’re not required to change them. As we’re backing up the whole server it is necessary to exclude some directories. To accomplish this you need to create a file exclude in the profile directory which contains at least following lines.
/dev
/proc
/sys
/tmp
/var/cache
/var/tmp
/var/run

As we’re using the server with OpenVZ we also add following lines:
/var/spool
/vz/root
/vz/private/*/proc
/vz/private/*/sys
/vz/private/*/dev
/vz/private/*/var/cache/apt/archives
/vz/private/*/var/lib/courier/allfilters
/vz/private/*/var/lib/dcc
/vz/private/*/var/lib/apache2/fastcgi
/vz/private/*/tmp

first backup: Type ftplicity profilename backup to make your first (=full) backup. You should not get any exceptions or error message if you’ve configured every correctly.

automatic backup As you see at the first backup, ftplicity is verbosely – this is good if an error occurs but I don’t like an email every day if all worked. Therefore I’ve written the python script ftplicity.py, which parses the output of the shell script and only sends (but than the full verbose output) an email (via cron) to me if something went wrong. Copy the script to /usr/local/sbin and set the execute flag.Now you only need to edit the crontab with following command: crontab -e and place some lines like this there.
5 9 * * * /usr/local/sbin/ftplicity.py profilename backup
6 17 1 * * /usr/local/sbin/ftplicity.py profilename full && /usr/local/sbin/ftplicity.py profilename purge --force && /usr/local/sbin/ftplicity.py hetzner purge-full

That’s it – quite easy? Anyway take a look at ftplicity usage which shows you these usage examples:

I just got my new Hetzner server, an EQ4 with 8GB RAM, Core i7-920 Quad-Core, 2x750GB HD. As my old server is running OpenVZ and I’m quite happy with it I wanted to use also OpenVZ for this one. Additionally a XEN could use the Hardware virtualization this CPU provides, if I at some point need a Linux with a special kernel or a Windows for testing it would come handy. To be able to keep the hardware node running as long as possible without upgrade, I chose CentOS 5.3 as distribution.

This Howto describes how I did the setup and stops at the moment I could start installing/migrating VEs or domU instances. Surely a hardware node needs more setup like backup, firewall, … but this is out of scope for this howto.

Base Install: Boot the 64Bit rescue system from the Hetzner Robot. Enter installimage and choose Centos 5.3 64Bit minimal. If you’re using a software raid you can keep the settings with the exception of the hostname. 😉

Kernel: After the boot into the new system we need an OpenVZ and XEN kernel. To achieve this you need to enter following first:
yum install wget
cd /etc/yum.repos.d
wget http://download.openvz.org/openvz.repo
rpm --import http://download.openvz.org/RPM-GPG-Key-OpenVZ

Now you can check with yum list | grep ovzkernel which kernel to use. You get something like this:

As I’ve a 64 Bit distribution and want the option for XEN I use following command:
yum install ovzkernel-xen.x86_64

Grub: Verify and tune the grub configuration. As we will update the Kernel every once a while we want a setup which switches back to a working kernel in case of a kernel panic during boot. Compare your grub configuration with this one. The lines with comments are added/changed by me to provide the wished functionality.
default saved ### changed
timeout 5

Some Checks: Take a look at /etc/sysconfig/selinux and make sure that SELINUX=disabled is set. (This should be default with the Hetzner minimal image). Now take a look at cat /proc/mdstat to make sure your raid is rebuilt or at least at the beginning so you don’t loose to much rebuilding work. A rebuild under way looks like this:
Personalities : [raid1] [raid0] [raid6] [raid5] [raid4]
md0 : active raid1 sdb1[1] sda1[0]
4200896 blocks [2/2] [UU]

OpenVZ: Now we can install and configure the OpenVZ user space tools. With yum install vzctl.x86_64 vzquota.x86_64 you get the management tools install and chkconfig --add vz is needed so that you don’t need to type the next command after every boot by hand: /etc/init.d/vz start. Now you should be able to call vzlist which reports only Container(s) not found which is correct. The OpenVZ install is done now.

XEN: At last we install the XEN user space stuff with following command: yum install xen and add xend to the runlevels with chkconfig --add xend. After we launched it by hand this time with /etc/init.d/xend start you can use xm list to get following:
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 7647 8 r----- 202.4

We’re done. Hope this Howto helps you.

Update:

You should add following line
exclude=kernel

to the file /etc/yum.conf, which keeps the standard kernel from being updated. I don’t recommend uninstalling the standard kernel package but updating is not necessary as we won’t use it normally.

This entry is more a note to myself than a post for others. I just installed Kubuntu Jaunty on my Desktop. It was not easy. I think it is the first time in years that a Kubuntu install (Desktop CD version) was not abled to get anything than blank screen instead of the install mananger. I’ve a Radeon HD 3650 in this machine. What I did to solve this was to downloaded the alternative CD version and install it. Surely it booted also in a blank screeen but I was able to switch to the console with ALT-CRTL-F1. I installed than the openssh server which I used to follow this howto to install the ATI own drivers. After this all works again. Maybe this post helps also someone else except me.