Activity log for bug #1799332

Date Who What changed Old value New value Message
2018-10-23 02:11:32 Mike Joseph bug added bug
2018-10-24 17:59:24 Morgan Fainberg keystone: status New Invalid
2018-10-24 21:38:12 Mike Joseph keystone: status Invalid New
2018-10-25 13:41:12 Colleen Murphy keystone: status New Triaged
2018-10-25 13:41:15 Colleen Murphy keystone: importance Undecided Low
2018-10-25 23:32:32 Morgan Fainberg tags documentation
2018-10-25 23:33:42 Morgan Fainberg description 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. 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. ---- 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.
2018-10-25 23:34:53 Morgan Fainberg 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. ---- 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. 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.