Raskas’ blog

I upgraded my laptop to Fedora 9 alpha some days after the release. You could see that it is an alpha release because several things weren’t going as smooth as they should go. But most of them got fixed when updating all packages regularly. Except for Firefox.

When I started Firefox for the first time everything looked extreme big (user interface and content). This was caused by a bad autodetected dpi setting. Manually changing it to 96dpi solved the problem.
Bug 394103 in the mozilla bugzilla describes the problem and how you can solve it.

Some time later, when I upgraded some packages (including Firefox), i had a problem with the address bar. I could enter the url but pressing enter won’t bring me to the website. Pressing the green arrow on the right side of the url did.
Some upgrades later it still wasn’t fixed, it was even worse. Entering some text in the address bar was impossible and thus making Firefox useless. It was time to find the cause and solve the issue.

Removing and reinstalling the Firefox package didn’t solve it, but it showed there were some problems with xulrunner, a dependency of Firefox. The xulrunner rpm never got installed correctly, it gave following errors during rpm installation:

Error unpacking rpm package xulrunner-1.9-0.beta3.29.nightly20080227.fc9.i386
error: unpacking of archive failed on file /usr/lib/xulrunner-1.9pre/dictionaries: cpio: rename

Searching the Fedora bugzilla for this problem pointed me to bug 433096 which handles this problem. As explained in one of the comments removing and reinstalling xulrunner rpm solved the problem.

I can now enjoy again from my Fedora 9 alpha with Firefox 3 beta!

Yesterday evening O’Reilly ONLamp.com published “Using Xen for High Availability Clusters“.

This article is written by my colleague, Kris Buytaert, and me and describes the setup of the clustering of the virtual gateways at Newtec.
It explains the networking in a xen dom0 and how to block all virtual machines from the network. It also explains how you can integrate this with linux-ha.

This is my first article on O’Reilly, this means that I now have a profile on O’Reillynet, you can check it out here: http://www.oreillynet.com/pub/au/3323.

Enjoy the reading !

Today I encountered a problem with the 3ware module.

The fresh installed CentOs 5, on a machine with a 3ware 9500 card, booted without any problems, but this wasn’t the case when booting with the xen enabled kernel. During boot of the xen kernel, which ended in a kernel panic, it showed something about ioremap. When googling about the problem I found a patch which solved the problem.

Here is a step-by-step guide how I’ve applied the patch and solved the problem… read more »

Welkom to all planet.grep.be readers!

The RSS feed of my blog has been added to the list of Belgian bloggers who are involved with Open Source projects or are actively using them.

You can visit the planet on http://planet.grep.be or add the feed to your favorite RSS reader.

Rsync, the popular file synchronization tool, can be used as a daemon. It is quite easy to start the daemon version of it, just execute:
rsync --daemon --config=/path/to/rsyncd.conf

If you want to start it at boottime you have to create an init script as it is not delivered with the rpm (or at least not with redhat/centos/fedora rpms).
You can search for any existing init scripts, for example systemimager-server delivers such init script, and use that script or write a simple init script yourself, using an existing script as guideline.

In my setup I needed 2 daemons, one running on port 873 (the default), the other one running on port 874. This is off course perfectly feasible but had some problems with the init scripts.
I wanted to be able to start and stop each daemon separately. But with the simple init script I could start both separately but when i wanted to stop one of them they are both stopped.

Diving into the daemon and killproc functions, which are stored in /etc/rc.d/init.d/functions and used by all init scripts, showed me that I have to use a combination of storing the pid file and the base filename of the init script.
The pid of the rsync daemon can be stored in any file (this is handle by rsync itself), this can be configured in the rsyncd configuration with following line: pid file = /var/run/rsyncd.pid

Following init script can start or stop the specific rsync daemon even if there are multiple daemons running on the system.
There is only requirement for this init script, which is explicitly explained in the script, the filename of the initscript must be the basename of the pidfile. For example if your initscript is /etc/init.d/custon-rsyncd the pid must be stored in /var/run/custom-rsyncd.pid.

#! /bin/sh
#
# chkconfig:   2345 50 50
# description: The rsync daemon

# source function library
 . /etc/rc.d/init.d/functions

PROG='/usr/bin/rsync'
BASE=${0##*/}

# Adapt the --config parameter to point to your rsync daemon configuration
# The config file must contain following line:
#  pid file = /var/run/<filename>.pid
# Where <filename> is the filename of the init script (= this file)
OPTIONS="--daemon --config=/etc/rsyncd.conf"

case "$1" in
  start)
    echo -n $"Starting $BASE: "
    daemon --check $BASE $PROG $OPTIONS
    RETVAL=$?
    [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$BASE
    echo
    ;;
  stop)
    echo -n $"Shutting down $BASE: "
    killproc $BASE
    RETVAL=$?
    [ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$BASE
    echo
    ;;
  restart|force-reload)
    $0 stop
    sleep 1
    $0 start
    ;;
  *)
    echo "Usage: $0 {start|stop|restart|force-reload}" >&2
    exit 1
    ;;
esac

exit 0

A couple of days ago, Dag wrote how you can browse your mobile phone with CentOS.

I’ve recently installed the new Fedora 8, so it is time to check how you can browse you mobile phone with F8.

If you bluetooth adapter is recognized you will see the icon of the “Bluetooth Applet”. Right click on it and you will find the Browse Device… entry. Any bluetooth device in your neighborhood will be listed, choose your phone and connect with it. After pairing (= exchanging passwords for the first time) a Nautilus window will open with the content of your phone.

It is just that easy… That’s really something different than a couple of fedora releases ago.

Thumbs up for the Fedora 8 team!

It can be quite annoying that when you perform a ls all your files are sorted alphabetically which give such result:
[johan@raskas versions]$ ls
a_file_name-1.0.1-10
a_file_name-1.0.1-11
a_file_name-1.0.1-2
a_file_name-1.0.1-3
a_file_name-1.0.1-4
a_file_name-1.0.1-9
some_other_file-2.0.10-1
some_other_file-2.0.9-1


Of course you want your file not sorted like that, but sorted per revision. Meaning that version 9 of the file comes before 10.
The ls-option –sort=version will do this for you.
The same files are now correctly sorted:
[johan@raskas-jhu versions]$ ls --sort=version
a_file_name-1.0.1-2
a_file_name-1.0.1-3
a_file_name-1.0.1-4
a_file_name-1.0.1-9
a_file_name-1.0.1-10
a_file_name-1.0.1-11
some_other_file-2.0.9-1
some_other_file-2.0.10-1


It is not rocket science, but it is a less known option which can come in very handy some times!

I was configuring a bonding interface on one of the machines here, but i couldn’t connect to the host after a reboot or network restart.
The bond0 interface was up and running but no eth interfaces where marked as slave for that bond interface.
If I manually ran ifup eth0 the eth0 comes up and is marked as slave of bond0 and the connection to the outside can be established.
I started to debug the /etc/init.d/network script and also the ifup script. In that ifup script i noticed following lines of code:

if [ "${TYPE}" = "Bonding" ] || ethtool -i $DEVICE 2>/dev/null| grep -q "driver: bonding" ; then  for device in `LANG=C grep -l "^[[:space:]]*MASTER=${DEVICE}" /etc/sysconfig/network-scripts/ifcfg-*` ; do
    /sbin/ifup ${device##*/}
  done
fi


So it will grep for MASTER=bond0 and not for MASTER=’bond0′ (note the quotes around bond0).
When i removed the quotes from bond0 in the ifcfg-eth0 file the network started correctly.

For reference, here is my config:
ifcfg-bond0
DEVICE='bond0'
BOOTPROTO='static'
IPADDR='10.0.10.2'
NETWORK='10.0.10.0'
NETMASK='255.255.255.0'
BROADCAST='10.0.10.255'
STARTMODE='onboot'


ifcfg-eth0
DEVICE='eth0'
BOOTPROTO='none'
ONBOOT='yes'
SLAVE='yes'
MASTER=bond0


ifcfg-eth1
DEVICE='eth1'
BOOTPROTO='none'
ONBOOT='yes'
SLAVE='yes'
MASTER=bond0


Your passwords are stored encrypted in the /etc/shadow file. This encryption is normally done by the passwd command, but for some cases you want to produce your own encrypted password for manually placing it in the shadow file.

With following perl oneliner you can produce encrypt your password:
# echo "EnterHereYourNonEncryptedPassword" | perl -nle 'print crypt($_, "\$1\$".join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64]);'
This will print an ecrypted string on the screen:
$1$UckA8UmW$Ck0rISvkyk2rDutFT4nU20

Let’s split the oneliner in different pieces so it is easier to understand. The most important perl function, which does the actual encrypting, used in the oneliner is:
crypt("password", "salt");
The “salt” is a random string starting with $1$. Following join will produce such 8 charachters long random string:
join "", (".", "/", 0..9, "A".."Z", "a".."z")[rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64, rand 64];

More information about the crypt function can be found here: http://perldoc.perl.org/functions/crypt.html.
As you can notice the join is also listed on that page

If you try to manage users and there passwords with puppet on CentOs you will receive the error explained by “Known issues” on following page: Puppet on RedHat/CentOS. That page also describes the solution: install the libshadow package on the client.
It is not that easy because there is not yet an rpm of the ruby shadow libraries for CentOs.

“Not yet” because there IS a ruby-shadow rpm available in fedora (see: https://bugzilla.redhat.com/show_bug.cgi?id=240008).

So we only need to download and rebuild it:
wget http://download.fedora.redhat.com/pub/fedora/linux/extras/6/SRPMS/ruby-shadow-1.4.1-6.fc6.src.rpm
rpmbuild --rebuild ruby-shadow-1.4.1-6.fc6.src.rpm


Once we have that rebuilded rpm we can install it on all our puppet-clients. Off course we are not going to do this manually but use puppet for it .
If you have a local repository you can just add the package, but this is not yet the case for my setup so we need some extra rules.
Here is a snippet of puppet manifest:

class ruby-shadow {
   package {
      "ruby-shadow":
         ensure   => installed,
         provider => rpm,
         source   => "/tmp/ruby-shadow-1.4.1-6.i386.rpm",
         require  => file["/tmp/ruby-shadow-1.4.1-6.i386.rpm"],
   }

   file {
      "/tmp/ruby-shadow-1.4.1-6.i386.rpm":
         source => "puppet://puppetmaster/files/ALL/tmp/ruby-shadow-1.4.1-6.i386.rpm"
   }
}

class users {
   include ruby-shadow
   user {
      "root":
         ensure   => present,
         name     => "root",
         password => "SomeAlreadyEncryptedPassword";
   }
}

With this code it will require 2 runs of the puppet client. Even if you add a require in the user section for the ruby-shadow package 2 runs are necessary. Don’t know if this is a bug or a feature…