The backend uses urlretrieve() to download comps.xml from the frontend
at /coprs/<user>/<project>/chroot/<chroot>/comps/. Since this path is
under /coprs/ which is protected by Anubis, the backend receives the
JavaScript challenge page instead of the actual comps data.
This HTML then gets saved as comps.xml and included in the repository
metadata, causing users to download Anubis challenge HTML instead of
the actual comps.xml.gz file.
We cannot simply use the same Copr path but on Pulp, because the
directory structure is different.
Copr:
@copr/copr-dev/fedora-43-x86_64/09975054-copr-cli/copr-cli-2.4.post1-1.git.12.8aed90c.fc43.src.rpm
Pulp:
@copr/copr-dev/fedora-43-x86_64/Packages/c/copr-cli-2.4.post1-1.git.12.8aed90c.fc43.src.rpm
Anubis was accidentally enabled for all traffic (/) instead of just
the /coprs/ web UI. This caused unnecessary bot challenges for API
clients, dnf/yum, and other automated tools.
Use Anubis BASE_PREFIX to cleanly protect only specific endpoints:
- Frontend: /coprs/ (web UI)
- Dist-git: /{{ cgit_uri }}/ (package browser)
https://anubis.techaro.lol/docs/admin/installation#using-base-prefix
This is mostly adding aarch64 runs of existing tests, but also
we add the new desktop_graphics_validation test on both arches,
and desktop_keyring on KDE which wasn't run before for no good
reason.
All of these were turned on in openQA itself last year. The most
recent is desktop_graphics_validation which was added 2025-11-28.
All the others have been running since at least 2025-11-19. I'll
check for any old, stuck updates which need any of these run
manually.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This tweaks the Forgejo redirect-to-pagure-for-attachments stuff
to work for prod as well as staging, since we proved it out in
staging and we do want it to actually work for prod migrations.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Moved to openshift in 2022 (see e.g. ab4db44) and was dropped from
the haproxy config in 55056c6, nothing listens on 10022 on the
proxies these days.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
See cb22afd (removed ask config in 2018). It's been gone since
then. Nothing listens on 10021 on the proxies.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
See 5413a21 (noting it was moved to openshift in 2020) and
55056c6 (removed it from haproxy config).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
Was moved to openshift long ago. All of these URLs are now just
302s to bodhi.fedoraproject.org in the httpd config. Nothing
listens on port 10009 on the proxies.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
I'm pretty sure this is a vestige of FAS2. 'fas01' resolves on
*most* proxies, but to an IP address that doesn't exist. On
proxy01.stg (but not proxy02.stg for some reason?) it does not
resolve at all, and this causes varnish to fail to start up.
Let's just get rid of it.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This is a bit ugly, but can't think of a better way right now.
Since @kparal is using this migration of testdays-web from prod
pagure to staging forgejo as a test case for prod migrations in
general, let's make sure it works properly by proxying attachment
requests to prod pague instead of staging.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This turned out to be a bit complicated, see
https://codeberg.org/forgejo/forgejo/issues/6360#issuecomment-9010932 . Pagure
images in comments use root-relative Markdown links, like this:
but Forgejo renders those relative to *the repo*, not the server root, so
they get rendered as something like:
<img src="/forgejoorg/forgejorepo/group/repo/issue/raw/files/image.png">
However, it does *not* do this for *non-image* root-relative links, so those
aren't 'broken'. This means we need to handle *both* cases in the proxying,
and we also need to keep in mind that Pagure allows repos without a group.
So we can wind up with one, two, three or four folders before /issue.
I did some testing and I *think* this should cover all cases. I've tested
this does fix images, I haven't tested on a non-image attachment yet (need
to find one).
Signed-off-by: Adam Williamson <awilliam@redhat.com>
The attachment reverse proxy was failing for several reasons, one
of which is that SSL options weren't set up correctly so the SSL
connection to pagure.io failed. This adds a Proxy section for
stg.pagure.io with the appropriate settings to make it work.
There are still several other issues, but this at least fixes the
SSL problem.
Signed-off-by: Adam Williamson <awilliam@redhat.com>
