dinkin / munki Goto Github PK

View Code? Open in Web Editor NEW

0.0 1.0 0.0 8.05 MB

Automatically exported from code.google.com/p/munki

License: Other

Objective-C 0.71% Python 96.46% Shell 2.84%

munki's People

Contributors

Watchers

munki's Issues

FEATURE REQUEST: set permissions on appdmg installer

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:

<key>set_app_permissions</key>
<array>
    <dict>
        <key>owner</key>
        <string>0</string>
        <key>group</key>
        <string>80</string>
        <key>mode_owner</key>
        <string>u+rwX</string>
        <key>mode_group</key>
        <string>g+rwX</string>
        <key>mode_others</key>
        <string>o+rX</string>
    </dict>
</array>

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 reported on code.google.com by [email protected] on 21 Jul 2010 at 8:14

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

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 reported on code.google.com by [email protected] on 21 Sep 2010 at 10:45

Munki pkg descriptions dishonors newlines

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 reported on code.google.com by [email protected] on 21 Jul 2010 at 9:10

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

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 reported on code.google.com by [email protected] on 20 Oct 2010 at 3:17

Attachments:

make_munki_pkg.patch

Unhelpful error message with corrupt pkgsinfo

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 <module>
    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 reported on code.google.com by [email protected] on 8 Oct 2010 at 12:14

Code review request

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 reported on code.google.com by [email protected] on 13 Oct 2010 at 9:12

NSInvalidArgumentException - Class OC_PythonObject: no such selector: _cfTypeID

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
http://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 <module>
    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 reported on code.google.com by [email protected] on 15 Nov 2010 at 12:23

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

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 reported on code.google.com by christophergrande on 17 Aug 2010 at 4:13

Munki Code Review Request; pkg hash verification

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 reported on code.google.com by [email protected] on 31 Aug 2010 at 3:18

client does not delete any catalogs that are no longer needed

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 reported on code.google.com by [email protected] on 15 Sep 2010 at 6:54

Munki throws exception when encountering installed pkgs without pgk-version

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
http://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
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" 
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>install-time</key>
    <integer>1246633725</integer>
    <key>pkgid</key>
    <string>com.nowsoftware.installer.commonservices</string>
    <key>receipt-plist-version</key>
    <real>1</real>
    <key>volume</key>
    <string>/</string>
</dict>
</plist>



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 reported on code.google.com by vongablersahm on 6 Sep 2010 at 10:52

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

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 reported on code.google.com by [email protected] on 7 Sep 2010 at 5:17

Code review request

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 reported on code.google.com by [email protected] on 29 Nov 2010 at 11:02

Issue Installing Pro Applications Update 2010-01 with 0.5.2.533

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
http://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 reported on code.google.com by [email protected] on 24 Jun 2010 at 4:03

Munki tools package should not require a restart

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 reported on code.google.com by [email protected] on 10 Mar 2010 at 9:41

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

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 "%s" to "%s" Version "%s"') % (aString, aString[0:index].rstrip('v- '), possibleVersion)
        return (aString[0:index].rstrip('v- '), possibleVersion)
    else:
        print >> sys.stderr, ('Splitting "%s" to "%s" Version "%s"') % (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 reported on code.google.com by vongablersahm on 13 Sep 2010 at 2:37

packages should only be downloaded once

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 reported on code.google.com by [email protected] on 24 Sep 2010 at 2:23

Code review request

Purpose of code changes on this branch:
added pkg/installed apps features


After the review, I'll merge this branch into:
/trunk

Original issue reported on code.google.com by [email protected] on 27 Sep 2010 at 8:40

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

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?
    <key>RestartAction</key>
    <string>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.</string>

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 reported on code.google.com by [email protected] on 12 Nov 2010 at 2:17

Add --ciphers HIGH to limit curl ssl ciphers usage

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 reported on code.google.com by [email protected] on 22 Oct 2010 at 8:02

FEATURE REQUEST: limiting Apple updates

Request for new functionality in Munki: limiting Apple updates

Munki client could check client manifest if it has ignored_apple_updates:

<key>ignored_apple_updates</key>
<array>
    <string>Bluetooth Firmware Update*</string>
    <string>Security Update*</string>
    <string>Safari*</string>
    <string>Mac OS X Update 10.6.4</string>
</array>

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 reported on code.google.com by [email protected] on 9 Aug 2010 at 8:10

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

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 reported on code.google.com by vongablersahm on 2 Sep 2010 at 3:49

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

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 <module>
    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 reported on code.google.com by [email protected] on 29 Jul 2009 at 4:58

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

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.  /<ManagedInstallsDir>/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 reported on code.google.com by [email protected] on 4 Oct 2010 at 8:57

FEATURE REQUEST: accepted MAC addresses

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

<key>accepted_mac_addresses</key>
<array>
    <string>00:12:34:56:78:90</string>
    <string>00:22:33:44:55:66</string>
    <string>01:ab:20:cd:33:ef</string>
</array>

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 reported on code.google.com by [email protected] on 9 Aug 2010 at 8:32

FEATURE REQUEST: Countdown until forced install/uninstall takes place

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 reported on code.google.com by [email protected] on 12 Nov 2010 at 1:06

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

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 reported on code.google.com by [email protected] on 8 Sep 2010 at 9:06

FEATURE REQUEST: use custom background image in loginwindow

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 reported on code.google.com by [email protected] on 21 Jul 2010 at 8:23

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

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 reported on code.google.com by [email protected] on 26 Oct 2010 at 4:43

makepkginfo installing old(?) version of ManagedInstalls.plist

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 reported on code.google.com by [email protected] on 3 Mar 2010 at 5:23

Uninstalling Packages not working correctly in Snow Leopard

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 reported on code.google.com by [email protected] on 31 May 2010 at 7:46

Attachments:

removepackages.patch

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

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 reported on code.google.com by [email protected] on 28 Nov 2010 at 1:30

Don't call verifySoftwarePackageIntegrity more than necessary

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 reported on code.google.com by [email protected] on 24 Sep 2010 at 12:19

munkiimporting a .app fails if you change the item name

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 <module>
    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 reported on code.google.com by [email protected] on 21 Oct 2010 at 11:56

updatecheck.py uses incorrect URL when downloading manifests via https

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 reported on code.google.com by [email protected] on 8 Mar 2010 at 4:06

FEATURE REQUEST: new installer type, copyitems

Munki could have a new installer type:
copyitems

<key>items_to_copy</key>
<array>
    <string>/JAlbum</string>
</array>    

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 reported on code.google.com by [email protected] on 21 Jul 2010 at 9:30

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

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 reported on code.google.com by [email protected] on 21 Jul 2010 at 8:36

Adobe CS5 updates will not install in login window

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 reported on code.google.com by [email protected] on 16 Jul 2010 at 6:48

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

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 reported on code.google.com by [email protected] on 26 Nov 2010 at 10:40

info output should display installs and upgrades separately.

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 reported on code.google.com by [email protected] on 23 Sep 2010 at 3:36

View Manifest Repo in Web Browser

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 reported on code.google.com by [email protected] on 4 Aug 2010 at 1:19

makepkginfo: insufficient unsupported pkg handling

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 reported on code.google.com by [email protected] on 29 Jul 2009 at 1:07

FEATURE REQUEST: multiple manifest/package sources

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.

<key>CatalogURL</key>
<array>
    <string>http://munki4mac/repo</string>
    <string>http://10.20.30.41/munki/repo</string>
    <string>http://10.20.30.42/munki/repo</string>
</array>
<key>PackageURL</key>
<array>
    <string>http://10.20.30.50/munki_pkgs</string>
    <string>http://10.20.40.51/munki_pkgs</string>
</array>

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

Original issue reported on code.google.com by [email protected] on 21 Jul 2010 at 9:18

mdfind takes multiple minutes if a NTFS bootcamp volume is mounted

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 reported on code.google.com by [email protected] on 27 Nov 2010 at 7:30

Code Review Request: preflight/postflight permissions verification

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 reported on code.google.com by [email protected] on 7 Sep 2010 at 7:38

FEATURE REQUEST: Installation loop check

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 reported on code.google.com by [email protected] on 9 Aug 2010 at 8:22

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

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 reported on code.google.com by [email protected] on 15 Nov 2010 at 10:59

optional_install cannot be removed if also a managed_update

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 reported on code.google.com by [email protected] on 27 Nov 2010 at 6:54

Unattended Installs/Removals Code Review Request

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 reported on code.google.com by [email protected] on 18 Oct 2010 at 12:28

Adobe CS5 updates still not working when in loginwndow

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 reported on code.google.com by [email protected] on 10 Aug 2010 at 7:29

dinkin / munki Goto Github PK

munki's People

Contributors

Watchers

munki's Issues

Recommend Projects

Recommend Topics

Recommend Org