IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
We've long struggled with semantics for `/var`. Our stance of
"/var should start out empty and be managed by the OS" is a strict
one, that pushes things closer to the original systemd upstream
ideal of the "OS state is in /usr".
However...well, a few things. First, we had some legacy bits
here which were always populating the deployment `/var`. I don't
think we need that if systemd is in use, so detect if the tree
has `usr/lib/tmpfiles.d`, and don't create that stuff at
`ostree admin stateroot-init` time if so.
Building on that then, we have the stateroot `var` starting out
actually empty.
When we do a deployment, if the stateroot `var` is empty,
make a copy (reflink if possible of course) of the commit's `/var`
into it.
This matches the semantics that Docker created with volumes,
and this is sufficiently simple and easy to explain that I think
it's closer to the right thing to do.
Crucially...it's just really handy to have some pre-existing
directories in `/var` in container images, because Docker (and podman/kube/etc)
don't run systemd and hence don't run `tmpfiles.d` on startup.
I really hit on the fact that we need `/var/tmp` in our container
images by default for example.
So there's still some overlap here with e.g. `/usr/lib/tmpfiles.d/var.conf`
as shipped by systemd, but that's fine - they don't actually conflict
per se.
I want to try to get away from the "repository global" configuration
in the repo config.
A major problem is that there's not an obvious way to configure
it as part of an ostree commit/container build - it needs
to be managed "out of band".
With this change, we parse the `usr/lib/ostree/prepare-root.conf`
in the deployment root, and if composefs is enabled there,
then we honor it.
We do still honor `ex-integrity.composefs` but that I think
we can schedule to remove.
When we added composefs, it broke the logic for detecting the booted
deployment which was previously a direct (device, inode) comparison.
So the code there started looking at `etc`. However, that in
turns breaks with `etc.transient = true` enabled.
Fix all of this by tracking the real deployment directory's
(device,inode) that we found in `ostree-prepare-root`, and inject
it into the extensible metadata we have in `/run/ostree-booted`
which is designed exactly to pass state between the initramfs
and the real root.
Signed-off-by: Colin Walters <walters@verbum.org>
Currently when writing data for selinux systems on a non-selinux
system there will be no labels. This is because
`ostree_sepolicy_setfscreatecon()` just returns TRUE on non-selinux
systems and xattr writing for `security.seliux` is filtered out.
This patches uses the suggestion of Colin Walters (thanks!) from
https://github.com/ostreedev/ostree/issues/2804 and detects if
the host has selinux enabled and if not just skips filtering the
xattrs for selinux.
I've been testing this in various places and not seen any fallout,
so let's finally enable this by default and have the situation where
`/boot` is on the root `/` filesystem work out of the box.
In CoreOS live environments, we do have `/run/ostree` but no `ostree=`
karg; we hackily fool `ostree-prepare-root.service` by bind-mounting
over `/proc/cmdline` so it does the right thing. Presumably, we should
clean this up eventually, but even so we don't want to require PXE users
to add an `ostree=` arg, so we need to tolerate this.
So this assertion would fail there. Restore the behaviour prior to
b9ce0e89 and re-add a more contemporary comment.
Fixes b9ce0e89 ("generator: Exit if there's no `/run/ostree`").
This backend always explicitly emitted a `/boot` - but if
the global `sysroot.bootprefix` is enabled, then we can rely
on the outer code doing it.
Luckily this was caught by the unit tests here failing when
enabling `sysroot.bootprefix` by default.
This generates the new format for whiteout markers which was added in
6.8 (and which will be backported to 6.7). Without this whiteouts
will not work anymore.
This is a slight format change, but will only affect ostree commits
that already were broken (i.e that had whiteouts), and since the
composefs code is still marked experimental I think it is fine to
do this without introducing another format version on the ostree
side.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
Add new commands to pin the current, staged and previous deployment for
use in automation and scripting. Right now, it's difficult to pin the
current deployment without needing to look into the output of some other
tooling (like rpm-ostree) to get the index of each deployment. This
index also is not consistent - the current deployment could be 0 when
you first boot the system then 1 shortly after. This change makes it
easy to pin the current or future deployment.
Co-authored-by: Robert Sturla <robertsturla@outlook.com>
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
Currently if run in a container image under systemd, we will
incorrectly synthesize a `var.mount` unit even if `ostree-prepare-root`
hasn't run.
The comment here said why we didn't do that before, but that's
for the really legacy embedded-only "ostree-prepare-root-static"
path, and even then I'm pretty sure it was wrong because
the generator here only runs in the *real* root, and we should
have `/run/ostree` at that point.
Otherwise, this test fails on Debian 12 (Linux 6.1) kernels if /var/tmp
is a tmpfs. Some autobuilders put the entire build chroot on a tmpfs,
to speed up builds.
Signed-off-by: Simon McVittie <smcv@debian.org>
It's a followup of commit e6a560b407.
We should also ignore sockets and fifos in the subdir of /etc.
Signed-off-by: Yuanhong Peng <yummypeng@linux.alibaba.com>
In the OSTree model, executables go in `/usr`, state in `/var` and
configuration in `/etc`. Software that lives in `/opt` however messes
this up because it often mixes code *and* state, making it harder to
manage.
More generally, it's sometimes useful to have the OSTree commit contain
code under a certain path, but still allow that path to be writable by
software and the sysadmin at runtime (`/usr/local` is another instance).
Add the concept of state overlays. A state overlay is an overlayfs
mount whose upper directory, which contains unmanaged state, is carried
forward on top of a lower directory, containing OSTree-managed files.
In the example of `/usr/local`, OSTree commits can ship content there,
all while allowing users to e.g. add scripts in `/usr/local/bin` when
booted into that commit.
Some reconciliation logic is executed whenever the base is updated so
that newer files in the base are never shadowed by a copied up version
in the upper directory. This matches RPM semantics when upgrading
packages whose files may have been modified.
For ease of integration, this is exposed as a systemd template unit which
any downstream distro/user can enable. The instance name is the mountpath
in escaped systemd path notation (e.g.
`ostree-state-overlay@usr-local.service`).
See discussions in https://github.com/ostreedev/ostree/issues/3113 for
more details.
This is a tool to check if we are booted as default or not, just a
rename before it becomes widely used. We also shortened the '-h' output
for this.
Signed-off-by: Eric Curtin <ecurtin@redhat.com>
