Client repair fails with 'object has no attribute'

[John Meyers]

We've noticed that when a client gets sent the repair command, it fails over and over resulting the client never fixing itself...  We're using simian-2.5-and-munkitools-3.0.3-3352 on a fresh pull.  I don't see anything previously reported about this.  Also tried a complete re-install manually of the client, but the server is still pushing the "You need to repair" flag.

INFO:root:Reinstalling Munki client....

INFO:root:Fetching repair client from: https://xxx.appspot.com/repair

Traceback (most recent call last):

  File "/usr/local/munki/simian_client.py", line 87, in <module>

    sys.exit(main(sys.argv[1:]))

  File "/usr/local/munki/simian_client.py", line 73, in main

    preflight.RunPreflight(runtype, server_url=server_url)

  File "/usr/local/munki/simian/lib/python2.7/site-packages/simian-2.5-py2.7.egg/simian/mac/client/preflight.py", line 393, in RunPreflight

    flight_common.RepairClient()

  File "/usr/local/munki/simian/lib/python2.7/site-packages/simian-2.5-py2.7.egg/simian/mac/client/flight_common.py", line 910, in RepairClient

    updatecheck.getResourceIfChangedAtomically('%s/repair' % url, download_path)

AttributeError: 'module' object has no attribute 'getResourceIfChangedAtomically'

[Will Holtz]

Hi John,

I ran into this same problem. The existing code tries to call getResourceIfChangedAtomically from updatecheck. That method does not exist in updatecheck but is in fetch. So I made the following change:

diff --git a/src/simian/mac/client/flight_common.py b/src/simian/mac/client/flight_common.py

index d21f810..9690731 100755

--- a/src/simian/mac/client/flight_common.py

+++ b/src/simian/mac/client/flight_common.py

@@ -907,7 +907,7 @@ def RepairClient():

     DownloadError = fetch.DownloadError

 

   try:

-    updatecheck.getResourceIfChangedAtomically('%s/repair' % url, download_path)

+    fetch.getResourceIfChangedAtomically('%s/repair' % url, download_path)

   except DownloadError as e:

     raise RepairClientError(

         u'MunkiDownloadError getting Munki client: %s' % e)

~

Even with this modification, my repairs still fail, but this allows the preflight to complete. In my case this allowed my clients to get to a point where they no longer triggered the repair.

-Will

[John Meyers]

Thanks!   Yes, I concur it allows the client to get passed the issue.  When it attempts to download the repair package, the server returns a 403 error, presumably because the fetch call is not authenticated.

One possible solution would be to get rid of the whole client-managed repair process and instead call Google's own MacOps 'planb', which will re-install Simian, Puppet, and other critical management tools.  I'm hesitant to do that refactoring without the Google folks chiming in.

John