I'm only taking into consideration the work cultures in different sites, and all that it entails. At your employer, "obvious things" may be easily accepted. I don't know if it's fair to say, therefore that's how it is everywhere.
Honestly, what % of mainframe sysadmins use Artifactory vs the rest (mainframe developers, distributed folks). Are you really saying mainframe sysadmins prevalently use rsync to keep config backups? - KB ------- Original Message ------- On Thursday, June 8th, 2023 at 6:36 AM, David Crayford <dcrayf...@gmail.com> wrote: > 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
