Cleaning OktaVerify cache after each run

[agburch]

We occasionally see autopkg fails due to permissions issues overwriting the OktaVerify.app file left in the cache from previous runs. This PR adds a step to delete the unpackaged app after each run to avoid this issue.

[nstrauss]

Hi @agburch. Can you share sanitized logs to help debug when this is occurring? Since we use autopkg in CI with ephemeral runners this never comes up for us. Want to see if there's another potential fix before adding more processors to the recipe. Thanks.

[agburch]

Sure thing! This is what we were seeing in the autopkg logs

        Error in local.munki.OktaVerify: Processor: PkgPayloadUnpacker: Error: extraction of /Users/autotime/Library/AutoPkg/Cache/local.munki.OktaVerify/unpack/Payload with aa failed
            Traceback (most recent call last):
              File "/Library/AutoPkg/autopkglib/__init__.py", line 840, in process
                self.env = processor.process()
              File "/Library/AutoPkg/autopkglib/__init__.py", line 626, in process
                self.main()
              File "/Library/AutoPkg/autopkglib/PkgPayloadUnpacker.py", line 129, in main
                self.unpack_pkg_payload()
              File "/Library/AutoPkg/autopkglib/PkgPayloadUnpacker.py", line 122, in unpack_pkg_payload
                raise ProcessorError(error)
            autopkglib.ProcessorError: extraction of /Users/autotime/Library/AutoPkg/Cache/local.munki.OktaVerify/unpack/Payload with aa failed

            The above exception was the direct cause of the following exception:

            Traceback (most recent call last):
              File "/usr/local/bin/autopkg", line 2278, in run_recipes
                autopackager.process(recipe)
              File "/Library/AutoPkg/autopkglib/__init__.py", line 852, in process
                raise AutoPackagerError(
            autopkglib.AutoPackagerError: Error in local.munki.OktaVerify: Processor: PkgPayloadUnpacker: Error: extraction of /Users/autotime/Library/AutoPkg/Cache/local.munki.OktaVerify/unpack/Payload with aa failed

After manually running aa we saw permission errors writing to paths within OktaVerify.app.

[nstrauss]

@agburch Thanks. I can't replicate this. I've run autokpg with sudo (don't) to try to bump into a permissions issue, but no dice. There were known issues with aa in previous versions - https://github.com/autopkg/autopkg/pull/804 and https://github.com/autopkg/nstrauss-recipes/issues/37. Not entirely the same. Are you on the latest autopkg 2.x release? https://github.com/autopkg/autopkg/releases/tag/v2.7.2

If you're using a wrapper to run autopkg in CI or through a launch daemon on a static box, is it possible the permissions scheme there is to blame?

[agburch]

Thanks for digging into this @nstrauss, and for trying to replicate. Yes, we are running the latest autopkg version. It's definitely possible that this is an artifact of our github actions runner configuration, however I wasn't able to find the root cause there. Happy to keep digging.

That being said, feel free to close this if you would prefer not to add the additional processor step.

[nstrauss]

@agburch Poked at this a little more. I'm fairly sure your runner is acting as root, setting permissions on %RECIPE_CACHE_DIR%/payload/Applications/Okta Verify.app as such, and then the next run for whatever reason runs into the above error. ditto is actually used before aa, which is only referenced when ditto fails, in this case presumably for the same permissions issue. https://github.com/autopkg/autopkg/blob/126f90f7c6ea9c89c164b9dd575520bf97718e38/Code/autopkglib/PkgPayloadUnpacker.py#L50

Luckily both FlatPkgUnpacker and PkgPayloadUnpacker have a purge_destination key. I've merged https://github.com/autopkg/nstrauss-recipes/pull/62 which should hopefully fix the issue you're seeing without adding an additional processor. Please update the recipe and try again. Going to close this PR for now, but still curious if the #62 change works for you.

[agburch]

Thanks for your help with this. Great solution!