Vlad the D. - help and observations

G

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:in `execute'
/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:in `execute'
/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:in `each'
/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:in
`invoke'
/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:in
`invoke'
/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:in
`each'
/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:in
`standard_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:in `run'
/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:in `run'
/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
 
G

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
 
G

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
 
G

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
 
W

Wilson Bilkovich

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.
 
G

goodieboy

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

Matt
 
E

Eric Hodel

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.)
 
M

Marcin Raczkowski

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
 
E

Eric Hodel

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

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.
 
M

Marcin Raczkowski

Eric said:
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

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.

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top