[capistrano] Re: Can't call /etc/init.d script?
On Jul 26, 2009, at 1:10 PM, jemminger wrote: > > I'm trying to call a script I wrote to manage solr via: > > task :start do > sudo "/etc/init.d/solr start" > end > try this instead: sudo "nohup /etc/init.d/solr start" Cap uses a weird tty when it connects via ssh that will send processes started from the cap ssh command to get a HUP signal when cap disconnects, This cause your processes to be terminated when cap disconnects. IF you append nohup to the command it will ignore the HUP that gets sent and will therefor not fail when cap disconnects. Cheers- Ezra Zygmuntowicz e...@engineyard.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 does Capistrano handel shell escaping / quoting?
On Jan 11, 2009, at 8:29 PM, Jamis Buck wrote: > > On 1/11/09 8:33 PM, Trejkaz wrote: >> On Sun, Jan 11, 2009 at 2:13 AM, Jamis Buck >> wrote: >>> The reason run doesn't accept arguments and escape them itself, is >>> because it can be used to run arbitrary shell instructions, not just >>> commands: >>> >>> run "if [ -d foo ]; then xyz; fi; nohub blarg bam biz 'boo ya' &" >> >> Fair enough. That would be very hard to replicate except for >> translating the control stuff to Ruby code. Which one might argue is >> more clear anyway, though I'm definitely not sure how one could do >> "&"... > > FWIW, I'd LOVE for someone to write a library that allows shell > scripts > to be generated from Ruby. Lots of things that people trip over in > Capistrano are due to shell scripting issues, and it'd be nice to be > able to standardize some of that by putting it behind a ruby DSL. > > Just in case someone's looking for a project. :) I know Ezra worked on > something like that a couple years ago or so... no idea if that code > is > still around to form a base for new hacking or not. > > - Jamis That code is still around if someone wants to pick it up and run with it ;) http://brainspl.at/articles/2007/01/22/shellscriptbuilder-for-capistrano Cheers- Ezra Zygmuntowicz e...@engineyard.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: git deploy
On Dec 10, 2008, at 10:21 AM, Jamis Buck wrote: > > set :repository, "." > set :deploy_via, :copy > > Does exactly what you're describing, Ara. It'll do a local clone of > your current repo, tar it up, and ship it off to the servers. > > - Jamis > > On Wed, Dec 10, 2008 at 11:15 AM, ara.t.howard > <[EMAIL PROTECTED]> wrote: >> >> >> On Dec 10, 2008, at 10:53 AM, Ezra Zygmuntowicz wrote: >> >>> Well it makes a tarball of your local app dir and then uses >>> net-sftp >>> to upload it to your server instead of ever bothering with version >>> control(i think?). You may have to experiment. >> >> that is definitely *not* what i'm trying to do. it seems that with >> git, or a distributed scm, the 'right way' is just to do a local >> check- >> out/clone and deploy that. exactly like checking out from a server - >> only without the server ;-) >> >> specifically i don't want my deployment to be beholden to github >> being >> up or down. Yeah I meant without bothering with *remote* version control sorry, it still uses a local git checkout of your repo for deploy. Ezra --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: git deploy
On Dec 10, 2008, at 9:49 AM, ara.t.howard wrote: > > > On Dec 10, 2008, at 10:47 AM, Ezra Zygmuntowicz wrote: > >> set :deploy_via, :copy > > and that's zero network dep? Well it makes a tarball of your local app dir and then uses net-sftp to upload it to your server instead of ever bothering with version control(i think?). You may have to experiment. -Ezra --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: git deploy
On Dec 10, 2008, at 9:41 AM, ara howard wrote: > > > maybe people are already doing this, but it seems that doing a git > deploy could simply *always* deploy from the deployment user's current > directory. has this been written already? set :deploy_via, :copy Cheers- Ezra --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Capistrano | Google Groups
On May 27, 2008, at 11:03 PM, Rich Morin wrote:
>
> I'm having trouble getting a "solo" Capistrano app (as discussed
> in "Deploying Rails Applications") to work. I'm hoping someone
> on this list can give me a hand.
>
> My impression is that the SSH login is failing, because of some
> authorization issue, but I've tried setting assorted variables
> with no success. Help?
>
> -r
>
> P.S. I'd also like to know is there's a way to get the return
> code from a failing command, assuming I get that far...
>
> === === ===
>
> $ cat t1_s
> #!/usr/bin/env ruby
> #
> # t1_s - sub-command for use by t1.cap
>
> puts 'Hi on STDOUT'
> STDERR.puts 'Hi on STDERR'
>
> === === ===
>
> $ cat t1.cap
> # t1.cap
>
> set :application, 'localhost'
> set :user,'rdm'
> role :arti,application
>
> desc 'Run a test command.'
> task :test_cmd, :roles => :arti do
>begin
> cmd = 'Work/Cap/t1_s'
> run cmd do |channel, stream, data|
>case stream
>when :err
> puts "stderr from #{channel[:host]}: #{data}"
>when :out
> puts "stdout from #{channel[:host]}: #{data}"
>end
> end
>rescue
> puts 'Command failed: ' + $!
>end
> end
>
> === === ===
>
> $ cap -f ./t1.cap test_cmd
> * executing `test_cmd'
> * executing "Work/Cap/t1_s"
>servers: ["localhost"]
> Command failed: connection failed for: localhost
> (NoMethodError: private method `split' called for nil:NilClass)
It looks like you are just trying to deploy to localhost? Do you have
an sshd server running on your local machine? Also this: cmd = 'Work/
Cap/t1_s' looks a bit suspect to me. When you run a command via
capistrano you have to be careful with absolute versus relative paths.
You should add the fully qualified path to the front of that command
Cheers-
-Ezra
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: SSL - no "accept (p)ermanently" option :(
On May 27, 2008, at 11:45 PM, Liam Morley wrote: > Thanks very much Ezra for the reply. That /almost/ worked. The > problem is, I'm on a Windows box :( and that makes everything more > difficult. I do have a cygwin copy of svn and cygwin is in my path, > so after executing 'svn co' on the cmd line, I can successfully add > the key permanently, but I don't think that setting makes it outside > of cygwin. After I accept permanently from the cmd line, I'm still > presented with only 'reject or accept temporarily' from Capistrano. > > The interesting thing is, I tried checking out from TortoiseSVN in a > new directory, and it didn't even prompt me to accept at all, it > just checked everything out. Just for full disclosure, my ordinary > everyday svn client is Subclipse (plugin for Eclipse, I'm a RadRails > user), which had prompted me earlier, and did offer the "accept > permanently" option. > > Liam Hmm, I actually don't know how to get around this on windows, I don't know how it handles openssl type stuff.. Cheers- - Ezra --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: SSL - no "accept (p)ermanently" option :(
Hey~ On May 27, 2008, at 11:16 PM, Liam Morley wrote: > > I'm guessing that our sys admin is just using a bum certificate or > something, but in any case, when I try to use our svn repo which is on > a secure server, i get the following: > > [err] Error validating server certificate for 'https://blah:443': > - The certificate is not issued by a trusted authority. Use the > fingerprint to validate the certificate manually! > ... > (R)eject or accept (t)emporarily? > > > In all of my googling, I always see something like "(R)eject, accept > (t)emporarily or accept (p)ermanently?" I'd really like to accept > permanently, but cap won't let me. :( And to make matters worse, both > Firefox and my SVN client will accept the cert permanently, so I have > a hard time going to my sys admin and telling him to fix the cert. Is > there anything I can do with capistrano (or maybe Net::SSH?) to > somehow permanently accept the cert? Thanks all. Liam- The way to get around this is to do a fresh svn checkout of the repo in question and permanently accept it on the command line. once you do this the next time you run cap tasks it will not prompt you anymore. $ cd ~ $ svn co # permanently accept cert $ cd ~/railsapp $ cap deploy Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- [EMAIL PROTECTED] -- EngineYard.com --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Where is the SSH Known Hosts Cache
On Dec 19, 2007, at 10:56 AM, Endikos wrote: > > Already checked that one too. :( The error appears to be originating > from the server rails is deployed to. It's like Capistrano has it's > own cache file somewhere... > > On Dec 19, 1:41 pm, Philip Hallstrom <[EMAIL PROTECTED]> wrote: >> Oh :) Then check the host you deploy from. For some things it >> connects >> from there too I think. >> >> It's got to be in one of the two spots :) >> >> On Wed, 19 Dec 2007, Endikos wrote: >> >>> That's what I did check... the deployment user, on the server the >>> app >>> is deployed to... >> >>> On Dec 19, 1:12 pm, Philip Hallstrom <[EMAIL PROTECTED]> wrote: >>>>> The host key on my subversion server has changed recently, and >>>>> now I >>>>> can't deploy without getting a Net::SSH::HostKeyMismatch >>>>> Exception. >>>>> Where is this information cached? I looked in my deployment >>>>> users .ssh/known_hosts file, and didn't see a reference to it >>>>> there. >> >>>> Check that file on your deployed to server(s). Those are the >>>> ones making >>>> the connection to your subversion server... >> >>>> -philip ssh_options[:paranoid] = false Cheers- - Ezra Zygmuntowicz -- Founder & Software Architect -- [EMAIL PROTECTED] -- EngineYard.com --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Cap 2.0 file upload problem
What version of RUby itself are all of you experiencing this problem running? Is it perhaps ruby 1.8.6? I've been doing file transfers with cap here of up to 25Mb without ever seeing this issue no matter what i call before or after the put command. THis was with ruby 1.8.5 But I just tried it with ruby 1.8.6 and was able to get the same deadlocking error. Ruby 1.8.6 has a bug in the threading code that causes deadlocks sometimes. Can those of you having this issue please install the fastthread gem and add require 'fastthread' to the top of your recipe files and report back please? Thanks -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Capistrano and Leopard
On Jun 12, 2007, at 8:23 AM, Jamis Buck wrote:
>
> Perhaps this only tickles me because I'm the author of the software,
> but apparently the next version of Mac OS X will ship with
> Capistrano, bundled. (see http://www.apple.com/macosx/leopard/
> technology/unix.html) No doubt it will ship with 1.4.1, but this is
> getting me motivated again on the cap2 front. Expect the third-and-
> final preview release soon, perhaps late this week or early next.
>
> Out of curiosity, how many of you are using Cap2 right now? What
> issues have you encountered with it that should be addressed before
> cap2 final?
>
> Onward!
>
> - Jamis
That's super cool Jamis, congrats!
Cheers-
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: run ruby code on server magically
On May 2, 2007, at 9:22 AM, Rob Sanheim wrote:
>
> Sorry, sent that too early. I'd like:
>
> set :my_func, lambda { # arbitrary ruby code here }
>
> then
>
> task :after_deploy do
> my_func # this runs the lambda in the context of all servers for
> this task, not locally
> end
>
> The reason I ask for this is because I find myself writing a lot of
> little helper ruby scripts, then pushing them out to all the servers
> so that I can run them from capistrano. I find ruby much more
> friendly for almost all shell tasks once they go beyond the very
> simple, especially for things like testing if files exist and the
> like. I really don't like trying to switch my brain into bash mode
> :).
>
> Of course right now, if you just run ruby from w/i a custom task now,
> it just executes in the local scope.
>
> Is something like this possible, maybe using ruby2ruby for sending the
> proc to the servers?
>
> - Rob
It's probably possible but may be more trouble then it's worth. What
about something like this instead?
module Ruby
def ruby(cmd, options={}, &block)
temp_name = "/tmp/#{Time.now.strftime("%m%d%H%M%S")}" + ".rb"
begin
put(cmd, temp_name, :mode => 0700)
send(run_method, "ruby #{temp_name}", options, &block)
ensure
delete temp_name
end
end
end
Capistrano.plugin :script, Ruby
task :foo do
script.ruby "10.times { puts `uname -a` }"
end
Cheers-
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: [ANN] Capistrano 2.0 Preview 1
Awesome Jamis, congrats on the release. No let's see how easy it is to update 300+ cap 1.x recipes ;) -Ezra On Apr 24, 2007, at 9:49 PM, Jamis Buck wrote: > > It is with a great deal of excitement and anticipation that I > announce the first preview release of Capistrano 2.0. This is _not_ > an official release, but simply the first of several attempts to get > people using what will eventually be 2.0, so that we can iron out all > the wrinkles. Thus, if you're the enterprising, daring, and/or > masochistic sort, I encourage you to give it a whirl: > >gem install -s http://gems.rubyonrails.com capistrano > > (WARNING. Capistrano 2.0 is _not_ entirely backwards compatible with > 1.x, so be sure to read this entire announcement before going all > install happy!) > > In addition to this preview release, I'm happy to announce the > beginnings of Capistrano's own web presence: > >http://www.capify.org > > There's not much there right now, but it'll grow quickly. Currently, > the sections that might be of most interest are: > >Upgrade guide: > http://www.capify.org/upgrade > >What's new in Capistrano 2.0: > http://www.capify.org/upgrade/whats-new > > Read up on those, and if you're still feeling brave, install away! > Feel free to post feedback of any kind (whether it be on Capistrano > 2.0, the website, or my own personal grooming habits) to the > Capistrano mailing list (http://groups.google.com/group/capistrano). > > - Jamis > > > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Cap2 test question?
Ruby 1.8.6 has replaced the Thread classes with the fastthread
implementation. Unfortunately there is a bug in the release of 1.8.6
that has to do with threading that will hopefully be fixed in the
next release.
For now install the fastthread gem and then somewhere in the code
you need to do this:
require 'fastthread'
Try that and see if you still get the deadlock, my hunch is that
this will fix it.
Cheers-
-Ezra
On Apr 11, 2007, at 7:08 AM, Jamis Buck wrote:
>
> Hmmm, looks like a Ruby 1.8.6 thing. It works fine on 1.8.5, but I
> can duplicate it too with 1.8.6.
>
> I'll make some time this week to investigate this a bit.
>
> - Jamis
>
> On Apr 11, 2007, at 7:27 AM, rubdabadub wrote:
>
>>
>> Yes, The deadlock error. I am on OSX 10.4 and ruby 1.8.6 (2007-03-13
>> patchlevel 0) [powerpc-darwin8.9.0]
>> and Rails 1.2.3.
>>
>> I am running ruby darwin ports if thats says something ..
>>
>> Cheers
>>
>> On Apr 11, 3:21 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>>> On Apr 11, 2007, at 5:10 AM, rubdabadub wrote:
>>>
>>>> FYI:
>>>
>>>> I still receive the rake error. SVN rev - 6512
>>>
>>> The deadlock when running rake, you mean? What ruby version are you
>>> using? What is your operating system?
>>>
>>> - Jamis
>>>
>>>
>>>
>>>> Cheers
>>>
>>>> On Mar 30, 9:40 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>>>>> Ah! Brilliant, Doug. Thanks for the patch! That cleared the
>>>>> problem
>>>>> right up.
>>>
>>>>> - Jamis
>>>
>>>>> On Mar 30, 2007, at 12:51 PM, Doug Barth wrote:
>>>
>>>>>> The problem here is that your signaling thread is signaling
>>>>>> before the
>>>>>> originating thread has had the chance to wait on the condition.
>>>>>> This
>>>>>> results in the wait hanging forever waiting for a signal. The
>>>>>> fix is
>>>>>> to synchronize the creation of the background thread as well.
>>>>>> Here's a
>>>>>> patch that fixes the issue. I have also removed the Thread.pass
>>>>>> calls
>>>>>> as they not needed.
>>>
>>>>>> Index: gateway.rb
>>>>>> =
>>>>>> =
>>>>>> =
>>>>>> --- gateway.rb (revision 6494)
>>>>>> +++ gateway.rb (working copy)
>>>>>> @@ -38,18 +38,18 @@
>>>>>>mutex = Mutex.new
>>>>>>waiter = ConditionVariable.new
>>>
>>>>>> - @thread = Thread.new do
>>>>>> -logger.trace "starting connection to gateway
>>>>>> `#{server.host}'" if logger
>>>>>> -SSH.connect(server, @options) do |@session|
>>>>>> - logger.trace "gateway connection established" if
>>>>>> logger
>>>>>> - Thread.pass
>>>>>> - mutex.synchronize { waiter.signal }
>>>>>> - @session.loop { [EMAIL PROTECTED] }
>>>>>> + mutex.synchronize do
>>>>>> +@thread = Thread.new do
>>>>>> + logger.trace "starting connection to gateway
>>>>>> `#{server.host}'" if logger
>>>>>> + SSH.connect(server, @options) do |@session|
>>>>>> +logger.trace "gateway connection established" if
>>>>>> logger
>>>>>> +mutex.synchronize { waiter.signal }
>>>>>> +@session.loop do
>>>>>> + [EMAIL PROTECTED]
>>>>>> +end
>>>>>> + end
>>>>>> end
>>>>>> - end
>>>
>>>>>> - mutex.synchronize do
>>>>>> -Thread.pass
>>>>>> waiter.wait(mutex)
>>>>>>end
>>>>>> end
>>>
>>>>>> On Mar 30, 9:38 am, Jamis Buck <[EMAIL PROTECTED]> wrote:
>>>>>>> Yeah...I've not been able to figure that out. It only happens
>>>>>>> intermittently to me. If you go into test/gateway_test.rb and
>&
[Capistrano] Re: Deploy on specific server
I have found that the cleanest way to do staging and production tasks like this is this way: task :production do role :web, '65.74.169.199:8192' role :app, '65.74.169.199:8192' role :db, '65.74.169.199:8192', :primary => true end task :staging do role :web, '65.74.169.199:8194' role :app, '65.74.169.199:8194' role :db, '65.74.169.199:8194', :primary => true end Then you can do: $ cap staging deploy $ cap production deploy Cheers- -Ezra On Mar 29, 2007, at 7:49 AM, Jamis Buck wrote: > > On Mar 28, 2007, at 2:02 AM, dubek wrote: > >> Many people have this kind of situation (usually with 3 environments: >> dev, staging and production). Just search the capistrano and rails >> groups for "staging" and you'll find all the talks about it... I have >> a feeling the Jamis is planning some solution for it in the next big >> release. ;-) > > I'm curious why you have that feeling. :) Even more, though, I'm > curious what you think Capistrano ought to do about this. Personally, > I think the case statement is a great solution. Totally fine. What > could Capistrano do that would be cleaner and easier to read than: > >case ENV['STAGE'] >when "production" > role > set ... > ... >when "development" > >... >end > > If it is the environment variable that looks klunky you, you can use > capistrano variables instead: > >case stage >... >end > > And then invoke it like this > >cap -S stage=production deploy > > - Jamis > > > > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Getting user input from within tasks
Hey-
Here is a task I use to add users and set their passwords:
task :new_user, :roles => :slice do
run "adduser rcreasy"
run "passwd rcreasy" do |ch, stream, out|
ch.send_data 'xxx'+"\n" if out =~ /New UNIX password:/
ch.send_data 'xxx'+"\n" if out =~ /Retype new UNIX password:/
end
end
Cheers-
-Ezra
On Mar 15, 2007, at 11:57 AM, rcreasey wrote:
>
> I've been trying to extend Capistrano into more than just a web
> application deployment framework and into the realm of system
> administration.
>
> I wanted to write a recipe file that would include common tasks, such
> as adding and deleting system users, but realized that it would only
> really work if I were able to actually get STDIN from the user after
> running cap with the recipe.
>
> I'm thinking of something like this:
>
> desc "Add a user to the specified host"
> task :adduser do
> puts "Username: "
> gets username
> puts "Password: "
> gets password
>
> run "/usr/sbin/adduser #{username}"
> run "/usr/bin/passwd --stdin #{password} | /bin/echo #{password}"
> end
>
> This is a simple kind of example, but you can see what I mean.
> Unfortunately, since (I think) the tasks are Erb templates doing
> methods such as 'gets' doesn't work for variable assignment, and when
> you try to execute a task similar to the one above, it will just skip
> over the 'gets' and complain about the variable not being defined when
> trying to reference it in the following 'puts'.
>
> Any thoughts?
>
> --
> Ryan C. Creasey
> [EMAIL PROTECTED]
>
>
> >
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: Where's the list of hooks to override?
On Feb 26, 2007, at 8:55 AM, Phlip wrote: > > Jamis Buck wrote: > >> Do you mean, which task should they go in? I'm afraid I can't really >> help you there, without knowledge of your application. Why are you >> hard-coding RAILS_ENV to development, for instance? > > Sorry to mislead the newbies; the site is simply not in production > yet. Pay those no mind. > >> ...What is the absolute >> latest in the deployment cycle that the backgrounddrb stuff can >> safely not be running? > > Just before a user hits the site. > > -- > Phlip > http://c2.com/cgi/wiki?ZeekLand <-- NOT a blog!! > Philip- I always run my backgroundrb start script in a task called before_restart. This way the bdrb daemon starts right before your mongrels do. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: [ANN] Capistrano 1.4.1
On Feb 24, 2007, at 1:14 PM, Jamis Buck wrote:
> Here it is, another Capistrano release, and less than a month since
> the last one! Miracles truly never cease.
>
> Version 1.4.1, available just as soon as the mirrors get updated,
> is a pretty minor update, but has one new feature:
>
> * You can now pass :env to 'run' (and friends), in order to specify
> environment variables that should be set for that command. For
> example:
>
> run "some_batch_thang.rb", :env => { "DEBUG" => "1" }
>
> There is also one deprecation: if you are using UPPERCASE variables
> in your Capistrano recipes, you'll being seeing warnings now.
> Support for variables that start with uppercase letters will be
> removed altogether in Capistrano 2.0. If you want uppercase
> identifiers, you should use Ruby constants.
>
> The two fixes in this release:
>
> * Actor#get will not close the SFTP channel when it finishes. This
> makes it possible to do multiple SFTP gets and puts in a single
> session.
> * The subversion adapter now passes the "no-auth-cache" option, so
> that if you configure an explicit subversion username for
> deployment _other_ than your dev username, those deployment auth
> tokens won't clobber your development tokens.
>
> So, go get it, "gem install capistrano." Or download it directly
> from RubyForge (http://rubyforge.org/frs/?group_id=1420). And at
> the risk of promising too much, too early: I expect this to be the
> last 1.x release of Capistrano, barring any critical problems that
> may arise with 1.4.1. Come on, cap2!
>
> - Jamis
>
Awesome thanks Jamis!
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: how to spawn/launch/detach a process?
Philip-
The nohup has to be in the cap recipe not in a script on the server.
task :restart, :roles => :app do
run 'kill `ps aux | grep push_server | grep -v grep | cut -c 10-15`'
run 'cp ~/juggernaut.yml champion/current/config/'
run 'chmod 755 ~/champion/current/public ' +
'~/champion/current/public/dispatch*'
run "cd #{current_path} && nohup ./script/start_juggernaut.sh &"
end
-Ezra
On Feb 18, 2007, at 11:13 AM, Phlip wrote:
>
> Vegan Buddy wrote:
>
>> Put nohup at the beginning and & at the end. The nohup will
>> allow it
>> outlive its TTY.
>>
>> run('nohup ruby script/push_server &')
>
> That works fine from the SSH shell, and I can't get it working from
> deploy.rb. Start with script/start_juggernaut.sh:
>
> cd ~/champion/current
> nohup ruby script/push_server &
>
> Then run this restarter:
>
> task :restart, :roles => :app do
> run 'kill `ps aux | grep push_server | grep -v grep | cut -c 10-15`'
> run 'cp ~/juggernaut.yml champion/current/config/'
> run 'chmod 755 ~/champion/current/public ' +
> '~/champion/current/public/dispatch*'
> run "sh #{current_path}/script/start_juggernaut.sh"
> end
>
> The transcript naturally can't say if anything went wrong after the
> shell:
>
> * executing "sh /home/myglad/champion/current/script/
> start_juggernaut.sh"
>
> And no process or nohup.out ever show up.
>
> --
> Phlip
> http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
>
>
> >
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: Cap ShellScriptBuilder
Hey~
On Jan 22, 2007, at 8:20 AM, Wayne E. Seguin wrote:
>
> Ezra,
>
> I think this is a great idea and will prove very useful, I would
> definitely use it.
>
> I especially like your great use of method_missing.
>
> I do however forsee a problem with the current idea regarding calls
> like ln_nfs for ln -nfs.
>
> The issue I see here is with commands like:
> mongrel_rails
> mongrel_cluster
> mysqld_safe
> mysql_*
> etc...
>
> As for how to fix this nicely... I'm not sure yet but I see three
> possibilities:
> 1. Use two underscores
> 2. Grab the last part of the underscore
> 3. Use ! at the end to indicate that parameters are intended
>
> Problem with 1 is, well, it's ugly! It is however functional and it
> would be clear what was meant by it
> Problem with 2 is better except for if you call a command with no
> arguments
> Not sure there is much of an issue with 3 unless you intend on using !
> in other places
>
> I'll be monitoring this thread, I'd love to help out here.
>
> Thanks for the great work!
>
> ~Wayne
So I have worked on this some more to incorporate being abel to set
ENV vars per line if you want.
sh.RAILS_ENV('production').mkdir_p 'foo/bar'
#=> RAILS_ENV=production mkdir -p foo/bar
Also I made the method_missing dispatch work if you called
sh.mongrel_cluster_C "config/mongrel.conf" It will now take only the
last text after an underscore and convert that into -args.
But this still doesn't account for calling sh.mongrel_cluster
"start" . the method missing will trigger and split that into mongrel
-cluster start, which is obviously not what we want. Here is a hack I
am using right now to get around this:
%w[
mongrel_rails
mongrel_cluster
mysqld_safe
].each do |m|
define_method(m) do |*args|
@cmdbuff << "[EMAIL PROTECTED] #{args.join(' ')}\n"
self
end
end
I use define_method and a list of known commands with underscores
that should not be picked apart my method missing any more. This gets
around the problem at the expense of the need to compile a big list
of commands that we need to put in that list. If anyone has any other
ideas to handle this case I am all ears.
Jamis asked me to get the update_code task to work with this. Here
you can see a comparison between the old way and the new way:
http://pastie.caboo.se/34983
ALso I have made this into a capistrano plugin that you can use
right now and it already will upload your script to a tmpdir on the
server chmod +x it and then run it and then delete it. I am attaching
the new gem here if you want to try it.
Install the gem and then in your recipe do this:
require 'rubygems'
require 'shell_script_builder/cap_plugin'
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
shell-script-builder-1.0.1.gem
Description: Binary data
Cheers-
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
[Capistrano] Re: Cap ShellScriptBuilder
Wayne- Yeah I already thought about that and there is a decent workaround for when you have a command that doesn't conform to the method missing underscore to flag. So similar to RJS you can use << to push arbitrary commands onto the stack: script = shell do |sh| sh.ln_nfs "foo", "bar" sh << "mongrel_rails start -C some/config.conf" end puts script #!/bin/sh ln -nfs foo bar mongrel_rails start -C some/config.conf So for the majority of commands you will be able to use the method_missing approach but you will still be able to use arbitrary commands when you need to -Ezra. On Jan 22, 2007, at 8:20 AM, Wayne E. Seguin wrote: > > Ezra, > > I think this is a great idea and will prove very useful, I would > definitely use it. > > I especially like your great use of method_missing. > > I do however forsee a problem with the current idea regarding calls > like ln_nfs for ln -nfs. > > The issue I see here is with commands like: > mongrel_rails > mongrel_cluster > mysqld_safe > mysql_* > etc... > > As for how to fix this nicely... I'm not sure yet but I see three > possibilities: > 1. Use two underscores > 2. Grab the last part of the underscore > 3. Use ! at the end to indicate that parameters are intended > > Problem with 1 is, well, it's ugly! It is however functional and it > would be clear what was meant by it > Problem with 2 is better except for if you call a command with no > arguments > Not sure there is much of an issue with 3 unless you intend on using ! > in other places > > I'll be monitoring this thread, I'd love to help out here. > > Thanks for the great work! > > ~Wayne > > Ezra Zygmuntowicz wrote: >> Hey Folks- >> >> I spent the weekend working on a shell script builder DSL for >> writing your capistrano tasks in ruby instead of putting shell script >> snippets in strings to the run method. >> >> I wrote about this on my blog with a call for some input on look and >> feel and whatnot. >> ... >> I would love some feedback and thoughts from folks as to whether >> they would use this or not. >> > > > > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Cap ShellScriptBuilder
Hey Folks-
I spent the weekend working on a shell script builder DSL for
writing your capistrano tasks in ruby instead of putting shell script
snippets in strings to the run method.
I wrote about this on my blog with a call for some input on look and
feel and whatnot.
http://brainspl.at/articles/2007/01/22/shellscriptbuilder-for-capistrano
http://brainspl.at/shell_script_builder.tar.gz
Right now it is just a standalone library that generates shell
scripts. I haven't made the mechanism that will allow cap to upload
these scripts to the servers and execute them but thats an easy task.
I am going to try to rewrite all the standard cap recipes to use this
Builder instead of shell scripts.
The reasoning is that with this dsl you will not have to remember
what all the flags to bash's if statements are. And you also don';t
have to worry about shell escaping or the way capistrano escapes
commands itself.
I would love some feedback and thoughts from folks as to whether
they would use this or not.
Here is a small example:
script = shell do |sh|
sh.sudo.ln_nsf "foo/bar", "bar/bar"
sh.echo "some string" => "/path/to/log.txt"
sh.if :directory? => "some/dir" do |sub|
sub.rm_rf 'some/dir'
sub.ln_nsf "shared/foo", "some/dir"
sub.if_not :file? => 'foo' do |ssub|
ssub.mkdir_p "some/foo"
end
end
sh.unless :file? => 'foo/bario' do |sub|
sub.touch 'foo/bario'
end
sh.if :writable? => "some/file.txt" do |sub|
sub.echo "#{Time.now}" => 'some/file.txt'
end
sh.mkdir_p 'foo/bar'
sh.rm_rf 'foo/bar'
end
puts script
OUTPUT:
#!/bin/sh
sudo ln -nsf foo/bar bar/bar
echo "some string" >> /path/to/log.txt
if [ -d some/dir ]
then
rm -rf some/dir
ln -nsf shared/foo some/dir
if [ ! -a foo ]
then
mkdir -p some/foo
fi
fi
if [ ! -a foo/bario ]
then
touch foo/bario
fi
if [ -w some/file.txt ]
then
echo "#{time}" >> some/file.txt
fi
mkdir -p foo/bar
rm -rf foo/bar
Cheers-
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: Capistrano 2.0 (was: bugfix and new feature)
Hi~ On Jan 18, 2007, at 11:46 AM, Jamis Buck wrote: Hey Ezra, I really appreciate the offer. I'm afraid my ideas are still in the vague/proof-of-concept/experimenting state, but right now these are the things I know that I want to happen for Capistrano 2.0: * Decouple the core from the standard recipes. This should slim the core stuff down quite a bit. * Decouple the deployment method from the SCM, so you can use any SCM you want with any supported deployment method (e.g. "checkout", "export", "copy", "rsync", etc.) * Get serious about the tests. Right now they're admittedly weaksauce. My testing-fu is quite challenged by the ssh requirement. It'd be lovely to have a "mock server" that ships with Net::SSH, which could be used to do testing with Net::SSH, but that's a tall order. I've also been toying with the idea of having a minimal DSL for writing shell scripts, primarily so that capistrano's default recipes can work with non-POSIX shells (like csh and tcsh). This would have the happy side-effect of making it easier to write simple conditionals in scripts; currently it requires shell-script- fu as well as a knowledge of how capistrano is going to mangle the script when it runs it. So this part sounds pretty fun to me ;) Can you perhaps show me a few examples of some DSL syntax you would like to see and what things should be supported? -Ezra --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Capistrano 2.0 (was: bugfix and new feature)
I would also love to see this happen for cap 2.0. Jamis- is there anything moving towards 2.0 that you would like to see that I can help work on? I know your a busy guy. Cheers- -Ezra On Jan 17, 2007, at 11:42 PM, Mike Bailey wrote: I think this is great news! It will make life easier for people writing plugin gems which in turn will lead to more and varied recipe gems surfacing. Another system built around the 'everything is a plugin' idea is Nagios network monitoring. Is just makes things easier to grok when the core is simplified and decoupled from the peripheral bits. - Mike On 18/01/2007, at 3:11 PM, Jamis Buck wrote: Neil, My vision for Capistrano 2.0 is to follow the suggestions a few people have offered and decouple "Capistrano-the-part-that- executes- remote-processes" from "Capistrano-does-rails- deployment". The "core" capistrano bit would be installable standalone, with no defaults. The rails-specific bits would then depend on capistrano-core. - Jamis On Jan 17, 2007, at 3:20 AM, NeilW wrote: How does '-x' work with this lot? It would be quite useful if '-x' skipped preloading of any task library - including standard. I might be (and often am!) doing something with capistrano that doesn't involve Rails deployment at all. > > > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: loading recipe file a second time
On Jan 17, 2007, at 12:30 AM, Mike Bailey wrote:
I'm curious about why a recipe file I "require" in ~/.caprc is not
loaded a second
time when it is "require"d by deploy.rb
I noticed this when investigating a problem with ~/.caprc not
overriding standard
tasks ('fcgi not found' appeared in place of restart_mongrel_cluster).
When I removed 'require deprec/recipes' from ~/.caprc, it was
loaded by deploy.rb
and the :restart task was overwritten. However when it was in
~/.caprc the :restart
task was not overwritten.
Is there someone stopping a recipe file from being loaded twice?
- Mike
Mike-
You can require the same file multiple times in one ruby program but
it will only ever be loaded once. If you want it to load twice use
load instead of require.
so
load 'deploy.rb'
instead of
require 'depoy'
the .rb is necessary with load.
Cheers-
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: Documentation Project
On Jan 14, 2007, at 1:03 PM, Rob Sanheim wrote: On 1/12/07, Jamis Buck <[EMAIL PROTECTED]> wrote: Alright, apologies to Julie for hijacking her thread. That was not my intention. I'm rectifying the situation by giving the documentation topic it's own thread. So, here's the status of Capistrano documentation: 1. The existing manual (http://manuals.rubyonrails.org/read/book/17) is woefully out of date. 2. My login to update the manual is broken, and has been for months, so I cannot do anything about that copy of the manual. I'd like to find some way to allow the Capistrano community to contribute documentation, since that way I don't have to do it. :) Seriously, though, with the community working the docs, they will be much more likely to stay up-to-date, and accurate. I do not want to go the wiki route, for various reasons. Ultimately, I'd like to be able to provide a printable version of the docs, as well as a version for reading online, but that may be too pie-in-the-sky. Ezra has generously offered to host whatever we decide on. Does anyone have any suggestions for what we can do? Perhaps a wiki is really the only solution right now. I suppose it is better to have something immediate up-and-running, than wait a year while we try and devise a "perfect" solution. - Jamis Maybe something could spring board off from the caboose doc project? http://caboose.stikipad.com/documentation/ - rob I think a wiki may have to do for now. May I suggest we use Jim Weirich's Ruse wiki engine? It's built from the ground up to easily deal with spam. It runs the new rubygarden wiki and since they installed it there there has been very little spam. It's either that, or maybe we can do like the mongrel project does for it's docs. It uses webgen and a svn repo to manage the docs. So people who want to contribute would do so with patches. But this means someone has to apply the patches. I can also talk to court3nay about the caboose doc project. Maybe he would sponsor a few people to have a sprint and build a new app for the new capistano manuals. Cheers- -- Ezra Zygmuntowicz-- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Capistrano basic tasks
On Jan 11, 2007, at 7:29 PM, Jamis Buck wrote: > > On Jan 11, 2007, at 8:13 PM, Julie wrote: > >> Capistrano manual talks about tasks such as spinner and spawner which >> stops-restarts the FastCGI processes on the app server. We are using >> Mongrel instead of FastCGI, so do these tasks do the same thing with >> Mongrel servers? Does the deployment stops-restarts those servers by >> default? > > The spinner is obsolete--and so, sadly, is the manual. My login to > the manuals site is broken, so I've been unable to update it in > several months. What I'd _love_ to do is ditch that one and find some > way to do a manual where the community can contribute bits and pieces > to it, but I'm not sure how best to proceed. At any rate, that topic > goes way beyond your question, so I'll save it for another post. Jamis- Sorry to be a little off topic for this thread. But I am more then happy to offer free hosting for such a manual when the time comes. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: revisions.log
On Jan 10, 2007, at 8:08 AM, Jamis Buck wrote: > > How many of you use the revisions.log file that capistrano updates on > every checkout? The idea was originally that it would provide a kind > of audit trail for deployments, showing who deployed what, when. > However, it is currently the only thing standing in the way of > pulling the requirement that capistrano have access to the source > repository from the local host (since the revisions log also logs the > release number). > > Would anyone cry if it went away? Or if it simply reported who/when, > instead of who/what/when? > > - Jamis I have no love for the revisions.log myself. It just sits there on the server. If it removes the requirement for checking revision numbers locally then tear it out I say. Or at least make it configurable so you can use or not use it. Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: [Mongrel] versioning of win32 versus ruby gems
Hey Charles-
Cool I'm glad you like it. It definitely needed a cleanup of the
params and your patch looks really nice. Unfortunately email ate the
formatting and I can't use it :/ Can you send me a copy of the entire
file in its new state? You can send it to me directly if you like. I
really need to package this thing up with a few other goodies I have
and release it.
Thanks-
-Ezra
On Jan 9, 2007, at 3:00 PM, Charles Brian Quinn wrote:
> Ezra, I found this cap plugin you posted to be extremely useful, ccing
> Capistrano list, where I know you've posted about it too. I have a
> patch, adding the options as a params hash for readability. My
> cursory googling..err..searching could not reveal where this
> capistrano "Gem" plugin resides.
>
> main difference is this method:
>
> def install(packages, source=nil, version=nil)
>
> is now:
>
> def install(packages, options={})
>
> so you can do:
>
> gem.select 'mysql', :version => '2.7', :platform => 'ruby',
> :extra_params => '-- --with-mysql-config'
>
> or:
>
> gem.select 'mongrel', :version => '0.3.13.4'
>
> Here's the diff, (email formatting is horrible), or point me to an svn
> for latest to build a patch
>
> $ diff cap_gem_plugin.rb cap_gem_plugin_cbq.rb
> 39,41c36,40
> < def install(packages, source=nil, version=nil)
> < sudo "#{GEM_INSTALL} #{version ? '-v '+version.to_s : nil} #
> < {source ? '--source='+source : nil } #{packages.to_a.join(' ')}"
> ---
>> # def install(packages, source=nil, version=nil)
>> def install(packages, options={})
>> sudo "#{GEM_INSTALL} #{options[:version] ? '-v '+options
>> [:version].to_s : nil} " +
>> "#{options[:source] ? '--source='+options[:source] :
>> nil } " +
>> "#{packages.to_a.join(' ')}"
> 63c59,60
> < def select(package, source=nil, version=nil, platform='ruby')
> ---
>> # def select(package, source=nil, version=nil, platform='ruby')
>> def select(package, options={})
> 65,66c62,65
> < cmd="#{GEM_INSTALL} #{version ? '-v '+version.to_s : nil} #
> < {package} #{source ? '--source='+source : nil }"
> ---
>> cmd="#{GEM_INSTALL} #{options[:version] ? '-v '+options
>> [:version].to_s : nil} " +
>> "#{package} " +
>> "#{options[:source] ? '--source='+options[:source] : nil }
>> " +
>> "#{options[:extra_params] ? options[:extra_params] : nil}"
> 70c69
> < when /\s(\d+).*\(#{platform}\)/
> ---
>> when /\s(\d+).*\(#{options[:platform]}\)/
>
>
> Thanks!
> --
> Charles Brian Quinn
> self-promotion: www.seebq.com
> highgroove studios: www.highgroove.com
> slingshot hosting: www.slingshothosting.com
> 678.389.9462
>
> Ruby on Rails Bootcamp at the Big Nerd Ranch
> Intensive Ruby on Rails Training:
> http://www.bignerdranch.com/classes/ruby.shtml
>
> On 12/21/06, Ezra Zygmuntowicz <[EMAIL PROTECTED]> wrote:
>> On Dec 21, 2006, at 11:13 AM, Charles Brian Quinn wrote:
>>> Thanks Steven,
>>>
>>> This is using Jamis' net/ssh library and using:
>>>
>>> sudo cmd do |channel, stream, data|
>>>data.each_line do | line |
>>>
>>> to regex match lines and type in input. this could work, but i was
>>> hoping for bash or something simpler
>>>
>>> Guess that means it's time to move my all of my shell scripts
>>> over to
>>> ruby (except for the one that installs ruby) ;-)
>>>
>>> Thanks!
>>
>>
>> Charles-
>>
>> You and me both. I didn't want to spend the time writing bash
>> scripts for this when I need to do it on tons of machines anyway. So
>> the script he linked to is actually a capistrano plugin. Take the
>> file and put it somewhere in your load path and then require it from
>> a capistrano recipe file and then you can use it like this:
>>
>>
>> require 'cap_gem'
>>
>> task :install_gems, :roles => :app do
>>gem.select 'mongrel' , 'http://mongrel.rubyforge.org/releases'
>>gem.install 'mongrel', 'http://mongrel.rubyforge.org/releases' ,
>> '1.0'
>> end
>>
>> select will select the most recent versions for the current platform
>> and install it. install will
[Capistrano] Fix for ssh auth error with cap 1.3
Hey Jamis - I did some work and was able to find and fix the bug that people are having with the 1.3 release and ssh authentication failure when using a gateway. The bug was in my patch for username and ports in server strings. When a gateway was used the retry block in the SSH.connect method was called and the explicit port number passed in by the gateway was not being respected. I have fixed this error and I sent a patched gem to Jason Norris who originally reported this problem. And the fix has gotten rid of the error and his recipe runs fine now. I can also no longer make this bug happen. Patch submitted to the trac: http://dev.rubyonrails.org/ticket/6913 I would say this warrants another release. I apologize for not finding this before you released 1.3 Cheers- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Strange problem with SSH
Hi~ On Dec 29, 2006, at 11:41 AM, Jason Norris wrote: I did verify that it is the 1.3 release that caused the problem, and not something with having two versions installed. Also, both my client and servers are running Arch Linux, kernel 2.6.19, and my ssh version is OpenSSH_4.5p1, OpenSSL 0.9.8d 28 Sep 2006. Jamis Buck wrote: That'sa little worrisome. I've not had any issues with 1.3 and auth failures. Can anyone else duplicate this? - Jamis On Dec 29, 2006, at 12:03 PM, SmokeyMiles wrote: I got it fixed. I was trying everything I could think of, so I did gem uninstall capistrano. It responded by asking which version I would like to uninstall - 1.2.0 or 1.3.0. I uninstalled the .3 version (because I knew the .2 one worked), and BAM, everything is hunky dory. Jason It looks like it is happening near the code I submitted for ssh usernames and ports in the server strings. I would like to figure out why it's failing for you and fix it. Can you please send a stripped down version of your deploy.rb file that is failing so I can use it as a test case to get this fixed asap? I have been using these new changes for a while now with and without ssh keys and have had no issues. So I would like to see a small example of the recipe you have that is failing so I can fix it. Cheers- -- Ezra Zygmuntowicz-- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: [ANN] Capistrano 1.3.0
Hi~ On Dec 23, 2006, at 8:23 PM, Jamis Buck wrote: Here it is, Capistrano 1.3.0. Mostly it is just bug fixes, but it includes a few minor new features. The new features: * The sudo() method now supports an :as option, so that you can specify who the command should be executed as. This defaults to 'root'. * You can now encode the SSH user and port in the host specification, like: role :app, "[EMAIL PROTECTED]:1234" * You can create a .caprc file in your home directory, which will be loaded on every cap invocation. The syntax for it is exactly the same as any other recipe file. This lets you specify common tasks and configuration across multiple projects. The significant miscellaneous fixes: * Make sure all assets in images, javascripts. and stylesheets directories are touched when code is deployed, so that the asset- timestamping feature in Rails works correctly. (Otherwise, the timestamps on the assets can be different on each host, which totally defeats the purpose.) * cap setup and checkouts use group-writable permissions for new directories and files * cap/rake integration is now deprecated. You should be using 'cap' directly, unless you write your own rake tasks. So, give it a whirl! Have a Merry Christmas, all. - Jamis Sweet! Thanks for the xmas present Jamis. I'm glad you deprecated the rake integration as that aspect has confused quite a few people I have helped get up and running on cap. Long live the cap! Merry Christmas everyone- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Cap ssh ports patch
Jamis- No problem, thanks for applying it. And yes that last patch on the ticket was the one. Many thanks Jamis! Cheers- -Ezra On Dec 8, 2006, at 8:21 PM, Jamis Buck wrote: > > Ezra, > > My apologies for dropping the ball on that one. I just applied the > last patch in the list on that ticket--is that the one you meant? It > applied cleanly and the tests all pass. > > - Jamis > > On Dec 8, 2006, at 12:40 PM, Ezra Zygmuntowicz wrote: > >> >> Hey Jamis- >> >> Anyway I can get you too take one more look at the patch I submitted >> for using username and ports on the server hostname part of the >> roles. I found an edge case where net/ssh auth would fail if it >> didn't find a cert and tried to ask you for your password. It was >> only a one liner fix to get rid of this bug but the patch for it is >> still dangling. >> >> This means that cap trunk has a bug right now. If you get a chance >> please see this ticket and apply the patch if you can. If you need me >> to grab the latest trunk and make a new patch I can if that one is >> out of sync now. >> >> http://dev.rubyonrails.org/ticket/6547 >> >> Thanks! >> -- Ezra Zygmuntowicz >> -- Lead Rails Evangelist >> -- [EMAIL PROTECTED] >> -- Engine Yard, Serious Rails Hosting >> -- (866) 518-YARD (9273) >> >> >> >>> > > > > -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Cap ssh ports patch
Hey Jamis- Anyway I can get you too take one more look at the patch I submitted for using username and ports on the server hostname part of the roles. I found an edge case where net/ssh auth would fail if it didn't find a cert and tried to ask you for your password. It was only a one liner fix to get rid of this bug but the patch for it is still dangling. This means that cap trunk has a bug right now. If you get a chance please see this ticket and apply the patch if you can. If you need me to grab the latest trunk and make a new patch I can if that one is out of sync now. http://dev.rubyonrails.org/ticket/6547 Thanks! -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Re: Multiple ssh ports?
Jamis-
Great! Thanks for capistrano. And also thanks for all your great
blogging as of recently. Very nice to be able to read advanced rails
content like that. It is rare these days.
Thanks
-Ezra
On Nov 6, 2006, at 7:24 AM, Jamis Buck wrote:
> Ezra,
>
> This looks really good (as well as the recent addition to the
> ticket where the username can be encoded as well). I'll apply it
> today, as soon as the Monday-morning issues at work die down. :)
>
> - Jamis
>
> On Nov 4, 2006, at 11:15 PM, Ezra Zygmuntowicz wrote:
>
>>
>>
>> On Nov 3, 2006, at 12:12 PM, Jamis Buck wrote:
>>
>>>
>>> On Nov 3, 2006, at 1:10 PM, Jamis Buck wrote:
>>>
>>>> Ezra,
>>>>
>>>> Capistrano is currently extremely opinionated on this point. There
>>>> is setting anywhere you can tweak to make Capistrano use different
>>>> SSH
>>>
>>> Gah. That should be "There is NO setting anywhere..."
>>>
>>> - Jamis
>>>
>>
>> Hey Jamis-
>>
>> I was able to come up with a 3 line patch that allows for multiple
>> ports. All current tests still pass and backwards compatibility is
>> completely retained. This patch allows for this syntax for defining
>> roles as well as the old syntax and you can intermix the two and
>> still use ssh_options[:port].
>>
>> role :web, "65.74.169.199"
>> role :app, "65.74.169.199:8029", "65.74.169.199:8030",
>> "65.74.169.199:8031", "65.74.169.199:32"
>> role :prod_slave, "65.74.169.199:8030"
>> role :db, "65.74.169.199", :primary => true
>>
>> ssh_options[:port] =
>>
>> ssh_options[:port] will be over-ridden for any host that has :PORT
>> as part of the string. And any IP's or hostnames that do not
>> have :PORT in them will use the ssh_options[:port] num or 22 if this
>> is not set.
>>
>>
>> Does this seem like an exceptable patch Jamis? I am happy to make it
>> a capistrano extension if you don't think it belongs in core cap. But
>> using "hostname.com:7555" seems like something that should "just
>> work" with cap so I would love to see this make it in.
>>
>> Should I submit this to the rails track as a [PATCH] ticket?
>>
>> Thanks you so much for capistrano. It makes my life a lot easier
>> maintaining hundreds of Xen instances ;)
>>
>>
>> ez capistrano $ svn diff
>> Index: lib/capistrano/ssh.rb
>> ===
>> --- lib/capistrano/ssh.rb (revision 5430)
>> +++ lib/capistrano/ssh.rb (working copy)
>> @@ -27,7 +27,9 @@
>> :password => password_value,
>> :port => port,
>> :auth_methods => methods.shift }.merge
>> (config.ssh_options)
>> -Net::SSH.start(server,ssh_options,&block)
>> +Net::SSH.start((server.gsub(/:(\d+)$/,'') || server),
>> + ($1 ? ssh_options.merge({:port=>$1}) :
>> ssh_options),
>> + &block)
>> rescue Net::SSH::AuthenticationFailed
>> raise if methods.empty?
>> password_value = config.password
>>
>>
>> ez capistrano $ rake test
>> (in /Users/ez/_engine_yard/capistrano)
>> /usr//bin/ruby -Ilib -rubygems "/usr//lib/ruby/gems/1.8/gems/
>> rake-0.7.1/lib/rake/rake_test_loader.rb" "test/actor_test.rb" "test/
>> command_test.rb" "test/configuration_test.rb" "test/ssh_test.rb"
>> "test/scm/cvs_test.rb" "test/scm/subversion_test.rb"
>> Loaded suite /usr//lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/
>> rake_test_loader
>> Started
>> .
>> ...
>>
>> Finished in 0.027193 seconds.
>>
>> 84 tests, 161 assertions, 0 failures, 0 errors
>>
>>
>> Cheers-
>>
>> -- Ezra Zygmuntowicz-- Lead Rails Evangelist
>> -- [EMAIL PROTECTED]
>> -- Engine Yard, Serious Rails Hosting
>> -- (866) 518-YARD (9273)
>>
>>
>>
>>
>> >>
>
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: Multiple ssh ports?
On Nov 3, 2006, at 12:12 PM, Jamis Buck wrote:
>
> On Nov 3, 2006, at 1:10 PM, Jamis Buck wrote:
>
>> Ezra,
>>
>> Capistrano is currently extremely opinionated on this point. There
>> is setting anywhere you can tweak to make Capistrano use different
>> SSH
>
> Gah. That should be "There is NO setting anywhere..."
>
> - Jamis
>
Hey Jamis-
I was able to come up with a 3 line patch that allows for multiple
ports. All current tests still pass and backwards compatibility is
completely retained. This patch allows for this syntax for defining
roles as well as the old syntax and you can intermix the two and
still use ssh_options[:port].
role :web, "65.74.169.199"
role :app, "65.74.169.199:8029", "65.74.169.199:8030",
"65.74.169.199:8031", "65.74.169.199:32"
role :prod_slave, "65.74.169.199:8030"
role :db, "65.74.169.199", :primary => true
ssh_options[:port] =
ssh_options[:port] will be over-ridden for any host that has :PORT
as part of the string. And any IP's or hostnames that do not
have :PORT in them will use the ssh_options[:port] num or 22 if this
is not set.
Does this seem like an exceptable patch Jamis? I am happy to make it
a capistrano extension if you don't think it belongs in core cap. But
using "hostname.com:7555" seems like something that should "just
work" with cap so I would love to see this make it in.
Should I submit this to the rails track as a [PATCH] ticket?
Thanks you so much for capistrano. It makes my life a lot easier
maintaining hundreds of Xen instances ;)
ez capistrano $ svn diff
Index: lib/capistrano/ssh.rb
===
--- lib/capistrano/ssh.rb (revision 5430)
+++ lib/capistrano/ssh.rb (working copy)
@@ -27,7 +27,9 @@
:password => password_value,
:port => port,
:auth_methods => methods.shift }.merge
(config.ssh_options)
-Net::SSH.start(server,ssh_options,&block)
+Net::SSH.start((server.gsub(/:(\d+)$/,'') || server),
+ ($1 ? ssh_options.merge({:port=>$1}) :
ssh_options),
+ &block)
rescue Net::SSH::AuthenticationFailed
raise if methods.empty?
password_value = config.password
ez capistrano $ rake test
(in /Users/ez/_engine_yard/capistrano)
/usr//bin/ruby -Ilib -rubygems "/usr//lib/ruby/gems/1.8/gems/
rake-0.7.1/lib/rake/rake_test_loader.rb" "test/actor_test.rb" "test/
command_test.rb" "test/configuration_test.rb" "test/ssh_test.rb"
"test/scm/cvs_test.rb" "test/scm/subversion_test.rb"
Loaded suite /usr//lib/ruby/gems/1.8/gems/rake-0.7.1/lib/rake/
rake_test_loader
Started
Finished in 0.027193 seconds.
84 tests, 161 assertions, 0 failures, 0 errors
Cheers-
-- Ezra Zygmuntowicz
-- Lead Rails Evangelist
-- [EMAIL PROTECTED]
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)
--~--~-~--~~~---~--~~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~--~~~~--~~--~--~---
[Capistrano] Re: Multiple ssh ports?
On Nov 3, 2006, at 12:12 PM, Jamis Buck wrote: > > On Nov 3, 2006, at 1:10 PM, Jamis Buck wrote: > >> Ezra, >> >> Capistrano is currently extremely opinionated on this point. There >> is setting anywhere you can tweak to make Capistrano use different >> SSH > > Gah. That should be "There is NO setting anywhere..." > > - Jamis > Ok thanks Jamis. I will dig in and see what I can come up with. -- Ezra Zygmuntowicz --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
[Capistrano] Multiple ssh ports?
Hello~ I am using capistrano to build Xen VM's with the whole rails stack on them. I need to build a ton of these and would like to do it in parallel cap style. The catch is that ssh access to all these VM's is through the same IP address but each one is on a different ssh port number. Is there anyway to tell cap to use a different port number for each VM I am trying to build? It seems like cap caches the ssh_options[:port] and uses only the one port for all connections. IS this hard coded in cap somewhere? Can you give me a pointer to how to go about adding multiple ssh port functionality to cap? I am happy to make a patch and contribute it back. Thanks- -- Ezra Zygmuntowicz -- Lead Rails Evangelist -- [EMAIL PROTECTED] -- Engine Yard, Serious Rails Hosting -- (866) 518-YARD (9273) --~--~-~--~~~---~--~~ To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/capistrano -~--~~~~--~~--~--~---
