XPost: comp.unix.programmer

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 !!!!!!!!!!!

ʕʘ̅͜ʘ̅ʔ

ʕʘ̅͜ʘ̅ʔ

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)