Bug 978011 - nova-cert tries to write to /root
nova-cert tries to write to /root
Status: CLOSED NOTABUG
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova (Show other bugs)
3.0
x86_64 Linux
unspecified Severity low
: ---
: 4.0
Assigned To: Xavier Queralt
Ami Jeain
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-25 15:34 EDT by Jaroslav Henner
Modified: 2015-06-04 17:52 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-04 04:12:35 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
api.log (14.35 KB, text/plain)
2013-06-25 15:36 EDT, Jaroslav Henner
no flags Details

  None (edit)
Description Jaroslav Henner 2013-06-25 15:34:32 EDT
Description of problem:
nova-cert tries to write to the root after restart:

[root@folsom-rhel6 ~(keystone_admin)]# keystone ec2-credentials-list --user_id 5634602be3ce4e4b95c514eb5ce4c696^C
[root@folsom-rhel6 ~(keystone_admin)]# nova x509-create-cert 0a2cdee813f046d9b2cf2fdd318f853e /tmp/foo
ERROR: The server has either erred or is incapable of performing the requested operation. (HTTP 500) (Request-ID: req-e882519e-199a-40cb-8597-ca32aecf52c3)


Version-Release number of selected component (if applicable):
openstack-nova-cert-2013.1.2-2.el6ost.noarch

How reproducible:
2/2

Steps to Reproduce:
1. restart openstack-nova-cert
2. keystone ec2-credentials-create ...
3. keystone ec2-credentials-list ...
4. nova x509-create-cert 0a2cdee813f046d9b2cf2fdd318f853e /tmp/foo

Actual results:
When done first time, HTTP 500, tracebacks in nova api log
Second time it succeeds.

Expected results:
cert ready

Additional info:
log:
...
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack   File "/usr/lib64/python2.6/contextlib.py", line 34, in __exit__
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack     self.gen.throw(type, value, traceback)
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack 
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack   File "/usr/lib/python2.6/site-packages/nova/utils.py", line 1205, in tempdir
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack     yield tmpdir
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack 
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack   File "/usr/lib/python2.6/site-packages/nova/crypto.py", line 405, in _sign_csr
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack     os.chdir(start)
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack 
2013-06-25 19:26:23.463 15187 TRACE nova.api.openstack OSError: [Errno 13] Permission denied: '/root'
Comment 1 Jaroslav Henner 2013-06-25 15:35:13 EDT
There is similar https://bugs.launchpad.net/keystone/+bug/1036847
Comment 2 Jaroslav Henner 2013-06-25 15:36:45 EDT
Created attachment 765264 [details]
api.log
Comment 4 Jaroslav Henner 2013-06-25 15:53:14 EDT
Note I was playing with memcache when I found this. More concretely, I had following in nova conf:

[keystone_authtoken]
memcache_security_strategy = ENCRYPT
memcache_secret_key = change_me
memcache_servers = localhost:11211
...

but after removing it and restarting nova-cert, it behaves the same. I don't believe it is related to configuring memcache use.
Comment 5 Xavier Queralt 2013-09-24 10:46:05 EDT
I've tried to reproduce this on the latest RHOS 3.0 and the upcoming 4.0 

Note that nova-cert is not trying to write to root's home directory, it fails while changing the current directory to the initial one after creating the certificate in the 'ca_folder'. On all the environments I've tested this the nova-cert CWD is always '/', I've no idea why this was set to '/root' in your case (is it possible that it was upgraded from folsom and the configuration/init scripts were broken?).

Could you confirm that this issue is not valid any more (and close the bz) or provide more information about your environment if it still happens?
Comment 6 Jaroslav Henner 2013-09-25 00:30:16 EDT
It has been long time since I reported this but despite server name (folsom-rhel6), it certainly wasn't upgraded from Folsom. We were testing Grizzly in that time and I am destroying the servers each puddle. I will try to reproduce on latest Grizzly.
Comment 7 Xavier Queralt 2013-11-04 04:12:35 EST
I've tried once again to reproduce it in 4.0 but I couldn't. Feel free to reopen this if you can see this behavior again.

Note You need to log in before you can comment on or make changes to this bug.