Everything is a Freaking DNS problem

Devops Needs Sushi

KVM vs Virtualbox

So you need that old FC9 instance on your fresh F11 install.

Obviously I started a KVM instance on my desktop and installed FC9 in a Virtual Machine,
It took long to install, too long, so I looked if KVM was working correctly
Kvm was loaded but not in use ..
And then you remember why you had VirtualBox on that machine before it’s upgrade . indeed, this machine was to old it was not a VT Capable machine . VirtualBox performs much better there ..

RiverMuse

Rivermuse is the new Fault Management platform tool on the market, their initial relase was lurking around the corner for a while now but since earlier this week it finally arrived

Eager to see what all the fuzz was about I jumped to their dowload page to find an yum repository for Fedora Core 9, that’s right .. it’s july 2009 and RiverMuse released their platform for a Linux distribution that got it’s End Of Life notice last month.

SquashFS errors during FC11 install

My FC10 to FC11 yum upgrade got stuck on a zillion dependencies .. well actually libssl and mysql from Remi .. but from there it’s a whole chain of other things. So I had the great idea to go for the F11 Live CD, the LiveCD works like a charm,, only upon trying to install the live CD to my OS partition it started failing on me with a bunch of squashfs errors ,

Webbased Administration Interfaces

Dear Hardware / Appliance and any other kind of being that creates web interfaces to manage devices remotely. Pleaze keep in mind that plenty of these kind of machines are being managed from behind a ssh tunnel so people often connect to them using http://localhost:8080/ where 8080 locally is mapped e.g. via ssh to the port 80 on the remote port.

If your application does anything closely to rewriting the localhost:8080 part to localhost it will fail and I as a potential purchaser of your device wil vote against buying your stuff.
(This is specifically annoying if I want to tunnel 16 KVM/IP boxen to my localhost 8001:8016)

DRBD2, OCFS2, Unexplained crashes

I was trying to setup a dual-primary DRBD environment, with a shared disk with either OCFS2 or GFS. The environment is a Centos 5.3 with DRBD82 (but also tried with DRBD83 from testing) .

Setting up a single primary disk and running bonnie++ on it worked Setting up a dual-primary disk, only mounting it on one node (ext3) and running bonnie++ worked

When setting up ocfs2 on the /dev/drbd0 disk and mounting it on both nodes, basic functionality seemed in place but usually less than 5-10 minutes after I start bonnie++ as a test on one of the nodes , both nodes power cycle with no errors in the logfiles, just a crash.

Weird Scenes inside the Tarball, Midnight Commander woes

I was transferring an apt repository to a remote site using the tarbal I created locally. When the first machines tried to do an apt-get update from that repository they failed to getthe package list.

1. Jun 24 11:01:28 10.99.2.253 root: Failed to fetch <a href="http://10.99.0.1/repo/ntc/i386/base/pkglist.CentOsDistro" title="http://10.99.0.1/repo/ntc/i386/base/pkglist.CentOsDistro">http://10.99.0.1/repo/ntc/i386/base/pkglist.CentOsDistro</a>  404 Not Found
2. Jun 24 11:09:29 10.99.2.253 root: Err <a href="http://10.99.0.1" title="http://10.99.0.1">http://10.99.0.1</a> i386/CentOsDistro pkglist

However at first sight the appropriate files were in place

Twitter Woes

This one has been sitting in the drafts for too long, but frankly there’s not much I have to add.
Twitter is acting weird , we all know that .. but the following movie really beats everything.

Yes that’s right what you are seeing is me logging into my twitter account, checking my @krisbuytaert
messages and seeing the @vti messages and then even taking full control of their (in the mean while deleted) account.

resolv.conf problem

Collegue troubleshooting a machine that he couldn’t log into anymore

root@Validation_Radio3_Ku_VN1:~# cat /etc/shadow\

/etc/resolv.conf generated on 20090604022133 by\

/etc-ro/rc.d/resolvdotconf.pl
nameserver 192.168.104.1\

Really folks .. Everything is a fine dns problem :)

PS. Yeah yeah .. the real problem was a filesystem corrupted

Told Ya sooo

By now everybody and their neigbour has realized that indeed Everything is a funky dns problem, Frank is giving talks about it at ZooCamp, and Serge figured out the hard way the downtime of planet.geekdinner.be was due to a dns problem :)

But I told you different things before … and some of you listened others are still reinventing the wheel as we go …

Matt A. points out that the OpenBravo folks realized that one should try to build on top of Open Source projects rather than modify core code ..