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 abou
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 program
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, bu
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
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
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
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 enti
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.
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 suppos
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
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 "Su
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
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("...")
en
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
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:
O
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 :use
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 tr
17 matches
Mail list logo
