Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 988316 - Django 1.5 makes change in dashboard config necessary
Django 1.5 makes change in dashboard config necessary
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: openstack-packstack (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Julie Pichon
Fedora Extras Quality Assurance
:
: 1006766 1036198 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-25 05:47 EDT by Matthias Runge
Modified: 2016-04-26 16:15 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-11-17 07:12:28 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Launchpad 1223317 None None None Never
OpenStack gerrit 54606 None None None Never

  None (edit)
Description Matthias Runge 2013-07-25 05:47:25 EDT
Description of problem:
openstack_dashboard introduced new settings to use with Django-1.5 (required for havana on Fedora):

in /etc/openstack-dashboard/local_settings:
ALLOWED_HOSTS = ['horizon.example.com', 'localhost']
horizon.example.com should be replaced with the hostname or with the domain:
https://docs.djangoproject.com/en/dev/ref/settings/#allowed-hosts

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:
# https://docs.djangoproject.com/en/1.4/ref/settings/#secure-proxy-ssl-header
# 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.
Comment 1 Sandro Mathys 2013-08-16 04:52:46 EDT
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.
Comment 2 Matthias Runge 2013-08-16 04:54:16 EDT
(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
Comment 3 Sandro Mathys 2013-08-16 04:56:32 EDT
(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).
Comment 4 Sandro Mathys 2013-08-16 05:15:52 EDT
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.
Comment 5 Sandro Mathys 2013-09-13 09:28:39 EDT
*** Bug 1006766 has been marked as a duplicate of this bug. ***
Comment 6 Sandro Mathys 2013-09-13 09:37:20 EDT
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:
https://review.openstack.org/#/c/46491/1/templates/local_settings.py.erb
Comment 7 Xavier Queralt 2013-09-13 09:46:01 EDT
*** Bug 1006766 has been marked as a duplicate of this bug. ***
Comment 8 Fedora End Of Life 2013-09-16 10:50:30 EDT
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:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 9 Fedora Admin XMLRPC Client 2013-10-14 05:50:28 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 10 Fedora Admin XMLRPC Client 2013-10-14 05:50:57 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 11 Ben Nemec 2013-10-30 17:11:12 EDT
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.
Comment 12 Sandro Mathys 2013-10-30 17:53:09 EDT
Yes, it does. $fqdn might have to be set by Puppet accordingly, though.

Actually, you really (really!) want all the current changes. Most notably:
https://github.com/stackforge/puppet-horizon/commit/4fabab3b63c73685f335ce334f1dad69ae848926
and
https://github.com/stackforge/puppet-horizon/commit/ae419046c4156ee235915719b8df74f3fb031ad4
Comment 13 Fedora Update System 2013-11-04 11:17:33 EST
openstack-packstack-2013.2.1-0.13.dev840.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.13.dev840.fc20
Comment 14 Fedora Update System 2013-11-05 14:58:21 EST
Package openstack-packstack-2013.2.1-0.13.dev840.fc20:
* 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:
https://admin.fedoraproject.org/updates/FEDORA-2013-20689/openstack-packstack-2013.2.1-0.13.dev840.fc20
then log in and leave karma (feedback).
Comment 15 Fedora Update System 2013-11-13 08:24:45 EST
openstack-packstack-2013.2.1-0.14.dev846.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/openstack-packstack-2013.2.1-0.14.dev846.fc20
Comment 16 Matthias Runge 2013-12-02 06:49:52 EST
*** Bug 1036198 has been marked as a duplicate of this bug. ***
Comment 17 Dave Neary 2013-12-02 07:01:05 EST
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.
Comment 18 Julie Pichon 2013-12-02 07:12:59 EST
@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.
Comment 19 Dave Neary 2013-12-02 08:30:48 EST
@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.

Thanks,
Dave.
Comment 20 Julie Pichon 2013-12-02 09:25:13 EST
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.
Comment 21 Mohammed Arafa 2013-12-03 07:34:49 EST
(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.

jpichon
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.
Comment 22 Matthias Runge 2013-12-03 07:48:54 EST
Mohammed,
are you trying to connect via IP address or via hostname? This is the main difference here.
Comment 23 Mohammed Arafa 2013-12-03 14:52:41 EST
hostname from the network.
Comment 24 Mohammed Arafa 2013-12-04 07:44:59 EST
fixed in last nights release (ip, fqdn)

Note You need to log in before you can comment on or make changes to this bug.