Nice, Neil, I like that. Excuse my umask ignorance, but is there any danger of a particular host having restrictions on the allowable settings for umask? There's already been people reporting issues with shared hosts because of the attempts elsewhere to set the files and directories to be group-writable, so that's all going to have to be rethought. Using umask would help in allowing that to be configurable (on or off), but I just want to make sure it's not going to have any issues of its own.
- Jamis On Jan 17, 2007, at 9:27 AM, NeilW wrote:
The current Capistrano 'setup' does the following: mkdir -p -m 775 #{deploy_to} #{releases_path} #{shared_path} #{shared_path}/system && mkdir -p -m 777 #{shared_path}/log && mkdir -p -m 777 #{shared_path}/pids Unfortunately the POSIX prescribed behaviour for the '-m' option means that the mode only applies to the last directory on the path. The rest are created according to a formula involving the current 'umask' setting which is then bitwise ANDed with 0600. (Betya didn't know that - I didn't!) So if my system umask is 0077, the mkdir -p creates intermediate directories without any group or other permission and nobody but the creating user can read any of these directories.The workaround is to set the appropriate umask in the command sequence.umask 02 && mkdir -p #{deploy_to} #{releases_path} #{shared_path} #{shared_path}/system && umask 0 && mkdir -p #{shared_path}/log && mkdir -p #{shared_path}/pids NeilW >
--~--~---------~--~----~------------~-------~--~----~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~----------~----~----~----~------~----~------~--~---
