Record original OS version in the image somewhere #170
Comments
|
When we get rid of anaconda for building the images in COSA we can easily implement this, correct? I guess even with anaconda we can implement this easily. We just need to decide where to store the info and what format? Another thing to consider is coreos/rpm-ostree#1489 . We might just be able to use that. |
I've been working on this in the background and should have something up soon. Though the way I've been designing it, we're essentially piggy-backing on the systemd journal for tracking history, which eventually gets pruned. I guess we could special-case the first boot ever so it's retained forever, though it seems easier/more foolproof to just have e.g. a |
ahh didn't realize it wasn't something that was going to persist forever |
which makes me wonder.. should we have a separate place where we store that information (in addition to the journal) that doesn't get pruned? Probably not, but thought i would ask |
|
https://www.freedesktop.org/software/systemd/man/tmpfiles.d.html#f could be used to create it on first boot then not touch it afterwards. By using tmpfiles we also don't need to carry extra logic/code. |
Yeah, I was discussing this with @lucab this morning. It seems like it comes down to what the history is for. My main goal was to help people trace their machine history and be useful for debugging issues. How useful is history from 2 years ago? I can imagine different requirements for audit-style logging though. E.g. we could log an audit event on every boot with the OSTree commit details? So... dunno. Neither CL nor FAH had this, so I'm inclined to just not do that until a need shows up? |
|
Also https://url.corp.redhat.com/c04429a |
|
Thoses urls do not seems to be public, that's not great for a transparency point of view :/ |
It will be very useful in the future to be able to more rigorously know the state that a given machine *started* from. For example, small tweaks like `chattr +i /sysroot` are things that won't happen for in-place updates. The term "aleph" here means "start". If we decide to introduce a mechanism (e.g. systemd unit) that performs those changes even for old in-place installs, it could be useful to know exactly what the starting state was. Note this ends up in the *physical* storage root `/` which appears as `/sysroot` when booted. Closes: coreos/fedora-coreos-tracker#170
|
Also in fedora-coreos-pinger, we are recording original OS version: coreos/fedora-coreos-pinger#30 |
It will be very useful in the future to be able to more rigorously know the state that a given machine *started* from. For example, small tweaks like `chattr +i /sysroot` are things that won't happen for in-place updates. The term "aleph" here means "start". If we decide to introduce a mechanism (e.g. systemd unit) that performs those changes even for old in-place installs, it could be useful to know exactly what the starting state was. Note this ends up in the *physical* storage root `/` which appears as `/sysroot` when booted. Closes: coreos/fedora-coreos-tracker#170
It will be very useful in the future to be able to more rigorously know the state that a given machine *started* from. For example, small tweaks like `chattr +i /sysroot` are things that won't happen for in-place updates. The term "aleph" here means "start". If we decide to introduce a mechanism (e.g. systemd unit) that performs those changes even for old in-place installs, it could be useful to know exactly what the starting state was. Note this ends up in the *physical* storage root `/` which appears as `/sysroot` when booted. Closes: coreos/fedora-coreos-tracker#170
For upgrade handling and metrics, we should be sure to record the original OS version (when the node was first installed) somewhere in the image. Container Linux calls this the
aleph-version.The text was updated successfully, but these errors were encountered: