Re: [vagrant-up] Discussion about private_network issue (continued from gh-2881)

[Alvaro Miranda Aguilera]

I think the way you are approaching is causing you so much troubles.

1. At this moment, and until that change, the virtualbox provider will use
eth0 as nat.

2. at the boot time, the port forwarders and the nics are cleared out and
reconfigured

3. all the reconfiguration is done by the forwarded port done in 1.

so you have a chicken egg you are trying to break, but the way it is, it
works, just you want to make it work diffeerently.

I think at the moment, you should have 2 configuration blocks, one for the
destop/virtualbox and other for your cloud provider.

I did test those config.ssh.port/host and wasn't able to make them work due
the point 1 and 2.

After chekcing past issues, I can see you have been months trying to get
those to work, however.

I thing the best way to go is the 2 block for virtualbox and cloud.

Alvaro.



On Sun, Feb 9, 2014 at 4:17 PM, Alan Pinstein apinst...@mac.com wrote:

 Actually you have to disable the custom ssh host  port, as with the
 private networking and custom ssh, the default ssh port-forwading doesn't
 run, and the box is inaccessible...


 On Saturday, February 8, 2014 10:11:11 PM UTC-5, Alan Pinstein wrote:

 Actually, now that I try it with a real setup, I don't see how using:

   config.ssh.host = [private network ip]

 ever works... because in this situation, vagrant will always kill the
 private network on all runs 2..n trying to re-configure the network... see
 log below.

  INFO ssh: Attempting SSH connnection...
  INFO ssh: Attempting to connect to SSH...
  INFO ssh:   - Host: 33.33.33.50
  INFO ssh:   - Port: 1855
  INFO ssh:   - Username: vagrant
  INFO ssh:   - Key Path: [/Users/apinstein/.vagrant.d/
 insecure_private_key]
  INFO subprocess: Starting process: [/usr/bin/VBoxManage, showvminfo,
 9e49fd36-ef99-49df-9219-b1b867e2ee64, --machinereadable]
  INFO ssh: SSH is ready!
  INFO interface: info: Machine booted and ready!
 [default] Machine booted and ready!
  INFO warden: Calling IN action: #VagrantPlugins::
 ProviderVirtualBox::Action::CheckGuestAdditions:0x0100f8a0d8
  INFO subprocess: Starting process: [/usr/bin/VBoxManage,
 guestproperty, get, 9e49fd36-ef99-49df-9219-b1b867e2ee64,
 /VirtualBox/GuestAdd/Version]
  INFO warden: Calling OUT action: #VagrantPlugins::
 ProviderVirtualBox::Action::CheckGuestAdditions:0x0100f8a0d8
  INFO warden: Calling OUT action: #Vagrant::Action::Builtin::
 WaitForCommunicator:0x0100f880a8
  INFO warden: Calling OUT action: #VagrantPlugins::
 ProviderVirtualBox::Action::Customize:0x0100f80060
  INFO warden: Calling OUT action: #VagrantPlugins::
 ProviderVirtualBox::Action::Boot:0x0100f800b0
  INFO warden: Calling OUT action: #VagrantPlugins::
 ProviderVirtualBox::Action::Customize:0x0100f80178
  INFO warden: Calling OUT action: #VagrantPlugins::
 ProviderVirtualBox::Action::SaneDefaults:0x0100ed1100
  INFO warden: Calling OUT action: #Vagrant::Action::Builtin::
 SetHostname:0x0100ed1150
  INFO warden: Calling OUT action: #VagrantPlugins::
 ProviderVirtualBox::Action::ForwardPorts:0x0100ed12e0
  INFO subprocess: Starting process: [/usr/bin/VBoxManage, showvminfo,
 9e49fd36-ef99-49df-9219-b1b867e2ee64, --machinereadable]
  INFO interface: info: Configuring and enabling network interfaces...
 [default] Configuring and enabling network interfaces...
  INFO ssh: SSH is ready!
  INFO guest: Execute capability: configure_networks (redhat)
  INFO ssh: SSH is ready!
  INFO guest: Execute capability: network_scripts_dir (redhat)
  INFO ssh: Execute: /sbin/ifdown eth1 2 /dev/null (sudo=true)
  INFO subprocess: Starting process: [/usr/bin/VBoxManage, showvminfo,
 9e49fd36-ef99-49df-9219-b1b867e2ee64, --machinereadable]
  INFO subprocess: Starting process: [/usr/bin/VBoxManage, showvminfo,
 9e49fd36-ef99-49df-9219-b1b867e2ee64, --machinereadable]
  INFO ssh: Execute: echo; printf $SSH_AUTH_SOCK (sudo=false)
  INFO subprocess: Starting process: [/usr/bin/VBoxManage, showvminfo,
 9e49fd36-ef99-49df-9219-b1b867e2ee64, --machinereadable]
  INFO subprocess: Starting process: [/usr/bin/VBoxManage, showvminfo,
 9e49fd36-ef99-49df-9219-b1b867e2ee64, --machinereadable]
  INFO ssh: Setting SSH_AUTH_SOCK remotely: /tmp/ssh-UqBfSa1371/agent.1371
 [hangs ssh vagrant@33.33.33.50 will never work b/c vagrant just ran
 `/sbin/ifdown eth1` ]

 Right?

 On Saturday, February 8, 2014 9:47:43 PM UTC-5, Alan Pinstein wrote:

 I should add.. I'm not really concerned about security with VirtualBox
 provider, but we wanted to start trying out Vagrant to bootstrap our cloud
 instances, and thus I wanted to automate moving of the ssh port.

 That said, is there a place/way to put a block code that only runs on
 certain providers? So that way I could locate the code that kills port 22
 ssh in certain providers. My concern here is that even if I could do this,
 wouldn't I still have the same problem but just on that provider?

 I really think the fix here is to make vagrant's network munging much
 more robust. Change 

Re: [vagrant-up] Common Vagrantfile to provision code as a VM or Docker container (building via Dockerfile)

[Alvaro Miranda Aguilera]

Have a look at

config.ssh.port
config.ssh.host

If you set those, and the vagrant user/ssh key, then I assume you can use
vagrant to connect and execute commands in that machine you want to use
with docker.

Will be this what you are looking?

Desktop with Vagrant === Server with Docker.

Alvaro.


On Sun, Feb 9, 2014 at 6:14 PM, Slicer ja...@balean.com.au wrote:

 I'm trying to standardize my project development setup using Vagrantfiles
 such that project components may be installed on multiple virtualization
 platforms - Virtual Box, VMware, Parallels, ... - as well as in Docker
 containers. Project components will be developed on separate VMs, then
 integrated for production using Docker containers on another VM.


 *For development of components:*

- I have created minimal base boxes for all platforms, and add
Provider definitions for each in the Vagrantfile of components. Components
are then Provisioned with Puppet. This is the typical way Vagrant is used.


 *For production (integration of components):*

- The aim is to the have the production Vagrantfile's Provisioner
(Puppet) execute component Vagrantfiles on the VM. These will create Docker
containers for each project component and Provision with Puppet. I believe
this will require a Docker Provider, similar to Fabio Rehm's attempt (
github.com/fgrehm/docker-provider). However, it seems as though it is
not possible to provision the Docker container ('machine mode') through
Vagrant using this project.


 *My queries:*

1. Has anybody else attempted something similar? What are your
comments on this approach?
2. Is it necessary to install Vagrant on the production VM to execute
the Docker Vagrantfiles? Or is it possible to use the Vagrant installation
on the hypervisor to provision internal Vagrantfiles over SSH?
3. As this use case shows, I would have thought that Docker is more of
a Vagrant Provider than a Provisioner, though perhaps I am misunderstanding
something?

 Any advice would be greatly appreciated.

 Thanks,
 Slicer

 --
 You received this message because you are subscribed to the Google Groups
 Vagrant group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to vagrant-up+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
You received this message because you are subscribed to the Google Groups 
Vagrant group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vagrant-up+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.