Building an Alternative to RHEL6: Saving the Repositories
Posted 2020-07-06 14:04 PDT | Tags: software rhel6fork
It has seemed to me for some years now that there is quite a bit of demand from the enterprise sector for a RHEL-like distribution which is just a forked RHEL6 https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux with updated kernel and packages, omitting the "features" Red Hat introduced with RHEL7.
The desire to avoid these features is motivating a lot of businesses to keep using RHEL6 (or its derivatives) beyond its EOL, which is a suboptimal solution for everyone involved. Red Hat has chosen to accomodate those customers to a degree by offering "Extended Lifecycle Support" for RHEL6 through the end of June 2024, so they are at least getting security patches for these systems.
The longer RHEL6 users lack alternatives to RHEL7/8 (and their derivatives), the more those users will feel pressured to make the painful transition to an operating system which is less reliable and harder to maintain. The best time to develop an alternative was five years ago, when most RHEL6-using businesses were just starting to weigh their options, but I don't think the window of opportunity has closed quite yet. There are still many foot-dragging stragglers who would welcome the chance to perpetuate their accustomed infrastructure. If enough of these stragglers adopted the alternative and found it good, it might entice other companies which have already made the transition (and have been suffering the consequences) to transition back.
I've talked to some people who voiced interest in such a project, but couldn't get them to talk to each other, and AFAIK they didn't follow through. I'm interested in contributing to the project, but have resisted taking the lead because I'm already drowning in unfinished projects and would rather invest my time and energy in making Slackware more enterprise ready. Existing RHEL6 users would likely find an RHEL-based alternative more appealing, though.
Time is not on our side. One of the consequences of delaying the fork is that the RHEL6 package repositories are being neglected and falling into disrepair. Information is being lost, which an RHEL6 fork would need as a reference template.
I've been downloading Scientific Linux 6 https://en.wikipedia.org/wiki/Scientific_Linux and the related RHEL6 repositories -- sl, sl6x, sl-other, epel, adobe-linux, and rpmforge. SL6 seems like the best RHEL6-clone from which to base a fork because their community is very fork-friendly. They have invested resources in making "spins" (shallow forks) easy for their users and would gladly give advice to a project fork. In contrast, when I brought up the notion of a fork in CentOS6 forums, it was received with uniform hostility. The difference was like night and day.
The downloads are ongoing. I've got about 400GB so far, with I think about 200GB more to go. It's quite a bit of information, but not unmanageable.
I'd still appreciate it if someone else took point, but while I'm waiting for that champion, I'll put in some work to make sure the repository data is complete and available as a working SL6 mirror. If a project fully materializes, I'd be happy to hand over the mirror or manage it on behalf of the project.
I tried using yum and createrepo to construct a local mirror in the prescribed manner https://www.unixmen.com/setup-local-yum-repository-on-centos-rhel-scientific-linux-6-4/ but the repo metadata was too badly in disrepair for some repos to work. Some mirror lists are stale, some domains have disappeared, some mirrors are -empty- (directories are there, but no files), some are redirecting to nonexistent locations, and some have slightly-wrong packages which make yum unhappy. I've switched to just wget'ing the entire contents of good mirrors (once I found them) and will reorganize them into proper repos and fix broken dependencies later.
That dysfunction will only grow worse with time, which makes it all the more important to obtain copies of them -now-, before the dysfunction deepens.
I'll also see about getting it onto redundant storage. I'd hate to lose it all to a disk crash.
Posted 2020-07-06 14:04 PDT | Tags: software rhel6fork
It has seemed to me for some years now that there is quite a bit of demand from the enterprise sector for a RHEL-like distribution which is just a forked RHEL6 https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux with updated kernel and packages, omitting the "features" Red Hat introduced with RHEL7.
The desire to avoid these features is motivating a lot of businesses to keep using RHEL6 (or its derivatives) beyond its EOL, which is a suboptimal solution for everyone involved. Red Hat has chosen to accomodate those customers to a degree by offering "Extended Lifecycle Support" for RHEL6 through the end of June 2024, so they are at least getting security patches for these systems.
The longer RHEL6 users lack alternatives to RHEL7/8 (and their derivatives), the more those users will feel pressured to make the painful transition to an operating system which is less reliable and harder to maintain. The best time to develop an alternative was five years ago, when most RHEL6-using businesses were just starting to weigh their options, but I don't think the window of opportunity has closed quite yet. There are still many foot-dragging stragglers who would welcome the chance to perpetuate their accustomed infrastructure. If enough of these stragglers adopted the alternative and found it good, it might entice other companies which have already made the transition (and have been suffering the consequences) to transition back.
I've talked to some people who voiced interest in such a project, but couldn't get them to talk to each other, and AFAIK they didn't follow through. I'm interested in contributing to the project, but have resisted taking the lead because I'm already drowning in unfinished projects and would rather invest my time and energy in making Slackware more enterprise ready. Existing RHEL6 users would likely find an RHEL-based alternative more appealing, though.
Time is not on our side. One of the consequences of delaying the fork is that the RHEL6 package repositories are being neglected and falling into disrepair. Information is being lost, which an RHEL6 fork would need as a reference template.
I've been downloading Scientific Linux 6 https://en.wikipedia.org/wiki/Scientific_Linux and the related RHEL6 repositories -- sl, sl6x, sl-other, epel, adobe-linux, and rpmforge. SL6 seems like the best RHEL6-clone from which to base a fork because their community is very fork-friendly. They have invested resources in making "spins" (shallow forks) easy for their users and would gladly give advice to a project fork. In contrast, when I brought up the notion of a fork in CentOS6 forums, it was received with uniform hostility. The difference was like night and day.
The downloads are ongoing. I've got about 400GB so far, with I think about 200GB more to go. It's quite a bit of information, but not unmanageable.
I'd still appreciate it if someone else took point, but while I'm waiting for that champion, I'll put in some work to make sure the repository data is complete and available as a working SL6 mirror. If a project fully materializes, I'd be happy to hand over the mirror or manage it on behalf of the project.
I tried using yum and createrepo to construct a local mirror in the prescribed manner https://www.unixmen.com/setup-local-yum-repository-on-centos-rhel-scientific-linux-6-4/ but the repo metadata was too badly in disrepair for some repos to work. Some mirror lists are stale, some domains have disappeared, some mirrors are -empty- (directories are there, but no files), some are redirecting to nonexistent locations, and some have slightly-wrong packages which make yum unhappy. I've switched to just wget'ing the entire contents of good mirrors (once I found them) and will reorganize them into proper repos and fix broken dependencies later.
That dysfunction will only grow worse with time, which makes it all the more important to obtain copies of them -now-, before the dysfunction deepens.
I'll also see about getting it onto redundant storage. I'd hate to lose it all to a disk crash.