Slashdot

So... OpenBSD programmers are masturbating monkeys, right? Right?.

While I have the utmost respect for Linus Torvalds -- and I even agree with some of the things he has to say about security and the "3133t" crowd it attracts -- I have to say this troll was worthy of Theo de Raadt himself.

Seriously, though: OpenBSD programmers are focused on security... So what? How is this a problem for Linus? How does it impact the Linux kernel we all know and love? Sheeesh, no wonder some people think open source is this immature, nerdy, stupid thing: with that kind of flames, who has time to convince The Man that Open Source is worth investing in...

Sometimes, configuring new (and old) software can be a pain in the... backside.

Anyway, I finally upgraded Firefox to 3.0 and, so far, everything looks good. Some extensions did not work (nothing crucial), some needed to be updated, but everything worked smoothly. Firefox 3 looks good, and seems a bit smaller than 2.0.0.15, so I am going to upgrade on all machines.

Except for Brief. If you don't know Brief, let's just say this is THE Firefox extension that made me understand why RSS feeds are the next best thing since sliced bread. It's cool, it's fast, it's great.

And it did not work with Firefox 3.0, even after I updated Brief to version 1.2, which is supposed to work with FF3.

Now, RSS reading does not work anymore. Aaaaaaaaargh. It really sucks when something that great does not work. Fortunately, the answer was just a few clicks away, on the Brief support forums.

The answer is simple: go to your Mozilla Firefox profiles folder, delete the file named "brief.sqlite" and rename the file brief-backup-*.sqlite as brief.sqlite. That's it, Brief now works as usual and it feels so good to have it back!

I have decided to go "old school" on my newest OpenBSD 4.3 machine. Instead of Vim 7.1, I have installed Elvis 2.1.4 on it, straight from the official OpenBSD package.

So far, I like what I have seen. While I haven't used Elvis much in the past, it's fast, complete and a very good clone of vi. It is the standard vi on Slackware, which is a very high recommendation in my book indeed (see this post for more explanation). While the syntax colouring is not as good as the one used in vim, it is good enough for my needs, and the speed is excellent. Also interesting is the size of the executable:

-bash-3.2$ ls -alhF $(which vim) && ls -alhF $(which elvis)
-rwxr-xr-x 1 root wheel 1.2M Mar 10 22:44 /usr/local/bin/vim*
-r-xr-xr-x 1 root bin 349K Mar 12 14:03 /usr/local/bin/elvis*

And please note that the elvis executable also has X11 display, while the vim binary is terminal/plain text only:

-bash-3.2$ pkg_info | grep -i vim
vim-7.1.244p0-no_x11 vi clone, many additional features
-bash-3.2$ pkg_info | grep -i elvis
elvis-2.1.4p2 clone of the ex/vi text editor

One third of the size for a fully fledged editor is enough to make you think.

Anyway, to configure Elvis, here is what I have put in my ~/.elvisrc file:

-bash-3.2$ cat .elvisrc
:set ruler
:set backup
:set flash
:set showmode
:set showname
:set undolevels=100
:map gg :1
:color cursor blue
:set blinktime=0
:courier 14

Simple, small, fast, complete and easy to configure... What more can you ask for?

[EDIT: of course, the Elvis configuration should be in ~/.elvisrc and not in ~/.exrc, and the X11 configuration should be dead last. Other than that, elvis is great.]

It's a tragedy to work with useless software such as this deep fried piece of ..... named MQSeries, for verily, I tell thee, rarely have I seen such a useless piece of spaghetti application.

OK, enough ranting, here is the nitty-gritty of it:

If you get MQSeries messages -- on a Red Hat Linux platform -- such as:

06/02/2008 09:11:58 PM - Process(10406.238) User(mqm) Program(amqrmppa)
AMQ6184: An internal WebSphere MQ error has occurred on queue manager Wolfenstein.
 
EXPLANATION:
An error has been detected, and the WebSphere MQ error recording routine has
been called. The failing process is process 10406.
ACTION:
Use the standard facilities supplied with your system to record the problem
identifier, and to save the generated output files. Contact your IBM support
center. Do not discard these files until the problem has been resolved.

Or a bit like this:

06/03/2008 09:20:10 AM - Process(4092.20) User(mqm) Program(runmqlsr)
AMQ9999: Channel program ended abnormally.
 
EXPLANATION:
Channel program 'JAVA.CHANNEL' ended abnormally.
ACTION:
Look at previous error messages for channel program 'JAVA.CHANNEL' in the error
files to determine the cause of the failure.

HINT#1: check the files named /var/mqm/errors and /var/mqm/qmgrs/wolfenstein/errors, for instance... (replace 'wolfenstein' by the name of your queue, of course).

HINT#2: if you only see two mqm processes when you type ps faxu | grep -i mqm, something is wrong...

Well, my friend, your MQSeries just crashed and crapped all over itself. Information about this is sparse on the Internet, but Google is your friend and should be able to give you more links than you can shake a stick at.

Fortunately, getting MQSeries unstuck is not too difficult, just follow the four easy steps below... All of these steps should be performed as root:

1. Check that all 'mqm' processes are stopped with ps faxu | grep -i mqm | grep -v grep, if there are processes left, kill them all with pkill -9 -u mqm.
2. Delete all sockets left in /tmp with: rm -v /tmp/MQ*, but watch out, as there may be a very large number of them...
3. Clean up all temporary files and whatnot with the command: su - mqm -c "/opt/mqm/bin/amqiclen -x -m QMGR" (return code should be zero).
4. Finally, clean up all used IPCS resources with the commands ipcs -a and ipcrm (do a man ipcrm for more information).

That's it! MQM should now be able to restart without any problem. Ain't that helpful?

The task: install ASAP a small mail server on a VMWare Virtual machine running SuSE Linux Enterprise 10 SP1. It's urgent.

One of my user soon goes to a client site to make a demo of our latest product. That product is supposed to offer several reporting options, one of which is email. So, the physical machine, running Windows XP, is supposed to receive email from the SuSE virtual machine.

The only problem is, SuSE is an over-engineered, byzantine piece of @&**!! And its default (POP/IMAP) server is Cyrus, which I have come to hate with a vengeance (the SMTP server is Postfix, and I have no problem with it). Basically, I spent an entire day fiddling with the Cyrus configuration, and not getting anywhere. That thing just sat there and did not do anything. After a while, I felt like jumping naked in a huge pile of thumstacks rather than deal with Cyrus ever again.

Usually, under SuSE, you are supposed to go through YaST (Yet another Stoopid -- and Stoopidly capitalized -- Tool) to install and configure everything... Except for Cyrus, which is NOT managed by YaST. Great. See, people, that's how you do it: "German engineering" at its best.

Did I mention this was supposed to be urgent? Like, it had to be done yesterday?

I was hoping Google would be able to help me. Nope. No relevant information, except some poor schmucks who have the same problem that I have. This is urgent. The user is almost breathing down my neck, starting to panic about his oh-so-important demo.

Then it hits me: what I'll call from now on "The Slackware Rule": "When in doubt, see how Slackware does it, and copy that" .

So, a POP mail server. Slackware uses a package of POPA3D as its default POP server.

This is the description of popa3d from Solar Designer, its programmer: "popa3d is a tiny POP3 daemon designed with security as the primary goal."... Hmmmm... Tiny, secure. What's not to like?

Downloading and compiling popa3d 1.0.2 under SuSE is done in a few minutes. The instructions contained in the "INSTALL" file are clear and simple. In a nutshell, you are supposed to edit the Makefile (only to uncomment a Linux-related line) and "params.h" (I configured the SuSE mail spool directory and the stand-alone daemon mode), compile and install.

I also had to create a small script in /etc/init.d to make sure popa3d was launched each time the machine was restarted. The default Postfix configuration, which uses /var/spool/mail/ worked perfectly with popa3d, without any modifications. And, the best part: popa3d does not require any configuration file! Now, that's what I call tiny, and convenient!

About 30 minutes of work later, my user reported that email was now working between Outlook and the virtual machine. Mission accomplished! One less problem to deal with.

The moral of the story is:

1. SuSE is a piece of &@^**++!!
2. Slackware ROCKS! If you want another proof of this, using Slackware from the very beginning helped me compile requested software on UNIXes as different as AIX, Solaris and others. Slackware is the Linux distro that will teach you.
3. popa3d ROCKS!
4. When in doubt, see how Slackware does it, and copy that.

I feel like I can relax now, knowing that horrendous Cyrus thingie is behind me. Friday night, here I come!

I have been asked to make a (really) small Jabber server on a small HP machine.

Installing OpenBSD 4.3 on the machine was fairly simple and uneventful, but the fecal matter hit the rotating oscillator when I first rebooted the machine.

Almost as soon as the machine was starting, the OpenBSD kernel crashed and dropped me into its integrated debugger (with a ddb> prompt).

Not good.

Thankfully, Google is your friend, and entering "OpenBSD HP PC crash kernel" immediately gives you the correct answer. By the way, do read the entire page, as it contains a fairly nice explanation on how to recover from a crash, not just an ACPI-related one.

So, if you install OpenBSD 4.3 on an HP machine, and the kernel crashes almost immediately, try the following, it worked for me:

1. Once at the ddb> prompt, type boot reboot (Try typing help for more information on the functions of the integrated debugger).
2. Once the machine has rebooted, you have a few seconds to type -c at the boot> prompt. The kernel itself is booted very fast, so hurry up as soon as the boot> prompt appears!
3. The OpenBSD kernel is then launched, but does not probe the hardware. Instead, it stops and displays a UKC>/ (User Kernel Configuration) prompt.
4. On the UKC> prompt, type disable 426 or disable acpiprt*. The kernel should then respond "426 acpiprt* disabled".
5. Type quit to quit the UKC> prompt and save your changes temporarily. You can try list to see all the drivers contained in the OpenBSD kernel or help for more information on the functions of the UKC.
6. The kernel should then boot normally.
7. To make this change permanent, and avoid having to do this every time you reboot the machine, make sure you read the excellent OpenBSD FAQ, and enter config -u -f -e /bsd as root.
8. Your OpenBSD kernel is now in activity and should avoid crashes at the next reboot.

That's it! Hope this helps someone...

Once again: OpenBSD rocks and its documentation really is top-notch.

Doing this under Linux would require passing boot arguments (disable acpi?) at the LILO or GRUB prompt, but this is pure speculation on my part.