michaelanthoni.com

So I’ve been using the Ubuntu 8.04 LTS Desktop Edition on my laptop since its release and I must say that its a huge improvement since their last LTS release which I was running prior. I was previously on a dual boot configuration but I have been so satisfied with the current state of Ubuntu that I have not felt the need to boot into Windows at all. Anything I need to do on Windows has been far and few between lately and terminal services is just a click away, not to mention wine 1.0, wow has that come along way. Sure this version of ubuntu has its bugs but what doesn’t, and its not necessarily the bugs that bug me, but its the annoyances that get under my skin, sometimes caused by bugs or just design issues or lack of features. The previous Ubuntu LTS was filled with so many annoyances that it drove me crazy sometimes, such as WPA support out the box, buggy suspend/hibernation modes,ipod recognition, audio/video/codec annoyances and numerous other minor issues that just left me with a bad taste in my mouth. Their has been very little that has annoyed me with Ubuntu 8.04 LTS and I have never been a huge fan of Ubuntu, but it was the lesser of three evils. I still haven’t gotten to the point where I feel I need to migrate all my debian installations to ubuntu, but this desktop lts version might persuade me to at least give the ubuntu server version another shot. I had a horrendous experience with the last ubuntu server version and I havent looked back since. I dont remember what the exact issues were but debian was just so much less of a headache. And with the lenny branch frozen with a pending release in september this may be a good time to start evaluating my options that will be runnin on my servers for the next couple of years. So thanks to the Ubuntu/Debian teams for releasing a great product. Its been a pleasure.

The rsync folks just recently released rsync 3.0 last month with a bug-fix release and a security release earlier this month. Unfortunately, after upgrading one of my critical systems that feeds a cluster of about 10 machines, I ran into an ugly little bugger that prevented my cluster’d nodes from successfully pulling there data from the central rsync machine resulting in stale files on the clustered nodes. Heres the error I seen when running my rsync manually:

$ rsync -t 10.9.8.7::module/* /dest
rsync: link_stat “/*” (in module) failed: No such file or directory (2)
rsync error: some files could not be transferred (code 23) at main.c(1515) [receiver=3.0.2]

Instead of using the wildcard I tried one file specifically and that seemed to work just fine so I knew something was up with the wildcard thrown in there…After a little searching I confirmed my suspicions…

https://bugzilla.samba.org/show_bug.cgi?id=5388

Unfortunately this required a manual patch as the current version remains unpatched at the time of this writing and unavailable via package managers such as apt-get, portage, ports, yum, etc. Luckily this was easy enough as the patching and compilation was very smooth as I would expect…

#cd /usr/local/src/
#wget http://samba.org/ftp/rsync/src/rsync-3.0.2.tar.gz
#wget http://samba.org/ftp/rsync/src/rsync-patches-3.0.2.tar.gz
#tar -zxvf rsync-3.0.2.tar.gz
#tar -zxvf rsync-patches-3.0.2.tar.gz
#cd rsync-3.0.2
#patch util.c patches/util.c
#./configure
#make
#make install
#cp /usr/local/bin/rsync /usr/bin/rsync
#/etc/init.d/rsync restart

And once again my cluster’d nodes are happy again :).

The rsync folks just recently released rsync 3.0 last month with a bug-fix release and a security release earlier this month. Unfortunately, after upgrading one of my critical systems that feeds a cluster of about 10 machines, I ran into an ugly little bugger that prevented my cluster’d nodes from successfully pulling there data from the central rsync machine resulting in stale files on the clustered nodes. Heres the error I seen when running my rsync manually:

$ rsync -t 10.9.8.7::module/* /dest
rsync: link_stat “/*” (in module) failed: No such file or directory (2)
rsync error: some files could not be transferred (code 23) at main.c(1515) [receiver=3.0.2]

Instead of using the wildcard I tried one file specifically and that seemed to work just fine so I knew something was up with the wildcard thrown in there…After a little searching I confirmed my suspicions…

https://bugzilla.samba.org/show_bug.cgi?id=5388

Unfortunately this required a manual patch as the current version remains unpatched at the time of this writing and unavailable via package managers such as apt-get, portage, ports, yum, etc. Luckily this was easy enough as the patching and compilation was very smooth as I would expect…

#cd /usr/local/src/
#wget http://samba.org/ftp/rsync/src/rsync-3.0.2.tar.gz
#wget http://samba.org/ftp/rsync/src/rsync-patches-3.0.2.tar.gz
#tar -zxvf rsync-3.0.2.tar.gz
#tar -zxvf rsync-patches-3.0.2.tar.gz
#cd rsync-3.0.2
#patch util.c patches/util.c
#./configure
#make
#make install
#cp /usr/local/bin/rsync /usr/bin/rsync
#/etc/init.d/rsync restart

And once again my cluster’d nodes are happy again :).

Well Openbsd 4.2 has been out for about two months now and I wanted to post this a little sooner but with all the holidays I havent had a chance.

If you’ve upgraded to 4.2 then you have probably ran into the libexpat dependency issue like the rest of us. For those of you who have not upgraded yet, I hope you would read the Upgrade guide as one would expect as this issue is described here.

If you havent read the “gotchas” section, the issue is that the libexpat library has been moved from the base set to the xbase set. Now this presents a problem for people such as myself who do not install the xbase on firewalls and routers. The main problem is that this library is a dependancy to many other packages and is acknowledged with the following statement:

This will impact a large number of users! This was an unfortunate decision whose ramifications were not recognized earlier in the process. For 4.3, libexpat will be part of base43.tgz, solving this problem.

I believe this issue has already been resolved in the -current tree but for those of us who are only running stable we cannot wait the 4 months until the next release cycle and we sure as hell are not installing the xbase set. So what are we to do. I’m sure this is completely unsupported by the OpenBSD folk but this worked fine for me.

Workaround:

Download the xbase set at ftp://ftp.openbsd.org/pub/OpenBSD/4.2/i386/xbase42.tar.gz

Extract the xbase42.tar.gz to a temporary location, say /tmp

#mv xbase42.tar.gz /tmp
#cd /tmp
#tar -zxvf xbase42.tar.gz

There are 3 files in which you need inside the ./xbase42/usr/X11R6/lib directory.

#cd ./xbase42/usr/X11R6/lib
#ls -al libe*

-rw-rw-rw- 1 user group 153436 Aug 8 23:03 libexpat.a
-rw-rw-rw- 1 user group 157767 Aug 8 23:03 libexpat.so.8.0
-rw-rw-rw- 1 user group 183510 Aug 8 23:03 libexpat_pic.a

Copy these 3 files to your /usr/lib directory.

#cp libe* /usr/lib

And whala! A stupid simple solution to a really annoying issue. Now you should be able to install/upgrade your packages as you need without hitting this dependency issue. Other then this little bug the Openbsd 4.2 release has worked great for me.