Warnings for items not installed based on conditional

[Rod Christiansen]

I have many profiles and packages that have conditional install keys such as machine_type == “desktop”. Many items are rejected for install based on this or similar conditions, but munki spills out a warning for all machines that don’t fit a certain criteria. Moving that to munki report all or almost all of my machines have warnings, but these warnings are by design, so warnings end up not meaning anything — cry wolf scenario as I'll likely miss true warnings. Is there more granularity I can add to the setup?

[Gregory Neagle]

This sounds like you are using installable_condition items in your pkginfo files.

If so, you might consider using conditional_items in manifests to avoid warnings.

If an item is in managed_installs, you are telling Munki it must be installed. If Munki can’t find an item with acceptable condition to install, it warns you that you told it Foo needed to be installed, yet it could find no installable version.

conditional_items avoids this issue: if a condition is not met, it doesn’t exist in the items to be installed (or whatever)— therefore Munki doesn’t even try to install it.

-Greg

[Erik Gomez]

This was resolved in Slack. Sorry Greg.

Sent from my iPhone

> --
> Find related discussion groups here:
> https://github.com/munki/munki/wiki/Discussion-Group
> ---
> You received this message because you are subscribed to the Google Groups "munki-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
> To post to this group, send email to munk...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Gregory Neagle]

Ah, but I think this location is more searchable and of value to others now and in the future.

Sent from my iPhone

[Mike Solin]

Yeah, I’ve just learned to ignore the “warnings” section altogether. It’s mostly stuff I, as the admin, intended - such as minimum_os_version and maximum_os_version. Unfortunately, we have a wide range of OS versions on campus, so every machine will report about software that wasn’t installed or offered as optional due to OS compatibility.

Using conditional_items as a replacement for pkginfo keys wouldn’t work quite as well, so I’ve resigned myself to the fact that there will always be a high amount of warnings. I’m trying to lower the error count, instead.

Mike

--

mi...@mikesolin.com / @flammable
http://mikesolin.com

[Gregory Neagle]

> On Sep 1, 2015, at 9:04 PM, Mike Solin <mi...@mikesolin.com> wrote:
>
> Yeah, I’ve just learned to ignore the “warnings” section altogether. It’s mostly stuff I, as the admin, intended - such as minimum_os_version and maximum_os_version. Unfortunately, we have a wide range of OS versions on campus, so every machine will report about software that wasn’t installed or offered as optional due to OS compatibility.
>
> Using conditional_items as a replacement for pkginfo keys wouldn’t work quite as well,

Why?

[Mike Solin]

Here’s an example. It’s a weird one, I know, but I’m not making any of this up.

Using createOSXinstallPkg, I made a 10.10.5 installer and imported it into Munki. With a modified version of Hannes Juutilainen’s admin provided condition,

https://github.com/hjuutilainen/adminscripts/blob/master/check-yosemite-compatibility.py

we’ve limited Yosemite upgrades to OS X 10.7 and above, even though Apple supports upgrading from OS X 10.6 and above (this decision was reached after much back-and-forth with other IT groups on campus). The thinking is that machines running 10.6 should be reimaged or retired, not upgraded. It’s in one of our widely-used manifests as an optional_install with the condition of yosemite_supported = true (our version of Hannes’s script checks for 10.7+, RAM amount, etc.).

However, as the admin, I appreciate having the option of being able to put the 10.10.5 upgrade installer in any manifest as a managed_install and upgrading the machine, if necessary. It’s happened a couple of times. Thus, the pkginfo keys are set to 10.6.8 as the minimum_os_version, and 10.9.99 as the maximum_os_version.

If I had used the pkginfo keys to limit the OS X installer to 10.7 and above, it would not install on 10.6.8 machines even when explicitly putting it in the machine’s manifest. If I had relied solely on the conditional_items, I’d run the risk of a 10.5.0 machine running the Yosemite upgrade installer and failing horribly (yes, unfortunately there are 10.5.0 machines on campus) if it were put directly in a computer’s manifest that didn’t meet the system requirements.

Also, if the installer had to be temporarily removed from a manifest for some reason (this goes for anything in Munki!), I’d have to remember the OS requirements when putting it back in a manifest, so I could set the conditional_item correctly. We have several manifests used by different groups of computers on campus - I’d prefer to set something as important as the minimum OS version for a pkg in a single place.

To be clear, I like conditional_items! I combined a bunch of separate manifests tonight that were initially separated for things like laptops/desktops, now that I understand I can utilize conditional_items instead. But in our environment, it’s not possible to be completely free of warnings.

It’d be nice if the minimum_os_version and maximum_os_version warnings could be considered something else, like “informational”, so I could take the “warnings” header in MunkiReport as seriously as I do the "errors" header. Or, if it were hidden behind a certain level of verbosity.

Mike

--

mi...@mikesolin.com / @flammable
http://mikesolin.com

[Gregory Neagle]

On Sep 1, 2015, at 10:27 PM, Mike Solin <mi...@MIKESOLIN.COM> wrote:

It’d be nice if the minimum_os_version and maximum_os_version warnings could be considered something else, like “informational”, so I could take the “warnings” header in MunkiReport as seriously as I do the "errors" header.  Or, if it were hidden behind a certain level of verbosity.

That strikes me as more of a problem to be solved by MunkiReport or some other layer: categorizing warnings and errors by level of importance. Munki itself has two levels: warnings and errors.

In your example, Munki is telling you “hey, boss, you told me I was supposed to make sure this machine has Yosemite installed, but I can’t find anything that allows me to do that”. Only you can tell if that’s an important issue that needs to be addressed, or if it’s something that can be ignored.

conditional_items allow you to provide more info to Munki.

Keys on a pkginfo can only tell Munki “you can’t install this specific version of Foo, but there might be some other version you can install”.

Manifests tell Munki what to install.

Pkginfo items give Munki information about a particular installer item.

-Greg

[A.E. van Bochoven]

I would not like to change the default behaviour, I rely on the warnings to tell me I have something misconfigured. Of course I see warnings I don't care about, but I'm afraid that comes with the job.

I would think that your problem could be fixed with a included manifest that contains the condition and the pkg if that fits in your workflow.

-Arjen

[Dominic Carmelo Ridolfo]

Sounds like you’re not using munki’s full feature set to your advantage.

There are a few ways this particular scenario could be handled. A few that jump to mind off the top of my head:

1,) Set Yosemite as an optional install (with different conditions) so that it is available for ad hoc deployment.
2,) Create multiple manifests with different conditions. Then assign or nest the manifests so that a particular machine picks up Yosemeite.
3,) Create an additional pkginfo item pointing to the same payload, but with different conditionals and/or install checks.

You could also combine the above as well - two pkginfos with different conditionals (minor version < 10, OS version ≥ 10.6.8 ) pointing to the same payload and within separate, nested manifests. To give an idea of how this can add color to munki’s decision making tree, we do this for troublesome print drivers, which install different payloads depending on the host machine’s OS version. The end result is that the drivers are installed if a machine is added to particular department, reinstalled when the machine is updated to a newer OS and removed if the machine is moved to a branch office. This was done with a single installer, a couple pkginfos, a handful of manifests and some pre-post install scripts - but all without manual intervention.

By trying to make every decision within the pkgs info, you’re limiting yourself to a fraction of decisions processing munki offers.

Oversimplified, of course, but I tend to view the decision hierarchy as follows:
- Catalog = basic dumb decision making. Everything is black and white.
- Pkgsinfo = slightly more advanced decision making. Greyscale.
- Manifests = fine tuned decision making. Full color spectrum.

Often, I use pkginfos features as a fail-safe measure, to ensure payloads do not break the client machines; and try to do the rest with the features that manifests offer.

Hope this was helpful.

best,
dominic

[Rod Christiansen]

Thanks Greg, Erik, Arjen, Demonic,

I switched all my installable_condition items to conditional_items inside manifests and warnings have dissipated. The warnings I have are valid warnings that I can work at and manage.

Mike,

Conditional_items are really powerful in how granular you can get, up to the serial number. You can certainly change your Yosemite install with conditions. Use booleans 'AND' 'OR' 'NOT' and you'll be able to come up with a logic that won't produce unnecessary warnings.

[Mike Solin]

Thanks, guys.  While this stuff makes sense, I’m still really hesitant to set data like minimum_os_version in two places: pkginfos and manifests.  I’m concerned that would lead to unintended behavior due to human error.

Long-term, the real solution is to upgrade everything to the latest OS - then, I wouldn’t need to keep legacy pkgs in the Munki repo.  That would cut down on warnings, so I’m working towards that.

Mike

-- 

mi...@mikesolin.com / @flammable
http://mikesolin.com

[Shane Pinnell]

Great info! Thanks! This cleared up the errors for me as well. I had no idea that manifests could be used like this. Munki is such a cool tool!

[bryanzak]

If you don't want to have version info in two places (pkgsinfo and manifest conditionals) then you could always create "fake"pkgsinfo files. Basically nopkg plists that just "install" a breadcrumb file for use in the installs array. The idea is these fake plists "install" on the the unsupported OS versions and eliminate any warnings. But the "install" is just the breadcrumb file.

Here's an example of a plist for an app we have called BigBrainz that does not run on 10.5.8. Yes, yes. we actually have some 10.5.8 machines still...53....don't ask me why, they're not at schools I'm responsible for :( 

But this approach can be used for any app, it's a way to have all version related info just in pkgsinfo

apps/BigBrainz/BigBrainzOSUnsupported-1.0.plist

<?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">

<plist version="1.0">

<dict>

<key>autoremove</key>

<false/>

<key>catalogs</key>

<array>

  <string>production</string>

</array>

             <key>description</key>

<string>BigBrainz *** unsupported on Mac OS X 10.5.8 Leopard ***</string>

             <key>display_name</key>

<string>BigBrainz 10.5.8 Unsupported</string>

<key>installer_type</key>

<string>nopkg</string>

<key>name</key>

<string>BigBrainz</string>

<key>minimum_os_version</key>

<string>10.5.0</string>

<key>maximum_os_version</key>

<string>10.5.8</string>

<key>unattended_install</key>

<true/> 

<key>unattended_uninstall</key>

<true/> 

<key>uninstallable</key>

<true/>

<key>uninstall_method</key>

<string>uninstall_script</string>

<key>version</key>

<string>1.0</string>

<key>installs</key>

<array>

<dict>

<key>path</key>

<string>/Library/Application Support/OPS/.OSX1058-bigbrainz</string>

<key>type</key>

<string>file</string>

</dict>

</array>

<key>postinstall_script</key>

<string>#!/bin/bash

mkdir -p "/Library/Application Support/OPS"

touch    "/Library/Application Support/OPS/.OSX1058-bigbrainz"

</string>

    <key>uninstall_script</key>

<string>#!/bin/bash

rm -f "/Library/Application Support/OPS/.OSX1058-bigbrainz"

</string>

</dict>

</plist>