Skip to main content

Was fighting a script that worked perfectly in our test environment but kept failing in production.



Figured someone made a mistake copying and pasting the script, but that was not the case. The scripts were identical.



Then only difference was the display name. In PRD, the display name for the script was changed to include a site prefix for a site that uses a "/" in its name. it's two diff departments that recently merged, so the site is named DeptA/DeptB.



For POLICY names, this prefix has never a problem, but it appears that the presence of the "/" character will break script execution. Once we removed the "/" from the Display name of the script in production, it immediately started working properly whether called from Self Service or any other trigger.



so the question is "why?" I thought all objects in the database were assigned a ID number--that the "Display Name" is just for the web front end....there's nothing in the documentation that specifics any sort of naming conventions or warns against using illegal characters in script Display Names.

Just a guess, but the script must be downloaded to the client system before being run. I don't believe it runs over the network. This is mostly true for many aspects of Jamf processes and policies. I think scripts get downloaded to /Library/Application Support/JAMF/tmp/ if I'm not mistaken. If that's the case, a script filename with a / in it may cause an issue as / is a path delimiter on macOS and Unix systems. So it likely isn't able to find the script to run once it gets pulled down, because it tries to find it in another additional directory that doesn't exist.



If I had to take another guess, I assume the reason policy names can take a slash character is because the policy is not an actual object that gets downloaded to the machine to run, only the items in some of the payloads within the policy get downloaded, like scripts, packages, etc.



All that being said, it would be nice if Jamf Pro would automatically escape any such characters in the filename that gets downloaded, to prevent such errors. It's not as if the script display name is all that relevant to running the script. I'm guessing it's just a limitation in how it all works, i.e, the policy tells the local jamf binary about the items it needs to run, and uses the actual names as added to the policy. It probably uses literal paths to run any items after they get downloaded, and that's where it all goes wrong under these circumstances.

Reply


Terms & ConditionsCookie settings