Want an option for transient /etc #2868
Comments
|
Note another example of a file (well a symlink), that may want to be added or unadded to early /etc: This was a feature added to do non-rootfs updates at a very early point in the boot, i.e. a firmware upgrade. Just another feature to consider, even if it clashes, I'm sure we could figure something out. /etc was chosen as a location for the symlink as it's one of the earliest mounted rw persistent directories that exists, maybe it's as simple as moving the location of this symlink or treating it exceptionally somehow like /etc/machine-id or /etc/resolv.conf |
cgwalters
added a commit
to cgwalters/ostree
that referenced
this issue
Jul 29, 2023
In preparation for support for a transient `/etc`: ostreedev#2868 particularly in combination with composefs. Basically it's just much more elegant if we can directly mount an overlayfs on the *empty* `etc` directory, using `usr/etc` as the lower. In the composefs case, we'd have to mount the composefs overlayfs itself writable (and call `mkdir`) *just* so we can make that empty `etc` directory which is ugly.
|
Some WIP for this in #2970 |
Closed
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Oct 2, 2023
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
|
This was fixed by #3062 |
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Oct 24, 2023
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Oct 24, 2023
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Oct 24, 2023
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Oct 24, 2023
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
cgwalters
added a commit
to cgwalters/rpm-ostree
that referenced
this issue
Oct 24, 2023
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
cgwalters
added a commit
to coreos/rpm-ostree
that referenced
this issue
Oct 25, 2023
Depends on ostreedev/ostree#3063 This is intended for use with ostreedev/ostree#2868 but is conceptually orthogonal to it; we probably want to try switching to this by default actually.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
For the automotive usecase, and for the general extension of the composefs work (#2867) it would be nice to have a mode where /etc is mounted as an overlayfs on top of /usr/etc from the commit and a tmpfs directory (say in /run). This way you can have a system that is validated by composefs, where you cannot persist system changes between boots.
In theory this should not be very complex, but my initial experiments ran into some issues with selinux contexts which need to be resolved.
In addition, there are some files that we really want to per persist in /etc that are host machine specific. In particular, the
machine-idfile. This would have to be solved by copying in it from some persistent location during early boot.Additionally, and vaguely related:
In the automotive project we are interested in being able to extend the system dynamically, but in a controlled fashion. In particular, we want to install container images and add systemd service files, but only for a trusted set of apps. Such service files would have to be persisted in /etc/systemd/system, but allowing files to be added there is very risky. The plan we have for this is to have a systemd generator that copies these files from a persisted location, after having verified that they are all signed (for example, using fs-verity signatures) against a trusted key.
For full chain of trust, this also needs a container image backend using composefs, which is also in the works.
The text was updated successfully, but these errors were encountered: