How do downgrade an install with Munki?
559 views
Skip to first unread message
Richard Glaser
Jul 11, 2014, 4:08:52 PM7/11/14
to munk...@googlegroups.com
How do downgrade an install?
For example, you have MyApp version 1.0 that is distributed to your fleet. You test MyApp version 1.1, but you missed a critical issue to your end-users and need to downgrade.
But, according to the wiki...
> Note that munki generally will not downgrade an existing install from
> a newer version to an older version, so specifying an older version
> in the managed_installs list will not downgrade existing
> installations.
So, do you temporarily add MyApp version 1.1 to "managed_uninstalls", then once removed add MyApp version 1.0 back to "managed_installs?
I tried having the old app version listed in "managed_installs" and the newer in "managed_uninstalls", but I get the following error with managedsoftware command line tool:
# managedsoftwareupdate
Managed Software Update Tool
Copyright 2010-2014 The Munki Project
Starting...
Checking for available updates...
Retrieving list of software for this machine...
0..20..40..60..80..100
WARNING: Will not attempt to remove MyApp because some version of it is in the list of managed installs, or it is required by another managed install.
Finishing...
Done.
I found this in the list archive...
> You put Lync in managed_uninstalls and you put Lync in
> managed_installs. You've confused Munki.
>
> Munki doesn't handle this situation (downgrades) well because Apple's
> installer and Apple packages don't handle this well.
>
> This _might_ work: Change the name key of Lync-14.0.5 to Lync_broken.
>
> Add "Lync-broken" to managed_uninstalls instead of Lync-14.0.5.
>
> This may unconfuse Munki enough to do what you want.
>
> -Greg
I tried this too modifying the application metadata name key, but it didn't appear to work.
For example...
<key>name</key>
<string>MyApp_broken</string>
So, is the solution others are doing, is removing the application from managed_installs to managed_uninstalls let it uninstall then add the older version to managed_installs?
Or are there other options?
Richard Glaser
Jul 11, 2014, 4:29:42 PM7/11/14
to munk...@googlegroups.com
Ok, I tried removing "Google Chrome-35.0.1916.153" from a box that has it installed.
I tried removing it from managed_installs to managed_uninstalls run makecatalogs
and then on the client run "managedsoftware" and then "managedsoftwareupdate --installonly" and it outputs
Nothing to install or remove.
And Google Chrome application is still installed on client.
Shouldn't this work?
Erik
Jul 11, 2014, 5:50:16 PM7/11/14
to munk...@googlegroups.com
Run managedsoftwareupdate -vvvv
Richard Glaser
Jul 11, 2014, 6:29:03 PM7/11/14
to munk...@googlegroups.com
Hello Erik:
Thanks, that enabled super verbose mode.Curious, why isn't any documentation available in the managedsoftware help or wiki?
The only reference that hints at it is the verbose flag,
-v, --verbose More verbose output. May be specified multiple times.
Which to me makes me how many "v's" can you add. Maybe, hitting the right number will give you the meaning of life ;-)
Anyway, which help me find the issue with the pkginfo for "Google Chrome-35.0.1916.153" was incorrect and is working correctly now.
So, is this the only method you can downgrade an install?
It was...
<key>path</key>
<string>/Applications/Web Browsers</string>
But, should have been
<key>path</key>
<string>/Applications/Web Browsers/Google Chrome.app</string>
For example...
managedsoftwareupdate -vvvv
Managed Software Update Tool
Copyright 2010-2014 The Munki Project
Starting...
Checking for available updates...
Manifest base URL is: http://munki.myinstitution.edu/manifests/
Manifest base URL is: http://munki.myinstitution.edu/manifests/
Getting manifest client_manifest...
follow_redirects is False
HTTP/1.1 304 Not Modified
Date: Fri, 11 Jul 2014 21:56:22 GMT
Server: Apache/2.2.26 (Unix) DAV/2 mod_ssl/2.2.26 OpenSSL/0.9.8y
ETag: "423-27f-4fdf1f6f464c0"
/Library/Managed Installs/manifests/client_manifest.plist already exists and is up-to-date.
Using manifest: development/individuals/richard/machines/types/minimal
**Checking for installs**
** Processing manifest client_manifest.plist for managed_installs
Catalog base URL is: http://munki.myinstitution.edu/catalogs/
Getting catalog development-individual-richard...
follow_redirects is False
HTTP/1.1 304 Not Modified
Date: Fri, 11 Jul 2014 21:56:22 GMT
Server: Apache/2.2.26 (Unix) DAV/2 mod_ssl/2.2.26 OpenSSL/0.9.8y
ETag: "77d-2037-4fdf180b2f4c0"
/Library/Managed Installs/catalogs/development-individual-richard already exists and is up-to-date.
Getting catalog development-all...
follow_redirects is False
HTTP/1.1 304 Not Modified
Date: Fri, 11 Jul 2014 21:56:22 GMT
Server: Apache/2.2.26 (Unix) DAV/2 mod_ssl/2.2.26 OpenSSL/0.9.8y
ETag: "779-2037-4fdf180b2f4c0"
/Library/Managed Installs/catalogs/development-all already exists and is up-to-date.
Getting catalog testing-all...
follow_redirects is False
HTTP/1.1 304 Not Modified
Date: Fri, 11 Jul 2014 21:56:22 GMT
Server: Apache/2.2.26 (Unix) DAV/2 mod_ssl/2.2.26 OpenSSL/0.9.8y
ETag: "776-2037-4fdf180b2f4c0"
/Library/Managed Installs/catalogs/testing-all already exists and is up-to-date.
Getting catalog production-all...
follow_redirects is False
HTTP/1.1 304 Not Modified
Date: Fri, 11 Jul 2014 21:56:22 GMT
Server: Apache/2.2.26 (Unix) DAV/2 mod_ssl/2.2.26 OpenSSL/0.9.8y
ETag: "77a-2037-4fdf180b2f4c0"
/Library/Managed Installs/catalogs/production-all already exists and is up-to-date.
* Processing manifest item Adium-1.5.10 for install
Looking for detail for: Adium, version 1.5.10...
Considering 1 items with name Adium from catalog development-individual-richard
Considering item Adium, version 1.5.10 with minimum os version required 10.6.8
Our OS version is 10.9.4
Found Adium, version 1.5.10 in catalog development-individual-richard
Looking for application Adium with bundleid: com.adiumX.adiumX, version 1.5.10...
Getting info on currently installed applications...
Skipped app App Store with path /Users/mac/Applications/App Store.app
Name: Adium
Path: /Applications/Chat & Talk/Adium.app
CFBundleIdentifier: com.adiumX.adiumX
Version: 1.5.10
Adium version 1.5.10 (or newer) is already installed.
Looking for updates for: Adium-1.5.10
Looking for updates for: Adium--1.5.10
* Processing manifest item Evernote-5.5.2 for install
Looking for detail for: Evernote, version 5.5.2...
Considering 1 items with name Evernote from catalog development-individual-richard
Considering item Evernote, version 5.5.2 with minimum os version required 10.6.6
Our OS version is 10.9.4
Found Evernote, version 5.5.2 in catalog development-individual-richard
Found Info.plist at /Applications/Office & Productivity/Evernote.app/Contents/Info.plist
Checking /Applications/Office & Productivity/Evernote.app/Contents/Info.plist for CFBundleShortVersionString 5.5.2...
Using version_comparison_key CFBundleShortVersionString
Installed item has version 5.5.2
Installed item is the same.
Evernote version 5.5.2 (or newer) is already installed.
Looking for updates for: Evernote-5.5.2
Looking for updates for: Evernote--5.5.2
**Checking for removals**
** Processing manifest client_manifest.plist for managed_uninstalls
Catalog base URL is: http://munki.myinstitution.edu/catalogs/
* Processing manifest item Google Chrome-35.0.1916.153 for removal
Looking for detail for: Google Chrome, version 35.0.1916.153...
Considering 1 items with name Google Chrome from catalog development-individual-richard
Considering item Google Chrome, version 35.0.1916.153 with minimum os version required 10.6.0
Our OS version is 10.9.4
Found Google Chrome, version 35.0.1916.153 in catalog development-individual-richard
Considering item Google Chrome-35.0.1916.153 for removal info
Checking 'installs' items...
/Applications/Google Chrome.app not found on disk.
Google Chrome-35.0.1916.153 not installed.
Google Chrome-35.0.1916.153 doesn't appear to be installed.
**Checking for managed updates**
** Processing manifest client_manifest.plist for managed_updates
Catalog base URL is: http://munki.myinstitution.edu/catalogs/
** Processing manifest client_manifest.plist for optional_installs
Catalog base URL is: http://munki.myinstitution.edu/catalogs/
No change in InstallInfo.
Finishing...
Done.
On Friday, July 11, 2014 3:50:16 PM UTC-6, Erik wrote:
Run managedsoftwareupdate -vvvv
lists.mac
Jul 12, 2014, 9:48:26 PM7/12/14
to munk...@googlegroups.com
On Jul 11, 2014, at 6:29 PM, Richard Glaser <richard...@UTAH.EDU> wrote:
Hello Erik:Thanks, that enabled super verbose mode.Curious, why isn't any documentation available in the managedsoftware help or wiki?The only reference that hints at it is the verbose flag,
Verbose mode doesn’t require a whole lot of documentation. It is noted in the Troubleshooting section of the wiki:
Marnin
--
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/d/optout.
Richard Glaser
Jul 14, 2014, 7:36:16 PM7/14/14
to munk...@googlegroups.com
Ok, understand it doesn't require a lot of documentation. But, for those new or learning munki having it included with the managedsoftwareupdate --help would be beneficial.
With version 1.0.0.1864 doesn't include this information about the extra verbose mode.
For example...
managedsoftwareupdate --help
Usage: managedsoftwareupdate [options]
Options:
-h, --help show this help message and exit
-a, --auto Used by launchd LaunchAgent for scheduled runs.
No user feedback or intervention. All other options
ignored.
-l, --logoutinstall Used by launchd LaunchAgent when running at the
loginwindow.
--installwithnologout
Used by Managed Software Update.app when user
triggers an install without logging out.
--manualcheck Used by launchd LaunchAgent when checking
manually.
-m, --munkistatusoutput
Uses MunkiStatus.app for progress feedback when
installing.
--id=ID Alternate identifier for catalog retreival
-q, --quiet Quiet mode. Logs messages, but nothing to stdout.
--verbose is ignored if --quiet is used.
-v, --verbose More verbose output. May be specified multiple
times.
--checkonly Check for updates, but don't install them.
This is the default behavior.
--installonly Skip checking and install any pending updates.
--applesuspkgsonly Only check/install Apple SUS packages, skip Munki
packages.
--munkipkgsonly Only check/install Munki packages, skip Apple SUS.
-V, --version Print the version of the munki tools and exit.
Gregory Neagle
Jul 14, 2014, 7:40:13 PM7/14/14
to munk...@googlegroups.com
On Jul 14, 2014, at 4:36 PM, Richard Glaser <richard...@utah.edu> wrote:
Ok, understand it doesn't require a lot of documentation. But, for those new or learning munki having it included with the managedsoftwareupdate --help would be beneficial.With version 1.0.0.1864 doesn't include this information about the extra verbose mode.
Sure it does:
-v, --verbose More verbose output. May be specified multiple times.
Perhaps it's not as clear as you'd like. Feel free to suggest alternative phrasing.
Also have you seen: https://code.google.com/p/munki/wiki/Troubleshooting, and specifically: https://code.google.com/p/munki/wiki/Troubleshooting#Command_line
Richard Glaser
Jul 14, 2014, 7:42:52 PM7/14/14
to munk...@googlegroups.com
Ok, so, why doesn't munki support downgrading an install to the previous version?
Is it true, that you have to add the newer version to "managed_uninstalls" make sure the client does have the newer version, then add the older version to "managed_installs"?
This seems like a lot of extra work that munki could support or do.
This seems like a lot of extra work that munki could support or do.
Is this planned in the future?
Also, what if the application has been moved to another location that isn't defined in the package metadata? I got an error because the application wasn't installed in "/Applications" but "/Applications/Web Browsers".
Can you setup munki to uninstall and search multiple locations like anywhere in /Applications? Or other locations?
On Friday, July 11, 2014 2:08:52 PM UTC-6, Richard Glaser wrote:
Gregory Neagle
Jul 14, 2014, 7:49:28 PM7/14/14
to munk...@googlegroups.com
On Jul 14, 2014, at 4:42 PM, Richard Glaser <richard...@utah.edu> wrote:
Ok, so, why doesn't munki support downgrading an install to the previous version?
Because most software installers (Apple pkgs, etc) do not.
And in practice, this is rarely needed. In the five years I've been using Munki, I've only had to downgrade things less than a handful of times. I managed to do that without adding more code to the Munki tools.
Is it true, that you have to add the newer version to "managed_uninstalls" make sure the client does have the newer version, then add the older version to "managed_installs"?
That might be needed for Apple package installers, especially if the packages prevent downgrades.
It's not needed for drag-n-drop app installs. Instead you can use a correctly crafted installs array to cause Munki to install the exact version you want, overwriting any existing install.
This seems like a lot of extra work that munki could support or do.Is this planned in the future?
I have no plans for adding more explicit support, since the exact steps needed to be successful vary for each piece of software. This is not radmind, which manages files. This uses existing vendor installers. Not all work the same.
Also, what if the application has been moved to another location that isn't defined in the package metadata? I got an error because the application wasn't installed in "/Applications" but "/Applications/Web Browsers".
Can you setup munki to uninstall and search multiple locations like anywhere in /Applications? Or other locations?
Nope.
bryanzak
Jul 14, 2014, 8:26:06 PM7/14/14
to munk...@googlegroups.com
If what you are uninstalling is simple enough you could...
Remove the "bad" 1.1 version from pkgs and pkgsinfo - leaving the "good" 1.0 version in Munki
Write a shell script to remove the offending 1.1 and then package it up inside a payload free package. If you used package receipts to check for whether or not the app is installed, be sure your script uses pkgutil --forget to remove the package receipts associated with the 1.0 and 1.1 packages (if different IDs). Import into Munki and makecatalogs.
Now your package runs and removes 1.1 and the next time munki runs after that 1.0 will get reinstalled.
If you're not familiar with payload free packages they are incredibly trivial - basically just your script and a call to pkgbuild to make it.
Bryan
Erik
Jul 14, 2014, 9:07:46 PM7/14/14
to munk...@googlegroups.com
You could perhaps even go a step further and mark the specific version as an update_for the payload free package and reduce it to one munki run.
Richard: If you move computers that often, why not just redeploy a thin image and let munki install the software properly? It may take longer, but it's probably for the best and would reduce your admin overhead.
Richard: If you move computers that often, why not just redeploy a thin image and let munki install the software properly? It may take longer, but it's probably for the best and would reduce your admin overhead.
MiqViq
Jul 15, 2014, 4:08:20 AM7/15/14
to munk...@googlegroups.com
Or you could make the removal script as a preinstall_script for the correct version.
If the version to be removed was installed using pkg receipt then add this as the last command in your removal script:
pkgutil --forget com.pkg.identifier
Replace com.pkg.identifier with the correct pkg id.
-MiqViq
Richard Glaser
Jul 15, 2014, 7:40:35 PM7/15/14
to munk...@googlegroups.com
>You could perhaps even go a step further and mark the specific version as an update_for the payload free package and reduce it to one munki run.
Ok, I will look into this. We have ideas of other workarounds to this issue.
Because we distribute a lot of software and using thin images would greatly slow deployment or re-configuration. Plus it adds additional burden to our management which we currently do not have.
Seems like we would probably use code if it exists to manage the managesoftware plist settings or develop it ourselves, if it doesn't existtot give us the functionality we need. It seems like we need/want to manage most of the settings more centrally/easily than just client manifest setting.
Daniel Warren
Aug 22, 2016, 1:18:32 PM8/22/16
to munki-dev
Forgive my ignorance, but is their a wiki on how to "correctly" craft an installs array that would allow you to downgrade?
A.E. van Bochoven
Aug 22, 2016, 2:05:01 PM8/22/16
to munk...@googlegroups.com
It would be nice if we had a wiki article explaining that.
If I need to downgrade, I remove the higher version from the munkirepo and add an installs array to the pkginfo file of the previous version that contains an md5 hash of some file that is unique to that version.
Make sure that you don't point munki to something that it could use for a numerical comparison, because it will decide that the installed version is higher.
Probably other (better) methods exist.
-Arjen
Warren, Daniel
Aug 22, 2016, 2:08:28 PM8/22/16
to munk...@googlegroups.com
Thank you. I understand that each install is different, but information such as you just provided would be helpful if it were better documented.
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.
Reply all
Reply to author
Forward
0 new messages