Apache WSGI config shipping with Keystone is incompatible with Horizon

Bug #1799332 reported by Mike Joseph
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Identity (keystone)
Triaged
Low
Unassigned

Bug Description

The documentation needs to be changed to cover that we do not recommend running keystone on a high port but instead on it's own host or under a sub-url.

This is not something we need to fix in the example WSGI file.

We should also change documentation to recommend uwsgi over mod_wsgi in all cases.

---- Below this point is kept for historical reasons ----

In keystone/httpd/wsgi-keystone.conf, the following configuration is present:

Alias /identity /usr/local/bin/keystone-wsgi-public
<Location /identity>
    SetHandler wsgi-script
    Options +ExecCGI

    WSGIProcessGroup keystone-public
    WSGIApplicationGroup %{GLOBAL}
    WSGIPassAuthorization On
</Location>

However, it is both harmful and unnecessary. The operative WSGI configuration for Keystone comes from the <VirtualHost *:5000>...</VirtualHost> section. In fact, the commit which added the /identity endpoint described it as an documentation example:

"Apache Httpd can be configured to accept keystone requests on all
sorts of interfaces. The sample config file is updated to show
how to configure Apache Httpd to also send requests on /identity
and /identity_admin to keystone."

Leaving it in place, however, causes conflicts when Horizon is concurrently installed:

AH01630: client denied by server configuration: /usr/bin/keystone-wsgi-public

...in responses to Horizon URL's referencing '/identity'. Therefore, I believe keeping this configuration snippet in the shipped WSGI configuration (as opposed to actual documentation) is a defect.

Revision history for this message
Morgan Fainberg (mdrnstm) wrote :

It is recommended keystone NOT be deployed on non-http/https (80/443) ports. If you would like to use a Vhost on a different port it is up to the deployer/installation tools to make that decision. The provided wsgi file is intended to be opinionated on the best way to deploy keystone, port 80/443 (standard ports) under the identity-prefix.

Changed in keystone:
status: New → Invalid
Revision history for this message
Mike Joseph (mj-mode) wrote :

I believe that this should be reopened, since the issue remains for the following reasons:

* All installation guide docs refer to Keystone running on port 5000 (OS_AUTH_URL=http://controller:5000/v3). If that's no longer the recommended deployment model, then the docs should be updated accordingly.

* The file in question still contains endpoints on both :5000 and /identity. If the Keystone project believes that :5000 is deprecated in favor of /identity, then the WSGI config should be updated in the file to remove :5000. But having both seems broken.

* For some reason that I haven't worked out yet, the /identity endpoint *is* interfering with the /horizon endpoint. If /identity will be remaining, we should try to figure out why that is.

-MJ

Changed in keystone:
status: Invalid → New
Revision history for this message
Colleen Murphy (krinkle) wrote :

This is valid IMO. It's hard to fix for exactly the reason you describe, we have to update all our documentation to stop referring to the port as well as every other projects' docs and also make sure the operator is aware of how to set it up without interfering with horizon. So far we've been sticking to referring to the port because there are fewer prerequisites to explain. But the long-term answer is to update the install guide to set up /identity and correct all instances of :5000 in ours and other projects' docs.

I think packagers rely in the example apache file so if we want to change it we should try to be sure it's the right move and coordinate with them.

If you do already have horizon using a /horizon endpoint, the /identity endpoint shouldn't be causing problems for you. It would be good to try to figure that out so that eventually the docs can help other people avoid whatever problem this is.

Changed in keystone:
status: New → Triaged
importance: Undecided → Low
tags: added: documentation
description: updated
description: updated
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.