The Caching Server in OS X Server 5.2 (for Sierra) does content, apps, and
software updates. The Software Update service is hidden by default indicating it will likely be removed from the Server app in a future update, although when is kinda’ up in the air. The Software Update service can still be enabled for now, which we’ll look at later. The Caching service on the Server app works like a proxy. When 10 of your users download that latest Nicholas Sparks book and movie, you only sacrifice your WAN pipe to download it once, and the other 9 people piggy-back off that. And when 10.12.1 ships, you only need to download it over the WAN once, and the other local users will pull off that spiffy Caching server sitting in your office. Pretty sweet, right?
So, how do you use this ultra-complicated service? It looks and feels kinda’ like an iPad app. Which is to say that as far as server stuffs go, this thing is pretty darn easy to use. To get started, open the Server app and then click on the Caching service in the sidebar of the Server app.
Here, click on the ON button. OMG, so hard. But wait, there’s more! Click on that Change Location button and you can select a larger volume for your updates that are cached. You’ll likely wanna’ do this because the entire series of the HBO drama OZ is kinda’ big (and yes, creepy, but really well written)…
If you do change the location, you’ll see a window to change the volume you’re caching to. That’s pretty much it. Other than the waiting for the updates to move. By default, the Caching service allows for unlimited space. Use the spiffy slider to reduce the total amount of space that the service can occupy on the hard drive. This can be a good thing if it happens to be your boot volume and there are other more mission critical services hosted on that thing.
Overall, this all seems pretty straight forward. So what else might you need to know. In case you get a corrupt asset, or in case your volume fills up, there’s a Reset button, to reset the cache.
The service can be controlled from the command line as well. To start it, use the serveradmin command along with the start verb and the service name (oddly, that’s caching).
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin start caching
To stop the service, use the stop verb along with the service name:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin stop caching
To see a list of settings, use the settings verb with the service name:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings caching
The settings are as follows, mostly available in the Server app:
caching:ReservedVolumeSpace = 25000000000
caching:CacheLimit = 350000000000
caching:ServerRoot = "/Library/Server"
caching:ServerGUID = "DEE63BBB-9F32-428B-B717-E3941F82E2DC"
caching:DataPath = "/Library/Server/Caching/Data"
caching:LocalSubnetsOnly = yes
caching:Port = 0
One setting you might choose to change is the reserved volume space, as this can keep you from getting the service started on smaller volumes. In the above example, the setting is 250 gigs. To change that to 100 gigs:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings caching:ReservedVolumeSpace = 10000000000
A new setting in Server 5.2 for macOS Sierra is defining other servers that can access your Caching server. This is like providing a proxy for a proxy. Basically if your devices can cache updates onto the server from other servers then the updates are caching much faster than if your server caches the updates from Apple. This is called Peering Permissions. To define Peering Permissions, click on the Edit Peering Permissions… button.
At the Caching screen, click on Only Local Subnets if you want to let the server identify which subnets are local, or Only Some Networks to define which ranges of addresses have servers that can cache content and update from your server.
Click on the plus sign to add a network and then click on “Create a new network”
At the Create A New Network screen, provide a name and then the first and last IP
Click Create and then add all of the appropriate subnets. Click OK when you’re done. Restart the service and viola, you’re finished.
krypted September 24th, 2016
Posted In: Mac OS X Server
caching service, Content, ibooks, iPad, iPhone, macOS sierra, OS X Server, proxy, server 5.2, Software Updates
One of the primary use cases for Apple Configurator 1 and Apple Configurator 2 is to get apps on devices. Even with MDM, you can use Apple Configurator 2 for app deployment. The value here might be that you end up transferring 10 gigs of apps over a USB cable, rather than over the air in larger deployments. Here, we’ll look at a basic app deployment using Apple Configurator 2.
To get started, first download the app and get it in iTunes. This can be accomplished by copying the .ipa file for an app onto a device, or syncing an iOS device with iTunes that has the app installed. Take care that the Apple ID associated with the app will be applied on the device. Then, open Apple Configurator 2 and choose a Blueprint (View -> Edit Blueprints) you’d like to apply, or deploy, this app to. Once uploaded and assigned, any device that you apply the Blueprint to will receive the app. Right-click on the Blueprint and click on Add and then choose Apps in the submenu.
You will need to authenticate to the iTunes Store using an Apple ID. Notice that if you’ve previously connected Apple Configurator 2 to the iTunes Store that you will routinely get prompted to reconnect when the key expires (seems to be after a good 4 hours of inactivity, but not sure yet exactly when to expect – this might be a bit annoying for environments that have students that don’t have that password doing some of the work).
The when you authenticate, you’ll be prompted for a list of apps to install. Here, we’re just going to choose some generic app and click on Add Apps (yes, that’s plural, you can choose more than one).
The app will be listed. Any device the Blueprint is applied to then receives the app.
You can also assign an app to a device manually. To do so, control-click (or right-click) on a device and then use Add to choose the Apps… option. The rest of this process is pretty much the same.
Overall, these options are similar but a bit more matured than they were in Apple Configurator 1. There are a few other pretty cool options that we’ll explore soon, but for now this should get you started in getting apps as a part of your Apple Configurator 2 deployment.
krypted November 9th, 2015
Posted In: Apple Configurator, iPhone, Mass Deployment
Apple Configurator 2, apps, Content, deploy apps to devices, ios, iPad, iPhone, Mass Deployment
At some point, you may find that you would like to remove all episodes from Podcast Producer that were brought in using a specific workflow, or based on a specific keyword, a string in the title, a date, or the user that created the episodes. All of these attributes are trapped in the db.sqlite3 database for Podcast Producer. This database is stored in the Server directory of your shared library. Within this database there is a table called episodes. Using that table you can locate all episodes that match the given pattern. To query, you will use the sqlite3 command and identify the database path. A very basic incantation of this command would be to show all of the data for a given table, which in our example would be “episodes”:
sqlite3 /Volumes/xsanVolume/Library/PodcastProducer/Shared/Server/db.sqlite3 ‘SELECT * FROM episodes’
You could then expand this to limit results based on a pattern match. Here, we will have sqlite3 return the uuid for episodes that have a workflow_uuid of AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE:
sqlite3 /Volumes/xsanVolume/Library/PodcastProducer/Shared/Server/db.sqlite3 ‘SELECT uuid FROM episodes WHERE workflow_uuid=”AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE”‘
We could also change it up slightly and look for episodes that were created by a user with a shortname of cedge:
sqlite3 /Volumes/xsanVolume/Library/PodcastProducer/Shared/Server/db.sqlite3 ‘SELECT uuid FROM episodes WHERE author_shortname=”cedge”‘
The sqlite3 commands will return a set of uuids. Once you have a list of uuids, you can go into the Content directory in your shared library and you will see each listed there based on the date they were created (inside of their date folders). Date is also a field in the sqlite3 database, but given the ease of recursively performing tasks I’m not sure it will be required. The uuids will have a .prb extension and you can then piped paths with the added extension out of your command, into an array or use them for some other action, thus allowing for archiving, removing and even performing further tasks to the assets that live within the actual bundle, including hooking into transmogrifier
to link to Final Cut Server.
krypted August 26th, 2010
Posted In: Mac OS X Server
archiving, bundle, Content, deleting podcasts based on workflows, Mac OS X, Mac OS X Server, Podcast Producer, podcasting, prb, property lists, resources, scrubbing old content, sqlite3