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, <matthew.web...@diamond.ac.uk> 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 <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> 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> > 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 > > > -- *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.
