Yeah, I was thinking about setting groups as well; just placing the
sudoer and nonsudoer in the same group should solve most of this
thread’s issues. I still kinda wish I could specify something akin to
ssh flags and be able to programmatically drop the connection and
reconnect as another user, but I think you’re right about how the
assumed Capistrano approach should be to define another role so that
another connection will surface.
Thanks for all the Cap pointers. I hope Utah’s weather today is as
nice as it is here.
On 4 May, 12:37, Jamis Buck <[EMAIL PROTECTED]> wrote:
> On May 4, 2008, at 10:19 AM, [EMAIL PROTECTED] wrote:
>
> > 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"
>
> Things get much simpler if you just give the nonsudoer_group write
> access to the directory in question. :)
>
> > 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.
>
> Roles are just a way of categorizing your servers. The various helpers
> (run, sudo, put, upload, download, etc) all accept the same basic set
> of options, including :roles and :hosts. Those default to whatever
> servers were defined for the task, for convenience's sake, but you can
> override on a per-call basis, as I demonstrated.
>
> - Jamis
>
>
>
> > 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
