[Info-vax] Distributed Applications, Hashgraph, Automation

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Mon Feb 26 12:41:20 EST 2018


On 2018-02-25 17:15:48 +0000, DaveFroble said:

> 1) Is node names the way to ID a computer?

In OpenVMS, host names are central to clustering and a whole lot of 
normal operations.  In many other environments, servers are installed 
with host names acquired using DHCP and DDNS, or generated host names, 
and with locally-generated or ACME-acquired certificates or 
install-time certificate provisioning.  Certificate authentication and 
SSL are centrally tied to the DNS host name and the presence of the 
private key for the certificate.  Generating a host name is one thing, 
getting a proper set of certificates loaded (securely) can be more 
entertaining.  OpenVMS didn't work all that well with DHCP-provided 
configuration data the last few times I've tried that; some of the 
network services really wanted more traditional host names.  Folks that 
don't use those services however, might have an option with DHCP and 
DDNS configurations.

Getting the right public certs and an appropriate public-private key 
pair into a newly-installed host or into a guest in a VM or into the 
app(s) in a container is its own little source of entertainment.  
OpenVMS doesn't really have anything similar to RedHat Kickstart, for 
instance.

Malware and adware is using domain-name generation these days.  This to 
avoid some of the more common detection measures and block lists.  But 
I digress.

> Well, you need to know someone's phone #, or email address, or such 
> before you can contact them.  Sort of the same issue with computers, 
> right?  Not saying node names is the best method, but, it is the method 
> we're used to using.
> 
> 2) How to manage such identification?
> 
> On VMS there is not one central app that can do so.  Nor could it be 
> static, as requirements change, and the app would have to be updated to 
> include new requirements.
> 
> Can such be managed?  Yes, and I've done so in the past.  If it's been 
> a short while since the last change, I was able to remember the correct 
> incantations to get the job done.  After a couple of years, it was a 
> bit more questionable.  It should not be that way.

DNS records (SRV, A and increasingly AAAA records) and LDAP are some of 
what is commonly used for that.  mDNS in a few other environments, and 
for locating local network resources.   OpenVMS has no support for 
mDNS.  There are other choices available here; some of the Apache 
projects are right in this area, for instance, and not the least of 
which would be Hadoop and all its adjuncts.   Hadoop is something VSI 
has mentioned, too.  Maybe Hashicorp Nomad for dealing with all of this 
across various private or public hosting providers, too.

IPv6 and 802.1x authentication and the ACME PKI certificate API, and 
DHCPv6 and many other pieces and parts were not things that many 
OpenVMS folks were seemingly commonly using, though.  Many (most?) use 
very traditional IPv4, NAT'd networks and protocols and implementations.

Note: Not enough folks are using the ACME API within OpenVMS (and the 
doc for that API is... problematic), but that ACME API I'm referencing 
here is very different from the PKI ACME API that is used to acquire 
signed digital certificates.

To paraphrase a comment that's been around for a while...   OpenVMS 
systems are often managed as pets with names and individualized 
configurations and care, and where other folks and other server systems 
are managed more as livestock.  Or the folks that are increasingly 
managing multiple herds of livestock.  For folks running one or two 
servers or incremental manually-processed deployments, this sort of 
stuff makes little sense for the servers, but might make sense for the 
clients connecting into the servers.  For folks running ten or a 
hundred or more servers or that are automating server deployments, 
things here get much more interesting.





-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list