[Info-vax] VSI and Process Software announcement

[David Froble]

IanD wrote:
> 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*'...>

I don't use DHCP ....

Not saying it cannot be useful for some people ....