msgbartop
MAC OS X, Linux, Windows and other IT Tips and Tricks
msgbarbottom

30 Dec 16 pygrub: Unable to find partition containing kernel

Introduction:
Lately after I upgraded many packages in a Xen 4.4 DOMU VM the pygrub could not boot the VM any more.
During the security update, the installed grub2(grup-pc), which never created any problems before with pygrub, got updated and suddenly it did create problems to boot the VM. Here is the error message I got when trying to boot it:
Parsing config from /etc/xen/VM.cfg
libxl: error: libxl_bootloader.c:628:bootloader_finished: bootloader failed - consult logfile /var/log/xen/bootloader.32.log
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: bootloader [-1] exited with error status 1
libxl: error: libxl_create.c:1024:domcreate_rebuild_done: cannot (re-)build domain: -3
libxl: error: libxl_dom.c:35:libxl__domain_type: unable to get domain type for domid=32
Unable to attach console
libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: console child [0] exited with error status 1

I have another VM whith the same Debian system in it which boots well. After comparing the grub.conf etc. with each other I could not see any differences.
If I launched the pygrub with the image disk of the VM as argument, I am normally presented with the Grub menu and then kicks out with the normal errors. This time I got no menu at all and got the following error message:
/usr/lib/xen-4.4/bin/pygrub /virtual/xen/VM/disk.img
Traceback (most recent call last):
File "/usr/lib/xen-4.4/bin/pygrub", line 839, in
raise RuntimeError, "Unable to find partition containing kernel"
RuntimeError: Unable to find partition containing kernel

After Googeling a bit I found this site which talks about this problem as well although with an LVM volume instead of with a file disk image. But the principle was the same:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745419
So in resume: If pygrub sees somethings else than zeroes in the first 512 bytes of the image disk, it returns with this error: ‘Unable to find partition containing kernel’

Cause:
During the upgrade of grub-pc the package script asked me to specify the boot sector where grub should be installed and I happen to select the proposed one ‘/dev/xvda2’ which was a mistake.

Preventive solution:
I should have left the image partition untouched and continue the upgrade of Grub-PC without grub being written in the boot sector, and then afterwards run the command:
update-grub

Present Solution:
Overwrite the boot sector(512 bytes) of the image file with zeros.

Command:
dd conv=notrunc if=/dev/zero of=/virtual/xen/domains/VM/disk.img bs=512 count=1
Note: I use the option conv=notrunc to make sure the output file will not be truncated to 512 bytes after the overwriting.

Result:
I could then boot the VM well again.

07 Mar 13 Using pyGRUB on Squeeze/Wheezy to boot a domU kernel

This adapded article is based on the following Debian Wiki article:
http://wiki.debian.org/PyGrub

In this article I assume:
– The reader is familiar with Linux and Xen Hypervisor
– The DOMu system partition is using a file image instead of a physical partition.

Introduction:
This method offers the advantage of loading the kernel which is installed in the DOMu. For this we use a Python script(/usr/lib/xen-default/bin/pygrub) which is located on DOM0. It understands the EXT3 filesystem of DOMu, loads and starts the Kernel(vmlinuz) and Ramdisk(initrd.img) files from DOMu defined in its Grub legacy configuration file(/boot/grub/menu.lst).

Prerequisites:
– The DOMu filesystem is EXT3
– The disk devices are using the format ‘xvda1/2/3…’
– The system image is the first listed in the DOMu xen configuration file.
Example:
root = '/dev/xvda1 ro'
disk = [
'file:/xen/VMS/disk.img,xvda1,w',
'file:/xen/VMS/disk.swp,xvda2,w',
]

On the DOMu:

Start the DOMu as done before and:
Make sure in the DOMu /etc/fstab that the mount points refer to /dev/xvd{a,b}1, /dev/xvd{a,b}2, …..
Example:
/dev/xvda1 / ext3 noatime,nodiratime,errors=remount-ro,usrquota,grpquota 0 1
/dev/xvda2 none swap sw 0 0

For Debian Squeeze DOMu install the Debian grub-legacy and latest kernel packages:
aptitude install grub-legacy linux-image-2.6-xen-amd64
For Debian Wheezy DOMu use this command:
aptitude install linux-image-amd64 grub-legacy
Create the pyGrub configuration file based on the system storage device (/dev/xvda1):
mkdir /boot/grub
vim /boot/grub/menu.lst

Content:
default 0
timeout 2
#
title Debian GNU/Linux
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro
initrd /initrd.img
#
title Debian GNU/Linux (recovery mode)
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro single
initrd /initrd.img

Stop DOMu.
halt

IMPORTANT: After every kernel update in the DOMU Debian tries to overwrite this file.
After each Kernel update issue the following commands:

mv /boot/grub/menu.lst /boot/grub/menu.lst.debian
mv /boot/grub/menu.lst~ /boot/grub/menu.lst

Reason: After a kernel upgrade the install script recreates its own grub.lst file which is not compatible with pygrub.

In DOM0:


Check that grub was properly installed on the domU. For DOM0 in Debian Squeeze with the command:
/usr/lib/xen-default/bin/pygrub /xen/VMS/disk.img
If your DOM0 is Debian Wheezy, then use this command instead:
/usr/lib/xen-4.1/bin/pygrub /xen/VMS/disk.img

This should give you a Grub boot menu as if the system will start but will kick out a couple of sec later with an error message. Ignore the error message, the presence of the boot menu was the indicator that everything is ready in the DOMu.

Replace the older kernel and ramdisk lines in the Xen DOMu configuration file as follows:
Example:
REPLACE:
kernel = '/boot/vmlinuz-2.6.32-5-xen-amd64'
ramdisk = '/boot/initrd.img-2.6.32-5-xen-amd64'

WITH:
bootloader = '/usr/lib/xen-default/bin/pygrub'
For Debian Wheezy, use the following entry instead.
bootloader = '/usr/lib/xen-4.1/bin/pygrub'

That was it. Now start the DOMu.

05 Feb 16 Creating a new Xen Debian virtual machine from scratch

Introduction:

In this tutorial a new virtual machine based on Debian Jessie distribution will be created from scratch with minimal components.
Assumption: The Xen Hypervisor should already be installed and running in the main system (DOM0).

Creating the Xen Virtual Machine

This virtual machine will be created with the xen tools which bootstraps the creation of the VM.
Bootstrapping:
mkdir -p /virtual/xen/
cd /virtual/xen/
xen-create-image --dir=. --dist=jessie --hostname=mail.myserver.com --size=10Gb --swap=2048Mb --ip=87.176.10.167 --gateway=87.176.10.254 --netmask=255.255.255.0 --memory=4096Mb --arch=amd64 --role=udev

Install the kernel and pyGrub
– Put the produced disk.img and swap.img in the proper path.
eg. in /virtual/xen/MAIL/
Mount the disk image in loop
mkdir /mnt/MAIL
mount /virtual/xen/MAIL/disk.img /mnt/MAIL -o loop,rw

Mount /sys, /proc, /dev and chroot to it
mount /proc /mnt/MAIL/proc -o bind
mount /sys /mnt/MAIL/sys -o bind
mount /dev /mnt/MAIL/dev -o bind
chroot /mnt/MAIL

Install the grub-legacy in VM
apt-get update
apt-get install grub-legacy linux-image-3.2.0-4-amd64 mc
mkdir /boot/grub
mcedit /boot/grub/menu.lst
CONTENT:
#----------------
default 0
timeout 2
#
title Debian GNU/Linux
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro
initrd /initrd.img
#
title Debian GNU/Linux (recovery mode)
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro single
initrd /initrd.img
#-------------

Leave chroot and unmount all.
exit
umount /mnt/MAIL/dev
umount /mnt/MAIL/sys
umount /mnt/MAIL/proc
umount /mnt/MAIL/

Adjust the VM xen configuration(/etc/xen/mail.server.com.cfg) as follows:
Replace the older kernel and initrd lines in the Xen DOMu configuration file as follows:
Example:
REPLACE:
kernel = '/boot/vmlinuz-2.6.32-5-xen-amd64'
ramdisk = '/boot/initrd.img-2.6.32-5-xen-amd64'

WITH:
For Debian squeeze hypervisor:
bootloader = '/usr/lib/xen-default/bin/pygrub'
For Debian wheezy hypervisor:
bootloader = '/usr/lib/xen-4.1/bin/pygrub'
For Debian jessie hypervisor:
bootloader = '/usr/lib/xen-4.4/bin/pygrub'

Adjust the paths of the disks properly:
Example:
disk = [
'file:/virtual/xen/MAIL/disk.img,xvda2,w',
'file:/virtual/xen/MAIL/disk.swp,xvda1,w',
]

Test the pyGRUB configuration with the VM disk
Note: A GRUB menu should appear for a few seconds and then disappear with an error message. Ignore the error message. Most important is that the Grub menu appears.
For Debian squeeze hypervisor:
/usr/lib/xen-default/bin/pygrub /virtual/xen/MAIL/disk.img
For Debian wheezy hypervisor:
/usr/lib/xen-4.1/bin/pygrub /virtual/xen/MAIL/disk.img
For Debian jessie hypervisor:
/usr/lib/xen-4.4/bin/pygrub /virtual/xen/MAIL/disk.img

Start the VM
The Grub menu should appear and start booting.
xm create /etc/xen/mail.server.com.cfg -c

Important note: Normally after such Bootstrap of a new Xen VM the VM uses the Hypervisor kernel when booting. This means, each VM is not capable to update its kernel independantly. This above method makes the VM fully independent of the Hypervisor kernel and gets its own kernel. The only disadvantage I see is that with some kernel updates the /boot/grub/menu.lst file gets automatically replaced during the kernel upgrade, you then NEED to recover the previous /boot/grub/menu.lst which is normally saved under /boot/grub/menu.lst~ before you reboot the VM. In case you forgot, then simply mount the VM image in loop as explained above and replace the file as needed. You should then be able afterwards to boot th VM.

03 Feb 16 Installing Xen 4.4 on Ubuntu Server 14.04 LTS (Trusty)

Introduction:

This HowTo assumes that the Internet access from VMs via DOM0 and the private LAN are done using the Bridge method. In the previous versions of Xen installation the bridges were dynamically built via the Xen scripts, in this version the bridges are built permanently as the DOM0 boots up.
DOM0:xenbr0(eth0) ---bridging==>> DOMUs:eth0
DOM0:pdummy0(dummy0) ---bridging==>> DOMUs:eth1

IMPORTANT: If you are installing Xen in a Hetzner(Germany) dedicated server and use only the available(max 3) IPs for the DOMUs, then you need to make sure you are generating a MAC address for each DOMU IP in the Hetzner robot site of your server, then use this MAC address in your DOMU Xen configuration. If you are using a subnet of 8 IP or more in Hetzner server for DOMUs, this bridging method would not work. Follow the instructions shown here instead: https://wp.me/pKZRY-F9

Install Xen Hypervisor and some useful tools
apt-get install xen-hypervisor-4.4-amd64 xen-utils-4.4 bridge-utils ethtool iptables

Some extra preparations

Since every virtual disk needs to be mounted using a loop device, we need to make sure there are enough of them available in the system.
Edit the file /etc/modules and add:
loop max_loop=64
dummy

We also need to turn on the IPv4 forwarding in the kernel.
Edit the file /etc/sysctl.conf (around line 44) activate the line by removing the ‘#’ as follows:
net.ipv4.ip_forward=1
The run the following command to activate it:
sysctl -p /etc/sysctl.conf

CONFIGURING THE NETWORK in DOM0

Based on the IP assumptions above, here is the content of the file /etc/network/interfaces.
# Internet Access nterface
auto xenbr0
iface xenbr0 inet static
address 85.114.145.5
netmask 255.255.255.0
network 85.114.145.0
broadcast 85.114.145.255
gateway 85.114.145.1
bridge_ports eth0
#
auto eth0
iface eth0 inet manual
#
# Internal LAN between VMs and DOM0
auto pdummy0
iface pdummy0 inet static
address 192.168.100.1
netmask 255.255.255.0
bridge_ports dummy0
#
auto dummy0
iface dummy0 inet manual

In order to make sure Xen scripts don’t create the normal bridges when a DOMu is started, we need to hinder this process by:
editing the file /etc/xen/xend-config.sxp and change the line:(around line 176)
FROM:
(network-script network-bridge)
TO:
(network-script none)
reboot

Configuring the DOMUs

DOMUs Configuration

PyGRUB
If your DOMUs configurations are set to use pygrub as boot loader,
then make sure the path to pygrub in the DOMU configuration file is correct as follows:
bootloader = '/usr/lib/xen-4.4/bin/pygrub'
In the same DOMU configuration file, make sure you are using a non duplicated MAC addresses with the network interfaces assignment as well as define the bridge that will be used by this DOMu, for example:
vif = [ 'ip=46.7.178.112,mac=00:16:34:D7:9C:12,bridge=xenbr0', 'ip=192.168.100.112,mac=00:16:3E:D7:1C:12,bridge=pdummy0' ]
NOTE:If you are not using the PyGRUb and want to use it as boot loader for each individual DOMUs, which makes the DOMUs kernel independent from the DOM0, see the following article. Please notice that in Ubuntu 14.04 the path to pygrub is different than in the article. Each new version of Xen has a different path to PyGRUB th rest of the article is fully accurate for Ubuntu as well.
http://tipstricks.itmatrix.eu/?s=pygrub&x=0&y=0

DOMus Network Configuration

Each DOMu will get an interface lo and eth0 with the following configuration:
I’m using the first IP of our subnet for this DOMU and will therefore be configured as follows:
Note: This configuration not really standard as it uses each IP with the netmask /32 (255.255.255.255).
This setting allows each IP of the subnet to be usable by each DOMu.
File: /etc/network/interfaces
Content:
# The loopback network interface
auto lo
iface lo inet loopback
#
# The primary network interface
auto eth0
iface eth0 inet static
address 46.7.178.112
netmask 255.255.255.255
gateway 46.7.178.1
#
# The internale LAN interface(will be connected to pdummy0 on DOM0)
auto eth1
iface eth1 inet static
address 192.168.100.112
netmask 255.255.255.0

05 Apr 15 Installing Xen 4.4 on Ubuntu Server 14.04 LTS (Trusty) in a Hetzner server with 8 IPs subnet

Hetzner Germany has very fast and not expensive rentals of Hardware servers available. In order to communicate internally via private network between Xen-DOMUs and DOM0, normally one would install Xen DOM0 network with bridge networking as follows:
DOM0:xenbr0(eth0) ===bridging===>> DOMUs:eth0

BUT!!!!
PROBLEM:
Because of the configuration of the network switches at Hetzner, one hardware server can have multiple IPs but only one MAC address (MAC of eth0 in DOM0). This means that Bridge networking for Internet connection (eth0) doesn’t work for multiple DOMUs, each one having its own IP AND MAC address. The situation is quite different if you order 1 to 3(max) extra IPs that can be added to each hardware server. Those IPs can be configured in the Xen DOMUs and use bridge as the method. On the Hetzner Robot site you can generate a MAC address per IP which you can use in your Xen DOMUs configuration and Hetzner switch will route it properly.(See this site for these instructions: https://wp.me/pKZRY-OE) BUT, this is not (yet?) the case with requested IP subnets from Hetzner. Therefore the following solution is the best found so far.

SOLUTION:
The solution is to use routing for Internet access. DOM0 does the routing of the traffic from internet to each DOMU. It also does routing the traffic between DOMUs, making this a private connection since this communication never leaves DOM0.
Note: This solution was presented in Hetzner documentation at http://wiki.hetzner.de/index.php/KVM_mit_Nutzung_aller_IPs_aus_Subnetz/en for KVM installation, which offers the possibility of using ALL of the subnet IPs, as opposed to the traditional way of using routing, which prevents the use of the first and last IP of the subnet as DOMU IP and also needs an extra IP as subnet Gateway for DOMUs. For example:
Traditional way of routing:
CIDR Subnet: 46.5.178.112/29
Network addr: 46.5.178.112 (unusable by DOMUs hosts)
Gateway addr: 46.5.178.113 (used as gateway for DOMUs, unusable by DOMUs hosts)
DOMUs usable IPs: 46.5.178.114 - 46.5.178.118 (5 IPs)
Broadcast addr: 46.5.178.119 (unusable for DOMUs hosts)

This means out of 8 IPs subnet (/29) you can only run 5 DOMUs in this Xen environment if each DOMU needs to have its own Internet reachable IP.

This specific routing method:
Every IP (8 IPs) of the subnet can be used for DOMUs: 46.5.178.112 – 46.5.178.119
No IP is lost for being the network or broadcast IP or as subnet gateway.
Internet ===>>(DOM0:eth0) --- routing ===>>(DOMu Bridge)===>>(DOMu VIF === DOMu:eth0)
Short explanation:
Each DOMu gets a bridge which contains a private network address(172.30.xx.1) used to link DOM0 to the DOMu Internet address.
Example:
DOM0:eth0 ===routing===>> (Bridge[172.30.112.1]) ===>> (vif1.0 === DOMu:eth0 [46.5.178.112])
DOM0:eth0 ===routing===>> (Bridge[172.30.113.1]) ===>> (vif2.0 === DOMu:eth0 [46.5.178.113])
DOM0:eth0 ===routing===>> (Bridge[172.30.114.1]) ===>> (vif3.0 === DOMu:eth0 [46.5.178.114])
DOM0:eth0 ===routing===>> (Bridge[172.30.115.1]) ===>> (vif4.0 === DOMu:eth0 [46.5.178.115])
DOM0:eth0 ===routing===>> (Bridge[172.30.116.1]) ===>> (vif5.0 === DOMu:eth0 [46.5.178.116])
DOM0:eth0 ===routing===>> (Bridge[172.30.117.1]) ===>> (vif6.0 === DOMu:eth0 [46.5.178.117])
DOM0:eth0 ===routing===>> (Bridge[172.30.118.1]) ===>> (vif7.0 === DOMu:eth0 [46.5.178.118])
DOM0:eth0 ===routing===>> (Bridge[172.30.119.1]) ===>> (vif8.0 === DOMu:eth0 [46.5.178.119])
DOM0:dummy0 ===routing===>> (Bridge:pdummy0) ===>> (vifx.0 === DOMu:eth1 [192.168.100.x])

Please notice the 3rd number in the bridge IP corresponds to the last number of the subnet IP of its respective DOMu. This is used just to identify the different subnets created in each bridge. They simply need to differ between each other.
The vifx.0 Virtual Interface is created automatically by the Xen scripts at the start of a DOMu. It is the internal link between the DOMu eth0 interface and its associated bridge located in DOM0.
The netmask of the private subnet of each bridge being 255.2555.255.0 is only a practical way of limiting the range of each subnet so they don’t overlap each other.

Note: In this HowTo I also use the virtual interface dummy0 to connect the DOMUs between each other in a private virtual LAN based on the network: 192.168.100.0/24. To realize this I set-up a dummy0 virtual interface and its attached bridge pdummy0.

Steps to create the virtual private LAN:

Edit /etc/modules and add the following line:
dummy
This will load the module dummy to the kernel automatically at boot time.
Now to avoid having to reboot we load it manually by issuing the command:
modprobe dummy
Interface configuration:
Edit /etc/network/interfaces and add the following lines:
(Replace IPs to your preferred IP Network)
auto dummy0
iface dummy0 inet manual
#
auto pdummy0
iface pdummy0 inet static
address 192.168.100.1
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
bridge_ports dummy0
bridge_stp off
bridge_fd 0
bridge_maxwait 0

Now we bring the dummy0 and bridge pdummy0 interfaces up:
ifup dummy0
ifup pdummy0

Note: at this point no worry about the error message. We can ignore it for now.
Check the configuration:
ifconfig dummy0
ifconfig pdummy0

You should get something like this:
dummy0 Link encap:Ethernet HWaddr 76:99:e1:48:64:f5
UP BROADCAST RUNNING NOARP MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:15 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:1230 (1.2 KB)
#
pdummy0 Link encap:Ethernet HWaddr 76:99:e1:48:64:f5
inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::7499:e1ff:fe48:64f5/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:407 errors:0 dropped:0 overruns:0 frame:0
TX packets:530 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:82394 (82.3 KB) TX bytes:57166 (57.1 KB)

The routing table looks then like this:
# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 178.61.78.129 0.0.0.0 UG 0 0 0 eth0
46.5.178.112 0.0.0.0 255.255.255.255 UH 0 0 0 br112
46.5.178.113 0.0.0.0 255.255.255.255 UH 0 0 0 br113
46.5.178.114 0.0.0.0 255.255.255.255 UH 0 0 0 br114
46.5.178.115 0.0.0.0 255.255.255.255 UH 0 0 0 br115
46.5.178.116 0.0.0.0 255.255.255.255 UH 0 0 0 br116
46.5.178.117 0.0.0.0 255.255.255.255 UH 0 0 0 br117
46.5.178.118 0.0.0.0 255.255.255.255 UH 0 0 0 br118
46.5.178.119 0.0.0.0 255.255.255.255 UH 0 0 0 br119
172.30.112.0 0.0.0.0 255.255.255.0 U 0 0 0 br112
172.30.113.0 0.0.0.0 255.255.255.0 U 0 0 0 br113
172.30.114.0 0.0.0.0 255.255.255.0 U 0 0 0 br114
172.30.115.0 0.0.0.0 255.255.255.0 U 0 0 0 br115
172.30.116.0 0.0.0.0 255.255.255.0 U 0 0 0 br116
172.30.117.0 0.0.0.0 255.255.255.0 U 0 0 0 br117
172.30.118.0 0.0.0.0 255.255.255.0 U 0 0 0 br118
172.30.119.0 0.0.0.0 255.255.255.0 U 0 0 0 br119
178.61.78.129 0.0.0.0 255.255.255.255 UH 0 0 0 eth0
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 pdummy0

ASSUMPTIONS in these examples

Current network settings:
DOM0 IP: 178.61.78.140
Default Gateway: 178.61.78.129
IP Net netmask: 255.255.255.240

Extra IPs subnet:
Subnet: 46.5.178.112/29 (46.4.178.112 – 46.4.178.119)
Netmask: 255.255.255.248
Broadcast: 46.5.178.119

Local virtual LAN
Subnet: 192.168.100.0/24
Netmask: 255.255.255.0
Broadcast: 192.168.100.255

XEN INSTALLATION

We will first install XEN in the main hardware server. This means installing the hypervisor, xen aware kernel and xen tools. This can be done by a installing the following packages and a few favorite tools 🙂
apt-get install xen-hypervisor-4.4-amd64 xen-utils-4.4 bridge-utils ethtool iptables mc ssh fail2ban

Some extra preparations

Since every virtual disk needs to be mounted using a loop device, we need to make sure there are enough of them available in the system.
Edit the file /etc/modules and add:
loop max_loop=64

We also need to turn on the IPv4 forwarding in the kernel.
Edit the file /etc/sysctl.conf (around line 44) activate the line by removing the ‘#’ as follows:
net.ipv4.ip_forward=1
The run the following command to activate it:
sysctl -p /etc/sysctl.conf

CONFIGURING THE NETWORK in DOM0

Based on the IP assumptions above, here is the content of the file /etc/network/interfaces:
Note: The configuration of the eth0 below is not standard. Please see the explanation of it at:
http://wiki.hetzner.de/index.php/KVM_mit_Nutzung_aller_IPs_aus_Subnetz/en
# Loopback device:
auto lo
iface lo inet loopback
#
## device: eth0 for normal operation
# The primary network interface for KVM operation
auto eth0
iface eth0 inet static
address 178.61.78.140
netmask 255.255.255.255
gateway 178.61.78.129
pointopoint 178.61.78.129
#
iface eth0 inet6 static
address 2a01:4f8:121:30ea::2
netmask 64
gateway fe80::1
#
auto dummy0
iface dummy0 inet manual
#
auto pdummy0
iface pdummy0 inet static
address 192.168.100.1
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
gateway 192.168.0.1
bridge_ports dummy0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
#
################# Individual bridges for each extra VM #################
auto br112
iface br112 inet static
address 172.30.112.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.5.178.112 $IFACE
post-down brctl delbr $IFACE
#
auto br113
iface br113 inet static
address 172.30.113.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.5.178.113 $IFACE
post-down brctl delbr $IFACE
#
auto br114
iface br114 inet static
address 172.30.114.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.4.178.114 $IFACE
post-down brctl delbr $IFACE
#
auto br115
iface br115 inet static
address 172.30.115.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.5.178.115 $IFACE
post-down brctl delbr $IFACE
#
auto br116
iface br116 inet static
address 172.30.116.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.5.178.116 $IFACE
post-down brctl delbr $IFACE
#
auto br117
iface br117 inet static
address 172.30.117.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.5.178.117 $IFACE
post-down brctl delbr $IFACE
#
auto br118
iface br118 inet static
address 172.30.118.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.5.178.118 $IFACE
post-down brctl delbr $IFACE
#
auto br119
iface br119 inet static
address 172.30.119.1
netmask 255.255.255.0
pre-up brctl addbr $IFACE
post-up route add -host 46.5.178.119 $IFACE
post-down brctl delbr $IFACE

In order to make sure Xen scripts don’t create the normal bridges when a DOMu is started, we need to hinder this process by:
editing the file /etc/xen/xend-config.sxp and change the line:(around line 176)
FROM:
(network-script network-bridge)
TO:
(network-script none)
Reboot for the new network configuration to take effect:
reboot

DOMUs Configuration

PyGRUB
If your DOMUs configurations are set to use pygrub as boot loader,
then make sure the path to pygrub in the DOMU configuration file is correct as follows:
bootloader = '/usr/lib/xen-4.4/bin/pygrub'
In the same DOMU configuration file, make sure you are using a non duplicated MAC addresses with the network interfaces assignment as well as define the bridge that will be used by this DOMu, for example:
vif = [ 'ip=46.5.178.112,mac=00:16:34:D7:9C:F8,bridge=br112', 'ip=192.168.100.112,mac=00:16:3E:D7:1C:13,bridge=pdummy0' ]

NOTE:If you are not using the PyGRUb and want to use it as boot loader for each individual DOMUs, which makes the DOMUs kernel independent from the DOM0, see the following article. Please notice that in Ubuntu 14.04 the path to pygrub is different than in the article. Each new version of Xen has a different path to PyGRUB th rest of the article is fully accurate for Ubuntu as well.
http://tipstricks.itmatrix.eu/?s=pygrub&x=0&y=0

DOMus Network Configuration

Each DOMu will get an interface lo, eth0 and eth1 with the following configuration:
I’m using the first IP of our subnet for this DOMU and will therefore be configured as follows:
Note: This configuration is not really standard as it uses each IP with the netmask /32 (255.255.255.255). This setting allows each IP of the subnet to be usable by each DOMu. The configuration pointopoint allows it to reach the gateway.

File: /etc/network/interfaces
Content:
# The loopback network interface
auto lo
iface lo inet loopback
#
# The primary network interface
auto eth0
iface eth0 inet static
address 46.5.178.112
netmask 255.255.255.255
gateway 178.61.78.140
pointopoint 178.61.78.140
#
auto eth1
iface eth1 inet static
address 192.168.100.112
netmask 255.255.255.0

07 Aug 14 Install Xen 4.1 on Debian Wheezy in a Hetzner Dedicated server

Hetzner Germany has very fast and not expensive rentals of Hardware servers available. In order to communicate internally via private network between Xen-DOMUs and DOM0, normally one would install Xen DOM0 network with bridge networking as follows:
DOM0:xenbr0(eth0) --- bridging==>> DOMUs:eth0
DOM0:xenbr1(dummy0) ---bridging==>> DOMUs:eth1

BUT!!!!
PROBLEM:
Because of the configuration of the network switches at Hetzner, one hardware server can have multiple IPs but only one MAC address (MAC of eth0 in DOM0). This means that Bridge networking for Internet connection (eth0) doesn’t work for multiple DOMUs, each one having its own IP AND MAC address.
SOLUTION:
The solution is to use routing for Internet access and bridging for private LAN as follows:
DOM0:eth0 --- routing===>> DOMUs:eth0
DOM0:xenbr1(dummy0) --- bridging==>> DOMUs:eth1

Note: The DISADVANTAGE of this solution is that DOM0 must use one IP from the subnet provided by hetzner to be used as a gateway for the running DOMUs to allow them to communicate with the Internet. In this case the following IP subnet of 8 IPs provided by by Hetzner could be for example:
CIDR Subnet: 140.231.213.168/28
Network addr: 140.258.213.168 (unusable by DOMUs hosts)
Gateway addr: 140.231.213.169 (used as gateway for DOMUs, unusable by DOMUs hosts)
DOMUs usable IPs: 140.231.213.170 - 140.231.213.174 (5 IPs)
Broadcast addr: 140.231.213.175 (unusable for DOMUs hosts)

This means out of 8 IPs you got as a subnet from Hetzner you can only run 5 DOMUs in this Xen environment if each DOMU needs to have its own Internet reachable IP.

XEN INSTALLATION


We will first install XEN in the main hardware server. This means installing the hypervisor, xen aware kernel and xen tools. This can be done by a installing the following packages and a few favorite tools 🙂
apt-get install xen-linux-system xen-tools bridge-utils mc ssh fail2ban ethtool
Debian Wheezy uses Grub 2 and as default boot manager. It lists normal kernels first, and then, if the xen kernel is installed, lists the Xen hypervisor and its kernels. You need to change this to cause Grub 2 to prefer to boot Xen as default kernel. It is done by changing the priority of Grub’s Xen configuration script (20_linux_xen) to be higher prority than the standard Linux config (10_linux). This is most easily done using dpkg-divert:
dpkg-divert --divert /etc/grub.d/08_linux_xen --rename /etc/grub.d/20_linux_xen
After any update to the Grub configuration you must apply the configuration by running:
update-grub
Disable Xendomains save & restore
We disable the saving and restore feature of DOMUs mostly because my experience is that this feature doens’t always work well. I prefer to do the shutdown of each DOMU manually before rebooting DOM0, then after reboot of DOM0, restart each individual DOMU using a @reboot cron job for example:
# This will start 2 virtual machines 60 sec after reboot of DOM0
@reboot /bin/sleep 60; /usr/sbin/xl create /etc/xen/DOMU1.cfg; /usr/sbin/xl create /etc/xen/DOMU2.cfg
This way if power failure happens or anything that forces an unattended reboot of DOM0, all the DOMUs will automatically restart after reboot.

Now the disabling of the automatic Save/Restore of DOMUs:
Edit /etc/default/xendomains
Content:
#XENDOMAINS_SAVE=/var/lib/xen/save
XENDOMAINS_SAVE=
#
#XENDOMAINS_RESTORE=true
XENDOMAINS_RESTORE=false

NETWORKING:


Add the dummy network interface module
echo dummy >> /etc/modules
modprobe dummy

Network configuration
Edit file: /etc/network/interfaces
(Note: here you’ll need to adapt your own IPs etc. in this file)
Content:
# Loopback device:
auto lo
iface lo inet loopback
#
# device: eth0
auto eth0
iface eth0 inet static
address 123.45.67.89
broadcast 123.45.67.255
netmask 255.255.255.0
gateway 123.45.67.1
#
iface eth0 inet6 static
address 2a01:4f7:192:4213::2
netmask 64
gateway fe80::1
#
# Used exclusively as Gateway for DOMUs for this subnet. Unfortunately losing one IP for Gateway purposes.
auto eth0:gw1
iface eth0:gw1 inet static
address 140.231.213.169
netmask 255.255.255.248
network 140.231.213.168
broadcast 140.231.213.175
#
# Internal private network to DOMUs
iface dummy0 inet manual
#
auto xenbr1
iface xenbr1 inet static
address 192.168.100.1
netmask 255.255.255.0
network 192.168.100.0
broadcast 192.168.100.255
bridge_ports dummy0
#
#other possibly useful options in a virtualized environment
bridge_stp off # disable Spanning Tree Protocol
bridge_waitport 0 # no delay before a port becomes available
bridge_fd 0 # no forwarding delay
post-up ethtool -K xenbr1 tx off
post-up ip link set xenbr1 promisc off

Switch to the XL Xen ToolStack
Edit /etc/default/xen
TOOLSTACK=xl
WARNING: The above entry is small ‘XL’ and not small ‘X1’ !!

Edit /etc/xen/xl.conf and make sure the entries are as follows:
# automatically balloon down dom0 when xen doesn't have enough free
# memory to create a domain
autoballoon=1
#
# full path of the lockfile used by xl during domain creation
lockfile="/var/lock/xl"
#
# default vif script.
#vifscript="vif-bridge"
vifscript="/etc/xen/scripts/vif-route_eth0-bridge_dummy0"

Note: Here we use a script which will set routing for eth0 and bridging for dummy0.
Create it.
touch /etc/xen/scripts/vif-route_eth0-bridge_dummy0
chmod 755 /etc/xen/scripts/vif-route_eth0-bridge_dummy0

Edit the file /etc/xen/scripts/vif-route_eth0-bridge_dummy0
Content:
#!/bin/sh
# Custom vif script which allows to combine routing for Internet and bridging for internal LAN
dir=$(dirname "$0")
IFNUM=$(echo ${vif} | cut -d. -f2)
if [ "$IFNUM" = "0" ] ; then
"$dir/vif-route" "$@"
else
"$dir/vif-bridge" "$@"
fi

Edit the file /etc/xen/xend-config.sxp
and make sure the already existing entries are disabled with ‘#’ and new lines entered as follows:
#.......
#(vif-script vif-bridge)
(network-script dummy)
#
#(vif-script vif-route)
(vif-script vif-route_eth0-bridge_dummy0)
#
# make sure DOM0 has enough memory
(dom0-min-mem 2048)
#.......

Setup the IP forwarding and ARP proxying in kernel:
Edit the file /etc/sysctl.conf
Either un-comment or add the following lines:
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
# ARP Proxying
net.ipv4.conf.eth0.proxy_arp = 1

To make this change take effect immediately run:
sysctl -p /etc/sysctl.conf
Finally, before we reboot the system we need to make sure we activate the proper toolstack and related features at boot time by running the following commands:
update-rc.d xendomains defaults
update-rc.d xen defaults
/etc/init.d/xen restart
/etc/init.d/xendomains restart

DOMUs Configuration


PyGRUB
If your DOMUs configurations are set to use pygrub as boot loader,
then make sure the path to pygrub in the DOMU configuration file is correct as follows:
bootloader = '/usr/lib/xen-4.1/bin/pygrub'
In the same DOMU configuration file, make sure you are using a non duplicated MAC addresses with the network interfaces assignment for example:
vif = [ 'ip=140.258.213.170,mac=00:16:34:D7:9C:F4' , 'ip=192.168.0.18,mac=00:16:3E:D7:9C:F6',bridge=xenbr1]
Note: The first IP doesn’t need any bridge since it is routing controlled, the internal LAN is bridged with xenbr1 though.

NOTE:If you want to use the pyGrub as boot loader for each individual DOMUs which makes the DOMUs kernel independant from the DOM0, see the following article:
http://tipstricks.itmatrix.eu/?s=pygrub&x=0&y=0

06 Apr 14 Switching from xm(xend) XenToolStack to XL XenToolStack in Delian Wheezy

Introduction:


While I upgraded my Xen DOM0 from Squeeze to Wheezy it was recommended to switch from the Xend(xm) Toolstack to XL Toolstack. Because I found very little info on how to do the switch. So here is a way do it on Wheezy.
Here we are assuming that you have installed Xen 4.1 Hypervisor on Debian Wheezy and you are still running the Xend ToolStack.
Since the Xend Toolstack will be rendered soon obsolete, it is therefore recommended to switch to the XL ToolStack.
Reference: http://wiki.xen.org/wiki/Network_Configuration_Examples_%28Xen_4.1%2B%29#Overview

Settings for Bridge networking on dual home: eth0 and eth1

Note: Unlike the Xend ToolStack, XL toolstack doesn’t create the bridges for eth0 and eth1, therefore they need to be created using the normal system network settings for them to be ready at boot time.
To make sure xend doesn’t try to configure the bridges, force xend to never try by reconfiguring the networking:
Edit /etc/xen/xend-config.sxp
(network-script dummy)
(vif-script vif-bridge)

INTERFACES
Edit the file: /etc/network/interfaces
Content: (make sure you replace the following example IPs etc. accordingly)
# The loopback network interface
auto lo
iface lo inet loopback
#
# eth0 and xenbr0 bridge
auto xenbr0
iface xenbr0 inet static
bridge_ports eth0
address 12.34.56.78
netmask 255.255.255.0
network 12.34.56.0
broadcast 12.34.56.255
gateway 12.34.56.254
bridge_stp off
post-up ethtool -K xenbr0 tx off
post-up ip link set xenbr0 promisc off
#
# eth1 and xenbr1 Bridge
auto xenbr1
iface xenbr1 inet static
bridge_ports eth1
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
bridge_stp off
post-up ethtool -K xenbr1 tx off

The command ifconfig will then show the eth0 and eth1 without IP and their respective Bridges (xenbr0,xenbr1) will have them.

Make sure xen Linux is listed as the default kernel when booting
mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
or
dpkg-divert --divert /etc/grub.d/09_linux_xen --rename /etc/grub.d/20_linux_xen
update-grub

Switch to the XL Xen ToolStack
Edit /etc/default/xen
TOOLSTACK=xl
Edit /etc/xen/xl.conf and make sure the entries are as follows:
# automatically balloon down dom0 when xen doesn't have enough free memory to create a domain
autoballoon=1
# full path of the lockfile used by xl during domain creation
lockfile="/var/lock/xl"
# default vif script
vifscript="/etc/xen/scripts/vif-bridge"

If your DOMUs configurations are set to use pygrub as boot loader, then make sure the path to pygrub in the DOMU configuration file is correct as follows:
bootloader = '/usr/lib/xen-4.1/bin/pygrub'
In the same DOMU configuration file, make sure you are using the appropriate bridges with the network interfaces assignment for example:
vif = [ 'ip=12.34.56.18,mac=00:16:3E:D7:9C:F4,bridge=xenbr0' , 'ip=192.168.0.18,mac=00:16:3E:D7:9C:F6,bridge=xenbr1']
Finally, before we reboot the system we need to make sure we deactivate the xend(xm) toolstack and related features at boot time via:
update-rc.d xendomains defaults
update-rc.d xen defaults
/etc/init.d/xen restart
/etc/init.d/xendomains restart

Reboot
reboot
Start your DOMUs as usual with the command xl instead of xm.

Settings for Routing/Bridging networking on dual home: eth0 and eth1

Note: In the example above I’m using the Bridging method for both eth0 and eth1. In this present example I use routing for eth0(Internet connection) and bridging for eth1(internal private network). One might ask why use routing for eth0? The reason is mostly because of some type of routers/switches that the server provider uses makes it impossible to use bridging for eth0. The problem with some of those routers/switches is that, although they allow multiple IP addresses per network adapter, they allow only one MAC address per network adapter. For example Hetzner in Germany is using such routers/switches. This makes the use of bridging impossible for accessing the virtual machines via DOM0 from Internet. In this case the routing method is used for eth0. The other reason for using routing is also, besides the possible problems with the providers routers/switches, is the use of the redundancy software Heartbeat where two virtual machines share the same virtual IP. Heartbeat switches the IP from one VM to another, depending on the VM’s availability. In this case using bridging is also impossible because of some long refresh rates of the ARP tables of the switches in front of eth0. For example, if the MAC addr. is set for a certain IP and then Heartbeat gives that IP to another VM, then the MAC addr. for this IP will change but the ARP table of the switch will not follow until the switch refreshes its ARP table. This would result in downtime, which is exactly what heartbeat is supposed to avoid.

In this example below I use routing method for eth0 and bridging for eth1, consequently configure eth0 as a usual interface and create a bridge for eth1.
Xen XL toolstack will automatically create the proper vif* interfaces and routing entries for each VM while starting the VM.
To make sure xend doesn’t try to configure the bridges, force xend to never try by reconfiguring the networking:
Edit /etc/xen/xend-config.sxp
(network-script dummy)
(vif-script vif-route_eth0-bridge_eth1)

Edit the file: /etc/network/interfaces
Content: (make sure you replace the following example IPs etc. accordingly)
Here we use a very normal Network configuration without bridges.
# The loopback network interface
auto lo
iface lo inet loopback
#
# eth0
auto eth0
iface eth0 inet static
address 12.34.56.78
netmask 255.255.255.0
network 12.34.56.0
broadcast 12.34.56.255
gateway 12.34.56.254
#
# eth1 and xenbr1 Bridge
auto xenbr1
iface xenbr1 inet static
bridge_ports eth1
address 192.168.0.19
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
bridge_stp off
post-up ethtool -K xenbr1 tx off
post-up ip link set xenbr1 promisc off

Make sure xen Linux is listed as the default kernel when booting
mv /etc/grub.d/20_linux_xen /etc/grub.d/09_linux_xen
or
dpkg-divert --divert /etc/grub.d/09_linux_xen --rename /etc/grub.d/20_linux_xen
update-grub

Switch to the XL Xen ToolStack
Edit /etc/default/xen
TOOLSTACK=xl
Edit /etc/xen/xl.conf and make sure the entries are as follows:
# automatically balloon down dom0 when xen doesn't have enough free memory to create a domain
autoballoon=1
# full path of the lockfile used by xl during domain creation
lockfile="/var/lock/xl"
# default vif script
vifscript="/etc/xen/scripts/vif-route_eth0-bridge_eth1"

Note: Here we use a script which will use routing for eth0 and bridging for eth1. Here we will create it.
touch /etc/xen/scripts/vif-route_eth0-bridge_eth1
chmod 755 /etc/xen/scripts/vif-route_eth0-bridge_eth1

Edit the file /etc/xen/scripts/vif-route_eth0-bridge_eth1.
Content:
#!/bin/sh
# Custom vif script which allows to combine routing for Internet and bridging for internal LAN
dir=$(dirname "$0")
IFNUM=$(echo ${vif} | cut -d. -f2)
if [ "$IFNUM" = "0" ] ; then
"$dir/vif-route" "$@"
else
"$dir/vif-bridge" "$@"
fi

PyGRUB
If your DOMUs configurations are set to use pygrub as boot loader, then make sure the path to pygrub in the DOMU configuration file is correct as follows:
bootloader = '/usr/lib/xen-4.1/bin/pygrub'
In the same DOMU configuration file, make sure you are using the appropriate MAC addresses with the network interfaces assignment for example:
vif = [ 'ip=12.34.56.18,mac=00:16:3E:D7:9C:F4' , 'ip=192.168.0.18,mac=00:16:3E:D7:9C:F6',bridge=xenbr1]
Setup the IP forwarding and ARP proxying in kernel:
Edit the file /etc/sysctl.conf
Either un-comment or add the following lines:
# Uncomment the next line to enable packet forwarding for IPv4
net.ipv4.ip_forward=1
# ARP Proxying
net.ipv4.conf.eth0.proxy_arp = 1

To make this change take effect immediately run:
sysctl -p /etc/sysctl.conf

Finally, before we reboot the system we need to make sure we activate the proper toolstack and related features at boot time via:
update-rc.d xendomains defaults
update-rc.d xen defaults
/etc/init.d/xen restart
/etc/init.d/xendomains restart

Reboot
reboot
Start your DOMUs as usual with the command xl instead of xm.

20 Jan 14 Creating a XEN machine and Installing Group Office in Debian Wheezy

Introduction

In this Tutorial I will explain the steps I did to create a Xen Virtual Machine with minimal packages and then install the latest Group Office Web based Collaboration software. You’ll need to be fluent in Linux and Xen because I don’t explain much here.

Note: My hypervisor is Xen 4.0 in Debian Squeeze with xen-utils-4.0 package installed. I also use fictive domain(myserver.com) names and IP addresses just as example.

Creating the Xen Virtual Machine

This virtual machine will be created with the xen tools which bootstraps the creation of the VM.
Bootstrapping:
mkdir -p /virtual/xen/
cd /virtual/xen/
xen-create-image --dir=. --dist=wheezy --hostname=mail.myserver.com --size=20Gb --swap=2048Mb --ip=87.176.102.167 --gateway=87.176.102.254 --netmask=255.255.255.0 --memory=4096Mb --arch=amd64 --role=udev

Install the kernel and pyGrub
– Put the produced disk.img and swap.img in the proper path.
eg. in /virtual/xen/MAIL/
Mount the disk image in loop
mkdir /mnt/MAIL
mount /virtual/xen/MAIL/disk.img /mnt/MAIL -o loop,rw

Mount /sys, /proc, /dev and chroot to it
mount /proc /mnt/MAIL/proc -o bind
mount /sys /mnt/MAIL/sys -o bind
mount /dev /mnt/MAIL/dev -o bind
chroot /mnt/MAIL

Install the grub-legacy in VM
apt-get update
apt-get install grub-legacy linux-image-3.2.0-4-amd64 mc
mkdir /boot/grub
mcedit /boot/grub/menu.lst
CONTENT:
#----------------
default 0
timeout 2
#
title Debian GNU/Linux
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro
initrd /initrd.img
#
title Debian GNU/Linux (recovery mode)
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro single
initrd /initrd.img
#-------------

Leave chroot and unmount all.
exit
umount /mnt/MAIL/dev
umount /mnt/MAIL/sys
umount /mnt/MAIL/proc
umount /mnt/MAIL/

Adjust the VM xen configuration(/etc/xen/mail.server.com.cfg) as follows:
Replace the older kernel and initrd lines in the Xen DOMu configuration file as follows:
Example:
REPLACE:
kernel = '/boot/vmlinuz-2.6.32-5-xen-amd64'
ramdisk = '/boot/initrd.img-2.6.32-5-xen-amd64'
WITH:
bootloader = '/usr/lib/xen-default/bin/pygrub'

Adjust the paths of the disks properly:
Example:
disk = [
'file:/virtual/xen/MAIL/disk.img,xvda2,w',
'file:/virtual/xen/MAIL/disk.swp,xvda1,w',
]

Test the pyGRUB configuration with the VM disk
Note: A GRUB menu should appear for a few seconds and then disappear with an error message. Ignore the error message. Most important is that the Grub menu appears.
/usr/lib/xen-default/bin/pygrub /virtual/xen/MAIL/disk.img
Start the VM
The Grub menu should appear and start booting.
xm create /etc/xen/mail.server.com.cfg -c

Installing Group-Office


Login as root and configure APT with the Group Office repositories
(REF: https://www.group-office.com/wiki/Installing_on_Debian_or_Ubuntu)
apt-get update, apt-get upgrade
echo -e "\n## Group-Office repository\ndeb http://repos.groupoffice.eu/ fivezero main" | tee -a /etc/apt/sources.list
gpg --keyserver hkp://keyserver.ubuntu.com:11371 --recv-keys 01F1AE44
gpg --export --armor 01F1AE44 | apt-key add -
apt-get update

Install Group Office
apt-get install groupoffice-mailserver postfix postfix-mysql dovecot-mysql dovecot-managesieved dovecot-sieve dovecot-lmtpd rsync mc
– Setting root password to MySQL server.
– Setting the domain name.

Note from Group Office before start of installation.
After installation is completed launch your browser and go to http://localhost/groupoffice/
or replace localhost with the hostname / IP of this machine.
The default login is username: admin and password: admin.
Enjoy Group-Office!

Setting root password to MySQL server:
Setting MySQL password of user:groupoffice-com DB groupofficecom :

Now some undesired installation features messages will appear:

[FAIL] Clamav signatures not found in /var/lib/clamav ... failed!
[FAIL] Please retrieve them using freshclam ... failed!
[FAIL] Then run '/etc/init.d/clamav-daemon start' ... failed!

To fix that:
apt-get -f install
freshclam
/etc/init.d/clamav-daemon start

All looking good now,
In Browser, try to login with your ‘admin’ password at:
http://mail.myserver.com/groupoffice

HINT about domains:
If you configure more domains in the admin web interface under ‘Email Domains’ menu item and try to create new users, only the original domain is offered to select as possible mailboxes for the new users. The newly configured domains are not listed. To remedy to that, you need to enter all of the domains this system may use into both GroupOffice and Amavis the configuration file:
IN /etc/groupoffice/config.php
$config['serverclient_domains']='domain1.com,domain2.com';

IN /etc/amavis/conf.d/05-domain_id
@local_domains_acl = ( ".$mydomain" , "domain1.com", "domain2.com")

Recommendation:
In order to raise your mail server’s general acceptance from large mailing servers like AOL, GMX, Yahoo, etc. it is recommended to:
– Configure your domain in DNS concerning the SPF1 and SPF2
– Configure in your mail server and DNS to send DKIM token.
See DKIM installation at: http://tipstricks.itmatrix.eu/?p=1494 for DKIM installation.
– Configure Postfix to use RBL SPAM filtering(see instructions below)

SPAM Reduction


This server is already providing some anti-spam protection but in some cases extra filter might need to be installed.

Add some more RBL SPAM Filtering

Note: In my mail server, almost every day about 800 to 2000 Spams are blocked using the RBL filtering method. So I do recommend it since its also quite simple as well.
Edit your Postfix main configuration file /etc/postfix/main.cf and replace the existing configuration with the following one. It contains the same configuration as the original except it adds to the list of RBL servers.
Postfix RBL settings:
smtpd_recipient_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unauth_destination,
reject_invalid_hostname,
reject_non_fqdn_sender,
reject_non_fqdn_recipient,
reject_unknown_sender_domain,
reject_unknown_recipient_domain,
reject_rhsbl_sender dsn.fc-ignorant.org,
check_recipient_access hash:/etc/postfix/spam_rec_addr,
check_client_access hash:/etc/postfix/rbl_whitelist,
reject_rbl_client abuse.rfc-ignorant.org,
reject_rbl_client blackholes.brainerd.net,
reject_rbl_client bl.deadbeef.com,
reject_rbl_client dnsbl.antispam.or.id,
reject_rbl_client korea.services.net,
reject_rbl_client l1.spews.dnsbl.sorbs.net,
reject_rbl_client l2.spews.dnsbl.sorbs.net,
reject_rbl_client postmaster.rfc-ignorant.org,
reject_rbl_client query.bondedsender.org,
reject_rbl_client relays.bl.kundenserver.de,
reject_rbl_client relays.nether.net,
reject_rbl_client sbl.spamhaus.org,
reject_rbl_client zen.spamhaus.org,
reject_rbl_client ix.dnsbl.manitu.net,
reject_rbl_client spamguard.leadmon.net,
reject_rbl_client tr.countries.nerd.dk,
reject_rbl_client unsure.nether.net,
reject_rbl_client whois.rfc-ignorant.org,
reject_rbl_client l1.bbfh.ext.sorbs.net,
reject_rbl_client l2.bbfh.ext.sorbs.net,
reject_rbl_client psbl.surriel.com,
reject_rbl_client b.barracudacentral.org,
reject_rbl_client cbl.abuseat.org,
permit

# Allows to add a SPAM blacklist if needed (/etc/postfix/spam_addr)
smtpd_reject_unlisted_sender = yes
smtpd_sender_restrictions =
permit_mynetworks,
permit_sasl_authenticated,
reject_unknown_sender_domain,
reject_non_fqdn_sender,
check_sender_access hash:/etc/postfix/spam_addr
permit

# Allows to set regex rules to refuse certain know SPAM content in (/etc/postfix/spam_body_regex)
body_checks = regexp:/etc/postfix/spam_body_regex

Raising server delivery acceptance rate with DKIM

Ref: See instruction in http://tipstricks.itmatrix.eu/?p=1494

Raising security with TLS mail delivery

Ref: http://tipstricks.itmatrix.eu/?p=855
This feature allows postfix to send emails to remote mail servers using TLS encryption if the remote email server does support TLS transport otherwise clear text as usual.

Edit the file: /etc/postfix/main.cf and at the end enter the following:
smtp_tls_security_level = may

OPTIONAL: Enable DKIM verification in Amavis

This verification will warn you if a mail has been received which failed the DKIM verification.
Edit the file /etc/amavis/conf.d/60-groupoffice_defaults
Add the following line:
# Activating warnings for failed DKIM checked emails
$enable_dkim_verification = 1;

OPTIONAL: Enable the addition of ‘*****SPAM*****’ in header of suspicious emails.

Edit the file: /etc/amavis/conf.d/60-groupoffice_defaults
Add the following line:
$sa_spam_subject_tag = '***SPAM*** ';
You can then use this extra Subject tag to filter your mails and send them automatically in another directory like in ‘Spam’ directory.

OPTIONAL: Enable the Bayes Spam and Ham learning


For this we need to feed Spamassassin some Spam(Bad) and Ham(good) emails.
In this above configuration file the path of the files where Spamassassin learns is set to /home/spamd which doesn’t exist.
I don’t quite know how SA will discern the difference between Ham and spam So I’m doing it another way.
In order to feed it some spam mails each user should contribute to it as follows:
– The users create two new mail folder called exactly ‘Spam’ and ‘Ok’
– Then each time the user receives a definite SPAM email that is NOT tagged *****SPAM*****, he drops the email into his ‘Spam’ folder and forget about it.
– Each time he sees that a good mail has been erroneously tagged *****SPAM***** he drops a COPY a copy of the email into his ‘Ok’ folder and forgets about it.
The following configurations will ensure the following:
– The emails gathered in user’s ‘Spam’ and ‘Ok’ directories will be harvested by a cron job and be added automatically to /home/SA/spam(BAD) or /home/SA/ham(Good) directories respectively for sa-learn to learn from them.

We will create the directories and assign full access to the user ‘spamd’
mkdir -p /home/SA/spam
mkdir -p /home/SA/ham
chown spamd: /home/SA/spam /home/SA/ham

– SpamAssassin will regularly learn from it and offer a continuous increasing accuracy in detecting spams.
System cron job to harvest each day the user’s Spam mails and feed SA learning directory:
0 0 * * * /root/bin/SA-learn.sh

Creating the script:
touch /root/bin/SA-Learn.sh
chmod 755 /root/bin/SA-Learn.sh
Content of script /root/bin/SA-Learn.sh
#!/bin/bash
# make sure the lock file can be written in /home/spamd/
mkdir -p /home/spamd
chown -R spamd: /home/spamd
#
# Purpose: Feeds SA to learn the SPAM emails and GOOD emails
# Harvest the SPAM emails from users and deposit them in spam directory
for spamdir in $(find /home/vmail/ -type d -name '.Spam') ; do rsync -au $spamdir/cur/ /home/SA/spam/; done
#
# Harvest the HAM emails from users and deposit them in ham directory
for hamdir in $(find /home/vmail/ -type d -name '.Ham') ; do rsync -au $hamdir/cur/ /home/SA/ham/; done
#
# Now tell SA to learn from them
/usr/bin/sa-learn --spam -u spamd --dir /home/SA/spam/* -D
/usr/bin/sa-learn --ham -u spamd --dir /home/SA/ham/* -D
#
# Then deleted the mails it learned from to prevent relearning the same thing and accumulating old mails
rm -r /home/SA/spam/* /home/SA/ham/*
# We let the users delete their own spam and ham mails.
# eof

IMPORTANT: In order for the spam filtering/Dovecot sieve to work you have to make sure that the following line is disabled or not present in /etc/postfix/main.cf
#transport_maps = proxy:mysql:/etc/postfix/mysql_virtual_transports.cf
If present and enabled this above line overwrites the setting of transport agent and prevents postfix from using ‘dovecot’ as local transport by using ‘virtual’ instead. It’s been fixed in the GroupOffice version 5.0.44.

Enabling DNS White List (DNSWL) in Postfix


Resources: http://www.dnswl.org
DNSWL.org provides a Whitelist of known legitimate email servers to reduce the chances of false positives while spam filtering. To enable it edit the file /etc/postfix/main.cf and add the following line right before the postgrey line as follows:
smtpd_recipient_restrictions =
......
permit_dnswl_client list.dnswl.org,
(postgrey line below)
check_policy_service inet:127.0.0.1:10023,
permit

OPTIONAL:
To force using TLS for delivering to selected destinations and fail sending the mail if the destination server doesn’t support it.
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
Content of /etc/postfix/tls_policy
example.com encrypt
.example.com encrypt

Hash the list:
postmap /etc/postfix/tls_policy

Allowing roaming SMTP use with SASL authentication

NOTE: Because the users’ credentials are stored in GroupOffice MySQL database we need to do the special authentication chain via dovecot which is configured to read Group Office database and its users data:
Configure SASL authentication
postconf -e 'smtpd_sasl_auth_enable = yes'
postconf -e 'smtpd_sasl_security_options = noanonymous'
postconf -e 'broken_sasl_auth_clients = yes'
postconf -e 'smtpd_sasl_type = dovecot'
postconf -e 'smtpd_sasl_path = private/auth'

Edit the file /etc/dovecot/conf.d/10-master.conf and enter inside the section ‘service auth {‘ insert the following lines as follows:

# Postfix smtp-auth
unix_listener /var/spool/postfix/private/auth {
mode = 0666
user = postfix
group = postfix
}

PROBLEM: After I upgraded GroupOffice to version 5.0.55 I was no more capable to login my mail accounts.
See solution in http://www.dovecot.org/list/dovecot/2012-June/066444.html
The /var/log/mail.log said:
..... inbox=yes namespace missing
The solution is:
Edit the file /etc/dovecot/conf.d/15-mailboxes.conf and right under the line:
namespace inbox {
Insert the line
inbox=yes

Raising the SMTP security with TLS encryption

This generates a self-signed certificate. It is strongly recommended to buy a proper CA signed certificate for that purpose especially if your mail clients are not very computer literates. The security warning messages appearing in their mail clients because of self-signed certificates might scare them and lose trust in your service.
Generating the self-signed certificate:
mkdir -p /etc/ssl/mailserver/
cd /etc/ssl/mailserver/
openssl genrsa 1024 > mail-key.pem
chmod 400 mail-key.pem
openssl req -new -x509 -nodes -sha1 -days 365 -key mail-key.pem > mail-cert.pem

Enter the information required for the self signed certificate.
IMPORTANT: Enter your host name when ‘Common Name’ is asked.
Configuring postfix for TLS
Run the commands:
postconf -e 'smtpd_use_tls = yes'
postconf -e 'smtpd_tls_session_cache_timeout = 3600s'
postconf -e 'smtpd_tls_cert_file = /etc/ssl/mailserver/mail-cert.pem'
postconf -e 'smtpd_tls_key_file = /etc/ssl/mailserver/mail-key.pem'
postconf -e 'smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache'
postconf -e 'smtpd_tls_security_level = may'
postconf -e 'smtpd_tls_loglevel = 0'
postconf -e 'tls_random_source = dev:/dev/urandom'
postconf -e '#smtpd_tls_CAfile = /etc/postfix/cert/cacert.pem'

IMPORTANT NOTE: The intermediate CA and Key of certificate MUST be included in the certificate file (CRT) if you dont specify it in smtpd_tls_CAfile and smtpd_tls_key_file.

You must also make sure the “permit_sasl_authenticated” is present in the “smtpd_recipient_restrictions” configuration option. Edit this option in /etc/postfix/main.cf and add it right after “permit_mynetworks”.

Edit the file /etc/postfix/master.cf and add the following lines:
# Added to allow postfix to also listen to port 587(submission) well as port 465(smtps)
587 inet n - - - - smtpd
465 inet n - - - - smtpd

Adding extra postfix server security


Recommendation for better security by OpenVAS
postconf -e 'disable_vrfy_command=yes'

Restart postfix and dovecot

/etc/init.d/postfix restart
/etc/init.d/dovecot restart

APACHE2 Configuration

Configuring Redirection of ALL HTTP requests to HTTPS

Commands:
a2enmod ssl rewrite
a2ensite default-ssl

Edit the file: /etc/apache2/sites-available/default-ssl
and add the following lines at the very end after </IfModule>.
# Redirecting all HTTP to HTTPs
<IfModule mod_rewrite.c>
<IfModule mod_ssl.c>
RewriteEngine on
RewriteCond %{HTTPS} !^on$ [NC]
RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI} [L]
</IfModule>
</IfModule>

Edit the file: /etc/apache2/sites-available/default
and add the following lines after LogLevel warn.
# Redirecting all HTTP to HTTPs
<IfModule mod_rewrite.c>
<IfModule mod_ssl.c>
RewriteEngine on
RewriteCond %{HTTPS} !^on$ [NC]
RewriteRule . https://%{HTTP_HOST}%{REQUEST_URI} [L]
</IfModule>
</IfModule>

Installing separate WebMail Interfaces

Configuration of RoundCube and Apache

Install Roundcube WebMail interface
apt-get install roundcube roundcube-plugins roundcube-plugins-extra
Prepare configuration for Roundcube and Apache
Edit file: /etc/roundcube/apache.conf
Uncomment the following 2 lines as follows:
Alias /roundcube/program/js/tiny_mce/ /usr/share/tinymce/www/
Alias /roundcube /var/lib/roundcube

Configuration of Squirrelmail and Apache

Installing Squirrelmail WebMail interface
apt-get install squirrelmail squirrelmail-decode
ln -s /etc/squirrelmail/apache.conf /etc/apache2/conf.d/squirrelmail

Optional:
For changing configuration of squirrelmail, run the command:
/usr/sbin/squirrelmail-configure

ADD authentication security to admin sites

Edit the file /etc/apache2/sites-available/default-ssl
and add the following lines at the very end:
# Authentication for private areas
<LocationMatch (/awstats|/awstats-icon|/mailgraph|/queuegraph|/phpmyadmin)>
AuthName "Private Area"
AuthType Basic
AuthUserFile /etc/apache2/web.auth
Require valid-user
</LocationMatch>

Run:
touch /etc/apache2/web.auth
For each admin user you need to create a password with this command
htpasswd /etc/apache2/web.auth <username>

Installing AWSTATS, MAILGRAPH and QUEUEGRAPH for Mail stats

As default Awstats creates a full new report at: 03:10 Hrs each day
it also refreshes the data every 10 minutes.

Installation:
apt-get install awstats mailgraph queuegraph
chown www-data. /var/lib/awstats
chmod o+r /var/log/mail.log

Edit /etc/awstats/awstats.local
Add the following lines:
# You can overrides config directives here.
# This is particularly useful for users with several configs for
# different virtual servers, who want to reuse common parameters.
# Also, this file is not updated with each new upstream release.
LogFile="perl /usr/share/doc/awstats/examples/maillogconvert.pl standard < /var/log/mail.log |"
LogType=M
LogFormat="%time2 %email %email_r %host %host_r %method %url %code %bytesd"
LevelForBrowsersDetection=0
LevelForOSDetection=0
LevelForRefererAnalyze=0
LevelForRobotsDetection=0
LevelForWormsDetection=0
LevelForSearchEnginesDetection=0
LevelForFileTypesDetection=0
ShowMenu=1
ShowSummary=HB
ShowMonthStats=HB
ShowDaysOfMonthStats=HB
ShowDaysOfWeekStats=HB
ShowHoursStats=HB
ShowDomainsStats=0
ShowHostsStats=HBL
ShowAuthenticatedUsers=0
ShowRobotsStats=0
ShowEMailSenders=HBML
ShowEMailReceivers=HBML
ShowSessionsStats=0
ShowPagesStats=0
ShowFileTypesStats=0
ShowFileSizesStats=0
ShowBrowsersStats=0
ShowOSStats=0
ShowOriginStats=0
ShowKeyphrasesStats=0
ShowKeywordsStats=0
ShowMiscStats=0
ShowHTTPErrorsStats=0
ShowSMTPErrorsStats=1
SiteDomain=mail.myserver.com
LoadPlugin="geoipfree"

Create the a Apache configuration file: /etc/apache2/conf.d/awstats
and add this following content:
# Configuration for email-AWSTATS, MAILGRAPH and QUEUEGRAPH
Alias /awstats /usr/lib/cgi-bin/
Alias /awstats-icon/ /usr/share/awstats/icon/
Alias /mailgraph /usr/lib/cgi-bin/mailgraph.cgi
Alias /queuegraph /usr/lib/cgi-bin/queuegraph.cgi
Alias /queuegraph.cgi /usr/lib/cgi-bin/queuegraph.cgi
#
<Directory /usr/lib/cgi-bin/>
Options +execCGI
AddHandler cgi-script .pl .cgi
DirectoryIndex awstats.pl
</Directory>

Restart Apache service

service apache2 restart

List of URLs for this mail server:

Group Office https://mail.myserver.com/groupoffice
Roundcube Webmail https://mail.myserver.com/roundcube
Squirrelmail Webmail https://mail.myserver.com/squirrelmail
Mail stats(Awstats) https://mail.myserver.com/awstats
Mail traffic graph https://mail.myserver.com/mailgraph
Mail queues graph https://mail.myserver.com/queuegraph

Group Office forum and wikis addresses

https://www.group-office.com/
https://www.group-office.com/forum/
https://www.group-office.com/wiki/
https://www.group-office.com/wiki/Mailserver

16 Mar 13 Installing an Ubuntu 12.0.4 LTS as Xen DOMu in Debian Squeeze hypervisor

Lately I needed to install Zimbra 8.0.3 which only installs easily in an Ubuntu 10.0.4 or 12.0.4 LTS system.
So I decided for that to install an Ubuntu 12.0.4 LTS as Xen DOMu in a Debian Squeeze Xen Hypervisor and here is how I did it.

The following commands can be put into a runnable bash script. Adapt the constants below to your system and simply run it, or simply(recommended) cut and paste the commands in bash terminal. Then afterwards (indicated below)inside the chroot the commands need to be done manually.

#!/bin/bash
# Settings some user changeble constants
virtbase=/virtual/xen
tempdir=/virtual/temp
VM=UBUNTU
#
# Installing required packages
apt-get update
apt-get install gnupg
#
# Creating, formating and mounting an empty 10GB VM
mkdir -p $virtbase/$VM
dd if=/dev/zero of=$virtbase/$VM/disk.img bs=1GB count=10
mkfs.ext3 $virtbase/$VM/disk.img
mkdir -p /mnt/$VM
mount $virtbase/$VM/disk.img /mnt/$VM -o loop,rw
#
# create and format a 2GB swap file
dd if=/dev/zero of=$virtbase/$VM/swap.img bs=1GB count=2
mkswap $virtbase/$VM/swap.img
#
# Creating a temporary ubuntu bootstrap environment
mkdir -p $tempdir
cd $tempdir
#
# Getting the ubuntu bootstrapper and keys
wget "http://de.archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.40~precise1_all.deb"
ar -xf debootstrap_1.0.40~precise1_all.deb
tar xzf data.tar.gz
tar xzf control.tar.gz
wget "http://archive.ubuntu.com/ubuntu/pool/main/u/ubuntu-keyring/ubuntu-keyring_2011.11.21.tar.gz"
tar xzf ubuntu-keyring_2011.11.21.tar.gz
#
# Bootstrapping Ubuntu system into the mounted empty VM
DEBOOTSTRAP_DIR=$tempdir/usr/share/debootstrap usr/sbin/debootstrap --arch amd64 --keyring=ubuntu-keyring-2011.11.21/keyrings/ubuntu-archive-keyring.gpg precise /mnt/$VM http://de.archive.ubuntu.com/ubuntu/
#
# Chroot to the new VM to prepare it
mount /sys /mnt/$VM/sys -o bind
mount /proc /mnt/$VM/proc -o bind
chroot /mnt/$VM/

From this point you need to cut-and-paste the commands in the console manually

Note: Ignore minor errors during apt-get install because we are in chroot and many things will not behave as normal but install properly.

Expand the repositories to get more packages to be available
sed -i 's/precise main/precise main restricted multiverse universe/' /etc/apt/sources.list
apt-get update

Remove server-useless resolvconf
apt-get remove resolvconf
Give a password to root user
passwd
Install the kernel and old grub(for virtual booting), ssh service and and some useful programs
apt-get install linux-image-virtual grub nano mc ssh fail2ban less manpages libgmp3c2 libperl5.14 sysstat sqlite3
Stop fail2ban
/etc/init.d/fail2ban stop
Add the correct mounts in /etc/fstab
echo "/dev/xvda1 / ext3 noatime,nodiratime,errors=remount-ro,usrquota,grpquota 0 1" > /etc/fstab
echo "/dev/xvda2 none swap sw 0 0" >> /etc/fstab

Create the grub config file
mkdir -p /boot/grub
nano /boot/grub/menu.lst

Content:
default 0
timeout 2
#
title Debian GNU/Linux
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro
initrd /initrd.img
#
title Debian GNU/Linux (recovery mode)
root (hd0,0)
kernel /vmlinuz root=/dev/xvda1 ro single
initrd /initrd.img

Here we need to configure the server name, and network addresses
Constants:(Create a script (/root/loadvars.sh) with the following content and fill in those Variables definitions accordingly.)
InternetIP=xx.200.75.211
LANIP=192.168.100.211
Gateway=xx.200.75.209
Broadcast=xx.200.75.223
Netmask=255.255.255.240
Hostname=ubuntu.myserver.com
DNS1=192.168.100.1
DNS2=xx.187.164.20
DNS3=xx.201.0.34
search="srv mysqrver.com"

Call/load the script which will set the proper variables for the processes below:
. /root/loadvars.sh

Configure the server name
echo "$Hostname" > /etc/hostname
echo "$Hostname" > /etc/mailname

Configure /etc/hosts
echo "$InternetIP $Hostname $(echo $Hostname | cut -d. -f1)" >>/etc/hosts
echo "$LANIP $(echo $Hostname | cut -d. -f1).srv" >>/etc/hosts

Configure the resolver
cat > /etc/resolv.conf << EOF
nameserver $DNS1
nameserver $DNS2
nameserver $DNS3
search $search
EOF

Configure the netwwork
cat > /etc/network/interfaces << EOF
# /etc/network/interfaces
auto lo
iface lo inet loopback
#
auto eth0
iface eth0 inet static
address $InternetIP
netmask $Netmask
broadcast $Broadcast
gateway $Gateway
#
auto eth1
iface eth1 inet static
address $LANIP
netmask 255.255.255.0
EOF

Leave chroot and unmount all of the VM
exit
umount /mnt/UBUNTU/sys
umount /mnt/UBUNTU/proc
umount /mnt/UBUNTU

Configure the xen configuration file for UBUNTU
Note: Replace the {InternetIP} and {LANIP} with the appropriate ones.
nano $virtbase/$VM/${VM}.cfg
Content:
bootloader = '/usr/lib/xen-default/bin/pygrub'
memory = '2500'
root = '/dev/xvda1 ro'
disk = [
'file:$virtbase/UBUNTU/disk.img,xvda1,w',
'file:$virtbase/UBUNTU/swap.img,xvda2,w',
]
name = 'UBUNTU'
vif = [ 'ip={InternetIP},mac=00:16:3E:3D:6B:11,bridge=eth0' , 'ip={LANIP},mac=00:16:3E:D7:9C:11,bridge=dummy0']
on_poweroff = 'destroy'
on_reboot = 'restart'
on_crash = 'restart'
vnc = 0
vncunused = 0
extra = "console=hvc0"
vcpus = 1
cpus ="1"

Create a symlink of the xen config file
ln -s $virtbase/$VM/${VM}.cfg /etc/xen/${VM}.cfg
Start the VM
xm create /etc/xen/${VM}.cfg
Connect to the VM via SSH
ssh root@$LANIP
(Give the root password you configured with passwd previoulsy)