Thinking about it again, in order to cover for the situation where
you’re updating a config file or something that’s now owned by the
nonsudoing user, wouldn’t you end up doing something like this
(because the put-ing is being done by the regular non-root, non-
nonsudoer user used to log in to the server)?
config_filepath = File.join(path_to_directory_mucking_about_in,
config_filename)
sudo "chown #{user} #{path_to_directory_mucking_about_in}"
put "Contents of some config file", config_filepath
sudo "chown #{nonsudoer}:#{nonsudoer_group}
#{path_to_directory_mucking_about_in} &&
chown #{nonsudoer}:#{nonsudoer_group} config_filepath"
It’s not a huge deal, but I just wanted to make sure this makes sense
to you too.
BTW, it’s interesting how you’re suggesting to use the roles to
establish another connection by feeding it to upload; I thought roles
were just for task blocks.
On 3 May, 23:29, Jamis Buck <[EMAIL PROTECTED]> wrote:
> The upload/download helpers (including put/get) cannot execute as any
> user other than the user that the connections are using. This means
> you need to resort to either chowning the uploaded files, or
> specifying a different connection when doing uploads:
>
> role :app, "app1"
> role :safe_app, "[EMAIL PROTECTED]"
>
> task :upload_something, :roles => :app do
> upload "/from/here", "/to/here", :roles => :safe_app
> end
>
> The chown approach is probably the DRYer of the two.
>
> - Jamis
>
> On May 3, 2008, at 3:24 PM, [EMAIL PROTECTED] wrote:
>
>
>
> > 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
>
> ...
>
> read more »
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
