Delete nvram

A nifty little new option that came in OS X 10.9 Mavericks and stays in Yosemite is the ability to delete all of the firmware variables you’ve created. This can get helpful if you’ve got a bunch of things that you’ve done to a system and want to remove them all. If you run nvkram followed by a -p option you’ll see all of the configured firmware variables: nvram -p If you run it with a -d you’ll delete the given variables that you define (e.g. boot-args): nvram -d boot-args But, if you run the -c you’ll wipe them all: nvram -c

Package Based Roundcube Setup For OS X Server

The good people at TopicDesk have released a new version of their Roundcube installer. Now, with Mountain Lion & Mavericks compatibility. Automatic setup of carddav is the biggest new feature, but it’s also been updated to the latest version of Roundcube. The “topicdesk Roundcube Installer 0.9.5a” will:
  • Install Roundcube 0.9.5 (the latest and greatest) as a WebApp in OS X Server
  • Configure sensible defaults for Roundcube and PHP
  • Automatically configure postgres and initializes the roundcube database
  • Configure managesieve server-side filtering (Vacation Replies)
  • Install mcrypt (if you don’t have it installed/functioning already)
  • Automatically configure a carddav plugin, it works on first launch
homescreen To download, check it out at:

Receipts & Bills of Material in 10.8

When installing a package OS X makes a list of what it installs in /Library/Receipts/InstallHistory.plist. The dictionaries show each package installed, along with the installation date, the name displayed during installation, the version of the package being installed, the identifier of the package and the process name used to install the package. This information, along with the file name of the actual package is stored in corresponding property lists in /private/var/db/receipts. Each bill of material is also stored there, in .bom file. The lsbom command is used to see a list of objects installed by the package. You can also see the options such as the permissions assigned to files by the package as they’re installed. For example, that Twitter app from the app store; to see what it installs: lsbom /private/var/db/receipts/ This package is installed by the Mac App Store. When run, packages installed by the Mac App Store should only contain objects within that applications .app bundle. That’s a pretty good bit of information, so you can also use the -s option to constrain the output to only see the paths of files (relative paths, of course). I’m usually a fan of getting more information than less, so I usually run it adding the -m option, which shows me those permissions. lsbom /private/var/db/receipts/ Note: You can also use the mkbom command to create new .bom files. As the man page for bom indicates, this goes back to NeXTSTEP and was extended for 10.0 and again in 10.3.

Determining .app Executables From a Script

I’ve mentioned the codesign tool in previous articles, but today let’s look at a specific use. I recently needed to generate a report of the executable for around 2000 app bundles. Luckily, codesign displays the executable for an app when run with the –display option: codesign --display /Applications/Utilities/ The output looks as follows: Executable=/Applications/Utilities/ Another tool that I haven’t written much about is productsign (also in /usr/sbin of Mac OS X 10.8). I’ll look at that one next, as a means of signing packages.

Changes in Mountain Lion Server

Mountain Lion Server is now available on the OS X App Store and as with the last few updates there are some things missing that you might be expecting and depending on. First up, three major services are gone: Podcast Producer, RADIUS and dhcp. You can still do dhcp as you always did with OS X client as those features work on OS X Server, but the more granular controls available in OS X Server are now gone. The biggest impact of dhcp is probably in testing NetBoot services when there are network issues and you need to prove to network admins that it’s the network and not your server… I had written an article before about FTP still being in OS X Server from the command line, but now it’s back in the GUI, which should make many an administrator happy. NAT is also gone from the GUI, but natd and natutil are still available from the command line. Might as well just use the Sharing System Preference pane for such things though… Server Admin is now gone (long live Server Admin!) and Workgroup Manager is now a download to be performed and installed following installation. Support for Managed Preferences is gone, even though most manifests technically still work. Many services also got some pretty nice updates. These include:
  • Calendar – There are a few updates on the client side, but not on the server side. Most notably, the option to publish calendars is now gone. If you used that, it’s time to get used to manually exporting, copying to a share and then distributing links. This is going to likely cause more use of the Calendar server itself, to some degree. Also, it’s not iCal or iCal Server, it’s now Calendar and Calendar server. Seems to me that this isn’t obviously an Apple-centric naming structure as with most other things they do, but sometimes you’re gonna’ have that…
  • Contacts – Nope, it’s not called Address Book server, it’s the Contacts service. Same with the client side application.
  • DNS – DNS management is moved into the Server application. You can also now restrict who you do lookups for in the GUI. Under the hood very little changes.
  • File Sharing – Nothing really changes with file sharing, except the wiki integration described in the Wiki section in a little bit.
  • Firewall – The firewall option is gone, as is the ipfilter at the command line, but pf is easy to configure from the command line.
  • FTP – It’s a quick and easy single share solution from the GUI. Using the sharing command there’s still tons available to administrators.
  • Mail – Authentication mechanisms and domains are in the GUI, but very little changes otherwise.
  • Messages – The service name has changed from iChat to Messages in the GUI but is still jabber from the command line. The big change with this service is that the client side is now able to leverage iCloud to instant message mobile devices as well. Therefore, the text messaging component is client-side and has no impact on the jabber service itself.
  • NetInstall – The “NetInstall” service is NetBoot. It can host NetRestore or NetInstall images, but the heavy lifting for that stuff is done in System Image Utility. And the output of the SIU commands are now more scriptable through the automator command line interface. The NetInstall screen is now in Server app and is a good port from Server Admin in that it’s similar in look and feel to the NetBoot screen in Server Admin. A feature that isn’t in the GUI is diskless NetBoot, which is fine because I documented how to do it when I realized it would be an issue for a few customers.
  • Open Directory – Given that Server Admin is gone, something had to happen with Open Directory. The Open Directory screens have been moved to Server app where it’s fast to setup and tear down Open Directory. Open Directory based Users and Groups are also created through the Server App, although Workgroup Manager can be downloaded and used still. Immediately following upgrades, the add and remove users buttons are gone for previously stand-alone hosts. Also the Manage Network Accounts option is now gone from Server app, replaced with the traditional ON button supplied by Apple for other services.
  • Profile Manager – This deserves its own post, which is in the queue, but suffice it to say that while you can’t tell when looking in Server app, there are a number of upgrades to Profile Manager.
  • Software Update – Management of the service is moved from Server Admin to Server app. There are now fewer options in the GUI, but the same in the command line. Cascading is a little different.
  • Time Machine – Time Machine server is the same… The versions option from the Time Machine Server preference pane is gone and the layout is a little changed, but the server component is identical in functionality as well as look and feel.
  • VPN – Unless you add another supported VPN protocol there’s not much to do after fixing most issues in 10.7.4. Except fixing the last issue with search bases, seemingly resolved as it’s working for me pretty well.
  • Websites – There are more options in the GUI for new sites. The default site appears twice (once for 80 and once for 443), but there are more options, such as the Web App functionality that comes with a default Python “Hello World” app. Also the server is still called web from the serveradmin command line, but is now called Websites through the GUI.
  • Wiki – The wiki has themes again, although they’re just color schemes. And you can create your own custom banners and upload, which brings back two of the most common feature requests from people that hack the look and feel of the wiki in versions previous to Lion. But the most substantial aspect of the Wiki to change to me is the document management options, available to users in WebDAV or through the portal. This allows for a very mobile-friendly file management tool. Blogs and wikis for the most part stay the same and have a very clean upgrade process from Lion. The command line tools also feature some new options for indexing, etc., which many will find helpful.
  • Xsan – cvadmin, cvlabel, cvversions, etc are now stored in /System/Library/Filesystems/acfs.fs/Contents/bin/ and Xsan has its own entry in the Server app. Despite hearing people question its future, I’ve never seen as many questions flying around about how to do things with Xsan than I do now. Storage sales are up, monkey chatter on the web is up, deployments are being booked and Xsan looks here to stay. The Server app only really shows you a status of things, but the Xsan Admin app is now embedded in the Server app and available through the Server app Tools directory.
Configuring Websites in Server app
The Alerts options are much more robust in Mountain Lion than they were previously. You  can now get alerts on a myriad of things, incuding certs, disks, space, storage quotas, virus detection, network changes and software updates.
Configuring Alerts in Mountain Lion Server
The Server commands also moved and in fact the whole file and folder structure mostly fit nicely inside of the Server app. There are certain things that haven’t been dealt with in this regard such as NetBoot’s library, but for the most part Apple is getting Server to the point where it’s very self-contained. The ramification of which is that upgrades for future releases (and from Lion to Mountain Lion for that matter) are much simpler. Simply downloading a new version informs administrators that the app has been replaced and is good to go, service data in tact. In real world, this has been a little hit or miss but should prove to make our lives much easier in the future. Reducing scope, aligning with better development practices and all the work to merge all of the remaining services into Server app are huge undertakings. I would fully expect no further support or updates to Workgroup Manager, no more testing of managed preferences in deference to profiles and a few other culture shifts that still need to shake themselves out. Most of us are going to seem underwhelmed (if that’s a word, no it’s not ’cause I looked it up -> awesome video below --> ’cause affection has 2 fs, especially when you’re dealin’ with me). But here’s the thing, with an incremental update, you’re not going to get massive changes. Instead we will get slow and steady updates hopefully continuing to build faster towards a better end goal. What’s important is that the foundation is actually better now, given changes to other parts of OS X and so Server is likely now better positioned than ever for great new features in subsequent releases.
Oh, and did I forget to mention that Xgrid is gone. I guess no one really noticed anyway…

Scripting Launchpad

LaunchPad is the OS X Lion version of the old Launcher, or the iOS home screen, according to how you look at these things. A few notes on issues I’ve seen with LaunchPad. First, I’ve had to nuke LaunchPad and have it rebuild. To do so, delete the database. rm ~/Library/Application Support/Dock/*.db You might also need to kill the dock: killall Dock In a deployment scenario, I’ve started doing both as post flight tasks. Getting to the point where you’re granularly adding and removing items is done by editing the .db file in ~/Library/Application Support/Dock. In here is a generatedID followed by .db that makes up a SQLite database. This database can be managed using a number of SQLite management tools, such as Base or SQLite Inspector. The management of databases from within these tools is pretty straight forward. You browse the apps, locate the offending rule and delete it. Then killall on the Dock (shown earlier) to actually have it disappear. You can also use the sqlite3 command line (where the string that begins with BF is the generated ID of the database): sqlite3 ~/Library/Application Support/Dock/BF222CEA-E6B2-4804-BAA2-DED0428E6C90.db "select * from apps" Assuming you see a row in the output that you’d just love to get rid of, you can look at the bundleID and then get rid of it using a command like this: sqlite3 ~/Library/Application Support/Dock/BF222CEA-E6B2-4804-BAA2-DED0428E6C90.db "DELETE from apps WHERE bundleid LIKE 'org.videolan.vlc'" Don’t forget to kill the Dock afterwards. That’s basically it. If you install an app and then want to toss items from Launchpad as a post flight use the bundleID, run sqlite3 and then a second query to verify that the item is gone. As you don’t know the generatedID for the database name, you can also replace it with * in scripts: sqlite3 ~/Library/Application Support/Dock/*.db "DELETE from apps WHERE bundleid LIKE ''" Oh, and the easy way to clean up LaunchPad is to use something like Launchpad Cleaner

Mass Deploying Time Machine in Mac OS X Lion

A lot of environments want to use Time Machine at scale. But prior to Lion there hasn’t been a simple way to do so. Apple has introduced a new weapon in the war to backup client computers in the new command tmutil that was introduced in OS X Lion. The tmutil command allows administrators to enable Time Machine, make snapshots, kick off backups, delete snapshots, perform restores, configure options within Time Machine and, with a little scripting, build a centralized dashboard, pulling in Time Machine statistics from clients.

Enabling Time Machine

The first thing to know is that pretty much everything you do in Time Machine is going to require elevated privileges. So if you are writing a script, it should run as such, or if you’re running each command independently you will likely need to prefix them with sudo. Let’s start with a computer that doesn’t have Time Machine enabled. To enable it, use tmutil along with the enable verb: tmutil enable To disable Time Machine, use the disable verb: tmutil disable This is the equivalent of sliding the Time Machine slider between the ON and OFF positions.

We’ll also enable local backups, turning on snapshots: tmutil enablelocal But these don’t yet associate Time Machine with any disks or configure any of the settings. One of the first things people usually do when they enable Time Machine is to configure a destination volume for backups as you cannot backup if you don’t have a place to backup to. This is done using the setdestination verb. The destination can be a local file system or a network mounted share.  To set a destination as a local volume, simply follow the setdestination verb with an argument that indicates the path to use. For example, if you are pointing backups to a volume called remade: tmutil setdestination /Volumes/reamde Setting a destination will either write data into a DestinationVolumeUUIDs key in /Library/Preferences/ The contents of the key match the Volume UUID output of diskutil info. For example: diskutil info disk1s2 | grep Volume UUID Therefore, it is possible to swap UUIDs using a script on a biweekly or weekly basis or using tmutil along with the volume name, to match an offsite rotation rather than changing the volume in the System Preference pane.

Dealing with Network Mounts

In the case of a network mounted share, you would still use the setdestination verb, but define that the target location is a network mount by embedding a URL into the command rather than a file system path. The traditional URL will consist of protocol followed by :// followed by the hostname/sharename. We can go an extra step and also embed the username and password delimited by a colon and prefixing the hostname, using an @ to separate the credentials and the hostname. For example, if we wanted to define a hostname of with a share of snowcrash and a username of neal with a password of theU to access that share we would use the following: tmutil setdestination afp:// Given that you might not want the password embedded into the command, you can use -p to enter a password manually (the password will not be displayed in the terminal screen). In this case, leave the username embedded into the path as follows: tmutil setdestination -p afp:// While the inclusion of a computer name in the path of actual Time Machine backups seems to indicate that it is OK to allow multiple computers to use it, doing so seems discouraged in Apple’s Time Machine documentation. Therefore, sticking with one computer per share will likely be the most secure and least corruptible means of backup. While creating a bunch of shares for backups might seem daunting at first, it’s worth mention that you can script share creation, per client computer in OS X Server using the sharing command. For example, to create a share for a computer named neal in /Shared with AFP only and no guest access: sharing -a /Shared/neal -s 100 -g 000 To list computers in Open Directory: dscl /LDAPv3/ -list Computers Variabalizing the dscl output into an array and creating machine-specific shares would then net a share per computer (assuming all computers have corresponding records in the directory service). Likewise, shares can be built using a DeployStudio, Absolute Manage or Casper machine export as well.

Configuring the Backup Source

In Time Machine, all data is backed up by default. Therefore, rather than define what the source is, you define what the source is not. Once a target location has been defined, the next thing many Time Machine users do is define any data that is not to be kept in the Time Machine backups. This is done with the addexclusion verb. These exclusions are defined using the Options button of the Time Machine System Preference pane as well. To use the addexclusion verb, simply define a list of items that are not to be backed up as arguments separated by spaces. The tmutil command will then use those items as an array. If you have one item to exclude, simply list the path. For example, to exclude the OS X Developer Tools: tmutil addexclusion /Developer Or to disable a number of items (below we are only backing up /Users): tmutil addexclusion /System /Library /Applications /var /etc /Developer /Groups /Incompatible Software /Volumes /bin /cores /usr /tmp /temp /opt /net /home /Shared Items /Network /Groups Provided no errors occur the command should have run properly. The isexcluded verb then allows you to see which source locations are being excluded. Use the verb similarly to addexclusion: tmutil isexcluded /Developer A minus sign means it’s being excluded and a plus sign means it’s being backed up. You could also just grab the first position of the output: tmutil isexcluded /Developer | cut -c 1 You can also use this as a sanity check prior to performing restores at a lower depth. For example, there is no reason to try to recover a file called /Users/cedge/Desktop/systemoftheworld.pdf if it hasn’t been backed up: tmutil isexcluded /Users/cedge/Desktop/systemoftheworld.pdf | cut -c 1 The arguments for addexclusion are not all of the items being excluded. Instead, you are adding items, but others may already be present. Also, you can define the same exclusion multiple times without adding each item to the list of excluded items. To remove an item, use the removeexclusion verb (you can separate these with spaces as well): tmutil removeexclusion /Volumes Finally, addexclusion and removeexclusion have a -p option. By default, if you move an item that has been defined as an exclusion, the exclusion will move with the item. You can specify a -p option to set the path for the exclusion as static: tmutil addexclusion -p /etc There are also a number of exclusions that are included by default. These are defined in the .exclusions.plist. The non-default exclusions are stored in the ExcludeByPath array in /Library/Preferences/ These are not shown to an end user in the Time Machine System Preference pane though. Those paths can be found in the SkipPaths array within the same file. By default, the backup source needs to be connected to power. This setting corresponds to the Back up while on battery power checkbox in the Time Machine System Preference pane’s Option overlay. That setting can be disabled using defaults to write a 1 into the RequiresACPower key: defaults write /Library/Preferences/ RequiresACPower 0

Manually Running Backups

Once you have defined your source and target, it’s time to test a backup. The tmutil command allows you to kick off a backup immediately run tmutil with the startbackup verb. tmutil startbackup Either the backup will work or the Finder will display an error that the backup could not complete. If the system performance is poor during backups or you need to stop one for another reason: use the stopbackup verb: tmutil stopbackup In Time Machine a snapshot is an incremental or a fill (aka initial) backup. These are stored on a target volume, or backup disk. For example, the previously used snowcrash volume will contain a snapshot:

Each machine will have its own entry, meaning you can move Time Machine volumes between hosts or use a single network mount to allow backups for multiple clients (although there are some interesting security implications behind doing so). To create a new local snapshot (seen above in the path), use the snapshot verb: tmutil snapshot

Managing Backups

The Time Machine System Preference pane doesn’t give you a lot of features for managing retention and recycling media. But with OS X Lion, you can now manage and delete given snapshots of data, thus allowing for manually cleaning out your backups (or doing so with a script that has a lot more logic than the default settings). To see a list of snapshots, use the listbackups verb: tmutil listbackups You will see output of each snapshot on the computer: /Volumes/EncryptedTMBackup/Backups.backupdb/ /Volumes/EncryptedTMBackup/Backups.backupdb/ To just see that last snapshot: tmutil latestbackup The fitting delete verb is used for such a task and is able to take the argument of an old snapshot (or an array of such) to delete. For example, to delete snapshot 2011-08-09 -181840 for computer on /Volumes/EncryptedTMBackup tmutil delete /Volumes/EncryptedTMBackup/Backups.backupdb/ You can also calculate how much drift has occurred between snapshots: tmutil calculatedrift /Volumes/EncryptedTMBackup/Backups.backupdb/ The calculatedrift verb will show the amount of data added, removed and changed between each backup as well as output the averages of drift between backups (helpful in capacity planning and reporting). To compare a snapshot to a file system path (or paths), use the compare verb. This is handy for figuring out which snapshots you might be able to nuke if you’re scripting a delete process. The compare verb is one of the more complicated as there are a number of options for how to compare data. tmutil compare /Volumes/EncryptedTMBackup/Backups.backupdb/ The output can be a bit verbose as it looks at each directory. You can limit the depth using a -D option. You can also specify a number of different options to specify what differences to look for when performing lookups. The output of compare is helpful if you preflight your backups with a sanity check to verify there is enough room (otherwise the user might get a Time Machine error dialog).

Other Options

The tmutil command also has options for troubleshooting, moving disks and restores. The restore verb can be handy as you can send restore scripts to clients over ARD or even build a self-restore portal with more options than can be found in the TIme Machine restore screen (I’d recommend using the -v option with restores, btw). The inheritbackup verb can be used to take ownership of a machine directory, useful when moving disks or shares between clients. The associatedisk verb can be used to attach a disk to a backup, thus allowing you to skip beginning backups all over again if the UUID of a disk changes. Also, the options in 10.6 are still applicable. To suppress the dialog to make all new disks a TimeMachine volume: defaults write DoNotOfferNewDisksForBackup -bool YES Backups are also still kicked off by, stored in /System/Library/LaunchDaemons and the interval between backups can be changed using the StartInterval key here. For example, if you set it to 360 then backups will occur every 6 minutes instead of 60, or more likely, if you set the integer to 14400 then your backups will occur every 4 hours instead of every hour.

Puzzle Pieces

To take a few pieces from this article and combine them. Setting up a basic backup (provided that you have a known volume name per client) is as easy as the following basic, quick and dirty shell script: /usr/bin/tmutil enable /usr/bin/tmutil enablelocal /usr/bin/tmutil setdestination /Volumes/BACKUP /usr/bin/tmutil addexclusion /System /Library /Applications /var /etc /Developer /Groups /Incompatible Software /Volumes /bin /cores /usr /tmp /temp /opt /net /home /Shared Items /Network /Groups /usr/bin/defaults write /Library/Preferences/ RequiresACPower 0 defaults write DoNotOfferNewDisksForBackup -bool YES

Mass Deploy Parallels

Sometimes it’s just that easy. Our good friends at Parallels have developed a special Mass Deploy package, available on their site. When you control-click on it and select Browse Contents you will see a license.txt.  You can paste your license into the license.txt file and then put your virtual machine into the root of the package. Parallels Mass Deploy, Mac OS X Once complete, you can push this package out at will.  Additionally, you can edit the postflight shell script in the Resources directory, throwing your own commands at the tail end of the file, adding more virtual machines, customizing settings, etc.  Good luck.