Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming > #14381 > unrolled thread

a kind of a web-shell-api for managing long running processes

Back to article view | Back to comp.programming

Contents

  a kind of a web-shell-api for managing long running processes Meredith Montgomery <mmontgomery@levado.to> - 2021-12-30 17:16 -0300
    Re: a kind of a web-shell-api for managing long running processes Härra Ramob <he6655442211@hotmail.com> - 2022-01-03 01:21 -0800
    Re: a kind of a web-shell-api for managing long running processes Julio Di Egidio <julio@diegidio.name> - 2022-01-03 05:45 -0800

#14381 — a kind of a web-shell-api for managing long running processes

I'm helping someone to improve a CMS-type of web system.  This web
system sometimes needs to run some background processes --- such as send
a batch of e-mail or other process that takes a while to finish.

I see the challenge here as just writing something that will look like a
very basic UNIX shell --- so I'll call it ``web-api-shell'' from now on.
(``Web'' because it will be used by a web system through some API.)

This thing must run really well.  It has to be flawless.  I'm looking
for design principles and advice.

(*) Where will it run

It will run on GNU systems running the Linux kernel.

(*) My own thoughts

The interface to shell will be through HTTP requests, so this shell will
likely be a web server of some sort.  But before I get involved in the
web at all, I need the shell working flawlessly.

So I need a laboratory first.  I could write a program that reads some
named pipe on disk to get commands such as ``run this or that'' while I
work.  (Later I can write a web server replacing this named-pipe
interface.)

Just like a UNIX shell, this web-api-shell must know all every process
it runs.  I suppose the work is essentially fork(), execve() followed by
waitpid().

One concern I have is the following.  Is it possible for a process to
simply ``get out of'' the shell?  What do I mean by that?  A process
that does fork() and puts itself into background would leave the
web-api-shell's control, wouldn't it?

I think I must avoid that.  Perhaps I can't let just any process run.
Perhaps the web-api-shell must only offer a few processes carefully
written by myself --- so that I know they won't put themselves in
background.  (For instance, I can't let them change PIDs, otherwise I
won't have any idea who they are and that's a mess.  I'd love to somehow
restrict system calls such as fork().)

(*) What is my level of training?

In the past I've studied many parts of

  Advanced Programming in the UNIX Environment
  W. Richard Stevens

I will definitely have to read it again to get work on this project.
Can you mention any UNIX concepts that are of great relevance for this
project?  I don't think I ever got my mind wrapped around things like
sessions, session leaders and so on.  Are these concepts relevant to
this application?

Thank you very much.

[toc] | [next] | [standalone]

#14402

Meredith Montgomery kirjutas Neljapäev, 30. detsember 2021 kl 22:18:55 UTC+2:
> I'm helping someone to improve a CMS-type of web system. This web 
> system sometimes needs to run some background processes --- such as send 
> a batch of e-mail or other process that takes a while to finish. 
> 
> I see the challenge here as just writing something that will look like a 
> very basic UNIX shell --- so I'll call it ``web-api-shell'' from now on. 
> (``Web'' because it will be used by a web system through some API.) 
> 
> This thing must run really well. It has to be flawless. I'm looking 
> for design principles and advice. 
> 
> (*) Where will it run 
> 
> It will run on GNU systems running the Linux kernel. 
> 
> (*) My own thoughts 
> 
> The interface to shell will be through HTTP requests, so this shell will 
> likely be a web server of some sort. But before I get involved in the 
> web at all, I need the shell working flawlessly. 
> 
> So I need a laboratory first. I could write a program that reads some 
> named pipe on disk to get commands such as ``run this or that'' while I 
> work. (Later I can write a web server replacing this named-pipe 
> interface.) 
> 
> Just like a UNIX shell, this web-api-shell must know all every process 
> it runs. I suppose the work is essentially fork(), execve() followed by 
> waitpid(). 
> 
> One concern I have is the following. Is it possible for a process to 
> simply ``get out of'' the shell? What do I mean by that? A process 
> that does fork() and puts itself into background would leave the 
> web-api-shell's control, wouldn't it? 
> 
> I think I must avoid that. Perhaps I can't let just any process run. 
> Perhaps the web-api-shell must only offer a few processes carefully 
> written by myself --- so that I know they won't put themselves in 
> background. (For instance, I can't let them change PIDs, otherwise I 
> won't have any idea who they are and that's a mess. I'd love to somehow 
> restrict system calls such as fork().) 
> 
> (*) What is my level of training? 
> 
> In the past I've studied many parts of 
> 
> Advanced Programming in the UNIX Environment 
> W. Richard Stevens 
> 
> I will definitely have to read it again to get work on this project. 
> Can you mention any UNIX concepts that are of great relevance for this 
> project? I don't think I ever got my mind wrapped around things like 
> sessions, session leaders and so on. Are these concepts relevant to 
> this application? 
> 
> Thank you very much.

Hey You !!!!!!!!!!!

ʕʘ̅͜ʘ̅ʔ

ʕʘ̅͜ʘ̅ʔ

[toc] | [prev] | [next] | [standalone]

#14403

On Thursday, 30 December 2021 at 21:18:55 UTC+1, Meredith Montgomery wrote:
> I'm helping someone to improve a CMS-type of web system. This web 
> system sometimes needs to run some background processes --- such as send 
> a batch of e-mail or other process that takes a while to finish. 
> 
> I see the challenge here as just writing something that will look like a 
> very basic UNIX shell --- so I'll call it ``web-api-shell'' from now on. 
> (``Web'' because it will be used by a web system through some API.) 
> 
> This thing must run really well. It has to be flawless. I'm looking 
> for design principles and advice. 

Depending on your requirements:

Maybe this, which is web-based access to the shell:
<https://www.tecmint.com/access-linux-server-terminal-in-web-browser-using-wetty/>

Or maybe something like these, which is controlled access to specific scripts/commands:
<https://www.cyberciti.biz/tips/executing-linuxunix-commands-from-web-page-part-i.html>
<https://www.instructables.com/Simple-linux-commands-from-a-web-page/>

See below for few comments on more complicated scenarios.

> (*) Where will it run 
> 
> It will run on GNU systems running the Linux kernel. 
> 
> (*) My own thoughts 
> 
> The interface to shell will be through HTTP requests, so this shell will 
> likely be a web server of some sort. But before I get involved in the 
> web at all, I need the shell working flawlessly. 
> 
> So I need a laboratory first. I could write a program that reads some 
> named pipe on disk to get commands such as ``run this or that'' while I 
> work. (Later I can write a web server replacing this named-pipe 
> interface.) 
> 
> Just like a UNIX shell, this web-api-shell must know all every process 
> it runs. I suppose the work is essentially fork(), execve() followed by 
> waitpid(). 
> 
> One concern I have is the following. Is it possible for a process to 
> simply ``get out of'' the shell? What do I mean by that? A process 
> that does fork() and puts itself into background would leave the 
> web-api-shell's control, wouldn't it? 
> 
> I think I must avoid that. Perhaps I can't let just any process run. 
> Perhaps the web-api-shell must only offer a few processes carefully 
> written by myself --- so that I know they won't put themselves in 
> background. (For instance, I can't let them change PIDs, otherwise I 
> won't have any idea who they are and that's a mess. I'd love to somehow 
> restrict system calls such as fork().) 
<snip>

If you offer web access to the terminal, a user can just do everything they could do directly at the terminal, so that problem does not exist.  If you instead offer a specific interface to run commands/scripts from a selected set that you (the programmer) have written, that problem does not exist either, as here it is you who control what runs and how.

It's in this latter case that things can get more complicated: if *you* need forking, then you need a more complicated client-server architecture, possibly with a daemon handling requests coming from a cgi script (over sockets, or named pipes, i.e. any IPC), and the daemon would also answer state info requests, so from the web client, via the cgi script, one would also be able to know how executions are progressing, terminating, etc.  But maybe you just don't need this much complication...

HTH,

Julio

[toc] | [prev] | [standalone]

Back to top | Article view | comp.programming

csiph-web