Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to run as an Agent #30

Open
cowwoc opened this issue Dec 16, 2013 · 5 comments
Open

Ability to run as an Agent #30

cowwoc opened this issue Dec 16, 2013 · 5 comments

Comments

@cowwoc
Copy link

cowwoc commented Dec 16, 2013

Jenkins must run as an Agent (instead of a Daemon) if you need to run the iOS simulator. See http://9elements.com/io/index.php/continuous-integration-of-ios-projects-using-jenkins-cocoapods-and-kiwi/ for an explanation.

Please add a command-line option to install the service as an Agent.

@rhwood
Copy link
Owner

rhwood commented Dec 19, 2013

I think the following will need to be done:

  • use a keychain other than the login keychain by default.
  • ensure that security.sh does not attempt to lock or unlock the login keychain when running as an agent.
  • provide an intelligent migration method from the login keychain to the new keychain (this could be done later).
  • the installer needs to place the launch daemon plist in the correct place.
  • ensure the installer, when installing the agent, and when run by the user that will use the agent, does not call sudo

@rhwood
Copy link
Owner

rhwood commented Dec 19, 2013

Actually just ensuring that when run as an agent, security.sh does not lock the keychain would obviate any advantage of not using the login.keychain (since it would otherwise cause confusion when configuring jobs on Jenkins).

@cowwoc
Copy link
Author

cowwoc commented Jan 6, 2014

I posted a description of how I believe this should be implemented: https://issues.jenkins-ci.org/browse/JENKINS-21237

@rhwood
Copy link
Owner

rhwood commented Jan 9, 2014

I'm actually thinking that I'm going to require that, to install as an agent, the account must exist already, and that the installer be run by the account that will run the agent, such that something like:
sudo -u agent-user install —agent
would force an agent-based installation for another user.

Maybe I ought to just prompt for the type of installation unless —agent or —daemon are passed to the installer…

I have another higher-priority project to work on the next couple of weeks before I get to this.

@cowwoc
Copy link
Author

cowwoc commented Jan 9, 2014

I'm fine with that (requiring the account to exist).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants