Had to do some research on how to set up persistent remote automount points in OS X 10.3 (Panther). Let's break that down.

• persistent - Mounts should survive restarts.
• remote - In this case, I'm mounting NFS volumes exported from a Linux box.
• automount - Automatically mount the volume when I access the local mount point and then unmount after some duration of not using it anymore.

A Google search for "OS X" automount nfs yields some good results that pretty much all say the same stuff:

Using automount on OS X 10.3 means adding a bunch of crap to the NetInfo database using the NetInfo Manager tool.

Much longer descriptions of how to set things up using the GUI or a ton of niutil commands are here:

• Using automount on Mac OS X
• Automounting Sharepoints at Startup
• Integrating Mac OS X in an NIS network

This was my first experience with NetInfo Manager and it pissed me off. I'm sure the whole NetInfo thing has its merits (is it LDAP based?) but one of the key strengths of UNIX systems is that most system configuration stuff is handled using plain old text files. This may seem arcane to those accustomed to the registry editor in Windows but the benefits of plain text configuration are numerous. For one thing, you don't use a half-ass'd GUI (NetInfo Manager) to modify configuration, you use whatever your favorite editor is or string together a couple of text processing tools such as grep, sed, awk, etc.

Anyway, I had a hell of a time trying to get my OS X box to automount remote NFS volumes persistently. Usually, this is a simple matter of adding a few lines to an /etc/fstab or /etc/auto.misc file. The simplest way I could find for having this same capability in OS X is to use the niload and nidump utilities to import and export the NetInfo data from and to plain text files that look a lot like traditional fstab maps.

First, get root and dump the current set of mount definitions to a file:

$ sudo su -
Password: [your password]
# nidump fstab . > /etc/fstab

Note that this will result in a blank file if you haven't configured any remote automounts.

Next, add a line for each mount point. Mine looks like this:

asha:/pub                /Network/Servers   nfs   resvport,net  0 0
daishar:/pub             /Network/Servers   nfs   resvport,net  0 0
daishar:/home/rtomayko   /Network/Servers   nfs   resvport,net  0 0

Some explanation is in order.

• The first column is the remote mount point. This can be anything you might pass to mount (see man mount for more info).

• The second column tells the automounter where to create a symbolic link (I think Mac people call these "Aliases"). The automounter creates a directory with the name of server, then a series of directories mirroring the mountpoints dirname, and finally the symlink that points to the actual local mount point created by the automounter (usually somewhere under /private/var/automount). I use /Network/Servers as my base mount directory because then these things will show up in the Finder under Network:Servers.

• The third column is the type of filesystem you are mounting. This can be afp for AppleShare filesystems, cd9660 for CDs, hfs for HFS filesystems, msdos for FAT and FAT32 (I think), nfs for NFS filesystems, smbfs for SMB (samba/windows shares) filesystems, udf for DVDs, and webdav for WebDAV filesystems. I haven't tried anything but NFS to date but plan on taking a hard look at the webdav support in the near future.

• The fourth column contains options for mounting the filesystem. There are a whole slew of things that can be specified to tweak the mount. The two most important options are resvport and net. resvport tells the automounter to make the connection to the remote NFS server using a reserved (privileged port). Use this if you are mounting a box that is configured to reject requests coming from non-privileged ports. The net option is what tells the automounter that the mount isn't just a plain old static mount. If you don't specify the net option, the mount will be persistent but static (i.e. always mounted).

• The next two columns aren't important here. Just set them to zero.

Once you've tweaked up your /etc/fstab file, you will need to load it back into the NetInfo database using the following command (note: we are still root):

# niload -m fstab . < /etc/fstab

You should now be able to go into the NetInfo Manager utility and see that everything is in order under mounts. You should now be able to make changes to your /etc/fstab file and load them into NetInfo using the same niload command.

Turn Off Horizontal Wrapping

This is called "Auto Wraparound" in xterm. Disable it:

1. Ctrl + MiddleMouse click and deselect "Auto-Wraparound".
2. xterm +aw
3. From bash: printf %b '\033[?7l'

Disable it temporarily or for certain stuff by using less -S or w3m.

Read this and this. Neither addresses going directly from Redhat 9 to FC2 directly but it's pretty much the same as a FC1 to FC2 upgrade.

ppp and initscripts conflict

If you get the following during yum upgrade:

conflict between initscripts and pppd

Remove the ppp package and then try upgrading again:

$ yum remove ppp
Is this ok [y/N]: y
Downloading Packages
Running test transaction:
Test transaction complete, Success!
Erasing: wvdial 1/3
warning: /etc/ppp/pap-secrets saved as /etc/ppp/pap-secrets.rpmsave
warning: /etc/ppp/chap-secrets saved as /etc/ppp/chap-secrets.rpmsave
Erasing: ppp 2/3
Erasing: rp-pppoe 3/3
Erased:  ppp 2.4.1-10.i386 wvdial 1.53-9.i386 rp-pppoe 3.5-2.i386
Transaction(s) Complete
$ yum upgrade
...

See this bug for more info on this problem. There should be an updated initscripts package that fixes this soon. You probably don't need the ppp package anyway. If you don't want to remove the package, this message from the yum list might be another workaround. Removing worked for me.

Upgrade Python!

Something you never want to see:

yum -y upgrade
<snip>
Completing update for ed  - 972/973
Kernel Updated/Installed, checking for bootloader
Grub found - making this kernel the default
Traceback (most recent call last):
  File "/usr/bin/yum", line 30, in ?
    yummain.main(sys.argv[1:])
  File "/usr/share/yum/yummain.py", line 375, in main
    pkgaction.kernelupdate(tsInfo)
  File "/usr/share/yum/pkgaction.py", line 611, in kernelupdate
    up2datetheft.install_grub(kernel_list)
  File "/usr/share/yum/up2datetheft.py", line 13, in install_grub
    import grubcfg
  File "/usr/share/yum/grubcfg.py", line 12, in ?
    import iutil
  File "/usr/share/yum/iutil.py", line 2, in ?
    import types, os, sys, select, string, stat, signal
ImportError: No module named select

Anytime you see the words “kernel” and “traceback” in near proximity, worry. This turned out to not be a big deal but I highly recommend upgrading python before the rest of the system as Seth notes in his suggestion doc. Upgrading python under yum while it is trying to upgrade everything else is a bad idea.

IMAP

If you ran the default UW-IMAP daemon that came with Redhat 9, you will need to upgrade to dovecot or cyrus-imapd for Fedora Core 2. I'm not sure why but the RPM obsoletes work out such that cyrus-imapd becomes the new imap daemon. It is supposedly very much more powerful than dovecot but it is also completely backward-incompatible. I removed cyrus-imapd and installed dovecot:

yum remove cyrus-imapd
yum install dovecot
chkconfig dovecot on
service dovecot start

At this point you should be close to where you were with UW-IMAP. I ran into some issues with IMAP folders (dovecot seems to only pick up your inbox from /var/spool/mail). The dovecot wiki has some information on correcting this. I did something like this for each user:

[back stuff up..]
cd $HOME
mv $(cat .mailboxlist) ./mail/
mv .mailboxlist ./mail/.subscriptions

(This only works with single level folder hierarchies. For more complex setups you will need to adjust appropriately.) Once completed, you should be able to see all of your folders in

Unsolved Mysteries

OpenLDAP changed their damn storage format and you need to slapcat and slapadd to get back to where you were. Were we where we were, it would make life much easier because now I can't seem to log in with old user credentials any more. I only spent a couple of minutes on this so it probably isn't that big of a deal.

Things That Made Me Happy

Apache upgraded flawlessly.

Dovecot is about 600% more performant than UW-IMAP. this could be the 2.6 kernel or something.. I don't care. I'm happy :)

I've tried hard to get into Screen. The ability to detach sessions from one terminal and hop back in from another terminal would have come in handy many times in the past.

Basic usage is pretty simple and the man pages are done very well but what I need right now is a "How to start using screen in 5 minutes" type of deal. It is usually hard not to find a ton of information about these treasures due to the amount of console fanatics out there that tend to document every aspect of their configurations. Unfortunately, searching for "screen" is like searching for "computer". I wonder if this has deterred others from picking it up in the past?

I found a solution after toying with different searches for awhile—both "GNU/Screen" and "/usr/bin/screen" return decent results. Here's a good introductory article. The Screen FAQ is hardcore but I was able pull a few good tips anyway. And last but not least I found my fanatic: Making the Anti-Switch - an excellent get up and running quick guide with a sample ~/.screenrc file.

Nowish

• Sitemap.
• Start putting various project stuff up here.
• Only transform modified files.
• RSS 2.0 and RSS 1.0/RDF Support
• Feed autodiscovery. See here.
• Make bottom nav useable.
• Workaround IE CSS suckiness.
• Rewrite old blog URLs.

Later

• Put all content in an XML database.
• Atom API support.
• Support various wiki-like features. I'd like to be able to post and edit stuff directly like in a wiki.

I found what I believe is an undocumented trick in Apache 2.0. You can control the quality values Apache uses in content negotation with the <ForceType> directive.

When serving multiple content types from a single URI using MultiViews, Apache uses some oddly complex method of determining which file type to send. You can override this by creating .var files but that sucks sometimes. I really wanted something like the <LanguagePriority> that let's you specify which types should have priority. The following achieves that same result using the <ForceType> directive.

<FilesMatch ".*\.html$">
  ForceType text/html;charset=utf-8;qs=0.4
</FilesMatch>
<FilesMatch ".*\.xml$">
  ForceType application/xml;charset=utf-8;qs=0.3
</FilesMatch>

This tells Apache, should you come across two files that differ only in extension, and everything else being equal with the client (e.g. the client didn't specify a q value that would weigh one of these types heavier), that the server should send back the one with the .html extension.

UPDATE:  June 25, 2004 3:32 AM

It looks like this is another area where IE's standards support is shaky. While the qs value specified here gets picked up by Apache and used to determine which representation to pick, it looks like the Content-Type response header also contains the qs value. This results in IE thinking the qs value is part of the charset or something. I've been able to break it two separate ways.

• When the qs is before the charset, IE ignores the charset and loads the page using its default charset.
• When the qs is after the charset, IE gives me an error page saying that the “System does not support the specified encoding.”

Chalk up another one for Microsoft!

UPDATE:  June 26, 2004 11:29 PM

Found some more discussion on this topic:

Re: 'qs' parameter in Content-Type header

Some discussion on the IETF HTTP WG mailing list (June. 2002)

Specifying a MIME Type / Content Negotiation

Doh! Might be able to solve same problem with AddType directive.

UPDATE:  July 05, 2004 8:36 PM

The AddType directive seems to be the easiest method of accomplishing this. Right now, my .htaccess file has the following:

AddType text/html;charset=utf-8 .html
AddType application/xml;charset=utf-8;qs=0.9 .xml
AddType application/atom+xml;charset=utf-8;qs=0.8 .atom

If no qs value is specified, a default of 1.0 is assumed. The result of all this is that .html files will be served first, followed by .xml files, followed by .atom files.

There does seem to be an issue with Internet Explorer's handling of XML files containing <?xml-stylesheet?> processing instructions when served with a qs value.

These are my notes. This stuff is primarily useful to myself. You may see things here that make absolutely no sense due to lack of context, a blatant disregard for spelling and grammar, or possibly even intention. Things here may change significantly over time. In short, I make no guarantees on the quality, subject, or accuracy of content contained here.

I believe that recording thoughts and ideas—even those still being worked out—have tremendous value in communities of open development, such as the F/OSS community and development within standards organizations like the IETF.

Another example. Dag runs an extensive repository of packages for RPM based GNU/Linux distributions. There are two cults here: the Fedora Extras (fedora.us and livna repositories) and the “3rd Party Repositories” (Dag, freshrpms, NewRPMs, and atrpms [acuracy?]). The “3rd Party Repositories” are at the lowest level of the evolutionary chain. There is little barrier to releasing new packages. The Extras (fedora.us) repository plays in the middle of the chain. There are formal guidelines for package releases and tools for managing bugs and feature requests, etc. At the highest level of the evolutionary chain is the Fedora Core distribution itself—even more process around getting new packages established.

There are serious issues with this situation. The linked thread has Dag defending the 3rd party repositories existence. The Extras people look down on the 3rd party people because they have less process around packaging standards or quality control. What they fail to recognize is that having a level where these measures are less restrictive is healthy because it provides a place where people can play with packages on the ground floor. There's a ton of weeding out of useless packages that occurs here.

The 3rd party guys should probably be trying harder to push their stuff up through the next tier though. People finding packages they like in 3rd party repos should be shepherding them on the official Extras repos.

An article from Slashdot on how Google might support RSS over or in addition to the more recent Atom syndication format.

The comments on this article are amazing. First, it is enlightening to see a majority of “technical” people having little understanding about the various standardization processes or why multiple bodies even exist. This is slashdot so “not understanding” takes the form of people asserting inaccurate statements as fact instead of asking questions of course.

Ignorance aside, there are some beautiful examples of the types of things I want to speak to. For example, this is a really good question:

Why did atom even come into existence? Was not RSS already established, or is there some kind of deficiency in RSS that I'm missing here?

And here is a commonly held response:

If we didn't keep reinventing the wheel then society would be plagued with unemployed wheel inventors with nothing to keep them busy. It would be a nightmare.

What I'd like to get at here is that what we are seeing with RSS/Atom is evolution not reinvention. RSS/Atom is such a great example of what I would like to explore because it shows the ugliness that must occur in the evolution of popular data formats and the systems that use them. These things should start extremely primitive and specific and be thrown out there so that they can be tested for whether they have value at all. Once some critical value level is reached, you need to formalize a little bit. And then do it a little bit more. And then you eventually reach a point where you have a decent idea of what the problem domain is and you go back and attack with a clean slate (Atom).

So it seems an overall point I would like to make is that we need to be looking for patterns that tell us when to move to the next stage in the evolution of a format or system and instead of attacking those that recognize these patterns, embrace them and their ideas and move ahead. The first wheels were probably square, or maybe there were all shapes of wheels being developed in different places for different things. And then people using square wheels got a chance to see people using triangle wheels, and people using triangle wheels saw people using round wheels. Then they all started talking and the square wheel guys had the right material and the triangle wheel guys had the right ratios and the round wheel guys had the right shape. So they decided to agree on how wheels might share some things in common and from this comes the best of breed wheels we have today. But if people weren't out there “reinventing” the wheel, they might still be square. And if the square wheel guys had to wait for a standards body before they created there primitive and shitty wheels, we might not have wheels at all.

An interesting thread on the XML deviant mailing list where Elliotte Rusty Harold is pushing an information model where XML data is very loosely defined—as in no schemas—between producers and consumers. This seems to be in line with ideas put forth by Walter Perry over the past eight years suggesting that Standard Data Vocabularies are the wrong way to go and that everyone needs to just put data out there as XML. Tools like XPath and XSLT will allow different parties to interoperate. This results in very little barrier to publishing data with the expense of requiring consumers of that data to implement at least some customized selection or transformation or logic.

I agree with this view and it forms a large part of the foundation of the databank concept. That is, you need to be able to publish data quickly, whether a standard is available or not, and without having to define a formal schema. This is the first stage in the evolution of a data format. There is a high level of incompatibility between vocabularies describing the same thing but people are kicking the tires and they can do it quickly. But at some point this gets out of control and people need to come together and agree on how to provide that information in a common way, bringing the data format to stage 2. However, until you reach some level of usefulness, going down the schemas/standards road is a big waste of time because the requirements are immature and the use cases are weakly defined (all the SOAP stock quote / weather examples for instance).

Need to take a deeper look at these Zen Garden CSS styles.

Mediterranean

Colors work extremely well together.

South of the Border

Blues and browns? Who would have thunk it.

Springtime

Nice greenish theme. Probably my favorite ATM.

Emmakade

Dark grey/blue

Dune Temple

Three color rust theme works really well for some odd reason.

First Summary

Many flat colors.

Burning

The main green might be my favorite color.

Door to my Garden

Advanced positioning techniques.

White Lilly

Use this green and orange.