Web remote control

January 21, 2008 1:51 PM

Best web server/language for running remote tasks?

I have some console scripts/executables that I'd like to be able to run on my home machine via a web site. What is the best method to do so?

I have tried using Apache/PHP and trying exec(), shell_exec(), system(), running perl scripts and exe's, but keep running into small quirks, ie. not grabbing script output, not running at all, hanging, etc.

I'd also like some interaction between the scripts and the web pages, ie. form variables as parameters.

Is there a recommended way to do this? This is on a windows system. I am using XAMPP but am open to using any software/language.

posted by mphuie to computers & internet (9 comments total)

I would break this task into two pieces. Before you worry about the Web piece, work out a bulletproof way (with perl or whatever you like) of running your console commands using only standard input and standard output. That is, have a perl script that can run your target command via a pipe, providing all input from a variable and capturing its output to a variable, so you don't see anything on the screen or have to type anything.

In other words, I think your problem is that different Windows console apps interact with the console in different ways. Some of them may use standard input and output, some may use more-specific Windows things that your Web tools aren't understanding. Building a "driver" script will let you troubleshoot those problems without the whole Web server getting in the way.

Once you have that working, you can kick the driver script off from the Web using PHP, Perl, or pretty much anything.
posted by pocams at 2:07 PM on January 21, 2008

I think what I would do is have whatever your web language is write some file - say, an XML file - containing the instructions for what you want executed. Then have some process that polls for that file every ten minutes or so, reads it in, and executes the actual scripts. You could handle the polling with AT / Windows Task Scheduler, or write yourself a Windows Service if you're feeling ambitious. The full versions of the Windows development tools have little wizards that will spit you out a Windows Service, but it might also be possible to do this with the free versions and code samples or tutorials you find on the web.

With a two-part architecture like this you should avoid most security issues. Because it should be difficult to run an arbitrary executable remotely via the web - the OS should prevent things like this by default.
posted by XMLicious at 2:29 PM on January 21, 2008

Pocams: thats what I was thinking but I figured there was a more elegant way.

XMLicious: I'd like to run the script on the spot and be able to show its output (or a parsed text file of its output). I'm not exactly running arbitrary executables via the web, only ones that are already on the server.
posted by mphuie at 2:41 PM on January 21, 2008

Isn't this the very definition of what RPC was invented for?
posted by AmbroseChapel at 4:03 PM on January 21, 2008

Oops!

That's RPC. Sorry.
posted by AmbroseChapel at 4:04 PM on January 21, 2008

Ruby ships with its own webserver (Webrick), and has things like Backgroundrb specifically for running potentially long running things in the background with webapp integration, though of course there's also backticks (`foo.exe` # => "output from foo.exe")/system()/popen/etc.

While everyone's all about Rails when it comes to Ruby web development, I'd suggest something lighter; either a simple Rack adaptor, or something like Ramaze, Merb, or possibly Camping.
posted by Freaky at 5:20 PM on January 21, 2008

remember that http is unencrypted; anyone sniffing your traffic will be able to do whatever you are doing, including picking up any userid and password you are using to secure the application. Make sure you do everything via https / ssl (which can be a pain to set up; you'll need to generate your own certificate and key).

I'd recommend using the freeSSHD daemon; this lets you ssh into a windows box and run stuff right in the command shell. It's a free download, and it's ssh, so it's reasonably secure. Putty is a pretty good ssh client for windows.
posted by jenkinsEar at 8:32 PM on January 21, 2008 [1 favorite has favorites]

Personally, I would write CGI scripts in perl to wrap the system commands you want to do, sanitizing all the input as appropriate. That's mainly because it's what I'm used to - YMMV.

From the sounds of it though you want 2 things.. you have a public website, and some code to run on your home computer.
The elegant way would be to set up the perl (or whatever) CGI scripts on your home PC + a webserver to act as web-services, then have that open only to the public webserver to call those functions as necessary.
posted by TravellingDen at 8:55 PM on January 21, 2008

I'm not exactly running arbitrary executables via the web, only ones that are already on the server.

That IS running an arbitrary executable. If you're trying to open up a way to run any executable on the box, certainly any attacker who gained the same ability could use that to download and execute anything whatsoever (ftp.exe is already on the box too, for example.)

I'm not saying it would be impossible, I'm just saying that everything is going to be set up to avoid the slightest possibility of this successfully working by accident. So you would probably need to thoroughly understand all of the security measures in the scripting language, web server, filesystem, and OS to properly disable everything, which will most likely be a huge pain in the butt.

jenkinsEar has the best point here, I think. A lower-security alternative to SSH is telnet and there's a telnet client on every Windows box (Of course most Linux (and OSX?) clients will probably have both telnet and SSH clients already). There's also Remote Desktop Web Connection if you'll always be doing this from Windows clients.
posted by XMLicious at 6:57 AM on January 22, 2008