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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
File triggers are a post-RHEL7 thing; more information at
http://rpm.org/user_doc/file_triggers.html
There are two notable users I've been testing this with;
`glib2` and `vagrant`. The `vagrant` one is more immediately urgent,
since it makes `vagrant-libvirt` work, which I currently rely on
for my workstation dev.
I've tested things successfully with `vagrant`, and I did verify that we run the
`glib2` ones when doing `rpm-ostree ex container`.
Long term, more transaction file triggers are likely to live in
"base" packages like `glib2`. We don't implement those yet, but
extending this to do that shouldn't be too hard.
There was *significant* what I'd call reverse engineering of the
implementation in librpm. The file triggers code there is spread out
and abstracted in a few different places in the code. I found
trying to understand what header values were involved to be quite
tricky.
There are some corner cases like multiple patterns that I *think*
this does correctly, but could use more validation. The main
question I had was - is it required that the patterns for e.g.
`%transfiletriggerin` and `%transfiletriggerun` be identical?
Closes: https://github.com/projectatomic/rpm-ostree/issues/648Closes: #869
Approved by: jlebon
Now that we require clients to have an active session to RegisterClient,
we can't use runuser to check for non-root functionality. Add a new
vm_cmd_as() function to allow connecting as a different user. While
we're there, do some minor cleanups to consistently use `local` when
possible.
Closes: #894
Approved by: cgwalters
This is required for glibc-all-langpacks at least:
https://bugzilla.redhat.com/show_bug.cgi?id=1367585
Otherwise, its usage is...extraordinarily rare. In fact looking at a snapshot of
`rpm-specs-20170518.tar.xz` from Fedora, the only other use is in
`postfix.spec`, and it appears bogus (the value is already expanded at build
time).
But the glibc case is special, as the value of `install_langs` is indeed
potentially dynamic per system.
Closes: #873
Approved by: jlebon
Add experimental support for replacing packages from the base layer with
local RPMs. This is useful for example, to cherry pick a fixed package,
or to roll back to a previous package version. Like with pkg removals,
only files in /usr are actually replaced.
This patch also contains a few usability improvements as well, e.g.
showing the full NEVRA of removed packages rather than just their names,
and support for resetting overrides using either the pkgname or NEVRA.
Closes: #852
Approved by: cgwalters
Seen in the wild with `vagrant`'s use of `%post -p /usr/bin/ruby`. This was a
very easy fix, and actually makes the code a little bit nicer, as we no longer
need to explicitly make the script executable, since we now pass it as
`argv[1]`, the same way librpm does. That in turn would make it possible to fix
the TODO and use `bwrap --file`, but that can come later.
Closes: https://github.com/projectatomic/rpm-ostree/issues/856Closes: #858
Approved by: jlebon
Nuke all the previous goop that was used to create RPMs at `make check`
time and transition all the tests to use the new `build_rpm` function.
It definitely feels cleaner to use. It's also really nice to have the
spec live in the same file as the test that uses it.
Closes: #854
Approved by: cgwalters
Having to prepare RPMs in advance separately from the tests that use
them severely limits our ability to test various cases and to iterate
quickly when creating tests.
Add a new `build_rpm` function which can basically build the RPM on the
fly and update the yum repo afterwards. It makes it trivial to test
things like package updates:
build_rpm foo 1.0 1
<stuff>
build_rpm foo 1.0 2
<stuff>
The RPMs are all created inside the temporary test directory and thus
cleaned up on exit.
I'm doing this in a separate commit because it's the most important diff
of the transition and might be easy to lose in the larger diff where we
move all the tests to make use of this.
Closes: #854
Approved by: cgwalters
Import libostreetest.c from ostreedev/ostree as libtest.c. This is just
a really useful and outrageous way of using libtest.sh from C.
Closes: #854
Approved by: cgwalters
This was a kind of last-minute bug introduced when I tweaked the
checkout to use `.` to avoid a `mkdir()` for files. But there were
multiple bugs with that; for files that are in subdirectories of `/etc`
we obviously need to get the right subdir and not use `/etc`.
Second, we need to handle the case where we're adding new subdirectories.
This change fixes `rpm-ostree install firewalld + rpm-ostree ex livefs`.
Closes: #783
Approved by: jlebon
First, we need to preserve whitespace in the regexps. Second,
in the error path, all of our variables were wrong.
Commit 376a2cc3f5 is an excellent
poster child for how many bugs one can introduce in a single commit
for a ~5 line function.
Closes: #777
Approved by: jlebon
There are a few different use cases here. First, for layering new packages,
there's no good reason for us to force a reboot. Second, we want some support
for cherry-picking security updates and allowing admins to restart services. Finally,
at some point we should offer support for entirely replacing the running tree
if that's what the user wants.
Until now we've been very conservative, but there's a spectrum here. In
particular, this patch changes things so we push a rollback before we start
doing anything live. I think in practice, many use cases would be totally fine
with doing most changes live, and falling back to the rollback if something went
wrong.
This initial code drop *only* supports live layering of new packages. However,
a lot of the base infrastructure is laid for future work.
For now, this will be classified as an experimental feature, hence `ex livefs`.
Part of: https://github.com/projectatomic/rpm-ostree/issues/639Closes: #652
Approved by: jlebon
This was argued on list a while ago: http://lists.rpm.org/pipermail/rpm-ecosystem/2016-August/000391.html
Basically, every use of `%pretrans` is a workaround for some in-place
upgrade problem. But we never do inplace updates, we always assemble
a new tree. Hence, there is no point for us to ever execute these.
Let's stop erroring out on them. If there does turn out to be some problem with
a particular package (e.g. the `openjdk-copy-configs` or whatever), we would
likely end up needing to fix that package's `%post`, not start executing its
`%pretrans`.
Closes: #763
Approved by: jlebon
I need to build ostree from git too. So now my workflow is:
```
export insttree=/srv/walters/tmp/rootfs
cd ostree
make && make install DESTDIR=${insttree}
cd rpm-ostree
make && make install DESTDIR=${insttree}
env VMCHECK_INSTTREE=${insttree} make vmoverlay
```
Closes: #705
Approved by: jlebon
I originally thought there was a bug here, but missed we were skipping
symlinks earlier above. See [previous discussion][1].
Now, I'm not aware right now of something this patch actively fixes, but I think
it makes sense to be consistent in our handling of things here with respect to
symlinks.
1: 29dd1bd801..8158dcfb47 (r95017893)Closes: #689
Approved by: jlebon
I built+installed ostree git master with
https://github.com/ostreedev/ostree/pull/723 in my dev container,
which broke the rpm-ostree tests. Kind of embarrassing that
I forgot to check rpm-ostree for usage of `ostree trivial-httpd`.
This is another thing that really wants a shared test container.
Anyways let's just use Python for this.
Closes: #684
Approved by: jlebon
1. Don't require an ssh-config
In the case of redhat-ci, the VMs are already fully configured for the
system (injected in the hosts file, host key accepted, etc...). So
there's no need to have an ssh-config there. In general, it should be
acceptable to run the vmcheck suite against a resolvable host without
having to create an ssh-config for it.
2. Make the host name configurable
Rather than hardcoding "vmcheck" as the hostname, allow overridding it
by specifying a VM env var directly. We also prepare the various scripts
to make use of the $VM variable whenever host-specific dirs/files are
created so that parallel runs won't step on each other.
Closes: #675
Approved by: cgwalters
While reading a recent conversation about GPG checking at treecompose
time, I had a sudden thought - were we actually doing verification
client side? Turned out, we aren't. That happens as part of
`dnf_transaction_commit()` which we don't use.
That function verifies every package at one go, but for us I think it's better
to do it before "importing". We shouldn't have untrusted bits that we've
unpacked (they might have suid binaries, for one thing).
This is an embarassing problem, but it's worth emphasizing that everyone should
be retrieving repodata at a minimum over TLS, which sets a baseline. On RHEL, we
already do pinned TLS, and there are discussions about extending that elsewhere.
See: https://bugzilla.redhat.com/show_bug.cgi?id=1422157Closes: #656
Approved by: jlebon
We don't want to expose the host's `/tmp` since that means scripts could
potentially find things like the X11 socket or whatever.
To debug things better, add a quick bash script to run bwrap like the C code
does. Perhaps down the line we can add `rpm-ostree internals run-bwrap` or so.
Closes: #647
Approved by: jlebon
On the first call to vmsync/vmoverlay, we do an immediate vm_ssh_wait()
to check if we have a live VM. However, we don't necessarily have a
working rpm-ostree in there if we're hacking on stuff. It gets annoying
to wait for the timeout there.
Let's just work around that by instead only calling status if we got
there through vm_reboot_cmd(), which is most likely when we're most
interested in the status output anyway.
Closes: #645
Approved by: cgwalters
See https://github.com/projectatomic/rpm-ostree/issues/233 - for RPMs which
place files in e.g. `/opt`, we have different behavior in the treecompose case
(silently drop it) versus package layering (does the wrong thing).
Since the unpacker right now is only used in the layering case, this just
ensures we'll get a consistent error there.
Closes: #624
Approved by: jlebon
I'm not sure why we weren't doing this before, but we need to also
support files in /var and /run that are owned by root.
Related: RHBZ#1421781
Closes: #622
Approved by: cgwalters
One thing that's very confusing about OSTree is there are two layers -
deployments and the refs/commits. If one does an `rpm-ostree upgrade`, but then
e.g. `ostree admin undeploy 0`, you still have the new revision in the repo.
We don't do a good job of displaying this state, or helping people clean
it up.
Down the line, I also want to better support something like `rpm-ostree pull` to
cache updates explicitly *without* deploying.
This commit just adds a bit of information to the status display. We might want
to have better formatting, but I think this an OK start.
Closes: #595
Approved by: jlebon
Currently we push for a model where the initramfs is
generated (in non-hostonly mode), and merely replicated.
However, to support a few unfortunate corner cases like dm-multipath which wants
to inject a config file into the initramfs, we need to support regenerating it
client side too.
Down the line, we'll need this to support overriding the kernel too.
This changes things in the core to add the concept of an "empty"
`RpmOstreeContext`. I initially tried skipping it, but that was too much
duplication. We still want all of the core ostree-related logic that lives in
that code too.
The treespec bits barfed if the spec didn't have a `tree/packages` key. It was
simplest to change that to allow it - and because that was the only case where
we errored out in parsing, I dropped the error handling.
There was another place in the upgrader that now needed to be fixed to handle
transitioning from just regenerating initramfs to not.
Closes: #574
Approved by: jlebon
Many projects do this, and it really helps debugging to know the
exact hash.
(Of course this is broken in traditional rpm builds from a tarball,
and rpmdistro-gitoverlay injects it into the Version field,
but it will help me for vmcheck debugging)
Closes: #584
Approved by: jlebon
I don't see a reason not to require more stuff to execute tests,
and having it be optional reduces our coverage unnecessarily.
Closes: #580
Approved by: jlebon
Working on initramfs, I hit a subtle issue with the fact that
I was trying to "redeploy", but with the origin file changed
during the process.
Previously, it was a bit unclear which parts of the upgrader logic are operating
on the *new* origin versus the "original origin".
The package layering code in the upgrader explicitly carries a delta on top in
the "add/remove" hash sets, which means it isn't visible to
`rpmostree_origin_is_locally_assembled()`.
Whereas for initramfs, I set a new origin. This broke things since we were
expecting to find a parent commit, but the original origin wasn't locally
assembled.
When looking more at this, I realized there's a far simpler model -
rather than keeping track of commit + origin, and using the origin
to try to determine whether or not the commit is layered, we can
keep track of `base_revision` and `final_revision`, and the latter
is only set if we're doing layering.
The diff speaks for itself here - a lot of fragile logic looking at the origin
drops away.
The next step here is probably to drop away the package layering hash sets, but
I'm trying to not change everything at once.
Closes: #579
Approved by: jlebon
We seem to have substantial infrastructure drift here between the two, and I was
*really* confused why `TEST_SKIP_CLEANUP` wasn't being honored. Turned out in
rpm-ostree we have tmpdir code in two places, not entirely sure why. Punting
full cleanup.
Closes: #566
Approved by: jlebon
First try to log in, and if we fail, retry with SSH debugging,
so we have a better idea what might be going wrong. This helped
me figure out that vmcheck's `-o User=root` assumption wasn't
working with my vagrant setup.
Closes: #560
Approved by: jlebon
During a deploy operation, we would fetch commit objects from the remote
to resolve the version string. If gpg-verify was turned on, we would
fail to pull them if some of the commits were not signed. This is
because we pulled them in batches. We partially address this by only
fetching the HEAD commit on the first pass. This allows `upgrade`
operations to work just as well as `deploy` operations.
Though there is still an issue if we have to traverse farther back than
when signed commits become unsigned (unless they happen to fall on a
batch boundary). We leave that unsolved for now, since that would likely
require a more complex solution and it's not clear whether it's a real
world issue (signers can just retroactively sign commits).
Copy the gpghome from ostree so that we can test GPG-related cases in
our suite.
Closes: #527Closes: #557
Approved by: cgwalters
Expand the available options in the Rebase() D-Bus method to also have a
"revision" key. Its value has the same semantics as the "revision" key
in the Deploy() method (e.g. the "revision=" and "version=" prefixes are
also supported). Also expand the rebase CLI to allow for specifying the
revision as an additional argument.
This allows users to rebase to a specific version or checksum, rather
than only to the latest. Conceptually, this is the equivalent of doing a
rebase followed by a deploy. I.e. we specify an override-commit in the
origin and expect the same behaviours that apply after a deploy to also
apply here.
Closes: #212Closes: #555
Approved by: cgwalters
Unsurprisingly, rebooting machines that are running in OpenStack is
not as reliable or as fast as a local VM, which is what vmcheck was
originally written for and tested against.
Replace the:
sleep 2 # give time for port to go down
which is rife with raciness, with a stronger boot_id-based check to
ensure we're in a new boot. Run "sync" before rebooting which sometimes
helps (though I didn't fully investigate why or whether it always helps,
there's probably something more subtle going on underneath). Increase
the timeout to 120s.
Closes: #543
Approved by: cgwalters
