[Info-vax] Distributed Applications, Hashgraph, Automation

[Stephen Hoffman]

On 2018-02-27 02:37:52 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of Stephen 
>> Hoffman via Info-vax
>> Sent: February 26, 2018 11:21 AM
>> To: info-vax at rbnsn.com
>> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
>> Subject: Re: [Info-vax] Distributed Applications, Hashgraph, Automation
>> 
>> On 2018-02-25 15:48:02 +0000, Kerry Main said:
>> 
>>>> 
>>>> -----Original Message-----
>>>> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of Stephen 
>>>> Hoffman via Info-vax
>>>> Sent: February 24, 2018 7:10 PM
>>>> To: info-vax at rbnsn.com
>>>> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
>>>> Subject: Re: [Info-vax] Distributed Applications, Hashgraph, Automation
>>>> 
>>>> On 2018-02-24 20:52:20 +0000, Kerry Main said:
>>>> 
>>>>> Never been much of an issue if its just the OS (modparams) and TCPIP 
>>>>> (tcpip$config).
>>>> 
>>>> No, it's not.   Go try it.  We'll wait.
>>>> 
>>> 
>>> If just changing the node name and the TCPIP address as part of a new 
>>> OS deployment (e.g. gold image deployment - what we are talking about 
>>> here), then this is not a big deal.
>>> 
>>> Done it many times.
>> 
>> Go try changing a host name of a previously-installed and non-trivial 
>> OpenVMS system.  Getting a domain-change request can be a real 
>> challenge, absent a strategy built on guests or containers.
> 
> Mmm, we are talking in this thread about changing the server and tcpip 
> host names of a gold image which was just image copied to a system 
> partition?
> It was already mentioned that if Apps are installed with no focus on 
> the environment being homogeneous and/or keeping things off the system 
> disk, then there will likely be challenges with changing names.

I've yet to encounter a a installer that doesn't have to change the 
host name at install time, and — with some of usual sorts of apps 
installed — that usually gets entertaining.  Or the deployment 
configuration is headed toward thinner provisioning and installing the 
packages separately, which avoids having to rename stuff, but adds 
install-time "fun".  And the "thinner" provisioning approach is 
probably a more sustainable approach than the omnibus "gold master" 
installations, but all of this is presently bespoke code and tooling.   
And as was suggested earlier, please go try changing the host name of 
an existing and non-trivial OpenVMS host.  It gets entertaining.  
Particularly with Apache or some of the other packages that cache the 
host name around the file system or the configuration data.   OpenVMS 
itself caches the host name in some "odd" places, including in the 
RIGHTSLIST...

> 
> With the new IP stack, this should make it even less of an issue with OpenVMS.

Feel free to try the same host-renaming exercise starting with Multinet.

Changing the host name of an OpenVMS server — whether from an omnibus 
master or from an existing server — far more work than it should be.

Deploying and redeploying and reconfiguring OpenVMS is something we all 
need to be better at; all our apps and including OpenVMS itself.  The 
host name mess is just one small aspect of this problem, too.;






-- 
Pure Personal Opinion | HoffmanLabs LLC