#10373 Missing statics on registry.fp-o
Closed: Fixed with Explanation 2 years ago by kevin. Opened 2 years ago by darknao.

It seems like registry.fedoraproject.org no longer has access to its static files (css & js are 404).


Can you be more specific what exactly is not working. Looking at https://admin.fedoraproject.org/mirrormanager/statistics I see no errors. Do you mean something else. There are a couple of different statistics.

yeah sorry, I should probably stop doing 2 thing at the same time; I was referring to registry.fedoraproject.org

@cverna is the registry something coreos would like to look after as it is closely related to the work you are doing?

Fedora CoreOS uses quay.io a lot and are not super dependent on registry.fp.o. Couple years ago we discussed about moving registry.fp.o to quay.io also but we were blocked by multi arch support (which is supported by quay now) and flatpak.
@otaylor do you know if we could use quay.io to serve Flatpaks ? I assume yes but you might be more aware than me.

So overall the main users of registry.fp.o are the Fedora container base image (also available on Docker Hub and Quay.io) and Flatpaks.

We were blocked on Flatpaks because of the lack of support for OCI images/manifests, which has been resolved now for quay.io, and in addition Flatpak since switched to using the older Docker v2 image format.

We'd still need to keep flatpak-indexer running and expose its URL at https://registry.fedoraproject.org/index (this URl is in the configuration of Fedora systems so can't change), but the images could hosted on quay.io. [The index points to the registry - it doesn't have to be on the same toplevel URL]

Metadata Update from @mohanboddu:
- Issue priority set to: Waiting on Assignee (was: Needs Review)
- Issue tagged with: low-gain, low-trouble, ops

2 years ago

FWIW the initial ticket,

when browsing registry.fedoraproject.org, the following URLs are unavailable which makes the site render incorrectly:
- https://registry.fedoraproject.org/static/css/styles.css
- https://registry.fedoraproject.org/static/js/scripts.js
- https://registry.fedoraproject.org/static/favicon.ico

Inspect element on the site and remove "static" from these URLs, and the site will render properly.

This seems related to the 'reg' update on sundries01.

<comment deleted>

This seems related to the 'reg' update on sundries01.

It seems reg is not using the custom template files in /var/lib/reg-server/templates... those are installed by the RPM package, then overwritten by ansible on deployment.
On Sundries01 the template files are our custom, I don't understand what template files reg is using when generating the HTMLs....

Are these pages only used to have a list of flatpaks and their tags? Can we just have a simpler python script to generate these pages? I can work on that, so we can get rid of reg which is highly unmaintained... I just need to know where I can get the base data, maybe flatpak-indexer provides a json output?

I think we want to migrate our registry to quay.io and then we don't have to worry about this. ;)

So, I would say we should try and fix this if we can easily, and leave it at that...

So, I would say we should try and fix this if we can easily, and leave it at that...

I suppose something in Go has changed and the actual code cannot read the template files directory... but I don't know Go for trying to modify reg sources.
It seems to me that even if reg doesn't find the template files, it uses a base64 encoded version embedded in its sources, that's why it can still produce an output.

It seems like reg-server is not using local template files anymore since v0.15.7
I would say the easiest way to fix it is to rollback to the previous version that still use local templates (0.15.6 or older) until we move to quay. Or leave it like this.
Third option is to at least fix the css/js loading by adding a rewriterule to redirect /static/(.*) to /$1 or something in the like.

I just fixed it with a /static/ alias on proxies. Hacky, but should be fine for now.

Metadata Update from @kevin:
- Issue close_status updated to: Fixed with Explanation
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.

Metadata
Boards 1
ops Status: Backlog