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

JNLP not considering plain hostnames when evaluating NO_PROXY

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • remoting
    • None
    • Jenkins 2.89.2
      Jenkins remoting 3.1.4
      Jenkins swarm 3.7
    • Remoting 3.28

      Encountering a 502 Bad Gateway error when fetching the slave-agent.jnlp file through the swarm client. I have traced this down to being an issue with the way the no_proxy settings are evaluated in Jenkins remoting (swarm is currently evaluating the proxy settings correctly but remoting is not). It currently will ignore any no_proxy settings that consist of hostnames without a domain suffix, i.e. "localhost" or "jenkinsmaster".

      The use case for this is that I am running a docker swarm on a corporate proxy and need to be able to exclude my Jenkins master from the proxy in order for the slaves to be able to communicate.

      I believe this is a simple fix here: https://github.com/jenkinsci/remoting/blob/master/src/main/java/hudson/remoting/Util.java#L132-L140

      The regex should be changed such that the '.' is optional and that the hostname/domain can have underscores '_'.

          [JENKINS-48778] JNLP not considering plain hostnames when evaluating NO_PROXY

          Adam Hodges added a comment -

          Solution provided in JENKINS-32326 does not allow for simple hostnames in no_proxy

          Adam Hodges added a comment - Solution provided in JENKINS-32326 does not allow for simple hostnames in no_proxy

          Hervé Devos added a comment -

          I am encountering the same issue in same context : corporate proxy and need to connect the slave agent to my jenkins master with simple hostname (in a Docker environment)

          Hervé Devos added a comment - I am encountering the same issue in same context : corporate proxy and need to connect the slave agent to my jenkins master with simple hostname (in a Docker environment)

          Adam Hodges added a comment -

          hdevos I'm not sure how close our setups are, but I did find a workaround. In a docker network you can append the stack/network name as a domain and it will resolve. For example <service_name>.<stack_name>. Stack name did not work for me but network name did. Hope that helps as a workaround for this issue.

          Docs: https://docs.docker.com/docker-cloud/apps/service-links/#discovering-services-or-containers-on-another-stack

          Adam Hodges added a comment - hdevos I'm not sure how close our setups are, but I did find a workaround. In a docker network you can append the stack/network name as a domain and it will resolve. For example <service_name>.<stack_name>. Stack name did not work for me but network name did. Hope that helps as a workaround for this issue. Docs: https://docs.docker.com/docker-cloud/apps/service-links/#discovering-services-or-containers-on-another-stack

          Hervé Devos added a comment -

          ajhodges Thanks for your suggestion, i am deploying a basic docker-compose environment so unfortunately I don't have access to a stack name.

          My "workaround" is to use jenkins IP instead of simple hostname but my proxy configuration is now dirty and statically resolved before my agent launch 

          Hervé Devos added a comment - ajhodges Thanks for your suggestion, i am deploying a basic docker-compose environment so unfortunately I don't have access to a stack name. My "workaround" is to use jenkins IP instead of simple hostname but my proxy configuration is now dirty and statically resolved before my agent launch 

          Adam Hodges added a comment -

          hdevos I just confirmed that I can ping <service_name>.<network_name> as well with a simple docker compose stack. The network name will be "<directory_name>_default" by default but you can verify by checking docker network ls

          Hope that works!

          Adam Hodges added a comment - hdevos I just confirmed that I can ping <service_name>.<network_name> as well with a simple docker compose stack. The network name will be "<directory_name>_default" by default but you can verify by checking docker network ls Hope that works!

          Hervé Devos added a comment -

          I wasn't aware of this, thanks Adam! In fact I declared a dedicated network to my compose stack, therefore my container "complete" address is <container_name>.<directory_name>_<network_name> 

          Hervé Devos added a comment - I wasn't aware of this, thanks Adam! In fact I declared a dedicated network to my compose stack, therefore my container "complete" address is <container_name>.<directory_name>_<network_name> 

          Hervé Devos added a comment - - edited

          Looks like there is another issue with this Util class:

          when using docker compose network dns adress : <container_name>.<directory_name>_<network_name>  (e.g: jenkins.test_mycomposenetwork), host does not match specified regexp in https://github.com/jenkinsci/remoting/blob/master/src/main/java/hudson/remoting/Util.java#L132 

          Hervé Devos added a comment - - edited Looks like there is another issue with this Util class: when using docker compose network dns adress : <container_name>.<directory_name>_<network_name>  (e.g: jenkins.test_mycomposenetwork), host does not match specified regexp in  https://github.com/jenkinsci/remoting/blob/master/src/main/java/hudson/remoting/Util.java#L132  

          Adam Hodges added a comment -

          hdevos maybe try this to set a name without the directory name in there? https://docs.docker.com/compose/compose-file/compose-file-v2/#name-1

           

          I'll add the '_' to this issue.

          Adam Hodges added a comment - hdevos maybe try this to set a name without the directory name in there? https://docs.docker.com/compose/compose-file/compose-file-v2/#name-1   I'll add the '_' to this issue.

          Jeff Thompson added a comment -

          Here's a PR to re-work the no_proxy implementation: https://github.com/jenkinsci/remoting/pull/293

          It should deal with this report and provide additional, new capabilities.

          Jeff Thompson added a comment - Here's a PR to re-work the no_proxy implementation: https://github.com/jenkinsci/remoting/pull/293 It should deal with this report and provide additional, new capabilities.

          Jeff Thompson added a comment -

          This will be picked up by a Jenkins weekly build soon.

          Jeff Thompson added a comment - This will be picked up by a Jenkins weekly build soon.

            Unassigned Unassigned
            ajhodges Adam Hodges
            Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: