Before, when systemd was not present (for instance in a container), the
preun script would error out.
This checks if systemd is present and running in the same way the
systemd rpm macros do.
Fixes#1915
This is necessary for the new simplified release process and is done
ahead of time once for the upcoming release now.
After osbuild-composer 37 this will be done by the GitHub composite action.
dnf-json provides files that osbuild-composer used to provide, so they
should be marked as conflicting.
Signed-off-by: Achilleas Koutsou <achilleas@koutsou.net>
Exclude the `armv7hl` architecture, since osbuild-composer does not
support building images for it.
Fix#1839
Signed-off-by: Tomas Hozza <thozza@redhat.com>
The main changes are:
- Kind, Href, Id fields for every object returned
- Attach operationIds to each request, return it for errors
- Errors are predefined and queryable
The variables are set to the git revision from which the build is
triggered and rpm version from the spec file, if it is build using RPM.
This can be later used to query exact source version while
running osbuild-composer.
It is necessary to use both, because none of them is available in all
possible scenarios.
Use either git-rev (preferably) or RPM version (NEVRA) instead of the
"devel" build type. It was just a placeholder.
V2 is compliant with api.openshift.com design guidelines.
Errors are predefined, have codes, and are queryable.
All requests have an operationId set: a unique identifier which is
sortable by time. This is added to the response in case of an error.
All returned objects have the href, id, and kind field set.
We don't want to give the impression we support building Fedora on RHEL or
CentOS Stream, or CentOS Stream on RHEL, so drop these repositories from
the package.
Also adjust dnf-json to use test repositories, rather than the upstream ones.
These are shipped in the test package, so makes sure we are unaffected by
what is shipped in the RPM shipped in the distros.
The golang-github-osbuild-composer package was created by mistake a long
time ago. Stop providing it in Fedora 34 and newer and add a note about
removing the condition when Fedora 33 hits EOL.
2 configurations for the listeners are now possible:
- enableJWT=false with client ssl auth
- enableJWT=true with https
Actual verification of the tokens is handled by
https://github.com/openshift-online/ocm-sdk-go.
An authentication handler is run as the top level handler, before any
routing is done. Routes which do not require authentication should be
listed as exceptions.
Authentication can be restricted using an ACL file which allows
filtering based on JWT claims. For more information see the inline
comments in ocm-sdk/authentication.
As an added quirk the `-v` flag for the osbuild-composer executable was
changed to `-verbose` to avoid flag collision with glog which declares
the `-v` flag in the package `init()` function. The ocm-sdk depends on
glog and pulls it in.
Release osbuild-composer 32
Signed-off-by: Simon Steinbeiss <simon.steinbeiss@redhat.com>
Co-Developed-by: Christian Kellner <christian@kellner.me>
Co-Developed-by: Tom Gundersen <teg@jklm.no>
Add the new stages included in osbuild 30 that can be used to
deploy an OSTree commit as well as the grub iso stage that
is used to configure grub2 (efi) for isos.
Bump the spec file requirement accordingly.
Co-Developed-by: Achilleas Koutsou <achilleas@koutsou.net>
Co-Developed-by: Christian Kellner <christian@kellner.me>
Introduce a test case where 2 httpd proxies are used to simulate custom
repos with custom subscriptions. That is, every repo requires
client-side tls certificate with its own CA. Make sure both osbuild and
osbuild-composer can use these repositories by issuing an image build.
The problem: osbuild-composer used to have a rather uncomplete logic for
selecting client certificates and keys while fetching data from
repositories that use the "subscription model". In this scenario, every
repo requires the user to use a client-side TLS certificate. The problem
is that every repo can use its own CA and require a different pair of
a certificate and a key. This case wasn't handled at all in composer.
Furthermore, osbuild-composer can use remote workers which complicates
things even more.
Assumptions: The problem outlined above is hard to solve in the general
case, but Red Hat Subscription Manager places certain limitations on how
subscriptions might be used. For example, a subscription must be tight to
a host system, so there is no way to use such a repository in osbuild-composer
without it being available on the host system as well.
Also, if a user wishes to use a certain repository in osbuild-composer it
must be available on both hosts: the composer and the worker. It will come
with different pair of a client certificate and a key but otherwise, its
configuration remains the same.
The solution: Expect all the subscriptions to be registered in the
/etc/yum.repos.d/redhat.repo file. Read the mapping of URLs to certificates
and keys from there and use it. Don't change the manifest format and let
osbuild guess the appropriate subscription to use.
Not proud of the fix but it should work for now. See the comment in the spec
file for more information and also the upstream PR for more context:
https://github.com/getkin/kin-openapi/pull/351
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
This uses an image created and uploaded to Azure using composer-cli
and then terraform to spin up a linux vm from that image, check
if the machine works and then cleans up everything.
By default, `qemu-img convert` creates qcow2 images usable in qemu 1.1 and
newer. RHEL 8 guest images are meant to be bootable on RHEL 6 though.
Unfortunately, RHEL 6 has qemu 0.12, therefore these images cannot be used
there.
To fix this, we need to use the new qcow2_compat option in qemu assembler
to override the default compat version and make qcow2 images that can be used
in qemu 0.10 and newer.
For this, we need osbuild 28 that isn't yet available in of any of
downstreams, therefore we need to pin it everywhere.
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
genisoimage might be removed from RHEL 9. The users are advised to switch
to mkisofs tools from the xorriso package. It should be a drop-in replacement.
The same change was recently done by libguestfs:
efb8a766ca2216ab2e32
Signed-off-by: Ondřej Budai <ondrej@budai.cz>
The previous version referred to lorax-composer as the definition of
what osbuild-composer does. This worked fine while osbuild-composer was
considered an alternative for it. Now that osbuild-composer is the
default one, it should describe what it does without references to
lorax. Furthemore, composer is now able to build OSTree commits as well
as VM images, to the previous description was slightly incomplete.
This commit introduces description which is up-to-date and does not
refer to lorax any more.
The tools/provision.sh script is sourced by all test cases and it sets
up the system and software for running test cases. As part of the setup,
it copied over the whole content of test/data/composer/ to
/etc/osbuild-composer. However the source directory contains not only
osbuild-composer's configuration, but also configuration for the worker.
The worker however expects its configuration in /etc/osbuild-worker.
The fact that provision.sh does not copy the worker configuration to the
correct directory didn't affect the CI, because the only test case that
relied on it is koji.sh, which copies the worker configuration
explicitly.
Move osbuild-worker test configuration to a separate 'test/data/worker/'
subdirectory. Also install the osbuild-worker test configuration to its
own subdirectory in the "-test" RPM.
Move the copying of worker configuration to the correct destination
directory from koji.sh to provision.sh, so that all test cases can rely
on the system being set up properly. Do not use wildcard for copying
osbuild-{composer,worker} configuration files, but explicitly copy each
file to its respective destination directory.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
Add new internal upload target for Google Cloud Platform and
osbuild-upload-gcp CLI tool which uses the API.
Supported features are:
- Authenticate with GCP using explicitly provided JSON credentials
file or let the authentication be handled automatically by the
Google cloud client library. The later is useful e.g. when the worker
is running in GCP VM instance, which has associated permissions with
it.
- Upload an existing image file into existing Storage bucket.
- Verify MD5 checksum of the uploaded image file against the local
file's checksum.
- Import the uploaded image file into Compute Node as an Image.
- Delete the uploaded image file after a successful image import.
- Delete all cache files from storage created as part of the image
import build job.
- Share the imported image with a list of specified accounts.
GCP-specific image type is not yet added, since GCP supports importing
VMDK and VHD images, which the osbuild-composer already supports.
Update go.mod, vendor/ content and SPEC file with new dependencies.
Signed-off-by: Tomas Hozza <thozza@redhat.com>
In order to add the newly supported sysconfig stage, the osbuild
dependency needs to be updated to version 24. The version is updated to
24 in the specfile and README. Also, for testing purposes, the Schutzfile
now points to the commit hash for osbuild version 24 for rhel-8.3 tests.
