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