Has anyone determined the cause of this behavior? If I'm deploying to
a Solaris box, I get a very vanilla environment (i.e. no .bashrc) but
deploying to a Linux (Ubuntu) box shows that .bashrc is getting
sourced in that instance. Oddly, using the SSH command at the prompt
doesn't show this behavior (connecting to the Solaris box using `ssh
[EMAIL PROTECTED] utilizes user's ~/.bashrc).
Is there some sshd setting that might control this? Is Net::SSH
possibly doing something different than `ssh` that's causing this? I
also don't see the MOTD when connecting via Net::SSH, which is fine,
it's just another indication that `ssh` and Net::SSH are doing
something a bit different.
I could definitely use the functionality provided by
default_environment. Currently, I'm overriding the #run method to
change the original command to `source ~/.bashrc && <original command
here>`. That's a bit of a hack but it seems to work and allows remote
servers to be configured differently if necessary (i.e. our systest
environment might have some different environment variables than
production).
Anyway, I just thought I'd ask and see if anyone had any ideas.
Brian
On May 31, 10:09 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
> Alright, I just committed a change to Capistrano that makes it so you
> can do:
>
> default_environment["PATH"] = "/foo:/bar:/baz"
>
> Allenvironmentkeys that you put in the default_environment hash
> will be applied to every run() and sudo() call. If you specify
> the :env key to run() or sudo(), it will be merged on top of
> default_environment, so if (for example) you specify "PATH" via :env,
> it will override the "PATH" you specify via default_environment.
>
> Thanks for the idea, Chris!
>
> - Jamis
>
> On May 31, 2007, at 7:04 PM, mh wrote:
>
>
>
> > Same problem here. Lack ofenvironmentvariables is impacting the
> > ability to use Cap to manage a Rails app on Ubuntu using MS SQL Server
> > via unixODBC.
>
> > On May 22, 12:07 am, Chris Roos <[EMAIL PROTECTED]> wrote:
> >> I know (from googling) that some other people are having this same
> >> problem, so does anyone (Jamis) have any comments?
>
> >> Chris
>
> >> On May 15, 5:15 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> >> wrote:
>
> >>> Hi,
>
> >>> I've been playing with Capistrano 2 (which looks great) for the last
> >>> couple of days and have been running into problems caused by the
> >>> 'empty' defaultenvironmenton theremotehost/s. My main problem is
> >>> that the PATH is not set correctly. I can solve the problem for svn
> >>> (bysettingscm_command variable) and rake (bysettingrake variable)
> >>> but not for arbitrary commands. A little googling seems to suggest
> >>> that I could edit my /etc/sshd_config (enabling
> >>> PermitUserEnvironment)
> >>> and thensettingmyenvironmentvariablesin ~/.ssh/environment.
> >>> Alternatively, I can symlink the binaries to something like /bin
> >>> or /
> >>> usr/bin. None of these approaches seem particularly appealing so I
> >>> started digging into the code a bit. I noticed that you are able to
> >>> initialize a Command with options that includeenvironmentvariables
> >>> (by supplying {:env => {ENV_VAR}}, which are parsed by
> >>> Command#extract_environment). I also noticed that the only place a
> >>> Command is constructed is in Invocation#run. Although
> >>> Invocation#run
> >>> can take options that include theenvironmentvariables, there doesn't
> >>> seem to be any way to specify them for the default tasks (in
> >>> deploy.rb). I'm still pretty new to Capistrano so may have missed
> >>> something obvious here...
>
> >>> Anyhoo. I was thinking that we could maybe have a special variable
> >>> called, something like, env_vars, that was used as a default in
> >>> Invocation#run. In fact, adding these two lines to the beginning of
> >>> the run method (combined withsettingthe env_vars variable in my
> >>> Capfile) seem to have the desired effect.
>
> >>> # invocation.rb
> >>> def run(cmd, options={}, &block)
> >>> env_vars = { :env => fetch(:env_vars, {}) }
> >>> options = env_vars.merge(options)
>
> >>> # Capfile
> >>> set :env_vars, { 'PATH' => '/opt/local/bin:/usr/local/bin:$PATH' }
>
> >>> Being new to Capistrano, I'm not sure whether a) this is already
> >>> implemented and I missed it, b) this is intentionally not
> >>> implemented,
> >>> c) this would be the right way to go about implementing it.
>
> >>> I'd be happy to strap some tests around this change if it feels like
> >>> the correct place for it. Alternatively, I'd be happy to submit an
> >>> alternative patch if you had some strong feelings about how it
> >>> should
> >>> be implemented (if at all), and can give me some pointers.
>
> >>> Cheers,
>
> >>> Chris
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---