Jenkins agent is not honoring hudson.TcpSlaveAgentListener.hostName

Rino Bino

11/1/23, 3:22 AM

Background / Environment:

Jenkins 2.3x on Ubuntu 20.04

I am trying to use a Jenkins Agent installed on the same system as Jenkins server. Ideally it will connect to just "localhost" when talking to the Jenkins controller.

Jenkins sits behind a reverse proxy which requires 2FA auth (using the official plugin).

If a reason for me using this local agent is needed, it's because having a standalone agent is a workaround for this bug.

Implementation:

Since the agent can't use the primary Jenkins URL as configured in settings (because that's the proxy URL with 2FA), Jenkins provides the setting -Dhudson.TcpSlaveAgentListener.hostName to override the main server hostname setting. This is documented here.

I've set that value and can confirm that my "custom" name is set when querying the setting:

println(System.getProperty("hudson.TcpSlaveAgentListener.hostName") )

Returns:

http://localhost:8080

Which is the local listener of Jenkins and value I expect. I can curl and wget this address without issue from the host.

The problem

When starting the agent:

java -jar /data/jenkins_home/agent.jar \
  -workDir "/data/jenkins_home/agent_workspace" \
  -failIfWorkDirIsMissing \
  -jnlpUrl http://localhost:8080/computer/local/jenkins-agent.jnlp

It tries (and fails) to connect to the primary Jenkins URL, ignoring the hudson.TcpSlaveAgentListener.hostName setting

java.io.IOException: Failed to connect to <<MY_ACTUAL_JENKINS_URL>>

So, it's ignoring the hudson.TcpSlaveAgentListener.hostName value. This seems to be the primary problem. How can I get it to not use the primary URL value and instead use the URL I give it?

Everything works fine when the primary Jenkins URL is set directly to the host and not the proxy. However I can't have the agent connect through the proxy since it involves 2FA and is intended for humans to use. I've done several scripts against Jenkins using the direct hostname without issue, this the first time I've had an issue.
Not using JNLP is an option but it's not well documented and I can't seem to get it going either. The documentation also states it REQUIRES a secret, and this local agent is meant to connect anonymously.
I've tried with the agent config setting Use WebSocket enabled and disabled. Neither work.
If I can just tell the agent to use a different URL this whole thing would be solved.

It seems like a simple thing just having an agent connect to a local listener, but apparently I mis-judged the complexity. I'm willing to pretty much configure whatever is needed to get this working so please do shout any ideas!

647

1 + 1

jenkins

Sentient

1/18/24, 1:36 AM

tracking this, running into the same issue.

Score:0

Server

Sentient

1/18/24, 2:55 AM

I think I found a way. I preregister the agents on the jenkins server. This generates in /var/lib/jenkins/nodes/agent-name/config.xml file inside that config.xml you can specify the tunnel how it communicates back to the server. In the config below this is an internal dns (bypassing my proxy). Note also that it uses the Tcp port for the agent connection.

<?xml version='1.1' encoding='UTF-8'?>
<slave>
  <name>ubuntu-1</name>
  <description>build node at ubuntu-1 (ip-192-168-xx-yy)</description>
  <remoteFS>/jenkins_workdir</remoteFS>
  <numExecutors>6</numExecutors>
  <mode>NORMAL</mode>
  <retentionStrategy class="hudson.slaves.RetentionStrategy$Always"/>
  <launcher class="hudson.slaves.JNLPLauncher">
    <tunnel>jenkins-1.cicd-preprod-internal.com:8081</tunnel>
    <workDirSettings>
      <disabled>false</disabled>
       <internalDir>remoting</internalDir>
       <failIfWorkDirIsMissing>false</failIfWorkDirIsMissing>
    </workDirSettings>
    <webSocket>false</webSocket>
  </launcher>
  <label>Ubuntu x86_64 jammy android ubuntu</label>
  <nodeProperties/>
</slave>

It is the tunnel section on the server that is then passed on via jnlp to the client

This had me puzzled for quite some time as well

+ 1

Rino Bino

1/18/24, 7:04 PM

Nice. I can't test it myself because I moved on from this issue (ended up using SSH agents) but I'll mark it as an answer since it seems sane.

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Jenkins agent is not honoring hudson.TcpSlaveAgentListener.hostName

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.