Skip to main content

Munki

Deploying WhatPulse Professional with Munki

Munki is an open-source macOS software deployment tool widely used by Mac administrators to install and update applications in enterprise and education environments. It consists of a repository of packages and metadata (pkginfo files), and a client agent (managedsoftwareupdate) that runs on Macs to enforce installations. Deploying WhatPulse Professional via Munki involves importing the WhatPulse installer into your Munki repo, configuring a manifest for target Macs, and ensuring the client picks it up. While Munki handles software distribution, note that it does not manage macOS privacy permissions (PPPC), so you may combine this with an MDM profile for permissions if needed.

Prerequisites​

  • Munki Infrastructure: A functioning Munki repository and clients. You should have the Munki admin tools (e.g., munkiimport, manifestutil, or a UI like MunkiAdmin) and your Macs should be configured to use the Munki repo. Ensure you have appropriate catalogs and manifests set up for your deployment (e.g., a "production" catalog and a manifest that targets all relevant Macs).
  • WhatPulse Installer (.pkg): Download the latest WhatPulse Professional .pkg installer for macOS from the WhatPulse downloads page.
  • Organization ID: Have your WhatPulse organization ID on hand. You'll use this to configure automatic org registration by creating the wp-pro-org-id.txt file on clients.

Deployment Steps​

  1. Import the WhatPulse .pkg into Munki: Use the munkiimport command-line tool or MunkiAdmin to add the package to your repository.
    • If using Terminal, run: munkiimport /path/to/WhatPulse.pkg Munki will prompt for information and create a pkginfo file. During this process, you'll be asked for details:
      • Use an existing pkginfo as a template? (Since this is likely the first WhatPulse import, answer N for new, unless you've imported it before)link1.
      • Enter a display name (e.g., "WhatPulse Professional") and perhaps a description.
      • Category (you might choose "Productivity" or "Monitoring" or create a new category).
      • Developer (e.g., WhatPulse).
      • Version (make sure it reflects the WhatPulse version you're importing).
      • The import will copy the .pkg into Munki's repo (usually into the pkgs folder) and create a .pkginfo in the pkgsinfo directory.
      • When prompted to edit the pkginfo, you can hit N to accept defaults, or Y to open it in a text editor for tweaking.
    • Verify the pkginfo has unattended_install set to true (Munki typically sets this automatically for packages, meaning it will install without user interaction). Also ensure the catalogs array in the pkginfo includes the appropriate catalog (e.g., "production" if you plan to release it directly, or "testing" if you want to test first).
    • After importing, run munkiimport --sync or the MunkiAdmin equivalent to rebuild the repo catalogs so they include the new package.
  2. Include WhatPulse in a Manifest: Next, add the WhatPulse package to the manifest that your target Macs use:
    • If you have a "site_default" or general manifest for all machines, you can add WhatPulse to it. Using the command-line manifestutil tool, for example: manifestutil --add-pkg WhatPulse --manifest site_default (Replace "WhatPulse" with the exact name/id of the pkginfo, and "site_default" with the name of your manifest). This will add the WhatPulse pkg to that manifest's managed installs.
    • Alternatively, open your manifest in MunkiAdmin and add "WhatPulse Professional" (or whatever the pkginfo is titled) to the managed_installs list.
    • Ensure the manifest references the correct catalog where the pkg was added (e.g., if the pkginfo is in the "testing" catalog, use that for test machines, then promote to "production" when ready).
    • Save the manifest changes. Now the Munki repo knows that target Macs should install WhatPulse.
  3. Automatic Org Activation (Org ID file): To have each client automatically register in the WhatPulse dashboard, we need to deploy the wp-pro-org-id.txt file to the client machines:
    • Option A: Include in the Package – If you built a custom .pkg, you could bake the org ID file into it (for instance, by adding a postinstall script in the package that writes the org ID). A postinstall script line like: echo "<Your Organization ID>" > "/Applications/WhatPulse/wp-pro-org-id.txt" would create the file during installation. This way, as soon as the package installs via Munki, the org file is in place. Make sure to replace <Your Organization ID> with your actual organization identifier (name or numeric ID).
    • Option B: Deploy via Munki as a script ("nopkg") – Munki can run scripts using a "nopkg" pkginfo item. You can create a shell script that echoes your org ID to the file path and have Munki push it:
      • Write a simple script (e.g., create_wp_org_id.sh) that contains:
#!/bin/bash
/bin/echo "<Your Organization ID>" > "/Applications/WhatPulse/wp-pro-org-id.txt"

(Include any logic like checking the directory exists; the above will create the file regardless. Munki runs as root so it will have permission.)

  • Use munkiimport to import this script as a package-less item: munkiimport --nopkg create_wp_org_id.sh --name "WhatPulse Org ID" and provide metadata (this will create a pkginfo that just runs the script).
  • In the pkginfo, ensure installcheck_script or preinstall_script as needed so it only runs if the file isn't already present. Also add a requires key in this pkginfo pointing to the WhatPulse package, so that Munki installs WhatPulse first. For example, "requires": ["WhatPulse Professional"] in the org-id pkginfo.
  • Add this "WhatPulse Org ID" item to the same manifest (after WhatPulse) or include it in the manifest's managed_installs as well. The requires relationship will make sure Munki applies them in order.

With either approach, the goal is that by the time WhatPulse launches on a client Mac, /Applications/WhatPulse/wp-pro-org-id.txt exists and contains your org info. The WhatPulse app will then automatically show up in your org's Pending Computers list without user input.

  1. (Optional) Deploy Default Settings: If you want to provide a settings-overrides.ini to preset certain preferences (for example, turning off the startup welcome window or enabling specific logging), you can deploy it via Munki similarly:
    • Option A: Include the settings-overrides.ini in your custom .pkg build (place it in /Applications/WhatPulse/ during packaging).
    • Option B: Create another script or package that drops this file on the client. For instance, a script that uses cat to write the desired INI content to /Applications/WhatPulse/settings-overrides.ini. Import and deploy that through Munki (possibly in the same nopkg script as the org ID, or a separate one).
    • Ensure any overrides file is in place before the WhatPulse app is first launched, otherwise default settings might already be applied. Having Munki install it on first run ensures the next launch uses those settings.
  2. Trigger Installation: Munki will install the software at the next client check-in. By default, the Munki client checks every hour (or at a schedule you set). If you want to expedite testing:
    • On a target Mac, run /usr/local/munki/managedsoftwareupdate (this will check for updates and print available installs) followed by /usr/local/munki/managedsoftwareupdate --installonly to immediately install pending items. Alternatively, run the Managed Software Center app and initiate the installation from the Updates/Updates tab (if not unattended).
    • Because we set it as unattended, the user should not need to take any action; Munki will install WhatPulse in the background on its next regular run.
  3. Verification:
    • On Client Macs: After Munki runs, verify that WhatPulse is now in the Applications folder on the target Macs. You can check /Applications/WhatPulse.app existence or use Munki's logs (/Library/Managed Installs/Logs/ManagedSoftwareUpdate.log) which will indicate the installation was successful (look for "Installing WhatPulse…" and "Installation of WhatPulse complete" lines).
    • If the org ID deployment was successful, check that /Applications/WhatPulse/wp-pro-org-id.txt exists on the client and contains the correct org text.
    • Launch WhatPulse on one of the Macs (or reboot/login if it's set to auto-launch at login). On first launch, without a PPPC profile, macOS will prompt the user to grant Accessibility and Input Monitoring permissions. These must be allowed for WhatPulse to function. In an enterprise, you'll likely want an MDM profile to grant these permissions silently, since Munki itself cannot do that. If you did deploy a profile via another tool, verify that WhatPulse launches without prompting and that in System Settings > Privacy & Security, WhatPulse is already allowed for the required items.
    • Munki Reporting: If you use MunkiReport or another monitoring, verify that the software is listed as installed. The Munki client will also report installation status back to your Munki repo (if you examine the manifest's "Managed installs" on that client, WhatPulse should now appear as installed).
    • WhatPulse Dashboard: Log in to the WhatPulse Professional web dashboard and navigate to your organization's Computers section. All the Macs that installed WhatPulse and received the org ID file should show up as Pending Computers ready for activation. This confirms that each client has successfully linked to the org. Once you (or an admin) activate them and assign users, the clients will start collecting and sending data.
    • Troubleshooting: If a client did not show up, check that the org ID file was created properly (typo in ID, or file placed incorrectly). You can also ensure the Munki pkginfo didn't mark the install as failed. Rerun managedsoftwareupdate with verbose output if needed. For permission issues, verify any config profiles.

By leveraging Munki's automation, you can deploy WhatPulse Pro to many Macs efficiently. Munki will handle downloading and installing the app quietly in the background. Remember that Munki doesn't handle system settings like security permissions, so use an MDM in tandem for a fully seamless deployment (or instruct users to approve permissions on first run). After this setup, any new Mac added to the Munki manifest will automatically get WhatPulse at the next run, streamlining onboarding for your organization.

  1. https://helpx.adobe.com/enterprise/kb/deploy-packages-using-munki.html↩