This option is less open/permitting, but should be good enough since
we are currently running F32 builders and haven't messed with the
crypto policy value. According to
https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2#Upgrade.2Fcompatibility_impact
the `DEFAULT:FEDORA32` should be the first step and only when it is
not good enough, then we should fallback to `LEGACY`.
Thank you @nirik
For newer ssh (in fedora) we need to have certs that are not using
sha-1. So, we need to regenerate the certs signed by our CA with sha256.
While we are at it, enable the ed25519 host keys as rsa keys are
increasingly in disfavor.
So, old ssh will use the old rsa host certs that are sha1 for now, but
new ssh will use the sha256 signed ed25519 certs. If everything works
fine for a while, we can resign the rsa host keys also and totally get
rid of the sha1 certs.
Since both host keys are signed by our CA, they should still be just as
trusted as before. If you are asked to approve a new host key for
something, make sure you have our CA in your known_hosts file:
https://admin.fedoraproject.org/ssh_known_hosts
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
It was redirecting it to the old fedorainfracloud ip.
Then it wasn't proxying to openshift.
When moving to prod, the conditionals here should be removed.
Signed-off-by: Kevin Fenzi <kevin@scrye.com>
This works just fine now:
$ mock --enable-network -r fedora-rawhide-x86_64 --shell
...
<mock-chroot> sh-5.0# curl https://copr.fedorainfracloud.org/
curl: (6) Could not resolve host: copr.fedorainfracloud.org
Otherwise we get following error
Please login as the user "fedora" rather than the user "root".
Which messes up our variables - `$fedora` contains the `Please login
as the user "fedora" rather than the user "root".` warning and
therefore `new_volume_name` is
copr-builder-x86_64-fPlease login as the user "fedora" rather than the user "root".-20201101_155103
If we're running in prod, we probably want two workers in prod
and one in stg. Two in each would be better...
Signed-off-by: Adam Williamson <awilliam@redhat.com>
On client end, restart mount unit (with daemon-reload) if mount
file changes. On server end, run exportfs -r if export config
file changes.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
It's alive again now (thanks smooge), and I want to enable
aarch64 testing in production, so add it as a prod worker (and
tap and hdd worker).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
