CentOSからCentOS Streamへ。CentOS終了の衝撃
2020/12/14追記 CentOS終了に伴い、Rocky Linuxのリリースが発表されました。 ZDNet Japan: CentOSプロジェクトの創始者、「Rocky Linux」プロジェクトを立ち上げ
CentOSからCentOS Streamへ
2020/12/08のCentOS公式ブログで「CentOS Project shifts focus to CentOS Stream」という記事が発表された。
簡単にまとめると次のとおり。
- CentOS 8は2021/12/31でサポートが終了する
- CentOSは今後CentOS Streamに移行する
- CentOS Streamは、RHELのアップストリーム（開発）ブランチ。従来のリビルドしたものとは違う位置づけ
- CentOS 7のサポート期間は従来通り2024/06/30で変わらず
- CentOS 8の利用者は、差分が少ないCentOS Streamに移行するか、本番環境利用で心配ならばRHELに移行することが推奨されている
参考までにCentOS / RHELのサポート期間は次のとおり。
| バージョン | サポート終了 |
|---|---|
| RHEL/CentOS 6 | 2020/11/30 |
| RHEL/CentOS 7 | 2024/06/30 |
| CentOS 8 | 2021/12/31 |
| RHEL 8 | 2029/05/31 |
CentOS Streamとは
CentOS Streamは以下の赤帽ブログが詳しい。Fedoraほど離れていないけれど、開発ブランチという位置づけ。
RHELとCentOS Streamの関係について、わたしのイメージは下図のとおり。
世間の反応
日本のいろいろなネットニュースで取り上げられているけれど、CentOS blogのコメント欄が荒れまくり。Ubuntuに行くって声が多い。
Scientific Linuxはすでに開発中止。となるとProductionで使えるRHEL互換ディストリビューションはOracle Linuxなのだけれど、Oracleは嫌われものなのでネガティブな意見が多い。
CentOSは"poorman's RHEL"だから、RHELに行けと言われてもつらい。個人や開発環境ならCentOS Streamを使うのもありだけど。
個人的に思うこと
以前の商用パッケージ製品は、RHELやSUSEのような商用ディストリビューションしかサポートしていなかった。だけれど最近はAmazon LinuxやCentOSをサポートするパッケージも増えてきた。Amazon Linuxはシェアもあるし、AWSのサポートもあるしね。
今回の出来事で、CentOS Streamをサポートする商用パッケージは大幅減の予感。本番環境で使うってのも、エンタープライズ系の人たちはしなさそう。
エンタープライズ＆本番環境で使うなら、RHELに行けってことなのだけれど、お金ある人はすでに使ってるはずだし。それとは別に、Red Hatエンタープライズ契約って条件が厳しいんだよね。部分解約が困難とか。
Ubuntuはエッジやデスクトップ、個人利用で使っても、日本のエンタープライズ＆本番環境となると苦戦しそう。Ubuntu LTSは最低5年だけれど、日本のシステム更改間隔を考えると短いんだよね。
SUSEを使っているエンタープライズ系のユーザーにたまに出会うのだけれど、日本では現状のマイナー感を脱するのは想像できない。ちなみに、筆者は20年前にLinuxディストリビューション開発にかかわっていました。いまはかかわっていないけど。
Oracle Linuxは選択肢の一つだと思うけれど、宗教上の理由（？）でOracleを使いたくない人が多そう。最近AWSでOracle Linuxが使えるようになっていてビックリ。
今回のことはOracle Corporationも気になったようで、2020/12/12のブログで移行方法を紹介している。
2020/12/16追記 上記ブログで紹介しているスクリプトを実際に実行してみました。
RHEL互換ディストリビューションの作成方法
参考までに、RHEL互換ディストリビューションの一般的な作成方法を紹介する。テストなどは省略。
- RHELからソースRPMを入手
- ロゴなど商標権に関わる部分をはじめとして、そのまま利用できないものを削除
- ディストリビューション固有の変更（味付け）
- リビルド
- ISOイメージ化
この中で重要なことが2点ある。
1つめは「ディストリビューション固有の変更」。具体的には、既存のRPMパッケージに対する修正や、新規パッケージの追加。互換性を維持する必要があるので、kernelやglibc、gcc、binutilsなどのコアコンポーネントには手を加えないこと。もしくは、手を加えるとしても、必要最小限にすること。
CentOSの場合は、/etc/redhat-releaseから/etc/centos-releaseへの変更など最小限に抑えている。
CentOS blogのなかでrebuildという表現が出ているけれど、これは上記「4.リビルド」を指している。ニュアンスとしては、ソースを変更しないでリビルドしただけ。
2つめはリビルド時のビルド環境構築。これはプロダクトには含まれないけれど、同一ソースであってもビルド環境（おもにライブラリ群）が異なると、できあがるバイナリも異なる。そのため互換性のあるビルド環境を構築するのは、RHEL互換ディストリビューション作成者の腕の見せ所。
また「RHELのソースはGPLだから、商標権/著作権上まずい部分を削除すれば自由に使える」なんてことを言う人もいるけれど、Red Hatエンタープライズ契約を承諾しているユーザーにとっては、ダークグレーゾーン～ほぼOUT。詳しくは契約書を読んでみて。
ところで「リビルドだけなら簡単」とは思っていませんか？
はっきり言って甘い！ Red Hatからスポンサードされる前のCentOSのリリースがどれだけ遅れていたか。マイナーバージョンは一ヶ月くらいでキャッチアップできていたけれど、メジャーバージョンアップの6.0などはインストーラーの改造もあって半年以上リリースが遅れた。
2020/12/19追記 その後、CentOS blogに開発に関する投稿があり、赤帽ブログに翻訳記事が掲載された。興味のある方はどうぞ。
Rocky Linuxに続いて、いくつか開発表明されているけれど、ほとんどが残らない予感。信頼性の高いものを作るって大変なんだよね。テストが不十分なものを使うくらいなら、CentOS Streamのほうがよっぽどいいし。
結局のところタダ乗りが課題
いろいろ文句を言うのは勝手だけれど、OSSの開発者を苦しめているのは資金だろう。現在の主要Linuxディストリビューションは、Red HatやSUSE、Canonicalなど会社がマネタイズしながら、OSSにも還元していることを利用者は忘れてはならない。
マニュアルを作るのも莫大な作業だ。正直なところ、ネットで検索できる情報の質は玉石混交でクズ情報も多い。元は優れたものでも、古くなり陳腐化することもある。それらと比べるとベンダーの公式マニュアルは頼りになる。サポート契約者だけに提供されるナレッジは、さらに頼れる。
ソースコードを書いて貢献するのは難しくても、バグ報告やマニュアルバグ指摘なども貢献の一つだ。また、個別のOSSで言えば、manやマニュアルの日本語化なども、開発者に感謝される。
さらに間接的にはなるが、Qiitaやはてなブログ、書籍や雑誌などに優良な記事を書くことも、わずかながら貢献していることになるだろう。
