Creating a new vagrant machine with a box created with an old LXC config
format would fail with LXC 3.0. We now update the LXC config of the box
itself before calling `lxc-create`.
LXC 3.0, unlike 2.1, doesn't support old configuration formats at all
and because our previous approach to handling old format was incomplete,
running `vagrant up` on a system with LXC 3.0 would fail, even if the
base box itself was made with modernized config.
This commit fixes this problem: is the box has a modern config, it's
going to be properly created and booted under LXC 3.0. It does so
without breaking the support for LXC < 2.1
Since redir 2.x upstream is not evolving it, Joachim Nilsson adopted it
and have started to work on it and publish a new command line interface
(check out https://github.com/troglobit/redir). The redir 3.1 is already
available in Debian and Ubuntu in their stable releases.
To fix#406, I reverted the tmpfs mount we add at boot time. As we can
see in #455, it was a bad idea.
In addition to bringing back that mount, I've also added a
`tmpfs_mount_size` config that allows to change the size of the mount
from its default `2G`. It's also possible to disable the mount
altogether.
fixes#455
fixes#406 because the `tmpfs` mount isn't needed anymore.
Careful considerations had to be taken because #68 mentions host-side
data loss when cleaning up `/tmp`. We mitigate this by ensuring that all
mounts under `/tmp` are unmounted before we proceed with our `rm -rf`
operation.
More context about this issue can be found in #360.
When running with LXC 2.1+, ensure that our boxes have up-to-date config
keys by running the `lxc-update-config` utility that ships with LXC
2.1+.
When the command doesn't exist (LXC <2.1), we do nothing.
ref #445
`lxc-info -iH` to retrieve IP address was not available in early LXC
development but was there at LXC 1.0. Because we've bumped our minimum
LXC requirement to v1.0 recently, we can simplify the IP retrieval
process and also get rid of the `dnsmasq` fallback.
By looking at the code, it seems that it was a goal to make the sudo
wrapper path configurable through the Vagrantfile, but it wasn't
effective and didn't make much sense (that kind of config is a per-host
config, not a per-guest one).
This caused the cause to be needlessly complex by giving the Provider
the responsibility of instanciating the wrapper. This commit gets rid of
that.
I didn't get rid of `sudo_wrapper` injection in `Driver` and
`Driver::CLI` constructors because they're needed for tests. I'm not
ready to tackle this yet.
No other vagrant plugin use `Gemfile.lock`. It doesn't feel right.
When removing it, however, we end up with many dependencies conflicts.
It then becomes necessary to freeze dependencies in `Gemfile`.
Subprocessed being interrupted resulted in it looking
like those commands were executing successfully but with
zero output. Interrupting the sudo prompt would result
in any command running in sudo returning nothing and looking
like it had succeeded. There was some clean up code in
the lxc provider that nuked vagrant container state in
the .vagrant directory if it looked like the container no
longer existed based on the result of lxc-ls. Interrupting
this check resulted in it looking like the container not
existing, resulting in the provider code nuking the lxc dir
in .vagrant. Voila
The previously hardcoded lxc path prevented the sudo wrapper from
working in environment with alternative `lxcpath`.
I had to move `sudo_wrapper` from `provider` to `LXC` because the
concept of "provider" is tied to a machine when a command sush as
`sudoers` is not.
Fixes#413 and #399
