CentOS8に移行した際に苦労した点

2020 年 6 月 29 日katsura

お久しぶりです、開発Grのkatsuraです。
CentOS6のサポート期限が今年の11月末にせまり、最新の CentOS8への移行を検討している方も多いかと思います。
私が関わっているサーバにもCentOS6のサーバがあり、つい先日CentOS8マシンへの移行を行いました。
その際、苦労した点について、いくつか紹介していこうと思います。

CentOS8の主な変更点について
マイナーバージョンにてパッケージ提供体制が変わる点
AppStreamのパッケージを利用する際の注意点について
CentOS8で変更になった暗号化通信関連
まとめ

CentOS8の主な変更点について

CentOS8を利用する上での主な変更点については、CentOS8の元となっているRHEL8の以下のページ（RHEL 8 の導入における検討事項）が最も詳しいので、困った場合にはこちらをまずは読むのが良いでしょう。

マイナーバージョンにてパッケージ提供体制が変わる点

例えば、Zabbix-Server等に必要なパッケージとして、libssh2がありますが、CentOS8.0では非推奨となり、CentOS8.1からは標準リポジトリ(AppStream)から外されてしまいました。
現在は、epelやremiなどのサードパーティが提供するパッケージが存在しているのですが、CentOS8.1がリリースされてから数ヶ月の間はサードパーティでの提供も行われませんでした。
そのため、CentOS8.0のパッケージを直接ダウンロードしてきて、CentOS8.1のマシンにインストールするなど、イレギュラーな手段を取らざるを得ませんでした。

逆に、whoisのコマンドはこれまではepelにてパッケージが提供されていたのですが、RHEL8.2から標準のリポジトリにてパッケージが提供されるようになりました。
それに伴い、RHEL8.2がリリースされたタイミングで、epelからwhoisのパッケージが廃止されることになりました。
しかし、RHEL8.２リリースからCentOS8.2の提供までには時間がかかるため、CentOS8系ではwhoisのパッケージをインストール手段が存在しないタイミングが発生してしまっていました。

このように、CentOS8では、CentOS7以前と比べ、マイナーバージョンアップに伴うパッケージ提供体制の変更が多くある印象です。
ステージング環境の作成時には使えていたパッケージが、本番環境作成時には使えないみたいな事も起こり得るので、これまで以上にマイナーバージョンを意識してサーバの管理をしたほうが良さそうです。

AppStreamのパッケージを利用する際の注意点について

CentOS8では、BaseOSとAppStreamという2つのメインリポジトリで配布されており、後者のAppStreamには複数のバージョンのPHPやRuby等も含まれていて、利用することができます。

CentOS7以前では、最新の言語を利用する方法として、サードパーティ製のパッケージを利用する方法や、rbenvやnodenvなど言語導入のためのツールを利用する方法などがありました。

AppStreamを利用する場合には以下のようなメリットがあります

CentOSあるいはRHELからのサポートが受けられる
導入コストが低い

一方で以下の点を注意する必要があります。

言語のライブラリのパッケージ提供について
例えば、remiのリポジトリでは、多くのpeclライブラリがパッケージとして提供されていますが、AppStreamではpeclライブラリはほとんど提供されていないという違いがあります。
これまでサードパーティ製のパッケージを利用していたケースから移行する場合、言語自体だけでなく、関連パッケージがAppStreamにて提供されているかの確認も必要です。
サポート期限が従来のOS標準パッケージと比べ短い場合がある
CentOS7以前であれば、メジャーバージョンのサポート期限内であれば、標準リポジトリに含まれるパッケージは一律でサポートされていましたが、CentOS8のAppStreamに含まれるパッケージに関しては、パッケージ毎（厳密にはModule毎）にサポート期限が決められています。
これまでであれば、標準リポジトリに含まれるパッケージを利用する方がサポート期限が長く、その観点ではメリットが大きかったのですが、CentOS8では必ずしもそうではないので注意が必要です。
パッケージごとのサポート期限については、以下のリンクにて確認可能です。
Red Hat Enterprise Linux 8 Application Streams Life Cycle

CentOS8で変更になった暗号化通信関連

CentOS8では、暗号化ポリシーについて大幅な見直しがありました。
変更の多くは、安全ではない暗号アルゴリズムの無効化などであり、広く公開するサービスを提供しているサーバであれば、影響を受けることはほとんど無いでしょう。
ただし、古くからあるシステムと連携しているような場合は、システムからのアクセスができなくなる可能性もあるので注意が必要です。

システム全体の暗号化ポリシーについて
CentOS8からシステム全体で暗号化のポリシーを設定できるようになりました。
互換性を重視し、TLS1.0/TLS1.1などプロトコルをサポートする場合には、このポリシーをLEGACYに設定しておきましょう。
LEGACYでも明示的に指定しないと有効化されない暗号化方式について
CamelliaやIDEAなど、一部の暗号アルゴリズムはCentOS8でも利用可能ですが、デフォルトでは無効になっており、アプリケーションの設定で明示的に有効化しないと利用できません。
既存システムからの移行の際には予めこの点を含めて互換性の確認しておいた方が良いでしょう。
opensslやcurlの動作が異なる点
openssl は　1.1.1 で TLS1.3 に対応したことに伴い、s_client でのcipher の指定の仕方が変更されています。
また、curlはCentOS7等ではSSL/TLS通信にNSSを使っていましたが、CentOS8ではOpenSSLを利用するようになり、TLS関連の引数の指定方法が一部変更されています。
これらのコマンドの変更が、サービスの動作に影響するケースは少ないかもしれませんが、メンテ作業やサーバ構築時の確認に利用しているケースがあるかもしれません。
実際にメンテ作業中にコマンドが利用できないことに気づくと致命的な可能性もありますので、事前の検証はしておきましょう。