[Openstack] Can I move keystone-signing-XXX files out of /tmp ?

Adam Young ayoung at redhat.com
Thu Jan 2 22:42:56 UTC 2014


On 01/02/2014 01:29 PM, Clint Byrum wrote:
> Excerpts from Adam Young's message of 2014-01-02 08:51:04 -0800:
>> On 12/24/2013 11:30 AM, Xin Zhao wrote:
>>> Hello,
>>>
>>> I am running a Grizzly multi-host test cluster on RHEL6. On the
>>> controller node, there are several keystone-signing-XXXX files
>>> automatically created by the daemons. But if some disk cleanup scripts
>>> kick in and remove them, that will cause problem to the services. So I
>>> wonder if I can move them to a more permanent place like /var/cache/ ?
>>> Any advice and best practice experience on this will be greatly
>>> appreciated.
>> Yes, so long as the services get config option knowing where to look for
>> the files, they can and should live in /var/cache. That is what RDO does
>> by default.  /tmp is a "safe default and  developer friendly" solution,
>> but not necessary for a live deployment.
> Odd that /tmp is ok and yet /var/cache is used otherwise. Since /tmp is
> blown away at reboot, I'd expect /var/run not /var/cache. But meh,
> doesn't matter too much I suppose.
I prefer to think of them as a Cache, and that the sever should be 
prepared to refetch the certs on demand.  The problem is wiping out the 
directories that the files are storied in, not the files themselves.

>
>>> $ ls -lrt /tmp
>>>
>>>   keystone-signing-tdtD3g
>>>   keystone-signing-swift
>>>   keystone-signing-nova
>>>   keystone-signing-eEXjn_
>>>   keystone-signing-xwSFNi
>>>   keystone-signing-YqxWd2
> These random dirs are good, but the predictable ones open nova and swift
> up to local DOS.
  which is why the defaults were a secure temp directory instead...but 
that only works for a single process, not for running in Apache...lost 
of ways to mess this one up.

>   That isn't really an appropriate production default.
> Before I run off and file a bug without background, has this already
> been addressed? I did a shallow dive trying to find where these come
> from and only see the randomized ones, so perhaps a pointer to the code
> that made those would help?
Probably older versions of the code, but not the current auth_token 
middleware

>
> _______________________________________________
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack





More information about the Openstack mailing list