Windows server and Oracle Java updates

[Dave Bartholomew]

> After having gone through that issue I'm not sure whether someone doing
the above is in for unpleasent surprises or not.
> Does this method work reliably, with the IDP and with Java updates?

Yes, I haven't had any problems (and wouldn't expect to).
I uninstall the current Java from Control Panel.
Install the new JDK version to C:\Program Files\Java (skipping the JRE).
Overwrite with the JCE files.

This means that whenever I update Shib, I have to go to the daemon GUI and
put "C:\Program Files\Java\jre\bin\server\jvm.dll " in the Java tab (after
unchecking "Use default").

Personally, I would hesitate to automate Java updates having once
destroyed an entire server with a Java screw-up where I must have
installed the JRE inside the JDK or some such when I didn't really
understand how it worked. I tried to "undo" my mistake but eventually gave
up...

-- Dave

-----Original Message-----
From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Peter
Schober
Sent: Wednesday, November 30, 2016 4:44 PM
To: users at shibboleth.net
Subject: Re: Windows server and Oracle Java updates

* Cantor, Scott <cantor.2 at osu.edu> [2016-11-30 22:46]:
> > I'm not sure why every version of Java installs to a folder with
> the version name instead of to a generic name.
>
> You answered it yourself right in the next paragraph. ;-)
>
> > I was concerned that Java updates might break things(they have more
> > often than not in my limited experience)
>
> They can and do.

OK, I don't want automatic updates. :)

> That's why package-managed Java on Linux isn't reliable, and why
> OpenJDK is worthless because that's its only real advantage over the
> real stuff, you can't trust it.

What I want and get from packaged Java (from my experience with Debian
GNU/Linux and RHEL/CentOS to some degree) is notification when updates are
available, ideally with descriptions of the reasons to apply the upgrade
(e.g. CVE numbers), and trival methods of applying the upgrade ("apt
upgrade", "yum update") -- all within one "natural" channel for handling
other software maintenance as well. Upgrades can break stuff, sure. That's
what test instances are for.
Just because I need to test before applying (on a test system; with VMs
and containers and overpowered desktop computers there's no reason not to
do that, really) doesn't mean I have to like (or aim for) the most
complicated/manual/work intensive way of applying software upgrades.
Also, while accepting license terms in a graphical web browser,
downloading tgz files to MS-Windows, extracting them with some GUI thingy,
moving the folder around to a convenient place in the file system, and
doing some right-click-extended-settings-foo-bar-baz-environment-variables
clickery only to update JAVA_HOME may protect you from unintendedly
applying the upgrade, it sure doesn't protect you from the breakage once
you do apply the update in whatever weird way Oracle expects you to.
Meaning you'd have to apply (no matter how) elsewhere first anyway to
check for breakage.

So all of that only speaks against appying software changes to production
systems fully automated and without looking. Obviously this way madness
lies.

> PS. Yes, I'm sure lots of people have had good luck blindly updating
> Java automatically. I haven't. Over and over. Not trying it again,

I have never done so on GNU/Linux and I only considered this for a brief
moment on a MS-Windows system when confronted with the awkward and
complicated (compared to distribution-supported packages for GNU/Linux,
for example) installation and configuration method to get Java on a
Windows server and usable from the Shib IDP. Mostly considering how often
some admin person would need go through that process. If it hurts they may
stop doing that (as often as needed).

So make it easy to do something conciously, is what I'm saying.
That doesn't make manual or archaic means to upgrade/replace software a
feature, IMHO.
-peter
--
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net