[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
Issue Type: Bug Bug
Affects Versions: current
Assignee: Unassigned
Components: core
Created: 08/Jan/13 1:59 AM
Description:

All of my windows salve cannot connect to Jenkins master after upgrading to 1.498. Following messages showed up in slaves' jenkins-slave.err:

java.io.IOException: Failed to load http://192.168.30.95/jenkins/computer/Fortify%201/slave-agent.jnlp: 403 Forbidden
at hudson.remoting.Launcher.parseJnlpArguments(Launcher.java:238)
at hudson.remoting.Launcher.run(Launcher.java:200)
at hudson.remoting.Launcher.main(Launcher.java:173)

Environment: Windows Server 2008 R2
Project: Jenkins
Priority: Major Major
Reporter: Pei-Tang Huang
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
Change By: Pei-Tang Huang (08/Jan/13 2:22 AM)
Priority: Major Blocker
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

Stop the Jenkins slave service. Pasting the jnlp url ( http://192.168.30.95/jenkins/login?from=%2Fjenkins%2Fcomputer%2FFortify%25201%2Fslave-agent.jnlp ) in my browser and input my credential, the Jenkins slave agent starts.

But after I click the File / Install as a service, the attached error message showed up to me.

Change By: Pei-Tang Huang (08/Jan/13 2:31 AM)
Attachment: jenkins-slave-error.jpg
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

I confirm this bug for Jenkins 1.498 - it appears although User "anonymous" has Overall-> Read access. Jenkins 1.497 works fine.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Trevor A commented on Bug JENKINS-16273

We had this issue and were finally able to resolve it by granting the Anonymous user the "Connect" privilege under the "Slave" section. The permissions can be found in the "Authorization" section of the "Configure Global Security" page under "Manage Jenkins."

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Jesse Glick resolved Bug JENKINS-16273 as Not A Defect

This is intentional—part of the security fix. In order to retrieve slave-agent.jnlp now, you need to provide authentication demonstrating that you are permitted to connect to the slave. This is generally done using an API token. Alternately, download the JNLP from your browser (while logged in as an admin) and save that, rather than attempting to connect to slave-agent.jnlp on the fly.

@trevora: granting the Anonymous user the "Connect" privilege effectively bypasses (part of) the security fix. Do not do this unless you are on a trusted, closed network (in which case why are you running with security at all?).

Change By: Jesse Glick (09/Jan/13 12:31 AM)
Status: Open Resolved
Resolution: Not A Defect
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Trevor A commented on Bug JENKINS-16273

@jglick: Could you please point me to some information on how to properly configure Windows slave agents after the security fix? We are running on a closed network, but I'd prefer to configure it the right way if possible. Any information would be greatly appreciated.

If I understand correctly, the Windows service downloads and runs the slave-aget.jnlp when it starts using the parameters in the slave-agent.xml file. I'm not sure how to provide it an API key.

While we are on a closed network, we run security to control who may administer the Jenkins server and who can set up build projects. We thought it best to leave our Anonymous user restricted so non-developers would not have access to the server. We only added the "Connect" privilege to get our system back up and running after the upgrade.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

Same issue here. Reading through the comments above it made me think: would it be possible to make when jnlp is first started through a web browser to save this jnlp to local Jenkins directory and automatically configure service to use this cached copy instead of requesting it from the server? This would make setting up slaves automatic again without altering security fix.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

@Jesse: This is broken for the "Logged-in users can do anything" authorization policy. The help on that suggest that this is not "security" but instead record keeping, so it really shouldn't be locked down like this. Could we allow slaves access to jnlp in this mode? Or, allow a --auth user:password option to the slave start command which doesn't seem to work right now.

Context help on "Logged-in users can do anything" from the configureSecurity page:
"This mode is useful to force users to log in before taking actions, so that you can keep record of who has done what. This setting can be also used in public-facing Jenkins, where you only allow trusted users to have user accounts."

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Change By: Duane Bronson (09/Jan/13 4:19 PM)
Resolution: Not A Defect
Status: Resolved Reopened
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves cannot connect to master through JNLP after upgrading to 1.498

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

The slave agent windows service install is also broken by this change.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

@nerdmachine: regardless of what the help on “Logged-in users can do anything” may suggest, it is a true security policy and it means that any operation requiring authentication—even GET requests which do produce any “records” to keep—must be accompanied by a valid login token.

I do not know much about the Windows service; someone who understands this code will need to evaluate how it should be provided with an API token. Without any special (Windows-specific) tool you can always download a *.jnlp file, run it manually, and when prompted ask to save it as a service; this is just a feature of Java WebStart.

Change By: Jesse Glick (09/Jan/13 4:54 PM)
Summary: Slaves  cannot connect  forbidden  to  master through  request  JNLP  after upgrading  anonymously but no clear way  to  1.498  pass API token
Labels: jnlp regression security slave
Environment: 1.498+, Windows Server 2008 R2
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
Trevor A commented on Bug JENKINS-16273

@Pei-Tang, @Jesper: For what it's worth, we found that the Windows service install wasn't broken per se but that it failed if the service already existed. We were able to log onto one of our Windows build servers, manually uninstall the service, rename or delete jenkins-slave.exe and jenkins-slave.xml, reboot the system, and then successfully reinstall the service by logging in as an admin, downloading the .jnlp file, and using the Java WebStart to install it.

However, even after reinstalling the service the build slave was unable to register with master server because the service was trying to retrieve the the .jnlp from the master each time it started and was being denied.

I have not tried manually running the .jnlp file outside the browser and installing as suggested above.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue

The remote management facility of Windows is hard for me to set correctly, I spent more than 6 hours to make all of my 6 Windows slaves run as well as before.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

I managed to fix this fairly simply on my windows slaves (tested on XP, Vista & Win 7).

1 - autheticate as a Jenkins admin in a browser of your choice and download the slave-agent.jnlp file for the slave. The download URL will be something like
http://<jenkinsurl>/computer/<slavename>/slave-agent.jnlp
and can be found in the jenkins-slave.xml file on the slave.

2 - transfer slave-agent.jnlp to the slave and store in the same folder as slave.jar and jenkins-slave.xml files

3 - edit jenkins-slave.xml and change the URL of slave-agent.jnlp to be
<a href="file:///%BASE%/slave-agent.jnlp">file:///%BASE%/slave-agent.jnlp
That means that the arguments line in jenkins-slave.xml will likely read

<arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpUrl <a href="file:///%BASE%/slave-agent.jnlp">file:///%BASE%/slave-agent.jnlp</arguments>

Now just start the slave service as normal and all should work.

Disclaimer: I haven't studied the security implications of storing slave-agent.jnlp at that location in the slave. I suspect it is fine but it would be good if someone could comment on whether there is a better location.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

Based up @Trevor and @Richard instructions here is how I got the windows slaves to run as a service again:
1 - Uninstall the service if it exists
2 - Delete the old jenkins-slave.exe and jenkins-slave.xml
3 - Start the web client and let it install the service
4 - Download the slave-agent.jnlp to the directory where the jenkins-slave.exe is
5 - Edit the jenkins-slave.xml so the it looks like this the important part is the <a href="file:///%BASE%">file:///%BASE% <arguments>-Xrs -jar "%BASE%\slave.jar" -jnlpUrl <a href="file:///%BASE%/slave-agent.jnlp">file:///%BASE%/slave-agent.jnlp</arguments>
6 - Stop your web client if it not already and restart your service.

Mine are now running.

Disclaimer: I haven't studied the security implications of storing slave-agent.jnlp at that location in the slave. I suspect it is fine but it would be good if someone could comment on whether there is a better location. Also not sure how the jnlp file gets updated if needed.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

You have to pass in an user to authenticate via "-jnlpCredentials jenkinsuser:secret":
My cmd line:
java -Xrs -jar "slave.jar" -classpath "patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci/computer/winnt-1/slave-agent.jnlp

or my jenkins-slve.xml :

<arguments>-Xrs -jar "%BASE%\slave.jar" -classpath "%BASE%\patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci.../slave-agent.jnlp</arguments>

The difference to 1.480.1 is that there is now an slave connect/disconnect right which must be given to the "jenkinsuser" (Beside overall read)

The slave installer has the bug that it does not write a correct .xml file with credentials, you have to add this manually. (Also the common-codec-1.5.jar had to be added to the classpath, because otherwiese the authentication is missing a base64 codec)

-> this works on 1.480.2

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org
 
Rainer Weinhold edited a comment on Bug JENKINS-16273

You have to pass in an user to authenticate via "-jnlpCredentials jenkinsuser:secret":
My cmd line:
java -Xrs -jar "slave.jar" -classpath "patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci/computer/winnt-1/slave-agent.jnlp

or my jenkins-slve.xml :

<arguments>-Xrs -jar "%BASE%\slave.jar" -classpath "%BASE%\patches\commons-codec-1.5.jar" -jnlpCredentials jenkinsuser:secret -jnlpUrl http://ci.../slave-agent.jnlp</arguments>

The difference to 1.480.1 is that there is now an slave connect/disconnect right which must be given to the "jenkinsuser" (Beside overall read)

The slave installer has the bug that it does not write a correct .xml file with credentials, you have to add this manually. (For LTS the common-codec-1.5.jar had to be added to the classpath, because otherwiese the authentication is missing a base64 codec : JENKINS-9679)

-> this works on 1.480.2

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

@Pei-Tang Huang: "I have configured all of my Windows slave launching method from "Launch slave agents via Java Web Start" to "Let Jenkins control this Windows slave as a Windows service" to avoid this issue"

I tried this but kept getting error:

Connecting to JenkinsSlave1
ERROR: Unexpected error in launching a slave. This is probably a bug in Jenkins
java.net.UnknownHostException: JenkinsSlave1
at java.net.Inet4AddressImpl.lookupAllHostAddr(Native Method)
at java.net.InetAddress$1.lookupAllHostAddr(Unknown Source)
at java.net.InetAddress.getAddressFromNameService(Unknown Source)
at java.net.InetAddress.getAllByName0(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getAllByName(Unknown Source)
at java.net.InetAddress.getByName(Unknown Source)
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:202)
at hudson.slaves.SlaveComputer$1.call(SlaveComputer.java:204)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

Even though I have verified that's the correct slave/service name.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Reply | Threaded
Open this post in threaded view
|

[JIRA] (JENKINS-16273) Slaves forbidden to request JNLP anonymously but no clear way to pass API token

JIRA noreply@jenkins-ci.org
In reply to this post by JIRA noreply@jenkins-ci.org

Download the slave-agent.jnlp to the directory where the jenkins-slave.exe is

How are you accomplishing this? When I trigger the URl I do not get any option to do a download and the agent immediately launches.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
12