krypted.com

Tiny Deathstars of Foulness

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" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<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>http://suconfig.apple.com/resource/registration/v1/config.plist</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 http://suconfig.apple.com/resource/registration/v1/config.plist 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. (com.apple.servermgrd 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 suconfig.apple.com 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 http://suconfig.apple.com/resource/registration/v1/config.plist.

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 swupd.plist file used to daisy chain multiple servers so they act as a cascade of software update servers. The new path for the property list is /Library/Server/Software Update/Config/swupd.plist. Here, the metaIndexURL key is sill the location that points to an internal Software Update Server that the server you are editing should look to for updates.

The default server is http://swscan.apple.com/content/meta/mirror-config-1.plist. To set a server to look at another internal server for software updates, edit the metaIndexURL key in the /Library/Server/Software Update/Config/swupd.plist file to include the path to the new server. The path should always have /content/meta/mirror-config-1.plist after the FQDN of the host name. So if your internal software update server was called daneel.foundation.lan the command to set that as the upstream software update server would be:

defaults write /Library/Server/Software\ Update/Config/swupd metaiIndexURL “http://daneel.foundation.lan/content/meta/mirror-config-1.plist”

This is a minor change, but one that might be frustrating if you were still trying to cascade updates the old way. If you’re new to cascading updates, this is a pretty straight forward configuration change, run from a Terminal command. It’s also worth noting that there are a few other settings in this file that could come in handy. You can limit bandwidth using the limitBandwidth key, purge any old updates using the PurgeUnused key, set a max download speed using the maxDownloadSpeed key, configure the Software Update Server TCP port using the portToUse key (automatically set to 8088), change the path to the updates (e.g. if you mv them and then want to repoint to the new location without downloading them all again) using the updatesDocRoot key, etc. Overall, the settings align with the old settings, but just in a new place.

Note: The keys above correspond to settings found in the following command:

sudo serveradmin settings swupdate

The list of settings is as follows:

swupdate:checkError = no
swupdate:limitBandwidth = no
swupdate:PurgeUnused = yes
swupdate:portToUse = 8088
swupdate:autoEnable = yes
swupdate:valueBandwidth = 0
swupdate:syncStatus = "Initializing"
swupdate:autoMirror = yes
swupdate:syncBandwidth = 0
swupdate:updatesDocRoot = "/Library/Server/Software Update/Data/"
swupdate:autoMirrorOnlyNew = no

October 31st, 2014

Posted In: Mac OS X, Mac OS X Server, Mass Deployment

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

The software patching configuration built into most operating systems is configured so all that a user has to do is open a box at home, join the network and start using the computer right away. As environments grow from homes to small offices and then small offices grow into enterprises, at some point software updates and patches need to be managed centrally. Mavericks Server (OS X Server 3), as with its OS X Server predecessors has a Software Update service. The service in the Server app is known as Software Update and from the command line is known as swupdate.

The Software Update service, by default, stores each update in the /var/db/swupd directory. The Software Update servie is actually comprised of three components. The first is an Apache server, invoked by the /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.host.plist LaunchDaemon. This LaunchDaemon invokes a httpd process and clients access updates from the server based on a manifest of updates available in the sucatalog. These are synchronized with Apple Software Updates via /Applications/Server.app/Contents/ServerRoot/usr/sbin/swupd_syncd, the LaunchDaemon for swupdate at /Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.swupdate.sync.plist. The Apache version is now Apache/2.2.22.

Clients can be pointed at the server then via a Profile or using the defaults command to edit the /Library/Preferences/com.apple.SoftwareUpdate.plist file. The contents of this file can be read using the following command:

defaults read /Library/Preferences/com.apple.SoftwareUpdate.plist

To point a client to a server via the command line, use a command such as the following:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL http://mavserver.pretendco.lan:8088/index.sucatalog

But first, you’ll need to configure and start the Software Update service. Lucky you, it’s quick (although quick in a hurry up and wait kind of way). To get started, open the Server app and then click on the Software Update service.

Screen Shot 2013-10-06 at 8.24.19 PMBy default, updates are set to simply mirror the Apple servers, by default, enabling each update that Apple publishes, effectively proxying updates. You can use the Manual button if you would like to configure updates to either manually be approved and manually synchronized or just manually approved but automatically copied from Apple. Otherwise click on the ON button and wait for the updates to cache to simply mirror the Apple servers.

If you would like to manually configure updates, click on the Manual option and then click on the Updates tab.

Screen Shot 2013-10-06 at 8.58.16 PMThe first item in the Updates tab is the “Automatically download new updates” checkbox. This option downloads all of the updates but does not enable them. The Updates tab also displays all available updates. click on one and then click on the cog-wheel icon towards the bottom of the screen to configure its behavior (Download, Enable, Disable, Remove and View Update).

Note: The only option for updates in an Automatic configuration environment is disable.

The service can be managed using serveradmin. To start Software Update, use the start option, followed by the swupdate service identifier:

sudo serveradmin start swupdate

To stop the service, replace start with stop:

sudo serveradmin stop swupdate

To see the status of the service, including the location of updates, the paths to log files, when the service was started and the number of updates running, use the fullstatus option:

sudo serveradmin fullstatus swupdate

The output of which appears as follows:

swupdate:state = "RUNNING"
swupdate:lastChecktime = 2013-10-07 01:25:05 +0000
swupdate:syncStatus = "INPROGRESS"
swupdate:syncServiceState = "RUNNING"
swupdate:setStateVersion = 1
swupdate:lastProductsUpdate = 2013-10-06 04:02:16 +0000
swupdate:logPaths:swupdateAccessLog = "/var/log/swupd/swupd_access_log"
swupdate:logPaths:swupdateErrorLog = "/var/log/swupd/swupd_error_log"
swupdate:logPaths:swupdateServiceLog = "/var/log/swupd/swupd_syncd_log"
swupdate:readWriteSettingsVersion = 1
swupdate:checkError = no
swupdate:pluginVers = "10.8.93 (93)"
swupdate:updatesDocRoot = "/Library/Server/Software Update/Data/"
swupdate:hostServiceState = "RUNNING"
swupdate:autoMirror = no
swupdate:numOfEnabledPkg = 0
swupdate:servicePortsAreRestricted = "NO"
swupdate:numOfMirroredPkg = 0
swupdate:autoMirrorOnlyNew = no
swupdate:startTime = 2013-10-07 01:25:05 +0000
swupdate:autoEnable = no

There are also a number of options available using the serveradmin settings that aren’t exposed to the Server app. These include a feature I used to use a lot in the beginning of deployments with poor bandwidth, only mirroring new updates, which is available to swupdate via the autoMirrorOnlyNew option. To configure:

sudo serveradmin settings swupdate:autoMirrorOnlyNew = yes

Also, the service can throttle bandwidth for clients. To use this option, run the following command:

sudo serveradmin settings swupdate:limitBandwidth = yes

And configure bandwidth using the syncBandwidth option, as follows:

sudo serveradmin settings swupdate:syncBandwidth = 10

To automatically sync updates but not enable them (as the checkboxes allow for in the Server app, use the following command:

sudo serveradmin settings swupdate:autoEnable = no

The port (by default 8088) can be managed using the portToUse option, here being used to set it to 80 (clients need this in their catalog URL from here on out):

sudo serveradmin settings swupdate:portToUse = 80

Finally, administrators can purge old packages that are no longer needed using the PurgeUnused option:

sudo serveradmin swupdate:PurgeUnused = yes

One of the biggest drawbacks of the Software Update service in OS X Mavericks Server in my opinion is the fact that it does not allow for serving 3rd party packages, from vendors such as Microsoft or Adobe. To provide those vendors with a manifest file and a quick little path option to add those manifest files, a nice middle ground could be found between the Mac App Store and the built in software update options in OS X. But then, we wouldn’t want to make it too easy.

Another issue many have had is that users need administrative passwords to run updates and don’t have them (technically this isn’t a problem with the OS X Server part of the stack, but it’s related). While many options have come up for this, one is to just run the softwareupdate command for clients via ARD or a similar tool.

Many environments have used these issues to look at tools such as Reposado or third party patch management tools such as JAMF Software’s the Casper Suite (JAMF also makes a reposado-based VM that mimics the swupdate options), FileWave, Absolute Manage and others. Overall, the update service in Mavericks Server is easily configured, easily managed and easily deployed to clients. It is what it needs to be for a large percentage of OS X Mavericks (10.9) Server administrators. This makes it a very viable option and if you’ve already got a Mountain Lion computer sitting around with clients not yet using a centralized update server, well worth enabling.

October 23rd, 2013

Posted In: Mac OS X, Mac OS X Server

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

The swupd.plist file used to daisy chain multiple servers so they act as a cascade of software update servers. The new path for the property list is /Library/Server/Software Update/Config/swupd.plist. Here, the metaIndexURL key is sill the location that points to an internal Software Update Server that the server you are editing should look to for updates.

To set a server to look at another internal server for software updates, edit the metaIndexURL key in the /Library/Server/Software Update/Config/swupd.plist file to include the path to the new server. The path should always have /content/meta/mirror-config-1.plist after the FQDN of the host name. So if your internal software update server was called daneel.foundation.lan the command to set that as the upstream software update server would be:

defaults write /Library/Server/Software\ Update/Config/swupd metaiIndexURL “http://daneel.foundation.lan/content/meta/mirror-config-1.plist”

This is a minor change, but one that might be frustrating if you were still trying to cascade updates the old way. If you’re new to cascading updates, this is a pretty straight forward configuration change, run from a Terminal command. It’s also worth noting that there are a few other settings in this file that could come in handy. You can limit bandwidth using the limitBandwidth key, purge any old updates using the PurgeUnused key, set a max download speed using the maxDownloadSpeed key, configure the Software Update Server TCP port using the portToUse key (automatically set to 8088), change the path to the updates (e.g. if you mv them and then want to repoint to the new location without downloading them all again) using the updatesDocRoot key, etc. Overall, the settings align with the old settings, but just in a new place.

Note: The keys above correspond to settings found in the following command:

sudo serveradmin settings swupdate

The list of settings is as follows:

swupdate:checkError = no
swupdate:limitBandwidth = no
swupdate:PurgeUnused = yes
swupdate:portToUse = 8088
swupdate:autoEnable = yes
swupdate:valueBandwidth = 0
swupdate:syncStatus = "Initializing"
swupdate:autoMirror = yes
swupdate:syncBandwidth = 0
swupdate:updatesDocRoot = "/Library/Server/Software Update/Data/"
swupdate:autoMirrorOnlyNew = no

October 22nd, 2013

Posted In: Mac OS X Server, Mass Deployment

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 Server.app 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>http://suconfig.apple.com/resource/registration/v1/config.plist</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 http://support.apple.com/kb/HT5590.

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/Server.app/Contents/ServerRoot/usr/libexec/AssetCache/AssetCache,

then starts as the new user _assetcache user. It’s LaunchDaemon is at

/Applications/Server.app/Contents/ServerRoot/System/Library/LaunchDaemons/com.apple.AssetCache.plist.

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: , , , , , , , , , , , , , , ,

A number of files got shuffled around in Mountain Lion Server. One is the swupd.plist file used to daisy chain multiple servers so they act as a cascade of software update servers. The new path for the property list is /Library/Server/Software Update/Config/swupd.plist. Here, the metaIndexURL key is sill the location that points to an internal Software Update Server that the server you are editing should look to for updates.

To set a server to look at another internal server for software updates, edit the metaIndexURL key in the /Library/Server/Software Update/Config/swupd.plist file to include the path to the new server. The path should always have /content/meta/mirror-config-1.plist after the FQDN of the host name. So if your internal software update server was called daneel.foundation.lan the command to set that as the upstream software update server would be:

defaults write /Library/Server/Software Update/Config/swupd metaiIndexURL "http://daneel.foundation.lan/content/meta/mirror-config-1.plist"

This is a minor change, but one that might be frustrating if you were still trying to cascade updates the old way. If you’re new to cascading updates, this is a pretty straight forward configuration change, run from a Terminal command. It’s also worth noting that there are a few other settings in this file that could come in handy. You can limit bandwidth using the limitBandwidth key, purge any old updates using the PurgeUnused key, set a max download speed using the maxDownloadSpeed key, configure the Software Update Server TCP port using the portToUse key (automatically set to 8088), change the path to the updates (e.g. if you mv them and then want to repoint to the new location without downloading them all again) using the updatesDocRoot key, etc. Overall, the settings align with the old settings, but just in a new place.

Note: The keys above correspond to settings found in the following command:

serveradmin settings swupdate

July 25th, 2012

Posted In: Mac OS X, Mac OS X Server, Mass Deployment

Tags: , , , , , ,

May 14th, 2012

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

Tags: , , , , ,

The Mac OS X App Store was released earlier this month as a part of the Mac OS X 10.6.6 update. The App Store, with over 1,000 applications (including a couple of server tools), allowing people to download and install applications on Mac OS X computers without needing to understand how to click through the screens of a standard package installer, drag applications from disk images into the /Applications folder or basically how to do practically anything except for click and provide a valid credit card number. As with the App Store that debuted with the iPhone, the App Store for Mac OS X is clearly aimed at residential customers, but being that these computers are used in enterprises around the world, the impact to managed environments cannot be discounted. I decided to do plenty of testing and reading before I wrote this up, so hopefully you’ll find it helpful, if not very timely.

The first and probably most important aspect of the App Store to most who are charged with managing large numbers of Mac OS X computers is that only administrative users can install software from the App Store. This little fact makes the App Store itself a non-issue for most enterprises, who do not make typical users administrative users. Because only administrative accounts can download and install applications, there is little risk created from leaving the App Store on client computers.

Applications installed from the App Store can only be deployed into the /Applications directory. These applications are owned by System, with read-only access given to the wheel group and everyone else. No ACLs are used, so while a single user purchases the software any user on the system can open it. If you copy the software to another computer then you will be prompted to authorize it using the same Apple ID that was used to purchase it.

When an administrative user purchases an application, they are not prompted for a system password, only an App Store password, which uses the same Apple ID used for the iTunes Store and the iOS App Store. Application updates are handled using the familiar Updates screen borrowed from the iOS App Store, which includes the nifty Update All option.

As far as controlling the user’s experience with the App Store, there are a few options. Administrators can remove the App Store application bundle (which can be replaced any time) from /Applications. Administrators can also black list the application using managed preferences/parental controls. A Dock item is added by default and can be removed as well. Removing both the Dock item and the Application bundle will then remove the App Store menu item from the Apple menu. You can also block the hosts at apple.com, which includes itunes.apple.com, ax.itunes.apple.com, ax.init.itunes.apple.com, albert.apple.com, metrics.sky.com and possibly gs.apple.com. These will communicate over ports 80 and 443, according to the operation being used. There is also a launch daemon at /System/Library/LaunchAgents/com.apple.storeagent.plist that should be unloaded and likely removed if you’re going to outright disable the App Store. However, the only real way I would personally disable is using a managed preference.

There is also a property list file for the App Store that can be used to manage the application in Workgroup Manager in ~/Library/Preferences/com.apple.storeagent.plist. However, there isn’t much that can be done here at this time.

Because applications are tied to users, when a user moves computers you will want to backup and restore the applications for the user. To do so, here’s the captain obvious article for ya’: http://support.apple.com/kb/HT4482.

The App Store is not a replacement for a good patch management system. Software distribution cannot be managed centrally using the App Store and Software Update Server in Mac OS X Server does not currently cache applications from the App Store. Trying to think of a way to shoehorn the App Store into a software distribution system such as JAMF’s Casper Suite, Absolute Manage or FileWave is just asking for a world of pain, so let’s pretend that we never brought it up. If your organization isn’t able to license one of the aforementioned products, check out Star Deploy from http://www.stardeploy.com/StarDeploy/Home.html or munki from http://code.google.com/p/munki. Finally, I think that Apple’s done a great job with the App Store for a version 1 release. I think that my wife loves it and that over time if Apple chooses to do more with it then great; otherwise, all of the options we’ve been using, from the installer command on, are still at our disposal.

January 18th, 2011

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

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

Software Update Services allow your server to cache updates from Apple and then redistribute them to clients within your organization.  Now, this is going to greatly cut down on the amount of bandwidth consumed when new software patches are released.  But if you have a large distributed organization you might want to have multiple Software Update Servers daisy-chained together in a cascade to download updates from each other and provide updates to sets of clients (maybe they’re geographically separated or you just have too many clients to provide updates to for just one server).  Cascading the Software Update Services would further conserve bandwidth in your environment if you have multiple Software Update Servers.  

In order to cascade Software Updates from one server to another you would first setup your first Software Update Server.  Let’s say that we set it up as SUS1.domain.com and set it to run on port 8080.  Next you would setup your second server (let’s call it SUS2.domain.com) and edit the “metaindexURL” key (by default it’s set to be swscan.apple.com) of the file, /etc/swupd/swupd.plist.  So you would change the key to be SUS1.domain.com/content/meta/mirror-config-1.plist.

August 7th, 2008

Posted In: Mac OS X Server

Tags: ,