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.
