|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
- [JIRA] (JENKINS-16273) Slaves ... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)
- [JIRA] (JENKINS-16273) Sl... [email protected] (JIRA)

@jglick: Could you please point me to some information on how to properly configure Windows slave agents after the security fix? We are running on a closed network, but I'd prefer to configure it the right way if possible. Any information would be greatly appreciated.
If I understand correctly, the Windows service downloads and runs the slave-aget.jnlp when it starts using the parameters in the slave-agent.xml file. I'm not sure how to provide it an API key.
While we are on a closed network, we run security to control who may administer the Jenkins server and who can set up build projects. We thought it best to leave our Anonymous user restricted so non-developers would not have access to the server. We only added the "Connect" privilege to get our system back up and running after the upgrade.