Tiny Deathstars of Foulness

High Sierra sees the Caching service moved out of macOS Server and into the client macOS. This means administrators no longer need to run the Server app on caching servers. Given the fact that the Caching service only stores volatile data easily recreated by caching updates again, there’s no need to back the service up, and it doesn’t interact with users or groups, so it’s easily divested from the rest of the Server services.

And the setup of the Caching service has never been easier. To do so, first open System Preferences and click on the Sharing System Preferences pane.

From here, click on the checkbox for Content Caching to start the service.

At the Content Caching panel, the service will say “Content Caching: On” once it’s running. Here, you can disable the “Cache iCloud content” option, which will disable the caching of user data supplied for iCloud (everything in here is encrypted, by the way). You can also choose to share the Internet Connection, which will create a wireless network that iOS devices can join to pull content. 

Click Options. Here, you can see how much storage is being used and limit the amount used. 

defaults read /Library/Preferences/

Which returns the following configurable options:

Activated = 1;
CacheLimit = 0; DataPath = “/Library/Application Support/Apple/AssetCache/Data”; LastConfigData = <BIGLONGCRAZYSTRING>; LastConfigURL = “”; LastPort = 56452; LastRegOrFlush = “2017-09-11 16:32:56 +0000”; LocalSubnetsOnly = 1; PeerLocalSubnetsOnly = 1; Port = 0; Region = 263755EFEF1C5DA178E82754D20D47B6; ReservedVolumeSpace = 2000000000; SavedCacheDetails = {
SavedCacheSize = 0;
ServerGUID = “EB531594-B51E-4F6A-80B9-35081B924629”;
Version = 1;}

This means that all those settings that you used to see in the GUI are still there, you just access them via the command line, by sending defaults commands. For example, 

defaults write /Library/Preferences/ CacheLimit -int 20000000000

You can

AssetCacheManagerUtil status

Which returns something similar to the following:

2017-09-11 11:49:37.427 AssetCacheManagerUtil[23957:564981] Built-in caching server status: {
Activated = 1;
Active = 1;
CacheDetails = {
iCloud = 4958643;
“iOS Software” = 936182434;};
CacheFree = 472585174016;
CacheLimit = 0;
CacheStatus = OK;
CacheUsed = 941141077;
Parents = ();
Peers = ();
PersonalCacheFree = 472585174016;
PersonalCacheLimit = 0;
PersonalCacheUsed = 4958643;
Port = 56452;
PrivateAddresses = (“”);
PublicAddress = “”;
RegistrationStatus = 1;
RestrictedMedia = 0;
ServerGUID = “EB531594-B51E-4F6A-80B9-35081B924629”;
StartupStatus = OK;
TotalBytesDropped = 0;
TotalBytesImported = 4958643;
TotalBytesReturnedToChildren = 0;
TotalBytesReturnedToClients = 166627405;
TotalBytesReturnedToPeers = 0;
TotalBytesStoredFromOrigin = 166627405;
TotalBytesStoredFromParents = 0;
TotalBytesStoredFromPeers = 0;

You can also use AssetCacheManagerUtil to manage tasks previously built into the Server app. To see the available options, simply run the command:

bash-3.2# /usr/bin/AssetCacheManagerUtil

Which would show the following:

Options are:
-a|–all show all events
-j|–json print results in JSON
-l|–linger don’t exit
2017-09-11 11:57:30.066 AssetCacheManagerUtil[24213:569932] Commands are:
moveCacheTo path
absorbCacheFrom path read-only|and-destroy

As such, to enable the server:

bash-3.2# /usr/bin/AssetCacheManagerUtil activate 

To disable the server

bash-3.2# /usr/bin/AssetCacheManagerUtil deactivate

To check if the server can be activated

bash-3.2# /usr/bin/AssetCacheManagerUtil canActivate

To flush the cache of assets on the server:

bash-3.2# /usr/bin/AssetCacheManagerUtil flushCache 

To reload settings if you make any changes:

bash-3.2# /usr/bin/AssetCacheManagerUtil reloadSettings

To move the database

/usr/bin/AssetCacheManagerUtil moveCacheTo "/Volumes/SONY/Library/Application Support/Apple/AssetCache/Data"

Finally, if you’d like to see the caching server your client system is using, you can run the following command:

/usr/bin/AssetCacheLocatorUtil 2>&1 | grep guid | awk '{print$4}' | sed 's/^\(.*\):.*$/\1/' | uniq

And if you use Jamf Pro and would like to use this as an extension attribute, that’s posted here: I didn’t do any of the if/then there, as I’d usually just do that on the JSS.

Note: To see how AssetCache interacts with Tetherator, see Tethered Caching of iOS Assets from macOS 10.12.4.

September 28th, 2017

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , ,


Added 3 new flags into precache tonight: –jamfserver, –jamfuser, and –jamfpassword. These are used to provide a Jamf Pro server (or cloud instance), the username to an account that can list the mobile devices on that server, and a password to that account respectively. Basically, when you provide these, the script will pull a unique set of models and then precache updates for them. It’s similar to grabbing a list of devices: curl -s -u myuser:mypassword And then piping the output of a device list to: perl -lne 'BEGIN{undef $/} while (/<model_identifier>(.*?)<\/model_identifier>/sg){print $1}' And then running that array as an input to Hope this helps make the script more useful!

May 13th, 2017

Posted In: iPhone, Mac OS X Server

Tags: , , , , , ,

Fixed an error that was causing downloads not to run. Enjoy.

September 23rd, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , ,

Precache, available at, is a script that populates the cache on an OS X Caching server for Apple updates. The initial release supported iOS. The script now also supports caching the latest update for an AppleTV. To use that, there’s no need to include an argument for AppleTV. Instead, you would simply  run the script followed by the model identifier, as follows: sudo python AppleTV5,4 Screen Shot 2016-04-27 at 1.30.17 PM

April 28th, 2016

Posted In: Apple TV, iPhone, Mac OS X, Mac OS X Server, precache

Tags: , , , ,

AppleTVs automatically update. They do so using a process similar to how iOS updates, but instead of looking at the feed I posted in, they look at The AppleTV feed is similar to that available for iOS updates, with each dictionary having roughly the same data:
<string>Apple Inc.</string>
To construct a URL to a zip, you would then simply merge the _BaseURL and the _RelativePath to the asset from the feed for a given model, in the above example, ending up with the following URL to manually download tvOS 9.2 for AppleTV 5,3:
BTW, Applednld is load balanced between and, both within Apple’s Class C.
You don’t need two / characters in the path, but if you take the same process from my earlier post, you end up with

April 27th, 2016

Posted In: Apple TV, Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , , , , ,

A little while back, I did a little writeup on how the OS X Caching Server caches updates at The goal was to reverse engineer parts of how it worked for a couple of different reasons. The first was to get updates for devices to cache to my caching server prior to 15 people coming in before it’s cached and having caching it down on their own. So here’s a little script I call precache. It’s a little script that can be used to cache available Apple updates into an OS X Server that is running the Caching Service. To use, run the script followed by the name of the model. For example, for an iPad 2,1, you would use the following syntax: sudo python iPad2,1 To eliminate beta operating systems from your precache,use the –no-beta argument: sudo python iPad2,1 --no-beta I’ll probably add some other little things nee and there, this pretty much is what it is and isn’t likely to become much more. Unless someone has a good idea or forks it and adds it. Which would be cool. Enjoy. Screen Shot 2016-04-24 at 12.24.23 PM

April 25th, 2016

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

Tags: , , , , ,

The Caching Server in OS X Server 5 is pretty simple, right? You open up the server app and then click on the On button and you’re… off… to… the… races… Yup. There are also a few options that you can configure using the Server app. You can configure which IP addresses (or networks) are able to access your server. You can configure where the cache is stored. You can configure the amount of Cached used. And you can clear out that cache. Boom. Including the ON button, you’ve only got 5 things you can do here. Pretty easy. To script kicking off the service as just a proxy that caches all patches that it can, simply use the following command: sudo serveradmin start caching The above command simply enables the service and starts the daemon. At that point, it registers with Apple and starts caching what it can. For many environments, this is pretty much all you need to do. But you can also configure the options available in the GUI, and a few that aren’t, using the command line. And then there are some pretty cool things you can do in Caching under the hood that aren’t included in the Server app. Let’s look at what it might take to script setting up the Caching service. For example, if we wanted to do scripted Caching Server deployments. Well, we’d need to start the service. By default the service would start with only local subnets being able to access the service and all available content would be heated. Additionally, the default location for the cache is /Library/Server, with no limit to the cache and a reserved volume space of 25000000000 bytes. You can see this by looking at the output of serveradmin with a settings verb and the caching service, as follows: sudo serveradmin settings caching Which results in the following: caching:ServerRoot = "/Library/Server" caching:ReservedVolumeSpace = 25000000000 caching:LocalSubnetsOnly = yes caching:Port = 0 caching:CacheLimit = 0 caching:DataPath = "/Library/Server/Caching/Data" Now, let’s open up the caching server to the world, assuming of course that people can’t get to it unless they’re routable on our network. This makes caching for multiple subnets in a given LAN environment much simpler. To do so, we’d feed that caching:localSubnetsOnly back in, with a no: sudo serveradmin settings caching:LocalSubnetsOnly = no Once the service is started, you will be able to perform tasks, such as disabling the iCloud caching option. This is done by setting the AllowPersonalCaching key to false, as follows in the /Library/Server/Caching/Config/config.plist. <key>AllowPersonalCaching</key> <integer>false</integer> This can be done using the serveradmin command as well, using the settings verb with the caching service and the AllowPersonalCaching key, as follows: sudo serveradmin settings caching:AllowPersonalCaching = no You can also limit the space that the Caching Server uses for cached iCloud data with the Settings verb, the caching service and the PersonalCacheLimit keep, provided the PersonalCacheLimit doesn’t exceed the CacheLimit. For example: <key>PersonalCacheLimit</key> <integer>200000000000</integer> In /Library/Server/Caching/Config/ you’ll find a file called Config.plist. Here, you’ll find way more settings, including those not output when you run serveradmin. You can actually drop lots of settings into new servers by copying this file into the correct location. However, prior to doing so, you’ll need to sanitize the file. There are two unique keys that should never be copied between servers. The first is the ServerGUID. The ServerGUID is a generated unique identifier that the server creates for itself when started. <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ""> <plist version="1.0"> <dict> <key>CacheLimit</key> <integer>0</integer> <key>DataPath</key> <string>/Library/Server/Caching/Data</string> <key>LastConfigData</key> <data> XXX </data> <key>LastConfigURL</key> <string></string> <key>LastPort</key> <integer>52303</integer> <key>LocalSubnetsOnly</key> <true/> <key>Port</key> <integer>0</integer> <key>ReservedVolumeSpace</key> <integer>25000000000</integer> <key>SavedCacheDetails</key> <dict/> <key>SavedCacheDetailsOrder</key> <array> <string>Mac Software</string> <string>iOS Software</string> <string>iCloud</string> <string>Books</string> <string>iTunes U</string> <string>Movies</string> <string>Music</string> <string>Other</string> </array> <key>SavedCacheDetailsStrings</key> <dict> <key>de</key> <dict> <key>Books</key> <string>Bücher</string> <key>Mac Software</key> <string>Mac-Software</string> <key>Movies</key> <string>Filme</string> <key>Music</key> <string>Musik</string> <key>Other</key> <string>Anderes</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS-Software</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>en</key> <dict> <key>Books</key> <string>Books</string> <key>Mac Software</key> <string>Mac Software</string> <key>Movies</key> <string>Movies</string> <key>Music</key> <string>Music</string> <key>Other</key> <string>Other</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS Software</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>es</key> <dict> <key>Books</key> <string>Libros</string> <key>Mac Software</key> <string>Software Mac</string> <key>Movies</key> <string>Películas</string> <key>Music</key> <string>Música</string> <key>Other</key> <string>Otros</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>Software iOS</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>fr</key> <dict> <key>Books</key> <string>Livres</string> <key>Mac Software</key> <string>Logiciels Mac</string> <key>Movies</key> <string>Films</string> <key>Music</key> <string>Musique</string> <key>Other</key> <string>Autres</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>Logiciels iOS</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>it</key> <dict> <key>Books</key> <string>Libri</string> <key>Mac Software</key> <string>Software Mac</string> <key>Movies</key> <string>Film</string> <key>Music</key> <string>Musica</string> <key>Other</key> <string>Altro</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>Software iOS</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>ja</key> <dict> <key>Books</key> <string>ブック</string> <key>Mac Software</key> <string>Mac ソフトウェア</string> <key>Movies</key> <string>ムービー</string> <key>Music</key> <string>ミュージック</string> <key>Other</key> <string>その他</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS ソフトウェア</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>ko</key> <dict> <key>Books</key> <string>책</string> <key>Mac Software</key> <string>Mac 소프트웨어</string> <key>Movies</key> <string>동영상</string> <key>Music</key> <string>음악</string> <key>Other</key> <string>기타</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS 소프트웨어</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>nl</key> <dict> <key>Books</key> <string>Boeken</string> <key>Mac Software</key> <string>Mac-software</string> <key>Movies</key> <string>Films</string> <key>Music</key> <string>Muziek</string> <key>Other</key> <string>Overig</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS-software</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>zh-CN</key> <dict> <key>Books</key> <string>图书</string> <key>Mac Software</key> <string>Mac 软件</string> <key>Movies</key> <string>影片</string> <key>Music</key> <string>音乐</string> <key>Other</key> <string>其他</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS 软件</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>zh-Hans</key> <dict> <key>Books</key> <string>图书</string> <key>Mac Software</key> <string>Mac 软件</string> <key>Movies</key> <string>影片</string> <key>Music</key> <string>音乐</string> <key>Other</key> <string>其他</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS 软件</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>zh-Hant</key> <dict> <key>Books</key> <string>書籍</string> <key>Mac Software</key> <string>Mac 軟體</string> <key>Movies</key> <string>影片</string> <key>Music</key> <string>音樂</string> <key>Other</key> <string>其他</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS 軟體</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>zh-TW</key> <dict> <key>Books</key> <string>書籍</string> <key>Mac Software</key> <string>Mac 軟體</string> <key>Movies</key> <string>影片</string> <key>Music</key> <string>音樂</string> <key>Other</key> <string>其他</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS 軟體</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>zh_CN</key> <dict> <key>Books</key> <string>图书</string> <key>Mac Software</key> <string>Mac 软件</string> <key>Movies</key> <string>影片</string> <key>Music</key> <string>音乐</string> <key>Other</key> <string>其他</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS 软件</string> <key>iTunes U</key> <string>iTunes U</string> </dict> <key>zh_TW</key> <dict> <key>Books</key> <string>書籍</string> <key>Mac Software</key> <string>Mac 軟體</string> <key>Movies</key> <string>影片</string> <key>Music</key> <string>音樂</string> <key>Other</key> <string>其他</string> <key>iCloud</key> <string>iCloud</string> <key>iOS Software</key> <string>iOS 軟體</string> <key>iTunes U</key> <string>iTunes U</string> </dict> </dict> <key>SavedCacheSize</key> <integer>0</integer> <key>ServerGUID</key> <string>A955E484-E2A6-4759-A8F4-108CF9B733A7</string> <key>ServerRoot</key> <string>/Library/Server</string> <key>Version</key> <integer>1</integer> There’s always some sanity checking you can do. The main reason I’ve seen the server not want to start is because the server cannot register with Apple. The first thing that the server does when it registers is establishes a connection to Apple using the ServerGUID and then pulls down more settings from and if needed, begins heating the cache. Now, if the serveradmin command reports back a fullstatus that the server is pending and never makes a connection, there are two issues I’ve seen occur. The first is that you copied the ServerGUID from another host that’s already registered with Apple. The second is an error for “The operation couldn’t be completed” with an error code of 1. To see this, you can run serveradmin with fullstatus and then the service identifier and the caching:startupStatus identifier: caching:RegistrationStatus:error = <62706c69 73743030 d4010203 04050618 19582476 65727369 6f6e5824 6f626a65 63747359 24617263 68697665 72542474 6f701200 0186a0a4 07081112 55246e75 6c6cd409 0a0b0c0d 0e0f1056 4e53436f 64655a4e 53557365 72496e66 6f584e53 446f6d61 696e5624 636c6173 73100180 00800280 035f1014 636f6d2e 6170706c 652e7365 72766572 6d677264 d2131415 165a2463 6c617373 6e616d65 5824636c 61737365 73574e53 4572726f 72a21517 584e534f 626a6563 745f100f 4e534b65 79656441 72636869 766572d1 1a1b5472 6f6f7480 0108111a 232d3237 3c424b52 5d666d6f 7173758c 919ca5ad b0b9cbce d3000000 00000001 01000000 00000000 1c000000 00000000 00000000 00000000 d5> caching:RegistrationStatus:errorDescription = "The operation couldn’t be completed. ( error 1.)" caching:RegistrationStatus:errorCode = 1 caching:RegistrationStatus = 0 This is usually because the server cannot make a connection to Apple. Check that the server can ping, or access the server. Most of the time I’ve found that this involves a proxy. To sanity check for this in a script, try and curl down a copy of There’s more, but I’m out of time. Will come back to this.

October 23rd, 2015

Posted In: Mac OS X Server, Mass Deployment

Tags: , , , , , , , ,

The first thing you’ll want to do on any server is setup the networking for the computer. To do this, open the System Preferences and click on Network. You usually want to use a wired Ethernet connection on a server, but in this case we’ll be using Wi-Fi. Here, click on the Wi-Fi interface and then click on the Advanced… button.

At the setup screen for the interface, provide a good static IP address. Your network administrator can provide this fairly easily. Here, make sure you have an IP address and a subnet mask. Since we need to install the Server app from the Mac App Store, and that’s on the Internet, you’ll also need to include a gateway, which provides access to the Internet and using the DNS tab, the name servers for your Internet Service Provider (ISP).
Once you have provided a static IP address, verify that you can route to the Internet (e.g. open Safari and visit a website). Provided you can, the first step to installing macOS Server onto High Sierra is to download the Server app from the Mac App Store. To do so, open the App Store app and search for Server. In the available apps, you’ll see the Server app from Apple. Here, click on Buy and let the app download. That was pretty easy, right. Well, the fun has just gotten started. Next, open the app. When you first open the Server app, you’ll see the Server screen. Here, you can click on the following options:
  • Other Mac: Shows a list of Macs with the Server app that can be remotely configured. Choosing another system does not complete the setup process on the system you’re working on at the moment.
  • Cancel: Stops the Server app setup assistant and closes the Server App.
  • Continue: Continues installing the Server app on the computer you are using.
  • Help: Brings up the macOS Server manual.

Click Continue to setup macOS Server on the machine you’re currently using. You’ll then be prompted for the licensing agreement from Apple. Here, check the box to “Use Apple services to determine this server’s Internet reachability” and click on Agree (assuming of course that you agree to Apple’s terms in the license agreement).

Installing macOS Server must be done with elevated privileges. At the prompt, enter the credentials for an account with administrative access and click on the Allow button.

The services are then configured as needed and the command line tools are made accessible. This can take some time, so be patient. When the app is finished with the automation portion of the configuration, you will be placed into the Server app for the first time. Your first order of business is to make sure that the host names are good on the computer. Here, first check the Host Name. If the name doesn’t resolve properly (forward and reverse) then you will likely have problems with the server at some point. Therefore, go ahead and click on Edit Host Name… Here, enter the fully qualified address that the server should have. In the DNS article, we’ll look at configuring a good DNS server, but for now, keep in mind that you’ll want your DNS record that points to the server to match what you enter here. And users will use this address to access your server, so use something that is easy to communicate verbally, when needed.

At the Change Host Name screen, click Next. At the “Accessing your Server” screen, click on Internet and then click on the Next button.

At the “Connecting to your Server” screen, provide the Computer Name and the Host Name. The Computer Name is what you will see when you connect to the server over Bonjour and what will be listed in the Sharing System Preference pane. The Host Name is the fully qualified host name (fqdn) of the computer. I usually like to take the computer name and put it in front of the domain name. For example, in the following screen, I have osxserver as the name of the computer and as the host name.

Once you have entered the names, click on the Finish button. You are then prompted to Change Host Name. Click on Change Host Name at this screen. Next, let’s open Terminal and run changeip with the -checkhostname option, to verify that the IP and hostname match:
sudo changeip -checkhostname
Provided that the IP address and hostname match, you’ll see the following response. sudirserv:success = “success” If the IP address and hostname do not match, then you might want to consider enabling the DNS server and configuring a record for the server. But at this point, you’ve finished setting up the initial server and are ready to start configuring whatever options you will need on the server.

October 4th, 2015

Posted In: Mac OS X Server

Tags: , , , , , , ,

These days, new services get introduced in OS X Server during point releases. OS X now has a Software Caching server built to make updates faster. This doesn’t replace Apple’s Software Update Server mind you, it supplements. And, it’s very cool technology. “What makes it so cool” you might ask, given that Software Update Server has been around for awhile. Namely, the way that clients perform software update service location and distribution with absolutely no need (or ability) for centralized administration. Let’s say that you have 200 users with Mac Minis and an update is released. That’s 200 of the same update those devices are going to download over your Internet connection, at up to 2 to 3 gigs per download. If you’re lucky enough to have eaten at the Varsity in Atlanta, just imagine trying to drink one of those dreamy orange goodnesses through a coffee stirrer. Probably gonna’ be a little frustrating. Suck and suck and suck and it’ll probably melt enough to make it through that straw before you can pull it through. For that matter, according to how fast your Internet pipe is, there’s a chance something smaller, like an update to Expensify will blow out that same network, leaving no room for important things, like updates to Angry Birds! Now, let’s say you have an OS X Server running the new Caching service. In this case, the first device pulls the update down and each subsequent device uses the WAN address to determine where the nearest caching service is. If there’s one on the same subnet, provided the subnet isn’t a Class B or higher, then the client will attempt to establish a connection to the caching service. If it can and the update being requested is on that server then the client will pull the update from the server once the signature of the update is verified with Apple (after all, we wouldn’t want some funky cert getting in the way of our sucking). If the download is stopped it will resume after following the same process on a different server, or directly from Apple. The client-side configuration is automatic so provides a seamless experience to end users. Pretty cool, eh? But you’re probably thinking this new awesomeness is hard as all heck to install. Well, notsomuch. There are a few options that can be configured, but the server is smart enough to do most of the work for you. Before you get started, you should:
  • Be running Mountain Lion with Server 2.2 or better.
  • Install an APNS certificate first, described in a previous article I wrote here.
  • Have an ethernet connection on the server.
  • Have a hard drive with at least 50GB free in the server.
  • The server must be in a Class C or smaller LAN IP scheme (no WAN IPs can be used with this service, although I was able to multihome with the WAN off while configuring the service)
Once all of the requirements have been met, you will need to install the actual Caching Service. To do so, open from the /Applications directory and connect to the server with which you would like to install the Caching service. Click on Caching from the SERVICES section of the Server sidebar. Here, you have 3 options you can configure before starting the service. The first is which volume with which to place updates. This should typically be a Pegasus or other form of mass storage that is not your boot volume. Use the Edit… button to configure which volume will be used. By default, when you select that volume you’ll be storing the updates in the Library/Server/Caching/Data of that volume. The next button is used to clear out the cache currently used on the server. Click Reset and the entire contents of the aforementioned Data directory will be cleared. Next, configure the Cache Size. Here, you have a slider to configure about as much space as you’d like, up to “Unlimited”. You can also use the command line to do some otherwise unavailable numbers, such as 2TB. Once you’ve configured the correct amount of space, click on the ON button to fire up the service. Once started, grab a client from the local environment and download an update. Then do another. Time both. Check the Data folder, see that there’s stuff in there and enjoy yourself for such a job well done. Now, let’s look at the command line management available for this service. Using the serveradmin command you can summon the settings for the caching service, as follows: sudo serveradmin settings caching The settings available include the following results: caching:ReservedVolumeSpace = 25000000000 caching:SingleMachineMode = no caching:Port = 0 caching:SavedCacheSize = 0 caching:CacheLimit = 0 caching:DataPath = "/Volumes/Base_Image/Library/Server/Caching/Data" caching:ServerGUID = "FB78960D-F708-43C4-A1F1-3E068368655D" caching:ServerRoot = "/Library/Server" Don’t change the caching:ServerRoot setting on the server. This is derived from the root of the global ServerRoot. Also, the ServerGUID setting is configured automatically when connecting to Apple and so should not be set manually. When you configured that Volume setting, you set the caching:DataPath option. You can make this some place completely off, like: sudo serveradmin settings caching:DataPath = "/Library/Server/NewCaching/NewData" Now let’s say you wanted to set the maximum size of the cache to 800 gigs: sudo serveradmin settings caching:CacheLimit = 812851086070 To customize the port used: sudo serveradmin settings caching:Port = 6900 The server reserves a certain amount of filesystem space for the caching service. This is the only service I’ve seen do this. By default, it’s about 25 gigs of space. To customize that to let’s say, ‘around’ 50 gigs: sudo serveradmin settings caching:ReservedVolumeSpace = 50000000000 To stop the service once you’ve changed some settings: sudo serveradmin stop caching To start it back up: sudo serveradmin start caching Once you’ve started the Caching service in OS X Server and familiarized yourself with the serveradmin caching options, let’s look at the status options. I always use fullstatus: sudo serveradmin fullstatus caching Returns the following: caching:Active = yes caching:state = "RUNNING" caching:Port = 57466 caching:CacheUsed = 24083596 caching:TotalBytesRequested = 24083596 caching:CacheLimit = 0 caching:RegistrationStatus = 1 caching:CacheFree = 360581072384 caching:StartupStatus = "OK" caching:CacheStatus = "OK" caching:TotalBytesReturned = 24083596 caching:CacheDetails:.pkg = 24083596 The important things here:
  • An Active setting of “yes” means the server’s started.
  • The state is “STARTED” or “STOPPED” (or STARTING if it’s in the middle).
  • The TCP/IP port used 57466 by default. If the caching:Port setting earlier is set to 0 this is the port used by default.
  • The CacheUsed is how much space of the total CacheLimit has been used.
  • The RegistrationStatus indicates whether the server is registered via APNS for the service with Apple.
  • The CacheFree setting indicates how much space on the drive can be used for updates.
  • The caching:TotalBytesRequested option should indicate how much data has been requested from clients while the caching:TotalBytesReturned indicates how much data has been returned to clients.
Look into the /Library/Server/Caching/Config/Config.plist file to see even more information, such as the following: <key>LastConfigURL</key> <string></string> <key>LastPort</key> <integer>57466</integer> <key>LastRegOrFlush</key> <date>2012-12-16T04:33:13Z</date> There are also a number of other keys that can be added to the Config.plist file including CacheLimit, DataPath, Interface, ListenRanges, LogLevel, MaxConcurrentClients, Port and ReservedVolumeSpace. These are described further at As you can see, this provides the host name of the server and path on that server that the Caching server requires access to, the last port connected to and the last date that the contents were flushed. In the Data directory that we mentioned earlier is a SQLite database, called AssetInfo.db. In this database, a number of files are mentioned. These are in a file hierarchy also in that Data directory. Client systems access data directly from that folder. Finally, the Server app contains a log that is accessed using the Logs option in the Server app sidebar. If you have problems with the service, information can be accessed here (use the Caching Service Log to access Caching logs). The Caching Service uses the AssetCache service, located at /Applications/, then starts as the new user _assetcache user. It’s LaunchDaemon is at /Applications/ Note: In my initial testing it appeared that after rebooting devices, that iOS updates were being cached; however, several have reported that this is not yet possible. I’ll try and replicate and report my findings later.

December 17th, 2012

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

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