Bug 978011 - nova-cert tries to write to /root
Summary: nova-cert tries to write to /root
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-nova
Version: 3.0
Hardware: x86_64
OS: Linux
unspecified
low
Target Milestone: ---
: 4.0
Assignee: Xavier Queralt
QA Contact: Ami Jeain
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-25 19:34 UTC by Jaroslav Henner
Modified: 2019-09-09 15:40 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-11-04 09:12:35 UTC
Target Upstream Version:


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

Description Jaroslav Henner 2013-06-25 19:34:32 UTC
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 19:35:13 UTC
There is similar https://bugs.launchpad.net/keystone/+bug/1036847

Comment 2 Jaroslav Henner 2013-06-25 19:36:45 UTC
Created attachment 765264 [details]
api.log

Comment 4 Jaroslav Henner 2013-06-25 19:53:14 UTC
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 14:46:05 UTC
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 04:30:16 UTC
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 09:12:35 UTC
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.