[systemd-devel] the need for a discoverable sub-volumes specification

[Topi Miettinen]

On 9.11.2021 23.03, Lennart Poettering wrote:
> On Di, 09.11.21 19:48, Topi Miettinen (toiwoton at gmail.com) wrote:
> 
>>> i.e. we'd drop the counting suffix.
>>
>> Could we have this automatic versioning scheme extended also to service
>> RootImages & RootDirectories as well? If the automatic versioning was also
>> extended to services, we could have A/B testing also for RootImages with
>> automatic fallback to last known good working version.
> 
> At least in the case of RootImage= this was my implied assumption:
> we'd implement the same there, since that uses the exact same code as
> systemd-nspawn's image dissection and we definitely want it there.
> 
> Doing this RootDirectory= would make a ton of sense too I guess, but
> it's not as obvious there: we'd need to extend the setting a bit I
> think to explicitly enable this logic. As opposed to the RootImage=
> case (where the logic should be default on) I think any such logic for
> RootDirectory= should be opt-in for security reasons because we cannot
> safely detect environments where this logic is desirable and discern
> them from those where it isn't. In RootImage= we can bind this to the
> right GPT partition type being used to mark root file systems that are
> arranged for this kind of setup. But in RootDirectory= we have no
> concept like that and the stuff inside the image is (unlike a GPT
> partition table) clearly untrusted territory, if you follow what I am
> babbling.

My images don't have GPT partition tables, they are just raw squashfs 
file systems. So I'd prefer a way to identify the version either by 
contents of the image (/@auto/ directory), or something external, like 
name of the image (/path/to/image/foo.version-X.Y). Either option would 
be easy to implement when generating the image or directory.

But if you have several RootDirectories or RootImages available for a 
service, what would be the way to tell which ones should be tried if 
there's no GPT? They can't all have the same name. I think using a 
specifier (like %q) would solve this issue nicely and there wouldn't be 
a need for /@auto/ in that case.

> Or in other words: to enable this for RootDirectory= we probably need
> a new option RootDirectoryVersioned= or so that takes a boolean.

Wouldn't this be unnecessary, if the version magic would be available 
explicitly as specifier to the path of RootDirectory= or RootImage=? 
Then we know that the configuring user made this decision.

-Topi