prasannakumar123 / munki

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

ManagedInstallReports InstallResults can be wiped #108

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

1. a preflight pushes the contents of MIR[InstallResults] via network if 
available. if the values have been pushed, it clears the list.  if the values 
have not been pushed because the network is not available, they stay in the 
list.

2. managedsoftwareupdate runs and initializes the InstallResults variable to [] 
in munkicommon

3. managedsoftwareupdate calls munkicommon.savereport() in at least 1 place, 
line 715, right before postflight.  this wipes any unreported InstallResults.

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

munkicommon should initialize the InstallResults with a method like 
loadreport() etc.

Please use labels and text to provide additional information.

Agree? I'll submit a fix

Original issue reported on code.google.com by jr...@google.com on 21 Jul 2011 at 5:27

GoogleCodeExporter commented 8 years ago
Take a look in managedsoftwareupdate around line 553; there is an attempt to 
initialize the report with the previous values in some circumstances.

Since managedsoftwareupdate archives each report, you might instead want to 
keep track of which reports have been submitted (or when) and submit from the 
archive if needed.

Original comment by gregnea...@mac.com on 21 Jul 2011 at 6:48

GoogleCodeExporter commented 8 years ago
re: your L553 reference, what's the logic behind only reading the existing 
report when in installonly mode? it seems that we need to read the reports in 
ALL modes?

Original comment by jr...@google.com on 21 Jul 2011 at 8:18

GoogleCodeExporter commented 8 years ago
Reports originally reflected only what actually occurred in a given 
managedsoftwareupdate run. But when doing an --installonly run, we skip the 
entire checking phase and therefore have a lot less state info. So I added the 
reload of previous state info for that run type only.

But munki is generally stateless in that it doesn't really care what happened 
in the past (except for an --installonly run).

It sounds to me like you're thinking of the report as a description of the 
overall state as opposed to a description of the state at the last execution of 
managedsoftwareupdate.

I think you should keep track of the last successful submission date/time and 
submit not only /Library/Managed Installs/ManagedInstallReport.plist, but any 
report in /Library/Managed Installs/Archives that is newer than your last 
successful submission date/time.

Original comment by gregnea...@mac.com on 25 Jul 2011 at 7:15