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 : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
_______________________________________________
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : [email protected]
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
