Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-51223

remoting processing of "no_proxy" env var needs improvement


    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • remoting
    • Seen as far back as v3.7 on Jenkins 2.43, and as recent as v3.15 on Jenkins 2.107

      The regular expression algorithm in org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.inNoProxyEnvVar(String)(String) does not match when a single element of a fully qualified hostname and domain is part of the no_proxy setting.


      For example, taking a host name of "jenkins.bnd-cd.svc", we tried adding ".svc", "svc", and "*.svc", "*svc", and none of them matched.


      We had to specify "bnd-cd.svc" in the no_proxy evn var.


      By comparison, in th same env, we were able to run curl with a no_proxy evn var containing ".svc" and it properly matched "jenkins.bnd-cd.svc"


      When running in kubernetes/openshift, having to specify "bnd-cd.svc" is problematic as "bnd-cd" corresponds to the project/namespace, and "svc" was the default suffix applied to all service hostnames.  We wanted to have the http_proxy/no_proxy settings be applicable across jenkins running in any project/namespace.


      In addition to proving this when running an end to end Jenkins master/agent scenario using the standard jar, we also

      a) took the logic from org.jenkinsci.remoting.engine.JnlpAgentEndpointResolver.inNoProxyEnvVar(String) and put it in a simple main program where we set host and no_proxy accordingly

      b) create debug versions of remoting.jar with additional LOGGER calls to trace the behavior

            jthompson Jeff Thompson
            gmontero Gabe Montero
            0 Vote for this issue
            4 Start watching this issue