[Info-vax] Distributed Applications, Hashgraph, Automation

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf Of
> johnwallace4--- via Info-vax
> Sent: February 25, 2018 5:13 PM
> To: info-vax at rbnsn.com
> Cc: johnwallace4 at yahoo.co.uk
> Subject: Re: [Info-vax] Distributed Applications, Hashgraph, Automation
> 
[snip...]

> >
> > 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
> 
> You've done this before haven't you :)
> 

Yep, when doing DC consolidations, you get to see the real ugly "under belly" of DC's on all platforms

😊

> Let's also remember that in some 'organisations'
> (not just DEC, CPQ, and HP), there's potentially
> the fun of merging (and then perhaps de-merging)
> various naming conventions, the database names,
> the Bill of Material and parts numbers
> hierarchies, serial numbersm and other such
> administrivia (some of which actually matter
> outside HQ). Ideally with no service disruption
> (please don't laugh, I've seen it happen).
> 
> In those circumstances, the node/host name used for
> a given box (be it virtual or physical) really isn't
> the biggest worry. It'd be nice if it wasn't a
> worry at all, but...
> 

Agree .. when doing DC consolidations, the typical mantra is "transition", NOT "transformation".

Big challenge is always scope creep like when some BU says "lets rename [upgrade] the server as part of the migration!"

Std answer is "you can do anything you want before hand as long as it is not within 2 weeks of the workload migration".

Btw, if you want to see some real fireworks with resource naming, merging large AD environments is even more fun when it comes to account name strategies and challenges.

Duplicates (John Smith, Janitor and Jayne Smith, Doctor) e.g. who gets Jsmith that both have been using for 10 years in different facilities. What happens if John Smith is given access to jsmith in the new AD which happens to be associated with the Doctors account? This is real life as while at HP, we were involved with a number of vendors and partners on a large project which merged 14 provincial Health industry AD's into 1. 90,000 accounts across the province.

Resource naming was a huge issue.

😊

Regards,

Kerry Main
Kerry dot main at starkgaming dot com