sheepy.org - sheepy goings on...

Nokia's MMSC is a stunning example of how to make problems as hard as possible to debug.

The MMSC can speak a number of protocols over HTTP including EAIF and MM7. As you would expect you submit your POST and get back a HTTP Error Code and Message. However the Codes and Messages leave a lot to be desired:

So lets take the 499 Error code which, according to their spec, can mean:

• Address Hiding - basically reject all messages to this Number
• Desired Delivery Time Error - aka delivery time set too far in the future
• No Credit
• Recipient Barred
• Sender Barred
• Rejected - or "We ain't gonna tell you why"

No surprises for guessing which one I'm seeing at the moment :)

Next comes the legendary 599 Error Code, again lets look at the spec.
This can mean:

• CCR Error - Rejected as the MMSC has exceeded the number of messages licensed
• Capacity Exceeded - Number of msgs/second exceeded
• Kernel Overloaded
• DB Error - Message could not be stored in database

although in our case we normally see "No reason given or reason given not included in EAIF specification".

If the above wasn't fun enough, Nokia obviously doesn't think it is, if you use the Nokia MMSC Client libs they will generate their own 666 error code if they don't get anything back from the MMSC. Great!

Seriously, how do people manage to come up with this crap. If you're going to define Error codes and Messages then FFS use them and don't have a "Oh we can't be bothered to tell you why" message.

I'm not the greatest fan of XML for much the same reasons as Jeff Atwood who wrote a controversial blog post on the subject.

Sometimes though I'm forced to deal with it. XMLStarlet looks like it might relieve some of my frustration.

Thanks to BASH Cures Cancer for flagging this.

As a sysadmin I spend much of my day trawling though log files looking for problems.
Unfortunately many developers don't appear to know how to use log levels effectively which can make a sysadmin's life a small hell when it comes to debugging.

As a general rule I advise the following:

Be quiet about successful operations and verbose about unsuccessful ones.

Yes I like to see what an application is doing but I don't need to know every function call that it's making, yes this is useful when developing an application but can make isolating a problem in production a real pain.

Generally I use 4 different log levels:

• DEBUG
• INFO
• WARN
• ERROR

The definitions for these go something as follows:

DEBUG	Things that should happen but you don't want to see in production. This includes function tracing, SQL statements, variable values etc...
INFO	Things that should happen that give you just enough idea about what's going on. This should be limited to 1 or 2 lines per transaction,
WARN	Things that shouldn't happen but the end user should see no difference. For example $foo failed so falling back to $bar instead
ERROR	Houston we have a problem! This is a serious error that has caused a problem for the end user. If you want to dump variables to the logs then now is a good time to do it.

Some applications do logging in a completely different way, they have more log levels. Generally in production you want to know just enough to know what the application is doing + all the warnings and errors.

If something goes wrong then you need enough information to be able to replicate it. If all is well then, as sysadmins, we don't care.

Here is a quick guide to getting MySQL installed on Debian Etch without pulling
in anything from testing or unstable.

Now there are a number of different ways you could do this but I wanted a debian
package (as I have banned installing anything from source on new servers at work).

After some google action I found that Norbert Tretkowski had submitted packages to experimental
However after checking these out they wanted to pull things in from testing and/or unstable and I didn't want
that (especially considering it wanted to upgrade libc6)

That said it turned out that this package would build fine on Etch by doing the following:

Add the following to /etc/apt/sources.list:

deb http://ftp.uk.debian.org/debian/ experimental main contrib non-free
deb-src http://ftp.uk.debian.org/debian/ experimental main contrib non-free


Then create /etc/apt/preferences with the following in:

Package: *
Pin: release o=Debian,a=stable
Pin-Priority: 900
Package: *
Pin: release o=Debian
Pin-Priority: -1

which basically says "only install stuff from stable".

Next we get the dev tools and the build dependencies:

aptitude install dpkg-dev devscripts
apt-get build-dep mysql-server-5.1
apt-get source mysql-server-5.1


Then build the .debs:

cd mysql-dfsg-5.1-5.1.24rc
debuild


Once that has finished get the run time deps:

aptitude install libdbd-mysql-perl libdbi-perl


And finally install the .debs we created earlier:

cd ..
dpkg -i *.deb


...and there you go, MySQL 5.1 on Debian Etch :)

So after a mate a work started raving about Gnome Do I decided to give it another go, not quite remembering which I gave up with it last time.

Quicksilver is a program I've always installed first when using any Mac and Gnome Do is a very similar thing for Linux.

It wasn't long before I worked out why I had ditched it. I keep switching between window managers and seem to always end up back with pekwm. Launching Gnome Do in pekwm for some reason causes the "window" to end up behind all the other windows.

A quick RTFM later and I found the answer. In my ~/.pekwm/autoproperties I added:

Property = "Do,Do" {
ApplyOn = "Start New Reload"
Layer = "Menu"
Title = "^Do"
}

which forces it above all other windows.

With that sorted the only thing left is the occasional erratic behavior of the window placement, but I can live with that for now :)