Added in a recent version of OS X Server was the ability to provide an advanced software update feature called Caching Server. This enhanced the previous Software Update server features by including content from iTunes (i.e. iOS app updates and iBooks), along with providing an easy way for automatic server update selection (for those who are unfamiliar with Caching Server’s nifty features, check out the PDF on this page).

During setup you are required to select a volume for the cached updates to be stored. Depending on the size of this volume, the maximum size used slider can be rather useless. For example, when configuring my RAID enclosure (which has 8.8TB of useable space), the slider went from 30GB to 580GB in one step! This kind of limited selection is very frustrating. I want more than 30GB of cached updates, but I don’t want 580GB! Unfortunately, the current GUI slider steps in very high increments. Thankfully for us, using serveradmin through the terminal will save us.

If you want to see what limit Caching Server has set via the command line, you can do sudo serveradmin fullstatus caching then check out the line caching:CacheLimit. This number is shown in bytes and will convert nicely to a base 10 unit (otherwise known as SI), rather than the normal base 2.

For example, if you wanted to set a limit of 100GB, you would use the number 100000000000. That’s a lot of zeroes. Alternatively, 250GB would be 250000000000. To work out your storage conversion needs, I’d recommend checking out this converter here and use the Byte SI Decimal Prefix to convert to bytes.

Now that we’ve decided on how much space we’d like to use for Caching Server, lets tell it what we want. Open up a new Terminal window and using the command serveradmin settings caching:CacheLimit we can specify (in bytes) how much space we want to use. In my case, I wanted to use a maximum of 100GB for Caching Server. To do this, I enter the following:

sudo serveradmin settings caching:CacheLimit = 100000000000

After pressing return and running fullstatus on Caching Server (or opening the Caching tab in the Server app), you can now see that a maximum of 100GB will be used. Naturally, entering a different number will yield a different result in Server app (or the Terminal), but you get the picture.

Since making the iStat Server for Status Board script I’ve wanted to make more graphs for Status Board. Lo and behold, I use SABnzbd+ and it has an API. A graph is born:

The above graph collates all the downloads in the queue and counts them up then graphs them out, it’s pretty self explanatory really. Along side those bar graphs is the total of all items in the queue. Also available is a custom “Do-it-yourself” panel with core information about your SABnzbd+ server.

This pane is also pretty self explanatory. At the top you’ve got the version number of SABnzbd+, the current speed of your downloads, the status of the server (i.e. paused, downloading etc), and the size (in GBs) of what’s left to download in the queue. At this point in time, the info pane is only suitable for a 4x4 panel.

Jump over to the GitHub page to take a gander at the code and download it. Getting it set up is pretty easy, but if you’re stuck, I can provide limited support on the GitHub page, or via Twitter.

Please take a look and let me know if you find it useful!

Ever since Panic’s Status Board for iPad app came out I’ve wanted to have data from iStat Server appear in Status Board.

After finding that iStat Server stores its data in /Library/Application Support/iStat Server/databases/local.db and that the SQLite database and all its data is not encrypted/obfuscated in any way, I figured it wouldn’t be too difficult to get the juicy data into some sexy Status Board graphs.

Using the PDO and SQLite libraries included with Mac OS X 10.8.3 I was able to get a connection to the database and pull out rows. Simply store this file anywhere on your Mac that’s accessible by the built-in web server.

Lo and behold, a graph is born:

The project is still in its infancy, with only a few different graphs. I plan on slowly adding more and more graphs and types. As of this post, the following graphs are possible:

• ram_hour - RAM usage for the past 60 minutes
• ram_day - RAM usage for the past 24 hours
• cpu_hour - CPU usage for the past 60 minutes
• cpu_day - CPU usage for the past 24 hours
• load_hour - CPU load for the past 60 minutes
• load_day - CPU load for the past 24 hours
• temp_hour - Temp sensors for the past 60 minutes *new*

Take a look at the GitHub repo for more details and the download link to get this puppy running. Limited support can be provided on GitHub or on Twitter at @yesdevnull.

Update - 05/06/2013

Todays big update includes temp sensor monitoring so you can get more pretty graphs, like below.

If you’re checking 1 sensor, make your query string &temps=TC0D, or for multiple sensors, do &temps=TC0D,TC0H. If you have multiple temp sensors, they must be comma delimited. For the most up-to-date list of sensors, check the README in the GitHub repo.

Head over to the GitHub repo (linked above) to check out the new changes and get it set up on your Mac!

Recently I’ve been working on some bash scripts for a NetBoot system we have at work for diagnosis and troubleshooting Macs.

Currently the collection only includes a script for the command-line utility memtest, and a simple CPU workhorse yes. Also included is a few bash aliases you can add to your bash profile.

To view the collection, or fork et al, visit GitHub now!

Welcome to my new site yes > /dev/null!

Here I’ll be writing about code I’ve written, technical experiences I’ve had, music I work to, and maybe even other things unrelated to computers and programming.

I’m planning on doing a couple posts per month, so check back soon for some nifty content.

Dan.