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