Re: Interactive Provisioning

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Interactive Provisioning

Patrick Connolly
In case it helps anyone, it's a little less clean than I'd like, but here's how we do it:

Generate gitignored config file with rake task:
https://github.com/myplanetdigital/vagrant-ariadne/blob/db557fe28b8986d62bbeb7a7cf129a6a06b11e4a/Rakefile#L18-L34

Load config settings into Vagrantfile and roles:
https://github.com/myplanetdigital/vagrant-ariadne/blob/db557fe28b8986d62bbeb7a7cf129a6a06b11e4a/Vagrantfile#L33
https://github.com/myplanetdigital/vagrant-ariadne/blob/db557fe28b8986d62bbeb7a7cf129a6a06b11e4a/roles/ariadne.rb

The values all get loaded into the chef node object in our case:
https://github.com/myplanetdigital/vagrant-ariadne/blob/db557fe28b8986d62bbeb7a7cf129a6a06b11e4a/Vagrantfile#L111

For what it's worth, we allow these to be set via envvar, and this overwrites the settings in the config.yml file:
https://github.com/myplanetdigital/vagrant-ariadne/blob/db557fe28b8986d62bbeb7a7cf129a6a06b11e4a/Vagrantfile#L22-L40

So if there's a value named "basebox" in the config.yml file, you can run this to set it to "lucid64" before running any vagrant command:

`basebox=lucid64 vagrant up` or `basebox=lucid64 vagrant reload`

Also handy to reprovision a VM, for example if you have recipes that can rebuild a site from a different branch:

`branch=123-my-new-feature clean=true vagrant provision`

(`clean=true` is the "safety" envvar that is needed to blow away the site docroots)

Anyhow, currently thinking on how to convert this into a vagrant plugin that generalizes the features in between projects.

P

On Thursday, June 21, 2012 1:45:00 PM UTC-4, Mitchell Hashimoto wrote:
Matt,

On Thu, Jun 21, 2012 at 8:44 AM, Matt Bierbaum <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="VxhfVpTPPw8J">matt.b...@...> wrote:

> I was wondering if there was a way to provide user interaction during
> provisioning.  As it is now, I'm using a Shell provisioner that would like
> to ask for a password to gather a public key from another server.  However,
> the ssh run during `vagrant up` does not allocate a pseudo-tty.  Is there a
> way to provide this option to ssh during the up command.  The shell does run
> successfully when run with ssh -t -p 2222 vagrant@localhost "/bin/bash
> ~/script.sh".  I tried to sneak it into other parts of the ssh command but
> it appears you've escaped the options well enough.
>
> I was also considering using ssh-askpass, but haven't got that to function
> properly either.  The last option is to login to the box and run the script.
>  I was hoping to make these as simple to distribute as possible though.

There isn't any way to ask for input because usually thats not what
you want to do. However, it is an idea for the future.

In the meantime, there are a few options:

1. Use a version control ignored local file for storing your
passwords, have your Vagrantfile read this file. This way the
passwords remain on the system.
2. Use environmental variables that are read in the Vagrantfile and
passed as arguments perhaps to the shell script.

I hope this helps.

Best,
Mitchell

>
> Thanks!

--
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Interactive Provisioning

Patrick Connolly
This might help:
http://stackoverflow.com/questions/7211287/use-ssh-keys-with-passphrase-on-a-vagrantchef-setup

If your users have ssh keys on their host machines that have access, this gives the chef run (and `vagrant ssh`) access to the forwarded session of the host. So your VM can access anything that the host can via ssh keys :)

On Thursday, June 21, 2012 2:40:22 PM UTC-4, Matt Bierbaum wrote:
Thank for you for the response.  I  am currently doing something similar to 1. though I was hoping to remove the need for a password stored in a flatfile.  We are trying to distribute a VM to a number of sources (some more secure than others) to join in a computational task.  Currently authentication for the box goes through a public key which provides access to shared resources using sshd restrictions and chroot jail.  As the provisioning is finished, the idea is that the user enters his credentials to authenticate the box and is then locked out of the box and left with a webserver that outputs its status.  However, I was hoping to remove a bit of direct insecurity by removing the password file.  

Another option would be two stage provision where the main provisioner runs most of the setup.  Then, we could ask the user to also run `vagrant ssh -c "finish.sh" -- -t` and resolve credentials at that time.  Something like this is an option as well.  

Do you have thoughts on better ways to achieve these stand alone compute resources that could live in places of mixed security?  

On Thursday, June 21, 2012 1:45:00 PM UTC-4, Mitchell Hashimoto wrote:
Matt,  

On Thu, Jun 21, 2012 at 8:44 AM, Matt Bierbaum wrote:

> I was wondering if there was a way to provide user interaction during
> provisioning.  As it is now, I'm using a Shell provisioner that would like
> to ask for a password to gather a public key from another server.  However,
> the ssh run during `vagrant up` does not allocate a pseudo-tty.  Is there a
> way to provide this option to ssh during the up command.  The shell does run
> successfully when run with ssh -t -p 2222 vagrant@localhost "/bin/bash
> ~/script.sh".  I tried to sneak it into other parts of the ssh command but
> it appears you've escaped the options well enough.
>
> I was also considering using ssh-askpass, but haven't got that to function
> properly either.  The last option is to login to the box and run the script.
>  I was hoping to make these as simple to distribute as possible though.

There isn't any way to ask for input because usually thats not what
you want to do. However, it is an idea for the future.

In the meantime, there are a few options:

1. Use a version control ignored local file for storing your
passwords, have your Vagrantfile read this file. This way the
passwords remain on the system.
2. Use environmental variables that are read in the Vagrantfile and
passed as arguments perhaps to the shell script.

I hope this helps.

Best,
Mitchell

>
> Thanks!

--