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 a better alternative to https://github.com/coreos/fedora-coreos-config/pull/830
Basically rather than trying to send this out to all FCOS users,
it's much saner to allow people to opt-in to it locally.
If we'd finished https://github.com/coreos/rpm-ostree/issues/2326
then this would be something as trivial as:
```
$ echo 'cliwrap: true' > /etc/rpm-ostree.d/cliwrap.yaml
$ rpm-ostree rebuild
```
Unfortunately that's not the world we live in, so a whole lot of
layers here need crossing to just propagate a boolean. And it
interacts in a tricky way with our change detection code.
But, it works and will allow people to try this out.
Other fixed problems:
- Our `rpm --verify` wrapping was broken
- Dropping privileges clashed with the default directory being `/root`,
so `chdir(/)` too
The inevitable followup to https://github.com/coreos/rpm-ostree/pull/2278
that I was too cowardly to do at the time. But it's time to admit
the 2 months or so of work on this was wasted. We have too much
tech debt and this is a large chunk of C/C++ code that touches everything
in the codebase in a nontrivial way.
Bigger picture, I'm going to work on
https://github.com/coreos/fedora-coreos-tracker/issues/828
which will strongly orient rpm-ostree towards the container world instead.
We'll still obviously keep the rpm package world around, but only
as a secondary layer. What rojig was trying to do in putting "images"
inside an RPM was conflating layers. It would have had a lot of
benefits probably if we'd truly pushed it over the edge into completion,
but that didn't happen. Let's focus on containers instead.
There's still a lot more rojig code to delete but this first patch removes
the bulk of it. Touching everything that references e.g. `RPMOSTREE_REFSPEC_TYPE_ROJIG`
etc. can come as a 3rd phase.
This reworks the special-case handling of `/var/lib/rpm`, in order
to make it uniform across codepaths and outside of auto-tmpfiles logic.
It prepares for further oxidation and auto-tmpfiles codepaths unification.
In Fedora CoreOS, updates are driven by Zincati and we thus completely
trust the information it gives us. The branch validation rpm-ostree does
is thus not necessary. It's also harmful in the case where the node is
extremely out of date because it may not be able to GPG verify the
commit at the tip of the branch (because the GPG key isn't yet in the
tree).
See: https://github.com/coreos/fedora-coreos-tracker/issues/749
If updates driver is registered but "stopped", ignore driver (i.e.
do not error out during deploy, rebase, ugprade).
We define "stopped" to mean the driver's `ActiveState` is not in
the following states: "active", "activating", "reloading", "failed".
This addresses the server compose side of
https://github.com/coreos/rpm-ostree/issues/2584.
One tricky bit is handling overrides across included treefiles (or
really, even within a single treefile): as usual, higher-level treefiles
should override lowel-level ones. Rust makes it pretty nice to handle.
For now this just supports a `repo` field, but one could imagine e.g.
`repos` (which takes an array of repoids instead), or e.g.
`exclude-repos`.
The actual core implementation otherwise is pretty straightforward.
This should help a lot in RHCOS where we currently use many `exclude=`
directives in repo files to get it to do what we want.
This is also kind of a requirement for modularity support because as
soon as rpm-ostree becomes modules-aware, modular filtering logic will
break composes which assume rpm-ostree treats modular and non-modular
packages the same.
This made me hesitate for a bit so add a comment about it to make it
clear. The RPMOSTREE_ASSEMBLE_TYPE_SERVER_BASE path was used by the `ex
container`, which was subsequently ripped out.
The only entrypoint so far doesn't use it (`countme`), but a future new
entrypoint will.
Also mention that the commands should add themselves to the array in
libmain.cxx if applicable so it shows up in `--help`.
`rpmvercmp()` doesn't properly compare full EVR. It needs to
be given the Version and Release separately in order to do
a comparison. For example `rpmVersionCompare()` first calls
`rpmvercmp()` to compare the Version and then checks the Release
in a second call to `rpmvercmp()`.
35739c2a22/lib/headerutil.c (L434-L440)
Let's just use `rpmverCmp()` instead, which can do the full
EVR comparison.
Fixes: https://github.com/coreos/rpm-ostree/issues/2668
These new switches will allow users/drivers to more easily make idempotent changes to kernel arguments.
Closes: https://github.com/coreos/rpm-ostree/issues/2709
Signed-off-by: Rafael G. Ruiz <llerrak@hotmail.com>
Since in the future we'll operate on a treefile, move the callers
still using treespecs to an explicit API. This is also clearer
because about half the callers were passing `NULL` for this anyways.
This ports to Rust the auto-tmfiles.d translation logic which is
meant to consume a populated `/var` and to produce a matching
`rpm-ostree-1-autovar.conf` instead.
It also adds a unit-test covering most codepaths.
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.
The intention here was to distinguish between server composes
and client side layering. But that doesn't work today because
we we call`_new_system()`; probably a result of refactoring.
Doesn't matter too much because we only checked it to
throw an error if we failed to load the policy.
And now add a check for `is_system` instead of checking whether
a treefile is present.
This is prep for converting the origin to a treefile and
using that as our standard format.
Remove the unnecessary builder causing memory leaks like this one:
Direct leak of 8 byte(s) in 1 object(s) allocated from:
#0 0x7f60bd2fe3cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
#1 0x7f60bca6cbb8 in g_malloc (/lib64/libglib-2.0.so.0+0x5bbb8)
#2 0x7f60bcaa54f2 in g_variant_type_copy (/lib64/libglib-2.0.so.0+0x944f2)
#3 0x7f60bcaa3384 in g_variant_builder_init (/lib64/libglib-2.0.so.0+0x92384)
#4 0x55e5bb3120d3 in filter_xattrs_cb src/libpriv/rpmostree-postprocess.cxx:1493
#5 0x7f60bc89cb38 (/lib64/libostree-1.so.1+0x49b38)
#6 0x7f60bc8a5e1a (/lib64/libostree-1.so.1+0x52e1a)
#7 0x7f60bc8a622b in ostree_repo_write_dfd_to_mtree (/lib64/libostree-1.so.1+0x5322b)
#8 0x55e5bb307e6e in write_dfd_thread src/libpriv/rpmostree-postprocess.cxx:1551
#9 0x7f60bca92401 (/lib64/libglib-2.0.so.0+0x81401)
#10 0x7f60bc12d3f8 in start_thread (/lib64/libpthread.so.0+0x93f8)
#11 0x7f60bc05ab52 in __GI___clone (/lib64/libc.so.6+0x101b52)
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
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.
