SWY's technical notes

Relevant mostly to OS X admins

Monthly Archives: September 2014

iOS8 Family Sharing with an Apple ID for a child

It’s a happy coincidence that my < 13 year old kid accumilated the savings to buy the iPod Touch he’s wanted right as iOS 8 with Family Sharing hit the market.  Here’s my experience with the process:

1) Upgrade a device of mine to iOS8.  Pretty straightforward process- but always make a backup anyway.

2) In Settings: iCloud, there’s now a new “Set Up Family Sharing…” link2014-09-17_16_09_38



3) Since my kid is under 13, the “Create an Apple ID for a child” option is the right choice:



4) Yep, this seems like exactly what I want:



5) But this isn’t.  I have my own domain. I don’t need a proliferation of email addresses.  Even if email is mostly dead to young people these days, and full of spam, email still isn’t going away.  Oh well, the THOU SHALT USE ICLOUD DOMAIN rule appears to be non-negotiable, so I begrudgingly complied.



6) After the standard, mandatory Security Questions (should I answer for me? For him? Must be me, since he couldn’t yet have a favorite singer in High School), I can enable Ask To Buy.




7) With that, my kid has an Apple ID.  The next day, his iPod Touch arrives, and out of the box, we attempt to authenticate with the new Apple ID.  Being a refurb, and day 1 after iOS 8 release, it ships with iOS7.  I’m not sure if that’s the cause, but when trying to use his new Apple ID, we get the most confusing error dialog I’ve ever received from an Apple product.  And I’ve received a few.


I eventually gave in on trying to authenticate with his Apple ID, it consistently gave the above.  I signed in with my ID, attached to iTunes, and started downloading the iOS 8 update.  Following that install, I signed out, and now it was happy to accept his Apple ID credentials on the first try.


8) With that configured, it was time to see the electronic  “please dad, may I have an app?” conversation.  The Buy button gets a new behavior in this situation:



And promptly over on my device, I see an alert from Family, which links to this page in the App Store:




9) I approve and authenticate to the App Store, and with this, the installation proceeds on his Touch:



Just because it isn’t logged…

… doesn’t prove it’s not working.

With the release of iOS8 this week, I wanted to make use of Caching Server on work’s guest WiFi, as I figure I’ll have a few early adopter staff looking to upgrade their personal devices.  In my setup, the guest SSID is tagged with a VLAN, which is routed straight out to the internet.  My Caching Server had no connection to that VLAN, so the first step was to add that VLAN to the switch port the OS X Server running Caching Server was connected to.

With the Guest WiFi VLAN now available to the Caching Server, it needed a new network interface associated with that VLAN.  That is done via System Preferences: Network: Gear button: Manage Virtual Interfaces:




Screen Shot 2014-09-16 at 9.52.16 AM

Then the [+] to Add a new VLAN:

Screen Shot 2014-09-16 at 9.53.29 AM

Name it usefully, associate it with the proper tag and interface for your environment (probably Ethernet), and [create].

With this, my new virtual interface came up with an IP on the Guest wireless subnet, as would be expected.

Per OSX Server documentation, the default behavior for Caching Server is to listen on all interfaces.  To confirm this was happening, I put Caching Server into verbose mode via

sudo serveradmin settings caching:LogLevel = verbose

And restarted the service, while tailing /Library/Server/Caching/Logs/Debug.log .  This is where I got concerned: the log only acknowledged “registering” on the local subnet, with no mention of the VLAN network.  After some troubleshooting, I was able to confirm it really was listening on the VLAN, by noting what port the HTTP server was started on (as listed in the log), and pointing a browser from a machine on the Guest WiFi to that Caching Server:port combination.

When you do this, the client browser will return a blank page, and Debug.log on the Caching Server will record a Error 400 – Bad Request from that source machine, citing a non-whitelisted URL.  This confirms that the service is listening on the added VLAN, despite not being mentioned in the verbose log.  Therefore, the documentation is correct: unless overridden, Caching Server is active on all interfaces. Don’t let the fact that the log doesn’t acknowledge multiple interfaces bother you, as I did.

If you wish to use Caching Server for multiple networks in this way, it’s important to make sure they both appear to the internet from the same WAN IP.  Caching Server will only be available to clients that contact Apple from the same network that the Caching Server did.


And then it turns out that Caching Server can’t/won’t/doesn’t cache iOS8.  Sometimes you just can’t get ahead of the game.