[Capistrano] Re: Unable to get both a sudoer's username and password

[Jamis Buck]

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

well. Not a big deal. I'm just happy that it's worked out so far.)

having a "before :monit, :switch_to_sudoer", but it didn’t take. Ah,

My more serious problem turned out to be the silent error which I

to rsync something locally).

ended up attributing to monit misconfiguration (or rather, forgetting

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

the :as option:

SCM operations as. To specify a specific user when sudo'ing, give

  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

but
not both. Here's the code:

a $ cap deploy. I *can* get either the username or the password,

set :user, "mongrel"
set :group, "mongrel"

...

namespace :deploy do
desc "restart mongrels using monit"

do
  deploy.monit.mongrel.restart
end

task :restart, :roles => :app, :except => { :no_release => true }

# 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',

the
'mongrel' user, and are eventually executed by 'mongrel'.

so that when the svn export is executed, the results are owned by

(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

when
I’m restarting the mongrel processes it monitors.

root, so I’ve got to sudo every time I want to mess with it, like

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

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

smime.p7s
Description: S/MIME cryptographic signature