Setting up server-side resources for Imagr testing

Imagr requires a web server (or servers) to get its workflows, images to restore, and packages to install.

In an earlier post, I described setting up an existing DeployStudio NBI for Imagr testing.

If you are testing Imagr, or even better, hoping to help with its development, you’ll need to configure a test server.

You’ll need a web server, and a way to get some files on it. I just used my existing Munki repo web server. I created a new folder called “testing” and copied a few packages into it. (For first-boot install, Imagr currently supports only flat packages. For immediate install, bundle packages are OK if they are at the root of a disk image/.dmg file.).

Next, create a configuration plist. There’s an example here: https://github.com/grahamgilbert/imagr#the-configuration-plist. Here’s another:

<?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>password</key>
  <string>40e78b0d11c553be61645796fdb9438271a23ed8b4aadb253a9222c6e4c861e2dbc75139000b0709fc0c5ad66b0f2573e38a72a8f629e270e59530fc3159d8e4</string>
  <key>workflows</key>
  <array>
    <dict>
      <key>name</key>
      <string>Munki Bootstrap</string>
      <key>description</key>
      <string>Installs the required pkgs to begin a Munki bootstrap on restart.</string>
      <key>components</key>
      <array>
        <dict>
            <key>type</key>
            <string>package</string>
            <key>url</key>
            <string>http://munki/repo/testing/DA_adminaccount_1.5.pkg</string>
            <key>pre_first_boot</key>
            <true/>
        </dict>
        <dict>
            <key>type</key>
            <string>package</string>
            <key>url</key>
            <string>http://munki/repo/testing/DisableSetupAssistant.pkg</string>
            <key>pre_first_boot</key>
            <true/>
        </dict>
        <dict>
            <key>type</key>
            <string>package</string>
            <key>url</key>
            <string>http://munki/repo/testing/munkitools-2.2.4.2431.pkg</string>
            <key>pre_first_boot</key>
            <true/>
        </dict>
        <dict>
            <key>type</key>
            <string>package</string>
            <key>url</key>
            <string>http://munki/repo/testing/munki_kickstart.pkg</string>
            <key>pre_first_boot</key>
            <true/>
        </dict>
      </array>
    </dict>
  </array>
</dict>
</plist>

The password is a hash for “LETMEIN”; you can certainly generate your own as explained here: https://github.com/grahamgilbert/imagr#password

The various URLs point to the pkgs I copied into the testing folder in my Munki repo share. Adjust as needed.

I saved this plist in the same folder as the testing pkgs as “testing.plist”. (Boring, I know.)
Make sure you can open it in a web browser before you continue — in my case it’s available
at http://munki/repo/testing/testing.plist

We are now done with the server config.

Boot a test client into the DeployStudio NBI that was configured as in my earlier post.

Open the Terminal.app.
We need to tell Imagr how to find the configuration plist, so:

defaults write com.grahamgilbert.Imagr serverurl http://munki/repo/testing/testing.plist

Make sure you replace the URL with the actual URL to the config plist you created.

Now launch Imagr:

/private/var/tmp/DSNetworkRepository/testing/Imagr.app/Contents/MacOS/Imagr

And bask in your success (or grumble at your failure…)

Setting up server-side resources for Imagr testing

Introducing Imagr

The prolific Graham Gilbert is working on a new tool: https://github.com/grahamgilbert/imagr

Imagr is an application designed to be run from a NetInstall environment. It is able to restore a disk image and install packages on a target volume.

Though Graham claims it is not intended to be a replacement for DeployStudio, I think in time it could very well be exactly that, at least for many people/organizations.

Some exciting things about Imagr:

  • It is open source! DeployStudio is free, but the source is closed. Open source means you can look at the code and see what it is doing. You can fix bugs and perhaps even help add features to the product.
  • It’s written in Cocoa-Python, with much of the “interesting” tasks in Python — a language many OS X admins are familiar with.
  • And most importantly: it does not require a specialized server: it can work with any plain-old web server. This means that you (potentially) can eliminate the last OS X device in your server room/data center. Almost every service of interest to OS X admins can be run on platforms other than OS X with the huge exception of a DeployStudio server. If Imagr can meet your imaging/machine build needs, you can finally get rid of that poor Mac mini sitting on a shelf in the server room.

Graham has posted detailed instructions on how to build a NetBoot image that contains Imagr. But if you just want to take a look and play with the tool, and you have an existing DeployStudio NBI with Python support included, you can play with Imagr without needing to build a new NBI. More importantly, you can test new versions (or work on the code yourself and test new versions you build) without having to build a new NBI each time.

Continue reading “Introducing Imagr”

Introducing Imagr

“Building” 2015 Macs

We’ve recently gotten a few of the new 2015 Macs, specifically the new MacBook Airs and 13″ MacBook Pros. These models have new builds of 10.10.2, and won’t boot from our current NetBoot/DeployStudio Server.

While there are ways of capturing the hardware-specific OS so you can use it with AutoDMG and to create NetBoot sets, usually what we do with new hardware like this is employ a “no-imaging” process: we boot the new machine in Target Disk Mode, attach it to another Mac, and install some “bootstrapping” packages on the new Mac. For us, that’s four packages:

  • A package to create a local admin account
  • A package to disable the Setup Assistant
  • The Munki tools package
  • A package to put Munki in “bootstrap mode” on first boot.

Once these packages are installed on the new machine, we shut it down, connect it to the network, and start it up. Munki takes over and installs everything else we need.

This approach has worked well for us in the past with new hardware, and allowed us to deploy new hardware to users much faster than if we had to build hardware-specific NetBoot and AutoDMG images.

But these new 2015 Macs were throwing us a curve ball. After using Target Disk Mode to install the packages, upon reboot the Macs were refusing to boot, or booting very slowly. A check with Disk Utility claimed the startup volume had unrepairable filesystem corruption, and advised us to back up any user data, format, and re-install.

We saw this behavior on multiple new 2015 machines. Two things that stood out to me:

  • The new machines all ship with an unencrypted CoreStorage volume as their main system volume, and
  • We were connecting these machines (in Target Disk Mode) to a Mac running Mavericks (10.9.5).

My theory was that there is a bug causing the Installer on Mavericks to do something “wrong” when installing to a Yosemite CoreStorage volume that led to file system corruption.

I did not have the time (or desire) to get to the bottom of this issue; I needed to find a successful procedure for getting these new 2015 Macs to build. I found two.

First one: after starting the new Mac in Target Disk Mode, connect to another Mac running OS X Yosemite 10.10.2, and install the bootstrapping packages.

Second one: Boot the new Mac into the Recovery partition. Connect a USB drive (a flash stick will do) containing the bootstrapping packages. Open the Terminal from the Utilities menu and use the command-line installer to install the bootstrapping packages onto the main partition.

With either method, things proceeded normally and there was no filesystem corruption.

UPDATE: after seeing some reactions to this post on Twitter, until we understand more about this issue, I’d recommend using the second approach (via Recovery partition) — it’s possible this is more about Thunderbolt/Target Disk Mode than it is about 10.9 vs 10.10.

I hope this saves others some time and headaches.

“Building” 2015 Macs

“unsetpassword” alternatives

Recently, prolific Mac admin documentation writer Rich Trouton blogged about a new tool available in Yosemite: unsetpassword. It’s a tool with a rather specific purpose: to clear the password for a local admin user account and set it to require a new password.

Rich’s post is here.

Rich’s suggested use-case for this tool is this: you create a local account for a user on a new machine. Instead of then handing the machine over with a password you now know (and the user may not change) or with an empty password (that the user may not replace with a better one), instead, you run unsetpassword before returning the machine to the user. The user now logs in with a blank password and is immediately prompted to change it.

You actually have to run sudo unsetpassword while logged into the account. This limits its functionality to admin accounts — you can’t use this tool to unset the account password if you’ve set up a standard account for a user. It’s pretty common to provide standard accounts — that is, accounts without admin rights — to users in many organizations, so this is a significant limitation.

The tool also leaves the login.keychain and Local Items keychains in place, but does not reset their passwords, leading to an almost certainly confusing prompt when the user logs in after the password is unset.

unsetpassword also forces a shutdown after running. This doesn’t seem strictly needed. Certainly a logout is needed, but it seems annoying to have to go through a restart cycle.

Finally, this tool is available only on Yosemite. If you are still supporting and even deploying machines running older versions of OS X, you can’t use it. But there is good news. You can accomplish the same basic task (“unsetting” a local user account password) with other tools that exist in Yosemite and older versions of OS X.

Here are the commands:

sudo dscl . passwd /Users/username ""
sudo pwpolicy -u username -setpolicy "newPasswordRequired=1"

Where “username” is the short username of the user for whom you wish to “unset” their password.

The dscl command sets the user’s password to an empty string.
The pwpolicy command marks the account as requiring a new password.

If the user account is an admin account capable of running commands with sudo, you can run these commands while logged in as that account. You should then immediately log out. (Shutting down as the unsetpassword command does isn’t required.)

If you have a different admin account available (either locally or via directory services), or you can SSH in as root, you can run these commands for a non-admin user account.

We can also eliminate the keychain prompts. Since the intention here is a new account setup, there shouldn’t be anything of value stored in the login keychain, so we could just delete the login.keychain and Local Items keychains. When the user logs back in, these keychains will be recreated without prompting the user.

sudo rm -r ~username/Library/Keychains/*

As always, you should test these commands on some test accounts to get a feel for how they work. While the unsetpassword command is much easier to remember, the techniques presented here are more flexible and usable in more contexts.

“unsetpassword” alternatives

Configuration Profiles and Identity payloads

In today’s MacTech deployment lab, the subject of using Identity payloads in configuration profiles came up.

Here: https://raw.githubusercontent.com/gregneagle/profiles/master/Identity_payload_demo.mobileconfig is a sample/demo configuration profile that contains both an Identity payload and an Email configuration payload.

When installed (by double-clicking the profile, after the normal warnings, the user is presented with a form for entering identification information:

Profiles identity

After entering the requested information and clicking Continue, Mail.app gets a new Gmail account added with the information you entered.

Configuration Profiles and Identity payloads

MacTech Conference 2014: What’s New with Munki?

Here are links from my MacTech Conference 2014 presentation: “What’s New with Munki?”.

Munki itself:

GUI tools:

Web interfaces/Web reporting consoles:

Alternate Munki servers:

Update management:

Miscellaneous tools and add-ons:

Managed Software Center help page link:

Munki 2 documentation:

Munki discussion group:

Munki demonstration setup:

Removing Munki:

MacTech Conference 2014: What’s New with Munki?

You Oughta Check Out AutoPkg: Links

If you attended my presentation on AutoPkg today, thanks! Here are the links:

AutoPkg:
http://autopkg.github.io/autopkg
https://github.com/autopkg/autopkg
https://github.com/autopkg/autopkg/releases

AutoPkg recipe repos:
http://github.com/autopkg

JSSImporter:
https://github.com/arubdesu/jss-autopkg-addon

AbsoluteManage Processor:
https://github.com/tburgin/autopkg/blob/master/Code/autopkglib/AbsoluteManageExport.py

AutoPkg Change Notifications script:
http://seankaiser.com/blog/2013/12/16/autopkg-change-notifications/

MacSysAdmin 2013 session:
http://docs.macsysadmin.se/2013/video/Day2Session4.mp4

Steve Yuroff’s AutoPkg and Jenkins notes:
http://swytechnotes.wordpress.com/2013/10/21/autopkg-and-jenkins-under-one-admin-account/

AutoPkg Wiki:
https://github.com/autopkg/autopkg/wiki

You Oughta Check Out AutoPkg: Links