darwinup, Apple’s Darwin Update utility

Yesterday in ##osx-server, Pepijn Bruienne mentioned having stumbled upon an OS X system binary he’d never seen before, which was new to me as well: darwinup. This tool is used (or was used – public development of it seems to have stopped around OS X 10.7) for the purpose of managing versions of OS X system components by installing “roots” distributed in a variety of ways. It abstracts several different archive formats and wraps tools like curl, tar, rsync to perform its tasks.

It can install and remove packages installed via rsync-able locations and HTTP(S) URLs, and keeps track (in an SQLite database) of its activity and overwritten files such that it can roll back installations of system components to previous versions. I’ve seen it included on OS X systems as far back as OS X 10.7 (Lion) up through 10.10 (Yosemite). My immediate reaction was that this was like a basic package manager that’s included with every copy of OS X.

Digging a bit further, this tool is part of the DarwinBuild project, whose public development seems to have stopped around 10.6/10.7 (like most other macosforge projects). According to their notes, it is definitely not a package manager, however. These notes contain a much more thorough explanation of the tool than its manpage, so I’d encourage you to read through it if you’re interested in why the tool exists. The manpage has a few useful examples, such as installing components from Apple’s (similarly-abandoned) Roots repository. This repo of compiled OS X components was also completely news to me.

The darwinup tool obviously exists for testing and development purposes, so I would highly not recommend installing Apple’s old roots onto a system you care about, because they are now so outdated and could overwrite critical system components with incompatible versions. Of course, you can always roll back..

Here’s an example of installing compiled bootp tools from 10.7.2. You can also add additional -v options to print out more details about exactly what it’s doing with network and files-on-disk activity.

$ sudo darwinup install http://src.macosforge.org/Roots/11C74/bootp.root.tar.gz

A /AppleInternal
A /AppleInternal/Developer
A /AppleInternal/Developer/Headers
A /AppleInternal/Developer/Headers/BSDPClient
A /AppleInternal/Developer/Headers/BSDPClient/BSDPClient.h
A /AppleInternal/Developer/Headers/DHCPServer
A /AppleInternal/Developer/Headers/DHCPServer/DHCPServer.h
  /System
  /System/Library
  /System/Library/LaunchDaemons
  /System/Library/LaunchDaemons/bootps.plist
  /System/Library/SystemConfiguration
  /System/Library/SystemConfiguration/IPConfiguration.bundle
  /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Info.plist
  /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/MacOS
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/MacOS/IPConfiguration
  /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Resources
  /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Resources/English.lproj
U /System/Library/SystemConfiguration/IPConfiguration.bundle/Contents/Resources/English.lproj/Localizable.strings
  /usr
  /usr/lib
U /usr/lib/libBSDPClient.A.dylib
  /usr/lib/libBSDPClient.dylib
U /usr/lib/libDHCPServer.A.dylib
  /usr/lib/libDHCPServer.dylib
  /usr/libexec
U /usr/libexec/bootpd
  /usr/local
  /usr/local/bin
A /usr/local/bin/bsdpc
A /usr/local/darwinbuild
A /usr/local/darwinbuild/receipts
A /usr/local/darwinbuild/receipts/bootp
A /usr/local/darwinbuild/receipts/fb5424a830958c1b4cc8191de7b8c6e9d31f1aaf
  /usr/sbin
U /usr/sbin/ipconfig
  /usr/share
  /usr/share/man
  /usr/share/man/man5
  /usr/share/man/man5/bootptab.5
  /usr/share/man/man8
  /usr/share/man/man8/bootpd.8
U /usr/share/man/man8/ipconfig.8
Installed archive: 2 bootp.root.tar.gz
9C140C50-A30E-453D-8F66-01207F4539A8

$ sudo darwinup list

Serial UUID                                  Date          Build    Name
====== ====================================  ============  =======  =================
2      17FEFDD5-E202-485A-B429-E5407881A845  Jan 21 11:33  13F34    bootp.root.tar.gz

Note that the build number is not that of the root that was installed, it’s the build of the currently-running system (10.9.5).

Now let’s run the bsdpc utility that was just installed into /usr/local/bin to display info about available NetBoot images:

$ sudo bsdpc
Discovering NetBoot servers...

NetBoot Image List:
   1. DeployStudio-10.10-1.6.12 [Mac OS X Server] [Install] [Default]

Again, use this with care. We can see that these bootp tools installed system components in addition to executable binaries (from a 10.7 system onto a 10.9 system), so this is just a demonstration of the capabilities of darwinup. Don’t do this at home!

Tagged , , | Leave a comment

OS X admins: your clients are not getting background security updates

Have I got your attention? The more accurate (and longer) qualifier for this title should actually be: “admins who configure clients to not automatically check for software updates.”

From recent discussions in ##osx-server, some of us have determined that OS X’s “system data files and security updates” will only install automatically if a client is already configured to automatically check for updates. Many sysadmins managing OS X clients tend to disable this setting so that they can control the distribution of these updates, but aren’t aware that their clients are now no longer receiving Apple’s background updates for at several of its built-in security mechanisms, including XProtect and Gatekeeper.

Rich Trouton beat me to this post with his post yesterday, but it prompted me to do a bit more digging into trying to reproduce an issue that comes up when attempting the most obvious workarounds for this issue, which I’ll outline after giving some more context.

Update: Greg Neagle has come up with a simple but flexible workaround for the issue described below, which he’s implemented in Reposado and documented here. If you use Reposado (and you really should), look into the new --remove-config-data option that can be applied selectively to SUS updates you’re mirroring.

Read More »

Tagged , , | 11 Responses

Keeping your OS X VM guest tools current with Munki

fusion_256.pngI use VMware Fusion to test client software, deployment workflows, and using virtual machines allows me to frequently take and roll back snapshots. Over time, the VMware guest OS tools tend to drift out of date with the version of Fusion, and are reported to need updates/reinstalling. Sometimes when this happens, things like pasteboard synchronization, automatic window resolution resizing and drag-and-drop file transfers stop working. I’d like to not have to manually click “Update VMware tools..” and go install the tools manually every time I notice the tools are out of date between snapshots (which on my system seems to be frequently).

Luckily, I use Munki to manage OS X clients, and it’s great at updating software. In this post I’ll walk through the few steps I did to have all my test machines configured to automatically keep their VMware tools up to date. The same logic should apply for other software management platforms like Casper, Absolute Manage or Puppet, using their respective mechanisms for customizable discoverable attributes. This technique should work for users of Parallels, if they use a sane OS X installer for their tools. VirtualBox has yet to ship with any OS X guest tools.

Read More »

Tagged , | Leave a comment