Hi,
In live-boot/scripts/live one can find this comment:
# FIXME: add a custom mounts configurable system
It's in the context of setting up "home-rw", so presumably it's about
making overlays able to have their content appear in arbitrary
directories, not just in / and /home as we're currently limited to. In
other words it would be the overlay version of /etc/live-snapshot.list.
This is exactly what we need in Tails [1]. Previously we thought about
using cpio.gz type snapshots and /etc/live-snapshot.list, and for that
reason we outlined some stuff that need to be fixed with snapshots in
our persistence rework RFC [2]. The problem with snapshots is that they
are synced into a tmpfs, so they cannot handle large amounts of data,
and even smaller amounts of data can be problematic on systems with
little RAM. So overlays seem like the better option.
[1] https://tails.boum.org/
[2] http://live.debian.net/devel/rfc/persistence/
I'd like to implement this "custom mounts configurable system" in
live-boot, but the comment above suggests that someone may have thought
about how this would be designed already. If so, I'd like to hear about
it. However, I have already thought a bit about this, and come up with
this solution that I'd like comment and general input on (newest version
available in the RFC [2]):
Design for custom mounts system: locally specified inclusions
=============================================================
Features
--------
* Allows all types of overlays and snapshots to have the same
flexibility as cpio.gz snapshots with a /etc/live-snapshot.list.
* It's interface is consistent for both overlays and snapshots.
* Each persistent media contains information about where its content
should appear in the live filesystem.
General idea
------------
We make home-{rw,sn} obsolete, and use live-{rw,sn} as the only way to
tell that "this is a live-boot compatible overlay/snapshot". When a
persistent media (i.e. with the right label/filename) is found by
live-boot, it looks for a file called .live-persistence.list (but I'll
continue calling it just ".list" for brevity) in its root. If it's not
there, then it mounts the media on / just like it does for live-rw
currently. But if .list is present, then it doesn't mount anything on
/, it instead bind-mounts the directories listed in .list to their
specified destinations. Each persistent media can have it's own .list,
but we'd be careful about making sure not to hide a previous
bind-mounted directory by mounting everything in the right order, and
not allowing bind-mounts to the same mount point.
In-depth example
----------------
We want to have home-rw style persistence, but we also want the apt
cache in case of security upgrades and the occasional program we need
but are not installed on the image. So, inside our persistent media
$dev (either a file called live-rw.$EXT or a partition with label
live-rw), we put a .list containing:
/home/user
/var/cache/apt
When live-boot is supposed to mount $dev, it does so on some $mnt. It
checks for the existence of $mnt/.list, and since it's there it does:
mount -o bind ${mnt}/home/user ${root}/home/user
mount -o bind ${mnt}/var/cache/apt ${root}/var/cache/apt
where $root is what will become the filesystem root after
initramfs.
Say that we also have another persistent media that contains the
following .list:
/etc
/var
/home/user
* /etc would be mounted as above without any second thoughts since
there's no possible mount hiding.
* /var would have to be mounted before /var/cache/apt in order to
avoid getting one mount hiding the other. Note: if the same list
would include both, we'd only bind /var, i.e we'd just ignore the
children.
* /home/user is problematic, since hiding is unavoidable. Hence we'd
only use the one appearing on the device we scanned first, and
reject all consecutive ones.
Snapshots
---------
.list could also be used for all types of snapshots, working as a
"local" version of the currently available /etc/live-snapshot.list for
cpio.gz type snapshots. The "local" .list is more flexible than the
"gloabl" /etc/live-snapshot.list since the latter is *inside* the live
system and thus isn't modifiable (unless you create a new live image).
If there's good reasons for having a "global" .list, like
/etc/live-snapshot.list, we could keep it, and introduce a
/etc/live-overlay.list for overlays. And/or we could have a file
called /etc/live-persistence.list that handles both overlays and
snapshots. The question is then which .list:s take precedence over
which. I don't see any use for all this though, so unless someone has
a good use case I'd drop the /etc files completely and stick with just
"local" .list files for both overlays and snapshots.
Note: for snapshots the .list file wouldn't be limited to
directories but could also handle individual files. Overlays cannot
handle individual files as long as we rely on bind-mounting.
Backwards-compatibility
-----------------------
*If* we care for backwards-compatibility, we'd have to allow for an
optional extended syntax which allows specifying source-desination
pairs. To use a home-{rw,sn} partition/file that worked in an older
version of live-boot, the .list should look like this:
. /home
which translates to:
mount -o bind ${mnt}/. ${root}/home
so it would work exactly like before. If live-boot finds a
home-{sn,rw} partition/file, it could just create the above file,
making the backwards-compatibility completely transparent.
*If* we care for backwards-compatibility, we should also keep the
"global" /etc/live-snapshot.list, but then the precedence problem
mentioned in the "Snapshots" section needs to be resolved.
Attachment:
signature.asc
Description: OpenPGP digital signature