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.

 

Troubleshooting Autopkg and AutoPkgr (part 1 of 5,432)

I love Autopkg and Autopkgr. They feed Munki and they keep me fed.

Sometimes Autopkg gives an error that doesn’t make sense since you don’t have enough info. Like this one:

autopkgr-work-tree

That’s no way to make friends. Nope.

If even I understood all that… which is saying a lot. It doesn’t tell us what to do, or where to go to fix it.

Git makes sense, but maybe not in the context of Autopkgr errors. It wants us to “Git add or rm” (remove) offending items, but what does it have to do with what we’re doing at this moment? Hmm. Ok, we know  that autopkgr uses autopkg which uses git but that still leaves us in the dark about what’s going on.

Drop down in terminal and poke at autopkg. That always helps.

bash-3.2$ autopkg

Usage: autopkg <verb> <options>, where <verb> is one of the following:

    help             (Display this help)

    info             (Get info about configuration or a recipe)

    install          (Run one or more install recipes. Example: autopkg install Firefox -- equivalent to: autopkg run Firefox.install)

    list-processors  (List available core Processors)

    list-recipes     (List recipes available locally)

    make-override    (Make a recipe override)

    processor-info   (Get information about a specific processor)

    repo-add         (Add one or more recipe repo from a URL)

    repo-delete      (Delete a recipe repo)

    repo-list        (List installed recipe repos)

    repo-update      (Update one or more recipe repos)

    run              (Run one or more recipes)

    search           (Search for recipes on GitHub.)

    version          (Print the current version of autopkg)

autopkg <verb> --help for more help for that verb

Looking at all that we notice that “repo-update” is most likely the autopkg command that gets activated when Autopkgr gui “update repos now” button gets clicked.

screen-shot-2016-09-29-at-10-26-20-am

Running autopkg with repo-update option gets us a better error message.

Attempting git pull for /Users/awesome/Library/AutoPkg/RecipeRepos/

com.github.autopkg.wardsparadox-recipes...

ERROR: Pull is not possible because you have unmerged files.

Please, fix them up in the work tree, and then use 'git add/rm <file>'

as appropriate to mark resolution and make a commit.

So, at least we know now what is causing that error that Autopkgr showed us. Quick fix:

autopkg repo-delete https://github.com/autopkg/wardsparadox-recipes.git

And then we go on and pretend like nothing happened and continue on with our day, amirate? Maybe we go to the Mac Admins Slack autopkg channel and ask our colleagues, or  post on the autopkg mail-list. Or we write a blog post.

More information:

The Autopkgr read me has troubleshooting tips

In the archives:

I first wrote about troubleshooting Autopkgr 2 years ago

 

Packaging and deploying software

I am about to send an email to a software vendor asking them to please consider shipping their apps in a deployable Apple PKG format and I wanted to ask if anyone has some boilerplate text, excellent blog entry or list of arguments I can use. I could have posted in the MacAdmins slack, tweeted or posted a lovely photo on Instagram, but instead I sent an email to the MacEnterprise mail list.

Hat tip to Rick Heil on the MacEnterprise for pointing me to this post on AFP548 by Gary Larizza in June 2010.

“This one is an oldie but a goodie. It hits all my pain points, such as not assuming GUI interaction and minimizing pre/post scripts.”

https://www.afp548.com/2010/06/03/the-commandments-of-packaging-in-os-x/

Gary outlines his thesis in six rules:

  1. Do not assume that your package will be installed interactively via the GUI or on the currently booted volume.
  2. Unnecessary actions are unnecessary.
  3. Licensing should have the option to be managed by Systems Administrators.
  4. Use pre/post-install scripts only when necessary
  5. Be true to the Operating System
  6. Naming Conventions are Necessary and Helpful

All software vendors should aspire to follow these rules.

We should always send feedback to software vendors explaining carefully why their Mac OS X installers are not optimal for deployment when they are custom apps (e.g. InstallAnywhere) and not in Apple package format (i.e. PKG). Also, if the installers (as well as the app) require the legacy Java 6 then this seems to be a security risk and it is our duty to provide feedback if we hope to improve the situation in the future.

Another great source of information is Der Flounder, Rich Trouton’s blog, is worth perusing because of Rich’s excellent documentation and many excellent posts, including this one about re-packaging app:

“Using AutoPkg to build installer packages from installer applications” from May 24, 2016.

Reference: Re-packing using Auto PKG

As Rich succinctly puts it: “One of the challenges Mac admins have to deal with are Mac application installers which don’t follow one of the following models: Drag-and-drop installation or Package installation”.

Greg’s managingosx blog has many articles on packaging and I thank you for taking the time to write all those posts. We benefit greatly from all the work of everyone in this community. Greg has spoken at many conferences and given great packaging workshops.

Reference: packaging blog posts on Managing OSX
My personal preference for software deployment is to use Munki to deploy apps and not have to deploy app manually. While Mac sysadmins may use difference software for deployment, I think we are all in agreement in not wanting to do this manually when it can be automated. I don’t have a large IT team, and simple solutions based with Munki are best for me. Hence my desire for vendors to use the Apple PKG format where possible.

 

 

MacDevOps Manifesto

I was explaining Munki (and autopkg) to some colleagues when I hit on the idea of the MacDevOps manifesto.

Munki and friends (apps used to augment and extend Munki) are helpful automation tools. Setting up automation systems take time and must be maintained and grown but they pay big dividends.  Freeing us to do Dev work or other tasks they automate and iterate and repeat and build our systems in the way we want.

No more 100 machines built in a hundred different ways (unless we want to). But now we can check at a glance in MunkiReport to verify that indeed the latest Adobe Flash patch is installed. That may make our lives better. Especially if we need to satisfy corporate IT or our bosses that we are up to date and patched as required.

The MacDevOps Manifesto Part 1: Munki and friends

Munki is at its core free software created by Greg Neagle at Disney Animation and used worldwide in many different ways but essentially to distribute apps and run scripts on client workstations. There are many ways to customize it and if fits many different workflows. The MacDevOps:YVR conference I ran last June turned out to be a Munki love-in and showed me the many awesome and varied ways organizations are using it.

With AutoPkg, another free Mac open source project, Munki can get the latest updates to any software that it has recipes for and by extension install them on clients immediately. This fits the workflow of having Flash, Java and web browsers (Chrome or FireFox) updated as soon as possible for security patches. Exploits on the Mac are coming from these entry points and if you need to use these apps or plugins then having the latest versions helps. For this feature alone I use Munki. In a few months you will see that Munki with AutoPkg has downloaded dozens of versions of each app and keeping up with this takes time away from other tasks. Automation of simple tasks frees up our time so we can focus on other things. That is MacDevOps.

I also use Munki for installation of any app that is needed everywhere. If I have to download or install one app for one client workstation I put it in Munki and it is ready for installation anywhere with a simple click by the user in a self service portal or automatically by choosing managed installs. Of course if there is an app you don’t want installed (flash or Skype or messenger, etc) add it to Munki and mark it as managed uninstall. Done.

Scripts and files and config Profiles (replacement for mcx, managed preference settings for OS X) can be imported and used to configure workstations to make deployment easy and flexible. Put everything in Munki and then you don’t have to use golden master builds anymore. Buy a new Mac and install the Munki client. Done.

Add to this Munki Report which gives an excellent dashboard for what is installed and a total inventory of your client Macs. Very useful info which will let you know if you 15 different versions of flash or Photoshop or any app you choose to look for.

Last but least I always install Watchman Monitoring which reports to a secure cloud (web portal) to automatically monitor for bad drives, Ram, backups not running etc. It’s a great 50ft overview of all your installs and it can alert you immediately when a machine is having issues that you need to deal with (drives 90% full or Xsan volume not mounted, etc).

I find this combination of Munki and Watchman great for helping me manage my clients and I want to share these ideas about MacDevOps inspired ways of automating systems with everyone. Jump in and get involved with all these projects. You’ll be writing recipes for AutoPkg and sharing cool Munki tips and tricks with all your friends. And maybe like me you will start writing plugins for Watchman to monitor your favourite apps (I’m working on Archiware P5 backup and archive monitoring scripts).

Good luck to everyone and hope to see you at the next MacDevOps:YVR conference in June 2016. If you can’t make it go to your nearest Mac Dev / IT conference or start your own meet up somewhere local.

Troubleshooting AutoPkgr

While awaiting my awesome Part.2 of how to set up Munki we will look at quick fix I made recently to troubleshoot AutoPkgr issues I was having.

I have AutoPkgr set up with several sites as a quick and easy way to get updates of free and licensed software into Munki. Strangely, I ran into an error on my test box, and not on my deployments with clients. So it was something I had done, but what did I do?

AutoPkgr python error

AutoPkgr python error

At first I thought that one of the recent updates to AutoPkgr had broken the application. But since it was running correctly elsewhere I had to quickly rule that out. Running the recipes, which looks for new updates of certain applications, kept giving me a python error. How do you troubleshoot this? Re-install Python? De-compile AutoPkgr? Rant on the MacEnterprise maillist? No, that won’t help. 🙂

AutoPkgr is a very nice GUI front end to the excellent AutoPkg project. AutoPkgr installs Git and AutoPkg which are needed. AutoPkgr makes much of the set up much quicker and faster. It’s a great tool. Thanks to the Linde group.

AutoPkgr update dialog

AutoPkgr update dialog

The best way to troubleshoot this issue with AutoPkgr is to see if it is an issue with AutoPkgr. Let’s see if AutoPkg runs at all, and with the same errors. Now there’s an idea. So how do we run AutoPkg? Terminal. Open Terminal.app, and run AutoPkg directly. I always start with a basic “where is the app binary I want?” and then run the app with no options to see if there’s a help menu with an explanation of the switches.

AutoPkg in Terminal

AutoPkg in Terminal

Looking at what Terminal says we now know that AutoPkg is installed in the path /usr/local/bin which is a very accepted place for non-standard (extra, or optional) binaries to live. We also know that “autopkg run all” is not the correct command to run, but it was enough to elicit a better error message. In fact, the problem seems to be a “plist error” with the TextWrangler override recipe. What’s that you might be asking? AutoPkg allows the use of “overrides” which adjust a recipe. In my use of AutoPkg I set an override to add information to a recipe, specifically developer and category information so that Munki’s Managed Software Update app correctly displays the information and the user has a more logically sorted software self-serve portal. In any case, we know from this error that something is wrong with the override. I can run xmllint and clean it, I can open and find the error, or I can just delete this override and re-run AutoPkg to see if we can get somewhere.

AutoPkg transmit

AutoPkg transmit

In this example I run AutoPkg with the Transmit recipe and all runs well. Everything is good now. So what’s the lesson here? Be careful with your plist files. When you make your override, and add useful keys, double-check your work to avoid a broken AutoPkg.

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)