4933: Missing CSS and JS files (/static ?) after migration to official container


What version are you running?

3.0.21, 4.0.3

What's the URL of the page containing the problem?


What steps will reproduce the problem?

  1. Just connect

What is the expected output? What do you see instead?

A regular page

What operating system are you using? What browser?


Please provide any additional information below.

Until doday we are running unofficial contauers ducatel/reviewboard (https://github.com/Ducatel/reviewboard). Today I have switched to containers provided by beanbag, fist 3.0.21 and then 4.0.3. In both cases the the css and js files are not accesible.

#1 kofemann

This is what I see on the console:

[2021-07-07 14:25:03 +0000] [61] [DEBUG] GET /static/djblets/js/datagrid.min.c3b715397200.js
WARNING:django.request:Not Found: /static/djblets/js/datagrid.min.c3b715397200.js

However the file exists:

root@rb-pod:/# ls -l /site/htdocs/static/djblets/js/datagrid.min.c3b715397200.js
-rw-r--r--. 1 root root 9281 Jun 29 08:49 /site/htdocs/static/djblets/js/datagrid.min.c3b715397200.js

Moreover, the direct get from the container returs an error:

root@rb-pod:/# curl -v localhost:8080/static/djblets/js/datagrid.min.c3b715397200.js
*   Trying ::1:8080...
* connect to ::1 port 8080 failed: Connection refused
*   Trying
* Connected to localhost ( port 8080 (#0)
> GET /static/djblets/js/datagrid.min.c3b715397200.js HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.68.0
> Accept: */*
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Server: gunicorn
< Date: Wed, 07 Jul 2021 14:29:39 GMT
< Connection: keep-alive
< Content-Type: text/html
< Vary: Accept-Language
< Content-Language: en
< ETag: "571e88fb6da35fec3989eca6b40f5e20"
< Content-Length: 26
< X-Frame-Options: SAMEORIGIN
* Connection #0 to host localhost left intact
<h1>Bad Request (400)</h1>root@rb-pod:/# 
#2 kofemann

And more info:

2021-07-07 16:44:02 +0000] [60] [DEBUG] GET /static/djblets/js/extensions.min.89cfb166357d.js
Error rendering TemplateHook <rbpowerpack.extension.hooks.LicenseBannerTemplateHook object at 0x7f9b23599bb0>: Reverse for 'powerpack-apply-license' not found. 'powerpack-apply-license' is not a valid view function or pattern name.
Traceback (most recent call last):
  File "/venv/lib/python3.8/site-packages/django/core/handlers/exception.py", line 41, in inner
    response = get_response(request)
  File "/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 249, in _legacy_get_response
    response = self._get_response(request)
  File "/venv/lib/python3.8/site-packages/django/core/handlers/base.py", line 172, in _get_response
    resolver_match = resolver.resolve(request.path_info)
  File "/venv/lib/python3.8/site-packages/django/urls/resolvers.py", line 394, in resolve
    raise Resolver404({'tried': tried, 'path': new_path})

No Powerpack is configured.

#3 kofemann

Sorry for the noise. It was not obvious that static content requires extra web server.

#4 kofemann

Some comments on docu improvement to let others to avoid the same mistakes:

  • The volume binding in the docker run command should be as <local_path>:/site (site vs. sitedir)
  • The extra server configuration should be un the top of the page, as in step-by-stel approach css files not available
  • Extra note on SELinux is required. I failed to allow podman and nginx to access the same directory in parallel and finally have disabled selinux
#5 chipx86

Sorry you had to deal with this.. Yeah, Django/Gunicorn does not serve up static media, so something like nginx is required. The Serving Content docs are intended to cover this, but we need to make some adjustments, as people often miss this.

We'll fix up the sitedir/site issue. Definitely a problem that's probably confused plenty of people.

What did you need to run for SELinux? We can add that to the docs.

#6 kofemann

The local path, /data/reviewboard in my case, should have two lables: httpd_sys_content_t for nginx and svirt_sandbox_file_t for access from a contaier. I failed to apply both. Thus just have disabld the selinux completly by changing /etc/selinux/config file. Eventually I would go back and try to enable it again.