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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is prep for running inside (unprivileged) Kube containers
as they exist today: https://github.com/projectatomic/rpm-ostree/issues/1329
Sadly FUSE today uses a suid binary that ends up wanting CAP_SYS_ADMIN.
I think there's some work on FUSE-in-containers but I'm not sure of
the current status.
What rofiles-fuse here is doing here is protecting is the hardlinked
repo imports. But if `--cachedir` isn't specified, that repository
gets thrown away anyways. So there's no real value to using FUSE
here.
Also since nothing is cached, disable the devino cache.
We also make use of --force-copy-zerosized that just landed
in libostree: https://github.com/ostreedev/ostree/pull/1752
Down the line ideally we gain the capability to detect if either
unprivileged overlayfs/FUSE are available. Then if `--cachedir`
is specified we can make things work.
Closes: #1591
Approved by: jlebon
This is basically overriding what happens with `bare-user` mode
OSTree repositories. I put a lot of thought into avoiding creating
suid files with that mode.
But today this creates a situation where if we don't have a devino
cache, the file will lose its suid bits.
In the end, since we're using the "inaccessible directory" pattern
anyways for rpm-ostree on the host, we don't need to really worry
about transient suid binaries. And similarly when we're run inside
an existing container, that's also fine.
Closes: #1591
Approved by: jlebon
PR: https://github.com/projectatomic/rpm-ostree/pull/1562
AKA commit: a7bbf5bc14
introduced two regressions. First one for `compose tree`. The intention is
the default there is to *always* immediately check for updated
rpm-md - a bit like `yum clean expire-cache`. However due
to bugs in the stack we end up downloading it again anyways, but
that's not the topic here.
When we made that change we basically stopped using `DnfContext`'s
`cache_age`, which is what `compose tree` was setting.
Introduce a new explicit API to do what we want for `compose tree`.
Secondly, we were mistakenly always caching on the client
side.
This also fixes an issue that `--cache-only` didn't work, it basically
just made `compose tree` use the default `metadata_expire`. Now we
really don't expire it.
Closes: #1587
Approved by: jlebon
Now that we have `CUtf8`, let's just store the serialized JSON
as a string, owned by the Rust side. This way we can drop the
`serialized_treefile` buffer we were passing around and simplify
various bits of code. Most notably, we only serialize the JSON
once (via Serde) rather than also doing it again in the C side.
Closes: #1600
Approved by: jlebon
In preparation for running in default Docker permissions where
we can `chroot()` and `makedev()` but not e.g. create bind mounts,
move `/usr/etc` to `/etc` when running scripts.
The script processing is also entangled with our passwd/group
file handling, so change those functions called from the core too.
It's tempting to basically maintain `/usr/etc` as `/etc` all
the way from immediately after checkout to just before commit.
We can't change how we do imports now; perhaps importing
RPMs into ostree as `usr/etc` was just a mistake in retrospect,
but oh well.
Closes: #1592
Approved by: jlebon
Split out of supporting "pure rojig" work. We also want
to support this for doing "oscontainers" as is planned for
Red Hat CoreOS. The user experience in both cases is oriented
around versioning of the external wrapper, not the inner ref/commit.
Note for users/builders who want to make use of this feature:
You probably want to mirror the changes in our test suite here to
use the compose JSON and parse the resulting `ostree-commit` out of that.
Closes: #1603
Approved by: jlebon
This follows up to https://github.com/projectatomic/rpm-ostree/pull/1576
AKA commit 2e567840ca - we now process
treefile inheritance in Rust code. Previously for elements which
reference external files (`postprocess-script` and `add-files`)
we'd hardcoded things to only look in the first context dir.
Now we open file descriptors in the Rust side for these "externals"
as we're parsing, and load them C side. Hence we'll correctly handle
a `postprocess-script` from an included config.
Other advantages are that the include handling was ugly un-typesafe C code
with no unit tests, now it's memory safe Rust with unit tests.
The downside here is I ended up spelling out the list of fields
again - there's probably a way to unify this via macros but
for now I think this is OK.
Closes: #1574
Approved by: jlebon
It still takes a noticeable amount of time to stage a deployment, so
just give some feedback so we don't just hang there.
Closes: #1594
Approved by: cgwalters
Noticed these while perusing the codebase. We don't do anything in those
handlers, and they're optional, so just nix them.
Closes: #1594
Approved by: cgwalters
Make sure we can open and query the rpmdb when creating new deployments.
This should help filter out cases where somehow librpm failed to
actually write the rpmdb but didn't error out.
This requires splitting the sanity checking in two so that we still get
that nice error first on scripts that do `rm -rf`.
See: #1566Closes: #1584
Approved by: cgwalters
Following on to the previous change which added an explicit bind
mount API and also removed the API to append bwrap arguments, let's
also change the constructor to disallow the latter.
There was just one non-bind-mount argument being used
for "ro /var + tmpfs /var/tmp" - change that to an explicit new
API.
Looking at all of this, perhaps what we really want is to move
the "mutability" for `/var` underneath our API too, but let's
do this smaller incremental step first.
Closes: #1593
Approved by: jlebon
This is prep for adding a "backend" to this that uses just plain
`chroot` - we want things to avoid talking to bwrap's commandline
directly.
Closes: #1590
Approved by: jlebon
While debugging test failures in #1584, I was perplexed to find that the
ex-container tests didn't work on current git master. It turns out we
were only checking for one of the two possible error codes in the case
where we rename to a non-empty dir. So why is CI getting `EEXIST` while
locally I get `ENOTEMPTY`? Doing some diving kernel-side revealed it's
due to xfs vs tmpfs.
Closes: #1589
Approved by: cgwalters
Drop the `rpmostree.rpmdb.pkglist` keys from the deployment metadata
since users shouldn't need it and it greatly increases the size of the
output.
Closes: #1577
Approved by: cgwalters
In `--unified-core` mode, we would segfault if `selinux: true`
but no policy was found.
I hit this while hacking up the manifest for some Red Hat CoreOS
work.
Closes: #1578
Approved by: jlebon
The core bug here is that previously if we had multiple YAML files
in include, we ended up overwriting self->treefile_rs for the
last one. Handling inheritance worked, but it broke rojig since
we generate the specfile Rust side.
Let's have first-one-wins semantics for now. I have a bigger
fix incoming in https://github.com/projectatomic/rpm-ostree/pull/1574Closes: #1576
Approved by: jlebon
Currently `compose tree` supports writing to both an OSTree
repository and optionally simultaneously generating a rojig
RPM or rojig set.
We are instead going to split off a separate `compose rojig` verb,
since we want to support a "pure rojig" mode, and having all
3 options would make this code far too complex.
For now anyone who wants *both* formats can use `compose tree` then
follow up with `ex commit2rojig`.
This is also inline with the new coreos-assembler push, where
we'll treat `rpm-ostree compose` as more of a "low level" API,
and wrap it in a more opinionated model there.
Closes: #1570
Approved by: jlebon
In coreos-assembler I want to sort our builds by timestamp,
and having the ostree timestamp in the metadata is convenient.
Closes: #1569
Approved by: jlebon
Often, after rebooting from an upgrade, I want to check what was just
updated. This patch makes `db diff` do the right thing in those cases.
Specifically, before `db diff` without arguments would default to
diff'ing the pending deployment with the booted deployment and error out
otherwise. This patch extends the logic so that if there's a rollback
deployment, we default to diff'ing against that.
Closes: #1565
Approved by: cgwalters
Factor out a function for reading checksums from deployments and
printing their diffs. Also slightly rework the error-handling logic.
Prep for next commit.
Closes: #1565
Approved by: cgwalters
By the way `ostree_sysroot_query_deployments_for()` is defined, the
pending deployment is never the same as the booted deployment, so drop
that redundant check.
Closes: #1565
Approved by: cgwalters
Prep for adding a new toplevel rojig command. It's also just
cleaner to avoid cluttering up the main compose logic with
distractions like the `_legacy_prep_dev()` bits.
Closes: #1564
Approved by: jlebon
This completes the removal of externally-provided rojig spec files.
In the current flow then `compose tree --ex-rojig-output-*` will
end up parsing the manifest twice. But this is prep for defaulting
rojig to "pure" mode without a separate ostree repo. Then
anyone who wants to do both can run `commit2rojig` after.
Closes: #1561
Approved by: jlebon
Check if we can reuse the base rpmdb from the pending deployment if it
matches the base rev we're targeting. This allows us to avoid checking
out the tree early only to later on discard it. Such cases include
layering existing packages and inactive requests.
Closes: #1502
Approved by: cgwalters
Apparently I was just totally confused into thinking `OsStr`
was `NUL` terminated. I don't know where I got that idea
but a quick inspection of the Rust source code makes this
clear. I may submit a PR to the docs.
So we have two choices: allocate, or internally use a `NUL`-terminated
type. Let's just use `Box<CStr>` internally. Note I chose that
over `CString` as the latter is theoretically mutable, and when
passing data back over to C we don't have ownership/mutability
guarantees.
Closes: #1563
Approved by: jlebon
Prep for another patch. Some callers will need to know whether some
layers contain certain fixes before proceeding. We already have that
information handy so just expose it.
We should probably do something about that massive argument list... will
return to that at some point. But at least with the new base layer
accessor from the previous patch, there aren't many callers affected by
the added argument.
Closes: #1560
Approved by: cgwalters
In the majority of cases, we just want to know if a deployment is
layered and what the base commit is. Make a simpler accessor for this.
We can further simplify the logic on the client side here by relying on
the fact that there is only a base layer iif we're layered, so we don't
need two output variables.
I find it also makes things much easier to grok in some places, e.g. in
`rpmostreed-deployment-utils.c`, we now have:
const char *current_base_checksum = current_base_checksum_owned ?: current_checksum;
which better crystallizes what we want to get at.
Or e.g. in the sysroot upgrader, we can drop a comment which states
something that is now completely obvious.
Closes: #1560
Approved by: cgwalters
We only want to copy our own rpmdb to the base rpmdb location in the
server-side paths. OTOH, when creating layered commits client-side, we
want to make sure that we *don't* touch the base rpmdb location.
Accordingly, move the logic that does the hardlinking into
`postprocess_final`.
This can cause issues if we want to make use of the base rpmdb (as in a
forthcoming patch) of commits that were not created by a recent enough
rpm-ostree which inject the base rpmdb. When layering on such base
commits, we would unwittingly copy the new rpmdb (with the layered
packages) into the base rpmdb location. This then of course throws off
any logic that assumes the rpmdb at that location is from the base
layer.
There's a slight compatibility issue here: there are still older layered
commits out there where we did this and which might throw off new logic
that relies on this. We bump the clientlayer version so that we can just
check for that version to know whether it's safe to use the base rpmdb.
Closes: #1560
Approved by: cgwalters
This change gives an error when --arg is specified on its own.
Previously, if adding --arg without --enable, no changes occur and
only the initramfs regeneration status is printed. Since --arg only
takes effect when used with --enable, this should also give an error
(or let the user know in some way).
Closes: #1548
Approved by: jlebon
Previously, after enabling initramfs regeneration, the initramfs
command would indicate that initramfs regeneratin is disabled,
suggesting that the initramfs had not actually been enabled. This
happened because the initramfs regeneration status for the current
deployment was printed; initramfs regeneration is only enabled for a
pending deployment.
This change prints the regeneration for the pending deployment,
rather than the current, when no options are given to the initramfs
command.
Fixes: #1526Closes: #1548
Approved by: jlebon
This removes the logic around supporting opting out of the staging
feature. We don't want to support multiple configurations here, and at
this point, staging should be considered stable.
Closes: #1546
Approved by: cgwalters
This is [brown paper bag bug](http://www.catb.org/jargon/html/B/brown-paper-bag-bug.html)
for sure. But it's existed forever. Basically our recursion
when parsing `include:` ended up parsing the first included treefile
twice.
I noticed this with the new `postprocess` element - luckily
my script was idempotent. Historically we've gotten away with
this probably because the main thing is the `packages` array
and duplicates don't matter there.
Closes: #1552
Approved by: jlebon
Accumulate the list of requested packages that were not found and error
out with the full list rather than failing early. This fixes a small UX
papercut in certain situations.
Closes: #1540Closes: #1541
Approved by: cgwalters
Let's be more graceful here for people who `yum install rpm-ostree`
and expect magical[1] things to happen.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1537
[1] Understandably if one doesn't know lots of background
Closes: #1538
Approved by: cgwalters
For higher level tools driving rpm-ostree, the command line arguments
are mostly OK as inputs, but the addition of `--write-commitid-to`
shows that we really want structured data that these tools can parse.
JSON is a good enough interchange format, let's use that.
Most notably this does a pkgdiff in the JSON which several higher
level tools do too.
Closes: #1529
Approved by: jlebon
I'm splitting up coreos-assembler to have separate fetch/build
stages, with the first using `--download-only` and the second
using `--cache-only`, and the message from `fetch` is basically
wrong.
Closes: #1534
Approved by: jlebon
Just like the other ones from commit: 716b60b7d7
Yes, we probably should just patch the package but then
we'd have to wait for all of the koji/bodhi pain.
Closes: #1532
Approved by: sinnykumari
Prep for rojig-only compose support. We want to be able
to quickly detect whether or not there were changes in the
input, just like we do when targeting an OSTree repository.
Closes: #1528
Approved by: jlebon
If a `--workdir` was explicitly provided, we would pass `-1`
down into the Rust libs.
I found this while working on rojig-only which is reworking
the workdir bits.
Closes: #1528
Approved by: jlebon
If we're going to scale out our oxidation, let's follow
the path of Firefox (and other projects) further and use
cbindgen: https://github.com/eqrion/cbindgen
It's actually nice that `cbindgen` is packaged today in Fedora,
but I doubt it is elsewhere; we may end up needing to push
that forward, or just vendor it via a `build.rs` script and Cargo.
I chose to rename things to `ROR`/`ror_` since it's shorter. I
am tempted a bit to rename our internal functions to just `ro_` to
or so.
Closes: #1516
Approved by: jlebon
I'm trying to have a more opinionated model where custom builds
use inheritance, and currently one can only have a single
`postprocess-script`.
Further, in YAML it's very convenient to use inline vs external
data.
Closes: #1527
Approved by: jlebon
Per tile, added logic for sysusers_sorting. The comparison
for each sysuer_ent is like the following:
1: g > u > m for sysent_type and this takes precedence
2: if type matches, we compare the name for sysent using strcmp
3: If both type and name matches, we want to error out because it indicates a duplicate entry
Closes: #1519
Approved by: cgwalters
Adds function that interprets sysuser struct into usable string
content, which can later be used as content for `sysusers.d` files
Closes: #1519
Approved by: cgwalters
Similar to the passwd conversion, this commit
implements conversion of group entries into sysuser struct entries
Tests are also included in the commit
Closes: #1519
Approved by: cgwalters
Adds initial implementation of converting passwd entries(read from
/etc/passwd file) into sysuser_ent structs.
The converted sysuser_ent struct will then get tracked inside
a pointer array.
Closes: #1519
Approved by: cgwalters
This commit adds dir, geco and shell information to passwd_ent so
that they can be used later in sysusers section.
This also adds the sysuser_ent struct to track information of the
converted sysuser entries
For more information, please refer to https://github.com/projectatomic/rpm-ostree/issues/49Closes: #1519
Approved by: cgwalters
This teaches the client to fetch packages from URLs directly so that one
doesn't have to `curl` first and then install. Supported anywhere
package filenames are allowed (notably: `install` and
`override replace`).
One neat things about this is that we download the file into an
`O_TMPFILE` and then pass on ownership of that fd directly to the
daemon. So at no point are the packages actually laying visible on the
system. (Assuming the filesystem supports `O_TMPFILE` that is).
This adds direct linking to libcurl and openssl, two libraries which we
were already pulling in indirectly.
Closes: #1508
Approved by: cgwalters
This is for: https://github.com/projectatomic/rpm-ostree/issues/718
But I'm not going to close that issue as this only does the server
side, and I think we should support it client side too.
Since I wrote that issue, we ended up skipping the `dnf_transaction_depsolve()`
API, and hence we don't need to block on a libdnf change. So
this was quite simple.
Closes: #1513
Approved by: jlebon
This treats strs=NULL as an empty array and returns FALSE on the basis
that a string (str) is not contained in an empty array. If str == NULL,
then a run-time assertion will fail.
Previously, a segmentation fault occured when NULL was dereferenced,
expecting NULL to be handled by rpm_str_ptrarray_contains.
fixes#1494Closes: #1507
Approved by: jlebon
As something that manages your base operating system, we care
about reliability, predictability, as well as performance and
low-level access to native operating system facilities. The
C programming language is great for the latter two, but fails
at providing a truly memory-safe environment. Rust is fairly
unique in providing a language that doesn't carry a runtime,
so we can gradually "oxidize" and convert our C code without
imposing additional overhead. It's also got a lot of modern
design niceties, like not having a null pointer.
Let's pull the trigger here and hard require Rust. It's the
programming language I personally want to be primarily writing in for
years to come.
This is also in line with a recent trend of reducing our
experimental/optional matrix.
Closes: #1509
Approved by: jlebon
We've put a lot of work into staged deployments, it's time
to pull the trigger and turn them on by default. This is
a key step for enabling `stage` mode automatic updates by
default in e.g. Fedora CoreOS/Silverblue.
We add a new `--disable-staged` build-time option to flip
things back.
Closes: #1430
Approved by: jlebon
Staging fixes the `/etc` bug for livefs. There's actually more
we could do here around taking advantage of staging for livefs;
for example, I think once the livefs is complete, we could just delete
the staged deployment. And then we don't need to render on the next
boot the live status, etc.
Anyways, all that can come in the future. This is prep for
enabling staging by default.
Closes: #1430
Approved by: jlebon
Fix `--booted` was printing an extra line after `Deployments:`. While
we're there, also update the section name to `BootedDeployment:` in that
case to be more correct. (We're not printing all the deployments, only
the booted deployment.)
Closes: #1503
Approved by: cgwalters
Otherwise we risk rejecting perfectly valid treefiles. E.g.
fedora-atomic only defines packages in the `-base` file. Let's just move
the check to after having processed all the includes, right where we
collate packages from all the various entries.
The FAHC treecompose is hitting this right now.
Closes: #1500
Approved by: cgwalters
And don't mention "replace" in the error texts.
This is (now) known broken with kernel updates; making that not
dangerous isn't going to be easy. I debated entirely removing it
but for now let's just make it harder to use.
Ref: https://github.com/projectatomic/rpm-ostree/issues/1495Closes: #1497
Approved by: jlebon
Call `rpmtsSetRootDir()` even in the `JUSTDB` run. This brings us in
line with libdnf and the rpm CLI itself, which both unconditionally call
`rpmtsSetRootDir()` regardless of whether we're targeting the system
root or a subdir.
This doesn't cause a `chroot()` to happen since librpm only does this
if the target root dir is not `/`.
Related: https://bugzilla.redhat.com/show_bug.cgi?id=1613517Closes: #1492
Approved by: cgwalters
I noticed that the latest Fedora Atomic Host 28 and Silverblue did not
have an `OSTREE_VERSION` line in `/etc/os-release` even though both
specified `mutate-os-release` in their manifests. This turned out to be
due to the fact that `/usr/lib/os-release` is now a symlink to a
variant-specific file (e.g. `os-release-atomichost`), so we would
fallback to mutating `/usr/lib/os.release.d/os-release-fedora` instead.
Fix this by just taking the nuclear option of running `realpath` in the
rootfs directly. This is more maintainable than trying to keep up with
changes in variants/naming/etc. There's related discussions to this in
the original [PR](https://github.com/projectatomic/rpm-ostree/pull/410)
which introduced the feature re. resolving symlinks within the rootfs.
Closes: #1481
Approved by: jlebon
The `GSubprocess` API has a great `g_subprocess_communicate` function
that makes it easy to capture stdout and/or stderr. Let's expose that.
Closes: #1481
Approved by: jlebon
Rather than silently ignoring it.
In theory...we could write to /usr/lib/systemd instead of `/etc`
but eh...I feel like what we really want to do is make it convenient
to write a preset file from the YAML.
(We could have an `add-files` content that takes values literally
which would be nice in YAML and suck in JSON)
A general thread running through this is that for people making
*derivatives* of a CoreOS-like system, having to create their
own `exampleos-release` package is an annoying hurdle.
Anyways for now we're fixing the bug that we were silently ignoring
it.
Closes: #1488
Approved by: jlebon
The rojig spec is almost entirely rpm-ostree implementation details;
let's not have lots of people fork/duplicate it. Rather add the bits
of rojig to the treefile that people need to define (most notably
the name).
Prep for stabilizing rojig.
I had a few false starts with this PR; managing ownership/lifetimes
across C/Rust is just complicated. I got bit hard by the fact that
the workdir in `--unified-core` is really dfd-relative, and had to
do a dance to propagate the dfd into rust, as well as down into
the rojig builder.
Closes: #1484
Approved by: jlebon
We weren't actually transferring ownership of the error, which meant
that the error message was freed before we could even print it to the
user.
Closes: #1486
Approved by: cgwalters
Changing the process' working directory is evil in potentially
multi-threaded code, and at this point we really should be using
`openat()`/fd-relative bits most everywhere. But let's be
conservative and only stop doing it in `--unified-core` mode.
Closes: #1485
Approved by: jlebon
Newer librpm defaults to doing a full payload checksum, which we can't
do at this point (writing the db) because we imported the RPMs into
ostree commits, saving just the header in metadata - we don't have the
exact original content to provide again.
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1607223Closes: #1469
Approved by: jlebon
I think we have issues with librepo not handling being forcibly
interrupted; I saw an lzma error from what I think was a partial
download.
Let's add an error prefix here so this is easier to debug. I
think we used to have a prefix but lot it when we moved to async.
Closes: #1477
Approved by: jlebon
This is analogous to `upgrade --upgrade-unchanged-exit-77`, but for
`install`/`uninstall`. This way, one can determine whether the command
truly had an effect on the default deployment or not.
Since this works by comparing against the previous default deployment,
this works correctly even if we already had a pending deployment at the
beginning of the transaction.
Closes: #1478
Approved by: cgwalters
Add a new `install/uninstall --idempotent` option to make it easier to
interact with the CLI through scripts. E.g. one doesn't have to check
first if a request has already been installed/uninstalled.
Closes: #1467Closes: #1478
Approved by: cgwalters
This makes it easier for scripts to determine whether there is a pending
deployment instead of using `--json/--jsonpath`.
Closes: #1478
Approved by: cgwalters
In a later patch I'm going to add more API; basically rather
than doing the JSON parsing from C, we can add APIs to directly
access the treefile object. This also demonstrates how we
can do more extensive APIs, in particular implement an "object"
in Rust.
The ownership across the FFI boundary becomes nicer here too,
we don't need to do a dance with the fd.
For writing this I found
http://jakegoulding.com/rust-ffi-omnibus/objects/
quite useful, as well as
https://github.com/rust-lang/regex/blob/master/regex-capi/src/rure.rsCloses: #1474
Approved by: jlebon
Dusty hit this when working on Fedora CoreOS. IMO we don't need
to do the same for a future e.g. `fedora-release-silverblue` as
we don't support someone installing it on a non-ostree system.
(Note this all only really matters for `--unified-core` on the compose
side)
Closes: #1473
Approved by: jlebon
The `cached-update` variant would mark a bunch of RPMs as upgraded even
if they didn't actually change. The issue turned out to be we were doing
the diff all wrong in the staged deployment case. I'm not sure what I
was thinking in #1344, but essentially, we were marking all layered RPMs
in the staged deployment as updates instead of only marking those
layered RPMs which were actually changed EVR.
We just simplify the approach here by directly doing a pkglist diff
between the booted and staged deployments and consuming that. That's
really all there is to it! Reduces the code quite a bit too.
Closes: #1446Closes: #1455
Approved by: cgwalters
In line with the recent trend of marking things stable, and in
preparation for stabilizing `rojig://` - Let's stabilize the `--unified-core`
option for `compose tree`.
I'm not sure we could make it the default anytime soon; today it trips
over bugs in the PAM package in RHEL7 for example. But it
works fine for Fedora, and I think the code/design are good enough to be stable.
Closes: #1465
Approved by: jlebon
Follow up to: https://github.com/projectatomic/rpm-ostree/pull/1459
We now honor arch-specific packages in YAML, and reject unknown
architectures. I looked a little bit at how to avoid having hardcoded
arch lists, but it doesn't seem worth it right now.
Closes: #1468
Approved by: jlebon
Skip building man pages and HTML docs for our embedded libdnf to speed
up builds.
This bump also pulls in a fix to ensure we never try to install src
packages from `dnf_context_install()`.
See: https://github.com/projectatomic/libdnf/pull/3
Update submodule: libdnf
Closes: #1463
Approved by: jlebon
We're looking to embed an ostree commit inside a container image,
to make it easier to transport around with other images.
Conceptually here the host system is tracking a container (just
like for rojig we're tracking an RPM). This is the first step
towards making that support nicer; tooling can do
`rebase --custom-origin-url oscontainer://quay.io/exampleos@sha256:...`
and have that show up in `rpm-ostree status`.
There are two values, one intended to be machine readable (like
the `ostree://` and `rojig://` and one for humans which we
display when an admin types `rpm-ostree upgrade`.
This builds on prior work in
27bd7b97bb from #1396 .
Closes: #1406
Approved by: jlebon
Seeing a crash on in one of our builds, not sure yet what's
going wrong as I haven't gotten a core out, but this makes things
clearer.
($kingdom for `T`/`Option<T>` instead of nullable pointers...)
Closes: #1454
Approved by: jlebon
First, split it into its own section; it's important enough to merit it.
Second, explicitly reference the systemd timer/service units. For
example, a question I often have is "when is the next run" and of course
you can get that rpm `systemctl status rpm-ostreed-automatic.timer` but
you have to know that, and the reminder helps.
(I briefly looked at implementing the `Trigger` line from `systemctl status`
but it's not entirely trivial...tempting to just fork off a `systemctl status | grep `)
Prep for unifying this text with the message we print when one does
`rpm-ostree upgrade` when auto-updates are enabled.
Closes: #1432
Approved by: jlebon
It makes more sense to have the include live next to the associated
code, just like we do with C, even though the `cargo build` doesn't
touch it.
Closes: #1444
Approved by: jlebon
Use the new API introduced in
9131d8a4cc
which helps avoid relying on the magical deployment refs. I thought
this would help with a livefs+staging issue, but it doesn't. But we might
as well do it, it's adding another level of safety.
Closes: #1439
Approved by: jlebon
Follow up to #1434. I was testing this inside my test VM, which didn't
have a rollback deployment (i.e. it was just the staged deployment and
the booted deployment). Testing the upcoming release on my real system
showed that this wasn't correctly fixed.
Closes: #1437
Approved by: cgwalters
It doesn't make sense to rollback a staged deployment. Give a hint
instead to use `cleanup -p` if needed. Otherwise, we dump core later on
in libostree.
This is technically a breaking change once staged deployments become the
default. However, I think it makes sense overall. We'll have to make
some noise about it.
Closes: #1434
Approved by: cgwalters
A new update might not have any package changes at all. In which case,
we shouldn't even try to print the diff, otherwise we'll fail on trying
to lookup the `upgraded` key. We did this check already from
`rpmostree_print_cached_update`, but not from `print_one_deployment`
(when printing the diff as part of the pending deployment), so we'd
error out on no-diff upgrades.
Let's just inline a check in the function directly instead of wrapping
every call site.
Closes: #1431
Approved by: cgwalters
Add a new `reset` command that makes it easy to blow away all
customizations: overlays, overrides, and initramfs. One can use flags to
only reset some of the customizations.
I placed this under `ex` out of conservatism. It's a pretty simple
command with simple behaviour, though the features it relies on
(no-layering, no-initramfs) are brand new. We can move it out of there
in a release or two?
Closes: #1387Closes: #1419
Approved by: cgwalters
It's been in experimental for a while now, and we've had good feedback
that it's working. With #1392 fixed, it seems in a good position to
declare stable and commit to that API. This also helps empty out `ex` a
bit.
Closes: #1428
Approved by: cgwalters
Follow-up improvement after
https://github.com/openshift/os/pull/135
This should ensure it survives systemd's preset run on firstboot.
Although honestly...what we should *really* do is check whether
the `default.target` symlink target exists, and if not reset it
to `multi-user.target` so no one would have to care, but that'd
be conceptually separate from this, so I may do it later.
Closes: #1427
Approved by: jlebon
We actually want systemd's `ConditionFirstBoot` to fire. The
primary rationale here is that we're adopting Ignition for Fedora CoreOS,
and having `ConditionFirstBoot=` function will help a lot, as the idea
is it only runs once.
However, I discovered that this breaks the `units` directive for example,
as systemd blows away all the unit state in `/etc`. The correct thing
to do from the start is to use presets. We could add an implementation of
`units` which works with this on and instead writes a preset file but...eh.
My plan is to at some point introduce an "epoch" and flip various defaults,
this one, `tmp-is-dir`, the passwd file handling, etc.
See: https://github.com/dustymabe/bootengine/pull/11Closes: #1425
Approved by: jlebon
We added the `no-layering` option, but made it conflicting with
`--install`. This loosens that requirement so that one can do e.g.
rpm-ostree uninstall --all -install foobar
to essentially remove all layered packages and then add back `foobar`.
Prep for `reset` command.
Closes: #1424
Approved by: cgwalters
While looking at the inline help for `install`, I thought we could do
better by specifically stating that the `--uninstall` switch only
operates on layered packages. This might prevent any users from
trying to use the `--uninstall` switch on a package that is part of
the base deployment.
Closes: #1421
Approved by: jlebon
Kernel arguments added from `rpm-ostree ex kargs` can be lost
after doing multiple deploy related operations (e.g upgrade, install etc).
The root cause of that is because when doing the deployment
(ostree_sysroot_deploy_tree), the kernel arguments from the
pending deployment were never passed in.
This commit adds logic to pass in kernel arguments from pending deployment
to fix the above mentioned problem
Closes: https://github.com/projectatomic/rpm-ostree/issues/1392Closes: #1420
Approved by: cgwalters
A bunch of commands had descriptions for `--reboot` that were copied
from the `upgrade` description. Let's just make them all the same to
keep it consistent.
Closes: #1418
Approved by: cgwalters
Minor tweaks to try to clarify that the `install` and `uninstall`
commands are for managing an overlay. This should hopefully make it less
likely that someone tries `uninstall` when really they want
`override remove`.
Also drop the paragraph about having to specify NEVRAs for removing
local RPMs since that's no longer necessary.
Closes: #1418
Approved by: cgwalters
Fewer variables and avoid extra strdupv calls. I also fixed
handling of refspec canonicalization that I broke with a previous
change (we weren't actually setting `self->refspec` to the canonicalized
version).
Closes: #1414
Approved by: jlebon
I think this is what's showing up in a PR test:
21b68a68ff.2.1529072619059542132/artifacts/vmcheck/livefs.log
```
(rpm-ostree status:17017): Json-CRITICAL **: json_gvariant_serialize: assertion 'variant != NULL' failed
```
It shouldn't be happening; let's add an assertion which will give us a core
dump reliably instead of the "stumble on" `g_warning()` default.
Closes: #1416
Approved by: jlebon
It's just all-around simpler if we only parse the vardict
and avoid exploding everything into enums/parameters. Previously
we were converting the variant into parameters and flags, and
then in most cases converting the flags back into booleans!
This should make it easier to add new parameters.
Closes: #1412
Approved by: jlebon
We are having exact same function call between rpmostree_check_groups
and rpmostree_check_passwd, which means we are ignoring all the logic
for group checking.
This commit changes the option `passwd` to FALSE to also check for groups
during compose process.
Closes: #1413
Approved by: cgwalters
Minor regression from #1382. Since we no longer always include all the
option keys, we actually need to initialize the default values now.
Closes: #1410Closes: #1411
Approved by: cgwalters
This is one part of #1387 and is prep for a single higher level command
that makes it easier to remove all customizations (layering *and*
overrides).
Closes: #1408
Approved by: cgwalters
We were also counting the `NULL` element we added at the end of the
array when appending how many local installs we were doing. Fix this by
just reading the array length before adding the `NULL` terminator.
Closes: #1407
Approved by: cgwalters
We were previously relying on `!self->revision` to determine what
message to print in the no-op case. This made `override reset --all`
also print `No upgrade available.`.
Fix this by using the stronger `is_upgrade` instead.
Closes: #1407
Approved by: cgwalters
We were labeling pure `uninstall` transactions as `install`. Tease out
that distinction. (Though if a `--install` switch is passed, then we
still just label it as `install` -- there's no difference between that
and `install --uninstall` anyway).
Closes: #1407
Approved by: cgwalters
Doing `override reset --all` may be a no-op if there are no overrides
currently applied. But we were trying to always print the tree diff
under the assumption that all override invocations have to result in a
new deployment.
Fix this by using the same default deployment check that `upgrade` does
before printing.
Closes: #1407
Approved by: cgwalters
Follow to previous change; this should make it easier to add
a new parameter. It also just makes more sense to centralize
the parsing here.
Closes: #1403
Approved by: jlebon
Subsequent patches will move it down farther; the high level
goal is to avoid touching many functions to add a parameter.
Closes: #1403
Approved by: jlebon
This fixes a painful UX issue where one must use the full NEVRA when
uninstalling a locally layered RPM. Now, one can specify either the
NEVRA or the package name only. Though we still try to interpret the
request first as a NEVRA or a capability.
Closes: #1386Closes: #1400
Approved by: cgwalters
There are a few scenarios today where one might deliver content
to a machine via an external transport. For example, take the
scenario of a single server updated via USB drive. While we
can provide a refspec...what should the remote be? (This gets
into ostree collections). There's nothing really that can
happen when typing `rpm-ostree upgrade` unless the USB stick
is plugged in. That type of scenario should be emphasized
by pinning the commit - the machine is updated via an external
script.
Another case: we're experimenting embedding OSTree commits inside OCI
containers. Here again since rpm-ostree can't understand how to
pull content from containers, it's saner to drop the refspec
bits, and pin to a commit.
Further enhancements will follow to make the admin experience more
obvious.
Closes: #1396
Approved by: jlebon
We were missing a bunch of flags as part of the property GType. I was
getting a warning that's become fatal because we set
`G_DEBUG=fatal-warnings` for `make vmsync`, which is how I was testing
this:
```
rpm-ostree[1813]: value "((RpmOstreeSysrootUpgraderFlags) 48)" of type 'RpmOstreeSysrootUpgraderFlags' is invalid or out of range for property 'flags' of type 'RpmOstreeSysrootUpgraderFlags'
kernel: traps: pool[1816] trap int3 ip:7f47f4b4b6d5 sp:7f47e989d1f0 error:0 in libglib-2.0.so.0.5600.1[7f47f4af9000+115000]
```
I'm not quite sure why this is happening now though, since I use
`make vmsync` a lot. My guess would be something to do with how we
changed flag passing in d568e54d from "all of them" to "only those we
need", but I didn't verify that.
Closes: #1398
Approved by: cgwalters
When I initially added support for local RPM layering (#657), I was
operating under the assumption that there is no reliable way to parse a
NEVRA back to its constituent elements. So we worked around this by
doing lookups in the pkgcache and comparing against branches converted
back to their NEVRAs, which was pretty hacky.
Later on, I learned that you *can* reliably parse a NEVRA back to its
elements because RPM forbids all fields from having a colon `:` and all
fields other than the package name to have a dash `-`. In fact, there is
a helper from `libdnf` to do exactly this.
This patch swaps out the old way of decomposing NEVRAs and converting
NEVRAs to their cache branch notation with a simpler more direct
approach using the helper function from `libdnf`.
Closes: #1395
Approved by: cgwalters
Prep for later commit.
I hesitated between `rpmostree-util.c` and `rpmostree-rpm-util.c`. In
the end, I decided on the latter since some of the functions require
rpmlib headers, which aren't currently included in `rpmostree-util.c`.
Closes: #1395
Approved by: cgwalters
We're seeing a case where the change detection apparently isn't
working; let's log the hash we got so it's easier to debug.
Closes: #1393
Approved by: jlebon
For now all this switch does is turn off the scary warning. We also
tweak the warning to make it clear that this will be required in a
future release.
Closes: #1378
Approved by: cgwalters
Follow-up to previous commit. Rather than allocating and destroying
RefSacks multiple times, hoist it out of those blocks so it can be
re-used.
Closes: #1378
Approved by: cgwalters
This has been a huge point of confusion for users with the new
declarative way of specifying package requests (see #1216, #1287).
Essentially, doing `rpm-ostree install glibc` will work, but it's not
very useful because we don't really expect glibc to ever go away. As a
heuristic, let's work towards forbidding package requests that would
immediately become inactive. For now, we just print a warning.
Note that this still leaves the door open for layered pkgs that e.g.
become inactive during a rebase to a tree which has it baked in, and
then active again when rebasing back; supporting this was the major
advantage of switching to a declarative approach.
Closes: #1378
Approved by: cgwalters
Let's modernize and start supporting YAML treefiles. I'll dare make the
sweeping generalization that most people would prefer reading and
writing YAML over JSON.
This takes bits from coreos-assembler[1] that know how to serialize a
YAML file and spit it back out as a JSON and makes it into a shared lib
that we can link against. We could use this eventually for JSON inputs
as well to force a validation check before composing.
If we go this route, we could then turn on `--enable-rust` in FAHC for
now and drop the duplicate code in coreos-assembler.
[1] https://github.com/cgwalters/coreos-assemblerCloses: #1377
Approved by: cgwalters
In the middle of adding yet another parameter to
`rpmostree_get_options_variant`, it dawned upon me that we weren't
gaining much from making it its own function. Just generating the
GVariant inline seems much cleaner since (1) we only actually have to
insert keys for values we want to specify, rather than always specifying
default `FALSE` values, and (2) the fact that the key name is right
there makes it self-documenting and thus doesn't require a bunch of
comments on the side.
Closes: #1382
Approved by: jlebon
With the new support for pinning deployments, we need to also update
rpm-ostree to clean up the transient state as is now done in the ostree
sysroot upgrader.
This addresses that issue as well as tries to be a little cleaner in how
we clean up other transient state. Notably, we add a new helper function
to `RpmOstreeOrigin` to do this for us and use it in the upgrader. In
other cases, we do want this transient information since it allows us to
describe the deployment.
Closes: https://github.com/ostreedev/ostree/issues/1595Closes: #1372
Approved by: cgwalters
This makes the logs a bit more useful, but the ultimate goal
here is to write the originating client `id` to the cached update
data, so users know that e.g. `gnome-software` triggered it.
Closes: #1368
Approved by: jlebon
The high level goal is to render in a better way what caused an
update: https://github.com/projectatomic/rpm-ostree/issues/247#issuecomment-386615707
This gets us for Cockpit:
`Initiated txn DownloadUpdateRpmDiff for client(dbus:1.28 unit:session-6.scope uid:0): /org/projectatomic/rpmostree1/fedora_atomic`
which isn't as good as I'd hoped; I was thinking we'd get `cockpit.service`
but actually Cockpit does invocations as a real login for good reason.
We get a similar result from the CLI.
Closes: #1368
Approved by: jlebon
Following up to https://github.com/projectatomic/rpm-ostree/pull/1352
AKA 506910d930
which added an experimental flag to globally enable deployment
staging, let's add an `ex-stage` automatic update policy.
I chose to create a new `test-autoupdate-stage.sh` and rename
the previous one to `test-autoupdate-check.sh` in going with
the previous theme of smaller test files; it's
way faster to iterate on new tests when it's a new file. And adding
staging at the top would have been weird.
This was all quite straightforward, just plumbing through lots
of layers.
Closes: #1321
Approved by: jlebon
The common case is having layered packages and no overrides; seeing
`Applying 8 overlays` then `Building filesystem [0/8]` is redundant.
Tweak the progress to avoid the double message. Also change the terminology
to clarify that each item is a package.
Also update libglnx to pull in progress bar newline fix.
Update submodule: libglnx
Closes: #1363
Approved by: jlebon
The `status --verbose` output is getting quite long now that we print
repo information and diffs. Let's add a switch for only making
advisories more verbose so that it's easy to get more information
without having to use `-v` and scroll up if the diff is massive.
Closes: #1350
Approved by: cgwalters
Follow-up from #1344.
In the case where a cached update is created from an `upgrade` operation
(and soon, "stage" auto-update policy runs), we can just print the diff
and advisory info together with the pending deployment. This makes the
output look much more natural.
Closes: #1350
Approved by: cgwalters
In #1344, we changed `upgrade` to always write the cached update. One
thing I hadn't noticed was that with pkglayering, loading the sack twice
meant we printed all that gory repo info twice.
Really, the much nicer thing to do is just to make an effort to try to
*keep* the original sack that the core used so that we skip all that
overhead completely.
Closes: #1357
Approved by: cgwalters
It just makes the sack more useful for other purposes this way. Callers
can just use `download_metadata` directly if they'd like to override
this. Prep for a follow-up patch.
Closes: #1357
Approved by: cgwalters
Prep for printing this info as part of the deployments. I also snuck in
a small fix so that we don't print the `Diff:` line if there's no diff
(e.g. it's a no-op update).
Closes: #1357
Approved by: cgwalters
In https://github.com/cockpit-project/cockpit/pull/9090#issuecomment-386564044
we're seeing:
`Txn DownloadUpdateRpmDiff ... failed: open(O_TMPFILE): No such file or directory`
Looking at the error paths in the rpmdb diff code, there's not really
any error prefixing. Let's add some so this is easier to debug.
Closes: #1356
Approved by: jlebon
I was hitting an error during sysroot loading while playing
with deployment staging, and it wasn't initially
clear which phase was causing it (a client-initated reload versus
one we do before or after deploying). Add some error prefixing.
Closes: #1355
Approved by: jlebon
Now that infrastructure for this has landed in libostree,
let's make it easy for people to opt-in to testing it. This is a distinct first
step for adding it as an update policy.
Closes: #1352
Approved by: jlebon
