Mongrel users - Jul 2007 - Capistrano mongrel recipes and /usr/local/bin

Hello,

I''m trying to deploy my application with Capistrano using Mongrel  
recipes. Since I''ve installed Ruby from source code, mongrel scripts  
are found in /usr/local/bin. But the recipes can''t find  
mongrel_rails : "bash: mongrel_rails: command not found". The path of
the user account used to deploy is OK. For sure, I can redefine  
start_mongrel_cluster/restart_mongrel_cluster/stop_mongrel_cluster  
tasks in the recipes to add path before calling mongrel_rails.

Any idea of a better solution ?

Thanks,

Nicolas St-Laurent
Analyst-Programmer
Wanted Technologies
350, Blvd. Charest East, 4th Floor
Quebec City, Quebec
Canada G1K 3H5

Tel: (418)523-6663
Fax: (418)523-4205
http://www.wantedtech.com/

On Jul 09, 2007, at 12:06 , Nicolas St-Laurent wrote:
> Hello,
>
> I''m trying to deploy my application with Capistrano using Mongrel
> recipes. Since I''ve installed Ruby from source code, mongrel
scripts
> are found in /usr/local/bin. But the recipes can''t find
> mongrel_rails : "bash: mongrel_rails: command not found". The
path of
> the user account used to deploy is OK. For sure, I can redefine
> start_mongrel_cluster/restart_mongrel_cluster/stop_mongrel_cluster
> tasks in the recipes to add path before calling mongrel_rails.
>
> Any idea of a better solution ?
I install Ruby from source on all my machines so I''m not sure where  
that comes in.

mongrel_rails command is installed with the mongrel gem (gem install  
mongrel).

Then just make sure that mongrel_rails is in the path of the user  
account you''re deploying to, you could also add /usr/local/bin to the  
users path. ( PATH=/usr/local/bin:... )
--
Wayne E. Seguin
Sr. Systems Architect & Systems Admin
wayneseguin at gmail.com



-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20070709/667eb5e6/attachment-0001.html

Le 07-07-09 ? 13:42, Wayne E. Seguin a ?crit :
> On Jul 09, 2007, at 12:06 , Nicolas St-Laurent wrote:
>> Hello,
>>
>> I''m trying to deploy my application with Capistrano using
Mongrel
>> recipes. Since I''ve installed Ruby from source code, mongrel
scripts
>> are found in /usr/local/bin. But the recipes can''t find
>> mongrel_rails : "bash: mongrel_rails: command not found". The
path of
>> the user account used to deploy is OK. For sure, I can redefine
>> start_mongrel_cluster/restart_mongrel_cluster/stop_mongrel_cluster
>> tasks in the recipes to add path before calling mongrel_rails.
>>
>> Any idea of a better solution ?
>
> I install Ruby from source on all my machines so I''m not sure
where
> that comes in.
>
> mongrel_rails command is installed with the mongrel gem (gem  
> install mongrel).
>
> Then just make sure that mongrel_rails is in the path of the user  
> account you''re deploying to, you could also add /usr/local/bin to
> the users path. ( PATH=/usr/local/bin:... )
> --
> Wayne E. Seguin
> Sr. Systems Architect & Systems Admin
> wayneseguin at gmail.com
>
Thanks for your feedback.

Well, /usr/local/bin is already in user''s path. But since PATH is  
define in /etc/profile, it ain''t define when a subshell is started,  
hence a run "echo $PATH" gives the default path :

/usr/bin:/bin:/usr/sbin:/sbin

I certainly miss something, but I doesn''t know what. I''m on
SuSE
Entreprise 64bits, but I''ve got the same issue on Mac OS X, Ubuntu or  
Debian.

On Jul 09, 2007, at 15:18 , Nicolas St-Laurent wrote:
> Thanks for your feedback.
>
> Well, /usr/local/bin is already in user''s path. But since PATH is
> define in /etc/profile, it ain''t define when a subshell is
started,
> hence a run "echo $PATH" gives the default path :
>
> /usr/bin:/bin:/usr/sbin:/sbin
>
> I certainly miss something, but I doesn''t know what. I''m
on SuSE
> Entreprise 64bits, but I''ve got the same issue on Mac OS X, Ubuntu
or
> Debian.
You are most welcome.

Usually you''d put your path extensions inside .bash_profile  
or .bash_rc like so:
PATH=/usr/local/bin:$PATH

Then, when you login next it should be sourced (or you can do  
manually via "source ~/.bash_profile" for the current session) you  
should see this:

 > echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin

( assuming that "echo $PATH" originally produces: /usr/bin:/bin:/usr/ 
sbin:/sbin )

In this example /usr/local/bin will be searched first, of course you  
can set it last also by appending instead of prepending.

Let me know if this helps.

--
Wayne E. Seguin
Sr. Systems Architect & Systems Admin
wayneseguin at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20070709/4accff8f/attachment.html

Le 07-07-09 ? 15:34, Wayne E. Seguin a ?crit :
> On Jul 09, 2007, at 15:18 , Nicolas St-Laurent wrote:
>> Thanks for your feedback.
>>
>> Well, /usr/local/bin is already in user''s path. But since PATH
is
>> define in /etc/profile, it ain''t define when a subshell is
started,
>> hence a run "echo $PATH" gives the default path :
>>
>> /usr/bin:/bin:/usr/sbin:/sbin
>>
>> I certainly miss something, but I doesn''t know what.
I''m on SuSE
>> Entreprise 64bits, but I''ve got the same issue on Mac OS X,
Ubuntu or
>> Debian.
>
> You are most welcome.
>
> Usually you''d put your path extensions inside .bash_profile  
> or .bash_rc like so:
> PATH=/usr/local/bin:$PATH
>
> Then, when you login next it should be sourced (or you can do  
> manually via "source ~/.bash_profile" for the current session)
you
> should see this:
>
> > echo $PATH
> /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
>
> ( assuming that "echo $PATH" originally produces: /usr/bin:/bin:/
> usr/sbin:/sbin )
>
> In this example /usr/local/bin will be searched first, of course  
> you can set it last also by appending instead of prepending.
>
> Let me know if this helps.
>
Well, not really. I already set my path correctly. When I''m ssh  
logged with the user I use for my capistrano deployment, my path is :

/usr/local/bin:/usr/local/sbin:/home/myuser/bin:/usr/local/bin:/usr/ 
bin:/usr/X11R6/bin:/bin:/opt/gnome/bin:/usr/lib/mit/bin:/usr/lib/mit/ 
sbin:/usr/local/java/bin.

But, it goes to :
>> /usr/bin:/bin:/usr/sbin:/sbin
in Capistrano''s run method.

bash_rc and bash_profile doesn''t do the same job in Bash. bash_rc is  
sourced everytime a shell is started while profile is sourced only on  
login.

My path is define in /etc/profile instead of locally in user account  
so that every users got almost the same path. It''s the default  
setting on a Suse distro.

Since Mongrel''s recipes use a send(run_method, "cmd") and
other
Mongrel users should have the same issue, I was asking on this  
mailing list. I will ask on Capistrano mailing list.

Thanks for your time,

Nicolas

On 09/07/07, Nicolas St-Laurent <nstlaurent at wantedtech.com>
wrote:
>
> bash_rc and bash_profile doesn''t do the same job in Bash. bash_rc
is
> sourced everytime a shell is started while profile is sourced only on
> login.
Yes, that''s right. I might be getting a little confused while trying
to follow this thread, but have you overridden your path in .bashrc ?
If not, I''m not surprised that it''s not getting set for a
non-interactive command, which need not run in a login shell (and
therefore might not source /etc/profile).

On Jul 09, 2007, at 16:11 , Nicolas St-Laurent wrote:
> Well, not really. I already set my path correctly. When I''m ssh
> logged with the user I use for my capistrano deployment, my path is :
>
> /usr/local/bin:/usr/local/sbin:/home/myuser/bin:/usr/local/bin:/usr/
> bin:/usr/X11R6/bin:/bin:/opt/gnome/bin:/usr/lib/mit/bin:/usr/lib/mit/
> sbin:/usr/local/java/bin.
>
> But, it goes to :
>
>>> /usr/bin:/bin:/usr/sbin:/sbin
>
> in Capistrano''s run method.
>
> bash_rc and bash_profile doesn''t do the same job in Bash. bash_rc
is
> sourced everytime a shell is started while profile is sourced only on
> login.
>
> My path is define in /etc/profile instead of locally in user account
> so that every users got almost the same path. It''s the default
> setting on a Suse distro.
>
> Since Mongrel''s recipes use a send(run_method, "cmd")
and other
> Mongrel users should have the same issue, I was asking on this
> mailing list. I will ask on Capistrano mailing list.
>
> Thanks for your time,
>
> Nicolas
>
> _______________________________________________
> Mongrel-users mailing list
> Mongrel-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-users
Nicolas,

There is one more thing you can try, although I haven''t experienced  
your issue you can try this inside capistrano:

default_environment["PATH"] = "/usr/local/bin:/usr/bin:/bin:/usr/
sbin:/sbin"

I''m assuming you''re using Cap2, and if you''re not
then: why not!? :)

Let me know if this helps, and yes this should have been in the  
Capistrano list :)

--
Wayne E. Seguin
Sr. Systems Architect & Systems Admin
wayneseguin at gmail.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-users/attachments/20070709/591d1078/attachment-0001.html

Le 9 juil. 07 ? 18:06, Nicolas St-Laurent a ?crit :
> Hello,
>
> I''m trying to deploy my application with Capistrano using Mongrel
> recipes. Since I''ve installed Ruby from source code, mongrel
scripts
> are found in /usr/local/bin. But the recipes can''t find
> mongrel_rails : "bash: mongrel_rails: command not found". The
path of
> the user account used to deploy is OK. For sure, I can redefine
> start_mongrel_cluster/restart_mongrel_cluster/stop_mongrel_cluster
> tasks in the recipes to add path before calling mongrel_rails.
>
> Any idea of a better solution ?
I experienced the same problem, it comes from two things : sshd and  
capistrano.

SSHd (at least on Suse Linux Entreprise Servers 10.1) is compiled and  
configured to have a really basic path defined and  
PermitUserEnvironment set to "no", if you combined that with  
capistrano not using any environment variables, you get your problem.

One solution is to set PermitUserEnvironment to "yes" in sshd_config  
and use ~/.ssh/environment file to set a path containing your  
mongrel_rails command (in your deployment user home). But be aware  
there are some security risks setting this variable to "yes".

Hopes this help.

Tron Jonathan
http://jonathan.tron.name

Le 07-07-10 ? 14:52, Jonathan Tron a ?crit :
> One solution is to set PermitUserEnvironment to "yes" in
sshd_config
> and use ~/.ssh/environment file to set a path containing your
> mongrel_rails command (in your deployment user home). But be aware
> there are some security risks setting this variable to "yes".
>
> Hopes this help.
Thanks a lot. It solve my problem. I can live with the security  
issue. And Capistrano 2.0 allow environment variables. But for now, I  
kept version 1.4x.