Best way to install into shared file system on z/OS

[MikeFultonDev]

I have been doing some reading on installation of software on Linux (https://unix.stackexchange.com/questions/215776/recommended-way-to-install-software-to-usr-local-use-sudo-or-chown) and this seems too 'loose' for my liking.

The recommendation is to perform a 'make install' as a user with elevated authority.

I am curious what others think.

My proposal would be that we provide a 'zopen clone' function, but that it doesn't run the entire 'clone' job under sudo, but instead would sudo to a particular user for just the minimum sequences required.

I am thinking:

• install software into working tree (e.g. $HOME/usr/local/zopen) with standard authority
• sudo mv /usr/local/zopen /usr/local/backup
• sudo mv $HOME/usr/local/zopen /usr/local/zopen
• sudo chown OWNER:GROUP /usr/local/zopen

[v1gnesh]

sudo make install is a nono.
https://www.youtube.com/watch?v=wFlyUzUVFhw

Also, what are your thoughts on the XDG spec?

Category	Environment Variable	Default Value	FHS Approximation
Configuration	$XDG_CONFIG_HOME	$HOME/.config	/etc
Data	$XDG_DATA_HOME	$HOME/.local/share	/usr/share
State	$XDG_STATE_HOME	$HOME/.local/state	/var/lib
Cache	$XDG_CACHE_HOME	$HOME/.cache	/var/cache

[MikeFultonDev]

Watched the video. Worth the time

[MikeFultonDev]

My primary concern with XDG spec is that if software doesn't embrace it fairly globally, you've just created ANOTHER 4 locations in the home directory and not fixed anything. I see the 'who else does this' list - I don't see vim, but I do see git and nano. Does bash support it? If our bash and git support that, I'd definitely turn it on...
We have moved our .config for zopen into our own /etc so I don't believe this is an issue for 'zopen' itself, but curious what you think?

[v1gnesh]

I can't say decisively but I think I'm seeing a preference for XDG.
The usage of ~/.config is pretty common. in the devblogs, developer tools, etc I've come across in recent times.

Here's a link to a only-slightly-related post on the topic of where to keep what (as the guy thinks it out for an immutable OS - Fedora Silverblue) - https://blog.verbum.org/2020/08/22/immutable-%e2%86%92-reprovisionable-anti-hysteresis/

On bash & XDG, the only good thing I could find on a quick search was https://hiphish.github.io/blog/2020/12/27/making-bash-xdg-compliant/.

[mfsysprog]

What would a 'clone' option do? In my opinion a clone option should be used to do a git clone of the port source to a zopen/dev directory so you can locally build the software using zopen build. Or is that what you intent to do here?

[mfsysprog]

And zopen install already has an option to set the prefix for installation, so if you set that to / wouldn't the current zopen install already do what you are looking for here?

[MikeFultonDev]

ah. perhaps clone is a crappy verb name! The intent is that it's just a 'copy' of a tested install from a sandbox location to the 'official' location on the system to be shared - typically I would expect /usr/local

[MikeFultonDev]

@DevonianTeuchter and I have been chatting and we are thinking 'mirror' or (even better) 'promote' might be the right verbs.

[v1gnesh]

+1 for promote.

[DevonianTeuchter]

"Promote" was what we were thinking also :-)

[MikeFultonDev]

Another question - if we do a 'promote' to a shared area, should we strip out the 'zopen' tool since this shouldn't be tampered with in any way, or should we keep it so things like 'list --installed' would function (i'm leaning to 'strip' to prevent having multiple zopen tools lying on the system but curious what folks think

[lbdyck]

A promote should be only the production elements and thus exclude zopen in my view

[v1gnesh]

+1 for leaving it out, however, would adding list --installed-at <location>, or a similar generalizable arg help?

[MikeFultonDev]

that's an interesting approach @v1gnesh - have zopen package manager be able to 'point' to an alternate location

[v1gnesh]

Yeah, it'll be a neat way of managing deployed zopen tooling.

[lbdyck]

Would be nice to have a promote option and an upgrade-promote option where the upgrade-promote option would just upgrade the packages already promoted. I can see some using this. My plan would be to promote to a new zfs and then change the mounted zfs to the new zfs.

[DevonianTeuchter]

Would be nice to have a promote option and an upgrade-promote option where the upgrade-promote option would just upgrade the packages already promoted. I can see some using this. My plan would be to promote to a new zfs and then change the mounted zfs to the new zfs.

The thinking is that if you are promoting to a location (without the zopen admin tooling), you wouldn't really want to make changes to it; even upgrading those packages could, if there had been a build between testing a particular upgrade and the actual upgrade occurring, lead to untested versions in the "promoted" environment.
Your "plan would be to promote to a new zfs and then change the mounted zfs to the new zfs." would really be the usecase for this - a known "good" version promoted to a location [even overwriting/purging an existing location]

[lbdyck]

Actually I would expect the use case scenario to be:

1. install into zopen and validate
2. promote into a dev/test zfs for broader testing and validation
3. after (2) then promote into production zfs

[DevonianTeuchter]

having something like "zopen promote --from <testzfs> <promotetarget>" in other words. Makes sense.

[MikeFultonDev]

+1

[MikeFultonDev]

@lbdyck @mfsysprog et al for 'promotion into production zfs' that Lionell mentioned, I was thinking the flow could be something like:

• mount file system to temporary location
• copy files into file system at temporary location
• unmount file system
• unmount /usr/local file system
• mount new file system under /usr/local
• update BPXPRMxx to reflect the new mount location

The question is, should we have a very simple script that runs via sudo for the privileged operations, or to instead have a small number of commands that run under sudo - or perhaps a combination of the two (a small script that sudo's to a small number of commands)?

[lbdyck]

no - there could be a filesystem that is exclusive to the zopen tools and the activation may occur outside an IPL but during a scheduled maintenance window which may or may not include an IPL

[MikeFultonDev]

ok - got it - so a maintenance window may or may not involve an IPL, but you can be confident processes are not running that will be referencing /usr/local so it's safe to 'fiddle with it' correct?

[lbdyck]

correct

[lbdyck]

and it would be implemented on one, or more systems, during that window.

[v1gnesh]

@lbdyck can you elaborate on the 'change management record' ? I expect this is company specific? What's involved?

@MikeFultonDev How do I sign up to live in this world? 😁

It's true that there's change mgmt everywhere, however, providing a bunch of commands or scripts as handy reference doesn't hurt.
IMO, it's a way of demonstrating tools/techniques that can be used.
Pretty sure that many places use the same methods as they devised decades ago; so seeing options is good.

[lbdyck]

You're assuming here that zopen will be the only thing under /usr/local. I would just automate steps one and two and leave the rest to the client. Most of the time the zfs is prepared on an installation system and subsequently distributed to a number of lpars in my experience.

I agree - remember it may not be /usr/local/ but could be something else or could be /usr/local/tools as an example.

[MikeFultonDev]

it could be some other location than /usr/local, but I would hope most folks could use the default location. I would say one of the biggest issues we have on z/OS is customization (also one of the biggest strengths unfortunately).

[lbdyck]

Remember that these tools are being installed on an existing system and they may have tools from multiple sources which they keep separated for various reasons - including being able to update one tool or one set of tools without affecting others.

[v1gnesh]

You're very likely to come across companies using /<sysres>/whatever, so /usr/local, I'm afraid will be an immediate no from the OMVS admins/sysprogs.