Bug 1223094

So there is a mismatch in what is expected from the RDO package and the upstream wsgi file.

The upstream wsgi file specifies running the keystone as the keystone user but maintaining the apache group: https://github.com/openstack/keystone/blob/master/httpd/wsgi-keystone.conf#L5

The RDO packaging files specify that /etc/keystone/keystone.conf is owned by root and the keystone group https://github.com/openstack-packages/keystone/blob/rpm-master/openstack-keystone.spec#L197 

What's happening here in the linked bug is the order of precedence of reading config files.

The apache process tries to read the /etc/keystone/keystone.conf file and doesn't have appropriate permissions and then falls back to the /usr/share/keystone/keystone-dist.conf file where those credentials are being read from. 

We either need to update upstream to package the wsgi file specifying a group='keystone' tag so that it can read /etc/keystone/keystone.conf or change the ownership permissions. 

In addition i think it's a bad idea that we put default database strings in the dist file as they should never be useful and it makes the error a permission error connecting to the db with these bad creds rather than options missing.

Yeah, I'm not sure why we have db connection string in default, RPM installation doesn't create default db. I guess it was done in the past when default was sqlite which was created by default? I'll have a look at this.

Re. group - I'd check what puppet-keystone is doing and make upstream match this, so that we have same result after Packstack installation.

Looking at what puppet-keystone does, it sets ownership for /etc/keystone as keystone:keystone, then also to /etc/keystone/keystone.conf 

If we all agree on this, we can go ahead and change the packaging. I'm ok with it.

I think making the ownership keystone:keystone makes sense and is certainly the easier option. 

In looking at the packaging of other services it looks like shipping a database connection string is normal. I see it set in the dist files for nova, cinder and glance (all the ones i checked). Ideally we'd remove all of these.

Also in looking this will make keystone different to the other services.

For example cinder-api.conf is installed with root:cinder and run by user cinder. This will be ok because cinder-api is an application and not run by apache so the group permissions will get picked up.

I don't think this is a problem but i just thought i'd mention it.

> Looking at what puppet-keystone does, it sets ownership for /etc/keystone as
> keystone:keystone, then also to /etc/keystone/keystone.conf 

That's not what I meant! Changing ownership of /etc/keystone doesn't seem right, why is puppet-keystone doing that?

I meant to say that puppet-keystone sets group=keystone in wsgi file:
https://github.com/stackforge/puppet-keystone/blob/master/manifests/wsgi/apache.pp#L167
and httpd/wsgi-keystone.conf in upstream Keystone should do the same.
I've added comment in https://bugs.launchpad.net/keystone/+bug/1456441

...and proposed https://review.openstack.org/187800

(In reply to Alan Pevec from comment #6)
> > Looking at what puppet-keystone does, it sets ownership for /etc/keystone as
> > keystone:keystone, then also to /etc/keystone/keystone.conf 
> 
> That's not what I meant! Changing ownership of /etc/keystone doesn't seem
> right, why is puppet-keystone doing that?
> 

Not sure, I see the code has been there for quite long.