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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Add a helper function for whitespace_split_packages() so that it now
splits a String by whitespace only if it is not wrapped between single
quotes.
This should allow RHCOS to use syntax like podman > 1.4 in the treefile.
Also add new unit tests and tweak existing compose tests to test this
functionality.
Both `upgrade` and `deploy` already support this. There's no reason why
all the remaining "deployment-creating" commands shouldn't. Prompted by
https://github.com/openshift/machine-config-operator/issues/1897 which
will need this specifically for `rebase`.
The latest crypto-policies package changed recently to dynamically set
the policy at install time so that if FIPS is enabled, the selected
backend is `FIPS`:
9b9c9f7378
This doesn't really make sense for us though since the compose server
configuration should be decoupled from the installroot. (More generally,
this also affects e.g. `yum install --installroot`).
Override the script for now so that we always select the `DEFAULT`
policy. We'll discuss with upstream to see what the right solution is
there.
This also works around the fact that rpm-ostree doesn't yet implement
Lua (#749).
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1847454
Resolves: https://github.com/coreos/fedora-coreos-tracker/issues/540
Now that cosa and FCOS have moved to f32, a bunch of tests are breaking.
Let's make them more resistant to releasever changes.
While we're here though, bump the container image we use on the target
host to f32, and update the systemd example output.
Switch to the "installed" model introduced by:
https://github.com/coreos/coreos-assembler/pull/1441
It's hard to support running tests *both* from the srcdir
and installed; in this case because we have a symlink that needs
to be followed, which kola knows how to do from the srcdir
but not when installed. Let's establish a new convention of
`tests/kolainst`. In our case we follow the symlink manually
for now.
That bit will be cleaned up when we eventually switch entirely
to kola tests.
Same motivation as
7392259332
I think we should encourage removing the writable bits from
executables. This has happened to me:
https://thomask.sdf.org/blog/2019/11/09/take-care-editing-bash-scripts.html
And not having the writable bit may help prevent hardlink
corruption with OSTree in some cases.
We can't do this by default, but add a convenient treefile option
for it.
This starts out by just doing this for RPMs, but I'll add
a secondary pass which does it during postprocessing soon too.
The main goal here is to get `assert_jq()` usable in
kola tests.
This was forked from ostree long ago but we aren't
using most of it. I want to try to move this into kola where
we're just using `tests/common` but this code references
`tests/gpghome` which we weren't using.
Only a few things here reference `SRCDIR` - change those
to fail for now if it's not set, since we're not running
those tests in kola yet. I will eventually try to
clean that up later.
Pre-FCOS we made an effort for automatic updates but nowadays
with Fedora CoreOS we generally expect people to be using zincati.
Until we fix the "agent registration" problem:
https://github.com/coreos/rpm-ostree/issues/1747
Let's not confuse people by printing `AutomaticUpdates: disabled`.
Only print if it's set to a value in non-verbose mode.
In Fedora CoreOS, we have a "coreos-pool" repo from which all packages
in lockfiles are tagged for reproducible builds. This repo is shared
across all streams, including those on f31 and f32.
Thus, it makes no sense for composes to ever pick packages unconstrained
from the pool without being guided by a lockfile. Otherwise, one can
easily end up with e.g. f32 packages in an f31 compose.
Add a new `lockfile-repos` for this which is only used for fetching
lockfile packages and nothing else. For example, this will allow
`cosa fetch --update-lockfile` to Just Work as expected by only fetching
new packages from regular yum repos.
Today, lockfiles only restrict the NEVRA of specifc package names from
which libsolv can pick. But nothing stops libsolv from picking entirely
different packages which still satisfy the manifest requests.
This was mostly a theoretical issue in Fedora CoreOS, but became reality
with the addition of Fedora 32 packages in the pool. libsolv would
happily try to pick e.g. `libcurl-minimal` from f32 instead of sticking
with the f31 `libcurl` from the lockfiles:
https://github.com/coreos/fedora-coreos-streams/issues/75#issuecomment-610734584
(But more generally, see
https://github.com/coreos/fedora-coreos-tracker/issues/454).
Let's add a `--ex-lockfile-strict` mode, which in CI and production
pipeline build contexts will require that (1) *only* locked packages are
considered by libsolv, and (2) *all* locked packages were marked for
install.
One important thing to note here is that we don't short-circuit libsolv
and manually `hy_goal_install` lockfile packages. We want to make sure
the treefile is still canonical. Strict mode simply ensures that the
result agrees with the lockfile.
That said, even in developer contexts, we don't want the
`libcurl-minimal` issue that happened to be triggered. But we still want
to allow flexibility in adding and removing packages to make hacking
easier. I have some follow-up patches which will enable this.
We need to be friendlier to people who are transitioning from
"traditional" yum managed systems. This patchset starts to lay
out the groundwork for supporting "intercepting" binaries that
are in the tree.
For backwards compatibility, this feature is disabled by default,
to enable it, one can add `cliwrap: true` to the manifest.
To start with for example, we wrap `/usr/bin/rpm` and cause it
to drop privileges. This way it can't corrupt anything; we're
not just relying on the read-only bind mount. For example nothing
will accidentally get written to `/var/lib/rpm`.
Now a tricky thing with this one is we *do* want it to write if
we're in an unlocked state.
There are various other examples of binaries we want to intercept,
among them:
- `grubby` -> `rpm-ostree kargs`
- `dracut` -> `rpm-ostree initramfs`
- `yum` -> well...we'll talk about that later
The garbage collection issue should be fixed now, and it's just nicer on
developers' cache to stay on the same commit. And again, it's a nice
sanity-check to know that we're always able to compose an older tree.
That said, we probably should still bump this from time to time.
While we're here, add some comments for making it easier to match `popd`
calls with the original `pushd`.
Start the ball rolling on converting some of our tests into
the coreos-assembler/kola framework:
d940420b78/mantle/kola/README-kola-ext.md
The nondestructive ones are easy.
This way we handle filenames with spaces in `/var` in general,
like `/var/app/foo bar`, but *also* the special `/opt/foo bar`
translation bits.
I saw this bug and thought "oh that'd be easy". But hoo boy
did it take me down a rat's nest. The first thing was verifying
that `systemd-tmpfiles` supports any kind of quotation/escaping; it does.
The next thing was figuring out *exactly* what the syntax for that
is and how it works, as it's obviously not widely used.
Writing tests for this ended up being a painful exercise because
of the multiple levels of shell script, e.g. our `build_rpm` shell
script ends up being inlined into RPM specs, which then interprets
again...and not to mention the usual annoying issues with `ssh`
eating quotes.
Anyways, all that and:
Closes: https://github.com/coreos/rpm-ostree/issues/2029
We need to adapt some of our tests here which assume that `/sysroot` is
writable. However, in FCOS this is no longer the case now that we enable
`sysroot.readonly`.
We only remount rw for the couple of operations that need it so that we
still retain coverage for the ro path everywhere else.
This is the second half of the previous commit. We check if the
canonical dracut args are available in the commit metadata, and prefer
those over using `--rebuild`. The latter is delegated as a backcompat
fallback.
It's the latest, and matches the rest of the host we're running on. But
also, pulling f30 is hitting 503s from the Fedora registry:
https://pagure.io/releng/issue/9282
We're hitting issues with packages getting tagged out of the pool:
https://pagure.io/releng/issue/9281
This in turn means we can't reliably recompose older builds right now,
which breaks our CI. For now at least, let's compose from the latest.
(Note we were already also composing the latest FCOS in the vmcheck
branch.)
Instead of basing our decision to use the local `/etc` on whether we're
using `dracut --rebuild`, base it directly on a boolean parameter.
This is relevant in the client-side when initramfs regeneration is
requested as well as a kernel override. In such cases, we do want to use
the local `/etc`, but we'd skip that path because we didn't also use
`dracut --rebuild`.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1806588
This fixes a longstanding spew of error messages from the initramfs
because we don't have nss-altfiles set up there. Rather than
trying to do it, just do the dance of re-synthesizing `/etc/passwd`
as it traditionally looks around running dracut, the same as we
do for scripts during core layering.
Yes, this is all a mess and hopefully I'll get to sysusers soon...
In FCOS we have a kola test that basically does `rpm -q python`.
It's...a bit silly to spawn a whole VM for this. Ensuring that
some specific packages don't get included has come up in a few
cases.
I think FCOS/RHCOS at least will want to blacklist `dnf` for example.
And as noted above, FCOS could blacklist `python`.
One major benefit of doing this inside rpm-ostree is that one
gets the full "libsolv error message experience" when dependency
resolution fails, e.g. blacklisting `glibc` I get:
```
Problem 79: conflicting requests
- package coreos-installer-systemd-0.1.2-1.fc31.x86_64 requires coreos-installer = 0.1.2-1.fc31, but none of the providers can be installed
- package coreos-installer-0.1.2-1.fc31.x86_64 requires rtld(GNU_HASH), but none of the providers can be installed
- package glibc-2.30-10.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-7.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-8.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-5.fc31.i686 is filtered out by exclude filtering
- package glibc-2.30-5.fc31.x86_64 is filtered out by exclude filtering
- package glibc-2.30-10.fc31.i686 is filtered out by exclude filtering
```
Translate RPM paths under `/var/run` to `/run` automatically; this
quiets down systemd. Since we end up running `systemd-tmpfiles`
a few times in FCOS reducing spew here is particularly valuable.
The bug is really in the packages here but...we don't have an
agile process for fixing them.
Note that for this fix to take effect, if you have a `cache/pkgcache-repo`
you'll need to remove it.
We were basing whether to print the `Upgraded`/`Downgraded` heading on
the iteration count rather than the actual first iteration where a valid
upgrade/downgrade was found. And because of how we print our diff, this
confusingly can make it look like downgrades are part of the same
upgrade section.
Closes: #1821
This is a follow-up hack to #1797 to force libdnf to let us use modular
packages as if they were regular packages until we actually support
modules correctly (#1435).
A repo marked as a modular hotfix means that libdnf doesn't try to
filter out modular RPMs from the repo as it usually does.
Resolves: https://pagure.io/releng/failed-composes/issue/717
Again, a lot going on here, but essentially, we adapt the compose tests
to run either privileged or fully unprivileged via supermin, just like
cosa.
I actually got more than halfway through this initially using `cosa
build` directly for testing. But in the end, we simply need more
flexibility than that. We want to be able to manipulate exactly how
rpm-ostree is called, and cosa is very opinionated about this (and may
also change from under us in the future).
(Another big difference for example is that cosa doesn't care about
non-unified mode, whereas we *need* to have coverage for this until we
fully kill it.)
Really, the most important bit we want from there is the
unprivileged-via-supermin bits. So we copy and adapt that here. One
obvious improvement then is sharing this code more easily (e.g. a
`cosa runasroot` or something?)
However, we still use the FCOS manifest (frozen at a specific tag). It's
a realistic example, and because of the lockfiles and pool, we get good
reproducibility.
There's a lot going on here, but essentially:
1. We change the `vmcheck` model so that it always operates on an
immutable base image. It takes that image and dynamically launches a
separate VM for each test using `kola spawn`. This means we can drop
a lot of hacks around re-using the same VMs.
2. Following from 1., `vmoverlay` now takes as input a base image,
overlays the built rpm-ostree bits, then creates a new base image. Of
course, we don't have to do this in CI, because we build FCOS with
the freshly built RPMs (so it uses `SKIP_VMOVERLAY=1`). `vmoverlay`
then will be more for the developer case where one doesn't want to
iterate via `cosa build` to test rpm-ostree changes. I say "will"
because the functionality doesn't exist yet; I'd like to enhance
`cosa dev-overlay` to do this. (Note `vmsync` should still works just
as before too.)
3. `vmcheck` can be run without building the tree first, as
`tests/vmcheck.sh`. The `make vmcheck` target still exists though for
finger compatibility and better meshing with `vmoverlay` in the
developer case.
What's really nice about using kola spawn is that it takes care of a lot
of things for us, such as the qemu command, journal and console
gathering, and SSH.
Similarly to the compose testsuites, we're using parallel here to run
multiple vmcheck tests at once. (On developer laptops, we cap
parallelism at `$(nproc) - 1`).
This is a hack to allow using `inject-pkglist` without having to build
the tree first.
Higher-level, I think we can split this back out again if we have a
`-tests` subpackage where we ship the vmcheck testsuite.
This allows replacing the `.` in automatic version increments
with whatever one wants (as long as it's a single ASCII character)
right now.
The specific motivation here is for at least RHEL CoreOS to use
`version-suffix: "-"` so that its versions can become valid
semantic versions.
Related: https://github.com/coreos/rpm-ostree/issues/1954
E.g. the generation timestamp, repos that were enabled, and their
generation timestamps.
This is just generally useful, though I'd like to make use specifically
of the new `metadata.generated` key in FCOS to drive versioning:
https://github.com/coreos/fedora-coreos-releng-automation/pull/50
All this does is put the immutable bit on the target directory.
The intention is to replace this bit to start:
8b205bfbb9/src/create_disk.sh (L229)
However, the real goal here is to add code in this file
to handle redeploying the rootfs for Fedora CoreOS which
combines OSTree+Ignition:
https://github.com/coreos/fedora-coreos-tracker/issues/94
Basically doing this in proper Rust is going to be a lot
nicer than shell script in dracut modules. Among other
details, coreutils `mv` doesn't seem to do the right thing
for SELinux labels when policy isn't loaded.
This is the rpm-ostree equivalent of `dnf history`. As opposed to the
history of the refspec (i.e. `ostree log`), this shows the history of
the system, i.e. the refspecs the host deployed, checksums, versions,
layered packages, etc... The amount of details remembered is similar to
what shows up in `status`.
There's definitely some further enhancements possible (e.g. printing
package diffs, displaying rollbacks), though this seems in good enough
shape as a first cut.
Closes: #1489Closes: #1813
Approved by: cgwalters
This has a bit of history, but essentially in 1c01141e, we made both
`upgrade` and `deploy` automatically exit 77 if there were no changes.
Then in c3f1e7c8, we only changed `upgrade` so that it became gated
behind `--upgrade-unchanged-exit-77`.
I think we should carry this forward into `deploy` as well. The way I
look at this is: the default UX shouldn't require users to care about
special exit codes. That's something scripts care about. In its vanilla
form, either a command should error out or succeed.
This patch tries to add some consistency by introducing a new
`--unchanged-exit-77` in both `deploy` and `upgrade` (where it just
replaces the previous switch). The naming here matches what `install`
has too.
So... this does break backwards compatibility for any scripts which
relied on that behaviour. Though the only app I know today which wants
deploy semantics and doesn't use the D-Bus API is Zincati, which
actually hit this issue. There's also RHCOS, though the `pivot` there
uses `rebase`, not `deploy`. So overall, I think this is worth breaking
now while we're still in a transitionary period in the downstreams?
Closes: #1906
Approved by: cgwalters
This is one of the tests right now that assumes it's running on f29.
We might be sort of in this awkward dual path for a while where we want
tests to run on both f29 (i.e. FAH) and f30 (i.e. FCOS).
Closes: #1900
Approved by: cgwalters
