The upload/download helpers (including put/get) cannot execute as any
user other than the user that the connections are using. This means
you need to resort to either chowning the uploaded files, or
specifying a different connection when doing uploads:
role :app, "app1"
role :safe_app, "[EMAIL PROTECTED]"
task :upload_something, :roles => :app do
upload "/from/here", "/to/here", :roles => :safe_app
end
The chown approach is probably the DRYer of the two.
- Jamis
On May 3, 2008, at 3:24 PM, [EMAIL PROTECTED] wrote:
>
> Cool, so I’ve rewritten my recipes to assume that we’re always
> logging-
> in as a sudoer.
>
> Is there a way to execute `put` or use any of the deplyoment
> strategies as a specific user, or should I just be chown-ing the
> results to my non-sudoer afterwards, if I want to maintain the state
> where the entire app is owned by the nonsudoing 'mongrel' user (so I
> don’t run into permissions issues down the road)?
>
> Thanks again,
> Edward
>
> On May 1, 2:25 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>> We run the mongrels as a different (non-sudoer) user. You can
>> accomplish that lots of ways, but one way is to set :use_sudo to true
>> (the default), and :runner to the name of the user you want running
>> your processes (it defaults to "app"). Then, deploy:start will try to
>> do the right thing.
>>
>> - Jamis
>>
>> On May 1, 2008, at 11:09 AM, [EMAIL PROTECTED] wrote:
>>
>>
>>
>>> Mmmm.... bowel-reaching...
>>
>>> Ok, that’s what I figured would end up happening and leads me to
>>> think
>>> that I’m fundamentally doing something wrong.
>>
>>> I had thought that it’d be more secure if the user running the
>>> mongrels/owning all the Rails app files was not a sudoer. Does that
>>> make sense?
>>
>>> I suppose where this gets tricky is when you bring monit into the
>>> equation and require the user-shifting to occur so that sudo-ing can
>>> actually happen.
>>
>>> Is it silly that I’m trying to do this sort of thing? What kind of
>>> approach would you recommend?
>>
>>> Thanks again for your patience,
>>> Edward
>>
>>> On May 1, 12:44 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>>>> The simplest thing is to just make sure the entire deploy is done
>>>> by a
>>>> sudoer. If that's not possible for whatever reason, then you have
>>>> to
>>>> reach into the bowels of capistrano to unplug the cached
>>>> connections.
>>>> (This, by the way, is really really not recommended, and the
>>>> implementation could change without notice at any time and leave
>>>> your
>>>> recipes high and dry. You've been warned!)
>>
>>>> servers = find_servers_for_task(current_task)
>>>> teardown_connections_to(servers)
>>
>>>> - Jamis
>>
>>>> On May 1, 2008, at 10:31 AM, [EMAIL PROTECTED] wrote:
>>
>>>>> Hi Jamis,
>>
>>>>> Sorry to re-open this thread, but it turns out that I was thinking
>>>>> about it wrong earlier (and just wanted to make it clear if
>>>>> someone
>>>>> stumbles upon this thread later).
>>
>>>>> I switched my default deploy task to look like this:
>>
>>>>> task :default do
>>>>> update
>>>>> switch_to_sudoer
>>>>> puts "Sudo-ing user is now: #{user}" # reports
>>>>> that
>>>>> 'edwardog' is the current user
>>>>> run "logger `whoami` is trying to restart mongrels" # reports
>>>>> that
>>>>> 'mongrel' is the current user.
>>>>> restart #
>>>>> attempts to
>>>>> run as 'mongrel'
>>>>> end
>>
>>>>> and I realize now that what might be happening is that the
>>>>> connection
>>>>> is persisting after the update task.
>>
>>>>> How do I call to have the connection closed and re-established as
>>>>> the
>>>>> sudoer? Should I just be doing something more like
>>
>>>>> task :switch_to_sudoer do
>>>>> # Set regular_user and sudoer if they haven't been set already
>>>>> if regular_user.nil? && sudoer.nil?
>>>>> set(:regular_user, user)
>>>>> set(:sudoer, Capistrano::CLI.ui.ask("Please enter the name
>>>>> of a
>>>>> user you can sudo with: "))
>>>>> end
>>
>>>>> set(:user, sudoer)
>>>>> run "su #{sudoer} -"
>>>>> end
>>
>>>>> task :switch_to_regular_user do
>>>>> if regular_user
>>>>> set(:user, regular_user)
>>>>> run "exit"
>>>>> end
>>>>> end
>>
>>>>> and hoping that the password input for the `su` command is
>>>>> magically
>>>>> caught and read by Capistrano/Highline?
>>
>>>>> Sorry about the extra bother,
>>>>> Edward
>>
>>>>> On May 1, 9:05 am, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>>> Ah, ok, yeah, that makes a little more sense. Cool.
>>
>>>>>> Thanks again Jamis.
>>
>>>>>> On Apr 30, 6:38 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>>
>>>>>>> In that case, you can lose the proc--all the proc does is defer
>>>>>>> the
>>>>>>> actual prompt until it is actually needed, but in this case, you
>>>>>>> _know_ you're going to need it, so you might as well prompt
>>>>>>> earlier
>>>>>>> than later:
>>
>>>>>>> task :switch_to_sudoer do
>>>>>>> set :user, Capistrano::CLI.ui.ask("...")
>>>>>>> end
>>
>>>>>>> - Jamis
>>
>>>>>>> On Apr 30, 2008, at 4:18 PM, [EMAIL PROTECTED] wrote:
>>
>>>>>>>> Yep. That’s what I ended up doing:
>>
>>>>>>>> task :switch_to_sudoer do
>>>>>>>> set :user, Proc.new { Capistrano::CLI.ui.ask("Please enter
>>>>>>>> the
>>>>>>>> name of a user you can sudo with: ") }
>>>>>>>> end
>>
>>>>>>>> and calling it before any monit-related task.
>>
>>>>>>>> (I tried putting all my monit-stuff under a :monit namespace,
>>>>>>>> and
>>>>>>>> having a "before :monit, :switch_to_sudoer", but it didn’t
>>>>>>>> take.
>>>>>>>> Ah,
>>>>>>>> well. Not a big deal. I'm just happy that it's worked out so
>>>>>>>> far.)
>>
>>>>>>>> My more serious problem turned out to be the silent error
>>>>>>>> which I
>>>>>>>> ended up attributing to monit misconfiguration (or rather,
>>>>>>>> forgetting
>>>>>>>> to rsync something locally).
>>
>>>>>>>> Thanks for all the help Jamis!
>>
>>>>>>>> On Apr 30, 5:59 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>>>>>>>>> It should be sufficient to set the user like this, outside of
>>>>>>>>> any
>>>>>>>>> task:
>>
>>>>>>>>> set(:user) do
>>>>>>>>> Capistrano::CLI.ui.ask("What user do you want to log in
>>>>>>>>> as")
>>>>>>>>> end
>>
>>>>>>>>> Or, if you always know the user name in advance:
>>
>>>>>>>>> set :user, "bob"
>>
>>>>>>>>> - Jamis
>>
>>>>>>>>> On Apr 30, 2008, at 3:21 PM, [EMAIL PROTECTED] wrote:
>>
>>>>>>>>>> Ok, so I think my issue here is actually that I’d like to set
>>>>>>>>>> that :user variable before the login to the server so I can
>>>>>>>>>> specify a
>>>>>>>>>> sudoer. As you say, using a -u flag with sudo doesn’t help if
>>>>>>>>>> I'm
>>>>>>>>>> logged-in as a non-sudoer.
>>
>>>>>>>>>> Should I be doing something like a before_deploy hook that
>>>>>>>>>> sets
>>>>>>>>>> the :user variable then?
>>
>>>>>>>>>> On Apr 30, 1:30 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>>>>>>>>>>> The :user variable does not have any effect on sudo. It only
>>>>>>>>>>> controls
>>>>>>>>>>> who you are logging into your servers as, and who you are
>>>>>>>>>>> doing
>>>>>>>>>>> your
>>>>>>>>>>> SCM operations as. To specify a specific user when sudo'ing,
>>>>>>>>>>> give
>>>>>>>>>>> the :as option:
>>
>>>>>>>>>>> my_sudo_user = "bob"
>>>>>>>>>>> sudo "...", :as => my_sudo_user
>>
>>>>>>>>>>> That will translate (effectively) to "sudo -u bob ..."
>>
>>>>>>>>>>> - Jamis
>>
>>>>>>>>>>> On Apr 30, 2008, at 10:46 AM, [EMAIL PROTECTED] wrote:
>>
>>>>>>>>>>>> I'm unable to get both a sudoer's username and password
>>>>>>>>>>>> while
>>>>>>>>>>>> running
>>>>>>>>>>>> a $ cap deploy. I *can* get either the username or the
>>>>>>>>>>>> password,
>>>>>>>>>>>> but
>>>>>>>>>>>> not both. Here's the code:
>>
>>>>>>>>>>>> set :user, "mongrel"
>>>>>>>>>>>> set :group, "mongrel"
>>
>>>>>>>>>>>> ...
>>
>>>>>>>>>>>> namespace :deploy do
>>>>>>>>>>>> desc "restart mongrels using monit"
>>>>>>>>>>>> task :restart, :roles => :app, :except => { :no_release =>
>>>>>>>>>>>> true }
>>>>>>>>>>>> do
>>>>>>>>>>>> deploy.monit.mongrel.restart
>>>>>>>>>>>> end
>>
>>>>>>>>>>>> #
>>>>>>>>>>>> Fromhttp://www.almostserio.us/articles/2007/10/08/monit-and-capistrano
>>>>>>>>>>>> namespace :monit do
>>>>>>>>>>>> namespace :mongrel do
>>>>>>>>>>>> [ :stop, :start, :restart ].each do |t|
>>>>>>>>>>>> desc "#{t.to_s.capitalize} mongrel using monit"
>>>>>>>>>>>> task t, :roles => :app do
>>>>>>>>>>>> set :user, Proc.new
>>>>>>>>>>>> { Capistrano::CLI.ui.ask("Please
>>>>>>>>>>>> enter
>>>>>>>>>>>> the name of a user you can sudo with: ") }
>>>>>>>>>>>> sudo "monit -g wuntoo_mongrel #{t.to_s} all"
>>>>>>>>>>>> end
>>>>>>>>>>>> end
>>>>>>>>>>>> end
>>>>>>>>>>>> ...
>>>>>>>>>>>> end
>>
>>>>>>>>>>>> My setup here is where the regular deploying user is named
>>>>>>>>>>>> 'mongrel',
>>>>>>>>>>>> so that when the svn export is executed, the results are
>>>>>>>>>>>> owned by
>>>>>>>>>>>> the
>>>>>>>>>>>> 'mongrel' user, and are eventually executed by 'mongrel'.
>>
>>>>>>>>>>>> (Yes, I know the name sucks, and I'll be changing it soon.)
>>
>>>>>>>>>>>> My problem here is that the monit processes can only be
>>>>>>>>>>>> manipulated by
>>>>>>>>>>>> root, so I’ve got to sudo every time I want to mess with
>>>>>>>>>>>> it,
>>>>>>>>>>>> like
>>>>>>>>>>>> when
>>>>>>>>>>>> I’m restarting the mongrel processes it monitors.
>>
>>>>>>>>>>>> So I thought I’d be able to just set the :user to be a
>>>>>>>>>>>> sudoer
>>>>>>>>>>>> prior to
>>>>>>>>>>>> running the 'sudo' method, and things would be peachy.
>>
>>>>>>>>>>>> However, the CLI method is only executed *sometimes*.
>>
>>>>>>>>>>>> $ cap deploy:monit:mongrel:restart # I get asked for the
>>>>>>>>>>>> sudoer's
>>>>>>>>>>>> username
>>>>>>>>>>>> $ cap deploy:restart # I don't get asked
>>>>>>>>>>>> $ cap deploy # I don't get asked
>>
>>>>>>>>>>>> So I asked my friend John, who tells me that I should try
>>>>>>>>>>>> leaving
>>>>>>>>>>>> the
>>>>>>>>>>>> Proc.new out, and I end up changing my code to
>>
>>>>>>>>>>>> ...
>>
>>>>>>>>>>>> task t, :roles => :app do
>>>>>>>>>>>> user = Capistrano::CLI.ui.ask("Please enter the name of a
>>>>>>>>>>>> user
>>>>>>>>>>>> you
>>>>>>>>>>>> can sudo with: ")
>>>>>>>>>>>> set :user, user
>>>>>>>>>>>> sudo "monit -g wuntoo_mongrel #{t.to_s} all"
>>>>>>>>>>>> end
>>
>>>>>>>>>>>> ...
>>
>>>>>>>>>>>> Now I get:
>>
>>>>>>>>>>>> $ cap deploy:monit:mongrel:restart
>>>>>>>>>>>> triggering start callbacks for
>>>>>>>>>>>> `deploy:monit:mongrel:restart'
>>>>>>>>>>>> * executing `production'
>>>>>>>>>>>> *** Deploying to the PRODUCTION server!
>>>>>>>>>>>> * executing `deploy:monit:mongrel:restart'
>>>>>>>>>>>> Please enter the name of a user you can sudo with: edwardog
>>>>>>>>>>>> * executing "sudo -p 'sudo password: ' monit -g
>>>>>>>>>>>> wuntoo_mongrel
>>>>>>>>>>>> restart all"
>>>>>>>>>>>> servers: ["foo.com"]
>>>>>>>>>>>> [wuntoo.com] executing command
>>>>>>>>>>>> Password:
>>>>>>>>>>>> ** [out :: foo.com]
>>>>>>>>>>>> command finished
>>
>>>>>>>>>>>> So at this point, I’m thinking that it’s worked, and I’m
>>>>>>>>>>>> golden.
>>
>>>>>>>>>>>> Nope! It turns out to be failing silently, and -v or -vvv
>>>>>>>>>>>> doesn’t
>>>>>>>>>>>> have
>>>>>>>>>>>> any effect.
>>
>>>>>>>>>>>> What gives? Is there any way I can see what it’s doing?
>>
>>>>>>>>>>> smime.p7s
>>>>>>>>>>> 3KDownload
>>
>>>>>>>>> smime.p7s
>>>>>>>>> 3KDownload
>>
>>>>>>> smime.p7s
>>>>>>> 3KDownload
>>
>>>> smime.p7s
>>>> 3KDownload...
>>
>> read more »
>>
>> smime.p7s
>> 3KDownload
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
