This repository has been archived by the owner on Jan 6, 2023. It is now read-only.
tools/test-setup.sh: Add workaround for CI failures on CentOS and fix Ubuntu support #39
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The libssl bundled with vagrant is not compatible with the one coming from CentOS 8.2, leading to failures like: /opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require': /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b The details seems to be that CentOS has backported some newer OpenSSL functions (eg EVP_KDF_ctrl) and patched krb5 to use them. Which means that there's no way that /lib64/libk5crypto.so.3 works with vagrant bundled OpenSSL. This should be probably fixed on vagrant rpm side, but for now rebuild krb5 to workaround the issue. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
dnf download (as user) failed in zuul with error: + dnf download --enablerepo=BaseOS-source --disablerepo=epel-source --disablerepo=epel --source krb5-libs enabling AppStream-source repository enabling extras-source repository enabling epel-modular-source repository [Errno 13] Permission denied: '/var/cache/dnf/expired_repos.json' This more or less looks like https://bugzilla.redhat.com/show_bug.cgi?id=1636909 but modifying/changing dnf is obviously not an option so try using 'dnf makecache' to workaround the issue. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
Codecheck lint check found this spelling error, so fix it. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
Previous commit was not enough to solve the permission issue and I've yet to reproduce it with the official CentOS 8.2 vagrant libvirt box. As an other possible solution, use sudo to download the .src.rpm. It's working since the test user only needs to be able to read the .src.rpm. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
- remove "build-dep" dependency as it doesn't exist. Replace it with build-essential, even if the idea was probably to use "apt-get build-dep vagrant ruby-libvirt" as it the vagrant-libvirt doc - Install python3/python3-dev - Install qemu-system/qemu-utils. This has been tested on debian 10 (with Debian's official vagrant and vagrant-libvirt package) and on Xenial with hashicorp debian package and manually installed vagrant-libvirt. The only remaining possible test to do would be to try installing vagrant-libvirt manually and using the offician Debian/Ubuntu vagrant packages but I'm not sure it's a case needed for now. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
- don't use rpm on Debian distribution family - detect apt-get on Debian distribution family. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
- the workaround for https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1588004 doesn't seem to be needed anymore - Xenial has a too old version of vagrant, leading to failure with alpine boxes (missing trigger support), so remove vagrant in this case and use Hashicorp debian package. Since this commit is adding a 3rd hack for vagrant setup, I've used a 'case' relying on /etc/os-release to detect the distribution name and then detect the distribution version. Unfortunately, doesn't work with the case of centos 8.2 since the version is 8 so the test on /etc/centos-release remains. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
The usermod command line is run on the same session as the one running vagrant. This means that the current user is not in the libvirt group when vagrant is called. It should be failing, as in Xenial, but the libvirt socket rights are 0777 on Debian buster / Centos 8 / Fedora 31 which means that the bug was not noticed before. Since I don't want to use exec -l (in order to get the "vagrant destroy -f" command), I've choosen to use "sudo su -l "$(whoami)" -c " instead. Not really nice but works. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
apatard
changed the title
|
recheck |
While the workaround for centos 8.2 issue CI is working fine locally, it fails on Zuul with: error: Bad source: /home/zuul/rpmbuild/SOURCES/krb5-1.17-pdfs.tar: No such file or directory The issue is not certain, so: - make sure we're using $HOME/rpmbuild/SOURCES to extract and build kbr5 - make cpio verbose. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
While trying to get a test setup near to the zuul CI, it seems that make is installed here but not in Zuul, so add it to the bindep.txt file, as done for CentOS 7. Signed-off-by: Arnaud Patard <apatard@hupstream.com>
|
recheck |
3 similar comments
|
recheck |
|
recheck |
|
recheck |
ssbarnea
approved these changes
Jul 21, 2020
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The libssl bundled with vagrant is not compatible with the one coming
from CentOS 8.2, leading to failures like:
/opt/vagrant/embedded/lib/ruby/2.4.0/rubygems/core_ext/kernel_require.rb:55:in `require': /lib64/libk5crypto.so.3: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b
The details seems to be that CentOS has backported some newer OpenSSL functions
(eg EVP_KDF_ctrl) and patched krb5 to use them. Which means that there's no
way that /lib64/libk5crypto.so.3 works with vagrant bundled OpenSSL.
This should be probably fixed on vagrant rpm side, but for now rebuild krb5
to workaround the issue.
Signed-off-by: Arnaud Patard apatard@hupstream.com