When (re-)building RPMS on CentOS, you need one of the buildsys-macros packages to be installed so the correct macros are defined:

http://buildsys.fedoraproject.org/buildgroups/rhel5/x86_64

We're in the process of rolling out a redundant switch configuration in the data centre. As a part of this, we're re-configuring all our servers with bonded NICs. I ran into a bit of a problem with our xen machine in that I couldn't add a bonded interface to a bridge, which is required for xen networking.

It turns out that a patch to the ifcfg-eth script fixes the issue by creating the bonded interface before creating the birdges.

The patch is here:

http://git.fedorahosted.org/git/?p=initscripts.git;a=commitdiff;h=f9cfaa365ee15b7cb4585f5220702ac5f39c2743

I recently followed this guide to create a custom CA root certificate: http://sial.org/howto/openssl/ca/

One thing that is missing is how to install the certificate on all client machines.

The best I could come up with was to append the certificate to the CA bundle supplied with openssl:

openssl x509 -in ca-cert.pem -text >> /etc/pki/tls/certs/ca-bundle.crt

Anyone got a better idea?

I wanted to create a secure place to store ssl keys, etc. I decided to create an lvm logical volume and encrypt it. Here's what I did:

1. Create the logical volume (LV):
   lvcreate --size 5G --name lv_secure vg_name
2. Encrypt the LV:
   cryptsetup luksFormat /dev/vg_a001/lv_secure
3. Verify the LV is encrypted:
   cryptsetup isLuks /dev/vg_a001/lv_secure && echo Success
4. Open the secure volume and create a mapped device named "secure":
   cryptsetup luksOpen /dev/vg_a001/lv_secure secure
5. Get info about the mapped device:
   dmsetup info secure
6. Create an ext3 file system on the mapped device:
   mke2fs -j /dev/mapper/secure
7. Mount the mapped device:
   mkdir /mnt/secure
mount /dev/mapper/secure /mnt/secure
8. When you are done, unmount and close the secure device:
   umount /mnt/secure
cryptsetup remove secure
    

 

It seems that the latest Sun Java release includes a native 64-bit plugin for Firefox. Yay!

I first read about this here: luke.faraone.cc/2009/01/native-64bit-java-plugin-in-ubuntu/

However, the instructions in that article didn't quite work for me on Ubuntu Intrepid 8.10.

Here's what I did:

wget http://www.java.net/download/jdk6/6u12/promoted/b03/binaries/jre-6u12-ea-bin-b03-linux-amd64-22_dec_2008-rpm.bin
sh jre-6u12-ea-bin-b03-linux-amd64-22_dec_2008-rpm.bin
fakeroot alien jre-6u12-ea-linux-amd64.rpm
sudo dpkg -i jre_1.6.0_12-1_amd64.deb
sudo update-java-alternatives  -s java-6-sun
sudo ln -s /usr/java/jre1.6.0_12/lib/amd64/libnpjp2.so /usr/lib64/firefox-3.0.5/plugins/

Then restart Firefox.

In my new job, I was provided with a VMWare image running Ubuntu 7.10 which contains my own dev environment. I wanted to run it using VirtualBox instead of VMWare. The migration was fairly straight-forward since VirtualBox can read VMWare disk files. However, networking didn't work.

I found the answer here: http://mydebian.blogdns.org/?p=177#comments

Basically, it was due to persistent udev rules. To fix it, I did this:

1. sudo rmmod e1000
2. sudo rm /etc/udev/rules.d/70-persistent-net.rules
3. sudo modprobe e1000
4. sudo /etc/init.d/networking restart

Et viola!

This is one of those "I've done it several times but don't do it often enough to remember" things!

I wanted to set up NFS on a dev server and mount it on my workstation - both machines running Ubuntu.

This link the necessary info at a suitable level of detail:

www.quietearth.us

yum uses gpg signatures to verify the integrity of rpm packages installed from yum repos. In order to use them, the GPG public key must first be imported into the rpm db. However, this is a rather "dumb" operation - no checks are made to prevent the same key being imported multiple times. Duplicate (or triplicate, or quadruplicate, etc.) keys do not cause any problems, but are unnecessary clutter in the rpmdb.

Here's how to check if a public key has already been imported into the rpmdb.

In earlier versions of xen, the default network setup was a bridge - the domU guests attached to the bridge and were not affected by the firewall on dom0.

In recent versions (> 3.1.x, I think) with libvirt, the default set up is slightly different - the standard libvirt installation provides NAT based connectivity to virtual machines through virbr0, which has an IP address of 192.168.122.1. This is all described on the libvirt networking page.

However, I'd tried this set up several times before and always had problems - specifically, the bridge would not start automatically at boot, it failed and had to be brought up manually post-boot.

Today, I decided to dig in and get to the bottom of the issue. I hopped onto the  #virt IRC channel on ORTC and asked for help. As luck would have it, danpb was in there and worked through things with me. The breakthrough was when he said:

<danpb> you have got ifcfg-br0 using  TYPE=Bridge, and not  TYPE=BRIDGE  right ?
<danpb> it is stupidly case sensitive

I was actually using "TYPE=bridge". I made the change and rebooted and it worked!

Dan has since added a note about this to the wiki page.

One further useful tip: if you don't need libvirt's NAT network then you can remove it:

virsh net-destroy default

Or disable it, but leave it defined:

virsh net-autostart --disable default

Then restart libvirtd to see it disappear:

service libvirtd restart

I decided it was time to sort out my xen box (a quad core, 8GB machine I use to run several virtual machines under xen).

It was previously running CentOS 5.2 with xen 3.1.2 that I built myself from Fedora RPMS; I decided it was time to do a fresh install and to upgrade to xen 3.3.

This proved to be remarkably trivial, having found the gitco repository, which has x86_64 RPMs for xen 3.3 and libvirt 0.4.4. Simply do a minimal CentOS 5.2 install, including the xen kernel, add the gitco repository to your yum config, and install:

yum install xen xen-libs libvirt python-libvirt python-virtinst

There was one small gotcha - the install process doesn't modify the grub config to boot from the correct xen kernel image. The symptoms are that xend won't start (you see permission denied errors) and virsh list results in errors in /var/log/xen/xend-debug.log like:

sysctl operation failed -- need to rebuild the user-space tool set?
Exception starting xend: (13, 'Permission denied')

Once you've realised what the problem is, the fix is straight-forward. This link was helpful. So, simply modify /boot/grub/grub.conf, changing the kernel line to boot the correct xen kernel image, e.g.:

title CentOS (2.6.18-92.1.13.el5xen) + xen 3.3
        root (hd0,0)
        kernel /xen.gz-3.3.0 dom0_mem=384M
        module /vmlinuz-2.6.18-92.1.13.el5xen ro root=/dev/vg_virt01/lv_root
        module /initrd-2.6.18-92.1.13.el5xen.img


This could also be done using a script like this:

perl -pi -e 's/([^#]\s+kernel).*$/$1 \/xen.gz-3.3.0 dom0_mem=384M/' /boot/grub/grub.conf

dom0_mem=384M sets the size of memory used by dom0, and is not strictly necessary.

Reboot and all should be working.