My shared host did not provide git, so I built and installed it into ~/bin.
When I ran it, I got the following error on most commands, although they were successful.
stdin: is not a tty
I can solve that problem by adding:
default_run_options[:pty] = true
to my deploy.rb, but then I get this error, which blocks deployment:
sh: git: command not found
How can I resolve both errors?
I tried adding a ~/.ssh/environment file with "PATH=$PATH:$HOME/bin" (and changing sshd_config to use it) but it did nothing.
It seems whatever shell is being used by capistrano is not using the ~/.bashrc or ~/.bash_profile on the remote server.
Any ideas how to set the path on the remote machine?
other info: I'm using OS X locally, and the shared server is linux on Site5.
Thanks, Chu - you put me on the right path.
just using: set :scm_command, "~/bin/git"
still gave me errors, since my local git is not in that place.
However, the following seems to work, and to solve my issues:
set :scm_command, "~/bin/git"
set :local_scm_command, "/usr/local/bin/git"
The problem is that you've set
default_run_options[:pty] = true
which means that your .bash_profile or your usual shell init file won't be run, which is not the case when you set it to false -- but then you'll have issues when it wants to ask you for the password.
To get around this problem, you can manually set your PATH environment variable in your deploy file:
default_environment['PATH'] = "/your/path/to/git:/and/any/other/path/you/need"
You should be able to specify the full path to git like so:
set :scm_command, "/home/your_cap_runner_user/bin/git"
I haven't tried this out for myself - found it in the documentation in the source code for git.rb in Capistrano itself.
stdin: is not a tty
This is probably because of CPanel installed on your shared host. It executes "mesg y" in global /etc/.bashrc file that is included in your ~/.bashrc one. So you can just comment-out the inclusion.
Here’s the source: http://webhostingneeds.com/Git_stdin_is_not_a_tty
A quick workaround is to set the following in your deploy.rb file:
set :deploy_via, :copy
This will cause the checkout to occur on your own machine and then be copied to the deployment server.
This is a great help, as I was running into the same issue as the original poster.
"Before" symptoms:
run cap deploy:setup (successful)
ran cap deploy:check (fails, with 'git command not found')
I now added set :scm_command, "~/bin/git" to my deploy.rb file.
ran cap deploy:setup (successful)
ran cap deploy:check (successful)
ran cap deploy:cold (fails, with the following error)
:97:in ``': No such file or directory - ~/bin/git info git#github.com:quintar/eu
reka.git -rHEAD (Errno::ENOENT)
So it looks like 'git' is recognized, but the repository I included in my deploy.rb is bypassed?
The ~/.ssh/environment file is not executed by a shell. It's a hardcoded environment file. If you want to set the path this way, you'll need to hardcode it instead of appending to $PATH. The other answers are possibly more correct, but setting ~/.ssh/environment correctly is a reliable fallback if all else fails.
Related
I'm trying to set up Mina for deploying my Rails app. Unfortunately, when running mina setup or mina deploy, I get to the password prompt, and then nothing happens anymore.
I can manually ssh with the given user and password, so this shouldn't be a problem. But I have no idea, where mina's stuck:
josh#macbuech:~/Documents/Work/MuheimWebdesign/base (features/deployment *)$ mina deploy --verbose
base#josh.ch's password:
-----> Mina: SIGINT received.
Elapsed time: 61.00 seconds
Interestingly, yesterday it was suddenly able to connect (one of a dozen retries worded, I guess):
josh#macbuech:~/Documents/Work/MuheimWebdesign/base (features/deployment *)$ mina deploy --verbose
base#josh.ch's password:
stdin: is not a tty
jailshell: line 3: cd: /var/www/base.josh.ch: No such file or directory
! ERROR: not set up.
The path '/var/www/base.josh.ch' is not accessible on the server.
You may need to run 'mina setup' first.
! Command failed.
Failed with status 15
Then, I couldn't connect to my server anymore (neither by using mina nor plain ssh). I had to call support, and they did something that re-enabled ssh for me. Mina still doesn't work.
In config/deploy.rb, I only added set :user ... and changed :domain, :deploy_to and :repository.
set :domain, 'josh.ch'
set :user, 'base'
set :deploy_to, "/var/www/base.josh.ch"
set :repository, 'git://jmuheim/base'
set :branch, 'master'
Any idea? I'd rather not switch back to Capistrano... Thank you.
This is an old question but this is for any future Googlers that stumble across this. I had the issue described in the question, mina hanging after password entry. Looking around in the issues section of the mina git repo lead me to the fix, albeit a silly one.
In your deploy.rb file put this setting:
set :term_mode, nil
Have you tried run:
mina init
after install gem?
Can you show your deploy.rb?
I didn't have any luck with password authentication. But with public key SSH authentication, it's working fine.
HOW TO: https://www.debian-administration.org/article/530/SSH_with_authentication_key_instead_of_password
I'm trying to deploy using Capistrano 3.1.0.
The file deploy.rb states:
# Default deploy_to directory is /var/www/my_app
However, when I run cap production deploy I get the following error:
mkdir: cannot create directory /var/www/shared
It appears to be ignoring my app name completely and trying to create directories in the wrong place. It should be trying to create /var/www/myapp/shared/. My deploy.rb file specifically has:
set :application, 'myapp'
Am I missing something here, or is this a bug?
UPDATE: The relevant line of the Capistrano source code appears to be:
set :deploy_to, "/var/www/#{fetch(:application)}"
in defaults.rb. If I print out the value of fetch(:application) it's nil, so something is stopping my application name from being set properly.
Turns out it's a bug with a fix that hasn't yet made it into a release.
Here's the change:
https://github.com/capistrano/capistrano/blob/master/lib/capistrano/defaults.rb#L3
Make sure you have the directory structure that Capistrano requires. You can use the Capistrano itself to create it with the command:
cap deploy:setup
Or you can create it directly with something like this:
# Capistrano will use /var/www/....... where ... is the value set in
# :application, you can override this by setting the ':deploy_to' variable
deploy_to=/var/www/:application
mkdir -p ${deploy_to}
mkdir ${deploy_to}/{releases,shared}
ref.: wiki deploy:setup and Authentication and Authorisation
edit: if you set the :deploy_to after the :application, you don't need the commit you mentioned.
I'm aware of the keep_releases option in capistrano and I have this set in our deploy script. The problem I'm having is I think more related to permission issues. I tried running cap deploy:cleanup but I get a permission denied error when trying to delete directories inside tmp/cache. I'm using fragment caching which is why I have lots of files inside tmp/cache.
Can someone shed any light how to fix this issue? I have to manually delete the folders in the server in order to clean up the releases folder.
It looks like I just have to pass use_sudo
cap production deploy:cleanup -s use_sudo=true
i will try to change the owner of your directory to the user you use for capistrano:
sudo chown -R capistrano_user /path/to/www/app
I've got a staging server with both standard Ruby and Ruby Enterprise installed. As standard Ruby refuses to install a critical gem, I need to set $PATH so that ruby/gem/rake/etc. always refer to the REE versions. And since I use Capistrano to deploy to our machines, I need to do it in Capistrano.
How can I set an environment variable once, and have it persist throughout the Capistrano session?
1) It's easy to do in bashrc files, but Capistrano doesn't read bashrc files.
2) I'd use Capistrano's
default_environment['PATH'] = 'Whatever'
but Capistrano uses these environment variables like
env PATH=Whatever command arg ...
and they're lost whenever another shell is spun up within the executable passed to env. Like when you use sudo. Which is kinda important:
[holt#Michaela trunk]$ env VAR=hello ruby -e "puts ENV['VAR']"
hello
[holt#Michaela trunk]$ env VAR=hello sudo ruby -e "puts ENV['VAR']"
nil
3) And I can't use the bash export command, as these are lost too - Capistrano seems to start up a new shell for each command (or something like that), and that's lost, too:
cap> export MYVAR=12
[establishing connection(s) to xxx.xxx.xxx.xxx]
cap> echo $MYVAR
** [out :: xxx.xxx.xxx.xxx]
cap>
4) I've tried messing with Capistrano's :shell and :pty options as well (and in combination with the other approaches), but no luck there, either.
So - what's the right way to do this? This seems like such a basic task that there should be a really simple way to accomplish it, but I'm out of ideas. Anyone?
Thanks in advance!
I have the exactly same problem, but I think this solution is better:
set :default_environment, {
'env_var1' => 'value1',
'env_var2' => 'value2'
}
This works for me like a charm.
If you need to set a variable on the remote host other than PATH, you should know that sshd only allows certain /etc/profile or ~/.bashrc environment variables by default, for security reasons. As Lou said, you can either do cap shell and use the cap> printenv command, or you can do cap COMMAND=printenv invoke in one command.
If you see the variable when you ssh into the remote shell normally, but you don't see it in the cap printenv command, here's one solution:
Set PermitUserEnvironment yes in your remote server's /etc/ssh/sshd_config file, and restart sshd
Edit the ~/.ssh/environment file for the remote user you are ssh'ing in as, and put your variable(s) there as VARIABLE=value
Now those should show up when you do cap COMMAND=printenv invoke
I think you have in fact 2 problems:
1) You want to change the PATH on your remote host(s).
Alter/set the path in your .bashrc on your remote host(s) and run cap> printenv, if your path is right, goto #2, else try to add export BASH_ENV=~/.bashrc to your /etc/profile (be careful, ~/.bashrc will then be run for all non-interactive shell for all users)
2) You want sudo to keep your PATH
Run visudo on your remote host(s) and add:
Defaults exempt_group = "<your_user>"
I needed to set an environment variable for a specific task to work. The "run" command allows you to pass options which include :env:
run "cmd", :env => { 'name' => 'value' }
In my case, I wanted to add the environment variable to a task that I didn't write, so I used default_run_options which is used by all invocations of run. I added this to the top of my Capfile:
default_run_options[:env] = { 'name' => 'value' }
I tried unsuccessfully to use #brian-deterling's technique, which is pretty commonly used by others who have discussed this... Maybe I'm doing something wrong, but meanwhile I found the dotenv-rails gem, and it worked very nicely for loading up values out of a .env file in my project root.
The instructions on their Github repo are pretty straight-forward. I added the Dotenv.load to my config/application.rb
I'm using: Rails 3, ruby 1.9.2 and trying to deploy using capistrano. When I run cap deploy:check, capistrano tells me that it can't find git on my deployment server (see below).
Any thoughts on what I'm doing wrong??
Here's my setup.
I have a git repo # github
I have a
laptop with an updated local copy of
the github repo
I have a local
"production" server (192.168.0.103) where the
production app should be deployed
I'm running all commands from the local repo on my laptop (not the production server)
If I run cap deploy:setup, my deploy.rb file successfully adds the "releases" and "shared" directories on my production server (aka 192.168.0.103).
If I run the cap deploy:check command, it fails with the error message of
`git' could not be found in the path (192.168.0.103).
What is strange (to me at least) is that git is definitely installed on 192.168.0.103 and the command that's used to see if git is there (which git) works when I ssh into 192.168.0.103.
So, obviously I'm doing something wrong (maybe in the deploy.rb file?)
Here's a sanitized version of the deploy.rb file
default_run_options[:pty] = true
set :application, "myapp"
set :repository, "git#github.com:xxxxxxx/myapp.git"
set :user, "abcde" #username that's used to ssh into 192.168.0.103
set :scm, :git
set :scm_passphrase, "xxxxxxxx"
set :branch, "master"
set :deploy_via, :remote_cache
set :deploy_to, "/Users/abcde/www"
role :web, "192.168.0.103"
role :app, "192.168.0.103"
Here's the output of cap deploy:check
* executing `deploy:check'
* executing "test -d /Users/abcde/www/releases"
servers: ["192.168.0.103"]
Password:
[192.168.0.103] executing command
command finished
* executing "test -w /Users/abcde/www"
servers: ["192.168.0.103"]
[192.168.0.103] executing command
command finished
* executing "test -w /Users/abcde/www/releases"
servers: ["192.168.0.103"]
[192.168.0.103] executing command
command finished
* executing "which git"
servers: ["192.168.0.103"]
[192.168.0.103] executing command
command finished
The following dependencies failed. Please check them and try again:
--> `git' could not be found in the path (192.168.0.103)
Okay, I think I figured it out.
I was basically having the same problem as described here: http://groups.google.com/group/capistrano/browse_thread/thread/50af1daed0b7a393
Here's a choice excerpt:
I try to deploy an application on a
shared environment on which I
installed git. I have added the path
to bashrc, but this would work only
in an interactive bash. When cap is
logging in, it will not be running
bash. If I run deploy:check it fails
by
--> `git' could not be found in the path (example.com) If i set
:scm_command, "/home/user/opt/bin/git"
the problem is solved with the
deploy:check command, but when I run
deploy:cold, it fails because it
tries to run /home/user/opt/bin/git
locally and I can't even put git in
there, because I use windows on my pc.
adding :scm_command, "path/to/my/git" fixed the issue, although I'm not 100% that this is the correct approach to take.
I would recommend using:
default_run_options[:env] = {'PATH' => '/home/user/opt/bin/git:$PATH'}
This will allow adjusting the PATH system environment variable (and of them more if needed) so that not only the "Capistrano can't find the SCM" problem get solved bu any other similar problems with Capistrano not running in interactive bash (not executing the .bashrc etc.).