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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The same way we abbreviate ReplacedBasePackages when there are matching
EVR diffs, let's do something similar for RemovedBasePackages for
matching EVRs.
Solves #1784
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1852
Approved by: jlebon
Drop the use of Ansible everywhere. In the few cases where we really
Python, just spawn a container instead.
This is required to be able to hack on Fedora CoreOS.
Closes: #1850
Approved by: jlebon
The use case for `ostree-layers` is to support injecting non-RPM
content in a more flexible way than can be done with `add-files`,
and also without dropping all the way to split composes.
This starts with support on the `compose tree` side but down the
line I'd like to make it more convenient to do *client* side too.
For `ostree-override-layers` this is mainly a development thing
for tools like coreos-assembler. Rather than building an RPM
we just `make install DESTDIR` then commit and add to
`ostree-override-layers`.
Closes: #1830
Approved by: jlebon
One problem with how we use lockfiles right now is that we don't enforce
them for dependencies. That is, if `foo` requires `bar`, but only `foo`
is in the manifest, then while `foo` will be locked, `bar` will never
be checked against the lockfile because it was never explicitly
requested.
Higher-level though, I don't like how indirect the locking here feels.
See some comments about that in:
https://github.com/projectatomic/rpm-ostree/pull/1745#discussion_r288772527https://github.com/projectatomic/rpm-ostree/pull/1745#discussion_r289419017
Essentially, the manifest is an input file of patterns, and all we
really know from the lockfile output is that the set of packages in
there satisfies this input in some way. But:
1. there are multiple ways to satisfy the same input (hence why hints
like `SOLVER_FAVOR` exist)
2. the solution is dependent on how the solver is implemented (i.e.
different libsolv versions might yield different solutions)
3. the solution is dependent on flags fed to the solver (i.e. different
libdnf versions might yield different solutions)
So any attempt at cross-checking between the input file and the lockfile
is going to be very hard. Using a stricter mode as I suggested in #1745
of only allowing pure pkgnames or NEVRAs would help, but it wouldn't
address the dependency issue. (Though I'm still thinking about possibly
doing this anyway.)
The solution I propose here is instead to take the nuclear approach: we
completely exclude from the sack all packages of the same name as
packages in our lockfiles, but which do not match the NEVRA. Therefore,
any possible solution has to also satisfy our lockfile (or error out).
Closes: #1849
Approved by: cgwalters
Fixes#1670
This patch introduces a new `compose tree
--ex-write-lockfile-to=manifest.lock` argument and a new `compose tree
--ex-lockfile=manifest.lock` to read it back for subsequent invocations.
Signed-off-by: Rafael Fonseca <r4f4rfs@gmail.com>
Closes: #1745
Approved by: jlebon
Of course, update agents driving rpm-ostree know exactly to which commit
they want the system to upgrade, so `upgrade --lock-finalization` is not
helpful. Teach `deploy` the `--lock-finalization` switch too.
Closes: #1846
Approved by: lucab
Add a new "json" output format. The "diff" format is also a mostly
machine-compatible one. But JSON is much more ubiquitous and easier to
consume.
Closes: #1844
Approved by: cgwalters
1. Allow deleting keys without values (e.g. `nosmt`) if such a key
variant exists (i.e. this won't work if there are only e.g.
`nosmt=foo` and `nosmt=bar` variants).
2. Allow deleting duplicate `keys[=val]` kargs.
Closes: #1834Closes: #1835
Approved by: cgwalters
This allows one to run the tests from a container using overlay +
SELinux protection by running the actual compose into a non-overlay
bind-mount. Otherwise, we'll hit `ENOTSUP` when trying to set labels on
various checkouts.
Closes: #1829
Approved by: cgwalters
There are cases where we do want all the things that specifying a ref
provides (e.g. change detection, version incrementing, SELinux labeling
optimizations, and of course writing the ref) but we *don't* want the
new commit to have a parent. Add a new `--no-parent` option to
accommodate this.
This will be used by coreos-assembler. See discussions at
https://github.com/coreos/coreos-assembler/issues/159.
Closes: #1829
Approved by: cgwalters
We had a subtest that wasn't actually part of the `basic_test()` and so
was being executed when the file gets sourced instead of the function
being explicitly called.
Closes: #1829
Approved by: cgwalters
In the app, rebuild the exact command-line that the client used and pass
that to the daemon to be used as the transaction title. Especially in
transactions like `UpdateDeployment()`, we can avoid reverse-engineering
what the original command used was.
This will be used by the upcoming history feature to record the
command-line used in the journal.
Closes: #1824
Approved by: rfairley
This bumps the requirement on the controlling host to Python 3 only.
It also bumps the requirement on the target host to Python 3 as well
since FCOS doesn't ship Python 2 right now.
Though we'll need to eventually drop all Python usage anyway, but at
least let's get tests passing on FCOS first. (See related previous
patch).
Closes: #1828
Approved by: cgwalters
Also switch to using `jq` on the controlling host instead of Python.
This is also prep for switching CI to FCOS which is likely to not ship
Python at all. There are still spots a bit everywhere where we currently
assume Python on the target host. We'll have to address those soon.
Closes: #1828
Approved by: cgwalters
In Fedora 29, and Fedora 30 Silverblue, I have come across the
following error when executing `make vmsync` from my build container
(also on Fedora 29 and Fedora 30 images respectively):
```
...
Failed to connect to new control master
...
Control socket connect(/var/tmp/ssh-vmcheck-1556768111752693879.sock): Connection refused
Failed to connect to new control master
...
```
Previously this worked with Fedora 28 as the host.
After changing the socket to be in /dev/shm, the SSH connection to
the `vmcheck` VM is successful and the sources sync over.
The cause of this seems to be a problem with overlayfs and unix
sockets: https://github.com/moby/moby/issues/12080
Since overlayfs is the default graph driver in Fedora now, work
around this by switching the socket to be in /dev/shm.
Closes: #1827
Approved by: jlebon
Teach `UpdateDeployment` to make use of libostree's staging lock and
then add a `FinalizeDeployment` API to perform the final unlock &
reboot.
I also added a hidden CLI to make testing this easier, but also because
it's likely the FCOS-agent-yet-to-be-named will just end up using the
CLI to keep it simple.
Closes: #1748Closes: #1814
Approved by: lucab
Prep for making `--unified-core` the only path. It turns
out our compose testsuite has a lot of hardcoded ideas about
how the two paths work. The rojig tests in particular need
cached RPMs, so we can't just rely on caching the pkgcache repo.
Add a `--download-only-rpms` that always returns RPMs, and doesn't
import into the pkgcache repo.
Closes: #1798
Approved by: jlebon
Note this patch only touches the *new* APIs that aren't part of
libostree.
Now that we can use `g_ptr_array_find_with_equal_func`, we can drop our
custom `_ostree_ptr_array_find`.
Also strengthen our handling of values everywhere to handle the `NULL`
case and properly support `KEYWORD` args. I ended up getting rid of
`_ostree_kernel_arg_query_status` in the process since it made that
assumption a lot and overall added more complexity than necessary.
Closes: #1796
Approved by: cgwalters
When we expect a test to not fail, let's `g_assert_no_error` first so
that if it fails, we get an exact printout of what error we encountered
when we expected none.
Closes: #1796
Approved by: cgwalters
Right now we only print a diff of the pending deployment if we have a
cached update (which only happens if user just did an `upgrade`
operation). But really, we can just always print this for the pending
deployment regardless of whether there's a cached update calculated.
This is prep for changing chained operations to only show the diff
between the previous pending deployment to the new pending deployment.
With this patch, the full diff from booted to pending will always be
available through `status` (and `db diff` too though it's not as nice).
Closes: #1760
Approved by: cgwalters
This brings us back in sync with the latest libdnf git master. This
required a bunch of work both on the libdnf and rpm-ostree side to get
working. See e.g.
https://github.com/rpm-software-management/libdnf/issues/645.
A few things to adapt to:
- soname bump to `libdnf.so.2`
- `DnfAdvisory` is no longer a `GObject` (annoyingly it's not replaced
by something we can keep a ref on, so this requires some hacks to
steal from the `GPtrArray` -- could enhance libdnf for this later)
- disable SWDB history writing
- use new reldep public API
- update for latest `hy_subject_get_best_selector()` API
This now unlocks the possibility to add support for modules. (One can
see hints of this in the diff by the fact that `libdnf` links to
`libmodulemd1`.)
Update submodule: libdnf
Closes: #1404
Approved by: cgwalters
Let's make this test work across major version rebases of the FAHC
treecompose job by not hardcoding a specific `%{dist}` here. It's strong
enough to check that the `deploy` operation has the expected previous
version.
I did bump the FAHC buildroot so that next version of the rojig RPM will
be f29, but I don't want to wait until the job has composed at least two
of them.
Closes: #1787
Approved by: cgwalters
Let's output to `ex-container-logs`, which matches the directory we
currently have specified in `artifacts:` so that we actually get test
logs uploaded.
Closes: #1787
Approved by: cgwalters
Otherwise, glib will complain if the array is empty since it can't infer
the type of the item.
While we're here, just `git grep` all instances of
`G_VARIANT_TYPE_ARRAY` and make sure they use a fully-specified format.
I added a test to sanity check that glib is happy to synthesize empty
`GVariant` arrays from `g_variant_builder()` if the format string is
specified.
Closes: #1783
Approved by: cgwalters
And this (for now at least) completes the epic journey of the
"where's the kernel"? With this it's found solely in
`/usr/lib/modules/$kver`.
There are a few reasons to do this; most prominent is that
it avoids duplicating the content as the locations may have
different SELinux labels.
Closes: #1773
Approved by: jlebon
I'd like to add a new `boot-location: modules`. In prep
for that, let's remove the legacy `both` which drops into
`/boot`.
The libostree support for handling `/usr/lib/ostree-boot` has
existed for over 4 years:
```
commit 37a059925f6b96d30190b65bee6bdde0ae1c6915
Commit: Colin Walters <walters@verbum.org>
CommitDate: Sun Nov 30 23:14:05 2014 -0500
deploy: Ensure that we can deploy using only /usr/lib/ostree-boot
```
I think we assume now that no one is now making *new* treecomposes and needs
a newer rpm-ostree and that they expect people to be able to use as an
upgrade target from a libostree that predates that.
Closes: #1773
Approved by: jlebon
Add a `basearch` key to the manifest. This can be used at compose time
to assert the architecture the compose is running on. Though my
motivation is for the common case where it gets omitted from the input
manifest and gets automatically added by rpm-ostree into
`/usr/share/rpm-ostree/treefile.json` for introspection on the client.
(The crucial part here is that the treefile created by rpm-ostree
remains deserializable into a `TreeComposeConfig`).
Closes: https://github.com/coreos/fedora-coreos-tracker/issues/154Closes: #1766
Approved by: cgwalters
Manually patch `file_contexts.subs_dist` so that `/home` is equivalent
to `/var/home`. This is required now that the generated homedirs rules
use `/var/home`. Otherwise, `matchpathcon` for example will return wrong
results.
This patch also includes the *removal* of `/var/home -> /home` so that
we're not dependent on this selinux-policy patch making it at the same
time as downstream:
https://src.fedoraproject.org/rpms/selinux-policy/pull-request/14
(See the conversation there for more information.)
Closes: #1754
Approved by: cgwalters
It's possible for some postprocessing scripts to affect the final
SELinux policy. This is the case for the new `/etc/default/useradd` edit
we now do (#1726), but it could've been the case beforehand too with
user scripts modifying e.g. booleans (though ideally all these
modifications would be part of RPMs).
Do a final `semodule -nB` during postprocessing so that the final policy
we commit is "up to date". Otherwise, users may only see changes take
effect if they layer packages that trigger a rebuild.
The motivation for this is specifically for `/etc/default/useradd`.
There is magic in `selinux-policy` that parses the file and generates
templated rules from the value of `HOME`.
For more info, see:
https://bugzilla.redhat.com/show_bug.cgi?id=1669982https://src.fedoraproject.org/rpms/selinux-policy/pull-request/14Closes: #1754
Approved by: cgwalters
RPM-OSTree has been pretty good so far at consuming the exact same RPMs
used for traditional OSes without modifications. This is important,
because shielding RPMs from the OSTree abstraction means we remain
compatible with a large portion of the ecosystem.
However, there are some apps that definitely require rethinking their
approach. The example right now is akmods, which has a patch proposed to
build kmods at `%post` time on OSTree systems instead of from the
daemon.[1]
In such situations, scriptlets need something to key off of for the
OSTree-specific approach. The `/run/ostree-booted` file is the de facto
API to determine if we're running on an OSTree system or not. This patch
simply extends this API so that scriptlets can naturally make use of
them.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1667014Closes: #1750
Approved by: cgwalters
There's lots of gyrations here for unified-core vs not; it's
been broken in the case of `--unified-core` for a while I think.
In that case our workdir is tmpdir, so rename that directory.
Closes: #1743
Approved by: jlebon
Teach rpm-ostree to interpret rebases where the remote component is a
path to a local repo, e.g.:
rpm-ostree rebase /mnt/ostree/repo:my/target/ref
Essentially, the local remote in this case is considered "ephemeral".
It's kind of the equivalent of, on traditional systems:
dnf install --repofrompath repo,/path/to/repodata ...
The use case for this is in OpenShift v4, in which upgrades are done
from containers containing the OSTree commit. There, we want to point
RPM-OSTree directly at the repo in the mounted container and rebase to
the checksum.
For now, the option is marked experimental. One major reason for this is
that the way we pass the repo differs on RHEL7 vs other platforms. (See
comment block in `rpmostree-dbus-helpers.c` for details).
Related: https://github.com/openshift/machine-config-operator/issues/314
Co-authored-by: Colin Walters <walters@verbum.org>
Closes: #1732
Approved by: cgwalters
This adds an optional date field to the prefix
passed by automatic_version_prefix. An example of specifying
the field is as follows:
10.<date:%Y>
And the fields progress like:
10.2018.0
10.2018.1
10.2018.2
10.2019.0
The date format creates a new "current date" string using
valid date directives passed into g_date_time_format().
If there is a problem reading the given date format,
an error is given and the next version is returned as NULL.
If no <date:...> tag is detected in the auto version prefix,
the same behavior as before (appending .1 and incrementing) occurs.
This may be helpful to avoid writing glue code to auto-update
the version if a date string in the commit version is desired.
Otherwise, --add-metadata-string=version= is an alternative for
complete customization.
Fixes: #1712Closes: #1721
Approved by: jlebon
We were using `g_strfreev()` to free the string array, but the strings
themselves were owned by the `modifiers` GVariantDict. Fix this and make
the comments about it more explicit. On my computer (and at least
Dusty's), this was only actually tripping up libc when passing more than
just one package on the CLI.
Closes: #1707Closes: #1709
Approved by: cgwalters
When handling `GetDeploymentBootConfig()`, we would trip an assertion
when trying to read the full bootconfig from a staged deployment, which
of course doesn't have a full bootconfig yet. Rework this to add a new
`staged` key to the returned dict, in which case only `options` is
included. (Which is all `rpm-ostree kargs` needs anyway).
Closes: #1708
Approved by: cgwalters
If no cache dir is given in the workdir, we would alias the cache dir fd
to the workdir fd. But of course, this meant that we'd try to close the
same fd twice when freeing the compose context. Instead, let's just copy
the fd as is also done in the non-unified path.
Closes: #1697Closes: #1698
Approved by: lucab
One question I often have when looking at the output of `status -a`:
```
AvailableUpdate:
Version: 29.20181202.0 (2018-12-02T08:37:50Z)
Commit: dece5737a087d5c6038efdb86cb4512f867082ccfc6eb0fa97b2734c1f6d99c3
GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
SecAdvisories: FEDORA-2018-042156f164 Unknown net-snmp-libs-1:5.8-3.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-core-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-extra-4.19.5-300.fc29.x86_64
FEDORA-2018-f467c36c2b Moderate git-core-2.19.2-1.fc29.x86_64
Diff: 67 upgraded, 1 removed, 16 added
```
is "How serious and relevant are these advisories to me? How soon should
I reboot?". For the packages that I'm most familiar with, e.g. `kernel`
and `git-core`, I usually look up the advisory and check why it was
marked as a security update, mentioned CVEs, and how those affect me.
The updateinfo metadata includes a wealth of information that could be
useful here. In Fedora, CVEs treated by the security response team
result in RHBZs, which end up attached to the advisories and thus make
it into that metadata.
This patch tries to reduce friction in answering some of those questions
above by checking for those CVEs and printing a short description in the
output of `status -a`. Example:
```
AvailableUpdate:
Version: 29.20181202.0 (2018-12-02T08:37:50Z)
Commit: dece5737a087d5c6038efdb86cb4512f867082ccfc6eb0fa97b2734c1f6d99c3
GPGSignature: Valid signature by 5A03B4DD8254ECA02FDA1637A20AA56B429476B4
SecAdvisories: FEDORA-2018-042156f164 Unknown net-snmp-libs-1:5.8-3.fc29.x86_64
CVE-2018-18065 CVE-2018-18066 net-snmp: various flaws [fedora-all]
https://bugzilla.redhat.com/show_bug.cgi?id=1637573
FEDORA-2018-87ba0312c2 Moderate kernel-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-core-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-4.19.5-300.fc29.x86_64
FEDORA-2018-87ba0312c2 Moderate kernel-modules-extra-4.19.5-300.fc29.x86_64
CVE-2018-16862 kernel: cleancache: Infoleak of deleted files after reuse of old inodes
https://bugzilla.redhat.com/show_bug.cgi?id=1649017
CVE-2018-19407 kernel: kvm: NULL pointer dereference in vcpu_scan_ioapic in arch/x86/kvm/x86.c
https://bugzilla.redhat.com/show_bug.cgi?id=1652656
FEDORA-2018-f467c36c2b Moderate git-core-2.19.2-1.fc29.x86_64
CVE-2018-19486 git: Improper handling of PATH allows for commands to executed from current directory
https://bugzilla.redhat.com/show_bug.cgi?id=1653143
Diff: 67 upgraded, 1 removed, 16 added
```
Including the CVE name and RHBZ link also makes it easier to look for
more details if desired.
Closes: #1695
Approved by: rfairley
