pk stuff

Copied from JP Houde’s blog:

I recently needed to configure Xen guests on a CentOS server. I didn’t want to use CentOS/Redhat’s tool for several reasons : I don’t like the fact that it creates a “disk” with a whole partition table within the partition where you install it. Installing the guest directly on a LVM logical volume seems better to me (I may not be right, I’m still somewhat new to Xen!). Also, it was very instructive to do all the steps by myself rather than using a tool that does everything.

However, I had several problems while trying to install my first guest system, so it took me quite some time to find the right way to do it. I found a lot of documentation on the web, but nothing really described what I really wanted to do. So here we are, I decided to write a post describing what to do exactly to make a custom guest image and install it as a Xen domU.

In this first part, I will explain how to make an OS image of CentOS 5 that will be suited for Xen.

Ready to use images

Jailtime.org offer Xen images for several operating systems, including CentOS 4 and 5. However, only 32-bit images are available. If 32-bit images are OK for you, I recommend that you use the jailtime images : it will be a lot easier.
A note about the jailtime.org CentOS image : I found that the console was not working on boot. The OS seemed to just hang after starting SSHD, but in fact, it was just that there was no console for Xen to connect to. If you have this problem, see the part about configuring the console in the “Custom CentOS 5 image” section of this article.

Custom CentOS 5 image

Since I wanted 64-bit domUs, I decided to make my own images. There are few things that need to be modified to make a standard CentOS installation work as a Xen domU. Here are the steps needed to make your own image with yum.

Prepare the environment

1. Prepare a directory where you will store your image. I will use /mnt/centos.
   Note that you may want to chroot into the image when you need to work within it only. To do so, type :
   cd /mnt/centos; chroot .
   (Don’t chroot now, since there’s nothing in there for now)
2. Create a special yum configuration file. We need a yum.conf file with “hard coded” architecture and version, instead of the variables the default yum.conf file contains.
   Create /etc/yum-xen.conf with the following content.

   [main]
   cachedir=/var/cache/yum
   keepcache=1
   debuglevel=2
   logfile=/var/log/yum.log
   pkgpolicy=newest
   distroverpkg=redhat-release
   tolerant=1
   exactarch=1
   obsoletes=1
   gpgcheck=1
   plugins=1
   metadata_expire=1800[base]
   name=CentOS-$releasever - Base
   mirrorlist=https://mirrorlist.centos.org/?release=5&arch=x86_64&repo=os
   gpgcheck=1
   gpgkey=https://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
   #released updates
   [updates]
   name=CentOS-$releasever - Updates
   mirrorlist=https://mirrorlist.centos.org/?release=5&arch=x86_64&repo=updates
   gpgcheck=1
   gpgkey=https://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5
   #packages used/produced in the build but not released
   [addons]
   name=CentOS-$releasever - Addons
   mirrorlist=https://mirrorlist.centos.org/?release=5&arch=x86_64&repo=addons
   gpgcheck=1
   gpgkey=https://mirror.centos.org/centos/RPM-GPG-KEY-CentOS-5

3. Install the core packages.
   We will use yum to install a core CentOS system in our target directory.

   yum -c /etc/yum-xen.conf --installroot=/centos -y groupinstall core --disablerepo=extras

   Here, we disable the “extras” repository since we don’t need it, and the variables it contains will make yum fail. You may need to disabled other repositories if you have installed custom ones.

You should now have a base system in your /centos directory ! But that’s not all, we need to modify few things to make our system suitable as a Xen guest.

Changes needed to the base system

As said earlier, you should now chroot in the /centos directory for the next steps. If you don’t do that, you could end up modifying your host OS instead of the image.

1. Console
   You need to add a console to /etc/inittab, or Xen won’t display any login prompt when the image boot. You can also remove the default TTYs (tty1-tty6), since they won’t be needed in a Xen guest.

   # add a console for xen
   co:2345:respawn:/sbin/mingetty console
   # comment out the default TTYs
   #1:2345:respawn:/sbin/mingetty tty1
   #2:2345:respawn:/sbin/mingetty tty2
   #3:2345:respawn:/sbin/mingetty tty3
   #4:2345:respawn:/sbin/mingetty tty4
   #5:2345:respawn:/sbin/mingetty tty5
   #6:2345:respawn:/sbin/mingetty tty6

2. You need to disabled TLS (it would slow down the guest)

   # for 32 bit :
   mv /lib/tls /lib/tls.disabled
   # for 64 bit :
   mv /lib64/tls /lib64/tls.disabled

3. Disable the hardware clock
   The Xen domU will use the host’s clock, so we replace hwclock with an empty shell script

   echo exit 0 > /sbin/hwclock

4. Disable udev in /etc/rc.sysinit
   Apparently udev is problematic with Xen, so we will comment the line where it’s started in rc.sysinit (line 338):

   #/sbin/start_udev

   UPDATE 2008-02-14 : It seems that it may be a good idea to leave udev enabled after all… I’m getting permissions problem on devices such as /dev/null without udev. Enabling it fix the problem, and does not seem to cause any other problem.

5. Network configuration.
   If you want, you can define network parameters.
   /etc/sysconfig/network-scripts/ifcfg-eth0

   TYPE=Ethernet
   DEVICE=eth0
   BOOTPROTO=static
   BROADCAST=192.168.0.255
   IPADDR=192.168.0.13
   IPV6ADDR=
   IPV6PREFIX=
   NETMASK=255.255.255.0
   NETWORK=192.168.0.0
   ONBOOT=yes

   /etc/sysconfig/network

   NETWORKING=yes
   HOSTNAME=myhost.l3i.ca
   GATEWAY=192.168.0.1

   /etc/resolv.conf (DNS resolver)

   nameserver 4.2.2.1
   nameserver 4.2.2.2

6. SELinux
   You may want to disabled SELinux. That’s done in /etc/sysconfig/selinux (put SELINUX=disabled)
7. Root password
   We need to create a root password and create the password database (or we wouldn’t be able to log in the system).

   pwconv
   passwd root

8. Create the /etc/fstab file.
   In this file, /dev/sda1 is the root (ext3) filesystem and sda2 is swap. You will need to configure Xen with these device names.

   cat > /etc/fstab
   # This file is edited by fstab-sync - see 'man fstab-sync' for details
   /dev/sda1               /                       ext3    defaults 1 1
   /dev/sda2               none                    swap    sw       0 0
   none                    /dev/pts                devpts  gid=5,mode=620 0 0
   none                    /dev/shm                tmpfs   defaults 0 0
   none                    /proc                   proc    defaults 0 0
   none                    /sys                    sysfs   defaults 0 0
   #(press CTRL+D to end "cat")

9. Disable HAL
   HAL will fail, so let’s just disable it.

   /sbin/chkconfig haldaemon off

10. SSH
    A note about SSH : it will fail to generate a key on the first load because there is not /dev/urandom device. You will have to fix it after starting the domU, on the console. The following command will fix it :

    /sbin/MAKEDEV generic
    /etc/init.d/sshd start

You now have an image ready to be used as a Xen guest! Be sure to keep a copy before using it as a domU, so when you need to install another guest, you will have an image ready for it and won’t need to repeat these steps all over again.

Here is a link to an image I made myself using this procedure. You can use it if you don’t want to make your own. It is a 64-bit CentOS 5 core system, and the root password is “zaqxsw”.

In part 2, I will explain how to install a Xen guest from this image. (coming soon!)

I’m always on the prowl for new, better tools, especially for C++ development under Linux. While I’ve used vi for decades, my years spent with Visual Studio have left me wanting more.

I’ve tried several commercial and open source C++ IDEs on Linux, from Borland’s C++Builder to KDevelop and of course Eclipse/CDT and found all less than ideal, either because they were too cumbersome, too general or too awkward. Vi and emacs were stiil my editors of choice.

Then one day I stumbled across Code::Blocks and was immediately impressed. Here was a nice, lightweight IDE specifically targeting C++, with good support for existing makefile projects, mutliple compilers and platforms. I used it regularly for about a year until one day I tried browsing Google’s V8 and failed miserably. That’s when I realized Code::Blocks doesn’t support ctags and its own “tag” engine is broken. Googling turned up references to a C::B search plugin but I couldn’t find any code – guess the project stalled.

In fact the project hadn’t stalled but had instead morphed into a complete C++ IDE: codelite. It’s amazing what Eran and his crew have been able to accomplish. Most of the functionality of Code::Blocks is there plus superb search tools.

If you’re developing in C++ you owe yourself the favor of checking it out:

https://codelite.org

Intermittent problems with a USB drive attached to an Acer desktop running Ubuntu appear related to a long-standing issue with the ehci_hcd driver.

After much googling, the fix is to add acpi=noirq to the kernel boot line in /boot/grub/menu.lst.

title           Ubuntu 8.04.1, kernel 2.6.24-19-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.24-19-generic root=/dev/sda1 ro acpi=noirq
initrd          /boot/initrd.img-2.6.24-19-generic

Copied from others:

I’m getting this problem too after just having upgraded some packages on the host node. The fact that this can be corrected by entering the VPS and running any rpm command makes it look suspiciously like a bug. Any rpm database inside a VPS is somehow left in an inconsistent state. Of course, this makes vzyum unusable. Does vzyum need an upgrade in order to handle this?

vzyum 139 install wget

Yields:

exec /usr/share/vzyum/bin/yum -c /vz/template/centos/5/i386/config/yum.conf --installroot /vz/root/139 --vps=139 install wget
rpmdb: unable to initialize mutex: Invalid argument
rpmdb: PANIC: Invalid argument
rpmdb: PANIC: DB_RUNRECOVERY: Fatal error, run database recovery

—

I’ve experienced the same behavior and found that a simple
rpm -qa run inside the VE (either via ‘vzctl exec’ or entering the VE and running it inside) solves the issue

update: unfortunately, this fix isn’t permanent and the issue reappears as soon as the VE is restarted as mentioned above
At least this workaround doesn’t need the installation of yum inside the VE

Somehow my ThinkPad (T60p) desktop never seems big enough so whenever possible I like to plug in a second monitor. Until recently, Ubuntu required all sorts of messing around in xorg.conf, but fortunately the situation is somewhat improved with Hardy. To be fair, much of this configuration mess is probably due to ATI’s less than stellar Linux support, which is slowly improving.

First, always backup your existing /etc/X11/xorg.conf !!!  Virtually every screen config tool I’ve used under Linux has ultimately toasted my xorg.conf file.

I found “amdcccle” produced the best results, with Compiz still operational.

Others may prefer “aticonfig –initial=dual-head“, which also worked but left my Compiz out of action.

Both are far from perfect and this is one area where Ubuntu (and other distros) still lag far behind Windows and OSX.

While CentOS stability is great, some packages are considerably behind those available in Fedora. EPEL and Dag provide a great selection of backported RPMs.

To install EPEL:

rpm -Uvh https://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-3.noarch.rpm

And Dag:

rpm --import https://dag.wieers.com/rpm/packages/RPM-GPG-KEY.dag.txt
wget https://apt.sw.be/redhat/el5/en/i386/RPMS.dag/rpmforge-release-0.3.6-1.el5.rf.i386.rpm
rpm -K rpmforge-release-0.3.6-1.el5.rf.i386.rpm
rpm -i rpmforge-release-0.3.6-1.el5.rf.i386.rpm

And Remi:

wget https://rpms.famillecollet.com/enterprise/remi-release-5.rpm
rpm -Uvh remi-release-5.rpm

Bundle EC2 image and save it to S3 :

/etc/init.d/mysql stop # make sure mysql is not running

ec2-bundle-vol -d /mnt -k /mnt/<your pk>.pem 
    -c /mnt/<your cert>.pem -u <your AWS account name> -r i386
ec2-upload-bundle -b <your-s3-bucket> -m /mnt/image.manifest.xml 
    -a <your AWS access key ID> -s <aws-secret-access-key>

register your AMI :

ec2-register <your s3 bucket>/image.manifest.xml

This is too good to risk losing so I’m reproducing the recipe here.
For my needs, I was able to skip a few steps by using root and by using screen session ids.
Here is the original article (with a couple of minor changes):

Assume user jsmith wants to share his terminal session with remote user bjones for training or troubleshooting purposes, but does not want to use VNC or other full-blown GUI remote control access.

Requirements:
– GNU Screen
– Local account on host computer for remote user (i.e. bjones requires local account)

1. Install screen

sudo apt-get install screen

2. Set the screen binary (/usr/bin/screen) setuid root. By default, screen is installed with the setuid bit turned off, as this is a potential security hole.

sudo chmod +s /usr/bin/screen
sudo chmod 755 /var/run/screen

3. The host starts screen in a local xterm, using the command screen -S SessionName. The -S switch gives the session a name, which makes multiple screen sessions easier to manage.

screen -S screen-test

4. The remote user (bjones) uses SSH to connect to the host computer (jsmith).

ssh [email protected]

5. The host (jsmith) then has to allow multiuser access in the screen session via the command CTRL-A :multiuser on (all ‘screen’ commands start with the screen escape sequence, CTRL-A).

CTRL-A
:multiuser on

6. Next, the host (jsmith) must grant permission to the remote user (bjones) to access the screen session using the commadn CTRL-A :acladd user_name where user_name is the remote user’s login ID.

CTRL-A
:acladd bjones

7. The remote user can now connect to the hosts ‘screen’ session. The syntax to connect to another user’s screen session is screen -x host_username/sessionname.

screen -x jsmith/screen-test

Every once in a while archives contain DOS formatted text files – they contain carriage returns in addition to Unix-style linefeeds. Depending on the project, these may cause all sorts of subtle problems.

The following command recursively strips carriage returns from all files in this and lower folders.

find . -type f -exec dos2unix '{}' ;