License seat tracking

[Gregory Neagle]

Warning: long post ahead.

I'm working on a new feature (initially for internal use, but hoping to build it so it would be more generally useful) and am looking for some opinions.

We want to move a larger number of our software packages to "Self-Service" via Optional installs.

Items that are free, open source, or for which we have site licenses are no problem; they can just be added to optional_installs.

But we'd like to add software for which we have a limited number of license seats as well.

I've extended MunkiWebAdmin so it does basic license seat tracking: it knows how many machines have a given piece of software thanks to the existing application inventory and some queries; we can tell it how many seats we've purchased.  See the first attached picture for the idea.

Next, managedsoftwareupdate can ask the server for the number of available seats for a given item and record that info in InstallInfo.plist.

Managed Software Update.app can use that information to "disable" the availability of items in optional_installs that do not have available seats. See the second attached picture.

Note that the checkbox for Adobe Photoshop CS5 is grayed-out and the Status has been updated to tell the user there are no available seats.

This behavior of course will be completely optional/opt-in; the admin will (at a minimum) need to set a LicenseInfoURL key in the ManagedInstalls preferences.

Initially this will _only_ affect optional_installs. If an item is in managed_installs, it was put there by an administrator. That administrator intends to install an item, so Munki will install it without checking for available seats. Only when processing optional installs will this mechanism be invoked.

A few things I have not yet decided upon:

1) Should there be a pkginfo key that controls this behavior on a per-item basis, or should managedsoftwareupdate ask the server for available seats for every item in optional_installs? The latter is simpler and less likely for an admin to screw up; but if the majority of software in optional_installs does not have license tracking data, that could be a lot of unnecessary web requests.

2) Right now the Item name as seen in the first attached photo (the Licenses view in MWA) _must_ match the item name in pkginfo. Should this be more flexible somehow?

Current limitations of this approach and ideas for the future:

The third attached photo should provide an idea on what data is used to track license seat usage.

MunkiWebAdmin finds inventory records based on application name, bundleid, bundlename, or full pathname, and can also filter based on version number.

In the provided example, records with a bundleid of "com.microsoft.Word" and version starting with "14." count as an Office 2011 install.

To accurately track a license seat, you must find an application/version combination that is unique to that product -- in the case of Adobe CSx products, the Uninstaller application is actually the unique thing (and can tell the difference between an install of Photoshop CS6 and one of the suites that includes Photoshop CS6).

Currently this allows you to only track applications. There's no way currently to track other, non-application software like fonts or Photoshop plugins. I have some ideas on how to address that in a generic manner in the future.

You can also use this mechanism to track other things, even if you don't really care about license seats:

You could get this information out of MWA other ways, but this might be more convenient or non-techy friendly...

The implementation used by the clients is simple enough that it should be easy to add to, say, Simian or MunkiServer. The client requests

<LicenseInfoURL>itemname

Where <LicenseInfoURL> is a partial URL to the web(?) service, for example "http://mwa/licenses/available/"

and 'itemname" is the name key from the pkginfo item. So a full request would be something like an GET request to http://mwa/licenses/available/AdobePhotoshopCS6

The server needs to return one of two types of info. Either a simple number of available seats, or a plist-formated dictionary:

% curl http://mwa/licenses/available/AutoCAD2013

5

or

% curl http://mwa/licenses/usage/AutoCAD2013

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>available</key>

<integer>5</integer>

<key>item_name</key>

<string>AutoCAD2013</string>

<key>total</key>

<integer>10</integer>

<key>used</key>

<integer>5</integer>

</dict>

</plist>

Currently the only key/value used in the plist-formatted dictionary is the "available" key.

Before you ask "why couldn't it be JSON?" -- Python on Leopard does not come with a json module. So plain text and plist are the two supported formats.

Please send along any thoughts or feedback you might have. I intend to start simple; the first version of this may be pretty basic. But if there is something major or important I should be considering earlier rather than later, please let me know.

-Greg

[Josh Malone]

Well, this just might be the killer feature that makes me invest the time to set up MWA (dammit :)

I will say that I have (what I think is) a fair number of optional installs and extra web requests for most of them might be a bummer. Not sure, in practice...

-Josh

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Ken Elliott]

WOW,

echo , Josh's comments,

That would be a yes for

1) Should there be a pkginfo key that controls this behavior on a per-item basis, 

Have been a bit slow on doing the MWA, but installing now…

Thank you

Ken

On 3/07/2013, at 1:08 PM, Josh Malone <josh....@gmail.com> wrote:

Well, this just might be the killer feature that makes me invest the time to set up MWA (dammit :)

I will say that I have (what I think is) a fair number of optional installs and extra web requests for most of them might be a bummer. Not sure, in practice...

-Josh

On Tue, Jul 2, 2013 at 8:04 PM, Gregory Neagle <gregn...@mac.com> wrote:

Warning: long post ahead.

I'm working on a new feature (initially for internal use, but hoping to build it so it would be more generally useful) and am looking for some opinions.

We want to move a larger number of our software packages to "Self-Service" via Optional installs.

Items that are free, open source, or for which we have site licenses are no problem; they can just be added to optional_installs.

But we'd like to add software for which we have a limited number of license seats as well.

I've extended MunkiWebAdmin so it does basic license seat tracking: it knows how many machines have a given piece of software thanks to the existing application inventory and some queries; we can tell it how many seats we've purchased.  See the first attached picture for the idea.

<MWA_licenses.png>

Next, managedsoftwareupdate can ask the server for the number of available seats for a given item and record that info in InstallInfo.plist.

Managed Software Update.app can use that information to "disable" the availability of items in optional_installs that do not have available seats. See the second attached picture.

<MSU.png>

Note that the checkbox for Adobe Photoshop CS5 is grayed-out and the Status has been updated to tell the user there are no available seats.

This behavior of course will be completely optional/opt-in; the admin will (at a minimum) need to set a LicenseInfoURL key in the ManagedInstalls preferences.

Initially this will _only_ affect optional_installs. If an item is in managed_installs, it was put there by an administrator. That administrator intends to install an item, so Munki will install it without checking for available seats. Only when processing optional installs will this mechanism be invoked.

A few things I have not yet decided upon:

1) Should there be a pkginfo key that controls this behavior on a per-item basis, or should managedsoftwareupdate ask the server for available seats for every item in optional_installs? The latter is simpler and less likely for an admin to screw up; but if the majority of software in optional_installs does not have license tracking data, that could be a lot of unnecessary web requests.

2) Right now the Item name as seen in the first attached photo (the Licenses view in MWA) _must_ match the item name in pkginfo. Should this be more flexible somehow?

Current limitations of this approach and ideas for the future:

<MWA_licenses3.png>

The third attached photo should provide an idea on what data is used to track license seat usage.

MunkiWebAdmin finds inventory records based on application name, bundleid, bundlename, or full pathname, and can also filter based on version number.

In the provided example, records with a bundleid of "com.microsoft.Word" and version starting with "14." count as an Office 2011 install.

<MWA_licenses2.png>

To accurately track a license seat, you must find an application/version combination that is unique to that product -- in the case of Adobe CSx products, the Uninstaller application is actually the unique thing (and can tell the difference between an install of Photoshop CS6 and one of the suites that includes Photoshop CS6).

Currently this allows you to only track applications. There's no way currently to track other, non-application software like fonts or Photoshop plugins. I have some ideas on how to address that in a generic manner in the future.

You can also use this mechanism to track other things, even if you don't really care about license seats:

<PastedGraphic-1.png>

[Gregory Neagle]

The feature is not currently available in MWA...

Sent from my iPhone

[Ken Elliott]

Understand, but still need to get it to work, be familiar, etc

I have been following the MWA from the start, and was happy with, still am with php-munkireports.

I didn't see the reason to install Django.

Strangely enough my first google search this morning was "why use Django"

-ken

[Erik]

MWA doesn't take very long to setup. I took my time with it and in less than an hour it was running beautifully. If you send it out unattended with munki, you get to watch the "fun" happen as your clients begin to run the pre/posts.

Greg: This looks like a very useful feature. I think the .plist is the route to go for now. I'm going to think about it and come back to this.

Is this a munki 2 planned feature, or on the road map to 1.0?

[Erik]

Pkginfo, not .plist.

[Joe Wollard]

A few things I have not yet decided upon:

1) Should there be a pkginfo key that controls this behavior on a per-item basis, or should managedsoftwareupdate ask the server for available seats for every item in optional_installs? The latter is simpler and less likely for an admin to screw up; but if the majority of software in optional_installs does not have license tracking data, that could be a lot of unnecessary web requests.

I like the latter, It does mean we'd be requiring a munki "server" in order to take advantage of all features, but to be honest I can't believe it's taken this long for that to happen!

Something I would do to minimize calls to the web server is combine them into a single request. Combining them into a nice clean GET url might not be trivial, but you could always send them via POST (which seems unintuitive since you want to 'GET' information), or with custom HTTP headers, such as X-Munki-AvailableSeatsFor-[0-9]+: <pkginfoname>.

curl --header "X-Munki-AvailableSeatsFor-0: AutoCAD2013" \

      --header "X-Munki-AvailableSeatsFor-1: AdobePhotoshopCS6" \

      http://mwa/licenses/available

The server should then be expected to respond in the order asked:

5, 100

...plist output could be a top-level array of dictionaries instead of a single dict. That wouldn't be a ton of work server-side, but I'm not sure if I'm underestimating how easy it would be to for Munki on the client machine.

2) Right now the Item name as seen in the first attached photo (the Licenses view in MWA) _must_ match the item name in pkginfo. Should this be more flexible somehow?

Can't see any reason that it should be. The `name` field has always been the true identifier of the installer item, so it makes sense that we would want to tie licenses and seats to that same value.

 

[Gregory Neagle]

On Jul 2, 2013, at 8:30 PM, Joe Wollard <joe.w...@gmail.com> wrote:

A few things I have not yet decided upon:

1) Should there be a pkginfo key that controls this behavior on a per-item basis, or should managedsoftwareupdate ask the server for available seats for every item in optional_installs? The latter is simpler and less likely for an admin to screw up; but if the majority of software in optional_installs does not have license tracking data, that could be a lot of unnecessary web requests.

I like the latter, It does mean we'd be requiring a munki "server" in order to take advantage of all features, but to be honest I can't believe it's taken this long for that to happen!

We'd require a server in either scenario.

Scenario #1: key in pkginfo tells Munki that this item has limited seats, so Munki asks the server for available seats.

Scenario #2: Munki just asks for available seats for all uninstalled items in optional_installs. If a large number of these have no licensing info, then this is wasted effort/bandwidth/server CPU/etc.

The pkginfo key would be used to tell the Munki client to ask for license/seat information; it would not _contain_ that information, though if you are the developers of Simian or MunkiServer it might make sense to inject that info into the the catalog(s) returned to the client.

Something I would do to minimize calls to the web server is combine them into a single request.

That's an interesting idea.

Currently it's legal (and expected) for the server to return empty data to say "I have no information":

% curl http://mwa/licenses/usage/foo

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

</dict>

</plist>

or 

% curl http:/mwa/licenses/available/foo

% 

So we'd have to handle that. If we request info for multiple items at once, I think I'd want to support _only_ plist returns; it would just be a list of dictionaries:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<array>

    <dict>

            <key>available</key>

            <integer>199</integer>

    <key>item_name</key>

    <string>MicrosoftOffice2008</string>

    <key>total</key>

    <integer>200</integer>

    <key>used</key>

    <integer>1</integer>

    </dict>

    <dict>

            <key>available</key>

            <integer>149</integer>

    <key>item_name</key>

    <string>MicrosoftOffice2011</string>

    <key>total</key>

    <integer>200</integer>

    <key>used</key>

    <integer>51</integer>

    </dict>

</array>

</plist>

or this structure(a dict containing dicts):

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">

<plist version="1.0">

<dict>

<key>MicrosoftOffice2008</key>

<dict>

            <key>available</key>

            <integer>199</integer>

    <key>total</key>

    <integer>200</integer>

    <key>used</key>

    <integer>1</integer>

</dict>

<key>MicrosoftOffice2011</key>

<dict>

            <key>available</key>

            <integer>149</integer>

    <key>total</key>

    <integer>200</integer>

    <key>used</key>

    <integer>51</integer>

</dict>

</dict>

</plist>

Combining them into a nice clean GET url might not be trivial,

No, it's trivial if you don't care about pretty urls (which I don't for this purpose):

http://mwa/licenses/usage?name=foo&name=bar&name=baz

All of this is probably no problem for me to implement in MWA; I don't know if that makes alternative implementations more difficult.

but you could always send them via POST (which seems unintuitive since you want to 'GET' information), or with custom HTTP headers, such as X-Munki-AvailableSeatsFor-[0-9]+: <pkginfoname>.

curl --header "X-Munki-AvailableSeatsFor-0: AutoCAD2013" \

      --header "X-Munki-AvailableSeatsFor-1: AdobePhotoshopCS6" \

      http://mwa/licenses/available

The server should then be expected to respond in the order asked:

5, 100

...plist output could be a top-level array of dictionaries instead of a single dict. That wouldn't be a ton of work server-side, but I'm not sure if I'm underestimating how easy it would be to for Munki on the client machine.

I think it would be pretty easy to deal with on the client. Munki already knows how to request and deal with plists from a web server!

2) Right now the Item name as seen in the first attached photo (the Licenses view in MWA) _must_ match the item name in pkginfo. Should this be more flexible somehow?

Can't see any reason that it should be. The `name` field has always been the true identifier of the installer item, so it makes sense that we would want to tie licenses and seats to that same value.

That was my thinking as well, but just wanted to see if anyone could think of a reason to make it more flexible.

One thing I already ran into was that for a few products the Munki "name" wasn't as "boss-friendly" as I'd like, so I toyed with having a "display name" just as managedsoftwareupdate/MSU.app do...

-Greg

[Samuel Keeley]

I would think that method #2, asking the server for license availability for each item, would be better, and easier to extend to non-MWA implementations, especially since we'd be adding a new URL into /Library/Preferences/ManagedInstalls.plist.

For example, a munki repo could remain static, with no changes needed to any current pkginfos.  The rest of this could just be added in to MWA or another license management/reporting tool.

One more thing, it might be nice to have the option to hide items that are out of licenses from the optional installs list, or put them at the bottom.  I know a lot of these lists would be quickly filled up with items starting with "Adobe."

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Samuel Keeley

[Gregory Neagle]

On Jul 2, 2013, at 9:52 PM, Samuel Keeley <sam.k...@gmail.com> wrote:

I would think that method #2, asking the server for license availability for each item, would be better, and easier to extend to non-MWA implementations, especially since we'd be adding a new URL into /Library/Preferences/ManagedInstalls.plist.

I think I must not be making myself clear.

In the implementation I am proposing (and coding), the client will make a request of a URL to get license info for optional_installs items that are not currently installed.

That part is not in question. In question:

Should there be a pkginfo key that tells Munki "there should be license info available for this item, so ask for it". If that key is missing or false, Munki doesn't bother asking. That way we don't bother querying for information that's not on the server anyway.

For example, a munki repo could remain static, with no changes needed to any current pkginfos.  The rest of this could just be added in to MWA or another license management/reporting tool.

Yes, that is the intention.

One more thing, it might be nice to have the option to hide items that are out of licenses from the optional installs list, or put them at the bottom.  

The plan for now is to leave them in the list, but disabled so they cannot be chosen for install, and tagged with a status message that says why they are unavailable. The though process here is that users then would surface the need for us to either buy additional licenses, or do an audit to see if we can recover unused/underutilized seats.

I know a lot of these lists would be quickly filled up with items starting with "Adobe."

If you have a lot of unavailable Adobe apps in your optional installs and unmet demand for them, wouldn't you want to know? You could always just remove them from the optional_installs list if all licenses are used and there are no current plans to buy more.

-Greg

[A.E. van Bochoven]

Great idea, I currently use an included manifest with conditional items based on serial number to manage the apps that have limited licenses. This is fine for single licenses, but would be unwieldly for licenses that run in the tens or hundreds.

I'm in favor of (also) putting the license requirement in the pkginfo file, because of the following reason:

Say MWA dies for some reason, maybe a software patch killed python, no software can be installed anymore because the amount of seats cannot be determined anymore, even for the unlimited-license apps.

I would like the unlimited-licensed apps to be installed wether mwa runs or not. 

-Arjen

PS If you could provide a well described api, I'm sure we will be able to add this feature to munkireport-php as well.

On 3 jul. 2013, at 02:04, Gregory Neagle <gregn...@mac.com> wrote:

Warning: long post ahead.

I'm working on a new feature (initially for internal use, but hoping to build it so it would be more generally useful) and am looking for some opinions.

We want to move a larger number of our software packages to "Self-Service" via Optional installs.

Items that are free, open source, or for which we have site licenses are no problem; they can just be added to optional_installs.

But we'd like to add software for which we have a limited number of license seats as well.

I've extended MunkiWebAdmin so it does basic license seat tracking: it knows how many machines have a given piece of software thanks to the existing application inventory and some queries; we can tell it how many seats we've purchased.  See the first attached picture for the idea.

<MWA_licenses.png>

Next, managedsoftwareupdate can ask the server for the number of available seats for a given item and record that info in InstallInfo.plist.

Managed Software Update.app can use that information to "disable" the availability of items in optional_installs that do not have available seats. See the second attached picture.

<MSU.png>

Note that the checkbox for Adobe Photoshop CS5 is grayed-out and the Status has been updated to tell the user there are no available seats.

This behavior of course will be completely optional/opt-in; the admin will (at a minimum) need to set a LicenseInfoURL key in the ManagedInstalls preferences.

Initially this will _only_ affect optional_installs. If an item is in managed_installs, it was put there by an administrator. That administrator intends to install an item, so Munki will install it without checking for available seats. Only when processing optional installs will this mechanism be invoked.

A few things I have not yet decided upon:

1) Should there be a pkginfo key that controls this behavior on a per-item basis, or should managedsoftwareupdate ask the server for available seats for every item in optional_installs? The latter is simpler and less likely for an admin to screw up; but if the majority of software in optional_installs does not have license tracking data, that could be a lot of unnecessary web requests.

2) Right now the Item name as seen in the first attached photo (the Licenses view in MWA) _must_ match the item name in pkginfo. Should this be more flexible somehow?

Current limitations of this approach and ideas for the future:

<MWA_licenses3.png>

The third attached photo should provide an idea on what data is used to track license seat usage.

MunkiWebAdmin finds inventory records based on application name, bundleid, bundlename, or full pathname, and can also filter based on version number.

In the provided example, records with a bundleid of "com.microsoft.Word" and version starting with "14." count as an Office 2011 install.

<MWA_licenses2.png>

To accurately track a license seat, you must find an application/version combination that is unique to that product -- in the case of Adobe CSx products, the Uninstaller application is actually the unique thing (and can tell the difference between an install of Photoshop CS6 and one of the suites that includes Photoshop CS6).

Currently this allows you to only track applications. There's no way currently to track other, non-application software like fonts or Photoshop plugins. I have some ideas on how to address that in a generic manner in the future.

You can also use this mechanism to track other things, even if you don't really care about license seats:

<PastedGraphic-1.png>

[Adam Reed]

I would vote for using a display name. I find that most of the "name" keys are fine, but there are numerous times when the staff try to add an item to a manifest and complain that they can't find it (for example I have Flash Player as name: FlashPlayer, but display_name:  Adobe Flash Player). It's a little more annoying as you have to fall back to "name" if display_name isn't set however. 

Underneath MWA and Munki should use name, but display_name is potentially more human friendly.

[Edward Marczak]

We're kind of doing this with Simian, and we're already on the self-service model you describe, but we're not relying on this for the actual license counts. Largely because we're not tracking uninstalls. For example, someone installs Office, and that uses a license. Now, instead of using Munki to uninstall, they just drag it to the trash. The receipt is still there, of course, but that machine really isn't using a license any longer. If you have some way to deal with that, then depending on these license counts becomes much more reasonable.

--
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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Edward Marczak
w: http://www.radiotope.com/writing
p: http://profiles.google.com/edwardmarczak

[Gregory Neagle]

On Jul 2, 2013, at 10:44 PM, A.E. van Bochoven <ne...@mac.com> wrote:

Great idea, I currently use an included manifest with conditional items based on serial number to manage the apps that have limited licenses. This is fine for single licenses, but would be unwieldly for licenses that run in the tens or hundreds.

I'm in favor of (also) putting the license requirement in the pkginfo file, because of the following reason:

Say MWA dies for some reason, maybe a software patch killed python, no software can be installed anymore because the amount of seats cannot be determined anymore, even for the unlimited-license apps.

That's not really a problem for either implementation; if the license info server isn't responding, it moves on; it does not stop managedsoftwareupdate in its tracks; the only question is: when the LicenseInfoURL is not responding, should we make the application(s) available for install or not?

If we don't know _if_ there is license info for a given piece of software and we're asking for each uninstalled optional item, if the LicenseInfoURL is not responding, we should probably default to making the item available for install.

If, on the other hand, we know there is license info "on file" (because of the existence of a key in the pkginfo), if the LicenseInfoURL is not responding, we should probably default to making the item NOT available for install.

I would like the unlimited-licensed apps to be installed wether mwa runs or not. 

They would be.

-Arjen

PS If you could provide a well described api, I'm sure we will be able to add this feature to munkireport-php as well.

I did! And I expect it will be easy to add to munkireposrt-php. I'll repeat the current implementation:

The client makes a request of the form:

<LicenseInfoURL><itemname>

Where <LicenseInfoURL> is a partial URL to the web(?) service, for example "http://mwa/licenses/available/"
and <itemname> is the name key from the pkginfo item. 

An example: The LicenseInfoURL is "http://mwa/licenses/available/", and the item we want license info for is "AdobePhotoshopCS6".

So a full request would be a GET request to http://mwa/licenses/available/AdobePhotoshopCS6

This URL needs to return one of two types of info. Either a simple number of available seats, or a plist-formated dictionary:

[Gregory Neagle]

On Jul 2, 2013, at 10:54 PM, Adam Reed <adam...@ANU.EDU.AU> wrote:

I would vote for using a display name. I find that most of the "name" keys are fine, but there are numerous times when the staff try to add an item to a manifest and complain that they can't find it (for example I have Flash Player as name: FlashPlayer, but display_name:  Adobe Flash Player).

If they are using MunkWebAdmin, wouldn't they just type "Flash" and choose from the autocomplete suggestions?

For license tracking, I worry that adding a display name will obscure or confuse the relationship between the name of the license tracking record and the name of the software item being tracked. People might expect the display name was linked in some way to the display name of the item being tracked, where that would not be the case.

[Harry Fike]

For the problem you described, you could use an Installs array that keeps putting the software back until they decide to uninstall it correctly. Not really a good way to fix a lazy/ignorant human error!

-- 

Harry

On Wednesday, July 3, 2013 8:19:06 AM UTC-4, marczak wrote:

We're kind of doing this with Simian, and we're already on the self-service model you describe, but we're not relying on this for the actual license counts. Largely because we're not tracking uninstalls. For example, someone installs Office, and that uses a license. Now, instead of using Munki to uninstall, they just drag it to the trash. The receipt is still there, of course, but that machine really isn't using a license any longer. If you have some way to deal with that, then depending on these license counts becomes much more reasonable.

[Gregory Neagle]

On Jul 3, 2013, at 5:19 AM, Edward Marczak <mar...@radiotope.com> wrote:

> We're kind of doing this with Simian, and we're already on the self-service model you describe, but we're not relying on this for the actual license counts. Largely because we're not tracking uninstalls. For example, someone installs Office, and that uses a license. Now, instead of using Munki to uninstall, they just drag it to the trash. The receipt is still there, of course, but that machine really isn't using a license any longer. If you have some way to deal with that, then depending on these license counts becomes much more reasonable.

This is not a problem for my current implementation, as it uses the application inventory feature of Munki/MunkiWebAdmin to track application installs. This is an inventory of applications found on the machine. It's not dependent on pkg receipts.

In your scenario, if the user drags Office to the trash (and empties it), the application inventory for that machine would no longer list Office applications, and so a license seat would become available.

-Greg

[Ricky Chilcott]

What happens if the client takes too long to install and will put you over your license count?

For instance, if the user goes to optional installs, chooses a product that has 2 seats remaining. Munki will then download that installer, but won't install yet. Then, the user waits 5 days because they get interrupted or go on vacation. When they finally install, however, the 2 remaining licenses have been used.

Munki should check the LicenseURL to make sure there is still a license available before actually installing and not let the user install until more licenses have been purchased.

Ricky Chilcott
ri...@rickychilcott.com

[Gregory Neagle]

On Jul 3, 2013, at 6:41 AM, Ricky Chilcott <ri...@rickychilcott.com> wrote:

> What happens if the client takes too long to install and will put you over your license count?
>
> For instance, if the user goes to optional installs, chooses a product that has 2 seats remaining. Munki will then download that installer, but won't install yet. Then, the user waits 5 days because they get interrupted or go on vacation. When they finally install, however, the 2 remaining licenses have been used.
>
> Munki should check the LicenseURL to make sure there is still a license available before actually installing and not let the user install until more licenses have been purchased.

The initial implementation will not do this. It will indeed be possible to exceed available licenses. Another scenario:

There is one remaining license seat. Two people run MSU at approximately the same time. MSU shows the app as available; both select it and install it at approximately the same time.

Even if Munki checked right be before install, it would miss this issue, and you'd end up with one install over your available count.

If you see this as a major potential problem - underreport your available licenses! IOW, keep a few back.

If you only _have_ a handful of licenses in the first place (and the item is in demand), putting it in optiona_installs may not be the best strategy. Use existing management methods to control which machines get the very few available installs.

-Greg

[Ricky Chilcott]

Sure, there certainly are race conditions that pose problems. I'm just trying to avoid the multi-day issue, which for faculty at a university tends to be the rule rather than the exception.

Perhaps there could be logic to remove the item from being installed if upon the next munki run (an hour from now), the user has still not installed and there are no licenses?

Ricky Chilcott
ri...@rickychilcott.com

[Joe Wollard]

For the sake of verbosity, could you explain _when_ the (web)server would know to decrement its available seat count? It sounds like you're currently having MWA infer this event by examining the install history for each machine. Just want to be sure msu isn't expecting to be able to explicitly tell the server "Hey, using a seat here boss".

Although, perhaps a slight variation of the latter would be interesting since it could let mwa mark a seat as "reserved", but not "used" until it actually is; programmatically 'holding a few back' for you.




---
Joe Wollard

[Gregory Neagle]

On Jul 3, 2013, at 7:12 AM, Ricky Chilcott <ri...@rickychilcott.com> wrote:

> Sure, there certainly are race conditions that pose problems. I'm just trying to avoid the multi-day issue, which for faculty at a university tends to be the rule rather than the exception.
>
> Perhaps there could be logic to remove the item from being installed if upon the next munki run (an hour from now), the user has still not installed and there are no licenses?

Good request.

[Gregory Neagle]

On Jul 3, 2013, at 7:12 AM, Joe Wollard <joe.w...@gmail.com> wrote:

> For the sake of verbosity, could you explain _when_ the (web)server would know to decrement its available seat count?

In my implementation, it doesn't increment _or_decrement it's count. It simply counts the installations it knows about (via the inventory table).

> It sounds like you're currently having MWA infer this event by examining the install history for each machine. Just want to be sure msu isn't expecting to be able to explicitly tell the server "Hey, using a seat here boss".

It communicates it's using a seat by _installing_ the software and then reporting that via the application inventory.

>
> Although, perhaps a slight variation of the latter would be interesting since it could let mwa mark a seat as "reserved", but not "used" until it actually is; programmatically 'holding a few back' for you.

Thought about that; decided it was more complex to implement than I was willing to do.

Ultimately the application inventory is truth.

-Greg

[Gregory Neagle]

On Jul 3, 2013, at 7:12 AM, Ricky Chilcott <ri...@rickychilcott.com> wrote:

> Sure, there certainly are race conditions that pose problems. I'm just trying to avoid the multi-day issue, which for faculty at a university tends to be the rule rather than the exception.
>
> Perhaps there could be logic to remove the item from being installed if upon the next munki run (an hour from now), the user has still not installed and there are no licenses?

Upon further reflection: how would we communicate to the user what happened here?

I think it's probably unusual for a user to select software to install from Optional Software, then click Later and not install it for a while. I'd assume they are choosing to install an item from the optional list because they want it now. I think we need to think harder about the UI issues here.

[Daniel Hazelbaker]

Is there any provision for handling partial installs?  I'll give an extreme example (meaning we don't do it exactly this way, but for example):

The entire Adobe CS6 suite is rather large.  Lets say some users only get Photoshop, some only get InDesign and some get all 3 (Photoshop, InDesign and Illustrator).

Is there a way to easily handle that, or do we have to find a way to identify the entire package (via a common helper tool etc.) and/or ensure that a single app (say Photoshop) is always installed on all systems that get any part of CS6.

Otherwise love the idea.  We currently use key management software that is a joke, so I love the idea of something more easily managed.

Daniel

[Gregory Neagle]

On Jul 3, 2013, at 10:10 AM, Daniel Hazelbaker <danielha...@gmail.com> wrote:

Is there any provision for handling partial installs?  I'll give an extreme example (meaning we don't do it exactly this way, but for example):

The entire Adobe CS6 suite is rather large.  Lets say some users only get Photoshop, some only get InDesign and some get all 3 (Photoshop, InDesign and Illustrator).

Which suite? There are several.

If you install only Photoshop using a Master Collection installer/license, you've just consumed a Master Collection license.

Is there a way to easily handle that,

I covered that in my original post.

"Easy" is always in the eye of the beholder, of course.

or do we have to find a way to identify the entire package (via a common helper tool etc.) and/or ensure that a single app (say Photoshop) is always installed on all systems that get any part of CS6.

Otherwise love the idea.  We currently use key management software that is a joke, so I love the idea of something more easily managed.

Daniel

On Wednesday, July 3, 2013 6:23:16 AM UTC-7, gregn...@mac.com wrote:

On Jul 3, 2013, at 5:19 AM, Edward Marczak <mar...@radiotope.com> wrote:

> We're kind of doing this with Simian, and we're already on the self-service model you describe, but we're not relying on this for the actual license counts. Largely because we're not tracking uninstalls. For example, someone installs Office, and that uses a license. Now, instead of using Munki to uninstall, they just drag it to the trash. The receipt is still there, of course, but that machine really isn't using a license any longer. If you have some way to deal with that, then depending on these license counts becomes much more reasonable.

This is not a problem for my current implementation, as it uses the application inventory feature of Munki/MunkiWebAdmin to track application installs. This is an inventory of applications found on the machine. It's not dependent on pkg receipts.

In your scenario, if the user drags Office to the trash (and empties it), the application inventory for that machine would no longer list Office applications, and so a license seat would become available.

-Greg

[Edward Marczak]

That's great! I think our issue was a little more nuanced: what is,
"Office"? What if someone just got rid of PowerPoint? What if they got
rid of it all but Word? Same goes for many of the Adobe suites.

Also, at the scale we're dealing with, client-based counts are a big
bucket of slosh, due to machines that move around, may be off for a
few days or not check in for other reasons.

In short, we're dealing with this using a different mechanism, but
would certainly revisit handling it via Munki if that made sense.

[Gregory Neagle]

On Jul 3, 2013, at 12:14 PM, Edward Marczak <mar...@radiotope.com> wrote:

> That's great! I think our issue was a little more nuanced: what is,
> "Office"? What if someone just got rid of PowerPoint? What if they got
> rid of it all but Word? Same goes for many of the Adobe suites.

I don't think there can ever be a perfect solution to this, especially if your users have admin rights and can modify their machines arbitrarily.

We can make a best effort.

-Greg

[Josh Malone]

Perhaps MWA can know about products that have "components" ; if you
have any one of the components, you have the product?

-Josh

[Josh Malone]

...or maybe all "products" have a "components" array. Some will have a
single app bundle, others will have more.

[Gregory Neagle]

The general case solution is simpler.

Munki already knows how to determine if a given pkginfo item is installed or not. It just needs to (optionally) insert this information into the ApplicationInventory report. (which then becomes a more general "software inventory" report.

But that will wait for a later iteration.

-Greg