UrlBlogGrey

Simplified sharing of files between computers is a very compelling reason for installing a home computer network. There are many protocols that simplify file-sharing: FTP, Secure FTP, Samba/Windows File Sharing, NFS, and Apple Filing Protocol (AFP). The last three support mounting remote file-systems on the local machine, making the remote system semi-transparent.

I'm hoping to upgrade my Mac machines to Mac OS X Leopard soon, and would like to take advantage of the new Time Machine feature. Time Machine will periodically backup changes to your system to an external hard-drive or network file-system. This makes file backup and recovery automatic. I have a Linux box that I think would be well-suited for hosting a backup-drive, so I began researching what it might take. I've read that Time Machine will back-up to network file-systems only over AFP. My Fedora Core 6 Linux machine was not configured to use AFP by default. What follow are the steps I took to get AFP support working under Fedora Core 6 with Netatalk 2.x.

The tutorial I found most helpful was on the Gentoo Linux site. I took the steps of installing the 'netatalk' and 'atalk' RPMS using YUM (yum install atalk netatalk).

Next, I changed directories to '/etc/atalk' in order to edit the configuration files provided by atalk. As mentioning in the tutorial, I configured the following services to run:

# Set which daemons to run (papd is dependent upon atalkd):
ATALKD_RUN=no
PAPD_RUN=no
CNID_METAD_RUN=yes
AFPD_RUN=yes
TIMELORD_RUN=no
A2BOOT_RUN=no

Next, I edited the 'afpd.conf' file to contain the changes mentioned in the tutorial. I added the following line at the bottom of the file:

- -noddp -advertise_ssh

I then edited the 'AppleVolumes.default' file to ensure that only home-directories (~) are accessible by AFP. This, too, is described in the tutorial.

Lastly, I configured the AVAHI daemon to publish the service using mDNS (Rendezvous
) by creating the file '/etc/avahi/services/afpd.service' with the XML document provided in the tutorial.

Make sure that the following services are enabled in the Fedora Services tool (run 'setup', select 'System Services'): atalk, avahi-daemon. Also, make sure that AFP (port 548, protocol TCP) is allowed through the firewall, if you are running one. Consider rebooting the machine, and you should be done.

I'm now able to access my Linux machine using AFP, which yields higher transfer rates and is better supported by OS X than the Microsoft-designed SMB protocol. Maybe I'll be able to use Time Machine, too!

Posted by Scott at 9:56 AM | Permalink

First, I'd like to say that my only experience with a hard-drive failure occurred while I was in the process of transferring my files to a new drive. I had a 40 GB drive in a Linux server, and on the drive I stored my entire music collection. At the time, my music collection amounted to about 20 GB of MP3 files; now, it's around 53 GB in size. The drive failed when I connected it to my new PC and attempted to start the machine; the old drive simply would not power on. I had to resort to a trick I had heard about from an IT guy at work: place the broken hard-drive in the freezer for 30 minutes and then retry. Sounds crazy, but I had honestly spent more than an hour trying to power on the drive with traditional methods. Sure enough, placing the drive in the freezer worked and I was able to transfer all of my files intact onto the new hard-drive. I had learned an important lesson: identify the data that's most important to you (large music collection, tax records, photos, etc) and back them up on a separate physical medium - preferably a CD or DVD.

Approximately a month ago, the hard-drive in our 12" PowerBook G4 began performing unreliably. The pattern it followed was that the machine would power on okay, but eventually the hard-drive would "stick" during an arbitrary task. All processes on the machine would be blocked until the hard-drive completed its task, which seemed to be endless unless I intervened by changing the orientation of the laptop. This looked pretty weird: me twisting and turning the PowerBook in the air as part of a desperate attempt to get the hard-drive to function correctly.

The diagnosis was not good: I needed a new hard-drive, stat.

The form-factor for laptop hard-drives is typically different from the form-factor of drives used in desktop computers. In the case of our 2004 12" PowerBook 1.33 GHz G4, it takes a 2.5" ATA-6 drive. To replace our ailing drive, I chose the Hitachi Travelstar HTS721010G9AT00. It's a 100 GB drive that operates at 7200 RPM, which is much faster than the 60 GB 4200 RPM drive that the PowerBook shipped with. This should make for faster application load times, which improves the overall performance of the system.

The installation of the drive required the disassembly of the PowerBook, which involved keeping track of many small screws, but didn't take more than an hour and was fairly straightforward thanks to instructions I found. Now, the hard-drive has been replaced, OS X has been re-installed, and my data has been restored. The drive performs great, and my PowerBook is once again in outstanding health!

Posted by Scott at 9:37 AM | Permalink

I bought a 1.5 GHz G4 Mac Mini a little over a year ago to serve as my primary desktop computer at home. It's been a good machine, though it has always been limited on system resources. The points of contention have been disk space, disk speed, and memory. The Mini shipped with a meager 512 MB of RAM, which is barely enough to have OS X running along with a few apps (Safari/Firefox, iTunes, Terminal). Also, the hard-disk is only 60 GB in size and spins at 5400 RPM (most desktop hard-drives spin at 7200 RPM or more, which provides faster access to data on the disk).

So, I finally got around to upgrading the RAM to 1 GB. The Mini has only a single RAM slot, so I had to purchase a 1 GB memory module to replace the stock 512 MB module. I chose the Kingston 400 MHz PC3200 1 GB RAM module because it was fairly inexpensive ($90 at Fry's) and from a well-known manufacturer. Removing and replacing the Mini's case was an absolute nightmare, though working with the memory modules was a one-minute task. With that behind me, I'm now working with a solid 1 GB of RAM and have seen performance improve noticeably. It's also worth noting that I chose to purchase PC3200 RAM despite the fact that the Mini treats the RAM as PC2700. PC3200 is more readily available, more recent, and cheaper. And the Mini cares not. :)

I chose to upgrade the RAM before upgrading the hard-disk because RAM limitations have a big effect on the performance of applications while they're in use, whereas hard-disk limitations tend to affect performance only during application start-up and file operations (load, save, etc). Also, virtual memory on the hard-disk is used to supplement RAM when there isn't any free RAM left. A slow hard-disk will only make things worse. So, by increasing the amount of RAM available I can safely avoid relying on virtual memory. This lessens the importance of a fast hard-disk. Not to say that I wouldn't appreciate a much faster and larger hard-disk to accomodate my ever-growing digital music collection!

Posted by Scott at 11:06 PM | Permalink

The human mind is extremely capable of processing and acting on information in real-time; however, it's not so good at maintaining a record of information for arbitrary lengths of time. Or, at least that's how my mind works. So, I rely on tools - digital and analog - to get by in this crazy world. One tool that I've become come to rely on at work is NoteBook 2.1 for Mac OS X.

NoteBook works just like the $2 Mead notebooks I used in school, except that it's intended to organize and collect digital information. Most people find themselves working with a mixture of digital information (e-mails, attachments, URLs for webpages, etc.) and analog information (post-it's, T.P.S. reports, etc.) Managing information across the two mediums can be a real pain. I don't know if we'll ever see a product that handles both successfully, but NoteBook does a wonderful job of taking care of digital half.

In my job, I often have a running list of new features I'm working on for the Documentum product, bug-fixes, and customer cases. Prior to using NoteBook, I created folders on my computer to hold attachments and random data associated with my current task. I also created a physical manila file-folder to hold the notes, printed e-mails, and research materials I collected. Correlating the two was difficult, and neither could be searched effectively.

NoteBook allows me to easily aggregate information into pages that resemble pages from a college-ruled notebook. Paste information from an e-mail, drag a URL from Firefox, or drag a ZIP file sent by a colleague - NoteBook ties it all together and maintains a hidden database of all the cruft that you collect in your notebook, just like iTunes takes care of the details of storing MP3 and AAC files without the user's knowledge. This makes is easier to get back to collecting and annotating your information.

I tried the 30-day demo of NoteBook and enjoyed it so much that I bought a copy within a week. I bought an individual license which cost $50. The license is enforced by NoteBook during program initialization by sending a multicast DNS query on the LAN; any other copies of NoteBook running in the LAN respond to the query, which allows NoteBook to determine if the license terms are in question. It's a pretty clever way to enforce the program's license. I don't usually need to run NoteBook on both of my Macs at the same time, so this doesn't create much concern.

Overall, NoteBook is an excellent tool that makes managing information and easy and efficient. I highly recommend at least trying the demo to see if it works for you!

Posted by Scott at 8:49 PM | Permalink

I recently learned of the recall initiated Apple on some 2 million notebook batteries. The recall includes batteries for iBook and PowerBook models produced between 2004 and August 2006 (details). Sure enough, the battery for our 1.33 GHz PowerBook is included in the recall. I should be receiving a replacement battery in a mere 4-6 weeks...

But, in the meantime can I use the PowerBook? Sure! Apple says "...once you've removed the affected battery, just plug in the AC adapter to power the computer until a replacement battery arrives." Um...hwhat? So, that means the PowerBook is grounded and chained to the wall until the new battery arrives.

Hopefully the new battery will provide a longer-lasting charge than the current battery. I've been getting about 3 hours from it lately, though it was better when the battery was new. Incidentally, this is not the first time I've had battery problems with an Apple product: my 3G iPod was down to an hour of battery power, until the hard-drive crashed in July and rendered it dead.

Posted by Scott at 6:01 PM | Permalink

I recently received a fantastic Nokia 6682 mobile phone for use on the Cingular wireless network. Our plan includes unlimited Internet usage for the first month, so I figured I'd experiment with as many features possible while the service is free.

I love the idea of being able to access the Internet on my Apple PowerBook laptop using a mobile phone. Mac OS X supports using a Bluetooth-enabled mobile phone as a modem. I figured that configuring the phone and computer might be difficult, but it was pretty much self-guiding.

First, I paired the phone and computer by invoking the "Setup a New Device" wizard from the Bluetooth preferences in OS X. I indicated that I was adding a mobile phone, and that it should be used for connecting to the Internet using GPRS.

Then, I configured the Bluetooth PPP settings for the Cingular network. Here's what the settings look like (derived from a Cingular support page):

Then, I configured the Bluetooth modem for the Nokia 6682 mobile phone. I chose "Nokia Infrared", which seemed to work alright:

The last thing for me to do was click 'Connect' for the Bluetooth modem on the Mac. Everything just worked perfectly from that point forward. The transfer-rate wasn't anything to get excited about - it was reminiscent of the days of dial-up Internet access. Now, I can get my geek on from any place with mobile network coverage!

Posted by Scott at 10:11 PM | Permalink

I installed Firefox 2.0 Alpha 3 ("Bon Echo") last week on our Macs and have been very pleased with the release. It has shown to be very stable and efficient. My favorite new feature is the inclusion of a Google Suggest search box in the upper right where a simple search box lived previously. Google Suggest is a great application of the AJAX web design strategy that enables completion of search phrases while typing with phrases used in similar searches. Having the convenience of this search box in the browser is very nice.

As a side, I posted just in time with 2 minutes of battery power left! Type, quickly!

Posted by Scott at 8:02 PM | Permalink

It has been a long time since I last updated the Fink installation on my Powerbook running Mac OS X Panther (10.3). I attempted to do a straight upgrade, but encountered problems related to the version of GCC (3.3) installed. So, I decided to perform a clean installation rather than muck about with settings.

Downloaded version 0.7.1 of Fink, which is the most current release compatible with Panther. Installation using the graphical installer worked fine. I then proceeded to install (download & build) the packages I've come to rely on, such as Ethereal.

Posted by Scott at 5:06 PM | Permalink

Earlier today, I started up iTunes to listen to the KCRW Internet radio station while at work. The music played fine, even though all Internet-bound traffic on my employer's network is restricted to HTTP(S). I ran Ethereal for a minute to capture some of my network traffic to find out what protocol iTunes was using, and was surprised to see that it uses the Hyper-Text Transport Protocol (HTTP). HTTP is most often used for web browsing, not streaming audio.

It's interesting that HTTP is used since it relies on TCP, which implies guaranteed delivery of all packets even if the connection can't keep up with the transmission. Most Voice-Over-IP applications use UDP instead of TCP because UDP is a much less "chatty" protocol although it does not guarantee delivery.

Come to think of it, one of my favorite parts of iTunes radio stations is the quality of their sound. This could very well be attributed to the use of TCP. I wonder how many other internet radio services use TCP instead of UDP, too?

Posted by Scott at 9:29 PM | Permalink

I happened upon a personal webpage containing links to a lot of useful Mac tips and tools. One of the tools mentioned was SSHKeychain, which is an Open Source tool intended to provide SSH agent and tunneling functionality. It is also integrated with the OS X Keychain, which means that your password-protected private key can be loaded using just your Keychain master password. This is a really nice feature set that I haven't seen offered in any other product. I intend to download the SSHKeychain progam when I get home, and possibly even get involved in the development of the program.

Posted by Scott at 4:20 PM | Permalink

I've been struggling with the speed and lack of features present in the Mail.app program included in the Panther and Tiger versions of Mac OS X. I've also been experimenting with PGP a lot lately, and Apple's lack of direct support for PGP plugins has led me to migrate my mail messages to the Mozilla Thunderbird e-mail client

Thunderbird is a cleanly-designed e-mail client available for all popular computing platforms (Windows, Mac, Linux, etc.) and is part of the Mozilla family of Open Source products. I was expecting some difficulty in migrating my e-mail data since I was ultimately unable to get my messages out of Microsoft Outlook when moving to the Mac over 2 years ago. This wasn't the case with Thunderbird. Information on the Thunderbird website led me to believe that I could simply copy my "mbox" directories into the Thunderbird library directory and be done with it. Unfortunately, this applies only to the first version of Mail.app, which is not included on Mac OS X Tiger (10.4) (version 2 is included, instead). A quick Google search led me to a blog entry that then directed me to the Apple support site which recommended a program for converting Mail.app's "emlx" files into Thunderbird-friendly "mbox" files.

In 15 minutes, I was working in Thunderbird with all of my old mail messages looking pristine as ever. Now the Thunderbird just needs to tie in to the Mac OS X Addressbook. Then I would be in heaven!

Posted by Scott at 4:50 PM | Permalink | Comments (2)

Natalie bought a new desk from Crate & Barrel as my Christmas present. I assembled it last weekend and situated the Mac Mini on it. I think that the modern styling of the Mini, monitor, speakers and desk provide a very cohesive look. I can't wait to receive the new chair I've ordered so that I can actually make use of the desk! Here are some photos of the setup:

Posted by Scott at 2:39 PM | Permalink

I've been facing the problem of securely mirroring my security credentials across our two Macs at home. The solution I've gone with is to use a Sandisk USB flash drive containing an encrypted, password-protected keychain.

The Apple Keychain is a great application that integrates nicely with any application capable of using its various APIs (Applescript, Cocoa, Carbon, etc). Rather than commiting to memory dozens of usernames and passwords for various web sites and programs, you can consolidate them in a password-protected keychain. Applications like Safari and Mail can then request access to a user's keychain to obtain security credentials.

Having a single keychain per machine would be like keeping your house keys at home, and your work keys at work. It doesn't make sense. Consolidating all of your keys onto a single, portable keychain improves the manageability of the keys and makes them less vulnerable. Imagine leaving on the surface of your desk the key to a filing cabinet located in your office. When you aren't at your desk, the key can be used without your knowledge. Such an opportuntiy for theft would not exist if you took the key with you on a keychain.

So, placing all of your digital credentials on a portable keychain has the ability to improve your overall information security. But it's extremely important that you protect the keychain. Just as with your real keys, anyone who gets your keys has access to your home, office, and car. Therefore, it's important that you protect your digital credentials as much as, if not more than, your real keys. Protecting the keychain in Mac OS X is easy since the keychain is password protected and encrypted. By choosing a strong password for the keychain, you can ensure that anyone who surreptitiously gains physical access to the digital keychain won't be able to view your credentials.

So far, I've had a good experience with my digital flash drive. While switching between my Powerbook and Mini, I simply bring the flash drive with me. Mac OS X automatically refers to the keychain when it is available. I wish that a similar facility were available for Windows PC's so that I could securely store and access my credentials at work.

Posted by Scott at 10:55 AM | Permalink

So, I finally got around to making a couple of AppleScript scripts to automate the tunneling of my SMTP and IMAP traffic through a secure SSH connection established to my mail server. Here are the steps I took.

First, I generated an SSH DSA key from a UNIX shell on my PowerBook. I suggest supplying a password for the DSA key since it will prevent an attacker who has access to the client (PowerBook) from accessing the remote system (mail server) without your DSA password. The command I used to create a key was "ssh-keygen -t dsa".

Next, I added an entry in my Mac OS X keychain for the DSA key password. The keychain is a secure way of consolidating your various security credentials with OS-level protection. I started the Keychain from "Applications->Utilities->Keychain Access". Then, I selected the "File->New Password Item" menuitem and supplied the password associated with the newly created DSA key:

I then created a shell script capable of starting the 'ssh-agent' program. The role of 'ssh-agent' is to cache SSH keys in memory so that the key password needs to be supplied only once. I gleaned this script from the MacTechNotes website. Here's the body of the script:

#!/bin/sh
#
# Check that the ssh-agent is running, and if not, kick it off
#

if [[ -z $SSH_AUTH_SOCK ]]; then
   SOCKETFILE=/Users/${USER}/tmp/ssh/ssh-agent.socket
else
   SOCKETFILE=${SSH_AUTH_SOCK}
fi

/bin/ps -wU ${USER} | /usr/bin/grep "[s]sh-agent" > /dev/null
if [[ $? -gt 0 ]]; then
   /bin/rm -f ${SOCKETFILE}
   /usr/bin/ssh-agent -a ${SOCKETFILE} > /dev/null
   /bin/chmod 600 ${SOCKETFILE}
fi

Posted by Scott at 11:14 AM | Permalink

Now that my new Mac Mini arrived, I am facing the age-old problem of synchronizing information across multiple machines. I have a lot of transient information (addresses, mail, bookmarks, etc.) on my PowerBook that will need to be synchronized with the Mini. Since both machines are equipped with Bluetooth, I thought that they would be able to sync with each other in the same way that they would sync with a Bluetooth-enabled phone or PDA. Apparently, this is not the case. I believe that Apple chose to not enable this feature in order to promote the synchronization features in their .Mac subscription-based service.

So, I've been looking around for alternate methods of synchronizing data on the two machines. It's got to be a network-based solution since moving USB thumbdrives around is not something I'm willing to do.

The fact that both machines are UNIX-based opens the avenue of using the 'rsync' program to synchronize points on the disparate filesystems. Rsync can easily be secured with SSH, operates over any network, and has been around for years. It's also a generic solution that can be used to sync any data, application-oriented or otherwise.

This morning, I came across a Rendezvous/Bonjour-based program called 'address-o-sync' (yeah, pretty bad name) for synchronizing AddressBook data across multiple Macs. Bonjour is a zero-configuration network protocol that is the successor of AppleTalk. It seems like a cool idea, though the program doesn't encrypt any of the data transmitted over the network, and solves synchronization issues for AddressBook only. I'd like to get the Mail data synchronized, too.

I think that I'll try out the rsync solution next week. But only after I've made a verified back-up of my data! :)

Additional links:

• http://www.macdevcenter.com/pub/a/mac/2005/07/22/backup.html


• http://www.alexking.org/blog/2004/12/10/rsync-backup-system/


• http://www.nongnu.org/rdiff-backup/index.html

Posted by Scott at 10:04 AM | Permalink

Yesterday, I ordered a Mac Mini on Amazon. I absolutely can't wait for it to arrive! For a while, I've wanted to upgrade the OS on my Powerbook from 10.3 (Panther) to 10.4 (Tiger) which the Mini will include. The RSS feature in Tiger's Safari web browser has got me super excited, along with support for Java 1.5. Also, I need some extra hard-drive space for my ever-growing digital music collection. The Mini will give me a chance to use the 19" LCD monitor that's been collecting dust for the last year since I moved in with Natalie and mothballed my PC. I'm really hoping that I get one of the unadvertised upgrades rumoured to be in circulation. Yay!

Posted by Scott at 10:43 AM | Permalink

Natalie and I use our 12" Apple Powerbook almost exclusively for home computing. The MP3 library that I brought to our relationship consists of about 36 gigabytes of music. We both have iPods, and wanted to sync them to a single library. Unfortunately, iTunes didn't support this out-of-the-box.

My UNIX experience told me that we could move the music files to a commonly-accessible directory and have each of our iTunes instances reference the files in that directory. That was cool, but it didn't address the problem of changing file contents. If I updated the name of a file, the change would not be reflected in Natalie's iTunes library. This sounded like a big inconvenience.

So, I settled on both of us having symbolic links to a single iTunes library. If one of the changed the name of a file, added new songs, etc., it would be reflected in the other's library. Perfect.

I found a couple of resources on the web that draw the same conclusion (http://captnswing.net/howto/itunes/). Hopefully others will have similar success!

Posted by Scott at 8:19 PM | Permalink

I've been using iTunes for about 2 years now, since purchasing my third-generation iPod. I loved the fact that iTunes would update the ID3 meta-tags in media content automatically when modified through the GUI. This feature enabled me to introduce consistency into my ID3 tag values (artist, album, genre, etc).

However, I was long leary of letting iTunes manage the organization and name of media files on the file-system. I've got thousands of files that were meticulously organizing by hand over the years. I was terrified by the thought of letting a new and unknown application rearrange them. Once you've seen the ill-conceived devices that often lie behind metaphorical curtain, it's hard to bestow your trust to any magician who could easily wreck countless hours of effort. But things were getting out of hand, and I figured it might be worthwhile letting iTunes handle the least-pleasant aspect of maintaing any collection: content management.

Well, iTunes does a wonderful job of managing media files. So well, in fact, that I never even think to look through the directory containing my media files. I have no need to. This makes perfect sense in terms of application usability. I want to listen to a media file, and not be concerned with how it's stored on the file-system. The file-system is simply an artifact of how modern operating systems store content. I want to use content, not be bogged down with read, writing, moving, deleting files. This translates into a beautiful separation of concerns: the user focuses on using content, the application focuses on managing content in forms not pertinent to the user-experience.

Thanks, Apple, for doing it right! And with the ability to search and browse by ID3 meta-tag values, my media has much more dimension that it ever did through applications that relied on me to act as the bridge between application and file-system.

Posted by Scott at 3:35 PM | Permalink

I have been a Quicken user since 2001, and have grown to appreciate its usefulness for aggregating and reporting on spending and investing activities. From 2001 to 2004, I used Microsoft Windows for most of my work at home. However, in the summer of 2004 I purchased an Apple Powerbook. I have gradually ported my information from the PC to my Powerbook, with the greatest problems being my MP3 collection and Quicken.

So, in February 2005 I purchased Quicken 2005 for Mac OS X. I had read reviews on Amazon, and they weren't very flattering. Nonetheless, I figured it was worth evaluating. My immediate reaction was that the reviews were correct: it sucked. I can't import data from most of the institutions supported on the PC version. The user interface is completely different. As are the standard reports.

Two months later, I'm still using Quicken on my Powerbook simply because I don't want to be inconvenienced with balancing my life between two operating systems. But I really miss Quicken on the PC. Hopefully the Mac product will improve in future releases. In meantime, I caution anyone looking to migrate from the PC version to the Mac version.

Posted by Scott at 8:28 PM | Permalink