Category: OSX app deployment automation

  • 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

     

     

  • 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.

     

     

  • Hands on with Imagr

    At the recent MacTech conference in Los Angeles I got a chance to sit in a workshop led by Graham Gilbert walking us through his open source imaging tool, Imagr.

    This was a perfect follow-up to last year’s awesome demo by Pepijn Bruienne at last year’s MacTech where he demoed his BSDPy netboot replacement running in a Docker container net booting and imaging a new VM in VMWare. Amazing live netboot demo with bonus points for writing your own netboot replacement in Python, stuffing it into a Docker container!

    This year, Graham Gilbert led us through setting up BSDPy Docker container, getting the link to VMware working and using his Imagr tool to image a new VM instance of OS X. Fun stuff.

    Here are some screenshots:

    1. VMWare booting up looking for NetBoot services
    VMWare booting up
    VMWare booting up

    2. The lovely NetBoot globe spinning

    Netboot globe
    NetBoot

    3. Progress!

    Booting up
    Booting up

    4. Image NetBoot image booted

    Netboot image booted, but there’s an issue with the plist I built by hand. Some of the keys and strings got mixed up when copying from the whiteboard. Thanks to Rich Trouton who was sitting next to me who helped me diff his plist with mine to find how I’d messed it up. Easy to fix, slightly tricky to find. Luckily you only have to edit this plist to do initial set up.

    Image NetBoot image booted
    Image NetBoot image booted

    5. Imagr start up

    Imagr start up
    Imagr start up

    6. Imagr starting, password first

    Image password
    Image password

    7. Imagr restoring OS X image

    Imagr restoring OS X image
    Imagr restoring OS X image

    8. Imgr completed workflow

    Imgr completed workflow
    Imgr completed workflow

    9. Shutting docker down

    docker down
    docker down

    Reference:

    Graham Gilbert’s blog post with slides of the workshop.

    http://grahamgilbert.com/blog/2015/11/12/mactech-2015-hands-on-with-imagr/

    Pepijn Bruienne’s blog, Enterprise Mac

    http://enterprisemac.bruienne.com

  • Munki discussion groups

    As posted on the munki-dev list by Greg Neagle and posted https://github.com/munki/munki/wiki/Discussion-Group, a list of discussion groups related to Munki:

    Discussion group for the development of Munki is here: http://groups.google.com/group/munki-dev

    Other related discussion groups:
    General Munki discussion: https://groups.google.com/forum/#!forum/munki-discuss
    MunkiAdmin: https://groups.google.com/forum/#!forum/munkiadmin
    MunkiReport: https://groups.google.com/forum/#!forum/munkireport
    MunkiWebAdmin: https://groups.google.com/forum/#!forum/munki-web-admin
    Sal: https://groups.google.com/forum/#!forum/sal-discuss
    Simian: https://groups.google.com/forum/#!forum/simian-discuss

  • 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…

  • Munki: Part 3 aka Setting up MunkiReport-PHP to monitor your Munki Setup

    This is Part 3 in our series on getting started with Munki. Part 1 covered the basic installation of Munki and the elusive Part 2 covers using Munki Admin and Munki’s Managed Software Centre. Part 3 covers the after you’ve setup Munki, now what part of the deployment. Munki is installed. Software is downloaded via AutoPkg and manifest contain catalog and clients have manifests. But is it working? Do all the Macs have the latest Flash plugin? Do they really? We will cover basic setup of MunkiReport-PHP to show  easy it can be to get going.

     Step 1. Download munkireport-php, download ZIP
    Note: It’s a good idea to read through the setup notes on the site
    Step 2. Rename folder to “report”
    Rename the the expanded folder to whatever you like, I shorten it to “report”
    Step 3. Drop in Munki_repo folder
    To get started quickly drop this folder into your munki repo site folder (which is presumably accessible via the web for client access to Munki).
    rename the munkireport folder
    rename the munkireport folder
    Step 4. Change perms of app/db folder
    Your set up will fail is the app/db folder is not accessible. Make it writable.
    Note: Do not make your site accessible to the outside Internet if you’re not confident in your security model. This is for inside your LAN testing. Be careful and mindful of security concerns. ‘Nough said
    MunkiReport app-db-sqlite
    MunkiReport app-db-sqlite

    If you get this error you haven’t changed the permissions it requires.

    Error
    MunkiReport errors
    Step 5. Rename default_config to config.php
    rename the default config php file
    rename the default config php file
    Step 6. Enable php for apache
    Enable PHP in Apache or other web server service you’re using. Example below is using Server.app
    Enable PHP server.app
    Enable PHP server.app
    Step 7. Create user (and hash)
    Load up your MunkiReport-PHP site and create a user and hash.
    Step 8. Add hash to config.php
    hash-crop
    Step 9. Download MunkiReport.plist using curl
    Download MunkiReport.plist using curl. Note: use an IP address accessible to your Munki clients, i.e. not ‘localhost’
    curl
    Step 10. Add MunkiReport.plist to pkgsinfo
    Add MunkiReport.plist to pkgsinfo
    MunkiReport pkgsinfo
    MunkiReport pkgsinfo
    Step 11. Import in munki repo
    Use munkiimport or MunkiAdmin to import your MunkiReport.plist to Munki
    Step 12. Add to client manifest
    Add MunkiReport.plist to client manifest using Munki Admin or Munki cli tools
    MunkiReport plist installs in MunkiAdmin
    MunkiReport plist installs in MunkiAdmin
    Step 13. Add apps to monitor in config.php
    Use the apps_to_track model. See also Rsaeks blog post.
    MunkiReport apps to track
    MunkiReport apps to track
    Step 14. Login and check your App Versions report
    MunkiReport app versions
    MunkiReport app versions

    Step 15. Explore Munki Report

    MunkiReport-Dashboard
    MunkiReport-Dashboard
  • 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
    curl -O https://munki.googlecode.com/git-history/Munki2/code/client/iconimporter
    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)