Re: Processing Ideas Needed:

Hi Wilm,

I am a forgiving person(a).

Give me time Wilm, give me time :-)

The webserver does not assume anything. It causes a process to be
created for user JANEDOE, who is not privileged, but happens to be
associated with a rights identifier RUNANIMAGE, so she's able to run an
image that SUBMIT/USER's a job.

I'll give you London to a brick that the webserver calls $persona_assume
"JANEDOE" before calling $creprc, in order to achieve the end result. If it
isn't then it should! (Although back in 6.2 days there were "helpdesk
celebrities" at Digital (becoming EDS at that time in Europe) whose
arrogance led them to question whether or not this was supported. VMSNOTES
conference is there for those with access.)

2) Does it create, and rundown, a new VMS process for each client
request?

I hope so.

The crying shame here Wilm is I bet that you're not alone in this desire for
self-flagellation :-(

"Dear VMS Engineering, we the undersigned wish not only to endure the
overhead of image activation/rundown for each web-client request but also to
suffer the multitudenal indignities of a process activation." No wonder they
don't give a Monkey's anymore; it's not just that WSIT is crap it's just
that the client-base is technically incapable of understanding what "crap"
is. (To be brutally honest, the VMS world seems to have plateaued with
Perl/CGI or ODBC and seems unlikley to ever be confronted with
the issues that have seen the rest of the industry searching for something
like SOA, in the first place. An as far as AJAX and that predictive text
stuff goes "Just leaves us banjo-plucking VMSers to ourselves! But you
sure do have a purdy mouth. . .")

3) Does it use some dodgy inner-mode personae that manages to survive
image
rundown?

No.

For anyone following at home, I looked at the code a while back and recall
that it's doable. Personae can survive image rundown.

5) Where does the logfile go?

The webservers log file is where it always is, and records the run
request. The /OUTPUT, /ERROR qualifiers of the RUN command determine
where those log files go. The SUBMIT/USER command causes the log file of
that job to go to the /USER=xxx login directory.

So the webserver "causes a process to be created for user JANEDOE" (and many
other simultaneous users presumably) and channels *all* of the output from
*all* of the processes to the one log file? To spell it out, I'm asking what
you do with the sys$crappy_disk:bullshit_web_process_log.32767 files?

6) Has non-interactive logins for (1) user id been clicked over?

Not sure that it's relevant, but "No". The user JANEDOE exists for one
purpose only, to SUBMIT jobs. Her VMS "account" should, maybe by being
CAPTIVE or by other standard issue modifiers, restrict her to berform
only that function.

That's strange, but then I think that not updating the last login time for a
detached job is also strange, so what do I know. Network logins "Yes" this
"No" that "Maybe".

In this our stateless universe,

NO! "Your" stateless universe Wilm "YOUR"! Thus is the world as YOU have
made it. (Or at least perceive it.) Take off your bull*** HTTP blinkers for
a while and smell the coffee! And other mixed metaphors :-)

I cannot think of a way to do this
synchronously.

Well, as long as you've explored all avenues; that's the main thing!
Wilm's stumped everybody so the rest of us might as well go home :-)

I mean "RPC" what's it all about eh? Context-Rich? Connection-Oriented?
Surely nothing but heretical clap-trap from an age before the I.T.
killing-fields? I mean, imagine being able to control server-affinity or
have your server processes assume the persona of the client they're
performing work for, at any time without the need for any privileges.
Imagine only having to supply a shareable image with six User Action
Routines that produce the business logic for your application. Imagine all
of this occuring in the context of a pool of worker processes that can be
tuned for client demand with min/max servers and idle timeouts. I mean what
the ***'s the point of that eh? But I'm sure I'm distracting you from that
Perl manual that discusses the difference between "die" and "exit(1)" so
I'll move on. . .

8) If (1) user id decides to submit the job again, does he have to enter
his
username/password again or is it held in some dogy cookie or session
variable?

Preferably not.

And the other options are?

Yeah, and from my point of view, this is what he gets. Unless he wants
to submit a million jobs a day, process creation is not an issue. We'll
walk that bridge when we come to it.

Yes, I'm sure you're right Wilm; it's all about Chuck submitting one batch
job. There are certainly no architectural truths, credos, or dogmas that
transcend individual application requirements that are to be found here.
Move along, nothing more to see. (I'm sure SSH could've done it better
anyway)

Cheers Richard Maher

"Wilm Boerhout" <w5OLD.PAINTboerhout@xxxxxxxxx> wrote in message
news:46d13299$0$25476$ba620dc5@xxxxxxxxxxxxxxxxxxxxxx
on 26-8-2007 9:00 Richard Maher wrote...
You'll have to forgive me as I rarely pay much attention to anything Bob
G
has to say (especially stuff such as "Shareable image installed with the
needed privilege.") but when it comes to the application of your/Bob's
solution to Chuck's problem, can I ask you to clarify a couple of things
for
me: -

I am a forgiving person(a).

1) How does Chuck's Webserver assume the "only (1) particular user id",
and
the associated identifier, whilst handing over to the image activator in
order to run the Executable installed with privs?

The webserver does not assume anything. It causes a process to be
created for user JANEDOE, who is not privileged, but happens to be
associated with a rights identifier RUNANIMAGE, so she's able to run an
image that SUBMIT/USER's a job.

2) Does it create, and rundown, a new VMS process for each client
request?

I hope so.

3) Does it use some dodgy inner-mode personae that manages to survive
image
rundown?

No.

4) Does it keep the process lying around in case the (1) user id is
needed
again?

No.

5) Where does the logfile go?

The webservers log file is where it always is, and records the run
request. The /OUTPUT, /ERROR qualifiers of the RUN command determine
where those log files go. The SUBMIT/USER command causes the log file of
that job to go to the /USER=xxx login directory.

6) Has non-interactive logins for (1) user id been clicked over?

Not sure that it's relevant, but "No". The user JANEDOE exists for one
purpose only, to SUBMIT jobs. Her VMS "account" should, maybe by being
CAPTIVE or by other standard issue modifiers, restrict her to berform
only that function.

7) How does the success (Job entry number, perhaps pending status, or
execution queue) or failure get returned to the user?

In this our stateless universe, I cannot think of a way to do this
synchronously. So, write it into a file, and tell the user to check back
on the status later. My favourite web shop does it that way, I can live
with it.

8) If (1) user id decides to submit the job again, does he have to enter
his
username/password again or is it held in some dogy cookie or session
variable?

Preferably not.

9) What sort of expiration time do you put on that crap?

See above, none.

10) What window of opportunity for Session Hijacking is good/small
enough?

Also, N/A

Yep, welcome to VMS development! What have we had so far? FAL jobs with
proxy usernames, Cookies, Session IDs, New processes (let alone image
activation) for each request, and polling for file existance. (I'll
throw in
the inevitable "Use ODBC and an external function to the submit the
batch
job and put an ACL on the function") All of this brought to you via HTTP
and
a codepath that would tempt Alexander the Great to reach for his sword!
Funnily enough, I suspect that all Chuck wanted was a RPC.

Yeah, and from my point of view, this is what he gets. Unless he wants
to submit a million jobs a day, process creation is not an issue. We'll
walk that bridge when we come to it.

/Wilm


.