|
Grex > Coop11 > #51: Enabling CGI scripts for Grex users | |
|
| Author |
Message |
| 25 new of 59 responses total. |
mic
|
|
response 30 of 59:
| 
Mar 21 07:39 UTC 1999 |
You'll regret allowing CGI access.
|
ryan
|
|
response 31 of 59:
|
Mar 31 15:53 UTC 1999 |
This response has been erased.
|
aruba
|
|
response 32 of 59:
|
Mar 31 18:53 UTC 1999 |
How hard would it be to add that as a command you can give while waiting in
the telnet queue?
|
ryan
|
|
response 33 of 59:
|
Mar 31 19:50 UTC 1999 |
This response has been erased.
|
prp
|
|
response 34 of 59:
|
Apr 2 05:57 UTC 1999 |
(big) If I understand this, allowing users to run CGI scripts is
equivalent to allowing robots.
It would be reasonable to allow forms on web pages, and collect
all the data in a file. The user could then run whatever to
process the file.
It would also be reasonable to collect E-mail, as long as it is
sent to the owner of the web page.
|
remmers
|
|
response 35 of 59:
|
Apr 2 17:56 UTC 1999 |
CGI isn't quite equivalent to bots. A bot runs all the time; a CGI
script runs only when somebody clicks on something that activates it.
If I understand what you mean by "collecting E-mail", it's already
possible. The owner of the web page can put a <mailto:...> link on it.
Anybody can then click on the link to send the owner mail.
|
prp
|
|
response 36 of 59:
|
Apr 2 23:06 UTC 1999 |
Well, a CGI script wouldn't get started when Grex boots, but it would
the first time anyone, not just the owner, activates it. It could
then run forever, or at least until the system goes down.
|
davel
|
|
response 37 of 59:
|
Apr 3 14:21 UTC 1999 |
Or, quite probably, until the kill-orphans script kills it.
|
ryan
|
|
response 38 of 59:
|
Apr 3 14:21 UTC 1999 |
This response has been erased.
|
ryan
|
|
response 39 of 59:
|
Apr 3 14:24 UTC 1999 |
This response has been erased.
|
prp
|
|
response 40 of 59:
|
Apr 3 23:41 UTC 1999 |
So, what exactly is an orphan? And why do you need a script to kill them?
My guess would be that an orphan is a task/job/process with no connection
to a terminal and presumably a person watching it. But in that case, I
would assume that when a connection closes, the device driver gets notified
from the Internet and ends things. No need for an orphans script.
|
remmers
|
|
response 41 of 59:
|
Apr 4 12:35 UTC 1999 |
You're pretty much correct about what an orphan is. But your assumption
about closed connections is wrong. Under Unix, you can arrange to run a
process "nohup" -- i.e. to ignore that the connection has closed. Then
the process continues to run even after its controlling terminal has
gone away. That behavior is what makes unattended bots possible. Grex
has been running a "kill-orphans" task for a number of years now to
catch such things. Presumably, it would continue to catch them if
they're running as CGI's.
|
prp
|
|
response 42 of 59:
|
Apr 4 15:58 UTC 1999 |
I remember some system from way back when, where when a connection was
lost, the task was suspended for 30 minutes. If the owner logged in
within that time, it was possible to reconnect with the old task, rather
than starting a new one. That could be nice for Grex, given all the
trouble I have with dropped connections.
Barring that, it seems like the easy way would be to kill the orphans
when the connection is lost, rather than having a kill orphans script.
But then I don't have to program it.
|
drew
|
|
response 43 of 59:
|
Apr 4 20:25 UTC 1999 |
That, I think, was the computer at Wastern Michigan university. The command
was "attach" instead of login; it prompted for a password, then you could pick
up where you left off.
|
davel
|
|
response 44 of 59:
|
Apr 4 22:32 UTC 1999 |
nohup (and the various underlying system features that make it possible) are
pretty basic to the operating system. To try to disable them so that orphans
are always killed right away might be pretty hard ... and I'm not sure it
would be desirable anyway.
|
prp
|
|
response 45 of 59:
|
Apr 5 02:14 UTC 1999 |
After thinking about this, I'm more confused. Are you telling me that
on a standard Unix system, when someone hangs up the phone rather than
logging out, the task just stays around until someone kills it by hand?
That cann't be right.
If I remember right, Grex has a fifteen minute timer which automatically
logs people off when there has been no input. How does that work?
|
remmers
|
|
response 46 of 59:
|
Apr 5 09:40 UTC 1999 |
When you start up a background task on a Unix platform, you can arrange
for it to be immune to hangup signals. Or the task can make that
arrangement itself. In either case, the task will continue to run after
the user logs out normally or hangs up the phone. This is a standard
Unix feature; it would be described in almost any book on Unix
programming. For starters, you can read "!man nohup" on Grex to find out
how a user can run a task that is immune from hangups.
|
prp
|
|
response 47 of 59:
|
Apr 5 16:45 UTC 1999 |
Or basically, submit a batch job with no limits, real-time or cpu-time.
It seems that if you are going to allow CGI scripts, you'll have to
restrict them to a few system supplied and trusted ones, impose some
limits, or put up with user generated infinite loops and such.
Given there are no restrictions on nohup, why should CGI scripts be
any worse?
|
ryan
|
|
response 48 of 59:
|
Apr 5 17:02 UTC 1999 |
This response has been erased.
|
remmers
|
|
response 49 of 59:
|
Apr 5 17:08 UTC 1999 |
We do have a restriction on nohup: The kill-orphans program limits the
amount of time that no-hupped programs can run. (Except for certain
exempt system jobs that need to always be running.)
One fundamental difference between CGI's and other kinds of programs: A
normal program stored on Grex can be run only by someone who is logged
into Grex. A CGI script stored on Grex can be run by anyone on the
internet with a web browser, whether or not they have an account on Grex.
|
remmers
|
|
response 50 of 59:
|
Apr 5 17:08 UTC 1999 |
(ryan slipped in with response #48)
|
pfv
|
|
response 51 of 59:
|
Apr 5 17:20 UTC 1999 |
Actually, as I recall - there is some oddball-superweird method
of convincing httpd that a page/cgi or whatever is "password
protected", too - ala' Backtalk..
A brief discrip of that method would prolly be applicable here,
but I sure can't remember what I read, where and how.
|
prp
|
|
response 52 of 59:
|
Apr 5 17:30 UTC 1999 |
Whether or not they have an account on Grex seems quite irrelevant.
Anybody can get an account, and with out ANY identification, or at
least any non-fictional identification.
|
pfv
|
|
response 53 of 59:
|
Apr 5 17:37 UTC 1999 |
And, your point was?
|
remmers
|
|
response 54 of 59:
|
Apr 5 21:12 UTC 1999 |
Yes, you can password-protect webpages and CGI's. I won't attempt
to describe the method here.
Not sure I see the point in #52 either. My point was: If somebody
puts up a web page on Grex, and that web page has a CGI on it, and
the web page and CGI become really popular, such that 20,000 users
visit it every week, that could add up to a fair chunk of Grex's
CPU usage. At least with regular programs, the necessity to log in
to Grex first before running them puts some kind of control on how
much the programs get run. No such control exists with CGI programs.
I'm not saying we shouldn't allow user CGI's, or that the above
worst-case scenario is necessarily going to happen, but it's
conceivable that user CGI's could sustantially increase the load
on Grex.
|