Tiny Deathstars of Foulness

MacTech just announced MacTech Pro: a new series of one day, regional events that are specifically designed for professional Apple techs, consultants, and support staff.  MacTech Pro Events are single-track, hotel-based seminars that are specifically geared to serve the needs of professional consultants, IT Pros and techs who support others on OS X and iOS.  The first MacTech Pro will take place on March 4th, 2015 in Seattle.

MacTech Pro will take place in nine U.S. cities in 2015 including:

• March 4, 2015 : MacTech Pro, Seattle
• March 25, 2015 : MacTech Pro, San Francisco
• April 15, 2015 : MacTech Pro, Boston
• May 6, 2015 : MacTech Pro, Atlanta
• June 24, 2015 : MacTech Pro, Washington DC
• July 22, 2015 : MacTech Pro, Chicago
• August 12, 2015 : MacTech Pro, New York
• September 2, 2015 : MacTech Pro, Dallas
• September 30, 2015 : MacTech Pro, Denver

Using MacTech’s proven “running order” approach, MacTech Pro will pack in the maximum amount of sessions possible into the time available combined with the opportunity to talk to sponsors, network with peers and meet new contacts. Event topics in 2015 include:

• Deconstructing iCloud Drive: What a Tech Must Know
• Time Machine Deep Dive, and Fitting it Into a Backup Strategy
• The Professional Apple Tech’s Toolbox
• Using OS Resources to Diagnose Troubles
• Caching servers, DNS Tricks, and More
• VPP, DEP, and Under 13: How New Apple ID Requirements Impact You and Your Clients
• Productivity Tools: Best Practices and Uses of Microsoft Office
• Security, Viruses and Malware. It’s real. It’s now. You need to take it seriously.
• Managing Your Clients To Increase Productivity and to Optimize Revenue

MacTech Pro Events are economically priced, include the full day of sessions, lunch, breaks and access to sponsor tables. Those who register early can take advantage of the Early Registration and save $200.00 and pay only $299 to register for any of the nine regional MacTech Pro Events in 2015.

To honor the announcement, those that register this week can save an additional $50 savings for any MacTech Pro Event in 2015 — $249 until January 26th.  EDU pricing for students, educators and staff is $199.

Additional information on topics, sessions, sessions chairs, speaker and sponsorship opportunities are available at

January 22nd, 2015

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, MobileMe

Tags: , , ,

Xcode and other tools can be used to view logs on iOS devices. One of those other tools is libimobiledevice. I usually install libimobiledevice using homebrew, as there are a few dependencies that can be a little annoying. To install homebrew if you haven’t already, run the following command:

ruby -e "$(curl -fsSL"

Once run, follow the prompts to complete the installation. Once homebrew is installed, run the following brew command to download the required components and then libimobiledevice:

brew install -v --devel --fresh automake autoconf libtool wget libimobiledevice

Then run ideviceinstaller:

brew install -v --HEAD --fresh --build-from-source ideviceinstaller

Once these are installed, you can plug in a paired device, unlock it and use the following command to view the logs on the screen:


This is akin to running a tail against the device. Again, the device must be paired. You can use the command line (e.g. if you’re running this on Linux) to view the logs, but if you’re not paired you’ll need to use idevicepair to pair your device, followed by the pair verb (which is very different from the pear verb):

idevicepair pair

You can also unpair using the unpair verb:

idevicepair unpair

When pairing and unpairing, you should see the appropriate entries in /var/db/lockdown. The final option I’m going to cover in this article is the date (very useful when scripting unit tests using this suite. To obtain this, use the idevicedate command, no operators or verbs required:


November 14th, 2014

Posted In: iPhone, Mac OS X, Mac OS X Server, MobileMe, Network Infrastructure

Tags: , , , , , , , ,

You can do some pretty simple testing of ports and network communications using strategies I’ve outlined in the past with tcpdump, trace route, telnet, curl, stroke and of course ping. However, netcat has a few interesting things you can do with it; namely actually run a port super-quickly to test traffic between subnets, forcing scans of ipv6 traffic, debugging sockets, keeping connections alive, parodying through SOCKS 4 and 5 and just checking for daemons that are listening rather than actually sending data to them.

In this first example, we’re going to just check that Apple’s web server is accessible (adding -v for verbose output):

/usr/bin/nc -v 80

The result would be pretty verbose

found 0 associations
found 1 connections:
outif en0
src port 50575
dst port 80
rank info not available
TCP aux info available

Connection to port 80 [tcp/http] succeeded!
HTTP/1.0 408 Request Time-out
Server: AkamaiGHost
Mime-Version: 1.0
Date: Tue, 29 Jul 2014 15:41:34 GMT
Content-Type: text/html
Content-Length: 218
Expires: Tue, 29 Jul 2014 15:41:34 GMT

<TITLE>Request Timeout</TITLE>
<H1>Request Timeout</H1>
The server timed out while waiting for the browser’s request.<P>

If we added a -w to timeout we’ll cut out all the cruft (but wouldn’t know that the server’s at Akamai). Next, we’ll get a little more specific and fire up a test to check Apple’s push gateway at, using port 2195:

/usr/bin/nc -v -w 15 2195

But, I want the cruft for the purposes of this article. Next, we can add a -4 to force connections over IPv4 and check the Apple feedback server and port 2196, also required for APNs functionality:

/usr/bin/nc -v -4 2196

Right about now, something is probably happening at Apple where they’re getting sick of me sending all this data their direction, so let’s add a -z option, to just scan for daemons, without actually sending any data their way:

/usr/bin/nc -vz -4 2196

Because of how NAT works, you might notice that the src port keeps changing (incrementing actually). Here’s the thing, we’re gonna’ go ahead and force our source port to stay the same as our destination port using the -p option:

/usr/bin/nc -vz -4 -p 2196 2196

Now, what if this is failing? Well, let’s spin up a listener. I like to start on my own subnet, then move to another subnet on the same network and ultimately to another network so I’m checking zone-by-zone so-to-speak, for such a failure. So, we can spin up a listener with netcat in a few seconds using the -l option on another host:

/usr/bin/nc -l 2196

Then I can scan myself:

/usr/bin/nc 2196

I could also do this as a range if I forgot which port I used per host:

/usr/bin/nc 2195-2196

Now, as is often the case, if our connection problem is because data isn’t parodying, we can also use nc to check that using the -x operator followed by an IP and then : and a port. For example:

/usr/bin/nc -vz -4 -w 10 -p 2196 -x 2195-2196

Fun times with push notifications. Enjoy.

July 29th, 2014

Posted In: Mac Security, Mass Deployment, MobileMe, Network Infrastructure

Tags: , , , , , , , , , , , , , ,

I’m sure you’ve heard by now. But just in case you hadn’t logged into in awhile or let the to-do lapse, it’s just worth a reminder that iWork Public Beta, the site that you could upload Pages, Numbers and Keynotes to, is being deprecated. The end comes on today.

In other words, if you have documents up on the site, you should download them immediately or you won’t be able to come August. Apple has even provided a document explaining how.

The service that was being provided by the iWork public beta is replaced by iCloud. Using iCloud, you can sync your documents between all of your devices. When you configure iCloud in System Preferences, you are prompted to sync contacts, calendars and bookmarks, but iCloud also gets configured for file synchronization as well at that time. While iCloud doesn’t allow you to edit documents online, you can access them through the iCloud web portal and download them from any computer you like. The new iCloud integration also allows for seeing all your documents in each supported app, when first opened:

July 31st, 2012

Posted In: cloud, iPhone, Mac OS X, Mac OS X Server, Mass Deployment, MobileMe

Tags: , , ,

Sometimes you deploy iOS based devices with iTunes. There are a number of factors that can still force you into iTunes based deployments, such as needing the icons to appear a certain way in iOS. It’s not optimal but it happens. And sometimes you need to give an iPad or iPhone to a user leveraging an existing AppleID that will have a password known by multiple users. Again, not the right way, but there are design requirements that cause you to do it from time to time.

And if you’re using a shared account, one of the last things you want is for users to actually buy stuff with that shared account. Because you might have used that account and connected a credit card to it, it can come up from time to time that you then need to disable that card. Again, none of this is optimal, but it happens.

To remove the card, first open up iTunes.

From here, click on the AppleID in the upper right hand corner of the screen (the email address the account was registered with, usually) and select Account from the drop-down list.

Once the account page loads, click on Edit beside the Payment Type.

At the Edit Payment Information screen, click on None (the big red arrow isn’t actually on the screen at this point, btw).

Then click on Done and there won’t be a payment funding source attached to the account any longer. This can cause a few minor issues with deployments, but turns out way better than having tons of explicit content downloaded to devices using your organizations funds…

May 16th, 2012

Posted In: iPhone, Mac OS X, Mac OS X Server, MobileMe

Tags: , , , , , ,

Whenever someone mentions Apple and BYOD devices, this is what immediately springs to mind as what will invariably walk through the door requiring support:


Apple's Newton

February 25th, 2012

Posted In: iPhone, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, MobileMe

In a previous article I showed how to get and install an SMIME certificate. Now let’s look at installing it into Mail. It’s really, really hard. First, open Mail. Then, click on the Mail menu and select Preferences. Then click on Accounts. Then click on the account you got an SMIME cert for. Then, in the TLS box, select the certificate you want to use.

Next, go to compose a new message. You will see the little disclosure triangle to the left of the From dialog. Click on it and then check the box for the lock and the icon to the right of that, meant to look like a Beholder from Dungeons and Dragons. Beholders see well, so they can see if you’re the person who really is the person allowed to send the email. The lock encrypts email (provided you have a certificate for all recipients) and the eye of the beholder icon signs messages. Once you’re happy with your checkboxes, click on OK.

Now, in your new email message, use the icons. Sign or encrypt. If you don’t have a certificate for a user, have them sign an email and send it to you. When you read their email you should then have their public key in your Keychain. Now, take your 100 sided dice and take the rest of the day off (after all, you just figured out how to make email more secure for your company).

Also, you may notice that in these screens I’m using MobileMe certs. If you use the System Preferences pane to install MobileMe into your account then you’ll be greeted by the cert automatically being installed into your keychain for you. So for MobileMe users, you don’t even need to go get a 3rd party cert. I also use this on my work email, but didn’t want to put those screens in here (after all, I did misplace my tin hat and would hate to get hax0r’d by government goblins before I can track it down).

July 20th, 2011

Posted In: Mac OS X, Mac Security, MobileMe

Tags: , , , , , , , , ,

As most people who are going to read anything I write will already know, Apple released their new cloud service today. The Apple pages are already up, with a splash page on the main site pointing to a dedicated iCloud page. Apple has also anticipated some of the questions that most of us using MobileMe were going to ask in a short Kbase article re: the transition from MobileMe to iCloud:

Additionally, an email went out to MobileMe users today that read:

We’d like to share some exciting news with you about iCloud — Apple’s upcoming cloud service, which stores your content and wirelessly pushes it to your devices. iCloud integrates seamlessly with your apps, so everything happens automatically. Available this fall, iCloud is free for iOS 5 and OS X Lion users.

What does this mean for you as a MobileMe member?

When you sign up for iCloud, you’ll be able to keep your MobileMe email address and move your mail, contacts, calendars, and bookmarks to the new service.

Your MobileMe subscription will be automatically extended through June 30, 2012, at no additional charge. After that date, MobileMe will no longer be available.

When iCloud becomes available this fall, we will provide more details and instructions on how to make the move. In the meantime, we encourage you to learn more about iCloud.

Immediately, users of iOS 4.3.3 or higher, can make use of the new music features. I purchased a song in iTunes and received an alert from the iTunes store to enable the feature.

I could then go over to Store -> Settings from within the iPhone and enable Music and Apps automatically downloading when purchased from another device. It’s also possible to enable transfers over cell networks, although I can’t imagine a lot of people using such an option.

Apple also announced a slew of new features for iOS 5 and for Mac OS X 10.7, Lion. To me the most critical things announced today is that iOS 5 will not need to be tethered to a computer to activate and that it can wirelessly run software updates. Those items are extremely important for growing enterprises of iOS-based devices. The most important things that weren’t bothered to be announced is that Xsan is included in Mac OS X now and that Mac OS X Server survives another profitable year at Apple, but now as an App (or as much an App as you can be when you’re an operating system). These were published to the Apple website. Many thought Xsan would be disappearing, but it is obviously here to stay for some time. The most important thing that we haven’t heard jack-diddly-squat about is the future of our friend Final Cut Server given that Mac OS X can now do a subset of the features out of the box (versioning).

Considering that I have more Apple computers than Imelda Marcos had shoes I have a lot of mixed feelings about synchronizing media between devices. Luckily I don’t have to enable the new features on all of them, although I already have on some…

June 6th, 2011

Posted In: cloud, Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, MobileMe

Large scale mail migrations can be tricky. There is a shareware app that can be used to migrate pst files from the pst format into mbox, which can then be used with Mac OS X

If the migration process needs to be automated (they all seem to at scale) then a script could be written to crawl users, finds the pst files and then convert them. Or it could be done on the client side using a self-destructing launchd item. Conversion syntax for libpst would be something like the following:

readpst -o /output/folder /server/path/user.pst

Before you can use readpst, it needs to be built via libpst on the system that will run any scripts. Download libpst from This can be done with curl:

curl --O libpst-0.5.3.tar.gz

Next, extract the tar:

tar -zxvf libpst-0.5.3.tar.gz

Then cd into the new directory:

cd libpst-0.5.3

Then make libpst:


And now readpst should be available to convert mailboxes. This could be run from a centralized server or distributed to clients.

April 27th, 2011

Posted In: Kerio, Mac OS X, Mac OS X Server, Microsoft Exchange Server, MobileMe, Ubuntu, Unix

Tags: , , , ,

I recently spent a few days trimming down the amount of space consumed by my home folder. In so doing I discovered a number of things I could be doing better with regards to utilization of my drive space. So I decided to offload most of my media (photos, movies, etc) off my laptop and onto my Mac Mini server. I also decided that one thing I’d like to live on both is iTunes.

Note: Before you do anything in this article you should verify you have a good back up. Also, both machines will end up needing to be Authorized for your iTunes account.

There are a lot of ways to keep two iTunes libraries in sync. There are also a number of 3rd party tools that can help you do so. I tested all the tools I could find and decided I’d rather just script it myself. Scripting a synchronization operation in Mac and Linux always seems to come down to a little rsync action. Given that rsync is a little old in Mac OS X, I started out by updating rsync to the latest (3.0.7) using the steps provided on (I added using /tmp):

mkdir /tmp/rsyncupdate
cd /tmp/rsyncupdate
curl -O
tar -xzvf rsync-3.0.7.tar.gz
curl -O
tar -xzvf rsync-patches-3.0.7.tar.gz
cd rsync-3.0.7
curl -o patches/hfs_compression.diff
curl -o patches/crtimes-64bit.diff
curl -o patches/crtimes-hfs+.diff
patch -p1 <patches/fileflags.diff
patch -p1 <patches/crtimes.diff
patch -p1 <patches/crtimes-64bit.diff
patch -p1 <patches/crtimes-hfs+.diff
patch -p1 <patches/hfs_compression.diff
sudo make install
sudo rm -Rf /tmp/rsyncupdate
/usr/local/bin/rsync –version

Provided the version listed is 3.0.7 then we have a good build of rsync and can move on with our next step, getting a target volume mounted. In this case, I have a volume shared out called simply Drobo (I wonder what kind of RAID that is?!?!). Sharing was done from System Preferences -> Sharing -> File Sharing -> click + -> Choose Drobo and then assign permissions. The AFP server is on an IP address of For the purposes of this example, the username is admin and the password is mypassword. So we’ll do a mkdir in /Volumes for Drobo:

mkdir /Volumes/Drobo

Then we’ll mount it using the mount_afp command along with a -i option:

mount_afp “afp://admin:mypassword@” /Volumes/Drobo

Now that we have a mount we’ll need to sync the library up. In this case, the Music directory on the Drobo has a symlink from ~/Music. This was created by copying my Music folder to the drobo and then rm’ing it (fails when trying from Finder):

rm -Rf ~/Music

Then using ln to generate the symlink:

ln -s ~/Music /Volumes/Drobo/Music

Now sync the files. I’m not going to go into all of the options and what they do, but make sure you have permissions to both the source and the target (using the username and password from the user whose data your changing helps):

/usr/local/bin/rsync -aAkHhxv –fileflags –force –force-change –hfs-compression –delete –size-only ~/Music/iTunes /Volumes/Drobo/Music

Note: If you get a bunch of errors about operations failing then consider disabling the Ignore ownership on this volume setting for any external media you may be using.

Now fire up iTunes on the target machine and make sure it works. At this point, I could also share out the Music folder from my laptop and sync back as well, which would effectively allow me to make changes on both machines. However, for now, I only want to make changes on the laptop and not the desktop so there’s no need for a bidirectional sync.

Once the sync is complete, we can tear down our afp mount:

diskutil unmount /Volumes/Drobo

Now that we can sync data, we still need to automate the process as I’m not going to want to type all this every time I run it. First up, I’m going to create a .sh file (let’s just say /scripts/

touch /scripts/

Then I’m going to take the commands to mount the drive, sync the data and then unmount the drive and put them in order into the script:

/bin/mkdir /Volumes/Drobo
mount_afp “afp://admin:mypassword@” /Volumes/Drobo
/usr/local/bin/rsync -aAkHhxv –fileflags –force –force-change –hfs-compression –delete –size-only ~/Music/iTunes /Volumes/Drobo/Music
/usr/sbin/diskutil unmount /Volumes/Drobo

Once created, the script should be run manually and provided it succeeds then it can be automated (ie – creating a LaunchDaemon). If it works after a little while, then you can consider synchronizing your iPhoto and anything else if you so choose. Also, I ended up actually using ssh pre-shared key authentication and doing rsync over ssh. That allows you not to put the password for a host on your network into an unencrypted form in a script. You could do some trickeration with the password, but you might as well look into pre-shared keys if you’re going to automate this type of thing to run routinely. Finally, I also later ended up removing the iTunes Genius files as I started to realize they were causing unneeded data to sync and they would just rebuild on the other end anyway. Hope this helps anyone else looking to build an iLife server of their own!

December 20th, 2010

Posted In: Mac OS X, Mac OS X Server, MobileMe

Tags: , , , , , , , , ,

Next Page »