On 12/30/20 1:26 PM, Nico Kadel-Garcia wrote: > On Wed, Dec 30, 2020 at 5:55 AM Ljubomir Ljubojevic <centos at plnet.rs> wrote: >> >> On 12/30/20 9:47 AM, Nico Kadel-Garcia wrote: >>> On Tue, Dec 29, 2020 at 7:04 AM Phil Perry <pperry at elrepo.org> wrote: >>>> >>>> On 28/12/2020 23:32, Lamar Owen wrote: >>>>> >>>>> >>>>> Will Stream cut it for me? One issue that keeps getting glossed over is >>>>> that many drivers that are already in-kernel, not 3rd party, but >>>>> disabled by Red Hat, still have users who need them. ELrepo and others >>>>> have provided support at the "point release" milestones for these >>>>> "unsupported" drivers; it really looks like Stream will break this hard. >>>>> >>>>> For instance, I need megaraid_sas for my servers; that's not a 3rd party >>>>> binary driver, but is already in-kernel; it is intentionally not built >>>>> by Red Hat. ELrepo rebuilds this AND most importantly provides a >>>>> working driver disk for installs; I just don't see Red Hat providing >>>>> these drivers, even in a SIG, for hardware they have already decided is >>>>> "unsupported "; but I always reserve the right to be wrong. >>>>> >>>> >>>> Hi Lamar, >>>> >>>> Unfortunately there's an issue with driver disk ISO images too, as they >>>> are based on point release GA kernels (as are most all OEM ISO driver >>>> disks), and Stream regularly releases new installation media based on >>>> the latest Stream kernel, so if you need a 3rd party driver disk to >>>> install, you are probably out of luck and may not even be able to >>>> install CentOS Stream, even if a driver were available. I'm guessing for >>>> the next year you could install CentOS Linux 8 and convert to Stream, >>>> but after 2021 that will no longer be an option. >>> >>> He should also consider finding a more reputable hardware vendor. >>> Those so-called "megaraid" chipsets were abominable monstrosities and >>> there were a number of extremely poorly written vendor kernel hacks >>> supporting them. >>> >>> Why wouldn't installing from CentOS 8.3 and updating to CentOS Stream >>> be an option? The yum repos are well defined, in well-defined RPMs. >>> And an add-on internal RPM to point to a locked internal repository to >>> provide a "base OS imae" snapshot is a commonplace practice for EPEL, >>> one I've used effectively myself to lock the "update" channels from >>> RHEL and CentOS for consistency in cluster deployment. The approach >>> costs time and effort to set up, and some internal resources, but it >>> provides much faster "yum update" or "yum check-update" operations >>> than always reaching out to the central repos. It's also very useful >>> when you need to rebuild or update 200 cluster members simultaneously, >>> and the yum metadata alone will overwhelm your external bandwidth. >>> _______________________________________________ >> >> And dozens or hundreds of thousands of regular users with need for 3rd >> party drivers and no time and/or money for carefully maintained internal >> repositories? > > Anyone who has to this kind of 3rd party integration is already > devoting time and resources to it. The space for a snapshotted > internal mirror is quite modest, the cooperation with internal > architects is the expensive resource And keeping people from investing > a much larger engineering and cash investment in a "spacewalk" system > which will spend many man-hours on hand-tuning individually tuned RPM > lists for individual servers is.... well, it's one of those > discussions that makes DevOps DevOps. that is ordinarily a *much* > bigger expense. The primary difficulty is when Red Hat sells RHN as > part of a "pure Red Hat solution" and it won't properly handle CentOS > or EPEL or other third party channels. RHN in this setup would need to > cache and enable RPM's that have been deleted from the upstream > repositories, such as CentOS Stream and EPEL, and *that* argument > requires very, very careful attention. It's vastly cheaper to just set > up your own locked internal repo and stay away from the RHN tuning > arguments. > > The time spent for a maintained internal repository is really quite > modest: the github repo I publish for useful tools for one dates back > to 2014, with reposync-rhel8.sh tools from 2019 if you feel the need > for those. It's often well worth the benefit in update performance and > deployment to use an internal mirror. Snapshotting those takes some > thought, but is possible with the old "rsnapshot" tool, which I also > did some work with when it was published back in.... 2003. > > In other words, these are not new problems. They have some available > workarounds. I publish places to start if you'd care to try them out. It looks like you did not understand what I mean when I write "no time and/or money". For example, a single CentOS server in client premises. Assembled from retail PC components (large parts of the planet buy parts and assemble them or buy from small shop that will sell them desired parts and assemble it for free). Is there logic in creating and regularly maintaining local repo for a single CentOS Stream server? Or maybe 3? Or is it much more simpler to just use distribution that does not need a person to be paid just to watch if distro developers will drop a ball? I vote for fire-and-forget distro, preferably free RHEL clone, but in any case one that does not need organized effort to upgrade... > > Nico Kadel-Garcia > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > https://lists.centos.org/mailman/listinfo/centos-devel > -- Ljubomir Ljubojevic (Love is in the Air) PL Computers Serbia, Europe StarOS, Mikrotik and CentOS/RHEL/Linux consultant