Executing an interactive shell script remotely from a web GUI

Question

There's a requirement in my project to execute interactive shell scripts remotely through a web GUI. This means that stuff printed to the standard output of the script has to be made available on the GUI, and the user input has to be taken from the GUI and written to the standard input of the script.

My questions are (a) Is this is a good idea (setting aside for the moment the fact that it is a requirement)? (b) Has anybody solved this kind of problem before? If yes, what's the 'best' way to go about it?

EDIT #1: The scripts to be executed are not located on the same host as the web server.

EDIT #2:

Thanks for your responses! I'm afraid that browser-side solutions won't fit my purpose because the user can start off one or more scripts, could close the browser, come back after sometime to check on the scripts' outputs and provide input.

The design I've come up with involves storing the output of the scripts to different files and when the user fires up the browser it starts to read from the files and keeps polling it (via Ajax) until the scripts have finished executing.

Answer 1

Sounds like CGI

Answer 2

It is probably not a great idea. Interactive shell scripts are not usually executed through web pages...

but of course it is possible.

Instead think of what you want to accomplish and make a nice UI that is comprised of standard web components. Maybe you could build something that works like a "wizard"?

Answer 3

Seems like you need some sort of background process for this to work. You cannot do it from a single script, because while such a script is running - the browser thinks it is loading the page. If this takes longer than it anticipates, it aborts and states that. "Server took too long to respond"

So in fact you need to spawn/fork a separate process, and make periodical requests from client-side to the server, which will cause server side script to connect to the process and exchange messages with it.

See phpterm for example.

Answer 4

Perhaps you have reasons not to consider it, but what about a web-based shell into the server? e.g. AjaxTerm (http://antony.lesuisse.org/software/ajaxterm/)

As I recall, you can configure what user account it can login as, and then you can apply the usual controls to limit what scripts that user can run (or chroot?).

After all, if you want to run a shell script, why not use a shell? :)

Answer 5

The answer to this should be cron, but cron is so dated. Theoretically your Web GUI could schedule these one time (batch) jobs into cron, and then cron would manage them and have a "hook" you provided to run to give the answer back to you -- like loading it into a database.

To my knowledge, the way to schedule one time batch jobs with cron is silly, and then getting the output back is as sophisticated as getting an email.

Your task is really a subset of "build automation" and "continuous integration", see the free software solutions -- CruiseControl and Hudson -- for ideas.

Answer 6

You could use Expect to mimic the user starting the process as a nohup or background job, logging out, then periodically logging back into check on its logfiles or provide input.