Managed Software Update - Updates show, but don't install (Mavericks)

[Mike Wilkerson]

I'm a little new to this whole setup, but I think I've done enough research at this point to know that I need help now.  I've not been able to find anyone else reporting this behavior.

Here's our setup:

- We have Reposado set up on an internal server that points to Apple's SUS (it doesn't actually host the updates, just the catalog). 
- We then use Munkitools (Managed Software Update.app) on our end users machines for Apple-only updates.

Here's our problem:

In Mavericks, we are able to run Managed Software Update.app and we do see updates available, but when you click Install, then click Log out and update, it logs out, but the updates do not actually happen.

Could this be the curl issue I've read about? Is there something else I'm missing? A nudge in the right direction would be most appreciated.

Thanks,
Mike

[Edward Marczak]

Is it specific updates you're repeatedly seeing this with?

> --
> You received this message because you are subscribed to the Google Groups
> "munki-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to munki-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.



--
Edward Marczak
w: http://www.radiotope.com/writing
p: http://google.com/+EdwardMarczak

[Mike Wilkerson]

Well, so far it has been all of them... but technically that has only been 3 updates:

- iBooks update
- Remote Desktop update
- 10.9.1 update

The behavior is the same, though, no matter which updates it needs.

Oh I forgot to mention that if you run the updates from the App Store, it does work.

[Samuel Keeley]

What version of the munkitools do you have installed?  What is the output of /usr/local/munki/managedsoftwareupdate -vvvv?

--

You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Samuel Keeley

[Gregory Neagle]

As Sam Keeley suggested in another reply, the best place to start troubleshooting is with the output of the following commands:

sudo /usr/local/munki/managedsoftwareupdate -vvvv

sudo /usr/local/munki/managedsoftwareupdate -vvvv --installonly

Without seeing this (or the equivalent output from /Library/Managed Installs/Logs/ManagedSoftwareUpdate.log), we're all just playing twenty questions.

-Greg

[Edward Marczak]

How Apple's Software Update works is undocumented, and what Reposado
does is unsanctioned (though very cool and useful). Apple will often
delete and change updates on their end, which works for their system.
However, if you've set up different branches, or delay catalog
updates, it's likely that you have information in your catalog that
points to a now non-existent file on Apple's server. I'd suggest you
look at the update in the catalog itself and see if you can download
the actual update package from the server.

[Mike Wilkerson]

Thanks everyone,

After looking through the logs, I was able to determine a few things:

- when i point the client back to the normal Apple SUS, the problem goes away.
- when pointing at our Reposado server, the log shows the following:

RGM-IT-L1:~ rgmadmin$ sudo /usr/local/munki/managedsoftwareupdate -vvvv --installonly
Managed Software Update Tool
Copyright 2010-2013 The Munki Project
http://code.google.com/p/munki

Starting...
NOTE: managedsoftwareupdate is configured to process Apple Software Updates only.
Installing available Apple Software Updates...
ERROR: Missing local Software Update catalog at /tmp/munki_swupd_cache/content/catalogs/local_install.sucatalog
Finishing...
    Getting info on currently installed applications...
Done.

[Gregory Neagle]

On Jan 9, 2014, at 9:31 AM, Mike Wilkerson <mindya...@gmail.com> wrote:

Thanks everyone,

After looking through the logs, I was able to determine a few things:

- when i point the client back to the normal Apple SUS, the problem goes away.

How do you do this? ("point" the client)

- when pointing at our Reposado server, the log shows the following:

RGM-IT-L1:~ rgmadmin$ sudo /usr/local/munki/managedsoftwareupdate -vvvv --installonly
Managed Software Update Tool
Copyright 2010-2013 The Munki Project
http://code.google.com/p/munki

Starting...
NOTE: managedsoftwareupdate is configured to process Apple Software Updates only.
Installing available Apple Software Updates...
ERROR: Missing local Software Update catalog at /tmp/munki_swupd_cache/content/catalogs/local_install.sucatalog
Finishing...
    Getting info on currently installed applications...
Done.

[Gregory Neagle]

...and I don't believe you ever told us what version of the Munki tools you are using...

-Greg

On Jan 9, 2014, at 9:31 AM, Mike Wilkerson <mindya...@gmail.com> wrote:

[Mike Wilkerson]

Oh, so sorry.  Version 0.9.2.1863.0

[Gregory Neagle]

Thank you. I still want to see the _entire_ output of 

sudo /usr/local/munki/managedsoftwareupdate -vvvv

and

sudo /usr/local/munki/managedsoftwareupdate -vvvv --installonly

-Greg

[Mike Wilkerson]

Ok, here is the output from both of those... from a freshly updated machine that is pointed to our Reposado server.

RGM-IT-L1:~ rgmadmin$ sudo /usr/local/munki/managedsoftwareupdate -vvvv

Password:

Managed Software Update Tool
Copyright 2010-2013 The Munki Project
http://code.google.com/p/munki

Starting...
NOTE: managedsoftwareupdate is configured to process Apple Software Updates only.

Checking Apple Software Update catalog...
    Caching CatalogURL https://swup1-aus.rgmadvisors.com/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_update-testers.sucatalog
    follow_redirects is True
    HTTP/1.1 304 Not Modified
    Date: Thu, 09 Jan 2014 19:24:16 GMT
    Server: Apache
    Connection: close
    ETag: "4359be0-101ffa-4edbc54474c0b"
    /tmp/munki_swupd_cache/mirror/apple.sucatalog already exists and is up-to-date.
Checking for available Apple Software Updates...
    softwareupdate cmd: ['/usr/local/munki/ptyexec', '/usr/sbin/softwareupdate', '-v', '-l', '-f', '/tmp/munki_swupd_cache/ApplicableUpdates.plist']
ERROR: softwareupdate error: 100
    The following Apple Software Updates are available to install:
        + Remote Desktop Client Update-3.7.1
        + iBooks Update-1.0.1
        + OS X Update-10.9.1
           *Restart required

Run managedsoftwareupdate --installonly to install the downloaded updates.

[Gregory Neagle]

On Jan 9, 2014, at 11:31 AM, Mike Wilkerson <mindya...@gmail.com> wrote:

Ok, here is the output from both of those... from a freshly updated machine that is pointed to our Reposado server.

RGM-IT-L1:~ rgmadmin$ sudo /usr/local/munki/managedsoftwareupdate -vvvv
Password:
Managed Software Update Tool
Copyright 2010-2013 The Munki Project
http://code.google.com/p/munki

Starting...
NOTE: managedsoftwareupdate is configured to process Apple Software Updates only.
Checking Apple Software Update catalog...
    Caching CatalogURL https://swup1-aus.rgmadvisors.com/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_update-testers.sucatalog
    follow_redirects is True
    HTTP/1.1 304 Not Modified
    Date: Thu, 09 Jan 2014 19:24:16 GMT
    Server: Apache
    Connection: close
    ETag: "4359be0-101ffa-4edbc54474c0b"
    /tmp/munki_swupd_cache/mirror/apple.sucatalog already exists and is up-to-date.
Checking for available Apple Software Updates...
    softwareupdate cmd: ['/usr/local/munki/ptyexec', '/usr/sbin/softwareupdate', '-v', '-l', '-f', '/tmp/munki_swupd_cache/ApplicableUpdates.plist']
ERROR: softwareupdate error: 100

So the softwareupdate binary is reporting an error. That's almost certainly significant!

I've seen these before, and the only way I've seen to make them go away is a reboot, assuming the problem isn't triggered by a bad sucatalog from  'https://swup1-aus.rgmadvisors.com/content/catalogs/others/index-10.9-mountainlion-lion-snowleopard-leopard.merged-1_update-testers.sucatalog'

The latter remains a possibility because you mentioned you don't see this issue if the machine is "pointed" to Apple's servers.

You could also take Munki out of the mix, "point" the machine at your internal SUS URL, and run /usr/sbin/softwareupdate -l to look for additional clues.

    The following Apple Software Updates are available to install:
        + Remote Desktop Client Update-3.7.1
        + iBooks Update-1.0.1
        + OS X Update-10.9.1
           *Restart required

Run managedsoftwareupdate --installonly to install the downloaded updates.
Finishing...
    Getting info on currently installed applications...
Done.

RGM-IT-L1:~ rgmadmin$ sudo /usr/local/munki/managedsoftwareupdate -vvvv --installonly
Managed Software Update Tool
Copyright 2010-2013 The Munki Project
http://code.google.com/p/munki

Starting...
NOTE: managedsoftwareupdate is configured to process Apple Software Updates only.
Installing available Apple Software Updates...
ERROR: Missing local Software Update catalog at /tmp/munki_swupd_cache/content/catalogs/local_install.sucatalog

Almost certainly related to the above issue.

Try removing /Library/Managed Installs/AppleUpdates.plist and  /Library/Managed Installs/swupd.

Reboot the client.

Run managedsoftwareupdate again. What happens?

[Michal Moravec]

Sorry to hijack old thread but we are seeing very similiar issue.

Setup: 

• client with OS X 10.10.5
  
• Munki 2.3.0
  
• Reposado repo (we replicate packages from Apple and do URL rewrites for .sucatalog files)
  
• HTTPS for both Munki and Reposado repos (self-signed certs at the moment)
  

1. Deploy through Deploystudio (postponed = at first boot)
   
1.   Install packages containing configuration profiles with certificate payload
2.   Install munki 
3.   Configure munki
4.   Configure Software Update (defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL)
5.   touch /Users/Shared/.com.googlecode.munki.checkandinstallatstartup
2. Restart (second boot)
   
1.   Munki installs software from munki repo
2.   Munki does NOT install Apple sofware updates from Reposado -> what happened?

  

I run managedsoftwareupdate from commandline. In this particular example I use --applesuspkgsonly but result was same without it.

It looks like I run into famous error: 100 !

managedsoftwareupdate -vvvv --applesuspkgsonly
Managed Software Update Tool
Copyright 2010-2014 The Munki Project
https://github.com/munki/munki


Starting...
    Performing preflight tasks...
    preflight stdout:     Munkireport: # Executing scripts in preflight_abort.d
    Munkireport: etc. etc.
    +++

NOTE: managedsoftwareupdate is configured to process Apple Software Updates only.
Checking Apple Software Update catalog...

    Caching CatalogURL https://reposado.replaceddomain.cz/index_production.sucatalog
    Options: {'logging_function': <function display_debug2 at 0x11263f6e0>, 'additional_headers': {u'User-Agent': u'managedsoftwareupdate/2.3.0.2519 Darwin/14.5.0 (x86_64) (MacBookAir6,2)'}, 'file': '/tmp/munki_swupd_cache/mirror/apple.sucatalog.download', 'cache_data': {
    etag = "\"2c429a-51fa8f9e5c944\"";
    "last-modified" = "Sun, 13 Sep 2015 23:04:51 GMT";
}, 'url': u'https://reposado.replaceddomain.cz/index_production.sucatalog', 'follow_redirects': True, 'download_only_if_changed': True, 'can_resume': True}
    connection_willSendRequestForAuthenticationChallenge_
    Authentication challenge for Host: reposado.domain.cz Realm: None AuthMethod: NSURLAuthenticationMethodServerTrust
    Allowing OS to handle authentication request
    Status: 304
    Headers: {u'Date': u'Mon, 14 Sep 2015 00:14:39 GMT', u'Connection': u'Keep-Alive', u'Etag': u'"2c429a-51fa8f9e5c944"', u'Keep-Alive': u'timeout=5, max=100', u'Server': u'Apache/2.4.7 (Ubuntu)'}
    Item is unchanged on the server.

    /tmp/munki_swupd_cache/mirror/apple.sucatalog already exists and is up-to-date.
Checking for available Apple Software Updates...
    softwareupdate cmd: ['/usr/local/munki/ptyexec', '/usr/sbin/softwareupdate', '-v', '-l', '-f', '/tmp/munki_swupd_cache/ApplicableUpdates.plist']
ERROR: softwareupdate error: 100

Finishing...
    Getting info on currently installed applications...

    Performing postflight tasks...
    postflight stdout:     Munkireport: # Executing scripts in postflight.d
    Munkireport:  etc. etc.
    +++

I guess undocumented softwareupdate flags have following meaning: -v is for verbose and -f is for using file instead of downloading catalog from network server.

When I ran managedsoftwareupdate multiple times I got same error or this message:

Skipping Apple Software Update check because sucatalog is unchanged, installed Apple packages are unchanged and we recently did a full check.

This is state of files in /Library/Managed Installs/swupd

/Library/Managed Installs/swupd/ApplicableUpdates.plist

<?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>date</key>
 <date>2015-09-14T10:10:30Z</date>
 <key>phase</key>
 <string>ERROR</string>
 <key>phaseError</key>
 <string>The operation couldn’t be completed. (NSURLErrorDomain error -1012.)</string>
 <key>phaseStatus</key>
 <string>INPROGRESS</string>
 <key>pid</key>
 <integer>8893</integer>
</dict>
</plist>

Only other files in swupd are:

/Library/Managed Installs/swupd/content/catalogs/apple_index.sucatalog

/Library/Managed Installs/swupd/mirror/apple.sucatalog

Both valid plist files (plutil -lint)

Manual (temporary) fix

I was able to install Apple software updates through managedsoftwareupdate after I run softwareupdate -l

Most of the times I also had to delete /Library/Managed Installs/swupd

Permament fix:

Use HTTP. We haven't reproduced this issue when we reconfigured webserver and Reposado (repoutil --configure) and clients to use HTTP.

Notes

- running apple's softwareupdate from command line always worked

- I wonder for exactly where NSURLErrorDomain error -1012 comes from

- HTTPS configuration on server was set to allow TLS 1.1 and TLS 1.2 only, adding TLS 1.0 did not help

- we replicated this issue with both EC 384b and RSA 4096b certificates 

Wild guess -> this is somehow related to our HTTPS setup and tricks munki is doing with Apple software update.

We are going to replace self-signed certificate with certificates signed by our own CA soon. I will try to get back to this issue when is happends.

I would gladly appreciate any tips how to investigate further.

Perhaps I am missing something obvious?

[Gregory Neagle]

https://developer.apple.com/library/mac/documentation/Cocoa/Reference/Foundation/Miscellaneous/Foundation_Constants/index.html#//apple_ref/doc/constant_group/URL_Loading_System_Error_Codes

NSURLErrorDomain error -1012 is described as: NSURLErrorUserCancelledAuthentication

So Munki’s internal code (gurl.py) has no trouble downloading the catalog from https://reposado.replaceddomain.cz/index_production.sucatalog

    /tmp/munki_swupd_cache/mirror/apple.sucatalog already exists and is up-to-date.
Checking for available Apple Software Updates...
    softwareupdate cmd: ['/usr/local/munki/ptyexec', '/usr/sbin/softwareupdate', '-v', '-l', '-f', '/tmp/munki_swupd_cache/ApplicableUpdates.plist']
ERROR: softwareupdate error: 100


Here, softwareupdate is throwing the error. But I suspect at this point that softwareupdate is actually using the locally-cached 

Finishing...
    Getting info on currently installed applications...
    Performing postflight tasks...
    postflight stdout:     Munkireport: # Executing scripts in postflight.d
    Munkireport:  etc. etc.
    +++

I guess undocumented softwareupdate flags have following meaning: -v is for verbose and -f is for using file instead of downloading catalog from network server.

No — -f means write the output to the file provided, here:  '/tmp/munki_swupd_cache/ApplicableUpdates.plist’

That is (poorly) documented here: `softwareupdate —testhelp`

When I ran managedsoftwareupdate multiple times I got same error or this message:

Skipping Apple Software Update check because sucatalog is unchanged, installed Apple packages are unchanged and we recently did a full check.

This is state of files in /Library/Managed Installs/swupd

/Library/Managed Installs/swupd/ApplicableUpdates.plist

<?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>date</key>
 <date>2015-09-14T10:10:30Z</date>
 <key>phase</key>
 <string>ERROR</string>
 <key>phaseError</key>
 <string>The operation couldn’t be completed. (NSURLErrorDomain error -1012.)</string>
 <key>phaseStatus</key>
 <string>INPROGRESS</string>
 <key>pid</key>
 <integer>8893</integer>
</dict>
</plist>

Only other files in swupd are:

/Library/Managed Installs/swupd/content/catalogs/apple_index.sucatalog

/Library/Managed Installs/swupd/mirror/apple.sucatalog

Munki temporarily sets the CatalogURL to use these local files.

To further troubleshoot, you could:

sudo defaults write /Library/Preferences/com.apple.SoftwareUpdate CatalogURL file://localhost/tmp/munki_swupd_cache/mirror/apple.sucatalog

softwareupdate -l

This would cause softwareupdate to use the file:// URL as the CatalogURL.

Munki’s Apple Software Update implementation under El Capitan stops redirecting and rewriting apple catalogs; I wonder if this issue would not occur for you under 10.11?

Both valid plist files (plutil -lint)

Manual (temporary) fix

I was able to install Apple software updates through managedsoftwareupdate after I run softwareupdate -l

Most of the times I also had to delete /Library/Managed Installs/swupd

Permament fix:

Use HTTP. We haven't reproduced this issue when we reconfigured webserver and Reposado (repoutil --configure) and clients to use HTTP.

Notes

- running apple's softwareupdate from command line always worked

- I wonder for exactly where NSURLErrorDomain error -1012 comes from

- HTTPS configuration on server was set to allow TLS 1.1 and TLS 1.2 only, adding TLS 1.0 did not help

- we replicated this issue with both EC 384b and RSA 4096b certificates 

Wild guess -> this is somehow related to our HTTPS setup and tricks munki is doing with Apple software update.

We are going to replace self-signed certificate with certificates signed by our own CA soon. I will try to get back to this issue when is happends.

I would gladly appreciate any tips how to investigate further.

Perhaps I am missing something obvious?

--
Find related discussion groups here:
https://github.com/munki/munki/wiki/Discussion-Group
---

You received this message because you are subscribed to the Google Groups "munki-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to munki-dev+...@googlegroups.com.

To post to this group, send email to munk...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.