That fixes the mounting problem. You've WONTFIXed the security options
(and I understand your reasoning there).
One last question: Since this requires the pool to be empty at `lxd
init` time, is that going to cause a problem for reinstalls? That is, if
I have a working system, then I reinstall it (e.g. for an OS upgrade or
repair), would I normally re-run `lxd init`? If not, I think this is
done.
Thanks for bearing with me on this!
** Description changed:
+ lxd should ensure that, when using an existing pool, its datasets are
+ not spuriously mounted.
+
+ --- Original Description:
+
Currently, lxd is not explicitly creating the intermediate "containers"
and "images" datasets. It is allowing them to be created implicitly by
calling "zfs create -p".
I would like to see lxd always (regardless of whether lxd is creating
the pool) create these datasets explicitly (e.g. in lxd/main.go) and set
"canmount=off" or "mountpoint=none" on both. Otherwise, regardless of
which existing dataset I choose, I end up with "/something/containers"
and "/something/images" mounted for no reason. Setting "canmount=off" or
"mountpoint=none" are the normal approaches for ZFS datasets that only
exist to contain other datasets; which one to use depends on whether the
children need to inherit a mountpoint. Currently, the children of
"containers" and "images" do not need to inherit a mountpoint, as lxd
always sets a mountpoint. (This is because lxd wants the mountpoints to
be "foo.zfs" rather than just "foo".) So either option would be fine.
I think it would be wise to also set "exec=on" and "setuid=on" on the
"containers" dataset. If the children of the "containers" dataset are
mounted with noexec ("exec=off"), the container fails to start, for
obvious reasons. Likewise, "setuid=on" is necessary for proper operation
of setuid executables inside the container. If lxd doesn't set these
options itself, it is at the mercy of whatever options might be
inherited. This was a problem for me; see below.
Since "devices=off" is not a problem, I don't see any other options to
be concerned with. The other options are either irrelevant, or might be
something the admin actually wants to control. It's just these two that
break the container.
Setting the options as described above would fix the following scenario,
plus many other scenarios:
# Simulate a root pool setup that matches the upstream ZFS root HOWTO (which
I maintain):
truncate -s 10G /var/lib/rpool.img
zfs create rpool /var/lib/rpool.img
zfs set -o devices=off rpool
zfs create -o canmount=off -o setuid=off -o exec=off rpool/var
# Try to use lxd, following the same dataset convention:
zfs create -o canmount=off rpool/var/lib
zfs create rpool/var/lib/lxd
apt install lxd
lxd init
# Specify "no" to creating a pool, and "rpool/var/lib/lxd" as the existing
dataset.
# Accept the rest of the defaults.
lxd launch ubuntu:
The "containers" and "images" datasets are created too late, after data
has already been written to /var/lib/lxd/containers and
/var/lib/lxd/images. Creating them earlier solves this, as would setting
"canmount=off" or "mountpoint=none" regardless of when they are created.
The latter has the advantage of also fixing the unnecessary mounting for
other cases.
** Summary changed:
- lxd should explicitly create "containers" and "images" datasets on ZFS
+ lxd should avoid spurious mounting of ZFS datasets on existing pools
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1629824
Title:
lxd should avoid spurious mounting of ZFS datasets on existing pools
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1629824/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
