munki/munki

Managed software installation for macOS —

Munki

Managed software installation for macOS

Introduction

Munki is an open source project originated by Walt Disney Animation Studios.

Munki is a set of tools that, used together with a webserver-based repository of packages and package metadata, can be used by macOS administrators to manage software installs (and in many cases removals) on macOS client machines.

Munki can install software packaged in the Apple package format and software distributed in "drag-and-drop" disk images.

Additionally, Munki can install many Apple Software Updates on Intel Macs, and can prompt users to install pending Apple updates on both Intel and Apple silicon.

Munki is currently in use at organizations all over the world, managing software for tens of thousands -- perhaps hundreds of thousands of Macs.

Get started

Get started with Munki here: Getting Started with Munki

Check out the Wiki for some notes and documentation, and browse and/or check out the source. See the releases page for pre-built installer packages of supported releases.

Some video learning resources are here.

Get help

The wiki is an in-depth resource: https://github.com/munki/munki/wiki
Frequently Asked Questions are here: https://github.com/munki/munki/wiki/FAQ

If you have additional questions, or need even more help getting started, post a question to munki-discuss. Please don't post support questions as comments on wiki documentation pages, or as GitHub code issues.

Issues with MunkiWebAdmin should be discussed in its group: munki-web-admin.

munki's Issues

packages should only be downloaded once

From [email protected] on September 24, 2010 07:23:58

What steps will reproduce the problem? 1. run managedsoftwareupdate
2. run managedsoftwareupdate again 3. What is the expected output? What do you see instead? Every run of managedsoftwareupdate will download packages that have not been installed / updated yet. Packages that have been downloaded in previous runs of managedsoftwareupdate should not be downloaded again. What version of the product are you using? On what operating system? 0.6.755 pre-release Please provide any additional information below.

Original issue: http://code.google.com/p/munki/issues/detail?id=32

MSU.app - Optional software button hidden if only Apple Updates available.

From [email protected] on November 26, 2010 02:40:35

What steps will reproduce the problem? 1. Allow all normal munki updates to install
2. System needs to be in a state where some Apple Updates are not yet installed
3. Launch Managed Software Update.app
4. "Optional software..." button is not available. What is the expected output? What do you see instead? I would like to be able to do an optional install without forcing the user to install all Apple updates first.

I was at a computer today where there is a 1GB 10.6.5 update to install that requires a restart, I want to show the user a new piece of software that might help them; I don't want to wait for the Apple update to finish first. [same problem if needing to talk a user through installing an optional item over the phone which should fix some problem they are having]

Not sure if it was a deliberate decision to not allow optional installs to be displayed if apple updates are listed?

I think the change should be as simple as below. I did get one exception in MSU.app after making that change (and going through optional installs install/remove a few times); however I couldn't make that exception repeat again, so quite likely not due to this change.

Index: code/Managed Software Update/MSUAppDelegate.py

--- code/Managed Software Update/MSUAppDelegate.py ( revision 927 )
+++ code/Managed Software Update/MSUAppDelegate.py (working copy)
@@ -253,7 +253,8 @@
if appleupdates:
self.listofupdates = appleupdates.get("AppleUpdates", [])
self.update_view_controller.updateNowBtn.setEnabled(YES)

•            self.update_view_controller.optionalSoftwareBtn.setHidden_(YES)
  

•            #self.update_view_controller.optionalSoftwareBtn.setHidden_(YES)
  

•            self.getOptionalInstalls()
       else:
           self.update_view_controller.updateNowBtn.setEnabled_(NO)
           self.getOptionalInstalls()
  

Original issue: http://code.google.com/p/munki/issues/detail?id=46

makepkginfo has problems parsing package names with digits in it (like Flip4Mac, TypeIt4Me)

From vongablersahm on September 13, 2010 07:37:53

What steps will reproduce the problem? 1. Get a package containing a number in its name
2. do makepkginfo What is the expected output? What do you see instead? The package name is truncated at the first digit. One would expect to see the whole package name. What version of the product are you using? On what operating system? munki 0.5.2-572 on 10.6 Please provide any additional information below. The whole Name and Version splitting in munkicommon.py is of course guesswork and cannot be guaranteed to be right. But it might be more reliable to try to parse the name beginning at the end until a non-digit is encountered. An updated nameAndVersion function is shown below:

def nameAndVersion(aString):
"""
Splits a string into the name and version numbers:
'TextWrangler2.3b1' becomes ('TextWrangler', '2.3b1')
'AdobePhotoshopCS3-11.2.1' becomes ('AdobePhotoshopCS3', '11.2.1')
'MicrosoftOffice2008v12.2.1' becomes ('MicrosoftOffice2008', '12.2.1')
"""
index = 0
for char in aString[::-1]:
if (char in '0123456789._b'):
index -= 1
else:
break

if index < 0:
    possibleVersion = aString[index:]
    print >> sys.stderr, ('Splitting "&#37;s" to "&#37;s" Version "&#37;s"') &#37; (aString, aString[0:index].rstrip('v- '), possibleVersion)
    return (aString[0:index].rstrip('v- '), possibleVersion)
else:
    print >> sys.stderr, ('Splitting "&#37;s" to "&#37;s" Version "&#37;s"') &#37; (aString, aString, '')
    # no version number found, just return original string and empty string
    return (aString, '')

In my tests it seems to parse the former example correctly and also parses Flip4Mac and other Packages with digits in its name correctly:

Splitting "TextWrangler2.3b1" to "TextWrangler" Version "2.3b1"
Splitting "TextWrangler 2.3 b1" to "TextWrangler 2.3" Version "b1"
Splitting "AdobePhotoshopCS3-11.2.1" to "AdobePhotoshopCS3" Version "11.2.1"
Splitting "AdobePhotoshopCS3 11.2.1" to "AdobePhotoshopCS3" Version "11.2.1"
Splitting "AdobePhotoshop CS3 11.2.1" to "AdobePhotoshop CS3" Version "11.2.1"
Splitting "MicrosoftOffice2008v12.2.1" to "MicrosoftOffice2008" Version "12.2.1"
Splitting "MicrosoftOffice2008 12.2.1" to "MicrosoftOffice2008" Version "12.2.1"
Splitting "Microsoft Office 2008 12.2.1" to "Microsoft Office 2008" Version "12.2.1"
Splitting "Flip4Mac" to "Flip4Mac" Version ""
Splitting "Flip4Mac 2.3.3.3" to "Flip4Mac" Version "2.3.3.3"
Splitting "TypeIt4Me 5.2" to "TypeIt4Me" Version "5.2"

Original issue: http://code.google.com/p/munki/issues/detail?id=27

Code review request

From [email protected] on September 27, 2010 13:40:47

Purpose of code changes on this branch: added pkg/installed apps features After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=33

View Manifest Repo in Web Browser

From [email protected] on August 03, 2010 18:19:37

I am interested in viewing the XML manifest files in a web browser. Currently, we use TextMate to view the XML files as a project and then search and copy our files from the repo.

Original issue: http://code.google.com/p/munki/issues/detail?id=15

Apple Update list has blank list items under non-english 10.5 systems

From vongablersahm on September 02, 2010 08:49:41

What steps will reproduce the problem? 1. Install munki on 10.5 system
2. Set system language to german
2. Set InstallAppleSoftwareUpdates to true in ManagedInstalls.plist
3. start Managed Software Update What is the expected output? What do you see instead? A list of available software updates should be displayed by munkis interface. Instead, the list is displayed with completely empty titles and descriptions - but you see the restart icons and can highlight every empty line. This is confusing for end-users, as they will not click on the "update now" button if they can not see what will be installed. What version of the product are you using? On what operating system? munki 0.5.2 on 10.5.8. it also happens up to the current revisions. Please provide any additional information below. The problem seems to be in the parseDist subroutine of appleupdates.py. It explicitly checks for English as language and fails to parse any update information when a different language is given in the update catalog file:

            if 'language' in strings.attributes.keys():
                if strings.attributes['language'
                                         ].value.encode(
                                                    'UTF-8') == "English":
                    for node in strings.childNodes:
                        text += node.nodeValue

Proposed solution: use any language or use english first, and if not available, any language.

Original issue: http://code.google.com/p/munki/issues/detail?id=22

FEATURE REQUEST: wake the screen when munki installer or MunkiStatus runs

From [email protected] on July 21, 2010 13:36:06

I was thinking that it could be useful to have munki wake up the sleeping screen while it runs, at least when munki starts installing something and when MunkiStatus.app launches in GUI userspace.

Usually a keyboard press wakes up the screen?

Sort of empty keypress (this emulates ctrl-only keypress) can be sent using applescript:
/usr/bin/osascript -e 'tell application "System Events"' -e 'key code "" using control down' -e 'end tell'

But I guess in this case it would be cleaner to use standard Cocoa frameworks for that (though I do not know how...)

Original issue: http://code.google.com/p/munki/issues/detail?id=11

optional_installs that cannot be installed on current OS should not generate a warning

From [email protected] on September 21, 2010 15:45:30

What steps will reproduce the problem? 1. Add an item to an optional_installs list that is only for 10.6.x
2. Run managedsoftwareupdate on a 10.5 machine What is the expected output? What do you see instead? INFO or silent; instead WARNING, Example below:

WARNING: Could not process item dpix for optional install:
WARNING: No pkginfo for dpix found in catalogs: production

Original issue: http://code.google.com/p/munki/issues/detail?id=29

client does not delete any catalogs that are no longer needed

From [email protected] on September 15, 2010 11:54:39

What steps will reproduce the problem? 1. Add a valid catalog to a manifest for a client
2. Run managedsoftwareupdate
3. Remove the catalog added in step 1
4. Run managedsoftwareupdate What is the expected output? What do you see instead? Expected: /Library/Managed Installs/catalogs/ should contain only the catalogs currently listed in the applicable manifests.
Actual: no-longer referenced catalogs continue to be cached. Please use labels and text to provide additional information. Reported by Gary Bernstein on 15 Sep 2010

Original issue: http://code.google.com/p/munki/issues/detail?id=28

FEATURE REQUEST: Installation loop check

From [email protected] on August 09, 2010 13:22:45

Request for new functionality in munki: Installation loop check

Could munki have a mechanism which keeps track of installation counts for the same package? Eevery time munki installs something installation log gets a line like:
Aug 09 22:35:12 Install of Firefox-US-3.5.8: SUCCESSFUL (install_count:001)

And I guess that if one tries to build a postflight script which tries to check if certain packages have been installed many times within a timeframe then date formatting in log should be slightly different. I would prefer this formatting:
2010-08-09 22:35:12 YYYY-MM-DD hh:mm:ss

So if you could change the log formatting at least, then it would be easier to build a postflight script which looks for installations that may be looping.

Original issue: http://code.google.com/p/munki/issues/detail?id=17

Don't call verifySoftwarePackageIntegrity more than necessary

From [email protected] on September 23, 2010 17:19:47

What steps will reproduce the problem? 1.Create installer items for each of the major applications in the iLife 09 suite
2.Add those items to a manifest for a machine that does not have them installed, so it will install each of them.
3. Be annoyed when verifySoftwarePackageIntegrity() is called five times for the iLife09.dmg, each time taking over a minute to generate the checksum.

We should verify the package only when it is initially downloaded, not when download_installeritem() returns a file that's already in the cache.

Original issue: http://code.google.com/p/munki/issues/detail?id=31

FEATURE REQUEST: Countdown until forced install/uninstall takes place

From [email protected] on November 11, 2010 17:06:52

Have a warning pop up with a countdown timer until the package is force-installed/uninstalled.

Possibly have the warning possibly be a field in the plist

Possibly have the time for the countdown an option in the plist

Original issue: http://code.google.com/p/munki/issues/detail?id=42

make_munki_pkg.sh doesn't work on non-English locales

From [email protected] on October 20, 2010 08:17:44

I had to make a number of changes for make_munki_pkg.sh to work on my system, but I didn't dare to check in the changes for fear of breaking your official builds. I also nicked a few features from make_munki_pkg_from_svn.sh and changed the script so that it does as much as possible without sudo (all the chowns are at the end).

Is there a reason for handling Info.plist and Description.plist manually, after packagemaker runs?

Original issue: http://code.google.com/p/munki/issues/detail?id=38

FEATURE REQUEST: accepted MAC addresses

From [email protected] on August 09, 2010 13:32:12

I was wondering if manifest could have a list of accepted MAC-addresses:

accepted_mac_addresses

00:12:34:56:78:90
00:22:33:44:55:66
01:ab:20:cd:33:ef

If managedsoftwareupdate finds this definition in manifest then it checks if the current client has any valid addresses.
This could be optional and if accepted_mac_addresses-array does not exist then munki does not care about that.

It may be best to check only the built-in Ethernet MAC (except with MacBookAir but its internal Airport card is usually defined as en0 by the system).

It may be better to use MAC address formatting without colons like 01ab20cd33ef.

I would use this as a general manifest which includes all MAC addresses of accepted clients. And when creating a new manifest for a client/group this goes to included_manifests.

This may help security of munki when munki-server is not set up using certs for munki client authentications. This does not give as strong security as cerificates so I am not really sure if this helps or hinders.
It may make things more complicated as sysadmin has to maintain MAC address lists in manifest files...but increasing security is always more work.

Original issue: http://code.google.com/p/munki/issues/detail?id=18

FEATURE REQUEST: multiple manifest/package sources

From [email protected] on July 21, 2010 14:18:38

FEATURE REQUEST:

Could munki support multiple repos for manifests and packages?

Munki would use the first defined repo as default and if it gets no response then moves along down the list.

These settings could be an array containing those fallback sources too.

CatalogURL

http://munki4mac/repo
http://10.20.30.41/munki/repo
http://10.20.30.42/munki/repo

PackageURL

http://10.20.30.50/munki_pkgs
http://10.20.40.51/munki_pkgs

Is this separated CatalogURL and PackageURL working already or is it just SoftwareRepoURL?

Original issue: http://code.google.com/p/munki/issues/detail?id=13

NSInvalidArgumentException - Class OC_PythonObject: no such selector: _cfTypeID

From [email protected] on November 15, 2010 04:23:42

What steps will reproduce the problem? 1. Upgrade to 0.7.0.887
2. /usr/local/munki/managedsoftwareupdate --checkonly What is the expected output? What do you see instead? bash-3.2# /usr/local/munki/managedsoftwareupdate --checkonly
preflight logged for GotvidMacPro

Managed Software Update Tool
Copyright 2010 The Munki Project https://code.google.com/p/munki ERROR: Could not retrieve catalog testing from server. (that's fine, no packages in testing right now).
ERROR: Error 22: The requested URL returned error: 404
ERROR: Could not retrieve catalog testing from server.
ERROR: Error 22: The requested URL returned error: 404
ERROR: Could not retrieve catalog testing from server.
ERROR: Error 22: The requested URL returned error: 404
ERROR: Could not retrieve catalog testing from server.
ERROR: Error 22: The requested URL returned error: 404
The following items will be installed or upgraded:
+ AdobeFlashPlayer -10.1.102.64.0
Adobe® Flash® Player is a cross-platform browser-based application runtime that delivers uncompromised viewing of expressive applications, content, and videos across screens and browsers.
ERROR: Unexpected error in updatecheck:
ERROR: Traceback (most recent call last):
File "/usr/local/munki/managedsoftwareupdate", line 555, in main
updatecheckresult = updatecheck.check(client_id=options.id)
File "/usr/local/munki/munkilib/updatecheck.py", line 2623, in check
munkicommon.savereport()
File "/usr/local/munki/munkilib/munkicommon.py", line 339, in savereport
os.path.join(pref('ManagedInstallDir'), 'ManagedInstallReport.plist'))
File "/usr/local/munki/munkilib/FoundationPlist.py", line 92, in writePlist
dataObject, NSPropertyListXMLFormat_v1_0, None)
ValueError: NSInvalidArgumentException - Class OC_PythonObject: no such selector: _cfTypeID

Traceback (most recent call last):
File "/usr/local/munki/managedsoftwareupdate", line 703, in
main()
File "/usr/local/munki/managedsoftwareupdate", line 559, in main
munkicommon.savereport()
File "/usr/local/munki/munkilib/munkicommon.py", line 339, in savereport
os.path.join(pref('ManagedInstallDir'), 'ManagedInstallReport.plist'))
File "/usr/local/munki/munkilib/FoundationPlist.py", line 92, in writePlist
dataObject, NSPropertyListXMLFormat_v1_0, None)
ValueError: NSInvalidArgumentException - Class OC_PythonObject: no such selector: _cfTypeID Please use labels and text to provide additional information. bash-3.2# defaults read /Library/Preferences/ManagedInstalls
{
AdditionalHttpHeaders = (
"Authorization: Basic XXXXXXXXXXXXXXXXXXX=="
);
ClientIdentifier = "litshum_sv_testing.plist";
InstallAppleSoftwareUpdates = 1;
LastCheckDate = "2010-11-15 12:20:00 +0100";
LastCheckResult = 1;
LastNotifiedDate = "2010-11-15 08:53:57 +0100";
SoftwareRepoURL = "https://munki.xxx.gu.se:xxxx/";
}

Original issue: http://code.google.com/p/munki/issues/detail?id=44

makepkginfo on a pkg on a network volume creates a broken RestartAction key

From [email protected] on November 12, 2010 06:17:00

What steps will reproduce the problem? 1. Place flat package on network volume (like your mounted munki repo)
2. makepkginfo /Volumes/Munki/repo_root/pkgs/flat.pkg What is the expected output? What do you see instead? RestartAction
installer: Error verifying FlashPlugin package contents: Paketet kan inte installeras från en nätverksvolym. Kopiera paketet till en lokal volym och försök igen. Please use labels and text to provide additional information. getRestartInfo needs to check the exit status of installer (in this case it's 1). I'll make a patch, but should I fail, warn, or silently ignore RestartAction?

Original issue: http://code.google.com/p/munki/issues/detail?id=43

FEATURE REQUEST: use custom background image in loginwindow

From [email protected] on July 21, 2010 13:23:30

I would like to use custom background image while munki is running in loginwindow.

Definition for /path/to/custom_image should be in ManagedInstalls.plist and possible key could be named something like BkgndImagePath.
If image is not found then munki should use standard loginwindow background.

Original issue: http://code.google.com/p/munki/issues/detail?id=10

Munki tools package should not require a restart

From [email protected] on March 10, 2010 13:41:09

To avoid user interruption and unnecessary downtime, it would be great if the
munki tools package didn't require a restart when installing the tools.

Original issue: http://code.google.com/p/munki/issues/detail?id=5

Munki Code Review Request; pkg hash verification

From [email protected] on August 31, 2010 08:18:35

Purpose of code changes on this branch: Adds SHA-256 hash verification to Munki packages via ManagedInstalls.plist setting and pkginfo plist keys. After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=21

FEATURE REQUEST: new installer type, copyitems

From [email protected] on July 21, 2010 14:30:57

Munki could have a new installer type:
copyitems

items_to_copy

/JAlbum

where array items refers to files or directories containing other items on dmg root.

Basically munki recursively copies the defined items (directories/files) from source dmg to /Applications in target system.

This could ultimately replace current "copy app from dmg"-task?

Original issue: http://code.google.com/p/munki/issues/detail?id=14

Package creation scripts need to be cleaned up and merged, and should produce an mpkg.

From [email protected] on October 26, 2010 09:43:44

See issue 38 for background.

code/tools/make_munki_pkg.sh and make_munki_pkg_from_svn.sh should be merged, and they should create an mpkg with app/lib/usr sub-packages.

Original issue: http://code.google.com/p/munki/issues/detail?id=41

MSU.app stop button pressed remembered for next munki-status run

From [email protected] on November 27, 2010 17:30:32

What steps will reproduce the problem? 1. Launch MSU.app manually
2. Change an optional install.
3. Click 'update'
4. Press 'stop' during the munki status run
5. [results are displayed ... perhaps they shouldn't be]
6. Click 'update'
7. Munki-status run stops promptly, and log file indicates it is because the stop button was pressed. (it hasn't been, it was pressed in the last run) What is the expected output? What do you see instead? A stopped run probably shouldn't take the user back to the results pane, but exit (or provide a popup then exit).

If it is legitimate that munki-status be run multiple times (in the same running instance of MSU.app), it shouldn't remember that the stop button was pressed between munki-status runs.

Original issue: http://code.google.com/p/munki/issues/detail?id=49

Load "secure config" plist in prefs() for secondary preferences file with secure permissions.

From [email protected] on October 04, 2010 13:57:47

Purpose of code changes on this branch: "defaults write" gives world-read privileged to all plists it changes. Furthermore, Managed Software Update.app runs as regular users (not root) and requires read access to ManagedInstalls.plist. The main reason for this change is so ManagedInstalls.plist is not used to store sensitive information.

Load "secure config" plist in prefs() for secondary preferences file with secure permissions. //Secure/SecureConfig.plist where Secure dir is not world-readable, so admins can still "defaults write" on SecureConfig.plist and it'll still be protected. After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=34

Uninstalling Packages not working correctly in Snow Leopard

From [email protected] on May 31, 2010 12:46:12

Starting with OSX 10.6, receipts are now stored
in /private/var/db/receipts instead of the normal
location /Library/Receipts. What is the expected output? What do you see instead? The current removepackages.py code does not import bom's
from /private/var/db/receipts during the initDatabase call. So when you go
to remove a package that was installed in 10.6, it fails to locate the
required bom to remove it. What version of the product are you using? On what operating system? munkitools-0.5.1.533.0 on OSX 10.6.3 Please provide any additional information below. I have attached the patch to fix this issue and have tested to make sure
it works. Hope this helps.

Original issue: http://code.google.com/p/munki/issues/detail?id=6

Code Review Request: preflight/postflight permissions verification

From [email protected] on September 07, 2010 12:38:31

Purpose of code changes on this branch: preflight/postflight permissions verification for security purposes; only root and the munki process should have write permissions to these files. After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=25

info output should display installs and upgrades separately.

From [email protected] on September 23, 2010 08:36:56

What steps will reproduce the problem? 1. create a manifest where there are both managed_installs and managed_updates.
2. run managedsoftwareupdate
3. see output like:
"""
Downloading package-install.dmg...
0..20..40..60..80..100
Downloading package-update.dmg...
0..20..40..60..80..100
The following items will be installed or upgraded:

• PackageInstall
• PackageUpdate
  """

Desired output would be more like:
"""
Downloading package-install.dmg...
0..20..40..60..80..100
Downloading package-update.dmg...
0..20..40..60..80..100
The following items will be installed:

• PackageInstall
  The following items will be updated:
• PackageUpdate
  """

The output comes from here: http://www.google.com/codesearch/p?hl=en#mI0VsCpr0cU/trunk/code/client/munkilib/updatecheck.py&d=4&l=2533 It seems all installs (both new and updates) are lumped install managed_installs, so we either need to separate them or just have a "install_type" key that allows the code to see if it's an install, update, etc.

Original issue: http://code.google.com/p/munki/issues/detail?id=30

MSU.app doesn't pop up on Login window with non-apple keyboard

From [email protected] on November 15, 2010 14:59:57

What steps will reproduce the problem? 1. Plug a non-Apple keyboard into a machine that is ready for first boot munki bootstrapping
2. Startup machine. Keyboard Wizard pops up and MSU.app is not displayed. 3. What is the expected output?
MSU.app is expected to pop up and show the process of the installs at the login window.

What do you see instead?
Instead, they Keyboard Wizard appears an no Munki status is displayed (It seems that only one or the other can be displayed?) What version of the product are you using? On what operating system? 0.7.0.875 Please provide any additional information below. Munki rocks! :)

Original issue: http://code.google.com/p/munki/issues/detail?id=45

munkiimporting a .app fails if you change the item name

From [email protected] on October 21, 2010 04:56:00

Removing a space from the item name fails:

galaga:repo_root pelle$ /usr/local/munki/munkiimport ~/Applications/The\ Unarchiver.app
Making disk image containing The Unarchiver.app...
created: /var/folders/m8/m8CDhrdvH-iq2BJ+b8+jyk+++TI/-Tmp-/tmpy79Ykt/The Unarchiver.dmg
Disk image created at: /var/folders/m8/m8CDhrdvH-iq2BJ+b8+jyk+++TI/-Tmp-/tmpy79Ykt/The Unarchiver.dmg
Item name [The Unarchiver]: TheUnarchiver
Display name []:
Description []:
Version [2.5.0.0.0]: 2.5
Catalogs [testing]:

  Item name: TheUnarchiver

Display name:
Description:
Version: 2.5
Catalogs: : testing

Import this item? [y/n] y
Upload installer item to subdirectory path [None]:
Copying The Unarchiver.dmg to /Volumes/Munki/repo_root/pkgs/The Unarchiver.dmg...
Traceback (most recent call last):
File "/usr/local/munki/munkiimport", line 417, in
main()
File "/usr/local/munki/munkiimport", line 407, in main
pkginfo_path = copyPkginfoToRepo(pkginfo, options.subdirectory)
File "/usr/local/munki/munkiimport", line 185, in copyPkginfoToRepo
index, pkginfo_ext)
TypeError: not all arguments converted during string formatting

Original issue: http://code.google.com/p/munki/issues/detail?id=39

Munki throws exception when encountering installed pkgs without pgk-version

From vongablersahm on September 06, 2010 03:52:05

What steps will reproduce the problem? 1. Install Now Up-To-Date 5.3.2
2. Create a manifest that references this package
3. managesoftwareupdate will throw an exception What is the expected output? What do you see instead? Munki should see that the package is already installed and do nothing. Instead, it shows the following exception:

bash-3.2# /usr/local/munki/managedsoftwareupdate --checkonly
Managed Software Update Tool
Copyright 2010 The Munki Project https://code.google.com/p/munki ERROR: Unexpected error in updatecheck:
ERROR: Traceback (most recent call last):
File "/usr/local/munki/managedsoftwareupdate", line 479, in main
updatecheckresult = updatecheck.check(id=options.id)
File "/usr/local/munki/munkilib/updatecheck.py", line 2187, in check
installinfo)
File "/usr/local/munki/munkilib/updatecheck.py", line 1325, in processManifestForInstalls
installinfo)
File "/usr/local/munki/munkilib/updatecheck.py", line 1202, in processInstall
if not isInstalled(pl):
File "/usr/local/munki/munkilib/updatecheck.py", line 966, in isInstalled
if compareReceiptVersion(item) in (-1, 0):
File "/usr/local/munki/munkilib/updatecheck.py", line 544, in compareReceiptVersion
installedvers = munkicommon.getInstalledPackageVersion(pkgid)
File "/usr/local/munki/munkilib/munkicommon.py", line 951, in getInstalledPackageVersion
(pkgid, foundvers))
UnboundLocalError: local variable 'foundvers' referenced before assignment

The problem lies within a faulty package installed by Now Up-To-Date. However munki should be robust enough to survive such a problem.

bash-3.2# /usr/sbin/pkgutil --pkg-info-plist com.nowsoftware.installer.commonservices
2010-09-06 11:55:21.235 pkgutil[1223:903] PackageKit: *** Missing bundle identifier: /Library/Receipts/PGP.pkg

install-time 1246633725 pkgid com.nowsoftware.installer.commonservices receipt-plist-version 1 volume / What version of the product are you using? On what operating system? Munki 0.5.2.572 on Mac OS X 10.6. Please provide any additional information below. An easy workaround would be to provide a bogus version number when no pkg-version is given by changing line 946 in munkicommon.py to:

        if "pkg-version" in pl:
            foundvers = pl["pkg-version"]
        else:
            foundvers = 0

Original issue: http://code.google.com/p/munki/issues/detail?id=23

optional_install cannot be removed if also a managed_update

From [email protected] on November 26, 2010 22:54:08

What steps will reproduce the problem? 1. List an item in both optional_installs and managed_updates in a manifest
2. Use MSU.app to install the optional install.
3. Attempt to use MSU.app to uninstall the optional install.
4. Application is not uninstalled - log:
"WARNING: Will not attempt to remove (application) because some version of it is in the list of managed installs, or it is required by another managed install." What is the expected output? What do you see instead? - If the item is only in the internal managed_installs array because it is a managed_update, then be able to process it for removal. Care would need to be taken if it is in the managed_installs array for multiple reasons (is a managed_update, also required by something in managed_install).

Original issue: http://code.google.com/p/munki/issues/detail?id=47

FEATURE REQUEST: set permissions on appdmg installer

From [email protected] on July 21, 2010 13:14:56

FEATURE REQUEST: set permissions on appdmg installer

I found out that by default munki applies the following permissions to a copied .app:
owner:root, group:admin, modes:755.

I am having some issues with Firefox.app as I would like to have admin users permission to use the internal update feature. If user has no write permissions on Firefox then it cannot update itself.

It would be helpful if munki could set copied .app permissions.
Permissions could be defined in pkginfo like this:

set_app_permissions


owner
0
group
80
mode_owner
u+rwX
mode_group
g+rwX
mode_others
o+rX

This example gives admin group read-write permissions.

When munki finds that these are defined then it sets .app permissions using:
/usr/sbin/chown -R $owner:$group "/Applications/CopiedApp.app"
/bin/chmod -R "$mode_owner","$mode_group","$mode_others" "/Applications/CopiedApp.app"

Original issue: http://code.google.com/p/munki/issues/detail?id=9

Add --ciphers HIGH to limit curl ssl ciphers usage

From [email protected] on October 22, 2010 13:02:19

Purpose of code changes on this branch: Add --ciphers HIGH to limit curl ssl ciphers usage After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=40

mdfind takes multiple minutes if a NTFS bootcamp volume is mounted

From [email protected] on November 26, 2010 23:30:36

Relating to:
munkicommon.getSpotlightInstalledApplications()

** What steps will reproduce the problem?
0. Need a computer with a bootcamp partition

1. time /usr/bin/mdfind "kMDItemKind = 'Application'"
2. in Disk Utility unmount the bootcamp volume
3. time /usr/bin/mdfind "kMDItemKind = 'Application'"

** What is the expected output? What do you see instead?
On my MBAir:

• 2min22s when Bootcamp mounted.
• 0m0.072s when Bootcamp is not mounted.
  Spotlight can't do its thing on a read-only volume, but will still try to search it!

** Possible fix:
Reimplement:
munkicommon.getSpotlightInstalledApplications()
as a loop over the '/' directory:
/usr/bin/mdfind -onlyin /Applications
/usr/bin/mdfind -onlyin /Library
/usr/bin/mdfind -onlyin /Users
/usr/bin/mdfind -onlyin /System
... etc ...
deliberately skipping /Volumes at the stage of mdfind rather than as a post-processing exclusion.

** Why a problem:

• on manual check, multiple minutes wasted
• on auto check, high disk I/O for a couple of minutes while the user is trying to work
• particularly for people using managed_updates, this check is triggered every time (if using a installs item of type application); for those only using managed_installs, once all apps are up to date this check is not triggered.

Original issue: http://code.google.com/p/munki/issues/detail?id=48

Adobe CS5 updates still not working when in loginwndow

From [email protected] on August 10, 2010 00:29:43

What steps will reproduce the problem? 1. Trying to get munki install CS5 Bridge 4.0.2 update What is the expected output? What do you see instead? Should install now with copy_local=true?

Excerpt of munki log:
Installing Adobe Bridge CS5 (1 of 1)...
Mounting disk image AdobeBridge_4.0.2_mul_AdobeUpdate.dmg...
Running Adobe Patch Installer...
ERROR: Error : Unable to complete Silent workflow
ERROR: Adobe Setup error: 7: Unable to complete the silent workflow

Using copy_local=true. What version of the product are you using? On what operating system? munkitools 0.6.0 Build 661 on Mac OS X 10.6.4. Please provide any additional information below. When installing update as GUI user with MSU.app not logging out it installs fine.

Original issue: http://code.google.com/p/munki/issues/detail?id=19

managedsoftwareupdate: "UnboundLocalError: local variable 'manifest' referenced before assignment"

From [email protected] on July 28, 2009 21:58:21

What steps will reproduce the problem? 1. setup Munki serveras per inc'l README
2. download and install munkitools-0.3.2.pkg.zip
3. install and edit /Library/Preferences/ManagedInstalls.plist
4. exec managedsoftwareupdate What is the expected output? What do you see instead? - expected: managedsoftwareupdate should fetch the client manifest

• actual: Python error,
  "Traceback (most recent call last):
  File "./managedsoftwareupdate", line 249, in
  main()
  File "./managedsoftwareupdate", line 168, in main
  result = updatecheck.check(id=options.id)
  File "/usr/local/munki/munkilib/updatecheck.py", line 1429, in check
  mainmanifestpath = getPrimaryManifest(id)
  File "/usr/local/munki/munkilib/updatecheck.py", line 1208, in getPrimaryManifest
  if not manifest:
  UnboundLocalError: local variable 'manifest' referenced before assignment" What version of the product are you using? On what operating system? 0.3.2, Mac OS X Leopard 10.5.7 Please provide any additional information below. - updatecheck.py: Python doesn't seem to like the 'if not manifest:' conditional statement on line
  1208
• Declaring manifest prior to the testing is a a fix but better maybe to use try/except blocks?

Original issue: http://code.google.com/p/munki/issues/detail?id=2

Munki pkg descriptions dishonors newlines

From [email protected] on July 21, 2010 14:10:46

What steps will reproduce the problem? 1. MunkiStatus.app launches and dishonors newlines in pkg description field. 2. 3. What is the expected output? What do you see instead? I would like to see newlines so the description field is more readable. What version of the product are you using? On what operating system? 0.5.2.572, 10.6.x Please provide any additional information below. My pkginfo-files are UTF-8, editing them TextWrangler, using UNIX-newlines.
Should I use some special code to get munki showing newlines?

Original issue: http://code.google.com/p/munki/issues/detail?id=12

FEATURE REQUEST: limiting Apple updates

From [email protected] on August 09, 2010 13:10:22

Request for new functionality in Munki: limiting Apple updates

Munki client could check client manifest if it has ignored_apple_updates:

ignored_apple_updates

Bluetooth Firmware Update_
Security Update_
Safari*
Mac OS X Update 10.6.4

If this definition is found then munki runs something like this:

softwareupdate -l | egrep "Bluetooth Firmware Update_|Safari_|Security Update*|Mac OS X Update 10.6.4" > "/Library/Managed Installs/ignored_apple_updates.txt"
(This file should be removed every time before softwareupdate -l is run.)

If ignored updates are caught then munki will write out a text file containing those items and suppress installation of those items. Then it is easy to use a postflight script to check the contents of this file and notify sysadmin that this client has some Apple updates which are on hold by munki (and probably need to be installed manually).

Then munki downloads and installs the remaining Apple updates using the list of accepted updates. (Probably doing something like this: softwareupdate -i iTunesX-9.2.1 061-8457-2.4.1 RAWCameraUpdate3.2-3.3)

This way it could be possible to let sysadmin to decide when certain updates should be installed if ever.

This should work also if this is a separate manifest (named like 10.6-ignored-apple-updates.plist) not assigned directly to just one client. I am using separate manifests like 10.6-apps-for-all, 10.6-apps-for-students, 10.6-apps-for-teachers. And when creating a manifest for a certain client (or client group) I just include these general manifests in included_manifests.

Original issue: http://code.google.com/p/munki/issues/detail?id=16

Code review request

From [email protected] on November 29, 2010 15:02:50

Purpose of code changes on this branch: wrap os.listdir() to always return unicode When reviewing my code changes, please focus on: After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=50

Unattended Installs/Removals Code Review Request

From [email protected] on October 17, 2010 17:28:14

Purpose of code changes on this branch: Allow for key "unattended" to be set in pkginfo plists, which will automatically install the application without notifying/prompting the user. This is just iteration one, and there is certainly room for improvement.

Note: I tested with managed_installs and managed_updates, but not managed_removals; however it shouldn't be any different.

Original issue: http://code.google.com/p/munki/issues/detail?id=37

Unhelpful error message with corrupt pkgsinfo

From [email protected] on October 08, 2010 05:14:17

What steps will reproduce the problem? 1. Add a bad pkgsinfo file
2. Run makecatalogs
3. Get an unhelpful error message that makes it What is the expected output? What do you see instead? butler:munki lits$ makecatalogs .
Adding Adium-1.3.10 to common...
Adding AdobeFlashPlayer -10.1r82 to common...
Adding Ebrary-0.9.6 to common...
Adding EndNoteX3-13.0.0.5726 to common...
Adding Firefox_EN-3.6.9 to english...
Adding Firefox_SV-3.6.9 to swedish...
Adding Flip4MacWMV-2.3.4.1 to common...
Traceback (most recent call last):
File "/usr/local/munki/makecatalogs", line 135, in
main()
File "/usr/local/munki/makecatalogs", line 132, in main
makecatalogs(repopath)
File "/usr/local/munki/makecatalogs", line 76, in makecatalogs
pkginfo = plistlib.readPlist(filepath)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plistlib.py", line 78, in readPlist
rootObject = p.parse(pathOrFile)
File "/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/plistlib.py", line 405, in parse
parser.ParseFile(fileobj)
xml.parsers.expat.ExpatError: not well-formed (invalid token): line 1, column 0
butler:munki lits$ What version of the product are you using? On what operating system? 0.6.0.759 Please provide any additional information below. Actually printing which file fails and why would make it easier to correct the error.

Original issue: http://code.google.com/p/munki/issues/detail?id=35

Disable highlighted button status of cancel button at login window install.

From christophergrande on August 17, 2010 09:13:30

What steps will reproduce the problem? 1. Install updates at login window.
2. Cancel button is highlighted.
3. Accidentally pressing of the space bar will activate the cancel button and stop any running updates. What is the expected output? What do you see instead? Pressing the cancel button should be an active task for the user, with the button highlighted accidentally triggering the button is possible. What version of the product are you using? On what operating system? 6.0.664. Snow Leopard Please provide any additional information below.

Original issue: http://code.google.com/p/munki/issues/detail?id=20

Issue Installing Pro Applications Update 2010-01 with 0.5.2.533

From [email protected] on June 24, 2010 09:03:59

What steps will reproduce the problem? 1. Install Apple Software Updates with Munki.
2. Attempt to Install Pro Application Update 2010-01 What is the expected output? What do you see instead? Expected:
Update installs.

Actual:
Update installation fails immediately:

bash-3.2# managedsoftwareupdate -vvv --installonly
Managed Software Update Tool
Copyright 2010 The Munki Project https://code.google.com/p/munki Installing Pro Applications Update 2010-01 (1 of 1)...
suppress_bundle_relocation: False
Error - This is not a supported installation method.
Install of Apple Loops Utility failed.
ERROR: ------------------------------------------------------------------------------
ERROR: installer: Error - This is not a supported installation method.
ERROR: ------------------------------------------------------------------------------ What version of the product are you using? On what operating system? 10.6.4 Munki 0.5.2.533 Please provide any additional information below. Here is the update that fails to install. http://support.apple.com/kb/DL949

Original issue: http://code.google.com/p/munki/issues/detail?id=7

Code Review Request: Allow for dynamic Client Identifier generation through custom plugin code.

From [email protected] on September 07, 2010 10:17:38

Purpose of code changes on this branch: Allow for dynamic Client Identifier generation through custom plugin code.

Note the security features around plugin code (both ManagedInstalls.plist and the plugin module must have owner/group matching Munki process, and not be world writable). After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=24

makepkginfo installing old(?) version of ManagedInstalls.plist

From [email protected] on March 03, 2010 09:23:29

If /Library/Preferences/ManagedInstalls.plist is missing, makepkginfo
installs a new copy. This can be confusing, as the version it installs is
different from the example copy included in the source repository. Also,
the version installed by makepkginfo does not contain the ManifestURL
key, which appears to be required. What steps will reproduce the problem? 1. Install the munki package on a clean machine
2. Run makepkginfo What is the expected output? What do you see instead? I guess I'd expect makepkginfo not to install the preference file at all, as
chance are, it wont' work. If it must, then it should install a current copy
that matched the example in SVN.

Original issue: http://code.google.com/p/munki/issues/detail?id=3

Adobe CS5 updates will not install in login window

From [email protected] on July 16, 2010 11:48:44

What steps will reproduce the problem? 1. Run munki when no GUI user is logged in. 2. 3. What is the expected output? What do you see instead? Adobe CS5 updates should install like Acrobat 9 Pro updates do behind the scene, I guess?
Or they just need a GUI user to be logged in for them to install?

When I run Managed Software Updates.app manually CS5 updates install fine. What version of the product are you using? On what operating system? munki 0.5.2.572.0 on Mac OS X 10.63 and 10.6.4. Please provide any additional information below. Thanks for munki, it has been very helpful for me even with sub-zero release numbers.

Original issue: http://code.google.com/p/munki/issues/detail?id=8

makepkginfo: insufficient unsupported pkg handling

From [email protected] on July 28, 2009 18:07:11

What steps will reproduce the problem? 1. download stuffit expander 2009 (arrives as and application wrapped in a dmg)
2. exec makepkginfo /path/to/stuffit.dmg
3. n/a What is the expected output? What do you see instead? - expected output should be an informational error

• makepkginfo provides no feedback, it simply exits What version of the product are you using? On what operating system? - Munki 0.3.2, Mac OS X Leopard Server 10.5.7 Please provide any additional information below. - Trivial UI error, but the user should receive some indication that the pkg/dmg did not contain
  a valid source.

Original issue: http://code.google.com/p/munki/issues/detail?id=1

Code Review Request: allow for custom/additional HTTP headers to be sent with curl

From [email protected] on September 08, 2010 14:06:50

Purpose of code changes on this branch: We have a need to send some extra headers with all curl calls to the Munki server. These headers will be dynamically generated via preflight execution and populate and array of strings with key "AdditionalHttpHeaders" in ManagedInstalls.plist. After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=26

Code review request

From [email protected] on October 13, 2010 14:12:28

Purpose of code changes on this branch: add filesystem query code based on BSD getfsstat()

add isNFS() method to determine if a given path (file or directory) is on NFS
storage

use isNFS in getLSInstalledApplications() After the review, I'll merge this branch into: /trunk

Original issue: http://code.google.com/p/munki/issues/detail?id=36

updatecheck.py uses incorrect URL when downloading manifests via https

From [email protected] on March 08, 2010 08:06:21

What steps will reproduce the problem? 1. Configure munki to use SSL certs. In particular, set SoftwareRepoURL to
start with "https://
2. /usr/local/munki/managedsoftwareupdate -v -v -v --checkonly

What is the expected output?
My manifest should be downloaded.

What do you see instead?
managedsoftwareupdate tries to download from an invalid url.

Looking at the code, line 1689 is only checking for "http:// Since my
client is configured to use "https:// it tries to request a nested manifest.
This patch fixes the problem, but may not be the most elegant way to do
so:

svn diff updatecheck.py

Index: updatecheck.py

--- updatecheck.py ( revision 498 )
+++ updatecheck.py (working copy)
@@ -1691,7 +1691,8 @@
manifest_dir = os.path.join(munkicommon.pref('ManagedInstallDir'),
"manifests")

• if partialurl.startswith("http://"
• if ((partialurl.startswith("http://" or (partialurl.startswith("https://")

• then it's really a request for the client's primary manifest

  manifesturl = partialurl
  manifestname = "client_manifest.plist"

Original issue: http://code.google.com/p/munki/issues/detail?id=4