[capistrano] Re: SSH Timeouts for Long Running Migrations

[Jamis Buck]

To be entirely honest, I almost never run my migrations via capistrano
anymore. I've been burned too many times by issues that come up during
a migration, that need manual intervention, so I usually do:

  $ cap deploy:update
  $ ssh to one of the app servers and run the migrations
  $ cap deploy:restart

That doesn't answer your question, though. Probably what needs to
happen is that the migrate task should force all connections to close
after the migration finishes, so that the next command that runs
causes them to open anew. You'd need to monkey patch the migrate task
itself to do that, though.

- Jamis

On Wed, Oct 21, 2009 at 6:44 PM, Mike bod...@gmail.com wrote:

 We have a long running migration. After the migration finishes on one
 box, when Cap starts the next task, the other ssh connections to the
 other servers timeout and the deploy fails.

 I have read a number of items on the net and from this group regarding
 this issue. However, there seems to be nothing that resolves the
 situation or at least nothing specific about what versions of cap and/
 or ruby solve the issue.

 I'm sure that many others must be encountering this problem and I
 would like to know if there is a highly recommended way to deal with
 this issue, any help is appreciated.

 Mike
 


--~--~-~--~~~---~--~~
* You received this message because you are subscribed to the Google Groups 
Capistrano group.
* To post to this group, send email to capistrano@googlegroups.com
* To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com For more options, visit this group at 
http://groups.google.com/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Best way to trim duplicate hosts in a given role

[Jamis Buck]

It shouldn't matter, actually, since Capistrano will only connect to
distinct hosts. Consider the case where a host exists in two different
roles (e.g. :web and :app). Tasks set to run on both :web and :app
would get that host twice in the resulting host list, so Capistrano
has to make sure and remove duplicates just before executing tasks.

- Jamis

On Fri, Oct 9, 2009 at 11:29 AM, Joe McDonagh
joseph.e.mcdon...@gmail.com wrote:

 Anybody think of a good way to trim duplicate hosts in a role?

 I realize this probably never happens to most of you, but I fill in
 dynamic roles via two DB's and there is a possibility of duplicating a
 host. Part of this is an architectural problem that I will fix in due
 time, however this would be nice to figure out.

 --
 Joe McDonagh
 Operations Engineer
 www.colonfail.com


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: How to Specify local and remote repository locations?

[Jamis Buck]

What happens if you use /path/to/repo.git instead of
file:///path/to/repo.git?

I know I've used local repositories with Capistrano without problem in
the past (as long as I'm using a deployment method that doesn't
require the remote hosts to access the repository).

- Jamis

On Thu, Sep 17, 2009 at 10:36 AM, BJ Neilsen bj.neil...@gmail.com wrote:

 Hi all,

 I'm having an issue deploying a Monk (Sinatra) app to an internal
 server here at work using Git. I've setup the git remote repos on the
 server that we're deploying to, we'll call it roger. The issue I'm
 coming into trying to deploy:cold is that if I specify
 set :repository, file:///path/to/repo.git, the local ls-remote fails
 since that path is relative to the server filesystem. But if I specify
 the whole ssh path (Set :repository, m...@roger:/path/to/repo.git),
 then I have to authenticate every time I deploy. This is still a minor
 problem, except authentication fails evertime, even though I can do
 normal ssh connections just fine. Is there any way to specify a
 local_repos path and remote_repos path?

 Here is the error output from deploy:cold

   �...@local ~/myapp: cap deploy:cold
      * executing `deploy:cold'
      * executing `deploy:update'
     ** transaction: start
      * executing `deploy:update_code'
        executing locally: git ls-remote
 deplo...@roger.mycompany.com:/path/to/repo.git master
    deplo...@roger.mycompany.com's password:
      * executing git clone -q deplo...@roger.mycompany.com:/path/to/
 repo.git /var/www/myapp/releases/20090917163008  cd /var/www/myapp/
 releases/20090917163008  git checkout -q -b deploy
 1af7918b501b0bad10ad4b51853453af224fed89  (echo
 1af7918b501b0bad10ad4b51853453af224fed89  /var/www/myapp/releases/
 20090917163008/REVISION)
        servers: [roger.mycompany.com]
        [roger.mycompany.com] executing command
     ** [roger.mycompany.com :: err] Permission denied, please try
 again.
     ** [roger.mycompany.com :: err] Permission denied, please try
 again.
     ** [roger.mycompany.com :: err] Permission denied
 (publickey,gssapi-keyex,gssapi-with-mic,password).
     ** [roger.mycompany.com :: err] fatal: The remote end hung up
 unexpectedly
        command finished
    *** [deploy:update_code] rolling back
      * executing rm -rf /var/www/myapp/releases/20090917163008;
 true
        servers: [roger.mycompany.com]
        [roger.mycompany.com] executing command
        command finished
    failed: sh -c \git clone -q deplo...@roger.mycompany.com:/path/
 to/repo.git /var/www/myapp/releases/20090917163008  cd /var/www/
 myapp/releases/20090917163008  git checkout -q -b deploy
 1af7918b501b0bad10ad4b51853453af224fed89  (echo
 1af7918b501b0bad10ad4b51853453af224fed89  /var/www/myapp/releases/
 20090917163008/REVISION)\ on roger.mycompany.com

 So the line executing locally: git ls-remote
 deplo...@roger.mycompany.com:/path/to/repo.git master works fine if
 the repository path is ssh, but the remote git clone fails. If I
 change the repository path to file:///... I suspect it would work if
 it got there, but the local ls-remote command fails.

 I can't be the only one who's ever wanted to deploy to the same
 machine as the hosted repo, can I?

 Thanks for the help.
 BJ

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Always checks out branch 'deploy'

[Jamis Buck]

Nick,

It's not checking out out a remote branch named deploy. It's creating
a new local branch called deploy, and then hard resetting it to the
revision you requested to deploy (e.g. HEAD on master, or whatever).

e.g.

  git checkout deploy

Would checkout an existing branch called 'deploy'.

  git checkout -b deploy

Creates a new branch called 'deploy', and then checks it out.

- Jamis

On Wed, Sep 16, 2009 at 1:00 PM, Nik Bauman nikbau...@gmail.com wrote:

 Hi - in my deploy.rb I specify the following settings:

 set :application, project
 set :repository, g...@github.com:nbauman/project_application.git
 set :branch, master
 set :scm, :git


 Yet, when I deploy I always see the following:
 * executing `deploy:update_code'
 executing locally: git ls-remote g...@github.com:nbauman/
 project_application.git master
 * executing git clone -q g...@github.com:nbauman/
 project_application.git /home/project/www/releases/20090916183149 
 cd /home/project/www/releases/20090916183149  git checkout -q -b
 deploy cce9a520c3965b518211de2e9aacaef602460979  (echo
 cce9a520c3965b518211de2e9aacaef602460979  /home/project/www/releases/
 20090916183149/REVISION)
    servers: [ec2-ip.compute-1.amazonaws.com]

 Notice the git checkout -q -b deploy

 When I go to my server and run 'git status' it always says it's on the
 deploy branch. Yet I have the files that I've added to the master
 branch. I'm confused...

 How do I get it to check out master?

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Custom TaskDefinition classes

[Jamis Buck]

Tasks aren't executed within the scope of their task definition, which
means adding methods to TaskDefinition won't help you (the new methods
won't be accessible to the task). Tasks are added to the current
namespace instance, which is also where custom methods are added.
Thus:

  task :foo do
run_something
  end

  def run_something
  end

Both the :foo task and the run_something method exist side-by-side on
the top-level Capistrano::Configuration instance, and if you do:

  namespace :bar do
 task :foo do
 end

 def run_something
 end
  end

Both :foo and run_something exist side-by-side in the :bar namespace.
It's all very non-pollutionary.

- Jamis

On Wed, Aug 26, 2009 at 7:48 AM, jerry.vosjerry@gmail.com wrote:

 In building out some complex deployments, I seem to continually have
 the need to have helper methods for my tasks. The way I've done it and
 the way I see capistrano-ext does this, is to just define the helpers
 alongside your task definitions:

 Capistrano::Configuration.instance(:must_exist).load do
  def something_interesting; end
 end

 This works fine and all, but I have the same problem with this that I
 have with doing this in rake tasks, that is, there is no scoping to
 these method definitions. This is worse in rake tasks, since doing
 this in a rake task defines the method on Object, but it still feels
 bad to me. The practical problem I've found is it makes it hard to
 track down where those methods are defined.

 My way of solving this with rake tasks (and others like rSpec seem to
 solve this) is by having subclasses of Rake::Task. I looked into doing
 this for capistrano, and I think it would just mean a little
 refactoring around the Capistrano::Configuration::Namespaces#task
 method. Before diving into this though, I wanted to see if anyone sees
 any downside to this or if there's some other common pattern to this
 I'm missing.

 You could also define helper classes and put the methods in there, but
 often you need access to the run/sudo/... functionality which would
 require injecting capistrano classes into the helpers. I'm not sure if
 that seems semi-elegant or semi-clunky, but I still feel that it
 should be solved with a custom TaskDefinition. It does seem flexible,
 but that the usage would be complicated.

 For conversation's sake, an example:
 Capistrano::Configuration.instance(:must_exist).load do
  namespace :data do
    desc Verifies that the data version is as expected
    task :verify_version = :environment, :roles = :db do
      run_rake(data:verify_version)
    end
  end

  def run_rake(*args); run(build_rake_command(*args)); end
  def system_rake(*args); system(build_rake_command(*args)); end
  def sudo_rake(*args); sudo(build_rake_command(*args)); end
 end

 I'd want to implement those methods as:
 module Capistrano
  class RakeTaskDefinition
    def (run,system,sudo)_rake
  end

  def rake_task(*args)
    RakeTaskDefinition.define_task(*args)
  end
 end

 Capistrano::Configuration.instance(:must_exist).load do
  namespace :data do
    desc Verifies that the data version is as expected
    rake_task :verify_version = :environment, :roles = :db do
      run_rake(data:verify_version)
    end
  end
 end

 Truthfully, the other reason I'm asking this instead of coding it is
 it seems like this is another one of those things Rake already does,
 so it's again making me wonder why not just spend the time making cap
 tasks be based on Rake (ala Vlad, but without trimming cap's
 functionality), but that's a much bigger topic.

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: release_path == current_path.symlink

[Jamis Buck]

release_path is recomputed every time Capistrano is invoked, and is
only valid for a deploy that is IN PROGRESS.

current_path, on the other hand, always points to the 'current' symlink.

current_release is always the most recent release in the releases directory.

Lastly, latest_release is the same as release_path if a deploy is in
progress, or current_release if not.

- Jamis

On Sun, Jul 26, 2009 at 8:06 PM, Houdinidmitrii.go...@gmail.com wrote:

 release_path:
 /home/dima/www/ebank/releases/20090727020410

 currency_path:
 /home/dima/www/ebank/releases/20090727013231

 Is it ok?
 Why it's happend?

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Identify current host

[Jamis Buck]

On Mon, Jul 6, 2009 at 9:06 AM, Gary
Richardsongary.richard...@gmail.com wrote:
 Hmm. That's odd..$CAPISTRANO:HOST$ wasn't working for me on Friday. Must be
 them gremlins.
 Is there another variable I can use to get the current host in the ruby
 code? This is what I'm trying to do:

Short answer: no.

Longer answer: yes, kind of.

Keep in mind one key concept: capistrano does not run a command on
each server sequentially; it runs the commands on all servers in
parallel. Thus, within a task, there is no such thing as a current
host. What you have is a set of servers that match the current task,
and all commands invoked within that task will run in parallel on that
set of servers.

So, what you can do is get the list of matching servers:

  task :bootstrap, :roles = :master do
servers = find_servers_for_task(current_task)
servers.each do |server|
   puts host: #{server.host}
end
  end

- Jamis

   task :bootstrap, :roles = [:master] do
         # instanceids is an array containing hostname = instanceid
 id = instanceids[$CAPISTRANO:HOST$]
 run register_host -H $CAPISTRANO:HOST$ -s #{id}
   end
 Obviously, $CAPISTRANO:HOST$ doesn't interpolate on the id = instanceids[]
 line.
 Thanks!
 On Mon, Jul 6, 2009 at 3:31 AM, Rafael G. r...@aspgems.com wrote:

 Gary Richardson wrote:
  Hey,
 
  Two part question that I haven't been able to answer:
 
  1) can I get the current host a task is executing on? I've read some
  stuff about $CAPISTRANO:HOST$, but it doesn't seem to work for me
 I tested this task and works for me:

    task :host_name do
        run host $CAPISTRANO:HOST$
    end

 What OS are you using? Could you paste your deploy.rb in
 someplace(gist.github, pastie,...)?

  2) if I have an array of values (let's say an array that maps ec2 host
  names to ec2 instance id's), can I use this same method to look up
  something from that array?
 Capistrano uses ruby If you can do it with ruby you can do the same in a
 capistrano task.

 --
 Rafa





 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Deploying without SCM

[Jamis Buck]

There is also a :none SCM that you can use. However, it only works
with the :copy deployment method that Lee mentioned.

So:

  set :repository, .
  set :scm, :none
  set :deploy_via, :copy

You can read more about the :none SCM in the comments for that module:

http://github.com/capistrano/capistrano/blob/e8429b0e198d3dbff53853e3b83f0155f05a910d/lib/capistrano/recipes/deploy/scm/none.rb

- Jamis

On Thu, Jul 2, 2009 at 12:29 PM, Lee Hambleylee.hamb...@gmail.com wrote:
 There is also the deploy_via :copy that will tar up your working directory
 and deploy it to the server, you can read more about that on our wiki under
 Understanding deployment strategies
 - Lee

 2009/7/2 Joe McDonagh joseph.e.mcdon...@gmail.com

 sixones wrote:
  Hello,
 
  I've seen this question pop up a few times but haven't been able to
  find a clear answer. Is there away to deploy with Capistrano without
  using SCM? I like the idea of the automated deployment strategies
  available with Capistrano and would like to benefit rather than
  manually uploading via SFTP etc..
 
  I fully understand how important SCM is but I'm planning on using
  Capistrano to deploy binary builds to a remote server. Storing the
  builds inside a repository just doesn't make sense for obvious
  reasons.
 
  Thanks in advance
 
  
 
 There is a 'put' method that uses scp to transfer files. You can make a
 task that uses this method to upload binaries.

 --
 Joe McDonagh
 Operations Engineer
 www.colonfail.com





 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Multistage deploy does not seem to be reading stage-specific files

[Jamis Buck]

Try this:

  role(:web) { [domain, {:primary = true}] }

In other words, the block should return an array corresponding to the
arguments you would normally have passed to role(). The first _n_
elements of the array are domain names to assign to the given role,
and the last option may be a hash containing the properties to set on
those servers (e.g., :primary = true, and so forth).

- Jamis

On Tue, Jun 23, 2009 at 5:42 PM, Cyrillecbonne...@gmail.com wrote:

 Thanks Lee,

 but I need to defer the evaluation of domain (see thread above for
 details), hence the block around domain.

 The problem is that I can't figure out how to set the primary to true
 while using the block syntax...

 Cheers

 Cyrille

 On Jun 23, 10:14 pm, Lee Hambley lee.hamb...@gmail.com wrote:
 If you have already set domain, do this:

 role :web,domain
 role :app, domain
 role :db,   domain

 else, use yours, for the rest, do this:

 role :db , domain, :primary = truerole(:db , domain, :primary = true)
 role(:db , domain, {:primary = true})

 (that is, right, righter and rightest syntax. Ruby is smart enough to
 figure out what you need without writing it long hand every time)

 2009/6/23 Cyrille cbonne...@gmail.com



  Since I spent 30 mins figuring out how this translates in code, maybe
  it will help someone else:

  role(:web) {#{domain}}
  role(:app) {#{domain}}
  role(:db) {#{domain}}

  However, I didn't manage to set :primary to true for the :db role:

  role(:db) {#{domain}}, :primary = true
  role(:db) {#{domain}, :primary = true}

  all fail.

  Anyone knows the correct syntax? (it is probably obvious to Capistrano
  gurus out there :-)

  Cheers

  Cyrille

  On May 29, 11:23 am, Cynthia Kiser cynthia.ki...@gmail.com wrote:
It seems that the problem is located here. You are trying to access the
domain variable before it is set (the variable will be set only when
  the
staging task is called, after all the necessary files are parsed.

It is possible to use a block for the role directive, which will be
evaluated only when required (that is, during the deploy task, after
  the
staging task is called), but you can't use blocks for the server
  directive.

   Thanks Jean-Philippe. Changing everything to roles and then using blocks
  to
   assign domain to them allows me to deploy! Yea!
   --
   Cynthia Kiser
   cynthia.ki...@gmail.com

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Ruby (Capsitrano) Returning Incorrect Exit Code

[Jamis Buck]

I'd be really curious to see the full output of a Capistrano run that
appeared to complete successfully, and yet terminated with a non-zero
exit code.

- Jamis

On Wed, Jun 17, 2009 at 4:03 AM, Lee Hambleylee.hamb...@gmail.com wrote:
 Hey,
 Someone (joe?) was hanging out in IRC last night asking about why capistrano
 always returned the failed exit code when it appeared to complete
 sucessfully I can think of two potential reasons:

 Your server having written to STDERR caused Capistrano to consider that
 that's an error
 Equally likely this Ruby 1.8.7
 bug: http://rubyforge.org/tracker/?func=detailatid=1698aid=9300group_id=426

 Just what I know, anything anyone else knows would be great!
 - Lee
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Ignoring lost+found as a release name

[Jamis Buck]

The problem is that cap has to accomodate the lowest common
denominator, and not every ls supports -r, or -1.

- Jamis

On Tue, Jun 16, 2009 at 1:20 PM, Robrob.biedenh...@gmail.com wrote:

 OK, in the latest release the code is:
 _cset(:releases) { capture(ls -xt #{releases_path}).split.reverse }

 which is better, but could be even better as:
 _cset(:releases) { capture(ls -1tr #{releases_path}).split }

 In any case, cap _2.5.5_ does the right thing.

 -Rob

 On Jun 16, 1:33 pm, Rob rob.biedenh...@gmail.com wrote:
 On a new server that I'm setting up, I've run into a slight problem. I
 have a partition mounted to hold the releases.

 Filesystem             Size   Used  Avail Use% Mounted on
 /dev/mapper/code-app   5.3G   329M   4.7G   7% /data/stylepath/
 releases

 in the recipes/deploy.rb, there is:

 _cset(:releases)          { capture(ls -x #
 {releases_path}).split.sort }

 and the name lost+found sorts later than the 20090616132111 style
 names and cap tries to run a rake from the lost+found directory.

 (As an aside, I don't know why the command is ls -x ... it seems
 like ls -1 ... would be more intention-revealing.)

 Is there any way to override this list to be some like either:
 _cset(:releases)          { capture(ls -1 #{releases_path}/[0-9]
 *).split.sort }
 Or:
 _cset(:releases)          { (capture(ls -1 #{releases_path}).split -
 ['lost+found']).sort }

 -Rob
 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: command line arguments

[Jamis Buck]

Yeah, that post describes capistrano 1.x behavior.

The same thing in cap2 would be something like:

   p option1 is #{opt1} if exists?(:opt1)

- Jamis

On Sat, Jun 13, 2009 at 10:29 AM, kennykennethst...@gmail.com wrote:

 from here:  http://ryandaigle.com/archives/2007/6

 you could check if a command line argument was supplied via
 'configuration[:opt1]'

 'configuration' doesn't work anymore.  cap complains that it is
 undefined.   is there any way for me to do this?

 thanks,

 kenny

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: No ftp transport?

[Jamis Buck]

FTP was not included for a variety of reasons. Capistrano is built on
top of SSH, and everything it uses to communicate with the servers
runs over that transport (e.g., SSH itself, SFTP, and SCP). To add FTP
would require a significant change to how parallel commands are
processed. (It would actually be fairly hard to make FTP run in
parallel with other FTP commands, since it is a synchronous protocol).
Also, FTP is extremely insecure (you realize it sends the password in
clear text, generally, right?). I'd strongly recommend you avoid FTP.

- Jamis

On Wed, Jun 3, 2009 at 8:43 AM, Byron Saltysiak byronsa...@gmail.com wrote:

 I'm surprised that there would be no ftp transport supported so I'm
 writing because perhaps I'm overlooking the obvious. However looking
 in transfer.rb I see:
 --
          session_map[session] = case transport
            when :sftp
              prepare_sftp_transfer(session_from, session_to, session)
            when :scp
              prepare_scp_transfer(session_from, session_to, session)
            else
              raise ArgumentError, unsupported transport type:
 #{transport.inspect}
            end
        end
 --

 Is there a normal solution to using ftp if desired? Is this something
 I should try to add myself?

 --
 Byron

 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: No ftp transport?

[Jamis Buck]

On Wed, Jun 3, 2009 at 8:53 AM, Byron Saltysiak byronsa...@gmail.com wrote:

 I'm only interested in using ftp to upload. It seems like it could be
 added to that single command without requiring any changes to running
 commands. I haven't delved too deeply yet so let me know if this is
 crazy talk.

The single-server scenario (which is just a special case of what
Capistrano handles) could do FTP easily enough: you could even do it
yourself within a task, manually, with Ruby's Net::FTP library.
However, the general case (FTP'ing something to multiple servers at
the same time) is going to be non-trivial, I suspect, and almost
certainly won't just drop in. I'd be happy to be wrong, though.

 Point taken. If I can use sftp I will but I'm trying to move files
 (via a utility account - not mine) to repository server within the
 company firewall. Of course this is a server I don't control.

If you can SSH, you should be able to SCP or SFTP, too? Unless the
admins have disabled both of those, which is possible, but it might be
worth communicating with them about it, since either of those are
infinitely to be preferred over FTP.

- Jamis

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: No ftp transport?

[Jamis Buck]

On Wed, Jun 3, 2009 at 9:05 AM, Byron Saltysiak byronsa...@gmail.com wrote:

 Unfortunately, I'd already tried ssh and it's not allowing it. I've
 requested the ability to scp or sftp but we'll see. I have a feeling
 this box was setup as ftp only for some purpose (perhaps 3rd party
 integration or something?) and also purposely has limited other
 functionality. Hopefully I'm wrong.

Oh, wow, you can't even SSH? Then yeah, your script is going to be the
way to go. Capistrano won't work for that scenario, at all. Capistrano
really is exclusively SSH (by design).

- Jamis

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Deploying to multiple hosts with one after deploy... callback

[Jamis Buck]

Also, to execute a task only on (for instance) the hosts that have
:primary = true defined:

  task :foo, :roles = :web, :only = { :primary = true } do
# ...
  end

That'll run on all hosts in the web role that have :primary = true set.

- Jamis

On Mon, Jun 1, 2009 at 11:59 AM, Lee Hambley lee.hamb...@gmail.com wrote:
 there is the :once = true addition you can make to the run call definition
 to make it only run on the first host that matches.
 Documented here: http://wiki.capify.org/index.php/Run#options
 2009/6/1 Supagroova supagro...@gmail.com

 Hi all,

 I have a recipe deploying to multiple hosts, and have a 'after'
 callback setting a tag for the deploy in my SCM. Problem is it's being
 executed each time for each host and I only want to execute it once:

 role :web, '_IP_ADDRESS_', '_IP_ADDRESS_', '_IP_ADDRESS_', :primary =
 true

 +

 after deploy:update_code, deploy:create_scm_tag

 Any ideas/help?

 Thanks!




 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[capistrano] Re: Preventing parallel execution on the same host (under two names)

[Jamis Buck]

My recommendation: keep the host names distinct, and just use roles to
indicate different purposes of identical hosts. Thus, you'd have
host1 in both the app and loadbalancer roles.

Personally, I've used the fact that Capistrano does NOT resolve host
names early. It's great for testing recipes, demoing (and debugging)
Capistrano, etc. I'd hate to see that go away.

- Jamis

On Wed, May 27, 2009 at 5:45 PM, Christian van der Leeden
christian.vanderlee...@googlemail.com wrote:

 Hi,

        we're deploying on EC2 and to keep the setup clean we've defined host
 aliase names.
 E.g. app1 and app2 for the app servers, lb1 for loadbalancer 1 etc.

 Even though the names are different the hosts are sometimes the same.
 E.g. load balancer
 is also hosting the app server 1. On a deploy the code deploy would
 now run in parallel
 on the same host (lb1 and app1 who are identical).

 I'm looking for ideas on how to patch (or configure) capistrano to
 prevent this situation.

 I imagine something along the lines of resolving the hostnames before
 running a command
 and then filtering out the duplicates. Is there an easy way to do
 accomplish this?

 Thanks

 Christian


 


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
Capistrano group.
To post to this group, send email to capistrano@googlegroups.com
To unsubscribe from this group, send email to 
capistrano+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.co.uk/group/capistrano?hl=en
-~--~~~~--~~--~--~---

[Capistrano] Re: backticks being ignored

[Jamis Buck]

The reason it is escaped is because Capistrano invokes the command via 
'sh' (by default). E.g., the following run command:

   run echo today is `date`

Gets translated into the following shell command:

   sh -c echo today is \`date\`

The backticks need to be escaped so that they get evaluated by the inner 
shell, and not the outer shell.

That said, what does the rest of your capfile look like? Are you setting 
:shell anywhere? What version of the posix shell do you have on your 
remote host?

You might also try setting :shell to false, so that all commands are 
invoked directly:

   set :shell, false

That way, commands will be run without wrapping them in a sh -c ... call.

- Jamis

On 5/19/09 10:33 AM, Scott Johnson wrote:
 I don't believe it is a permissions thing. I can run the same command
 not in backticks and it works. I can run the backticked command
 directly (not through Capistrano) and it works as expected:

 date is Tue May 19 09:25:51 PDT 2009 so there

 And I can edit Capistrano's source as described above and get it to
 work.

 There is something going on with Capistrano's escaping of the
 backticks that I don't understand. Why is it necessary on every
 computer except mine to escape the backticks? And why, when they are
 escaped on my machine, does the backticked command simply disappear
 without a trace?

 I can't imagine what could be so different on my machine. I realize
 I'm running an old Fedora, but things like backticks and shell escape
 characters haven't changed in 25 years.


 On 19 May, 08:10, Lee Hambleylee.hamb...@gmail.com  wrote:
 Scott,
 Hate to respond with a classic `worksforme` -- may it be that your user
 (humor me) doesn't have access to do any of the things you are asking, try
 something like run('touch `echo date`') or similar.

 To save potential email formatting issues, please post the code, output and
 error all in a gist/pastie and post us the links.

 - Lee

 2009/5/19 Scott Johnsonsc...@scottjohnson.org



 No difference. Not only is the output of the backticked command not
 getting into the string, the command itself is never being run. I can
 replace the command with `touch file.txt` and that file is never
 created.
 On 19 May, 01:26, Lee Hambleylee.hamb...@gmail.com  wrote:
 Try,
 task :foo, :hosts =  my.host.com do
   run echo date is `cat /bin/date` so there
 end
 2009/5/19 Scott Johnsonsc...@scottjohnson.org
 I have a run command that uses shell backticks, yet the command in the
 backticks never runs and I get an empty string instead of the output
 of the command.
 My Capfile:
 task :foo, :hosts =  my.host.com do
   run echo date is `/bin/date` so there
 end
 Output from running 'cap foo':
   * executing 'foo'
   * executing echo date is `/bin/date` so there
 servers: [my.host.com]
 [my.host.com] executing command
   ** [out :: my.host.com] date is  so there
 command finished
 Bizarre.
 I'm running cap 2.5.5 on Fedora Core release 6 with Ruby 1.8.7. The
 local and remote machine are the same (ie, I'm launching cap from
 my.host.com).
 If I edit line 212 of lib/capistrano/command.rb (that escapes certain
 special characters in the command) and remove the backtick from the
 gsub args, it works. But I somehow doubt this is the proper solution,
 since I seem to be the only one having this problem.
 

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

[Capistrano] Re: backticks being ignored

[Jamis Buck]

Maybe it's something with that version of GNU bash? This one works for me:

$ sh --version
sh --version
GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
Copyright (C) 2005 Free Software Foundation, Inc.

It also works fine with the posix shell in Ubuntu (not sure which 
version of Ubuntu, but fairly recent).

Also, I think I led you astray with the set(:shell, false) nonsense. The 
correct way to set that is either this:

   run(echo today is `date`, :shell = false)

or

   default_run_options[:shell] = false

The former only applies to that run invocation; the latter applies 
globally to all run invocations.

- Jamis

On 5/19/09 11:32 AM, Scott Johnson wrote:
 Getting closer! Something is wacked with my shell:

 % sh -c echo today is \`date\`
 today is

 % sh --version
 GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
 Copyright (C) 2005 Free Software Foundation, Inc.

 Perhaps I have some environment variable set wrong or something?

 Jamis, the capfile I posted in my original message is the complete
 capfile. I tried adding set :shell, false and it made no difference.

 I suppose the change I made to command.rb is incorrect because the
 backticked command will be run locally instead of remotely. (Right?)


 On 19 May, 09:47, Jamis Buckjamis.b...@gmail.com  wrote:
 The reason it is escaped is because Capistrano invokes the command via
 'sh' (by default). E.g., the following run command:

 run echo today is `date`

 Gets translated into the following shell command:

 sh -c echo today is \`date\`

 The backticks need to be escaped so that they get evaluated by the inner
 shell, and not the outer shell.

 That said, what does the rest of your capfile look like? Are you setting
 :shell anywhere? What version of the posix shell do you have on your
 remote host?

 You might also try setting :shell to false, so that all commands are
 invoked directly:

 set :shell, false

 That way, commands will be run without wrapping them in a sh -c ... call.

 - Jamis

 On 5/19/09 10:33 AM, Scott Johnson wrote:

 I don't believe it is a permissions thing. I can run the same command
 not in backticks and it works. I can run the backticked command
 directly (not through Capistrano) and it works as expected:
 date is Tue May 19 09:25:51 PDT 2009 so there
 And I can edit Capistrano's source as described above and get it to
 work.
 There is something going on with Capistrano's escaping of the
 backticks that I don't understand. Why is it necessary on every
 computer except mine to escape the backticks? And why, when they are
 escaped on my machine, does the backticked command simply disappear
 without a trace?
 I can't imagine what could be so different on my machine. I realize
 I'm running an old Fedora, but things like backticks and shell escape
 characters haven't changed in 25 years.
 On 19 May, 08:10, Lee Hambleylee.hamb...@gmail.comwrote:
 Scott,
 Hate to respond with a classic `worksforme` -- may it be that your user
 (humor me) doesn't have access to do any of the things you are asking, try
 something like run('touch `echo date`') or similar.
 To save potential email formatting issues, please post the code, output and
 error all in a gist/pastie and post us the links.
 - Lee
 2009/5/19 Scott Johnsonsc...@scottjohnson.org
 No difference. Not only is the output of the backticked command not
 getting into the string, the command itself is never being run. I can
 replace the command with `touch file.txt` and that file is never
 created.
 On 19 May, 01:26, Lee Hambleylee.hamb...@gmail.comwrote:
 Try,
 task :foo, :hosts =my.host.com do
run echo date is `cat /bin/date` so there
 end
 2009/5/19 Scott Johnsonsc...@scottjohnson.org
 I have a run command that uses shell backticks, yet the command in the
 backticks never runs and I get an empty string instead of the output
 of the command.
 My Capfile:
 task :foo, :hosts =my.host.com do
run echo date is `/bin/date` so there
 end
 Output from running 'cap foo':
* executing 'foo'
* executing echo date is `/bin/date` so there
  servers: [my.host.com]
  [my.host.com] executing command
** [out :: my.host.com] date is  so there
  command finished
 Bizarre.
 I'm running cap 2.5.5 on Fedora Core release 6 with Ruby 1.8.7. The
 local and remote machine are the same (ie, I'm launching cap from
 my.host.com).
 If I edit line 212 of lib/capistrano/command.rb (that escapes certain
 special characters in the command) and remove the backtick from the
 gsub args, it works. But I somehow doubt this is the proper solution,
 since I seem to be the only one having this problem.
 

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

[Capistrano] Re: backticks being ignored

[Jamis Buck]

I'll bet it's tcsh. Capistrano calls sh -c ... specifically to work 
around issues with non-posix shells; it sure sucks when those non-posix 
shells make it impossible to make posix calls.

I'm afraid it's looking like your only option is going to be to change 
your default shell to something posix. :(

- Jamis

On 5/19/09 12:47 PM, Scott Johnson wrote:
 Adding :shell =  false to the run params does work. But I would still
 like to resolve this. I'm probably not the last person that will
 encounter this problem with Capistrano, and while it's evidently not
 the tool's fault, if there's something Cap can do to avoid it, that
 would be nice.

 I think it's clearly something with my environment. I tried the sh -c
 command on all the bash versions I could find, all using the same
 environment, and they all failed.

 3.1.17(1)-release (i686-redhat-linux-gnu)
 3.1.7(1)-release (x86_64-redhat-linux-gnu)
 2.0.5a.0(1)-release (i686-pc-linux-gnu)
 3.00.15(1)-release (i686-redhat-linux-gnu)

 But when I ran at home (WinXP, msysGit bash, with the default msysGit
 environment), it worked fine.

 One difference is the shell I'm launching from: tcsh (my default shell
 on those systems) in all the broken cases. When I launch sh -c from
 bash itself, it works. Perhaps tcsh is mangling the command before
 invoking sh? Here's a clue:

 % echo foo is \`date\`
 foo is \

 I don't understand that.




 On 19 May, 10:39, Jamis Buckjamis.b...@gmail.com  wrote:
 Maybe it's something with that version of GNU bash? This one works for me:

 $ sh --version
 sh --version
 GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
 Copyright (C) 2005 Free Software Foundation, Inc.

 It also works fine with the posix shell in Ubuntu (not sure which
 version of Ubuntu, but fairly recent).

 Also, I think I led you astray with the set(:shell, false) nonsense. The
 correct way to set that is either this:

 run(echo today is `date`, :shell =  false)

 or

 default_run_options[:shell] = false

 The former only applies to that run invocation; the latter applies
 globally to all run invocations.

 - Jamis

 On 5/19/09 11:32 AM, Scott Johnson wrote:

 Getting closer! Something is wacked with my shell:
 % sh -c echo today is \`date\`
 today is
 % sh --version
 GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
 Copyright (C) 2005 Free Software Foundation, Inc.
 Perhaps I have some environment variable set wrong or something?
 Jamis, the capfile I posted in my original message is the complete
 capfile. I tried adding set :shell, false and it made no difference.
 I suppose the change I made to command.rb is incorrect because the
 backticked command will be run locally instead of remotely. (Right?)
 On 19 May, 09:47, Jamis Buckjamis.b...@gmail.comwrote:
 The reason it is escaped is because Capistrano invokes the command via
 'sh' (by default). E.g., the following run command:
  run echo today is `date`
 Gets translated into the following shell command:
  sh -c echo today is \`date\`
 The backticks need to be escaped so that they get evaluated by the inner
 shell, and not the outer shell.
 That said, what does the rest of your capfile look like? Are you setting
 :shell anywhere? What version of the posix shell do you have on your
 remote host?
 You might also try setting :shell to false, so that all commands are
 invoked directly:
  set :shell, false
 That way, commands will be run without wrapping them in a sh -c ... call.
 - Jamis
 On 5/19/09 10:33 AM, Scott Johnson wrote:
 I don't believe it is a permissions thing. I can run the same command
 not in backticks and it works. I can run the backticked command
 directly (not through Capistrano) and it works as expected:
 date is Tue May 19 09:25:51 PDT 2009 so there
 And I can edit Capistrano's source as described above and get it to
 work.
 There is something going on with Capistrano's escaping of the
 backticks that I don't understand. Why is it necessary on every
 computer except mine to escape the backticks? And why, when they are
 escaped on my machine, does the backticked command simply disappear
 without a trace?
 I can't imagine what could be so different on my machine. I realize
 I'm running an old Fedora, but things like backticks and shell escape
 characters haven't changed in 25 years.
 On 19 May, 08:10, Lee Hambleylee.hamb...@gmail.com  wrote:
 Scott,
 Hate to respond with a classic `worksforme` -- may it be that your user
 (humor me) doesn't have access to do any of the things you are asking, 
 try
 something like run('touch `echo date`') or similar.
 To save potential email formatting issues, please post the code, output 
 and
 error all in a gist/pastie and post us the links.
 - Lee
 2009/5/19 Scott Johnsonsc...@scottjohnson.org
 No difference. Not only is the output of the backticked command not
 getting into the string, the command itself is never being run. I can
 replace the command with `touch file.txt` and that file is never
 created.
 On 19 

[Capistrano] Re: backticks being ignored

[Jamis Buck]

It's only possible if you are using an interactive (e.g., login) shell 
with SSH, and Capistrano is not. Believe me, I've explored and explored 
this, trying to find ways to make Capistrano friendly to non-posix 
shells, and sh -c ... is the closest I got.

- Jamis

On 5/19/09 2:25 PM, Scott Johnson wrote:
 I guess I'm getting way beyond my expertise here, but is it possible
 to specify a shell when you SSH? Instead of taking the default shell?

 I tried default_run_options[:shell]=false in my real capfile, but of
 course that led to shell syntax errors in the builtin Rails recipes
 (specifically deploy:rollback) because it's using tcsh, not sh
 anymore.


 On 19 May, 12:15, Jamis Buckjamis.b...@gmail.com  wrote:
 I'll bet it's tcsh. Capistrano calls sh -c ... specifically to work
 around issues with non-posix shells; it sure sucks when those non-posix
 shells make it impossible to make posix calls.

 I'm afraid it's looking like your only option is going to be to change
 your default shell to something posix. :(

 - Jamis

 On 5/19/09 12:47 PM, Scott Johnson wrote:

 Adding :shell =false to the run params does work. But I would still
 like to resolve this. I'm probably not the last person that will
 encounter this problem with Capistrano, and while it's evidently not
 the tool's fault, if there's something Cap can do to avoid it, that
 would be nice.
 I think it's clearly something with my environment. I tried the sh -c
 command on all the bash versions I could find, all using the same
 environment, and they all failed.
 3.1.17(1)-release (i686-redhat-linux-gnu)
 3.1.7(1)-release (x86_64-redhat-linux-gnu)
 2.0.5a.0(1)-release (i686-pc-linux-gnu)
 3.00.15(1)-release (i686-redhat-linux-gnu)
 But when I ran at home (WinXP, msysGit bash, with the default msysGit
 environment), it worked fine.
 One difference is the shell I'm launching from: tcsh (my default shell
 on those systems) in all the broken cases. When I launch sh -c from
 bash itself, it works. Perhaps tcsh is mangling the command before
 invoking sh? Here's a clue:
 % echo foo is \`date\`
 foo is \
 I don't understand that.
 On 19 May, 10:39, Jamis Buckjamis.b...@gmail.comwrote:
 Maybe it's something with that version of GNU bash? This one works for me:
 $ sh --version
 sh --version
 GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
 Copyright (C) 2005 Free Software Foundation, Inc.
 It also works fine with the posix shell in Ubuntu (not sure which
 version of Ubuntu, but fairly recent).
 Also, I think I led you astray with the set(:shell, false) nonsense. The
 correct way to set that is either this:
  run(echo today is `date`, :shell =false)
 or
  default_run_options[:shell] = false
 The former only applies to that run invocation; the latter applies
 globally to all run invocations.
 - Jamis
 On 5/19/09 11:32 AM, Scott Johnson wrote:
 Getting closer! Something is wacked with my shell:
 % sh -c echo today is \`date\`
 today is
 % sh --version
 GNU bash, version 3.1.17(1)-release (i686-redhat-linux-gnu)
 Copyright (C) 2005 Free Software Foundation, Inc.
 Perhaps I have some environment variable set wrong or something?
 Jamis, the capfile I posted in my original message is the complete
 capfile. I tried adding set :shell, false and it made no difference.
 I suppose the change I made to command.rb is incorrect because the
 backticked command will be run locally instead of remotely. (Right?)
 On 19 May, 09:47, Jamis Buckjamis.b...@gmail.com  wrote:
 The reason it is escaped is because Capistrano invokes the command via
 'sh' (by default). E.g., the following run command:
   run echo today is `date`
 Gets translated into the following shell command:
   sh -c echo today is \`date\`
 The backticks need to be escaped so that they get evaluated by the inner
 shell, and not the outer shell.
 That said, what does the rest of your capfile look like? Are you setting
 :shell anywhere? What version of the posix shell do you have on your
 remote host?
 You might also try setting :shell to false, so that all commands are
 invoked directly:
   set :shell, false
 That way, commands will be run without wrapping them in a sh -c ... 
 call.
 - Jamis
 On 5/19/09 10:33 AM, Scott Johnson wrote:
 I don't believe it is a permissions thing. I can run the same command
 not in backticks and it works. I can run the backticked command
 directly (not through Capistrano) and it works as expected:
 date is Tue May 19 09:25:51 PDT 2009 so there
 And I can edit Capistrano's source as described above and get it to
 work.
 There is something going on with Capistrano's escaping of the
 backticks that I don't understand. Why is it necessary on every
 computer except mine to escape the backticks? And why, when they are
 escaped on my machine, does the backticked command simply disappear
 without a trace?
 I can't imagine what could be so different on my machine. I realize
 I'm running an old Fedora, but things like backticks and shell escape
 

[Capistrano] Re: backticks being ignored

[Jamis Buck]

Scott,

One more thing for you to try: if you have some posix-specific syntax in 
the backticks, does it still work, even if you're using tcsh?

What I'm wondering is, if you have this command, run from within tcsh:

   sh -c echo something `date`

Does that `date` command get run by the posix shell you're invoking? Or 
does it get run by the tcsh shell that you're invoking the posix shell from?

This is important, because if it's tcsh evaluating the backticks, then 
this will break non-posix shells whenever posix-only syntax is used in 
the backticks.

Likewise, if you specify a non-posix shell for the :shell option, 
expecting the backticks to be evaluated by that non-posix shell, do 
things break if the outer (possibly posix) shell evaluates the backticks 
instead?

This is all the reason behind the escaping of the backticks. They were 
there so that the backticks were evaluated by the inner (e.g., posix) 
shell, rather than the outer (invoking, and possibly non-posix) shell.

- Jamis

On 5/19/09 4:45 PM, Lee Hambley wrote:
 Scott,

 Thanks - I'll pick those up.

 - Lee

 2009/5/19 Scott Johnson sc...@scottjohnson.org
 mailto:sc...@scottjohnson.org


 It seems after testing that the solution I discovered last night
 (described in the first post, edit command.rb so it won't escape
 backticks) is a correct and robust solution.

 * The quoted command is run on the remote host.

 * It works when remote user's default shell is tcsh.

 * It works when remote user's default shell is bash.

 * It works when default_run_options[:shell]=false (though it will then
 run tcsh if that's your default shell)

 * It works when default_run_options[:shell] is not set.

 * 'rake test' reports all tests passing.

 I pushed the change to github scottj97/capistrano.


 On 19 May, 13:30, Jamis Buck jamis.b...@gmail.com
 mailto:jamis.b...@gmail.com wrote:
   It's only possible if you are using an interactive (e.g., login)
 shell
   with SSH, and Capistrano is not. Believe me, I've explored and
 explored
   this, trying to find ways to make Capistrano friendly to non-posix
   shells, and sh -c ... is the closest I got.
  
   - Jamis
  
   On 5/19/09 2:25 PM, Scott Johnson wrote:
  
I guess I'm getting way beyond my expertise here, but is it
 possible
to specify a shell when you SSH? Instead of taking the default
 shell?
  
I tried default_run_options[:shell]=false in my real capfile,
 but of
course that led to shell syntax errors in the builtin Rails recipes
(specifically deploy:rollback) because it's using tcsh, not sh
anymore.
  
On 19 May, 12:15, Jamis Buckjamis.b...@gmail.com
 mailto:jamis.b...@gmail.com  wrote:
I'll bet it's tcsh. Capistrano calls sh -c ... specifically
 to work
around issues with non-posix shells; it sure sucks when those
 non-posix
shells make it impossible to make posix calls.
  
I'm afraid it's looking like your only option is going to be
 to change
your default shell to something posix. :(
  
- Jamis
  
On 5/19/09 12:47 PM, Scott Johnson wrote:
  
Adding :shell =false to the run params does work. But I
 would still
like to resolve this. I'm probably not the last person that will
encounter this problem with Capistrano, and while it's
 evidently not
the tool's fault, if there's something Cap can do to avoid
 it, that
would be nice.
I think it's clearly something with my environment. I tried
 the sh -c
command on all the bash versions I could find, all using the same
environment, and they all failed.
3.1.17(1)-release (i686-redhat-linux-gnu)
3.1.7(1)-release (x86_64-redhat-linux-gnu)
2.0.5a.0(1)-release (i686-pc-linux-gnu)
3.00.15(1)-release (i686-redhat-linux-gnu)
But when I ran at home (WinXP, msysGit bash, with the default
 msysGit
environment), it worked fine.
One difference is the shell I'm launching from: tcsh (my
 default shell
on those systems) in all the broken cases. When I launch sh
 -c from
bash itself, it works. Perhaps tcsh is mangling the command
 before
invoking sh? Here's a clue:
% echo foo is \`date\`
foo is \
I don't understand that.
On 19 May, 10:39, Jamis Buckjamis.b...@gmail.com
 mailto:jamis.b...@gmail.comwrote:
Maybe it's something with that version of GNU bash? This one
 works for me:
$ sh --version
sh --version
GNU bash, version 3.2.17(1)-release (i386-apple-darwin9.0)
Copyright (C) 2005 Free Software Foundation, Inc.
It also works fine with the posix shell in Ubuntu (not sure
 which
version of Ubuntu, but fairly recent).
Also, I think

[Capistrano] Re: backticks being ignored

[Jamis Buck]

Ah! I think I may have found a work-around.

If you use single-quotes instead of double-quotes, the string isn't 
immediately interpolated, so:

   sh -c 'echo I need some `help`'

appears to work, even if the calling shell is tcsh. Can you verify?

- Jamis

On 5/19/09 7:27 PM, Scott Johnson wrote:
 I see your point. After further experimentation, I find you're
 correct. The backticked command is being run by tcsh before calling
 sh. Bummer. I had a feeling it wouldn't be quite so easy.

 Back to the drawing board. Or the workaround I had before I decided to
 dive in. :(

 I cannot seem to find, just playing around on the command line, a way
 to force tcsh to pass in the backticks to the sh command. That is
 lame. I'm probably missing something stupid.

 % echo I want my \`backticks\` dammit
 I want my \ dammit

 grr...


 On 19 May, 16:00, Jamis Buckjamis.b...@gmail.com  wrote:
 Scott,

 One more thing for you to try: if you have some posix-specific syntax in
 the backticks, does it still work, even if you're using tcsh?

 What I'm wondering is, if you have this command, run from within tcsh:

 sh -c echo something `date`

 Does that `date` command get run by the posix shell you're invoking? Or
 does it get run by the tcsh shell that you're invoking the posix shell from?

 This is important, because if it's tcsh evaluating the backticks, then
 this will break non-posix shells whenever posix-only syntax is used in
 the backticks.

 Likewise, if you specify a non-posix shell for the :shell option,
 expecting the backticks to be evaluated by that non-posix shell, do
 things break if the outer (possibly posix) shell evaluates the backticks
 instead?

 This is all the reason behind the escaping of the backticks. They were
 there so that the backticks were evaluated by the inner (e.g., posix)
 shell, rather than the outer (invoking, and possibly non-posix) shell.

 - Jamis

 On 5/19/09 4:45 PM, Lee Hambley wrote:

 Scott,
 Thanks - I'll pick those up.
 - Lee
 2009/5/19 Scott Johnsonsc...@scottjohnson.org
 mailto:sc...@scottjohnson.org
  It seems after testing that the solution I discovered last night
  (described in the first post, edit command.rb so it won't escape
  backticks) is a correct and robust solution.
  * The quoted command is run on the remote host.
  * It works when remote user's default shell is tcsh.
  * It works when remote user's default shell is bash.
  * It works when default_run_options[:shell]=false (though it will then
  run tcsh if that's your default shell)
  * It works when default_run_options[:shell] is not set.
  * 'rake test' reports all tests passing.
  I pushed the change to github scottj97/capistrano.
  On 19 May, 13:30, Jamis Buckjamis.b...@gmail.com
  mailto:jamis.b...@gmail.com  wrote:
 It's only possible if you are using an interactive (e.g., login)
  shell
 with SSH, and Capistrano is not. Believe me, I've explored and
  explored
 this, trying to find ways to make Capistrano friendly to non-posix
 shells, and sh -c ... is the closest I got.
 - Jamis
 On 5/19/09 2:25 PM, Scott Johnson wrote:
   I guess I'm getting way beyond my expertise here, but is it
  possible
   to specify a shell when you SSH? Instead of taking the default
  shell?
   I tried default_run_options[:shell]=false in my real capfile,
  but of
   course that led to shell syntax errors in the builtin Rails 
 recipes
   (specifically deploy:rollback) because it's using tcsh, not sh
   anymore.
   On 19 May, 12:15, Jamis Buckjamis.b...@gmail.com
  mailto:jamis.b...@gmail.comwrote:
   I'll bet it's tcsh. Capistrano calls sh -c ... specifically
  to work
   around issues with non-posix shells; it sure sucks when those
  non-posix
   shells make it impossible to make posix calls.
   I'm afraid it's looking like your only option is going to be
  to change
   your default shell to something posix. :(
   - Jamis
   On 5/19/09 12:47 PM, Scott Johnson wrote:
   Adding :shell =  false to the run params does work. But I
  would still
   like to resolve this. I'm probably not the last person that 
 will
   encounter this problem with Capistrano, and while it's
  evidently not
   the tool's fault, if there's something Cap can do to avoid
  it, that
   would be nice.
   I think it's clearly something with my environment. I tried
  the sh -c
   command on all the bash versions I could find, all using the 
 same
   environment, and they all failed.
   3.1.17(1)-release (i686-redhat-linux-gnu)
   3.1.7(1)-release (x86_64-redhat-linux-gnu)
   2.0.5a.0(1)-release (i686-pc-linux-gnu)
   3.00.15(1)-release (i686-redhat-linux-gnu)
   But when I ran at home 

[Capistrano] Re: backticks being ignored

[Jamis Buck]

On 5/19/09 9:03 PM, Scott Johnson wrote:
 I will try that and get back to you...

 The root problem here is that the SSH exec request parses the supplied
 command using the user's default shell, which is uncontrollable. Is
 that right?

Right.

 What if we did SSH exec of sh (without -c), then sent the command
 over the channel (followed by exit)?

Yeah, that's (more or less) the login shell scenario I mentioned 
earlier. It's possible, but non-trivial. At one point I got Capistrano 
*kind of* working with a login shell, but I didn't have the time, 
motivation, or energy to pursue it. Besides which, although there are 
undeniably benefits to using a login shell, there are drawbacks to that 
approach, too (notably, it is pretty fragile to programatically 
manipulate a login shell, for various reasons).

Honestly, the simplest option for you would be to put the stuff that you 
need backticks in, in a separate script file, and then invoke that 
script from Capistrano. That, or switch your default shell to something 
posix.

- Jamis



 On 19 May, 18:42, Jamis Buckjamis.b...@gmail.com  wrote:
 Ah! I think I may have found a work-around.

 If you use single-quotes instead of double-quotes, the string isn't
 immediately interpolated, so:

 sh -c 'echo I need some `help`'

 appears to work, even if the calling shell is tcsh. Can you verify?

 - Jamis

 

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

[Capistrano] Re: backticks being ignored

[Jamis Buck]

On 5/19/09 9:48 PM, Scott Johnson wrote:
 I agree 100%. But unfortunately neither of those options is good for
 me; the backticks are in the built-in deployment recipes (specifically
 deploy:rollback:cleanup and the Perforce p4client_root). And my
 default shell is tcsh because of an organization-wide, IT-
 maintained .cshrc file which I need.

 I'd like to help make Capistrano work for more people out of the
 box. I appreciate your help but I totally understand if you don't
 care to support semi-oddball setups like mine.

Well, it's not my call anymore. :) I'm no longer supporting Capistrano, 
so I'll leave it up to those who are actively maintaining Capistrano 
forks to decide whether they want to incorporate a fix.

In meantime, I'll keep lurking from here in the peanut gallery. :)

- Jamis



 On 19 May, 20:08, Jamis Buckjamis.b...@gmail.com  wrote:
 Honestly, the simplest option for you would be to put the stuff that you
 need backticks in, in a separate script file, and then invoke that
 script from Capistrano. That, or switch your default shell to something
 posix.

 

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

[Capistrano] Re: Running a task without callbacks

[Jamis Buck]

Looks like the documentation is ambiguous. What it means is, that 
particular version of the method doesn't invoke the callbacks. However, 
Capistrano also loads the Callbacks module (capistrano/callbacks.rb), 
which overrides the invoke_task_directly method to decorate it with the 
callback calls.

So, you have two options.

First, you can call the task via 
invoke_task_directly_without_callbacks (which is what the original 
method is aliased to when the callbacks are added).

Second (and this option is cleaner, I think, but only works when you 
have control over the tasks being invoked): write the target task as a 
vanilla Ruby method, first, and then have the tasks call the method. E.g.


   def do_foo
 puts foo!
   end

   task :say_foo_without_bar do
 do_foo
   end

   task :say_foo do
 do_foo
   end

   task :say_bar do
 puts bar!
   end

   after :say_foo, :say_bar

It takes a little more planning, but it's less magical, and less 
dependent on internal Capistrano methods.

- Jamis

On 5/12/09 8:02 AM, Emily wrote:
 I'm working on a complex Capistrano recipe that requires being able to
 run a task without callbacks. After some searching through source and
 rdocs, it seems that execute_task is the intended way to do this.
 The documentation states that it executes the task with the given
 name, without invoking any associated callbacks. However, when I run
 a task with execute_task, its callbacks are executed. I also tried
 using invoke_task_directly, which is what execute_task calls
 internally, and that also runs callbacks. Am I misunderstanding the
 purpose of execute_task? Is there some other method I should be using?
 I'm including a minimal Capfile which demonstrates the problem I'm
 having along with the results I'm getting and the results I'm
 expecting.

 I've spend a little bit of time trying to figure out what's happening
 with this in the ruby debugger, but with all the meta-programming
 going on in Capistrano, I had a hard time figuring out what's actually
 happening. So I thought that before I spend a whole day digging
 through the source code, I'd see if perhaps anyone else had
 experienced something similar or if I was misinterpreting what
 execute_task is supposed to do.

 Thanks in advance for your help,
 - Emily

 The capfile:
 task :say_foo_without_callback do
t = top.find_task 'say_foo'
execute_task t
 end

 task :say_foo do
puts 'foo!'
 end

 task :say_bar do
puts 'bar!'
 end

 after :say_foo, :say_bar


 Output from 'cap say_foo':
* executing `say_foo'
 foo!
  triggering after callbacks for `say_foo'
* executing `say_bar'
 bar!


 Output from 'cap say_foo_without_callback':
* executing `say_foo_without_callback'
* executing `say_foo'
 foo!
  triggering after callbacks for `say_foo'
* executing `say_bar'
 bar!


 What I would expect from 'cap say_foo_without_callback':
* executing `say_foo_without_callback'
* executing `say_foo'
 foo!

 

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

[Capistrano] Re: Running a task without callbacks

[Jamis Buck]

The task call frames are used primarily for rolling back (on rollback, 
that stack is walked). Also, it lets you programmatically infer which 
task is currently being executed. As far as I can remember, nothing in 
Capistrano itself should break if you are invoking the task directly, 
but there might be third-party extensions that depend on the task always 
existing in the call frame stack.

- Jamis

On 5/12/09 9:07 AM, Emily wrote:
 Thanks so much for the quick response. Unfortunately, magical is
 exactly what I need, so it looks like I'll be using
 'invoke_task_directly_without_callbacks'. I tested it, and it seems to
 work exactly the way I need. Am I going to break anything by not
 having the task added to the task call frame? I'm not sure of its
 function, and noticed that execute_task adds that around
 invoke_task_directly.

 Thanks for the help,
 Emily

 On May 12, 10:19 am, Jamis Buckja...@37signals.com  wrote:
 Looks like the documentation is ambiguous. What it means is, that
 particular version of the method doesn't invoke the callbacks. However,
 Capistrano also loads the Callbacks module (capistrano/callbacks.rb),
 which overrides the invoke_task_directly method to decorate it with the
 callback calls.

 So, you have two options.

 First, you can call the task via
 invoke_task_directly_without_callbacks (which is what the original
 method is aliased to when the callbacks are added).

 Second (and this option is cleaner, I think, but only works when you
 have control over the tasks being invoked): write the target task as a
 vanilla Ruby method, first, and then have the tasks call the method. E.g.

 def do_foo
   puts foo!
 end

 task :say_foo_without_bar do
   do_foo
 end

 task :say_foo do
   do_foo
 end

 task :say_bar do
   puts bar!
 end

 after :say_foo, :say_bar

 It takes a little more planning, but it's less magical, and less
 dependent on internal Capistrano methods.

 - Jamis

 On 5/12/09 8:02 AM, Emily wrote:



 I'm working on a complex Capistrano recipe that requires being able to
 run a task without callbacks. After some searching through source and
 rdocs, it seems that execute_task is the intended way to do this.
 The documentation states that it executes the task with the given
 name, without invoking any associated callbacks. However, when I run
 a task with execute_task, its callbacks are executed. I also tried
 using invoke_task_directly, which is what execute_task calls
 internally, and that also runs callbacks. Am I misunderstanding the
 purpose of execute_task? Is there some other method I should be using?
 I'm including a minimal Capfile which demonstrates the problem I'm
 having along with the results I'm getting and the results I'm
 expecting.
 I've spend a little bit of time trying to figure out what's happening
 with this in the ruby debugger, but with all the meta-programming
 going on in Capistrano, I had a hard time figuring out what's actually
 happening. So I thought that before I spend a whole day digging
 through the source code, I'd see if perhaps anyone else had
 experienced something similar or if I was misinterpreting what
 execute_task is supposed to do.
 Thanks in advance for your help,
 - Emily
 The capfile:
 task :say_foo_without_callback do
 t = top.find_task 'say_foo'
 execute_task t
 end
 task :say_foo do
 puts 'foo!'
 end
 task :say_bar do
 puts 'bar!'
 end
 after :say_foo, :say_bar
 Output from 'cap say_foo':
 * executing `say_foo'
 foo!
   triggering after callbacks for `say_foo'
 * executing `say_bar'
 bar!
 Output from 'cap say_foo_without_callback':
 * executing `say_foo_without_callback'
 * executing `say_foo'
 foo!
   triggering after callbacks for `say_foo'
 * executing `say_bar'
 bar!
 What I would expect from 'cap say_foo_without_callback':
 * executing `say_foo_without_callback'
 * executing `say_foo'
 foo!
 

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

[Capistrano] Re: Using Capistrano to Perform SQL operations

[Jamis Buck]

Another way to think of Capistrano is as automated SSH. If you can do 
it via an SSH command-line, then you can do it via Capistrano.

- Jamis

On 5/5/09 2:55 PM, Rafael G. wrote:
 liquid_rails wrote:
 Do Capistrano and Phusion's Passenger do the same thing?


 No, Passenger(aka mod_rails) is an apache/nginx module to execute ror
 applications. It simplify the deployment because you don't need to
 configure a proxy between apache/nginx + mongrel (or the stack that you
 have configured).





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

[Capistrano] Re: running multiple commands in sudo mode

[Jamis Buck]

The preferred way of doing sudo is by embedding #{sudo} in your run 
command. invoke_command() and sudo() are both otherwise not recommended.

So, to do sudo with multiple commands:

   run cd #{latest_release}; #{sudo} bin/merb #{merb_options}

- Jamis


On 4/28/09 5:13 PM, Lee Hambley wrote:
 Tiberiu,

 You can't to `sudo cd /somewhere` can you post the Capistrano tasks code
 via www.pastie.org http://www.pastie.org for us to help diagnose?

 - Lee

 2009/4/29 Mr_Tibs tiberiu.mo...@gmail.com mailto:tiberiu.mo...@gmail.com


 Hi,

 I'm trying to do a simple thing with Capistrano: run multiple commands
 in one shell session as a different user. For example: cd #
 {latest_release}; bin/merb #{merb_options}.

 This works with run (e.g. run cd #{latest_release}; bin/merb #
 {merb_options}), but it doesn't work with sudo and invoke_command. I
 tried:
 - sudo #{sudo :as = 'mongrel'} cd #{latest_release}; bin/merb #
 {merb_options}
 - invoke_command cd #{latest_release}; bin/merb #
 {merb_options}, :via = run_method, :as = #{mongrel_user}

 And I get errors from the shell: sudo: cd: command not found , sh:
 bin/merb: No such file or directory.

 Note that I cannot user #{latest_release}/bin/merb#{merb_options}.

 Thanks,
 Tiberiu



 

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

[Capistrano] Re: running multiple commands in sudo mode

[Jamis Buck]

As before, with the :as option:

   run cd #{latest_release}; #{sudo :as = bob} bin/merb #{merb_options}

- Jamis

On 4/28/09 6:52 PM, Mr_Tibs wrote:
 Thanks Jamis. I'm only using sudo because I want that command to be
 run by a different user. How would I specify the user's name in the
 example that you gave?

 Tiberiu

 On Apr 28, 5:33 pm, Jamis Buckjamis.b...@gmail.com  wrote:
 The preferred way of doing sudo is by embedding #{sudo} in your run
 command. invoke_command() and sudo() are both otherwise not recommended.

 So, to do sudo with multiple commands:

 run cd #{latest_release}; #{sudo} bin/merb #{merb_options}

 - Jamis

 On 4/28/09 5:13 PM, Lee Hambley wrote:

 Tiberiu,
 You can't to `sudo cd /somewhere` can you post the Capistrano tasks code
 viawww.pastie.orghttp://www.pastie.org  for us to help diagnose?
 - Lee
 2009/4/29 Mr_Tibstiberiu.mo...@gmail.commailto:tiberiu.mo...@gmail.com
  Hi,
  I'm trying to do a simple thing with Capistrano: run multiple commands
  in one shell session as a different user. For example: cd #
  {latest_release}; bin/merb #{merb_options}.
  This works with run (e.g. run cd #{latest_release}; bin/merb #
  {merb_options}), but it doesn't work with sudo and invoke_command. I
  tried:
  - sudo #{sudo :as =  'mongrel'} cd #{latest_release}; bin/merb #
  {merb_options}
  - invoke_command cd #{latest_release}; bin/merb #
  {merb_options}, :via =  run_method, :as =  #{mongrel_user}
  And I get errors from the shell: sudo: cd: command not found , sh:
  bin/merb: No such file or directory.
  Note that I cannot user #{latest_release}/bin/merb#{merb_options}.
  Thanks,
  Tiberiu
 

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

[Capistrano] Re: Roll back of a migration

[Jamis Buck]

On 4/27/09 4:31 AM, Lee Hambley wrote:
 Jacobo,

 You may need to implement something like the following pesudocode:

 * http://pastie.org/459506

Be very careful, though, because migrations are not (in general) 
reversible. Specific migrations may be, but the only way to be 100% sure 
of a migration being reversible is to do a complete backup of your 
database immediately before the migration. Then, to reverse the 
migration, simply restore the backup. Unfortunately, for databases of 
any relevant size, creating or restoring a snapshot is non-trivial, 
which is why Capistrano doesn't do it by default.

- Jamis


 I don't know how well that might work out, or if there is anything
 internally that would help, I note the following rake tasks in my Rails
 2.2.2 application:

 rake db:migrate
 rake db:migrate:down
 rake db:migrate:redo
 rake db:migrate:reset
 rake db:migrate:up
 rake db:reset
 rake db:rollback


 - Lee

 2009/4/27 Jacobo García jacobo.gar...@gmail.com
 mailto:jacobo.gar...@gmail.com

 I am looking for a way to roll back a migration.

 So if I run 'cap deploy:migrations' and something in the app is
 troublesome, running 'cap rollback' (with this rollback_migrations
 as a hook) will leave the database in the same point that before
 running 'cap deploy:migrations'

 Is there any common formula to solve this problem?

 Thanks in advance.


 Jacobo García López de Araujo
 blog: http://www.robotplaysguitar.com




 

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

[Capistrano] Re: I seem to have to delete the cached_copy folder every time I want to deploy

[Jamis Buck]

What version of git do you have on your server?

- Jamis

On 4/27/09 7:05 PM, chris wrote:
 http://pastie.org/460525

 it seems that it is on the git fetch  origin  git reset  --hard
 that it dies.

 On Apr 27, 3:26 am, Lee Hambleylee.hamb...@gmail.com  wrote:
 Chris,
 What error are you getting?

 - Lee

 2009/4/27 chrisolsen.ch...@gmail.com





 I had some earlier issues that can be found at
 http://groups.google.com/group/capistrano/t/ceed1b8db785a693
 After re-adding my ssh key I was able to deploy.  The next time I
 tried to deploy I got an error of :
   fatal: Needed a single revision
 For some reason it seems that I only get one deployment before having
 to ssh into the server and deleting the cached-copy.  I know I could
 add a task to the Capistrano scripts to delete this for me, but I
 would like to know what the reason is for this issue.
 Any thoughts?
 

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

[Capistrano] Re: Deployment through a gateway

[Jamis Buck]

On 4/23/09 2:11 AM, martins wrote:
 Jamis,

 It does not work with the -N option, I´m not getting the login prompt
  on the gateway.

Right...that's the point. All you need the gateway for is the tunnelled 
connection in the next command. You don't need the shell. So you do it 
with the -N, like I said, and let it sit there.  Then, in a new terminal 
window, you try the second command.

 I´ve tried adding this option, without luck.
  ssh_options[:keys] = %w(.ssh/id_rsa-target)

Don't forget the ~ to say it's relative to your home directory:

   %w(~/.ssh/id_rsa-target)

- Jamis



 --
 Martins

 On Apr 22, 3:46 pm, Jamis Buckjamis.b...@gmail.com  wrote:
 Gateway access via capistrano is not the same as logging into the target
 machine from the gateway machine. What capistrano does is open a
 forwarded connection from your workstation directly to the target
 machine, via the gateway.

 It's the same as doing something like this:

 # in one terminal window:
 workstation$ ssh -N -L 1234:target:22 gateway

 # in another terminal window:
 workstation$ ssh -p 1234 localhost

 What that does is open a forwarded port from workstation (port 1234) to
 target (port 22), via an ssh connection to gateway. Then, it opens an
 ssh connection on workstation (port 1234), which is then forwarded to
 target. If that approach works for you without a password, then it
 should work for capistrano without a password, too.

 - Jamis

 On 4/22/09 6:57 AM, martins wrote:

 Hi,
 I´m trying to deploy to target-server from workstation trough gateway-
 server.
 workstation$ ssh gateway   # Lets me inn without asking for
 password
 gateway$ ssh target# Grants access without password.
 I´m using ~/.ssh/id_rsa in both cases, but they are not identical.
 deploy.rb
 set :repository,  g...@git.server.com:project.git
 set :scm, git
 set :user, martins
 ssh_options[:config]=false
 ssh_options[:auth_methods] = publickey
 ssh_options[:verbose] = :debug
 set :gateway, 'mart...@gateway-server'
 role :app, target-server
 role :web, target-server
 role :db,  target-server, :primary =true
 workstation$ cap deploy  * Creating gateway using mart...@gateway-
 server
 DEBUG -- net.ssh.transport.session[90b3e8]: establishing connection to
 gateway-server:22
 DEBUG -- net.ssh.transport.session[90b3e8]: connection established
 [snipp..]
 DEBUG -- net.ssh.authentication.methods.publickey[903634]: publickey
 succeeded
 * establishing connection to `target-server' via gateway
 DEBUG -- net.ssh.transport.session[900b28]: establishing connection to
 127.0.0.1:65533
 DEBUG -- net.ssh.authentication.session[8f3720]: allowed methods:
 publickey,password
 ERROR -- net.ssh.authentication.session[8f3720]: all authorization
 methods failed (tried publickey)
 *** [deploy:update_code] rolling back
 * executing rm -rf /var/sites/matrix-ai/releases/20090422103117;
 true
   servers: [target-server]
 * establishing connection to `target-server' via gateway
 DEBUG -- net.ssh.transport.session[8ee1b2]: establishing connection to
 127.0.0.1:65532
 DEBUG -- net.ssh.transport.session[8ee1b2]: connection established
INFO -- net.ssh.transport.server_version[8edcee]: negotiating
 protocol version
 DEBUG -- net.ssh.service.forward[901366]: received connection on
 127.0.0.1:65532
INFO -- net.ssh.connection.session[901636]:
 channel_open_confirmation: 1 1 2097152 32768
INFO -- net.ssh.connection.channel[8eda82]: direct channel
 established
 DEBUG -- net.ssh.transport.server_version[8edcee]: remote is `SSH-2.0-
 OpenSSH_4.7p1 Debian-8ubuntu1.2'
 DEBUG -- net.ssh.transport.server_version[8edcee]: local is `SSH-2.0-
 Ruby/Net::SSH_2.0.11 i686-darwin9'
 DEBUG -- net.ssh.authentication.session[8e0eea]: beginning
 authentication of `martins'
 DEBUG -- net.ssh.authentication.session[8e0eea]: trying publickey
 DEBUG -- net.ssh.authentication.agent[8dee4c]: connecting to ssh-agent
 DEBUG -- net.ssh.authentication.agent[8dee4c]: sending agent request 1
 len 45
 DEBUG -- net.ssh.authentication.agent[8dee4c]: received agent packet 2
 len 5
 DEBUG -- net.ssh.authentication.agent[8dee4c]: sending agent request
 11 len 0
 DEBUG -- net.ssh.authentication.agent[8dee4c]: received agent packet
 12 len 5
 DEBUG -- net.ssh.authentication.methods.publickey[8dee88]: trying
 publickey
 DEBUG -- net.ssh.connection.channel[8eda82]: read 372 bytes from
 client, sending over local forwarded connection
INFO -- net.ssh.connection.session[901636]: channel_data: 1 68b
 DEBUG -- net.ssh.authentication.session[8e0eea]: allowed methods:
 publickey,password
 ERROR -- net.ssh.authentication.session[8e0eea]: all authorization
 methods failed (tried publickey)
** [deploy:update_code] exception while rolling back:
 Capistrano::ConnectionError, connection failed for: target-server
 (Net::SSH::AuthenticationFailed: martins)
 connection failed for: target-server (Net::SSH::AuthenticationFailed:
 martins)
 ~/.ssh/config is empty on both gateway and 

[Capistrano] Re: Server tries to pull from old git repo on deployment

[Jamis Buck]

The easiest thing to do is to just blow away the cached-copy directory 
on all your deployment servers, and redeploy:

   rm -rf /var/rails/app_name/shared/cached-copy

Deleting that directory will have no effect on your running application. 
It will just cause capistrano to reclone your repository on the next deploy.

- Jamis

On 4/23/09 8:26 AM, chris wrote:
 That I am.  I have checked the .git/config files on the server, but
 the only thing in them is:

 [core]
  repositoryformatversion = 0
  filemode = true

 Is there another config file that I am missing?

 On Apr 23, 7:49 am, Giovanni Intiniinti...@gmail.com  wrote:
 You're probably using the remote cache strategy, .git/config on the
 server still points to the old github account.

 Just manually edit it or remove the cache directory and redeploy.

 Il giorno 23/apr/09, alle ore 15:27, chrisolsen.ch...@gmail.com  ha
 scritto:





 Oops, a copy and past issue on the previous console output.  Here is
 the correction.
 $ cap deploy
   * executing `deploy'
   * executing `deploy:update'
 ** transaction: start
   * executing `deploy:update_code'
 updating the cached checkout on all servers
 executing locally: git ls-remote g...@github.com:NEW_SERVER/
 app_name.git master
   * executing if [ -d /var/rails/app_name/shared/cached-copy ]; then
 cd /var/rails/app_name/shared/cached-copy  git fetch  origin  git
 reset  --hard 904c8b690ea51115bbcc89dfcb24d67f6963c7b4; else git
 clone  g...@github.com:NEW_SERVER/app_name.git /var/rails/app_name/
 shared/cached-copy  cd /var/rails/app_name/shared/cached-copy  git
 checkout  -b deploy 904c8b690ea51115bbcc89dfcb24d67f6963c7b4; fi
 servers: [lixx-xx.members.linode.com]
 [lixx-xx.members.linode.com] executing command
 ** [lixx-xx.members.linode.com :: out] Repository not found. If
 you've just created it, please try again in a few seconds.
 ** [lixx-xx.members.linode.com :: out] fatal: unexpected EOF
 ** [lixx-xx.members.linode.com :: out] Fetch failure:
 g...@github.com:OLD_SERVER/app_name.git
 ** [lixx-xx.members.linode.com :: out] Repository not found. If
 you've just created it, please try again in a few seconds.
 ** [lixx-xx.members.linode.com :: out] fatal:
 ** [lixx-xx.members.linode.com :: out] unexpected EOF
 ** [lixx-xx.members.linode.com :: out]
 ** [lixx-xx.members.linode.com :: out] Failed to find remote refs
 ** [lixx-xx.members.linode.com :: out] fatal:
 ** [lixx-xx.members.linode.com :: out] Needed a single revision
 ** [lixx-xx.members.linode.com :: out]
 command finished
 *** [deploy:update_code] rolling back
   * executing rm -rf /var/rails/app_name/releases/20090423131000;
 true
 servers: [lixx-xx.members.linode.com]
 [lixx-xx.members.linode.com] executing command
 command finished
 failed: sh -c \if [ -d /var/rails/app_name/shared/cached-copy ];
 then cd /var/rails/app_name/shared/cached-copy  git fetch  origin
 git reset  --hard 904c8b690ea51115bbcc89dfcb24d67f6963c7b4; else git
 clone  g...@github.com:NEW_SERVER/app_name.git /var/rails/app_name/
 shared/cached-copy  cd /var/rails/app_name/shared/cached-copy  git
 checkout  -b deploy 904c8b690ea51115bbcc89dfcb24d67f6963c7b4; fi\ on
 lixx-xx.members.linode.com
 On Apr 23, 7:18 am, chrisolsen.ch...@gmail.com  wrote:
 I recently renamed my github account and have been having problems
 since.  For some reason when I run the cap deploy command the remote
 server continues to make calls to old github address.
 The old account name no longer exists any where within the project
 and
 I am able to make committals to the remote git server with no issues.
 Thanks for the help.
 $ cap deploy
* executing `deploy'
* executing `deploy:update'
   ** transaction: start
* executing `deploy:update_code'
  updating the cached checkout on all servers
  executing locally: git ls-remote g...@github.com:greenstem/
 NEW_SERVER.git master
* executing if [ -d /var/rails/NEW_SERVER/shared/cached-copy ];
 then cd /var/rails/NEW_SERVER/shared/cached-copy  git fetch  origin
   git reset  --hard 904c8b690ea51115bbcc89dfcb24d67f6963c7b4; else
 git clone  g...@github.com:greenstem/NEW_SERVER.git /var/rails/
 NEW_SERVER/shared/cached-copy  cd /var/rails/NEW_SERVER/shared/
 cached-copy  git checkout  -b deploy
 904c8b690ea51115bbcc89dfcb24d67f6963c7b4; fi
  servers: [lixx-xx.members.linode.com]
  [lixx-xx.members.linode.com] executing command
   ** [lixx-xx.members.linode.com :: out] Repository not found. If
 you've just created it, please try again in a few seconds.
   ** [lixx-xx.members.linode.com :: out] fatal: unexpected EOF
   ** [lixx-xx.members.linode.com :: out] Fetch failure:
 g...@github.com:OLD_SERVER/NEW_SERVER.git
   ** [lixx-xx.members.linode.com :: out] Repository not found. If
 you've just created it, please try again in a few seconds.
   ** [lixx-xx.members.linode.com :: out] fatal:
   ** [lixx-xx.members.linode.com :: out] unexpected EOF
   ** [lixx-xx.members.linode.com :: out]
   

[Capistrano] Re: Deployment through a gateway

[Jamis Buck]

Gateway access via capistrano is not the same as logging into the target 
machine from the gateway machine. What capistrano does is open a 
forwarded connection from your workstation directly to the target 
machine, via the gateway.

It's the same as doing something like this:

   # in one terminal window:
   workstation$ ssh -N -L 1234:target:22 gateway

   # in another terminal window:
   workstation$ ssh -p 1234 localhost

What that does is open a forwarded port from workstation (port 1234) to 
target (port 22), via an ssh connection to gateway. Then, it opens an 
ssh connection on workstation (port 1234), which is then forwarded to 
target. If that approach works for you without a password, then it 
should work for capistrano without a password, too.

- Jamis

On 4/22/09 6:57 AM, martins wrote:
 Hi,

 I´m trying to deploy to target-server from workstation trough gateway-
 server.

 workstation$ ssh gateway   # Lets me inn without asking for
 password
 gateway$ ssh target# Grants access without password.

 I´m using ~/.ssh/id_rsa in both cases, but they are not identical.

 deploy.rb
 set :repository,  g...@git.server.com:project.git
 set :scm, git
 set :user, martins

 ssh_options[:config]=false
 ssh_options[:auth_methods] = publickey
 ssh_options[:verbose] = :debug

 set :gateway, 'mart...@gateway-server'
 role :app, target-server
 role :web, target-server
 role :db,  target-server, :primary =  true




 workstation$ cap deploy  * Creating gateway using mart...@gateway-
 server
 DEBUG -- net.ssh.transport.session[90b3e8]: establishing connection to
 gateway-server:22
 DEBUG -- net.ssh.transport.session[90b3e8]: connection established
 [snipp..]

 DEBUG -- net.ssh.authentication.methods.publickey[903634]: publickey
 succeeded
* establishing connection to `target-server' via gateway
 DEBUG -- net.ssh.transport.session[900b28]: establishing connection to
 127.0.0.1:65533
 DEBUG -- net.ssh.authentication.session[8f3720]: allowed methods:
 publickey,password
 ERROR -- net.ssh.authentication.session[8f3720]: all authorization
 methods failed (tried publickey)
 *** [deploy:update_code] rolling back
* executing rm -rf /var/sites/matrix-ai/releases/20090422103117;
 true
  servers: [target-server]
* establishing connection to `target-server' via gateway


 DEBUG -- net.ssh.transport.session[8ee1b2]: establishing connection to
 127.0.0.1:65532
 DEBUG -- net.ssh.transport.session[8ee1b2]: connection established
   INFO -- net.ssh.transport.server_version[8edcee]: negotiating
 protocol version
 DEBUG -- net.ssh.service.forward[901366]: received connection on
 127.0.0.1:65532
   INFO -- net.ssh.connection.session[901636]:
 channel_open_confirmation: 1 1 2097152 32768
   INFO -- net.ssh.connection.channel[8eda82]: direct channel
 established
 DEBUG -- net.ssh.transport.server_version[8edcee]: remote is `SSH-2.0-
 OpenSSH_4.7p1 Debian-8ubuntu1.2'
 DEBUG -- net.ssh.transport.server_version[8edcee]: local is `SSH-2.0-
 Ruby/Net::SSH_2.0.11 i686-darwin9'
 DEBUG -- net.ssh.authentication.session[8e0eea]: beginning
 authentication of `martins'

 DEBUG -- net.ssh.authentication.session[8e0eea]: trying publickey
 DEBUG -- net.ssh.authentication.agent[8dee4c]: connecting to ssh-agent
 DEBUG -- net.ssh.authentication.agent[8dee4c]: sending agent request 1
 len 45
 DEBUG -- net.ssh.authentication.agent[8dee4c]: received agent packet 2
 len 5
 DEBUG -- net.ssh.authentication.agent[8dee4c]: sending agent request
 11 len 0
 DEBUG -- net.ssh.authentication.agent[8dee4c]: received agent packet
 12 len 5
 DEBUG -- net.ssh.authentication.methods.publickey[8dee88]: trying
 publickey
 DEBUG -- net.ssh.connection.channel[8eda82]: read 372 bytes from
 client, sending over local forwarded connection
   INFO -- net.ssh.connection.session[901636]: channel_data: 1 68b
 DEBUG -- net.ssh.authentication.session[8e0eea]: allowed methods:
 publickey,password
 ERROR -- net.ssh.authentication.session[8e0eea]: all authorization
 methods failed (tried publickey)
   ** [deploy:update_code] exception while rolling back:
 Capistrano::ConnectionError, connection failed for: target-server
 (Net::SSH::AuthenticationFailed: martins)
 connection failed for: target-server (Net::SSH::AuthenticationFailed:
 martins)


 ~/.ssh/config is empty on both gateway and workstation.

 Any idea why this fails? Can I provide more information?


 Cheers,
 Martin Stabenfeldt

 

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

[Capistrano] Re: conditional tasks depending on environment ? (using cap-ext)

[Jamis Buck]

It all looks good to me. When you (e.g.) cap staging deploy, what is
the output?

- Jamis

On Fri, Apr 17, 2009 at 12:20 AM, Ivar Vasara i...@oobik.com wrote:

 Thanks for the blazingly quick reply !

 I do have the appropriate require 'capistrano/ext/multistage' in my
 deploy.rb.
 I've posted what I think is the relevant data (relevant chunks of
 deploy.rb, and the stage files) at http://pastie.org/449514
 This is on os X, I've checked file permissions, everything *should* be
 in order.


 On Apr 16, 10:33 pm, Jamis Buck jamis.b...@gmail.com wrote:
 On 4/16/09 11:26 PM, Ivar Vasara wrote:

  As I tried to communicate in my earlier post (on Thu, 16 Apr 2009), it
  doesn't seem as if the stage files are actually being loaded. I'm not
  sure how to get capistrano to recognize the files generated by cap
  multistage:prepare.

 Are you requiring the multistage code in deploy.rb? You need to make
 sure and have a line something like this:

    require 'capistrano/ext/multistage'

 But that really ought to be all it takes for it work.

  Is there a problem with the approach of 1. defining all tasks in
  deploy.rb then 2. customizing deployments for specific environments
  using hooks in the appropriate stage file ?

 That should work just fine. At this point, I think the best thing you
 could do is post your recipe files somewhere for us to review.

 - Jamis
 


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

[Capistrano] Re: conditional tasks depending on environment ? (using cap-ext)

[Jamis Buck]

Each stage essentially becomes it's own task, so in order to invoke a 
task in the environment of a particular stage, you need to specify that 
stage:

   cap production deploy
   cap staging deploy:pending

etc.

- Jamis

On 4/16/09 6:22 PM, Ivar Vasara wrote:
 Jamis,

 That looks like a perfect solution. I've followed your suggestion and
 added the after deploy:update hook to config/deploy/staging.rb but
 the stage files don't seem to be parsed.  Unfortunately, I haven't
 been able to find any documentation or notes about capistrano-ext
 supporting the various stage files. To be honest, your reply was the
 first I'd heard of the stage file feature, but inspired by your
 solution I poked around and noticed the multistage:prepare task, which
 I must have missed earlier. I started a post here, but figured I
 should poke around the source a bit to understand my issue.. in I got
 to (line 15 from multistage.rb in capistrano-ext on github):

stages.each do |name|
  desc Set the target stage to `#{name}'.
  task(name) do
set :stage, name.to_sym
load #{location}/#{stage}
  end
end

 and it appears that the code inside the second 'do' is never
 executed.. I haven't dug deep enough to know what's wrong but that
 code has been there for ages, so it must be something to do with my
 environment, but I can't tell what. The 'stages' array appears to be
 set correctly by the time it gets to that code, but in config/deploy I
 have three files - dev.rb, staging.rb and production.rb - none of
 which are read.

 Any help/pointers appreciated.




 On Apr 10, 7:26 am, Jamis Buckjamis.b...@gmail.com  wrote:
 Just put your before/after declarations in the corresponding stage file.
 E.g., in config/deploy/production.rb, say:

 after deploy:update, upload_static_assets_to_s3

 etc.

 - Jamis

 On 4/10/09 8:00 AM, ivar vasara wrote:

 I've been using Capistrano for some time now, but one thing I haven't
 been able to figure out is how to conditionally invoke tasks based on
 environment. For example, on production there are additional
 configurations to be made and static assets to be uploaded to s3. I'm
 using the cap-ext plugin successfully, but being able to add before/
 after filters based on environment would be a big win. Is there a
 standard way of doing this ?

 

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

[Capistrano] Re: scm_command

[Jamis Buck]

You can actually already do that, Andrei:

   set :scm_command, /opt/local/bin/git
   set :local_scm_command, git

- Jamis

On 4/1/09 7:47 AM, Andrei wrote:
 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.
* executing `deploy:update_code'
  updating the cached checkout on all servers
  executing locally: /home/alfaimca/opt/bin/git ls-remote
 alfai...@alfaimcadastru.com:public_html/alfaim/alfaim.git master
 *** [deploy:update_code] rolling back
* executing rm -rf etc/rails_apps/alfaim/releases/20090401133001;
 true
  servers: [alfaimcadastru.com]
  [alfaimcadastru.com] executing command
  command finished
 C:/RubyStack/ruby/lib/ruby/gems/1.8/gems/capistrano-2.5.5/lib/
 capistrano/recipes/deploy.rb:97:in``': No such file or directory - /
 home/alfaimca/opt/bin/git ls-remote
 alfai...@alfaimcadastru.com:public_html/alfaim/alfaim.git master
 (Errno::ENOENT)
 If I don't set scm_command deploy:cold fails anyway, because it runs
 git commands locally and remote, and the paths are different.
 I tried to solve this by myself, but I just ended up hating myself.
 So, wouldn't be a good idea if capistrano would have instead of
 scm_command, scm_local_command and scm_remote_command?

 

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

[Capistrano] Re: Namespace collision error with frozen Capistrano

[Jamis Buck]

Rake doesn't add it to Capistrano, it adds it to Object, so that you can 
call FileUtils.symlink without the FileUtils prefix. It's pretty 
unfortunate, and I don't know of a good way to work around it, sadly.

- Jamis

On 4/1/09 5:41 PM, Sarah Mei wrote:
 The operations folks at my company would like to have Capistrano and
 all its related gems contained in the svn trunk of the Rails app. So
 in my local copy, I installed all the gems in vendor/gems using gem
 install. (capistrano, echoe, highline, net-scp, net-sftp, net-ssh,
 net-ssh-gateway, and rubyforge were installed.)

 I copied the cap executable from /usr/pkg/ruby/bin/cap and modified it
 to use vendor/gems as the gem path. Using that, I can run cap deploy
 just fine from the command line. I can tell it's running the version
 in vendor/gems.  So far so good!

 However, in my Rails app I also have a rake task that does some
 parameter munging and then calls Capistrano in code via the
 Capistrano::CLI library. When I run that, executing the equivalent of
 a cap deploy, it fails to load the deploy recipes. This happens in the
 first line of Capfile - it never even gets to my deploy.rb. The error
 is:

 defining a task named `symlink' would shadow an existing method with that name

 I tracked it down to lib/capistrano/configuration/namespaces.rb. While
 defining the tasks in the deploy recipe, Capistrano seems to think it
 has a method called symlink that the symlink task will collide with.
 I had a look at self.ancestors inside the call that's throwing the
 error - and it's right. One of its ancestors is FileUtils, which has a
 symlink method.

 Rake seems to be adding this. When I run the same code via a
 command-line cap deploy, self.ancestors does not include FileUtils.

 Any ideas why (or how?) Rake is adding this stuff to the Capistrano
 classes? I may just end up calling the command line from the Rakefile
 instead of doing it in code, but that's a little ugly. (Well, not like
 what I'm doing now isn't...) Here's how I do it in code:

 def cap(*parameters)
require 'rubygems'

Gem.use_paths(Gem.dir, [#{RAILS_ROOT}/vendor/gems]) # Point to
 frozen cap version
Gem.refresh # picks up path changes

gem 'capistrano', '=2.5.5'
require 'capistrano'
require 'capistrano/cli'

unless ENV['REVISION'] then
  raise Please set REVISION; exiting...
end
ENV.delete 'REVISION' if ENV['REVISION'].upcase == HEAD
parameters  ['-S', tag=#{ENV['TAG']}] if ENV['TAG']
parameters  ['-S', revision=#{ENV['REVISION']}] if ENV['REVISION']
parameters  ['-S', target=#{ENV['TARGET']}] if ENV['TARGET']
parameters  '-q' if ENV['QUIET']
parameters.flatten!
puts PARAMETERS:
puts parameters.map{|p| p.to_s}

Capistrano::CLI.parse(parameters.map { |param| param.to_s }).execute!
 end

 

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

[Capistrano] Re: git remote_cache: why not checkout from a bare/mirrored repository?

[Jamis Buck]

There's no reason you need to copy the .git directory. Just set
:copy_exclude to %w(.git) and it should ignore that directory.

As for why it's implemented the way it is: it's for compatibility with
other SCM's. Git is not the only SCM capistrano supports, so the
built-in deployment strategies have to support the lowest common
denominator. By all means, though, implement your idea and release it
as a git-specific deployment strategy. If it's useful to you, I'm sure
it'd be useful to others.

- Jamis

On Thu, Mar 19, 2009 at 5:14 PM, bkw bernho...@gmail.com wrote:

 Hi *,

 being a new capistrano (and ruby-) user I wonder whether the use of
 git with :remote_cache could not be made more effecient. Right now, we
 copy the whole checkout including the .git directory for every
 release.
 IMHO the following would be much faster and more space efficient:

 # first checkout of the repo cache as a bare. (only done once):
 git clone --mirror #{repository} #{repository_cache}

 # update the repo cache before each checkout:
 git --git-dir=#{repository_cache} fetch #{repository}

 # checkout a release from the repo cache:
 mkdir #{release_path}  \
  cd #{release_path}  \
  git --git-dir=#{repository_cache} --work-dir=. reset --hard #
 {branch}


 This way we would keep a bare repository without any checked out files
 current in the repository cache, and produce a quick and slim checkout
 for the release without duplicating the whole .git directory
 everytime.
 This would save both deployment time and storage space, in my case
 quite significantly.

 Did I overlook a compelling reason not to go this route? I'm about to
 dig into cap's internals to try to implement this (as a plugin
 maybe?), but before I waste my time on something stupid, I'd rather
 ask for advice here.

 Any thoughts?
  bkw

 


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

[Capistrano] Re: Detecting remote errors

[Jamis Buck]

On 3/13/09 9:14 AM, S. Robert James wrote:
 Does Capistrano check the exit status of the remote command (run
 method)?

Yes. It will raise an exception if a command finishes with a non-zero
exit status.

 I see that the deploy:setup task will run mkdir even the dirs already
 exist - this should exit nonzero - but I don't see any special
 handling to say it's okay, keep on going.

deploy:setup actually runs mkdir -p, which will not exit non-zero if
directories already exist.

- Jamis

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

[Capistrano] Re: Detecting remote errors

[Jamis Buck]

On 3/13/09 9:44 AM, S. Robert James wrote:
 Neat - got it.
 Where is this exception raised in the Capisterano source code?

http://github.com/jamis/capistrano/blob/df0935c4c135207582da343aacdd4cf080fcfed0/lib/capistrano/command.rb#L171-173

or, if that gets shattered into a million pieces, here's a tinyurl:

http://tinyurl.com/dm6wpg

- Jamis

 
 On Mar 13, 11:40 am, Jamis Buck ja...@37signals.com wrote:
 On 3/13/09 9:14 AM, S. Robert James wrote:

 Does Capistrano check the exit status of the remote command (run
 method)?
 Yes. It will raise an exception if a command finishes with a non-zero
 exit status.

 I see that the deploy:setup task will run mkdir even the dirs already
 exist - this should exit nonzero - but I don't see any special
 handling to say it's okay, keep on going.
 deploy:setup actually runs mkdir -p, which will not exit non-zero if
 directories already exist.

 - Jamis
  


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

[Capistrano] Re: cap deploy:cold hangs

[Jamis Buck]

You're going to need to include more of the output. What you've pasted
in your original email does not tell us enough. Please try pasting the
entire output (without ssh debugging output).

- Jamis

On 3/13/09 11:22 AM, Valafar wrote:
 I'm using Capistrano 2.5.5 and Git 1.5.6 as SCM to deploy my Rails 2.3
 -app.
 
 config/deploy.rb:
 --
 set :application, myapp
 set :repository, g...@mysite.ath.cx:myapp.git
 set :scm, :git
 set :deploy_via, :remote_cache
 set :ssh_options, { :forward_agent = true }
 set :user, myaccount
 set :deploy_to, /home/myaccount/sites/myapp
 server mysite.ath.cx, :app, :web, :db, :primary = true
 set :use_sudo, false
 ssh_options[:verbose] = :debug
 --
 
 Running cap deploy:cold without debug and getting:
 --
 servers: [mysite.ath.cx]
 [mysite.ath.cx] executing command
 --
 
 Debug revealed among many other things that
 net.ssh.authentication.methods.publickey[3f9ae077ec18]: publickey
 succeeded
 
 Lines after [mysite.ath.cx] executing command were
 
 I, [2009-03-13T19:19:44.986248 #23222]  INFO --
 net.ssh.connection.channel[3fb91cc6d2ec]: sending channel request
 exec
 D, [2009-03-13T19:19:44.986586 #23222] DEBUG -- tcpsocket
 [3fb91cc832e0]: queueing packet nr 9 type 98 len 476
 D, [2009-03-13T19:19:44.987310 #23222] DEBUG -- tcpsocket
 [3fb91cc832e0]: sent 568 bytes
 D, [2009-03-13T19:19:45.010155 #23222] DEBUG -- tcpsocket
 [3fb91cc832e0]: read 88 bytes
 D, [2009-03-13T19:19:45.010662 #23222] DEBUG -- tcpsocket
 [3fb91cc832e0]: received packet nr 8 type 99 len 12
 I, [2009-03-13T19:19:45.010971 #23222]  INFO --
 net.ssh.connection.session[3fb91cc6d60c]: channel_success: 0
 D, [2009-03-13T19:19:45.011193 #23222] DEBUG -- net.ssh.service.forward
 [3fb91cc6b960]: authentication agent forwarding is active
 D, [2009-03-13T19:19:45.011495 #23222] DEBUG -- tcpsocket
 [3fb91cc832e0]: received packet nr 9 type 93 len 28
 I, [2009-03-13T19:19:45.011726 #23222]  INFO --
 net.ssh.connection.session[3fb91cc6d60c]: channel_window_adjust: 0
 +2097152
 
 I don't get it :S Where's the problem? There was no problem with
 deploy:setup and deploy:check.
 
  


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

[Capistrano] Re: cap deploy:cold hangs

[Jamis Buck]

Can you please include the *full* output? The entire thing? The
abbreviated output you keep pasting is lacking potentially relevant
information, making it very hard to help you.

- Jamis

On 3/13/09 12:00 PM, Valafar wrote:
 Oh, now it finally finished. After executing command:
 
 command finished
 failed: sh -c \if [ -d /home/myaccount/sites/myapp/shared/cached-
 copy ]; then cd /home/myaccount/sites/myapp/shared/cached-copy  git
 fetch -q origin  git reset -q --hard
 fa998c24c672352b2bef3ff9314881f441bd4c54; else git clone -q
 g...@mysite.ath.cx:myapp.git /home/myaccount/sites/myapp/shared/cached-
 copy  cd /home/myaccount/sites/myapp/shared/cached-copy git
 checkout -q -b deploy fa998c24c672352b2bef3ff9314881f441bd4c54; fi\
 on mysite.ath.cx
  


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

[Capistrano] Re: cap deploy:cold hangs

[Jamis Buck]

The error is here:

 ** [mysite.ath.cx :: err] ssh: connect to host mysite.ath.cx port 22:
Connection timed out
 ** [mysite.ath.cx :: err] fatal: The remote end hung up unexpectedly
command finished

Apparently the ssh server at mysite.ath.cx is either not running, or is
not running on port 22.

- Jamis

On 3/13/09 12:59 PM, Valafar wrote:
 Umm, I was a bit mixed :S Here's the whole thing:
 
   * executing `deploy:cold'
   * executing `deploy:update'
  ** transaction: start
   * executing `deploy:update_code'
 updating the cached checkout on all servers
 executing locally: git ls-remote g...@mysite.ath.cx:myapp.git
 HEAD
   * executing if [ -d /home/myaccount/sites/myapp/shared/cached-
 copy ]; then cd /home/myaccount/sites/myapp/shared/cached-copy  git
 fetch -q origin  git reset -q --hard
 fa998c24c672352b2bef3ff9314881f441bd4c54; else git clone -q
 g...@mysite.ath.cx:myapp.git /home/myaccount/sites/myapp/shared/cached-
 copy  cd /home/myaccount/sites/myapp/shared/cached-copy  git
 checkout -q -b deploy fa998c24c672352b2bef3ff9314881f441bd4c54; fi
 servers: [mysite.ath.cx]
 [mysite.ath.cx] executing command
  ** [mysite.ath.cx :: err] ssh: connect to host mysite.ath.cx port 22:
 Connection timed out
  ** [mysite.ath.cx :: err] fatal: The remote end hung up unexpectedly
 command finished
 *** [deploy:update_code] rolling back
   * executing rm -rf /home/myaccount/sites/myapp/releases/
 20090313185556; true
 servers: [mysite.ath.cx]
 [mysite.ath.cx] executing command
 command finished
 failed: sh -c \if [ -d /home/myaccount/sites/myapp/shared/cached-
 copy ]; then cd /home/myaccount/sites/myapp/shared/cached-copy  git
 fetch -q origin  git reset -q --hard
 fa998c24c672352b2bef3ff9314881f441bd4c54; else git clone -q
 g...@mysite.ath.cx:myapp.git /home/myaccount/sites/myapp/shared/cached-
 copy  cd /home/myaccount/sites/myapp/shared/cached-copy git
 checkout -q -b deploy fa998c24c672352b2bef3ff9314881f441bd4c54; fi\
 on mysite.ath.cx
  


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

[Capistrano] Re: how to setup capistrano for three tier behind firewall

[Jamis Buck]

The :db question has come up before on the list: essentially, the answer
to why does my code have to be on the db server is it doesn't. Just
set one of your app servers to be the primary db server. Capistrano only
uses the :db role to determine where to run migrations.

- Jamis

On 3/11/09 9:21 AM, walt_d wrote:
 Hi -
 
 I cap my websites all the time - and am loving it, thanks to Jamis!
 
 But I've been assigned to a job which will take me on the grand
 tour (with three tier* deployment) - and I just cannot seem to get my
 deploy.rb right :(
 
 Does anyone have thoughts/experiences to share - or the magical three
 words to type into my 'googlescope' :)
 
 My physical world is like this (with me temporarily on the inside -
 ie able to address all servers directly from 10.4.3.x):
 
 firewall: 10.4.3.1 - admin assures me that all ssh will go through
 this
 webserver: 10.4.3.221, Apache and passengers ;) (ssh port 1)
 git repository: 10.4.3.222 (ssh port 2)
 dbserver: 10.4.3.220, MySQL (ssh port 0)
 except for the firewall, all accessible with public key as user
 www_user (ie I can do: ssh webserver -lwww_user)
 
 My eminent problem is that my role :db does not seem to work! When I
 cap deploy, I get this error:
 
  ** [10.4.3.220 :: err] fatal: could not create work tree dir '/data/
 napkins/shared/cached-copy': Permission denied.
 
 And I do not understand, what my code is doing on the db-server -
 why do the role :db try to update_code on my db-server?
 
 
 
 
 
 * - ehh, I know that this setup does not qualify for the gold
 standard three tier - but, hey, at least it includes 3 servers with
 different purposes :D
  


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

[Capistrano] Re: Ensure connectivity before deploy

[Jamis Buck]

You could do something like this:

  task :ensure_connected do
connect!
  end

  before deploy:update_code, ensure_connected

The connect! method forces a connection to be opened all servers that
match the given task. You can give arguments, too, so you can specify
explicit roles, hosts, etc:

  connect! :roles = %w(app db)
  connect! :hosts = %w(this.host that.host)

etc.

- Jamis

On 3/11/09 2:10 PM, gran.roble wrote:
 Greetings to all
 
 I'm using Capistrano to update code php and rails on 3 servers located
 in different geographic areas of Oaxaca in Mexico.
 The conditions of each region does not ensure that the VPN installed
 between each computer and office work.
 
 There is a way of ensuring that there Capistrano connectivity with the
 servers before you deploy one? If for some reason there is no
 connection abort deploy. The goal is always to ensure that deploy runs
 on three servers, or none.
 
  


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

[Capistrano] Re: no such file to load -- capistrano/cli (LoadError)

[Jamis Buck]

The install is definitely broken. capistrano/cli.rb is one of the
standard files for capistrano. Try uninstalling all installed versions
of capistrano and reinstalling it.

- Jamis

On 3/10/09 9:13 AM, lamp5matt wrote:
 I found another thread here where someone got this error and solved it
 more or less by reinstalling everything, and by adding capistrano-ext
 to support multistage deployment.
 
 I am *not using multistage deployment, and have reinstalled
 everything, and still get this error.
 
 Can someone explain what the problem is exactly? Ruby's $LOAD_PATH is
 /usr/local/lib/site_ruby/1.8
 /usr/local/lib/site_ruby/1.8/powerpc-linux
 /usr/local/lib/site_ruby
 /usr/lib/ruby/vendor_ruby/1.8
 /usr/lib/ruby/vendor_ruby/1.8/powerpc-linux
 /usr/lib/ruby/vendor_ruby
 /usr/lib/ruby/1.8
 /usr/lib/ruby/1.8/powerpc-linux
 
 do I need to symlink capistrano, or /var/lib/gems/1.8 ?
 
 This, incidentally, is capistrano 2.5.5; I've used 2.4.0 for a long
 time with no problems, and it's bin/cap doesn't require 'capistrano/
 cli' but rubygems installed 2.5.5 on this machine, which is new
 (Debian)
  


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

[Capistrano] Re: no such file to load -- capistrano/cli (LoadError)

[Jamis Buck]

Sounds like rubygems might not be loading. Try:

  export RUBYOPT=rubygems

and see if that helps. (That will cause rubygems to be loaded
automatically by Ruby.)

- Jamis

On 3/10/09 9:26 AM, lamp5matt wrote:
 I  have now reinstalled capistrano 3 times.
 and
 chmod -R o+r /var/lib/gems/1.8/gems/
 
 No improvement.
 
 On Mar 10, 9:18 am, Jonathan Weiss j...@innerewut.de wrote:
 This sounds like a permission problem. Check that all files of the gem
 are world-readable.

 Jonathan

 --
 Jonathan Weisshttp://blog.innerewut.dehttp://twitter.com/jweiss
  


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

[Capistrano] Re: no such file to load -- capistrano/cli (LoadError)

[Jamis Buck]

Ah, and thus we encounter one of my biggest reasons for hating Debian.
:) I have no idea how to solve that. I'll let other debianistas help you
with that one.

- Jamis

On 3/10/09 10:28 AM, lamp5matt wrote:
 it *does help!
 but alas i get
 /usr/lib/ruby/1.8/rubygems/custom_require.rb:27:in
 `gem_original_require': no such file to load -- openssl (LoadError)
 
 with apt-get install libopenssl-ruby1.8
 The following packages have unmet dependencies:
   libopenssl-ruby1.8: Depends: libruby1.8 (= 1.8.5) but it is not
 going to be installed
 
 and
 libruby1.8 is already the newest version.
 
 M
 
 On Mar 10, 9:44 am, Jamis Buck ja...@37signals.com wrote:
 Sounds like rubygems might not be loading. Try:

   export RUBYOPT=rubygems

 and see if that helps. (That will cause rubygems to be loaded
 automatically by Ruby.)

 - Jamis

 On 3/10/09 9:26 AM, lamp5matt wrote:

 I  have now reinstalled capistrano 3 times.
 and
 chmod -R o+r /var/lib/gems/1.8/gems/
 No improvement.
 On Mar 10, 9:18 am, Jonathan Weiss j...@innerewut.de wrote:
 This sounds like a permission problem. Check that all files of the gem
 are world-readable.
 Jonathan
 --
 Jonathan Weisshttp://blog.innerewut.dehttp://twitter.com/jweiss
  


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

[Capistrano] Re: Help with Capistrano on Multiple Servers

[Jamis Buck]

On 3/8/09 7:03 PM, S. Robert James wrote:
 Hi.  We're beginning to scale our Capistrano config to multiple
 servers, and I've gotten stuck on a few points:
 
 1. My understanding is that tasks themselves run only once, no matter
 how many servers and roles we have defined, just that run, sudo,
 and similar methods fork into each matching server/role.  Is that
 correct?

Yeah, though fork is probably the wrong term. Basically, the command
is pushed to each matching server, and then Capistrano waits until all
servers have finished before moving to the next run command.

 So, if a task doesn't use run or the like, its invocation will be
 identical, even after we define multiple roles.
 
 Is that correct?

Possibly, but I'm not sure what you mean. :)

 2. I also believe that run and similar methods will run, in
 parallel, on all servers that match the *current* task's roles, even
 if the current task was called by a task with a more limited set of
 roles.  (If task :a calls :b, and :b does run, the run will happen on
 all of :b's roles, even if :a doesn't share them.)  Is this correct
 also?

Right. Server scope is not inherited; it applies only to the curernt
task, not to tasks invoked from the current task.

 3. What happens if a run invoked by a task fails on one server but
 not others? Is the whole task considered to have failed (and will then
 normally be aborted and have its rollback invoked)?

If a command fails on one server but not on others, an exception is
raised. If the command was invoked inside of a transaction (and the
exception was not caught anywhere), all registered rollback blocks will
be invoked.

Thus, even if a task has a rollback block registered, the rollback will
not be called unless a transaction is active. E.g.

  task :foo do
transaction do
  bar
  baz
end
  end

Any exception in bar or baz will cause associated rollbacks to be called.

- Jamis

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

[Capistrano] Re: Capistrano Idioms

[Jamis Buck]

On 3/8/09 7:46 PM, S. Robert James wrote:
 Is there a standard Capistrano idiom for passing in, and parsing, user
 defined parameters from the command line? I know vars can be set using
 -S.  But I'd like more: supporting boolean switches, or switches with
 a default val. If I was writing my own script, I'd use OptionParser or
 the like - what's the preferred Capistrano way to do this?

The 'cap' utility doesn't have any way for you to extend the supported
set of command-line switches. However, you could write your own utility
that wraps Capistrano and has it's own set of switches. You could
probably just subclass Capistrano::CLI, implement the command-line
parsing stuff, and call that from  your own wrapper.

 Along similar lines, is there a standard idiom for a task to take a
 parameter, or return a result?  I could hack this with a global
 variable, but I'd like to find a preferred way.

Nope. What you could probably do is implement the task as a vanilla Ruby
method, and then invoke the method wherever needed:

  def my_stuff(param1, param2, ...)
run ...
return some_value
  end

  task :my_task do
puts my_stuff(a, b, ...)
  end

- Jamis

  


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

[Capistrano] Re: copy_exclude seemingly having no effect

[Jamis Buck]

Try:

  set :copy_exclude, [**/.svn]

- Jamis

On 3/6/09 1:16 AM, Yevgeniy A. Viktorov wrote:
 
 Hello,
 
 I have exactly same behavior with Capistrano v2.5.4
 Is there any solution? :)
 
 Thanks.
 
 On 11 Чер 2008, 06:43, JBB jay.borenst...@gmail.com wrote:
 With v2.3 I have the following in deploy.rb, but all the .svn dirs are
 deployed to remote servers anyway.   In other words, the copy_exclude
 seems to be having no effect.  Has anyone else experienced this?  I am
 using the lighter weight svn server as as opposed to an http one -
 would that make any difference?  Ideas welcome...

 set :deploy_via, :copy
 set :copy_cache, true
 set :copy_exclude, [.svn, .git]

 JBB
 
 
  


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

[Capistrano] Re: Help with custom task (moving contents of current)

[Jamis Buck]

I would strongly recommend that you not use the standard deploy tasks,
and just write your own.

- Jamis

On 3/5/09 12:16 PM, goodieboy wrote:
 Hi,
 
 I have a repo that's a simple static site. The trunk is the websites
 document root. I need to deploy this site to a server that has current/
 www as its document root, where current is the directory created by
 capistrano. I'm trying to figure out the best way to:
 
 create a www directory after deploy
 move all of the files (except for www) into www
 
 That just seems weird though.
 
 Is there are way to specify something like:
 
 before 'deploy:update_code', 'create_www_and_set_current_path_to_www'
 
 ?
 
 Thanks for any insight on how this can be accomplished.
 
 Matt
  


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

[Capistrano] Re: Help with custom task (moving contents of current)

[Jamis Buck]

Sorry, I misread your original message. I thought you were trying to
replace the current symlink; and in general, if you need to muck with
the core assumptions that much, it's easier to just write your own.

I see that you were just wanting to do something after the push of the
site. The before() hook you mentioned is one way, but it sounds like,
even more what you want, is to just structure your repository such that
everything is already in the right directory structure.

Otherwise, yeah, you're looking at some shell scripting, like a for loop
that skips 'www' and moves everything else to www.

- Jamis

On 3/5/09 12:40 PM, matt mitchell wrote:
 Interesting. I'll definitely consider that. The solution I just came
 up with involves using: grep -v www
 
 I'm curious about why you're strongly recommending against using the
 defaults? There must be something bigger I'm not thinking about...
 
 Matt
 
 On Mar 5, 2:36 pm, Jamis Buck ja...@37signals.com wrote:
 I would strongly recommend that you not use the standard deploy tasks,
 and just write your own.

 - Jamis

 On 3/5/09 12:16 PM, goodieboy wrote:

 Hi,
 I have a repo that's a simple static site. The trunk is the websites
 document root. I need to deploy this site to a server that has current/
 www as its document root, where current is the directory created by
 capistrano. I'm trying to figure out the best way to:
 create a www directory after deploy
 move all of the files (except for www) into www
 That just seems weird though.
 Is there are way to specify something like:
 before 'deploy:update_code', 'create_www_and_set_current_path_to_www'
 ?
 Thanks for any insight on how this can be accomplished.
 Matt

  


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

[Capistrano] Re: sftp failures on media temple

[Jamis Buck]

You'll need to override the deploy:symlink task to do that.

- Jamis

On 3/4/09 2:28 PM, mkrisher wrote:
 Thanks Jamis. That helped! Now I just need to control the current
 symlink to be relative to the directory rather than using the whole
 deploy path.
 
 Something like:
 
 releases/release
 
 Rather than:
 
 /users/xx/home/domains/example.com/releases/release
 
 is this possible through a variable, or do I have to write a custom
 task?
 
 Thanks again,
 -- Mike
  


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

[Capistrano] Re: a suggestion idea

[Jamis Buck]

You can create separate tasks, but then call them from a single meta
copyconfig task:

  task :copyconfig_app, :roles = appservers do
  end

  task :copyconfig_db, :roles = dbservers do
  end

  task :copyconfig do
copyconfig_app
copyconfig_db
  end

- Jamis

On 3/3/09 10:26 AM, Gerhardus Geldenhuis wrote:
 Hi
 It would be nice to have something like the following:
 
 namespace config
   task :copyconfig, :roles = appservers
do_something
   end
 
   task :copyconfig, :roles = dbservers
 do_something
   end
 end
 
 the idea being that if you call config.copyconfig it will get called
 twice but for each role type it is definined.
 
 If there is another way to achieve this I would gladly hear about it.
 
 at them moment I have to differentiate my tasks by giving them
 different names for each task that deploys config to server types.
 
 Regards
 
 
  


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

[Capistrano] Re: sftp failures on media temple

[Jamis Buck]

You need to specify the absolute path for the :deploy_to variable. SFTP
(the protocol) does not understand what the tilde character means, since
it is not a shell command.

- Jamis

On 3/2/09 8:13 PM, mkrisher wrote:
 I have been trying to use Cap to deploy a PHP site to the media temple
 Grid Servers. Should be a really easy recipe. I have the media temple
 cap gem installed as well. My deploy:setup was successful, and now I
 am trying to do my cold deploy. However I keep running into an SFTP
 error similar to the following:
 
 upload via sftp failed on s12345.gridserver.com:
 Net::SFTP::StatusException (Net::SFTP::StatusException open ~/domains/
 example.com/tmp/20090303030442.tar.gz (2, no such file))
 
 My recipe is pretty simple:
 
 require 'mt-capistrano'
 
 # Config
 set :site, 12345
 set :application,  example.com
 set :webpath,  example.com
 set :domain,   s#{site}.gridserver.com
 set :user, serverad...@#{webpath}
 set :password, 
 
 # Other options
 default_run_options[:pty] = true
 set :use_sudo, false # MediaTemple doesn't allow sudo command
 
 # Repo stuff
 set :scm, :git
 set :repository, .
 set :deploy_to, ~/domains/#{application}
 set :current_deploy_dir, #{deploy_to}/current
 set :deploy_via, :copy
 set :copy_remote_dir, #{deploy_to}/tmp
 set :branch, master
 
 # Roles
 role :web, domain
 role :app, domain
 role :db,  domain, :primary = true
 
 I know the login works, I can ssh in. I have setup an ssh key and that
 works as well. I changed the remote directory to a specific directory
 so I could make sure the permissions were set correctly.
 
 Anyone have any ideas as to why the upload is failing? I would
 appreciate any help.
  


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

[Capistrano] Re: major problems with simple code update from local git repo

[Jamis Buck]

The checkout is never run via sudo. You need to make sure the
permissions on the directories created by deploy:setup are such that
your deploy user can create files in them without using sudo.

- Jamis

On 2/28/09 7:50 AM, j0llyr0g3r wrote:
 Hey guys,
 
 i am fairly new to capistrano.
 
 I am desperately trying to deploy a freshly created git-project to a
 totally empty directory on my test-server.
 So far, this has been a friggin nightmare unfortunately:
 - the code checkout itself fails no matter what i am trying
 - the error messages i get back are weird and not helpfull at all.
 
 Here is my deploy.rb (without tasks since the code checkout itself is
 not working):
 
 #
 #Application
 #
 
 set :application, addloops
 set :deploy_to, /var/www/#{application}
 
 #
 #Settings
 #
 
 set :use_sudo, true
 set :port, 
 
 #
 #Servers
 #
 
 set :user, ''
 set :password, 'x'
 role :app, addloops.com
 role :web, addloops.com
 role :db,  addloops.com, :primary = true
 
 
 #
 #SCM
 #
 
 set :scm, :git
 set :repository, .
 set :deploy_via, :checkout
 #set :branch, master
 
 Now, a 'cap deploy:setup' is ok:
 
 Server--
 ls -al /var/www/addloops/
 total 8
 drwxrwxrwx 2 www-data root 4096 2009-02-28 15:41 .
 drwxr-xr-x 5 root root 4096 2009-02-27 14:12 ..
 
 -Client-
 cap deploy:setup
   * executing `deploy:setup'
   * executing sudo -p 'sudo password: ' mkdir -p /var/www/addloops /
 var/www/addloops/releases /var/www/addloops/shared /var/www/addloops/
 shared/system /var/www/addloops/shared/log /var/www/addloops/shared/
 pids  sudo -p 'sudo password: ' chmod g+w /var/www/addloops /var/www/
 addloops/releases /var/www/addloops/shared /var/www/addloops/shared/
 system /var/www/addloops/shared/log /var/www/addloops/shared/pids
 servers: [addloops.com]
 [addloops.com] executing command
 command finished
 
 -Server again
 ls -al /var/www/addloops/
 total 16
 drwxrwxrwx 4 www-data root 4096 2009-02-28 15:42 .
 drwxr-xr-x 5 root root 4096 2009-02-27 14:12 ..
 drwxrwxr-x 2 root root 4096 2009-02-28 15:42 releases
 drwxrwxr-x 5 root root 4096 2009-02-28 15:42 shared
 
 - Ok, so that went fine.
 
 But the checkout fails:
 
 cap deploy:cold
   * executing
 `deploy:cold'
   * executing
 `deploy:update'
  ** transaction:
 start
   * executing
 `deploy:update_code'
 executing locally: git ls-remote .
 HEAD
   * executing git clone -q . /var/www/addloops/releases/
 20090228144319  cd /var/www/addloops/releases/20090228144319  git
 checkout -q -b deploy 287dc08148f7ebcc271b82687b3704cf539115de 
 (echo 287dc08148f7ebcc271b82687b3704cf539115de  /var/www/addloops/
 releases/20090228144319/
 REVISION)
 servers:
 [addloops.com]
 [addloops.com] executing
 command
  ** [addloops.com :: err]
 mkdir:
  ** [addloops.com :: err] cannot create directory `/var/www/addloops/
 releases/
 20090228144319'
  ** [addloops.com :: err] : Permission
 denied
  ** [addloops.com ::
 err]
  ** [addloops.com :: err] usage: git-clone [options] [--] repo
 [dir]
  ** [addloops.com ::
 err]
  ** [addloops.com ::
 err]
  ** [addloops.com :: err] -
 n
  ** [addloops.com ::
 err] ,
  ** [addloops.com :: err] --no-
 checkout
  ** [addloops.com :: err]  don't create a
 checkout
  ** [addloops.com ::
 err]
  ** [addloops.com :: err] --
 bare
  ** [addloops.com :: err] create a bare
 repository
  ** [addloops.com ::
 err]
  ** [addloops.com :: err] --
 naked
  ** [addloops.com :: err]create a bare
 repository
  ** [addloops.com ::
 err]
  ** [addloops.com :: err] -
 l
  ** [addloops.com ::
 err] ,
  ** [addloops.com :: err] --
 local
  ** [addloops.com :: err]to clone from a local repository
 
 The problem seems to be:
 
 cannot create directory `/var/www/addloops/releases/
 20090228144319'
 
 which is odd, because my specified user can do anything with sudo
 (even without password for testing purposes):
 
 On the server:
 
 sudo mkdir /var/www/addloops/releases/20090228144319
 
 - is working!
 
 Now, since the error message is completely useless to me, i can only
 speculate what's going wrong here.
 
 - maybe this:
 set :repository, .
 in my deploy.rb? (when i execute capistrano i am within my local git-
 repo)
 - or maybe this:
 set :deploy_via, :checkout
 ?
 
 Any help would be greatly appreciated since i am totally stuck...
 
  


--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to 

[Capistrano] Re: major problems with simple code update from local git repo

[Jamis Buck]

Using file:// repos introduces issues of it's own. Search the list for
workarounds--it's come up pretty frequently.

- Jamis

On 2/28/09 8:22 AM, j0llyr0g3r wrote:
 Hi Jamis and thanks for the tip.
 
 Unfortunately all my directories already have a 777-mask (did that out
 of frustration) so this shouldn't be the problem.
 
 After a tip in the IRC i changed my deploy.rb to:
 
 set :repository, file:///var/www/#{application}
 set :deploy_via, :copy
 
 After that, it seemed to be working at first:
 
 cap
 deploy:cold
   * executing
 `deploy:cold'
   * executing
 `deploy:update'
  ** transaction:
 start
   * executing
 `deploy:update_code'
 executing locally: git ls-remote file:///var/www/addloops
 HEAD
   * getting (via checkout) revision
 287dc08148f7ebcc271b82687b3704cf539115de to /tmp/
 20090228152031
 executing locally: git clone -q file:///var/www/addloops /tmp/
 20090228152031  cd /tmp/20090228152031  git checkout -q -b deploy
 287dc08148f7ebcc271b82687b3704cf539115de
 remote: Counting objects: 457,
 done.
 remote: Compressing objects: 100% (420/420),
 done.
 remote: Total 457 (delta 64), reused 0 (delta
 0)
 compressing /tmp/20090228152031 to /tmp/
 20090228152031.tar.gz
 executing locally: tar czf 20090228152031.tar.gz
 20090228152031
 servers:
 [addloops.com]
  ** sftp upload /tmp/20090228152031.tar.gz - /tmp/
 20090228152031.tar.gz
 [addloops.com] /tmp/
 20090228152031.tar.gz
 ^C*** [deploy:update_code] rolling
 back
   * executing rm -rf /var/www/addloops/releases/20090228152031;
 true
 servers:
 [addloops.com]
 [addloops.com] executing
 command
 command finished
 
 But then i get an error message for every file in my project like
 this:
 
 *** [err :: addloops.com] 20090228150801/app/views/admins/
 search_track_for_edit_form.haml: Cannot
 open
 *** [err :: addloops.com] : No such file or
 directory
 *** [err ::
 addloops.com]
 *** [err :: addloops.com]
 tar:
 *** [err :: addloops.com] 20090228150801/app/views/admins/
 upload_file_form.haml: Cannot
 open
 *** [err :: addloops.com] : No such file or
 directory
 *** [err ::
 addloops.com]
 *** [err :: addloops.com]
 tar:
 *** [err :: addloops.com] 20090228150801/app/views/registrations:
 Cannot
 mkdir
 *** [err :: addloops.com] : No such file or
 directory
 *** [err ::
 addloops.com]
 *** [err :: addloops.com]
 tar:
 *** [err :: addloops.com] 20090228150801/app/views/registrations/
 show_purchases.haml: Cannot
 open
 *** [err :: addloops.com] : No such file or
 directory
 *** [err ::
 addloops.com]
 *** [err :: addloops.com]
 tar:
 *** [err :: addloops.com] 20090228150801/app/views/registrations/
 start.haml: Cannot
 open
 *** [err :: addloops.com] : No such file or
 directory
 *** [err ::
 addloops.com]
 *** [err :: addloops.com]
 tar:
 *** [err :: addloops.com] 20090228150801/app/views/registrations/
 index.haml: Cannot
 open
 *** [err :: addloops.com] : No such file or
 directory
 
 and so on.
 
 Any more ideas?
  


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

[Capistrano] Re: Capistrano maintainership

[Jamis Buck]

On 2/26/09 2:18 PM, Lee Hambley wrote:
 Hey Jamis,
 
 I never actually bothered to check, I figured it was served from the
 github gem server -- completely agree with your last statement about
 people not really taking much interest in hacking the core before,
 there's no reason that people should go messing with it for no real
 reason now...
 
 My only concern would be that there is no more single place to go to get
 a copy, get info and learn about it, a bunch of similarly named forks,
 with similar feature sets would just cause trouble :)

The only reason people look to /jamis/capistrano as the canonical copy
is because that's what's been linked to in the past. As soon as another
repo because the canonical one (whatever that means), it becomes a
documentation issue. There's really nothing especially discoverable
about /jamis/capistrano, and there are already a LOT of capistrano
forks on github, and it never really caused trouble before. :)

- Jamis

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

[Capistrano] Re: Capistrano maintainership

[Jamis Buck]

On 2/26/09 2:27 PM, Jonathan Weiss wrote:
 Lee Hambley wrote:
 My only concern would be that there is no more single place to go to get 
 a copy, get info and learn about it, a bunch of similarly named forks, 
 with similar feature sets would just cause trouble :)
 
 I don't think this will happen as the 'blessed' version will pretty fast 
 become known and linked.
 
 Mathias and I thought about using the 'capistrano' github user as the 
 main repo. So future releases come from github.com/capistrano/capistrano 
 and github.com/capistrano/capistrano/net-ssh. Is using the Capistrano 
 name for this user on Github ok with you Jamis?

I'm totally out of this game. :) Play by whatever rules you wish!

- Jamis

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

[Capistrano] Re: Capistrano maintainership

[Jamis Buck]

On 2/26/09 2:39 PM, Lee Hambley wrote:
 +1 for a capistrano user on github...
 
 Does anyone know what happens, if Rubyforge, and Github gems both exist,
 which do you end up with... the newest, I suppose?

Github gems are not searched unless you explicitly configure for them.
Furthermore, github gems are prefixed with the username (e.g.
jamis-capistrano, if my cap repo were configured to serve gems).

- Jamis

 
 - Lee
 
 2009/2/26 Jamis Buck ja...@37signals.com mailto:ja...@37signals.com
 
 
 On 2/26/09 2:27 PM, Jonathan Weiss wrote:
  Lee Hambley wrote:
  My only concern would be that there is no more single place to go
 to get
  a copy, get info and learn about it, a bunch of similarly named
 forks,
  with similar feature sets would just cause trouble :)
 
  I don't think this will happen as the 'blessed' version will
 pretty fast
  become known and linked.
 
  Mathias and I thought about using the 'capistrano' github user as the
  main repo. So future releases come from
 github.com/capistrano/capistrano
 http://github.com/capistrano/capistrano
  and github.com/capistrano/capistrano/net-ssh
 http://github.com/capistrano/capistrano/net-ssh. Is using the
 Capistrano
  name for this user on Github ok with you Jamis?
 
 I'm totally out of this game. :) Play by whatever rules you wish!
 
 - Jamis
 
 
 
 
  


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

[Capistrano] Re: Permission denied, please try again.

[Jamis Buck]

Hey,

Looking at the output:

  ** [domain.com :: err] Permission denied, please try again.
  ** [domain.com :: err] Permission denied, please try again.
  ** [domain.com :: err] Received disconnect from 99.99.99.99: 2: Too
 many authentication failures for git
  ** [domain.com :: err] fatal: The remote end hung up unexpectedly
 command finished

You'll notice it is the git process running on the remote host that is
complaining. I suspect you do not have your public keys configured so
that SSH works (passwordlessly) from domain.com to 99.99.99.99. Perhaps
on your old machine you had a local ssh-agent being forwarded, and you
havent' configured that for your fresh machine?

- Jamis

On 2/25/09 4:23 PM, partydrone wrote:
 I just moved to a fresh machine and am experiencing deploy problems.
 Here are my configurations:
 
 Laptop:
 capistrano 2.5.5
 rails 2.1.0
 rubygems 1.3.1
 git 1.6.1.3
 
 Host server:
 rails 2.1.0
 rubygems 1.1.1
 git 1.5.4.1
 
 Git server:
 git 1.6.0.1
 
 I downloaded the code for my app from my git repository. Here is my
 config/deploy.rb file:
 
 ##
 
 require 'rt_capistrano' # Custom gem for working in Media Temple (gs)
 environment
 
 set :site, 9
 set :application,  www
 set :webpath,  domain.com
 set :domain,   domain.com
 set :user, serveradmin%domain.com
 set :password, password
 
 # repository elsewhere
 set :scm, :git
 set :repository, g...@git.domain.com:Repositories/my_app.git
 set :ssh_options, { :forward_agent = false }
 set :branch, master
 set :deploy_via, :remote_cache
 
 # these shouldn't be changed
 role :web, #{domain}
 role :app, #{domain}
 role :db,  #{domain}, :primary = true
 set :deploy_to,/home/#{site}/containers/rails/#{application}
 
 namespace :deploy do
   desc Creates the database configuration file in the application's
 config directory.
   task :update_config, :roles = :app do
 database_yml = -CMD
   production:
 adapter: mysql
 database: db9_my_app_production
 username: db9
 password: password
 host: internal-db.s9.gridserver.com
 CMD
 put database_yml, #{release_path}/config/database.yml
   end
   after deploy:update_code, deploy:update_config
 end
 
 ##
 
 When I run cap deploy I get the following output:
 
 ##
 
 fiona:my_app aporter$ cap deploy
   * executing `deploy'
   * executing `deploy:update'
  ** transaction: start
   * executing `deploy:update_code'
 updating the cached checkout on all servers
 executing locally: git ls-remote g...@git.domain.com:Repositories/
 my_app.git master
   * executing if [ -d /home/9/containers/rails/www/shared/cached-
 copy ]; then cd /home/9/containers/rails/www/shared/cached-copy 
 git fetch -q origin  git reset -q --hard
 6932773a80d6a5a72ad42363ecbd6b8815e52483; else git clone -q
 g...@git.domain.com:Repositories/my_app.git /home/9/containers/
 rails/www/shared/cached-copy  cd /home/9/containers/rails/www/
 shared/cached-copy  git checkout -q -b deploy
 6932773a80d6a5a72ad42363ecbd6b8815e52483; fi
 servers: [domain.com]
 [domain.com] executing command
  ** [domain.com :: err] Permission denied, please try again.
  ** [domain.com :: err] Permission denied, please try again.
  ** [domain.com :: err] Received disconnect from 99.99.99.99: 2: Too
 many authentication failures for git
  ** [domain.com :: err] fatal: The remote end hung up unexpectedly
 command finished
 *** [deploy:update_code] rolling back
   * executing rm -rf /home/9/containers/rails/www/releases/
 20090225231003; true
 servers: [domain.com]
 [domain.com] executing command
 command finished
 failed: sh -c \if [ -d /home/9/containers/rails/www/shared/
 cached-copy ]; then cd /home/9/containers/rails/www/shared/cached-
 copy  git fetch -q origin  git reset -q --hard
 6932773a80d6a5a72ad42363ecbd6b8815e52483; else git clone -q
 g...@git.domain.com:Repositories/my_app.git /home/9/containers/
 rails/www/shared/cached-copy  cd /home/9/containers/rails/www/
 shared/cached-copy  git checkout -q -b deploy
 6932773a80d6a5a72ad42363ecbd6b8815e52483; fi\ on domain.com
 fiona:my_app aporter$
 
 ##
 
 I have created RSA keys and copied my public keys to both the hosting
 server and to the Git server. From my laptop, I can ssh into the
 hosting server successfully, and I can ssh into the Git server
 successfully. Also, I can successfully ssh from the hosting server to
 the Git server successfully.
 
 Has anyone overcome this problem or does anyone have any input on my
 configuration that might help resolve this issue? Previous posts on
 this topic have not been helpful.
 
 Thanks.
  


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

[Capistrano] Re: `require': no such file to load -- rubygems

[Jamis Buck]

What about which rake?

If I had to guess, I'd say you've got at least two different ruby
installations on that server, and the shebang line in whichever rake is
being run is pointing to the OTHER ruby installation, the one the
doesn't have rubygems installed.

- Jamis

On 2/21/09 9:48 AM, elliottg wrote:
 Lee,
 Here's the info. All server side...
 
 which ruby  __   /usr/bin/ruby
 which gem  __   /home/10838/data/rubygems/bin/gem
 
 ruby -v  __  ruby 1.8.5 (2006-08-25) [i386-linux]
 gem -v  __  1.3.1
 
 Again a further note: I was able to run rubygems-update but due to
 permission restrictions was not able to run update_rubygems as well.
 So I don't know if that somehow left me with an incomplete install...?
 
 Also, these lines are in  .bash_profile just FYI
 #MTSTART
 export PATH=$PATH:/home/10838/data/rubygems/bin:/home/10838/data/
 rubygems/gems/bin
 export RUBYLIB=/home/10838/data/rubygems/local/lib/site_ruby/1.8:/home/
 10838/data/rubygems/lib
 export GEM_HOME=/home/10838/data/rubygems/gems
 #MTEND
 
 Thanks a lot!
 
 
 
 On 21 Feb, 05:33, Lee Hambley lee.hamb...@gmail.com wrote:
 Elliot,
 Use 'pastie' for code snippets (pastie.org) - please run the following on
 your server:

 ruby -v
 gem -v

 which ruby
 which gem

 And give me the output from that...

 2009/2/21 elliottg x...@simplecircle.net



 Lee.
 Thanks for getting back to me.
 I ran gem list on the server. Neither rubygems or rubygems-update
 showed up.
 Then I ran  gem install rubygems-update it seemed to go as planned...
 Then based on what I read I thought I needed to run update_rubygems as
 well to complete the rubygems install and update. But when I ran the
 second line I got a read only permissions error. I'm sure it's due to
 the configs of my shared server...
 After that just to see what I had,  I ran gem --version and it said
 1.3.1
 So I can't really tell if rubygems is now installed and configured
 correctly or not due to the fact that update_rubygems got killed to
 the pemissions issue. I guess I should have ran gem -v at the
 beginning.
 At any rate I still get the same `require': no such file to load --
 rubygems  when running cap deploy:migrate
 Any thoughts?
 Thanks so much.
 Elliott
 P.S. Is there anyway to style text as code here?
 On Feb 20, 6:39 pm, Lee Hambley lee.hamb...@gmail.com wrote:
 Elliot,
 Your server doesn't appear to have Rubygems installed. You can get, and
 install it from the rubygems site, installation really is a snap, give
 that
 a shot (on your server) -- and post back here.
 - Lee
 2009/2/20 elliottg x...@simplecircle.net
 Hello,
 This is my first post here. I am new to Rails as well as working in
 Bash.
 I am trying to deploy a Rails app that is frozen to v2.1.2 to a
 MediaTemple gridserver. The app I'm deploying is the Redmine  OS
 project management program. The app runs fine on my OS X 10.5 machine
 and mysql as the dev environment.
 I went through this post:
 http://groups.google.com/group/capistrano/browse_thread/thread/dde29b.
 ..
 As well as tons of Google searches and trying stuff out. Still, I
 couldn't solve the problem. On my MT shared server I don't root access
 or write access to .bashrc etc... beyond that, I am foggy on what some
 of my paths should even be and where to set them.
 The cap deploy:set up worked fine. Then I ran cap deploy:cold, all the
 files went over fine from my git repo which is on the target deploy
 box. Below is the error I always get. I have the same problem running
 cap deploy:migrate as well.
  * executing cd /home/10838/containers/rails/redmine/releases/
 20090220170452; PATH=$PATH:/home/10838/data/rubygems/bin:/home/10838/
 data/rubygems/gems/bin RUBYLIB=/home/10838/data/rubygems/local/lib/
 site_ruby/1.8 GEM_HOME=/home/10838/data/rubygems/gems rake
 RAILS_ENV=production  db:migrate
servers: [simplecircle.net]
[simplecircle.net] executing command
 *** [err :: simplecircle.net] /home/10838/data/rubygems/gems/bin/rake:
 9:in `require': no such file to load -- rubygems (LoadError)
 *** [err :: simplecircle.net] from /home/10838/data/rubygems/gems/bin/
 rake:9
command finished
 failed: sh -c \cd /home/10838/containers/rails/redmine/releases/
 20090220170452; PATH=\\$PATH:/home/10838/data/rubygems/bin:/home/10838/
 data/rubygems/gems/bin RUBYLIB=/home/10838/data/rubygems/local/lib/
 site_ruby/1.8 GEM_HOME=/home/10838/data/rubygems/gems rake
 RAILS_ENV=production  db:migrate\ on simplecircle.net
 And here's my deploy.rb
 NOTE: I tried some setting default_run_options[:env] values in
 deploy.rb but to no effect. you can see them commented out. I am not
 sure if those two path are even correct.
 require 'mt-capistrano'
 set :site, 10838
 set :application,  redmine
 set :webpath,  projects.simplecircle.net
 set :domain,   simplecircle.net
 set :user, serverad...@simplecircle.net
 set :password, monkey75
 # default_run_options[:env] = { PATH = $PATH:/home/10838/data/
 rubygems/bin:/home/10838/data/rubygems/gems/bin,
 #  

[Capistrano] Re: writing a preflightcheck task

[Jamis Buck]

If an exception is raised, it does not cause a task to return a value;
it causes a task to raise an exception. You need to use a begin/rescue
clause, instead of an unless condition.

  begin
some.task
  rescue Exception = e
puts got exception: #{e}
  end

Does that make sense? Exceptions bypass your program logic and require
explicit handling.

- Jamis

On 2/20/09 9:28 AM, Gerhardus Geldenhuis wrote:
 Hi
 Version 1
   task :check_lb_worker_exists, :roles = :apacluster, :on_error
 = :abort do
 if exists?(:modjk_loadbalancerworker) then
   begin
 run if wget #{wgetparams} 'http://$CAPISTRANO:HOST$/jkserver-
 status?cmd=editfrom=listw=#{modjk_loadbalancerworker}' | grep
 'ERROR'; then false;else true;fi  22/dev/null;
   rescue
 puts The specified modjk load balancer worker does not
 exists
   end
 end
   end#task
 
 
 calling the task:
 task :preflightcheck, :on_error = :abort do
   unless exists?(:app_path)
 abort The download path variable app_path has not been specified
   end
 
   modjk.check_lb_worker_exists
 
   puts 'Everything is fine'
 end
 
 This version works fine except that everything is always fine
 regardless whether the check_lb_worker_exists failed or not
 
 version 2
 ~~~
 
   task :check_lb_worker_exists, :roles = :apacluster, :on_error
 = :abort do
 if exists?(:modjk_loadbalancerworker) then
 run if wget #{wgetparams} 'http://$CAPISTRANO:HOST$/jkserver-
 status?cmd=editfrom=listw=#{modjk_loadbalancerworker}' | grep
 'ERROR'; then false;else true;fi  ;
 end
   end#task
 
 task :preflightcheck, :on_error = :abort do
   unless exists?(:app_path)
 abort The download path variable app_path has not been specified
   end
 
   unless not modjk.check_lb_worker_exists
 
 abort 'horribly broken'
   end
 
   puts 'all looks fine!'
 end
 
 In version two if the check_lb_worker task fails that failure does not
 get handled by the unless abort block in the main preflight check.
 
 Basically I am trying to do the following:
 
 task preflight
   unless run(some command) fail
   unless run_task_check1, fail with nice message
   unless run_task_check2, fail with nice message
 
   if nothing failed then put everything looks ok
 end
 
 I am struggling to get the final everything looks ok message to
 display only if everything really is ok because at the moment it
 displays regardless. I hope this is all making some kind of sense...
 otherwise I will have to try again.
 
 Regards
  


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

[Capistrano] Re: logger vs puts

[Jamis Buck]

I think it's plenty clear. See cap -H, too. If it needs more
clarification, please feel free to start a wiki page for more detailed
examples of how to use each command-line option.

- Jamis

On 2/20/09 11:11 AM, Gerhardus Geldenhuis wrote:
 Thanks
 
 from the help text:
 -v, --verboseBe more verbose. May be given more
 than once
 
 and the source:
 IMPORTANT = 0
 INFO  = 1
 DEBUG = 2
 TRACE = 3
 
 
 can I assume that
   cap -v = 0
   cap -vv = 1
   cap -vvv= 2
   cap - =3
 
 If so I would like to submit a change to the help text to make it more
 clear.
 
 Regars
 
 On Feb 20, 6:05 pm, Jamis Buck ja...@37signals.com wrote:
 Using logger appropriately will let your own log statements display or
 hide based on the -v switch for Capistrano. See capistrano/logger.rb for
 the source.

 - Jamis

 On 2/20/09 11:00 AM, Gerhardus Geldenhuis wrote:

 Hi
 Is it recommended to use logger.info or should I rather be using puts?
 Also is there options other than logger.info and I would appreciate it
 if you could point me to the source code for logger which would
 probably answer my second question.
 Best Regards
  


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

[Capistrano] Re: Error deploying with Capistrano

[Jamis Buck]

Sounds like there's a syntax error one line one of /etc/profile.d/ruby.sh?

- Jamis

On 2/20/09 11:29 PM, Jaryl Sim wrote:
 I forgot to mention that I am deploying from a Vista machine to a
 CentOS box.
 
 On Feb 21, 2:18 pm, Jaryl Sim quantum.crus...@gmail.com wrote:
 Hi, I've never gotten such an error before, but I could not find any
 information regarding this.

 /etc/profile.d/ruby.sh: line 1: export: `/etc/profile': not a valid
 identifier

 I get this when I try to deploy or even deploy:check.

 I am using 2.5.4.
  


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

[Capistrano] Re: retrieving current role name

[Jamis Buck]

There's really no such thing as a current role, since servers can
exist in multiple roles simultaneously, and tasks can be executed on
multiple roles simultaneously. In other words, in general, Capistrano
can't know which role you mean for any particular server. The case where
you're dealing with only a single server, for instance, where the server
is app, db, and web all in one, is the simplest example of what I mean.

- Jamis

On 2/18/09 6:12 PM, Celso Pinto wrote:
 hi all,
 
 to deploy our service I need to generate configuration files for each
 role in capistrano (web.config, api.config, etc. where web/api is the
 role name but content is mostly the same). How can I retrieve the
 current role name to name the configuration file accordingly? I tried
 to look up a variable but couldn't find one, is this something
 possible to do?
 
 regards
 
  


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

[Capistrano] Re: fatal: could not create work tree dir '/home/user/app_name/shared/cached-copy'

[Jamis Buck]

In that case, log into your remote server, and try and do a git clone
manually. If it doesn't work, then you'll need to google and tweak until
it does. If it *does* work, but still doesn't work via capistrano, then
there is an environmental difference between what you get when you log
in via ssh, and what capistrano gets...but let's see what happens when
you do git clone, first.

- Jamis

On 2/17/09 10:23 PM, Vinay Seshadri wrote:
 Jamis,
 
Make sure that, if you are logged into the remote server via ssh, you
 can then ssh from there to the repository server.
 
 How can I do that? 
 My repo is in Github and Ive got a key up there that lets me connect
 from my local machine to the repo and push/pull.
 I went through some server config documentation again and disabled
 PublicKeyAuthentication altogether in the config file itself. 
 Im kind of swimming in a sea of new knowledge and im not sure whats what
 yet and its confusing everything up. 
 Could you give me a few directions I can try going into?
 Im on Slicehost by the way.
 
 Thanks!
 
 
 On Mon, Feb 16, 2009 at 8:40 PM, Jamis Buck ja...@37signals.com
 mailto:ja...@37signals.com wrote:
 
 
 It sounds like your git command on the remote host isn't able to
 authenticate with the repository server. Make sure that, if you are
 logged into the remote server via ssh, you can then ssh from there to
 the repository server.
 
 - Jamis
 
 On 2/16/09 12:11 AM, Ram wrote:
  Andrew,
 
  Thanks for that! That really helped me make some progress. Im still
  stuck though, and Im not able to figure out why.
  After setting up the permissions like you suggested, I ran cap
  deploy:setup, it worked fine and cap deploy:check which asked me for
  my server pwd once and declared that I seem to have my dependencies in
  place.
  But when I run cap deploy, this is the sequence of events
  ***
  DEBUG -- net.ssh.authentication.methods.publickey[]: trying publickey
  (rsa_signature)
  ...
  DEBUG -- net.ssh.authentication.session[]: allowed methods:
  publickey,password
  ERROR -- net.ssh.authentication.session[]: all authorization methods
  failed (tried publickey)
  Then asks for my server pwd
  ...
  DEBUG -- net.ssh.transport.session[]: connection established
  ...
  DEBUG -- net.ssh.transport.algorithms[]: exchanging keys
  ...
  ... beginning authentication of 'user in set_user line'
  ...
  ...trying password
  ...password succeeded
  ...
  [ahref.in http://ahref.in] executing command
  ...
  [ahref.in http://ahref.in :: out] Initialized empty Git
 repository in deploy_to_path/
  shared/cached-copy/.git/
  ...
  INFO -- net.ssh.connection.session[]: channel_data: 0 33b
  [ahref.in http://ahref.in :: out] Permission denied (publickey).
  ...
  [ahref.in http://ahref.in :: out] fatal: The remote end hung up
 unexpectedly
  ...
  command finished
  *** [deploy:update_code] rolling back
  ***
  I have removed the public key in the server and the matching key my
  local machine so that it defaults to password authentication everytime
  I connect to it (I would prefer reverting back to keys though, just
  not using them now to figure out what I need for successful Cap
  deployment).
  And yet, it seems to try to authenticate using public key and fails,
  fatally.
  Can you read more into this debug trace than I can? really appreciate
  the guidance so far. Just hoping you can see me through! :)
 
  @Jamis, thanks for putting that in perspective. Guess thats something
  I have to keep in mind for such similar requirements in the future, IF
  I can get this to work of course! :)
 
  On 14 Feb, 01:52, Andrew Fiedler afiedl...@gmail.com
 mailto:afiedl...@gmail.com wrote:
  Ram,
 
  Yeah, the problem is that /home/username/public_html/ahref.in
 http://ahref.in is
  probably not writable by the user you have on the set user line in
  deploy.rb. When you do a sudo mkdir /home/... you are switching to
  root so there are no permissions errors. I'd change the ownership of
  everything in /home/username/public_html to the username that you
  are deploying as (on the set user line). You can do this by running
  sudo chown user on set user line:user on set user line
  public_html/ -R in your home directory. Note that the user name is
  specified twice with a colon in between. The second one is actually
  the user's group, but on ubuntu users are in their own groups. That
  should make cap deploy work without errors.
 
  -Andrew
 
  On 13 Feb, 10:00, Jamis Buck ja...@37signals.com
 mailto:ja...@37signals.com wrote:
 
  :use_sudo does not cause all commands to use sudo, only

[Capistrano] Re: fatal: could not create work tree dir '/home/user/app_name/shared/cached-copy'

[Jamis Buck]

Ah, it looks like your repository URL is invalid it's trying to
interpret your username as the port number. Note that the public git
clone URL's don't have a username, and the private ones are git@ and not
git://. Make sure you've got the right one.

- Jamis

On 2/17/09 10:45 PM, Vinay Seshadri wrote:
 Jamis,
 
 I tried what you said. Here's the output
 ***
 git clone git://github.com
 http://github.com:git_username/ahref.in.git test_git_clone
 Initialized empty Git repository in
 /home/server_username/test_git_clone/.git/
 fatal: Unable to look up github.com http://github.com (port
 git_username) (Servname not supported for ai_socktype)
 ***
 Yeah the problem definitely lies with server  github communication. Any
 tips?
 Thanks!
 
 
 On Wed, Feb 18, 2009 at 10:57 AM, Jamis Buck ja...@37signals.com
 mailto:ja...@37signals.com wrote:
 
 
 In that case, log into your remote server, and try and do a git clone
 manually. If it doesn't work, then you'll need to google and tweak until
 it does. If it *does* work, but still doesn't work via capistrano, then
 there is an environmental difference between what you get when you log
 in via ssh, and what capistrano gets...but let's see what happens when
 you do git clone, first.
 
 - Jamis
 
 On 2/17/09 10:23 PM, Vinay Seshadri wrote:
  Jamis,
 
 Make sure that, if you are logged into the remote server via ssh, you
  can then ssh from there to the repository server.
 
  How can I do that?
  My repo is in Github and Ive got a key up there that lets me connect
  from my local machine to the repo and push/pull.
  I went through some server config documentation again and disabled
  PublicKeyAuthentication altogether in the config file itself.
  Im kind of swimming in a sea of new knowledge and im not sure
 whats what
  yet and its confusing everything up.
  Could you give me a few directions I can try going into?
  Im on Slicehost by the way.
 
  Thanks!
 
 
  On Mon, Feb 16, 2009 at 8:40 PM, Jamis Buck ja...@37signals.com
 mailto:ja...@37signals.com
  mailto:ja...@37signals.com mailto:ja...@37signals.com wrote:
 
 
  It sounds like your git command on the remote host isn't able to
  authenticate with the repository server. Make sure that, if
 you are
  logged into the remote server via ssh, you can then ssh from
 there to
  the repository server.
 
  - Jamis
 
  On 2/16/09 12:11 AM, Ram wrote:
   Andrew,
  
   Thanks for that! That really helped me make some progress.
 Im still
   stuck though, and Im not able to figure out why.
   After setting up the permissions like you suggested, I ran cap
   deploy:setup, it worked fine and cap deploy:check which
 asked me for
   my server pwd once and declared that I seem to have my
 dependencies in
   place.
   But when I run cap deploy, this is the sequence of events
   ***
   DEBUG -- net.ssh.authentication.methods.publickey[]: trying
 publickey
   (rsa_signature)
   ...
   DEBUG -- net.ssh.authentication.session[]: allowed methods:
   publickey,password
   ERROR -- net.ssh.authentication.session[]: all authorization
 methods
   failed (tried publickey)
   Then asks for my server pwd
   ...
   DEBUG -- net.ssh.transport.session[]: connection established
   ...
   DEBUG -- net.ssh.transport.algorithms[]: exchanging keys
   ...
   ... beginning authentication of 'user in set_user line'
   ...
   ...trying password
   ...password succeeded
   ...
   [ahref.in http://ahref.in http://ahref.in] executing command
   ...
   [ahref.in http://ahref.in http://ahref.in :: out]
 Initialized empty Git
  repository in deploy_to_path/
   shared/cached-copy/.git/
   ...
   INFO -- net.ssh.connection.session[]: channel_data: 0 33b
   [ahref.in http://ahref.in http://ahref.in :: out]
 Permission denied (publickey).
   ...
   [ahref.in http://ahref.in http://ahref.in :: out] fatal:
 The remote end hung up
  unexpectedly
   ...
   command finished
   *** [deploy:update_code] rolling back
   ***
   I have removed the public key in the server and the matching
 key my
   local machine so that it defaults to password authentication
 everytime
   I connect to it (I would prefer reverting back to keys
 though, just
   not using them now to figure out what I need for successful Cap
   deployment).
   And yet, it seems to try

[Capistrano] Re: fatal: could not create work tree dir '/home/user/app_name/shared/cached-copy'

[Jamis Buck]

On 2/17/09 10:57 PM, Vinay Seshadri wrote:
 Whoops! sorry about that.. :D
 Well when I tried MY clone URL with the @, I get the same error cap gave me.
 
 git clone g...@github.com
 mailto:g...@github.com:git_username/ahref.in.git test_git_clone
 Initialized empty Git repository in /home/server_user/test_git_clone/.git/
 Permission denied (publickey).
 fatal: The remote end hung up unexpectedly
 
 So does this mean the environments are the same and if I fix this here,
 it should reflect on Cap as well? 

That's my guess. :)

- Jamis

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

[Capistrano] Re: fatal: could not create work tree dir '/home/user/app_name/shared/cached-copy'

[Jamis Buck]

Yay!

You'll definitely want to investigate that Couldn't find pid file
error. It's Rails saying it couldn't restart your application on the server.

- Jamis

On 2/17/09 11:15 PM, Vinay Seshadri wrote:
 Its alive!! :D
 
 Thanks for that Jamis!
 I SCPed over my git rsa file to the server and put it in the right
 folder and setup an ssh config file to define github as a host and point
 to the right key.
 and then git clone worked.
 and then cap deploy worked too!! :)
 im getting a small message thats of concern in the end though.
 
 ** [out :: ahref.in http://ahref.in] Couldn't find any pid file in
 '/home/server_username/public_html/app/releases/20090218060951/tmp/pids'
 matching 'dispatch.[0-9]*.pid'
  ** [out :: ahref.in http://ahref.in] (also looked for processes
 matching
 /home/server_username/public_html/app/releases/20090218060951/public/dispatch.fcgi)
 
 Is it something I would be well advised to look into?
 Thanks again Jamis!
 
 
 On Wed, Feb 18, 2009 at 11:30 AM, Jamis Buck ja...@37signals.com
 mailto:ja...@37signals.com wrote:
 
 
 On 2/17/09 10:57 PM, Vinay Seshadri wrote:
  Whoops! sorry about that.. :D
  Well when I tried MY clone URL with the @, I get the same error
 cap gave me.
 
  git clone g...@github.com mailto:g...@github.com
  mailto:g...@github.com
 mailto:g...@github.com:git_username/ahref.in.git test_git_clone
  Initialized empty Git repository in
 /home/server_user/test_git_clone/.git/
  Permission denied (publickey).
  fatal: The remote end hung up unexpectedly
 
  So does this mean the environments are the same and if I fix this
 here,
  it should reflect on Cap as well?
 
 That's my guess. :)
 
 - Jamis
 
 
 
 
 
 -- 
 In Sport We Trust !!!
 
  


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

[Capistrano] Re: fatal: could not create work tree dir '/home/user/app_name/shared/cached-copy'

[Jamis Buck]

It sounds like your git command on the remote host isn't able to
authenticate with the repository server. Make sure that, if you are
logged into the remote server via ssh, you can then ssh from there to
the repository server.

- Jamis

On 2/16/09 12:11 AM, Ram wrote:
 Andrew,
 
 Thanks for that! That really helped me make some progress. Im still
 stuck though, and Im not able to figure out why.
 After setting up the permissions like you suggested, I ran cap
 deploy:setup, it worked fine and cap deploy:check which asked me for
 my server pwd once and declared that I seem to have my dependencies in
 place.
 But when I run cap deploy, this is the sequence of events
 ***
 DEBUG -- net.ssh.authentication.methods.publickey[]: trying publickey
 (rsa_signature)
 ...
 DEBUG -- net.ssh.authentication.session[]: allowed methods:
 publickey,password
 ERROR -- net.ssh.authentication.session[]: all authorization methods
 failed (tried publickey)
 Then asks for my server pwd
 ...
 DEBUG -- net.ssh.transport.session[]: connection established
 ...
 DEBUG -- net.ssh.transport.algorithms[]: exchanging keys
 ...
 ... beginning authentication of 'user in set_user line'
 ...
 ...trying password
 ...password succeeded
 ...
 [ahref.in] executing command
 ...
 [ahref.in :: out] Initialized empty Git repository in deploy_to_path/
 shared/cached-copy/.git/
 ...
 INFO -- net.ssh.connection.session[]: channel_data: 0 33b
 [ahref.in :: out] Permission denied (publickey).
 ...
 [ahref.in :: out] fatal: The remote end hung up unexpectedly
 ...
 command finished
 *** [deploy:update_code] rolling back
 ***
 I have removed the public key in the server and the matching key my
 local machine so that it defaults to password authentication everytime
 I connect to it (I would prefer reverting back to keys though, just
 not using them now to figure out what I need for successful Cap
 deployment).
 And yet, it seems to try to authenticate using public key and fails,
 fatally.
 Can you read more into this debug trace than I can? really appreciate
 the guidance so far. Just hoping you can see me through! :)
 
 @Jamis, thanks for putting that in perspective. Guess thats something
 I have to keep in mind for such similar requirements in the future, IF
 I can get this to work of course! :)
 
 On 14 Feb, 01:52, Andrew Fiedler afiedl...@gmail.com wrote:
 Ram,

 Yeah, the problem is that /home/username/public_html/ahref.in is
 probably not writable by the user you have on the set user line in
 deploy.rb. When you do a sudo mkdir /home/... you are switching to
 root so there are no permissions errors. I'd change the ownership of
 everything in /home/username/public_html to the username that you
 are deploying as (on the set user line). You can do this by running
 sudo chown user on set user line:user on set user line
 public_html/ -R in your home directory. Note that the user name is
 specified twice with a colon in between. The second one is actually
 the user's group, but on ubuntu users are in their own groups. That
 should make cap deploy work without errors.

 -Andrew

 On 13 Feb, 10:00, Jamis Buck ja...@37signals.com wrote:

 :use_sudo does not cause all commands to use sudo, only commands like
 deploy:setup and deploy:restart. The primary deploy methods (which copy
 the code to the server and update the symlink, etc.) are never run as sudo.
 I've mentioned this before on the list, but deploy:setup is kind of
 broken: if you use sudo for deploy:setup, then you need to manually fix
 the permissions so the directories are writable. If you don't use sudo,
 you need to fix the permissions on the parent directory first, or the
 setup fails. It's a catch 22, and I don't know of a good, flexible way
 to make it work.
 - Jamis
 On 2/13/09 4:35 AM, Ram wrote:
 Andrew,
 Thanks for you reply. I followed your instructions.
 The ** [out :: delugeventures.com] the_user_you_are_logged_in_as from
 whoami part shows the user on the set_user line correctly.
 I then ssh connected to my server and did mkdir
 folder_that_cap_is_trying_to_create and permissions failed.
 I did sudo mkdir folder_that_cap_is_trying_to_create and entered
 my passwrd and the folder got created.
 Now how do I effect this in my deploy.rb? This is my deploy.rb now.
 **
 set :application, ahref.in
 set :user, server_username
 set :repository,  g...@github.com:gitusername/ahref.in.git
 set :branch, master
 set :port, port_number
 default_run_options[:pty] = true
 set :scm_verbose, true
 ssh_options[:username] = user
 ssh_options[:verbose] = :debug
 set :use_sudo, true
 set :deploy_to, /home/#{user}/public_html/#{application}
 set :scm, :git
 set :deploy_via, :remote_cache
 set :runner, user
 role :app, application
 role :web, application
 role :db,  application, :primary = true
 task :before_update_code, :roles = :app do
 run whoami
 end

[Capistrano] Re: Spaces in Git Repository name..

[Jamis Buck]

On 2/15/09 11:05 PM, sergio_101 wrote:
 i am running a git repository that we hit via ssh.
 
 the problem is that the name of the directory has spaces in it...
 something like:
 
 /mnt/share/work server here/foo/bar
 
 i can't get deploy.rb to see the correct repository when doing:
 
 set_repository, although i have tried it with replacing the spaces
 with \  like:
 
 /mnt/share/work\ server\ here/foo/bar

\  is interpreted by ruby as a space without a slash. If you want a
literal backslash in the string, you need two slashes:

  set :repository, /mnt/share/work\\ server\\ here/foo/bar


 BTW.. this server works on a weird port.. the only way i could get it
 to read the port was to override .ssh/config ..
 
 has this been addressed?

Try

  role :foo, server.address:1234

or

  set :port, 1234

or even

  ssh_options[:port] = 1234

Note that those only work for servers that Capistrano is connecting to;
it won't work for (e.g.) repository servers that git is connecting to.

- Jamis

 
 thanks!
 
  


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

[Capistrano] Re: staggered deploy revisited

[Jamis Buck]

If you want subtasks to use a particular host, you need to set the HOSTS
or HOSTFILTER environment variables. E.g.

  find_servers(...).each do |server|
ENV['HOSTFILTER'] = server.host
sub.task.here
ENV['HOSTFILTER'] = nil
  end

It's extremely ugly and hacky and I don't like it, but there's not
currently another way to do it.

- Jamis

On 2/16/09 5:09 AM, Gerhardus Geldenhuis wrote:
 I have also put the relevant code on http://pastie.org/390600
 
 Regards
  


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

[Capistrano] Re: staggered deploy revisited

[Jamis Buck]

That actually sounds like a lot more than I want Capistrano core to be
involved with. :) By all means, experiment, but what you're suggesting
would be better suited to a third-party plugin than for cap-core. If
anything like this finds its way into capistrano core, it'll just be a
simple way to iterate over a subset of the servers and run tasks on
subsets of that.

- Jamis

On 2/16/09 9:07 AM, Gerhardus Geldenhuis wrote:
 Hi
 No code atm I'm afraid but I will share some ideas/requirements/
 thoughts
 
 We do a state check of the application before removing it from the
 cluster which we can use to compare with after new deployment.
 
 We have a level1 and level2 check for applications. Level1 check
 functional deployment in tomcat, which basically checks the
 application server.
 Level2 actually submits a request to check complete infrastructure
 functionality and parses xml( that is the intend anyway still needs to
 be written)
 
 We want to build in a failure percentage that if you have 10 servers
 and 1 fails after 5 deployments, deployment should continue until in
 reaches a failure percentage, say 20%.
 
 The modjk tasks I have written that act as our loadbalancers actually
 works quite well, once I have extended it a bit more I will gladly
 share the code.
 
 I think sequential deploy will need some generic loadbalancer/cluster
 tasks build-in.
 
 At the moment we use something like the following:
 run wget --quiet -O - --connect-timeout=1 --timeout=1 --tries=1
 'http://$CAPISTRANO:HOST$/jkserver-status?cmd=updatefrom=listw=#
 {modjk_loadbalancergroup}sw=#{current_tomcat}wa=1wf=1wn=#
 {current_tomcat}wr=wc=wd=0' 12/dev/null
 
 maybe a wrapper to allow easier/simplified http interaction with put
 and get might be usefull. (perhaps even some xml manipulation)
 
 Anyway just some random thoughts.
 
 Regards
 
 On Feb 16, 3:44 pm, Jamis Buck ja...@37signals.com wrote:
 On 2/16/09 8:37 AM, Gerhardus Geldenhuis wrote:

 Thanks, I am going to try that right now.
 How do you feel about a sequential extention to capistrano? Any
 thoughts on how it could fit in with the current structure?
 I think that'd be great. Even as something for Capistrano core. I've
 needed, and others have needed it, so I'm sure it'd be useful.

 In general, I'd really love to get away from the ROLES, HOSTS, and
 HOSTFILTER environment variables. I just don't know where to go instead
 of those, and honestly, I haven't spent much time thinking about it.

 If you have any ideas, please feel free to hack on them and see what you
 come up with.

 - Jamis



 Regards
 On Feb 16, 3:16 pm, Jamis Buck ja...@37signals.com wrote:
 If you want subtasks to use a particular host, you need to set the HOSTS
 or HOSTFILTER environment variables. E.g.
   find_servers(...).each do |server|
 ENV['HOSTFILTER'] = server.host
 sub.task.here
 ENV['HOSTFILTER'] = nil
   end
 It's extremely ugly and hacky and I don't like it, but there's not
 currently another way to do it.
 - Jamis
 On 2/16/09 5:09 AM, Gerhardus Geldenhuis wrote:
 I have also put the relevant code onhttp://pastie.org/390600
 Regards
  


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

[Capistrano] Re: help with reaper not restart mongrel with the latest release path

[Jamis Buck]

cap deploy:restart should be restarting your app so that it picks up the
new changes from the most recent deploy. I have no idea why it isn't.
What version of Capistrano are you using? How are you starting the mongrels?

- Jamis

On 2/15/09 1:02 PM, Greg Hauptmann wrote:
 (bump) Maybe I should confirm my basic understanding:
 
 Question 1 - Is the idea that cap deploy should do a restart/refresh
 of your apps servers such as to enable the application changes? (I'm
 assuming yes here).  If not what is the minimum set of cap ... calls
 one would normally make to deploy/update/enable app changes.
 
 Assuming the answer is 'yes', then I'm still stuck on this.  In short
 cap deploy is deploying the new application, trying to restart the
 application via reaper, however re enabling the new changes it is not
 working.  The issue is that whilst the reaper script is called, it
 just seems to restart the existing processes that themselves were tied
 to the old releases directly (as opposed to the newly created release
 current directory).  
 
 Question 2 - How could I get my cap deploy script working right
 through to enabling the updating of my application changes (i.e.
 ensuring when it restarts my mongrel that it is associated with the
 latest releases current directory?   
 
 I've had one suggestion on the rails list to: don't restart reaper,
 but: stop it, set symlink current, cd to current, start it.  However I'd
 prefer to understand from the Capistrano community whether what I have
 should already be working, or how Capistrano uses normally address this.
 
 
 Below is an example of the issue:
 
 *** BEFORE CALLING REAPER 
 [r...@home equity]# ps ax | grep -i ruby
 12857 ?S  0:02 ruby
 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails start
 -d -a 0.0.0.0 -p 3001 -P
 /u/apps/equity/releases/20090209112325/tmp/pids/dispatch.3001.pid -e
 production -c /u/apps/equity/releases/20090209112325 -l
 /u/apps/equity/releases/20090209112325/log/mongrel.log
 13036 pts/1R+ 0:00 grep -i ruby
 [r...@home equity]# cat current/tmp/pids/dispatch.3001.pid 
 12857[r...@home equity]# ls -l
 total 2
 lrwxrwxrwx   1 root root   38 Feb 10 21:10 current -
 /u/apps/equity/releases/20090210111005
 drwxrwxr-x  24 root root 1024 Feb 10 21:10 releases
 drwxrwxr-x   6 root root 1024 Feb  8 20:46 shared
 
 *** CALL REAPER *** 
 [r...@home equity]# /u/apps/equity/current/script/process/reaper
 Restarting 12857
 
 
 *** AFTER CALLING REAPER *** 
 [r...@home equity]# ps ax | grep -i ruby
 13043 ?S  0:02 ruby
 /usr/local/lib/ruby/gems/1.8/gems/mongrel-1.1.5/bin/mongrel_rails start
 -d -a 0.0.0.0 -p 3001 -P
 /u/apps/equity/releases/20090209112325/tmp/pids/dispatch.3001.pid -e
 production -c /u/apps/equity/releases/20090209112325 -l
 /u/apps/equity/releases/20090209112325/log/mongrel.log
 13048 pts/1R+ 0:00 grep -i ruby
 [r...@home equity]# ls -l
 total 2
 lrwxrwxrwx   1 root root   38 Feb 10 21:10 current -
 /u/apps/equity/releases/20090210111005  
 drwxrwxr-x  24 root root 1024 Feb 10 21:10 releases
 drwxrwxr-x   6 root root 1024 Feb  8 20:46 shared
 [r...@home equity]# cat current/tmp/pids/dispatch.3001.pid 
 13043[r...@home equity]# 
 [r...@home equity]# 
 
 
 Regards
 Greg
 
 2008/9/8 greghauptmann greg.hauptm...@gmail.com
 mailto:greg.hauptm...@gmail.com
 
 
 Hi,
 
 I've tracked my cap deploy problems down to the fact that (at least
 with the unix user I've created for use with capistrano) when script/
 process/reaper is run, whilst it restarts the ruby process the
 resulting ruby process itself has a path that reflects the previous
 release path, not the latest one that was put in place as a result
 of capistrano.  Note that the link (created by ln ...etc) is correct,
 so it seems cap deploy did it's job correctly except that the
 reaper call when it restarts the ruby processes does use the latest
 current path.   If I log onto the prod server with this user and
 manually run reaper the same issue occurs.
 
 
 Any ideas?
 
 === standard out ==
 
 Macintosh-2:myequity greg$ cap deploy --debug
  * executing `deploy'
  * executing `deploy:update'
  ** transaction: start
  * executing `deploy:update_code'
  * executing svn checkout -q  -r85
 http://10.1.1.1:3690/svn/myequity/trunk
 /u/apps/myequity/releases/20080908032908
 http://10.1.1.1:3690/svn/myequity/trunk
 /u/apps/myequity/releases/20080908032908  (echo 85  /u/apps/
 myequity/releases/20080908032908/REVISION)
 Preparing to execute command: svn checkout -q  -r85
 http://10.1.1.1:3690/svn/myequity/trunk /u/apps/myequity/releases/
 20080908032908  (echo 85  /u/apps/myequity/releases/20080908032908/
 REVISION)
 Execute ([Yes], No, Abort) ?  |y|  y
servers: [10.1.1.1]
 Password:
[calla...@10.1.1.1 mailto:calla...@10.1.1.1] executing command
command finished
  * executing 

[Capistrano] Re: Execute cap deploy:migrations fails

[Jamis Buck]

Maybe try putting a leading slash before 'home'? e.g.

  set :repository,
#{us...@#{domain}:/home/#{user}/#{domain}/git/#{application}.git

- Jamis

On 2/14/09 6:50 PM, olivierntk wrote:
 Hi there, I am trying to deploy a rails app on dreamhost.
 
 Here is the error message that I get:
 
 fatal: 'home/USER_NAME/DOMAIN_NAME/git/APPLICATION_NAME.git': unable
 to chdir or not a git archive
 fatal: The remote end hung up unexpectedly
 /Users/USER/.gem/ruby/1.8/gems/capistrano-2.5.3/lib/capistrano/recipes/
 deploy/scm/git.rb:224:in `query_revision': Unable to resolve revision
 for 'master' on repository
 
 I am using Capistrano v2.5.3, Rails 2.2 and Git v1.6
 
 I ran deploy:setup and deploy:check successfully. I get the following
 message when I run deploy:check command You appear to have all
 necessary dependencies installed.
 
 Here is my deploy script
 
 default_run_options[:pty] = true
 
 # be sure to change these
 set :user, 'USER_NAME'
 set :domain, 'DOMAIN_NAME'
 set :application, 'APP_NAME'
 
 # the rest should be good
 set :repository,  #{us...@#{domain}:home/#{user}/#{domain}/git/#
 {application}.git
 set :deploy_to, /home/#{user}/#{domain}
 set :deploy_via, :remote_cache
 set :scm, 'git'
 set :branch, 'master'
 set :git_shallow_clone, 1
 set :scm_verbose, true
 set :use_sudo, false
 
 server domain, :app, :web
 role :db, domain, :primary = true
 
 namespace :deploy do
   task :restart do
 run touch #{current_path}/tmp/restart.txt
   end
 end
 
 I am guessing my path to my git repository is incorrect but I checked
 many ... many times and this is my path on my host.
 
 Any help would be greatly appreciated, thank you
 
 Olivier
 
 
  


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

[Capistrano] Re: fatal: could not create work tree dir '/home/user/app_name/shared/cached-copy'

[Jamis Buck]

:use_sudo does not cause all commands to use sudo, only commands like
deploy:setup and deploy:restart. The primary deploy methods (which copy
the code to the server and update the symlink, etc.) are never run as sudo.

I've mentioned this before on the list, but deploy:setup is kind of
broken: if you use sudo for deploy:setup, then you need to manually fix
the permissions so the directories are writable. If you don't use sudo,
you need to fix the permissions on the parent directory first, or the
setup fails. It's a catch 22, and I don't know of a good, flexible way
to make it work.

- Jamis

On 2/13/09 4:35 AM, Ram wrote:
 Andrew,
 
 Thanks for you reply. I followed your instructions.
 The ** [out :: delugeventures.com] the_user_you_are_logged_in_as from
 whoami part shows the user on the set_user line correctly.
 I then ssh connected to my server and did mkdir
 folder_that_cap_is_trying_to_create and permissions failed.
 I did sudo mkdir folder_that_cap_is_trying_to_create and entered
 my passwrd and the folder got created.
 
 Now how do I effect this in my deploy.rb? This is my deploy.rb now.
 **
 set :application, ahref.in
 set :user, server_username
 set :repository,  g...@github.com:gitusername/ahref.in.git
 set :branch, master
 set :port, port_number
 default_run_options[:pty] = true
 set :scm_verbose, true
 
 ssh_options[:username] = user
 ssh_options[:verbose] = :debug
 
 set :use_sudo, true
 set :deploy_to, /home/#{user}/public_html/#{application}
 
 set :scm, :git
 set :deploy_via, :remote_cache
 set :runner, user
 
 role :app, application
 role :web, application
 role :db,  application, :primary = true
 
 task :before_update_code, :roles = :app do
 run whoami
 end
 **
 
 I assumed set :use_sudo, true will use sudo on all commands on the
 server and ask me for the server password. But it still fails.
 
 FYI
 **
 cap deploy o/p
 
 ** [ahref.in :: out] fatal: could not create work tree dir '/home/
 username/public_html/ahref.in/shared/cached-copy'.
 **
 cap deploy:check o/p
 
 The following dependencies failed. Please check them and try again:
 -- You do not have permissions to write to `/home/username/
 public_html/ahref.in'. (server_name)
 -- You do not have permissions to write to `/home/username/
 public_html/ahref.in/releases'. (server_name)
 -- `/home/username/public_html/ahref.in/shared' is not writable
 (server_name)
 **
 
 On 12 Feb, 20:35, Andrew Fiedler afiedl...@gmail.com wrote:
 Ram,

 Are you trying to set up SSH with public/private keys so you don't
 need to type a password? I'm not really sure how to get that working
 but I have capistrano working fine with basic password authentication.
 To help you debug, try adding to your deploy.rb in the
 namespace :deploy do section this:

 task :before_update_code, :roles = :app do
 run whoami
 end

 When you run cap deploy, you should get something like:
 * executing whoami
 servers: [yourserver.com]
 Password: you type password here
 [yourserver.com] executing command
  ** [out :: delugeventures.com] the_user_you_are_logged_in_as from
 whoami

 which should be the user on your set :user line. Then I'd manually
 ssh to your server as that user and try to create the directories
 manually that are failing on your mkdir lines below to debug the
 permissions issues.

 Hope that helps,
 Andrew

 On Feb 12, 5:27 am, Ram yourstruly.vi...@gmail.com wrote:

 OK, ive been making progress with diagnosing this. Posting my updates.
 Hope someone knows the fix.
 First off, im using 2 DIFFERENT ssh public keys for my Slicehost
 server and for the github server.
 And on the Slicehost server, although it does not ask for my password
 when I ssh connect, it DOES require my password for creating
 directories/files.
 My deploy.rb looks like this right now.
 set :application, ahref.in
 set :user, slicehost_server_username_with_write_permissions
 set :repository,  g...@github.com:gitusername/ahref.in.git
 set :branch, master
 set :port, port_number
 default_run_options[:pty] = true
 set :scm_verbose, true
 ssh_options[:username] = user
 ssh_options[:verbose] = :debug
 #set :run_method, :run
 #set :ssh_options, { :forward_agent = true }
 set :use_sudo, false
 set :deploy_to, /home/#{user}/public_html/#{application}
 set :scm, :git
 set :deploy_via, :remote_cache
 #The user that starts the Mongrel(?) instances
 set :runner, user
 role :app, application
 role :web, application
 role :db,  application, :primary = true
 This thread too discusses this problemhttp://ahref.in/33870andI
 realised I had set :use_sudo true when I did cap deploy:setup. I thus
 deleted the files/dirs created by Cap on the server, set :use_sudo
 false and ran cap deploy:setup again but I still get permission denied
 errors.
  ** [out :: ahref.in] mkdir: cannot create directory `/home/user/
 public_html/ahref.in/releases': Permission denied
  ** [out :: ahref.in] 

[Capistrano] Re: Checking for variable existence

[Jamis Buck]

See the #exists?(:var) method:

  http://wiki.capify.org/article/Exists%3F

Hope that helps,

Jamis

On 2/13/09 7:29 AM, Gerhardus Geldenhuis wrote:
 Hi
 I vaguely recall seeing a way to test for empty or non-existent
 variables but could not find it going through my archives.
 
 I want to know if there is a way to test whether a variable has been
 declared/have a value?
 
 Basically I want to write a pre-flight check program that checks that
 users have properly written a config file for a specific environment
 and that the deployment does not come down like a house of cards if
 one variable is missing.
 
 Regards
  


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

[Capistrano] Re: Caching in Capistrano

[Jamis Buck]

$CAPISTRANO:HOST$ is not a variable; it simply gets gsubbed with the
value of the current server name immediately before the command is
handed off to the server. It will not be affected by caching.

Caching only applies to variables set with a block, e.g.

  set(:releases) { capture(ls -xt #{releases_dir}).split }

- Jamis

On 2/13/09 9:38 AM, Gerhardus Geldenhuis wrote:
 Hi
 is any caching that capistrano does only for the duration of a
 running cap command?
 
 I have seen some weird errors which I thought might potentially
 caching related.
 
 Basically I thing this variable was not being set $CAPISTRANO:HOST$
 properly which caused some of the tasks to not work correctly...
 
 Is there a way to control/clear caching?
 
 Regards
  


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

[Capistrano] Re: Capistrano::CLI to deploy from a rails instance gives 'the task `deploy' does not exist'

[Jamis Buck]

So, regarding my last email, are you sure you're not loading (e.g.)
deploy.rb twice?

Second thing to check, make sure you (or a plugin) haven't declared a
method named 'tail' on Object (or otherwise in the global namespace).

- Jamis

On 2/13/09 1:45 PM, Michael Guymon wrote:
 First off, thanks for your help diagnosing my problems thus far Jamis,
 I appreciate it.
 
 My Capistrano::CLI implementation, http://pastie.org/388542 , works
 from rspec and the rails console, but gives the ArgumentError:
 defining a task named `tail' would shadow an existing method with that
 name in rails.
 
 I have tried changing the Capfile and manually adding the Capfile to
 the CLI impl class, but the ArgumentError still persists when run from
 Rails
 
 I guess it is not surprising that the ArgumentError is coming from
 Capistrano::CLI::Execute method load_recipes(config):
   Array(options[:recipes]).each { |recipe| config.load(recipe) }
 throws the ArgumentError
 
 Is there a good way to debug how the tasks are being loaded into the
 Capistrano::Configuration I am building?
 
 thanks,
 Michael
 
 On Feb 13, 1:23 am, Jamis Buck ja...@37signals.com wrote:
 If you're loading Capfile, you don't need to also load deploy.rb (since
 Capfile loads deploy.rb). Perhaps the double load is causing problems?

 - Jamis

 On 2/12/09 11:15 PM, Michael Guymon wrote:

 MMD::Actions::Cap is the class that is calling Capistrano as I described 
 earlier (by including Capistrano::CLI::Execute, Capistrano::CLI::Options 
 and handles steps for execute_requested_actions), the message 
 'MMD::Actions::Cap should run capistrano tasks' is the output from rspec. 
 The Arguments error was a bug, sorry for that. Now the rspec correctly 
 executes a 'cap staging deploy' from an external deploy.rb.
 In Rails tho, I am still getting:
   capistrano/configuration/namespaces.rb:97:in `task': defining a task 
 named `tail' would shadow an existing method with that name (ArgumentError)
 which is being thrown from load_recipes(config) when the external deploy.rb 
 is loaded. The error we indicate a collision of some sort, like the 
 deployer.rb is being loaded twice somehow?
 Here is a slimmed down version of the ruby I am attempt to execute from 
 Rails:http://pastie.org/387991
 thanks,
 Michael
 Jamis Buck wrote:
 On 2/12/09 9:17 PM, Michael Guymon wrote:
 I should have been more clear in the first place, I am actually trying
 to cap deploy another application from Rails, so it is trying to load
 a deploy.rb that is not in the RAILS_ROOT.
 In my rspec spec, if I load the Capfile first, then the external
 deploy.rb, attempt to execute 'staging deploy' in Rails, I get the
 strange error:
 ArgumentError in 'MMD::Actions::Cap should run capistrano tasks'
 wrong # of arguments(1 for 0)
 I have absolutely no idea what MMD::Actions::Cap is. It's definitely not
 Capistrano.
 - Jamis

  


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

[Capistrano] Re: Capistrano::CLI to deploy from a rails instance gives 'the task `deploy' does not exist'

[Jamis Buck]

Immediately before you declare the :tail task, add this:

  p(respond_to?(:tail) ? method(:tail) : no such method `tail')

If you see both no such method `tail' AND a string like #Method:
Object(Kernel)#tail, then you know you're including the file twice. If
you only see the former (no such method) then something weird is going
on and I have no idea what that is. If you see only the latter (the
inspection of a method object), then you can see where the method is
defined as part of the output.

- Jamis


On 2/13/09 3:31 PM, Michael Guymon wrote:
 I am fairly certain deploy.rb is not being loaded twice, I tried
 different combinations in the Capfile, double checked the
 options[:sysconf] (is nil), options[:dotfile] (is nil),  and that
 options[:recipes] only has a reference to the external deploy.rb
 
 The rails instance is pretty basic, the plugins are
 fixture_replacement2, restful_authentication, rspec, and rspec_on_rails.
 Just to be safe, I removed everything but the restful_authentication
 plugin but still got the ArgumentError. I have not defined any tail
 methods nor are there any I can find.
 
 thanks,
 Michael
 
 Jamis Buck wrote:
 So, regarding my last email, are you sure you're not loading (e.g.)
 deploy.rb twice?

 Second thing to check, make sure you (or a plugin) haven't declared a
 method named 'tail' on Object (or otherwise in the global namespace).

 - Jamis

 On 2/13/09 1:45 PM, Michael Guymon wrote:
   
 First off, thanks for your help diagnosing my problems thus far Jamis,
 I appreciate it.

 My Capistrano::CLI implementation, http://pastie.org/388542 , works
 from rspec and the rails console, but gives the ArgumentError:
 defining a task named `tail' would shadow an existing method with that
 name in rails.

 I have tried changing the Capfile and manually adding the Capfile to
 the CLI impl class, but the ArgumentError still persists when run from
 Rails

 I guess it is not surprising that the ArgumentError is coming from
 Capistrano::CLI::Execute method load_recipes(config):
   Array(options[:recipes]).each { |recipe| config.load(recipe) }
 throws the ArgumentError

 Is there a good way to debug how the tasks are being loaded into the
 Capistrano::Configuration I am building?

 thanks,
 Michael

 On Feb 13, 1:23 am, Jamis Buck ja...@37signals.com wrote:
 
 If you're loading Capfile, you don't need to also load deploy.rb (since
 Capfile loads deploy.rb). Perhaps the double load is causing problems?

 - Jamis

 On 2/12/09 11:15 PM, Michael Guymon wrote:

   
 MMD::Actions::Cap is the class that is calling Capistrano as I described 
 earlier (by including Capistrano::CLI::Execute, Capistrano::CLI::Options 
 and handles steps for execute_requested_actions), the message 
 'MMD::Actions::Cap should run capistrano tasks' is the output from rspec. 
 The Arguments error was a bug, sorry for that. Now the rspec correctly 
 executes a 'cap staging deploy' from an external deploy.rb.
 In Rails tho, I am still getting:
   capistrano/configuration/namespaces.rb:97:in `task': defining a task 
 named `tail' would shadow an existing method with that name 
 (ArgumentError)
 which is being thrown from load_recipes(config) when the external 
 deploy.rb is loaded. The error we indicate a collision of some sort, like 
 the deployer.rb is being loaded twice somehow?
 Here is a slimmed down version of the ruby I am attempt to execute from 
 Rails:http://pastie.org/387991
 thanks,
 Michael
 Jamis Buck wrote:
 
 On 2/12/09 9:17 PM, Michael Guymon wrote:
   
 I should have been more clear in the first place, I am actually trying
 to cap deploy another application from Rails, so it is trying to load
 a deploy.rb that is not in the RAILS_ROOT.
 In my rspec spec, if I load the Capfile first, then the external
 deploy.rb, attempt to execute 'staging deploy' in Rails, I get the
 strange error:
 ArgumentError in 'MMD::Actions::Cap should run capistrano tasks'
 wrong # of arguments(1 for 0)
 
 I have absolutely no idea what MMD::Actions::Cap is. It's definitely not
 Capistrano.
 - Jamis
   
   



   
 
 
  


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

[Capistrano] Re: Bug in deploy:migrations ?

[Jamis Buck]

Actually, current_release is correct. If you look at the definition
for current_release:

  _cset(:current_release) { File.join(releases_path, releases.last) }

Which returns the path of the last release in the releases directory:

  _cset(:releases) { capture(ls -xt #{releases_path}).split.reverse }

Now, it could be that you've got a before() hook somewhere that is
calling (directly or indirectly) the releases variable, before the new
release is uploaded. In that case, Capistrano is caching the
pre-new-code value. You could try something like this to make sure
you're getting the right version:

  before(deploy:migrate) { reset! :releases }

Calling reset! forces Capistrano to forget the cached value, so that the
next query for the releases variable will go and fetch the directory
list again from the server.

- Jamis

On 2/12/09 1:32 PM, max wrote:
 Hello
 
 I've just noticed a problem when using deploy:migrations (capistrano
 2.5.4).
 
 It appears that db:migrate is executed from the current release
 directory (previously deployed), instead of the latest release
 directory (current deployment).
 
 So latest migrations shipped with latest release are not executed !
 
 
 The problem occurs in migrate task (called by migrations task).
 
 The line 374 in capistrano-2.5.4/lib/recipes/deploy/deploy.rb :
 when :latest  then current_release
 should be :
 when :latest  then latest_release
 
 So directory of the latest release (just deployed) is used to run
 migrations.
 
 
 I hope I'm not missing something here, and that the google group is
 the right place to propose a patch...
 
 Thanks
 
 ++
 
 Max
 
  


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

[Capistrano] Re: Capistrano::CLI to deploy from a rails instance gives 'the task `deploy' does not exist'

[Jamis Buck]

You need to load #{RAILS_ROOT}/Capfile, not
#{RAILS_ROOT}/config/deploy.rb. Capfile loads both the default deploy
recipes, as well as your app's deploy.rb

- Jamis

On 2/12/09 7:23 PM, Michael Guymon wrote:
 Hello Capistranians,
 
 I am trying to trigger a deploy from a Rails app using
 Capistrano::CLI, similar to what Webistrano is doing. I have a test
 cap file - http://pastie.org/private/kmpdjoufaaw1dz2iwoga that works
 using 'cap staging deploy' but when attempting to run it directly in
 the rails instance, gives the error 'the task `deploy' does not exist'
 
 The execution of 'staging mmd:echo' does work in the rails instance,
 and dumps out the variables, namespaces, and tasks information.
 
 Calling the deploy in rails happens by a lib that includes
 Capistrano::CLI::Execute, Capistrano::CLI::Options,
 setting  the @option
 
 @options = {
 :recipes = ['/absolute/path/to/deploy.rb'],
 :actions = ['staging', 'deployer'], # or ['staging',
 'mmd:echo']
 :vars = [],
 :pre_vars = {},
 :verbose = 3 }
 
 and calling
 
  config = instantiate_configuration
  set_pre_vars(config)
  load_recipes(config)
 
  config.trigger(:load)
  execute_requested_actions(config)
  config.trigger(:exit)
 
 which run successfully for 'staging mmd:echo', but fails for 'staging
 deploy'
 
 Any help would be greatly appreciated.
 
 thanks,
 Michael
 
 Below is the ouput of the mmd:echo task, which is the same for
 manually runing cap and running in rails
 
 -- variables --
   ssh_options: Hash.class
   logger: Capistrano::Logger.class
   default_environment: Hash.class
   default_run_options: Hash.class
   password: cap test password
   username: cap test user
   scm: subversion
   keep_releases: Fixnum.class
   runner: Proc.class
   application: test app
   user: user
   repository: a repo
   scm_username: scm username
   scm_password: scm password
   dbuser: dbuser
   dbpass: dbpass
 ---
 
 -- tasks --
   invoke
   shell
   staging
 
 
 -- namespaces --
   ey_logger
   db
   ferret
   mongrel
   nginx
   slice
   deploy
   sphinx
   acts_as_sphinx
   thinking_sphinx
   ultrasphinx
   bdrb
   memcached
   solr
   monit
   tomcat
   juggernaut
   passenger
   apache
   mmd
 
 
  


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

[Capistrano] Re: Capistrano::CLI to deploy from a rails instance gives 'the task `deploy' does not exist'

[Jamis Buck]

On 2/12/09 9:17 PM, Michael Guymon wrote:
 I should have been more clear in the first place, I am actually trying
 to cap deploy another application from Rails, so it is trying to load
 a deploy.rb that is not in the RAILS_ROOT.
 
 In my rspec spec, if I load the Capfile first, then the external
 deploy.rb, attempt to execute 'staging deploy' in Rails, I get the
 strange error:
 
 ArgumentError in 'MMD::Actions::Cap should run capistrano tasks'
 wrong # of arguments(1 for 0)

I have absolutely no idea what MMD::Actions::Cap is. It's definitely not
Capistrano.

- Jamis

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

[Capistrano] Re: capistrano 2.5.4 fails on ssh [SOLVED]

[Jamis Buck]

I've added a ticket on Net::SSH's ticket tracker, so I'll get to this
when I can (unless someone wants to investigate a patch.)

- Jamis

On 2/12/09 11:08 PM, Erazor wrote:
 Now I did a small research:
 My ssh_config explicitly mentions
 PasswordAuthentication yes
 and no word about PubkeyAuthentication (which leaves the default
 'yes')
 Inserting the line
 PubkeyAuthentication yes
 fixes the problem.
 Removing the line about PasswordAuthentication also works.
 
 The code that checks the allowed authentication methods should use the
 same default values/resolution process as ssh itself to determine the
 allowed methods/sequence to use.
 
 Hope this helps.
 Stefan
 
 On 11 Feb., 07:45, Jamis Buck ja...@37signals.com wrote:
 Weird... I have no idea why 2.5.4 isn't trying publickey by default for
 you. Capistrano should always be trying publickey first, then password.
 There's something fishy there... I know publickey is picked up by
 default in cap 2.5.4, because it's what I use, and I haven't had any
 trouble with it.

 At any rate, I'm glad you found a workaround. I just wish I understood
 why it was necessary.

 - Jamis

 On 2/10/09 11:32 PM, Erazor wrote:

 Took a look at the outputs myself and found out the following:
 With above options 2.5.3 tries publickey and succeeds: (relevant lines
 only)
 D, [2009-02-11T06:57:44.873174 #4575] DEBUG --
 net.ssh.authentication.session[166972cc]: beginning authentication
 of `rails'
 D, [2009-02-11T06:57:44.915232 #4575] DEBUG --
 net.ssh.authentication.session[166972cc]: trying publickey
 D, [2009-02-11T06:57:44.915384 #4575] DEBUG --
 net.ssh.authentication.agent[16695ef4]: connecting to ssh-agent
 D, [2009-02-11T06:57:44.916451 #4575] DEBUG --
 net.ssh.authentication.methods.publickey[16695f6c]: trying
 publickey (###)
 D, [2009-02-11T06:57:44.921130 #4575] DEBUG --
 net.ssh.authentication.methods.publickey[16695f6c]: publickey
 succeeded (###)
 2.5.4 tries only password authentification and fails, cause I forbid
 PAM in sshd-config:
 D, [2009-02-11T06:57:36.374398 #4571] DEBUG --
 net.ssh.authentication.session[166964a8]: beginning authentication
 of `rails'
 D, [2009-02-11T06:57:36.416597 #4571] DEBUG --
 net.ssh.authentication.session[166964a8]: trying password
 E, [2009-02-11T06:57:36.416709 #4571] ERROR --
 net.ssh.authentication.session[166964a8]: all authorization
 methods failed (tried password)
 adding the following line to deploy.rb fixes this:
 ssh_options[:auth_methods] = publickey
 Thanks for pointing me to the debug option.
 Stefan
  


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

[Capistrano] Re: Capistrano::CLI to deploy from a rails instance gives 'the task `deploy' does not exist'

[Jamis Buck]

If you're loading Capfile, you don't need to also load deploy.rb (since
Capfile loads deploy.rb). Perhaps the double load is causing problems?

- Jamis

On 2/12/09 11:15 PM, Michael Guymon wrote:
 MMD::Actions::Cap is the class that is calling Capistrano as I described 
 earlier (by including Capistrano::CLI::Execute, Capistrano::CLI::Options and 
 handles steps for execute_requested_actions), the message 'MMD::Actions::Cap 
 should run capistrano tasks' is the output from rspec. The Arguments error 
 was a bug, sorry for that. Now the rspec correctly executes a 'cap staging 
 deploy' from an external deploy.rb.
 
 In Rails tho, I am still getting:
 
   capistrano/configuration/namespaces.rb:97:in `task': defining a task named 
 `tail' would shadow an existing method with that name (ArgumentError)
 
 which is being thrown from load_recipes(config) when the external deploy.rb 
 is loaded. The error we indicate a collision of some sort, like the 
 deployer.rb is being loaded twice somehow?
 
 Here is a slimmed down version of the ruby I am attempt to execute from 
 Rails: http://pastie.org/387991
 
 thanks,
 Michael
 
 Jamis Buck wrote:
 On 2/12/09 9:17 PM, Michael Guymon wrote:
   
 I should have been more clear in the first place, I am actually trying
 to cap deploy another application from Rails, so it is trying to load
 a deploy.rb that is not in the RAILS_ROOT.

 In my rspec spec, if I load the Capfile first, then the external
 deploy.rb, attempt to execute 'staging deploy' in Rails, I get the
 strange error:

 ArgumentError in 'MMD::Actions::Cap should run capistrano tasks'
 wrong # of arguments(1 for 0)
 

 I have absolutely no idea what MMD::Actions::Cap is. It's definitely not
 Capistrano.

 - Jamis


   
 
 
  


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

[Capistrano] Re: Error after installing capistrano

[Jamis Buck]

On 2/11/09 1:18 PM, SteveS wrote:
 set :db,  domain, :primary = true

I believe you mean to use role() here, and not set().

  role :db, domain, :primary = true

- Jamis

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

[Capistrano] Re: capistrano 2.5.4 authentication failure works with 2.5.3

[Jamis Buck]

This looks suspicious to me:

D, [2009-02-11T16:00:41.092822 #50594] DEBUG --
net.ssh.authentication.session[aa9baa]: trying pass
connection failed for: sage.example.com (NameError: uninitialized
constant Net::SSH::Authentication::Methods::Pass)

Can you pastie your complete deploy.rb? I suspect you've got something
in there that shouldn't be.

- Jamis

On 2/11/09 3:21 PM, eabolden wrote:
 When I upgraded to 2.5.4, capistrano (2.5.4, 2.5.3, 2.0.0) my deploy
 fails, it works correctly with 2.5.3.
 
 I want to be prompted for my username and password when I type
 $ cap deploy_keeps_to_edps
 
 with Capistrano 2.5.3 and 2.5.4 I use the following to prompt for
 username:
 
 ## # set the ssh username
 set (:user) do
   Capistrano::CLI.ui.ask Enter ssh username:
 end
 
 with Capistrano 2.5.3, I will later be prompted for my password, with
 Capistrano 2.5.4, I never get prompted for my password, and the deploy
 fails.
 
 I then tried:
 $ cap -p deploy_keeps_to_edps
 This did prompt me for my password, then username, but it still
 failed. I think my password was ignored?
 
 I do have a ~/.ssh/config file with user information, but I don't want
 to use that in this case, and the user for this deploy, is not in the
 file.
 
 a transcript follows, I hope someone has an idea.
 
 Thanks,
 
 Eric
 
 
 ~/Documents/git_svn_projects/keeps(master) $ cap deploy_keeps_to_sage
   * executing `deploy_keeps_to_sage'
   * executing mv /Library/WebServer/webapps/keeps /Library/WebServer/
 webapps/keeps_20090211_160352
 servers: [sage.example.com]
 Enter ssh username:
 support
 connection failed for: sage.example.com
 (Net::SSH::AuthenticationFailed: support)
 ~/Documents/git_svn_projects/keeps(master) $ cap -p
 deploy_keeps_to_sage
 Password:
   * executing `deploy_keeps_to_sage'
   * executing mv /Library/WebServer/webapps/keeps /Library/WebServer/
 webapps/keeps_20090211_160412
 servers: [sage.example.com]
 Enter ssh username:
 support
 connection failed for: sage.example.com
 (Net::SSH::AuthenticationFailed: support)
 ~/Documents/git_svn_projects/keeps(master) $
 
 
 ssh_options[:verbose] = :debug
 
 ~/Documents/git_svn_projects/keeps(master) $ cap -p
 deploy_keeps_to_sage
 Password:
   * executing `deploy_keeps_to_sage'
   * executing mv /Library/WebServer/webapps/keeps /Library/WebServer/
 webapps/keeps_20090211_160018
 servers: [sage.example.com]
 Enter ssh username:
 support
 D, [2009-02-11T16:00:41.006834 #50594] DEBUG --
 net.ssh.transport.session[ab50cc]: establishing connection to
 sage.example.com:22
 D, [2009-02-11T16:00:41.008464 #50594] DEBUG --
 net.ssh.transport.session[ab50cc]: connection established
 I, [2009-02-11T16:00:41.008641 #50594]  INFO --
 net.ssh.transport.server_version[ab4da2]: negotiating protocol version
 D, [2009-02-11T16:00:41.024190 #50594] DEBUG --
 net.ssh.transport.server_version[ab4da2]: remote is `SSH-2.0-
 OpenSSH_5.1'
 D, [2009-02-11T16:00:41.024347 #50594] DEBUG --
 net.ssh.transport.server_version[ab4da2]: local is `SSH-2.0-Ruby/
 Net::SSH_2.0.10 universal-darwin9.0'
 D, [2009-02-11T16:00:41.027752 #50594] DEBUG -- tcpsocket[ab4f1e]:
 read 784 bytes
 D, [2009-02-11T16:00:41.027935 #50594] DEBUG -- tcpsocket[ab4f1e]:
 received packet nr 0 type 20 len 780
 I, [2009-02-11T16:00:41.028082 #50594]  INFO --
 net.ssh.transport.algorithms[ab4ae6]: got KEXINIT from server
 I, [2009-02-11T16:00:41.028350 #50594]  INFO --
 net.ssh.transport.algorithms[ab4ae6]: sending KEXINIT
 D, [2009-02-11T16:00:41.028647 #50594] DEBUG -- tcpsocket[ab4f1e]:
 queueing packet nr 0 type 20 len 508
 D, [2009-02-11T16:00:41.028855 #50594] DEBUG -- tcpsocket[ab4f1e]:
 sent 512 bytes
 I, [2009-02-11T16:00:41.029094 #50594]  INFO --
 net.ssh.transport.algorithms[ab4ae6]: negotiating algorithms
 D, [2009-02-11T16:00:41.029518 #50594] DEBUG --
 net.ssh.transport.algorithms[ab4ae6]: negotiated:
 * kex: diffie-hellman-group-exchange-sha1
 * host_key: ssh-dss
 * encryption_server: aes128-cbc
 * encryption_client: aes128-cbc
 * hmac_client: hmac-sha1
 * hmac_server: hmac-sha1
 * compression_client: none
 * compression_server: none
 * language_client:
 * language_server:
 D, [2009-02-11T16:00:41.029613 #50594] DEBUG --
 net.ssh.transport.algorithms[ab4ae6]: exchanging keys
 D, [2009-02-11T16:00:41.029897 #50594] DEBUG -- tcpsocket[ab4f1e]:
 queueing packet nr 1 type 34 len 20
 D, [2009-02-11T16:00:41.030055 #50594] DEBUG -- tcpsocket[ab4f1e]:
 sent 24 bytes
 D, [2009-02-11T16:00:41.035828 #50594] DEBUG -- tcpsocket[ab4f1e]:
 read 152 bytes
 D, [2009-02-11T16:00:41.036168 #50594] DEBUG -- tcpsocket[ab4f1e]:
 received packet nr 1 type 31 len 148
 D, [2009-02-11T16:00:41.054694 #50594] DEBUG -- tcpsocket[ab4f1e]:
 queueing packet nr 2 type 32 len 140
 D, [2009-02-11T16:00:41.054862 #50594] DEBUG -- tcpsocket[ab4f1e]:
 sent 144 bytes
 D, [2009-02-11T16:00:41.067351 #50594] DEBUG -- tcpsocket[ab4f1e]:
 read 656 bytes
 D, [2009-02-11T16:00:41.067713 #50594] DEBUG -- tcpsocket[ab4f1e]:
 received packet nr 2 type 33 len 

[Capistrano] Re: capistrano 2.5.4 authentication failure works with 2.5.3

[Jamis Buck]

I suspect that your deploy.rb isn't the whole picture. Have you added
anything to the Capfile? Do you have a ~/.caprc file with anything in it?

- Jamis

On 2/11/09 4:23 PM, Eric Bolden wrote:
 Jamis Thanks for the blazingly quick reply!
 
 Here is my deploy file:
 
 set :application, keeps
 set :repository,  https://svn.example.com/svn/web/dev/rails/rails_2.2/keeps 
 
 
 # set :deploy_to, /Library/WebServer/webapps/#{application}
 #  deploy test_server
 role :sage, sage.example.com
 
 #  the name generated for use when the old application 'ictr_member'  
 gets backed up.
 application_timestamp_backup_command = mv /Library/WebServer/webapps/ 
 keeps /Library/WebServer/webapps/keeps_ + Time.now.strftime(%Y%m%d_%H 
 %M%S)
 subversion_local_repository_update_command = svn update /Users/ 
 support/Documents/svnbiostat/web/dev/rails/rails_2.2/keeps
 copy_application_to_webapp_directory_command = svn export /Users/ 
 support/Documents/svnbiostat/web/dev/rails/rails_2.2/keeps /Library/ 
 WebServer/webapps/keeps
 passenger_reload_application_trigger_file_command = touch /Library/ 
 WebServer/webapps/keeps/tmp/restart.txt
 
 
 ## # set the ssh username
 set (:user) do
Capistrano::CLI.ui.ask Enter ssh username:
 end
 
 
 #ssh_options[:verbose] = :debug
 
 #  deploy keeps to test deploy server, sage.
 desc deploy TESTING keeps to sage - includes backup of app first.
 task :deploy_keeps_to_sage, :roles = :sage do
 
#  Backup the current application with a timestamp
run application_timestamp_backup_command
 
#  update to current version of application
run subversion_local_repository_update_command
 
#  deploy non-versioned copy of current application to current web  
 application directory
run copy_application_to_webapp_directory_command
 
#  restart passenger to make it reload the application you are  
 updating
run passenger_reload_application_trigger_file_command
 end
 
 
 On Feb 11, 2009, at 4:30 PM, Jamis Buck wrote:
 
 This looks suspicious to me:

 D, [2009-02-11T16:00:41.092822 #50594] DEBUG --
 net.ssh.authentication.session[aa9baa]: trying pass
 connection failed for: sage.example.com (NameError: uninitialized
 constant Net::SSH::Authentication::Methods::Pass)

 Can you pastie your complete deploy.rb? I suspect you've got something
 in there that shouldn't be.

 - Jamis

 On 2/11/09 3:21 PM, eabolden wrote:
 When I upgraded to 2.5.4, capistrano (2.5.4, 2.5.3, 2.0.0) my deploy
 fails, it works correctly with 2.5.3.

 I want to be prompted for my username and password when I type
 $ cap deploy_keeps_to_edps

 with Capistrano 2.5.3 and 2.5.4 I use the following to prompt for
 username:

 ## # set the ssh username
 set (:user) do
  Capistrano::CLI.ui.ask Enter ssh username:
 end

 with Capistrano 2.5.3, I will later be prompted for my password, with
 Capistrano 2.5.4, I never get prompted for my password, and the  
 deploy
 fails.

 I then tried:
 $ cap -p deploy_keeps_to_edps
 This did prompt me for my password, then username, but it still
 failed. I think my password was ignored?

 I do have a ~/.ssh/config file with user information, but I don't  
 want
 to use that in this case, and the user for this deploy, is not in the
 file.

 a transcript follows, I hope someone has an idea.

 Thanks,

 Eric


 ~/Documents/git_svn_projects/keeps(master) $ cap deploy_keeps_to_sage
  * executing `deploy_keeps_to_sage'
  * executing mv /Library/WebServer/webapps/keeps /Library/WebServer/
 webapps/keeps_20090211_160352
servers: [sage.example.com]
 Enter ssh username:
 support
 connection failed for: sage.example.com
 (Net::SSH::AuthenticationFailed: support)
 ~/Documents/git_svn_projects/keeps(master) $ cap -p
 deploy_keeps_to_sage
 Password:
  * executing `deploy_keeps_to_sage'
  * executing mv /Library/WebServer/webapps/keeps /Library/WebServer/
 webapps/keeps_20090211_160412
servers: [sage.example.com]
 Enter ssh username:
 support
 connection failed for: sage.example.com
 (Net::SSH::AuthenticationFailed: support)
 ~/Documents/git_svn_projects/keeps(master) $


 ssh_options[:verbose] = :debug

 ~/Documents/git_svn_projects/keeps(master) $ cap -p
 deploy_keeps_to_sage
 Password:
  * executing `deploy_keeps_to_sage'
  * executing mv /Library/WebServer/webapps/keeps /Library/WebServer/
 webapps/keeps_20090211_160018
servers: [sage.example.com]
 Enter ssh username:
 support
 D, [2009-02-11T16:00:41.006834 #50594] DEBUG --
 net.ssh.transport.session[ab50cc]: establishing connection to
 sage.example.com:22
 D, [2009-02-11T16:00:41.008464 #50594] DEBUG --
 net.ssh.transport.session[ab50cc]: connection established
 I, [2009-02-11T16:00:41.008641 #50594]  INFO --
 net.ssh.transport.server_version[ab4da2]: negotiating protocol  
 version
 D, [2009-02-11T16:00:41.024190 #50594] DEBUG --
 net.ssh.transport.server_version[ab4da2]: remote is `SSH-2.0-
 OpenSSH_5.1'
 D, [2009-02-11T16:00:41.024347 #50594] DEBUG --
 net.ssh.transport.server_version[ab4da2]: local is `SSH-2.0-Ruby/
 Net

[Capistrano] Re: capistrano 2.5.4 authentication failure works with 2.5.3

[Jamis Buck]

Ah! Yeah, currently, if you specify PasswordAuthentication or
PubkeyAuthentication in your ssh_config file, Net::SSH will use those
exclusively (and not try any other authentication methods).

- Jamis

On 2/11/09 9:42 PM, Eric Bolden wrote:
 It works now. Thanks for your help.
 
 It turned out to be some uncommented lines in my ssh_config file.
 
 if I uncomment any of the three following lines, I see the failure:
 ##   PasswordAuthentication yes
 ##   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
 cbc,arcfour,aes192-cbc,aes256-cbc
 ##   MACs hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160
 
 
 if I uncomment ##   PasswordAuthentication yes, then I get this error.
 
 D, [2009-02-11T22:35:00.894215 #2626] DEBUG --  
 net.ssh.authentication.session[8fa872]: beginning authentication of  
 `support'
 D, [2009-02-11T22:35:00.894466 #2626] DEBUG -- tcpsocket[ab5ee6]:  
 queueing packet nr 4 type 5 len 28
 D, [2009-02-11T22:35:00.894622 #2626] DEBUG -- tcpsocket[ab5ee6]: sent  
 52 bytes
 D, [2009-02-11T22:35:01.090596 #2626] DEBUG -- tcpsocket[ab5ee6]: read  
 52 bytes
 D, [2009-02-11T22:35:01.091079 #2626] DEBUG -- tcpsocket[ab5ee6]:  
 received packet nr 4 type 6 len 28
 D, [2009-02-11T22:35:01.091337 #2626] DEBUG --  
 net.ssh.authentication.session[8fa872]: trying password
 E, [2009-02-11T22:35:01.091525 #2626] ERROR --  
 net.ssh.authentication.session[8fa872]: all authorization methods  
 failed (tried password)
 connection failed for: sage.example.com  
 (Net::SSH::AuthenticationFailed: support)
 
 if I uncomment ##   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
 cbc,arcfour,aes192-cbc,aes256-cbc, then I get this error.
 
 D, [2009-02-11T22:37:38.054608 #2669] DEBUG --  
 net.ssh.transport.session[ab609e]: establishing connection to  
 sage.example.com:22
 D, [2009-02-11T22:37:38.154510 #2669] DEBUG --  
 net.ssh.transport.session[ab609e]: connection established
 I, [2009-02-11T22:37:38.154731 #2669]  INFO --  
 net.ssh.transport.server_version[ab5d74]: negotiating protocol version
 D, [2009-02-11T22:37:38.259771 #2669] DEBUG --  
 net.ssh.transport.server_version[ab5d74]: remote is `SSH-2.0- 
 OpenSSH_5.1'
 D, [2009-02-11T22:37:38.259942 #2669] DEBUG --  
 net.ssh.transport.server_version[ab5d74]: local is `SSH-2.0-Ruby/ 
 Net::SSH_2.0.10 universal-darwin9.0'
 connection failed for: sage.example.com (NotImplementedError:  
 unsupported encryption algorithm: `arcfour')
 
 if I uncomment ##   MACs hmac-md5,hmac-sha1,umac...@openssh.com,hmac- 
 ripemd160, then I get this error.
 
 D, [2009-02-11T22:39:00.540102 #2699] DEBUG --  
 net.ssh.transport.session[ab6062]: establishing connection to  
 sage.example.com:22
 D, [2009-02-11T22:39:00.636295 #2699] DEBUG --  
 net.ssh.transport.session[ab6062]: connection established
 I, [2009-02-11T22:39:00.636551 #2699]  INFO --  
 net.ssh.transport.server_version[ab5d38]: negotiating protocol version
 D, [2009-02-11T22:39:00.742946 #2699] DEBUG --  
 net.ssh.transport.server_version[ab5d38]: remote is `SSH-2.0- 
 OpenSSH_5.1'
 D, [2009-02-11T22:39:00.743155 #2699] DEBUG --  
 net.ssh.transport.server_version[ab5d38]: local is `SSH-2.0-Ruby/ 
 Net::SSH_2.0.10 universal-darwin9.0'
 connection failed for: sage.example.com (NotImplementedError:  
 unsupported hmac algorithm: `umac...@openssh.com')
 
 
 
 my current working version of the ssh_config file is listed below.
 
 
 $ cat /etc/ssh_config
   Host *
 ForwardAgent no
 ForwardX11 yes
 ForwardX11Trusted yes
 RhostsRSAAuthentication no
 RSAAuthentication yes
 ##   PasswordAuthentication yes
 HostbasedAuthentication no
 #   GSSAPIAuthentication yes
 #   GSSAPIDelegateCredentials no
 #   GSSAPIKeyExchange yes
 #   GSSAPITrustDNS no
 BatchMode no
 CheckHostIP yes
 AddressFamily any
 ConnectTimeout 0
 StrictHostKeyChecking ask
 IdentityFile ~/.ssh/identity
 IdentityFile ~/.ssh/id_rsa
 IdentityFile ~/.ssh/id_dsa
 Port 22
 Protocol 2
 Cipher 3des-cbc
 ##   Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128- 
 cbc,arcfour,aes192-cbc,aes256-cbc
 ##   MACs hmac-md5,hmac-sha1,umac...@openssh.com,hmac-ripemd160
 EscapeChar ~
 #   Tunnel no
 #   TunnelDevice any:any
 #   PermitLocalCommand no
 
 On Feb 11, 2009, at 5:32 PM, Jamis Buck wrote:
 
 I suspect that your deploy.rb isn't the whole picture. Have you added
 anything to the Capfile? Do you have a ~/.caprc file with anything  
 in it?

 - Jamis

 On 2/11/09 4:23 PM, Eric Bolden wrote:
 Jamis Thanks for the blazingly quick reply!


 
 
  


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

[Capistrano] Re: capistrano 2.5.4 fails on ssh

[Jamis Buck]

One of the things that changed in 2.5.4 was that the User option in
.ssh/config was finally honored correctly; there may have been a bug
introduced as part of that fix, but authentication works fine for me
with 2.5.4.

Could you try adding the following option to your deploy.rb:

  ssh_options[:verbose] = :debug

Then run against both 2.5.3 and 2.5.4, redirecting the output to a
different file for each. If you would then email me (jamis at 37signals
d com) those files (after sanitizing any sensitive data from the files,
like user names, host names, passwords, etc.), I could take a look at
them and see if anything suspicious jumps out at me.

- Jamis

On 2/9/09 10:36 PM, Erazor wrote:
 Hello, I have a setup where cap 2.5.3 works perfectly for a long time
 now, but 2.5.4 fails to run.
 
 First, the interesting part of my deploy.rb:
 
 set :application, 'mct'
 set :repository, 'svn+ssh://bbzws162/var/svn/rails-mct/trunk'
 set(:deploy_to) { /var/www/applications/#{application} }
 set :user, 'rails'
 set :scm, :subversion
 set :deploy_via, :export
 set :runner, 'root'
 default_run_options[:pty] = true
 role :web, 'bbzlin14', :primary = true
 role :app, 'bbzlin14', :primary = true
 role :db, 'bbzlin14', :primary = true
 ssh_options[:keys] = #{ENV['HOME']}/.ssh/id_dsa
 
 Executed with 2.5.3 this works:
 
 * executing deploy'
 * executing deploy:update' ** transaction: start
 * executing deploy:update_code' executing locally: svn info svn
 +ssh://bbzws162/var/svn/rails-mct/trunk -rHEAD
 * executing svn export -q -r372 svn+ssh://bbzws162/var/svn/rails-
 mct/trunk /var/www/applications/mct/releases/20090209062621  (echo
 372  /var/www/applications/mct/releases/20090209062621/REVISION)
 servers: [bbzlin14] [bbzlin14] executing command command finished
 
 But with 2.5.4 it fails:
 
 * executing deploy'
 * executing deploy:update' ** transaction: start
 * executing deploy:update_code' executing locally: svn info svn
 +ssh://bbzws162/var/svn/rails-mct/trunk -rHEAD
 * executing svn export -q -r373 svn+ssh://bbzws162/var/svn/rails-
 mct/trunk /var/www/applications/mct/releases/20090209063436  (echo
 373  /var/www/applications/mct/releases/20090209063436/REVISION)
 servers: [bbzlin14] *** [deploy:update_code] rolling back
 * executing rm -rf /var/www/applications/mct/releases/
 20090209063436; true servers: [bbzlin14] ** [deploy:update_code]
 exception while rolling back: Capistrano::ConnectionError, connection
 failed for: bbzlin14 (Net::SSH::AuthenticationFailed: rails)
 connection failed for: bbzlin14 (Net::SSH::AuthenticationFailed:
 rails)
 
 Tell me what i need to provide for further help in resolving this.
 
  


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

[Capistrano] Re: Trouble starting a script/runner without waiting for it

[Jamis Buck]

Anibal,

What is the behavior when you try with nohup? Using nohup is the
recommended way to fire off long-running processes with Capistrano:

  run nohup #{current_path}/script/runner SomeService.run 

Also, if the invocation itself has any complexity at all, you might be
better off encapsulating it in your own script, first, and invoking it
that way:

  run nohup #{current_path}/script/my_script 

- Jamis

On 2/9/09 4:45 PM, Aníbal Rojas wrote:
 Hello,
 
As part of my deployment process I want to start a script/runner
 and I don't want to wait for it to end its execution, as it is a
 pretty long process , off course with a Capistrano task.
 
It works, but it never returns from the run  ... script/runner ...
  invocation
 
Breaking the execution of the Capistrano task with Ctrl-C doesn't
 affect the running process, but it is kind of ugly and I want to
 properly finish everything and call hooks, etc.
 
I am not sure about the fine details of the ssh stuff under the
 hood, and I tried using nohup ... , redirecting the stdin and error,
 and nothing made any difference run  ... script/runner ...  blocks
 without returning
 
   Thanks in advance,
 
  
 Aníbal Rojas
 http://hasmanydevelopers.com (work)
 http://rubycorner.com(community)
 http://anibal.rojas.com.ve  (personal)
 
  


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

[Capistrano] Re: Changing remote user's password

[Jamis Buck]

Here's how I've done that in the past:

  run passwd, :pty = true do |ch, stream, data|
if data =~ /Enter new UNIX password:/
  ch.send_data(Capistrano::CLI.password_prompt(
New root password: ) + \n)
elsif data =~ /Retype new UNIX password:/
  ch.send_data(Capistrano::CLI.password_prompt(
Retype new root password: ) + \n)
else
  Capistrano::Configuration.default_io_proc.call(ch, stream, data)
end
  end

Here's a pastie, if the above didn't get formatted well by your email
client:

  http://pastie.org/385103

- Jamis

On 2/10/09 9:39 AM, sant0sk1 wrote:
 A use case:
 
 There are n debian servers being managed on a LAN and the admin wants
 to synchronize their root user's password using Capistrano. The user
 wants to execute something like: cap ROLES=debian set_root_pw. The
 user is then prompted for the new password one time (with
 confirmation) and the password is changed on all n machines.
 
 I'd like to implement something like this but I can't seem to find a
 non-interactive 'passwd' method. Are there other ways to get this
 done? One thought is to generate the hashed password locally and have
 Cap edit the /etc/shadow files of all the remote hosts. Not sure if
 that would work with salting and whatnot. Any other ideas of how to
 get this done?
 
 Thanks guys. Love Cap!
  


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

[Capistrano] Re: Changing remote user's password

[Jamis Buck]

Just capture it and reuse:

password = nil
confirmation = nil

run passwd, :pty = true do |ch, stream, data|
  if data =~ /Enter new UNIX password:/
password ||= Capistrano::CLI.password_prompt(
  New root password: )
ch.send_data(password + \n)
  elsif data =~ /Retype new UNIX password:/
confirmation ||= Capistrano::CLI.password_prompt(
  Retype new root password: )
ch.send_data(confirmation + \n)
  else
Capistrano::Configuration.default_io_proc.call(ch, stream, data)
  end
end

I'll leave as an exercise for the reader how to handle the case where
the password and the confirmation do not match, and passwd tries to
reprompt.

- Jamis

On 2/10/09 9:56 AM, Jerod Santo wrote:
 Jamis-
 
 That is a nice way to handle the required input by passwd, but it
 doesn't quite get me where I want to go, because I will have to type the
 new password n times. Is there a way to prompt once and capture, then
 just send the captured output through the data channel for subsequent
 requests?
 
 
 Jerod Santo
 http://jerodsanto.net
 
 
 On Tue, Feb 10, 2009 at 10:43 AM, Jamis Buck ja...@37signals.com
 mailto:ja...@37signals.com wrote:
 
 
 Here's how I've done that in the past:
 
  run passwd, :pty = true do |ch, stream, data|
if data =~ /Enter new UNIX password:/
  ch.send_data(Capistrano::CLI.password_prompt(
New root password: ) + \n)
elsif data =~ /Retype new UNIX password:/
  ch.send_data(Capistrano::CLI.password_prompt(
Retype new root password: ) + \n)
else
  Capistrano::Configuration.default_io_proc.call(ch, stream, data)
end
  end
 
 Here's a pastie, if the above didn't get formatted well by your email
 client:
 
  http://pastie.org/385103
 
 - Jamis
 
 On 2/10/09 9:39 AM, sant0sk1 wrote:
  A use case:
 
  There are n debian servers being managed on a LAN and the admin wants
  to synchronize their root user's password using Capistrano. The user
  wants to execute something like: cap ROLES=debian set_root_pw. The
  user is then prompted for the new password one time (with
  confirmation) and the password is changed on all n machines.
 
  I'd like to implement something like this but I can't seem to find a
  non-interactive 'passwd' method. Are there other ways to get this
  done? One thought is to generate the hashed password locally and have
  Cap edit the /etc/shadow files of all the remote hosts. Not sure if
  that would work with salting and whatnot. Any other ideas of how to
  get this done?
 
  Thanks guys. Love Cap!
  
 
 
 
 
 
  


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

[Capistrano] Re: capistrano 2.5.4 fails on ssh [SOLVED]

[Jamis Buck]

Weird... I have no idea why 2.5.4 isn't trying publickey by default for
you. Capistrano should always be trying publickey first, then password.
There's something fishy there... I know publickey is picked up by
default in cap 2.5.4, because it's what I use, and I haven't had any
trouble with it.

At any rate, I'm glad you found a workaround. I just wish I understood
why it was necessary.

- Jamis

On 2/10/09 11:32 PM, Erazor wrote:
 Took a look at the outputs myself and found out the following:
 With above options 2.5.3 tries publickey and succeeds: (relevant lines
 only)
 D, [2009-02-11T06:57:44.873174 #4575] DEBUG --
 net.ssh.authentication.session[166972cc]: beginning authentication
 of `rails'
 D, [2009-02-11T06:57:44.915232 #4575] DEBUG --
 net.ssh.authentication.session[166972cc]: trying publickey
 D, [2009-02-11T06:57:44.915384 #4575] DEBUG --
 net.ssh.authentication.agent[16695ef4]: connecting to ssh-agent
 D, [2009-02-11T06:57:44.916451 #4575] DEBUG --
 net.ssh.authentication.methods.publickey[16695f6c]: trying
 publickey (###)
 D, [2009-02-11T06:57:44.921130 #4575] DEBUG --
 net.ssh.authentication.methods.publickey[16695f6c]: publickey
 succeeded (###)
 
 2.5.4 tries only password authentification and fails, cause I forbid
 PAM in sshd-config:
 D, [2009-02-11T06:57:36.374398 #4571] DEBUG --
 net.ssh.authentication.session[166964a8]: beginning authentication
 of `rails'
 D, [2009-02-11T06:57:36.416597 #4571] DEBUG --
 net.ssh.authentication.session[166964a8]: trying password
 E, [2009-02-11T06:57:36.416709 #4571] ERROR --
 net.ssh.authentication.session[166964a8]: all authorization
 methods failed (tried password)
 
 adding the following line to deploy.rb fixes this:
 ssh_options[:auth_methods] = publickey
 
 Thanks for pointing me to the debug option.
 Stefan
  


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

[Capistrano] Re: Using Capistrano to deploy server patchsets

[Jamis Buck]

On Fri, Feb 6, 2009 at 10:00 PM, Mathieu Jobin somek...@gmail.com wrote:

 no server side?

Right, the server side is just sshd. Capistrano is simply a tool for
executing commands on remote hosts via SSH. It doesn't need any other
software on the remote side.

 well, in this case, the developer working copy could be consider the
 master, which push the new release onto all capistrano clients, is
 that right?

Sure.

 files can be pushed, of course, along with scripts running whatever we
 might want along with the update, right?

Yup.

- Jamis

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

[Capistrano] Re: capistrano gets failed password when accessing git repository server, but when I manually ssh in it works fine????

[Jamis Buck]

, /repos/equity/.git
  set :local_repository, r...@10.1.1.1:/repos/equity/.git

If capistrano sees a :local_repository variable, it will use that URL
for all requests from the local host. The :repository variable will
then be used only for requests from the remote host. In this way you
can tell git to skip the SSH transport when requesting from the remote
host (since it's the same as the repo URL).

Hope that helps some.

- Jamis

On Sat, Feb 7, 2009 at 12:51 AM, Greg Hauptmann
greg.hauptmann.r...@gmail.com wrote:
 thanks Jamis,

 The interesting thing is I can copy/paste the commands capistrano is trying
 to issue (from the console, I did a dry-run) and then use this on the prod
 server and everything works fine (i.e. prod server to git repo server calls
 are working fine).  Can I ask a couple of quick questions:

 Is there anything different from an ssh call point of view between then:

 (a) the first call which works (i.e. executing locally: git ls-remote
 r...@10.1.1.1:/repos/equity/.git HEAD) and

 (b) second call which has authentication issue (i.e. f [ -d
 /u/apps/equity/shared/cached-copy ]; then cd
 /u/apps/equity/shared/cached-copy  git fetch -q origin  git reset -q
 --hard 7e92223c93c6f9019acd54d042fc8d348aa62a53; else git clone -q
 r...@10.1.1.1:/repos/equity/.git /u/apps/equity/shared/cached-copy  cd
 /u/apps/equity/shared/cached-copy  git checkout -q -b deploy
 7e92223c93c6f9019acd54d042fc8d348aa62a53; fi)

 Q1 - Do you see any difference in this first  second call from an ssh
 connection point of view?  Or is this also strange to you that the first
 call works fine, but then the 2nd call comes along and can't connect from
 the DEV box to the PROD box?   (or actually from your response is the main
 difference that the 1st targets the REPO server, whilst the 2nd then targets
 the PROD server - hence in my case am I really getting an authentication
 issue for the first capistrano call that is targeting the PROD server)
 Q2 - I'm assuming the authentication issue is my DEV box authenticating to
 the PROD box?  (i.e. not the PROD box trying to run GIT to contact the REPO
 server)   Is what you believe based on the logs?  And also can I ask when
 you give your answer why (i.e. so I can learn re how you interpreted things)
 You did mention (Capistrano opens a new SSH channel for each request.)
 Q3 - If it turns out to be an ssh/linux issue somehow, have you a pointer re
 where to look in the capistrano code?  (i.e. if I had to post the code that
 made the call onto an ssh/linux forum).  I'm finding it kind of confusing as
 I run capistrano of Server A, which authenticates to Server B, but the
 scripts actually run on Server B, which then has to authenticate from Server
 B to Server C, and to complicate things I think you pointed out the last ssh
 connection (server B to server C[repo]) is not really capistrano but git.
  :)

 Thanks again
 Greg


 2009/2/7 Jamis Buck ja...@37signals.com:

 Greg,

 1. Capistrano opens a new SSH channel for each request. Essentially,
 this means a new shell instance for each command, and means you cannot
 use stateful commands (e.g., run(cd foo) followed by run(pwd) will
 not display foo). If you need commands to execute from within a
 specific directory, or with a specific set of environment variables,
 or whatever, you must make sure to change directory or set environment
 variables every time you run() something.

 2. Yes. Capistrano needs to query the current revision, and does so
 from your local machine (DevServer, in your terminology). Once it
 knows the revision to deploy, it will push the code to the servers
 using the deployment strategy you selected (which may or may not do a
 code pull from the target machines).

 As for the remote end hung up unexpectedly error, I'm not sure. The
 error is coming from git on the remote server, and not from
 capistrano, so you need to make sure that git on the remote host can
 connect to the repository. Beyond that, I'm not sure what
 troubleshooting help I can offer.

 - Jamis

 On Fri, Feb 6, 2009 at 3:49 AM, Greg Hauptmann
 greg.hauptmann.r...@gmail.com wrote:
 PSS.  It seems like, in terms of the ssh connections:
 (1st connection) the initial ssh connection open by cap deploy:update
 actually *closes* prior to the next one [I'm guessing this is the
 problem?]
 (2nd connection) the connection from the prod app server to the git repo
 server then seems to occur from DevServer = ProdAppServer, as opposed to
 from ProdAppServer = ProdAppServer(where repo is).
 This would explain why for the repo connection password request I'm
 seeing
 output (e.g. Enter passphrase for /Users/greg/.ssh/id_rsa) that
 highlights
 the request is coming from my DevServer, and NOT the ProdAppServer.
 Make
 sense?
 QUESTION THEREFORE:  If this is correct, why would the SSH connection
 after
 the initial cap deploy:update drop?
 Here's a copy/paste of output over time.  I've pasted the first password
 request, and the session open/closing log