[Info-vax] Where to locate software

[Stephen Hoffman]

On 2016-06-09 14:46:25 +0000, Kerry Main said:

>> 
>> -----Original Message-----
>> 
>> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
>> 
>> Stephen Hoffman via Info-vax
>> 
>> Sent: 09-Jun-16 8:43 AM
>> 
>> To: info-vax at info-vax.com
>> 
>> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
>> 
>> Subject: Re: [New Info-vax] Where to locate software
>> 
>> 
>> 
>> On 2016-06-08 23:18:47 +0000, Paul Richards said:
>> 
>> 
>> 
>>> I'm running OpenVMS 8.4 on FreeAXP and am a comparative newbie.
>>> 
>>> So, a noob question: I am planning to install some of the HP 
>>> Open-source software and Freeware.
>>> 
>>> 
>>> 
>>> For those applications which don't automatically install where should I
>>> 
>>> locate them such that I can run them from any directory?
>>> 
>> 
>> 
>> Welcome!
>> 
>> 
>> 
>> I'm one of the resident curmudgeons, and deal with more than few 
>> packages and tools, and have worked with more than a few open source 
>> packages on OpenVMS.  And I use a mix of operating systems beyond 
>> OpenVMS and Windows.
>> 
>> 
>> 
>> This is an excellent question!   That's something most folks arriving 
>> from competently-designed systems might wonder, too.
>> 
>> 
>> 
>> Alas...
>> 
>> 
>> 
>> That you even have to ask this question points to a hole in the 
>> available documentation and resources.
>> 
>> 
>> 
>> Worse, OpenVMS itself has no idea how to do this and provides 
>> absolutely no guidance, and neither HPE nor VSI has stated any plans 
>> around draining this particular swamp.   VSI has come the closest here, 
>> with some very general discussions about maybe adding some support for 
>> containers in some future release.
>> 
>> 
>> 
>> In short...  Have at.  It's a free-for-all.
>> 
>> 
>> 
> 
> 
> As long as one wants to ignore available documentation and/or best 
> practices and/or constructive advice from those familiar with the 
> system  platform, then you are correct.

Pointers?   Recommendations around software installations and 
packaging?  This is not something that is documented with OpenVMS, 
beyond what's in the PCSI manual, the VMSINSTAL manual and the modular 
programming docs.

> Course, this applies to any platform one is just becoming acquainted with.
> 
> 
> 
> Performance, capacity planning, disk space availability, security, 
> available  hardware, changing technologies (e.g. flash SSD's), HA 
> requirements, App specific restrictions and pre-existing practices are 
> all areas that need to be  considered when looking at where to locate 
> new workloads on a system  platform. In a VM, its less of an issue as 
> there are only a few options.

Keeping different packages and their dependencies from getting tangled 
is a pretty basic requirement, as is efficient deployment.   OpenVMS 
has insufficient mechanisms for either of those tasks.

> Hence, there is no one right solution to install applications on any OS 
>  platform. The best app's are those that recognize this and provide the 
>  SysAdmin with the flexibility to make their own decisions that are 
> best  for their local environment.
> 
> 
> 
> Course, this applies to all OS platforms as well. 
> 
> 
> 
> Can this be improved on OpenVMS?
> 
> 
> 
> Absolutely, especially with changing technologies making decisions made 
>  In the past a bit of a non-issue.
> 
> 
> As an example - cheap 500GB SSD's make the old argument of worrying  
> about system disk space less of an issue.
> 
> 
> However, for those who have managed large Windows or Linux 
> environments,  the same is true.

I really don't care to discuss Windows or Windows Server or Linux 
limits in general.  Well, not outside of cases where I was marketing 
OpenVMS or some other product against those.   And OpenVMS isn't and 
won't be marketing against Windows and Windows Server for many years.  
If ever.     OpenVMS can and will be marketed against Linux servers 
certainly, but that's going to remain a tough sale for many years.  
More often than not, folks are migrating from OpenVMS to Windows Server 
or Linux or other platforms, as we've all experienced, too.    
Conversely, tell me about what's good about Windows or Windows Server 
or Linux and whether those advantages can work or can be reasonably be 
implemented in OpenVMS or applications, or can move OpenVMS sales 
forward, and then I'm interested.  That's part of why I learn and use 
other platforms and other tools; that can make my OpenVMS code and my 
OpenVMS support better, too.

>> Stick it everywhere, stick it anywhere, however you want, in the system 
>> directories or in private directories, it's completely and utterly up 
>> to the administrator and to the folks that created the installation 
>> kits — even the kits and kitting software lacks any a particular 
>> recommended organization for the installed software — which means that 
>> you'll have a zillion opinions and absolutely no consistency, even with 
>> the vendor products.  Upgrades can be well handled and clear, or they 
>> can be a complete train-wreck.   There's no standard way to remove more 
>> than a little of the installed software, no auditing of what's 
>> installed, and removing installed software — PCSI does better than most 
>> here — is completely manually implemented by whoever created the kit or 
>> the install.   If they even provide a way to remove the software.   
>> There's a little modular programming documentation that recommends 
>> using prefixes on file names and logical names and such — and facility 
>> prefixes registered with HPE and VSI, but I'm not sure there's any way 
>> to even get those registered these days — but OpenVMS itself 
>> *routinely* violates that recommendation, as do more than a few of the 
>> open source and commercial packages.
>> 
>> 
>> 
>> TL;DR: Vendor app design recommendations?  Doesn't exist.  Application 
>> bundles or packages?  Doesn't exist.  App stacking or containers or 
>> such?  Doesn't exist.  Sandboxes or jails or BSD pledge() or other 
>> forms of application security and isolation?  Doesn't exist. 
>> Recommendations for embedded libraries or frameworks?  Doesn't exist.
>> 
> 
> 
> Re: App stacking doesn’t exist on OpenVMS?

App stacking does not exist on OpenVMS.   You and other folks should be 
grumbling about this, too.

> Better not tell all those OpenVMS Customers out there who have been 
> 
> running multiple applications on the same OS and/or same cluster for 
> 
> decades. I am sure they will be shocked to find this out.

Tried to convince some folks that what you're referring to here is app 
stacking?  What you're referencing is bespoke management of the server. 
  That's managing pets and not managing livestock.   Sure, that works.  
 But it's a manual configuration process and something that only gets 
automated with locally-written tools.   (There's nothing even remotely 
like Homebrew on OpenVMS, nor anything akin to the various package 
managers on Linux, for instance.

http://brew.sh

As currently implemented on OpenVMS, that manually-configured and 
locally-replicated approach also tends to collide (badly) with 
dependencies in the base OS.

How many of us have been working through the SSL to SSL1 migration, for 
instance?

But you know this.

> For those with OpenVMS clusters, common system disks (dual for rolling 
> Upgrades) greatly simplify the App stacking process by providing common 
>  Boot, startup and config files. Ask a Windows person how they do this 
> on  a Windows cluster .. hint - they don't.

OpenVMS clustering is a mess, at least from the perspective of the 
initial configuration, the deployment of ACME, or — on topic here — 
shared software installations.

Manually maintained startup and shutdown files are not a viable 
strategy for herd-maintained servers, either.

But again, you know this.

I really don't care about Windows limits, outside of cases where I was 
marketing against those.   And OpenVMS isn't and won't be marketing 
against Windows Server for many years.  If ever.    Again, tell me 
about what's good about Windows or Windows Server or Linux or whatever 
other platform and the respective applications or associated tools — 
and whether any of that can be reasonably be migrated to or can be 
implemented in OpenVMS or in applications — and then I'm interested.

> :-)
> 
> 
> 
>> Integrating open source packages?  Always fun.   They all work 
>> differently.    Alas.   The (many) other replies here in the 
>> comp.os.vms newsgroup will have some examples of the various user 
>> recommendations.
>> 
> 
> 
> Like all of the other OS platforms, the install process for OpenVMS 
> could definitely use improvement - no one would likely say this is not 
> the case.

Other than OpenVMS being years behind what's becoming typical and 
available, sure.

> Again - changing technologies are going to change the way that future  
> Install decisions are made. As an example - given system disk space is 
> not  the same concern as it used to be, perhaps a VMS install should 
> come as an image (LD container?) with most of the core Apps already 
> installed and  the "install" process is simply a "Prod Remove" process 
> i.e. just remove  those you do not need, then update the license file 
> and startup /config files ..
> 
> 
> 
> Another LD container could come with most of the common 3rd party 
> packages pre-installed. Same process.

Using LD is likely more a reflection on problems and limitations with 
PCSI than an example that I'd cite around app stacking.    PCSI needs 
better handling of duplicate file names, integration with source 
control systems, better tools for kit creation and updates, the ability 
to audit installed software, the ability to reinstall OpenVMS over 
itself — which also ties back to how poorly OpenVMS isolates settings 
from system files — and various other areas.   On the plus side, 
support for multiple versions sort-of falls out of LD.  But support for 
isolation doesn't — the dependencies are separate and not integrated 
with the apps.  (App bundles aren't a panacea, either.  But they're 
better than stuff scattered all over the system disk.

BTW: "Best practices" is increasingly used as industry jargon for "I 
did some web searches and outsourced even thinking about this issue" or 
more succinctly as "it's not my fault" when something craters.





-- 
Pure Personal Opinion | HoffmanLabs LLC