Policies

This is actually quite easy. This is how you do it.

1) create two policies, the first policy runs a script which runs an if/then that will trigger a second policy that has a custom trigger

2) create your second policy to install/modify/whatever and give it a custom trigger.

Then just script it out like so

#!/bin/bash

# check to see current user by checking against /dev/console # if machine is at the login window, root will own the console

currentuser=/bin/ls -l /dev/console | /usr/bin/awk ' { print $3 }'

if [[ $currentuser == root ]]

then /usr/sbin/jamf policy -trigger my_custom_trigger_policy

else /bin/echo "$currentuser is currently logged in, exiting script..."

exit 5 fi done exit 0

If no one is logged in to the Mac, root will own the console, if someone is currently logged in they will own the console. This is a pretty constant and solid method of determining if someone is logged in. Also if the script exits, then it never runs the custom trigger policy. You could go even further if you wanted to and also use dummy packages, and keep the script as an ongoing policy and once everything is installed a dummy package is placed, so the script can check for the dummy receipt and exit that way. That way you can have on going policies that will hit all of your scope once, while the script itself can be ongoing to help mitigate resources used. That is, if you feel like getting crazy.

-Tom

nice. thanks buddy!

eric winkelhake
mundocomww
office 312 220 1669
cell 312 504 5155

Dude custom trigger policies is where it is at! I use them all the time now, and use scripts to automate stuff. Do all the leg work up front so you can put your feet up and surf fark and boing boing all day in the end!

I've also found that using custom triggers is a good way to install difficult software. I'd been trying to use Casper Imaging to install McAfee Security for Mac. Problem is, MSM really wants the OS to be live and booted (as opposed to a target like in Imaging) so I created a script that runs at reboot that Imaging lays down that calls a custom trigger to install MSM on the machine's first boot after imaging.

It's very slick.

j

On 12/15/09 12:29 PM, "Thomas Larkin" <tlarki at kckps.org> wrote:

Dude custom trigger policies is where it is at! I use them all the time now, and use scripts to automate stuff. Do all the leg work up front so you can put your feet up and surf fark and boing boing all day in the end!

i think you're on to something here. never really thought about using custom triggers before but now i'm imagining the possibilities.

eric winkelhake
mundocomww
office 312 220 1669
cell 312 504 5155

I use them for a ton of things as well, they are very powerful for policies and scripting event chains.

Craig E

Dudes-

I have a full fledged post image script that uses the JAMF binary to
create local user accounts, install custom trigger packages that are
specific to those machines, sets system wide settings (time zone,
date/time, network time server, remote log in, ARD access, so forth). The best part is, I never have to log into an image machine to post
config anything ever again. I even have a package that installs the
wireless. So I netboot, image it and forget it.

Only if I could get smart groups to work with compiled configurations I
would be 100% set!

Sure thing and I will also send this to the list so everyone can benefit
from it. Attached is an example script I use for post imaging. I have
created a few custom trigger packages that install that are outside my
base compiled configuration. My custom trigger add wireless package you
can get from here:

http://tlarkin.com/files/setAirPortNetwork.zip

The instructions on how to use that package are in the read me file. Attached is the example script. I am still tweaking it, so if you use it
and improve it please share with me what you did. I zipped the shell
script so hopefully it will not get flagged by your spam filters.

-Tom

?xml version="1.0" encoding="ISO-8859-1"?>