Skip to content

Commit

Permalink
Merge pull request #3168 from cgwalters/drop-tmpfiles-var
Browse files Browse the repository at this point in the history
Drop tmpfiles var
  • Loading branch information
cgwalters authored Feb 12, 2024
2 parents c8cf230 + 6df18ab commit 15b4ee8
Show file tree
Hide file tree
Showing 3 changed files with 38 additions and 65 deletions.
70 changes: 38 additions & 32 deletions docs/var.md
Original file line number Diff line number Diff line change
Expand Up @@ -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/container 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.
Expand All @@ -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.
4 changes: 0 additions & 4 deletions src/boot/ostree-tmpfiles.conf
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,3 @@
d /run/ostree 0755 root root -
# https://github.com/ostreedev/ostree/issues/393
R! /var/tmp/ostree-unlock-ovl.*
# Automatically propagate all /var content from /usr/share/factory/var;
# NOTE: This is now considered a mistake, and will likely be reverted.
# As of OSTree 2024.3, content from the initial deployment is used.
C+! /var - - - - -
29 changes: 0 additions & 29 deletions tests/kolainst/destructive/var-tmpfiles.sh

This file was deleted.

0 comments on commit 15b4ee8

Please sign in to comment.