This was raised to me by the documentation team, I would like to confirm this issue is not in the RHOSP 11 packaging (and if it isn't, understand why it isn't also fixed in RDO Ocata). It is possible this is worked around in TripleO (which would explain why AFAIK we don't see this in CI) but even if this is the case we should fix for folks to deploy directly from packages. +++ This bug was initially created as a clone of Bug #1430540 +++ Description of problem: openstack-nova-placement-api-15.0.0-1.el7 places a virtual host file in /etc/httpd/conf.d/00-nova-placement-api.conf. This file is missing the <Directory> parameter. Should add: <Directory /usr/bin> <IfVersion >= 2.4> Require all granted </IfVersion> <IfVersion < 2.4> Order allow,deny Allow from all </IfVersion> </Directory> Version-Release number of selected component (if applicable): 15.0.0-1.el7 [Ocata] How reproducible: yum install openstack-nova-placement-api- Steps to Reproduce: 1. 2. 3. Actual results: Will get an error in /var/log/nova/nova-compute.log 2017-03-07 15:48:34.956 21930 ERROR nova.scheduler.client.report [req-c2cd8993-1c3e-4443-a262-4fa2de789959 - - - - -] Failed to create resource provider record in placement API for UUID cbbf44b0-fad2-4ad3-a9c5-611890b5ab4c. Got 403: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /resource_providers on this server.</p> </body></html> Expected results: Additional info: --- Additional comment from Petr Kovar on 2017-03-20 13:27:18 EDT --- A related upstream manual installation docs change: https://review.openstack.org/#/c/438328/
Alex Schultz confirmed that in TripleO we nuke that file because puppet handles the placement apache config. https://github.com/openstack/puppet-nova/blob/master/manifests/wsgi/apache_placement.pp#L114-L122 We need to fix this issue in both RDO and RHOSP for anyone who deploys directly from packages (or basically any mechanism other than TripleO).
This is where the directory directive comes from in TripleO land: https://github.com/openstack/puppet-openstacklib/blob/master/manifests/wsgi/apache.pp#L46-L48
I had a poke at the nova-placement-api_15.0.1-0ubuntu1~cloud0_all.deb package from Ubuntu's ocata-staging for the cloud archive and found that they do include the <Dirctory> directive: """ Listen 8778 <VirtualHost *:8778> WSGIScriptAlias / /usr/bin/nova-placement-api WSGIDaemonProcess nova-placement processes=5 threads=1 user=nova group=nova display-name=%{GROUP} WSGIProcessGroup nova-placement WSGIApplicationGroup %{GLOBAL} WSGIPassAuthorization On LimitRequestBody 114688 <IfVersion >= 2.4> ErrorLogFormat "%{cu}t %M" </IfVersion> ErrorLog /var/log/apache2/nova_placement_error.log CustomLog /var/log/apache2/nova_placement_access.log combined <Directory /usr/bin> <IfVersion >= 2.4> Require all granted </IfVersion> <IfVersion < 2.4> Order allow,deny Allow from all </IfVersion> </Directory> </VirtualHost> """ On IRC Alex pointed out that for TripleO driven deployments as well as Heat/Puppet controlling the config (which is why we see no issue there) his recollection is that they specifically didn't follow the directory approach because they hit issues. He suggested Emilien would probably remember the history better and that they settled on just a vhost/port configuration since it's all hidden anyway.
I pushed a fix on RDO: https://review.rdoproject.org/r/#/c/5954/
Hi Lucy, Have I set this up correctly to get a release note as "known issue" for GA? Thanks, Steve
I'll echo my comments from https://review.rdoproject.org/r/#/c/5954/ here for posterity... We need to understand what is the problem, not address the symptom by exposing /usr/bin through a web server. That's anything but a good idea. What is required from /usr/bin exactly ? The trace isn't very explicit. Is it a wsgi script or something like that ? Puppet modules approaches this by copying the wsgi scripts to /var/www/cgi-bin and then specifying the necessary configuration to expose that directory. References: https://github.com/openstack/puppet-nova/blob/master/manifests/wsgi/apache_placement.pp#L129 https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L53-L55 https://github.com/openstack/puppet-openstacklib/blob/master/manifests/wsgi/apache.pp Petr mentions a thread from openstack-dev [1] that provides the Directory directive "workaround" and cites the same concern: > That can be fixed by doing (somewhere in your apache config): <Directory /usr/bin> Require all granted </Directory> but rather than doing that you may wish to move nova-placement-api to a less global directory and grant access to that directory. Providing wide access to /usr/bin is not a great idea. The fact that the official documentation provides a workaround with serious security implications rather than showing the right way (placing wsgi/api scripts in another directory such as /var/www/cgi-bin) is quite concerning and should be addressed. I've pinged an Ubuntu package maintainer (James Page) about the issue as Ubuntu includes the virtualhost /usr/bin directive right in the package. [1]: http://lists.openstack.org/pipermail/openstack-dev/2017-March/113550.html
Thanks for the input, David. I'll address the documentation issue once we have a working solution. The doc text will also need to be updated accordingly.
Clearing the needinfo on me. Once the doc text is updated and reviewed by docs again (as per Petr's note in comment 7), this text can be pulled in to the Release Notes.
Steve, in light of comment 6, does the doc text need to be updated with an alternative workaround? We'll need to know ASAP if we want this to appear in the Release Notes.
(In reply to Lucy Bopf from comment #10) > Steve, in light of comment 6, does the doc text need to be updated with an > alternative workaround? We'll need to know ASAP if we want this to appear in > the Release Notes. I've yet to see an alternative proposed in the packaging, so right now I believe the release note as stated remains the best solution we have and better than no solution (which is current state).
OSP11 is now retired, see details at https://access.redhat.com/errata/product/191/ver=11/rhel---7/x86_64/RHBA-2018:1828
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days