gmarnin

My Bootstrappr Workflow

2018-07-29T00:00:00-04:00

See Ya NetBoot

With Apple’s introduction of the T2 processor, a long standing tool in many MacAdmin’s toolkit has taken a big hit. The T2 introduces Secure Boot which renders Macs with the chip unable to be NetBoot. Although Secure Boot can be disabled, it is non trivial to do so and clearly non advisable. In summary, Apple considers NetBoot a security risk and NetBoot is no longer a viable option going forward. Apple’s preferred NetBoot replacement is DEP and MDM. For now, my preferred replacement is Bootstrappr from Greg Neagle.

Before the T2, I was NetBooting via BSDPy into Imagr. Imagr was running a simple workflow that took a new Mac, named it and created a new Munki manifest based off a template using a forked version of a Munki-Enroll. Finally, Imagr installed a few setup packages to boot the Mac into Munki’s bootstrap mode and the rest is history. This workflow has served me well for a for a few years.

Naming the Mac is an important step in our imaging workflow. I know some environments don’t care what the Mac is named, but we do. We have stable hostnames and use the name to key off for many of our other systems. The name codifies the physical location of the Mac on our sprawling campus. We also use it for Active Directory binding, as well as the identifier for the Munki manifest name and other stuff too.

Why Bootstrappr?

Bootstrappr is a bare-bones tool to install a set of packages and scripts on a target volume. So why use it over DEP and MDM? In short, because it is quick, easy, non-fragile and it just works. I can still keep the entire imaging process on our internal network which also means I still control the whole process. Bootstrappr can replace NetBoot and my Imagr workflow. I simply feed Bootstrappr the same packages Imagr was using and I’m done. Well, done until it came time to give the Mac its name before the Munki bootstrap mode takes over. Out of the box, Bootstrappr has no support for naming a Mac.

My Workflow

Bootstrappr is a simple bash script because it is made to run in Recovery mode where a lot of other scripting languages and binaries are not available. With an idea I got from Vaughn Miller at the hallway track at PSU MacAdmins Conference, I could modify the bootstrappr.sh script to ask for the computer name and write it to a file on the boot drive. For me, that addition looks like this:

# Name the Mac. Works in conjunction with the 1_bootstrappr_macname_munki_enroll-1.0.pkg to set the name and generate a munki manifest before munki runs. 
echo
echo "Please give the Mac a name:"
read computer_name
/usr/bin/touch "/Volumes/${SELECTEDVOLUME}"/Users/Shared/computer_name.txt
echo $computer_name > "/Volumes/${SELECTEDVOLUME}"/Users/Shared/computer_name.txt

Vaughn was using Outset to run a script on first boot to read the file that Bootstrappr set. While I love me some Outset, I didn’t want it as dependency in this workflow. I was looking to replace my Imagr workflow all within my Bootstrappr workflow. With a hat tip to Mike Lynn, I started looking at /usr/sbin/chroot to allow me to run scutil on the Macintosh HD volume from Recovery mode.

I created a package named 1_bootstrappr_macname_munki_enroll-1.0.pkg which Bootstrappr runs first. The payload drops bootstrappr_macname_munki_enroll.sh in /Users/Shared/ and a postinstall which executes it.

bootstrappr_macname_munki_enroll.sh reads the computer_name.txt file which contains the name, sets the name and generates the Munki manifest using Munki-Enroll. A perfect hat trick!

/Users/Shared/bootstrappr_macname_munki_enroll.sh:

#!/bin/sh

# This script is part of our bootstrappr workflow. It sets the Mac name, and gens a munki manifest based on munki-enroll.

ComputerName=`cat /Volumes/Macintosh\ HD/Users/Shared/computer_name.txt`
Serial=`/usr/sbin/ioreg -l | grep IOPlatformSerialNumber | cut -d'"' -f4`

echo "ComputerName is $ComputerName"
echo "Serial is $Serial"

# Name the Mac 
/usr/sbin/scutil --set ComputerName "$ComputerName"
/usr/sbin/scutil --set HostName "$ComputerName"
/usr/sbin/scutil --set LocalHostName "$ComputerName"

echo "The Mac has been named to $ComputerName"

# mDNSResponder is not available in the chroot'ed environment and so all DNS lookups will fail. Using the ip address as workaround.
# Using -k option, (--insecure) because ssl cert is based on the DNS name. Doesn't work without -k
SUBMITURL="https://ip.address/munki/munki-enroll/enroll.php"

	/usr/bin/curl -vv -k -H 'Authorization:Basic KeyGoesHere' --max-time 5 --silent --get \
	-d computername="$ComputerName" \
	-d serial="$Serial" \
	"$SUBMITURL"

The postinstall script uses /usr/sbin/chroot and cleans up:

#!/bin/sh

# Macintosh HD is hard coded because new Macs have shipped with that HD name since forever
/usr/sbin/chroot /Volumes/Macintosh\ HD /Users/Shared/bootstrappr_macname_munki_enroll.sh

/bin/sleep 10

# Clean up
/bin/rm /Volumes/Macintosh\ HD/Users/Shared/computer_name.txt
/bin/rm /Volumes/Macintosh\ HD/Users/Shared/bootstrappr_macname_munki_enroll.sh

In testing, I found this works well in 10.13 and on 10.14 beta 4. In 10.12, curl throws an error that I didn’t investigate. 10.12 isn’t really a concern for me because Apple isn’t shipping anymore 10.12 Macs except for maybe the Mac Mini.

The other packages Bootstrappr installs are (in order):

1_bootstrappr_macname_munki_enroll-1.0.pkg
2_create_local_admin-1.1.pkg
3_munki-config-1.1.pkg
4_munkitools-3.3.1.3537.pkg
5_munki-bootstrap-1.0.pkg
6_SuppressSetupAssistant-1.0.pkg
7_disable-login-popups-1.3.pkg

Update

After imaging several dozen Macs using Bootstrappr with the chroot method described above, I ultimately found the chroot method of naming the Mac unreliable. I haven’t been able to pin down why some Macs get named and some don’t. I needed a more consistent workflow and so I changed things up again. I’m still having Bootstrappr ask for and write the computer name to /Users/Shared/computer_name.txt because that always works. I stopped using chroot and moved the naming of the Mac to to Munki, using a postinstall_script in a nopkg that is in my site_default manifest:

 <key>installcheck_script</key>
    <string>#!/bin/sh

# Check if computer_name file exists. Abort if it doesn't exist. 

if [ ! -f /Users/Shared/computer_name.txt ]; then
    echo "/Users/Shared/computer_name.txt not found!"
    exit 1
fi

    </string>
    <key>postinstall_script</key>
	<string>#!/bin/bash

# This script is part of our bootstrappr workflow. It sets the Mac name, and gens a munki manifest based on munki-enroll.

ComputerName=`cat /Volumes/Macintosh\ HD/Users/Shared/computer_name.txt`
Serial=`/usr/sbin/ioreg -l | grep IOPlatformSerialNumber | cut -d'"' -f4

# Name the Mac
/usr/sbin/scutil --set ComputerName "$ComputerName"
/usr/sbin/scutil --set HostName "$ComputerName"
/usr/sbin/scutil --set LocalHostName "$ComputerName"

SUBMITURL="https://ip.address/munki/munki-enroll/enroll.php"

	/usr/bin/curl -vv -k -H 'Authorization:Basic KeyGoesHere' --max-time 5 --silent --get \
	-d computername="$ComputerName" \
	-d serial="$Serial" \
	"$SUBMITURL"

# Remove the file computer_name.txt bootstrappr file
/bin/rm /Users/Shared/computer_name.txt

exit 0
    </string>

I hope you find this workflow useful or at least gives you an idea of what Bootstrappr can do. If you have a similar workflow that improves on mine, please let me know.

Happy imaging!

Schedule Restart Configuration Profile

2017-03-28T00:00:00-04:00

I had a need to reboot a small lab of student use iMacs every night. My first thought was to use a configuration profile as I try to use them whenever I need to manage a setting. This is the preferred Apple way®️ of managing macOS settings. I don’t have an MDM in production and I don’t manually create configuration profiles by hand. Instead, I run Apple’s Profile Manager inside a VM. I fire it up whenever I need to generate a profile as it does most of the work for me. I then download the profile, run plutil -convert xml1 /path/to/foo.mobileconfig to fix the formatting and make minor edits in my text editor if needed. I use Munki to install the profile.

So in Profiler Manager Server 5.1.5, I went looking for the setting to schedule reboot. To my surprise, I didn’t find it anywhere. In the Energy Saver section, I have the option to sleep or shutdown the Mac on a schedule but no option to restart. In the Energy Saver preference pane in macOS there is a option to restart on a schedule but the option to do so is missing from Profile Manager. It didn’t make sense to me why the restart option was missing from Profile Manager.

To work around this limitation, and because I only had a small lab of iMacs that needed this setting, I could of manually configured each Mac by hand. But I know that won’t scale should my need to schedule restart on more Macs grow.

My solution was to configure one Mac with the restart settings that I needed and then, in a moment of #macadminshame, copy off the /Library/Preferences/SystemConfiguration/com.apple.AutoWake.plist the Mac created and use munki-pkg to package up the file for Munki to install.

I also filed radar 26844969 requesting that the Profile Manager Energy Saver section match what is available on the Mac. Specifically, I requested the ability to create a restart configuration profile to match the settings that are available in macOS.

Six months later, Apple responded to my radar and asked me to test the latest beta of Server. I cloned my non production Profiler Manager Server VM, updated it to the latest Server beta 5.2, and retested. I’m happy to say that Apple added the ability to create a scheduled restart configuration profile.

My take away here is simple: If you think filing radars is a waste of time you’re wrong. It really works. It may not be a quick process and you may not always get the answer you want but Apple hears you. I encourage you to file early and often.

Sample configuration profile to automatically restart a Mac every weekday at 2am:

<?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>PayloadContent</key>
	<array>
		<dict>
			<key>PayloadDisplayName</key>
			<string>Energy Saver</string>
			<key>PayloadEnabled</key>
			<true/>
			<key>PayloadIdentifier</key>
			<string>com.apple.mdm.domain.edu.339b00a0-162b-0134-2637-000c29bcc5f4.alacarte.energysaver.0fc3fd60-162d-0134-2638-000c29bcc5f4</string>
			<key>PayloadType</key>
			<string>com.apple.MCX</string>
			<key>PayloadUUID</key>
			<string>0fc3fd60-162d-0134-2638-000c29bcc5f4</string>
			<key>PayloadVersion</key>
			<integer>1</integer>
			<key>com.apple.EnergySaver.desktop.Schedule</key>
			<dict>
				<key>RepeatingPowerOff</key>
				<dict>
					<key>eventtype</key>
					<string>restart</string>
					<key>time</key>
					<integer>120</integer>
					<key>weekdays</key>
					<integer>127</integer>
				</dict>
			</dict>
		</dict>
	</array>
	<key>PayloadDisplayName</key>
	<string>Schedule Restart Overnight</string>
	<key>PayloadIdentifier</key>
	<string>com.apple.mdm.domain.edu.339b00a0-162b-0134-2637-000c29bcc5f4.alacarte</string>
	<key>PayloadOrganization</key>
	<string>ITS</string>
	<key>PayloadRemovalDisallowed</key>
	<false/>
	<key>PayloadScope</key>
	<string>System</string>
	<key>PayloadType</key>
	<string>Configuration</string>
	<key>PayloadUUID</key>
	<string>339b00a0-162b-0134-2637-000c29bcc5f4</string>
	<key>PayloadVersion</key>
	<integer>1</integer>
</dict>
</plist>

Querying CDP from a Mac

2016-12-16T00:00:00-05:00

As part of our network security plan, we manage all the ethernet ports in the spaces that we support. We have some long-standing policies around ethernet ports such as only allowing managed desktops access, binding the MAC address to the port and disabling ports not in use. These policies address various issues such as only allowing authorized devices on our network, preventing desktops from being moving around and preventing unauthorized devices from being connected on our network. Desktops have their Wi-Fi interface disabled via a configuration profile installed via a Munki Conditional Item. Mobile devices can remote into our network via vpn but ethernet is off limits.

The practical impact of these policies is that everytime we setup a new desktop or move devices around we have to configure or reconfigure the ethernet ports too. We have several expensive Fluke devices to query our Cisco switches for Cisco Discovery Protocol aka CDP which provides the info needed by the networking team. Using the Fluke method works well but has some annoying downsides. Namely, you have to remember to take the Fluke with you when doing fieldwork. We support offices all over town and if you forget the Fluke while across town the job is over before it begins. Worse, sometimes the Flukes don’t get returned to their shelf when not in use, get left on desk in someone’s office or are all in use when I need one. Dead batteries happen too. These are all are common scenarios that are very inconvenient when work has to get done.

Of course, using the Fluke isn’t the only way to query Cisco switches for the relevant information. While researching alternate methods, I found whichSwitch which is an gui application that displays CDP information. It works great but has to be installed on every Mac and only runs via the gui. whichSwitch uses tshark, a terminal based version of Wireshark, to grab CDP. tshark can be used without whichSwitch but it’s a dependency that I don’t want to manage. The installations can all be automated but is not ideal for my use case. Too much work.

There is a better way. We can capture CDP information without a Fluke, gui app or third party dependencies. I’m not the first person on to post this command but I sure do use it enough to warrant posting it again. A carefully crafted tcpdump command can do it:

/usr/sbin/tcpdump -nn -v -i en0 -s 1500 -c 1 'ether[20:2] == 0x2000'

To understand what’s going on with all those switches:

tcpdump - Dump the traffic on a network
-nn- Don’t convert any addresses
-v - Verbose output
-i - Interface name
-s - Capture 1500 bytes of data from each packet rather than the default of 65535 bytes. Less data = faster run.
-c - Count 1 packet (in this case) and exit
ether[20:2] == 0x2000 Check bytes 20 and 21 from the start of the ethernet header for a value of 2000 (hex)

I have posted my CDP switch script for all to use. Along with the above tcpdump command, the script also finds the MAC, IP and link speed for the active ethernet interface. CDP can show some interesting information not easily natively obtainable from the Mac which could come in handy when troubleshooting or documenting your network setup. Examples are which switch port the Mac is plugged into and the vlan the Mac is on. The name of the switch, ip address and physical location are also available. The switch model and duplex setting are returned but are not shown in my script output. I simply don’t need that information. To view the raw CDP information returned run cat /tmp/network.txt.

Sample output from the script:

$ sudo /Library/ITS/switch_script.sh
Password:

If the Ethernet interface is active, this script can take up to 30 seconds to run.
Still beats using a Fluke in the field. Please be patient.

tcpdump: listening on en0, link-type EN10MB (Ethernet), capture size 1500 bytes
1 packet captured
1495 packets received by filter
0 packets dropped by kernel

Mac Results:
Computer Name: mac02.domain.com
Mac IP (en0) = 172.X.X.X
Mac, MAC Address = 68:5b:35:XX:XX:XX
Link Speed: 1000baseT

Switch Results:
Switch Port = GigabitEthernet1/0/32
Vlan = 120
Switch Location = Basement-Building-3
Switch Name = b01-foo-bar
Switch IP = 172.X.X.X

The main advantage is I never forget the script. I always know where it is. If I need to run the script again, I don’t have to visit the port in question. I can remote into the Mac and run it. I can then copy the results and send it off to networking. Bonus points for not having any hardware or software dependencies.

In some cases, usually to further network security, CDP might be turned off on the port you are querying. An indication of this is if the script doesn’t return any results after 60 seconds.

I hope our Flukes don’t get offended.

When AutoPkg Meets a Munki Catalog Error

2016-12-06T00:00:00-05:00

I auto run a list of 25 or so AutoPkg recipes twice a day and, if the run finds an update or throws any errors, I have the results emailed to me for review.

I recently updated to AutoPkg 1.0.0. The major feature of 1.0.0 is the Parent Trust Info which alerts you to changes made in a parent recipes. I set this up by running autopkg update-trust-info against all my recipe overrides. Then I checked all the recipe overrides with autopkg verify-trust-info which came back with OK for each override. I then ran my recipe list and I got this error for every recipe:

Error Domain=NSCocoaErrorDomain Code=3840 "Encountered unexpected EOF" UserInfo={NSDebugDescription=Encountered unexpected EOF, kCFPropertyListOldStyleParsingError=Error Domain=NSCocoaErrorDomain Code=3840 "Malformed data byte group at line 1; invalid hex" UserInfo={NSDebugDescription=Malformed data byte group at line 1; invalid hex}} Failed.

At first I thought I had an AutoPkg trust error because that is all that changed in AutoPkg. To rule out AutoPkg 1.0.0, I downgraded to AutoPkg 0.6.1 and ran my recipe list again. Same error.

I then tested a recipe I never used before: Zoom.munki. I made an override for it, like I do with all my recipes but sans the parent trust info, and ran it:

The following recipes failed: Zoom.munki Error in local.munki.Zoom: Processor: MunkiImporter: Error: Error Domain=NSCocoaErrorDomain Code=3840 "Encountered unexpected EOF" UserInfo={NSDebugDescription=Encountered unexpected EOF, kCFPropertyListOldStyleParsingError=Error Domain=NSCocoaErrorDomain Code=3840 "Malformed data byte group at line 1; invalid hex" UserInfo={NSDebugDescription=Malformed data byte group at line 1; invalid hex}}

Not exactly the same error as before. After closer inspection, it’s the MunkiImporter Processor that’s at fault. I haven’t made any recent changes that would cause MunkiImporter Processor to balk so what is going here? I wasn’t sure so I asked Greg who suspected that I have an invalid plist somewhere in my munki repo. He was right:

plutil -lint /Volumes/server/munki/catalogs/*

/Volumes/macupdates/munki/catalogs/all: Encountered unexpected EOF

That surprised me. Not sure how that happen but the fix is an easy one: Run makecatalogs which came back clean. I ran my recipe list again and everything was normal.

Curious, I checked for client errors in munkireport-php to see how many of my Macs where failing because of this catalog error. Zero. Why? Clients don’t use the all catalog as documented on the Munki wiki

Lesson learned.

Welcome to gmarnin’s Blog

2016-12-05T00:00:00-05:00

Hello World!