Rui Paulo’s blog

Several times in the past I needed to query sysctls from Python. I was unhappy that this was not possible because the Python standard library didn’t include a sysctl function. I even created a Python module just to do this. Of course, you may already be thinking “ctypes! ctypes! ctypes!”. Yes, that’s what I’m going to talk about.

ctypes is a Python module to access foreign C types and functions, namely sysctlbyname(3). It’s easy to work with, here’s an example:

from ctypes import *

libc = CDLL("libc.so")

size = c_uint(0)

libc.sysctlbyname("kern.ostype", None, byref(size), None, 0);

buf = create_string_buffer(size.value)

libc.sysctlbyname("kern.ostype", buf, byref(size), None, 0);

>>> buf.value

'FreeBSD'

Python ctypes are available in Python 2.5 and up.

It’s about time that I release this project to the wild. It’s a really simple thing, nonetheless.

aimon is a system monitor much like MRTG, but specifically designed to monitor acpi_aiboost(4). acpi_aiboost(4) reports these values under FreeBSD and is present on several ASUS workstations and servers.

So, if you want nifty graphics about your server temperature, voltage and fan speed, this is for you. 

Here’s an example of how it looks like:

If you’re interested, the project home page is: http://fnop.net/~rpaulo/aimon/.

I’ve come across a blog post by Roy Hooper that explains how to setup CalendarServer on FreeBSD. I haven’t tried it yet, but I suppose it should work without much effort.

For those who don’t know, CalendarServer is a WebDAV server that implements the CalDAV extensions. This basically mens that you can register a bunch of users in your CalendarServer and using iCal or Chandler (to name a few) you can send invitations to meetings, share calendars and other nifty things that could help you organize better your company.

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.

Read the rest of this entry »

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:

1. Build & Install net/netatalk from ports.
2. Edit /usr/local/etc/AppleVolumes.default
3. 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.
4. Optionally, remove the “~” already present in that file if you don’t want to share users home directories.
5. Add “netatalk_enable=”YES”" and “afpd_enable=”YES”" to /etc/rc.conf.
6. /usr/local/etc/rc.d/netatalk start (nothing will be printed).

On the Mac OS X machine (running Leopard, of course):

1. 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.
2. 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.
3. 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”.
4. On the Terminal, type “defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1″. This is the crucial thing.
5. Go to “System Preferences”, “Time Machine” and enable it. The networked volume will now show up on the list.
6. 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”.
7. Select the networked Volume from the Time Machine volumes list.
8. Initiate the backup!

Enjoy!

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:

• Install rEFIt.
• Download http://people.freebsd.org/~rpaulo/boot.tgz.
• Extract boot.tgz to your / HFS+ partition (don’t worry, rEFIt will find it).
• Reboot.
• Select /boot/loader.efi from the rEFIt boot prompt.

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:

• Grab loader.efi from http://people.freebsd.org/~rpaulo/.
• Install rEFIt.
• Copy loader.efi to, for example, /efi/freebsd/loader.efi.
• Reboot and select loader.efi from the rEFIt boot menu.

Don’t expect nothing fancy though.

UPDATE: the bug is not in the FORTH library as I originally though.

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/.

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.