I understand why the network breaks. However I made a point on the issue (https://github.com/mitchellh/vagrant/issues/2881#issuecomment-34139326) that in this case it'd seem you can actually fix the bug. I don't see any reason to shut down the network, edit configs, then start the network. Why not edit the config, then restart the network in a single command, thus preventing any issue with my approach. I am sure I'm not the only one to run into this type of thing.
The other thing is that your fix is to add a rule for eth0, but there's no explicit config that makes the NAT on eth0. That might change in a future vagrant, and that'd be a subtle & dangerous regression. Unless/until you can map specific network configs to specific adapters, that seems like a bad idea, no? On Thursday, February 6, 2014 7:12:02 PM UTC-5, Alvaro Miranda Aguilera wrote: > > For the ssh port issue, I have to change your Vagrantfile a bit. > > As you are concerned of the security reasons, I did add a rule in iptables > that will allow only connections from interface eth0, that is nat, so > nothing bad will happen > > I add port 22 and 1855 to sshd, but 22 is protected by the iptables > firewall. > > A. On the first run, the normal portforwarded for ssh is [default] -- 22 > => 2222 (adapter 1), so the normal behaviour will fail on the 2nd run, as > ssh won't be on port 22 anymore > > So, we need to fix that for the 2nd and next runs > > *AND* > > on each run, on top, remember this happen: > > [default] Clearing any previously set forwarded ports... > > > [default] Clearing any previously set network interfaces... > > > > B. so, you won't be able to connect over the network that is not yet > created, that's why the ssh on the 2nd run fail. > > Please try this on your Vagrantfile > > if !::File.exists? ".vagrant/machines/default/virtualbox/id" # first-time > bootstrapping -- this is the best approximation of once-per-setup that can be > done, even mitchellh says so. > puts "NOTICE: Detected first-run of instance. Will connect localhost/2222 > and run first-time-only script." > # security configuration > config.vm.provision :shell, :inline => 'grep "root.*NOPASSWD" > /etc/sudoers || echo "root ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers' > config.vm.provision :shell, :inline => 'grep "SSH_AUTH_SOCK" /etc/sudoers > || echo "Defaults env_keep+=SSH_AUTH_SOCK" >> /etc/sudoers' > > > # configure iptables for our custom > port > > # install basic ssh port 22 rule if there is no existing iptables config > > > config.vm.provision :shell, :inline => "grep 'dport 22 ' > /etc/sysconfig/iptables 2>/dev/null || ( iptables -A INPUT -p tcp -m tcp > --dport 22 -j ACCEPT && service iptables save)" > > > # configure ssh for our custom port > > > config.vm.provision :shell, :inline => "grep '^Port 1855$' || echo 'Port > 1855' >> /etc/ssh/sshd_config && service sshd restart" > > config.vm.provision :shell, :inline => "grep '^Port 22$' || echo 'Port > 22' >> /etc/ssh/sshd_config && service sshd restart" > > config.vm.provision :shell, :inline => "sed -i 's/--dport 22 /--dport > 1855 /gi' /etc/sysconfig/iptables && service iptables restart" > > config.vm.provision :shell, :inline => "grep 'dport 22 ' > /etc/sysconfig/iptables 2>/dev/null || ( iptables -A INPUT -i eth0 -p tcp -m > tcp --dport 22 -j ACCEPT && service iptables save)" > else > > > # once we're on our custom port, disable the built-in host -> guest:22 > forwarding so that we can spin up multiple vagrants without incident. > > # https://github.com/mitchellh/vagrant/issues/1922 > > > # > https://github.com/mitchellh/vagrant/search?q=collision&ref=cmdform&type=Issues > > > #config.vm.network :forwarded_port, guest: 1855, host: 2222, > id: "ssh", auto_correct: true, disabled: true > > > > > > > > end > > > > > > > > > > On Thu, Feb 6, 2014 at 5:19 PM, Alan Pinstein <[email protected]<javascript:> > > wrote: > >> Alvaro asked me to move this discussion to the ML: >> https://github.com/mitchellh/vagrant/issues/2881#issuecomment-34147376 >> >> In summary I see a few issues: >> >> - As a user I don't expect placing network config to be handled >> differently when placed in a global config block vs a provider config >> block, esp since vagrant seems to be heading in a direction where one >> would >> use it to configure the same box across different providers (dev on VBox, >> prod on AWS for instance), being able to have per-provider network config >> work gracefully would seem to be the goal. >> - The way vagrant handles "re-configuring" the network is fragile; it >> stops the network, re-generates some temp files, ssh's them over, then >> re-starts the network. You can easily see how this would break if ssh >> only >> listens on the port that is being taken down, as the subsequent >> config/ifup >> commands will not succeed. It would seem that the config files should be >> pre-generated, copied over in a single ssh request, and ifdown/ifup in a >> single request to eliminate the network suicide problem currently >> exhibited. >> >> I think in the end those are the major issues that I feel exist after >> working through this particular issue. >> >> Thoughts? >> Alan >> >> -- >> 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 [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
