Remotely trigger an Uninstall through Munki?

[Lopezzi]

Hey all,

I have a situation that I'm hoping is an easy process, but I can't seem to find what I'm looking for searching the threads.  I basically want to trigger an uninstall of a certain app that was installed through Munki but not for all users of that manifest.  We ran into a licensing issue with an app so I want to uninstall it off the people's machines that don't use it, but I can't set it to autoremove cause there are people in the manifest that do legitimately need it.  I was wondering if there was a command or something I can push through ARD or Munki to tell Munki to uninstall it next time it runs.  I just want to simulate them clicking the uninstall button in MSC.  Is this possible/not-a-huge-pain to do?

[Gregory Neagle]

> On Jul 15, 2016, at 7:11 AM, Lopezzi <lop...@gmail.com> wrote:
>
> Hey all,
> I have a situation that I'm hoping is an easy process, but I can't seem to find what I'm looking for searching the threads. I basically want to trigger an uninstall of a certain app that was installed through Munki

How? managed_installs? optional_installs triggered by the end-user?

> but not for all users of that manifest.

And this is where having a manifest-per-machine would help you greatly.

> We ran into a licensing issue with an app so I want to uninstall it off the people's machines that don't use it, but I can't set it to autoremove cause there are people in the manifest that do legitimately need it. I was wondering if there was a command or something I can push through ARD or Munki to tell Munki to uninstall it next time it runs. I just want to simulate them clicking the uninstall button in MSC. Is this possible/not-a-huge-pain to do?

Possible, sure. Huge pain? That's an opinion call.

So you've removed it from the manifest, and now Munki isn't managing it at all? Seems like an odd way to manage a piece of software for which you've run into a licensing issue.

Since manifests are the primary mechanism that Munki uses to determine what should and should not be installed on a machine -- stop trying to work around them. Instead, use them as intended.

Here's my recommendation:

1) Start creating manifests for each machine, or at the very least, one for the machines that should keep the software and one for the machines that should not. But longer-term, a manifest-per-machine will give you the flexibility to deal with this sort of situation in the future.

2) Use ARD or ssh or sneakernet to reassign the ClientIdentifier (or _remove_ the ClientIdentifier) for your machines so they start using your new manifests.

See also https://groob.io/posts/manifest-guide/

[Lopezzi]

How? managed_installs? optional_installs triggered by the end-user? 

 

They were installed via optional_installs.

And this is where having a manifest-per-machine would help you greatly. 

I agree, but I don't have that setup and frankly, that sounds pretty awful to have to manage that many manifests, but I agree it would work in this situation.

So you've removed it from the manifest, and now Munki isn't managing it at all? Seems like an odd way to manage a piece of software for which you've run into a licensing issue.

I agree, which is why I never removed it from the manifest.  Not sure why you think I removed it.

Since manifests are the primary mechanism that Munki uses to determine what should and should not be installed on a machine -- stop trying to work around them. Instead, use them as intended.

Yes, that was my understanding too.  I don't see how I'm trying to work around them.  I have a manifest created for my Creative department (called Creative) that has certain "Creative" apps listed as optional_installs in it.  There are people that legitimately need an app (FileMaker Pro in this example) listed in there.  There are also Creative people that don't need FMP, but have it installed.  I would like to trigger an uninstall remotely if possible.  Yes I know I can ask them to open MSC and click the Remove button, but I'd like to simulate that remotely without having to rely on them.

I didn't think having a manifest per department was an insane idea that was not using it as intended.  Seemed like a fairly reasonable use to me, but maybe I'm way off.

[Mr. Alan Siu]

Having one manifest per machine isn't horrible to manage. It's great, actually, because of nested manifests.

For every individual manifest, you include a larger manifest.

So if Jane, Carol, and Martha each have individual manifests, and each of their individual manifests includes the manifest creative_team, then you can deploy software to all three of them by putting it in the creative_team manifest, but if only Carol needs something, you can put it in the carol manifest.

https://github.com/munki/munki/wiki/Manifests#included_manifests

You may also want to look into Munki Enroll to automate it a bit.

https://github.com/edingc/munki-enroll

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

On Friday, July 15, 2016 at 9:27:13 AM UTC-5, Gregory Neagle wrote:

> On Jul 15, 2016, at 7:11 AM, Lopezzi <lop...@gmail.com> wrote:
>
> Hey all,
> I have a situation that I'm hoping is an easy process, but I can't seem to find what I'm looking for searching the threads.  I basically want to trigger an uninstall of a certain app that was installed through Munki

How? managed_installs? optional_installs triggered by the end-user?

> but not for all users of that manifest.

And this is where having a manifest-per-machine would help you greatly.

>  We ran into a licensing issue with an app so I want to uninstall it off the people's machines that don't use it, but I can't set it to autoremove cause there are people in the manifest that do legitimately need it.  I was wondering if there was a command or something I can push through ARD or Munki to tell Munki to uninstall it next time it runs.  I just want to simulate them clicking the uninstall button in MSC.  Is this possible/not-a-huge-pain to do?

Possible, sure. Huge pain? That's an opinion call.

So you've removed it from the manifest, and now Munki isn't managing it at all? Seems like an odd way to manage a piece of software for which you've run into a licensing issue.

Since manifests are the primary mechanism that Munki uses to determine what should and should not be installed on a machine -- stop trying to work around them. Instead, use them as intended.

Here's my recommendation:

1) Start creating manifests for each machine, or at the very least, one for the machines that should keep the software and one for the machines that should not. But longer-term, a manifest-per-machine will give you the flexibility to deal with this sort of situation in the future.

2) Use ARD or ssh or sneakernet to reassign the ClientIdentifier (or _remove_ the ClientIdentifier) for your machines so they start using your new manifests.

See also https://groob.io/posts/manifest-guide/

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/c945eb1b-6346-49b6-a23d-82033c8e7d8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nick McSpadden]

If you absolutely don't want to spit up your manifests (and I agree with Greg completely that it's the best way to handle this), you can use admin-provided conditionals.  You'll have to figure out some means of determining which machines you want to remove it from - whether that's by checking on same state, or serial, or something.  But you can use admin-provided conditionals to offer a managed_install of this software to those who need/should get it, and a managed_uninstall for those who aren't licensed for it.

Pros:
* You don't have to make any more manifests

Cons:
* You have to script the admin provided conditional

* You have to deploy the conditional to your machines (which is easy, with Munki)

* You have to change the manifests to use it

Not sure that's less effort than making manifests, especially since there are tools like https://github.com/nmcspadden/ManifestCreator to help create manifests for you.

But ultimately, you have a simple problem: you have a manifest that says "Everyone using this should get X."  But now you have decided that not everyone in that group should get X.  The most straightforward approach is exactly what Greg describes - make new sub-manifests that include your parent manifest that allow you to distinguish "Should get X" vs. "Shouldn't get X."  And I think that's much easier than doing what I described above.

On Fri, Jul 15, 2016 at 7:45 AM, Lopezzi <lop...@gmail.com> wrote:

On Friday, July 15, 2016 at 9:27:13 AM UTC-5, Gregory Neagle wrote:

> On Jul 15, 2016, at 7:11 AM, Lopezzi <lop...@gmail.com> wrote:
>
> Hey all,
> I have a situation that I'm hoping is an easy process, but I can't seem to find what I'm looking for searching the threads.  I basically want to trigger an uninstall of a certain app that was installed through Munki

How? managed_installs? optional_installs triggered by the end-user?

> but not for all users of that manifest.

And this is where having a manifest-per-machine would help you greatly.

>  We ran into a licensing issue with an app so I want to uninstall it off the people's machines that don't use it, but I can't set it to autoremove cause there are people in the manifest that do legitimately need it.  I was wondering if there was a command or something I can push through ARD or Munki to tell Munki to uninstall it next time it runs.  I just want to simulate them clicking the uninstall button in MSC.  Is this possible/not-a-huge-pain to do?

Possible, sure. Huge pain? That's an opinion call.

So you've removed it from the manifest, and now Munki isn't managing it at all? Seems like an odd way to manage a piece of software for which you've run into a licensing issue.

Since manifests are the primary mechanism that Munki uses to determine what should and should not be installed on a machine -- stop trying to work around them. Instead, use them as intended.

Here's my recommendation:

1) Start creating manifests for each machine, or at the very least, one for the machines that should keep the software and one for the machines that should not. But longer-term, a manifest-per-machine will give you the flexibility to deal with this sort of situation in the future.

2) Use ARD or ssh or sneakernet to reassign the ClientIdentifier (or _remove_ the ClientIdentifier) for your machines so they start using your new manifests.

See also https://groob.io/posts/manifest-guide/

--

You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/c945eb1b-6346-49b6-a23d-82033c8e7d8f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

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

[Lopezzi]

Thanks Alan.  I think that would be a good idea for small teams but I have a decent sized user base so to create a new manifest for every machine seems tedious.  Again, I agree it would totally solve this problem I'm having, but it would take a lot of work on my side to get this setup (whaa, i know :) )

I also do do a little bit of nesting in my manifests as there is some software that is company wide which I have a main manifest for, and then more specific departmental manifests (i.e. Creative) that are part of that one.  Then even more focused manifests (photography) inside Creative.  It works mostly for my setup, except in weird situations like this.  Thanks again for your help!

[Mr. Alan Siu]

You may not have the mental bandwidth for this right now, but seriously take a look at Munki-Enroll. Its whole point is to automate the nesting of manifests and creation of individual manifests.

It's quite simple. One piece on the client just sends the client's machine name and identifier (you can tweak it to be primary username and serial number or something else) to the server, and then one piece on the server automatically creates the individual manifest that includes the old manifest.

Alan Siu

Client Systems Analyst

St. Ignatius College Preparatory

--

You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/533c0cd7-a554-40de-93fc-e10965ea1508%40googlegroups.com.

[Gregory Neagle]

On Jul 15, 2016, at 7:50 AM, Nick McSpadden <nmcsp...@gmail.com> wrote:

Not sure that's less effort than making manifests, especially since there are tools like https://github.com/nmcspadden/ManifestCreator to help create manifests for you.

I also really like a tool called "cp":

cp template_manifest new_machine_manifest

[Gregory Neagle]

On Jul 15, 2016, at 7:45 AM, Lopezzi <lop...@gmail.com> wrote:

How? managed_installs? optional_installs triggered by the end-user? 

 

They were installed via optional_installs.

So now we're talking about modifying the /Library/Managed Installs/manifests/SelfServeManifest file on each affected machine, moving the offending software from managed_installs to managed_uninstalls.

If the software is still available in optional_installs, you need to do this -- if the software was removed manually, Munki would just reinstall it.

And this is where having a manifest-per-machine would help you greatly. 

I agree, but I don't have that setup and frankly, that sounds pretty awful to have to manage that many manifests, but I agree it would work in this situation.

So you've removed it from the manifest, and now Munki isn't managing it at all? Seems like an odd way to manage a piece of software for which you've run into a licensing issue.

I agree, which is why I never removed it from the manifest.  Not sure why you think I removed it.

I guess I assumed that since you "ran into a licensing issue" with this app, you would have removed it so more people would not have installed it.

Since manifests are the primary mechanism that Munki uses to determine what should and should not be installed on a machine -- stop trying to work around them. Instead, use them as intended.

Yes, that was my understanding too.  I don't see how I'm trying to work around them.  I have a manifest created for my Creative department (called Creative) that has certain "Creative" apps listed as optional_installs in it.  There are people that legitimately need an app (FileMaker Pro in this example) listed in there.  There are also Creative people that don't need FMP, but have it installed.  

Then I might suggest that allowing all users to install it via optional_installs is not a good strategy. Even if/when you clean this up, what will stop you from getting right back into this situation in a few days/weeks/months?

I would like to trigger an uninstall remotely if possible.  Yes I know I can ask them to open MSC and click the Remove button, but I'd like to simulate that remotely without having to rely on them.

Again, we're talking about modifying the /Library/Managed Installs/manifests/SelfServeManifest file on each affected machine. But what prevents the user from immediately reinstalling the item from optional_installs?

I didn't think having a manifest per department was an insane idea that was not using it as intended.  Seemed like a fairly reasonable use to me, but maybe I'm way off.

Again -- since manifests are the primary mechanism of controlling what is installed or not installed on a machine, and you are trying to enforce "not installed" on certain machines, but are unwilling to use manifests to accomplish this, it seems to me that you are fighting them.

On Friday, July 15, 2016 at 9:27:13 AM UTC-5, Gregory Neagle wrote:

> On Jul 15, 2016, at 7:11 AM, Lopezzi <lop...@gmail.com> wrote: 
> 
> Hey all, 
> I have a situation that I'm hoping is an easy process, but I can't seem to find what I'm looking for searching the threads.  I basically want to trigger an uninstall of a certain app that was installed through Munki 

How? managed_installs? optional_installs triggered by the end-user? 

> but not for all users of that manifest. 

And this is where having a manifest-per-machine would help you greatly. 

>  We ran into a licensing issue with an app so I want to uninstall it off the people's machines that don't use it, but I can't set it to autoremove cause there are people in the manifest that do legitimately need it.  I was wondering if there was a command or something I can push through ARD or Munki to tell Munki to uninstall it next time it runs.  I just want to simulate them clicking the uninstall button in MSC.  Is this possible/not-a-huge-pain to do? 

Possible, sure. Huge pain? That's an opinion call. 

So you've removed it from the manifest, and now Munki isn't managing it at all? Seems like an odd way to manage a piece of software for which you've run into a licensing issue. 

Since manifests are the primary mechanism that Munki uses to determine what should and should not be installed on a machine -- stop trying to work around them. Instead, use them as intended. 

Here's my recommendation: 

1) Start creating manifests for each machine, or at the very least, one for the machines that should keep the software and one for the machines that should not. But longer-term, a manifest-per-machine will give you the flexibility to deal with this sort of situation in the future. 

2) Use ARD or ssh or sneakernet to reassign the ClientIdentifier (or _remove_ the ClientIdentifier) for your machines so they start using your new manifests. 

See also https://groob.io/posts/manifest-guide/

-- 
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/c945eb1b-6346-49b6-a23d-82033c8e7d8f%40googlegroups.com.

[A.E. van Bochoven]

If you don't want to create a manifest-per-client, you could use conditional items in the manifest. https://github.com/munki/munki/wiki/Conditional-Items

You would need to provide an identifier like the serial_number to target the machines:

<key>conditional_items</key>

<array>

    <dict>

        <key>condition</key>

        <string>serial_number == 'C02NM2ELXXXX'</string>

        <key>managed_uninstalls</key>

        <array>

            <string>OmniGraffle6</string>

        </array>

    </dict>

</array>

-Arjen

On 15 Jul 2016, at 16:11, Lopezzi <lop...@gmail.com> wrote:

Hey all,

I have a situation that I'm hoping is an easy process, but I can't seem to find what I'm looking for searching the threads.  I basically want to trigger an uninstall of a certain app that was installed through Munki but not for all users of that manifest.  We ran into a licensing issue with an app so I want to uninstall it off the people's machines that don't use it, but I can't set it to autoremove cause there are people in the manifest that do legitimately need it.  I was wondering if there was a command or something I can push through ARD or Munki to tell Munki to uninstall it next time it runs.  I just want to simulate them clicking the uninstall button in MSC.  Is this possible/not-a-huge-pain to do?

--
You received this message because you are subscribed to the Google Groups "munki-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-discus...@googlegroups.com.
To post to this group, send email to munki-...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/munki-discuss/059d77d6-8fa1-4632-9ca7-0d4a35115017%40googlegroups.com.

[Lopezzi]

So I finally got it worked out.  I opted in the meantime at least, to use what Greg mentioned:

So now we're talking about modifying the /Library/Managed Installs/manifests/SelfServeManifest file on each affected machine, moving the offending software from managed_installs to managed_uninstalls. 

I did this by running a few bash commands through ARD, using sed to remove the line from managed_installs and add it to the managed_uninstalls.  It took me all day as I'm not an expert by any means in coding and apparently the 'sed' command in OS X is different than other flavors of *nix, but with a lot of Googling and trial and error, I finally managed to edit the file with a command and have it successfully uninstall the software on the next munki run.

Thanks all for your help and suggestions.  I will definitely look into some of the ideas and manifest design and some of the tools to help build it.  Have a great weekend everyone.