[Info-vax] How do I make zip, unzip etc. available to all users?

[Stephen Hoffman]

On 2016-01-08 08:35:27 +0000, Hans Vlems said:

> I'm just a hobbyist so my requirements are not as strict as a shop that 
> serves a 24x7 production line.
> Applying a VMS patch on 11 Alphas was however a RPITA. Would I've 
> wanted a vendor pushed/forced update like Microsoft, Mozilla etc do? I 
> don't think so. I prefer to know what gets fixed and if it is something 
> that bothers me.

For more than a few folks, the reticence is around the perceived 
quality of the patches.   Or the lack thereof.   If the patches install 
and work, they're more easily accepted.   If the patches break things, 
then it's a circling-the-drain sort of mess, where even working patches 
get deferred and delayed, where server security weakens, where system 
integrity suffers, and where bug-related support calls increase 
including the sorts of callers that expect proof, and... well.... 
badness ensues.   This mess was also a factor in the genesis of the 
roll-up patches — running full regressions for all of the permutations 
of a dozen disparate point fix patch kits is time-consuming and 
expensive.

> Installing patches or layered products for 11 systems ought to be 
> easier than manually repeating the same procedure.
> All systems are basically configured the same. I am working on one 
> system that stores the kit and one batch job that does all the work.

For another platform, I run a central patch server.

That server downloads and caches patches from the vendor, and — if you 
want or need to manage that flow — stage which patches are available 
for deployment, and which are held pending.   This at the patch server. 
  Individual systems then query that server either on a schedule or 
manually, and then download and install the patches, and — prompting 
for permission — require at most one reboot to complete the 
installation.  Internally, this might actually be several reboots in a 
row, but control — unlike OpenVMS — is not returned to the user between 
any sequenced reboots that might be necessary.

These individual systems can then either be configured for automatic 
installation, or manually triggered.

For the end-user or the system or environment manager or the DevOps 
team, this amounts to pressing a button or issuing a single command, 
and all of the staged patches are downloaded from the vendor or from 
the local patch server, installed, configured and launched.

For those environments where this approach is insufficient or 
inappropriate, an environment akin to an installation via host-based 
InfoServer is available; selecting and installing new disk images, or 
pushing disk images.

If site-specific prepared disk images are inappropriate, then there's a 
web-based system that allows either pushing out specific software 
packages to specific systems, or allowing the end-users of the systems 
to select and install centrally-provided, licensed and managed software 
packages — self-service installations.

All of this is available now.   All of this works.  If folks do not 
currently have this for some particular platform — I don't know the 
Windows patch process and distribution mechanisms, for instance — then 
they likely will soon have these capabilities.   These are the sort of 
basic system operations and tools that tend to spread — not necessarily 
the same tools, but the same ideas and capabilities — that spread 
across all platforms, and that become expected.

>From the patch processing and associated contract and verification 
data, VSI also gets information on active OpenVMS systems and on 
down-revision systems, can get opt-in data on server configurations, 
and other benefits, too.  Probably opt-in crash data, too.   If a patch 
gets installed and applications and/or servers suddenly start crashing, 
maybe there's a bug that got past QA and the patch should be put on 
hold?  Better integration and quicker feedback, rather than the 
engineering team not knowing (at all), having to wait for support calls 
to be logged, and then sending out email messages to... somebody.  Or 
if there are crashes that are fixed by some existing patch, prompting 
for a particular patch, whether via the patch process and/or email.   
Given it's opt-in and given crash scanning can be partially automated, 
accepting crash reports from even off-contract and hobbyist sites is a 
way to up-sell support, and — if there are a boatload of crashes — a 
way to identify problems that can or will effect supported sites, too.  
 Post up a sane price and an HTTPS order form — web browsers can be 
embedded, and can be text-based — and you might sell a few, too.

What the OpenVMS system management folks have to go through to get 
InfoServer and/or patches and/or patch downloads and the rest is 
utterly absurd.   Computers are good at automating processes, even with 
the desire or the need that some sites have for manually pulling an 
installation "trigger".

Now some of you will rightfully harrumph over these features and claim 
"we've always done it this way" or "this works", well, good on you.   
Glad things are working out.   But ponder this...  New users are not 
going to want to learn and deal with this.  More than a few just aren't 
going to patch or to upgrade, too.   Yes, "we walked uphill to school.  
Both ways.  In the snow."  Etc.   Have fun expanding the installed base 
with that.   Yeah, "not my problem".   But if new users and new 
applications don't arrive at least as fast as the existing applications 
and environments retire or migrate off of OpenVMS, then OpenVMS is 
dead.  The more barriers are in the way of adoption and operations, the 
less likely anybody outside of a legacy shop will choose OpenVMS.

The article on changing the IP address of an OpenVMS server is doing a 
brisk business.  Which should tell you some things about user 
interfaces and changes in expectations.

But then this is rather advanced and probably way past aspirational for 
the folks at VSI, given their work schedule, staffing, and the utterly 
stellar state of the existing OpenVMS patch management tools.

> VMS systems operate in different environments and one solution won't 
> do. That is where a system manager still earns his keep. The same 
> applies to Windows servers, many are not blindly upgraded as soon  
> Microsoft issues a patch.

Which gets back to the trade-off between the fear of new and previously 
unknown bugs and the occasional known bugs, and the perceived risks of 
the existing and known bugs.   More than a few customers clearly don't 
trust Microsoft to be able to completely manage the complexity of their 
hardware and software environment.  (That Microsoft does as well as 
they do with the massive permutations they deal with is no small 
achievement, too.)



-- 
Pure Personal Opinion | HoffmanLabs LLC