New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Static Media Failure, episode #2 #39
Comments
We had a similar issue when upgrading from Netbox 2.9 to 2.10 (still with nginx and gunicorn containers). We had to chmod the static folder (holding static files).
|
I think with the change to NGINX Unit this requires changing/overriding the Alternatively you might be able to do something similar with NGINX Ingress rewrites, or potentially your chosen Ingress controller: just strip your chosen base path off the URL if the request is for |
Hey were you able to make it work? |
I was able to make this work! Totally nightmare but here is the solution to make it work using /netbox basePath:
This second ingress will rewrite any /netbox/static to /static. Hope this helps. |
Nice workaround @besteban1989, thanks for documenting it here! |
Be great to somehow template this, based on eg a new
|
I'd rather keep workarounds like this out of the chart to be honest. I'd be happy to have a note in the README saying how to deal with this particular issue with the NGINX Ingress, for example, but I don't think it belongs behind a flag in the chart. |
I was nearly finished creating a PR. Everyone who uses nginx and a path will experience this issue, possibly everyone who uses a path. Pretty common, no? These people will either have hard-coded hostname, path, namespace, etc or will have a messy task doing helm's job and templating them. Let me know if you change your mind. |
Hi and thanks for maintaining this helm!
Running release 3.0.0, we are seeing the following when browsing to http://HOST.NET/netbox:
despite
basePath
andingress.hosts[].paths[]
being set in values.yaml:The unit access logs seems to indicate that there might be an extra /netbox prefix leading to the 404s:
Given the unit conf.json:
#18 described a very similar issue back in May 2020, and commit e87f196 supposedly fixed it then. I suspect this might be related to the upstream's migration from Gunicorn to NGINX Unit, but I have not been able to figure out a fix yet.
The text was updated successfully, but these errors were encountered: