[Info-vax] OpenSSL CSWS-2.2-1

[Stephen Hoffman]

Local operating assumption:  Install-time questions are to be avoided.  
Install-time questions usually means the developer either couldn't 
answer a question and couldn't figure out how to eliminate the 
question, or didn't want to answer a question and didn't want to 
consider why.  Or wanted to ask questions to show off.  Among the 
various things that PCSI—the most recent OpenVMS platform package 
installer—did right here, it made asking questions of the installer 
more difficult.  If there are questions that cannot be answered at 
install time, provide a configuration tool.  And gather what data you 
can from the local environment and local network services, whether it's 
from mDNS or DHCP or NTP or otherwise.  Yeah, OpenVMS isn't good at any 
of that.  And it'd be very handy if there were standardized profiles 
and configuration files and tools available here, so that the 
installation deployment and configuration process can be automated, 
when there are questions or customizations required.   With OpenVMS, we 
all either end up writing that ourselves, and often differently. Or 
making automated and faster deployments more difficult.

On 2019-05-02 11:15:44 +0000, Neil Rieck said:

> Just thought I'd toss in my own 2-cents on the OpenSSL issue as well.
> I've been playing with WASD HTTPd v11.3 as a drop in replacement for CSWS-2.2-1
> 
> First off, WASD is a hackers delight because it is published with all 
> the source code. If you have a DEC-C compiler then you will be able to 
> support yourself if need be.

Apache source code is also available, and both HPE and VSI have made 
source code of the ports available.  Downside: OpenVMS C hasn't tracked 
that of other platforms, so the ports tend to be more complex.  VSI is 
on a path to fix that, starting with Clang and LLVM support. There's 
rather more past that, and hopefully the existing OpenVMS C RTL is 
eventually relegated to use by unmaintained applications.  There are 
far too many layers of backward-compatibility clogging the existing 
environment.

> Secondly, during the install (you are given the choice of "just 
> linking" or "compile then link") you will be prompted for five OpenSSL 
> options depending upon what you've already got installed on your 
> system. For example WASD can link against its own SSL library, or 
> HP-SSL1 (OpenSSL 1.0 and higher) or HP-SSL (OpenSSL 0.9 and lower) 
> although this last step is disabled by default when HP-SSL1 is present. 
> How cool is that!

How about installs with no questions at all?  That's cool.  That's the 
best.  For this case, probably with an embedded OpenSSL or libtls or 
libsodium kit, though this presumes there'll be upgrades to that 
support and thus some provisions are necessary for upgrades.

Now if somebody wants (needs) linkages against some other crypto 
library, allow that after the install, and instrument that to see how 
many folks use it as a foundation for adding or removing encryption 
support, or for removing the feature entirely.

And I'm skeptical around needing changes here, if the crypto libraries 
are kept current.

https://www.libressl.org
https://github.com/jedisct1/libsodium
etc.

Biggest reason to provide that variant support on OpenVMS has been a 
bad trade-off between longstanding issues with old vendor SSL 
libraries, and the time and effort involved in maintaining app-specific 
libraries.  OpenVMS is unfortunately missing a number of common 
libraries, and the pace of change here makes keeping the dependencies 
current more effort, whether that cost is at the vendor or at the 
developer.  And the crypto has been lagging, both with the OpenSSL 
library and with the embedded SSL within various versions of Apache.

> Last but not least, WASD HTTPd is the fastest web server in my shop. 
> Although I'm running WASD on an old rx2600 (8 CPUs, 16 GB of RAM), it 
> is faster than CSWS-2.2-1 on my rx2800-i2 (8 CPUs, 64 GB of RAM) as 
> well as Apache 2.4 under CentOS-7 on my DL385p-gen8 (24 CPUs, 132 GB of 
> RAM).
> 
> Now I haven't (yet) done full-load testing of WASD, but it appears get 
> its speed from doing a lot of caching to avoid disk i/o -AND- does not 
> be using the pre-fork model seen in CSWS on OpenVMS-8.4 or Apache 2.4 
> on CentOS-7

It'd be interesting to try that against a tuned Apache HTTP Server 
2.4-39 on VSI OpenVMS.  Also against nginx on CentOS, if running a 
comparison.  Apache has never been particularly fast.  It is, however, 
extremely common.

> Comment: I've done at least a half-dozen installs of CentOS which 
> included Apache by default. I do not recall ever being asked to choose 
> between pre-fork or something else. And yet, all the Apache self-help 
> sites tell you not to use pre-fork. Go figure!

The worker MPM is necessary when some part of your Apache module 
environment isn't thread-safe, and prefork MPM is the choice when your 
Apache module environment is thread-safe.  If the default Apache 
install is thread-safe, then there's no reason to ask a question.



-- 
Pure Personal Opinion | HoffmanLabs LLC