Capistrano Connection Caching Question

[Steven Hansen]

Hi,

I'm trying to clear up my understanding of how some of the Capistrano
connection stuff works. In the Capistrano manual, I found the following

"All |run| does is attempt to execute the given command on all
associated remote hosts. (We’ll talk more later about the available
helper methods, of which |run| is the most commonly used.) This means
that as soon as run is invoked, Capistrano inspects the current task and
determines what roles are active, and then determines which servers
those roles map to. If no connection has been made a server yet, the
connection is established and cached, and then the command is executed
in parallel. /This means that no connections are made to the remote
hosts until they are actually needed."/

I'm a bit confused about what it means to "cache" the connection. Let's
say I have the following tasks:

---------------------------------------------------------------------
task :wrapper do
show_env
set_gem_home
show_env
end

task :show_env do
run 'env'
end

task :set_gem_home do
run 'export GEM_HOME=/path/to/ruby/gems'
end
----------------------------------------------------------------------

What I'm seeing--when I run the :wrapper task--is that on the second
call to :show_env GEM_HOME is not set on the remote machine's
environment. If the connection is being cached, after the first call to
:set_gem_home wouldn't GEM_HOME be set for all subsequent tasks for that
machine?

I realize that the easiest way to set something like GEM_HOME is to
configure it in a .ssh/environment file. However, our sys admins have
disabled the [PermitUserEnvironment] option in the sshd_config file. As
things stand right now, I have to prepend all commands like this [export
GEM_HOME=/path/to/ruby/gems && gem install super_gem]. I'd like to avoid
this if possible.

Regards,
Steven

 

[Ezra Zygmuntowicz]

Hi,

I'm trying to clear up my understanding of how some of the =20
Capistrano connection stuff works. In the Capistrano manual, I =20
found the following

"All |run| does is attempt to execute the given command on all =20
associated remote hosts. (We=92ll talk more later about the available =20=

helper methods, of which |run| is the most commonly used.) This =20
means that as soon as run is invoked, Capistrano inspects the =20
current task and determines what roles are active, and then =20
determines which servers those roles map to. If no connection has =20
been made a server yet, the connection is established and cached, =20
and then the command is executed in parallel. /This means that no =20
connections are made to the remote hosts until they are actually =20
needed."/

I'm a bit confused about what it means to "cache" the connection. =20
Let's say I have the following tasks:

---------------------------------------------------------------------
task :wrapper do
show_env
set_gem_home
show_env
end

task :show_env do
run 'env'
end

task :set_gem_home do
run 'export GEM_HOME=3D/path/to/ruby/gems'
end
----------------------------------------------------------------------

What I'm seeing--when I run the :wrapper task--is that on the =20
second call to :show_env GEM_HOME is not set on the remote =20
machine's environment. If the connection is being cached, after the =20=

first call to :set_gem_home wouldn't GEM_HOME be set for all =20
subsequent tasks for that machine?

I realize that the easiest way to set something like GEM_HOME is to =20=

configure it in a .ssh/environment file. However, our sys admins =20
have disabled the [PermitUserEnvironment] option in the sshd_config =20=

file. As things stand right now, I have to prepend all commands =20
like this [export GEM_HOME=3D/path/to/ruby/gems && gem install =20
super_gem]. I'd like to avoid this if possible.

Regards,
Steven

Hey Steven-

What you need to know is that calls to run are all new calls. So =
if =20
you export a env variable in one call to run and then try to use it =20
in another call to run it will not be there. Same thing if you cd =20
into a directory in one call to run and then try to do something in =20
that dir with another call to run. The way around this is to call run =20=

will a series of commands in the same run call:

run "export GEM_HOME=3D/path/to/ruby/gems &&
ln -s whatever foo &&
cd /some/path &&
touch whatever"

So the idea is that if commands you call depends on something =
set in =20
a previous call to run you need to rework them into a chained command =20=

like above.

Cheers-
-- Ezra Zygmuntowicz=20
-- Lead Rails Evangelist
-- (e-mail address removed)
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

 

[Steven Hansen]

Hi,

I'm trying to clear up my understanding of how some of the Capistrano
connection stuff works. In the Capistrano manual, I found the following

"All |run| does is attempt to execute the given command on all
associated remote hosts. (We’ll talk more later about the available
helper methods, of which |run| is the most commonly used.) This means
that as soon as run is invoked, Capistrano inspects the current task
and determines what roles are active, and then determines which
servers those roles map to. If no connection has been made a server
yet, the connection is established and cached, and then the command
is executed in parallel. /This means that no connections are made to
the remote hosts until they are actually needed."/

I'm a bit confused about what it means to "cache" the connection.
Let's say I have the following tasks:

---------------------------------------------------------------------
task :wrapper do
show_env
set_gem_home
show_env
end

task :show_env do
run 'env'
end

task :set_gem_home do
run 'export GEM_HOME=/path/to/ruby/gems'
end
----------------------------------------------------------------------

What I'm seeing--when I run the :wrapper task--is that on the second
call to :show_env GEM_HOME is not set on the remote machine's
environment. If the connection is being cached, after the first call
to :set_gem_home wouldn't GEM_HOME be set for all subsequent tasks
for that machine?

I realize that the easiest way to set something like GEM_HOME is to
configure it in a .ssh/environment file. However, our sys admins have
disabled the [PermitUserEnvironment] option in the sshd_config file.
As things stand right now, I have to prepend all commands like this
[export GEM_HOME=/path/to/ruby/gems && gem install super_gem]. I'd
like to avoid this if possible.

Regards,
Steven

Hey Steven-

What you need to know is that calls to run are all new calls. So
if you export a env variable in one call to run and then try to use it
in another call to run it will not be there. Same thing if you cd into
a directory in one call to run and then try to do something in that
dir with another call to run. The way around this is to call run will
a series of commands in the same run call:

run "export GEM_HOME=/path/to/ruby/gems &&
ln -s whatever foo &&
cd /some/path &&
touch whatever"

So the idea is that if commands you call depends on something set
in a previous call to run you need to rework them into a chained
command like above.

Cheers-
-- Ezra Zygmuntowicz-- Lead Rails Evangelist
-- (e-mail address removed)
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

Cool,
Thanks!