Reverse port forwarding

18 views
Skip to first unread message

Benjamin Riefenstahl

unread,
May 16, 2019, 4:47:00 AM5/16/19
to vagra...@googlegroups.com
Hi everybody,

I'm new to this list, so please forgive me if this has been discussed
before, or if the solution is too obvious ;-)

We have a Vagrantfile that runs fine with 1.9.4 but has a problem with
2.2.4. We use the vagrant-triggers plugin and I am trying to make it
work with core triggers.

The Vagrantfile creates a development test system that consists of a
number of Debian VMs. For networking we use host-only private network
to isolate our testing from the rest of the world. Initially the VMs
need to be provisioned by installing packages from a Debian repo. To
connect to the repo we use a company internal HTTP proxy and port
forwarding from the VMs to the proxy on the host.

So to quote some code, we are doing this:

config.vm.define opts[:name] do |host|
# ...
host.vm.provision :trigger, run: "always" do |trigger|
trigger.fire do
run "vagrant ssh #{opts[:name]} -- -f -R 10000:proxy:8080 -N"
end
end

With 2.2.4, a direct translation of this would be something like

host.trigger.before :all do |trigger|
trigger.run = {inline: "vagrant ssh #{opts[:name]} -- -f -R 10000:proxy:8080 -N"}
end

But that does not work, because I can not execute "vagrant ssh" before
"vagrant up". "before :provision" does not work either, when I execute
"vagrant up" before the machine even exists, because the trigger is not
called for the provisioning step implied here by "vagrant up".

The main things I tried:

* ssh.extra_args, ssh.config - These do not work, because for
provisioning the standard SSH tool is not used, but a pure-Ruby
implementation of SSH that does not use these parameters. The Ruby
implementation supports remote forwards, but as it seems only via an
extra API. BTW: You want to mention in the documentation which of
these config parameters apply to provisioning, if any.

* trigger.before :"Vagrant::Action::Builtin::Provision", type: :action -
I enabled VAGRANT_EXPERIMENTAL=1 but this trigger does not seem to be
called. These new triggers are not yet fully documented it seems, so
I searched the code for a hook but could not find anything that works.

I have some work-arounds, but than it seems easier for now to just stick
with the old version of Vagrant.

Regards and TIA for any hint,
Benny Riefenstahl

--
mecom Medien-Communikations-Gesellschaft mbH

Mittelweg 143, D 20148 Hamburg

Tel: +49 40 411332 801

Fax: +49 40 451962

http://www.mecom.de

Registergericht Hamburg, HRB 43177

Geschäftsführung: Barbara Bliefert, Norbert Schmidt-Banasch

Brian Cain

unread,
May 16, 2019, 5:25:51 PM5/16/19
to vagra...@googlegroups.com
Hey there Benny,

Thanks for taking a look at the action triggers! I'll respond inline

Ah ok, so actually what you have written here is a trigger that will run before a given
guest runs any command, which I don't think is exactly the same.

You are correct in thinking that Vagrant::Action::Builtin::Provision would be the right
action to run before the provision step. Unfortunately that action does not work exactly
how you would expect it to work. It actually runs very early in the vagrant life cycle and returns early before
actually running any provision steps. So even if you get the trigger working, it would run before you
expected it to.

We have plans of adding a basic Provision action "stub" so that you can do exactly what you are wishing to here, but
we haven't got there yet.

That being said! For now you should be ok attaching your trigger to another action, perhaps?
 

But that does not work, because I can not execute "vagrant ssh" before
"vagrant up".  "before :provision" does not work either, when I execute
"vagrant up" before the machine even exists, because the trigger is not
called for the provisioning step implied here by "vagrant up".

The main things I tried:

* ssh.extra_args, ssh.config - These do not work, because for
  provisioning the standard SSH tool is not used, but a pure-Ruby
  implementation of SSH that does not use these parameters.  The Ruby
  implementation supports remote forwards, but as it seems only via an
  extra API.  BTW: You want to mention in the documentation which of
  these config parameters apply to provisioning, if any.

* trigger.before :"Vagrant::Action::Builtin::Provision", type: :action -
  I enabled VAGRANT_EXPERIMENTAL=1 but this trigger does not seem to be
  called.  These new triggers are not yet fully documented it seems, so
  I searched the code for a hook but could not find anything that works.

Apologies for this. The feature isn't as fully functional as I had hoped after implementing it, which is why
it's mostly guarded behind the experimental flag at the moment :) We have some provosioner enhancements
coming soon and will include some stuff that should make this a little nicer to work with. That should
include making these docs better, and hopefully removing the experimental guard.
 

I have some work-arounds, but than it seems easier for now to just stick
with the old version of Vagrant.

Regards and TIA for any hint,
Benny Riefenstahl

--
mecom Medien-Communikations-Gesellschaft mbH

Mittelweg 143, D 20148 Hamburg

Tel: +49 40 411332 801

Fax: +49 40 451962

http://www.mecom.de

Registergericht Hamburg, HRB 43177

Geschäftsführung: Barbara Bliefert, Norbert Schmidt-Banasch

--
This mailing list is governed under the HashiCorp Community Guidelines - https://www.hashicorp.com/community-guidelines.html. Behavior in violation of those guidelines may result in your removal from this mailing list.

GitHub Issues: https://github.com/mitchellh/vagrant/issues
IRC: #vagrant on Freenode
---
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vagrant-up/86ftpe9475.fsf%40riefenstahl3.mecom.de.
For more options, visit https://groups.google.com/d/optout.


--
Brian Cain

Benjamin Riefenstahl

unread,
May 20, 2019, 4:14:21 AM5/20/19
to Brian Cain, vagra...@googlegroups.com
Hi Brian,


Brian Cain writes:
> Thanks for taking a look at the action triggers!

;-) Thank you for your remarks.

> Benjamin Riefenstahl <Riefe...@mecom.de> wrote:
> So to quote some code, we are doing this:
>
> config.vm.define opts[:name] do |host|
> # ...
> host.vm.provision :trigger, run: "always" do |trigger|
> trigger.fire do
> run "vagrant ssh #{opts[:name]} -- -f -R 10000:proxy:8080 -N"
> end
> end
>
> With 2.2.4, a direct translation of this would be something like
>
> host.trigger.before :all do |trigger|
> trigger.run = {inline: "vagrant ssh #{opts[:name]} -- -f -R
> 10000:proxy:8080 -N"}
> end
>
> Ah ok, so actually what you have written here is a trigger that will
> run before a given guest runs any command, which I don't think is
> exactly the same.

Obviously.

> You are correct in thinking that Vagrant::Action::Builtin::Provision
> would be the right action to run before the provision
> step. Unfortunately that action does not work exactly how you would
> expect it to work. It actually runs very early in the vagrant life
> cycle and returns early before actually running any provision
> steps. So even if you get the trigger working, it would run before you
> expected it to.

Is that usefull?

> We have plans of adding a basic Provision action "stub" so that you
> can do exactly what you are wishing to here, but we haven't got there
> yet.

Ok.

> That being said! For now you should be ok attaching your trigger to
> another action, perhaps?

Which would that be? To restate the requirements of the scenario
(itself not written in stone, of course ;-)), it would have to run after
the machine is created, but before it is actually provisioned.


Thanks, benny
Reply all
Reply to author
Forward
0 new messages