undefined signing_dir does not work

[Bernhard M. Wiedemann]

SUSE's automated system testing found a regression for Folsom from the fix of bug 1174608

first failing:
http://ci.opensuse.org/view/Cloud/job/openstack-cleanvm/openstack_version=folsom,slave=cloud-cleanvm/79/
last working:
http://ci.opensuse.org/view/Cloud/job/openstack-cleanvm/openstack_version=folsom,slave=cloud-cleanvm/77/

The problem is that signing_dir is no more defined in /etc/nova/api-paste.ini and now defaults to $HOME/keystone-signing
but the init script does not have HOME setup at all or set to /root and the nova user does not have write-access to the /root/keystone-signing directory.

The nova-api process should likely use getpwent to determine the real home dir instead of relying on $HOME, which is usually not meaningful during system startup.

[Bernhard M. Wiedemann (ubuntubmw)]

this actually comes from
keystone/middleware/auth_token.py: self.signing_dirname = '%s/keystone-signing' % os.environ['HOME']

[Thierry Carrez (ttx)]

Hmm, I wonder if that's not an issue on the SUSE init script... Nova should be started as the "nova" user (which should have a HOME defined), which in turn reads the config file and defaults signing_dirname properly ?

Would you mind posting your init script ?

[Bernhard M. Wiedemann (ubuntubmw)]

init script is at
https://build.opensuse.org/package/view_file?expand=1&file=openstack-nova.init&package=openstack-nova&project=Cloud%3AOpenStack%3AFolsom

The init script uses startproc (which is the SUSE equivalent of LSB's start_daemon) which just sets the UID to the openstack-nova UID but unlike sudo or su does not set $HOME

btw: Debians equivalent works the same:
daemon --user nobody -- bash -c 'echo $HOME > /tmp/foo'
cat /tmp/foo
/root

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/29567

[Thierry Carrez (ttx)]

That sounds a bit weird to me... os.expanduser(~) should run OK within the python interpreter even if the env is not passed by your startproc. The problem seems to be that the environment is still passed, but with wrong values.

It may break you elsewhere (as we use os.expanduser elsewhere). Other distros say they are unaffected...

If you can't workaround it in packaging (by using a daemonizer that sets $HOME or resets the environment completely, by setting $HOME explicitly in your startproc call, or by explicitely setting signing_dir to something meaningful) I guess we could switch to using a tempfile.mkdtemp temporary directory...

[Thierry Carrez (ttx)]

$ echo $HOME
/home/ttx
$ python -c 'import os; print os.path.expanduser("~")'
/home/ttx
$ HOME=/root python -c 'import os; print os.path.expanduser("~")'
/root
$ unset HOME
$ python -c 'import os; print os.path.expanduser("~")'
/home/ttx

[Dolph Mathews (dolph)]

Bernhard cited usage of os.environ['HOME'] in #1, which I initially glossed over because that's not how auth_token does it today:

  cfg.StrOpt('signing_dir', default=os.path.expanduser('~/keystone-signing')),

Source: https://github.com/openstack/python-keystoneclient/blob/master/keystoneclient/middleware/auth_token.py#L215

However, the fix above, which was for bug 1078947 does not appear to have been backported to folsom (keystone's auth_token).

  self.signing_dirname = '%s/keystone-signing' % os.environ['HOME']

Source: https://github.com/openstack/keystone/blob/stable/folsom/keystone/middleware/auth_token.py#L219

Does expanduser() behave differently in suse's case? Should the fix above be backported to folsom?

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/29567
Committed: http://github.com/openstack/python-keystoneclient/commit/03012e641d6c2a98fbfe3780102e28a65d11a887
Submitter: Jenkins
Branch: master

commit 03012e641d6c2a98fbfe3780102e28a65d11a887
Author: Dolph Mathews <email address hidden>
Date: Fri May 17 10:38:25 2013 -0500

    Default signing_dir to secure temp dir (bug 1181157)

    Change-Id: I1a29f50b07a60de3d0519bf40074dbea92fa8656

[Matthew Thode (prometheanfire)]

keystoneclient fixed in gentoo 0.2.3-r2
keystone still open

[Bernhard M. Wiedemann (ubuntubmw)]

As shown in comment #6 os.path.expanduser behaves better in the case of an unset HOME variable, which would improve things for the SUSE packages. We could then just unset HOME in the init script.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/folsom
Review: https://review.openstack.org/30721

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/30721
Committed: http://github.com/openstack/keystone/commit/edbd3ad9158f96fdc7ed621d7c72cd2e71fa5101
Submitter: Jenkins
Branch: stable/folsom

commit edbd3ad9158f96fdc7ed621d7c72cd2e71fa5101
Author: Dolph Mathews <email address hidden>
Date: Tue May 28 08:09:49 2013 -0500

    Default signing_dir to secure temp dir (bug 1181157)

    Change-Id: I1a29f50b07a60de3d0519bf40074dbea92fa8656