Closed mmlb closed 2 years ago
The use of
downcase
seems odd when the hardcoded MAC in theVagrantfile
was using upppercase. But if it all works, then presumably the code that uses that value doesn't care.
Yeah, but the hardcoded mac in ../compose/.env is lowercase so I decided to keep it that way.
To use a dedicated adapter (real hardware, and not everybody can tinker(!) the surrounding network to isolate VLANs etc..) one has to switch to public networking and add the hardware. I am doing this for quite a while now:
provisioner.vm.network "public_network", ip: PROVISIONER_IP, bridge: ENV['MYTINK_BRIDGEDEV'],
and if the real MACHINE_1 shall get network/internet access:
provisioner.vm.provision "shell", name: "iptables", inline: <<-SCRIPT.gsub(/^ {6}/, "")
set -x
/usr/sbin/iptables --policy FORWARD ACCEPT
/usr/sbin/iptables -t nat -A POSTROUTING -s #{MACHINE1_IP} -j MASQUERADE
SCRIPT
the policy could be more strict, but "it works".
('Philipp' from chat)
Description
Allows for overriding the default vagrant/libvirt network details.
Why is this needed
Lets us use the vagrant and compose setup in a sort of hybrid mode with a real hw machine as machine1 instead of the VM.
How Has This Been Tested?
Ran
vagrant up
and verified defaults still work and overrides do in fact show up.How are existing users impacted? What migration steps/scripts do we need?
A way to test with real hardware while using the vagrant setup for the services.