keeleysam / munki-exported Goto Github PK
View Code? Open in Web Editor NEWAutomatically exported from code.google.com/p/munki
License: Other
Automatically exported from code.google.com/p/munki
License: Other
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.