• Type: Bug
• Resolution: Duplicate
• Priority: Blocker
• Component/s: remoting
• Labels:

  • proxy
  • slave
  • url
• Environment:

  Jenkins on port 8080, Apache proxy for SSL connections.

1. http-dump.txt

   1 kB

   2013-01-28 19:14

[JENKINS-16511] Jenkins behind a proxy sends JNLP agents incorrect URL

John Cook created issue - 2013-01-28 19:14

John Cook made changes - 2013-01-28 19:17

Description

Original: Once I upgraded to Jenkins 1.5, my slave agent ("mac-mini") could no longer connect. Here's an example session (I changed the hostname and credentials to protect the guilty): $ java -jar ./slave.jar -jnlpCredentials myuser:mypassword -jnlpUrl https://ci.mydomain.com/jenkins/computer/mac-mini/slave-agent.jnlp -noCertificateCheck Skipping HTTPS certificate checks altoghether. Note that this is not secure at all. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener <init> INFO: Hudson agent is running in headless mode. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://ci.mydomain.com/jenkins/, http://127.0.0.1:8080/jenkins/] Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently java.lang.Exception: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently at hudson.remoting.Engine.run(Engine.java:168) I then used Charles Proxy to capture the HTTP traffic to see what was going on. I've attached a file of that capture, but the relevant problem is here: <argument>-url</argument><argument>http://ci.mydomain.com/jenkins/&lt;/argument> The problem is that the slave is being told to connect via HTTP, but (thanks to our proxy) it is only available via HTTPS. I checked my configuration and it is correct. I believe the issue is caused by this change on January 15th: https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527#L0R1877 . The protocol of the request as far as Jenkins knows is HTTP. However the client needs to use the HTTPS protocol I configured for our root URL.

New: Once I upgraded to Jenkins 1.5, my slave agent ("mac-mini") could no longer connect. Here's an example session (I changed the hostname and credentials to protect the guilty): {code} $ java -jar ./slave.jar -jnlpCredentials myuser:mypassword -jnlpUrl https://ci.mydomain.com/jenkins/computer/mac-mini/slave-agent.jnlp -noCertificateCheck Skipping HTTPS certificate checks altoghether. Note that this is not secure at all. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener <init> INFO: Hudson agent is running in headless mode. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://ci.mydomain.com/jenkins/, http://127.0.0.1:8080/jenkins/] Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently java.lang.Exception: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently at hudson.remoting.Engine.run(Engine.java:168) {code} I then used Charles Proxy to capture the HTTP traffic to see what was going on. I've attached a file of that capture, but the relevant problem is here: {code} <argument>-url</argument><argument>http://ci.mydomain.com/jenkins/&lt;/argument> {code} The problem is that the slave is being told to connect via HTTP, but (thanks to our proxy) it is only available via HTTPS. I checked my configuration and it is correct. I believe the issue is caused by [this change on January 15th|https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527#L0R1877]. The protocol of the request as far as Jenkins knows is HTTP. However the client needs to use the HTTPS protocol I configured for our root URL.

John Cook made changes - 2013-01-28 19:18

Description

Original: Once I upgraded to Jenkins 1.5, my slave agent ("mac-mini") could no longer connect. Here's an example session (I changed the hostname and credentials to protect the guilty): {code} $ java -jar ./slave.jar -jnlpCredentials myuser:mypassword -jnlpUrl https://ci.mydomain.com/jenkins/computer/mac-mini/slave-agent.jnlp -noCertificateCheck Skipping HTTPS certificate checks altoghether. Note that this is not secure at all. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener <init> INFO: Hudson agent is running in headless mode. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://ci.mydomain.com/jenkins/, http://127.0.0.1:8080/jenkins/] Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently java.lang.Exception: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently at hudson.remoting.Engine.run(Engine.java:168) {code} I then used Charles Proxy to capture the HTTP traffic to see what was going on. I've attached a file of that capture, but the relevant problem is here: {code} <argument>-url</argument><argument>http://ci.mydomain.com/jenkins/&lt;/argument> {code} The problem is that the slave is being told to connect via HTTP, but (thanks to our proxy) it is only available via HTTPS. I checked my configuration and it is correct. I believe the issue is caused by [this change on January 15th|https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527#L0R1877]. The protocol of the request as far as Jenkins knows is HTTP. However the client needs to use the HTTPS protocol I configured for our root URL.

New: Once I upgraded to Jenkins 1.5, my slave agent ("mac-mini") could no longer connect. Here's an example session (I changed the hostname and credentials to protect the guilty): {code} $ java -jar ./slave.jar -jnlpCredentials myuser:mypassword -jnlpUrl https://ci.mydomain.com/jenkins/computer/mac-mini/slave-agent.jnlp -noCertificateCheck Skipping HTTPS certificate checks altoghether. Note that this is not secure at all. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener <init> INFO: Hudson agent is running in headless mode. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://ci.mydomain.com/jenkins/, http://127.0.0.1:8080/jenkins/] Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently java.lang.Exception: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently at hudson.remoting.Engine.run(Engine.java:168) {code} I then used Charles Proxy to capture the HTTP traffic to see what was going on. I've attached a file of that capture, but the relevant problem is here: {code:xml} <argument>-url</argument><argument>http://ci.mydomain.com/jenkins/&lt;/argument> {code} The problem is that the slave is being told to connect via HTTP, but (thanks to our proxy) it is only available via HTTPS. I checked my configuration and it is correct. I believe the issue is caused by [this change on January 15th|https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527#L0R1877]. The protocol of the request as far as Jenkins knows is HTTP. However the client needs to use the HTTPS protocol I configured for our root URL.

John Cook made changes - 2013-01-28 19:21

Description

Original: Once I upgraded to Jenkins 1.5, my slave agent ("mac-mini") could no longer connect. Here's an example session (I changed the hostname and credentials to protect the guilty): {code} $ java -jar ./slave.jar -jnlpCredentials myuser:mypassword -jnlpUrl https://ci.mydomain.com/jenkins/computer/mac-mini/slave-agent.jnlp -noCertificateCheck Skipping HTTPS certificate checks altoghether. Note that this is not secure at all. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener <init> INFO: Hudson agent is running in headless mode. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://ci.mydomain.com/jenkins/, http://127.0.0.1:8080/jenkins/] Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently java.lang.Exception: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently at hudson.remoting.Engine.run(Engine.java:168) {code} I then used Charles Proxy to capture the HTTP traffic to see what was going on. I've attached a file of that capture, but the relevant problem is here: {code:xml} <argument>-url</argument><argument>http://ci.mydomain.com/jenkins/&lt;/argument> {code} The problem is that the slave is being told to connect via HTTP, but (thanks to our proxy) it is only available via HTTPS. I checked my configuration and it is correct. I believe the issue is caused by [this change on January 15th|https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527#L0R1877]. The protocol of the request as far as Jenkins knows is HTTP. However the client needs to use the HTTPS protocol I configured for our root URL.

New: Once I upgraded to Jenkins 1.5, my slave agent ("mac-mini") could no longer connect. Here's an example session (I changed the hostname and credentials to protect the guilty): {code} $ java -jar ./slave.jar -jnlpCredentials myuser:mypassword -jnlpUrl https://ci.mydomain.com/jenkins/computer/mac-mini/slave-agent.jnlp -noCertificateCheck Skipping HTTPS certificate checks altoghether. Note that this is not secure at all. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener <init> INFO: Hudson agent is running in headless mode. Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://ci.mydomain.com/jenkins/, http://127.0.0.1:8080/jenkins/] Jan 28, 2013 1:45:43 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently java.lang.Exception: http://ci.mydomain.com/jenkins/tcpSlaveAgentListener/ is invalid: 301 Moved Permanently at hudson.remoting.Engine.run(Engine.java:168) {code} I then used Charles Proxy to capture the HTTP traffic to see what was going on. I've attached a file of that capture, but the relevant problem is here: {code:xml} <argument>-url</argument><argument>http://ci.mydomain.com/jenkins/&lt;/argument> {code} The problem is that the slave is being told to connect via HTTP, but (thanks to our proxy) Jenkins is only available via HTTPS. I checked my configuration and it is correct. I believe the issue is caused by [this change on January 15th|https://github.com/jenkinsci/jenkins/commit/460e508155187918e8c0f4fd0bb66a99cfe78527#L0R1877]. The protocol of the request from Apache to Jenkins *is* HTTP, however the client must use HTTPS as I configured our root URL.

John Cook made changes - 2013-01-28 19:22

Summary

Original: Jenkins Behind Proxy Sends JNLP Agent Incorrect URL

New: Jenkins behind a proxy sends JNLP agents incorrect URL

Collapse comment: Jesse Glick added a comment - 2013-01-28 19:36

Jesse Glick added a comment - 2013-01-28 19:36

Folding into JENKINS-16368.

Expand comment: Jesse Glick added a comment - 2013-01-28 19:36

Jesse Glick added a comment - 2013-01-28 19:36 Folding into JENKINS-16368 .

Jesse Glick made changes - 2013-01-28 19:36

Link

New: This issue duplicates JENKINS-16368 [ JENKINS-16368 ]

Jesse Glick made changes - 2013-01-28 19:36

Resolution		New: Duplicate [ 3 ]
Status	Original: Open [ 1 ]	New: Resolved [ 5 ]

R. Tyler Croy made changes - 2016-07-25 23:55

Workflow

Original: JNJira [ 147333 ]

New: JNJira + In-Review [ 192345 ]