Bug 889336

Summary: Glance: glance-manage db_sync as root makes glance-registry not start
Product: Red Hat OpenStack Reporter: Dan Prince <dprince>
Component: openstack-glanceAssignee: John Bresnahan <jbresnah>
Status: CLOSED WONTFIX QA Contact: Yaniv Kaul <ykaul>
Severity: medium Docs Contact:
Priority: medium    
Version: 3.0CC: abaron, eglynn, jbresnah, jkt
Target Milestone: asyncKeywords: Triaged
Target Release: 2.1   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-24 19:09:44 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
A patch to the init files. none

Description Dan Prince 2012-12-20 15:46:57 EST
Description of problem:

Running glance-manage db_sync as root before starting glance-registry will make /var/log/glance/registry.log ownership root:root which means that glance-registry won't be able to startup (and won't leave any messages in the log file either).

This can be really confusing for users who try to install Glance manually....

A work around might be to chown this file in the Glance registry init script so that we always know the glance user can write to it.
Comment 2 Eoghan Glynn 2012-12-21 11:10:11 EST
Yes, seems like we could use a ExecStartPre= directive in:


to chmod the log if necessary.
Comment 3 John Bresnahan 2013-03-11 14:45:57 EDT
To chmod/chown the file on start up we would have to figure out where the log file is.  We cannot really assume that the file is in /var/log/glance because the user could have changed the location in various ways.

Perhaps the solution here is to just have a friendly log message.
Comment 4 John Bresnahan 2013-03-11 18:45:05 EDT
The RHOS product instructions do not have a user run glance-manage db_sync.  If a user is doing this they are either misguided or doing something more complicated.  If it is the latter then it is fair to assume that they may have modified the configuration files and thus maybe logging some place besides the default location.  Therefore simply changing the ownership of the default file is only a partial solution.

In order to truly solve this we would need one of two things:

1) a utility that tracked down all of the files to which the services were going to write, and correct their permissions where possible.

2) a means to capture stderr from the init scripts and report it to the user.  Right now that output is just directed to /dev/null
Comment 5 John Bresnahan 2013-04-08 23:28:13 EDT
Created attachment 732948 [details]
A patch to the init files.
Comment 6 Pádraig Brady 2013-04-11 19:21:46 EDT
Comment on attachment 732948 [details]
A patch to the init files.

not sure about this.
The issue isn't specific to glance.
Also this doesn't handle the Fedora side of things.
Also the user shouldn't be running db sync as root.
Also this doesn't handle different logging locatations.

Maybe an upstream oslo patch to logging to move unwriteable files
out of the way would be better, and would fix it everywhere.

Isn't the error message for this edge case fairly obvious?
I never wasted any time with this issue at least,
but maybe the error message could be improved.

Comment 7 John Bresnahan 2013-04-24 19:09:44 EDT
Because the user should not run db_sync as root I think this should be a WONT_FIX.  We cannot effectively prevent misuse with root level access.