Munki issues do not display the package/app name if using SimpleMDM's Munki

[noahtalerman]

Fleet version: 4.20.1

This was observed in Fleet's internal dogfood instance.

At Fleet, we use the Munki included in SimpleMDM to manage applications on our macOS workstations.

---

🧑‍💻  Expected behavior

On the Home > macOS > Munki > Issues card I expect to see the package/app name in the issue's message. For example "Figma."

This way, I know which package is causing issues.

💥  Actual behavior

I see what looks like a random string, RmlnbWEaa, in the place of the package/app name.

Potential solutions

1. Update the munki_installs table (from macadmins extension) to pull in the display_name: https://github.com/macadmins/osquery-extension/blob/06cc1370c0ead1891987927fcfcbb208481d90e0/tables/munki/munki.go#L100-L105

• This way, Fleet can insert display_name in Munki issues if it exists. If it doesn't exist, fall back to name.
• UPDATE: This PR in the macadmins/osquery-entension repo adds a display_name column to the munki_installs table: https://github.com/macadmins/osquery-extension/pull/22

2. Update Munki itself to use the display_name in warning/error logs. This way Fleet just has to query the munki_info table to display Munki issues.

More info

Currently, the warnings and errors columns in the munki_info table (macadmins osquery extension) is used to gather data for Munki issues: https://github.com/macadmins/osquery-extension/blob/main/tables/munki/munki.go#L35

Here's a snippet from the host's (that logged the warning in the above screenshot) Munki manifest:

<dict>
      <key>autoremove</key>
      <false/>
      <key>category</key>
      <string>Design</string>
      <key>description</key>
      <string>Design, prototype, and gather feedback all in one place with Figma.</string>
      <key>developer</key>
      <string>Figma</string>
      <key>installer_item_hash</key>
   <string>41eb66ed2b1c20368ece91a5a7c08edb39a73401ac698fc8b5a02dc3cd9759f0</string>
      <key>installer_item_location</key>
      <string>apps/Figma/Figma-116.3.8.dmg</string>
      <key>installer_item_size</key>
      <integer>88829</integer>
      <key>installer_type</key>
      <string>copy_from_dmg</string>
      <key>installs</key>
      <array>
        <dict>
          <key>CFBundleIdentifier</key>
          <string>com.figma.Desktop</string>
          <key>CFBundleName</key>
          <string>Figma</string>
          <key>CFBundleShortVersionString</key>
          <string>116.3.8</string>
          <key>CFBundleVersion</key>
          <string>116.3.8</string>
          <key>minosversion</key>
          <string>10.12.0</string>
          <key>path</key>
          <string>/Applications/Figma.app</string>
          <key>type</key>
          <string>application</string>
          <key>version_comparison_key</key>
          <string>CFBundleShortVersionString</string>
        </dict>
      </array>
      <key>items_to_copy</key>
      <array>
        <dict>
          <key>destination_path</key>
          <string>/Applications</string>
          <key>source_item</key>
          <string>Figma.app</string>
        </dict>
      </array>
      <key>minimum_os_version</key>
      <string>10.12.0</string>
      <key>supported_architectures</key>
      <array>
        <string>arm64</string>
      </array>
      <key>unattended_install</key>
      <true/>
      <key>uninstall_method</key>
      <string>remove_copied_items</string>
      <key>uninstallable</key>
      <true/>
      <key>version</key>
      <string>116.3.8</string>
      <key>name</key>
      <string>RmlnbWEaa</string>
      <key>display_name</key>
      <string>Figma</string>
      <key>catalogs</key>
      <array>
        <string>default</string>
      </array>
      <key>PackageCompleteURL</key>
      <string>https://a.simplemdm.com/munki/client/apps/502034/Figma-116.3.8.dmg</string>
      <key>icon_name</key>
      <string>502034.png</string>
    </dict>

See RmlnbWEaa below name towards the bottom. Also see Figma below display_name.

More discussion on this issue in Slack (internal) here: https://fleetdm.slack.com/archives/C03PK8PJDDE/p1663790497027649

[noahtalerman]

@zwass I assigned you this bug and added it to the release board.

[sharvilshah]

I haven't dug into this at all, so please don't mind me -- but I noticed that RmlnbWEaa mentioned above is base64 encoded -- which just decodes to Figma

[lucasmrod]

@sharvilshah Oh good catch!

Linking the PR that adds the display_name column to munki_installs: https://github.com/macadmins/osquery-extension/pull/22

[noahtalerman]

RmlnbWEaa mentioned above is base64 encoded -- which just decodes to Figma

Linking the PR that adds the display_name column to munki_installs: https://github.com/macadmins/osquery-extension/pull/22

Nice! Great suggestions/work. Awesome that we can move quickly.

After Lucas's PR is merged, it looks like we’ll need to adjust the query Fleet uses to address this issue in Fleet.

Or, we can move quickly and decode the string (only requires Fleet changes): https://github.com/fleetdm/fleet/issues/7895#issuecomment-1255116870

[noahtalerman]

Or, we can move quickly and decode the string (only requires Fleet changes): https://github.com/fleetdm/fleet/issues/7895#issuecomment-1255116870

Lucas: Sounds hacky, because the base64 thing is a SimpleMDM specific thing

[lucasmrod]

Or, we can move quickly and decode the string (only requires Fleet changes): https://github.com/fleetdm/fleet/issues/7895#issuecomment-1255116870

Sounds hacky, because the base64 encoding of the Munki package name is a specific to SimpleMDM integration with Munki.

Once (if) https://github.com/macadmins/osquery-extension/pull/22 is approved and merged, then the user can munki_installs table to know which is the application having issues shown in the logs.

[noahtalerman]

the user can munki_installs table to know which is the application having issues shown in the logs.

@lucasmrod can Fleet do this for the user? We'd like the Fleet UI/API to just show the name of the package/application.

[lucasmrod]

can Fleet do this for the user? We'd like the Fleet UI/API to just show the name of the package/application.

Show where? (maybe am missing some recently added functionality).

the user can munki_installs table to know which is the application having issues shown in the logs.

Typo here sorry. What I meant is that for this particular issue, the user can run a live query SELECT * FROM munki_installs to know which application is the one with name == RmlnbWEaa (once https://github.com/macadmins/osquery-extension/pull/22 is merged and updated in Orbit).

[noahtalerman]

Show where?

@lucasmrod we'd like to show the package name here the Home > macOS > Munki > Issues card (released in 4.20):

[lucasmrod]

can Fleet do this for the user? We'd like the Fleet UI/API to just show the name of the package/application.

The Issue is an error log read from /Library/Managed\ Installs/ManagedInstallReport.plist read by munki's osquery-extension, here's an excerpt from mine:

        <key>RemovalResults</key>
        <array/>
        <key>RemovedItems</key>
        <array/>
        <key>RunType</key>
        <string>auto</string>
        <key>StartTime</key>
        <string>2022-09-22 20:22:42 +0000</string>
        <key>Warnings</key>
        <array>
                <string>Could not process item RmlnbWEaa for optional install. No pkginfo found in catalogs: default</string>
        </array>
        <key>managed_installs_list</key>
        <array>
                <string>R29vZ2xlIENocm9tZQaaa</string>
                <string>Lk5lc3N1c0FnZW50a</string>
                <string>TnVkZ2Uaa</string>
                <string>TnVkZ2VfTGF1bmNoQWdlbnQaa</string>
                <string>RG9ja2Vya</string>
                <string>U3BvdGlmeQaaa</string>
                <string>Wm9vbQaaa</string>
                <string>TWljcm9zb2Z0IFZpc3VhbCBTdHVkaW8gQ29kZQaaa</string>
                <string>aVRlcm0ya</string>
                <string>QVdTX1ZQTl9DbGllbnQaa</string>
        </array>
        <key>managed_uninstalls_list</key>
        <array/>
        <key>managed_updates_list</key>
        <array/>

From Fleet, we really shouldn't process such warning logs, as it depends on how the Munki app logs and may change in between versions.

--

Alternative: Fleet could in principle ingest the munki_installs table (which does contain a list of munki installations in the host) and we could introduce a third tab (Issues, Versions, Installs)

[zwass]

I'm asking in macadmins slack #munki channel about whether this is some kind of standard with the base64: https://macadmins.slack.com/archives/C04QVPFGU/p1664489640209459

I also wonder whether we could change Munki to output the display_name rather than the name? But I guess it all depends on what is standard for Munki.

[zwass]

I'm skeptical that it will be worth our effort to continue pursuing this.

It was confirmed that the base64 name is a SimpleMDM Munki thing (it is possible that other deployments do similar). display_name turns out to be optional, so we couldn't always rely on that being there. Seems like we would have to essentially special-case the SimpleMDM issue and try to parse it out of these unstructured warning strings.

I would be very interested to see if there are similar issues encountered by our customers who use their own Munki deployments and then try to fix those cases.

[noahtalerman]

I'm skeptical that it will be worth our effort to continue pursuing this.

@zhumo I passed this issue to you. Zach's proposed solution is above.

@zwass FYI I did this as per the Reproduced step in the new bug process: https://fleetdm.com/handbook/quality#reproduced

[zhumo]

Zach -- let's discuss at our Agent EM/PM meeting.

[zhumo]

Per the handbook, I reassigned Zach and put the release board on. We'll keep it labeled as reproduced, until we have some resolution.

[zwass]

I think we should reclassify this from "bug" to "feature request". The request being to do translation of SimpleMDM's application names in Munki error logs.

I would advise low priority because I don't think any of our customers use SimpleMDM.

I'll leave the labels as-is, but I think we should remove the bug label and take it off the release board.