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 <cha...@lytro.com<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 <markwa...@yahoo.com<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 <ri...@oldelvet.org.uk<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.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 -- 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
