Changes in the master branch (and daily build packages) now check the ALLOWED_HOSTS setting for each master in your instance(s) in /etc/lava-server/settings.conf
Please check your /etc/lava-server/settings.conf support for ALLOWED_HOSTS in Django as this will be required to upgrade to the next release of LAVA Software.
Remember to always restart lava-server-gunicorn after any change to /etc/lava-server/settings.conf
See also https://master.lavasoftware.org/static/docs/v2/pipeline-debug.html#check-lav... and https://master.lavasoftware.org/static/docs/v2/pipeline-debug.html#displayin... (new help sections on using and checking LAVA setttings.
Django docs: https://docs.djangoproject.com/en/1.11/ref/settings/#allowed-hosts
""" This is a security measure to prevent HTTP Host header attacks, which are possible even under many seemingly-safe web server configurations. ... Django also allows the fully qualified domain name (FQDN) of any entries. Some browsers include a trailing dot in the Host header which Django strips when performing host validation. ... When DEBUG is True and ALLOWED_HOSTS is empty, the host is validated against ['localhost', '127.0.0.1', '[::1]']. """
If this setting is wrong, updated LAVA packages will fail to serve HTTP and the /var/log/lava-server/django.log file will record messages like:
ERROR 2018-11-26 18:12:52,091 exception Invalid HTTP_HOST header: 'lava.codehelp.co.uk'. You may need to add 'lava.codehelp.co.uk' to ALLOWED_HOSTS.
(In this case, that was exactly the correct action)
"ALLOWED_HOSTS": ["lava.codehelp.co.uk"], to /etc/lava-server/settings.conf and restarting lava-server-gunicorn fixed lava.codehelp.co.uk
See also https://git.lavasoftware.org/lava/lava/issues/173
When checking this change, it is useful to also set DEBUG to true as Django will then show you all of the headers and environment variables. Do remember to turn DEBUG back to false because these variables are a security risk in themselves.
Another setting which might be useful, depending on your configuration:
"USE_X_FORWARDED_HOST": true,
It is safe to make this change in advance of the upgrade of LAVA but do test on an instance which is as close as possible to the network configuration of your production instance(s).
On Tue, 27 Nov 2018 at 10:45, Neil Williams neil.williams@linaro.org wrote:
Changes in the master branch (and daily build packages) now check the ALLOWED_HOSTS setting for each master in your instance(s) in /etc/lava-server/settings.conf
Along with this, there is also a change in /etc/apache2/sites-available/lava-server.conf related to this support.
In the section already covering Proxy* and gunicorn, add a line: ProxyPreserveHost On
See https://git.lavasoftware.org/lava/lava/merge_requests/244/diffs
This is a missing part of the gunicorn support which is safe to deploy now but will be necessary when the next release of LAVA is installed on your master (i.e. lava-server).
Most instances will have some modifications to /etc/apache2/sites-available/lava-server.conf so this update cannot be done automatically when the package is installed. Admins will need to manually update the file (either directly or via the preferred configuration management tool).
After this change, reload the configuration using:
service apache2 reload
(Restart isn't needed and reload is quicker, depending on your preference as admin.)
Please check your /etc/lava-server/settings.conf support for ALLOWED_HOSTS in Django as this will be required to upgrade to the next release of LAVA Software.
Remember to always restart lava-server-gunicorn after any change to /etc/lava-server/settings.conf
See also https://master.lavasoftware.org/static/docs/v2/pipeline-debug.html#check-lav... and https://master.lavasoftware.org/static/docs/v2/pipeline-debug.html#displayin... (new help sections on using and checking LAVA setttings.
Django docs: https://docs.djangoproject.com/en/1.11/ref/settings/#allowed-hosts
""" This is a security measure to prevent HTTP Host header attacks, which are possible even under many seemingly-safe web server configurations. ... Django also allows the fully qualified domain name (FQDN) of any entries. Some browsers include a trailing dot in the Host header which Django strips when performing host validation. ... When DEBUG is True and ALLOWED_HOSTS is empty, the host is validated against ['localhost', '127.0.0.1', '[::1]']. """
If this setting is wrong, updated LAVA packages will fail to serve HTTP and the /var/log/lava-server/django.log file will record messages like:
ERROR 2018-11-26 18:12:52,091 exception Invalid HTTP_HOST header: 'lava.codehelp.co.uk'. You may need to add 'lava.codehelp.co.uk' to ALLOWED_HOSTS.
(In this case, that was exactly the correct action)
"ALLOWED_HOSTS": ["lava.codehelp.co.uk"], to /etc/lava-server/settings.conf and restarting lava-server-gunicorn fixed lava.codehelp.co.uk
See also https://git.lavasoftware.org/lava/lava/issues/173
When checking this change, it is useful to also set DEBUG to true as Django will then show you all of the headers and environment variables. Do remember to turn DEBUG back to false because these variables are a security risk in themselves.
Another setting which might be useful, depending on your configuration:
"USE_X_FORWARDED_HOST": true,It is safe to make this change in advance of the upgrade of LAVA but do test on an instance which is as close as possible to the network configuration of your production instance(s).
--
Neil Williams
neil.williams@linaro.org http://www.linux.codehelp.co.uk/
lava-announce@lists.lavasoftware.org
-
Neil Williams