ostree/tests/kolainst/destructive/deployment-lint

#!/bin/bash
set -xeuo pipefail

. ${KOLA_EXT_DATA}/libinsttest.sh

require_writable_sysroot
prepare_tmpdir

mkdir -p rootfs/var/testcontent
ostree commit -b testlint --no-bindings --selinux-policy-from-base --tree=ref="${host_refspec}" --consume --tree=dir=rootfs
ostree admin deploy testlint 2>err.txt
assert_not_file_has_content err.txt 'Deploying commit.*which contains content in /var/testcontent'
test '!' -d /var/testcontent
echo "ok deploy var"

ostree admin stateroot-init newstatedir
ostree admin deploy --stateroot=newstatedir testlint
ls -al /sysroot/ostree/deploy/newstatedir/var
test -d /sysroot/ostree/deploy/newstatedir/var/testcontent

echo "ok deploy var new stateroot"
deploy: Warn if we find content in the deployment's /var This will be ignored, so let's make it very clear people are doing something wrong. Motivated by a bug in a build pipeline that injected `/var/lib/rpm` into an ostree commit which ended up crashing rpm-ostree because it was an empty db which it wasn't expecting. It also turns out rpm-ostree is incorrectly dumping content in the deployment `/var` today, which is another bug. 2021-06-09 09:44:09 -04:00			`#!/bin/bash`
			`set -xeuo pipefail`

			`. ${KOLA_EXT_DATA}/libinsttest.sh`

			`require_writable_sysroot`
			`prepare_tmpdir`

sysroot: Rework /var handling to act like Docker `VOLUME /var` 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. 2024-02-09 14:44:43 -05:00			`mkdir -p rootfs/var/testcontent`
deploy: Warn if we find content in the deployment's /var This will be ignored, so let's make it very clear people are doing something wrong. Motivated by a bug in a build pipeline that injected `/var/lib/rpm` into an ostree commit which ended up crashing rpm-ostree because it was an empty db which it wasn't expecting. It also turns out rpm-ostree is incorrectly dumping content in the deployment `/var` today, which is another bug. 2021-06-09 09:44:09 -04:00			`ostree commit -b testlint --no-bindings --selinux-policy-from-base --tree=ref="${host_refspec}" --consume --tree=dir=rootfs`
			`ostree admin deploy testlint 2>err.txt`
sysroot: Rework /var handling to act like Docker `VOLUME /var` 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. 2024-02-09 14:44:43 -05:00			`assert_not_file_has_content err.txt 'Deploying commit.*which contains content in /var/testcontent'`
			`test '!' -d /var/testcontent`
			`echo "ok deploy var"`

			`ostree admin stateroot-init newstatedir`
			`ostree admin deploy --stateroot=newstatedir testlint`
			`ls -al /sysroot/ostree/deploy/newstatedir/var`
			`test -d /sysroot/ostree/deploy/newstatedir/var/testcontent`

			`echo "ok deploy var new stateroot"`