Unixy

I’ve used the unix filesystem search utility find for many years. Though, like most things, until forced to learn its deeper secrets, I generally get by with only the most basic knowledge.

One of the cool things about find is that you can specify a search and then execute an action on the results, all in one command.

This example is probably my most common use of find:

find . -type d -name .svn -exec rm -fr {} \;

This means: find, in the current directory (.), a directory (-type d), named .svn (-name .svn), and for every result (-exec) remove that directory (rm -fr {}) .  The “{}” represents the matched path string, and the “;” is required to end the “-exec” command.

There’s one standard document on HOWTO get Network Connect working on Ubuntu Linux. It’s mad scientist’s doc: http://mad-scientist.us/juniper.html . However, there are a few things not covered. I’ll assume that you’ve followed mad scientist’s excellent guide before going any further.

Issue #1: 64-bit Ubuntu

By default, when you install java on your 64-bit system, you get a 64-bit java. No surprise there, right? Well, Juniper’s tools don’t play nice with 64-bit java. If you attempt to start the junipernc script you’ll promptly see the “VPN has failed!” error message.

Long have I searched for the magic bullet solution to my bookmark synchronization woes.  I’ve wanted a simple plugin that would synchronize my bookmarks between multiple installations of Firefox and Safari, thus making it simple to access said bookmarks from any computer, or between the two commonly used browsers on my Mac.  I’ve looked at many options, but always the solution only allows me to sync one browser or the other, leaving me looking for some secondary sync tool to get between Firefox and Safari on my Mac itself, not via network or a proper sync.

A while back I wrote about advertising Linux services via Avahi/Bonjour. Since then I’ve made a few changes to my setup.

First, I nixed netatalk for direct AFP support. My primary reason for using it was to gain a more Mac-like network filesystem which would make Time Machine happier. Well, Time Machine uses a sparse bundle disk image on it’s target; after learning about that, using AFP seemed a bit unnecessary. Also, Samba CIFS/SMB seemed to perform better. I don’t have solid benchmarks for this, but simple file copies seemed to be consistenly faster with Samba. One of the biggest annoyances about netatalk was all the extra hidden files and folders it created. I run a hybrid network, I have more Mac machines, but also Windows, plus I browse file systems on the command line quite often; and those excess files pushed me over the edge.

Second, I nixed Time Machine. Just when I thought everything was working perfectly, it completely blew up and could no longer access its data store. Not good for a backup solution. I plan to write about my new home backup solution sometime, but it’s basically rsync with a few key points.

Update: most of this information is still correct but an update for combining service definitions into one file and setting an icon is available here: bonjour-avahi-addendum

In my last post I outlined how I followed others’ directions to enable netatalk on Linux and Time Machine backups to a shared AFP folder. Originally, I also described how to put all your shares on netatalk. I suppose if only have Mac clients or you REALLY want to use AFP, you can do so. As I worked with files over AFP shares, I started noticing that the performance seemed to be quite bad. No, I didn’t benchmark, but copying large video files to a shared folder over my gigabit network was substantially slower over AFP (netatalk) than over CIFS/SMB (samba). I use my network shares pretty heavily, so this was a concern. Also, netatalk tries very hard to replicate an HFS filesystem complete with resource fork support. This means that your shared directories end up with lots of extra folders named “.AppleDouble”(and a few others) containing Mac specific info. (Note: even on CIFS you’ll get the “.AppleDB” folders unless you disable a setting in Finder. I can deal with .AppleDB better than .AppleDouble AND .AppleDB) So, because of these two issues I decided to try using CIFS and samba again.