Skip to main content

I wanted to make a plugin where our users can see what type of things Casper is doing (our culture makes it difficult for people to accept Casper) . I made this script here:



!/bin/bash



mkdir /Library/Scripts/Shopify



more /var/log/jamf.log | grep "Executing|Installing|Updating|Adding|Existing|Removing|Deleting" | sed s/jamf[[0-9]*]://g 2>&1 > /Library/Scripts/Shopify/Whatran.txt



Made the plugin:



And then made a policy to run the script ongoing to update the file. Unfortunately the next time it runs the policy the txt is up to date but my self service plugin shows a blank page.



Oddly though, when I run a sudo jamf policy in terminal the log show up fine in my self service plugin. All this command is doing is running that ongoing policy... so I don't understand why it wouldn't just work without this.





Thoughts?

@dianabirsan Looks nice! I can see this script helping your users to be more comfortable with Casper.



EDIT: oops - just reread your post. I thought you were showing off a solution. I'll see if I can diagnose now...



What are the permissions on the file? Does the user have read access to that file or the location the file is located?

Are Self Service URL plug-ins capable of showing a plain text file like what you're creating? Maybe, but I was under the impression they needed to be something like an html page, or something similar. I'm wondering if you exported the results from your script into a very basic html page if it would then display correctly in Self Service?



You could also try flipping that "Display > Open in Self Service" option to "Open in Browser" and see if it works better. I have a feeling its just the built in Self Service browser giving you some trouble. Its really not the most full featured browser to be honest.

I think it's because in terminal, you have $PATH defined. Try using /bin/cat instead of 'more' in the start of your script.

Yup, it was definitely because I was using more. Thanks so much!

It's not because you were using 'more' instead of 'cat', but because you need to specify where that program is on the hard drive. The JSS policy can't find the 'more' program, like you can when using Terminal.



To know where a program lives on the hard drive, type 'which more'. It'll tell you the full path, such as '/bin/more'. Then in your script, use the full path. I just used 'cat' in my response, but you could have used '/bin/more' in your script to resolve the issue.



When using Terminal, you have a variable pre-defined called PATH which lists all the places to look for a program like 'more'. 



[adminx@casper]# echo $PATH

/usr/bin:/bin:/usr/sbin:/sbin


When using a policy via the JSS, you don't have that PATH variable. That means when you say to run 'more', the policy can't find that tool, so it won't run your command.

Its actually not necessary to use either more or cat at all since grep or egrep can do it all by itself, because its acting against a file.



egrep "Executing|Installing|Updating|Adding|Existing|Removing|Deleting" /var/log/jamf.log | sed 's/jamf[[0-9]*]://g' 2>&1 > /Library/Scripts/Shopify/Whatran.txt


egrep also prevents the need to use backslashes to escape the pipes separating the terms to search for.

I'm old school 😉 But thanks for the tip on egrep! I didn't know about that one.

Of course, now I understand! Still new at scripting and command line so this is all really great info.

Terms & ConditionsCookie settings