Jedi/Sector One's random thoughts

As always, O'Reilly has a nice coverage of what's new in OpenBSD 4.4, from a technical point of view.

It's worth a read even if you don't use OpenBSD.

Yet another vulnerability in the PAM code of OpenSSH-portable. A basic format-string bug. Of course if you are running FreeBSD, the base OpenSSH is as affected as the port. Of course, almost every Linux distro is affected. And of course the latest release (5.0) is affected.

Simple fix:

Edit auth1.c and replace

        packet_disconnect(msg);

with

        packet_disconnect("%s", msg);

OpenBSD is not affected, this is only in OpenSSH-portable.

Published today by Mrdkaaa for the pwnie awards.

Update: it doesn't seem exploitable in the real world, though, see That thread, pointed out by Greg (thanks!)

The much awaited song for OpenBSD 4.2 is now available.

Click here to get the lyrics and to download the song called 4.2: "100001 1010101"

In case you missed it: OpenBSD has been ported to Xbox

Users can log in, network and sound are working.

Neat!

Crazy kernel hacker Arthur Grabowski has redesigned new TLB shootdown code and his work is now in the OpenBSD CVS tree.

That part of the commit message is probably why you want to upgrade your kernel if you're already running -current on an SMP host:

"This gives a 15% reduction in system time on my dual-core laptop during a kernel compile and an 18% reduction in real time on a quad machine doing bulk ports build."

Since efficient disk I/O scheduling is something critical to any busy host, I spent some spare time playing again with the OpenBSD scheduling policy.

As a first experiment, the default one-way elevator was replaced by a STF elevator. By the way, bufs are now taken out of queues through a wrapper function (disksort_get()) instead of reinventing the wheel for ATA, SCSI, Swap, etc.

You can download the patch against OpenBSD-current here : OpenBSD alternative I/O scheduler

The first benchmarks and live results are exciting. Blogbench, iozone and bonnie++ clearly show improvements over the default OpenBSD scheduler, although I only tried on IDE disks. WIth the STF scheduler, Blogbench yields a final score of 72 (for writes) and 5064 (for reads) on a french UFS2 filesystem, while the default scheduler peaks at 60 and 4934. Preliminary MySQL benchmarks also show improvements although only MyISAM was tested so far.

There are still tons of improvements that should go in. Going from STF to SATF, maybe, although I'm not convinced that it can be made in a generic way that would work with RAID arrays. Prioritizing requests (favor reads over writes, favor synchronous over async writes, delayed requests from processes with niceness above NZERO, deadline) will probably be the next step.

Markus Ritzer just announced the beginning of his port of OpenBSD to the Xbox

Memory management and the frame buffer are already working.

A new maintenance release of the stable branch of lighttpd is now available.

Here's the changelog

If you are still using Apache, please give it or try, or alternatively, try Nginx, you won't look back.

Here you can download the port diff I made for OpenBSD-current.

Works fine so far.

Finally, OpenBSD-current has support for UFS2. Wonderful screenshot as a proof:

$ mount
/dev/wd2a on / type ffs (local, noatime, softdep)
/dev/wd2d on /mnt/ufs2 type ffs2 (local, noatime, softdep)

I played a bit with it on an amd64 test box, and it seems to work fine so far. The only minor issue I had with it was df -h saying that 8 terabytes (!) were free while the sad truth is that the partition was only 20 gigabytes long.

But no crash and no file corruption.

Here's a first benchmark, but keep in mind that the filesystem hackathon is not over and there will probably be some other important code changes in the next days, probably some work on the buffer cache (UBC and a better elevator would really be a step forward for OpenBSD).

• Blogbench (default configuration), UFS : Final score for writes: 64 Final score for reads : 4846
• Blogbench (default configuration), UFS2 : Final score for writes: 60 Final score for reads : 4934

The buffer cache was intentionnaly as low as possible (1%) during the test, and of course both filesystems were freshly created on the same partition.

As you can see, there's no real speed difference between UFS and UFS2.

If you want to play with UFS2, upgrade to -current and recompile your kernel with that line added to your config:

option UFS2

Then, format a partition with something like (adjust /dev/rwd2d for your needs) :

newfs -O 2 /dev/rwd2d

The mount the partition as usual:

mount -o softdep,noatime /dev/wd2d /mnt/ufs2

Hey, hey, hey, the song for the next OpenBSD release is now available.

Here's the link to the lyrics and sound files.

As expected, it sounds very Ali-Baba-ish.

In order to moderate pictures from Skyrock Blog, moderators have dedicated web servers, that send pre-generated pages with 500 thumbnails to be reviewed.

Serving these static pages is not something that requires a lot of horsepower. Even with Apache web server, little memory and a single IDE disk, the system load on these hosts had always been very low and everything worked as expected.

But yesterday, something went wrong. I got a call "images are damn slow to load, moderators can't do their job".

Indeed, the system was very slow. While about 15 Apache processes were usually running, there were 1000. The filesystem was slow. All processes were waiting for the disk. Very odd.

The reason: while most moderators were previously working with Opera and Firefox, a lot of them switched to Internet Explorer.

Internet Explorer was the server killer. In order to load the 500 pictures, Internet Explorer opened 500 connections to the same host, in order to load all pictures at the same time. Every moderator using IE loaded the server the same way. Every picture was different so the disk cache was pointless. The disk was totally unable to serve so much random data at the same time. Of course, keepalive was enabled on the server, but Internet Explorer didn't care.

A workaround would be to tile the thumbnails into a single picture and to use offset and clipping to display a thumbnail.

But as I was in a hurry, I restricted the service to non-IE users. All moderators switched back to Firefox. Firefox is mature enough to restrict the number of concurrent connections to the same server. The server load immediately dropped to nothing, everything was smooth again, and everyone could do his job as before.

A workaround is to use a proxy like Squid, but it would be so much better if IE behaved a bit gentlier.

Here's an update of the MySQL port for OpenBSD to version 5.0.37:

MySQL 5.0.37 port upgrade

Nothing really exciting in that new release, mostly bug fixes. I'm running it with no issue so far on amd64 and i386.

Submitted to the maintainer.

As a summary to an interesting thread from OpenBSD-misc, but that is actually not OpenBSD-specific:

ALWAYS BUY LSI MEGARAID CARDS WITH A BATTERY UNIT

...or you will get very poor performance.

Roy Kim said that with his Intel SRCS28X (LSI Megaraid 300-8X in disguise) adapter, writes bog down at 3 Mb/s, which is terrible.

Marco Peereboom (the OpenBSD I/O adapter wizard) pointed out that LSI megaraid cards will ALWAYS disable write cache whenever there is no battery backed up memory on the card. No exceptions. The only thing you can do is to purchase a battery-backed unit and replace the current DIMM.

That way, you can get about 100 Mb/s with the same hardware.

The current port of PHP for OpenBSD still doesn't ship with the FastCGI version.

This is a shame, especially since modern web servers like Nginx or Lighttpd require the FastCGI version in order to process PHP scripts.

It's why I'm maintaining an unofficial port with FastCGI support.

Here you can download the PHP with FastCGI port for OpenBSD

It has just been updated for PHP 5.2.1 on OpenBSD-current.

The patch for the IPv6 mbuf vulnerability has just been updated to include further fixes.

Here's the link to the OpenBSD 4.0 errata that includes the new patch.

The fix is of course in OpenBSD 4.1-current, but not in OpenBSD 4.1-release.