-
Bug
-
Resolution: Fixed
-
Major
broken HTTP_PROXY handling on jenkins-slave (JNLP)
The proxy exclusion list (http.nonProxyHosts, no_proxy) is not taken into account on the jenkins-slave side.
This has been observed in our jenkins master/slave environment which uses JNLP.
Support for HTTP_PROXY handling on jenkins-slave side has been added with jenkins version 1.606.
Unfortunately that does not take the proxy exclusion list into account (e.g. defined by no_proxy env variable on linux).
This forces the slave to always use the proxy. Even for destinations which would be excluded by no_proxy.
Jenkins uses org.jenkins-ci.main:remoting for handling http proxy functionality.
Jenkins includes version 2.53.2 of org.jenkins-ci.main:remoting which contains the error described above.
possible solution:
1.) create new release of org.jenkins-ci.main:remoting which already contains the fix in it's master branch.
2.) update jenkins' to use this new version of org.jenkins-ci.main:remoting
see also:
- commit of fix in master branch of org.jenkins-ci.main:remoting
https://github.com/jenkinsci/remoting/commit/56d30acb89f5626320d6b47585053674a5fdfb78
- is related to
-
JENKINS-48778 JNLP not considering plain hostnames when evaluating NO_PROXY
-
- Resolved
-
- links to
We're encountering the same issue (see comment section of
JENKINS-28289for further details).It should also be noted that the proxy configuration defined by the system properties does not have precedence over the one defined by the environment variables. Indeed if you set both, you would expect the slave to actually work because http.nonProxyHosts is automatically taken in account by the JVM. But no, looks like some part rely on http_proxy (and obviously don't use no_proxy). Unless you unset all your proxy env var, the slave won't work even if your system properties are correct.
It means that on a host where you need to set those env var, there's no workaround to make the slave work.