[Info-vax] SAMBA and Ransomeware

[Stephen Hoffman]

On 2017-07-29 14:58:51 +0000, ultradwc at gmail.com said:

> THIS IS THE TIME FOR PROCESS SOFTWARE TO STEP UP TO THE PLATE. IT WOULD 
> NOT BE VERY HARD TO DUST OFF PURVEYOR AND UPDATE THE SSL AND BRING IT 
> BACK. IT WOULD BE THE TOP OPENVMS WEBSERVER ON THE MARKET.

Maybe it's time to replace that ASR33 you're apparently using with a 
refurb ASR38 or maybe a VT100?

Basically, you're asking for VSI to dust off code that was retired most 
of two decades ago (and undoubtedly for good and valid reasons), and 
bringing it forward.  It'd be worthwhile to ponder why Process got out 
of the Purveyor business back then, and what has happened with web 
servers and expectations since then?   Maybe also ponder what current 
folks are using Apache for, and which features they're using within the 
Apache port?

So...  Easy, huh?   Okay.  So...  Let us play this one out.   VSI 
decides to license the old code and dust it off and update it.    
Because "IT WOULD NOT BE VERY HARD TO DUST OFF PURVEYOR AND UPDATE THE 
SSL AND BRING IT BACK", of course.   To bring it back to what wasn't 
particularly competitive most of twenty years ago, when the product was 
retired.    Sure, if we're looking at TLS, that's (probably) a fairly 
isolated hunk.  Adding stapling and other TLS-related work will add to 
that.  Some other TLS-related work.

But if your suggestion undergoes seemingly-inevitable "project creep" 
and for this to be the primary VSI web server, then folks are going to 
want and need various features present in Apache that aren't in 
something as dated as Purveyor, and there'll be ongoing support and 
upgrade efforts as the standards evolve.   Not just porting the 
existing code over to OpenVMS as is the current case with Apache or to 
"DUST OFF PURVEYOR", but of designing and implementing and testing 
HTTP/2 support, IPv6 support, Unicode, LDAP, WebDAV, of connecting it 
all with VSI IP, and whatever other newer web services features and 
integration and features that might be required by the customers; of 
creating a more competitive web server.

The customers are not going to be fast to migrate to a web server 
lacking features they're using, after all.    And then there's the 
discussion of continuing support for Apache or migration of folks from 
Apache over to this new VSI web server, and duplication of development 
adds incremental costs.    And duplication will detract from the 
migration to and adoption of this hypothetical new VSI ULTRAPURVEYOR 
web server.

Creating and updating and testing documentation and product support for 
all that, and ensuring that content management systems and the rest of 
what now connects into web servers are tested with and documentation 
written for use with this new web server, too.

There'll also be customer questions about importing or exporting the 
configuration data from the existing Apache environments, and getting 
content management systems or business systems connected to the web 
server, and eventually working on whatever open-source or VSI-specific 
tools might access and potentially even eventually manage the contents 
of the web server configuration files, or the web server database.   
(I'm routinely working with servers that manage and modify the 
underlying Apache files, as part of the platform management interface, 
too.  Any of that will have to be modified to track the new platform, 
or the new platform will have to use the Apache files and formats.   
The use of the Apache configuration files would ease the migration into 
the new platform, of course.  But now you're dealing with all of the 
Apache modules, and a whole lot more support.   Or a subset of the 
supported Apache modules being supported in VSI ULTRAPURVEYOR, and all 
the trade-offs involved there.)

Then there's the question of the licensing and pricing for this 
hypothetical new web server; whether to license the code with the 
platform, or to require a separate license for folks that want that.   
Web servers are now integrated parts of pretty much any other server 
available on the market, but now VSI is accepting a rather larger 
effort than porting across Apache.   Customers too are now learning 
about and managing a new web server and one that's wholly different 
from Apache or nginx or another server, which adds to their own costs.

While certainly not all of this will be needed by all customers and 
there'll certainly be other work outside this list, here's a starting 
point for what else can be involved with updating Purveyor from most of 
twenty years ago, and replacing Apache:

https://httpd.apache.org/docs/trunk/new_features_2_4.html
https://httpd.apache.org/docs/2.2/new_features_2_2.html
https://httpd.apache.org/docs/2.2/new_features_2_0.html
https://en.wikipedia.org/wiki/Apache_HTTP_Server
Probably some other web-services historical lists of added features and 
web server changes has been posted... somewhere...

Purveyor is far enough back that it may well lack server-side includes 
and a whole lot of other support that's now considered common and 
expected.

Then there'll be requests for adding support for Tomcat and other such, 
and whatever else Purveyor lacks.

There'll be updating the code for modern compilers and maybe for modern 
coding practices, if not starting to rewrite the code in a more modern 
language, depending on what Purveyor was originally written in.

So.... sure.   "IT WOULD NOT BE VERY HARD TO DUST OFF PURVEYOR".  If 
it's just what Purveyor had, selling that to folks will be fun.   If 
it's hauling Purveyor forward to competitive features, it wouldn't 
surprise me to require a team of a dozen OpenVMS- and web-familiar 
developers and probably a year or two of effort and possibly longer, 
and an ongoing investment to track and upgrade to newer web standards 
and requirements, and VSI will have some combination of a large hole in 
their development budget to fund that work, or a unique and 
platform-specific web server with rather less than what 
comparable-vintage Apache or other major web servers provide.   I'm 
sure that'll really sell well with any folks wholly new to OpenVMS, and 
also with the OpenVMS folks using Apache.   And in parallel to this web 
server, VSI will continue to need developers for work on OpenVMS 
itself; on other features and tools, too.  Development budgets and 
schedules are seldom unlimited, and there are always these sorts of 
trade-offs.

I'd prefer to see Apache integrated directly into the base distro, and 
to see it and its TLS support kept current.   At least until there's a 
replacement that has marketable advantages over Apache or nginx or the 
other and more established web servers.   Because I can use Apache for 
whatever Purveyor did back then.  And for a whole lot more.

p.s. I've just noticed that the entire Apache 2.2 series has ended 
support.  Which means the VSI Apache port is the path forward for folks 
using the HPE port.






-- 
Pure Personal Opinion | HoffmanLabs LLC