Launching slave agent not working since upgrading from 1.421 to 1.423

[Thomas Fields]

Hi there,

My master node (tfieldsw7) is configured on a Windows7 box and I'm
trying to add a single slave agent (buildpc-x64).

The configuration for slave1 is as follows:

Usage: Utilize this slave as much as possible
Launch Method: Launch slave agents via Java Web Start

On slave1 in a cmd prompt I run:

javaws http://tfieldsw7:8080/computer/buildpc-x64/slave-agent.jnlp

This fails with an "Unable to launch application" dialog containing:

Name: Slave agent for buildpc-x64
Publisher: Jenkins project
From: http://tfieldsw7:8080

In the "Launch File" tab I have:

Launch file tab
<jnlp spec="1.0+" codebase="http://tfieldsw7:8080/computer/buildpc-
x64/"><information><title>Slave Agent for buildpc-x64</
title><vendor>Jenkins project</vendor><homepage href="https://jenkins-
ci.org/"/></information><security><all-permissions/></
security><resources><j2se version="1.5+"/><jar href="http://
tfieldsw7:8080/jnlpJars/remoting.jar"/><property
name="hudson.showWindowsServiceInstallLink" value="true"/></
resources><application-desc main-
class="hudson.remoting.jnlp.Main"><argument>b3eb0c64a047e25724ecfe9644fe025c2095e64cd9136ad490264ae5ef80b454</
argument><argument>buildpc-x64</argument><argument>-url</
argument><argument>http://tfieldsw7:8080/</argument></application-
desc></jnlp>

In the "Execution" tab I have:

com.sun.deploy.net.JARSigningException: Found unsigned entry in
resource: http://tfieldsw7:8080/jnlpJars/remoting.jar
at
com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(SigningInfo.java:
411)
at com.sun.javaws.security.SigningInfo.check(SigningInfo.java:276)
at
com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(LaunchDownload.java:
1741)
at
com.sun.javaws.LaunchDownload.checkSignedResources(LaunchDownload.java:
1508)
at com.sun.javaws.Launcher.prepareResources(Launcher.java:1232)
at com.sun.javaws.Launcher.prepareAllResources(Launcher.java:621)
at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:327)
at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:199)
at com.sun.javaws.Launcher.launch(Launcher.java:116)
at com.sun.javaws.Main.launchApp(Main.java:416)
at com.sun.javaws.Main.continueInSecureThread(Main.java:248)
at com.sun.javaws.Main$1.run(Main.java:110)
at java.lang.Thread.run(Thread.java:662)

If I click on "Log" in the Jenkins->nodes->buildpc-x64 menu I see:

JNLP agent connected from /127.0.0.1
<===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 1.420
This is a Windows slave
<snip>

The thing that worries me here is the version number of Slave.jar.
Shouldn't that be 1.423?

If I downgrade to 1.421 then my slave agent connects quite happily. My
log says:

JNLP agent connected from /192.168.1.139
<===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 1.421
This is a Windows slave
<snip>

There must be a regression failure between 1.421 and 1.423. Can this
be fixed?

Regards,
Tom.

[Cees Bos]

@Kohsuke/@Stephen the remoting.jar is unsigned.

I faced the same issue while testing 1.424 for ticket https://issues.jenkins-ci.org/browse/JENKINS-10424

JNLP slaves are not starting anymore. 

I think the issue is introduced on July 12th with the changes around signing: https://github.com/jenkinsci/remoting/commits/master

Regards,
Cees

[Stephen Connolly]

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen

[Stephen Connolly]

i will investigate today... it should be being signed though... hrm

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen

On 27 Jul 2011 07:19, "Cees Bos" <cbos.ec@gmail.com> wrote:

[Stephen Connolly]

7d45771e81dcc20e06065c2d41d3fbcf5cadd875 fixes this issue. the root cause was e9ee3f02d7075d13f149529694cb63367a796d5b which took out the execution.

We need KK to push a release of the remoting as AFAIK he is the only one with the trusted keystore (though I suspect the trusted keystore is available to all three of the triumvirate)

FYI, 47dcb7e4affcd55527ec78e00eb06b0741cb560b fixes the build when not doing a release, so the release would be best after 47dcb7e4affcd55527ec78e00eb06b0741cb560b rather than from 7d45771e81dcc20e06065c2d41d3fbcf5cadd875

[Cees Bos]

Hi Stephen,

Thanks for solving the issue!

Is is possible to share a local signed remoting.jar so I can test the slaves with that?

Regards,

Cees

[Stephen Connolly]

if you just do a snapshot build of the remoting github repo it should be signed with the debug signatures to let you test

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen

[Cees Bos]

Hi Stephen en Kohsuke,

Thanks. I did not create a ticket for this. So probably there is none.

Regards,
Cees

On Fri, Jul 29, 2011 at 9:11 PM, Kohsuke Kawaguchi <kkawa...@cloudbees.com> wrote:

Just committed a fix toward 1.424.

Is there any ticket for this? I looked for it but didn't find any.

On 07/27/2011 05:38 AM, Stephen Connolly wrote:

if you just do a snapshot build of the remoting github repo it should be signed
with the debug signatures to let you test

- Stephen

---
Sent from my Android phone, so random spelling mistakes, random nonsense words
and other nonsense are a direct result of using swype to type on the screen

On 27 Jul 2011 12:06, "Cees Bos"<cbos.ec<http://cbos.ec>@gmail.com
<http://gmail.com>>  wrote:

 >  Hi Stephen,
 >
 >  Thanks for solving the issue!
 >
 >  Is is possible to share a local signed remoting.jar so I can test the slaves
 >  with that?
 >
 >  Regards,
 >  Cees
 >
 >  On Wed, Jul 27, 2011 at 12:14 PM, Stephen Connolly<

 >  stephen.alan.connolly@gmail.com<mailto:stephen.alan.conn...@gmail.com>>  wrote:

 >
 >>  7d45771e81dcc20e06065c2d41d3fbcf5cadd875 fixes this issue. the root cause
 >>  was e9ee3f02d7075d13f149529694cb63367a796d5b which took out the execution.
 >>
 >>  We need KK to push a release of the remoting as AFAIK he is the only one
 >>  with the trusted keystore (though I suspect the trusted keystore is
 >>  available to all three of the triumvirate)
 >>
 >>  FYI, 47dcb7e4affcd55527ec78e00eb06b0741cb560b fixes the build when not
 >>  doing a release, so the release would be best
 >>  after 47dcb7e4affcd55527ec78e00eb06b0741cb560b rather than
 >>  from 7d45771e81dcc20e06065c2d41d3fbcf5cadd875
 >>
 >>

 >>  On 27 July 2011 07:32, Stephen Connolly<stephen.alan.conn...@gmail.com

<mailto:stephen.alan.connolly@gmail.com>>wrote:

 >>
 >>>  i will investigate today... it should be being signed though... hrm
 >>>
 >>>  - Stephen
 >>>
 >>>  ---
 >>>  Sent from my Android phone, so random spelling mistakes, random nonsense
 >>>  words and other nonsense are a direct result of using swype to type on the
 >>>  screen

 >>>  On 27 Jul 2011 07:19, "Cees Bos"<cbos.ec<http://cbos.ec>@gmail.com
<http://gmail.com>>  wrote:

 >>>  >  @Kohsuke/@Stephen the remoting.jar is unsigned.
 >>>  >
 >>>  >  I faced the same issue while testing 1.424 for ticket
 >>>  >  https://issues.jenkins-ci.org/browse/JENKINS-10424
 >>>  >  JNLP slaves are not starting anymore.
 >>>  >
 >>>  >  I think the issue is introduced on July 12th with the changes around
 >>>  >  signing: https://github.com/jenkinsci/remoting/commits/master
 >>>  >
 >>>  >  Regards,
 >>>  >  Cees
 >>>  >
 >>>  >  On Tue, Jul 26, 2011 at 6:32 PM, Thomas Fields<thomas...@gmail.com

<mailto:thomasmfields@gmail.com>

 >>>  >wrote:
 >>>  >
 >>>  >>  Hi there,
 >>>  >>
 >>>  >>  My master node (tfieldsw7) is configured on a Windows7 box and I'm
 >>>  >>  trying to add a single slave agent (buildpc-x64).
 >>>  >>
 >>>  >>  The configuration for slave1 is as follows:
 >>>  >>
 >>>  >>  Usage: Utilize this slave as much as possible
 >>>  >>  Launch Method: Launch slave agents via Java Web Start
 >>>  >>
 >>>  >>  On slave1 in a cmd prompt I run:
 >>>  >>
 >>>  >>  javaws http://tfieldsw7:8080/computer/buildpc-x64/slave-agent.jnlp
 >>>  >>
 >>>  >>  This fails with an "Unable to launch application" dialog containing:
 >>>  >>
 >>>  >>  Name: Slave agent for buildpc-x64
 >>>  >>  Publisher: Jenkins project
 >>>  >>  From: http://tfieldsw7:8080
 >>>  >>
 >>>  >>  In the "Launch File" tab I have:
 >>>  >>
 >>>  >>  Launch file tab
 >>>  >>  <jnlp spec="1.0+" codebase="http://tfieldsw7:8080/computer/buildpc-
 >>>  >>  x64/"><information><title>Slave Agent for buildpc-x64</
 >>>  >>  title><vendor>Jenkins project</vendor><homepage href="https://jenkins-

 >>>  >>  ci.org/<http://ci.org/>"/></information><security><all-permissions/></

 >>>  >>  JNLP agent connected from /127.0.0.1<http://127.0.0.1>

 >>>  >>  <===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 1.420
 >>>  >>  This is a Windows slave
 >>>  >>  <snip>
 >>>  >>
 >>>  >>  The thing that worries me here is the version number of Slave.jar.
 >>>  >>  Shouldn't that be 1.423?
 >>>  >>
 >>>  >>  If I downgrade to 1.421 then my slave agent connects quite happily. My
 >>>  >>  log says:
 >>>  >>

 >>>  >>  JNLP agent connected from /192.168.1.139<http://192.168.1.139>

 >>>  >>  <===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 1.421
 >>>  >>  This is a Windows slave
 >>>  >>  <snip>
 >>>  >>
 >>>  >>  There must be a regression failure between 1.421 and 1.423. Can this
 >>>  >>  be fixed?
 >>>  >>
 >>>  >>  Regards,
 >>>  >>  Tom.
 >>>
 >>
 >>

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/

[Thomas Fields]

I don't think there is a ticket for this. I certainly didn't open one.

Thank,
Tom.

On Jul 30, 2:14 pm, Cees Bos <cbos...@gmail.com> wrote:
> Hi Stephen en Kohsuke,
>
> Thanks. I did not create a ticket for this. So probably there is none.
>
> Regards,
> Cees
>

> On Fri, Jul 29, 2011 at 9:11 PM, Kohsuke Kawaguchi <kkawagu...@cloudbees.com

>
>
>
> > wrote:
>
> > Just committed a fix toward 1.424.
>
> > Is there any ticket for this? I looked for it but didn't find any.
>
> > On 07/27/2011 05:38 AM, Stephen Connolly wrote:
>
> >> if you just do a snapshot build of the remoting github repo it should be
> >> signed
> >> with the debug signatures to let you test
>
> >> - Stephen
>
> >> ---
> >> Sent from my Android phone, so random spelling mistakes, random nonsense
> >> words
> >> and other nonsense are a direct result of using swype to type on the
> >> screen
>

> >> On 27 Jul 2011 12:06, "Cees Bos"<cbos.ec<http://cbos.ec>@g**mail.com<http://gmail.com>

> >> <http://gmail.com>>  wrote:
>
> >>  >  Hi Stephen,
>
> >>  >  Thanks for solving the issue!
>
> >>  >  Is is possible to share a local signed remoting.jar so I can test the
> >> slaves
> >>  >  with that?
>
> >>  >  Regards,
> >>  >  Cees
>
> >>  >  On Wed, Jul 27, 2011 at 12:14 PM, Stephen Connolly<

> >>  >  stephen.alan.connolly@gmail.**com <stephen.alan.conno...@gmail.com>
> >> <mailto:stephen.alan.**conno...@gmail.com<stephen.alan.conno...@gmail.com>>>
> >>  wrote:
>
> >>  >>  7d45771e81dcc20e06065c2d41d3fb**cf5cadd875 fixes this issue. the
> >> root cause
> >>  >>  was e9ee3f02d7075d13f149529694cb63**367a796d5b which took out the

> >> execution.
>
> >>  >>  We need KK to push a release of the remoting as AFAIK he is the only
> >> one
> >>  >>  with the trusted keystore (though I suspect the trusted keystore is
> >>  >>  available to all three of the triumvirate)
>

> >>  >>  FYI, 47dcb7e4affcd55527ec78e00eb06b**0741cb560b fixes the build when

> >> not
> >>  >>  doing a release, so the release would be best

> >>  >>  after 47dcb7e4affcd55527ec78e00eb06b**0741cb560b rather than
> >>  >>  from 7d45771e81dcc20e06065c2d41d3fb**cf5cadd875
>
> >>  >>  On 27 July 2011 07:32, Stephen Connolly<stephen.alan.**
> >> conno...@gmail.com <stephen.alan.conno...@gmail.com>
> >> <mailto:stephen.alan.connolly@**gmail.com<stephen.alan.conno...@gmail.com>

> >> >>wrote:
>
> >>  >>>  i will investigate today... it should be being signed though... hrm
>
> >>  >>>  - Stephen
>
> >>  >>>  ---
> >>  >>>  Sent from my Android phone, so random spelling mistakes, random
> >> nonsense
> >>  >>>  words and other nonsense are a direct result of using swype to type
> >> on the
> >>  >>>  screen

> >>  >>>  On 27 Jul 2011 07:19, "Cees Bos"<cbos.ec<http://cbos.ec>@g**
> >> mail.com <http://gmail.com>

> >> <http://gmail.com>>  wrote:
>
> >>  >>>  >  @Kohsuke/@Stephen the remoting.jar is unsigned.
>
> >>  >>>  >  I faced the same issue while testing 1.424 for ticket

> >>  >>>  >  https://issues.jenkins-ci.org/**browse/JENKINS-10424<https://issues.jenkins-ci.org/browse/JENKINS-10424>

> >>  >>>  >  JNLP slaves are not starting anymore.
>
> >>  >>>  >  I think the issue is introduced on July 12th with the changes
> >> around

> >>  >>>  >  signing:https://github.com/jenkinsci/**remoting/commits/master<https://github.com/jenkinsci/remoting/commits/master>

>
> >>  >>>  >  Regards,
> >>  >>>  >  Cees
>
> >>  >>>  >  On Tue, Jul 26, 2011 at 6:32 PM, Thomas Fields<

> >> thomasmfie...@gmail.com
> >> <mailto:thomasmfields@gmail.**com <thomasmfie...@gmail.com>>

>
> >>  >>>  >wrote:
>
> >>  >>>  >>  Hi there,
>
> >>  >>>  >>  My master node (tfieldsw7) is configured on a Windows7 box and
> >> I'm
> >>  >>>  >>  trying to add a single slave agent (buildpc-x64).
>
> >>  >>>  >>  The configuration for slave1 is as follows:
>
> >>  >>>  >>  Usage: Utilize this slave as much as possible
> >>  >>>  >>  Launch Method: Launch slave agents via Java Web Start
>
> >>  >>>  >>  On slave1 in a cmd prompt I run:
>

> >>  >>>  >>  javawshttp://tfieldsw7:8080/**computer/buildpc-x64/slave-**
> >> agent.jnlp <http://tfieldsw7:8080/computer/buildpc-x64/slave-agent.jnlp>

>
> >>  >>>  >>  This fails with an "Unable to launch application" dialog
> >> containing:
>
> >>  >>>  >>  Name: Slave agent for buildpc-x64
> >>  >>>  >>  Publisher: Jenkins project
> >>  >>>  >>  From:http://tfieldsw7:8080
>
> >>  >>>  >>  In the "Launch File" tab I have:
>
> >>  >>>  >>  Launch file tab

> >>  >>>  >>  <jnlp spec="1.0+" codebase="http://tfieldsw7:**
> >> 8080/computer/buildpc- <http://tfieldsw7:8080/computer/buildpc->
> >>  >>>  >>  x64/"><information><title>**Slave Agent for buildpc-x64</

> >>  >>>  >>  title><vendor>Jenkins project</vendor><homepage href="
> >>https://jenkins-

> >>  >>>  >>  ci.org/<http://ci.org/>"/></**information><security><all-**

> >> permissions/></
>
> >>  >>>  >>  security><resources><j2se version="1.5+"/><jar href="http://

> >>  >>>  >>  tfieldsw7:8080/jnlpJars/**remoting.jar"/><property
> >>  >>>  >>  name="hudson.**showWindowsServiceInstallLink" value="true"/></
> >>  >>>  >>  resources><application-desc main-
>
> >> class="hudson.remoting.jnlp.**Main"><argument>**
> >> b3eb0c64a047e25724ecfe9644fe02**5c2095e64cd9136ad490264ae5ef80**b454</
> >>  >>>  >>  argument><argument>buildpc-**x64</argument><argument>-url</
> >>  >>>  >>  argument><argument>http://**tfieldsw7:8080/<http://tfieldsw7:8080/>
> >> </argument></**application-

> >>  >>>  >>  desc></jnlp>
>
> >>  >>>  >>  In the "Execution" tab I have:
>

> >>  >>>  >>  com.sun.deploy.net.**JARSigningException: Found unsigned entry
> >> in
> >>  >>>  >>  resource:http://tfieldsw7:8080/**jnlpJars/remoting.jar<http://tfieldsw7:8080/jnlpJars/remoting.jar>
> >>  >>>  >>  at
>
> >> com.sun.javaws.security.**SigningInfo.**getCommonCodeSignersForJar(**
> >> SigningInfo.java:
> >>  >>>  >>  411)
> >>  >>>  >>  at com.sun.javaws.security.**SigningInfo.check(SigningInfo.**
> >> java:276)
> >>  >>>  >>  at
>
> >>  >>>  com.sun.javaws.LaunchDownload.**checkSignedResourcesHelper(**
> >> LaunchDownload.java:
> >>  >>>  >>  1741)
> >>  >>>  >>  at
> >>  >>>  >>  com.sun.javaws.LaunchDownload.**checkSignedResources(**
> >> LaunchDownload.java:
> >>  >>>  >>  1508)
> >>  >>>  >>  at com.sun.javaws.Launcher.**prepareResources(Launcher.**
> >> java:1232)
> >>  >>>  >>  at com.sun.javaws.Launcher.**prepareAllResources(Launcher.**
> >> java:621)
> >>  >>>  >>  at com.sun.javaws.Launcher.**prepareToLaunch(Launcher.java:**
> >> 327)
> >>  >>>  >>  at com.sun.javaws.Launcher.**prepareToLaunch(Launcher.java:**
> >> 199)
> >>  >>>  >>  at com.sun.javaws.Launcher.**launch(Launcher.java:116)
> >>  >>>  >>  at com.sun.javaws.Main.launchApp(**Main.java:416)
> >>  >>>  >>  at com.sun.javaws.Main.**continueInSecureThread(Main.**
> >> java:248)
> >>  >>>  >>  at com.sun.javaws.Main$1.run(**Main.java:110)
> >>  >>>  >>  at java.lang.Thread.run(Thread.**java:662)

>
> >>  >>>  >>  If I click on "Log" in the Jenkins->nodes->buildpc-x64 menu I
> >> see:
>
> >>  >>>  >>  JNLP agent connected from /127.0.0.1<http://127.0.0.1>
>
> >>  >>>  >>  <===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 1.420
> >>  >>>  >>  This is a Windows slave
> >>  >>>  >>  <snip>
>
> >>  >>>  >>  The thing that worries me here is the version number of
> >> Slave.jar.
> >>  >>>  >>  Shouldn't that be 1.423?
>
> >>  >>>  >>  If I downgrade to 1.421 then my slave agent connects quite
> >> happily. My
> >>  >>>  >>  log says:
>

> >>  >>>  >>  JNLP agent connected from /192.168.1.139<http://192.168.**1.139<http://192.168.1.139>

>
> >>  >>>  >>  <===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 1.421
> >>  >>>  >>  This is a Windows slave
> >>  >>>  >>  <snip>
>
> >>  >>>  >>  There must be a regression failure between 1.421 and 1.423. Can
> >> this
> >>  >>>  >>  be fixed?
>
> >>  >>>  >>  Regards,
> >>  >>>  >>  Tom.
>
> > --

> > Kohsuke Kawaguchi | CloudBees, Inc. |http://cloudbees.com/- Hide quoted text -
>
> - Show quoted text -

[Thomas Fields]

Seems to be fixed in Jenkins version 1.424. Thanks.

> > > Kohsuke Kawaguchi | CloudBees, Inc. |http://cloudbees.com/-Hide quoted text -