Red Hat Bugzilla – Bug 988316
Django 1.5 makes change in dashboard config necessary
Last modified: 2016-04-26 16:15:16 EDT
Description of problem:
openstack_dashboard introduced new settings to use with Django-1.5 (required for havana on Fedora):
ALLOWED_HOSTS = ['horizon.example.com', 'localhost']
horizon.example.com should be replaced with the hostname or with the domain:
when using ssl:
# Set SSL proxy settings:
# For Django 1.4+ pass this header from the proxy after terminating the SSL,
# and don't forget to strip it from the client's request.
# For more information see:
# SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTOCOL', 'https')
# If Horizon is being served through SSL, then uncomment the following two
# settings to better secure the cookies from security exploits
#CSRF_COOKIE_SECURE = True
#SESSION_COOKIE_SECURE = True
those options need to become uncommented.
Looks like Fedora 19 is already shipping django 1.5, too:
# rpm -q python-django
But for some reason, my /etc/openstack-dashboard/local_settings did not have the ALLOWED_HOSTS line. Still, it was necessary to add it.
I think I did a F19 Havana-2 installation before and the ALLOWED_HOSTS line existed but it didn't in my most recent test. But maybe I'm just confused.
(In reply to Sandro Mathys from comment #1)
> Looks like Fedora 19 is already shipping django 1.5, too:
> # rpm -q python-django
> But for some reason, my /etc/openstack-dashboard/local_settings did not have
> the ALLOWED_HOSTS line. Still, it was necessary to add it.
> I think I did a F19 Havana-2 installation before and the ALLOWED_HOSTS line
> existed but it didn't in my most recent test. But maybe I'm just confused.
Fedora 19 ships grizzly, which is not compatible with Django-1.5
(In reply to Matthias Runge from comment #2)
> (In reply to Sandro Mathys from comment #1)
> > Looks like Fedora 19 is already shipping django 1.5, too:
> > # rpm -q python-django
> > python-django-1.5.1-1.fc19.noarch
> > But for some reason, my /etc/openstack-dashboard/local_settings did not have
> > the ALLOWED_HOSTS line. Still, it was necessary to add it.
> > I think I did a F19 Havana-2 installation before and the ALLOWED_HOSTS line
> > existed but it didn't in my most recent test. But maybe I'm just confused.
> Fedora 19 ships grizzly, which is not compatible with Django-1.5
As mentioned, I did install Havana-2 (there's a fedora-19 repo at RDO).
So after some quick debugging with Matthias, it seems Packstack in the Havana-2 repo (openstack-packstack-2013.2.1-0.2.dev702.fc20.noarch) does replace local_settings instead of editing it and Packstack's template is actually missing those lines.
That said, Packstack upstream (git master) does not replace it anymore AFAICS so this is issue is fixed once there's a new package.
*** Bug 1006766 has been marked as a duplicate of this bug. ***
Nevermind what I said in comment #4.
It's not directly Packstack's fault anyway, upstream puppet-horizon is having trouble's catching up with upstream Horizon's development. Since Puppet has no way of modifying Python code files, they actually have to deploy it based on a template. If it was an ini-file like most OpenStack configuration, life would be much easier for Puppet. Anyway...
In a first step, I proposed a change to puppet-horizon's local_settings.py.erb to include the options that were newly added to Horizon's local_settings.py.example. That includes ALLOWED_HOSTS.
The SSL stuff is also included but commented out (as in the example). Addressing that will require quite some more work (hopefully of someone with better skills), I guess.
Change is in review here:
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.
More information and reason for this action is here:
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
I believe this can fixed by moving the packstack horizon puppet module commit to this https://github.com/stackforge/puppet-horizon/commit/6cc187f95dc988e1026a52bfbcfc1aebfd672d30 or later.
Note that this problem makes Horizon unusable in a default Havana packstack install until the local_settings file has been altered.
Yes, it does. $fqdn might have to be set by Puppet accordingly, though.
Actually, you really (really!) want all the current changes. Most notably:
openstack-packstack-2013.2.1-0.13.dev840.fc20 has been submitted as an update for Fedora 20.
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing openstack-packstack-2013.2.1-0.13.dev840.fc20'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
openstack-packstack-2013.2.1-0.14.dev846.fc20 has been submitted as an update for Fedora 20.
*** Bug 1036198 has been marked as a duplicate of this bug. ***
Replying to @mrunge's comment on bug #1036198:
In a situation where there is only one host who should connect to Horizon, then setting ALLOWED_HOSTS is great. In a "standard" situation where someone is installing Horizon on a cluster or a single host, and connecting from a different host, we're almost never going to be able to guess correctly which is the correct host - you shouldn't have to do a Google search to figure out how to connect to Horizon.
On my set-up, I am connecting from 192.168.142.1 - I can't use "192.168.142.*" to allow connections from anywhere on the subnet, though.
@Dave: This is about what hostnames Django is allowed to serve, not who is allowed to connect to the dashboard. See https://docs.djangoproject.com/en/1.5/ref/settings/#allowed-hosts for more information. I hope this helps to clarify things.
@Julie: Thanks for the information! I don't see a huge difference between them - since (at least for me) if I connect to Horizon, the IP address of the laptop I connect from is what shows up in both the httpd access.log and is matched against ALLOWED_HOSTS - is Django supposed to be serving Horizon from behind a HA Proxy or something? By default with Packstack we don't install it that way.
Hey, you're welcome, although it looks like I didn't do a very good job of explaining still.
ALLOWED_HOSTS matches the hostname (or IP) used in the URL - the horizon server's hostname/IP. Not the IP of the machines that connect to it.
In your example in comment 17, if horizon lives on 192.168.142.1 and this IP is in ALLOWED_HOSTS, anyone else on the subnet can access horizon no matter their own IP, provided they type '192.168.142.1' in the URL bar.
(In reply to Julie Pichon from comment #20)
> Hey, you're welcome, although it looks like I didn't do a very good job of
> explaining still.
> ALLOWED_HOSTS matches the hostname (or IP) used in the URL - the horizon
> server's hostname/IP. Not the IP of the machines that connect to it.
> In your example in comment 17, if horizon lives on 192.168.142.1 and this IP
> is in ALLOWED_HOSTS, anyone else on the subnet can access horizon no matter
> their own IP, provided they type '192.168.142.1' in the URL bar.
if that is the case, then packstack configures allowed hosts correctly and there is a bug upstream, either in django or in httpd.
in Bug 1036198 that ip is the horizon host's ip. and yet i wasnt able to connect to it from the physical host without a horizon error showing up.
i am curious as to what you see when in horizon when your allinone installation is complete.
are you trying to connect via IP address or via hostname? This is the main difference here.
hostname from the network.
fixed in last nights release (ip, fqdn)