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

Jenkins behind a proxy sends JNLP agents incorrect URL

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Blocker
    • Resolution: Duplicate
    • remoting
    • Jenkins on port 8080, Apache proxy for SSL connections.

    Description

      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/</argument>

      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. The protocol of the request from Apache to Jenkins is HTTP, however the client must use HTTPS as I configured our root URL.

      Attachments

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-16368 Hardcoded protocol in some links

          • Major - Major loss of function.
          • Resolved

          Activity

            Ascending order - Click to sort in descending order
            jcook793 John Cook created issue -
            jcook793 John Cook made changes -
            Field Original Value New Value
            Description 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.             		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.
            jcook793 John Cook made changes -
            Description 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.             		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.
            jcook793 John Cook made changes -
            Description 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.             		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.
            jcook793 John Cook made changes -
            Summary Jenkins Behind Proxy Sends JNLP Agent Incorrect URL Jenkins behind a proxy sends JNLP agents incorrect URL
            jglick Jesse Glick made changes -
            Link This issue duplicates JENKINS-16368 [ JENKINS-16368 ]
            jglick Jesse Glick made changes -
            Resolution Duplicate [ 3 ]
            Status Open [ 1 ] Resolved [ 5 ]
            rtyler R. Tyler Croy made changes -
            Workflow JNJira [ 147333 ] JNJira + In-Review [ 192345 ]

            People

              Unassigned Unassigned
              jcook793 John Cook
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: