[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master

0 views
Skip to first unread message

bwalding@cloudbees.com (JIRA)

unread,
Aug 28, 2016, 9:28:02 PM8/28/16
to jenkinsc...@googlegroups.com
Ben Walding created an issue
 
Jenkins / Bug JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Issue Type: Bug Bug
Assignee: Jesse Glick
Components: core
Created: 2016/Aug/29 1:27 AM
Priority: Minor Minor
Reporter: Ben Walding

In the course of investigating a customer issue we discovered that the master is attempting a connection out to a tool installer - before attempting it on the agent.

One way to demonstrate this failure would be to set a fail always hostname verifier on the master (via script console)

HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
      return false;
    }
  }
);

From the stack trace, the failure is here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration).

Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access).

The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem.

For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.

It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine.

[1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c)
Atlassian logo

bwalding@cloudbees.com (JIRA)

unread,
Aug 28, 2016, 9:30:01 PM8/28/16
to jenkinsc...@googlegroups.com
Ben Walding updated an issue
Change By: Ben Walding
In the course of investigating a customer issue we discovered that the master is attempting a connection out to a tool installer - before attempting it on the agent.
One way to demonstrate this force a failure on the master would be to set a " fail always " hostname verifier on the master (via script console)

{code}

HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
      return false;
    }
  }
);
{code}
{quote}
From the stack trace, the The failure is was here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration).

Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access).

The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem.

For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.

It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine.

bwalding@cloudbees.com (JIRA)

unread,
Aug 28, 2016, 9:31:01 PM8/28/16
to jenkinsc...@googlegroups.com
Ben Walding updated an issue
In the course of investigating a customer issue we discovered that the master is attempting a connection out to a tool installer - before attempting it on the agent.
h4. Stack Trace

{noformat}
java.io.IOException: Failed to install <tool url> to <file path>
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:832)
at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:76)
at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:108)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
at org.jenkinsci.plugins.mongodb.MongoDBInstallation.forNode(MongoDBInstallation.java:50)
at org.jenkinsci.plugins.mongodb.MongoBu
{noformat}

h4. Forcing a problem
 One way to force a failure on the master would be to set a "fail always" hostname verifier on the master (via script console)


{code}
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
      return false;
    }
  }
);
{code}


h4. Discussion

 The failure was here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration).

Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access).

The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem.

For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.

It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine.

bwalding@cloudbees.com (JIRA)

unread,
Aug 28, 2016, 9:32:01 PM8/28/16
to jenkinsc...@googlegroups.com

bwalding@cloudbees.com (JIRA)

unread,
Aug 28, 2016, 9:43:02 PM8/28/16
to jenkinsc...@googlegroups.com
Ben Walding updated an issue
In the course of investigating a customer issue we discovered It appears that during a tool install, the master is attempting a connection out to a tool installer the remote url - before attempting it on the agent.


h4. Stack Trace

{noformat}
java.io.IOException: Failed to install <tool url> to <file path>
at hudson.FilePath.installIfNecessaryFrom(FilePath.java:832)
at hudson.tools.DownloadFromUrlInstaller.performInstallation(DownloadFromUrlInstaller.java:76)
at hudson.tools.InstallerTranslator.getToolHome(InstallerTranslator.java:68)
at hudson.tools.ToolLocationNodeProperty.getToolHome(ToolLocationNodeProperty.java:108)
at hudson.tools.ToolInstallation.translateFor(ToolInstallation.java:206)
{noformat}

h4. Forcing a problem
One way to force a failure on the master would be to set a "fail always" hostname verifier on the master (via script console)

{code}
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
    public boolean verify(String hostname, SSLSession session) {
      return false;
    }
  }
);
{code}


h4. Discussion

The failure was here [1]. But this is happening on the master. We do not really care how the master is configured; we want to do the download from the agent, for builds run in a remote workspace (the recommended configuration).

Which it does try to do, starting at line 804, falling back to a slower master-based download only if that fails (for example because the agent has no Internet access).

The problem is that we first try to get a URLConnection on the master merely to check the timestamp and other response headers plus status (so we know whether a download is even needed); normally con is then discarded without downloading content. So the fact that a failure occurred in the dummy initial connection (which would ideally be a HEAD not GET) is causing the whole tool installation to fail is a serious problem.

For a remote workspace, we should be doing even the metadata checks inside the Unpack callable.

It should not really matter whether the master’s settings were broken or not, at least not for purposes of tool downloads. One connection to the tool installer URL would be made, from the agent JVM, which (I hope) would have default Java settings that would work fine.

[1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
Reply all
Reply to author
Forward
0 new messages