[Info-vax] IS everyone waiting?

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 24-Oct-16 8:20 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] IS everyone waiting?
> 
> On 2016-10-20 16:44:52 +0000, Kerry Main said:
> 
> > Have you ever tried to manage a large Windows or UNIX
> cluster?
> 
> Of what relevance is that to fixing the disaster that is OpenVMS
> clustering?   Bad UI designs on platforms as limited and arcane
> and
> rare as OpenVMS — or any other not-widespread platform, for
> that matter — are simply not going to make the platform more
> desirable or more
> interesting to anybody outside the installed base.   Fixing those is
> how the installed base has somewhere to grow, and new users
> have
> something to choose.   Comparing against what will be older
> versions of
> software is also specious — again, this is aiming at ~2021 or ~2026
> and
> not the ancient history of 2016.   It can and will require years to fix
> and to update some of these messes, and nobody is standing still
> in this business.
> 
> > Sure, there is room for improvements with OpenVMS
> clustering, but
> > clustering on other platforms is a rats nest as well.
> 
> I deal with some platforms that have LDAP and Kerberos
> implementations that are far easier than OpenVMS — installation
> of the servers, and creating and populating a directory is vastly
> easier than what's
> typical on OpenVMS.   But then I really don't care about ancient
> hardware and software — what you're persisting in comparing
> against — and neither should anybody else around here that's
> doing newer
> development and particularly OS development work.   Everything
> that's
> available now — some of which is significantly better than what
> OpenVMS provides — is already ancient history, from a
> development perspective.
> To be competitive, the product has to compare reasonably with
> what will be available at the time of product release — for
> OpenVMS, all of what
> I'm referring to here likely cannot exist until ~2021 or later.
> Which
> is a long time, and which means that all of what you're comparing
> with will have advanced and improved.
> 
> > I actually agree that ED should eventually be developed to
> become a
> > distributed directory more like Active Directory whereby it is
> not
> > only SSO, but also resource management (aka group policies
> etc).
> > For lack of a better term, I like to call this a "cluster of clusters"
> > (includes standalone systems as well).
> 
> Enterprise Directory as a server is not going to interest most folks
> that may be looking at OpenVMS, and also likely won't interest
> most
> existing OpenVMS sites that don't already have a directory
> running.
> Most folks either already have LDAP and Kerberos running, or are
> likely to chose a far more mainstream LDAP server
> implementation such as
> Microsoft Active Directory or maybe Open Directory.   Not with
> the
> OpenVMS Enterprise Directory product.    Which means that
> OpenVMS needs
> to operate natively and easily with AD and maybe OD.   It'd be
> nice to
> have ED and ED should be fully integrated into the distro —
> integrated, like IP needs to be integrated, and not the still-
> grafted-on approach that VSI IP is reportedly adopting — but
> then ED itself needs some work, much as the native
> authentication in OpenVMS needs an overhaul, etc.
> 
> > Regardless of the OS platform, large user management in
> today's world
> > is cross platform (SSO) and requires careful design and planning.
> If
> > you are really serious, then you not only look at the OS /
> directory
> > layer, but also the upper layers of Identity and Access
> Management.
> 
> Everybody gets to operate with Active Directory and maybe Open
> Directory, and OpenVMS just isn't good at that.   It's manual,
> arcane
> and all of what old-line Enterprise management seems to expect.
> Troubleshooting external authentication is interesting, too.
> There
> are reasons why there are sessions on how to do this at Boot
> Camp each
> year, after all.    Having done these same tasks on other
> platforms,
> it's way easier on those other platforms, too.
> 

As the old saying goes "if you do not know where you are going, there are many ways to get there."

An enterprise directory is much more that single sign-on across many systems. 

Imho, similar to MS Active Directory, Sysuaf, queues, resource mgmt, rightslist (rights mgmt.), enforcing security policies, certificate stores etc. can/should all be stored in a native distributed OpenVMS enterprise directory product. 

That is not to say sysuaf could not also be part of a local system authentication - think of the MS world whereby you have a local login (sysuaf) or a global login capability (AD).

Here is good article on what an enterprise directory is - think about all these current repositories spread across OpenVMS that you rightfully have called out as being a current issue. 

http://www.isode.com/whitepapers/ic-6083.html
https://msdn.microsoft.com/en-us/library/bb727070.aspx 

Note that there is a big difference between relational databases (what some have suggested here) and LDAP directory databases. 
https://blogs.oracle.com/treydrake/entry/ldap_vs_relational_database 

Btw, despite its popularity, most experienced directory folks I have talked to will tell you that MS AD is one of the lowest form of directory products available today.

> > Application upgrades is always a challenge and is not something
> > specific to OpenVMS because they are application specific.
> When Apps
> > are designed, they seldom think about how to upgrade them
> cleanly
> > other than the traditional stopping the app, updating the app,
> > optionally restarting the system and then restarting the App.
> 
> Ayup.    On OpenVMS, there's no help here.   Not by present
> standards.
>  OpenVMS and RMS certainly helpfully throw the equivalent of a
> burlap sack of rabid weasels and a few granite boulders into the
> application developer's canoe, too.
> 
> > I agree areas like OpenVMS patching, tools and other areas can
> be improved.
> >
> > Having stated this, you are never going to get to the point
> whereby
> > clusters are going to be simple enough for sysadmins with very
> little
> > cluster or OS knowledge are going to be able to properly setup
> > clusters in a medium to large environment - on ANY OS
> platform.
> 
> I think you're wrong.   Utterly.   But then I'm working with
> systems
> that are vastly easier than what you're clearly accustomed to, and
> systems that are vastly more capable, and I already know how to
> make
> OpenVMS clustering vastly easier to manage.   Downside is, I'd
> end up
> breaking at least some parts of the much-vaunted compatibility
> and replacing more than a little of the mess that comprises the
> "user
> interface".   The upgrade would be somewhat disruptive, in other
> words.
>   But then that's going to be the case with fixing any of the long-
> standing problems in OpenVMS.  That compatibility is why more
> than a few of the messes were created, and why they still exist.
> 

I am not sure what OS platforms you are dealing with, but after having to deal with most of them (Solaris, AIX, OpenVMS, NonStop, HP-UX, Linux, Novell, z/OS, Windows, other misc. ones) as part of large DC migrations, I would love to know which server OS's I have missed.

One key concept that has to be understood when dealing with clusters and why it is not something a rookie should be allowed to do is that it is not just the technical steps, but also how they will impact the business when upgrades, patches, failures, backups, security, batch queues, HA/DR (things like RTO/RPO) processes kick in. Setting up clusters requires not only an understanding of the technology, but also the business SLA's they need to support.


Regards,

Kerry Main
Kerry dot main at starkgaming dot com