[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> DaveFroble via Info-vax
> Sent: February 25, 2018 12:16 PM
> To: info-vax at rbnsn.com
> Cc: DaveFroble <davef at tsoft-inc.com>
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph,
Automation
> 
> johnwallace4 at yahoo.co.uk wrote:
> > On Sunday, 25 February 2018 07:22:01 UTC, DaveFroble  wrote:
> >> Craig A. Berry wrote:
> >>> On 2/24/18 12:33 PM, Kerry Main wrote:
> >>>
> >>>> In OpenVMS, you could also build master LD containers to image
> backup to
> >>>> new OS, customize and reboot. Maybe 15-30 minutes start to
> finish?
> >>> Then another month of tinkering to figure out how to change the
> node
> >>> name without breaking anything.
> >> This is the result of setting up some things once, and assuming
they
> will not
> >> change.
> >>
> >> One would hope VSI takes a critical look at such, and perhaps uses
> some database
> >> to contain all such things.  Then there is still the question of
whether
> such
> >> data would be set at boot time, or could be changed on the fly.
That
> could get
> >> sticky.  If not a re-boot, perhaps some other type of "refresh".
There
> would be
> >> the question of other computers "knowing" the node name, and
> getting confused.
> >>
> >> --
> >> David Froble                       Tel: 724-529-0450
> >> Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
> >> DFE Ultralights, Inc.
> >> 170 Grimplin Road
> >> Vanderbilt, PA  15486
> >
> > What are names used for (and useful for) in the context of
> > computers and applications (and, if necessary, users)?
> >
> > How many of those uses are things that people outside the
> > IT Department should care about?
> >
> > How many of them are things that should be important to
> > the innards of OS, rather than (say) some OS-independent
> > distributed naming layer on top of the OS?
> >
> > Host names, for anyone outside the IT department, for
> > example? In a seriously distributed environment, are
> > host names as such not a rather dated and devalued
> > concept? Perhaps they should even be deprecated (for
> > things being designed from scratch)?
> >
> > Even back in the 1980s, in a terminal-centric environment,
> > things like terminal servers allowed user-visible 'service
> > names' to be distinct from IT-visible host names. A bit of
> > 'terminal server magic' was all that was needed. For LAT
> > users, or for telnet users (round robin DNS?).
> >
> > What's the 'modern' equivalent, where what is needed is not
> > just users talking to application services but applications
> > talking to other applications, in a (semi?) standardised
> > fashion? (The obvious legacy approach is to use well-known
> > IPhostnames and wll-known IP portnumber/name but that's
> > not really helpful for reasons that should be fairly obvious)
> >
> > And why do the OS internals have to get involved in this,
> > except to provide the necessary facilities in a suitably
> > robust and trustworthy way?
> >
> > As a historical side note, I'm thinking that back in the
> > 1980s, there was a VAX VMS software product that did the
> > *technical* stuff of changing the SCSnode and DECnet
> > name and stuff like that as part of deploying what Kerry
> > likes to call a 'golden image'. It might have been called
> > VAX Remote Systems Manager or something like that, and it
> > wasn't just intended for use within a VMScluster. No
> > matter. Anyway, on top of that, there was still the licencing
> > stuff, which DEC did one way, others did other ways (FlexLM,
> > dongles, etc). Three decades later there still isn't a
> > universally accepted licence management and enforcement
> > mechanism.
> >
> > DHCP and friends (mDNS etc?) may be part of a modern
> > follow on. Or may not. But I'm struggling to see why
> > a host name (as such) is still important (outside the
> > IT department). Application service names? Different
> > matter; they may well need to be meaningful, or at
> > least pre-agreed.
> >
> > To an extent, the same naming issue applies to storage
> > (files etc). That data someone wanted, those files
> > that need restoring, are they on C: or are they on
> > banana$dka300:[john] or /usr/users/john, or what (and
> > where)?
> >
> > Enlightenment welcome.
> 
> Some good questions.
> 
> There is actually two issues.
> 
> 1) Is node names the way to ID a computer?
> 
> 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.


The bigger the IT environment, the more critical it is to get resource
naming right. The challenge is that server naming is a bit of a OS
religion in may shops and you often have varying levels of IT experience
and maturity.

Depending on the site's IT maturity, the best approach to keep track of
who supports any IT Infrastructure device or App  is in the local help
desk / service desk system. The Service Desk is a typically a web based
CMDB based system which can be used for tracking and maintaining all
CI's (configuration items) and this includes server AND App names. If a
user can not access a specific service, they should simply log a call
with "unable to connect to the XYZ" service. Each Service has a primary
owner who then determines if the issue is network or server or app or ??
related. If someone leaves and there is a new server owner assigned,
then it can be updated transparently without telling any other IT
people.

Course, this breaks down pretty quickly in sites with less IT maturity,
where the Service Desk is not kept up to date.

Re: Server Naming considerations -

Server names like POPEYE, MOE, JOE and CURLY etc. are ok when the site
is small, but is obviously not a scalable naming strategy.

Past mistakes also include putting location and/or functions in the node
name. Other notes:
- always assume the server may be relocated to another location e.g. DC
consolidation (e.g. some Cust's now have a server called TOR-001 server
now sitting in a Montreal DC beside a server called MQO-00x)
- think about a hacker who sees a node named PAYROLL or PROD-ERP in the
node name. Or a server with DB or WEB in the name? 
- should also align with naming on other platforms e.g. align with
NetBIOS and TCPIP host name requirements (no illegal characters).

Think those names might provide an incentive and/or clues (web server
vs. a DB server) as to how to approach a hack?

Most large environments prefer a generic server naming approach for prod
e.g. SYS001, SYS002, SYS00x etc. or MFGxxx which makes them easier to
relocate and less visible as primary hacking targets. They might do
something like sub-divide servers 1-100 are Wintel range while servers
200-400 are Linux, OpenVMS servers are 401-500, LAB/Dev servers are
800-899 etc.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com