[Info-vax] Where to locate software

[David Froble]

Stephen Hoffman wrote:
> 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.

Ah, but Consolidated Data does provide such with the Codis application.  After 
all, we know what the application requires.  I really don't see how VMS could 
ever know that.

To be precise, we have directions, and also do much of the set-up for a new 
customer ourselves.  We need things to be set up in a particular manner, so that 
our automated updates will work correctly.

>> 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.

I got to ask, how could VMS know the particular requirements of third party 
applications?

Not that I'm claiming that every third party vendor has done an outstanding job 
in this area.  But some have, and do.

>> 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.

I have run multiple applications on a single VMS system.  I've even seen 
multiple companies using the same VMS system.  It can be done, if the people 
doing it have half a clue.

>> 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.

Ok, you win that one ....

:-)

But if the user accounts are not set up properly, then I'm guessing nothing else 
can help.  At some point some knowledge and intelligent management is required, 
right?

>  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.

While pretty much dead with HP, perhaps with VSI there might be some who return 
to VMS, because the "new" system never really was acceptable?

>> :-)
>>
>>
>>
>>> 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.
> 
> 
> 
> 
>