On 20/02/2013 17:01, Les Mikesell wrote:
On Wed, Feb 20, 2013 at 10:53 AM, Stephen Connolly
<stephen.alan.conno...@gmail.com> wrote:
On 20 February 2013 16:43, Les Mikesell <lesmikes...@gmail.com> wrote:
On Wed, Feb 20, 2013 at 10:26 AM, Fisher, Allen <afis...@makemusic.com>
wrote:
... snip ...
And, as this thread points out - we need a usable workaround for
win2008R2 slaves. I'm fine with installing some flavor of ssh if that
would work, but I can't be the first/only one to run into the problem.
Why is it a surprise?
I'm not sure if I'm misunderstanding your situation but as far as I
understand the security fix had two parts:
1 - invalidate all existing authentication tokens because they could
have already been compromised. New ones are generated.
2 - stop slaves (or indeed anyone else) downloading the authentication
tokens without being properly authenticated.
The main breakage for jnlp slaves was that they tried to download the
authentication token on each startup. This is no longer allowed so they
need to get the token by another means.
An easy way to do this is to download the token, in slave-agent.jnlp,
(once) for each slave and to save it on the slave. Then the windows
service startup script needs to be changed to reference this rather than
downloading the file each time it starts up.
Note that the security token only changes once and does not need
re-downloading each time you restart/reboot the slave instance.
There are quite a few examples of how to setup the configuration in
https://issues.jenkins-ci.org/browse/JENKINS-16273
I'm using the one that I posted there on 11/Jan and it works fine for my
jnlp slaves.
Regards
Richard
--
You received this message because you are subscribed to the Google Groups "Jenkins
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to jenkinsci-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
