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

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


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to