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

[Jamis Buck]

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

'edwardog' is the current user

'mongrel' is the current user.
   restart                                             # attempts to
run as 'mongrel'
 end

puts "Sudo-ing user is now: #{user}" # reports that run "logger `whoami` is trying to restart mongrels" # reports that

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

than later:

_know_ you're going to need it, so you might as well prompt earlier

  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

logged-in as a non-sudoer.

sudoer. As you say, using a -u flag with sudo doesn’t help if I'm

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

your
SCM operations as. To specify a specific user when sudo'ing,
give
the :as option:

who you are logging into your servers as, and who you are doing

  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

you
can sudo with: ")
set :user, user
sudo "monit -g wuntoo_mongrel #{t.to_s} all"
end

user = Capistrano::CLI.ui.ask("Please enter the name of a user

...

Now I get:

$ cap 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

restart all"
  servers: ["foo.com"]
  [wuntoo.com] executing command
Password:
** [out :: foo.com]
  command finished

triggering start callbacks for `deploy:monit:mongrel:restart' * executing "sudo -p 'sudo password: ' monit -g wuntoo_mongrel

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

--~--~---------~--~----~------------~-------~--~----~
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