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 went through a lot of gyrations on this one. It's only
relevant to server side composes, so having the core parse
the treefile for it directly just makes sense.
Figuring out that we can't `fchmod()` on an `O_PATH` descriptor
took me a while =(
As part of that I discovered the `nix` crate grew a `Dir`
abstraction too. But I think we still probably want to be using
https://docs.rs/cap-std/0.13.7/cap_std/fs/index.html
Previously we carefully ported functionality bit by bit here.
Now take the last step and move it all in to Rust.
A reason I didn't do this in one go before is around the
incredibly twisted handling of the `/etc` vs `/usr/etc`.
I think longer term we should aim to basically have all
of our code keep it as `/etc` up until the very end. For
now we just do a rename dance around some of the add/remove
files code.
I came across this crate the other day randomly - yet *another*
dtolnay dependency. We have a bunch of these inline multi-line
strings that are just much nicer to read this way.
I only converted this one use, if this merges I'll do more
over time.
Now that `source-packages` is supported, we should allow a lockfile to
not specify a `packages` field at all. So make it optional.
We still require at least one of the two fields to be specified.
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.
In preparation for publishing this to crates.io and moving
into e.g. github.com/ostreedev/ostree-host-rs
So that ostree upstream can move forward with more Rust on the
"top level".
This tweaks the data and types parsed from `check-passwd` and
`check-groups`, so that it can be more easily iterated and
consumed by passwd-handling logic.
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.
The manual `std::mem::drop()` bits are ugly; while we can do
function pointers from Rust to C++, let's just add the obvious
high level wrapper in Rust that accepts a `FnOnce()`.
Note in one instance we directly pass a function pointer which
is quite clean.
I was thinking about privilege separation today with
systemd units, and that led me to the problem of "lifecycle binding".
We really want e.g. `systemctl stop rpm-ostreed` to kill any
separate systemd units we're managing.
systemd already has a mechanism for this with `BindsTo=`.
And then I realized we weren't doing this for the systemd-tmpfiles
invocations in the `live.rs` code.
Generalize this into a small `isolation` module that fixes this
and several other things at the same time. I'd like to build
on this to further improve our multi-process isolation story
later.
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).
It turns out there's a naming clash between `to_string()` here in
Rust *and* introspection is incorrectly associating the method
with `ostree::Deployment` because of the naming prefix.
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.
Same motivation as https://github.com/coreos/bootupd/pull/163
Effectively what we're doing here is creating a human-readable subset
of the stack trace. This is nicer than having the calling functions
add with_context() because it's more verbose (gets duplicative at
each call site), easy to forget, etc.
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.
There's a huge difference between live updates that change
existing things, versus simply adding new packages (files).
The latter is really quite safe, and live layering is one
of the most requested features.
