I notice that most of my readers’ homes consist of one/more FreeBSD server(s) and one/more Apple computer(s) running Mac OS X. In this post I will introduce the multicast DNS and service discovery concepts. Both are very will suited for a workstation running Mac OS X and a home server running FreeBSD. In the previous blog post I showed how you could use FreeBSD as a Time Machine backup and now I’m going to show you how to make your FreeBSD look like an Apple Xserve.
I assume familiarity with FreeBSD administration and some networking concepts.
So, here’s a quick howto on how to setup Time Machine on Mac OS X so that it backups to a networked machine running FreeBSD.
On the FreeBSD machine:
- Build & Install net/netatalk from ports.
- Edit /usr/local/etc/AppleVolumes.default
- Append: “/your_time_machine_path TimeMachine allow:your_user_name cnidscheme:cdb options:usedots” and replace your path and your username in the proper places.
- Optionally, remove the “~” already present in that file if you don’t want to share users home directories.
- Add “netatalk_enable=”YES”" and “afpd_enable=”YES”" to /etc/rc.conf.
- /usr/local/etc/rc.d/netatalk start (nothing will be printed).
On the Mac OS X machine (running Leopard, of course):
- Mount your remote volume. Command+K on the Finder and then type: “afp://<machine IP address or local hostname if you have a local DNS server>”. You can’t type the machine name because we’re not using multicast DNS.
- Build a sparse bundle image using “Disk utility” (HFS+ case-sensitive formatted). Usually, the size should be something that gives you enough room for expansion. If you want to backup your whole MacBook/iMac/etc. disk, you can set the sparse bundle image size the same as the disk your are backing up.
- The name of this image is important. It should be “Your_Computer_Name_MACAddress.sparsebundle”. Check your computer name from the “Sharing” section of “System Preferences” and the MAC address comes from the interface you’ll be using to do the backup. I really recommend using your Wired interface. Check the MAC address via ifconfig(1) or via the “Network” section of “System Preferences”. E.g., if you’re John Doe, have a MacBook and your MAC address is 00:01:02:03:04:05, your file should be named “John Doe’s MacBook_000102030405.sparsebundle”.
- On the Terminal, type “defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1″. This is the crucial thing.
- Go to “System Preferences”, “Time Machine” and enable it. The networked volume will now show up on the list.
- Before selecting the volume on which you’ll dump the backup, copy the sparse bundle file you’ve created to your networked volume called “TimeMachine”.
- Select the networked Volume from the Time Machine volumes list.
- Initiate the backup!
EDIT: As Remko points out in the comments, the MAC address is not restrictive. So, if you want to backup via wired interface and after that via wireless, Time Machine will work using both interfaces. I suppose that Time Machine inspects all MAC addresses in your machine and then searches a sparse bundle in the networked volume that matches.
Many people use a Version Control Systems to mirror their $HOMEs in several networked computers. This has clear advantages of doing incremental backups of your $HOME (TimeMachine, anyone? :-)) and keeping it in sync across several computers. In the past, I’ve used Mercurial to do this job, but some months ago I switched to Subversion because I wanted to use try the one-VCS-for-all meme (Subversion is now being used by FreeBSD in case you don’t know). Unfortunately, it didn’t work out well. The computer where I kept the svn repo had a horrible hard disk failure and this made me wonder if I was using the right tool. Today, I switched back to Mercurial and I guess this is the right tool for the job.
Well, EFI is nothing new, but, currently, we only support EFI booting on FreeBSD/ia64. Before Apple started shipping MacBooks with EFI, there would be a small interest in adding EFI boot loader to anything but ia64. But now that there are thousands of Intel Macs, interest has risen.
I’ve been asked by several people to make available a patch for my recent take on the FreeBSD/i386 EFI boot loader. I’m also making available binaries for i386.
So, if you have a Core Duo/Solo MacBook (Core 2 won’t work yet, sorry) and want to try it out, do the following:
One thing worth playing with is the ‘col’ command I just added. It basically changes the screen resolution. So here’s your chance to have something super leet: a FreeBSD boot loader at 1280×800 or more! Also, EFI will make your HFS+ partition avaiable to the boot loader, so doing an ‘ls’ will really show your files.
Oh, the source code? Here: http://people.freebsd.org/~rpaulo/efi.tgz.
One final thing: I’m still working on kernel booting, so don’t expect it to work.
Something I’ve wanted to do for sometime was to boot FreeBSD on my MacBook via EFI. EFI is a firmware standard for BIOS and OS writers to deal with. Basically, it replaces the good old MBR booting scheme and is capable of much more, namely, all the real mode restrictions are gone, TCP support in the firmware and, if you write a driver, you can have UFS, ZFS, whateverFS support on the firmware itself
Apparently, I couldn’t make it work for last years’s Summer of Code, but now something works. I was able to boot loader.efi on my MacBook and see a “FreeBSD/i386″ boot message. Yay! Unfortunately, there seems to be a bug in (probably) the FORTH library and it sometimes hangs or, if it doesn’t hang, it displays a lot of garbage.
So, you have a MacBook and want to try this out? Great! Here’s the procedure:
Don’t expect nothing fancy though.
UPDATE: the bug is not in the FORTH library as I originally though.
So, I’ve been offline for some days now and I’ll continue to be until the end of the month. Development of tcpad is going fine and I just committed a few days of work into Perforce. This new work includes parsing of the TCP options and further SEQ/ACK analysis.
SEQ/ACK analysis is probably the most challenging task of this project, so it hasn’t been finished yet.
The good news is that I’m learning a lot about TCP and its extensions and it’s being thrilling!
In other news, my TCP ECN work will most likely be committed to FreeBSD-CURRENT RSN.
I’ve been hacking the NetBSD lii(4) driver so that it works under FreeBSD. This driver is most notably found on the Asus line of sub-notebooks, Eee PC. So far, so good. I did not finish the porting yet, but the mechanical changes are mostly done.
The reason for this is that I bought an Eee PC 701, hence I need this driver, :-), although I haven’t touched my Eee PC yet (it’s at my parents house). But I will do the first testing this weekend.
If you have this hardware and would like to help with the effort, please email me.
The effort is being revision controlled at //depot/user/rpaulo/lii/.
So, I found some time to continue my SoC work. tcpad is now capable of handling the most important TCP FSM transitions, like CLOSE_WAIT, FIN_WAIT_1, SYN_SENT, etc. I also implemented a basic timer facility that cleans up old connections in TIME_WAIT state. This still doesn’t honor the 2MSL required by the RFC, but it’s a start.
I also cleaned the code a little and improved the debugging macro.
Next is SEQ/ACK analysis.
So, I’ve been busy studying for this month’s exams. Hence, not much tcpad development time was spent.
Nonetheless, I’ve did the initial pcap processing, that is, saving selected packets to a pcap dump file. And that works.
The next step is finish the TCP/IP processing. This includes FSM transitions and SEQ/ACK analysis.
I’ve been running Mac OS X on my MacBook for some time mostly because I needed a very stable platform and good power management for college. But now that college is over, I decided to install FreeBSD again.
After a few hours of compiling/installing/configuring, I booted up Xorg. Of course, I never created a /etc/X11/xorg.conf file because new Xorg versions can auto-detect the hardware. After a few seconds of fluxbox usage, Xorg crashes. WTH? I tried to start it up again. The graphics card registers are in an unexpected state (that’s what the Xorg intel driver tells me). Double WTH?
Only a reboot fixed it.
The problem was that Xorg was using a 24 or 32 bit depth. It works fine with 16 bit.
Unfortunately, this is the “state-of-the-art” when it comes to Xorg and I’m so tired of it that I got back to Mac OS X. I’ve been enduring XFree/Xorg/<insert crappy application here> pain for some years now and I’m only 22 years old. I can try to fix FreeBSD, but I don’t have time to fix all the other applications.
As you may have guessed from the title, this means that I won’t devote my time to the FreeBSD on the MacBook project and, instead, I will dedicate myself to other FreeBSD projects.