0

I've deployed a Rails application that is using page caching and is run via Passenger on Ubuntu Server. Rails caching simply uses Ruby's File.open to write the cached files.

Unfortunately these files are being written with mode 666. The umask for all appropriate accounts is 022. What else could I check to determine what is causing this?

Thanks in advance.

aculich
  • 3,610
  • 1
  • 26
  • 33
lipsum123483
  • 101
  • 3

2 Answers2

1

In your case you'll want to modify your Apache httpd.conf file to change RailsRuby to:

RailsRuby /usr/local/bin/ruby_with_env

And then create the file /usr/local/bin/ruby_with_env with these contents:

#!/bin/bash
umask 022
/usr/bin/ruby $*

Then make sure to do chmod 755 /usr/local/bin/ruby_with_env so the wrapper script is executable and then tell Apache to reload its configuration.

Also, this of course presumes you have ruby installed in /usr/bin, but if you have it in another location you'll want to change the line to either /path/to/ruby $* or the more general /usr/bin/env ruby $* which will search in Apache's path for ruby.

The discussion entitled Setting umask for rails user suggested a similar solution:

> I'd like to set umask to 002 for the user running the rails processes. 
> However, passenger ignores the value set in ~/.profile (or set in 
> environment.rb via File.umask). 

I would set it in a wrapper script that sets enviroment stuff and then
invokes ruby; use this wrapper script as the target of your 
PassengerRuby/RailsRuby parameter. See this blog post for an example:

http://blog.rayapps.com/2008/05/21/using-mod_rails-with-rails-applications-on-oracle/

aculich
  • 3,610
  • 1
  • 26
  • 33
  • Thank you for the detailed instructions! We will try this now & let you know how it goes. – Jamon Holmgren Jan 24 '12 at 18:02
  • It ended up being a different issue, but I'm giving you the bounty anyway since this was a nice, detailed answer. Thank you! – Jamon Holmgren Jan 25 '12 at 23:57
  • @JamonHolmgren Thanks for the bounty... though I'm curious to know if your solution solves the same problem for the original question asker, Tricon? – aculich Jan 27 '12 at 02:13
  • sorry, I don't really recall what the issue ended up being and my developer doesn't either. I should have documented it here. I believe we ended up hiring a server admin to uninstall our setup and reinstalling using a different methodology. – Jamon Holmgren Apr 09 '12 at 17:08
0

We were having the same problem and the issue was that we were running Passenger as a standalone nginx-hosted process. We reinstalled Passenger as a system-wide Apache module (version 3.0.11 in this case) and are no longer having the caching file permission issues.