I upgraded my Mac OS X from Tiger to Leopard yesterday. Overall I got nice things to say offset by one big honkin’ rant. Read on if this may concern you in the near future.

First off and most notably, it took a long time. I mean over an hour to just upgrade the OS – not counting installing all the development tools and running the software updater to get fresh patches. Probably two and a half hours door to door. I don’t remember the Tiger upgrade taking so long. However I do applaud that the installation disk verifies its own integrity before installing. You don’t want a bunk disk failing during upgrade thereby trashing your current installation. So after upgrading, restarting, installing more crap, restarting, installing patches, restarting and finally upgrading the firmware in my Airport Extreme/Express units, I was apparently good to go. So I did some looking around to make sure some of my crucial settings were still in place.

Cue the rant…

I had made some custom modifications to the firewall – opening up certain ports to accommodate certain things. So I went looking for that to make sure all was well. First I found that the firewall settings are no longer to be found where they were. I tracked them down under the “Security” pane in System Preferences. They re-did things a bit and here is what I saw:

So first off, the firewall is disabled by default. And that is so not OK. Next off, what do those other options actually mean? Especially the second and third options? Are they independent or do they work in tandem? I did some poking around and found an excellent discussion that shed a little light on the subject. First off, “Block all” does not actually do that. It sort of does. So, most importantly, hit the Advanced button and enable Stealth Mode. Then it actually functions like a proper firewall. You want this enabled for whatever mode you want to run the firewall in. But what if you want to open up ports for specific apps? Well, then that’s what the third option is for. When you run in this mode, if an app (a torrent client, doing point to point file transfers using a chat client, etc) attempts to start up on a port and accept connections, you will get a dialog box asking if this is OK. So one may allow or deny certain services through the firewall. Unfortunately, when you shut down the app in question, the firewall does not close the port. Moreover, it’s rumored that the OS digitally signs the apps that it opens up the ports for, so if they change – it all breaks. A for effort security-wise but D for execution.

Point one: what the fuck Apple? Leaving the firewall disabled by default? What gives with that? Point two: I get trying to streamline exposing pinholes in the firewall, but what reason is there to remove a power-user option to configure port exceptions manually? Not many people need to use it, but the ones that do need that. The feature existed in Tiger, so why remove it? Argh! So yeah, if you upgrade, tidy up that firewall. The link above give a more in-depth discussion of what’s going on under the hood. God bless the people that have the drive and the time to tinker and write it up for the rest of us.

So after I got done frothing and foaming about the firewall issue, I got down to tinkering around with all those nifty new features. Gotta say, pretty slick at points. Apple has a video that goes over much of it (worth watching if you upgrade) but some comments of mine:

The hacks to the finder – the new Cover Flow browsing mode coupled with Quick Look – are really nice. Plus the whole Stacks thing (another desktop/finder tweek) also looks really slick and could be potentially very useful for re-organizing the messy desktop. I just watched the video of those features and giggled and the sheer Apple-y-ness of the finder hacks. Spotlight is quite a bit faster now and it really speedy if you use it as an app launcher – so you Quicksilver users may not need that anymore. The iChat app has lots of multimedia eye candy jammed into it. Meh. Use Adium instead. Preview got a facelift and a bunch of nice (most PDF oriented) features added as well. The terminal no longer lets you set an image as a background. Boo to that. The Mail app got a slew of new cool features. I like the Notes and To Do features – the To Do notes also tie into the iCal app and that is slick. Notes take any sort of media you care to jam into them and can get all the sticky notes off of one’s desktop. The mail reading window has some neat additions – if there is something in the body of the email that looks like an address or email address or chat handle, it makes it easy to suck it right into the Address Book app. Nice job with that.

However, as a long time UNIX user, I’m mostly stoked about having real native virtual desktop support (Spaces) rather than having to rely on the other ones that have their problems. They even mapped the desktop movement hotkeys to Control-Arrow – just like we did it back in the day. Spaces is hands-down my favorite thing about the new upgrade. Furthermore, Spaces plus the Growl notification app is a win.

I’m not going to go on about all the new features since you can read about that anywhere. Overall, It looks like a worthwhile upgrade and it went painlessly. It just takes a while to accomplish it all, and the sins with the firewall left a bad taste in my mouth that has not gone away yet.

Cheers all.

about fixing the RSS feeds problem with iWeb using Apache RewriteRules. Here is an update for those using a web hosting environment where they do not have godly power over the Apache configuration files. I’ve recently transitioned to the former situation from the latter and I’ve had to adapt my strategy for dealing with this little bug a bit.

Side rant: WTF Apple? This RSS feed publishing bug is well known and well complained about and from a programming point of view is trivial to fix. People bitch about it in the forums, and it’s wrong, even though some of the forum dwelling sockpuppets keep saying that it’s perfectly alright to have to upload your site twice to make up for the broken links produced by otherwise nicely functioning software. So look, either your hosting service is broken or your software is broken. Just fix it.

Rant off.

So anyways, won’t work in an .htaccess file driven hosting environment. It has to do with the URI-to-filename translation handler phase of the Apache request chain. In my last commentary I suggested a RewriteRule (henceforth: RR) that looked like this:

RewriteRule ^/Example/(.*) /$1 [R,L]

To remove the spurious “Example” (or whatever you named your site in iWeb) string from the URLs in the RSS feeds, and the links pointing to the RSS feeds. If you put that in the server configuration file that’s fine. The RR short-circuits the URI mapping phase and will happily redirect things from the URI-segment “Example” even though it does not exist (because iWeb does not create it, which is the whole reason for this little exercise). However, when including these directives in .htaccess files, this approach will not work because the URI-to-filename translation handler has already started and when it does not find the directory “Example” in your document root, it fails out.

There is a solution however. How it is executed depends on how you push out files to your hosting environment. What need to happen is that one needs to create a directory at their DocumentRoot called “Example” and place an .htaccess files in this empty directory with the following directives:

Options +FollowSymLinks
RewriteEngine On
RewriteRule ^(.*) /$1 [R,L]

Using this approach the same thing will happen. Apache will find the bogus directory from the buggy URL and then the RewriteEngine will then take over and translate your paths such that they resolve properly.

It should be noted that while it might be tempting to just create this directory and .htaccess file on your local disc in your ~/Sites/sitename directory, there is a problem with that. Every time you publish your site, it will get over written by iWeb. So it has to be placed on your web host machine some other way. I just wrote a bit of shell script to create the directory and .htaccess file .

But really, iWeb should just be fixed so this is irrelevant.

I’m currently looking at RapidWeaver. This is becoming foolish.

Seems like most of the “external” hits to my blog are being generated by Google searches hitting my second blog entry. In the aforementioned entry, that arises when using iWeb to “publish to a folder” when you don’t wish to host your site on the Mac hosting service. So, since people seem to be finding this blog by Google searches like “using iWeb with Apache” I thought I would toss out another thing I do when using iWeb to publish to other hosting platforms.

If you’re using iWeb you’re obviously using some flavor of OS X which means you have a UNIX shell utility on your system called rsync. It’s a file transfer utility that is far more flexible and interesting than FTP, and since you can do it over SSH, you have more options when transferring your files to some sort of shell-based hosting environment since many places allow SSH use since it’s far more secure than things like FTP. Moreover, rsync is smart enough to figure out which files have changed since you last used it so it will only transfer the new files rather than: 1) having to copy over your entire site every time; or 2) figure out what the new files are and copy them manually. Finally, if you remove pages locally, it will remove them from the remote server as well. This does involve using the terminal program. so if that freaks you out, then I can’t help you – but I will address how you can streamline the process somewhat.

The basic command you want to issue (from the terminal) will look something like this:

rsync -vrca –delete –rsh=ssh /Users/username/Sites/sitename/ username@www.example.com:/www/docroot

The first file path is the pathname to where iWeb stores your published site when you publish it to a folder. The default place is in the “Sites” subdirectory of your home directory and the “sitename” defaults to what you named your site at the top level. Note the trailing ‘/’ on the path name – it tells rsync to push out the entire contents of that folder. The hostname “www.example.com” should be replaced with the name of the machine your site is hosted on and the “username@” is your username on that machine. Finally, the path after the ‘:’ (no spaces between hostname and that) is the document root of where your website files go on the hosting server. Note the lack of a trailing slash on that.

If you run that command, it will take all your “publish(ed) to a folder” iWeb files and transfer them to the proper spot after prompting you for your passphrase. And when you update your site, it will only push out the new files, or ones that have been changed rather than transferring everything. And entries/files/images that have been deleted, will also be removed at the remote end. Play with this until it’s putting the files from the right place, to the right place (will involve tweeking your file paths to taste).

For the non-UNIX-savvy, here is an easy way to automate this process rather than having to deal with this rather cumbersome command (requires administrative access on your Mac):

1) Edit the file /etc/bashrc to include the following line: source ~/.bashrc (admin access needed).
2) In the root of your home directory create a file called .bashrc if it does not already exist (note leading ‘.’ character) and add the following line to it:

alias publish=”your long tailor-made rsync command” (quotation marks included)

3) If you want to execute the command immediately, execute the command: source .bashrc (optional).

Now, all you need to do whenever you are ready to push out new changes to your iWeb publish(ed) to a folder website, just open the terminal program and type publish (or whatever you named the alias). There are probably other Mac-oriented ways to alias this command, but this is the UNIX way and that’s all I know.

Cheers.

OK, so when using the iWeb “Publish To Folder” (ie: not to mac.com) option it does not get the RSS feed urls right. The on-page links to the RSS feeds will be munged up and the pointers that the RSS feed gives will be munged up as well. Charming. A known fact. Thanks Apple! But, if you happen to be hosting your iWeb produced website on an Apache webserver that you have control (or influence) over, there is a pretty easy fix to this little issue. Our friend mod_rewrite will take care of things.

If you have named your top level site name “Example” and are publishing to the url “www.example.com”, all the links will work – mostly. Your sub-page named “Blog” will be reachable at:

http://www.example.com/Blog/ (as it should be)

however even if you tell the “Publish To Folder” dialog (as you are supposed to) that your site is:

http://www.example.com/

iWeb will try to force your RSS URL to (as it should not be):

http://www.example.com/Example/Blog/rss.xml

as well as making incorrect links in RSS feed itself.

If you can get all up in the Apache config, the following directives will take care of the problem once and for all (where “Example” == the name of your top-level site name):

RewriteEngine On
RewriteRule ^/Example/(.*) /$1 [R,L]

iWeb in certain circumstances is putting the name of the top level site page into the URL as it should not be doing. This simple rewrite rule will take care of this particular mistake.

Caveat: this will now work if you have a sub-page with the same name as your “top-level” page name.

From experience, I know that hand-coded/programmer-generated html is better than that which tools like this can produce, but this is really egregious. Of course, the problem does not surface if you are “publishing” to mac.com, but I thought that Apple prided itself on not acting like Microsoft.