Re: remote management software

[Stephen Hoffman]

On 2018-09-05 00:16:48 +0000, Craig A. Berry said:

> The SNMP widgets need to be updated regardless and presented via
> something that doesn't suck as much as SMH.
>
> I believe the Insight Manager stuff was always required to run on a
> Windows server on the same LAN as the VMS system. I have no idea how
> good it was as I could never get anyone to give me a free Windows
> server nor justify the cost of a Windows Server license just to monitor
> another server that didn't have adequate capabilities of its own.
>
> Plus it's not clear to me the remote management stuff owned by HPE is
> available to VSI or was part of the licensing deal that allows VSI to
> develop VMS.

SNMP on OpenVMS needs serious help, and SMH—which is part of SNMP
support on OpenVMS—is insecure.

SNMP isn't particularly popular as a host-management control interface,
though it is commonly used for and useful for server and network
monitoring. And tools such as smtpwalk definitely have their uses.

As with other aspects of IP networking, SNMP (SNMPv3) and the SMH-based
MIBs need to be better or entirely integrated into OpenVMS, and not
bolted on.



On 2018-09-03 15:09:05 +0000, Jim Johnson said:

> I helped get the management station work underway and through its first
> release.
> We took an approach of doing successive vertical functions in order to
> avoid several year delays that would have come from going after the
> full breadth of the space. That, however, required a sustained
> multi-release effort. It was sustained for a while, but not for long
> enough (IMO).

Pragmatically, incremental releases are the only way that non-trivial
projects can be built and deployed, as the problems are large and
complex, and as migrations from the old and soon-deprecated APIs to the
new takes several releases both for the vendor and for the customers.
And there needs to be a clear benefit to the new framework or new API.

The OpenVMS Management Station (OMS, also sometimes known as Argus) UI
support wasn't particularly integrated with OpenVMS.

An OMS intro, for those unfamiliar with the package:
http://h41379.www4.hpe.com/openvms/products/argus/v33_overview.htm

The TNT-related underpinnings of OMS were never documented for
third-party usage. Not being familiar with the TNT protocol, I don't
know if it would have been easy for third-party folks to connect and
use it, nor if it's secure by present standards.

As for integration with OpenVMS, it didn't become normal practice to
create a UI for both OpenVMS local usage and for OMS. Nor was there a
means created to provide one UI for both OpenVMS and for OMS- or
TNT-based UI presentations.

But then there's UI chaos here in OpenVMS in general. Which means we
continue to get and still have a plethora of very different styles and
interfaces and configuration file formats for OpenVMS, and few or none
of which are accessible through OMG. We have SYSMAN, MAIL, AUTHORIZE,
MSA$UTIL, SAS$UTIL, EFI$UTIL, various DCL commands, the SMTP bits in
TCPIP and the SMTP bits in the "new" configuration file, TCPIP$CONFIG,
etc. There's no common way to do any of this, and everybody including
the various ISVs, end-user customer developers, and the developer folks
in OpenVMS development all tend to do this stuff uniquely; differently.
No guidelines. No tools. No mechanism for entirely splitting the UI
from the app within the development tools, as is available on some
platforms. That approach doesn't end any place other than chaos and
confusion.

How many different places and how many different ways is a host name
stored on OpenVMS? A dozen? More? The chaos we have now with host
names—a fundamental part of the identity of a server—is far from
optimal.

This chaos also means multiple per-app parsers, and more than a few of
which are privileged. And potentially or actually vulnerable.

DEC did try to solve some of this chaos with the Enterprise Management
Architecture (EMA), but there was never an easy way to integrate with
that — much like OSI and some other giblets from that era, EMA was
lacking for adoption and for ease of use. DECnet Phase V NCL is
probably the largest surviving part of EMA compliance still around.
EMA was huge and complex, and didn't solve the easy cases well enough
to gain acceptance.

For the curious, there are apparently some historical bits of DEC EMA
documentation here:
ftp://ftp.iks-jena.de/pub/mitarb/lutz/standards/DEC/

> Fwiw, the management station was intended to fit an OOB niche where a
> customer had a small number of clusters and wanted a simpler
> experience. Full enterprise management was always expected to be done
> by 3rd party or layered products.

Those third-party management packages unfortunately didn't arise, nor
did the infrastructure to support those.

> The choice of a windows client made sense at the time, with the data I
> had before me. Personally, if I were to do this today, I'd pick an
> HTML5 client, assuming that there was a sufficiently secure and feature
> rich server to use on the VMS side.

I'd not expect to connect into an Apache server for an HTML5 interface,
whether the server is sending over WebAssembly or otherwise. I would
not expect to see an SMG or DECforms or TDMS or ncurses interface here,
either. Not a terminal emulator, either. I'd expect remote clients
to connect to a purpose-dedicated port. Though it would be handy to
allow that server to be reconfigured over onto TCP port 443 for ease of
connecting through firewalls, and that'd preferably mean at least some
coordination with or some integration with Apache for cases when that
also happens to be active on TCP 443.

With WebAssembly and a server on TCP port 443 or maybe on a variant
port, there's no separately-installed management client required. This
akin to what was provided via SMH, and via iLO. Given LLVM and
Emscripten or similar, there are options for the implementation
language. Arguably, this should be in the base distribution, too.
Not in an add-on. That's if this UI and this approach is fundamentally
the new way to install and manage and use OpenVMS itself and for apps,
this for those folks not ssh'ing into some app-specific code and some
app-specific tooling from a remote terminal emulator or some specific
client.

Emscripten:
https://github.com/kripken/emscripten

HPE has bet on DMTF and Redfish or ilk here. HTTPS REST. If this
OpenVMS remote management work does get near the top of the
prodigiously-sized pending-work queue over at VSI—and I'm skeptical
that queue placement will happen in this decade—support for DMTF and
better support for SNMP are undoubtedly going to be among the options
seriously considered.

> I'd also do two other things differently, if I were doing them today.
> First, there was some amount of custom server-side code to support the
> client that was private to the management station. Today, I'd want any
> server-side logic to be put into documented services so that someone
> else could write a client using them.

Absolutely.

> Second, I'd have some other organization do the client, if any such
> could be found. My reason is less about the skill set required (enough
> to do a reasonable job can be picked up fairly quickly, in my
> experience). It is more about resource management - the OS team has
> requirements that only it can fill. That it not new, of course. But
> the stresses on it are undoubtedly higher than when the management
> station work began. Figuring out what they have to do, and only doing
> that - in such a way that someone else does the rest - has to be a
> strong consideration.

The UI is a very important part of the work, but there's a whole lot
more going on behind the UI. The UI is what folks see, and the effort
and skills of a good UI are frequently discounted and a bad UI
preserved.

A third-party management could certainly do most or all of the client
work, too. The most problematic part of this and similar efforts is
adopting the related and variously-necessary changes into base OpenVMS.
Using what's available now with TNT and other APIs is not technically
difficult. The adoption of changes and improvements to OpenVMS is
where the effort will almost certainly derail. And it's a whole lot
of work to do this correctly and to integrate it, and which won't be
cheap for a third-party. And there's little incentive for a
third-party provider for any of this; it's all very much
platform-specific support, and adding platform-specific support into
OpenVMS. And the tools would have to track whatever VSI changed in the
underpinnings, for those currently-far-too-common cases where there
isn't a stable API.

What do I mean by the platform-specific support? Installations.
Backups and restoration of specific users and systems. OpenVMS is akin
to Windows XP and ilk, in how the user and system pieces are
intermingled together. LDAP integration, for authentication and mail
forwarding and whatnot. Patch inventories and patch downloads and
patch installations. Mechanisms for upgrade and patch notifications.
User and system provisioning. Remote network configuration.
Certificate trust. Surfacing and logging and reporting errors from the
underlying x86-64 hardware, for that matter. There's no volume
management. No distributed scheduler. No means to load an OpenVMS
distro into a VM and boot it into a working installation with an ssh
server configured to trust your public key or to a DMTF server
configured to trust your public key. There's a whole lot that OpenVMS
just expects the system manager to understand and to do and to do those
tasks expeditiously and manually, and that's a declining market and a
weakening assumption. Did I mention this is a big project, it'll only
happen incrementally, and only over many years?


> IMO, I could see ideally pursuing this with three vectors: key focus on
> secure modern networking, which Steve repeatedly has called out
> (correctly, IMO); providing callable services that simplify building
> management interfaces, with some simple client, either command line or
> GUI, to validate those interfaces; agreement with some external agency
> for the client itself - either a 3rd party, or some crowd-sources or
> OSS effort.

Another platform I'm working with followed something similar to the
SYSMAN model that OpenVMS started back around V5, but the platform kept
going with the approach. There are commands to manage the various
servers and subsystems and configuration files for the most common
purposes, and those commands can be wrapped for API purposes. Common
configuration file support, and this ties into the ability to load and
verify and trust and use app and system profiles, too. This approach
can also provide a bridge into other add-on or other integrated tools
within OpenVMS, such as LDAP and DNS and Apache. In OpenVMS terms, a
DCL command that might manage all network servers, whether it's
starting or stopping the SSH server or the Apache server. Not
everything, but the 90% or 95% that most folks access and use. Yeah,
OpenVMS doesn't wrap DCL commands all that well—and there's been no
announcements around updating for and generating YAML output or
PowerShell-like objects from DCL commands specifically intended to
allow app parsing—and which means a SYSMAN-ilk and SYSMAN-parallel API
would likely need to be available.

Big, big, big, decade-scale project. Expectations and scales and scope
have all shifted from the era of OMS, after all. Biggest issue is
arguably VSI sorting out and deciding what they want to do for server
management and configuration files and related, getting the foundations
built, getting the old stuff patched or pitched, and then the rest of
us then working from there. For now, we have what we have, and what we
have works well enough for the existing apps and existing OpenVMS
folks. But what we have doesn't and won't work nearly so well for
larger deployments and for newer apps and for hands-off servers. Or
for remote installation and remote management of OpenVMS servers
whether the hardware is local or hosted, for that matter.



--
Pure Personal Opinion | HoffmanLabs LLC