capistrano, .bashrc, Debian and RedHat

[VitalyK]

Hi.
I just spent lots of time trying to figure out why my recipes work on
Debian and do not work on RedHat (RHEL4). So I thought to share it in
case someone else stumbs on it too. And at the end I also have a
question :-)

The essence of the problem is that the .bashrc file is loaded when
running on Debian servers and not when running on RHEL. I tracked the
difference to different settings bash was compiled with. in addition
to usual options bash loads .bashrc if it senses that the stdin comes
from a network [1] or if it finds SSH_CLIENT or SSH_CLIENT2 in the
environment [2]. The 2nd check is disabled on RedHat. And when
running with capistrano, the stdin is not considered a network
connection.
So if you run
ssh myhost.com 'echo $PATH'
bash will sense the network and will load .bashrc on both Debian and
RedHat, but if you do a task that does
run "echo $PATH"'
then it will only load .bashrc on Debian.

the 'is_stdio_a_netconnection' (function isnetconn in lib/sh/netconn.c)
check is
performed (on Linux) by calling 'getpeername'.
I tried to run a "ps ax" as a task and as a direct ssh command.
in a case of a task, the parent process is 'sshd: username@pts/X'
X=1,2,3..
in a case of a direct ssh command, the parent process is 'sshd:
username@notty'

obviously capistrano allocates a pseudo terminal for its working
which defies the network-sense check (i.e. stdin is not a socket so
getpeername fails).

At this point I got too tired to continue digging so I just hacked
the following to make it work:

module ::Capistrano
class Actor
alias :run_without_env :run
def run cmd
cmd = <<-CMD
# -i switch will force bash to load .bashrc
/bin/bash -ic -- "#{cmd}"
CMD
run_without_env cmd
end
end
end

A better solution would be to change capistrano so that the other
side can see that we are coming from a network but I already spent on
this one too much time :-)

So is this capistrano behavior is 'by design' or is it a bug? does it
have to use a pseudo terminal? can we leave stdin to be a socket?

/V

[VitalyK]

I found 2 problems with my 'hack' above:
1) it breaks tasks that use more then 1 arg for 'run' (fixed by proper
method sig and passing args)
2) it breaks when .bashrc has a color 'ls' for interactive shell etc.
(instead of using -i for interactive shell, I now pass BASH_ENV to
force inclusion of .bashrc

Fixed version:

module ::Capistrano
class Actor
alias :run_without_env :run

def run(cmd, options={}, &block)
if use_run_with_env
cmd = <<-CMD
BASH_ENV=.bashrc /bin/bash -c -- "#{cmd}"
CMD
end

run_without_env cmd, options, &block
end
end
end

/V

[Jamis Buck]

If you'd like to experiment with running capistrano without the pty
allocation, you can remove the "request_pty" call on line 66 of
capistrano/command.rb and see what happens. I remember putting that
line there for a reason, but alas, I cannot recall the reason. :(

- Jamis

> --~--~---------~--~----~------------~-------~--~----~
> To unsubscribe from this group, send email to capistrano-
> unsub...@googlegroups.com
> For more options, visit this group at http://groups.google.com/
> group/capistrano
> -~----------~----~----~----~------~----~------~--~---
>

[chris.a....@gmail.com]

I tried removing that line (though for me that's on line 58) and the
deply task just hung after I entered my password.

[Jamis Buck]

On Oct 27, 2006, at 9:20 AM, chris.a....@gmail.com wrote:

>
> I tried removing that line (though for me that's on line 58) and the
> deply task just hung after I entered my password.

Thanks for being willing to experiment, Chris. There may yet be a way
to make it work, but I don't know how. It'll require some serious SSH-
fu, I think. If anyone wants to play with that and figures out a way
to make it work, please let me know. I'd love for capistrano to mimic
the command-execution semantics of the ssh command as closely as
possible.

- Jamis

[Charles Brian Quinn]

This was driving me nuts on a client's gentoo box -- I couldn't get
any PATH variables to work, therefore ruby and rubygems and everything
I had compiled from source in /usr/local wasn't loading or available.

I had to enable user environments in the /etc/ssh/sshd_config:

PermitUserEnvironment yes

restart sshd

then I had to create a ~/.ssh/environment variable that had the line:

PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/bin:/usr/sbin:/sbin

since that file only wants key value pairs, I believe.

this task helped me out:

desc "show path"
task :show_path do
run "echo $PATH"
end

Now that I see some more options in the ssh like enabling "login" -- I
am curious, but don't have enough time to keep going down this rabbit
hole.

--
Charles Brian Quinn
self-promotion: www.seebq.com
highgroove studios: www.highgroove.com
slingshot hosting: www.slingshothosting.com