Tag Archives: Deployment

Automate those apps. Get some robot love 🤖 âť¤ď¸Ź!

Posted on by
1

If only one person needs an application then I think about using Munki to deploy that app. If more than one person should have it then Munki is definitely the way to automate app deployment. And really, if you’re going to take the time to download an app from a website, mount a disk image or un-pack a ZIP archive, run an installer, type an admin password, close that installer … then for the love of all that is good just put the app into your Munki repo and be done with it. Automate it.

Using Munki to solve problems makes sense. Automation helps everyone in this case. But if you’re putting in one off applications into your Munki repo more often than you need to, you need to get those apps into Autopkg. Using Autopkg recipes to download the latest apps and put them into your Munki repo automatically is an automation love fest, but if your apps don’t have recipes what are you going to do? Manually add your apps to Munki? No way. We need a robot 🤖❤️. Recipe robot, that is.

Using Recipe Robot we can build Autopkg recipes for most apps then add the recipes to the Autopkg community to enjoy. Everyone wins.

I recently created recipes for two important apps in my media workflow: Kyno and Hedge. I’ll show an example of this workflow using Recipe Robot and Munki Admin to demonstrate the workflow.

Step 1. Feed the robot.

Drag and and drop the app you want to create your Autopkg recipes.

RecipeRobot-FeedMe

Step 2. Watch the robot do it’s work

RecipeRobot-start

Step 3. Robot is done. Recipes made.

RecipeRobot-Done

Various type of recipes can be made. I chose download and munki because those are what I am using to automate adding apps to my Munki repo. But there are other options: jss, Filewave, or “install” for example.

reciperobot-options.jpg

Step 4. Run those Recipes

You can use your recipes locally with Autopkg. Run them in Terminal or use Autopkgr , a very nice GUI app for automating the collection and scheduling of recipes. Note: Autopkg and Munki can all be run via cli (command line interface) but for this demo we are showing the GUI apps that are there provided by outstanding members of the community. Many Thanks to them and the contributors to their projects.

Autopkgr-notification

Autopkgr app can send notifications in macOS, emails, or post to your Slack group.

Step 5. See the recipes, Use them wisely

MunkiAdmin-Recently ChangedPKGS

Here is an example of newly imported Kyno and Hedge apps in our Munki repo (via Munki Admin GUI).

MunkiAdmin-Description

Add a display name, choose which catalogs the apps will reside in, and check that the description will help explain what the app is.

References:

Elliot Jordan – Autopkg talk at MacDevOps:YVR

https://youtu.be/Q_cvgGtJ71M

Elliot Jordan – Recipe Robot talk at MacDevOps:YVR

https://youtu.be/DgjO1mfMHtI

 

Use Munki to install a screensaver

Posted on by
Reply

Use munki-pkg to package up stuff and make your life easier when managing Macs using munki. Here is an example of installing a screensaver.

Why use munki-pkg? How else do you install stuff using munki, run scripts, and version your testing buildings all in one easy to use application? This is all possible with munki-pkg.

Munki-pkg makes package (PKG) installers, Munki likes pkg installers. Munki will also install apps, run scripts, install profiles, and do many things but packages are useful because we can put files in specific places, such as the main computer level screensaver folder, then run a script to set it as a default.

Download munki-pkg and create a working project folder.

Step 1.

Create the folders you need and place your files (payloads) in the right places.

munkipkg-payload.png

Step 2.

Create your post install script if you need one. Example: setting the screensaver you just installed as the default.

#!/bin/sh

defaults -currentHost write com.apple.screensaver moduleDict -dict moduleName Brooklyn path /System/Library/Screen\ Savers/Brooklyn.saver/ type 0

 

munkipkg-postinstall.png

Step 3. Build your package

Run munki-pkg on the command line and build your package. If you make changes then version up in your build-info.plist and build again.

munkipkg-build.png

 

 

No NetBoot, No problem: installr and bootstrappr

Posted on by
Reply

It’s 2019, and NetBoot is almost dead. All new Macs have T2 chips. Sent from the future to protect us from …. ourselves? No more NetBoot, no problem!!

When NetBoot first appeared and I was able to boot entire labs of Macs across the network I was amazed and overjoyed. It was awesome. Spinning globe, spinning…

Netboot-GlobeSpin.jpg

But in the years since I’ve moved on to no-imaging. Using Munki to manage software means no more imaging, just install Munki and a small config change to point to the Munki server, thereafter the software that should be there goes on, and what’s not supposed to be there goes away. Simple. Just install one package, well, maybe two, then you’re good.

Well, what if you want to streamline or automate these things? What if these are new Macs which don’t have users configured? What if we could do all this from recovery mode? Hmm… Enter bootstrappr and installr!!

bootstrappr

This awesome project allows to add packages to install in one step while booted in recovery mode. Plug in a USB stick with the bootstrapr script to run the package install magic or mount a disk image over http. Create a DMG with the included script make_dmg.sh. And now this is the best part: in recovery mode open the Terminal app from Utilities and type:

hdiutil mount http://server/yourDMG.dmg

Then:

/Volumes/bootstrap/run

When it’s done you can Reboot the Mac and you’ll have a set up customized to your liking with Munki installed and configured with custom settings.

installr

The installr script works in the same way but adds the macOS installer to the party. You can also mount the DMG over http and re-image a Mac and then add your custom packages. It’s awesome. Truly amazing.

One note: Added packages in Installr must be in a special format. From the installr site: startosinstall requires that all additional packages be Distribution-style packages (typically built with productbuild) and not component-style packages (typically built with pkgbuild)

productbuild --package component.pkg --version x.y --identifier com.example.component distribution.pkg

In one of my first tests with installr and pycreateuserpkg I was caught up by this, even though it is properly mentioned in the read me. Packages that work in Bootstrappr or munki directly don’t necessarily work when called by the macOS installer (startoinstall). Armin Briegel was helpful in the MacAdmins Slack and reminded me of this. Thanks Armin and thanks everyone on the MacAdmins Slack.

Many Thanks to Greg Neagle for creating these tools and Munki. Looking forward to hearing him speak at the next MacDevOps:YVR conference June 12-14, 2019. Greg will be speaking about his efforts to port some parts of Munki from Python to Swift. More info on the conference and speakers here: https://mdoyvr.com/speakers/

Also a shout out to Graham Gilbert who has worked on Imagr (MDOYVR talk), over the years, an imaging and automation tool which was also an inspiration (along with bootstrappr and installr) to Tim Perfit and his MDS project.

Update: corrected the names of installr and bootstrappr in the title because… autocorrect.

 

Blocking minor major macOS upgrades

Posted on by
1

Continuing our theme of welcoming our new macOS overlords, uh, I mean, blocking major macOS upgrades such as macOS 10.14 Mojave with AppBlock we shall examine some other methods of stopping the freight train known as Apple upgrades.

1) A smart person on the MacAdmins Slack posted a useful command to tell macOS not to download major upgrades.

In their testing, running:

`software update –ignore macOSInstallerNotification_GM`

blocks the installation of the Mojave notification package (at /Library/Bundles/OSXNotification.bundle).

However if it already installed, then it’s too late. They pushed out this command prior to that package being distributed by Apple, and they could subsequently see in install.log that the update is being found by softwareupdated but not being installed.

2) If you missed the chance to tell the Mac not to download major macOS upgrades then Rick Heil on his blog has detailed a way using munki to delete the bundle that triggers the macOS upgrade installer.

3) App Block

If your users are intent or their computers are all hell bent on downloading the install app then block it with App block detailed in my previously mentioned blog post

4) Warning

In an effort to get an early warning when users are about to upgrade I use Watchman Monitoring to send me an alert email when a Mac starts downloading the Install macOS app. Sometimes it’s enough of a warning to send an email to a user to ask them whether it is a good idea to upgrade at this time. If storage or software needed for production or backups aren’t qualified or tested thoroughly beforehand then upgrading in the early waves can be less than ideal and frought with peril.

In other interesting and related news, Victor (MicroMDM) was spelunking into the MDM Protocol for what prompts Macs like iOS devices to download major updates. Great post here

If you have any better ways to block macOS upgrades or want to contribute some great solutions let me know. Cheers

 

 

 

 

Be a NoMAD!

Posted on by
Reply

 

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.

 

Setting up Secure Munki

Posted on by
Reply

So you’ve set up Munki to deploy software to your Macs by following the basic set up here: Set up Munki, and now you want to set it up more securely.

You need two things. 1) a cert and 2) a secure repo

  • TRUST US

The optimal situation is a trusted secure certificate for your server from a reputable certificate authority, if you don’t have that, or want to use the self-signed certificate your server has then your Munki Mac clients will need to trust this certificate.

Export out the cert from Server Admin if you’re using that to manage your Mac mini server. Place this cert file on your clients (using ARD, or other methods) then use the security command to get the Mac clients to trust this cert.

security add-trusted-cert -d -r trustRoot -k “/Library/Keychains/System.keychain” “/private/tmp/name-of-server.cer”

REFERENCE: Rich Trouton’s blog goes into more detail and details a way to script this.

  •  SECURE IT

Use htpasswd to add a password to your Munki repo.

htpasswd -c .htpasswd munki

Edit the htaccess info

AuthType Basic
AuthName "Munki Repository"
AuthUserFile /path/to/your/munki/repo_root/.htpasswd
Require valid-user

Encode this password for Munki:

python -c 'import base64; print "Authorization: Basic %s" % base64.b64encode("USERNAME:PASSWORD")'
Authorization: Basic VVNFUk5BTUU6UEFTU1dPUkQ=

Push out this password to your Munki clients with ARD (or use some other method)

defaults write /Library/Preferences/ManagedInstalls.plist AdditionalHttpHeaders -array “Authorization: VVNFUk5BTUU6UEFTU1dPUkQ=”

Change the Munki RepoURL on all your clients to use the new secure URL

defaults write /Library/Preferences/ManagedInstalls SoftwareRepoURL “https://munkiserver/munki_repo&#8221;

REFERENCES:

Consult the Munki Wiki for: Basic authentication setup for Munki 

Ala Siu’s excellent write on securing munki

Notes:

Consider using a server made for securing Munki, like the Squirrel server from the MicroMDM project. More on this in another blog post.

Consider using certificate from a known reputable certificate authority such as Let’s Encrypt (the Squirrel server above automates the setup with Let’s Encrypt).

Further:

Another project which seeks to combine all these open source projects in the Munki ecosystem is Munki in a Box. There’s a secure branch of this project which setups a basic authentication as well but while it aims to simplify setting up a secure Munki it may be a bit confusing to set up at first glance. Test, and test again.

 

 

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

Posted on by
Reply

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

 

Hello macOS Sierra, bye bye El Cap

Posted on by
Reply

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

 

 

Packaging and deploying software

Posted on by
Reply

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.

 

 

Troubleshooting AutoPkgr

Posted on by
2

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.