I've been doing some searching around the discussions and knowledge base, but I can't find definitive info on whether Casper Suite is yet compatible with 10.11 El Capitan (beta) and whether there is a timeline when it will be.
I had a user running OS X 10.11 beta trying to enroll using self-enrollment with Quickadd (JSS 9.73), and it would not work. She could not open the Quickadd package, error was "The operation could not be completed. (com.apple.installer.pagecontroller error -1). She is a software engineer and tried to unpack the package various ways with no luck, "Error while extracting archive: (PackageInfo): archived-checksum MD5's do not match (No such file or directory)." She did not believe the error stemmed from 10.11 on her machine. I didn't know there was any problem with 10.11 until I searched the Internets.
Could someone let me know whether the problems she had do (likely) stem from 10.11 incompatibility, or if that would be something else? I am still new to the wonders of OS X management with JAMF, as in I often “wonder” whether I am in over my head. :(
Thanks!
@dgreening Was the environment you were running casper Imaging from within 10.11?
Nope, its on a 10.10.4 based NetBoot created with AutoCasperNBI.
The initial testing I did with imaging using Casper Imaging on my production (9.73) JSS had the machine image, but enrollment failed and none of the policies worked (all software is installed after CI lays down the OS X package on a custom trigger called by a script).
It's no surprise that in-place upgrades to El Capitan are going smoothly.
Did you know that Apple has added a Compatibility exception list to the System Integrity Protection function?
That list can be found here:
/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths
In my other post on this topic, I discovered that the "paths" file contains hundreds of exceptions for programs like puppet, vagrant, shake, gutenprint, nortonscanner, folding@home, VirtualBox, and filesystem extensions like Fuse and Tuxera.
These are very well known tools in the Mac community, and the creation of this exception list means that at least a few engineers at Apple have taken notice. The exception list has also persisted for several beta cycles AND is included in the GM Candidate of El Capitan that was released yesterday.
The JAMF Software Engineers need to be made aware that this change will not be required as they had initially planned when the first beta of El Capitan had dropped.
@bradtchapman,
Why does the existence of the exception list matter? Apple giveth, Apple can also taketh away.
In the long run, it's best to go with what the OS vendor says you should do as a best practice.
One more thing...
In a recent Casper 9.8 beta, this is how JAMF has moved the binaries:
/usr/local/jamf // symbolic link
/usr/local/jamfAgent // symbolic link
/usr/local/jamf/bin/jamf // actual file
/usr/local/jamf/bin/jamfAgent // actual file
To JAMF Software Engineers, I would say this: "Bro, do you even UNIX?"
Have you looked at the "PATH" environment variable on a stock OS X system lately?
declare -x PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"
Please correct me if I'm wrong, but if JAMF moves the binaries to the location(s) mentioned above, it's my understanding that the scripts will break because they are not in locations that are part of the PATH environment variable. It will be their responsibility to modify the PATH variable with an export command.
You can see status of this using
csrutil status
To disable it (for testing) you boot into the Recovery HD and run:
csrutil disable
I'm not sure if there's a way to disable it on an active system, but that is what I know.
@rtrouton , I agree that JAMF should be following standard practice.
The binaries should go to /usr/local/bin . I sincerely hope they fix that before the final release of 9.8.
@bradtchapman,
You're wrong. The symlink is actually stored in /usr/local/bin/, so it's /usr/local/bin/jamf.
You should be able to verify this by running which jamf in Terminal on your test box. It should return /usr/local/bin/jamf.
So then maybe part of the problem is the directory structure, unless I'm reading this incorrectly (which is likely):
if [ $major_version -lt 10 ] || [ $major_version -eq 10 -a $minor_version -lt 7 ];then
jamfCLIPath=/usr/sbin/jamf
/bin/rm /Applications/JAMFQuickAdd/Binaries/jamf
/bin/mv /Applications/JAMFQuickAdd/Binaries/jamf2 $jamfCLIPath
else
jamfCLIPath=/usr/local/jamf/bin/jamf
/bin/rm /Applications/JAMFQuickAdd/Binaries/jamf2
/bin/mkdir -p /usr/local/jamf/bin
/bin/mv /Applications/JAMFQuickAdd/Binaries/jamf /usr/local/jamf/bin/jamf
/bin/ln -s /usr/local/jamf/bin/jamf /usr/local/bin
fi
It looks like it's trying to use /usr/local/jamf/bin/jamf instead of /usr/local/bin/jamf/.
Thanks, @rtrouton. I did say a "recent" 9.8 beta, but I didn't say which one. Are you running 9.8 b2?
My cloud instance is running 9.8b1.
@alexjdale and I were talking yesterday after he noticed the individual recovery key disappears and the system no longer shows up as encrypted in the JSS after upgrading to 10.11. I tested on my 9.72 JSS this morning and noticed the same thing. This could cause major issues...has anyone else noticed this?
Yep. Recovery key escrow breaks for me too.
SIP disabled systems are portable via imaging. This does not appear to help 9.73 recon - this fails to ssh in my tests:
SSH failed to start up session with host 'x.x.x.x' (kex error : did not find one of algos diffie-hellman-group1-sha1 in list curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-
But no issue using ssh from the terminal.
I also have to me too on the enroll quickadd from 9.73 on 10.11 failing:
The operation could not be completed. (com.apple.installer.pagecontroller error -1)
Which again is with SIP disabled.
