Application usage tracking

[Gregory Neagle]

As some people have guessed by looking at the contents of recent commits, I'm working on adding support for automated removal of unused/under-used apps from clients to Munki: Admins could set certain software to be installed via self-service (optional installs), and if the software was not used (launched/activated) more than a certain number of times over a certain time period, Munki would remove the software.

I know other people have implemented similar things -- I'm wondering what your decision matrix is to decide whether or not to remove an "underused" item.

-Greg

[Nick McSpadden]

We do it purely based on last launch. We track application usage for a specific subset of applications using crankd and store that in a database. We have admin-provided conditionals that check the database for last launch date every time Munki runs.

If the last launch date is > X days (typically 30), the conditional is false which means the manifest adds it to managed_uninstalls (and removes it from SelfServe manifest).

We don't have any accounting for someone who has launched it but left it in the background for weeks.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.
To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Nick McSpadden
nmcsp...@gmail.com

[Mr. Alan Siu]

30 days is aggressive! Is that based on disk space, licensing, or just keeping things clean?

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

[Gregory Neagle]

On Feb 16, 2017, at 10:35 AM, Nick McSpadden <nmcsp...@gmail.com> wrote:

We do it purely based on last launch. We track application usage for a specific subset of applications using crankd and store that in a database. We have admin-provided conditionals that check the database for last launch date every time Munki runs.

If the last launch date is > X days (typically 30), the conditional is false which means the manifest adds it to managed_uninstalls (and removes it from SelfServe manifest).

We don't have any accounting for someone who has launched it but left it in the background for weeks.

Or worse: launched it over 30 days ago and uses it every day but has never quit it in that time?

On Thu, Feb 16, 2017 at 9:17 AM, Gregory Neagle <gregn...@mac.com> wrote:

As some people have guessed by looking at the contents of recent commits, I'm working on adding support for automated removal of unused/under-used apps from clients to Munki:  Admins could set certain software to be installed via self-service (optional installs), and if the software was not used (launched/activated) more than a certain number of times over a certain time period, Munki would remove the software.

I know other people have implemented similar things -- I'm wondering what your decision matrix is to decide whether or not to remove an "underused" item.

-Greg

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.
To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Nick McSpadden
nmcsp...@gmail.com

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Nick McSpadden]

For software that costs $2000 a person when we have to do a licensing audit, it makes a pretty big difference when we're talking about thousands and thousands of people.

[Mr. Alan Siu]

Totally makes sense. I figured it had to be one of the three, and that's certainly the most compelling!

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

[Thistle, Jason]

We have a policy that runs and looks for the program that they use the most then deletes it....just to be jerks.

Jason D. Thistle
Network Manager
Natick Public Schools
(508) 647-6400 x1753

[Stephen Hudak]

Now that sounds fun!

We never delete things… But we don’t really have licensing issues on our Macs. For the most part, we’re licensed for every computer since the only licensing we had to worry about in the past. But now we have an EES agreement with Microsoft and can install Office on EVERY computer.

That being said, it would be nice to say specific apps get removed after not being used for so long as the State of Tennessee Department of Education has dropped multiple testing vendors over the years and a lot of apps were installed prior to me taking over the admin side.

Stephen Hudak | Webmaster and Digital Media Developer
Robertson County Schools
P: 615.384.5588
E: stephe...@rcstn.net
A: 800 M.S. Couts Blvd, Springfield, TN 37172

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Erik Gomez]

Really happy you're working on this. We have the same $2000 software and we're quickly approaching a point where we need to aggressively uninstall it as well. 

[Gregory Neagle]

How do you avoid this scenario:

1) User chooses to install ExpensiveSoftware via optional installs right before lunch. They leave for lunch.

2) Munki runs automatically in the background while the user is at lunch. It notices that the user has not run ExpensiveSoftware even once in the past 30 days, so it uninstalls it.

3) User returns from lunch and is mystified/annoyed that ExpensiveSoftware is not on his/her machine.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Alexander (Mailing List) Taylor]

Have the automated uninstall check the initial install date, don't uninstall if it's less than the 30-day check.  Some receipts should have this information, correct?  Does Munki keep track of installed date another way?

Alexander

The Right-To-Know Law provides that most e-mail communications to or from School District employees regarding the business of the School District are government records available to the public upon request. Therefore, this e-mail communication may be subject to public disclosure.

[A.E. van Bochoven]

On 17 Feb 2017, at 16:20, Alexander (Mailing List) Taylor <ataylo...@orcsd.org> wrote:

Have the automated uninstall check the initial install date, don't uninstall if it's less than the 30-day check.  Some receipts should have this information, correct?  Does Munki keep track of installed date another way?

It does not in a easily parsable format no. There is install.log, but I would not use that atm.

-Arjen

[Gregory Neagle]

I'll clarify my question. For those of you who have already implemented deletion of under-used software (like Nick), how have you avoided that scenario?

Yes, checking the install date could be a solution, but is not easy to do now since Munki doesn't explicitly track install date for software.

-Greg

[Mr. Alan Siu]

Would it be too messy to, for only the $2000-per-seat software, have a pkginfo postinstall script that makes a bogus entry in Crankd's sqlite database of an initial "launch"?

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

The Right-To-Know Law provides that most e-mail communications to or from School District employees regarding the business of the School District are government records available to the public upon request. Therefore, this e-mail communication may be subject to public disclosure.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.
To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gregory Neagle]

I'm rather looking for a generic solution/approach, not one-off hacks.

Also: not using crankd.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Gregory Neagle]

Just a reminder: this is the munki-dev list, for discussion of development issues for Munki: future features; current implementations; bugs; etc.

That's the framework for this "Application usage tracking" discussion.

If we were discussing "how to delete unused software without changing any code in Munki", that would be a great topic for munki-discuss, and we'd be talking about crankd and Google's scripts and clever postinstall scripting, etc.

The intention here is to discuss how best to add this new feature to Munki.

-Greg

[Tim Sutton]

I also imagined something similar, although not necessarily the full (for example) 30 days, but some other configurable, lesser amount.

But yes, Munki then having to track install dates for everything is its own issue that probably has some edge cases. And Greg's example can be taken to more of an extreme - a user who installs new software immediately before travelling far away somewhere, and enough time elapsed at the outset of travel that the grace period is over, and getting the software again while traveling is more complicated.

Was the thinking that the grace period value would be part of an item's pkginfo? I could see value for it being also (or instead) a manifest property, though I'd think that would need its own new key type with a dict structure, similar to conditional_items.

Tim

--

[Gregory Neagle]

On Feb 17, 2017, at 8:17 AM, Tim Sutton <t...@synthist.net> wrote:

I also imagined something similar, although not necessarily the full (for example) 30 days, but some other configurable, lesser amount.

But yes, Munki then having to track install dates for everything is its own issue that probably has some edge cases. And Greg's example can be taken to more of an extreme - a user who installs new software immediately before travelling far away somewhere, and enough time elapsed at the outset of travel that the grace period is over, and getting the software again while traveling is more complicated.

I'm not sure what it is that you are calling the "grace period"...

Was the thinking that the grace period value would be part of an item's pkginfo? I could see value for it being also (or instead) a manifest property, though I'd think that would need its own new key type with a dict structure, similar to conditional_items.

There would almost certainly be new data added to pkginfo to support this feature, yes.

[Mr. Alan Siu]

Sorry, I mentioned crankd, only because that's what Nick said he was using, and I know kMDItemLastUsedDate isn't that reliable.

In terms of this becoming a Munki feature in general (and not just for this $2000-per-seat software), would Munki also have to account for the installation / last-launch date of software that users install themselves (not via Munki) if they have admin privileges?

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

[Gregory Neagle]

On Feb 17, 2017, at 8:28 AM, Mr. Alan Siu <as...@siprep.org> wrote:

Sorry, I mentioned crankd, only because that's what Nick said he was using, and I know kMDItemLastUsedDate isn't that reliable.

In terms of this becoming a Munki feature in general (and not just for this $2000-per-seat software), would Munki also have to account for the installation / last-launch date of software that users install themselves (not via Munki) if they have admin privileges?

The application usage database tracks all application launches, activations, and quits. It does not know or care how the applications were installed. It does not track application installs: AFIAK there is no documented notification event for that sort of thing.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Mr. Alan Siu]

Yes, of course, but I'm following the logic of your hypothetical scenario in which a user installs something and then goes to lunch (or Tim's suggestion it might be a long trip) in which case it may be worth tracking the installation date somehow before the initial launch.

If those are hypotheticals to consider (and they should be), the install date matters, not just the last launch.

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

[Gregory Neagle]

Yes, it might, unless there are other ways to avoid the scenario. Thus, the discussion.

And tracking the install date has its own edge cases.  Some updates/upgrades are really reinstalls. IOW, to upgrade from ExpensiveSoftware-1.0 to ExpensiveSoftware-1.1, Munki must install the ExpensiveSoftware-1.1 package. Does that reset the install date? That could mean:

User chooses via optional installs to install ExpensiveSoftware. The current version in the repo is 1.0.

Munki records the install date for ExpensiveSoftware-1.0.

The user never launches the software, but for the first 30 days Munki will not try to remove it since the install date was less than 30 days ago.

The vendor is on an aggressive update schedule and releases ExpensiveSoftware-1.1 28 days after the user installed ExpensiveSoftware-1.0. Munki installs the update, and records the install date for ExpensiveSoftware-1.1.

User _still_ does not launch the software, but now another month goes by where Munki won't remove the software since it's less than 30 days since the last recorded install for ExpensiveSoftware...

This is not an insurmountable issue; it just illustrates the need to really think through the scenarios and make good choices about implementations.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Mr. Alan Siu]

Going with that line of thinking, another thing to consider is removals and reinstalls. So if, for example, the Munki client were to keep track of just the first installation (1.0) and not the upgrade installation (1.1), it would also have to keep track of the item's removal date.

Suppose a user installs version 1.0 February 1. Doesn't launch the application.

Munki upgrades the application to 1.1 on February 28. User still hasn't launched the application.

User removes the application on March 2.

User reinstalls the application on March 10. and still hasn't launched it but plans to later that day.

If the Munki client just keeps track of the original 1.0 version installation (and assuming 30 days before automatic removal for this item), it will try to remove the application on March 10, even though it was just installed that day.

If, however, as you noted, the Munki client keeps track of only the most recent version installation, a never-launched application would never be removed as long as newer versions keep getting installed within the 30-day (or however many days decided by the pkginfo) period.

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

[Gregory Neagle]

Perhaps what should be tracked is the date the user chose the item for install via MSC -- not any dates where managedsoftwareupdate installed things.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Mr. Alan Siu]

That seems like a pretty clean way to approach it, so Munki would have to have some timestamp for when an optional install got selected.

It wouldn't account for users with admin privileges installing the app sans Munki, but maybe that's too much of a fringe scenario, and it's not really Munki's job to keep track of stuff that happens outside of Munki.

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

[Gregory Neagle]

One could argue that's expected (or at least not _unexpected_) behavior --  that users are not expected to manually install ExpensiveSoftware without using Managed Software Center, and if they do it might get removed.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Gregory Neagle]

On Feb 17, 2017, at 9:02 AM, Mr. Alan Siu <as...@siprep.org> wrote:

That seems like a pretty clean way to approach it, so Munki would have to have some timestamp for when an optional install got selected.

Of course, tracking that turns out to be harder than you might expect, since user interactions with MSC run in a non-privileged user context and the data really needs to be recorded as root. So we'd have to build a message-passing mechanism...

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Erik Gomez]

Hidden folder in /User/Shared for the interim or something to that effect.

[A.E. van Bochoven]

On 17 Feb 2017, at 18:09, Gregory Neagle <gregn...@mac.com> wrote:

Of course, tracking that turns out to be harder than you might expect, since user interactions with MSC run in a non-privileged user context and the data really needs to be recorded as root. So we'd have to build a message-passing mechanism...

Why not store it in the AppUsage db as an ‘install’ event?

-Arjen

[Gregory Neagle]

Same problem.

User is clicking a button in MSC. We need to send an event to the app_usage_tracker process. And additionally, we get to map between install_items (like "MicrosoftOffice2016") and applications (like Word.app, Excel.app, PowerPoint.app, etc)

-Greg

[A.E. van Bochoven]

On 17 Feb 2017, at 18:20, Gregory Neagle <gregn...@mac.com> wrote:

Same problem.

User is clicking a button in MSC. We need to send an event to the app_usage_tracker process.

But the actual install is done by root (which can update the db)

And additionally, we get to map between install_items (like "MicrosoftOffice2016") and applications (like Word.app, Excel.app, PowerPoint.app, etc)

You would need to add the app name(s) to the pkginfo file, like the blocking_applications array..

-Arjen

[Mr. Alan Siu]

Could whatever process is modifying SelfServeManifest also put the data of the event in a log file?

But, yes, there is the added complication of the install item not necessarily being the application. This may also warrant a similar Wiki entry to "how does Munki know what to install/remove" which would be "how does Munki decide what stale items haven't been used in a while that need to be removed."

Would it be overkill to have a separate key for what application to track? And if that key isn't present the removal-after-X-days key is ignored?

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

--

Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.

[Gregory Neagle]

On Feb 17, 2017, at 9:22 AM, A.E. van Bochoven <ne...@me.com> wrote:

On 17 Feb 2017, at 18:20, Gregory Neagle <gregn...@mac.com> wrote:

Same problem.

User is clicking a button in MSC. We need to send an event to the app_usage_tracker process.

But the actual install is done by root (which can update the db)

But we only want to track the user-initiated install, and not any subsequent update install. So attaching to a managedsoftwareupdate install run would not be the right place.

And additionally, we get to map between install_items (like "MicrosoftOffice2016") and applications (like Word.app, Excel.app, PowerPoint.app, etc)

You would need to add the app name(s) to the pkginfo file, like the blocking_applications array..

Yes -- and we'll need to do that anyway so Munki knows which apps to check usage for. I'm considering using application items from the installs array as a fallback, though so admins don't have to manually populate such an array in the common case.

[Gregory Neagle]

Still looking for details on how Nick McSpadden and Wes Wetstone (and their orgs) are handling these issues. Seems a shame to reinvent the wheel.

-Greg

[Gregory Neagle]

I meant of course "Wes Whetstone". Sorry 'bout that...

-Greg

[Nick McSpadden]

We add the install time to the application tracking database so that the day they install it counts as the "first launch," for tracking purposes.  So they basically get 30 days past when they installed it at a very minimum before Munki will consider uninstalling it due to lack of usage.

On Fri, Feb 17, 2017 at 9:37 AM, Gregory Neagle <gregn...@mac.com> wrote:

I meant of course "Wes Whetstone". Sorry 'bout that...

-Greg

On Feb 17, 2017, at 9:32 AM, Gregory Neagle <gregn...@mac.com> wrote:

Still looking for details on how Nick McSpadden and Wes Wetstone (and their orgs) are handling these issues. Seems a shame to reinvent the wheel.

-Greg

On Feb 17, 2017, at 9:28 AM, Gregory Neagle <gregn...@mac.com> wrote:

On Feb 17, 2017, at 9:22 AM, A.E. van Bochoven <ne...@me.com> wrote:

On 17 Feb 2017, at 18:20, Gregory Neagle <gregn...@mac.com> wrote:

Same problem.

User is clicking a button in MSC. We need to send an event to the app_usage_tracker process.

But the actual install is done by root (which can update the db)

But we only want to track the user-initiated install, and not any subsequent update install. So attaching to a managedsoftwareupdate install run would not be the right place.

And additionally, we get to map between install_items (like "MicrosoftOffice2016") and applications (like Word.app, Excel.app, PowerPoint.app, etc)

You would need to add the app name(s) to the pkginfo file, like the blocking_applications array..

Yes -- and we'll need to do that anyway so Munki knows which apps to check usage for. I'm considering using application items from the installs array as a fallback, though so admins don't have to manually populate such an array in the common case.

-Arjen

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+unsubscribe@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Nick McSpadden
nmcsp...@gmail.com

[Gregory Neagle]

On Feb 17, 2017, at 10:31 AM, Nick McSpadden <nmcsp...@gmail.com> wrote:

We add the install time to the application tracking database so that the day they install it counts as the "first launch," for tracking purposes.  So they basically get 30 days past when they installed it at a very minimum before Munki will consider uninstalling it due to lack of usage.

Could you share details on how you do that?

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

[Timo Lemburg]

The approach we are going for different configurations (mostly nopkg stuff) is to write our installations in a com.mycompany.plist in Library/Preferences. If I would have to make app usage tracking like in this case I would go the same route. 

So on install on ExpensiveApp-1.0 I would write the install date into com.mycompany.plist as „ExpensiveApp DateInFormatThatSuitsMe“. An installation of ExpensiveApp-1.1 would see the already existing entry in the plist and wouldn’t change anything while a new installation of the app without 1.0 being present already would write the install date in the plist.

In this case I would have to remove the plist entry on uninstall of the app as postuninstall_script, but that’s fine for me.

I guess this is just a way too easy for the purpose of this list, but that’s the way I’d use.

Regards,

Timo

[Tim Sutton]

By "grace period" here I meant the "other configurable, lesser amount" I suggested - in other words, a length of time since the user first installs software, during which if Munki runs and sees it has not yet been used at least once, that it doesn't then go and auto-remove it.

Again, just thinking out loud, this might be just adding too much complexity. If your default "lease" for a license is only 30 days, then Alexander's suggestion of just not removing it if it's been less than 30 days could be an appropriate amount of slack for many orgs who currently have no regimented usage auditing for expensive licenses.

Tim

[Nick McSpadden]

To be more specific about the process:

We store the information in an sqlite database locally on the client.

In the Munki postinstall and postuninstall scripts for the specific targeted software, we call the scripts that add the time into the application usage database, and to turn on tracking of its usage via crankd. When the software is uninstalled, we remove it from the database.

crankd is locally installed as well to track application launches, and every time it detects a launch of this app, it updates the time in the sqlite database.

There are Munki conditionals we provide that query the app usage database and determine if the last time entered was > X days ago (say, 30), and if so, the conditional is false. The Munki manifests include an "app_removals" manifests that adds the items to `managed_uninstalls` should these conditionals be false.

So if someone installs Tableau today, upon installation it gets inserted into the sqlite database as 2/18/17. If they don't launch it for 30 days, when Munki runs, it will see that the last time it was "used" was > 30 days ago, and then the Munki manifest conditional triggers and adds it to managed_uninstalls.



In regards to a Munki-specific implementation, I don't think it needs to be so elaborate (and I'd frankly be happy to simplify our approach, but it hasn't been touched in a while and no one wants to fix what isn't broken).

[Wesley Whetstone]

Apologies on my tartiness to the party here. Our implementation of this is very similar to that of Mr. McSpadden's. One thing we did that may be of help is at the end of each munki run we do a comparison between the application usage database and Apps that are installed on the machine. If there is an app that is installed on the machine but isn't found in the database we write to the database saying that is was launched at the time of the run. Same goes for the reverse. If we notice there is usage information for an app that is no longer installed we remove it from the database. This solved our problem of accidental uninstalls of apps that may have been installed before, removed and then needed again. Other than that everything seems close to our implementation. 

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

--
Nick McSpadden
nmcsp...@gmail.com

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---
You received this message because you are subscribed to the Google Groups "munki-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Gregory Neagle]

I was kind of hoping for references _before_ I implemented the built-in support, but thanks anyway...

-Greg