JamfPackageUploader.py: Share does not dismount when Jamf Admin running

[jazzace]

When running the processor JamfPackageUploader, if the pkg already exists and the replace_pkg variable is set to False (as it is by default), the SMB server will remain mounted.

Excerpt from successful run:

JamfPackageUploader: Checking for existing 'Firefox-78.6.0esr.pkg' on https://[JamfProServer]:8443
JamfPackageUploader: No existing cookie found - starting new session
JamfPackageUploader: ['/usr/bin/osascript', '-e', 'mount volume "smb://[JamfProServer]/VolumeName" as user name "user" with password "password"']
JamfPackageUploader: b'file VolumeName:\n'
JamfPackageUploader: No existing package found
JamfPackageUploader: Expected path: /Volumes/VolumeName/Packages/Firefox-78.6.0esr.pkg
JamfPackageUploader: Copying Firefox-78.6.0esr.pkg to /Volumes/VolumeName/Packages/Firefox-78.6.0esr.pkg
JamfPackageUploader: Package copy successful
Unmount successful for /Volumes/VolumeName
JamfPackageUploader: Creating package metadata
[etc.]

Run when package already exists:

JamfPackageUploader: Checking for existing 'Firefox-78.6.0esr.pkg' on https://[JamfProServer]:8443
JamfPackageUploader: No existing cookie found - starting new session
JamfPackageUploader: Package 'Firefox-78.6.0esr.pkg' already exists: ID 479
JamfPackageUploader: ['/usr/bin/osascript', '-e', 'mount volume "smb://[JamfProServer]/VolumeName" as user name "user" with password "password"']
JamfPackageUploader: b'file VolumeName:\n'
JamfPackageUploader: Existing package found: /Volumes/VolumeName/Packages/Firefox-78.6.0esr.pkg
JamfPackageUploader: Not replacing existing Firefox-78.6.0esr.pkg as 'replace_pkg' is set to False. Use replace_pkg='True' to enforce.
JamfPackageUploader: Setting for pkg metadata replacement: False
{'Output': {'pkg_name': 'Firefox-78.6.0esr.pkg'}}
Receipt written to /Users/tech/Library/AutoPkg/Cache/local.jamf.FirefoxESRSignedPkg-upload/receipts/local.jamf-receipt-20201216-110243.plist

Based on the fact that the processor already knows the package exists before it mounts it using AppleScript, the solution should probably be to not mount the share at all should the package exist and the replace_pkg variable not be set.

[grahampugh]

Hi @jazzace First off, thanks a lot for testing! That's exactly what I was hoping for when writing the blog post.

Note that with on-premises setups, there is a difference between checking that package metadata exists on the Jamf server and whether the package actually exists on the distribution point. We have to treat the two separately.

The share should be getting unmounted. The two options (package replaced vs not replaced) both have an unmount command attached to them. See https://github.com/autopkg/grahampugh-recipes/blob/master/JamfUploaderProcessors/JamfPackageUploader.py#L585-L618

I cannot see a pathway that would skip that step. If it is not unmounting for you, I wonder if there's something preventing it? I guess it needs more verbosity at the unmount.

[grahampugh]

I did a test and I do see the unmount:

...
JamfPackageUploader: Package 'erase-install-0.17.0.pkg' already exists: ID 1831
JamfPackageUploader: ['/usr/bin/osascript', '-e', 'mount volume "smb://REDACTED" as user name "REDACTED" with password "REDACTED"']
JamfPackageUploader: b'file JPShare:\n'
JamfPackageUploader: Existing package found: /Volumes/REDACTED/Packages/erase-install-0.17.0.pkg
JamfPackageUploader: Not replacing existing erase-install-0.17.0.pkg as 'replace_pkg' is set to False. Use replace_pkg='True' to enforce.
JamfPackageUploader: b'Unmount successful for /Volumes/REDACTED\n'
JamfPackageUploader: Setting for pkg metadata replacement: False
{'Output': {'pkg_name': 'erase-install-0.17.0.pkg',
            'pkg_path': '/Users/REDACTED/Library/AutoPkg/Cache/local.jamf.macOS-erase-install/erase-install-0.17.0.pkg'}}
StopProcessingIf
{'Input': {'predicate': 'pkg_uploaded == False'}}
StopProcessingIf: (pkg_uploaded == False) is True
{'Output': {'stop_processing_recipe': True}}

(albeit some of the outputs needs to be decoded to string).

[grahampugh]

I made slight adjustments to the mount/unmount functions to see if it makes any difference. See/try the test-unmount branch (https://github.com/autopkg/grahampugh-recipes/blob/test-unmount/JamfUploaderProcessors/JamfPackageUploader.py#L323-L352)

JamfPackageUploader: Package 'erase-install-0.17.0.pkg' already exists: ID 1831
JamfPackageUploader: file JPShare:

JamfPackageUploader: Existing package found: /Volumes/JPShare/Packages/erase-install-0.17.0.pkg
JamfPackageUploader: Not replacing existing erase-install-0.17.0.pkg as 'replace_pkg' is set to False. Use replace_pkg='True' to enforce.
JamfPackageUploader: Unmount successful for /Volumes/JPShare

JamfPackageUploader: Setting for pkg metadata replacement: False

By the way, you can choose to update the metadata anyway and continue the recipe If desired. replace_pkg_metadata='True' is also a thing, e.g. https://github.com/eth-its/autopkg-mac-recipes/blob/main/Jamf_Recipes/macOSBigSur-download.jamf.recipe#L79-L91

[jazzace]

OK, I'll start with the mea culpa. I ran a different recipe using the release version and the dismount did not occur on the initial upload. So my error had nothing to do with whether it was replacing an existing package or not. I was using Jamf Admin to verify what JamfPackageUploader was doing. If I had Jamf Admin open, the mount would occur but the dismount would not (nor would it be reported in the output). If I closed Jamf Admin, the behaviour was as expected. I haven't tested your changed code; should I? Or should we just close this (incorrectly named) issue?

[jazzace]

Never mind, I did the testing. The only difference is that the new code reports the dismount that never occurs (or is ineffective). So this is a straightforward conflict with Jamf Admin. Probably just something to document and close.

[grahampugh]

I guess we can close it? I'll run the amended version with n my scheduled run tonight and if nothings broken as a result I will merge it tomorrow.

But you did bring up an issue I had been thinking about. What if your computer already has the folder mounted? Should the processor check for this and not attempt to mount it again (if that's even possible to check), and also not unmount it? I don't believe JSSImporter does. At present, I plumped for not forcing the unmount.

[grahampugh]

Is it incorrectly reporting that the dismount occurred when it didn't?

[jazzace]

Release version: does not (reliably) report dismount (as per excerpt above). test-unmount version:

JamfPackageUploader: Package 'Firefox-84.0.pkg' already exists: ID 482
JamfPackageUploader: file JSSDP:

JamfPackageUploader: Existing package found: /Volumes/JSSDP/Packages/Firefox-84.0.pkg
JamfPackageUploader: Not replacing existing Firefox-84.0.pkg as 'replace_pkg' is set to False. Use replace_pkg='True' to enforce.
JamfPackageUploader: Unmount successful for /Volumes/JSSDP

JamfPackageUploader: Setting for pkg metadata replacement: False
{'Output': {'pkg_name': 'Firefox-84.0.pkg'}}
Receipt written to /Users/username/Library/AutoPkg/Cache/com.github.jazzace.ds.FirefoxSignedPkgTest/receipts/FirefoxSignedPkg-uploadtest-receipt-20201216-143551.plist

Nothing downloaded, packaged or imported.

and SMB share stays mounted in the Finder.

Doing some more testing…

[jazzace]

I'm not certain why, but if I go back to the release version, I am now getting reports of the dismount (even when it actually fails). So I'm going to assume the lack of the dismount report was a transient issue. Nevertheless, I have narrowed the case for the conflict with Jamf Admin. Steps to reproduce:

1. Login to Jamf Admin using your credentials
2. From a Terminal session, run a recipe that uses JamfPackageUploader and has the (same) Jamf Pro credentials available in the environment.

Result: Recipe runs, mounts Distribution Point, which shows up in the Finder but does not dismount.

3. Re-run the same recipe (!!) with the share still mounted.

Result: "No file or directory" error (see run excerpt):

JamfPackageUploader: Package 'Firefox-78.6.0esr.pkg' already exists: ID 479
JamfPackageUploader: ['/usr/bin/osascript', '-e', 'mount volume "smb://[JamfProServer]/JSSDP" as user name "user" with password "password"']
JamfPackageUploader: b''
JamfPackageUploader: Expected path not found!: /Volumes/JSSDP
JamfPackageUploader: Copying Firefox-78.6.0esr.pkg to /Volumes/JSSDP/Packages/Firefox-78.6.0esr.pkg
[Errno 2] No such file or directory: '/Volumes/JSSDP/Packages/Firefox-78.6.0esr.pkg'
Failed.
Receipt written to /Users/user/Library/AutoPkg/Cache/local.jamf.FirefoxESRSignedPkg-upload/receipts/FirefoxESRSignedPkg-upload-receipt-20201216-145449.plist

The following recipes failed:
    FirefoxESRSignedPkg-upload.jamf
        Error in local.jamf.FirefoxESRSignedPkg-upload: Processor: com.github.grahampugh.jamf-upload.processors/JamfPackageUploader: Error: [Errno 2] No such file or directory: '/Volumes/JSSDP/Packages/Firefox-78.6.0esr.pkg'

4. Manually dismount the Distribution point in the Finder, then run the same recipe again (!!). Jamf Admin is still open.

Result: Runs properly. Distribution point SMB share mounts and dismounts silently (i.e. nothing shows up in the Finder, unlike after Step 2).

I've re-titled this issue for clarity. At least the case has narrowed.

[grahampugh]

I have added a note to the wiki (https://github.com/grahampugh/jamf-upload/wiki/JamfUploader-AutoPkg-Processors) to point out the conflict. I'll keep this open as an enhancement to at some point see if there's a way to detect that the FileShare is already mounted.