I run a master and slave Kerberos servers, which requires setting up kprop to run regularly on the master server in order to transfer any changes to the slave server. The usually suggested way of doing this is a 2-line script (dump to file, propagate file across), which runs from /etc/crontab with the output directed to /dev/null.

I didn’t like this, because whilst I don’t want (obviously) to get the SUCCEEEDED message emailed to me every time it propagates successfully, I do want to know about it in the event of failure. So I wrote this slightly improved script, which does just that.

#!/bin/sh
# Script to run automatic Kerberos dump & transfer to slave server

DUMPFILE=/etc/krb5kdc/slave_dump_file
RESULT=/etc/krb5kdc/slave_dump_result
SLAVE=server2.example.com
MAIL=sysadmin@example.com

/usr/sbin/kdb5_util dump $DUMPFILE
/usr/sbin/kprop -f $DUMPFILE $SLAVE > $RESULT

if grep -vq SUCCEEDED $RESULT ; then
        mail -s "Kerberos replication problem" $MAIL < $RESULT
fi

This goes in /etc/cron.hourly (if you wanted to run it more often you'd want to call it from /etc/crontab at whatever interval you prefer) and seems to work fine.

I started using Debian in late 2002, today I am a Debian package maintainer and use it full time every day at my job as a Debian Sysadmin. On the flip side I’m also an Ubuntu enthusiast and now an official Member of the project, I use Xubuntu (XFCE version of Ubuntu) on my desktop, work extensively with the Ubuntu community, and attend and help organize events with the Ubuntu team here in Pennsylvania. My work with Debian trickles down into Ubuntu, as almost all of the work in Debian does, the packages I maintain end up in Ubuntu repositories, the tools developed for Debian are adopted by Ubuntu.

With the release of Debian Etch as stable a couple months ago there have been several articles circulating comparing these two distributions (such as: Debian as a desktop system: A good alternative to Ubuntu by Yousef Ourabi). I’ve also found myself in conversations with several people of various backgrounds about this, including Don Crowder, a hobbist who recently wrote Slowly Closing Old Windows (Living On The Etch).

The result of all this discussion has been pretty much as I expected.

Back in January I wrote a review of Vector Linux 5.8 Standard. The fact that as I write this, over five months later, that review is still in the O’Reillynet Blogs Hot 25 says a lot about just how much interest there is in this up and coming Canadian distribution, a user friendly derivative of Slackware. Back when I wrote that review I talked about the three different flavors of Vector Linux. Standard, with a default Xfce desktop, can be compared to Xubuntu in some ways while SOHO, it’s big brother with a default KDE desktop, is more directly comparable to Kubuntu. The implication is that the same code base is used in both. That was true for all versions prior to 5.8. This time, however, there was a really long gap, as in almost five full months, between the two releases and a lot of bugfixes and upgrades were put in. The new SOHO even sports a newer kernel under the hood: 2.6.20.3. Vector Linux SOHO resembles a next release rather than a different build of the same release. It probably should have been numbered 5.9 rather than 5.8 and it does deserve a separate review.

Generally I’d want to do a review of a distro with a KDE desktop on a fairly powerful machine. As I’ve written before KDE tends to be quite sluggish on my aging laptop, a four and a half year old Toshiba Satellite 1805-S204 (1 GHz Celeron processor, 512MB RAM). Heck, even GNOME is a bit slower than I’d like, hence my recent interest in Xfce as an alternate desktop environment. This has been true of Mandriva 2007, SuSe 10.2, Fedora Core 6, and Ubunutu/Kubuntu right up through Feisty. I have always assumed this is because KDE does consume more memory than GNOME or Xfce and because it always needs the dcop-server running in the background. Guess what? I was wrong. Vector Linux 5.8 SOHO proves that KDE can be built for speed. There is no sluggishness at all on the old Toshiba. If it’s fast on this old notebook it’ll positively scream on an up-to-date system.

Last week I finally finished installing Condor (a distributed computing project) on our machines here. The install packages didn’t seem to include a Debian startup script (or I couldn’t find it), and a little light Googling produced nothing either. So I wrote my own, & reproduce it here to assist the laziness of others.

#! /bin/sh
# /etc/init.d/condor: start and stop Condor

set -e

test -x /soft9/condor/sbin/condor || exit 0

if test -f /etc/default/condor; then
    . /etc/default/condor
fi

export PATH="${PATH:+$PATH:}/usr/sbin:/sbin:/soft9/condor/sbin"
export CONDOR_CONFIG="/soft9/condor/etc/condor_config"
PIDFILE="/var/run/condor.pid"

case "$1" in
  start)
        echo -n "Starting condor"
        start-stop-daemon --start --quiet --exec /soft9/condor/sbin/condor_master -- $CONDOR_OPTS
        PID=`pidof condor_master` || true
        echo $PID > $PIDFILE
        echo "."
        ;;
  stop)
        echo -n "Stopping condor"
        start-stop-daemon --stop --quiet --oknodo --pidfile /var/run/condor.pid
        echo "."
        ;;

  *)
        echo "Usage: /etc/init.d/condor {start|stop}"
        exit 1
esac

exit 0

I may write more about condor when we’ve been using it a bit longer.

There is a very interesting back-and-forth going on between Linux creator Linus Torvalds writing on the Linux kernel mailing list and Jonathan Schwartz, President and CEO of Sun Microsystems writing in his blog. Despite the different fora the two actually seem to be talking to each other as well as their respective audiences.

A year and a half ago Mr. Schwartz posted to his blog about possibly releasing Solaris under dual Open Source licenses, CDDL and GPL v3. Never mind that GPL v3 doesn’t exist yet and certainly wasn’t finalized a year and a half ago. This was one of Sun’s many pronouncements about their support for Open Source that seemed to have very little substance behind it.

Fast forward to yesterday and Linus’ post to the kernel mailing list in a discussion about the possibility of dual licensing the kernel under GPL v2 and v3. While Linus acknowledges positive contributions made by Sun he is very skeptical about their motives and about what, if anything, interesting they may release under any form of the GPL. While I share his skepticism I applaud his decision to be civil towards Sun and to say that he hopes he’s wrong. Read the whole post — it’s very interesting and informative.

Today Jonathan Schwartz responded. I must say he did nothing to allay my skepticism but… at least a discussion is taking place and a Sun commitment to Open Source and the GPL has been reiterated.

After upgrading to etch recently, I had a plaintive email from a user saying that some Fortran software she had downloaded now wasn’t compiling any more (when it had been previously).

The error message was pretty clear that the problem was with g77 not being able to find the relevant include file - but there it was, right in the directory.

It transpired after a little Googling that g77 (at least as of the version in etch) doesn’t use the current directory or the source file directory to look for include files in. The problem was readily solved by adding -I. (note the dot!) in the configure file & running make clean;./configure;make.

However, this seems to me to be a strange decision - for my intuition, looking in the current directory and in particular the source file directory for desired files makes sense. I can’t offhand find anything explaining why it works this way; and the fact that this code used to work fine implies that it’s not “it’s always been done this way” (although I’ve now upgraded all machines to etch so haven’t got a sarge box kicking around to test!).

There’s a bug report for gfortran stating that it does include files in the current working directory while g77 doesn’t (with a patch fixing the problem); but this also states that g77 includes files in the same directory as the source file; which doesn’t actually seem to be the case with this version. Curious.

(yes, we do still have people using Fortran here. Lots of people, in fact!)