[Info-vax] HP Integrity rx2800 i4 (2.53GHz/32.0MB) :: PAKs won't load

[Stephen Hoffman]

On 2016-02-18 20:26:32 +0000, Phillip Helbig (undress to reply said:

> To me, the big advantage of a cluster  is to have the possibility to 
> use common files such as SYSUAF and so on.

SYSUAF is a disaster and an ancient and limited design ill-suited to 
the current era, but that's being polite.

> The logical names for this are documented.

Where?   (Other than the comments that I put into SYLOGICALS a decade 
ago, that is.)   What's present is scattered around multiple parts of 
the documentation or in file comments.

> Accounding and the audit  server are similar but somewhat different.  
> Then  there is TCPIP stuff. I thought I had that down pat, then I 
> discovered that SSH has its own  default disk and directory, which are 
> by default on the system disk.
> 
> The basic problem here is that the original design was for a boot 
> server and some satellites.

The original cluster design — the earliest versions were in V3 with the 
one-writer-multiple-reader HSC storage and the later DLM and related 
support at V4.0, and which allowed ganging together multiple slower 
computers via CI, because the available VAX hardware was slow and too 
uncompetitive in the market.

What as then known as local area VAXcluster and satellites all came later.

> One really needs a search list which would be SYS$SPECIFIC, then some 
> cluster-common area, the SYS$COMMON.  A bit strange since the first and 
> third are on the same disk, but there you go.

Or...  How about using LDAP and Kerberos?    Which can be replicated 
and are already distributed, are already supported for distributed 
authentication, and which also mean you're not hammering on some subset 
of your storage.   Maybe...  Not doubling down on the existing mess, 
that is.

> I just had an OS upgrade, which took just a few minutes.  :-)  I don't 
> think that VMS should go this far, but some design improvement would be 
> nice.

Some?

> What VMS should do is clean  things up, but not break existing installations.

This request is fundamentally impossible.

You cannot fix broken designs without distrupting applications that are 
fundamentally dependent on those same broken designs.

Not until you can figure out how to store a 32-byte or a 64-byte hash 
value into an 8-byte-sized buffer in multiple applications, and while 
also maintaining the specific and insecure feature you are expressly 
seeking to replace, and get this all working across a mixed-version 
cluster, for instance.   Yes, I'm referring to the password hash, in 
this case.

> Sound impossible?  Not really.  Things CAN be set up properly now; it's 
> just a lot of work, and with each new version of VMS one has to review 
> one's setup.

Work which is unnecessary, if VSI uses existing tools and mechanisms, 
and doesn't NIH their way out of this.

> It would be nice to have a standard procedure which does all the 
> necessary definitions, so all one needs to do is tell it the name of 
> the disk where the off-the-system-disk stuff is to reside.

A volume manager would be nice to have certainly, but I'm not 
interested in creating a more complex variant of what is already a 
fundamentally flawed design.

Now if you're going to break some area of application compatibility, 
it's important to design it and drag it all as far forward as you can 
manage.

Not to shuffle the deck chairs around, in the finest Titanic tradition.


-- 
Pure Personal Opinion | HoffmanLabs LLC