Umask in tmp/{cache|pids|sessions|sockets}? / rails in AFS

Rails Deployment
1

Is it possible to change the umask on the files created in the “tmp”
directory via some mechanism present in rails itself? I tried adding
“File.umask 0000” to
config/enviroment.rb and no go.

Here’s the situation. We’re trying to set up a RoR development
environment (Apache 2.2.x, fastcgi), but the files for most of our web
development are located in AFS (a networked file system). AFS doesn’t
really use normal unix file permissions the way that a local file system
does. So, on a local disk, I’d probably have done like…

chown www:www tmp/sessions

But in AFS, I still own the directory, but have to give the webserver
principal rights to it…

fs sa tmp/sessions www rliwdk

Rails is happy to create files in directories permitted in these
directories, but claims not to be able to read them.

Processing InfoController#properties (for xxx.xxx.xxx.xxx at 2007-03-20
16:37:58
) [GET]
Session ID: ebf3af9d4b0849d55d948c6790f76567
Parameters: {“action”=>“properties”, “controller”=>“rails/info”}
Completed in 0.00105 (949 reqs/sec) | Rendering: 0.00006 (5%) | 500
[http://blah.umich.edu/rails-afs/rails/info/properties]
file /afs/umich.edu/user/blah/rails/public/…/config/…/tmp/session
s//ruby_sess.916337a4b4cd819c not readable^M

It seems to be linked to the initialize() function in
/usr/lib/ruby/1.8/pstore.rb ~ line
94:

if File::exist? file and not File::readable? file
raise PStore::Error, format(“file %s not readable”, file)
end

if I change File::readable? to File::readable_real?, it works… but I’d
rather not change this code. It seems like the wrong way to handle it.

So… I was wondering if there was something I could set in my rails
environment such that the files in tmp/cache, tmp/sessions and
tmp/sockets are permitted 0666?

Suggestions?

2

http://weblog.textdrive.com/article/196/on-rails-sessions

http://mongrel.rubyforge.org/docs/apache.html
3

Admittedly this is a non-answer, but why not use the database session
store? You side-step this problem and get better performance plus the
potential to scale across hosts…

4

It’s mostly to be able to support a freshly created rails project, out
of the box… or rather to know what we need to do support such an
installation.

I know there are other session handlers, but I imagine that without
fixing the umask, we’d run into the same issue with any other file
created in the various subdirectories under “tmp” (cache, pids, sessions
and sockets).

5

On 3/21/07, Liam H. [email protected] wrote:

I know there are other session handlers, but I imagine that without
fixing the umask, we’d run into the same issue with any other file
created in the various subdirectories under “tmp” (cache, pids, sessions
and sockets).

The best way to handle this is to make your rails set up as “shared
nothing”
as possible. Each Rails app should be independent.

Store your sessions in the database, and then use Apache 2.2’s
mod_proxy_balancer to route requests between Mongrel processes on the
various boxes you have.

The only place you need shared storage in this set up is for user
uploaded
files (and even then, you could go with something like S3).

Hope this helps,
Luke F.