Windows agent connected over ssh - requires elevation to install jdk-8-orable

[Amedee Van Gasse]

There was a thread here last month "Recommended way to setup a windows agent nowadays?"

I have a (new) windows agent (Windows Server 2019) that is connected through SSH, as described in that thread. It's configured through Packer and Ansible, to avoid clickety-click Next-Next-Next-Finish.

I have a user "jenkins" on Windows, who is a regular user, not an Administrator.

When I start a job on this new agent, I get this error:

00:00:09.445 Installing C:\Users\jenkins\tools\hudson.model.JDK\jdk-8-oracle\jdk.exe 00:00:09.475 [jdk-8-oracle] $ C:\Users\jenkins\tools\hudson.model.JDK\jdk-8-oracle\jdk.exe /s ADDLOCAL="ToolsFeature" REBOOT=ReallySuppress INSTALLDIR=C:\Users\jenkins\tools\hudson.model.JDK\jdk-8-oracle /L C:\Users\jenkins\tools\hudson.model.JDK\install6146141972686424355log 00:00:10.064 ERROR: SEVERE ERROR occurs 00:00:10.064 org.jenkinsci.lib.envinject.EnvInjectException: java.io.IOException: Cannot run program "C:\Users\jenkins\tools\hudson.model.JDK\jdk-8-oracle\jdk.exe" (in directory "C:\Users\jenkins\tools\hudson.model.JDK\jdk-8-oracle"): CreateProcess error=740, The requested operation requires elevation

In short, Jenkins launches the Oracle JDK 8 installer, to install in C:\Users\jenkins\tools\hudson.model.JDK\jdk-8-oracle, and it fails to do, because the Oracle installer program, jdk.exe, requires elevated privileges to be able to install JDK8.

This contrasts with OpenJDK installers, which are just zip files that are extracted into the install directory and do not require elevated privileges.

(context: we have builds that need to run on more than one JDK, because legacy products)

In Ye Olden Days I know that Java Web Start was used to connect windows agents, and that allows you to register Jenkins as a service, which then has the required elevated privileges to install software (I think, not sure, I'm basically a Linux user for the better part of 2 decades). But as we all know, Java Web Start is going the way of the dodo, and I feel more at ease if my Linux agents and my Windows agents are configured in exactly the same way.

I have a backup plan, and that is to extract the JDK8 installation directory from the Oracle installer, zip that, put it on our Artifactory server, and use the zip as an installer in Global Tool Configuration. Before I do that, I would like to hear if others have encountered this issue before and how they have solved it.

[Mark Waite]

I use a WIndows Server 2019 ssh agent that has AdoptOpenJDK 8u275 unpacked in a user directory with JAVA_HOME set in the environment of that user to use the AdoptOpenJDK 8u275 installation.  It seems like you should not need the Oracle JDK at all if you use AdoptOpenJDK.  That avoids the requirements for purchase of an Oracle JDK license and does not require privilege escalation.  Is the Oracle JDK a requirement for some other reason?

When I run my Jenkins controller (Dockerized on Linux) on Java 11, the Windows Server 2019 ssh agent is configured to use AdoptOpenJDK 11.0.9.1 unpacked in a user directory.

Mark Waite

--
You received this message because you are subscribed to the Google Groups "Jenkins Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/dd38ac37-1952-48a7-aafd-19fd3cd092d4n%40googlegroups.com.

[Amedee Van Gasse]

The Oracle JDK is a requirement for a non-technical reason, and I am not at liberty to discuss the nature of those non-technical requirements on a public communication channel.
I know, that sounds more mysterious than it actually is. :-)

An Oracle JDK license is only required for Oracle Java SE 11+, and for updates to Oracle Java SE 8 released after January 2019.

From which you can deduce that the exact JDK 8 version we use, is 8u221.

We have jobs that have to run the same identical code on different JDK versions.

Past experiences (implementation changes in Collections, legacy code using sun.* imports,...) have learned us the hard lesson that we should not trust JDK compatibility between versions, so we run our code in parallel on _all_ JDK versions that we support.

I seriously hope that it stays a secret that there are about a dozen different JDK vendors/distributions these days, build times are already long enough as it is now with what we have...

Code snippet to illustrate:

    static javaVersions = ['jdk-8-oracle', 'jdk-11-openjdk', 'jdk-13-openjdk', 'jdk-14-openjdk', 'jdk-15-openjdk', 'jdk-16-openjdk']

When you write "unpacked in a user directory", what does that mean exactly for you?

A) JDK is "installed" in advance on the agent, either manually (next-next-next-finish) or configuration management (Chef, Puppet, Ansible,...)

B) JDK is "installed" by Jenkins, using https://$JENKINS_URL/configureTools/ -> JDK installations

We do B, but now you've got me thinking that you maybe do A?

Do you use only one single JDK version ever on each agent?

I wrote "installed", because that can either be

* Windows Installer, for Oracle JDK

* Extract zip file, for OpenJDK (for me, binaries from https://jdk.java.net/ or for you, from https://adoptopenjdk.net/)

I haven't really seriously looked at the difference between OpenJDK and AdoptOpenJDK.

-- 

Amedee Van Gasse

[Mark Waite]

On Fri, Dec 18, 2020 at 10:29 AM Amedee Van Gasse <amedee....@gmail.com> wrote:

The Oracle JDK is a requirement for a non-technical reason, and I am not at liberty to discuss the nature of those non-technical requirements on a public communication channel.
I know, that sounds more mysterious than it actually is. :-)

An Oracle JDK license is only required for Oracle Java SE 11+, and for updates to Oracle Java SE 8 released after January 2019.

From which you can deduce that the exact JDK 8 version we use, is 8u221.

We have jobs that have to run the same identical code on different JDK versions.

Past experiences (implementation changes in Collections, legacy code using sun.* imports,...) have learned us the hard lesson that we should not trust JDK compatibility between versions, so we run our code in parallel on _all_ JDK versions that we support.

I seriously hope that it stays a secret that there are about a dozen different JDK vendors/distributions these days, build times are already long enough as it is now with what we have...

Code snippet to illustrate:

    static javaVersions = ['jdk-8-oracle', 'jdk-11-openjdk', 'jdk-13-openjdk', 'jdk-14-openjdk', 'jdk-15-openjdk', 'jdk-16-openjdk']

When you write "unpacked in a user directory", what does that mean exactly for you?

A) JDK is "installed" in advance on the agent, either manually (next-next-next-finish) or configuration management (Chef, Puppet, Ansible,...)

B) JDK is "installed" by Jenkins, using https://$JENKINS_URL/configureTools/ -> JDK installations

We do B, but now you've got me thinking that you maybe do A?

That's correct.  The JDK that runs the agent is pre-installed on the agent before the agent starts.  I install it with a shell script (Unix) or PowerShell script (Windows) by unpacking the zip file provided by the AdoptOpenJDK project.  Chef, Puppet, or Ansible would do that as well.

 

Do you use only one single JDK version ever on each agent?

I run the agent with a single JDK.  When the controller is running with JDK 8u275, I try my best to run the agent with JDK 8u275.  When the controller is running with JDK 11.0.9, I try my best to run the agent with JDK 11.0.9.

Jenkins is rather forgiving of mismatches in JDK versions, but I prefer to generally keep them matched.  In my specific case, the match is imperfect since I have Raspbian agents that are "stuck" on 8u212, a FreeBSD 10 agent that is "stuck" on 8u181, a FreeBSD 12 agent that is "stuck" on 8u242, and an OpenBSD agent that is "stuck" on 8u252.   They are "stuck" there because I've not found newer versions for those environments yet.

I can run other JDK's as part of agent jobs with the Jenkins AdoptOpenJDK tool installer plugin.  That plugin is similar to the Oracle JDK tool installer plugin but provides AdoptOpenJDK rather than Oracle JDK.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/64660224-54e8-46a8-929e-3215d77f6376n%40googlegroups.com.

[Amedee Van Gasse]

Well, this has all been very interesting, and I am truly grateful for the time you took to write your answers.

I went with the backup plan - zipping the Oracle JDK 8 directory and then letting Jenkins get it from Artifactory. That works good enough for me.

I think that the conclusion is that the Oracle JDK installation executable is just something particularly nasty that has to be worked around...

[christop...@googlemail.com]

Sorry for the late answer, I am only reading this after my vacation.

Just an idea: under windows the concept of unattended installation is used when providing software updates and installation from a centralized server in a domain environment without user interaction and a lot of common installer frameworks (nsis, msi,....) support this. I'd bet there is a way to install also Oracle Java by only calling the installer-exe.

Regarding the need for priviledge escalation: the java standard installation path is on the bootdrive below program files\Java and standard users don't have write priviledges there. I'd bet that's why the installer requires admin rights. It might still work without admin right using unattended installation.

I hope that still helps...

Best regards,

Christoph