CGI to Telnet Interprocess Fun Stuff

[Pedro Picasso]

I'm doing a project for the big boss here at work. Basically he wants to access a telnettable machine somewhere and pass it commands from a cute looking web form.

i.e. I click the "Turn 'A' On" checkbox on a form and submit, and the CGI perl script telnets to the remote machine, passes the "turnon -function A" command, then gathers the output from that command to display on the returned HTML.

Thanks to the wonders of CGI and Net::Telnet, this works wonderfully, but slowly. Initiating a telnet session during every page load sucks even if I'm the only one using it.

What I'd like to do is have a Perl telnet program running a constant session and message it with I/O from my CGI script when the need arises.

Most of the interprocess tips that I read have to do with open(), exec(), and system(), but I need a way to have a constant session running instead of generating one all the time, and these don't help.

I've got one server running Apache mod_perl under NT, and another running it under RedHat, so I can do Unix/Win32 specific things if need be. I'd like to avoid writing my own Apache module unless it's absolutely necessary.

Help me Obi-Monks Kenobi. You're my only hope!

-the Pedro Picasso
(sourceCode == freeSpeech)

[Everlasting God]

Well, if security isn't much of a concern (and it looks like it isn't if a webpage is gonna be performing telnet commands...) I would suggest a daemon process running the telnet session and listening on some predefined socket, preferably unix domain. Then, whenever it gets some data on that socket it can do it's thing in the telnet session, preferably with a little data laundering.
Might also be a good idea for the daemon to time out after some long time, and have the client cgi check to see if it's listening on the socket, and if not start the daemon again. That way, there won't always be a telnet session open.

'The fickle fascination of and Everlasting God' - Billy Corgan, The Smashing Pumpkins

[jeffa]

EEK! that's a big security hole you are digging. But i won't bog you down with why i think this is a bad idea.

Instead I will point you to SOAP::Lite. You could write a server that keeps a persistant connection (via SOAP::Transport::HTTP::Daemon) to a Net::Telnet session. The client would then call the server with a command and print the results back to the browser:

diagram:

-------------    -------------    ------------    ---------
|Net::Telnet|<-->|SOAP Daemon|<-->|web script|<-->|browser|
-------------    -------------    ------------    ---------

This is just a suggestion - i have not actually written anything like this myself . . . but i think this is definately do-able. The big question is - WHY!?! It's horribly unsafe!

jeffa

[trantor]

From what I understand, security is not a concern in your case.

You may want to have a look at Net::Rexec which does what you want without the burden of opening and closing a telnet session each time.

It's considered highly insecure, but in these time of cut-and-paste hackers a telnet daemon is not any better.

For a more secure and pragmatic approach, have a look at ssh support for Perl.

I haven't tried these modules for secure authentication and remote command execution, but the ssh command allows that, and so may this code.