Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
Docker compose file with nginx configuration provided to reproduce the issue
-
-
Jenkins 2.248
Description
I'm using nginx in a proxy setup. One public/ingress with a single upstream Jenkins instance. The attached docker-compose file can be used to recreate the exact environment. My test docker is running on Windows 10. The domain "ingress" was added hosts file as "127.0.0.1 ingress" for convenience.
Basic Jenkins setup steps, root URL is set to _http://ingress/jenkins/
Agent is connecting via JNPL with WebSocket option enabled. The following error message is reported:
C:\workdir\jenkins\http\agent-1>java -jar agent.jar -jnlpUrl http://ingress/jenkins/computer/agent-1/slave-agent.jnlp -secret 4068cc653d7d0ca16f72404ac6ad62d5fe19f5798f5b3f0807c6ecf50fba4353 -workDir "c:\workdir\jenkins\http\agent-1" Jul 08, 2020 8:33:25 PM org.jenkinsci.remoting.engine.WorkDirManager initializeWorkDir INFO: Using c:\workdir\jenkins\http\agent-1\remoting as a remoting work directory Jul 08, 2020 8:33:26 PM org.jenkinsci.remoting.engine.WorkDirManager setupLogging INFO: Both error and output logs will be printed to c:\workdir\jenkins\http\agent-1\remoting JNLP file http://ingress/jenkins/computer/agent-1/slave-agent.jnlp?encrypt=true has invalid arguments: [4068cc653d7d0ca16f72404ac6ad62d5fe19f5798f5b3f0807c6ecf50fba4353, agent-1, -webSocket, -workDir, c:\workdir\jenkins\http\agent-1, -internalDir, remoting, -url, http://ingress/jenkins/, -url, http://jenkins:8080/jenkins/, -headless, -workDir, c:\workdir\jenkins\http\agent-1, -internalDir, remoting] Most likely a configuration error in the master -webSocket supports only a single -url
There are 2 URLs in the parameter list which is rejected.
I cannot rule out the possibility of nginx configuration issue, but I followed all the guidelines.
Attachments
Issue Links
- causes
-
JENKINS-63222 Cannot use yet-another-docker-plugin JNLP agents in 2.248+
-
- Closed
-
-
JENKINS-63671 With Version 2.249.1 LTS the the Remote Agent over JNLP does not use the internal Hostname anymore
-
- Closed
-
- links to
The non-trivial-lts-backporting label is misleading: the patch merely removes a couple of lines, so it should certainly be trivial to backport. Whether it should be backported is of course up for discussion, as would be true for any patch.
I would not say that the deleted code was unused. If your reverse proxy configuration was wrong, or you were otherwise accessing Jenkins via a nonstandard URL for some reason, it would allow inbound TCP agents to connect using the nonstandard URL in case the standard URL were broken. The point is that this was a dubious decision when written, and became even less advisable after subsequent improvements in Jenkins to: guide you to define the root URL in the setup wizard; show an administrative monitor if you had not; and display an administrative monitor if it could be detected that the root URL was configured yet incorrect.