so now i've set up another AFS cell. That's two cells successfully under my belt. Of course, i ran into other problems with DNS on the new one, but i've gone ahead and reported them to debian. it seems that there's a conflict between having explicitly fully qualified domain names in some places, and simple bare hostnames in others.

alright. i've actually made a client successfully talk to the AFS server, and things seem to work as they're supposed to (though Ubuntu 5.04 is startlingly behind the times on their packaging of OpenAFS. i had to backport the more modern versions from Ubuntu 5.10 -- i could have probably pulled in the debian sarge packages as well).

The more i read of the documentation, the more reasonable i think OpenAFS is. Not genius, mind you, but reasonable. It deliberately and systematically abstracts away the physical location of the data so that it becomes accessible by a globally-visible name. Like URLs, but uh, developed over 20 years ago.

There are still troubling inconsistencies in it: userIDs and groupIDs appear to be 16 bit integers, with userIDs the positive numbers and groupIDs relegated to the negative ones. For AFS to work smoothly, it needs your client workstations to have native Unix UIDs which match the AFS accounts, thereby defeating some of the slickness of using kerberos principals as your basic identification device. Of course, it's also handicapped by the POSIX requirements of producing an actual numeric owner and group for each file. But still, having some sort of independent translation layer seems like a good idea for a (hopefully) global service (as suggested by this conversation way back last century during the designing and planning of NFSv4).

All in all, i'm frustrated by the lack of a good networked, global filesystem that everyone is comfortable with and capable of manipulating natively. i should probably work my thoughts on this out more in a separate post, but i feel like there are a few concrete things that have held us back from this goal.

Anyhow, just checking back in to say that yes, this seems to be an acheivable project, and it is extremely cool to see it up and working and start to understand the inner structure of some of these mechanisms. I've even got the "backup" volumes working, which simply gives users convenient access to their files as they existed "last night"... That is, the server runs a nightly job which sort of snapshots everyone's home directories. Except that the snapshot takes up no space, because it's pointing towards files which already exist. Changes to these files then do a sort of copy-on-write, but the backup versions are still available. As a user, you'd have read-only access to that file you just deleted (or horribly mangled), and can copy that older version (from 3am last night or whenever the backup update was done) and breathe a sigh of relief. It'd be nice to be able to provide more than one backup copy, but i think it would probably eat up too much disk space.

OK, off to bed...

heh-- "more about this tomorrow"... that sure didn't happen. spent the day goofing around, tuning up an old bicycle that i found in the trash on Thursday, and then coding some with some friends at ABC No Rio. maybe i'll post more about it tomorrow tomorrow. sure...

Thanks, D.... Sounds simple as pie, even at 4 a.m.

But what I really want is more graphic information. What does your RIGHT foot look like? I'm aware the left one is tastefully green, at least from the bottom view. That hasn't changed in months.

Does noesis permit on-line dermatologic diagnosis? Blue and yellow, as you know, are easier for me to see than green. Let me see more current pix of the right foot just to keep my cones working. (or is it my "cohens"?....)

H.