Cool, so I’ve rewritten my recipes to assume that we’re always logging-
in as a sudoer.
Is there a way to execute `put` or use any of the deplyoment
strategies as a specific user, or should I just be chown-ing the
results to my non-sudoer afterwards, if I want to maintain the state
where the entire app is owned by the nonsudoing 'mongrel' user (so I
don’t run into permissions issues down the road)?
Thanks again,
Edward
On May 1, 2:25 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> 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
> >>> 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...
>
> read more »
>
> 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
-~----------~----~----~----~------~----~------~--~---
