Re: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Chanda Unmack]

Thank you Just by checking that box magically all my windows slaves
came online. I'm not sure about the security ramifications, but for now it
gets me where I need to be.

Thanks again!

chanda


On Wed, Jan 9, 2013 at 1:59 PM,  wrote:

>  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”.
>
> Matthew Webber
>
> ** **
>
> *From:* jenkinsci-users@googlegroups.com [mailto:
> jenkinsci-users@googlegroups.com] *On Behalf Of *Chanda Unmack
> *Sent:* 09 January 2013 19:18
> *To:* jenkinsci-users@googlegroups.com
> *Subject:* Re: Null pointer exceptions after upgrade from 1.480.1 to
> 1.480.2
>
> ** **
>
> Spoke too soon apparently - as soon as I logged out of the slave, the
> connection was broken, so back to where I was before.
>
> Any other ideas? I'm going to keep looking in case there is a jnlp hiding
> somewhere else on the system.
>
> ** **
>
> chanda
>
> ** **
>
> On Wed, Jan 9, 2013 at 11:04 AM, Chanda Unmack  wrote:**
> **
>
> Thanks for the pointer - sometimes it takes an external pair of eyes to
> see something so obvious :) I did read that advisory, and I thought I was
> deleting everything and or it was overwriting the *.jnlp. Unfortunately it
> looks as if it was merely adding copies, and not overwriting - found
> slave-agent[1].jnlp, slave-agent[2].jnlp sigh. In case anyone else runs
> into this, in my environment I found them in temporary internet files for
> the user launching the service.
>
> After removing all the slave-agent*.jnlp, deleting the service and copying
> the jar files over again, all is working as it was before the upgrade.
>
> ** **
>
> thanks again for the help! 
>
> ** **
>
> chanda
>
> ** **
>
> On Tue, Jan 8, 2013 at 1:15 PM, Mark Waite  wrote:***
> *
>
> I think that message means that the technique which is launching the
> slaves as a windows service from the GUI is using JNLP.
>
> The security advisory page on the wiki [1] says "Slaves that are started
> via Java Web Start will fail to reconnect if the *.jnlp file is locally
> stored. This is because the authentication tokens change. *An
> administrator would have to login to the UI, retrieve the *.jnlp file and
> overwrite what's already on the slave*. A slave that was launched via
> Java Web Start and then turned into a service through its menu falls into
> this category." (emphasis added).
>
> I think that means you'll need to find some way to remove the JNLP file
> from your Windows machine where the service placed it, then download the
> JNLP again.  Unfortunately, I don't know how to remove the JNLP from
> Windows when running as a service.  Possibly, you could search for all JNLP
> files?
>
> Mark Waite
>
> [1]
> https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04
> 
>
>
>
> On Monday, January 7, 2013 3:32:13 PM UTC-7, Chanda Unmack wrote:
>
>  I have the same issue after upgrading from 1.480.1 to 1.480.2 on Ubuntu
> 12.04. I am able to launch the windows slaves manually, but unable to have
> them run as a windows service from the gui. I am able to install it as a
> service from the command line, but the master never connects to the slave.
>  The only hint I have is if I try to run the command for a headless slave,
> then I get 
>
> ** **
>
> java.io.IOException: Failed to load
> http://jenkins/computer/server-bld-pc1/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)
>
> ** **
>
> I'm obviously missing something here so any pointers greatly appreciated.
> I have removed all the jar, exe and xml files from the slaves several
> times, completely deleted the service from the slave, but no change in the
> behavior. 
>
> ** **
>
> thanks,
>
> chanda
>
> ** **
>
> ** **
>
> On Mon, Jan 7, 2013 at 11:17 AM, Richard Mortimer 
> wrote:
>
> Hi Mark,
>
>
>
> On 07/01/2013 18:21, Mark Waite wrote:
>
> I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using the
> Debian package manager.  The machine was running with authentication
> enabled and was using Debian, CentOS, Red Hat, and Windows slave agents.
>   The Linux slave

RE: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Matthew.Webber]

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”.
Matthew Webber

From: jenkinsci-users@googlegroups.com 
[mailto:jenkinsci-users@googlegroups.com] On Behalf Of Chanda Unmack
Sent: 09 January 2013 19:18
To: jenkinsci-users@googlegroups.com
Subject: Re: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

Spoke too soon apparently - as soon as I logged out of the slave, the 
connection was broken, so back to where I was before.
Any other ideas? I'm going to keep looking in case there is a jnlp hiding 
somewhere else on the system.

chanda

On Wed, Jan 9, 2013 at 11:04 AM, Chanda Unmack 
mailto:cha...@lytro.com>> wrote:
Thanks for the pointer - sometimes it takes an external pair of eyes to see 
something so obvious :) I did read that advisory, and I thought I was deleting 
everything and or it was overwriting the *.jnlp. Unfortunately it looks as if 
it was merely adding copies, and not overwriting - found slave-agent[1].jnlp, 
slave-agent[2].jnlp sigh. In case anyone else runs into this, in my 
environment I found them in temporary internet files for the user launching the 
service.
After removing all the slave-agent*.jnlp, deleting the service and copying the 
jar files over again, all is working as it was before the upgrade.

thanks again for the help!

chanda

On Tue, Jan 8, 2013 at 1:15 PM, Mark Waite 
mailto:markwa...@yahoo.com>> wrote:
I think that message means that the technique which is launching the slaves as 
a windows service from the GUI is using JNLP.

The security advisory page on the wiki [1] says "Slaves that are started via 
Java Web Start will fail to reconnect if the *.jnlp file is locally stored. 
This is because the authentication tokens change. An administrator would have 
to login to the UI, retrieve the *.jnlp file and overwrite what's already on 
the slave. A slave that was launched via Java Web Start and then turned into a 
service through its menu falls into this category." (emphasis added).

I think that means you'll need to find some way to remove the JNLP file from 
your Windows machine where the service placed it, then download the JNLP again. 
 Unfortunately, I don't know how to remove the JNLP from Windows when running 
as a service.  Possibly, you could search for all JNLP files?

Mark Waite

[1] 
https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04


On Monday, January 7, 2013 3:32:13 PM UTC-7, Chanda Unmack wrote:
I have the same issue after upgrading from 1.480.1 to 1.480.2 on Ubuntu 12.04. 
I am able to launch the windows slaves manually, but unable to have them run as 
a windows service from the gui. I am able to install it as a service from the 
command line, but the master never connects to the slave.  The only hint I have 
is if I try to run the command for a headless slave, then I get

java.io.IOException: Failed to load 
http://jenkins/computer/server-bld-pc1/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)

I'm obviously missing something here so any pointers greatly appreciated. I 
have removed all the jar, exe and xml files from the slaves several times, 
completely deleted the service from the slave, but no change in the behavior.

thanks,
chanda


On Mon, Jan 7, 2013 at 11:17 AM, Richard Mortimer 
mailto:ri...@oldelvet.org.uk>> wrote:
Hi Mark,


On 07/01/2013 18:21, Mark Waite wrote:
I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using the
Debian package manager.  The machine was running with authentication
enabled and was using Debian, CentOS, Red Hat, and Windows slave agents.
  The Linux slave agents are launched with ssh.  The Windows slave
agents are launched with JNLP from a batch file on the Windows machines.

The upgrade seems to have blocked all connections from the Windows
(JNLP) slaves.  I assume that is intentional since I had authentication
enabled and 1.480.2 attempts to disallow unauthenticated slave agent
connections.  I resolved that by disabling authentication on the master
server.
I believe that is a consequence of the changes made in 1.480.2. I haven't 
upgraded my Jenkins instance yet to see this but I read the following advisory 
earlier today and believe the change is related to that.

https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04

Regards

Richard


After the upgrade, I see some "Dead" entries in the list of slaves on
the left side of the Jenkins opening page.  When I click the red "Dead"
entry, it shows the following stack trace:

java

Re: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Chanda Unmack]

Spoke too soon apparently - as soon as I logged out of the slave, the
connection was broken, so back to where I was before.
Any other ideas? I'm going to keep looking in case there is a jnlp hiding
somewhere else on the system.

chanda


On Wed, Jan 9, 2013 at 11:04 AM, Chanda Unmack  wrote:

> Thanks for the pointer - sometimes it takes an external pair of eyes to
> see something so obvious :) I did read that advisory, and I thought I was
> deleting everything and or it was overwriting the *.jnlp. Unfortunately it
> looks as if it was merely adding copies, and not overwriting - found
> slave-agent[1].jnlp, slave-agent[2].jnlp sigh. In case anyone else runs
> into this, in my environment I found them in temporary internet files for
> the user launching the service.
> After removing all the slave-agent*.jnlp, deleting the service and copying
> the jar files over again, all is working as it was before the upgrade.
>
> thanks again for the help!
>
> chanda
>
>
> On Tue, Jan 8, 2013 at 1:15 PM, Mark Waite  wrote:
>
>> I think that message means that the technique which is launching the
>> slaves as a windows service from the GUI is using JNLP.
>>
>> The security advisory page on the wiki [1] says "Slaves that are started
>> via Java Web Start will fail to reconnect if the *.jnlp file is locally
>> stored. This is because the authentication tokens change. *An
>> administrator would have to login to the UI, retrieve the *.jnlp file and
>> overwrite what's already on the slave*. A slave that was launched via
>> Java Web Start and then turned into a service through its menu falls into
>> this category." (emphasis added).
>>
>> I think that means you'll need to find some way to remove the JNLP file
>> from your Windows machine where the service placed it, then download the
>> JNLP again.  Unfortunately, I don't know how to remove the JNLP from
>> Windows when running as a service.  Possibly, you could search for all JNLP
>> files?
>>
>> Mark Waite
>>
>> [1]
>> https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04
>>
>>
>> On Monday, January 7, 2013 3:32:13 PM UTC-7, Chanda Unmack wrote:
>>
>>> I have the same issue after upgrading from 1.480.1 to 1.480.2 on Ubuntu
>>> 12.04. I am able to launch the windows slaves manually, but unable to have
>>> them run as a windows service from the gui. I am able to install it as a
>>> service from the command line, but the master never connects to the slave.
>>>  The only hint I have is if I try to run the command for a headless slave,
>>> then I get
>>>
>>> java.io.IOException: Failed to load http://jenkins/computer/**
>>> server-bld-pc1/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)
>>>
>>> I'm obviously missing something here so any pointers greatly
>>> appreciated. I have removed all the jar, exe and xml files from the slaves
>>> several times, completely deleted the service from the slave, but no change
>>> in the behavior.
>>>
>>> thanks,
>>> chanda
>>>
>>>
>>>
>>> On Mon, Jan 7, 2013 at 11:17 AM, Richard Mortimer >> > wrote:
>>>
 Hi Mark,


 On 07/01/2013 18:21, Mark Waite wrote:

> I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using
> the
> Debian package manager.  The machine was running with authentication
> enabled and was using Debian, CentOS, Red Hat, and Windows slave
> agents.
>   The Linux slave agents are launched with ssh.  The Windows slave
> agents are launched with JNLP from a batch file on the Windows
> machines.
>
> The upgrade seems to have blocked all connections from the Windows
> (JNLP) slaves.  I assume that is intentional since I had authentication
> enabled and 1.480.2 attempts to disallow unauthenticated slave agent
> connections.  I resolved that by disabling authentication on the master
> server.
>
>  I believe that is a consequence of the changes made in 1.480.2. I
 haven't upgraded my Jenkins instance yet to see this but I read the
 following advisory earlier today and believe the change is related to that.

 https://wiki.jenkins-ci.org/**di**splay/SECURITY/Jenkins+**Securit**
 y+Advisory+2013-01-04

 Regards

 Richard



  After the upgrade, I see some "Dead" entries in the list of slaves on
> the left side of the Jenkins opening page.  When I click the red "Dead"
> entry, it shows the following stack trace:
>
> java.lang.NullPointerException
> at hudson.matrix.**MatrixConfigurat**ion.newBuild(**
> MatrixConfigurati**on.java:218)
> at hudson.matrix.**MatrixConfigurat**ion.newB

Re: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Chanda Unmack]

Thanks for the pointer - sometimes it takes an external pair of eyes to see
something so obvious :) I did read that advisory, and I thought I was
deleting everything and or it was overwriting the *.jnlp. Unfortunately it
looks as if it was merely adding copies, and not overwriting - found
slave-agent[1].jnlp, slave-agent[2].jnlp sigh. In case anyone else runs
into this, in my environment I found them in temporary internet files for
the user launching the service.
After removing all the slave-agent*.jnlp, deleting the service and copying
the jar files over again, all is working as it was before the upgrade.

thanks again for the help!

chanda


On Tue, Jan 8, 2013 at 1:15 PM, Mark Waite  wrote:

> I think that message means that the technique which is launching the
> slaves as a windows service from the GUI is using JNLP.
>
> The security advisory page on the wiki [1] says "Slaves that are started
> via Java Web Start will fail to reconnect if the *.jnlp file is locally
> stored. This is because the authentication tokens change. *An
> administrator would have to login to the UI, retrieve the *.jnlp file and
> overwrite what's already on the slave*. A slave that was launched via
> Java Web Start and then turned into a service through its menu falls into
> this category." (emphasis added).
>
> I think that means you'll need to find some way to remove the JNLP file
> from your Windows machine where the service placed it, then download the
> JNLP again.  Unfortunately, I don't know how to remove the JNLP from
> Windows when running as a service.  Possibly, you could search for all JNLP
> files?
>
> Mark Waite
>
> [1]
> https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04
>
>
> On Monday, January 7, 2013 3:32:13 PM UTC-7, Chanda Unmack wrote:
>
>> I have the same issue after upgrading from 1.480.1 to 1.480.2 on Ubuntu
>> 12.04. I am able to launch the windows slaves manually, but unable to have
>> them run as a windows service from the gui. I am able to install it as a
>> service from the command line, but the master never connects to the slave.
>>  The only hint I have is if I try to run the command for a headless slave,
>> then I get
>>
>> java.io.IOException: Failed to load http://jenkins/computer/**
>> server-bld-pc1/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)
>>
>> I'm obviously missing something here so any pointers greatly appreciated.
>> I have removed all the jar, exe and xml files from the slaves several
>> times, completely deleted the service from the slave, but no change in the
>> behavior.
>>
>> thanks,
>> chanda
>>
>>
>>
>> On Mon, Jan 7, 2013 at 11:17 AM, Richard Mortimer 
>> wrote:
>>
>>> Hi Mark,
>>>
>>>
>>> On 07/01/2013 18:21, Mark Waite wrote:
>>>
 I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using the
 Debian package manager.  The machine was running with authentication
 enabled and was using Debian, CentOS, Red Hat, and Windows slave agents.
   The Linux slave agents are launched with ssh.  The Windows slave
 agents are launched with JNLP from a batch file on the Windows machines.

 The upgrade seems to have blocked all connections from the Windows
 (JNLP) slaves.  I assume that is intentional since I had authentication
 enabled and 1.480.2 attempts to disallow unauthenticated slave agent
 connections.  I resolved that by disabling authentication on the master
 server.

  I believe that is a consequence of the changes made in 1.480.2. I
>>> haven't upgraded my Jenkins instance yet to see this but I read the
>>> following advisory earlier today and believe the change is related to that.
>>>
>>> https://wiki.jenkins-ci.org/**di**splay/SECURITY/Jenkins+**Securit**
>>> y+Advisory+2013-01-04
>>>
>>> Regards
>>>
>>> Richard
>>>
>>>
>>>
>>>  After the upgrade, I see some "Dead" entries in the list of slaves on
 the left side of the Jenkins opening page.  When I click the red "Dead"
 entry, it shows the following stack trace:

 java.lang.NullPointerException
 at hudson.matrix.**MatrixConfigurat**ion.newBuild(**
 MatrixConfigurati**on.java:218)
 at hudson.matrix.**MatrixConfigurat**ion.newBuild(**
 MatrixConfigurati**on.java:64)
 at hudson.model.AbstractProject.**c**reateExecutable(**
 AbstractProjec**t.java:1197)
 at hudson.model.AbstractProject.**c**reateExecutable(**
 AbstractProjec**t.java:136)
 at hudson.model.Executor.run(**Exec**utor.java:211)


 Once I click through that "Dead" thread one or two times, the slave
 agent seems to remain running 

Re: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Mark Waite]

I think that message means that the technique which is launching the slaves 
as a windows service from the GUI is using JNLP.

The security advisory page on the wiki [1] says "Slaves that are started 
via Java Web Start will fail to reconnect if the *.jnlp file is locally 
stored. This is because the authentication tokens change. *An administrator 
would have to login to the UI, retrieve the *.jnlp file and overwrite 
what's already on the slave*. A slave that was launched via Java Web Start 
and then turned into a service through its menu falls into this category." 
(emphasis added).

I think that means you'll need to find some way to remove the JNLP file 
from your Windows machine where the service placed it, then download the 
JNLP again.  Unfortunately, I don't know how to remove the JNLP from 
Windows when running as a service.  Possibly, you could search for all JNLP 
files?

Mark Waite

[1] 
https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04

On Monday, January 7, 2013 3:32:13 PM UTC-7, Chanda Unmack wrote:
>
> I have the same issue after upgrading from 1.480.1 to 1.480.2 on Ubuntu 
> 12.04. I am able to launch the windows slaves manually, but unable to have 
> them run as a windows service from the gui. I am able to install it as a 
> service from the command line, but the master never connects to the slave. 
>  The only hint I have is if I try to run the command for a headless slave, 
> then I get 
>
> java.io.IOException: Failed to load 
> http://jenkins/computer/server-bld-pc1/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)
>
> I'm obviously missing something here so any pointers greatly appreciated. 
> I have removed all the jar, exe and xml files from the slaves several 
> times, completely deleted the service from the slave, but no change in the 
> behavior. 
>
> thanks,
> chanda
>
>
>
> On Mon, Jan 7, 2013 at 11:17 AM, Richard Mortimer 
> 
> > wrote:
>
>> Hi Mark,
>>
>>
>> On 07/01/2013 18:21, Mark Waite wrote:
>>
>>> I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using the
>>> Debian package manager.  The machine was running with authentication
>>> enabled and was using Debian, CentOS, Red Hat, and Windows slave agents.
>>>   The Linux slave agents are launched with ssh.  The Windows slave
>>> agents are launched with JNLP from a batch file on the Windows machines.
>>>
>>> The upgrade seems to have blocked all connections from the Windows
>>> (JNLP) slaves.  I assume that is intentional since I had authentication
>>> enabled and 1.480.2 attempts to disallow unauthenticated slave agent
>>> connections.  I resolved that by disabling authentication on the master
>>> server.
>>>
>>>  I believe that is a consequence of the changes made in 1.480.2. I 
>> haven't upgraded my Jenkins instance yet to see this but I read the 
>> following advisory earlier today and believe the change is related to that.
>>
>> https://wiki.jenkins-ci.org/**display/SECURITY/Jenkins+**
>> Security+Advisory+2013-01-04
>>
>> Regards
>>
>> Richard
>>
>>
>>
>>  After the upgrade, I see some "Dead" entries in the list of slaves on
>>> the left side of the Jenkins opening page.  When I click the red "Dead"
>>> entry, it shows the following stack trace:
>>>
>>> java.lang.NullPointerException
>>> at hudson.matrix.**MatrixConfiguration.newBuild(**
>>> MatrixConfiguration.java:218)
>>> at hudson.matrix.**MatrixConfiguration.newBuild(**
>>> MatrixConfiguration.java:64)
>>> at hudson.model.AbstractProject.**createExecutable(**
>>> AbstractProject.java:1197)
>>> at hudson.model.AbstractProject.**createExecutable(**
>>> AbstractProject.java:136)
>>> at hudson.model.Executor.run(**Executor.java:211)
>>>
>>>
>>> Once I click through that "Dead" thread one or two times, the slave
>>> agent seems to remain running without interruption.
>>>
>>> Are those expected results that are part of the transition from 1.480.1
>>> to 1.480.2?
>>>
>>> Thanks,
>>> Mark Waite
>>>
>>
>
>
> -- 
> *Confidentiality Notice*: This e-mail, including all attachments, is 
> confidential information of Lytro, Inc. If the reader of this e-mail is not 
> the intended recipient or its authorized agent, the reader is hereby 
> notified that any dissemination, distribution or copying of this e-mail is 
> prohibited. If you have received this e-mail in error, please notify the 
> sender by replying to this message and delete this e-mail immediately. 
>

Re: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Chanda Unmack]

I have the same issue after upgrading from 1.480.1 to 1.480.2 on Ubuntu
12.04. I am able to launch the windows slaves manually, but unable to have
them run as a windows service from the gui. I am able to install it as a
service from the command line, but the master never connects to the slave.
 The only hint I have is if I try to run the command for a headless slave,
then I get

java.io.IOException: Failed to load
http://jenkins/computer/server-bld-pc1/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)

I'm obviously missing something here so any pointers greatly appreciated. I
have removed all the jar, exe and xml files from the slaves several times,
completely deleted the service from the slave, but no change in the
behavior.

thanks,
chanda



On Mon, Jan 7, 2013 at 11:17 AM, Richard Mortimer wrote:

> Hi Mark,
>
>
> On 07/01/2013 18:21, Mark Waite wrote:
>
>> I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using the
>> Debian package manager.  The machine was running with authentication
>> enabled and was using Debian, CentOS, Red Hat, and Windows slave agents.
>>   The Linux slave agents are launched with ssh.  The Windows slave
>> agents are launched with JNLP from a batch file on the Windows machines.
>>
>> The upgrade seems to have blocked all connections from the Windows
>> (JNLP) slaves.  I assume that is intentional since I had authentication
>> enabled and 1.480.2 attempts to disallow unauthenticated slave agent
>> connections.  I resolved that by disabling authentication on the master
>> server.
>>
>>  I believe that is a consequence of the changes made in 1.480.2. I
> haven't upgraded my Jenkins instance yet to see this but I read the
> following advisory earlier today and believe the change is related to that.
>
> https://wiki.jenkins-ci.org/**display/SECURITY/Jenkins+**
> Security+Advisory+2013-01-04
>
> Regards
>
> Richard
>
>
>
>  After the upgrade, I see some "Dead" entries in the list of slaves on
>> the left side of the Jenkins opening page.  When I click the red "Dead"
>> entry, it shows the following stack trace:
>>
>> java.lang.NullPointerException
>> at hudson.matrix.**MatrixConfiguration.newBuild(**
>> MatrixConfiguration.java:218)
>> at hudson.matrix.**MatrixConfiguration.newBuild(**
>> MatrixConfiguration.java:64)
>> at hudson.model.AbstractProject.**createExecutable(**
>> AbstractProject.java:1197)
>> at hudson.model.AbstractProject.**createExecutable(**
>> AbstractProject.java:136)
>> at hudson.model.Executor.run(**Executor.java:211)
>>
>>
>> Once I click through that "Dead" thread one or two times, the slave
>> agent seems to remain running without interruption.
>>
>> Are those expected results that are part of the transition from 1.480.1
>> to 1.480.2?
>>
>> Thanks,
>> Mark Waite
>>
>


-- 
*Confidentiality Notice*: This e-mail, including all attachments, is
confidential information of Lytro, Inc. If the reader of this e-mail is not
the intended recipient or its authorized agent, the reader is hereby
notified that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.

Re: Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Richard Mortimer]

Hi Mark,

On 07/01/2013 18:21, Mark Waite wrote:

I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using the
Debian package manager.  The machine was running with authentication
enabled and was using Debian, CentOS, Red Hat, and Windows slave agents.
  The Linux slave agents are launched with ssh.  The Windows slave
agents are launched with JNLP from a batch file on the Windows machines.

The upgrade seems to have blocked all connections from the Windows
(JNLP) slaves.  I assume that is intentional since I had authentication
enabled and 1.480.2 attempts to disallow unauthenticated slave agent
connections.  I resolved that by disabling authentication on the master
server.

I believe that is a consequence of the changes made in 1.480.2. I 
haven't upgraded my Jenkins instance yet to see this but I read the 
following advisory earlier today and believe the change is related to that.


https://wiki.jenkins-ci.org/display/SECURITY/Jenkins+Security+Advisory+2013-01-04

Regards

Richard



After the upgrade, I see some "Dead" entries in the list of slaves on
the left side of the Jenkins opening page.  When I click the red "Dead"
entry, it shows the following stack trace:

java.lang.NullPointerException
at 
hudson.matrix.MatrixConfiguration.newBuild(MatrixConfiguration.java:218)
at 
hudson.matrix.MatrixConfiguration.newBuild(MatrixConfiguration.java:64)
at 
hudson.model.AbstractProject.createExecutable(AbstractProject.java:1197)
at 
hudson.model.AbstractProject.createExecutable(AbstractProject.java:136)
at hudson.model.Executor.run(Executor.java:211)


Once I click through that "Dead" thread one or two times, the slave
agent seems to remain running without interruption.

Are those expected results that are part of the transition from 1.480.1
to 1.480.2?

Thanks,
Mark Waite

Null pointer exceptions after upgrade from 1.480.1 to 1.480.2

[Mark Waite]

I upgraded my Debian Jenkins LTS from 1.480.1 to 1.480.2 today using the Debian 
package manager.  The machine was running with authentication enabled and was 
using Debian, CentOS, Red Hat, and Windows slave agents.  The Linux slave 
agents are launched with ssh.  The Windows slave agents are launched with JNLP 
from a batch file on the Windows machines.

The upgrade seems to have blocked all connections from the Windows (JNLP) 
slaves.  I assume that is intentional since I had authentication enabled and 
1.480.2 attempts to disallow unauthenticated slave agent connections.  I 
resolved that by disabling authentication on the master server.

After the upgrade, I see some "Dead" entries in the list of slaves on the left 
side of the Jenkins opening page.  When I click the red "Dead" entry, it shows 
the following stack trace:

java.lang.NullPointerException at 
hudson.matrix.MatrixConfiguration.newBuild(MatrixConfiguration.java:218) at 
hudson.matrix.MatrixConfiguration.newBuild(MatrixConfiguration.java:64) at 
hudson.model.AbstractProject.createExecutable(AbstractProject.java:1197) at 
hudson.model.AbstractProject.createExecutable(AbstractProject.java:136) at 
hudson.model.Executor.run(Executor.java:211)

Once I click through that "Dead" thread one or two times, the slave agent seems 
to remain running without interruption.


Are those expected results that are part of the transition from 1.480.1 to 
1.480.2?

Thanks,
Mark Waite