Re: /home and /root handling

[Colin Walters <walters verbum org>]

On Sat, Dec 23, 2017, at 8:35 AM, Dan Nicholson wrote:

> I agree that it's nice that most of the state is under /var, but
> that's not actually how it is today since /home and /ostree resolve
> into /sysroot. 

/ostree (/sysroot/ostree) is very special state.  As for /home...today
for rpm-ostree we end up making it be /var/home by default actually,
in contrast to the ostree docs.

One wrinkle in the otherwise nice idea of sharing /home between
different OS installs is SELinux (or perhaps generalized to different LSMs
with xattrs or different versions of them).  It's possible for /home itself
or more likely subdirectories to have different labels.

> Putting things in /var also means that you lose the
> system wide nature if you were to deploy multiple OSes. 

I actually wonder how many people are using that feature.  I think
it is cool, but it's also this extra thing one has to understand.  It feels
a bit like an LVM volume group to me; yes, you can have multiple and
it makes sense to do so in advanced cases, but in the simple cases it'd
be nice if it was invisible by default.

> I think you're talking more about ostree container while I'm thinking
> about ostree host. In an ostree host, you couldn't make /sysroot
> read-only since that's where /sysroot/ostree lives and you'd never be
> able to update. 

See the linked issue, specifically this phrase:

"...and then have apps using libostree create a new mount namespace,
  and make manipulations there. That way the system stays read-only to
 everything else."

This is a bit like how today with `rpm-ostree livefs` it actually writes
to the deployment root "underneath" the ro /usr mount.

Basically IMO libostree is not about "immutability" - it's about
*controlling* mutability to a much greater degree than is done
via traditional package systems and the like.

> Why handle /tmp at all? Don't you just mount a tmpfs over it?

See the linked rpm-ostree issue:
https://github.com/projectatomic/rpm-ostree/pull/778

> Now that I'm thinking about this some more, it think it would be an
> improvement for ostree host if /ostree, /home and /root where bind
> mounts from their /sysroot equivalents. 

That conflicts directly with the approach of making /sysroot read-only
to everything else though.

Does this all make sense?  While I think we should be flexible, it's
obviously useful if libostree-based systems can converge on common
semantics since other projects like systemd will have to learn to interact
with them in some cases.