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