collective / collective.hostout

zc.buildout deployment and remote control
22 stars 7 forks source link

Still too much sudo #7

Open auspex opened 13 years ago

auspex commented 13 years ago

Why is a hostout deployment I've used for months with 1.0a3 now running "bootstrap_users" when I try to use 1.0a5? How can I stop it? I don't have or need sudo access, my users exist, I just need to get on with the "deploy".

djay commented 13 years ago

I'm not sure. I have decided however to seperate bootstrap routines out of predeploy as testing if you need to bootstrap has been problematic. This will mean bootstrap will be a manual step and less magic. I'll let you know when I've made this change.

auspex commented 13 years ago

I've determined why it wanted to bootstrap. When I first started using hostout, I specified the "identity_file" option. Later, I moved to the github version, and I was having trouble with the logons. I was always prompted for a password - even though I already had passwordless logons set up for the account. So I removed the "identity_file" option, and everything worked again. I'm not sure what really went wrong there, but I suspect I was confused by the documentation which says.:

identity-file
  A public key for the login user.

when it isn't really the public key it's the private key.

In 1.0a5, I see it's relying on the presence of that identity_file setting to determine if it needs to bootstrap. I'm not sure that's ideal, but once I correctly set identity_file, it stopped trying to bootstrap.

djay commented 13 years ago

The latest code has removed the autobootstrap. In addition the bootstrap itself should be able to run without sudo access. We're still working on one more issue to make that change complete.