On 7/6/2023 10:04 pm, kekronbekron wrote:
Git is not the right tool for tracking systems directories such as /etc and
var. No sysadmin wants a .git directory in system directories.
Maybe it's easier if zOSMF used it internally, and maintains a mirror of (a
selected subset perhaps) system config?
As you can infer, I'm just trying to find the holes in having config as code,
where zOSMF is the centre-piece... since it's doing zOS config anyway.
I don't think any sysadmin will want system configs out in an artifact repo
either...
Really? That's a rather odd statement considering it's one of it's use
cases. Back in the day admins would use rsync now they use Artifactory.
- KB
------- Original Message -------
On Wednesday, June 7th, 2023 at 6:52 PM, David Crayford <dcrayf...@gmail.com>
wrote:
Git is not the right tool for tracking systems directories such as /etc
and var. No sysadmin wants a .git directory in system directories. We
use Artifactory which has an excellent API with diffs, versioning and
other tools such as hosting. It has a REST API but you can use a Python
library to script it https://pypi.org/project/pyartifactory/.
On 7/6/2023 11:52 am, kekronbekron wrote:
True, which is why a colourized and visually easy interface to viewing the diff
(like the diff view in GitHub or JetBrains IDEs) is important to make its use a
lot easier.
- KB
------- Original Message -------
On Wednesday, June 7th, 2023 at 9:15 AM, Gibney, Dave
000003b5261cfd78-dmarc-requ...@listserv.ua.edu wrote:
On occasion, I tried the USS diff to evaluate my running /etc against a new
serverpac version. And sometimes to compare the previous serverpac version with
the new one.
The utility of this exercise varied.
-----Original Message-----
From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On
Behalf Of kekronbekron
Sent: Tuesday, June 6, 2023 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Best practice for /etc and /var when upgrading
Integrating git is not something we as customers need to take on ourselves
(for system upgrade workflows like this).
It's something best given in a polished manner by IBM, as a part of zOSMF.
And again, getting git ourself is another thing; so the suggestion on IBM
establishing a dependency on git (ex: for zOSMF's use) and working backwards
up to what is required.
Of course, they can choose IBM zOS Change tracker, but it's not free, and is yet
another thing to learn.
As long as there's a solution that hides the complexities and delivers the
niceness in an interface, that'll be the way to go.
CA's Mainframe/Chorus Software Manager was ahead of its time.
It or zOSMF needs to be far, far better today than CSM was years ago.
- KB
------- Original Message -------
On Wednesday, June 7th, 2023 at 7:56 AM, Mark Zelden
m...@mzelden.com wrote:
I don't know git so I can't really comment. I did google gif diff and see what
you mean
now by a patch.
For one, it seems like overkill. Two, I don't have git diff on z/OS so somehow
I'd have to
get all my existing /etc (and /var) out there to compare what IBM would put
out there
that matches the /etc (and /var) you get with a new OS?
To go back to my parmlib example, why would I need to compare
IPO1.PARMLIB sample
members to my running parmlib members from a system I'm about to
upprade.
The LNKLST, APF, SVCs, etc are are locally customized for my running system.
However, if
a new sample member was introduced that could be used if I implemented
some new
feature, then it may be nice to have that sample in my running parmlib with
the
"merge" process or "IEBCOPY, no replace" if you will. :)
Not really a good comparison because in this scenario the new parmlib
member would be put
in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could
come up with
right now.
BTW, A better approach to what the OP said happened in his upgrade (done
by some
3rd party) is to not touch it at all and just use your existing /etc and /var
for
your OS
upgrade or a copy of it with documented required changes from the upgrade
workflow,
just like you would handle required parmlib changes.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
efense.com%2Fv3%2F__http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.ht
ml__%3B!!JmPEgBY0HMszNaDT!pk5HXJWpgjdGm1ZKxIR0jXpfieiYVx5kXcbXxI
juUxrbI5Q96ZNuTbnMoBubxwv4x6Hh483-
uHawPpVeYyZWlAbrCog_VLTF%24&data=05%7C01%7CGIBNEY%40WSU.ED
U%7C503456fbfcbe4365386708db67000c1a%7Cb52be471f7f147b4a8790
c799bb53db5%7C0%7C0%7C638217022129812477%7CUnknown%7CTWF
pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u1zF6wTztHDEhj1jeBW4YCupjk
1DpKQjwtgLZgrRxFI%3D&reserved=0
On Wed, 7 Jun 2023 01:53:40 +0000, kekronbekron
kekronbek...@protonmail.com wrote:
Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and
have updated the sudoers file.
When upgrading, you get a prompt showing a diff between the new
version and your customized version.
And quoting a bit from your reply...
compare the distributed /etc to what you already have to see if possible
other changes
may be desired.
"compare the..."
Normal diff, git diff...
/untouched/etc/
/custom/etc
(git) diff against both to see what we customized.
create a patch
/new-untouched/etc/
/new-custom/etc/
Here, I'm saying /new-custom/etc/ can be created by doing a git apply of
the patch from earlier.
I mean... creating patches is quite common to keep just the delta, on a
version-controlled repository.
If it still doesn't make sense, it would be good to correct my
understanding... without being pointed to the git website :)
- KB
------- Original Message -------
On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden
m...@mzelden.com wrote:
On Tue, 6 Jun 2023 03:15:46 +0000, kekronbekron
kekronbek...@protonmail.com wrote:
I do wonder... with git now available, and this being normal USS, maybe
zOSMF can start formally adopting/requiring git.
Then, moving updates from these files onto newer versions is a matter
of applying git patches on the new ones, where possible.
Something that the zOSMF UI can accomodate.
Do let me know if this doesn't make sense lol.
No, that makes no sense. Think of /etc as the SYS1.PARMLIB for z/OS
Unix. Any customization to
existing files should not be touched. That is why it only makes sense to
copy what's new into it
and also compare the distributed /etc to what you already have to see if
possible other changes
may be desired. I can't think of many required changes of the years but
when there are
they are (or should be) in the migration manual or upgrade workflow for
current versions.
Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:m...@mzelden.com
Mark's MVS Utilities:
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld
efense.com%2Fv3%2F__http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.ht
ml__%3B!!JmPEgBY0HMszNaDT!pk5HXJWpgjdGm1ZKxIR0jXpfieiYVx5kXcbXxI
juUxrbI5Q96ZNuTbnMoBubxwv4x6Hh483-
uHawPpVeYyZWlAbrCog_VLTF%24&data=05%7C01%7CGIBNEY%40WSU.ED
U%7C503456fbfcbe4365386708db67000c1a%7Cb52be471f7f147b4a8790
c799bb53db5%7C0%7C0%7C638217022129812477%7CUnknown%7CTWF
pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u1zF6wTztHDEhj1jeBW4YCupjk
1DpKQjwtgLZgrRxFI%3D&reserved=0
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
