Skip to main content
Solved

AppleScript - Deploying Through Jamf Pro

JDaher
Forum|alt.badge.img+9

Hello everyone,

I'm looking for help deploying AppleScript through Jamf Pro. I know the basics of bash scripts but almost nothing about AppleScript. I got the following AppleScript from one of our network administrators:

tell application "System Events"

set macUser to name of current user

end tell

try

set FortiDir to POSIX file "/Users/Shared/Fortinet/Forticlient"

set ztnaConfig to POSIX file "/Users/Shared/Fortinet/Forticlient/ztnaconfig.json"

set FortiDir to POSIX path of the file FortiDir

set ztnaConfig to POSIX path of the file ztnaConfig

do shell script "chown -R " & macUser & " " & FortiDir with administrator privileges

do shell script "chmod 755 " & FortiDir with administrator privileges

do shell script "chmod 644 " & ztnaConfig with administrator privileges

display dialog "BW FortiClient permissions patch successful"

on error theErr

display dialog "File permissions update failed for " & FortiDir

end try

I tried to deploy it as a shell script in Jamf like this:

#!/bin/bash

osascript -e 'tell application "System Events"
set macUser to name of current user
end tell
try
set FortiDir to POSIX file "/Users/Shared/Fortinet/Forticlient"
set ztnaConfig to POSIX file "/Users/Shared/Fortinet/Forticlient/ztnaconfig.json"
set FortiDir to POSIX path of the file FortiDir
set ztnaConfig to POSIX path of the file ztnaConfig
do shell script "chown -R " & macUser & " " & FortiDir with administrator privileges
do shell script "chmod 755 " & FortiDir with administrator privileges
do shell script "chmod 644 " & ztnaConfig with administrator privileges
display dialog "BW FortiClient ZTNA permissions patch successful"
on error theErr
display dialog "File permissions update failed for " & FortiDir
end try'

It works on some machines but fails on others. The error is:

Script result: 56-60: execution error: System Events got an error: Application isn't running. (-600)

I searched for the error and found out a line to launch System Events by adding this:

 

if application "System Events" is not running then
launch application "System Events"
delay 0.5
end if
 
So, I modified my shell script to look like this:
 
#!/bin/bash
 
osascript -e 'if application "System Events" is not running then
launch application "System Events"
delay 0.5
end if

tell application "System Events"

set macUser to name of current user

end tell

try

set FortiDir to POSIX file "/Users/Shared/Fortinet/Forticlient"

set ztnaConfig to POSIX file "/Users/Shared/Fortinet/Forticlient/ztnaconfig.json"

set FortiDir to POSIX path of the file FortiDir

set ztnaConfig to POSIX path of the file ztnaConfig

do shell script "chown -R " & macUser & " " & FortiDir with administrator privileges

do shell script "chmod 755 " & FortiDir with administrator privileges

do shell script "chmod 644 " & ztnaConfig with administrator privileges

display dialog "BW FortiClient permissions patch successful"

on error theErr

display dialog "File permissions update failed for " & FortiDir

end try'

I still get errors, and this post is getting too long to post them. I think it's possible that I'm messing up the syntax when integrating AS into shell. I'm hoping it's something very simple that one of you can spot easily. 

Appreciate your time and suggestions.

 

 

Best answer by mschlosser

JDaher wrote:

I don't know what's inside the ztnaconfig.json, this was deployed previously when FortiClient was installed. I spoke to the network admins. The goal is that the ztna* files in /Users/Shared/Fortinet/Forticlient/ be owned by the logged-in user and have perms set to 644, and that the directory itself is set to 755. So yes I agree that it is messy as I've tried to deploy it, and it is probably best accomplished with a relatively simple shell script. I think I'm going to try that instead. Thanks for validating my suspicion. 


if that is all you are trying to do, I'd package up ztnaconfig.json with composer, at the correct path; and then use chown -R /path/to/item and chmod -R 644 /path/to/item. both easy things to setup in a policy. no apple script needed the chown and chmod command could even be chain together with && if you like. hope that helps.

View original
    Did this topic help you find an answer to your question?

    6 replies

    jamf-42
    Forum|alt.badge.img+17
    • jamf-42
    • Esteemed Contributor
    • 744 replies
    • April 12, 2024

    Applescript.. in 2024? thats breaking out to shell script.. this is messy.. whats inside ztnaconfig.json 

    What exactly is this trying to do?

    How is the json deployed? 

    Lets start there, sure this could be done very simply with shell script.. if thats really what is required.. 

     

     

     

     

    JDaher
    Forum|alt.badge.img+9
    • JDaher
    • Author
    • Contributor
    • 40 replies
    • April 12, 2024
    jamf-42 wrote:

    Applescript.. in 2024? thats breaking out to shell script.. this is messy.. whats inside ztnaconfig.json 

    What exactly is this trying to do?

    How is the json deployed? 

    Lets start there, sure this could be done very simply with shell script.. if thats really what is required.. 

     

     

     

     


    I don't know what's inside the ztnaconfig.json, this was deployed previously when FortiClient was installed. I spoke to the network admins. The goal is that the ztna* files in /Users/Shared/Fortinet/Forticlient/ be owned by the logged-in user and have perms set to 644, and that the directory itself is set to 755. So yes I agree that it is messy as I've tried to deploy it, and it is probably best accomplished with a relatively simple shell script. I think I'm going to try that instead. Thanks for validating my suspicion. 

    M
    Forum|alt.badge.img+11
    • mschlosser
    • Contributor
    • 126 replies
    • Answer
    • April 15, 2024
    JDaher wrote:

    I don't know what's inside the ztnaconfig.json, this was deployed previously when FortiClient was installed. I spoke to the network admins. The goal is that the ztna* files in /Users/Shared/Fortinet/Forticlient/ be owned by the logged-in user and have perms set to 644, and that the directory itself is set to 755. So yes I agree that it is messy as I've tried to deploy it, and it is probably best accomplished with a relatively simple shell script. I think I'm going to try that instead. Thanks for validating my suspicion. 


    if that is all you are trying to do, I'd package up ztnaconfig.json with composer, at the correct path; and then use chown -R /path/to/item and chmod -R 644 /path/to/item. both easy things to setup in a policy. no apple script needed the chown and chmod command could even be chain together with && if you like. hope that helps.

    JDaher
    1 person likes this
    • JDaher
      JDaher
    JDaher
    Forum|alt.badge.img+9
    • JDaher
    • Author
    • Contributor
    • 40 replies
    • April 16, 2024
    mschlosser wrote:

    if that is all you are trying to do, I'd package up ztnaconfig.json with composer, at the correct path; and then use chown -R /path/to/item and chmod -R 644 /path/to/item. both easy things to setup in a policy. no apple script needed the chown and chmod command could even be chain together with && if you like. hope that helps.


    Thank you. The json file has already been deployed, so all I really need to do is to change ownership and permissions. Since our users don't share machines, I can probably dispense with the part of the script that looks for the currently-logged in user, and instead just send the chown and chmod commands in a two-line script via policy. Or maybe even just use the Files & Processes payload of a policy, I think it supports multiple commands. Am I missing something? As I write this I'm realizing that this project might have been overcomplicated. 

    C
    Forum|alt.badge.img+14
    • cdenesha
    • Honored Contributor
    • 862 replies
    • April 19, 2024

    Hello,

    I don't think the permissions need to be the user's. It is in 'Shared', so 'everyone' can usually read by default. I have that folder on my Mac, and FortiClient is working while user permissions are root/system.

    This is definitely NOT the job for applescript! :)

    chris

    JDaher
    Forum|alt.badge.img+9
    • JDaher
    • Author
    • Contributor
    • 40 replies
    • April 19, 2024

    Thank you, everyone. Once I spoke to the network administrator and he clarified what the goal of all of this was, I just put it all in a shell script and deployed it through a policy. I should have done that from the start, but I didn't know exactly what his AppleScript was doing and I thought integrating it in a shell script would be simple. Anyway, I really appreciate all your help, sometimes you just need to run these kinds of things by your peers in order for you to sort them out. 

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings