[Info-vax] VSI and Process Software announcement

[IanD]

On Saturday, September 24, 2016 at 6:05:59 AM UTC+10, Stephen Hoffman wrote:
> On 2016-09-23 18:49:54 +0000, Paul Sture said:
> 

<snip>

> 
> 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...
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

and...

> On 2016-09-23 20:05:55 +0000, Stephen Hoffman said:
> 
> > Looking forward to 2020 and beyond, rather than looking at back...
> > 
> > Get DHCP working out of the box.  ...
> 
> Full native IPv6 would be nice here, too.
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

+100000000000000000000000000000

How can I inject 'Hear, hear' in HUGE Massive flashing, glowing, exploding, nasal hair grabbing actioning letters?...

How about we frame this post at the same time and anyone buying OpenVMS going forward gets flogged mercilessly for accepting anything less

</Now lets watch the 'forever backwards folk chime in *sigh*'...>