Be a NoMAD!

 

NoMAD stands for “no more AD” and has nothing to do with a nomadic lifestyle, nomads, ronin or other wandering IT professionals. Sorry.

NoMAD allows you to stop binding Macs to a corporate domain and instead get your kerberos tickets as needed. Connect to those file shares, change your password, and other fun tasks, without being stuck on the domain and constantly resetting your keychain from the insanity of password retention policies.

NoMAD-intro

Using Autopkg and Autopkgr to feed trusted apps into your Munki repo you can easily deploy NoMAD to your fleet of Macs.

And for bonus points you can add your preference settings as “updates for” NoMAD in Munki. One such add on is a setting for an auto mounting sharepoint.

Name your file: “menu.nomad.shares.plist” and open up your favourite text editor.

<?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”&gt;
<plist version=”1.0″>
<dict>
<key>Shares</key>
<array>
<dict>
<key>AutoMount</key>
<true/>
<key>ConnectedOnly</key>
<true/>
<key>Groups</key>
<array/>
<key>LocalMount</key>
<string></string>
<key>Name</key>
<string>Corp_Share</string>
<key>Options</key>
<array/>
<key>URL</key>
<string>smb://winserver5000/Corp_Share</string>
</dict>
</array>
<key>Version</key>
<string>1</string>
</dict>
</plist>

Create a package with munkipkg and add this to Munki. Set the package as an update for Munki and as your NoMAD agent gets installed your updates for NoMAD go with it.

More tips and tricks in the future.

 

Hello macOS Sierra, bye bye El Cap

We welcome the beautiful and wonderful macOS Sierra (10.12) and say good bye to the old and weary El Capitan (OS X 10.11.6)…. Wait, not so fast. Slow it down. Just a tad bit.

While Watchman is alerting me to users downloading, then installing the newest Apple macOS (née OS X, Mac OS X), we must be ready. Ready to troubleshoot issues with apps that developers haven’t tested thoroughly for a new OS that appears to be the same, but changes everything under the hood.

How do we test? In a VM of course.

What do we need:

  1. VMWare Fusion
  2. Greg et. al. createOSXinstallPkg
  3. Rich Trouton’s disable setup assistant payload free packages
  4. Mager Valp’s Create User Pkg
  5. Greg et. al. Munki (latest release)
  6. add your own packages, such as a munki kicksart (set repo url, client identifier, etc)
  7. UPDATE: we can’t forget Rich Trouton’s First Boot Generator App

What are we doing?

createOSXinstallPkg was created to turn Apple’s App Store Install macOS Sierra.app or previous Install OS X versions into nice Apple installer packages to upgrade in place using Munki (or other deployment tools). The new trick added recently is to create a new Fake Install.app with our packages to use install in VMWare Fusion instead of on a real Mac.

UPDATED STEPS! Note: I’d forgotten about First Boot Generator

  1. Download your installer app of choice (Install macOS sierra)
  2. Download createOSX installer
  3. Prepare your custom packages, or gathers ones your want to add to the installer
  4. Organize your installers into folders like this: 00, 01, 02, etc
  5. Launch First Boot Generator App and transmogrify that folders of packages
  6. Run createOSX installer with the fake app option if you want to test a VM, or without if you want to build a package
  7. Run createOSX as many times as you want with different OS X installers, and the same first boot package. Test diff OS installers with your customer PKGs.

Note: use the “–make-fake-app” option to prep for VMWare Fusion, omit it for a pkg

Note2: Here’s some examples using createOSXinstallPkg and various OSX installers

createOSXinstallPkg sudo ./createOSXinstallPkg --source /Volumes/SSD/Install\ macOS\ Sierra.app --make-fake-app --pkg ~/bin/PKG_BUILD/FirstBoot_staging/First\ Boot\ Package\ Install.pkg --output /Volumes/Updates/Builds

createOSXinstallPkg sudo ./createOSXinstallPkg --source /Volumes/Updates/Builds/Install\ OS\ X\ El\ Capitan.app --pkg ~/bin/PKG_BUILD/FirstBoot_staging/First\ Boot\ Package\ Install.pkg --output /Volumes/Updates/Builds

 

firstbootgeneratorapp

firstbootpackages

Note: If you get a message that your custom pkg you want to add is not a Flat package then use productbuild to repackage it.

Example:

➜  productbuild –package SetMunkiRepo.pkg SetMunkiRepo_flat.pkg

 

Reference: See Greg’s post on Managing OS X for more info make VMWare images using this method. And also Rich Trouton’s Der Flounder blog post on First Book Generator App

 

 

Munki tricks: Import Adobe CC apps

In our ongoing quest to use Munki to manage all software, one eventually gets to the realization that Adobe software must be distributed as well. How we do this?

With Adobe CC Team you can use the excellent CCP (creative cloud packaging) tool to make packages with the settings you want (users can or can’t update, importantly).

Once you have all these packages what do you do? Grab Tim Sutton’s “munkiimport_cc_installers.py” script and scan your folder with all your newly created package and you’re on your way.

https://github.com/timsutton/aamporter/blob/master/scripts/munkiimport_cc_installers.py

Example:

$ sudo ./munkiimport_cc_installers.py /tmp/CC/ –subdirectory “apps/Adobe/CC/2014” –developer “Adobe” –category “Media”
Password:
Making disk image containing AE-CC2014_Install.pkg…
created: /tmp/munki-3aetVZ/AE-CC2014_Install.dmg
Disk image created at: /tmp/munki-3aetVZ/AE-CC2014_Install.dmg
Making disk image containing AE-CC2014_Uninstall.pkg…
created: /tmp/munki-3aetVZ/AE-CC2014_Uninstall.dmg
Disk image created at: /tmp/munki-3aetVZ/AE-CC2014_Uninstall.dmg
Copying AE-CC2014_Install.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/AE-CC2014_Install-13.0.0.dmg…
Copying AE-CC2014_Uninstall.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/AE-CC2014_Uninstall-13.0.0.dmg…
Saving pkginfo to /Users/Shared/munki_repo/pkgsinfo/apps/Adobe/CC/2014/AE-CC2014-13.0.0…
Making disk image containing Pho-CC2014_Install.pkg…
created: /tmp/munki-a005sR/Pho-CC2014_Install.dmg
Disk image created at: /tmp/munki-a005sR/Pho-CC2014_Install.dmg
Making disk image containing Pho-CC2014_Uninstall.pkg…
created: /tmp/munki-a005sR/Pho-CC2014_Uninstall.dmg
Disk image created at: /tmp/munki-a005sR/Pho-CC2014_Uninstall.dmg
Copying Pho-CC2014_Install.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/Pho-CC2014_Install-15.0.dmg…
Copying Pho-CC2014_Uninstall.dmg to /Users/Shared/munki_repo/pkgs/apps/Adobe/CC/2014/Pho-CC2014_Uninstall-15.0.dmg…
Saving pkginfo to /Users/Shared/munki_repo/pkgsinfo/apps/Adobe/CC/2014/Pho-CC2014-15.0…

Using Munki and AutoPkg to automate Mac software deployment (Part 1)

Recently Munki v2.01 was released and now more than ever with the help of other apps it is easier to automate software deployment. With help with AutoPkg (and AutoPkgr) you can quickly set up a Munki server to deliver software to all your Macs. In the time it takes to download one new app and update each of your client workstations you could instead put it in your Munki repo and have it ready to deploy to everyone.

Munki allows you to automate software deployment. When you have more than one or two Macs to ensure that they are up to date with security, Flash, Java or other app updates you being to realize that an automated system can save you time and maybe even your sanity. You don’t backup manually, of course, you automate it. When it’s important and you want it done right, then some planning ahead of time and automation will make your life much easier.

If you have not yet set up a Munki server then follow along as I walk you through setting Munki 2.01 with AutoPkgr 1.1 in part 1 of this blog post of Munki and AutoPkg. In part 2 I will go into further detail of how to use MunkiAdmin (Mac app) and Mandrill (a node.js web server) to edit and maintain your Munki set up. Pros and cons of each method will be touched upon. Using the command line in the past was required but I will show you how some really good apps and web services can help you maintain your automated software deployment workflow.

Note: Munki requires only a web server to deploy software, while traditionally the munki tools ran on a Mac. You can put your software repo on any web server. I will show you the set up on a Mac for the purposes of this blog post.

Steps to a basic Munki server set up on a Mac running 10.8, 10.9, or 10.10:
1. Install latest Munki tools (v.2.01 at the time I write this), restart
muni tools 2.01 pkg

muni tools 2.01 pkg

2. Install AutoPKGr (v.1.1 at the time I write this)

AutoPkgr icon

Install AutoPkg, and Git using AutoPkgr.
Install autopkg and git using autopkgr

Install autopkg and git using autopkgr

3. Set your Munki repo to some folder (for example, /Users/Shared/munki_repo)
Munki repo

Munki repo

4. Set up web services on OS X by manually editing httpd.conf document root to your Munki repo or with Server.app, setting your munki_repo as where you store your site files.
Server.app Website document root munki repo

Server.app Website document root munki repo

6. Add recipes to AutoPKGr and choose apps. Set a schedule for AutoPkgr.
Configure AutoPkgr

Configure AutoPkgr

7. Check for apps manually the first time, and let AutoPKG download them to your repo
Configure AutoPkgr schedule

Configure AutoPkgr schedule

8. Check your repo for a manifests folder, and if it is not there, create it
Munki repo manifests

Munki repo manifests

9. Download icon importer, move to /usr/local/munki folder, run against your repo
mv iconimporter /usr/local/munki/iconimporter.py
sudo chmod +x /usr/local/munki/iconimporter.py
cd /usr/local/munki ; sudo ./iconimporter.py /Users/Shared/munki_repo/
iconimporter munki repo

iconimporter munki repo

Next, go to the icons folder in your repo, pick a fav icon and rename if necessary (some have more than one icon with name with “_1, _2, etc”).
10. Open MunkiAdmin and add packages to catalogs as needed, edit package info (add developer and category info, descriptions etc as needed), then create a client manifest.
11. Choose apps to install for clients (choose from installs, optional installs, uninstalls)
12. Set client id and repoURL on actual clients.

sudo defaults write /Library/Preferences/ManagedInstalls ClientIdentifier “test-client”

sudo defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL “http://ip.addr.ess”

Done. Your munki server is set up and ready for clients to connect. Next up, in part 2, we will look at Munki’s client facing app, the Managed Software Center. We will also look at how to use Munki Admin (Mac app) and Mandrill (a node.js web server) to edit and maintain your Munki set up. Pros and cons of each method will be touched upon. Using the command line with Munki was required in the past but the Munki ecosystem has grown and there are some really good apps and web services can help you maintain your automated software deployment workflow.
Further Reading:
1. What’s new in Munki 2  (Links to apps in the Munki ecosystem)
2. Munki 2 Demonstations setup (basic walkthrough setup)