changed name of PreUpdate to patchooStart.

new --cache method that doesn't require passing pkgname and description to script manually (docs to come) will reorganise command line parameters too.

0patchoo.sh

@@ -21,7 +21,7 @@
 #
 
 name="patchoo"
-version="0.982"
+version="0.99"
 
 # read only api user please!
 apiuser="apiuser"
@@ -331,38 +331,56 @@ spawnScript()
 #
 
 
-cachePkgs()
+cachePkg()
 {
 	# run after a pkg is cached in a policy
 	#	- checks for prereqs and calls policies if receipts not found
-	#	- gets pkg data from jss api and gives pkg friendly name in the gui by writing some metadata to the pkgdatafolder
+	#	- gets pkg data from jss api and gives pkg friendly name in the gui
 	#
-	echo "$pkgdescription" > "$pkgdatafolder/$pkgname.caspinfo"
-	# get pkgdata from the jss api
-	curl $curlopts -s -u $apiuser:$apipass ${jssurl}JSSResource/packages/name/$(echo $pkgname | sed -e 's/ /\+/g') -X GET > "$pkgdatafolder/$pkgname.caspinfo.xml"
-	# if it's flagged as an OS Upgrade (using createOSXInstallPkg), add that to pkg (very crudely)
-	[ "$option" == "--osupgrade" ] && touch "$pkgdatafolder/$pkgname.caspinfo.osupgrade"
-	secho "jamf has cached $pkgname"
-	secho "$pkgdescription" 2 "Downloaded" "globe"
-	# flag that we need a recon
-	touch "$datafolder/.patchoo-recon-required"
-
-	if [ "$prereqreceipt" != "" ]
+
+	# find the latest addition to the Waiting Room
+	pkgname=$(ls -tr "/Library/Application Support/JAMF/Waiting Room/" | tail -n 1 | grep -v .cache.xml)
+	if [ ! -f "$pkgdatafolder/$pkgname.caspinfo" ]
 	then
-		# we need to check for a prereq casper receipt
-		if [ ! -f "/Library/Application Support/JAMF/Receipts/$prereqreceipt" ]
+		# get pkgdata from the jss api
+		curl $curlopts -s -u $apiuser:$apipass ${jssurl}JSSResource/packages/name/$(echo $pkgname | sed -e 's/ /\+/g') -X GET > "$pkgdatafolder/$pkgname.caspinfo.xml"
+		# (error checking)
+		pkgdescription=$(cat "$pkgdatafolder/$pkgname.caspinfo.xml" | xpath //package/info 2> /dev/null | sed 's/<info>//;s/<\/info>//')
+		if [ "$pkgdescription" != "<info />" ]
+		then
+			echo "$pkgdescription" > "$pkgdatafolder/$pkgname.caspinfo"
+		else
+			# if it's blank, use the pkgname
+			echo "$pkgname" "$pkgdatafolder/$pkgname.caspinfo"
+		fi
+
+		# if it's flagged as an OS Upgrade (using createOSXInstallPkg), add osupgrade flag
+		[ "$option" == "--osupgrade" ] && touch "$pkgdatafolder/$pkgname.caspinfo.osupgrade"
+		secho "jamf has cached $pkgname"
+		secho "$pkgdescription" 2 "Downloaded" "globe"
+		# flag that we need a recon
+		touch "$datafolder/.patchoo-recon-required"
+
+		if [ "$prereqreceipt" != "" ]
 		then
-			# the receipt wasn't found
-			# query the JSS for the prereqpolicy
-			secho "$prereqreceipt is required and NOT found"
-			secho "querying jss for policy $prereqpolicy to install $prereqreceipt"
-			prereqpolicyid=$(curl $curlopts -s -u $apiuser:$apipass ${jssurl}JSSResource/policies/name/$prereqpolicy -X GET | xpath //policy/general/id 2> /dev/null | sed -e 's/<id>//;s/<\/id>//')
-			# (error checking)
-			# let's run the preq policy via id
-			# this is how we chain incremental updates
-			jamf policy -id $prereqpolicyid
+			# we need to check for a prereq casper receipt
+			if [ ! -f "/Library/Application Support/JAMF/Receipts/$prereqreceipt" ]
+			then
+				# the receipt wasn't found
+				# query the JSS for the prereqpolicy
+				secho "$prereqreceipt is required and NOT found"
+				secho "querying jss for policy $prereqpolicy to install $prereqreceipt"
+				prereqpolicyid=$(curl $curlopts -s -u $apiuser:$apipass ${jssurl}JSSResource/policies/name/$prereqpolicy -X GET | xpath //policy/general/id 2> /dev/null | sed -e 's/<id>//;s/<\/id>//')
+				# (error checking)
+				# let's run the preq policy via id
+				# this is how we chain incremental updates
+				jamf policy -id $prereqpolicyid
+			fi
 		fi
+	else
+		secho "i didn't find a new pkg in the waiting room. :("
 	fi
+
 }
 
 checkASU()
@@ -1022,8 +1040,11 @@ getGroupMembership()
 	groupid=0
 	macaddress=$(networksetup -getmacaddress en0 | awk '{ print $3 }' | sed 's/:/./g')
 	# jss group file, we cache this in a central location so we can minimise number of hits on the jss for an update session.
-	[ ! -f "$jssgroupfile" ] && curl $curlopts -s -u $apiuser:$apipass ${jssurl}JSSResource/computers/macaddress/$macaddress | xpath //computer/groups_accounts/computer_group_memberships[1] 2> /dev/null | sed -e 's/<computer_group_memberships>//g;s/<\/computer_group_memberships>//g;s/<group>//g;s/<\/group>/\n/g' > "$jssgroupfile"
-
+	if [ ! -f "$jssgroupfile" ]
+	then
+		secho "getting computer group membership ..."
+		curl $curlopts -s -u $apiuser:$apipass ${jssurl}JSSResource/computers/macaddress/$macaddress | xpath //computer/groups_accounts/computer_group_memberships[1] 2> /dev/null | sed -e 's/<computer_group_memberships>//g;s/<\/computer_group_memberships>//g;s/<group>//g;s/<\/group>/\n/g' > "$jssgroupfile"
+	fi
 	for checkgroup in ${jssgroup[@]}
 	do
 		# we don't check against the production
@@ -1038,9 +1059,9 @@ getGroupMembership()
 	groupid=0
 }
 
-preUpdate()
+patchooStart()
 {
-	secho "performing preupdate checks ..."
+	secho "starting triggered patchoo run!"
 	jamfPolicyUpdate
 }
 
@@ -1228,7 +1249,7 @@ case $mode in
 
 	"--cache" )
 		# run after caching package in policy to add metadata.
-		cachePkgs
+		cachePkg
 	;;
 
 	"--checkasu" )
@@ -1264,9 +1285,9 @@ case $mode in
 		processLogout
 	;;
 
-	"--preupdate" )
-		# when using patchooAdvanceMode (tm) this is used to launch the update triggers
-		preUpdate
+	"--patchoostart" )
+		# this starts the patchoo update process, triggered by -trigger patchoo
+		patchooStart
 	;;
 
 	"--bootstrap" )
@@ -1291,4 +1312,4 @@ esac
 # tidy up any leftovers
 cleanUp
 
-exit
+exit 0

docs/configuring_patchoo.sh.md

@@ -4,7 +4,7 @@ Configuring patchoo.sh
 
 ### Basic Path Configuration   
 
-You will need to edit your _patchoo.sh to suit your environment before you upload it into Casper Admin.   
+You will need to edit your 0patchoo.sh to suit your environment before you upload it into Casper Admin.   
 
 
 `````

docs/install_triggers.md

@@ -1,24 +1,15 @@
 Install Triggers
 ----------------
-patchoo requires two additional triggers to work as documented. Depending on whether or not you use [advanced patchoo mode](advanced_patchoo_overview.md), you will use the following.
+patchoo requires two additional triggers to work as documented. 
 
-### Basic ###
 
-* update	- chains update policies for production installations
-* every120	- fires reminder bubbles, or reminder prompts
 
+* `patchoo` - should be linked to the [patchooStart](setup_core_policies.md) policy.
+* `every120`	- should be linked to the [patchooUpdateRemindPrompt](setup_core_policies.md) policy.
 
-### Advanced Mode ###
-* preupdate	- checks [group membership](setup_computer_deployment_groups.md) and fires software deployment trigger *(eg. update-dev, update-beta)* it then fires the update trigger
-* every120 - as above
-
-You can modify the triggers to suit your environment, but by default the update/preupdate run at midday, randomised by 1800 seconds. Every120 (as implied) runs every two hours to balance gentle reminders, with annoyance :)
-
-This triggers are [here](triggers), you can use the ready made packages and deploy on all clients via policy, or modify and package them yourself.
-
-**If using the ready made packages, use ONLY the preudpate or the update pkg**. Both contain the every120 trigger. If using [advanced patchoo mode](advanced_patchoo_overview.md) ***recommended*** only install the preupdate trigger, as the preupdate policy will fire update triggers.
-
+You can modify the triggers to suit your environment, but by default the `patchoo` trigger runs at midday, randomised by 1800 seconds. Every120 (as implied) runs every two hours to balance gentle reminders, with annoyance :)
 
+This triggers are [here](http://github.com/patchoo/patchoo/tree/master/triggers), you can use the ready made packages and deploy on all clients via policy, or modify and package them yourself.
 
 
 

docs/setup_categories.md

@@ -3,6 +3,8 @@ Setup Categories
 
 Creating categories within your JSS will help organise your policies, and if using [patchoo Advanced mode](advanced_patchoo_overview.md) it will give you a good visual representation of which package deployments are in dev, beta, and production.
 
+If you are not using [patchooSWReleaseMode](advanced_patchoo_overview.md), you can skip creation of the -beta, -dev categories.
+
 As with the 0patchoo.sh script, naming your categories with preceeding 0's will mean they sort alphabetically.
 
 The suggested categories are:

docs/setup_core_policies.md

@@ -4,7 +4,7 @@ The following policies are the core of patchoo. They drive the caching, Apple So
 
 It's recommended that you create a [category](setup_categories.md) to house them within your JSS.
 
-* [patchooPreUpdate](#patchooPreUpdate)
+* [patchooStart](#patchooStart)
 * [patchooCheckASU](#patchooCheckASU)
 * [patchooPromptToInstall](#patchooPromptToInstall)
 * [patchooPromptAndInstallAtLogout](#patchooPromptAndInstallAtLogout)
@@ -13,22 +13,21 @@ It's recommended that you create a [category](setup_categories.md) to house them
 
 
 ___
-### [000-patchooPreUpdate](id:patchooPreUpdate)
+### [000-patchooStart](id:patchooStart)
 
-*optional for [patchoo advanced mode](advanced_patchoo_overview.md)*  
 
-If using [patchoo advanced mode](advanced_patchoo_overview.md) you can utilise the preudpate policy, fired by the [preudpate trigger](install_triggers.md). By using a preupdate policy, you can enforce limitations (network segments, time of day etc) so updates are not triggers on certain WAN or VPN connections.
+The patchooStart policy fired by the [patchoo trigger](install_triggers.md). By using a preupdate policy, you can enforce limitations (network segments, time of day etc) so updates are not triggers on certain WAN or VPN connections.
 
 The preupdate policy queries the [JSS via the api](setup_jss_api_access.md) and checks if the client is a member of the any of the [deployment groups](setup_computer_deployment_groups.md) (*dev / beta / production / etc*). If found it fires the relevant trigger (*eg. update-beta*) before firing the default *update* trigger.
 
 Using this method allows us to allocate different software installations based on JSS group membership. This is great for a *dev / beta / production* similar to munki's catalogs.
 
 #### General tab
 
-* Name: `000-patchoo-PreUpdate`
+* Name: `000-patchooStart`
 * Enabled: `true`
 * Category: `0-patchoo-z-core`
-* Trigger: `preudpate`
+* Trigger: `patchoo`
 * Execution: `ongoing`
 
 ![preudpate general](images/policy_preudpate_general.png)
@@ -37,23 +36,23 @@ Using this method allows us to allocate different software installations based o
 
 * Script: `0patchoo.sh`
 * Priority: `before`
-* Mode (1st param): `--preupdate`
+* Mode (1st param): `--patchoostart`
 
 ![preupdate script](images/policy_preudpate_script.png)
 
 #### Scope / Targets tab
 
-![preupdate scope](images/policy_preudpate_scope.png)
+Since the patchooStart policy calls the rest of the update chain, you can perform all of your scope limitations to this policy, rather than scoping each and every software deployment policy. Clever!
+
 
-You can limit computers via group here any way you desire, or you can ensure that only clients that are patchoo capable (ie. have CocoaDialog installed).
+![preupdate scope](images/policy_preudpate_scope.png)
 
-* Computer Group: `allpatchooClients`
+* Computer Group: `allPatchooClients`
 
 #### Scope / Limitations
 
 You can limit your patchoo sessions via Network Segment, or times here. This can prevent your clients from attempting to pull updates whilst on the VPN or on a poor WiFi / WAN segment. In this example screenshot we add all of our high speed connects, and ensure that clients on the VPN IP range don't fire an update session.
 
-Since the preupdate policy calls the rest of the update chain, you can perform all of your scope limitations to this policy, rather than scoping each and every software deployment policy. Clever!
 
 ![preupdate limitations](images/policy_preudpate_limitations.png)
 
@@ -86,7 +85,7 @@ patchooCheckASU calls `0patchoo.sh --checkasu` which does the following:
 
 #### Scope tab
 
-* Computer Group: `allpatchooClients`
+* Target Computers `All Computers`
 
 ___
 ### [zzz-patchooPromptToInstall](id:patchooPromptToInstall)
@@ -117,7 +116,7 @@ As it MUST be called at the end of an update chain, it's important that's named
 
 #### Scope tab
 
-* Computer Group: `allpatchooClients`
+* Target Computers `All Computers`
 
 
 ___
@@ -148,7 +147,7 @@ If the user is logging out and there are available updates, this policy also pro
 
 #### Scope tab
 
-* Computer Group: `allpatchooClients`
+* Target Computers `All Computers`
 
 ___
 ### [zzz-patchooStartup](id:patchooStartup)
@@ -176,7 +175,7 @@ patchooStartup is responsible for any startup housekeeping. Currently this is li
 
 #### Scope tab
 
-* Computer Group: `allpatchooClients`
+* Target Computers `All Computers`
 
 ___
 ### [zzz-patchooUpdateRemindPrompt](id:patchooUpdateRemindPrompt)