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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
I just rebased my pet container to F27, and this was the only hiccup
when trying to build rpm-ostree. Basically, gdbus-codegen is sensitive
to how it's called when trying to find its own Python modules. Calling
it with the explicit `/usr` prefix works around that. This was fixed
upstream in [1], but hasn't made its way down the metaphorical stream
yet. See [2] for more information.
[1] b9f2ea4235
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1485853Closes: #1153
Approved by: cgwalters
This would have prevented corruption I saw when using unified core 🌐 mode; we
ended up appending repeatedly to the version in the imported pkgcache repo
where fedora-atomic does:
`echo 'Storage=persistent' >> /etc/systemd/journald.conf`
See also https://pagure.io/fedora-atomic/pull-request/97Closes: #1151
Approved by: jlebon
This fixes another thing broken with `compose --ex-unified-core`;
for e.g. `/usr/bin/ping` from `iputils`, the classic example of a filecaps
binary.
As I'm writing this commit message I realize it will actually also
take effect for package layering unnecessarily; we'll pointlessly
break the hardlink. But eh, it doesn't matter right now, we can
optimize that later.
Closes: #1151
Approved by: jlebon
Prep for adding `compose tree --ex-jigdo` to do both at the same time.
Changes other than code motion were minimized; the main thing was tweaks around
the initial option processing to call the API.
Closes: #1146
Approved by: jlebon
Rather than entirely symlinking `systemctl` → `/bin/true`, in order
to e.g. have NetworkManager be enabled, we need to process presets.
This is one of the things that's breaking FAHC where I did a
`--ex-unified-core` deployment.
(Actually it's a bit tempting to run a mass preset pass at the end,
but for now let's do this)
Implementation note: this is our first use of GResources, which
is a handy way to embed data into our final binary.
Closes: https://github.com/projectatomic/rpm-ostree/issues/550Closes: #1148
Approved by: jlebon
This rolls up several libglnx changes: https://github.com/GNOME/libglnx/pull/101
Now of course things are trickier here because we have an internal
abstraction over directly emitting to a console versus sending the
result over DBus. Further complicating things is that some things
call into libdnf and thus *require* use of `DnfState` which does
not give us the "n items" information, versus other parts which
we implement and can do what we want.
Even *further* complicating things is that we have to take care around non-CLI
callers like Cockpit; so I didn't try to pass the "n items" over DBus, rather
just reimplemented the "insert into text" that libglnx is doing.
Anyways overall this looks better IMO for all cases.
Update submodule: libglnx
Closes: #1143
Approved by: jlebon
The jigdo ♲📦 effort really throws a spanner into the logic behind our whole
code layout; so far I mostly sidestepped that by having a lot of the new logic
in the CLI, with just some `_jigdo_xxx()` methods in core code.
But in order to start on having the "sysroot" side use jigdo, let's start
moving some bits into core.
Closes: #1144
Approved by: jlebon
This is prep for a rework of
https://github.com/projectatomic/rpm-ostree/pull/621
For a no-op `rpm-ostree upgrade` (i.e. no updates available), as long as
layering is enabled, we pay the cost of checking out the base tree, *mostly*
only to get the base rpmdb.
This is prep for fixing that down the line by knowing we always have the "base"
tree's rpmdb checked out. Then in the layering case we only modify
`/usr/share/rpm` (eventually that will point to `/usr/lib/sysimage/rpm`).
Teaching `rpmostree-core.c` about this can follow on later.
Closes: #1142
Approved by: jlebon
This came out of discussion in: https://github.com/projectatomic/rpm-ostree/issues/1132
Let's simplify some logic and download/import even unused packages;
i.e. packages which do not provide any content objects.
A lot of the higher level logic wants to reference what I'm going to start
calling the "installSet" i.e. the packages in the rpmdb in the commit. So it's
simpler if the "jigdoSet" is exactly the same thing as the "installSet", and the
cost is pretty small.
Closes: #1140
Approved by: jlebon
Now that we have the jigdoset in `Requires`, let's make a hard
switch to using it and drop the jigdoset from the jigdoRPM data.
One lingering concern here is that the `Requires` are not quite
as strict as what we had before; for example one apparently can't
add a `Requires:` that refers to an architecture (x86_64 vs noarch).
And a lot more strongly than that we had the repodata checksums
in the old format. I'm still thinking of a way to use those.
But moving on, this allows us to rework the client side to do a lot more
up-front calculation before downloading the jigdoRPM. In the spirit of that, at
the same time let's add a `Provides: rpmostree-jigdo-commit(e7bdb7443d8...)` so
that we can determine ahead of time whether or not we have the actual commit.
A major change we could now take would be to download the jigdoRPM
in parallel with the jigdo set, but doing that would require
driving a lot more of the jigdo logic into the core; it'd need
to know to specially handle the jigdoRPM download.
Closes: #1140
Approved by: jlebon
I was looking at this while chasing what turned out to be an entirely different
bug. Since we're referencing `checksum`, let's call the interator removal last.
Closes: #1140
Approved by: jlebon
The idea is to see how much "waste" there is in downloading the set subtraction
of "installSet - jigdoSet".
At the moment I'm actually seeing e.g. `emacs-filesystem-1:25.3-3.fc27.noarch (0
bytes)` where I expected the download size, but that's a separate bug probably
in libdnf which I'll look at later.
Closes: #1140
Approved by: jlebon
While we do this when writing the final object, let's do it early on
for better security. Was just thinking about this while redoing
how we parse the jigdoRPM.
Closes: #1140
Approved by: jlebon
Having the "jigdo set" in repodata makes it so we can parallel download the
jigdo RPM with the set. However for now, I kept the jigdo set in the jigdoRPM,
since that way it'll be covered by the signature.
Also, this changes the way we inject metadata to use a magic comment string,
since trying to pass a gigantic macro to `rpmbuild` via its argv didn't work out
so well (it looks like rpmbuild eats newlines). This approach is more robust.
Closes: https://github.com/projectatomic/rpm-ostree/issues/1132Closes: #1140
Approved by: jlebon
This is another big task just like importing that greatly benefits
from being parallel. While here I hit the issue that on error
we didn't wait for pending async tasks to complete; I changed things
for importing so that we do that, and used it here too.
This was almost straightforward except I spent a *lot* of time
debugging what turned out to be calling `dnf_package_get_nevra()`
in the worker threads 😢.
I'm mostly writing this to speed up unified core/jigdo, but it's also obviously
relevant on the client side.
Closes: #1137
Approved by: jlebon
Basically since we're doing internal async ops which set the cancellable on
failure, we still want the first error to win since it'll be more useful. See
the docs for `g_task_set_check_cancellable()` for more.
Closes: #1137
Approved by: jlebon
I believe this is a leftover vestige, and it was adding confusion when I was
debugging `rpmostree-core.c` async ops and cancellation.
Now the only cancellables in the daemon are created by transaction ops.
Closes: #1137
Approved by: jlebon
In the whole libdnf/C++ discussion I experimented with trying to build
rpm-ostree as C++. There's a whole ton of stuff there. I'm going to punt for
now, but let's land this one change so some progress was made.
Closes: #1141
Approved by: jlebon
With unified core 🌐 we are *relying* on the devino cache
for correctness when using `bare-user` repos. Otherwise lots
of bad things will happen as we won't hit the happy path from
[this libostree PR](https://github.com/ostreedev/ostree/pull/1297)
(I should probably add an assertion there that we aren't trying to commit
`user.ostreemeta`).
It looks like I had this working in some of the old unified core WIP patches,
but it was lost when rebasing 🏄.
We noticed this when I was trying to deploy jigdo in FAHC and the system
wouldn't boot as various things rely on those suid transitions.
Closes: #1139
Approved by: jlebon
We don't want to have to download all of `/usr/share/rpm` just to get
the list of packages used to compose the tree. This is fundamental
information that needs to be easier to discover. So let's stick it right
in the commit metadata. There's various use cases for this information,
including easily checking for and displaying updates and a pkglist-aware
version of `ostree log`.
Closes: #1134
Approved by: cgwalters
Basically, it doesn't make sense for the caller to only want the
pkglist, but not the refsack because the former has a more limited
lifetime than the latter. Check for that to make sure nobody falls in
this trap like I did.
Closes: #1134
Approved by: cgwalters
This function is now basically reimplementing all of the intelligence
we have in libostree today. It wouldn't have worked before we
fixed https://github.com/ostreedev/ostree/issues/1165 but now
that's done, conceptually we just need to call
`ostree_repo_commit_modifier_set_sepolicy()`. However, I had
to drop the "number of files changed" since currently the libostree
API doesn't support that.
Also, in order to detect the case that content changes at all (so
we still have some useful information in the journal), implement
a "content hash" check.
See also https://github.com/projectatomic/rpm-ostree/pull/1123
(And note we *don't* use `DEVINO_CANONICAL` here)
Closes: #1138
Approved by: jlebon
In preparation for multithreading relabeling; the problem I hit badly was the
`dnf_package_get_nevra()` isn't safe[1]. Since we were only using that for error
prefixing, move the error prefixing to the (currently non-MT) caller.
[1] Write it in C/C++, where multithreading is doomed to endlessly debug
data races?
Write it in Python, where MT isn't useful at all?
Write it in Golang, where you face deep hostility to in-process C/C++ libs
or really any other language?
Or write it in Rust, where we spend a lot of time fighting the borrow checker
and (to some degree) debugging the FFI glue to C/C++?
Closes: #1138
Approved by: jlebon
Right now the fact that one can only cancel via `Ctrl-C` of an existing client
process is rather frustrating if for example one's ssh connection to a machine
drops. Now, upon reconnecting, one can easily `rpm-ostree cancel` a hung update
or whatever rather than doing the more forcible `systemctl stop rpm-ostreed`
(which is safe of course, unless livefs is involved).
Closes: #1019
Approved by: jlebon
Depends: https://github.com/ostreedev/ostree/pull/1358
For jigdo ♲📦 in order to get true image speed like libostree has we need to
interleave and parallelize downloading and importing.
The messy part about this is having sync API do the "invoke and wait on various
async tasks" pattern. It's the same thing in `ostree_repo_pull_with_options()`.
Importing is pretty dramatically faster with this, I can only imagine the speed
win if we actually interleaved with downloads. However doing that requires
libdnf/librepo work.
Closes: #1124
Approved by: jlebon
Now that the importer *only* imports into OSTree repos, let's
clean up the API so that the `OstreeRepo` and `OstreeSePolicy`
are passed as constructor args.
Also rework things so there's only one constructor API that
steals the fd.
This is prep for adding another async import API.
Closes: #1124
Approved by: jlebon
We are going to want versioning on the jigdo RPMs, since it's
highly likely things change.
This is done via new magic '-D rpmostree_jigdo_meta` macro, which we can also
use for other things down the line.
Closes: #1135
Approved by: jlebon
I have hit multiple times the bug with `bare-user` repos:
https://github.com/ostreedev/ostree/pull/1297
(Need to rebuild my dev container rather than relying on an updated
`sudo make install` from ostree git)
Anyways if things are out of sync, this bug would manifest as the
main repo wouldn't have the object.
Closes: #1135
Approved by: jlebon
Let's "repo bind" the OIRPM by default; this makes the rpm-md repo feel a lot
more like an ostree remote, and IMO is just a really good idea in general to
increase predictabilty.
Closes: #1130
Approved by: jlebon
Note this PR requires [bubblewrap 0.2.0](https://github.com/projectatomic/bubblewrap/releases/tag/v0.2.0).
Change our bwrap invocations drop truly dangerous capabilities like
`cap_sys_admin` and `cap_sys_module` just like Docker does today. Because of the
popularity of Docker, we can be pretty sure that most RPM scripts should have
adapted to this (although a problematic area here is that traditional librpm
doesn't actually error out if scripts fail).
There are two reasons to do this:
- We want "offline" updates by default; updates shouldn't affect the
running system. If we prepare the new root in the background, a
%post shouldn't restart a service for example. We already "handle"
this by making `systemctl` a symlink to `/bin/true`, but this approach
also shuts off `%post`s that do e.g. `insmod`.
- Protection against accidental system damage
Closes: #1099
Approved by: jlebon
There's a lot more details in the libostree PR:
https://github.com/ostreedev/ostree/pull/1357
Basically loading the xattrs is slow; let's only do it if we need to, and "need
to" is defined by "SELinux policy changed". On my test F27AH VM, the difference
between a stat() + hash table lookup versus the full xattr load on my test case
of rpm-ostree install ./tree-1.7.0-10.fc27.x86_64.rpm is absolutely dramatic;
consistently on the order of 10s without this support, and <1s with (800ms).
Closes: #1123
Approved by: jlebon
In unified core mode, this avoids an intense spam of errors from `cp`
because `tmpfs` doesn't support the `user.` xattr namespace, and
since [this dracut commit](61c761bc2c)
dracut tries to copy all xattrs, which was just done for IMA.
There's no point to having the SELinux labels or other xattrs
in the initramfs.
The real fix here is dracut should learn to *only* copy the IMA
xattrs, or even better disable IMA enforcement for the dracut
run or something.
Closes: #1126
Approved by: jlebon
Tracking issue: https://github.com/projectatomic/rpm-ostree/issues/1081
To briefly recap: Let's experiment with doing ostree-in-RPM, basically the
"compose" process injects additional data (SELinux labels for example) in an
"ostree image" RPM, like `fedora-atomic-host-27.8-1.x86_64.rpm`. That "ostree
image" RPM will contain the OSTree commit+metadata, and tell us what RPMs we
need need to download. For updates, like `yum update` we only download changed
RPMs, plus the new "oirpm". But SELinux labeling, depsolving, etc. are still
done server side, and we still have a reliable OSTree commit checksum.
This is a lot like [Jigdo](http://atterer.org/jigdo/)
Here we fully demonstrate the concept working end-to-end; we use the
"traditional" `compose tree` to commit a bunch of RPMs to an OSTree repo, which
has a checksum, version etc. Then the new `ex commit2jigdo` generates the
"oirpm". This is the "server side" operation. Next simulating the client side,
`jigdo2commit` takes the OIRPM and uses it and downloads the "jigdo set" RPMs,
fully regenerating *bit for bit* the final OSTree commit.
If you want to play with this, I'd take a look at the `test-jigdo.sh`; from
there you can find other useful bits like the example `fedora-atomic-host.spec`
file (though the canonical copy of this will likely land in the
[fedora-atomic](http://pagure.io/fedora-atomic) manifest git repo.
Closes: #1103
Approved by: jlebon
`test -n` would always be true. Also while I have the patient open
let's make writing the file atomic. Maybe someday I'll be motivated
enough to write an `O_TMPFILE` patch for bash.
Closes: #1103
Approved by: jlebon
When we added the `--ex-unified-core` option our caching story got
very messy because the non-unified core caches RPMs, but unified
does ostree repo caching.
For jigdo, we want the RPMs. Fix this by mirroring the RPMs using
`--download-only` and pointing the tests consistently at that.
Closes: #1122
Approved by: jlebon
With jigdo this is a very useful as one needs the ability to bind together the
RPMs and commits.
And for the compose tests this is a more reliable way to do caching anyways.
Closes: #1122
Approved by: jlebon
We originally needed the pkgcache to be a separate repo due to ostree's
overzealous pruning policies. The idea was to maintain multiple commits
in each pkg branch for different SELinux policies. In practice, there's
not much use in maintaining old copies and it's just easier to always
relabel on the fly. So then, the need for a separate repo completely
melts away.
This helps simplify the mental model a bit and allows us to avoid subtle
issues like #1047. Note however that the core is still capable of
handling split repos for the `--ex-unified-core` compose use case. Once
that and the jigdo work are a bit more settled, we can have a clearer
picture of how to simplify the core further.
The tricky bit is migrating the cache. When deploying, we check if a
pkgcache repo exists and migrate its refs if so. We then leave behind a
symlink to the system repo to remain compatible with older rpm-ostrees.
Closes: #1055
Approved by: cgwalters
Instead of just giving just the package that would be replaced, also
print out the package that replaces it, as well as the repo it comes
from.
Closes: #1113Closes: #1120Closes: #1121
Approved by: cgwalters
Noticed this while working on diff output somewhere else. I was
initially thinking of making use of this there too, but it's not quite
the right fit and would require a lot of churn.
Closes: #1121
Approved by: cgwalters
