search

rikho / munki

Automatically exported from code.google.com/p/munki
Other
0 stars 0 forks source link

Processing removals in SelfServeManifest breaks managedsoftwaruepdate if manifest contains a non-existent catalog #296

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Add a catalog "foo" to a manifest's catalogs array, where foo doesn't 
actually exist in the repo.
2. Add at least one item that's available in some other catalog to 
managed_uninstalls for this client's SelfServeManifest. In this example, 
"GoogleChrome" was added to managed_uninstalls.
3. Run managedsoftwareupdate -vvvv.
4. See traceback when the client attempts to read the local catalog file (that 
doesn't exist on the disk, but was in cataloglist), triggered in 
processRemoval().

What is the expected output? What do you see instead?

    Considering item GoogleChrome-33.0.1750.152 for removal info
    Checking 'installs' items...
ERROR: Unexpected error in updatecheck:
Traceback (most recent call last):
  File "/usr/local/munki/managedsoftwareupdate", line 970, in <module>
    main()
  File "/usr/local/munki/managedsoftwareupdate", line 691, in main
    updatecheckresult = updatecheck.check(client_id=options.id)
  File "/usr/local/munki/munkilib/updatecheck.py", line 2853, in check
    installinfo, cataloglist)
  File "/usr/local/munki/munkilib/updatecheck.py", line 2086, in processManifestForKey
    installinfo)
  File "/usr/local/munki/munkilib/updatecheck.py", line 2234, in processRemoval
    catalog_pl = FoundationPlist.readPlist(localcatalog)
  File "/usr/local/munki/munkilib/FoundationPlist.py", line 70, in readPlist
    raise NSPropertyListSerializationException(errmsg)
munkilib.FoundationPlist.NSPropertyListSerializationException: stream had too 
few bytes in file /Library/Managed Installs/catalogs/development

What version of the Munki tools/InstallOSpkg tools are you using? On what
version of OS X?

2.0.0.1938, OS X 10.8.5

Please provide any additional information below.

I found this while testing Munki2, but from what I can see of the Git history 
of updatecheck.py, this should be happening in 1.x versions of the tools as 
well.

Original issue reported on code.google.com by t...@synthist.net on 21 Mar 2014 at 3:41

GoogleCodeExporter commented 9 years ago 
To clarify this issue further, I now see it's not just the case of the item 
being in SelfServeManifest, it also occurs if there is an item in 
managed_uninstalls on the server-side manifest.

Original comment by t...@synthist.net on 21 Mar 2014 at 3:53

GoogleCodeExporter commented 9 years ago 
Should be fixed here: 
http://code.google.com/p/munki/source/detail?r=06cbcd924909 in master branch, 
and here: 
http://code.google.com/p/munki/source/detail?r=085e659e9736 in the Munki2 
branch. 

Note that the fix I decided to implement was to NOT attempt to read the catalog 
file from disk, but to instead use the already-exisiting CATALOG "database" 
(actually a dictionary). This was an optimization added a long time ago, but 
apparently I forgot to change the processRemovals code to use it.

Original comment by gregnea...@mac.com on 22 Mar 2014 at 4:26