This fixes compatibility with the existing Vagrantfile in
coreos-vagrant which expected the plugin code to create this directory.
Also, the units can be runtime since they are always written at boot.
The environment file will not be written if there are no public or
private networks defined since the configure_networks hook is never run.
Report an error after one minute to make this situation less confusing.
- Only write configs for static networks, DHCP will work by default.
- Match interfaces by MAC address if possible.
- Use the configured netmask instead of always using a /24
- Define default addresses in /etc/environment based on the type of
network. Now using both a private and a public network works!
The old override-plugin.rb didn't actually properly monkey patch the
change host name function because it was missing a requires line
pointing to the file it is defined in upstream. To clarify things split
the code into two files that match the upstream names. Additionally
using this hook as it is intended means it works if a host name is
defined but additional networks are not.
As part of the split switch to starting the units directly. The
indirection through a path unit just adds complexity.
There's no reason for handling vagrantfile-user-data in the Vagrant
plugin, move it to the OEM cloud-config.yml along side the user-data
handler. Use the generic user-config@ unit as well.
Import override-plugin.rb and some VirtualBox fixups from our published
Vagrantfile repo. The current Vagrant OEM depends on this code, making
it impossible to boot without using our special Vagrantfile. Using the
box as a stand-alone entity worked up until recently and is something
users expect to work.
Also bump the minimum Vagrant version to 1.5, matching our current
documentation.
Fixes https://github.com/coreos/bugs/issues/5
This is the static piece of the Vagrantfile previously defined in
scripts/build_library/virtualbox_ovf.sh. Moving it here so we can start
maintaining the major Vagrant OEM pieces together.
In vagrant /etc/environment is set up by cloudinit but other services
still depend on the coreos-setup-environment.service unit as a signal
that /etc/environment is valid. Also the OEM needs to provide this
script in order to block the likely to be broken defaults from being
written. This just provides a dumb script that blocks.
Use system-cloudinit@.service because it does not depend on
coreos-setup-environment.service. Otherwise we would dead lock on a
circular dependency.
Assorted config directories in /etc are normally empty but without them
users generally have no idea that they can actually use them. Switch to
installing them again and add tmpfiles rules to recreate them.
