Rye::Box.new() :opt to use existing Rye::Box

[vbatts]

Effectively making a chain, but when there is a need to access a host, that is not directly accessible. In theory, something like host0 = Rye::Box.new(host='somehost') host1 = Rye::Box.new(host='otherhost', :chain_host =>host0)

[vbatts]

another way, it seems this could be approached, but is not working, is: j = Rye::Box.new(host='jellyroll', :properties => { "LocalForward" => "6666 192.168.1.5:22"} ) s = Rye::Box.new(host='localhost', :port => '6666')

after inspecting netstat -tanup | grep 6666, then listener does not appear to be created.

[delano]

This is possible to do using the net-ssh-gateway library. I don't have much time right now but I'd happily pull in a patch.

[vbatts]

i'll poke on it. Net::SSH::Service::Forward looks promising. Maybe if there could be a method to access is, like there is with a Net::SSH::Session object.

[vbatts]

so delano, in working on a patch to merge this functionality in, would you rather: a) have a separate class, like Rye::Gate, that would serve as the gateway. b) extend the Rye::Box class to be able to serve as a gateway itself.

in either method, the Rye::Box should have opts and attributes like 'via', that would expect an object that is_a?(Net::SSH::Gateway) type. In option "a", there is a little bit of redundancy. in option "b", there would be an opt and methods to enable/disbable a Rye::Box as a gateway. There would be a fair amount of if/then cases for how to handle connections. One benefit of just extending the Rye::Box would be, that it would be easier to enable access to a host that is more than one layer separated. For example:

g1 = Rye::Box.new("my.firewall.awesome.com", :gateway => true) g2 = Rye::Box.new("192.168.1.1", :gateway => true, :via => g1) host = Rye::Box.new("10.10.0.57", :via => g2)

i'm in the middle of merging changes from the Rye::Gate model into the extended Rye::Box model, so let me know what you would favor.

Take care, vb

[delano]

Very nice. The Rye::Gate model is probably better. There is a little redundancy but it will be cleaner overall and make it more obvious that that object is specifically meant to be a gateway and not an endpoint itself. I like the :via option.

We'll need to call the class something else though. It needs to fit the arbitrary convention of using 3 characters. Maybe Rye::Way?

[vbatts]

as for the name, i was thinking that Rye::Hop would work nicely for the three character name. i little hickup in the Net::SSH::Gateway, that i'd like your thoughts on. The gateway.rb is relatively slim, and just utilizes the Net::SSH::Connection::Session#forward.local calls, which are already available in the current dependency set. The hickup is that gateway.rb sets a Mutex on the session and a Mutex on port forwarding, therefore limiting a gateway to only 1 (one) port forward. Just using the Net::SSH set, this is easily doable. It would be more appropriate for the Net::SSH::Gateway to build a thread pool of port forwards, and just add to them additional forwards (in a non-blocking approach). So the dilemma is whether to code a Rye::Hop at first with the Net::SSH::Gateway dependency, with the caveat that a Hop can only handle a single Box at a time. You'd have to instantiate another Hop for the same gateway, to get another Box to go through. In the meantime, patch and submit to the Net::SSH::Gateway team to not do a port Mutex, and instead do a thread pool of forwards. OR have no added dependencies, and build an implementation of port forward pools for the Rye::Hop class. (this is which one i am greatly favoring :)

Thanks for your thoughts.

Take care, vb

[delano]

Rye::Hop, love it.

I agree with you: the best way forward is to implement it within Rye::Hop. It would be a pretty significant change to Net::SSH::Gateway ad there are a lot of people using it as it is with the mutex limitation (I'm the maintainer for the Net::SSH libs as well and I haven't received any requests to make a change like this).

This gateway support is going to be awesome.

[vbatts]

alrighty, i've got a working prototype at git://github.com/vbatts/rye.git i've started some of the documentation, and cleanup. but check it out if you will, let me know where i can go next on getting this to your like'ing

[delano]

Hey man, it's looking good! You were right about the duplication, but it's not too bad.

Have you tried running the tests? You just need to install tryouts (2.0.x) and run try.

[vbatts]

cool. i learned something new! that tryouts is a pretty brief testing suite. i've added a test for it, and it expressed a Timeout related condition that i fixed as well. as far as the redunancy, it would seem cleanest to have a super class, and then Rye::Box and Rye::Hop would just extend and customize. But that would be a big overhaul.

[delano]

Awesome. I pulled the changes and tested it in my current infrastructure. Tryouts pass for 1.8 and 1.9. Looks ready to go to me. Do you want to make any other additions/changes? Otherwise I'll go ahead and create the 0.9.3 release.

[vbatts]

Looks good to me. I'll close out this ticket as well.

Take care, vb

[delano]

I just pushed the 0.9.3 release: https://github.com/delano/rye/tree/v0.9.3

It should be available on Rubygems now. I'll wrote a quick post on my blog: http://solutious.com/blog/2011/01/29/rye-hop-gateway-support/

Thanks for the great work!