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