Vlad the D. - help and observations

[goodieboy]

Hi,

I started using VD recently just to compare the differences with Cap.
Here goes:

I like the idea, but where do you get support? Is there a google
group? So far, nothing compares to the support Jamis B. puts out on
his own. Not knocking you VD people, just a plug for Jamis!

You guys really hype it up! Wow. It’s not THAT much more simple than
Cap.

I like the idea of it being lightweight!

Why do you have mongrel code/paths mixed in with core.rb, when you
also have a separate mongrel.rb “app” recipe file? Why not put it all
in mongrel.rb? Becuase I don’t use Mongrel, but there are things I can
use in core.rb; but I have to override :update and :setup_app because
they have mongrel/rails specific paths etc…

And the same for migrate? Why is that in core.rb? If my vote counted
I’d vote to move :migrate and :update out of the core. They’re very
app specific. Everything else is very general and could be used by any
app.

I think that Cap uses a SSH session, not so with VD. If you don’t have
a key/agent setup, you’re typing your password over and over. That’s
not simple

When trying to do a rollback, it asks me if I want to delete the
symbolic link for “current”. I type “yes”, I get an infinite hang.
Bummer. How can I get this to just work without typing in “yes” or
“y”. And obviously, how do I get it to NOT hand on me? I’ve posted the
error stack below…

Why is the fetch method not global like set? Is that just missing for
now?

Other than that, I like it. Good work! Depending on what kind of help/
feedback I get here, I may start using it.

Thanks,
Matt

Hang when doing rollback error stack:

rake aborted!

/opt/local/lib/ruby/gems/1.8/gems/vlad-1.1.0/lib/rake_remote_task.rb:
534:in join' /opt/local/lib/ruby/gems/1.8/gems/vlad-1.1.0/lib/rake_remote_task.rb: 534:inexecute’
/opt/local/lib/ruby/gems/1.8/gems/vlad-1.1.0/lib/rake_remote_task.rb:
534:in each' /opt/local/lib/ruby/gems/1.8/gems/vlad-1.1.0/lib/rake_remote_task.rb: 534:inexecute’
/opt/local/lib/ruby/gems/1.8/gems/vlad-1.1.0/lib/rake_remote_task.rb:
143:in execute' /opt/local/lib/ruby/gems/1.8/gems/vlad-1.1.0/lib/rake_remote_task.rb: 143:ineach’
/opt/local/lib/ruby/gems/1.8/gems/vlad-1.1.0/lib/rake_remote_task.rb:
143:in execute' /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:362:ininvoke’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:in
synchronize' /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:355:ininvoke’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in
top_level' /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:ineach’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1739:in
top_level' /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:instandard_exception_handling’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1733:in
top_level' /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1711:inrun’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1761:in
standard_exception_handling' /opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/lib/rake.rb:1708:inrun’
/opt/local/lib/ruby/gems/1.8/gems/rake-0.7.3/bin/rake:7
/opt/local/bin/rake:16:in `load’
/opt/local/bin/rake:16

[goodieboy]

Just an update here…

I found a problem. It was related to my login setup on the remote
server. Whenever I issued a remote command, the first line in returned
from the server was always: “stty: standard input: Invalid argument” -
This was caused by some weirdness in my .tcshsrc file. I fixed that…

Before I fixed it though, :previous_release would add “standard” to
the end of the path like:
/usr/local/projects/abonline-rake/releases/standard

Because the last line will have what you want, how about:

set(:releases) { task.run(“ls -x
#{releases_path}”).split("\n").last.split.sort }

Matt

[goodieboy]

And to get the hang to stop… in the :rollback task, I added the -f
flag to rm like:

run “rm -f #{current_path}; ln -s #{previous_release} #{current_path}
&& rm -rf #{current_release}”

That seems to work!

Matt

[goodieboy]

Also, where can I find a very clear description/docs for the
following: host, role

I get what domain is, a single host (role?) but I’m just not clear on
host v.s. role is?

Matt

[goodieboy]

On 9/26/07, goodieboy [email protected] wrote:

Also, where can I find a very clear description/docs for the
following: host, role

I get what domain is, a single host (role?) but I’m just not clear on
host v.s. role is?

See migration.txt, included with Vlad. It addresses some of your other
questions, as well. That being said:
‘host’ and ‘role’ result in the same config. I added ‘host’ because I
had often found myself doing this in Capistrano for simple apps:
set :domain, “example.com”
role :app, domain
role :web, domain
role :db, domain

‘host’ lets you specify multiple roles, so those four lines can be
written as:
host “example.com”, :app, :web, :db

Otherwise, they are identical. One lets you declare entries
‘host-wise’, and the other ‘role-wise’.

Check out the ‘doco’ directory in the Vlad distribution. If you find
anything that is missing, if you could file a documentation bug at the
RubyForge tracker, that would be very helpful.
http://rubyforge.org/tracker/?atid=16258&group_id=4213&func=browse

Thanks for trying Vlad. Your feedback helps tell us what to improve.

[goodieboy]

On Sep 26, 2007, at 11:30 , goodieboy wrote:

I started using VD recently just to compare the differences with Cap.
Here goes:

I like the idea, but where do you get support? Is there a google
group? So far, nothing compares to the support Jamis B. puts out on
his own. Not knocking you VD people, just a plug for Jamis!

Right here is fine. Plus there’s a bug tracker. http://
rubyforge.org/tracker/?group_id=4213

Why do you have mongrel code/paths mixed in with core.rb, when you
also have a separate mongrel.rb “app” recipe file? Why not put it all
in mongrel.rb? Becuase I don’t use Mongrel, but there are things I can
use in core.rb; but I have to override :update and :setup_app because
they have mongrel/rails specific paths etc…

Which mongrel code/paths? I don’t see any in 1.1.0 …

And the same for migrate? Why is that in core.rb? If my vote counted
I’d vote to move :migrate and :update out of the core. They’re very
app specific. Everything else is very general and could be used by any
app.

core.rb is rails-specific and has rails stuff in it. It might make
sense to pull out vlad:invoke and vlad:debug into something like vlad/
utils.rb, but we’ve not had any requests for it (hint: feature
request tracker).

I think that Cap uses a SSH session, not so with VD. If you don’t have
a key/agent setup, you’re typing your password over and over. That’s
not simple

You mean you didn’t do that when you logged into your box the very
first time? What about when you need to upgrade some core package?
I simply can’t live without ssh-agent!

When trying to do a rollback, it asks me if I want to delete the
symbolic link for “current”. I type “yes”, I get an infinite hang.
Bummer. How can I get this to just work without typing in “yes” or
“y”. And obviously, how do I get it to NOT hand on me? I’ve posted the
error stack below…

You other mail said adding the -f flag fixed it, so its probably a
platform-dependent thing we didn’t run into on our test platforms.
Could you file a bug in the tracker?

Why is the fetch method not global like set? Is that just missing for
now?

Just missing for now, bug please?

Other than that, I like it. Good work! Depending on what kind of help/
feedback I get here, I may start using it.

Thanks! Hope you keep using it. (Please don’t feel put off by the
requests for bugs, we need those because we’ve got another couple
projects we’re working on and need the permanent reminder. Also, if
other people have similar questions, they can see if its already been
reported and fixed by searching in the tracker.)

[goodieboy]

You mean you didn’t do that when you logged into your box the very first
time? What about when you need to upgrade some core package? I simply
can’t live without ssh-agent!

ssh agent (that comes with putty) is (or at least was 1 y ago) there was
bunch of exploits for it.

In company i was working recently, we had to have keys with password
anyway :]

so mayby using sessions is better idea

[goodieboy]

Great. That explains it very clearly. Thanks! I’ll definitely keep
digging and post tickets.

Matt

[goodieboy]

Eric H. wrote:

hmmm, I have to say I’m not security expert myself, I only mentioned
what i was told by security experts in 2 of my previous companies.
I only wanted to give more reasons to use SSH sessions, i often have to
setup something on virtual machine just once, so i don’t use keys,
forcing someone to use them if there’s another way is strange.

Of course you do it for free, and that’s just polite request even if my
poor english skills don’t allow me to express myself clearly

so to sum up: if you can use sessions please don’t force us to use keys
everywhere

[goodieboy]

On Sep 27, 2007, at 14:51 , Marcin R. wrote:

so mayby using sessions is better idea
If you’re going to be paranoid about keys, passwords and security
your choice is between an SSH toolset written in a garbage collected
language (that may leave passwords and unencrypted keys available to
a debugger for “long” periods of time) used by thousands to tens of
thousands of users (Net::SSH) or an SSH toolset written in a manual
memory management library (that may leave passwords and unencrypted
keys available forever to a debugger due to leaks) with millions to
tens of millions of users (OpenSSH).

Even if you aren’t using OpenSSH’s ssh-agent, you’ve still probably
got tens of thousands to hundreds of thousands of users to paranoidly
scour the code for security exploits.

I doubt that anybody has paranoidly scoured Net::SSH looking for ways
to pull your passwords and keys out of it. There certainly have been
people paranoidly scouring OpenSSH and putty’s code looking for
exploits.

This document contains forward-looking statements. Past
vulnerability is no guarantee of future vulnerability.