I wasn’t able to find this functionality in rails to begin with, so I
wrote a small wrapper to allow you to provide direct IRB shell access
into any long running app (for debug purposes, or as a way to control a
remote machine).
In your app, just require irb/server.rb (http://pastie.caboo.se/58859),
then run irb/client.rb (Parked at Loopia), passing it the
DRb url.
This allows me to run an IRB window on my local machine, with access to
the currently running rails app on my server.
Hope you find it useful…
Interesting… although it sounds a bit insecure since you don’t
authenticate and it’s being run in the clear over the wire.
I wonder if there’s a way to get ruby to tunnel this via ssh.
On Saturday 05 May 2007 04:39, eden li wrote:
Interesting… although it sounds a bit insecure since you don’t
authenticate and it’s being run in the clear over the wire.
I wonder if there’s a way to get ruby to tunnel this via ssh.
ssh remote host
irb
or is it to simple for you?
but well it’s insecure - but you can always add authentication and do it
over
ssl
On 5/5/07, eden li [email protected] wrote:
Interesting… although it sounds a bit insecure since you don’t
authenticate and it’s being run in the clear over the wire.
I wonder if there’s a way to get ruby to tunnel this via ssh.
Unless ruby sends address information on the application layer (as
e.g. Corba does or in redirects) you can do ssh port forwarding.
Let you IRB server serve on server:4242, assuming an ssh server
listening on port 22 on the server and a user ruby just do the
following on the client machine
ssh -fNL 2222:localhost:4242 ruby@server # (1)
do not forget to kill the ssh process on the client eventually.
The ruby client connects to localhost:2222 on the client machine now.
(1) N.B. localhost is localhost at the server.
HTH
Robert
Nice, looks like this would work. Just have to make sure that 4242 is
firewalled or only bound to lo on the server side.
As far as I can tell, all traffic is tunneled via SSH, so unless
something is on your machine (or your server) sniffing your loopback
device (or unless my understanding of how tunneling works), it should
be totally protected.
Yes 
The cool thing about this is you can get an irb shell right
into the ruby process running rails, which means you can do all sorts
of useful stuff like twiddling class variables and inspecting your
controller states directly.
Probably a bad idea to do this in production, but could be useful
during development.
On 5/6/07, eden li [email protected] wrote:
Nice, looks like this would work. Just have to make sure that 4242 is
firewalled or only bound to lo on the server side.
As far as I can tell, all traffic is tunneled via SSH, so unless
something is on your machine (or your server) sniffing your loopback
device (or unless my understanding of how tunneling works), it should
be totally protected.
Careful here, in our case everything is encrypted, but
if the port forwarding is forwarding a port from a different machine
that is not the case. Look at this command
ssh -fNL 4141:dbhost:mysqlport ruby@ssh-server
all traffic between the client and ssh-server is encrypted but the
forwarded traffic between ssh-server and dbhost is not.
I guess you are aware of that but not everybody is, nor was I before
warned by a colleague.
That still often is what you want especially if dbhost is in a DMZ, of
course.
Robert
Eden Li wrote:
Yes The cool thing about this is you can get an irb shell right
into the ruby process running rails, which means you can do all sorts
of useful stuff like twiddling class variables and inspecting your
controller states directly.
Probably a bad idea to do this in production, but could be useful
during development.
Precisely. It’s not intended to be exposed remotely. I’ve no idea what
DRb’s ACL stuff offers etc, but that could be looked at.
The idea was to be able to execute code inside a running ruby
application. Initially this was because I had rails running as a windows
service, and wanted to debug the different environment.
One of the things my (internal) rails app does though, is being a job
process monitor, for scripts largely written in ruby. I can set some
flag, that allows me to not just hook into and monkey patch rails live
:), but also to capture exceptions in a running job, and rescue it
providing this sort of simplistic remote debugging.
At any rate, while it was easy to write, it seems a few things didn’t
work with DRb as I thought they should.
I would’ve imagined that I could simply pass a local
ReadlineInputMethod, and StdioOutputMethod to the remote IRB::Irb#new,
but in fact that still did both input and output remotely - hence the
kind of cumbersome proxies.
Remote output still didn’t work, but that seems to be an IRB issue.