As a Linux enthusiast and Gentoo user I was always looking for the perfect boot experience. While I managed to boot my kernel with EFI and grub 2 (as described in my wiki), I still had some troubles with OpenRC playing nice with my LVM-only setup initialized by dracut. Tonight I finally figured out the missing configuration pieces to shut up all warnings on system init.

Initial situation All my Linux partitions are stored in a single LVM volume group, to stay as flexible as possible:

merkur ~ # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT [...] └─sda5 8:5 0 49.5G 0 part ├─vg_merkur-slash (dm-0) 253:0 0 2.5G 0 lvm / ├─vg_merkur-boot (dm-1) 253:1 0 200M 0 lvm /boot ├─vg_merkur-tmp (dm-2) 253:2 0 6G 0 lvm /tmp ├─vg_merkur-swap (dm-3) 253:3 0 4G 0 lvm [SWAP] ├─vg_merkur-var (dm-4) 253:4 0 4G 0 lvm /var ├─vg_merkur-usr (dm-5) 253:5 0 12.8G 0 lvm /usr └─vg_merkur-opt (dm-6) 253:6 0 8G 0 lvm /opt

My boot toolset currently consists of grub-2.00-r1, kernel-3.6.4, dracut-024, lvm-2.02.95-r4 and openrc-0.11.2

Kernel Configuration Before compiling the kernel, make sure to include all the required configurations. For this setup, the most important ones are:

CONFIG_BLK_DEV_INITRD CONFIG_DEVTMPFS CONFIG_MODULES CONFIG_SYSVIPC Dracut Configuration Before installing dracut, the desired modules have to be configured in /etc/make.conf. :

DRACUT_MODULES="caps lvm mdraid syslog"

For this setup at least the “lvm” module is mandatory. Further dracut was built with the “device-mapper” USE flag enabled.

Altough some Linux developers (especially from Red Hat/Fedora) advice against a separate /usr partition because of many boot time dependencies on this system path, I didn’t bother much to change my years old setup. Since version 014, dracut includes a module to fill this gap (/usr/lib/dracut/modules.d/98usrmount/mount-usr.sh). It simply mounts the /usr partition right after the root file system early in the boot process. Therefore we have to make sure that the dracut modules “usrmount” and “lvm” are included in the initramfs, which was possible without any manual modification of /etc/dracut.conf, when generating the boot image with:

dracut -H Kernel Command Line Configuration Dracut runtime parameters are given on the kernel command line in the Grub configuration. To automatically enable the LVM Volume Group and spawning a debug shell in case the boot should fail, I added the following parameters in grub:

root=/dev/vg_merkur/slash rd.lvm.vg=vg_merkur rd.shell LVM Configuration Since dracut is now responsible to enable our volume group, the corresponding init script has to be disabled:

rc-update del lvm boot Fsck and Fstab When booting the system now, the /etc/init.d/fsck script will complain that it cannot check the file systems which are already mounted. Fortunately, the init script allows us to define that fsck should be only run when specific “fs_passno” values are set. I therefore this value to “1” for the file systems which are mounted by dracut and to “2” for all the file systems which should be checked by OpenRC. Take care, when specifying a value of “0”, the file system will be never checked for consistency:

# [fs] [mountpoint] [type] [opts] [dump/pass] /dev/vg_merkur/boot /boot ext2 noatime,nosuid,nodev 0 2 /dev/vg_merkur/slash / ext4 noatime,discard 0 1 /dev/vg_merkur/usr /usr ext4 noatime,discard,nodev 0 1 /dev/vg_merkur/var /var ext4 noatime,discard,nosuid,nodev 0 2 /dev/vg_merkur/opt /opt ext4 noatime,discard,nosuid,nodev 0 2 /dev/vg_merkur/tmp /tmp ext4 noatime,discard,nosuid,nodev 0 2 /dev/vg_merkur/swap none swap sw 0 0

In /etc/conf.d/fsck we then can define, that the fsck init script should only care about file systems with a “fs_passno” larger than “1”:

fsck_passno=">1"

That’s it… If you have some questions or hints, please leave a comment.

Ever heard about the “Busy Beaver Problem”? Interesting introduction and visualization with lots of source code (Python, C++, Perl)

catonmat.net: The Busy Beaver Problem

Since I was using the nice FineGradePermissions feature of the trac 0.11 release, and Debian was only providing trac-0.10.3 in Etch, I had a custom trac installation running on my Etch server. For migrating to Lenny you would normally think that it’s enough to just copy your project directory to the new installation. Unfortunately this results in a nasty error message:

DatabaseError: file is encrypted or is not a database

Hmn, so let’s check the trac migration guide which advises you to first export the sqlite database with sqlite3 in a plain SQL file. Not much luck here either, the result is an empty database: `

sqlite3 trac.db .dump

BEGIN TRANSACTION; COMMIT; `

The reason is the trac installation in Etch was using the python-sqlite-1.0.1 back-end which uses the SQLite 2 format while in Lenny there is python-pysqlite2-2.4.1 which only knows about SQLite 3.

The conversion from SQLite 2 to 3 can be done by first exporting the database with the sqlite tool and then re-importing it with sqlite3: `

sqlite trac.db .dump | sqlite3 trac3.db

`

More infos about this can be found at the trac upgrade notes from 0.8.x to 0.9.

Finally your trac installation should work again as usual.

Xen is nowadays a widespread approach to run virtual hosts. Thanks to its flexible configuration it’s not only possible to run virtual Linux hosts but nearly any operating system that is compatible to the Xen hypervisor machine architecture will possibly run as guest host. The Xen paravirtualization feature, which provides a tighter association between the hypervisor and the guest kernel makes it especially interesting for running performance critical Linux guests.

For using Xen virtualization a separate patchset always had to be applied to the hypervisor and also the paravirtualized Linux kernel. Because of this it wasn’t always easy to migrate physical servers into virtual one’s, especially when requiring a special kernel version or another profound Linux patchset.

What is paravirt_ops? Paravirt_ops is a generic kernel structure that represents an interface to a virtualization hypervisor. It allows the kernel to run natively on the hardware but also virtual on a hypervisor. Since kernel 2.6.23 paravirt_ops support for Xen is integrated into the vanilla kernel and since then also support for VMI (VMware) and KVM was added. It is a first step to integrate full Xen compatibility into the mainline kernel tree. Today, with kernel 2.6.27, Xen paravirt_ops support exists at least for the x86 and x86_64 architecture.

How can I use the vanilla kernel as Xen domU? If you build the kernel by yourself, like every real man does, you have to activate the following features. Build the support directly into the kernel that you don’t have to fiddle around with an initramfs.

Processor type and features  --->
[*] Paravirtualized guest support  --->
--- Paravirtualized guest support
[*]   Xen guest support
...
[*] PAE (Physical Address Extension) Support

Device Drivers  --->
[*] Block devices  --->
<*>   Xen virtual block device support
...
[*] Network device support  --->
<*>   Xen network device frontend driver
...
Character devices  --->
[*] Xen Hypervisor Console support

Now we’re nearly done with it. After compiling the kernel we need to do some small changes concerning the console redirection in the baselayout of the Linux guest. In the future the distributions will likely prepare this for us.

Add hvc0 device node:

root # cd /dev
root # mknod hvc0 c 229 0
root # chown root:tty hvc0
root # chmod 600 hvc0

To change default console to hvc0 you have to edit the /etc/inittab. If not done already, disable all the other virtual consoles:

co:12345:respawn:/sbin/agetty 38400 hvc0 vt100-nav
#2:23:respawn:/sbin/agetty 38400 tty2
#3:23:respawn:/sbin/agetty 38400 tty3
...

Finally permit login on the hvc0 console by adding it to /etc/securetty.

Now we should be able to boot our paravirt_ops system on real hardware the same as on a Xen hypervisor. However compared with a Xen-patched paravirtualized kernel, the paravirt_ops kernel doesn’t support special features like framebuffer support or live migration.

Links: lwn.net - Connecting Linux to hypervisors linuxmonk.ch/trac - Building paravirt_ops domU kernel from vanilla sources

Recently I wanted to set up a testing server for the different virtualization techniques for Linux. For this I have an Asus P5LD2 mainboard with an Intel dual core Pentium D 3,2 GHz which supports the Virtual Machine Extensions (VMX). Thanks to this I can compile Xen with the ‘hvm’USE-flag and run fully virtualized guest operating systems on my Xen supervisor. This means I could run nearly every i386 compatible operating system (even Windows ;-) ) in my Xen environment. Without such hardware every guest operating system has to have a Xen enabled kernel.

Another approach with the same result is the open source project QEMU. Its abstraction level is higher than with Xen and it can even emulate different target architectures from your current x86 host. So far x86_64, ARM, SPARC, PowerPC, MIPS and M68k target systems are supported. Its guest operating system does not need any single change to run on QEMU. This makes it very comfortable to test new live CDs or operating system images. But it is not so trivial to setup QEMU and Xen together on a Gentoo machine.

How to setup QEMU on 32bit Gentoo in Xen dom0?

If you compile Xen on a 32bit host you have to add ‘-mno-tls-direct-seg-refs’ to your CFLAGS. That is because the glibc TLS library is implemented in a way that will conflict with how Xen uses segment registers. For compiling the non-patched QEMU 0.9.0 you have to use a gcc version 3.x. The nowadays default gcc 4.x is not yet supported. After several compile failures I finally found to setup QEMU the following way:

1. For compiling gcc-3.x remove the ‘-mno-tls-direct-seg-refs’ from /etc/make.conf and set the ’nossp’ and ’nopie’ USE-flags. Otherwise gcc or later qemu will not compile.

2. Switch to gcc-3.x before compiling qemu-softmmu, qemu-user and qemu. In my case it’s: gcc-config i686-pc-linux-gnu-3.3.6 3. Check your CFLAGS again because the optimization flags for gcc 4.x are not always backwards compatible to gcc-3.x. In my case the make.conf looks like this:

# gcc-3.x
CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs"

# gcc-4.x for compiling gcc-3.3
#CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer"

# gcc-4.x
#CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer -mno-tls-direct-seg-refs"

4. Now you can compile QEMU. Do not forget to switch back to your original CFLAGS and gcc-4.x after successfully emerging QEMU. I recommend to you to also build the QEMU kernel accelerator module kqemu which has to be compiled with the same compiler as the kernel itself.

Now Xen and QEMU are able to run whatever operating system image you give them. Have fun with playing around…

Additional links:

• gentoo-wiki.com - Xen
• wiki.xensource.com - HVM Compatible Processors
• gentoo-wiki.com - QEmu

For organizing our move to the shared flat I was looking for a small, simple to use Wiki for collecting ideas and coordinating our flat inventory. After a little search I found DokuWiki. It can be easily installed by every Linux distribution’s package manager. Unfortunately the stable Debian package was not the newest version and annoyed me with banners that there are some upgrades available. So I tried again with the newest version from the developers site. After unpacking, the directory has to be made accessible through your Web server and after running the install.php where you actually only create the administrator user, the Wiki is already prepared to use. In the default configuration there is no database needed. But the strength of this Wiki is that it can be expanded by more sophisticated configurations using MySQL or an LDAP back-end for user administration. The syntax is quite simple and similar to other Wiki systems. Also my friends were surprised by the usability of this piece of Open Source software. So if you are planning to use a powerful but simple Wiki software, keep an eye on DokuWiki.

This information is for all of you quite boring I know, but it is a happy thing for me. Finally my Xen domain, where I am hosting this Web site, has its own static public IP (193.138.215.129). Now I am ready for running all possible Internet services depending how I feel like. My first plan will be an own mail server with qmail. I am open about some tricks and hints about this. I eventually also found a domain name that suits for this site. When I do not change my mind again, the blog will be soon available under http://www.linuxmonk.ch.

There is a lot changing in my life at the moment so stay tuned for some more news later…

Most of you may have a similar problem. A lot of friends are present in the Internet but all of them use a different instant messenger. There are ICQ, MSN, Yahoo Messenger, Jabber and a lot more. With multi-protocol messenger like Pidgin (former Gaim) or Adium it is not that laborious to manage all your contacts anymore. But still you would like to reduce your number of accounts as much as possible.

Once more open source software gives an example how it could be. The protocol is called XMPP and originally used by Jabber. When Google introduced their own messenger GoogleTalk in 2005 they made the wise decision to also use XMPP instead of inventing a new protocol. The next big thing is that everybody with a Gmail account can also use this credentials for GoogleTalk. One account connects you to your friends of two networks. Why is not everything in information technology so handy?

Now you are maybe wondering that Gaim/Pidgin does not support GoogleTalk. But it does support Jabber/XMPP. So it is an easy thing to set up your GoogleTalk account. Enter your Gmail address as “Screen Name”; the server is not “jabber.org” but “gmail.com” and the connect server is “talk.google.com”. As resource you can leave “Home”. Finished and ready for chatting…

I think everybody that runs an own Linux server with the SSH daemon listening on port 22 is sooner or later annoyed by the amount of password attacks done by bots somewhere out in the Internet. What can you do against it?

Blocking via iptables ‘recent’ module How you can do this on a Gentoo system is described in the Gentoo Wiki here. Because it blocks the connection attempt only due to the number of tries within a certain time it is a very basic solution and needs quite a lot of testing to examine the good parameters for the ‘hitcount’ and ‘seconds’ arguments. You do not unintentionally want to block yourself when you only try to open several connections within a short time period. So not really the thing I recommend here.

Log parsing with sshguard sshguard uses another approach. It parses the SSH log messages and searches for login failures. For example when you try to connect with a non-existent user sshguard catches it and creates an iptables deny rule. But also sshguard has a small design mistake. It wants you to create a sshguard chain in iptables and redirect all the traffic to the chain assuming that your default INPUT policy is ACCEPT. When it wants to block a host it runs iptables -A sshguard -s host-to-block -j DROP. In case you have your policy set to DROP you cannot configure the iptables to accept the allowed SSH traffic because else the blocking rules will not work anymore. I made a small patch to change the blocking command to insert the rule in first place of the chain. After you applied the patch you have to make sure that you setup your iptables the following way:

iptables -N sshguard iptables -A sshguard -j ACCEPT iptables -A INPUT -p tcp --dport ssh -j sshguard

Further you have to edit your system logger configuration file. Please read the documentation.

For all the lazy people I even made a Ebuild that also adds a second patch where you can disable the IPv6 ability of sshguard. You can find it here.

YES, YES, YES! Finally I made it.

Since a while I am playing with the migration functionality of a Xen domU between two Xen servers. It allows to move a virtual machine without reboot between two physical machines. But my problem was: It did not hold what it promised.

Trying all possible versions of Xen and the xen-sources in the Gentoo Portage I was able to migrate a domU but not when it was configured as SMP machine. After I found that the kernel has to include the CONFIG_HOTPLUG_CPU option, I was able to migrate the domU at least one time from one host to the other. When repeating this procedure the domU crashed with a kernel oops. By finally trying the latest Xen 3.1 version from the unofficial mescalito portage overlay with the xen-sources-2.6.18, repeated migration of a domU between the Xen servers does work now. Prerequisite is that both dom0 and domU run the 2.6.18 kernel. I am trying to run this in production now and will see how reliable it is.

I just remember that I did also remove the memory restriction from the dom0. The dom0_mem parameter in the grub configuration is optional and when omitting it the dom0 can use the unused memory for itself.