Ah! Wow, I missed that 2006 blog post then.
mouth.insert foot
Setting the group id bit on my deploy_to directory's parent seems to
be doing the trick.
On 4 May, 14:35, Jamis Buck <[EMAIL PROTECTED]> wrote:
> On May 4, 2008, at 11:15 AM, [EMAIL PROTECTED] wrote:
>
> > 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.
>
> I'm sure Utahns everywhere appreciate the sentiment. The Idaho weather
> is great, though. :)
>
> - Jamis
>
>
>
> > 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
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
