Discussion:
WASD instead of CSWS?
(too old to reply)
Dirk Munk
2017-03-09 14:33:05 UTC
Permalink
Raw Message
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.

If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.

The second advantage is that it is documented. It has a wonderful VMS
style manual, the whole thing looks as if it is already part of the VMS
distribution kit.

And then something else, and this is more or less the continuation of
the GUI for VMS thread.

Jan-Erik pointed me to the WebSocket pages of the WASD web site. It
turns out that Mark Daniel wrote a C library with WebSocket functions.
Great for the interactive webpages we all want to have.

Now my question is, would it be possible to build a library with
callable WebSocket functions, so that you don't need to write a program
in C to use them.

That way you can just call the function you need from any VMS language.

Your comments please.
Michael Moroney
2017-03-09 15:52:24 UTC
Permalink
Raw Message
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
...
Post by Dirk Munk
Your comments please.
I personally am very much in favor of WASD being distributed with VMS on
the freeware, and/or being the default VMS web server. This requires the
developers going along with that, I do believe. Some people do require
Apache/CSWS, however.
Mark Daniel
2017-03-09 15:58:33 UTC
Permalink
Raw Message
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
The second advantage is that it is documented. It has a wonderful VMS
style manual, the whole thing looks as if it is already part of the VMS
distribution kit.
And then something else, and this is more or less the continuation of
the GUI for VMS thread.
Jan-Erik pointed me to the WebSocket pages of the WASD web site. It
turns out that Mark Daniel wrote a C library with WebSocket functions.
Great for the interactive webpages we all want to have.
Now my question is, would it be possible to build a library with
callable WebSocket functions, so that you don't need to write a program
in C to use them.
That way you can just call the function you need from any VMS language.
Your comments please.
Dirk,

wsLIB has descriptor variants of all of the relevant API functions

"It also abstracts as much of the required functionality into
callable functions using optional string descriptors so as to
minimise dependency on the C language and on knowing the internals
of the library data structure."

https://wasd.vsm.com.au/wasd_root/src/websocket/wsLIB.c

so you should just be able to link into those from a non-C object and be
up and running. Of course, the C API (to my knowledge) has been
exercised more than the descriptor API.

Cheers, Mark.
Jan-Erik Soderholm
2017-03-09 15:59:27 UTC
Permalink
Raw Message
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
The second advantage is that it is documented. It has a wonderful VMS
style manual, the whole thing looks as if it is already part of the VMS
distribution kit.
And then something else, and this is more or less the continuation of
the GUI for VMS thread.
Jan-Erik pointed me to the WebSocket pages of the WASD web site. It
turns out that Mark Daniel wrote a C library with WebSocket functions.
Great for the interactive webpages we all want to have.
Now my question is, would it be possible to build a library with
callable WebSocket functions, so that you don't need to write a program
in C to use them.
That way you can just call the function you need from any VMS language.
Your comments please.
Hi. Yes, I also thought that that looked promising... :-)

What is the biggest change from classical web based processing is that
the server application can write to the browser at any time, not only
when the browser has made a specific call. Think a MONITOR utility.

Now, as far as I have understood, it is generally speaking, some
difficulties in using anything else then C for the layer closest to
the web server, WASD in this case.

And it is not only the application that calls these functions, WASD
also calls your functions whenever something comes from the browser.

I hope to be able to setup some tests, but I would guess that
it will be with some C glue code.

But then, it's just programming, doesn't matter if it is C
or something else, does it? :-)

Jan-Erik.
Mark Daniel
2017-03-09 16:21:00 UTC
Permalink
Raw Message
Post by Jan-Erik Soderholm
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
The second advantage is that it is documented. It has a wonderful VMS
style manual, the whole thing looks as if it is already part of the VMS
distribution kit.
And then something else, and this is more or less the continuation of
the GUI for VMS thread.
Jan-Erik pointed me to the WebSocket pages of the WASD web site. It
turns out that Mark Daniel wrote a C library with WebSocket functions.
Great for the interactive webpages we all want to have.
Now my question is, would it be possible to build a library with
callable WebSocket functions, so that you don't need to write a program
in C to use them.
That way you can just call the function you need from any VMS language.
Your comments please.
Hi. Yes, I also thought that that looked promising... :-)
What is the biggest change from classical web based processing is that
the server application can write to the browser at any time, not only
when the browser has made a specific call. Think a MONITOR utility.
Now, as far as I have understood, it is generally speaking, some
difficulties in using anything else then C for the layer closest to
the web server, WASD in this case.
And it is not only the application that calls these functions, WASD
also calls your functions whenever something comes from the browser.
I hope to be able to setup some tests, but I would guess that
it will be with some C glue code.
But then, it's just programming, doesn't matter if it is C
or something else, does it? :-)
Jan-Erik.
Each of the Web applications

aLaMode https://wasd.vsm.com.au/wasd_root/src/alamode/
DCLinabox https://wasd.vsm.com.au/wasd_root/src/DCLinabox/
INTRUspect https://wasd.vsm.com.au/wasd_root/src/INTRUspect/
MonDesi https://wasd.vsm.com.au/wasd_root/src/mondesi/

use (either exclusively or optionally) the WebSocket API and protocol
(all via the C language API).

Main WASD WebSocket application API source with examples

https://wasd.vsm.com.au/wasd_root/src/websocket/

FYI: WASD v11.1.0 (due sometime this quarter or early next) also
supports what it is calling the "Raw"Socket interface. Essentially
WebSocket, without the WebSocket protocol; i.e. protocol agnostic,
allowing interactions with non-browser clients, those as "simple" as a
TELNET client.
Jan-Erik Soderholm
2017-03-09 16:43:01 UTC
Permalink
Raw Message
Post by Mark Daniel
Post by Jan-Erik Soderholm
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
The second advantage is that it is documented. It has a wonderful VMS
style manual, the whole thing looks as if it is already part of the VMS
distribution kit.
And then something else, and this is more or less the continuation of
the GUI for VMS thread.
Jan-Erik pointed me to the WebSocket pages of the WASD web site. It
turns out that Mark Daniel wrote a C library with WebSocket functions.
Great for the interactive webpages we all want to have.
Now my question is, would it be possible to build a library with
callable WebSocket functions, so that you don't need to write a program
in C to use them.
That way you can just call the function you need from any VMS language.
Your comments please.
Hi. Yes, I also thought that that looked promising... :-)
What is the biggest change from classical web based processing is that
the server application can write to the browser at any time, not only
when the browser has made a specific call. Think a MONITOR utility.
Now, as far as I have understood, it is generally speaking, some
difficulties in using anything else then C for the layer closest to
the web server, WASD in this case.
And it is not only the application that calls these functions, WASD
also calls your functions whenever something comes from the browser.
I hope to be able to setup some tests, but I would guess that
it will be with some C glue code.
But then, it's just programming, doesn't matter if it is C
or something else, does it? :-)
Jan-Erik.
Each of the Web applications
aLaMode https://wasd.vsm.com.au/wasd_root/src/alamode/
DCLinabox https://wasd.vsm.com.au/wasd_root/src/DCLinabox/
INTRUspect https://wasd.vsm.com.au/wasd_root/src/INTRUspect/
MonDesi https://wasd.vsm.com.au/wasd_root/src/mondesi/
use (either exclusively or optionally) the WebSocket API and protocol (all
via the C language API).
Main WASD WebSocket application API source with examples
https://wasd.vsm.com.au/wasd_root/src/websocket/
FYI: WASD v11.1.0 (due sometime this quarter or early next) also supports
what it is calling the "Raw"Socket interface. Essentially WebSocket,
without the WebSocket protocol; i.e. protocol agnostic, allowing
interactions with non-browser clients, those as "simple" as a TELNET client.
Just FYI...

DCLinabox is a terminal emulator written in JaveScript that runs in a
browser without any other software installs. Could be an alternative
for VMS applications without to much exotic VT-functions.
David Froble
2017-03-09 17:48:58 UTC
Permalink
Raw Message
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
The second advantage is that it is documented. It has a wonderful VMS
style manual, the whole thing looks as if it is already part of the VMS
distribution kit.
And then something else, and this is more or less the continuation of
the GUI for VMS thread.
Jan-Erik pointed me to the WebSocket pages of the WASD web site. It
turns out that Mark Daniel wrote a C library with WebSocket functions.
Great for the interactive webpages we all want to have.
Now my question is, would it be possible to build a library with
callable WebSocket functions, so that you don't need to write a program
in C to use them.
That way you can just call the function you need from any VMS language.
Your comments please.
As is well known, I don't get out much. However, I do have to ask, why can't
you use some library routine from any VMS language?

I know that statement is going to get jumped on, since I ran into a situation I
could not handle, and I still don't understand why.

:-(
Jan-Erik Soderholm
2017-03-09 17:55:14 UTC
Permalink
Raw Message
Post by David Froble
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is that
it is far more efficient and powerful then CSWS.
The second advantage is that it is documented. It has a wonderful VMS
style manual, the whole thing looks as if it is already part of the VMS
distribution kit.
And then something else, and this is more or less the continuation of the
GUI for VMS thread.
Jan-Erik pointed me to the WebSocket pages of the WASD web site. It turns
out that Mark Daniel wrote a C library with WebSocket functions. Great
for the interactive webpages we all want to have.
Now my question is, would it be possible to build a library with callable
WebSocket functions, so that you don't need to write a program in C to
use them.
That way you can just call the function you need from any VMS language.
Your comments please.
As is well known, I don't get out much. However, I do have to ask, why
can't you use some library routine from any VMS language?
Sometimes there are technical reasons, but one reason not to take too
light is that in many cases (in particluar whan using some "foreign"
open source tools) all examples available are written in C. So it is
much easier just to write your own code in C also.

And if one stops looking at that as a problem, the problem goes away... :-)
Post by David Froble
I know that statement is going to get jumped on, since I ran into a
situation I could not handle, and I still don't understand why.
:-(
Simon Clubley
2017-03-09 19:30:16 UTC
Permalink
Raw Message
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
And at the time of writing this, not one person has mentioned what
should be the actual number one concern: how secure is WASD compared
to Apache and how much security testing/probing does it get from
external security researchers compared to Apache ?

To make this very clear: this is absolutely NOT a negative comment
against Mark, but just me pointing out the kinds of questions which
should be asked for this type of application.

Don't forget what happened when WASD did actually come to the
attention of a third party security researcher. Once again, this
is absolutely NOT a negative comment against Mark but just a simple
stating of what can happen if less well known software isn't subject
to the same security testing regime as more mainstream software.

For example, it's possible that various issues are present in VMS
itself just waiting to be found by a security researcher using today's
tools and techniques.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Mark Daniel
2017-03-09 21:00:45 UTC
Permalink
Raw Message
Post by Simon Clubley
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
And at the time of writing this, not one person has mentioned what
should be the actual number one concern: how secure is WASD compared
to Apache and how much security testing/probing does it get from
external security researchers compared to Apache ?
To make this very clear: this is absolutely NOT a negative comment
against Mark, but just me pointing out the kinds of questions which
should be asked for this type of application.
Absolutely this question should be asked of any software that faces a
hostile, largely hidden crowd, who are out to do you real harm.

https://wasd.vsm.com.au/info-WASD/2017/31
Post by Simon Clubley
Don't forget what happened when WASD did actually come to the
attention of a third party security researcher. Once again, this
I haven't. My resting blood-pressure went up twenty points and
(non-medicated) stayed at that level until last year. Not hyperbole.
Coincidence maybe.

"don't think it can't happen to you!"

https://wasd.vsm.com.au/wasd_root/doc/config/config_0500.html
Post by Simon Clubley
is absolutely NOT a negative comment against Mark but just a simple
stating of what can happen if less well known software isn't subject
to the same security testing regime as more mainstream software.
And WASD is a *very* large suite of open-source software, grown by
accretion over twenty-plus years. Hmmm.

Simon's concern is absolutely legitimate and should be the number one
consideration on any Internet-facing system.
Post by Simon Clubley
For example, it's possible that various issues are present in VMS
itself just waiting to be found by a security researcher using today's
tools and techniques.
Simon.
Mark Daniel
2017-03-12 13:48:12 UTC
Permalink
Raw Message
Post by Mark Daniel
Post by Simon Clubley
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
If I had to make a choice right now, WASD would win, no doubt. It is a
'real' VMS application, and not a ported Unix program. The result is
that it is far more efficient and powerful then CSWS.
And at the time of writing this, not one person has mentioned what
should be the actual number one concern: how secure is WASD compared
to Apache and how much security testing/probing does it get from
external security researchers compared to Apache ?
To make this very clear: this is absolutely NOT a negative comment
against Mark, but just me pointing out the kinds of questions which
should be asked for this type of application.
Absolutely this question should be asked of any software that faces a
hostile, largely hidden crowd, who are out to do you real harm.
https://wasd.vsm.com.au/info-WASD/2017/31
Post by Simon Clubley
Don't forget what happened when WASD did actually come to the
attention of a third party security researcher. Once again, this
I haven't. My resting blood-pressure went up twenty points and
(non-medicated) stayed at that level until last year. Not hyperbole.
Coincidence maybe.
"don't think it can't happen to you!"
https://wasd.vsm.com.au/wasd_root/doc/config/config_0500.html
Post by Simon Clubley
is absolutely NOT a negative comment against Mark but just a simple
stating of what can happen if less well known software isn't subject
to the same security testing regime as more mainstream software.
And WASD is a *very* large suite of open-source software, grown by
accretion over twenty-plus years. Hmmm.
Simon's concern is absolutely legitimate and should be the number one
consideration on any Internet-facing system.
Post by Simon Clubley
For example, it's possible that various issues are present in VMS
itself just waiting to be found by a security researcher using today's
tools and techniques.
Simon.
Simon's comment got me to thinking, so I have added a section to the
documentation with some observations on the specific vulnerability
testing undertaken during the ongoing development of WASD. While not as
comprehensive as might be if a separate test team was available, it
hopefully underscores it's not code-and-pray either.

https://wasd.vsm.com.au/wasd_root/doc/config/config_0500.html#08e078e7
w***@gmail.com
2017-03-12 21:30:20 UTC
Permalink
Raw Message
I switched from Apache to WASD several years ago. Main reason is overall system load: Compared to Apache, WASD takes a load less of system resources. VERY important if you have a (very) small system (256 Mb at the time). Plus - for me - an invaluable tool built-in: WATCH. Even now, with 8 times the memory, I won't even consider a Unix-based webserver :)

OK, enough plugging done.

No matter how secure your base is (OS, Webserver and all), it all is blown to pieces if the software you expose to the web is not safe, or (IMHO) improperly configured. There are, I think, a few rules you have to follow:

1 - do NOT install software in the default location.
2 - do NOT allow write access to ANY location to the webserver (or any other publicly accessible program). If you need it, be sure you will need to authenticate yourself - properly (so by the server!)
3 - Keep your programs (and underlying infrastructure) up-to-date.
4 - Scrutinize your logs

I set up my systems this way - and when examining the access log of WASD, I see the effort of this has been worthwhile.
Simon Clubley
2017-03-13 01:19:41 UTC
Permalink
Raw Message
Post by Mark Daniel
Simon's comment got me to thinking, so I have added a section to the
documentation with some observations on the specific vulnerability
testing undertaken during the ongoing development of WASD. While not as
comprehensive as might be if a separate test team was available, it
hopefully underscores it's not code-and-pray either.
https://wasd.vsm.com.au/wasd_root/doc/config/config_0500.html#08e078e7
This is exactly the kind of thing which it is really good to include.

It gives people confidence that you are keeping in touch with the
changing security environment and addresses concerns that sometimes
exist in the VMS world when some people wrongly project an image
that the security concerns of other environments don't apply to VMS.

$ set response/mode=good_natured

BTW, I couldn't help but notice a couple of typos. :-)

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world
Richard Maher
2017-03-10 01:09:22 UTC
Permalink
Raw Message
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
Java seems to have HttpSession object and getSession, timeout etc. .NET
c# has a brilliantly simple Session['myVar'] = 'some contents';
Transparent to the code is the implementation of Session State: -

inProc = Sticky sessions. All future requests have to go to same server
process
Session State Server = Dedicated State server process at a given ip
REDIS Cache = Azure any VM any Process any Thread.

I imaging Mark would recommend global sections or sys$icc for 3GLs, but
does WASD support Java and does Java support non-sticky Session State on
VMS?
Arne Vajhøj
2017-03-10 02:03:42 UTC
Permalink
Raw Message
Post by Richard Maher
Post by Dirk Munk
There are several web servers available for OpenVMS, but I think there
are just two that count at the moment, the VSI supplied CSWS (=Apache),
and WASD.
Java seems to have HttpSession object and getSession, timeout etc. .NET
c# has a brilliantly simple Session['myVar'] = 'some contents';
Transparent to the code is the implementation of Session State: -
inProc = Sticky sessions. All future requests have to go to same server
process
Session State Server = Dedicated State server process at a given ip
REDIS Cache = Azure any VM any Process any Thread.
I imaging Mark would recommend global sections or sys$icc for 3GLs, but
does WASD support Java and does Java support non-sticky Session State on
VMS?
Java web applications are not executed directly by a web server, but
in a Java web container also known as a servlet container.

Like Tomcat.

You have the options of:

---(HTTP)---Tomcat
---(HTTP)---Apache---(HTTP)---Tomcat
---(HTTP)---Apache---(AJP)---Tomcat

Not sure if WASD can proxy in front of Tomcat, but it is
rather simple so either it can or it could easily be made to.

The Java EE specs defines session object access from Java web
applications.

Clustering capabilities are server specific (not defined in
the standard).

Tomcat supports session replication via:
* file in shared file system
* database via JDBC
* network via TCP

Details are here:

https://tomcat.apache.org/tomcat-9.0-doc/cluster-howto.html

I would expect all of them to work fine on VMS.

Arne
Loading...