SUSE 9.3

From Kolab Wiki

Kolab2 Server on SUSE 9.3

SuSE 9.3 sports a new feature called Xen, we will use to isolate Kolab from the host system and to improve security and ease of backup.

Preparations

Xen is shipped with SuSE, so you only have to install it via YaST (Selection Xen), as it does not get installed by default.

Xen is a VM monitor based on a microkernel (don't say Hurd, guys ;-), so it has to be started before Linux. The neccessary images are provided by the Xen RPMs, so we only have to create a correct boot configuration.

Add the following section to your /boot/grub/menu.lst (if you have more or less than 1.5GB of ram, adjust the number accordingly to (RAM minus 64MB for Xen)).

  title Xen
     kernel (hd0,0)/boot/xen.gz dom0_mem=1440000
     module (hd0,0)/boot/vmlinuz-xen root=/dev/hda1 selinux=0 noresume showopts 3
     module (hd0,0)/boot/initrd-xen

The boot process may look a little bit chaotic and lots of errors may appear, but everything should work. Please follow the advice to move your /lib/tls and /usr/lib/tls to /lib/tls.disabled and /usr/lib/tls.disabled, Xen will be awkwardly slow otherwise (but still work).

We need a root partition for the virtual machine. If you have a spare partition, you can use it, for this example we will use an ordinary file. Please not that all of the following steps need to be made as root, so please be extra careful!

• To store all of Xens files in one place we create /var/xen with root:root and 700.
• Each VM needs its own config file. It stores name, memory size and other parameters. We only need to change some of the standard values, so our kolab.conf is rather short:

  kernel = "/boot/vmlinuz-xen"
  memory = 256
  name = "Kolab"
  disk = [ 'file:/var/xen/kolab,hda1,w' ]
  # this would use a complete partition for kolab (be sure not to mess up the partitions!):
  # disk = [ 'phy:/dev/hdb2,hda1,w' ]
  root = "/dev/hda1"
  extra = "3"

This gives the Kolab VM 256MB ram (128MB would be enough for Kolab, but since we will build from source, the more the better. The size can be reduced later on.) and a writeable partition on hda1 which is kept in /var/xen/kolab on the host. Please note that the kernel image's name is (as in menu.lst) vmlinuz-xen.

• Now we create the VM image file. The main question is size. To be able to back it up easily on DVD we limit it to 8.5GB.

  dd if=dev/zero of=/var/xen/kolab bs=4375K count=2048

• Which filesystem to choose is a good fish for flamewars, in this tutorial we will use the old and trustworthy ext2 ;-)

  mkfs.ext2 /var/xen/kolab

• The VM needs a complete SuSE installation which is most easily created with YaST. So mount the image, start YAST2 and select Install into dir for Xen (you will need the SuSE install DVD 1 for this).

  mount -o loop /var/xen/kolab /mnt
  /sbin/yast2 [select minimal base system + kernel-development, no X]

• To be able to boot the new VM, some final touches have to be applied.

  chroot /mnt
  touch /etc/fstab
  mv /lib/tls /lib/tls.disabled
  mv /usr/lib/tls /usr/lib/tls.disabled
  passwd root [enter new passwort for root]
  groupadd kolab
  useradd -m -g kolab -d /kolab kolab
  mkdir /kolab/obmtool
  exit

• Next step is to create the backup script /var/xen/kolab-backup. Don't forget to set it 700.

  #!/bin/sh
  growisofs -dvd-compat -Z /dev/cd/by-id/[NAME_OF_YOUR_DVD_WRITER] -rock /var/xen/kolab /var/xen/kolab.conf
  eject /dev/cd/by-id/[NAME_OF_YOUR_DVD_WRITER]

Installing Kolab

First, download the Kolab sources from http://www.kolab.org/mirrors.html and put them into /mnt/kolab/obmtool.

The ram needed for the VM has to be subtracted from the host (again adjust the numbers to your system).

  xm balloon 0 1100

Ok, now we are ready for action. Tell Xen to start a new VM and attach to its boot tty:

  umount /mnt
  sync
  xm create /var/xen/kolab.conf -c

Loads of messages (and lots of errors and warnings) should follow. If everything works well, the VM should go to runlevel 3 and wait for login. First, we need to configure the network so login as root. Replace the IPs in parantheses with your network data (if not using dhcp).

  ifconfig eth0 up
  ifconfig eth0 inet (10.114.1.1) netmask (255.0.0.0) broadcast (10.255.255.255)
  route add default gw (10.113.1.1)

Ping some hosts in your net and try to ssh to them and back into the vm. If everything works, we can go on.

Ssh to your host (or switch to another tty) and do an xm list as root. The result should look like this:

  Name              Id  Mem(MB)  CPU  State  Time(s)  Console
  Domain-0           0     1100    0  r----   1670.2
  Kolab              1      255    0  -----      8.4    9601

Now we will finally install Kolab.

  cd /kolab/obmtool
  chmod u+x obmtool
  ./obmtool kolab

This will take a some time, so get a fresh pack of coffee.

After gcc and rpm did their job, Kolab has to be configured for its first run. Conflicting and unneeded services have to be stopped before continuing.

  rcpostfix stop
  insserv -r /etc/init.d/postfix
  insserv -r /etc/init.d/powersaved
  insserv -r /etc/init.d/xend
  ../etc/kolab/kolab_bootstrap -b

Enter the neccessary config data and as last step, Kolab will be started.

To make root's life easier, it's adviseable to put the following in /root/.profile

  alias kpm="/kolab/bin/openpkg rpm"
  eval `/kolab/bin/openpkg rc --eval all env`

To let spamassasin learn from your mails, create two cronjobs (make sure to use the kolab dcron):

  /kolab/bin/sa-learn --spam /kolab/var/imapd/spool/domain/[YOUR DOMAIN NAME]/shared^spam/[1-9]*
  /kolab/bin/sa-learn --ham /kolab/var/imapd/spool/domain/[YOUR DOMAIN NAME]/shared^ham/[1-9]*

The last step is to make sure, Kolab gets started when the VM boots. Create the following script as /etc/init.d/kolab:

  #!/bin/sh
  ### BEGIN INIT INFO
  # Provides:          kolab postfix sendmail
  # Required-Start:    $local_fs $network $named $time
  # Should-Start:
  # Required-Stop:
  # Should-Stop:
  # Default-Start:     3
  # Default-Stop:      0 1 2 6
  # Short-Description: Kolab 2 server according to kroupware contract
  # Description:       Start Kolab to allow your server to provide full groupware services.
  ### END INIT INFO
  KOLAB_BIN=/kolab/bin/openpkg
  . /etc/rc.status
  rc_reset
  case "$1" in
    start)
        echo -n "Kolab startup"
        exec /kolab/bin/openpkg rc all start
        rc_status -v
        ;;
    stop)
        echo -n "Kolab shutdown"
        exec /kolab/bin/openpkg rc all stop
        rc_status -v
        ;;
    restart)
        $0 stop
        $0 start
        rc_status
        ;;
    *)
        echo "Usage: $0 {start|stop|restart}"
        exit 1
        ;;
  esac
  rc_exit

Finally create the neccessary links:

  ln -s /etc/init.d/kolab /usr/sbin/rckolab
  insserv -d /etc/init.d/kolab

Via https://10.114.1.1/admin/ it should now be possible to reach Kolab. To make sure, everything is ok, shutdown the Kolab VM (via halt, when the VM is halted, Xen removes it automaticly) and recreate it via xm create /var/xen/kolab.conf. If it starts up, you can check this with your browser again.

Now shut it down again and make a first backup of this virgin installation. If something screws it up you can at least get back and don't have to compile and install everything again. If you want you can now reduce the VMs memory slice to 128MB which should be enough to run Kolab under normal circumstances, but if you can afford it, give it the full bottle, since every running instance of imapd needs approximately 1MB and >150 simultaneous users are quickly to achieve.

That's all folks. Have a lot of fun!