Posted on 03-04-2015 07:14 PM
I've discovered what seems like buggy behavior with Java 8u40 settings sticking, and I'm hoping someone else might've already encountered this and can point me in the right direction. Obviously, one can deploy Java 8 (even update 40) fairly simply, with known techniques:
https://derflounder.wordpress.com/2015/03/04/oracles-java-8-update-40-the-good-the-bad-and-the-ugly/
However, some of our environments are not particularly well-suited to updating Java every time a new version comes out, due to possible compatibility issues with web apps, interfaces on various network appliances, or, in this case, standardized tests like PARCC. We cannot have our users (K-8 students, in our case) being prompted to update Java when they're trying to take the PARCC tests – it confuses the students, the teachers, and neither one of them has the administrative power to update Java on student machines anyway.
Thus, we need the ability to suppress these updates. This looks fairly simple, at first blush. There's a "deployment.properties" file (located in ~/Library/Application Support/Oracle/Java/Deployment) with the following line:
deployment.macosx.check.update=true
You can uncheck the "Check for Updates Automatically" checkbox on the Update tab of the Java system preference pane, click OK, enter your administrative credentials, and then go check to see that this line in the deployment.properties file has changed to:
deployment.macosx.check.update=false
Easy enough to package up (with Composer, natch) and deploy to your fleet of Macs, right? Or even to edit with a well-constructed shell script. (See https://jamfnation.jamfsoftware.com/discussion.html?id=8239, for instance.)
Unfortunately... not so fast there, hombre. The minute a user (including a "Standard", non-administrator account) opens the Java system preference pane (which opens in its own window) the preferences revert back to their original settings. This persists even if you add a line right after that (per documentation I found somewhere) as follows:
deployment.macosx.check.update.locked
This even happens if they click "Cancel" instead of "OK" (and neither option requires an administrative password!) I apologize if I've missed something here, but up until a month ago, we had no reason to install Java on our student Macs, so I'm a bit new to this problem.
-Eric
Posted on 03-05-2015 05:53 AM
You might look to this thread/script (thanks Andrew!) for some options. Personally not tested with 8u40 ...
https://jamfnation.jamfsoftware.com/discussion.html?id=6489
Oops, missed the link in your post. Thanks for the update.
I can state that I've manually updated to 8u40 on a couple of machines set to not check for updates and the settings are preserved/maintained through update. I'll need to test with fresh install.
edit: Tested with a fresh workflow, 8u40 (autopkg) and aforementioned script. Still working for me with 8u40.
Posted on 03-05-2015 10:03 AM
Whoops, that's the JAMFnation thread I thought I already linked to. I know about that one, but it appears some things have changed between 7 and 8. I contacted Andrew on Twitter and he said he's no longer working with Casper in a new job, and he has no information about whether the script works with any version of 8.
I've actually found a promising bit of info here:
https://jamfnation.jamfsoftware.com/discussion.html?id=8239#responseChild67601
...and will be testing this out today.
Posted on 03-06-2015 08:35 AM
A bit late to the party (it was out Mar 3rd really?!) - been a bit busy - still I brought some things to share! :D
Java 8 Update 40 Installer App Fun!
http://www.brunerd.com/blog/2015/03/06/java-8-update-40-installer-app-fun/
Not only an installer app, but one that doesn't even verify the integrity of it's unsigned payload!?! One word: "Orable" (say it out loud, you'll get it! ;)
And an exercise in bash scripting...
Java 8 without the Adware (aka Java8Unjunker)
http://www.brunerd.com/blog/2015/03/06/java-8-without-the-adware-aka-java8unjunker/
Posted on 03-09-2015 05:01 AM
I haven't messed with 8u40 yet, but I add this execute line to my policy and have yet to see the update auto checked since in the system pref pane (credit to @foigus )
We do use the deployment.properties file as well.
/usr/bin/defaults write /Library/Preferences/com.oracle.java.Java-Updater JavaAutoUpdateEnabled -bool false
Posted on 03-09-2015 06:56 AM
Just as a follow-up, the "promising bit of info" I linked to above...
...does seem to be working for me, and the checkbox in the preferences even stays unchecked if you wrap up with a "/usr/bin/defaults write /Library/Preferences/com.oracle.java.Java-Updater JavaAutoUpdateEnabled -bool false" command. Turns out I just needed to RTFD. Kudos to @freddie.cox for posting the link to the Java documentation in question in discussion 8239. Kudos also to @dderusha for his many contributions across several threads I referenced and providing "starter" deployment.properties and deployment.config files. Although I think the bit about the MEDIUM security level may be deprecated at this point... :-)
Posted on 03-09-2015 07:11 AM
Glad I could lend you a hand @ericwacker!
IIRC I had a hard time ever getting directly to that information at the time which is what prompted me to post the link somewhat out of the blue.
Posted on 03-09-2015 07:35 AM
What an adOracle thread, hah hah. Adorable. Orable. Sorry, normally I suppress my pun urge. Thanks to all for this.
Posted on 03-30-2015 06:13 AM
I conquered the third party app installation of Java8u40. Now I have discovered another problem with Java8u40. I'm working on new student images on MBA using 10.8.5. Added java to the third-party preference panes on the server. Also enabled Jar Launcher, Java Preferences, and Java Web Start to approved apps for student restrictions. Now when I login as a student user on the mba, I can see and click on Java in system preferences. Unfortunately, once I click on Java, I get the window: You don't have permission to use the application "java." What am I missing here. Never had this problem in previous versions of Java.
Posted on 03-30-2015 06:49 AM
Nevermind. It is definitely a Monday morning. Problem solved.