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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
There are a lot of use cases for this, notably:
- This allows us to display advisories without fetching updateinfo
metadata in the pure OSTree case.
- It allows pipelines to fetch and display this information to
sanity-check builds.
- It makes it much easier to fix the "intermediate CVEs" issue described
in https://github.com/coreos/rpm-ostree/issues/1696#issuecomment-443861107.
This patch just adds the advisory information to the commit metadata.
There's follow-up work to make the client-side of rpm-ostree use this
data.
Also, remove the newly added metadata from the output of `rpm-ostree
status --json` for the same reason we remove the rpmdb. A follow-up
patch will teach `rpm-ostree db list/diff` to output advisories.
Closes: #1696
This removes some JSON-handling helper methods which are not used
anymore. All the consumers have been moved to directly use the
treefile logic in Rust in the meanwhile.
I did at one point look at converting this stuff into a C++
object but that led in to a whole rathole around a C++ `GObject<>`
smart pointer like glibmm has. But that would take over the code
and it's better to just port to Rust.
In general our error handling philosophy is "errors are strings".
Previously (before C++) we were relying on calling this API
to strip out the GDBus remote error message.
In the recent refactoring of clientlib to expose the txn APIs
to Rust via C++, we implicitly lost that because the C++
wrapper API throws an exception.
Add a copy of the remote error stripping here. Eventually
it will likely make sense for it to *only* be here instead
of also in `main.cxx`, but one thing at a time.
Port away from a generic child setup function towards more standard
APIs for setting up fd streams. Prep for oxidizing rpmostree-bwrap.cxx
because cxx-rs doesn't support passing callbacks from C++ to Rust.
Right now if we want to lock e.g. systemd, we need to specify every
subpackage of systemd that we use. This is a lot of duplication because
in the majority of cases, what we really mean is "lock at this build of
systemd".
Since RPMs bake in the source RPM they were built from, we can use this
to lock packages more succinctly. See the testcase and #2676 for
examples of how this looks.
Closes: https://github.com/coreos/rpm-ostree/issues/2676
This moves the users/groups validation logic to Rust, taking care of
all the treefile check-passwd/check-groups knobs.
As all the passwd-handling logic has been ported to Rust, it also
drops the stale C source/headers/imports.
Prep for porting rpmostree-bwrap.cxx to Rust; cxx-rs doesn't
expose passing a function pointer from C++ to Rust. There's
a simpler API for this anyways.
Install a copy of rpm-ostree as rpm-ostree-unpriv to get a `bin_t`
labeled binary as a temporary workaround for:
https://bugzilla.redhat.com/show_bug.cgi?id=1937404
Also modify the rpm-ostree count me service to use that binary.
* Use OnBootSec=5m to give a chance for the timer to trigger on the
first week the system is booted up.
* Use '1s' for AccuracySec as this is accurate enough for this use
case.
It's a bit silly to have a two bridged functions here; instead
have just a single one on the C++ side that calls multiple
on the Rust side.
Prep for moving more to Rust.
This code really makes sense as a method on the treefile.
And when that's done, we no longer need to expose
`get_postprocess_script()` via cxx, so we can return a nicely
Rust native `Option<&mut File>`.
Port add-files handling to Rust.
Note that there's one very magical line of diff here worth calling out:
We dropped an interface from the cxxrs bridge, because both sides
are now Rust! The treefile code can directly return an `&mut File` reference
instead of needing to pass the raw fd as `i32`.
The ugly C code for this turns into shorter Rust with a unit
test, a lot less allocation (notice how we don't malloc `NUL` terminated
strings in so many places).
I don't like the use of `HY_GLOB` in the lockfile package matching. We
have all the information in the Rust object, so it's silly to condense
that to a single string in a hashmap.
Fix this by returning the `LockfileConfig` object itself and then adding
a function to fetch the list of locked packages. This allows the C++
side to see all the individual fields which makes filtering trivial.
The next step is moving all the code which needs the lockfile to Rust.
Then we can drop the shared `LockedPackage` type.
(I did start on converting `find_locked_packages`, though it requires
adding bindings for all the `HyQuery` stuff, which... isn't great (and
also runs into the fact that `hy_query_run` needs to return a
GPtrArray). I think instead of a 1:1 mapping, we'll probably want the
libdnf-sys API wrappers to provide some sugar for the common paths.)
In FCOS, we use "override" lockfiles to pin packages to certain
versions. Right now, we have separate overrides for each base arch we
(eventually want to) support. But that makes maintaining the overrides
cumbersome because of all the duplication.
Let's allow lockfiles to specify only the `evr` of a package, which is
just as good for FCOS, and means that we'll only have to maintain a
single override file for all the architectures.
Prep for more oxidation work. One notable improvement here is that about half
of the callers of the mega function `rpmostree_deployment_get_layered_info`
only wanted the base information, not the layered package lists
for example - so we were passing 4 `NULL`s to ignore those.
This Rust API returns a simple shared struct instead for those
cases. I also changed things so that `base_commit` is always
set, avoiding the callers needing to do that.
OK I think it's time. This exposes the `apply-live` functionality
as implicitly stable, but specific to the package install case.
I'd like to add more intelligence to `apply-live` around separating
pure "additions" (as in this case) versus package (file) changes.
The change here doesn't try to do that; the implementation is
incredibly simple, we just have the client chain together the two
distinct transactions.
It's always nice when apps provide useful hints about other commands you
may be interested in.
For instance, if they've done `rpm-ostree override replace/remove`,
let's be helpful and tell users that they can use `rpm-ostree override
reset` to unpin packages.
This adds sufficient infrastructure to fully port the
`rpmostree-builtin-applylive.cxx` client code to Rust.
We just keep a stub entrypoint for now until we port
the rest of `rpmostree-builtin-ex.cxx`, at which point
a lot of C++ files go away.
The "finish" bits move from the daemon-oriented `live.rs`
into a new `rust/src/builtins` directory. I'd like
to try to more cleanly split up the Rust sources along
core(shared)/client/daemon directories in the future.
This stubs out sufficient infrastructure for us to register
as a client and call the Moo API.
A glaring problem here is the lack of extensive `glib::Variant`
bindings; that's covered in the next gtk-rs release.
My real goal was to try porting the `rpmostree-builtin-apply-live.cxx`
code entirely to Rust, but there's more to do to expose the
transaction helper APIs we have.
We have fully transitioned to cxx-rs! This drops a lot of now
dead code; only one binding system to think about generating
source code. For example, a notable advantage of cxx-rs
is it doesn't scan the whole source code, so running `make`
doesn't spew errors from cbindgen not understanding bits.
cxx-rs only supports a few basic types in `Vec<T>`/`CxxVector<T>`
and we need to pass an array of GObjects in a few cases.
Add a wrapper class hack instead of using `u64` so we at least
have some basic safety here and have a convenient place to
grep for later when we want to improve this.
This moves the `ror_lockfile_write` to cxx.rs, which brings us closer to
getting rid of cbindgen now.
There's one massive hack this uses, which is that we pass an array of
pointers to `DnfPackage` and `DnfRepo` objects as u64. We'll want to
circle back and fix that up once either cxx.rs supports natively arrays
of pointers, or we just come up with our own wrapper type for it.
But for now at least, this unblocks the cbindgen transition and hacking
on the lockfile code.
Instead of passing the pid back up the stack and using a cleanup
function on it to invoke `kill()`, use `PR_SET_PDEATHSIG` which
has the kernel take care of this for us.
(In practice we don't actually use this peer functionality anymore
because all of the client/daemon code kind of requires being run under systemd
on a real system now)
This shrinks the API surface and is much less repetitive in
the codebase.
Prep for moving more of the CLI code to Rust.
The refspec code really needs to be cleaned up and oxidized (and
unit tested more).
The original intention is that if you're pinned to a commit, we say
"No upgrade available" but we were crashing if one (understandably)
rebased to the combination of `remote:checksum` instead of just `checksum`.
But, we can't change the classifier to call this `CHECKSUM` and
output an error, because that just conflicts with us accepting
the syntax `rpm-ostree rebase :<checksum>`.
I'm actually coming around to the idea that this `remote:checksum` syntax means
"no upgrade available" is correct, whereas pinning to just `checksum`
is more of an error when you try to upgrade.
Closes: https://github.com/coreos/rpm-ostree/issues/2603
I was looking at a different problem and noticed a spam of
```
Feb 24 23:06:37 cosa-devsh rpm-ostree[1099]: g_variant_dict_ref: assertion 'is_valid_heap_dict (dict)' failed
Feb 24 23:06:37 cosa-devsh rpm-ostree[1099]: g_variant_dict_unref: assertion 'is_valid_heap_dict (dict)' failed
Feb 24 23:06:37 cosa-devsh rpm-ostree[1099]: g_variant_dict_ref: assertion 'is_valid_heap_dict (dict)' failed
Feb 24 23:06:37 cosa-devsh rpm-ostree[1099]: g_variant_dict_unref: assertion 'is_valid_heap_dict (dict)' failed
```
in the journal. It turns out that the Rust bindings try to call
`g_variant_ref()`, but that's (understandably) not allowed on
a stack allocated instance.
Since we heap allocate a *ton* here, let's just heap allocate
the dict too.
Now, we also along the way stopped using the bits to inject
```
[Service]
Environment=G_DEBUG=fatal-warnings
```
in our CI. I'll look at that as a followup.
Install the systemd unit, timer and sysusers configuration for Count Me
support. We do not enable or pull as a dependency those units by default
as this is a decision that should be taken at the distribution level and
needs support on the infrastructure side.
To enable those units in a disctribution package, you can add the
following symlink:
$ ln -snf /usr/lib/systemd/system/rpm-ostree-countme.timer /usr/lib/systemd/system/rpm-ostreed.service.wants/
or add the following config snippet to the rpm-ostreed.service unit:
Wants=rpm-ostree-countme.timer
If the systemd unit associated with the client's PID is the updates
driver's unit, don't require the --bypass-driver option for operations
like upgrade, deploy, and rebase.
This is useful for updates drivers that shell out to rpm-ostree's
binary (e.g. Zincati, currently).
Also refactor some helper functions to make them more general and
reusable.
Follow up to https://github.com/coreos/rpm-ostree/pull/2566.
Error out if users try to manually do a deploy/rebase if an updates
driver is registered. Provide `--bypass-driver` option to proceed
anyway.
Following https://github.com/coreos/rpm-ostree/pull/2566, we would
like to give other commands (deploy and rebase) the same treatment.
Factor out functions to retrieve systemd unit docs and a function
that detects updates drivers so they can be reused elsewhere.
Came out of discussion in https://github.com/coreos/rpm-ostree/pull/2581
around some racy code for checking for the live commit object.
The reliability of apply-live depends on the
underlying commits not being garbage collected. Our diff logic
is in terms of ostree commits, not the physical filesystem (this
allows us to make various optimizations too).
Ultimately I think we should drive some of the live-apply
logic into libostree itself; we can more easily have an atomic
state file instead of the two split refs.
(Or perhaps what we should add to ostree is like a refs.d model
where a single atomic file can refer to multiple commits)
For now though let's rework the code here to write refs. We
retain the file in `/run` as just a "stamp file" that signals
that a deployment has had `apply-live` run.
More prep for https://github.com/coreos/rpm-ostree/pull/2388
This was actually also my first time really trying out the
latest gtk-rs `glib::Variant` API, which is one of the major
things we need to use to progress oxidation more.
This moves passwd/group compose preparation logic to Rust,
dropping all the remaining minor helpers related to JSON parsing,
file stream creation, and entries deduplication.
A lot of our output is outside of a "task"; the Rust binding
incorrectly made it a method on `Progress`. This is really
just a `println!()` that is backed by our dispatch system.
Set `Persistent=yes` in the timer unit to make sure that systems that
are not running 24/7 gets counted when they wake up if they missed the
previous timer run / counting window.
This is mostly for Fedora Silverblue and IoT like systems as Fedora
CoreOS systems usually run 24/7.
https://www.freedesktop.org/software/systemd/man/systemd.timer.html#Persistent=
Changes to this ad-hoc `a{sv}` code have been scattered
around over time. Move the "core" bits to the top of
the function, then have the more complex stuff that depends
on the origin (and refspec/layering status) later.
Prep for further cleanups.
When we started using cxxrs, most of the glib-rs objects like
`OstreeRepo`/`OstreeSysroot` were owned by C++ and passed
down into Rust. That motivated the addition of the special
bridging infrastructure to re-create a glib-rs wrapper
type from what cxxrs wants (a `Pin<&mut T>`).
But now that we're adding more in Rust, we have the need
to pass these objects back into C++. In fact this will
hopefully soon because the default case as more of the
binary entrypoint becomes Rust.
Add another trait with a method `gobj_rewrap()` that converts
in the other direction. This implementation took me a number
of tries before I finally settled on simply using `mem::transmute()`.
There are a *lot* of caveats listed on the docs for that function,
but I think it really is what we want here. See the link for pending work
on a Rust RFC to enable safe transmutes for some cases, and I believe
that would cover this use case:
https://internals.rust-lang.org/t/pre-rfc-v2-safe-transmute/11431
I've verified this works in a separate patch, but this commit
also adds a simple test case - this goes all the way from:
Rust glib-rs `ostree::Repo` (holding strong ref)
-> Rust `Pin<&mut ostree_sys::OstreeRepo>`
-> (internal cxx-rs C bridge)
-> C++ `OstreeRepo&` reference
-> C `OstreeRepo*` pointer
Which is quite the dance if you think about it!
Do not perform an upgrade if detected that an updates driver has
been registered.
Add --bypass-driver option to force an upgrade regardless of whether an
updates driver has been registered.
This is actually a perfect example of the tradeoffs involved
in our team of C/Rust programmers trying to use C++ so we
can use cxx-rs =)
It turns out that "for (auto foo : bar)" is really yet another
one of those C++ sharp edges just waiting to cut. That
version does a copy of each value; one almost always wants to use
"for (auto & foo : bar)" which like Rust's `.iter()`.
In most of our code we were OK making copies, they were just
a performance hit, but in another place I was relying on the
"side effect" of `.c_str()` but that meant our value got
destroyed.
Pretty straightforward. Haven't moved `ror_lockfile_write` yet because
that's trickier to do and I'm still figuring out the most elegant way to
do this within cxx.rs' constraints.
We don't need it and it won't work in the unprivileged path where we're
running this in a cosa supermin (of course, this is all a bit silly
because we don't actually need privileges to begin with for this, but
there's a lot of momentum in sticking with that workflow).
Update submodule: libglnx
Now that we inject the `%_dbpath /usr/share/rpm` macro, `rpm -q`
will start using it. But in RPM script invocation, we don't
want them to see any RPM database at all - trying to query it
should be a clean failure.
Follow-up to previous commit: we had another path where we made a
temporary rootfs and symlinked `/var/lib/rpm` to the base rpmdb. That of
course broke now that we inject a macro to point the rpmdb to
`/usr/share/rpm`.
Rework this to use `/usr/share/rpm` since that's our canonical location
for now, but also add the compat symlinks so that this logic should keep
working even on trees without the injected macro yet.
We don't technically need this yet, but it mirrors how it's set up in
our composes so that if there's code that wants to use the new location
too, it'll just work.
We trigger a librpm macro file load in many of our paths. Since the
default value shipped by rpm's macro file sets `_dbpath` to
`/var/lib/rpm`, we have to explicitly set that back to `/usr/share/rpm`
in those paths.
This became more problematic recently with libsolv v0.7.17 which fully
keys off of `_dbpath` to find the rpmdb path to load:
04d4d036b2
And it's not technically wrong; we really should make that macro not
lie. This is what this patch does by injecting an RPM macro file in our
composes which sets it to /usr/share/rpm. So then e.g. the `rpm` CLI
doesn't actually need the `/var/lib/rpm` backcompat link anymore, though
there's no harm in leaving it.
In the future, we should be able to drop this once we move all of Fedora
to `/usr/lib/sysimage/rpm` (see
https://github.com/coreos/fedora-coreos-tracker/issues/639).
Closes: #2548
Originally the Rust apply-live code was exposed from Rust to C
via bindgen. But when working on that, I hit the problem
that our output infrastructure was C...and the "reverse direction"
binding stuff was just ugly.
This PR again IMO shows the value of the investment in cxx-rs
because we can now seamlessly call back from the Rust side
into a "C++-ish" progress API, which the C++ side is updated
to use.
The level of indirection here is obviously pretty silly
because the main thing on the C++ output side is basically
a function dispatcher, but...I didn't want to try to rework
that into Rust fully yet. (But, the moment we do this
whole area will get a *lot* cleaner)
Anyways, in the end this makes it easy for the apply-live
code to output progress to the user which was sorely
needed.
Our output system is very confusing in that we bridge over
DBus in some cases and not others. In preparation for allowing
Rust code to call into the C++ progress system which contains
that delegation layer, rename the Rust progress to `console_`
to clearly show that it should only be invoked by code that
knows it's writing to a tty.
