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
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
