[Info-vax] VSI and Process Software announcement

[Dirk Munk]

Stephen Hoffman wrote:
> On 2016-09-23 18:49:54 +0000, Paul Sture said:
>
>> On 2016-09-23, David Froble <davef at tsoft-inc.com> wrote:
>>> Bob Koehler wrote:
>>>> In article <32d1c9c9-97a7-45ca-9f90-f769da2a53c7 at googlegroups.com>,
>>>> IanD <iloveopenvms at gmail.com> writes:
>>>>> I assume when they mean 'older stack' they are meaning TCPIP Services?
>>>>>
>>>> Yes, the one many of us still stubbornly refer to as UCX, is what I
>>>> assumed, too.  What other 'older stack' would VSI have, that they
>>>> could plan its demise?
>>>
>>> Got to wonder why you are stubborn.  UCX was the product prior to
>>> TCP/IP V5.
>>> The TCP/IP V5 stuff came from the T64 product.  Not UCX.
>
> UCX was the prefix.   The product name has been TCP/IP Services for a
> very long time.    There's all sorts of history and baggage here, too —
> both organizational and technical...
>
> We're probably also going to get to go through yet another facility
> prefix change with this new VSI work, but that's fodder for some future
> discussion...
>
>> The user interface stayed much the same as UCX V4 though.
>>
>> When I first heard that the Tru64 version was being "imported" I was
>> kind of hoping for a better interface, albeit not one "too Unixy", but
>> that didn't happen.
>
> Looking forward to 2020 and beyond, rather than looking at back...
>
> Get DHCP working out of the box.    OpenVMS boots up, requests a DHCP
> address,

SLAAC or DHCPv6 is the recommended way to assign an IPv6 address. Now of 
course with IPv6 you can have lots and lots of addresses. Before I tamed 
by Windows PC in assigning IPv6 addresses, opening a new tab in 
Seamonkey caused a new IPv6 address to appear, so within a short while I 
had dozens and dozens of IPv6 addresses.

> and allows (only) remote-management connections, and an ssh
> server.   Generate a system password based on the server serial number.
>  That's available on Itanium.    Maybe use the MAC address if there's no
> serial number set or if the x86 box has no serial number, but that ends
> up being far too obvious.   This to allow full remote management on
> first boot, right after installing the bits.

Why not use a built-in web interface on a chip? That is the default way 
for any modern x86 system.

> Get SNMPv3 working, and
> also certificate-protected TNT/Argus, and ssh as part of this
> configuration.   (Want to play in the cloud, or in a VM or a hosted
> data
> center or such?  You can't always assume and can't depend on having a
> hardware console, and remote access to same...)
>
> Load common root certificates as part of the install.   Mozilla via
> curl
> or however y'all choose to do that.   Preferably also one set of
> directories for certificates, and not having them scattered around
> Apache and SSL and SSL1 and who-knows-where-else...
>
> Always create all server directories, using consistent and reserved
> UICs.   Offer to migrate the existing morass over to consistent users
> and UICs during an OpenVMS upgrade.  There's no point in not creating
> all of this stuff, and no reason not to load templates or whatever
> other
> pieces are needed.   Allow the system manager the choice of which
> services to start or not, via a consistent command interface and also
> available via a callable API.   But don't add all the complexity of
> checking for directories and users and the rest, both for the VSI
> folks
> and services, and for the ISVs and developers.    It's always there,
> it's always consistent.   We aren't on VAX boxes and we aren't on
> 456MB
> disks, after all.
>
> (This UIC mess shouldn't even exist.   It's a throwback to RSX-11M
> and a
> very old and very limited world-view.   Use UUIDs here.   This avoids
> most of the messes of UICs, including collisions.   Allow users and
> applications and application bundles to have associated UUIDs.   UUIDs
> and work toward containers properly applied also get away from the
> mess
> that is facility prefixes.   Obviously out of scope for IP work.
> This
> is part of the authentication overhaul, and toward more modern and
> modular application management.)
>
> Install Apache as part of the base distro.

Why Apache? Why not WASD? Because "everybody is using Apache"? If VSI 
can use Multinet components, then they can also use WASD. Instead of 
porting every new version of Apache to VMS, they can just add new 
functionality to WASD. After all WASD has a far better performance, and 
is more then properly documented.

>
> Install LDAP and particularly LDAP server as part of the base
> distro.

It seems there is a tendency to go to full blown X.500, instead of the 
smaller LDAP. Hey, we already have that on VMS!!!

> This in preparation of hauling the whole cluster management and
> authentication morass forward to this millennium.
>
> Get the configuration morass under control.   That isn't a combination
> of a command-line tool, a DCL menu, and a plethora of rustic,
> artisanal
> configuration files.   Pick one, preferably a replacement for the
> command line tool.   The menu morass is for a variety of reasons, but
> then there's also no in-built menu-generation tools.   Allowing
> OpenVMS
> users to avoid having to roll their own and wildly inconsistent menus > —
> some use ^Z, some use QUIT, some EXIT, some use 9 or 99, some others > use
> who-knows-what-else.  I don't care if this is DCL — well, I'd prefer > it
> not be or not require DCL — or some other scripting language, or some
> other tool.  But the lack of this interface means that everybody does
> configuration tools differently...
>
> Get ftp and telnet out of the default configurations and menus, and
> make
> folks work to enable those, and any other insecure transports,
> services
> or tools.

For some odd reason you don't want to use IPsec so it seems. But if you 
do, and make your IP network secure on the place where it should be done 
(the network stack), the suddenly all those insecure protocols become 
secure. And your IP cluster communication is also secure. That would be 
a really modern approach instead of antiquated protocols like SSH, or 
would you like IP clustering to use SSH???

> Lead folks to ssh, sftp, and related.   Get DECnet out of > the
> default install path, and for the same reasons.   Don't enable stupid
> choices.
>
> Disable all network services that are incompatible with DHCP, whenever
> DHCP is enabled.

Which services do you mean? The list of DHCP options is almost endless.

>
> Make IP cluster aware, such that you're really configuring the cluster
> akin to one host — there are still some advantages to clustering on
> OpenVMS, but the scatter-shot cluster management stinks and definitely
> makes the whole clustering implementation far less desirable —
> including
> automatically finding and sharing configuration data.   (This likely
> ties into LDAP, though there are other ways to do this.)
>
> Don't use RMS indexed files for TCP/IP Services configuration data.
> Use SQLite databases or something that makes particularly rolling
> upgrades less complex, less constrained, and less hack-ish.

Why not add RdB again? A long time ago RdB runtime was added to VMS to 
the dissatisfaction of Oracle. Negotiate with Oracle. Why spend precious 
time in porting SQLlite if VSI can make a deal with Oracle to add a real 
VMS database?

> Preferably
> use one file, not the usual blizzard of files.   Maybe give OpenVMS
> directories that specifically store configuration data for
> cluster-wide,
> system-wide, application-specific and user-specific activities, but
> that's quite possibly out of scope of any IP stack work.
>
> That's off the top...   There's rather more work here, to bring
> OpenVMS
> up to what's increasingly expected, and what will be expected 2020 and
> beyond...
>
>