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
lxc-template needlessly require root privileges in two places:
1. lock file location for `flock`
2. failing on `tar` failure during rootfs extraction
For `flock`, it's not necessary that the lock file be in `/var/lock`, it
can be anywhere. Why not put it in `LXC_PATH`?
For the failing `tar` thing, that's because some device are created with
`mknod` which unprivileged users can't do. These device, however, are
not necessary for the container to run well. We can ignore `tar`'s error
exit code.
I replaced the exist code check by a check for the existence of
`/bin/true` in rootfs. I think that it's a good indication of whether
the rootfs was extracted.
Why am I making this change? Because I'd like to add support for
unprivileged containers in `vagrant-lxc` but it's kind of a big change
to make at once, so I thought I'd go incrementally.
On Vagrant 1.9+ plugin gems are installed into a different folder, their path
containing the ruby version. This updates the regular expression whitelisting
the pipework script to reflect this change.
If LXC commands are run with a restrictive umask like 027 or 077, then
the root directory of new containers will lack read `r` and access `x`
permission for non-root users. The first failure to result from this
during `vagrant up` is that the SSH daemon cannot read the crucial file
`/home/vagrant/.ssh/authorized_keys` after it drops privileges to the
level of the `vagrant` user. The result is the familiar:
```
default: Warning: Authentication failure. Retrying...
default: Warning: Authentication failure. Retrying...
Timed out while waiting for the machine to boot. This means that
Vagrant was unable to communicate with the guest machine within
the configured ("config.vm.boot_timeout" value) time period.
```
So we should make sure that we run all LXC commands with a umask that at
least does not prevent group and world `r` and `x` bits from being set
in newly created files and directories.
