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

Swarm client should use Remoting version of master

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Minor Minor
    • swarm-plugin
    • None

      The Swarm client currently uses the remoting version declared in the pom.xml. This leads to the behavior, that it always uses the same remoting version.

      It should use the remoting version provided by the master (e.g. download the agent.jar from $rootUrl/jnlpJars/agent.jar and use it).

          [JENKINS-48477] Swarm client should use Remoting version of master

          Oleg Nenashev added a comment -

          There should be a ticket for that somewhere...
          I kinda agree with that, but I do not see a reliable way to do the transfer. Just a download is a security risk while there are HTTP connections to Jenkins

          Oleg Nenashev added a comment - There should be a ticket for that somewhere... I kinda agree with that, but I do not see a reliable way to do the transfer. Just a download is a security risk while there are HTTP connections to Jenkins

          Couldn't there be a check on SHA sums or something like that? Swarm client could download a list of valid SHA sums from jenkins.io (via HTTPS) and when the agent.jar is transfered by HTTP from the master, the swarm client checks if the SHA sum of the agent.jar is valid.

          E.g. apt is doing somethink like that when downloading deb files from repositories over HTTP, AFAIK.

          Jochen A. Fürbacher added a comment - Couldn't there be a check on SHA sums or something like that? Swarm client could download a list of valid SHA sums from jenkins.io (via HTTPS) and when the agent.jar is transfered by HTTP from the master, the swarm client checks if the SHA sum of the agent.jar is valid. E.g. apt is doing somethink like that when downloading deb files from repositories over HTTP, AFAIK.

          Oleg Nenashev added a comment -

          It requires a network connection. It could be an option of course, but it cannot be the only supported behavior. So there should be still a fallback to a whatever bundled Remoting version

          Oleg Nenashev added a comment - It requires a network connection. It could be an option of course, but it cannot be the only supported behavior. So there should be still a fallback to a whatever bundled Remoting version

          Mate Rigo added a comment -

          Mark Waite emphasises a lot to make sure that the infrastructure is all running the same java version, and the same remoting version.

          I started using this plugin only to find that my paranoid setting in the versions node monitoring disconnected the nodes, as the remoting version differs from the jenkins controller.

          Did I miss something, or is it actually safe to have different versions for remoting, since this is a very old ticket.

          Cheers!

          Mate Rigo added a comment - Mark Waite emphasises a lot to make sure that the infrastructure is all running the same java version, and the same remoting version. I started using this plugin only to find that my paranoid setting in the versions node monitoring disconnected the nodes, as the remoting version differs from the jenkins controller. Did I miss something, or is it actually safe to have different versions for remoting, since this is a very old ticket. Cheers!

            Unassigned Unassigned
            jochenafuerbacher Jochen A. Fürbacher
            Votes:
            3 Vote for this issue
            Watchers:
            4 Start watching this issue

              Created:
              Updated: