When trying to get policies from our 9.8 JSS test server with a 10.11 Mac (the GM Candidate, build 15A282b), I get following crash :
bash-3.2# jamf version
bash-3.2# jamf policy -verbose verbose: JAMF binary already symlinked verbose: JAMF agent already symlinked verbose: Checking for an existing instance of this application...
Checking for policies triggered by "recurring check-in"... verbose: Checking for active ethernet connection... verbose: No active ethernet connection found... verbose: The Management Framework Settings are up to date. verbose: Found 7 matching policies. verbose: Removing any cached policies for this trigger. verbose: Parsing servers... verbose: Parsing Policy XXXX (179)... verbose: Parsing Policy XXXX (132)... verbose: Parsing Policy XXXX (160)... verbose: Parsing Policy XXXX (90)... verbose: Parsing Policy XXXX (524)... verbose: Parsing Policy XXXX (194)... verbose: Parsing Policy XXXX (3)... verbose: Parsing Policy XXXX (179)...
Executing Policy Install XXXX... verbose: Starting install...
2015-09-18 08:38:55.127 jamf[4481:70779] Terminating app due to uncaught exception 'URL Connection Error', reason: 'Connection failure: "The operation couldn’t be completed. ( error 404.)"'
Call stack at first throw:
( 0 CoreFoundation 0x940359b9 raiseError 276 2 CoreFoundation 0x940358cd 141 3 jamf 0x00251bce -[JAMFHTTPRequest connection:didFailWithError:] 385 5 CFNetwork 0x91512792 ___ZL34_NSURLConnectionDidReceiveResponseP16_CFURLConnectionP14_CFURLResponsePKv_block_invoke 77 7 CFNetwork 0x9150e875 -[NSURLConnectionInternalConnection invokeForDelegate:] 269 9 CFNetwork 0x9150e6ae -[NSURLConnectionInternal _withActiveConnectionAndDelegate:] 88 11 CFNetwork 0x91512643 ___ZN27URLConnectionClient_Classic28_delegate_didReceiveResponseEP14_CFURLResponse_block_invoke 113 13 libdispatch.dylib 0x96b1c88b _dispatch_client_callout 459 15 libdispatch.dylib 0x96b2ad79 ___dispatch_block_create_block_invoke 70 17 CoreFoundation 0x93ef1139 CFArrayApplyFunction 141 19 CFNetwork 0x915e738a _ZThn16_N19RunloopBlockContext24multiplexerClientPerformEv 326 21 CFNetwork 0x9150e0dc _ZN17MultiplexerSource8_performEPv 15 23 CoreFoundation 0x93f2fe6b __CFRunLoopDoSources0 994 25 CoreFoundation 0x93f2ec46 CFRunLoopRunSpecific 123 27 Foundation 0x9d70d02c -[NSRunLoop(NSRunLoop) runMode:beforeDate:] 184 29 jamf 0x0025001d -[JAMFHTTPRequest submitRequest] 872 31 jamf 0x001b09cb -[PackageDownload downloadApplePackage:fromURL:] 2477 33 jamf 0x000f9161 _ZN3pkg7installER15GlobalVariables 12680 35 jamf 0x00140938 _Z16checkForPoliciesiPKPcR15GlobalVariables 5437 37 jamf 0x000c5567 main 53
Trace/BPT trap: 5
Did someone hit a similar issue?
I haven't updated to 9.8 yet, but I'm seeing exactly the same thing. Was hoping it was a glitch with 9.73 but the fact you're seeing it with 9.8 worries me a bit. According to the release notes for 9.8, there will be another update once 10.11 is released to provide compatibility with 10.11 (and add the new VPP functionality - yay!). Hopefully this will be resolved by then, but was hoping to do a bit more testing before Apple's release.
Having said that, it seems to be an NSURL issue when the binary tries to start downloading the pkg. I know that 10.11 has made some of the TLS / SSL stuff much stricter than before in the name of security, so wondering if it might have something to do with the ssl configuration on the web server not meeting 10.11's more stringent requirements?
Hi there @Olivier, thank you so much for helping us out and providing this information!! The community we have here is just so amazing; I love how ahead of the game on testing you are!
Full support for 10.11 will be included in a release beyond 9.8. If there's any time, I would love to see results with 10.11 against the current 9.81 beta. If there are any issues with 9.8 and 10.10 (or lower machines) please let us know so we can make the teams aware of new bugs, otherwise we'll continue 10.11 fixes against that newest beta.
Mea culpa, it was a problem with our JSS test infra, as we were using HTTP package download method on this test subnet (not HTTPS), and some Apache settings somehow reverted to some defaults values after we updated OSX on the DP...
Edited the Apache webserver settings, and updated to 9.81b1 as well : no problems so far with 10.11 GM Candidate (HTTP or SMB method).
@Olivier Thank you for the follow up. I'm super pumped with those test results, glad 9.81b1 was helpful! Please let us know if there are any issues with 9.81b1 and 10.11 in the beta discussions area. We're monitoring that heavily knowing the 10.11 release date is right around the corner.
@pkerns : are you sure you also get "The operation couldn’t be completed. ( error 404.)" in the error message?
- If yes, I would advise you to check what URL the jamf client requests to your server, and what you can access when browsing your casper share with a browser, when "allow directory listing" is temporary enabled. Crossing this with server access log files, this can help to debug basic 404 errors.
In my case, I wrongly assumed that my pkg download was done over SMB, so thought it was a problem of jamf client talking to JSS server
- If not, then this is probably a different root cause from what I experienced. As fsjjeff said, don't fall into the easy trap of "When negotiating a TLS/SSL connection with Diffie-Hellman key exchange, OS X El Capitan requires a 1024-bit group or larger.". Put the recent GCM cipher suites (like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) in front of all others in your IIS, as they do not use DHE but ECDHE, so any El Capitan negotiation problems go away. Note : you must run a recent IIS (min 7.5 if I am not wrong). Have a look at IISCrypto free tool (https://www.nartac.com/Products/IISCrypto).
@Olivier I believe you are correct as to the base cause of my issue. However, I have enabled and ordered the cipher suites on the IIS server (using IIS Crypto) according to the list found at https://developer.apple.com/library/prerelease/ios/technotes/App-Transport-Security-Technote/ and the error persists.
I am able to manually navigate the share from the affected machine (with allow directory listing enabled) and can curl the same file successfully to the affected machine.
But I do agree, this looks more like server configuration needed for El Cap specifically, and not the JAMF product itself. :(