Haven't seen this anywhere else yet (except at macnews.de), so might as well post it here.

According to the bulletin, there is a buffer-overflow vulnerability in the code that listens on port 660 (i.e. for Workspace Manager and Server Admin) that can lead to a server restart or, even worse to execution of arbitrary code.

I've shut down port 660 on all my publicly reachable systems...

Them darned bugs! Just keep poppin' up all over the place... And once again it's... no, not Windows, Internet Explorer or BIND, yes! Our good friend OpenSSL...

There has been an advisory for FreeBSD along with patches and as of now my four FreeBSD machines with a permanent internet connection and static IP-adresses (including the one serving this blog) have been updated with a steaming-fresh new world... The others can wait...

I'm currently still downloading it ;-) But I'm very anxious to find out, whether those promised network improvements in the Finder are worth the long wait. Especially a working WebDAV implementation would help me tremendously in my current work...

03:22: Yup, it's definitely snappier[tm] ;-) And don't forget to run Repair Permissions afterwards: on my system there a gazillion permissons had been corrected. Before that, iPhoto wouldn't start up, now it does...

Abstract: Mac Users usually don't use suffixes such as .doc - after all, we've got ressource forks! But what to do, if a such a file ends up on a *NIX machine (such as OS X Server!) without that ressource fork? Once again, shell scripting to the resuce!

A client of mine had some rather large amounts of project related files sitting on our Mac OS X Server - dating back until 1997. Since nobody really needed them regularily, it had been decided to archive them. That's when somebody decided to actually have a look at those dust-covered files and found out, that the majority of them was "broken" - catastrophy!

Well, as experience shows, in 99% when end-users claim that a file is "broken" it simply means, that it won't open when they double-click it, so I wasn't too alarmed ;-)

And indeed, it turns out, that these older files had been served on a MacOS 8.x/9.x machine (using FileSharing and, I might add, years before I started working for this company) serving samesuch clients - ergo none of these files had a suffix such as .doc or .jpg etc. And for some odd reason they had lost all of their ressource forks.

However, random samples showed, that most of the files were okay, if you just guessed or remembered the filetype and appended the correct suffix so all that remained to be done is to write a script that performs this task automatically on every file. It's fairly simple but having hardly any shellscripting experience it took me well over three hours to get it working (and it's still very crude!) but just in case any *NIX admin reading this blog is confronted with a bunch of suffix and ressource-forkless Mac files, here's how to save yourself some time...

As often in UNIX, the first thing we do is break the problem down into components. The first is: Find all files, that do not have a suffix. This, of course can be achieved with builtin-tools, namely the find command. The next bit is to analize each of these files using the file command and rename it accordingly. This step is handled in a script of its own called mtype2suffix.sh so we get the following snippet:

find <path-to-files> -type f -false -name \*.\* -exec mtype2suffix.sh {} \;

The script itself looks like this

#!/bin/sh

mtype=`file -ib "$1";`

case $mtype in

    audio/mpeg)
    suffix=".mp3"
    ;;

    application/msword)
    suffix=".doc"
    ;;

	# insert more mime-types as needed
    *)
    exit
    ;;

esac

mv "$1" "$1$suffix";

Important: the *) 'catch-all'-statement with the following exit statement basically means: "if you don't know what the file is, then leave it alone!", which seems more appropriate, than, say appending an emtpy suffix and thus messing with the file's modification date.

With lots of help from Carsten and Cryx, thanks!

Whew, what a week. After pulling two emergency night shifts (for two different servers, but both cyrus-related) yesterday and the night before I'm now officially 'zonked out'.

The good thing about these two incidents is, that I've learned lots again. I can't tell you how good that feels ;-) I'm about to compile a little history of these two events, because, as Eric Raymond likes to justify his rants "there's something to be learned from it"... Also, after updating the corrsponding chapters of the cookbook I will finally publish the new version - there have been quite a few changes over the past few weeks that haven't yet made it into the online version.

But first I have a very important appointment with a certain two-year-old I know. Apparently, some sort of big dangerous lion is involved and I'll have toooaaaarrrggghhhhhhhhhh!!!