Filed under: Uncategorized | Tags: front row, itunes, mac mini, mac os x server
Really, to be more accurate, I should say that on Mac OS X Server, Front Row has not been updated and therefore does not understand libraries from the last few versions of iTunes. The reason for this is simple. Front Row is really just a fancy, minimal face for several different data sources, most significantly iTunes. iTunes keeps track of all its media via the file named “iTunes Library” found in your “iTunes” folder. Each new version of iTunes gets all sorts of new bells and whistles, thus requiring the library file to keep track of new kinds of information. As a result, the library file’s format changes quite frequently.
Now, in order for Front Row to display media in the iTunes library, it has to understand the library file’s format. So, it has to be updated every time the iTunes library format is. This is why there are often new versions of Front Row released alongside new versions of iTunes. If the new version of iTunes uses a new library format, Front Row has to be tweaked to work with it.
This is all fine and dandy, except for the inexplicable fact that Apple hasn’t released any updates to Front Row for Mac OS X Server in quite some time. In fact, I’m unable to determine if they’ve ever released any for Leopard Server. Mac OS X gets them literally the moment they’re needed, released simultaneously with the new versions of iTunes that necessitate it. Those same iTunes updates are available for Server, but for some reason the corresponding Front Row updates don’t materialize. You can download the one for Mac OS X, but Installer won’t install it because it’s not intended for Server.
In my own setup, my iTunes library lives on a drive connected to a Mac mini running Mac OS X Server. I do all my work on my MacBook Pro, including my iTunes playing/ripping/purchasing/etc., and it just accesses the library via the network. I’m running the most recent version of iTunes most of the time. The mini is connected to my HDTV so that I can use Boxee and Front Row, but when Server’s copy of Front Row is too old to understand the newer library format the latest iTunes uses, Front Row displays an empty library and the whole point is lost.
The solution is simply to download the update for Mac OS X, open the package with Pacifist and install it anyway per the instructions over on the MacRumors Forums. I haven’t used it a lot since forcing the update this way, but so far things seem to work perfectly.
I honestly can’t imagine why Apple is neglecting Front Row on Mac OS X Server, since it doesn’t seem like it’s really any more effort than what they’re already doing. I can’t imagine Front Row for Mac OS X is especially different than Front Row for Server, if at all. Obviously Front Row probably doesn’t see a lot of use on Mac OS X Server, but it is a standard part of Server’s install so it seems odd to intentionally neglect it. Chalk it up as another one of those things Apple does that makes sense to no one but them.
Filed under: Uncategorized | Tags: amavisd, bug, mac os x server, mail, spam filtering
I had a recent spot of trouble with Mac OS X Server for a client who has mail services running. Due to a hardware issue I had to force off the server, but when I started it back up I noticed that while Postfix would accept mail from senders, it wouldn’t actually deliver it to the destination mailbox. Instead, I’d get this message in mail.log:
postfix/error[7063]: 56118A83885: to=<user@example.com>, relay=none, delay=4776, delays=4776/0/0/0, dsn=4.4.1, status=deferred (delivery temporarily suspended: connect to 127.0.0.1[127.0.0.1]: Connection refused)
The complaint that it wasn’t delivering mail due to an inability to connect to the local host suggested some sort of mail filter not running, of which there are two on Mac OS X Server: clamav (used for virus scanning) and amavisd (used for spam filtering). In my case it was easy to narrow it down, since clamav wasn’t enabled. I checked amavis.log and found that it hadn’t been updated since I’d restarted, so it seemed clear it wasn’t launching. By looking in system.log I could see launchd was trying to start it repeatedly since it was enabled in Server Admin, but it kept failing:
Feb 5 23:59:36 hq org.amavis.amavisd[5404]: Can't send SIG 0 to process [68]: Operation not permitted at /usr/bin/amavisd line 11203.
Feb 5 23:59:36 hq com.apple.launchd[1] (org.amavis.amavisd[5404]): Exited with exit code: 1
Feb 5 23:59:36 hq com.apple.launchd[1] (org.amavis.amavisd): Throttling respawn: Will start in 10 seconds
It was trying to kill process 68, which in my case was kadmind. This didn’t make sense since kadmind deals with Kerberos, something spam filtering has nothing to do with. Fortunately amavisd is a Perl script and it was giving me the line number, so I was able to open it and hunt down the offending code. I found that when amavisd starts, it looks to see if there’s already a PID file (located at /var/amavis/amavisd.pid), gets the PID out of that file and then tries to kill said PID. So, if another copy of amavisd is already running when you start it, it kills the old one so that they don’t conflict. Problem is, in my case the PID file was stale: it hadn’t been cleaned up after amavisd’s last run since I’d had to force off the system, and now the PID was in use by another, unrelated process that it doesn’t have permission to kill.
amavisd does check to see if the PID file was created before the last system startup, which would allow it to ignore stale PID files, but it only does this after trying to kill the old process. This bug was fixed in December in version 2.6.2 of amavis, but unfortunately for Mac OS X Server users, Apple uses version 2.5.1 from May of 2007.
Removing the stale PID file resolved the issue. Its removal allowed launchd’s next automatic attempt to start amavisd to succeed, then a few minutes later Postfix’s mail queue manager started being able to deliver all the mail queued during the downtime to the appropriate mailboxes.
One of the keys to my home media center project is the iTunes library. All my music and all my TV shows are in iTunes, so all facets of the media center orbit around it. Trick is, my media center and my personal computer are two different machines.
Fortunately, it’s pretty easy to share a single iTunes library between two (or more) computers. While iTunes used to insist on your iTunes library living in ~/Music/iTunes, as of version 7 you can keep it wherever you like and simply tell iTunes where it is. So in my case I keep my iTunes library on my Mac Mini media center, since it does double duty as my file server. On my personal computer I mounted the share it’s on and directed iTunes to it, and presto, it functions exactly as if it were residing locally. (Having a gigabit Ethernet link between the two certainly helps keep things snappy, though even when I switch seamlessly to WiFi iTunes can still play TV shows smoothly.) While I don’t run iTunes on the Mini, I do use Front Row, which relies on iTunes’ preferences for the location of the iTunes library. So, I fired up iTunes on the Mini once just to tell it where the library was so that Front Row can use it. Now Front Row on the Mini shares the same library with iTunes on my MacBook Pro. Front Row doesn’t even seem to mind if iTunes is running simultaneously on the other machine, I assume because Front Row only needs read-only access.
There are two small quirks to this setup. First, Front Row doesn’t update play counts on the shared library. The reasoning for this is unclear to me. Perhaps there’s a unique system ID in the library file that identifies the computer that’s last used it, and if it conflicts with the ID of the system Front Row is running on, it doesn’t modify it. I’m going to delve into that further. Second, Front Row reads the library only when it first launches, so when I download a new Daily Show episode on my MacBook Pro, Front Row on the Mini doesn’t know about it. One would think that exiting out of Front Row back to the desktop, then going back in again would resolve this, but after some frustration I discovered that Front Row doesn’t actually quit when you go back to the desktop. It stays running in the background, and thus the library is still cached in it. To get Front Row to rescan the iTunes library, you need to kill it in Terminal or Activity Monitor. The following command in Terminal will suffice:
killall "Front Row"
Once you’ve done that, Front Row can be relaunched and it will reflect the most recent changes to the library.
There are three major protocols in the filesystem sharing world. The most common is of course SMB, that which is used between most Windows systems. There is AFP, Apple’s equivalent, and finally there is my personal favorite, NFS. NFS is used primarily on UNIX-like systems, and fortunately Mac OS X falls into that category. For Mac users, AFP is usually the best choice just because of how well-integrated into the OS the protocol is. However, the demise of resource forks that corresponded with the advent of Mac OS X has made the advantages of AFP on the Mac platform a bit more muted.
NFS lacks some important things that AFP and SMB both provide. Security is probably the most immediately concerning issue, as there is no user authentication. While AFP and SMB both establish a TCP connection that first requires interactive authentication, NFS instead uses UDP, which as a stateless protocol doesn’t even have connections. Packets just get passed back and forth between the hosts, there’s no “connected” state between them. (Version 4 of the NFS standard does add TCP support, but that doesn’t help my soon-to-be-mentioned problem.) Authentication is host-based, meaning you tell the server what hosts can access what shares and with what privileges.
NFS’s use of stateless UDP can simultaneously be a virtue. In my home, all my work gets done on a MacBook Pro. I like to move my computer around, but also need high-speed access to large amounts of data. I keep a sizable iTunes library on a file server, along with my Parallels virtual machines and a variety of other large pieces of data. So, I have an 802.11n wireless network in addition to gigabit Ethernet. I keep the gigabit plugged in when I’m at my desk, then switch to wireless when I want to move elsewhere. However, this solution of dual interfaces introduces a new problem: when I switch interfaces, it kills most of my connections. This means that, if I’m using an AFP or SMB file server, I have to disconnect from it before I physically disconnect. This means quitting iTunes, stopping any video encodes I have going in the background, stopping all my virtual machines, etc. It’s not the end of the world, but it definitely disrupts my workflow. It would be really nice to avoid this hassle, and fortunately NFS provides a way to do just that.
To explain how, it helps to understand a few basic things about how traffic moves via TCP and UDP. When you establish a TCP connection, it is between two IP addresses. Each network interface has its own IP address, so TCP connections are bound to particular interfaces. For example, if I’m connected to both Ethernet and wireless, let’s say my Ethernet interface has the IP 10.0.0.10 and my wireless interface has 10.0.0.11. I of course have my interface priority set to prefer Ethernet over wireless, so if I start downloading something in my web browser (which uses TCP), it will start doing so over the Ethernet. Let’s pretend the server I’m downloading from is 10.0.0.20. So, the TCP connection is established between 10.0.0.10 and 10.0.0.20. Now, if part-way through this download I disconnect my Ethernet cable, the connection will be lost and the download will abort. The fact that I also have a simultaneous wireless connection doesn’t matter, since that interface has a different IP address and the connection does not involve that address. I could, however, attempt the download again immediately after its failure and it would work, this time with a connection established via the wireless interface.
Now, let’s start the example over, but instead of downloading a file via the web, let’s transfer a file via NFS. First, in order for this to work, the NFS server has to be configured to allow access from both the Ethernet and wireless interfaces’ IP addresses. Now, I mount the NFS server, start copying a large file, then disconnect the Ethernet. There is a brief pause as my OS adjusts to the change, then the progress resumes, albeit at a slower pace. Sure enough, the data is now moving over wireless. Why? Well, let’s look at what happens when you disconnect an interface. The computer notices that you’ve lost a link so it brings down the interface, killing all TCP connections (like your web download). Any NFS data en route from the server to that interface gets lost along the way, but your computer notices it hasn’t arrived and re-requests it. This request now goes out the wireless interface, and the NFS server sees the request coming from a different IP than before, but given that NFS is using stateless UDP it doesn’t really care so it sends the data along to the new IP. And lo, your NFS transfer continues as if nothing happened (albeit slower due to the wireless’s lower speed).
And that is why I love NFS.
This post is part of a series documenting the creation of a home media hub. It may be helpful to read through the other posts in the series in order to better understand this one.
One remaining issue is the mini’s lack of a 2nd Ethernet interface. Obviously if I want to use it as a firewall, I’ll need a second Ethernet port. I was originally going to pick up a USB Ethernet adapter like a Netgear FA120 and have the Parallels VM hosting pfSense take control of the adapter directly, but I discovered that traffic shaping probably won’t work in that situation. Another strategy, however, would be to get one of those same adapters and pair it with Sustainable Softworks’ USB-to-Ethernet driver to get Mac OS X see it, then use Parallels’ “bridge” function to communicate through it. I was all set to move down that path when Apple released the MacBook Air and, along with it, the Apple USB Ethernet Adapter.
Their adapter works on any Mac running 10.5.2 or later, so I elected to use that instead of a 3rd party adapter driven by a different 3rd party’s driver. While I do find using Apple products over other manufacturers’ just because they’re made by Apple distasteful, experience has show me it tends to be less problematic in the long run.
The mini’s built-in Ethernet is gigabit, so obviously I want to use that as the LAN interface. Given that one of the mini’s tasks will be performing file server duties, LAN bandwidth is important. So, the USB adapter will be handling WAN duties. Since I only want the Parallels VM running pfSense to be communicating with this adapter, I need to configure OS X to ignore it. This is simply a matter of going into the Network system preference and setting “Configure IPv4″ under the TCP/IP settings to “Off”.
This way OS X should ignore any data coming through that interface, making things more secure. While I should obviously do the same for the “Configure IPv6″ menu, a problem appears if I do. If I set both to “Off”, the interface stops being available. It appears in the Network system preferences, but it stops being available to Parallels for bridging. After an hour of futile efforts, I determined that at least one protocol must be enabled, so I kept IPv4 off and IPv6 at automatic. This shouldn’t be a serious security concern as I’m pretty sure my ISP doesn’t route IPv6 traffic to me, but I’m going to delve into the OS X firewall in the near future and set up some rules to drop any traffic coming in through that interface, be it via IPv4 of IPv6. I’ll be sure to post about it once I tackle it.
So, our WAN interface is ready. OS X is ignoring it, but Parallels is ready to see it.
Filed under: Uncategorized | Tags: drm, itunes, mac mini, memory, nas, netatalk, parallels, power efficiency, time machine, via
This post is part of a series documenting the creation of a home media hub. It may be helpful to read through the other posts in the series in order to better understand this one.
I’ve done a lot of thinking on the subject of what computer to use as the core of this whole project. An Apple Mac mini is an obvious choice, but I’m also very fond of building custom systems. I’ve always found VIA’s processor line very alluring, both because of their low power consumption and because of their potential for silent operation. I’ve long had a custom, tiny Mini-ITX firewall planned out in my head that is silent, using a CompactFlash card in place of a hard drive and no fans. There are a lot of VIA CPU-based motherboards out there geared specifically for home media centers or network gateways, packing features such as multiple Ethernet ports, hardware acceleration for MPEG-2 and MPEG-4 decoding and on-board CompactFlash slots. Hardware-wise, these would be better equipped than a Mac mini.
The problem is, I have two things I want my solution to do that recommend or require the system to be running Mac OS X. First, I’d like to keep my MacBook Pro’s Time Machine backup on a network volume. This is supported by Apple in Leopard. It seems like this may be possible using Netatalk under Linux or BSD if you apply a little elbow grease, but I couldn’t find anyone saying with reasonable certainty that it works 100% properly. Given that Time Machine is my backup solution, I don’t want to have the hard drive fail on my MacBook Pro only to discover that my Time Machine backup is incomplete or corrupted. So, while it might work with Netatalk, it’s not a risk I’m comfortable taking.
The second issue is that I want to be able to watch the videos I purchase or rent off iTunes (like my Daily Show subscription) on the system, and iTunes’ DRM makes this effectively impossible under Linux or BSD. Despite my disdain for DRM, that issue is show-stopping. So, despite my interest in a VIA-based system, that option is off the table. I definitely want to revisit that idea at a later date, though.
After this deliberation, I selected a new Mac mini (Mid 2007). The reasoning I chose this over any other Mac should be fairly obvious: It’s small, powerful and power efficient.
Starting with this project, I’m trying to be more aware of power consumption. I intend to purchase a Kill A Watt, but until I do I’ll be relying on research and reasoning. While the mini’s power supply is rated at 110 watts, my use is going to pretty light and others have measured the previous Intel mini’s idle power consumption at 20 watts. Parallels uses some CPU power even when the virtual machine is idle, but my previous experience leads me to believe that even with two VMs running I will be utilizing less than 25% of the total available CPU power.
The physical size is also quite convenient, as it’s about half the width of a home stereo component and is designed to be stackable. The AirPort Extreme Base Station I’ll be using has the exact same footprint and will stack nicely on top of it. Furthermore, LaCie made some hard drives a few years ago creatively named the mini, which were designed to accommodate a Mac mini perched atop them. I snagged one off eBay that had a failed HD, removed the dead drive and replaced it with a 750GB PATA one. While all three of these components stack very neatly, my only concern is heat. I’ll be keeping an eye on how warm the stack gets and might add some spacers to let a little more air flow between them.
Horsepower wise, the Mac mini appears to be more than adequate. I did some testing at the local Apple Store and found that, so long as there’s enough memory available, I was able to play a 1080p H.264 video from the Apple trailers site smoothly, even with two Parallels VMs running in the background. Parallels is quite memory hungry, and testing on my MacBook Pro made it clear that between the host OS and the two VMs 2GB of memory could be exhausted without much difficulty. While Apple claims that the Core 2 mini only supports up to 2GB of memory, it’s well-established that it can address 3GB if you install it. This creates a conundrum, however, as all the Macs with integrated graphics (like the Intel Mac minis) yield their best graphical performance when their memory consists of two same-size SO-DIMMs. 3GB is therefore not ideal, since the GPU will take a bit of a performance hit due to the mismatched SO-DIMMs. A little research revealed that 4GB can be installed, but only 3GB will be usable. This lets us have more than 2GB of memory without mismatching the SO-DIMMs. While I’m not certain this avoids the graphical performance hit, everything I can find indicates it should. Obviously there’s some wasted RAM here, but Crucial sells a 4GB memory kit for $104 so it’s not an expensive waste.
Next up, the networking…
Filed under: Uncategorized | Tags: airport, apple tv, hd, home, mac mini, nas, parallels, playstation 3, server, time machine, virtualization, wifi, wrt54g
I’m half-way through the largest personal tech project I’ve ever undertaken. Its purposes are varied: improve, simplify and make more efficient. Nearly every aspect of my home technology situation is affected.
Here are the general goals:
- I want an HDTV.
- I want a PlayStation 3.
- I want a simpler, more efficient network setup.
- I want my data stored centrally on my network.
- I want to be able to browse my media library on said HDTV.
Now, this seems relatively simple, but each of these simple things entail numerous additional undertakings. I have tons of little ideas I’ve coddled and developed over the past few years, and this is basically an excuse to try them all out. This project touches all my favorite topics: networking hardware, A/V hardware, multiple operating systems, virtualization, the works.
The HDTV and PlayStation 3 are pretty self-explanatory, but the network setup is where things get interesting. Currently my network consists of a DSL connection from the venerable bway.net running into a Linksys WRT54G running DD-WRT. That, in turn, is connected to an Apple AirPort Extreme Base Station (Gigabit), which then has a Pentium III-powered Dell mini-tower hanging off it. The Dell runs FreeBSD and hosts web and mail services.
This is obviously an overcomplicated setup. The Dell is big, power-hungry and, while not exactly loud, not as quiet as I’d like it to be. The Linksys and AirPort are each fine in those regards, both being small and comparatively low-power, but they are clearly redundant, as they are both WiFi-enabled routers with built-in switches. The devil is in the details, though: I use the Linksys as my perimeter firewall because it is much more configurable than the AirPort. I can use QoS to keep BitTorrent from saturating my connection when I’m trying to do something else (especially useful with services that are sensitive to latency, like VoIP or gaming) and I can fine-tune the firewall rules much more specifically than the AirPort allows. I use the AirPort because it has a gigabit Ethernet switch, and because it can provide 802.11n wireless, both abilities the Linksys lacks. If I want to add a multimedia PC like an Apple TV or a MythTV box into the mix in order to satisfy goal 5, this just clutters things even more. It’ll draw additonal power, require additional cables and require additional shelf space.
But what if I could combine three of those devices into one? Here’s the idea: Have a Mac mini running two Parallels virtual machines. One VM runs pfSense and takes over duties for the Linksys, handling firewall and Internet routing duties, and the other VM runs FreeBSD, handling the web and mail hosting that the Dell currently handles. Thus the Linksys and Dell are replaced by the Mac mini, accomplishing goal 3. Then have the mini’s host OS, Mac OS X Leopard, launch Front Row (as there isn’t really any need for Parallels to be visible), connect it to the HDTV with a DVI cable and you’ve got 90% of the functionality of an Apple TV on top of all of this. Goal 5 accomplished. Finally, for goal 4, I can just connect some external storage to the mini and share it via Mac OS X file sharing, which will even allow me to do Time Machine backups via the network.
So: Simple goals, but a pretty complex solution. Lots of new ideas to play with, and plenty of things to learn about along the way. I’ll spend the next few posts catching up to where I am with this currently, and then it’ll just follow the developments as they happen.
