fleetdm
Self-service scripts
@harrisonravazzolo - gong snippet
Problem
As an IT Admin, I want to be able to add a script to Fleet and designate it as "Self Service," much like I'm able to do with uploading Software today.
What have you tried?
Today, I am able to upload scripts to Fleet, but they can't be triggered by end users.
Potential solutions
When an admin uploads a script to Fleet, there could be a checkbox to designate the script as Self Service. This would mirror the process that exists today for Software.
What is the expected workflow as a result of your proposal?
Self Service scripts is a feature available in other MDM products and the use cases are wide ranging. In general, expected workflows are the same as regular script execution except the user determines when they should be run.
Customer: As an end user, I want to execute organization-provided scripts on my host, to troubleshoot, remediate issues, or configure my system from a GUI portal.
Examples:
-
An IT admin can write a script to collect diagnostics for an app. The user can use the self-service script to trigger the collection of diagnostics when they are experiencing the issue.
-
Collect TPM EKPub for escrow to IT asset management platform.
-
Configure
nssdbto interoperate with a PKCS#11 module.
CPE Context: In a previous life I had a self service script called "Log Collector" that just ran sysdiagnose and then a trigger to go grab that file in Fleet through carving.
prospect-nishiyama: https://us-65885.app.gong.io/call?id=620458040443628606&highlights=%5B%7B%22type%22%3A%22SHARE%22%2C%22from%22%3A885%2C%22to%22%3A989%7D%5D
Problem
As an IT Admin, I want to be able to add a script to Fleet and designate it as "Self Service," much like I'm able to do with uploading Software today.
What have you tried?
Today, I am able to upload scripts to Fleet, but they can't be triggered by end users.
Potential solutions
When an admin uploads a script to Fleet, there could be a checkbox to designate the script as Self Service. This would mirror the process that exists today for Software.
What is the expected workflow as a result of your proposal?
Self Service scripts is a feature available in other MDM products and the use cases are wide ranging. In general, expected workflows are the same as regular script execution except the user determines when they should be run.
Customer: As an end user, I want to execute organization-provided scripts on my host, to troubleshoot, remediate issues, or configure my system from a GUI portal.
Examples:
-
An IT admin can write a script to collect diagnostics for an app. The user can use the self-service script to trigger the collection of diagnostics when they are experiencing the issue.
-
Collect TPM EKPub for escrow to IT asset management platform.
-
Configure
nssdbto interoperate with a PKCS#11 module.
I've added the g-software tag to this (/cc @mostlikelee) and added a size (S) with the idea that we could implement this via software "installers", as there's very little daylight between this and a tarball (no defaults on scripts, no associated inventory, no version number, no caring about patching...and that's all already implemented for tarballs). Only difference is there's no artifact to download (and we can just deliver a zero-length artifact). That would allow for compatibility with existing fleetd releases, so all of the lift here would be server-side. We would also get various pieces of filtering (incl. categories) for free.
Now, the above only really solves the use case of e.g. opt-in/opt-out scripts, which was mentioned as a customer use case, because for one-off "please run this script" cases we don't want to have the concept of installed/uninstalled...the script can be run an arbitrary number of times and we should show the status of the last run. But we can cover that use case by allowing "uninstall scripts" to be optional for the implementation, and if the script isn't supplied then we don't show the uninstall option. Not much extra effort, and that fulfills the other use case.
This ties in with #30240 in that, for these scripts, we'll want to use Fleet-init'd install status for scripts rather than anything inventory-based. This walks back some of the work we're doing this sprint, but we already need to make an exception for tarballs (they don't have invenotry), so this just follows the same pattern.
One thought on use cases is that if a customer is using a script to opt a host in/out of a canary group, that actually sounds like a completely different feature, namely the ability to self-service add/remove (specified) manual host labels. So if that was the only reason for having package-less installers (it's not), we should build self-service label membership changes rather than package-less installers.
/cc @mikermcneil since this ties into the 7/4 design review.
- @noahtalerman (2025-10-01): Learned from
customer-numathat they have a workaround for this:
- Package up a script as an empty package themselves. The script lays down a "receipt" so that Fleet verifies the install "action" was successful. Fleet shows "Installed" status. They add the package to Fleet and add an uninstall script so that the end user can undo the action. They also add a preinstall query.
- So, for Fleet to catch up to
numa's workaround, in addition to this story, we think Fleet will want to also add these features:
- Add support for preinstall query and uninstall script for
.shand.ps1custom packages.- Automatically, for the user, lay down a receipt to do the verification that the action was installed. Or, let the IT admin define a postinstall query that Fleet runs to verify the action was successful.
FYI @rachaelshaw learnings from numa.
@Patagonia121 #31719 shipped in v4.66.0. We think this fulfills the request (at least for for Windows and Linux) because it allows adding a script as a software package, which can then be added to self-service. One caveat: this is not yet supported on macOS, because all .sh files are assumed to be Linux scripts right now (no way to specify platform).
@noahtalerman we heard a need for this from customer-antonella this week so I've included their Gong snippet up above for your review. Thanks!
@rachaelshaw I think you mean that user story shipped in 4.76 instead of 4.66? It's carrying the 4.76 milestone just wanted to make sure it's labeled correctly (I'm like 99% sure it is). Thanks!
https://github.com/fleetdm/fleet/issues/20692#issuecomment-3583524706 this reason for not having this feature for macOS does not make much sense. We should be allowing any script with any command line interpreter be uploded to any host. If the computer has a runtime for that command line interepreter, the device itself will do the work of determining if it can run @rachaelshaw @noahtalerman
@iansltx Not totally sure I followed the comment above about "different features" but something to understand about how putting a script in Self Service would work in Jamf is that it 9/10 would be executed by a policy that is set to "ongoing" meaning it's available to run any time & always visible in Self Service, as opposed to being set to some other execution frequency, or set in such a way that it's only visible to a user 1 time (there are use cases for policies like that, usually some kind of temporary "fix" that only can happen once.)
@nonpunctual macOS support is on the roadmap. Here's the user story: https://github.com/fleetdm/fleet/issues/33951
Currently targeting 4.82.