[Info-vax] VSI and Process Software announcement

[IanD]

On Saturday, September 24, 2016 at 7:08:18 AM UTC+10, David Froble wrote:
> 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, 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.    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.
> > 
> > Install LDAP and particularly LDAP server as part of the base distro.   
> > 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.  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.
> > 
> > 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.  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...
> > 
> > 
> 
> You just want to take all the "fun" out of running a VMS system ....
> 
> :-)

lol

I see no fun in it at all having ground my teeth a number of times doing this

I ended up having to redo a number of the installs too, partly because I didn't know what I was doing and partly because it's just too easy to make mistakes or miss something

Security and stability is enhanced by boiler plating what is known to work rather than choosing from a myriad of options

I'd eventually like to see standard hardware with options selected as a ready-made package install with all the configuration already done - like what you can buy on Amazon when you buy a pre-configured OS + package install. Much much easier to do when OpenVMS will be on a VM host because hardware options will be more uniform

We might even get to the stage where OpenVMS is run from a single distribution file and unpacked and run in memory as a turn-key. No more having to update EXE's or code in myriads of directories and scan for security breaches and/or corruption. Updates would be simply a matter of download a single file. Checksumming an entire system then becomes much easier as it's just one single file. We could then finally move towards separating the OS from user data totally and could then lock down the OS even further. It's much easier to ring-fence a static or near static area than a dynamic one

OpenVMS needs to pick up the security mantle it once had and forge ahead with new ideas to attract people back to it - security going forward is going to become a major issue. Performance gains will slow, storage will get faster but security IMO will become more important than ever and a big diffirentitor