On 11.11.2021 19.27, Lennart Poettering wrote:
On Mi, 10.11.21 10:34, Topi Miettinen (toiwoton@xxxxxxxxx) wrote:
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.
Hmm, so thinking about this again, I think we might get away with a
check "/@auto/ exists and /usr/ does not". i.e. the second part of the
check removes any ambiguity: since we unified the OS in /usr it's an
excellent way to check if something is or could be an OS tree.
That said: naked squashfs sucks. Always wrap your squashfs in a GPT
wrapper to make things self-descriptive.
It would be an extra step in image making process. I think naming the
images '*.squashfs' documents them well enough for me.
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.
A specifier is resolved at unit file load time only. It wouldn#t be the
right fit here, since we don#t want to require that the paths
specified in RootDirectory=/RootImage= are already accessible at the
time PID 1 reads/parses the unit file.
Well, that's out then.
What about this: we could entirely independently of the proposal
originally discussed here teach RootDirectory= + RootImage= one magic
trick: if the path specified ends in ".auto.d/" (or so) then we'll not
actually use the dir/image as-is but assume the path refers to a
directory, and we'd pick the newest entry inside it as decided by
strverscmp().
Or in other words, we'd establish the general rule that dirs ending in
".auto.d/" contains versioned resources inside, that we could apply
here and everywhere else where it fits, too.
of course intrdocuing this rule would be kind of a compat breakage
because if anyone happened to have named their dirs like that already
we'd suddenly do weird stuff with it the user might not expect. But I
think I could live with that.
A patch for that should be pretty easy to do, and be very generically
useful. I kinda like it. What do you think?
Yes, that could work. I'd need to rename the LVM VG to 'levy.auto.d'
(maybe instead create a new VG just for these images) and the directory
too but that's no problem.
-Topi
