cswebgirl,
Depending how your groups and users are configured, there's an option to
make things group writable during a finalize_update (see below) - this
defaults to true, and depending on your OS can be made so that your deploy
user is in the group (the difference may be between being in the group, or
having that group set as the primary group, see "man groups (1)" for more
info, your OS will dictate how you assign users groups, and primary group,
but it's usually pretty simple, here's the readme for finalize_update:
$ cap -e deploy:finalize_update
------------------------------------------------------------
cap deploy:finalize_update
------------------------------------------------------------
[internal] Touches up the released code. This is called by update_code after
the
basic deploy finishes. It assumes a Rails project was deployed, so if you
are
deploying something else, you may want to override this task with your own
environment's requirements.
This task will make the release group-writable (if the :group_writable
variable
is set to true, which is the default). It will then set up symlinks to the
shared directory for the log, system, and tmp/pids directories, and will
lastly
touch all assets in public/images, public/stylesheets, and
public/javascripts so
that the times are consistent (so that asset timestamping works). This
touch
process is only carried out if the :normalize_asset_timestamps variable is
set
to true, which is the default.
I can't promise that will solve your problems, but rather than running tasks
as the other user, Unix's mechanism for this is groups, so imho you should
make the most of it! The only other thing to mention, is that this happens
as part of a deploy:setup (which, you can run repeatedly, if you need to it
is non-destructive) - the implementation reads (line #160ish of deploy.rb
depending which version you are running)
task :setup, :except => { :no_release => true } do
dirs = [deploy_to, releases_path, shared_path]
dirs += shared_children.map { |d| File.join(shared_path, d) }
run "#{try_sudo} mkdir -p #{dirs.join(' ')} && #{try_sudo} chmod g+w
#{dirs.join(' ')}"
end
As you can see, it makes the directories concerned group writable.
-- Lee Hambley
Twitter: @leehambley
Blog: http://lee.hambley.name/
Working with Rails: http://is.gd/1s5W1
2009/7/9 Rafael G. <[email protected]>
>
> I use slackware and have this permissions:
> drwxr-xr-x 6 root root 4,0K 07/01/09 07:32 www/
>
> But I don't put my rails apps on /var/www/ I separate them by users,
> then in the vhost I said where to find public directory (I use
> passenger, but it's the same for mongrel).
>
> Perhaps anyone that install rails apps in /var/www can recommend how to
> set the permissions.
>
> Regards
>
> PS: In our servers /var/www has the same permissions.
>
> cswebgrl wrote:
> > Just for clarification... the www directory needs to be owned by www-
> > data? Currently it is owned by root and I get permissions errors when
> > using my login as user.
> > >
> >
> >
>
>
> --
> Rafa
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Capistrano" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.co.uk/group/capistrano?hl=en
-~----------~----~----~----~------~----~------~--~---
