JNLP slave no longer works

[Jon Schewe]

I just upgraded to 1.480.2 from 1.471 and my JNLP slaves can no longer connect. I get an error:

JNLPException[category: Download Error : Exception: java.io.IOException: Server returned HTTP response code: 403 for URL: https://server:8010/computer/slave-jnlp/slave-agent.jnlp : LaunchDesc: null ]
    at com.sun.javaws.Main.launchApp(Unknown Source)
    at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
    at com.sun.javaws.Main$1.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

I have security turned on, although anonymous has overall read. What other permissions do I need to change? What are my options?

--

http://mtu.net/~jpschewe

[Kohsuke Kawaguchi]

This is unfortunately a necessary measure.

See the "Fix" section in https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04

2013/1/7 Jon Schewe <jpsc...@mtu.net>

--
Kohsuke Kawaguchi

[Jon Schewe]

OK, so if I just keep the jnlp local now instead of always requesting it on startup, thing will continue to work, correct?

--
On my mobile device - please excuse typos

[stuart...@doccentrics.com]

Thanks for the info, but how is this change applied to a linux slave?

On Tuesday, 8 January 2013 02:50:39 UTC, Kohsuke Kawaguchi wrote:

This is unfortunately a necessary measure.

See the "Fix" section in https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04

--
Kohsuke Kawaguchi

[Matthew...@diamond.ac.uk]

From a message I sent to the list a few days ago, which worked for at least some people:

 

>>> 

I was in a slightly different situation (linux, slaves launched manually), but had the 403 as well. Fixed by going to Manage Jenkins ->  Configure Global Security, and under  Project-based Matrix Authorization Strategy I had to enable “connect” in the “slave” section, for user “Anonymous”.

<<< 

 

I’m not sure if that address your problem, of what the security implications are, but anyhow …

 

Matthew Webber

[stuart...@doccentrics.com]

Thanks Matthew, I'm a complete newbie with jenkins, I only started at this workplace a week ago and this update landed!  Going through my log I certainly had the 403 errors and ticked various anonymous access rights to get it to connect again.  I've just got it working after I noticed that it had moved onto a 401 error which prompted me to get the jnlp credentials(which look much like an api key) for our jenkins linux slave user account, I reapplied it as the password in the jenkins master and its now connecting, even with all the anonymous privileges revoked. 

Cheers.

Stuart Green

[Richard Mortimer]

Hi,

I managed to fix this fairly simply on my windows slaves (tested on XP,
Vista & Win 7). The fix should be similar for Linux slaves but I use a
home-cooked script to start those so you'll have to adapt the solution
as appropriate.

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
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
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.

Richard

P.S. I just added this to
https://issues.jenkins-ci.org/browse/JENKINS-16273
because it seems to be an appropriate solution there.

On 11/01/2013 10:55, Matthew...@Diamond.ac.uk wrote:
> From a message I sent to the list a few days ago, which worked for at
> least some people:
>
>>>>
>
> I was in a slightly different situation (linux, slaves launched
> manually), but had the 403 as well. Fixed by going to Manage Jenkins ->
> Configure Global Security, and under Project-based Matrix
> Authorization Strategy I had to enable “connect” in the “slave” section,
> for user “Anonymous”.
>
> <<<
>
> I’m not sure if that address your problem, of what the security
> implications are, but anyhow …
>
> Matthew Webber
>

> *From:*jenkins...@googlegroups.com
> [mailto:jenkins...@googlegroups.com] *On Behalf Of
> *stuart...@doccentrics.com
> *Sent:* 11 January 2013 10:39
> *To:* jenkins...@googlegroups.com
> *Subject:* Re: JNLP slave no longer works

[SBreitbach]

The slave.jar from LTS 1.480.2 version has parameters "-auth" and "-jnlpCredentials". Neither of them seems to work, I will get a "Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64" or "java.io.IOException: Failed to load http://bsjenkinsslave03.server.lan:8280/jenkins/computer/bsjenkinsslave03/slave-agent.jnlp: 403 Forbidden", depending on what combination of parameters I use.

I consider the "manually download the jnlp file" as a very dirty quickhack... will we see a proper launching of the slaves again soon?

[Brian J. Murrell]

On 13-01-11 07:58 AM, SBreitbach wrote:
> The slave.jar from LTS 1.480.2 version has parameters "-auth" and
> "-jnlpCredentials".

I discovered that the -auth in 1.498 also doesn't work. I grabbed the
packets that the slave was sending to the jenkins server on connect and
there is absolutely no authentication credentials in them, even with
-auth account:password being set.

> I consider the "manually download the jnlp file" as a very dirty
> quickhack...

+1

b.

[Brian J. Murrell]

On 13-01-11 05:55 AM,

Matthew...@Diamond.ac.uk wrote:
>
> Fixed by going to Manage Jenkins -> Configure Global Security, and under Project-based Matrix Authorization Strategy I had to enable “connect” in the “slave” section, for user “Anonymous”.

IIUC, that's going to leave your Jenkins server open to allowing any
random (i.e. blackhat) slave to connect, accept a build job and submit a
build result with a trojan inserted.

So not really an acceptable solution, or even work-around.

b.

[Les Mikesell]

On Fri, Jan 11, 2013 at 7:12 AM, Brian J. Murrell <br...@interlinx.bc.ca> wrote:
>>
>> Fixed by going to Manage Jenkins -> Configure Global Security, and under Project-based Matrix Authorization Strategy I had to enable “connect” in the “slave” section, for user “Anonymous”.
>
> IIUC, that's going to leave your Jenkins server open to allowing any
> random (i.e. blackhat) slave to connect, accept a build job and submit a
> build result with a trojan inserted.
>
> So not really an acceptable solution, or even work-around.

Doesn't the connecting node name already have to be configured in
jenkins - and not already connected? I'd actually like the ability
to add new anonymous-but-labeled nodes on demand but didn't think it
was possible.

--
Les Mikesell
lesmi...@gmail.com

[Brian J. Murrell]

On 13-01-11 08:44 AM, Les Mikesell wrote:
>
> Doesn't the connecting node name already have to be configured in
> jenkins

Sure. But if anonymous read is allowed, anyone can see the node names.

> - and not already connected?

Is disconnecting a node really that difficult? You could try attacking
a vulnerability or even simply DDoS it. Or even just wait for some
network/node flap and jump in while it's not connected.

b.

[Kohsuke Kawaguchi]

Yes, you just need to re-download the JNLP file from the master and overwrite the local copy at the slave.

2013/1/7 Jon Schewe <jpsc...@mtu.net>

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

Slaves installed as a service stores the secret token information in the startup configuration file, such as /etc/init/jenkins-slave-*.conf (Linux), /System/Library/LaunchDaemons/org.jenkins-ci.slave.*.plist (OS X), or $SLAVE_ROOT/jenkins-slave.xml (Windows). Look for seemingly meaningless hex-encoded token in this file (which is passed as an argument to the the Java program).

Now download the JNLP file again for that slave from Jenkins Web UI, then look for a similar seemingly meaningless hex-encoded token in that file. Overwrite the local version with what's now in JNLP, and it'd be good to go.

If you aren't sure, you can also simply re-install the slave agent again. Existing slave agent will do no harm since it will not be able to connect back. 

2013/1/11 <stuart...@doccentrics.com>

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

Agree with Brian here. Only do it when you are trusting the users of the network.

2013/1/11 Brian J. Murrell <br...@interlinx.bc.ca>

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

If you want to be able to add slaves without configuring them first on the master, you can use the swarm slave plugin.

2013/1/11 Les Mikesell <lesmi...@gmail.com>

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

If your command line is something like "java -jar slave.jar -jnlpUrl http://host/path/to/jnlp", then the right thing to do is to use the -jnlpCredentials option. But as SBreitBach discovered, due to a missing dependency problem it turns out this doesn't work (Ugh!). This is being fixed now.

In the mean time, what I recommend is to manually download the JNLP file from your browser, then have -jnlpUrl point to the local copy via file:///path/to/local.jnlp 

I'm not really sure what the -auth option does, even though I added it :-(

2013/1/11 <Matthew...@diamond.ac.uk>

--
Kohsuke Kawaguchi

[Matthew...@diamond.ac.uk]

But what about when the slave is not installed as a service? I use headless jnlp (https://wiki.jenkins-ci.org/display/JENKINS/Distributed+builds#Distributedbuilds-Launchslaveagentheadlessly) in a script that makes sure slave.jar is up to date.

 

It looks like should be able to authenticate with -auth  or –jnlpCredentials, but neither seems to work  - ideally, I’d like to use my API token rather than my password …

 

Is this supposed to work, or is this a request for a new feature?

 

From: jenkins...@googlegroups.com [mailto:jenkins...@googlegroups.com] On Behalf Of Kohsuke Kawaguchi
Sent: 11 January 2013 14:16
To: jenkins...@googlegroups.com
Subject: Re: JNLP slave no longer works

 

Slaves installed as a service stores the secret token information in the startup configuration file, such as /etc/init/jenkins-slave-*.conf (Linux), /System/Library/LaunchDaemons/org.jenkins-ci.slave.*.plist (OS X), or $SLAVE_ROOT/jenkins-slave.xml (Windows). Look for seemingly meaningless hex-encoded token in this file (which is passed as an argument to the the Java program).

 

-- 

This e-mail and any attachments may contain confidential, copyright and or privileged material, and are for the use of the intended addressee only. If you are not the intended addressee or an authorised recipient of the addressee please notify us of receipt by returning the e-mail and do not use, copy, retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not necessarily of Diamond Light Source Ltd.
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments are free from viruses and we cannot accept liability for any damage which you may sustain as a result of software viruses which may be transmitted in or with the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and Wales with its registered office at Diamond House, Harwell Science and Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom
 

[Kohsuke Kawaguchi]

2013/1/11 SBreitbach <steffen....@1und1.de>

The slave.jar from LTS 1.480.2 version has parameters "-auth" and "-jnlpCredentials". Neither of them seems to work, I will get a "Exception in thread "main" java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64" or "java.io.IOException: Failed to load http://bsjenkinsslave03.server.lan:8280/jenkins/computer/bsjenkinsslave03/slave-agent.jnlp: 403 Forbidden", depending on what combination of parameters I use.

I consider the "manually download the jnlp file" as a very dirty quickhack... will we see a proper launching of the slaves again soon?

It's no less secure than using the -jnlpCredentials, and JNLP files do not change as you change the slave configuration, so in my mind it is pretty practical workaround, although it does require some extra step.

We'll fix this in the next mainline release, and once all the fallout bugs like this are fixed and verified, I'll plan on another LTS release.

My apologies for the problems in the mean time.

--
Kohsuke Kawaguchi

[Steffen Breitbach]

We'll fix this in the next mainline release, and once all the fallout bugs like this are fixed and verified, I'll plan on another LTS release.

 

My apologies for the problems in the mean time.

No problem! The workaround using the anonymous user is OK for me in the meantime. :)

[Chris Withers]

Hi All,

Just as a headsup, the instructions at the following URL no longer work
when it comes to getting a Windows slave working as a service:

https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+as+a+Windows+service

On 11/01/2013 14:26, Kohsuke Kawaguchi wrote:
> In the mean time, what I recommend is to manually download the JNLP file
> from your browser, then have -jnlpUrl point to the local copy via
> file:///path/to/local.jnlp

Working from the above, here's a recipe:

1 - stop the service, it'll be complaining in jenkins-slave.err.log
something like the following:

Failing to obtain http://<server>/computer/<node>/slave-agent.jnlp
java.io.IOException: Failed to load
http://<server>/computer/<node>/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)
Waiting 10 seconds before retry

2 - make a note of the folder listed in the "Remote FS root" in
http://<server>/computer/<node>/configure. In my case, it was C:\Jenkins

3 - using a web browser on the windows box, log in to your jenkins
server and go to http://<server>/computer/<node>/, right click on the
"Launch" icon and "save as" the slave-agent.jnlp to the folder from (2)
above.

4 - in the folder in (2) above, you will find a file called
jenkins-slave.xml, edit the -jnlpUrl argument in the <arguments> element
and replace "http://<server>/computer/<node>/slave-agent.jnlp" with the
path to the file you saved in (3) above. In my case, this was
"file:///C:/Jenkins/slave-agent.jnlp".

5 - You should now be good to start the service up again. This time the
node should show up as connected on your Jenkins master and the
jenkins-slave.err.log on the slave should end in something like:

Jan 19, 2013 5:06:35 PM hudson.remoting.jnlp.Main$CuiListener status
INFO: Connected

I hope a future release will fix the installation of the
slave-as-service so these manual steps aren't needed. To whoever does
that work, firstly, thankyou in advance :-) While you're at it, could
you consider setting the slave service to run as a user other that
System? (which is a bit like running as root, if I understand Windows
correctly)

I manually set up a "normal" Jenkins user and changed the Jenkins
service to run as that user...

cheers,

Chris

--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk