Also, provided you're running your own methods (mostly) you might benefit
from this mostly undocumented gem:
* # If a command is given, this will try to execute the given command, as*
* # described below. Otherwise, it will return a string for use in
embedding in*
* # another command, for executing that command as described below.*
* #*
* # If :run_method is :sudo (or :use_sudo is true), this executes the given
command*
* # via +sudo+. Otherwise is uses +run+. If :as is given as a key, it will
be*
* # passed as the user to sudo as, if using sudo. If the :as key is not
given,*
* # it will default to whatever the value of the :admin_runner variable is,
*
* # which (by default) is unset.*
* #*
* # THUS, if you want to try to run something via sudo, and what to use the
*
* # root user, you'd just to try_sudo('something'). If you wanted to
try_sudo as*
* # someone else, you'd just do try_sudo('something', :as => "bob"). If you
*
* # always wanted sudo to run as a particular user, you could do *
* # set(:admin_runner, "bob").*
* def try_sudo(*args)*
* options = args.last.is_a?(Hash) ? args.pop : {}*
* command = args.shift*
* raise ArgumentError, "too many arguments" if args.any?*
*
*
* as = options.fetch(:as, fetch(:admin_runner, nil))*
* via = fetch(:run_method, :sudo)*
* if command*
* invoke_command(command, :via => via, :as => as)*
* elsif via == :sudo*
* sudo(:as => as)*
* else*
* ""*
* end*
* end*
*
*
* # Same as sudo, but tries sudo with :as set to the value of the :runner*
* # variable (which defaults to "app").*
* def try_runner(*args)*
* options = args.last.is_a?(Hash) ? args.pop : {}*
* args << options.merge(:as => fetch(:runner, "app"))*
* try_sudo(*args)*
* end*
That little lot is taken from the top of deploy.rb (and has been there since
~2.2.x) -- if you read it carefully it makes quite a lot of sense,
internally throughout a standard deploy Capistrano calls #{try_sudo} suring
deploy, symlink, restart, etc... with that in mind if you set the
admin_runner variable to be your www-user, provided your deploy user has
password-less sudo access to su, then you should get what you need, mostly -
I would still be inclined to at least look at how groups work on your
machine though!
HTH
- Lee
2009/7/9 Lee Hambley <[email protected]>
> 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
-~----------~----~----~----~------~----~------~--~---
