In our mail server migrations from 10.5 to 10.6 we’ve been running the migrate_mail_data.pl Perl script to move our mail data from Cyrus to Dovecot. Seemingly at random email rules will work for users but vacation messages will not. I’ve spent the better part of Christmas Morning (Merry Christmas btw 
trying to sort this out. As is typical for Apple when simplifying the GUI side (abstracting things Apple from the Open Source goodies) they kind of complicate what’s happening behind the scenes. In trying to resolve this problem, here are the notes I’ve taken thus far.
What I know to this point 200912251448PST…
The wiki writes sieve scripts to /Library/EmailRules/sievescripts/ . Each script is the users GUID ending in .sieve. They are owned by _teamsserver user and group and perms are 770. Also in /Library/EmailRules is vacationIndex.db . Still sorting out what that does.
There is a LaunchDaemon, /System/Library/LaunchDaemons/com.apple.wiki_sieve_manager.plist that watches /Library/EmailRules/mailsieve and executes /usr/bin/wiki_sieve_manager on changes to that directory . I don’t know what’s put into mailsieve at this point.
By some mechanism scripts are moved into /var/spool/imap/dovecot/sieve-scripts/GUID/ . Unlike the .sieve files in /Library/EmailRules these are owned by the user. The group is mail and perms are 700. Inside the GUID directories should be four files
- .dovecot.lda_dupes which tracks to whom auto replies have been sent.
- wiki_server_rules.sieve which should have the sieve file from /Library/EmailRules/ if I’m at all understanding what’s going on here.
- dovecot.sieve which is a symlink to wiki_server_rules.sieve and the file the server looks for as the current sieve as defined in /etc/dovecot/dovecot.conf .
- dovecot.sievec which is may be the binary of the script. Trying to think back to hand editing sieve scripts a few years ago. Not sure though.
I posed the question on Twitter this week “What’s your favorite iPhone app?” I received tons of responses and have compiled this list of 61 apps that you people love! Here’s the list complete with links to the iTunes apps store::
Social Networking:
Bump
AudioBoo
FourSquare
FaceBook
Focus for Facebook
Twitter:
Twitterific Premium
Tweetie 2
Twittelator Pro
SimplyTweet
TweetDeck
Echofon Pro
Twitter Helpers:
BirdBrain
Boxcar
Productivity:
Things
Evernote
VehiCal Car Expenses Manager
Handbase Database Manager
1Password
reQall
Dropbox
Jaadu VNC
Awesome Notes
Photography:
CameraBag
ShakeItPhoto
AutoStitch
Best Camera
Purchasing:
Starbucks Card Mobile
B&N Bookstore
Messengers:
WhatsApp Messenger
Games:
imobsters
Monopoly
Traffic Rush
Kids:
Monkey Preschool Lunchbox
News/RSS Readers:
Newsstand
iReddit
Google Reader
Entertainment:
VLC Remote
Koi Pond
SlingPlayer
Apple Remote
MyDVR
Sky+ Remote Record Only available in the UK
Utilities:
Lithium
Convertbot
RedLaser
Business:
EasyVoice Mobile
UPS
Reference:
Mactracker
Sports:
NBA League Pass Mobile
Navigation:
Navagon
Peaks
MotionX
Travel:
Tripit- Travel Organizer
Weather:
The Snow Report
Health & Fitness:
C25K
Finance:
Chase Mobile
USAA
mac-fusion has a new Mac mini with Snow Leopard Server. It ships with (2) 500GB hard drives but it’s not configured as any kind of RAID. We wanted to know how the redundancy and reduced capacity of a RAID 1 compared to the speed and size benefits of running a RAID 0. We also wanted to find the baseline speed of a non RAID setup. So we pitted the mini against itself and several other Macs for good measure.
Methodology
We used Quickbench 4.0.4. It says it’s Leopard compatible but there’s no mention of Snow Leopard. That would really be a drag if all this data was not valid. But unfortunately the developer’s support forums have been offline all week so we’ll go with it for now. We ran the Standard test using transfer sizes ranging from 4KB to 1MB and taking the average. We did 5 passes to try and even out any big anomalies. All machines were tested after being rebooted, and, except for the Xserve with SSD, all servers were running a minimum set of services. We threw the Xserve SSD in just to see if the MacBook Air SSD performance was hobbled at all. Results are in MB per second.
Sequential Read
Sequential Write
Random Read
Random Write
Thoughts
It’s no surprise that you get what you pay for and the Xserve with RAID 5 Donkey Kongs the others in all but Random Read, although not by a huge margin. But if you’re supporting a workgroup of more than a handful of people and providing a broad range of services, it’s the way to go. The MacBook Air w/ the SSD drive puts up some pretty solid numbers in the Random Read area. That’s the nature of SSD. And that’s what makes it feel pretty sporty compared to a regular HD. But it’s still slower than a production Xserve box with an SSD. I don’t know if that’s the drive or the bus or something else but would love some comments on that. Even though the old mini didn’t come anywhere near saturating it’s limited 1.5Gbps SATA bus, I don’t think it helped anything. That thing is S L O W. The Mac min Server however is much faster even with a single drive. But, to address what we set out to find, if you’ve got a good backup plan in place, the size and speed benefits of a RAID 0 seem to be justified offering nearly 2x the performance in both sequential tests, a small boost in Random Read and nearly a 50% gain in Random Write.
Specs
Mac mini – Mac mini (Late 2006) 1.66GHz Intel Core Duo, 2GB RAM, 60GB, Mac OS X Server 10.6.2
Mac mini Server – Mac mini (Mac OS X Server, Late 2009) 2.53GHz Intel Core 2 Duo, 4GB RAM, 2x500GB, Mac OS X Server 10.6.2
MacBook Air SSD – MacBook Air (Mid 2009) 2.13GHz Intel Core 2 Duo, 2GB RAM, 128GB SSD, Mac OS X 10.6.2
MacBook Pro – MacBook Pro (15-inch, Mid 2009) 3.06GHz Intel Core 2 Duo, 4GB RAM, 500GB Seagate Momentus 7200RPM, Mac OS X 10.6.2
Mac Pro – Mac Pro Two 2.66GHz Dual-Core Intel Xeon “Woodcrest” processors, 8GB RAM, 1TB Hitachi Deskstar, Mac OS X 10.5.8
Xserve SSD – Xserve (Early 2009) Two 2.66GHz Quad-Core Intel Xeon “Nehalem” processors, 12GB RAM, 128GB SSD, Mac OS X Server 10.6.2
Xserve RAID 5 – Xserve (Early 2009) One 2.26GHz Quad-Core Intel Xeon ”Nehalem” processor, 6GB RAM, 3x1TB Apple Drive Modules, Xserve RAID Card, Mac OS X Server 10.6.2
The Domain Name System, DNS, makes the Interweb go around. It’s the White Pages of the internet, translating names to numbers, a forward lookup, and numbers to names, a reverse lookup. Having a handle on DNS can help you with basic troubleshooting as a user and is essential for managing and maintaining servers as a Systems Engineer. Without getting any more preachy, let’s move on. There are three primary record types in forward looks ups. An “A” record maps a name directly to an IP. “CNAME” is an alias record. It maps one name to another. “MX” defines mail exchangers responsible for a domain and the associated priority. The lower the number, the higher the priority, i.e. closer to final mail delivery. On the reverse DNS side of the coin, there’s the “PTR” record that maps an IP to a name. Generally speaking, unless you’re doing DNS admin, you don’t need to sweat other records like SOA and NS. Now let’s take a look at the services that actually makes up the Domain Name System. First there’s something called a resolver that lives on your computer. It, well, resolves the query, “What is the IP address of a specific host?” The resolver issues a recursive query to the DNS Servers in the Network System Preferences that you’ve probably pulled down via Dynamic Host Configuration Protocol, DHCP. If one of those Name Servers has previously looked up the IP address of the host in question, it hands it over. If it doesn’t have that information cached then it needs to go to the Root Name Servers. These guys are the top of the food chain in DNS land and are responsible for the Top Level Domains, TLDs, both the generic (com, net, edu, etc.) and country codes (us, au, ca, etc.). Think of them as the phone company. They have a critical piece of information for resolution to take place. That being which Name Servers are authoritative for a particular domain, or which phone book contains the information we seek. Once the Name Servers (phone book user) that our resolver is querying has retrieved those authoritative Name Servers (phone book) from the Root Name Servers (phone company), they query those Name Servers (phone book), directly for the IP of the host in question and return that to our resolver which hands it off to the requesting application. Whew.
OK so we’ve identified the critical players, let’s put it into action. You fire up Safari and type in www.mac-fusion.com, because that site is rad. Moments later you’re there. We take it for granted but how do it know? Think about it. How did Safari know where all the HTML files were stored for rending the web page you’re checking out? The entire process is pretty fascinating. For now we’ll leave out a whole lot and focus on the big picture. So when you type in the address and hit Enter in Safari, all kinds of stuff happens behind the scenes. And here’s the high altitude, conversational, view of it all:
So if DNS really is the White Pages of the Internet let’s see how hard we can flog this phone book analogy. After hitting Enter, Safari says, “Hey, can you put me in touch with www.mac-fusion.com?” The Network System Preference checks the DNS servers it has, and sends the resolver off on it’s mission. The resolver then asks the DNS servers from Network System Preferences, “I’m looking for www.mac-fusion.com. Do you know which phone book they’re in?” To which, they reply, “I don’t have that cached, let me check with the phone company.” After being asked, the phone company replies, “Ok, mac-fusion.com, you’ll want to check in the following phone books.” And the Root Name Servers pass along the Name Servers authoritative for the domain, in our case, ns2.mac-fusion.com, ns2.mydyndns.org and ns3.mydyndns.org. Network System Preferences says, “Sweet!” and cracks open the phone book, querying those Name Servers. At this point the DNS server from Network System Preferences has looked up the .com and .mac-fusion parts (name resolution takes place from right to left) of the fully qualified domain name, FQDN, now it needs the specific host, www. But a hah! When asking the phone book for www, the DNS server finds www is an alias, a CNAME, for the actual server, hemi.mac-fusion.com. “So where’s hemi at?” demands the DNS server. “hemi’s at 72.26.106.202.”, replies the phone book. The DNS server replies to resolver which turns to Safari and says, “Blow up www.mac-fusion.com at 72.26.106.202.” And Safari does. And you’ve got a kick ass website in front of you.
The End.
Except for the Open Directory and the http and the arp and a million other crazy things that go on behind the scenes. I feel a sequel coming.
