[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Change By:
Ben Walding
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 to 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 problemOne 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. DiscussionThe 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
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
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.h4. Stack Trace{noformat}java.io.IOException: Failed to install to 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 problemOne 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. DiscussionThe 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
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
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. h4. Stack Trace {noformat}java.io.IOException: Failed to install to 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. {quote} [1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding updated an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
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.{quote}[1] https://github.com/jenkinsci/jenkins/blob/jenkins-1.651.2/core/src/main/java/hudson/FilePath.java#L767
Add Comment
[JIRA] (JENKINS-37745) Tool installer prematurely connecting to download URLs on master
Title: Message Title
Ben Walding created an issue
Jenkins / JENKINS-37745
Tool installer prematurely connecting to download URLs on master
Issue Type:
Bug
Assignee:
Jesse Glick
Components:
core
Created:
2016/Aug/29 1:27 AM
Priority:
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
