Separating System and User Data with DeployStudio

2 Comments

Separating System and User Data with DeployStudio

Some end-users seem to find new ways to mess-up their computers, instead of spending a lengthy time trying to undo the damage, IT Staff can simply reimage a Mac with DeployStudio.

Placing the operating system (OS X & Applications) and user data (home directories) on separate partitions makes the process of restoring/upgrading the operating system even faster as there is no longer a need to migrate user data. 

Below I have listed the steps to configure DeployStudio to set up Macs with separate partitions for operating system and user data.

Setup

In DeployStudio create a new workflow titled ‘Partition’. The first item to add is a safeguard Alert task, followed by a Partition task. Allocate 80 GB to ‘System’ and the remaining space to the ‘Data’ partition. Also set ‘Target volume’ to ‘First disk available.’

Now edit your existing Reimage workflow. Before your ‘Restore’ task add a ‘Workflow’ task and set ‘Embed workflow’ to ‘Returned by script…’ and the script to ‘check_partitions.sh’. The check_partitions.sh script can be downloaded from here.

The check_partitions.sh script:

  • Skips partitioning if the System and Data partitions already exist.
  • Partitions the disk if neither System or Data partitions are found.
  • Aborts the DeployStudio workflow if only one of the partitions are found.

Under your ‘Restore’ task set the ‘Target volume’ to ‘System’ and ‘Rename volume’ to ‘System’.

After the ‘Restore’ task add a ‘Generic’ task, set the command to ‘redirect_users.sh’, check ‘Postponed execution’ and ‘Automate.’ The redirect_users.sh script can be downloaded from here.

The redirect_users.sh script:

  1. Removes the standard Users directory from the System partition. 
  2. Creates a symbolic link pointing Users to /Volumes/Data/Users.
  3. Recreates the /Users/Shared directory on the Data partition.

 

That’s it, happy reimaging!

 

Additional Information

Size Restriction
Unlike the standard single Macintosh HD partition layout, users are limited by the size of the Data partition. This can be an issue for small (<128 GB) MacBook Air SSDs. If your Macs are low on storage I recommend taking a look at this DeployStudio guide.

Always Backup
Although reimaging a machine with the above set up should not affect the Data partition you should always ensure your user has an up-to-date backup (e.g. Time Machine) beforehand.

No FileVault Support
Working mainly in school environments there has never been a demand for encrypting user data. Feedback from MacEnterprise.org members has brought to my attention that FileVault only encrypts the OS X partition (System) and not the Data partition. If you plan on using FileVault the only option is to keep everything on a single partition.

Missing Finder Icons
If a home directory path contains a symbolic link there is a bug in Finder where the pretty sidebar/home folder icons are missing. This issue occurs because we are using a symbolic link to redirect the Users directory.

To correct this issue OS X needs to be updated with the actual path to the user’s home directory. This can be done in System Preferences > Users & Groups, unlock the preferences and right click your user account > Advanced Options and update ‘Home directory,’ with the actual path (e.g. /Volumes/Data/Users/mpage).

This can also be achieved in Terminal with the ‘dscl' command by updating a user’s ‘NFSHomeDirectory’ attribute.

To automate this for school environments I have created a LaunchDaemon script, set to run on startup. This script updates all local user accounts with their actual home directory paths. You can download the script from here.

2 Comments

Creating a Never-booted OS X Standard Operating Environment (SOE) with AutoDMG

1 Comment

Creating a Never-booted OS X Standard Operating Environment (SOE) with AutoDMG

In the past creating an OS X SOE image would involve performing a clean install of OS X, installing Applications, configuring any special settings, booting into single-user mode to remove any cache and machine specific files and lastly creating a restorable disk image.

This process is time consuming, has many easy to forget steps and discourages image updating. Thankfully we now have AutoDMG, a user-friendly Mac application for creating never-booted OS X disk images.

Instead of telling you how amazing it is you can try it yourself, it’s easy!

Simply download the latest release of AutoDMG here.

To make any use of AutoDMG you will also need a copy of the Install OS X Yosemite application. You can download the latest version of OS X Yosemite from the Mac App Store here.

Open AutoDMG and drag and drop the Install OS X Yosemite application onto AutoDMG.

AutoDMG can download and install the Apple software updates released post that version of the Install OS X Yosemite application. AutoDMG is also capable of installing additional custom packages.

Click Build, select where you wish to save the image and wait.

The resulting image can then be copied straight into a DeployStudio repository.


Bonus Tips

After a major OS X combo update is released you should delete and re-download the OS X installer from the Mac App Store, as they are also updated.

In my experience packages containing preinstall and/or postinstall scripts are unreliable. The AutoDMG documentation here explains why that is. However, packages that simply copy files to a directory work reliably. If your package contains scripts, attempt a build and test the image. If it doesn’t work as expected consider repackaging it with AutoDMG friendly scripts, or simplify it down to a basic payload only package (copy various files to various directories).

I recommend only including large package files in an SOE, leaving all other packages to your preferred software package management system (e.g. Munki, Casper, etc).

1 Comment

Capturing Package Files with PkgKeeper

2 Comments

Capturing Package Files with PkgKeeper

Deploying software via Munki is an excellent asset to sites managing fleets of Macs. Sometimes however, a package will not be listed directly on Apple's Support website and also may not be taking advantage of OS X Server's Caching Service. This is why I created the script PkgKeeper. The script works by monitoring filesystem access and if a pkg or dmg file is detected a hard link of the file is created on the user’s desktop.

At this point you may be asking yourself “what is a hard link?” Every unique file on a Unix (the foundation of OS X) filesystem has an inode (index node). One of the attributes of an inode is ‘link count.’ The link count is the number of hard links to a file.

Normally a file has a link count of just one, but when a new hard link is created that link count is incremented by one. Naturally, removing a file decrements the link count by one. It is not until the link count reaches zero that the inode is removed and the space is marked as available for use.

Under normal circumstances once an update package is installed and the package is removed the file's link count goes from one to zero. However, PkgKeeper creates another hard link of the file while it is still in use setting the file's link count to two. This stops the file from hitting a link count of zero and being completely removed.

 

Using The Script

Open Terminal and paste the following to download the script:

curl -O https://raw.githubusercontent.com/Error-freeIT/PkgKeeper/master/pkgkeeper.sh

Make the script executable:

chmod +x pkgkeeper.sh

Run the script:

sudo ./pkgkeeper.sh

Start downloading an update and watch as the script captures the package file.

Note for OS X 10.11 users: El Capitan's System Integrity Protection prevents this script from working. To temporally disable SIP boot into a recovery partition or 10.11 USB installer, open Terminal and type 'csrutil enable --without dtrace'.

Bonus Tips

In Terminal you can view a file's link count with the command:

stat -f '%l' FILE_NAME

The inode also contains the User ID, Group ID and file mode attributes of the file. Therefore all hard links will have the same user, group ownership and access permissions.

Once the update is installed the original process deletes its hard link to the file. This means it is no longer accessing the file and we are safe to edit the file's ownership. The easiest way to do this is by editing the 'Sharing & Permissions' section in the 'Get Info' window.

2 Comments

Installing & Automating AutoPkg with a Launch Daemon

1 Comment

Installing & Automating AutoPkg with a Launch Daemon

UPDATE (1/12/15): Since AutoPkgr now supports recipe overrides I recommend using AutoPkgr over my headless script.


AutoPkg is a great tool for downloading and packaging software for distribution. It also integrates nicely with Munki. After testing AutoPkg I looked into methods to further automate the updating process. I came across Sean Kaiser’s blog detailing how he created a script and triggered it using a launch daemon. I took his script as an example and began to build my own, with a few extra tweaks.

My AutoPkg Wrapper triggers AutoPkg to run once daily at 8:30am, dynamically checking for updates to user recipe overrides and sending an email in the event of a new package.

Without further ado I will walk you through setting up AutoPkg and automating it with my AutoPkg Wrapper.

Note: If you haven’t already, it is important to install Munki and AutoPkg.

 

Configuring AutoPkg

First we need to add the main recipe repository to AutoPkg, we do this by opening Terminal and typing:

autopkg repo-add http://github.com/autopkg/recipes.git

Note: AutoPkg requires Git to be installed, if it is not installed you will be prompted to install it from Apple Software Update.

Next we need to set the location of our Munki repository:

defaults write com.github.autopkg MUNKI_REPO "/PATH/TO/MUNKI_REPO"

AutoPkg uses recipe overrides to override default or unspecified recipe attributes. My Munki repositories follow a consistent naming convention and therefore I create recipe overrides for every AutoPkg recipe used. Below are the criteria for packages added to my Munki repositories:

  • Packages are placed directly into pkgs and not into subdirectories.
  • Packages are named in lowercase (e.g. Firefox.dmg > firefox.dmg).
  • Packages do not contain the developer’s name (e.g. googlechrome.dmg > chrome.dmg).
  • Packages are initially added to the development catalog.
  • The pkginfo display_name attribute is set to match the package name with proper case and spaces (e.g. flashplayer.dmg > Flash Player).
  • The unattended_installs pkginfo attribute is disabled.
  • The developer and category pkginfo attributes are set.

 

Optionally you can download and install my collection of AutoPkg recipe overrides from GitHub:

git clone https://github.com/Error-freeIT/AutoPkg-Recipe-Overrides.git ~/Library/AutoPkg/RecipeOverrides

 

With AutoPkg configured let’s test a recipe:

autopkg run -v AdobeFlashPlayer.munki

Automating AutoPkg

If that worked it’s time to automate AutoPkg, download and run the autopkgwrapper installer:

git clone https://github.com/Error-freeIT/AutoPkg-Wrapper.git /tmp/autopkgwrapper && cd /tmp/autopkgwrapper && sudo ./install.sh

The install script requires administrator privileges and therefore will prompt for a password, as it copies the script and launch daemon into place and opens the script in Nano for configuration.

Update the ACCOUNT_NAME value to match the account name (a.k.a. username) containing the recipe overrides and update the EMAIL_FROM and EMAIL_TO addresses.

Note: To save changes in the Nano text editor press control + X, type y and hit return.

That’s it! Once set up you will be emailed when new items are added to the Munki repository. Standard workflow would then involve testing the new software and if the new software is stable, simply add it to your production catalog.

 

Troubleshooting The AutoPkg Wrapper

This AutoPkg Wrapper was intended to only be run as a launch daemon (by root) to manually run the AutoPkg Wrapper type:

sudo "/Library/Scripts/AutoPkg Wrapper/autopkgwrapper.sh"

You can update your email settings by typing:

sudo nano "/Library/Scripts/AutoPkg Wrapper/autopkgwrapper.sh"

By default the installed launch daemon is set to run daily at 8:30am, if you want to further customise how often the script is run I recommend editing the launch daemon with Lingon X.

1 Comment

DeployStudio Rsync Backup & Restore User Data

2 Comments

DeployStudio Rsync Backup & Restore User Data

The MacBook Air is a great laptop and thanks to its SSD (Solid-state Drive), it provides impressive read and write speeds. The only problem is that SSD storage is expensive and the approach of storing user data on a separate partition becomes unfeasible with the limited space. One site running a fleet of 64GB MacBook Airs found themselves manually backing up user data before reimaging, then manually restoring the user's data.

To help improve their workflow, I investigated methods of backing up user data during reimaging with DeployStudio. I came across the BackupRestore scripts by Rusty Myers and they looked great for backing up and restoring over a gigabit network (up to 125 MB/s). However, since all reimaging at this site occurs in the I.T. Office, I wanted to make use of the jaw-dropping speeds of USB 3.0 (up to 525 MB/s) and Thunderbolt (up to 1.25 GB/s). Of course, real world transfer rates are less due to disk read/write speeds, but it’s still a substantial improvement over gigabit Ethernet speeds.

My solution involves two scripts, a backup script ran just before DeployStudio reimages the internal disk and a restore script executed on first boot.

To further speed up the backup/restore process, unwanted data is skipped with rsync’s --include-from option, allowing pattern filtering of the items backed up and restored. A good example use is skipping the restore of ~/Library/Caches directories.

Setup

Setting up the required workflows is straightforward and takes approximately 10 minutes. To try it out simply follow the steps below.

Download backup.sh, restore.sh, backup_filter.txt and restore_filter.txt from GitHub here.

Copy backup.sh and restore.sh into your DeployStudio Scripts directory.

Copy backup_filter.txt and restore_filter.txt into your DeployStudio Files directory.

Open DeployStudio and create a workflow called 'Backup', add a ‘Generic’ script task and select backup.sh from the ‘Command’ drop-down list.

Create another workflow called ‘Restore’ and add a file copy task. Set the ‘Target volume’ to ‘Macintosh HD’, select ‘restore_filter.txt’ from the ‘File’ drop-down list and set the ‘Path’ to ‘/Library/Scripts’. Add a ‘Generic’ script task and select ‘restore.sh’ from the ‘Command’ drop-down list and check ‘Postponed execution (command will be launched on first boot).’

Create a third workflow called ‘Backup + Reimage + Restore’ and drag over three ‘Workflow’ tasks. As you can probably guess, the first ‘Workflow’ task is set to ‘Backup’. The second is your standard workflow for reimaging and the last is ‘Restore’.

Duplicate this workflow, rename it to ‘Reimage + Restore’ and remove the first backup ‘Workflow’ task. This workflow is used to restore a backup to a different Mac.

Lastly, uncheck the Publish checkboxes next to your reimage and ‘Restore’ workflows.

Time To Test

Before proceeding make sure you have a backup of any important data!

Format a USB/Thunderbolt/FireWire external disk, with the name 'Backups' and connect it to a Mac you wish to reimage.

NetBoot into DeployStudio and test out the new workflows.

Rapid Backup & Restore

Unfortunately, todays MacBook Airs only have one Thunderbolt port and during reimaging, that port is taken up by a Thunderbolt to gigabit Ethernet adapter. Although untested, I believe a Belkin Thunderbolt Express Dock would allow NetBooting into DeployStudio while attaching a Thunderbolt SSD.

Mac Migration

To migrate a user from one Mac to another, first run the the Backup workflow to take a backup of the source Mac. Connect the external disk to another Mac you will see a directory with the serial number of the source Mac. Simply rename the directory to the serial number of the destination Mac. Connect the backup disk to the destination Mac and then run a ‘Reimage + Restore’ workflow on the new Mac.

It is important to note that the restore script does not recreate user accounts, it just transfers user home directories. This is by design as the creation of the mobile account occurs when a user logs into the Mac for the first time.

Backup Archive

After successfully restoring a backup, it is moved into /Volumes/Backups/Restored/. This allows for recovery of any files that may have been skipped during restore, due to restore_filter.txt rules.

2 Comments

Apple's iPad/iPhone Out-of-Warranty Service

Comment

Apple's iPad/iPhone Out-of-Warranty Service

I often find those with broken iPads/iPhones are unaware of Apple’s Out-of-Warranty Service. Apple's Out-of-Warranty Service encourages users with accidental damage to stay with Apple without paying full price for a new iPad/iPhone. This is huge saving as with today's pricing, a 64GB iPhone 5S would cost AU$1,129 outright and if the device was damaged, replacing it through Apple's Out-of-Warranty Service would cost only AU$348.95!

Apple’s Out-of-Warranty Service covers devices that have been water damaged, cracked or are outside of their warranty period. The only requirements are that the device needs to be in one piece and cannot be damaged due to an unauthorised modification/repair.

The web pages containing the Out-of-Warranty Service information can be hard to find. Below are direct links, under the 'Warranty & Service Pricing' tab you will find the Out-of-Warranty Service pricing table:

iPad - Service Answer Centre

iPhone - Service Answer Centre

Simply walk into an Apple Store with your device and pay the Out-of-Warranty Service fee. Apple will replace your iPhone/iPad with a new or equivalent (refurbished) device of the exact same model and capacity

Comment

Creating OS X Package Files (.pkg) In Terminal

Comment

Creating OS X Package Files (.pkg) In Terminal

OS X includes a handy Terminal tool called ‘pkgbuild’ for compiling package installer files.

To demonstrate pkgbuild I will use my 'Enable ARD' (Apple Remote Desktop) package.

This package places an enableard.sh script into /Library/Scripts/Enable ARD/ and creates a LaunchDaemon to run that script on boot. The enableard.sh script simply removes all users from Remote Management (ARD) and then gives full access to a specified username, ensuring that user has remote access.

Structure

To keep things organised when creating a package, I create a directory consisting of the following files and folders:

build.sh: Includes the package name, versioning information and is used to compile the package.

complied: Is where the product of build.sh is written.

files: Contains the files the package will copy into place.

scripts: Can contain preinstall and/or postinstall scripts. A preinstall script is run before the contents of files is copied into place, whereas postinstall is after. It is important not to give these script files an extension.

Contents of build.sh:

#!/bin/bash

# Name of the package.
NAME="enableard"

# Once installed the identifier is used as the filename for a receipt files in /var/db/receipts/.
IDENTIFIER="au.com.errorfreeit.$NAME"

# Package version number.
VERSION="1.0"

# The location to copy the contents of files.
INSTALL_LOCATION="/Library/Scripts/Enable ARD"


# Remove any unwanted .DS_Store files.
find files/ -name '*.DS_Store' -type f -delete

# Set full read, write, execute permissions for owner and just read and execute permissions for group and other.
/bin/chmod -R 755 files

# Remove any extended attributes (ACEs).
/usr/bin/xattr -rc files

# Build package.
/usr/bin/pkgbuild \
    --root files/ \
    --install-location "$INSTALL_LOCATION" \
    --scripts scripts/ \
    --identifier "$IDENTIFIER" \
    --version "$VERSION" \
    "compiled/$NAME-$VERSION.pkg"

 

Contents of scripts/postinstall:

#!/bin/bash

# Filename of script.
NAME="enableard.sh"

# Path to script.
PATH="/Library/Scripts/Enable ARD"

# Script identifier (same as package identifier).
IDENTIFIER="au.com.errorfreeit.enableard"


LAUNCH_DAEMON_PLIST="/Library/LaunchDaemons/$IDENTIFIER.plist"

# Write LaunchDaemon plist file.
echo '<?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>Label</key>
    <string>'$IDENTIFIER'</string>
    <key>ProgramArguments</key>
    <array>
        <string>'$PATH/$NAME'</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>' > "$LAUNCH_DAEMON_PLIST"

# Load the new LaunchDaemon.
/bin/launchctl load "$LAUNCH_DAEMON_PLIST"

# Check LaunchDaemon is loaded.
STATUS=`/bin/launchctl list | /usr/bin/grep $IDENTIFIER | /usr/bin/awk '{print $3}'`

if [ "$STATUS" = "$IDENTIFIER" ]
then
        echo "Success: LaunchDaemon loaded."
        exit 0      
else
        echo "Error: LaunchDaemon not loaded."      
        exit 1
fi

 

Contents of files/enableard.sh:

#!/bin/bash

# Username of account used for ARD access.
USER="ardadmin"

# Revoke ARD access for all users.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -off

# Assign full privileges to an ARD Administrator account.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -configure -access -on -users $USER -privs -all -restart -agent -menu

# Set Remote Management to only accept the user specified.
/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -configure -allowAccessFor -specifiedUsers

Ready To Compile

To compile a package:

Open Terminal,

type 'cd ' (change directory),

drag the folder containing build.sh into Terminal and hit return,

type 'chmod +x build.sh' to make it executable,

lastly type ‘./build.sh’ and hit return.

You should now have a new package file in the compiled directory.

Bonus Tips

Use Full Paths

When writing scripts it is important to include the full path to any binaries used. You can easily find the full path of a binary with the ‘which’ command.

Check Your Packages

Sometimes I want to know what a package would do without running it. This is where the Finder QuickLook plug-in called ‘Suspicious Package’ comes in handy, as it shows where files would be copied and the contents of any preinstall and postinstall scripts. I also like to use Suspicious Package on my own package files to ensure files are being copied into the correct directory and any scripts are present.

Read The Manual

My example build.sh script does not take advantage of pkgbuild’s complete feature-set, for example packages can also be signed to prove authenticity. If you want to know more about pkgbuild simply read the man (manual) file, by typing ‘man pkgbuild’ into Terminal.

Comment

Disk Utility can’t repair this disk. Back up as many of your files as possible.

65 Comments

Disk Utility can’t repair this disk. Back up as many of your files as possible.

Recently I had a student whose MacBook Pro would't boot into the OS. Using an bootable OS X 10.9 USB I was able to open Disk Utility and see the 'Macintosh HD' partition greyed out. Clicking 'Mount' resulted in:

Mount failed
The disk “Macintosh HD” could not be mounted.
Try running First Aid on the disk and then retry mounting.

Running 'Repair Disk' failed with:

Disk Utility stopped repairing “Macintosh HD”
Disk Utility can’t repair this disk. Back up as many of your files as possible, reformat the disk, and restore your backed-up files.

Here are the steps to back up user data. First open Terminal under the Utilities menu.

To prevent the Mac from going to sleep type:

pmset sleep 0

Note: The display will still go to sleep, but the rest of the computer won't.

We need to find the disk identifier with:

diskutil list

Next we need to manually create a directory to mount our partition to:

mkdir /Volumes/Manual

Time to mount the partition as read only:

mount -t hfs -o rdonly /dev/disk0s2 /Volumes/Manual

Note: If you receive a 'mount_hfs: Resource busy' error your disk identifier for Macintosh HD is not disk0s2 or the more likely scenario is the Macintosh HD partition eventually mounted by itself. If Macintosh HD has mounted by itself the next command is replaced with: cd "/Volumes/Macintosh HD/Users/"

If the above mount command was successful you should be able to move into the Users directory:

cd /Volumes/Manual/Users/

List available home directories:

ls

Time to copy those irreplaceable documents:

ditto -V USERNAME "/Volumes/EXTERNALDRIVE/USERNAME"

In this example I attached an external drive named 'HFS'.

Note: Ditto copies each file individually. It is important that the drive you are copying data to has enough free space, otherwise ditto will give the error “No space left on device” skipping that particular file and going onto the next. The external drive should also be formatted in Disk Utility as 'Mac OS Extended (Journaled).'

Once the copy is complete Terminal will display '-bash-3.2#'.

Now that you have a back up, shutdown and remove the external drive. Connect the external drive to another computer and verify you have a copy of everything important.

At this point you could reformat and reinstall OS X onto the same drive. However, if you believe the disk is faulty and your MacBook is no longer under warranty I recommend having a look at the hard drive replacement guides on iFixIt.com.

65 Comments

Meet Munki - Managed Mac Software Deployment

2 Comments

Meet Munki - Managed Mac Software Deployment

Recently I have come across a number of Mac schools and businesses running Munki, an open source software distribution tool. I have only studied it for a couple weeks but I can already see why so many Mac sites are using it. This post covers the concept of Munki, my best practices and a list of common commands.

 

The Concept

To put it simply, a Munki server maintains a repository of Mac software. Users running the Munki client application (a.k.a. Managed Software Update) are notified of new software and are then prompted to install it.

Munki can deploy newer versions of currently installed applications (e.g. Google Chrome), Apple software updates (e.g. OS X 10.9.3 Combo) or even custom in-house packages (e.g. ConfigurePrinters.pkg). Munki can also detect if an application has been deleted and will reinstall it.

 

The Structure

A Munki repository is hosted on an internal web server and consists of four directories:

pkgs: This contains all available software, generally as dmg, iso or pkg files.

pkgsinfo: This contains a plist file for each software in the pkgs folder. It’s common to edit these plist files to add software to different catalogues, set software dependencies or edit the minimum OS requirements. The Munki server reads all the plists in pkgsinfo and compiles catalogues from the data. Clients do not access this directory.

catalogs: This is another directory of plists. My Munki server has two catalogues: ‘development’ and ‘production.’ Catalogues are useful for sandboxing new versions of software until they are deemed ready for widespread deployment. Munki automatically generates a catalogue named ‘all’. This catalogue should not be included in any manifest.

manifests: This directory contains more plist files, controlling which software is deployed to which clients as each client is set to download a specific manifest (e.g testing, staff_laptop, etc.). A manifest plist lists software (without versions) to install and/or remove. You can also add the optional_items key in a manifest plist and specify a list of optional software choices. This provides a self-service interface, allowing users to choose from the list of optional software.

My Best Practices

Naming Conventions
To make maintaining the Munki repository more intuitive, I have taken a different approach to naming my catalogues and manifests that differs from norm found on the Munki wiki. I have chosen not to have a ‘testing’ catalogue, only ‘development’ and ‘production’ catalogues. I do however have a manifest called ‘testing’ that accesses the ‘development’ catalogue.

Munki imports new .dmg files with the same filename. To keep the repository tidy, I recommend renaming files before importing. The filename should be in lowercase with no spaces, followed by a dash and the softwares version number (e.g. googlechrome-2.1.4.dmg).

Granular Software Control
In my previous workplace, every Mac ran a SOE (Standard Operating Environment) suite of software. Depending on the location (e.g. Art, Music, etc.) and user type (e.g. staff or student), specific extra software (e.g. Photoshop, Sibelius, etc.) was installed. On top of that there were faculty that required access to software normally only provided to Art or Music computer labs. Since Munki clients can only check a single manifest, I dealt with this limitation by creating a structure of manifests included in other manifests.

It seems confusing at first, but once the infrastructure is set up, assigning new software to all relevant clients is simple. The green bubbles are manifests that clients check, we normally do not add any software directly to these. Yellow are purely for merging manifests, again nothing should be added to these. Blue are core attributes (e.g. laptop, staff, science, etc) software is assigned to these.

For example; Skype is an application only installed on boarding house student machines. To add Skype to the boarders manifest I run:

/usr/local/munki/manifestutil
add-pkg Skype --manifest boarder

The boarder’s MacBooks are configured to check the ‘student_laptop_boarder’ manifest and therefore are notified of any changes made to ‘soe,’ ‘student,’ ‘laptop’ and ‘boarder’ manifests.

student_laptop_boarder.png

Since Skype was added to the ‘boarder’ manifest, Managed Software Update lists Skype as well as VLC media player from the ‘soe’ manifest as available software.

Please note: Manifests directly accessed by clients require a catalogue (e.g. ‘production’) to be specified, however, included manifests that are not directly accessed by clients do not require a catalogue to be set.


Updating Software

In this example I have two versions of Skype, 6.15 and 6.17 in my repository. Version 6.15 has already been tested and added to the ‘production’ catalogue, however, the newer version 6.17 still needs to be tested and was added to the ‘development’ catalogue on import. After thoroughly testing Skype version 6.17, I would simply edit the associated Skype-6.17.plist file in pkgsinfo, replacing 'development' with ‘production’ in the 'catalogs' section.

To update the ‘production’ catalogue with this change I run:

/usr/local/munki/makecatalogs

The new version of Skype is now part of the ‘production’ catalogue and made available to clients.


Common Commands

Server Commands
Display Munki server configuration:

defaults read ~/Library/Preferences/com.googlecode.munki.munkiimport

Import a new application or package:

sudo /usr/local/munki/munkiimport /PATH/TO/SOFTWARE

Rebuild catalogues from pkgsinfo data:

/usr/local/munki/makecatalogs

Enter manifest utility interactive mode:

/usr/local/munki/manifestutil

Common manifest utility interactive mode commands:

list-manifests
new-manifest MANIFESTNAME
display-manifest MANIFESTNAME
list-catalogs
list-catalog-items CATALOGNAME
add-catalog CATALOGNAME --manifest MANIFESTNAME
add-pkg CATALOGITEM --manifest MANIFESTNAME


Client Commands
Set Munki software repo URL:

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL "http://swupate.local/munki_repo"

Set ClientIdentifier (manifest):

sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier "student_laptop_boarder"

View client configuration:

defaults read /Library/Preferences/ManagedInstalls

Check for available updates from Terminal:

sudo /usr/local/munki/managedsoftwareupdate 

After checking for updates, install any discovered updates:

sudo /usr/local/munki/managedsoftwareupdate —-installonly

Download and install Apple software updates (does not require admin rights):

sudo defaults write /Library/Preferences/ManagedInstalls InstallAppleSoftwareUpdates -bool true

Show the user which software will be removed (managed uninstalls):

sudo defaults write /Library/Preferences/ManagedInstalls ShowRemovalDetail -bool true

Disable Munki installing software at the login window (useful for laptop users):

sudo defaults write /Library/Preferences/ManagedInstalls SuppressAutoInstall -bool true

Disable Munki installing software while user is logged in (useful for computer labs):

sudo defaults write /Library/Preferences/ManagedInstalls SuppressUserNotification -bool true

2 Comments

PHP ARD (Apple Remote Desktop) Import List Generator

6 Comments

PHP ARD (Apple Remote Desktop) Import List Generator

In the past, adding new computers to Apple Remote Desktop has been through either Bonjour discovery (local subnet) or scanning IP address ranges. These methods work great until you have hundreds of Macs and your ARD computer list starts to become out of sync from your colleagues.

Since we keep an asset database tracking our Mac's hostnames and last known IP addresses, I have written a PHP function for generating an ARD friendly import file.

You can find the source code on GitHub here.

This function only requires a filename and an array of Mac's with their hostname and last known IP address. Examples of these are included at the top of ardgen.php. With very little work, this script could be integrated into any database containing Mac's with their recent IP addresses.

An earlier version of this function also included device MAC addresses. However, during a migration to a new database, MAC address information was not ported over, therefore the optional MAC address data was removed from the plist generation. If you have access to the MAC addresses of your computers it is worth including it in the plist.

How to import an ARD import list file

Open Apple Remote Desktop and click 'File' > 'Import List...'

Select your newly created plist file.

Assuming all your Mac's use the same Remote Management user account, uncheck 'Verify user name and password before adding' and then click 'Add.'

With a single import, all your Macs are now in ARD!

6 Comments