supported_architecture not evaluated for uninstalls

[ericholtam]

I have a software install that has both an x86_64 architecture and arm architecture import into Munki with the same name. The install properly detects the architecture and installs the right agent, but when it comes to uninstalling the architecture is not evaluated. Instead, it is using a different uninstall_script than the one in its own pkginfo. At minimum, an uninstall script from a different pkginfo should not be used.

When the item is added as a managed_install to the manifest, it is detected properly as seen I the managedsoftwareupdate log output:

    * Processing manifest item Rapid7 for install
    Looking for detail for: Rapid7, version latest...
    Considering 2 items with name Rapid7 from catalog production
    Considering item Rapid7, version 3.1.6.42.1 with minimum os version required 10.5.0
    Our OS version is 10.15.7
    Considering item Rapid7, version 3.1.6.42.1 with supported architectures: (
    arm64
)
    Our architecture is x86_64
    Considering item Rapid7, version 3.1.6.42.1 with minimum os version required 10.5.0
    Our OS version is 10.15.7
    Considering item Rapid7, version 3.1.6.42.1 with supported architectures: (
    "x86_64"
)
    Our architecture is x86_64
    Found Rapid7, version 3.1.6.42.1 in catalog production
    Looking for package com.dotdashmeredith.pkg.rapid7-install-mac-intel, version 3.1.6.42.1
        This package is not currently installed.
    Need to install Rapid7
    Download base URL is: https://munkiserver/pkgs/
    Package name is: rapid7-install-mac-intel-3.1.6.42.1.pkg
    Download URL is: https://munkiserver/pkgs/management/rapid7/rapid7-install-mac-intel-3.1.6.42.1.pkg
    Downloading to: /Library/Managed Installs/Cache/rapid7-install-mac-intel-3.1.6.42.1.pkg
    Downloading rapid7-install-mac-intel-3.1.6.42.1.pkg from management/rapid7/rapid7-install-mac-intel-3.1.6.42.1.pkg
    Downloading rapid7-install-mac-intel-3.1.6.42.1.pkg from management/rapid7/rapid7-install-mac-intel-3.1.6.42.1.pkg
    autoremove = 0;
    catalogs =     (
        production
    );
    category = Management;
    description = "At Rapid7, we believe in simplifying the complex through shared visibility, analytics, and automation that unite your teams around challenges and successes of cybersecurity.";
    developer = Rapid7;
    "display_name" = "Rapid 7";
    "installed_size" = 37045;
    "installer_item_hash" = 1cd2b0e4001bb69f947f4e47a7d1a45a22e9b6ad6ef794483e54da5e3bea7341;
    "installer_item_location" = "management/rapid7/rapid7-install-mac-intel-3.1.6.42.1.pkg";
    "installer_item_size" = 36910;
    "minimum_os_version" = "10.5.0";
    name = Rapid7;
    "postuninstall_script" = "#!/bin/bash\nif [ -d /opt/rapid7 ]\nthen\n\trm -r /opt/rapid7\nfi\n\nif [ -d /Library/Management/rapid7 ]\nthen\n\trm -r /Library/Management/rapid7\nfi\n\npkgutil --forget com.dotdashmeredith.pkg.rapid7-install-mac-intel\n\nexit 0\n\t";
    receipts =     (
                {
            "installed_size" = 37045;
            packageid = "com.dotdashmeredith.pkg.rapid7-install-mac-intel";
            version = "3.1.6.42.1";
        }
    );
    "supported_architectures" =     (
        "x86_64"
    );
    "unattended_install" = 1;
    "unattended_uninstall" = 1;
    "uninstall_method" = "uninstall_script";
    "uninstall_script" = "#!/bin/bash\nUNINSTALLER=\"/Library/Management/rapid7/agent_installer-x86_64.sh\"\n\nif [ -x \"${UNINSTALLER}\" ]\nthen\n\t\"${UNINSTALLER}\" uninstall\nfi\n\t";
    uninstallable = 1;
    version = "3.1.6.42.1";
}}
    URLSession_task_didReceiveChallenge_completionHandler_
    Authentication challenge for Host: munkiserver Realm: None AuthMethod: NSURLAuthenticationMethodServerTrust
    Allowing OS to handle authentication request
    Downloading rapid7-install-mac-intel-3.1.6.42.1.pkg...
    0..20..40..60..80..100
    Status: 200
    Verifying package integrity...
    rapid7-install-mac-intel-3.1.6.42.1.pkg downloaded at 18455 KB/s
    Looking for updates for: Rapid7
    Looking for updates for: Rapid7-3.1.6.42.1
    Looking for updates for: Rapid7--3.1.6.42.1

After letting the software install and moving the item to a manage_uninstall in the manifest, the managedsoftwareupdate logs don't reference the architecture at all during uninstall evaluation:

 * Processing manifest item Rapid7 for removal
    Looking for all items matching: Rapid7...
    Adding item Rapid7, version 3.1.6.42.1 from catalog production...
    Adding item Rapid7, version 3.1.6.42.1 from catalog production...
    Considering item Rapid7-3.1.6.42.1 for removal info
    Checking receipts...
    Looking for updates for: Rapid7
    Looking for updates for: Rapid7-3.1.6.42.1
    Looking for updates for: Rapid7--3.1.6.42.1
    Removal of Rapid7 added to ManagedInstaller tasks.

And in the /Library/Managed Installs/InstallInfo.plist we can see that the uninstall_script is not referencing the same file or pkg receipt as seen in the log output when the product was detected for install above.

    <key>removals</key>
    <array>
        <dict>
            <key>category</key>
            <string>Management</string>
            <key>description</key>
            <string>Will be removed.</string>
            <key>developer</key>
            <string>Rapid7</string>
            <key>display_name</key>
            <string>Rapid 7</string>
            <key>installed</key>
            <true/>
            <key>installed_version</key>
            <string>3.1.6.42.1</string>
            <key>name</key>
            <string>Rapid7</string>
            <key>postuninstall_script</key>
            <string>#!/bin/bash
if [ -d /opt/rapid7 ]
then
    rm -r /opt/rapid7
fi
if [ -d /Library/Management/rapid7 ]
then
    rm -r /Library/Management/rapid7
fi
pkgutil --forget com.dotdashmeredith.pkg.rapid7-install-mac-arm
exit 0
    </string>
            <key>unattended_uninstall</key>
            <true/>
            <key>uninstall_method</key>
            <string>uninstall_script</string>
            <key>uninstall_script</key>
            <string>#!/bin/bash
UNINSTALLER="/Library/Management/rapid7/agent_installer-arm64.sh"
if [ -x "${UNINSTALLER}" ]
then
    "${UNINSTALLER}" uninstall
fi
    </string>
        </dict>
    </array>

[gregneagle]

This is a bit trickier than it might sound at first pass.

Filters or conditions on install are designed to make sure the correct version is installed based on what OS version is running or what processor architecture is available. But uninstalls are different -- we have to uninstall what is actually present, which may or may not match the version Munki would install if asked to.

Examples:
Machine was running macOS 10.15 and Foo v1 was installed. Foo v2 is released, and requires macOS 12.
Machine is upgraded to macOS 12, and at the same time, Foo is moved to managed_installs.

Machine is now running macOS 12, but still has Foo v1 installed. What if the uninstall process for Foo v2 won't properly uninstall Foo v1? We need to uninstall what's actually currently installed and not just use the uninstall info from the "latest" version of the item.

The same concept can apply to supported_architectures.

Bar 2.5 is available only as an Intel binary (or perhaps you've added only the Intel version to your Munki repo). You install it on your fleet, which includes Apple silicon machines.
Later the vendor releases an Apple silicon build of Bar 2.5, and you import it into Munki. Since it's the same version, it's likely that Apple silicon machines will still just have the Intel version of Bar 2.5.
Now you decide to remove it from one or more Apple silicon machines. If the uninstall is different between Intel and Apple silicon, using the uninstall method for the Apple silicon version would be the wrong thing to do here, since the Intel version is actually installed. Again: we need to uninstall what's actually currently installed and not just use the uninstall info from whatever version we'd choose to install if this were a managed_install.

I do not disagree that processor architecture should be considered here: but it's not as simple as it might seem at first glance.

[ericholtam]

Thanks for your time and thought on this matter. I understand the scenarios and the complexities they present. I would, however, consider those examples "admin created" situations where the implementation could be modified using existing Munki behaviors to address uninstalling at a different time in regard to the OS update, or manipulating installcheck/preinstall scripts in the pkginfo for a newly released Apple Silicon-specific version to address those complexities. The issue I'm referring to is an internal issue where a script from a pkginfo was used on a machine that the pkginfo was never intended to be used on because it has a supported_architecture array set. For example, the scenario could be that a vendor has a specific uninstall method/script for intel that destroys data in a spot that it should not be destroyed on an Apple Silicon installation. If one uninstallscript is used for both platforms, that could lead to unexpected, or detrimental, consequences. One _could_ argue that knowing how the uninstall currently behaves, the situation can be, and I have, admin mitigated by creating an uninstall_script that detects platform at run time and acts accordingly. But, based on the intuitive model that the install process uses, it's not clear that the uninstall process behaves differently. I don't downplay the considerations that have to be made for it to be addressed, but just pointing out they are distinct types of issues - admin based vs code based.

…

On Fri, Aug 5, 2022 at 4:01 PM Greg Neagle ***@***.***> wrote: This is a bit trickier than it might sound at first pass. Filters or conditions on *install* are designed to make sure the correct version is installed based on what OS version is running or what processor architecture is available. But uninstalls are different. Examples: Machine was running macOS 10.15 and Foo v1 was installed. Foo v2 is released, and requires macOS 12. Machine is upgraded to macOS 12, and at the same time, Foo is moved to managed_installs. Machine is now running macOS 12, but still has Foo v1 installed. What if the uninstall process for Foo v2 won't properly uninstall Foo v1? We need to uninstall what's actually currently installed and not just use the uninstall info from the "latest" version of the item. The same concept can apply to supported_architectures. Bar 2.5 is available only as an Intel binary (or perhaps you've added only the Intel version to your Munki repo). You install it on your fleet, which includes Apple silicon machines. Later the vendor releases an Apple silicon build of Bar 2.5, and you import it into Munki. Since it's the same version, it's likely that Apple silicon machines will still just have the Intel version of Bar 2.5. Now you decide to remove it from one or more Apple silicon machines. If the uninstall is different between Intel and Apple silicon, using the uninstall method for the Apple silicon version would be the wrong thing to do here, since the Intel version is actually installed. Again: we need to uninstall what's actually currently installed and not just use the uninstall info from whatever version we'd choose to install if this were a managed_install. I do not disagree that processor architecture should be considered here: but it's not as simple as it might seem at first glance. — Reply to this email directly, view it on GitHub <#1149 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/APR4CRVKVYGO7VSVKOIBYJLVXV6KXANCNFSM54W2IQPQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>