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