removing packages

[Roy Nielsen]

Hello,

Is there a way that I can remove a package, by running a command on the client instead of having to specify it's removal on the server?

I'm guessing even if I do that, I have to specify it's removal on the server?  or remove it from the catalog?

Regards,
-Roy

[Greg Neagle]

On Mar 26, 2010, at 8:29 PM, Roy Nielsen wrote:

> Hello,
>
> Is there a way that I can remove a package, by running a command on
> the client instead of having to specify it's removal on the server?

Yes.

/usr/local/munki/munkilib/removepackages.py --help
Usage: removepackages.py [options]

Options:
-h, --help show this help message and exit
-f, --forcedeletebundles
Delete bundles even if they aren't empty.
-l, --listfiles List the filesystem objects to be removed,
but do not actually remove them.
--rebuildpkgdb Force a rebuild of the internal package
database.
--noremovereceipts Do not remove receipts and boms from
/Library/Receipts and update internal package
database.
--noupdateapplepkgdb Do not update Apple's package database.
If --noremovereceipts is also given, this is
implied
-m, --munkistatusoutput
Output is formatted for use with MunkiStatus.
-v, --verbose More verbose output. May be specified multiple
times.

You'll need the packageid(s). If you have a pkginfo file for the pkg,
this is part of the receipt data.
So if you have a pkg for Foo that has a packageid of com.bar.foo.pkg:

/usr/local/munki/munkilib/removepackages.py com.bar.foo.pkg

If it's actually a metapackage with mulitple subpackages, you can
specify more than one packageid:

/usr/local/munki/munkilib/removepackages.py com.bar.foo.pkg
com.bar.foo_support_files.pkg com.bar.foo_extras.pkg

-Greg

>
> I'm guessing even if I do that, I have to specify it's removal on
> the server? or remove it from the catalog?
>
> Regards,
> -Roy
>
>

> --
> You received this message because you are subscribed to the Google
> Groups "munki-dev" group.
> To post to this group, send email to munk...@googlegroups.com.
> To unsubscribe from this group, send email to munki-dev+...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/munki-dev?hl=en
> .

[Roy Nielsen]

Hello Greg,

Ok, got it.
 

If it's actually a metapackage with mulitple subpackages, you can specify more than one packageid:

/usr/local/munki/munkilib/removepackages.py com.bar.foo.pkg com.bar.foo_support_files.pkg com.bar.foo_extras.pkg

Cool, I'll have to make sure arrays can be handled with the munki package provider, probably for both installing and removing packages.
 
Do you see an issue with the order packages are installed or removed, with the way munki works?

From the looks of the removepackages.py file, it handles the 10.5 package database..  Does it handle the differences with 10.6 (sorry, I can't test on a 10.6 box, all I've got at home is this 10.5 machine)

Regards,
-Roy

[Greg Neagle]

In the context of using a munki as a package provider for Puppet (now that I understand the context of your question) - using removepackages.py is probably not a good approach.

Why:

1) It only works with a subset of software installed via standard Apple-style packages. It doesn't work with drag-n-drop disk images or Adobe CS3/4 installers.

2) You have to take care of the installer-item to packageid mappings

3) You have to track and handle dependencies.

I think a better approach would be to write out a (munki) manifest and then call /usr/bin/munki/managedsoftwareupdate with a special flag that skipped the manifest retrieval, using the one generated by Puppet. This would allow munki to handle dependencies, handle install/removal order and all of the things munki was designed to do.

-Greg

[Roy Nielsen]

Hello Greg,

On Sat, Mar 27, 2010 at 10:29 AM, Greg Neagle <gregn...@mac.com> wrote:

In the context of using a munki as a package provider for Puppet (now that I understand the context of your question) - using removepackages.py is probably not a good approach.

Why:

1) It only works with a subset of software installed via standard Apple-style packages. It doesn't work with drag-n-drop disk images or Adobe CS3/4 installers.

2) You have to take care of the installer-item to packageid mappings

3) You have to track and handle dependencies.

I think a better approach would be to write out a (munki) manifest and then call /usr/bin/munki/

Does it work only with the manifest on the server, or can I tell the client to apply a specific manifest, the one puppet generates for/on the client? or maybe a manifest that is cached on the client?
 

managedsoftwareupdate with a special flag that skipped the manifest retrieval, using the one

generated by Puppet. This would allow munki to handle dependencies, handle install/removal

order and all of the things munki was designed to do.

Sounds good. 

I'm kind of thinking, at least to start with, that the provider will be rather simple, and the manifest can be created via a template created by the puppet admin/programmer...

What do you think?

Regards,
-Roy

[Nigel Kersten]

Given what Greg said, I reckon you want the provider to autogenerate
the manifests.

I think you have to treat this like apt or rpm or whatever, where it's
assumed you have a functional client setup on the machine first.

Really for a provider all you need are ways to:

* list all packages installed on the system (this should be set up for
ralsh as well)
* interrogate the state of a given package
* install a package
* remove a package

I assume we can request a specific version of a package with munki? If
so then we want to implement the puppet package provider feature
':versionable' so you can request a specific version.

[Greg Neagle]

On Mar 27, 2010, at 11:13 AM, Roy Nielsen wrote:

>
> I think a better approach would be to write out a (munki) manifest
> and then call /usr/bin/munki/
>
> Does it work only with the manifest on the server, or can I tell the
> client to apply a specific manifest, the one puppet generates for/on
> the client? or maybe a manifest that is cached on the client?

We'd have to modify managedsoftwareupdate to skip the manifest request/
retrieval from the server and instead use a manifest you provide.

-Greg

[Greg Neagle]

On Mar 27, 2010, at 3:47 PM, Nigel Kersten wrote:

> I think you have to treat this like apt or rpm or whatever, where it's
> assumed you have a functional client setup on the machine first.
>
> Really for a provider all you need are ways to:
>
> * list all packages installed on the system (this should be set up for
> ralsh as well)

If you limit yourself to Apple packages, this is (relatively) easy.
But for the other install type munki supports, this is harder.

> * interrogate the state of a given package

munki supports this.

> * install a package
> * remove a package

Obviously munki supports these.

>
> I assume we can request a specific version of a package with munki?

Yes. In a manifest it look like this:

<key>managed_installs</key>
<array>
Firefox-3.6.0.0.0
Thunderbird
</array>

In this example, you're asking specifically for version 3.6 of
Firefox, and the "latest" version of Thunderbird.

-Greg

[Roy Nielsen]

Hello,

(see inline)

On Sat, Mar 27, 2010 at 4:54 PM, Greg Neagle <gregn...@mac.com> wrote:

On Mar 27, 2010, at 3:47 PM, Nigel Kersten wrote:

I think you have to treat this like apt or rpm or whatever, where it's
assumed you have a functional client setup on the machine first.

Really for a provider all you need are ways to:

* list all packages installed on the system (this should be set up for
ralsh as well)

hmm... ok.  the dpkg package provider has a query..
 

If you limit yourself to Apple packages, this is (relatively) easy. But for the other install type munki supports, this is harder.

I think we can limit the puppet provider to apple packages... The current pkgdmg provider is limited to pkgs inside dmgs..

 

* interrogate the state of a given package

munki supports this.

ok

* install a package
* remove a package

Obviously munki supports these.

right.
 

I assume we can request a specific version of a package with munki?

Yes. In a manifest it look like this:

<key>managed_installs</key>
<array>
       Firefox-3.6.0.0.0
       Thunderbird
</array>

In this example, you're asking specifically for version 3.6 of Firefox, and the "latest" version of Thunderbird.

The package provider could key off the "name" and if the name has a version, populate the manifest with a version (like firefox above), and if not, treat it like "Thunderbird" above...

I may have to go through my tech transfer department to get this released..

Regards,
-Roy

[Roy Nielsen]

On Sat, Mar 27, 2010 at 4:50 PM, Greg Neagle <gregn...@mac.com> wrote:

On Mar 27, 2010, at 11:13 AM, Roy Nielsen wrote:

I think a better approach would be to write out a (munki) manifest and then call /usr/bin/munki/

Does it work only with the manifest on the server, or can I tell the client to apply a specific manifest, the one puppet generates for/on the client? or maybe a manifest that is cached on the client?

We'd have to modify managedsoftwareupdate to skip the manifest request/retrieval from the server and instead use a manifest you provide.

Sounds good,

Is the manifest where it's decided whether it's an install or removal?

-Roy

[Greg Neagle]

On Mar 27, 2010, at 6:16 PM, Roy Nielsen wrote:

> Is the manifest where it's decided whether it's an install or removal?

Yes:

<key>managed_installs</key>
<array>
<string>Firefox</string>
</array>
<key>managed_uninstalls</key>
<array>
<string>Thunderbird</string>
</array>

[Nigel Kersten]

On Sat, Mar 27, 2010 at 5:44 PM, Roy Nielsen <amr...@gmail.com> wrote:
> Hello,
>
> (see inline)
>
> On Sat, Mar 27, 2010 at 4:54 PM, Greg Neagle <gregn...@mac.com> wrote:
>>
>> On Mar 27, 2010, at 3:47 PM, Nigel Kersten wrote:
>>
>>> I think you have to treat this like apt or rpm or whatever, where it's
>>> assumed you have a functional client setup on the machine first.
>>>
>>> Really for a provider all you need are ways to:
>>>
>>> * list all packages installed on the system (this should be set up for
>>> ralsh as well)
>
> hmm... ok.  the dpkg package provider has a query..
>
>>
>> If you limit yourself to Apple packages, this is (relatively) easy. But
>> for the other install type munki supports, this is harder.
>
> I think we can limit the puppet provider to apple packages... The current
> pkgdmg provider is limited to pkgs inside dmgs..

Yes, definitely. If it's simply not practical to support the other
types, then so be it I think.

>
>>
>> * interrogate the state of a given package
>
>> munki supports this.
>
> ok
>
>> * install a package
>> * remove a package
>
>> Obviously munki supports these.
>
> right.
>
>>>
>>> I assume we can request a specific version of a package with munki?
>>
>> Yes. In a manifest it look like this:
>>
>> <key>managed_installs</key>
>> <array>
>>        Firefox-3.6.0.0.0
>>        Thunderbird
>> </array>
>>
>> In this example, you're asking specifically for version 3.6 of Firefox,
>> and the "latest" version of Thunderbird.
>
> The package provider could key off the "name" and if the name has a version,
> populate the manifest with a version (like firefox above), and if not, treat
> it like "Thunderbird" above...
>
> I may have to go through my tech transfer department to get this released..
>
> Regards,
> -Roy
>
>

[Roy Nielsen]

Got it.

Regards,
-Roy

[Greg Neagle]

Currently, the "other" package types include drag-n-drop diskimages
containing an application to install, and several Adobe-specific
formats. The drag-n-drop type is a convenience; it's trivial to
repackage these as Apple packages. But the Adobe apps are much, much
more difficult to repackage. I think there would be value in
supporting those when using munki as a Puppet package provider.

-Greg

[Roy Nielsen]

ok, you're right.  Adobe products are a real headache to try to package up.

Maybe the documentation should give a stipulation that only certain parameters work unless one uses the apple package format, then you get the full range of parameters.

Is there a way for a client to check if the package is a ".pkg" or if the ".dmg" contains a ".pkg" file --- or "other installer"?

If we could check that, we could do a check the return value to determine if the "extended" parameters should be run or not.

Regards,
-Roy

[Roy Nielsen]

Hello,

On Sat, Mar 27, 2010 at 4:54 PM, Greg Neagle <gregn...@mac.com> wrote:

On Mar 27, 2010, at 3:47 PM, Nigel Kersten wrote:

I think you have to treat this like apt or rpm or whatever, where it's
assumed you have a functional client setup on the machine first.

Really for a provider all you need are ways to:

* list all packages installed on the system (this should be set up for
ralsh as well)

If you limit yourself to Apple packages, this is (relatively) easy. But for the other install type munki supports, this is harder.

One can use the "system_profiler SPApplicationsDataType" to get a list of software installed on a Mac... I think it's the same for 10.5 & 10.6 (not sure, I'm on a 10.5 box right now)

I don't see a way to do this with munki (am I missing something?)
 

* interrogate the state of a given package

munki supports this.

How?  From what I can see, it appears to do this internally, but I don't see anything returning the state of a package...

Thanks,
-Roy

[Greg Neagle]

On Mar 27, 2010, at 9:32 PM, Roy Nielsen wrote:

Hello,

On Sat, Mar 27, 2010 at 4:54 PM, Greg Neagle <gregn...@mac.com> wrote:

On Mar 27, 2010, at 3:47 PM, Nigel Kersten wrote:

I think you have to treat this like apt or rpm or whatever, where it's
assumed you have a functional client setup on the machine first.

Really for a provider all you need are ways to:

* list all packages installed on the system (this should be set up for
ralsh as well)

If you limit yourself to Apple packages, this is (relatively) easy. But for the other install type munki supports, this is harder.

One can use the "system_profiler SPApplicationsDataType" to get a list of software installed on a Mac...

No, that's a list of _applications_.  There are plenty of things one can install that aren't applications.  And some installers install more than one application.

I think it's the same for 10.5 & 10.6 (not sure, I'm on a 10.5 box right now)

Yes, the same.

I don't see a way to do this with munki (am I missing something?)

If we limit ourselves to standard Apple packages, we don't use munki at all, but instead look at /Library/Receipts (under 10.5) and ask pkgutil --pkgs (in both 10.5 and 10.6).  But that's probably not really what you want, and as I mentioned, ignores all the non-Apple-package stuff munki supports.

So we'll probably need a new tool or tools to provide all the information a Puppet pkg provider needs.

 

* interrogate the state of a given package

munki supports this.

How?  From what I can see, it appears to do this internally, but I don't see anything returning the state of a package...

You are correct - the code is there for internal use, but needs to be exposed externally. See above. ("new tool")

[Roy Nielsen]

Hello,

On Sat, Mar 27, 2010 at 10:40 PM, Greg Neagle <gregn...@mac.com> wrote:

On Mar 27, 2010, at 9:32 PM, Roy Nielsen wrote:

Hello,

On Sat, Mar 27, 2010 at 4:54 PM, Greg Neagle <gregn...@mac.com> wrote:

On Mar 27, 2010, at 3:47 PM, Nigel Kersten wrote:

I think you have to treat this like apt or rpm or whatever, where it's
assumed you have a functional client setup on the machine first.

Really for a provider all you need are ways to:

* list all packages installed on the system (this should be set up for
ralsh as well)

If you limit yourself to Apple packages, this is (relatively) easy. But for the other install type munki supports, this is harder.

One can use the "system_profiler SPApplicationsDataType" to get a list of software installed on a Mac...

No, that's a list of _applications_.  There are plenty of things one can install that aren't applications.  And some installers install more than one application.

aah.. right.

I think it's the same for 10.5 & 10.6 (not sure, I'm on a 10.5 box right now)

Yes, the same.

I don't see a way to do this with munki (am I missing something?)

If we limit ourselves to standard Apple packages, we don't use munki at all, but instead look at /Library/Receipts (under 10.5) and ask pkgutil --pkgs (in both 10.5 and 10.6).  But that's probably not really what you want, and as I mentioned, ignores all the non-Apple-package stuff munki supports.

that's probably the most sensible - at least to start..
 

So we'll probably need a new tool or tools to provide all the information a Puppet pkg provider needs.

right.

 

* interrogate the state of a given package

munki supports this.

How?  From what I can see, it appears to do this internally, but I don't see anything returning the state of a package...

You are correct - the code is there for internal use, but needs to be exposed externally. See above. ("new tool")

yes...

Regards,
-Roy
 
PS.  So, can munki un-install apple packages that were not installed by munki?

[Greg Neagle]

Yes.

[Roy Nielsen]

Cool.

Looks like apple packages can be fully supported in the puppet module, with install, remove, upgrade, and query.  The other packages can be supported for install..  I don't see a way for query and remove to be supported for them.  This functionality sounds like a good target for the munki puppet package provider.

Regards,
-Roy