Make support-file config tenant-agnostic and add a banner fallback - #15
Open
AndrewMBarnett wants to merge 2 commits into
Open
AndrewMBarnett wants to merge 2 commits into
AndrewMBarnett wants to merge 2 commits into
Conversation
JAMFGetDDMInfo hardcoded Giant Eagle paths and policy triggers, so on any other tenant it ran a jamf policy that could never succeed and then pointed swiftDialog at a banner image that was not there. Configuration: - Resolve every setting as environment variable, then managed preference, then built-in default, via read_config(). The previous "defaults read ... || default" pattern missed empty preference values, since defaults read exits 0 on an empty key. - locate_defaults_domain() picks the preference domain from SCRIPT_DEFAULTS_DOMAIN or DEFAULTS_DOMAIN_CANDIDATES, accepting either a domain name or a full plist path, and checking both Managed Preferences and Preferences. - Make the three policy triggers configurable. Setting the support-file trigger to "none" skips that policy entirely. Banner handling: - Resolve a bare banner filename against the support directory whether or not the file exists yet, so the later existence check tests the real location instead of the working directory. This is what caused the support-file policy to run on every invocation. - Only run the support-file policy when it could actually help: a local image path that is missing, with the jamf binary present. A URL banner no longer triggers a policy. - Fall back to a swiftDialog colour/gradient banner when no image can be found, configurable via BannerFallback. Gradient banners require swiftDialog 3.1.0, which check_swift_dialog_install already enforces. - Leave colour= and gradient= values unmodified during path resolution so they can also be used as the primary banner. Also in this change: - Install swiftDialog and jq directly from their GitHub releases, with the jamf policy as fallback. swiftDialog is verified by Developer ID Team ID; the jq binaries are ad-hoc signed, so they are verified against the sha256sum.txt published with the release. - Check the installed jq against MIN_JQ_REQUIRED_VERSION, and add /usr/local/bin to PATH, which the bare jq call sites need. - Restore the suppressed stderr on the swiftDialog --version check, use the autoload -Uz idiom for is-at-least, and add a .gitignore for .DS_Store. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Jamf_get_server read jss_url from the local com.jamfsoftware.jamf.plist, so the script could only ever query the server this Mac happens to be enrolled with. That rules out pointing it at a test tenant, or running it from a Mac enrolled somewhere else. The URL is now resolved in order: 1. Script parameter 6 2. JamfProURL, via the environment or the managed preference domain 3. jss_url from the local jamf plist (unchanged default) 4. A swiftDialog prompt, only if the first three come up empty On an enrolled Mac step 3 still answers, so existing policies keep working with no change and the prompt never appears. Supporting changes: - normalize_jamf_url() accepts what an admin is likely to type or paste: a bare hostname gains https://, surrounding whitespace and any trailing slashes, query string or fragment are trimmed, and a host:port is preserved. Input with internal spaces, a non-http scheme, or no host is rejected rather than being coerced into a plausible-looking hostname. - Jamf_get_server records whether the URL came from enrollment or from an override, in JAMF_URL_SOURCE. - Jamf_check_connection uses that: "jamf -checkjssconnection" only reports on the enrolled server, so it is used only when that is the server being queried. Otherwise the resolved URL is probed directly, treating HTTP 401 from /api/v1/jamf-pro-version as a healthy unauthenticated response. - Jamf_get_server now runs before Jamf_check_connection, which previously tested a connection before the script had worked out what to connect to. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JAMFGetDDMInfo hardcoded Giant Eagle paths and policy triggers, so on any other tenant it ran a jamf policy that could never succeed and then pointed swiftDialog at a banner image that was not there.
Configuration:
Banner handling:
Also in this change: