-
Notifications
You must be signed in to change notification settings - Fork 305
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This reorients things here around the latest `VOLUME /var` approach.
- Loading branch information
Showing
1 changed file
with
38 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -26,54 +26,43 @@ because this is more resilent. | |
|
||
Even better, use `StateDirectory=` for systemd units. | ||
|
||
### ostree container /var | ||
|
||
Some earlier versions of the ostree-container stack migrated content in `/var` | ||
in container images into `/usr/share/factory/var` (per below). This has | ||
been reverted, and the semantics defer to the above ostree semantic. | ||
|
||
## Previous /var handling via /usr/share/factory/var | ||
## Pitfalls | ||
|
||
As of OSTree 2023.8, the `/usr/lib/tmpfiles.d/ostree-tmpfiles.conf` file gained this snippet: | ||
On subsequent upgrades, normally `/var` would not be empty anymore | ||
(as it's typically expected that basics like `/var/tmp` etc. are created, | ||
if not also other local state such as `/var/log` etc.). Hence, | ||
*no updates* from the commit/container will be applied. | ||
|
||
```text | ||
# Automatically propagate all /var content from /usr/share/factory/var; | ||
# the ostree-container stack is being changed to do this, and we want to | ||
# encourage ostree use cases in general to follow this pattern. | ||
C+! /var - - - - - | ||
``` | ||
To be clear then: | ||
|
||
This is inert by default. As of version 0.13 of the ostree-ext project, content in `/var` in fetched container images is moved to `/usr/share/factory/var`. This is no longer recommended. | ||
- Any files which already exist will *not* be updated. | ||
- Any files which are deleted in the new version will not be deleted on existing systems. | ||
|
||
Together, this will have the semantic that on OS updates, on the next boot (early in boot), any new files/directories will be copied. For more information on this, see [`man tmpfiles.d`](https://man7.org/linux/man-pages/man5/tmpfiles.d.5.html). | ||
## Examples | ||
|
||
However, `tmpfiles.d` is not a package system: | ||
### debs/RPMs which drop files into `/opt` (i.e. `/var/opt`) | ||
|
||
## Pitfalls | ||
The default OSTree "strict" layout has `/opt` be a symlink to `/var/opt`. | ||
Including any packaged content that "straddles" `/usr` and `/var` (i.e. `/var/opt`) | ||
will over time cause drift because changes in the package will not be reflected on disk. | ||
|
||
- Large amounts of data will slow down firstboot while the content is copied (though reflinks are used if available) | ||
- Any files which already exist will *not* be updated. | ||
- Any files which are deleted in the new version will not be deleted on existing systems. | ||
For situations like this, it's strongly recommended to enable either | ||
`composefs.enabled = true` or the `root.transient = true` option for `ostree-prepare-root.conf` | ||
and change ensure your commit/contianer image has `/opt` as a plain directory. In the former case, | ||
content in `/opt` will be immutable at runtime, the same as everything else in `/usr`. | ||
In the latter case content it will be writable but transient. | ||
|
||
## Examples | ||
There's also a currently-experimental [../man/[email protected]]([email protected]) | ||
which can manage stateful writable overlays for individual mounts. | ||
|
||
### Apache default content in `/var/www/html` | ||
|
||
The `tmpfiles.d` model may work OK for use cases that wants to treat this content as locally mutable state. But in general, such static content would much better live in `/usr` - or even better, in an application container. | ||
In general, such static content would much better live in `/usr` - or even better, in an application container. | ||
|
||
### User home directories and databases | ||
|
||
The semantics here are likely OK for the use case of "default users". | ||
|
||
### debs/RPMs which drop files into `/opt` (i.e. `/var/opt`) | ||
|
||
The default OSTree "strict" layout has `/opt` be a symlink to `/var/opt`. | ||
However, `tmpfiles.d` is not a package system, and so over time these will slowly | ||
break because changes in the package will not be reflected on disk. | ||
|
||
For situations like this, it's recommended to enable the `root.transient = true` option for `ostree-prepare-root.conf` | ||
and change your build system to make `/opt` a plain directory. | ||
|
||
### `/var/lib/containers` | ||
|
||
Pulling container images into OSTree commits like this would be a bad idea; similar problems as RPM content. | ||
|
@@ -83,3 +72,20 @@ Pulling container images into OSTree commits like this would be a bad idea; simi | |
For $reasons dnf has its own database for state distinct from the RPM database, which on rpm-ostree systems is in `/usr/share/rpm` (under the read-only bind mount, managed by OS updates). | ||
|
||
In an image/container-oriented flow, we don't really care about this database which mainly holds things like "was this package user installed". This data could move to `/usr`. | ||
|
||
## Previous ostree /var and tmpfiles.d /usr/share/factory/var | ||
|
||
From OSTree versions 2023.8 to v2024.3 the `/usr/lib/tmpfiles.d/ostree-tmpfiles.conf` file included this snippet: | ||
|
||
```text | ||
# Automatically propagate all /var content from /usr/share/factory/var; | ||
# the ostree-container stack is being changed to do this, and we want to | ||
# encourage ostree use cases in general to follow this pattern. | ||
C+! /var - - - - - | ||
``` | ||
|
||
Until version 0.13.2 of the ostree-ext project, content in `/var` in fetched container images is moved to `/usr/share/factory/var`, but this no longer happens when targeting ostree v2024.3. | ||
|
||
Together, this will have the semantic that on OS updates, on the next boot (early in boot), any new files/directories will be copied. For more information on this, see [`man tmpfiles.d`](https://man7.org/linux/man-pages/man5/tmpfiles.d.5.html). | ||
|
||
This has been reverted, and the semantics defer to the above ostree semantic. |