CentOSからUbuntuへの移行

この記事は2024年の7月に執筆されています。この時期はLinuxで人気のDistributionであるCentOS7のサポートが終了し、実質CentOS自体が完全に終了してしまうという、大きな出来事がありました。

私は元々IT企業で働いていて、Red Hat系でありながら無料で手堅いCentOSには本当に沢山お世話になってきました。実は最近までCentOS7のサポートが終了することを知らず、リリース前の新規のサーバーをCentOSで組み立てている途中でこの事変に遭遇し、急遽Ubuntuへの入れ替えを行いました。

今回の記事ではこのLinux Distributionの選択について簡単な解説の後、具体的なCentOSからUbuntuへの移行についてまとめていってみます。

CentOS7のサポートが2024/06に終了
Linux Distributionの選択
1. 主流はRed Hat系かDebian系
2. Red Hat系のDistributionを選ぶべきか
CentOSからUbuntuへの移行
1. Ubuntuはrootがデフォルトで無効
2. パッケージマネージャの違い (yumからaptへ)
  1. yumとaptのコマンド比較
  2. リポジトリの追加 (PHP7.4のインストール)
ApacheからApache2へ
結局違いはコアな所だけ

CentOS7のサポートが2024/06に終了

まず最初に、CentOS7のサポートが終了した件について、もう少し詳しくまとめておきます。

CentOSは、Red Hatを基にした無料のLinux Distributionで、個人から企業まで幅広い層で利用されていましたし、現時点でも移行できずに利用し続けているサービスも多い事でしょう。Linuxには数多くのDistributionがあって、選択基準は様々ですが、2020年代の大枠のシェアは以下のような感じです。様々なメディアでシェアがまとめられていますが、CentOSは大体3位のポジションに落ち着いているようです。

順位	Distribution	割合
1	Ubuntu	30%
2	Debian	15%
3	CentOS	8%

Linux Distribution Share

CentOSにはいくつかのバージョンがあって、それらは並行して利用されていました。今回サポートが終了したのはその中のCentOS7で、それよりも新しいCentOS8はもう少し前にサポートが終了してしまっています。

バージョン	サポート期限
CentOS 8	2024/05/31
CentOS 7	2024/06/30

CentOS EOL(End of Life) Dates

一応後継のCentOS 9は引き続き利用可能で、現時点の期限は2027/05/31までとなっています。

サポート終了で困る事

サポートの終了によってセキュリティーアップデートが受けられないなどの問題もありますが、それ以上に日本を含めて世界中にあったミラーサーバーがデータの提供を終了していることが大きな問題です。日本でもKDDIや山形大学などがCentOSのミラーを提供してくれていましたが、軒並みディレクトリの中身が空っぽになっています。

ディレクトリ構造はそのままですが、中にreadmeが置いてあり、中身は以下の文面になっています。(このバージョンのCentOSは非推奨[サポート終了]ですという意味合いです)

This directory (and version of CentOS) is deprecated.

この関係で、現行のCentOSサーバーにパッケージマネージャ(yum等)からアプリケーションをインストールしようとすると、ことごとくNot Foundのエラーとなってしまいます。もちろんLinux自体の機能は生きているので、ソースからmakeしたりなどは可能ですが、著しく作業効率が落ちることは明白です。

OSとして生きてはいるけど、実質CentOSとしての旨味は完全になくなった状態ともいえるでしょう。日本のミラーサーバーをいくつか確認しましたが、CentOS 9のデータを配布してくれているところは見つけられませんでした。CentOSが今後どうなっていくのかは現状不透明で、新規導入に踏み切るのには少し勇気が必要そうです。

Linux Distributionの選択

Linuxには種類が無数にあって、それぞれがコアなLinuxに様々な便利な機能を追加したり、既存のソフトウェアなどを組み合わせて特色があり、インターネットなどを中心に様々な方法で配布されています。書店にならぶ解説本や、ネット上にも使い方などを解説したサイトが星の数ほどあって、選ぶ側も何で選べばよいのか判断するのも一苦労です。

上記のように利用可能な形態で配布されているLinuxのことをDistributionと呼びます。今回言及するCentOSやUbuntuは、いずれもLinuxのDistributionの一つです。

IT現場でLinuxを利用する際にも、当然いずれかのLinux Distributionを選択することになります。ここでは、IT現場での選択における主な指針と共に、今回Ubuntuを移行先に決定した基準についてまとめてみます。

主流はRed Hat系かDebian系

Linuxには多くのDistributionがあり、それぞれ様々な特徴がある事については前述したとおりですが、実際には中心となる人気のDistributionがいくつかあり、そこから派生したパターンのものも多くあります。

今回言及するCentOSはRed Hat、UbuntuはDebianというDistributionから派生して生まれています。

Red HatとDebianは、2024年現在シェアのトップ3を占有していることからも、主流と言ってよいでしょう。特にDebianとその派生であるUbuntuはトップ2を占めていることから、世界の半分のLinuxはDebianで出来ているといっても概ね正解な現状にあります。

人気がある事は重要で、サポートは手厚くなり不具合はすぐに修正され、便利なツールが多く流通することになる環境は、利用者・開発者双方に多くのメリットを提供します。そのため、Red HatとDebian(Ubuntu/Debian/CentOS)はIT現場では非常によく聞く名前です。

企業での選択で重要なのは「コスト」

Red Hatの総本山としては、RHEL(Red Hat Enterprise Linux)というDistributionがあります。これは多くの派生Distributionの基になっている非常に優秀なものではありますが、シェアはそれほど多くありません。むしろ派生したCentOSの方がシェアも多く、現在ではRHELのことを知らない人すらいるかもしれません。

大きな違いは「RHELは有償、CentOSは無償」という点です。

企業でシステムを構築するときには、初期コストと運用コストというものが重要になってきます。Linuxを選択している時点でWindowsよりも圧倒的に初期コストは低く抑えられることになりますが、REHLを選択すると、運用コストがかかることになります。例え少額であっても、継続的にお金が流れていくことを喜ぶ企業はありません。当然議論して取捨選択していくことになります。

RHELは有償ですが、専門的なサポートを受けられるというメリットもあります。企業での責任問題の回避や障害へのリスク対応として一定の評価価値は認められています。IT企業が無償のリスク、有償のメリットなどを提示した後は、導入企業が取捨選択して決断するというの一番多いのではないでしょうか。その結果が現在の世界シェアに結果として表れているという状況です。これは有償のメリットが小さいというよりも、無償の安定性・信頼性があまりにも高すぎることが原因と思われます。

Red Hat系のDistributionを選ぶべきか

Red HatとDebianは、世界シェアから見ても間違いなくLinuxの2台巨頭です。大きなこだわりのない限り、このどちらか(またはその派生)から選択した方が、手厚いサポートと安心のセキュリティーを手に入れられることでしょう。

Red Hat(CentOS)とDebianは、IT業界では宗教のようなもので、完全に好みの世界だと個人的には感じます。私自身は間違いなくCentOS派でした。ですが、一般的なインフラ系のエンジニアで、どちらかしか扱えないという人は出会ったことがありません。まぁ同じLinuxなので当然なのですが…。

CentOSのサポートが終了することになって、Red Hat系のDistributionを選び直すかどうかは、本当に悩ましい問題です。Red Hat系と共に過ごして時間が長すぎて、今後Debian一色になっていくことに若干の抵抗があるものの、時代の流れ的には間違いなくRed HatからDebianという風潮です。

選択肢として、Red Hat系でCentOSに近いとされているDistributionには以下のようなものが有ります。多くのサイトで紹介されていますのでここでは詳しい解説は割愛させてもらいます。紹介されていることは少ないようですが、一応FedoraもRed Hat系でシェアもそれなりにあります。

Alma Linux
Rocky Linux

いずれにしても、CentOSは規格外に人気で支持されていたDistributionだったため、移行先のDistributionのサポート内容や情報の少なさに驚き、苦しむこともあるでしょう。

Ubuntuを選んだ個人的な理由

個人的には長年Red Hat系に親しんでいたので、CentOSに近くて無料のLinux Distributionを選ぼうと思っていたのですが、結局Ubuntuを選ぶことにしました。Debianも経験が少しあったこともあって、正直どちらでもよかったのですが、参考までに私がUbuntuを選んだ理由を紹介しておきます。

CentOSから移行するシステムはWebサーバー用途のLinuxだったので、最終的にはHTTPS用の証明書を準備する必要がありました。証明書はLet’s Encryptを利用しようと考えていました。

Let’s Encryptは、世界中のHTTP通信を暗号化しようとする組織で、非営利団体によって運営されています。日本企業の中でもこの組織への寄付などが行われていることもあり、日本でも有名になっているので、利用したことがある人も多いのではないでしょうか。

Let’s EncryptはCentOSでもDebianでも利用することができるサービスですが、推奨されている導入方法はSnap(snapd)というパッケージマネージャを利用する方法です。Snapは元々Ubuntu(Phone)用に開発されたパッケージマネージャです。

私がUbuntuを選んだのは、Debian/Ubuntuが非常に大きなシェアを持っていたことに加えて、利用しようとするシステムとの親和性が高いことが理由です。

この記事に辿り着いている人は同じ気持ちだと思うのですが、Red Hat系のCentOSからDebian系のUbuntuへの移行は少し大変です。

何しろ慣れ親しんだコマンドが使えなかったり、設定ファイルの場所や項目の知識が使えないことなどが想像できてしまい、「調べればわかるだろうけど面倒だ」という感覚になってしまうのも無理ありません。

今回は、そういう面倒ごとをクリアしながらとりあえずCentOSとUbuntuでWeb/Databaseのサーバーを構築したので、今後似た様な作業をする人の時間節約に役立つことを願いながら、CentOSの構築手順とUbuntuの構築手順のメモを比較しながら、その差を紹介しておきます。

今回利用したOSは以下のバージョンになっています。参考までに。

OS	バージョン
CentOS	7.9.2009
Ubuntu	24.04

Linux DistributionのVersion (UbuntuはDesktopではなくServer用を使用)

Ubuntuはrootがデフォルトで無効

一番最初に困ったのが、Ubuntuのインストール直後にはrootユーザーが無効になっていることです。インストール時に作成したユーザーでログインし、適宜sudoで昇格実行するのがDebian文化です。

でも初期設定などで大量に強い権限のコマンド実行が必要な時など、正直一度rootに昇格して短いコマンドで連続してコマンドを実行したいと思うCentOSの民です。

rootユーザーを有効にするには、Ubuntuインストール時に作成したユーザーでログイン後、以下のコマンドを実行してパスワードを設定します。

sudo passwd root

実行すると、ログインしているユーザーのパスワード入力に続いて、rootユーザーのパスワード設定と確認を求められます。設定完了後、CentOSなどと同様にsuコマンドでrootユーザーに昇格できます。

パッケージマネージャの違い (yumからaptへ)

一番頭の痛い問題なのが、パッケージマネージャの変更でしょう。

CentOSでは、必要なアプリケーションはyumでインストールすればよかったのが、Debianではyumは使えず、代わりにaptがあるけど使い方の違いを覚え直すのが面倒だと思うかもしれません。私は少なくともそうでした。

実際には、かなり類似しているのでそれほど大変ではありませんでした。一部困ったこともあったので、それについても少し紹介します。

yumとaptのコマンド比較

CentOSのyumと、Ubuntuのaptは同じパッケージマネージャで、同じような使われ方をするだけでなく、コマンド体系もどちらが寄せたのか分かりませんが、かなり似ています。以下はinstallのアクションの比較です。同様にsearchしたり色々とオプションで指定できるのもyum/aptで似ていますが、結果の表示などは異なりますが、ほぼ同じことが実行できます。

yum	apt
yum install [package name]	apt install [package name]

install packageの違い

MariaDBのインストールコマンドの例です。

#CentOS上のyum
yum install mariadb-server

#Ubuntu上のapt
apt install mariadb-server

こんな感じで基本的にはyumのaptへの置き換えで対応が可能ですが、パッケージ名が異なるものと出会ったらそこは書き換えが必要になります。存在しなければ失敗するだけなので、「aptに置き換えて実行して、なければ探す」くらいの勢いで乗り切れることも多いでしょう。

リポジトリの追加 (PHP7.4のインストール)

最初につまずいたのが、「yumのリポジトリの追加をaptではどうするのか」という問題です。私の場合、CentOSの環境や開発環境で使っているPHP7.4をUbuntuでも使いたかったので、OS標準にないリポジトリを追加する必要がありました。

OSから新しい環境を作るときにしか必要にならないこのコマンドを覚える元気はないので、ここにまとめて記載しておきます。同じような問題に困っている人は是非参考にしてみてください。

#CentOS
yum -y install epel-release
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
yum -y install --enablerepo=remi,remi-php74 php

#Ubuntu
add-apt-repository ppa:ondrej/php
apt install php7.4

yumの場合は、リポジトリの追加をした後もyumで[–enablerepo=***]を指定する必要がありましたが、aptの場合はadd-apt-repositoryの実行後はオプション指定なしで参照してくれているようで、その後はリポジトリの事自体を考慮しなくてよくなっています。

phpのパッケージ名におけるバージョン番号は結構重要で、各種モジュールもバージョンに対応した指定が必要になります。参考までに私がインストールしたパッケージについて列挙しておきます。バージョン番号の指定の仕方が、ピリオドが途中に入っていてちょっと面白いと感じてしまいます。

apt install php7.4-mysqli
apt install php7.4-curl
apt install php7.4-xml
apt install php7.4-mbstring

ApacheからApache2へ

CentOSをWebサーバーとして利用していた場合、WebサーバーにApacheを使っていることが多いでしょう。Ubuntuに入れ替える際に、WebサーバーをNginxに入れ替えようと考える人も多いかもしれませんが、できれば移行コストやリスク回避のために、CentOSと同じApacheを使いたいと考える人も多いでしょう。

Ubuntuの配布パッケージにhttpd(apache)がないことに驚くかもしれません。

CentOSのパッケージでは、ApacheもApache2もhttpdというサービス名でしたが、UbuntuではApache2からhttpdではなくapache2というサービス名に変更されています。コアな部分に大きな変更はなくとも、慣れ親しんだディレクトリ構成や設定ファイルの構成が無くて戸惑うこともあるでしょう。

ここではその違いについて少しまとめてみます。

設定ファイル(httpd.conf)がない

最初に驚くのが/etc/httpd/conf/httpd.confという、慣れ親しんだ設定ファイルが存在しない事です。Apache2の設定関連のファイルは/etc/apache2ディレクトリ以下に配置されています。以下はそのディレクトリの中身です。CentOSのhttpdに慣れた人は、あまりにも違うこの景色で絶句してしまうかもしれません。

# ls -la /etc/apache2/
total 88
drwxr-xr-x   8 root root  4096 Jul 16 05:03 .
drwxr-xr-x 111 root root  4096 Jul 16 05:30 ..
-rw-r--r--   1 root root  7198 Jul 16 05:03 apache2.conf
drwxr-xr-x   2 root root  4096 Jul 14 15:41 conf-available
drwxr-xr-x   2 root root  4096 Jul 14 15:41 conf-enabled
-rw-r--r--   1 root root  1782 Mar 18 11:41 envvars
-rw-r--r--   1 root root 31063 Mar 18 11:41 magic
drwxr-xr-x   2 root root 12288 Jul 14 15:49 mods-available
drwxr-xr-x   2 root root  4096 Jul 16 04:47 mods-enabled
-rw-r--r--   1 root root   274 Mar 18 12:35 ports.conf
drwxr-xr-x   2 root root  4096 Jul 14 15:41 sites-available
drwxr-xr-x   2 root root  4096 Jul 16 04:39 sites-enabled

複雑に見えますが、httpd.confがバラバラになっているだけで、基本的には同じものなので安心してください。

あまりにも長く冗長になっていたhttpd.confは、中を検索しながら設定項目を修正するという作業を余儀なくされていましたが、Ubuntuのapache2ではそれを分解して分かりやすく、そして修正範囲/影響範囲を小さくしようという意図が感じられます。分解した大元のapache2.confに各ディレクトリのファイルを読み込みますという定義が書かれています。

以下は、/etc/apache2/apache2.confに書かれているコメントの抜粋です。

# It is split into several files forming the configuration hierarchy outlined
# below, all located in the /etc/apache2/ directory:
#
#       /etc/apache2/
#       |-- apache2.conf
#       |       `--  ports.conf
#       |-- mods-enabled
#       |       |-- *.load
#       |       `-- *.conf
#       |-- conf-enabled
#       |       `-- *.conf
#       `-- sites-enabled
#               `-- *.conf

DocumentRootはsites-enabled

とりあえずDocumentRootを変えたいということはよくあると思います。サイトごとの設定はsite-enabledに指定するようになっています。標準ではsite-enabledには000-default.confというファイルが配置されていて、中にはhttpd.confにあった<VirtualHost *:80>のセクションが切り出されています。

000-default.conf内には標準状態で4項目くらいしか設定値がなく、他は数十行のコメントがあるだけという単純構造になっています。

もう気づいた人もいるかもしれませんが、HTTPS(443)の対応をするのもsites-enabledの中に追加・変更が入って、AllowOverrideとか他の設定項目はapache2.confとかそれぞれ該当する他のファイルに設定項目/値があるという感じです。

Alias

httpd.confにAliasを設定したい場合も違う設定ファイルに記載します。Aliasは、/etc/apache2/mods-enabled/alias.confに設定があります。標準状態では、以下のように/icons/のAliasが設定されており、不要ならコメントアウトしてくださいと書かれています。

# We include the /icons/ alias for FancyIndexed directory listings.  If
# you do not use FancyIndexing, you may comment this out.

Alias /icons/ "/usr/share/apache2/icons/"

<Directory "/usr/share/apache2/icons">
        Options FollowSymlinks
        AllowOverride None
        Require all granted
</Directory>

新しい設定を追加する際に、こういう例が載っているのは参考になるので助かります。ちなみにalias.conf内の設定項目はこれだけで、後はこの上にもう少しのコメントしかありません。

この値を変更して使ってもいいし、別途のAlias定義を追加しても問題ありません。

www-data [apache2の実行ユーザー]

一点設定ファイルとは関係ない話ですが、重要な事なのでここに紹介しておきます。

CentOSのhttpdは、apacheというユーザー:グループで実行されていました。そのため、Webサーバーが操作するファイルは同ユーザー:グループで管理することも多いでしょう。

Ubuntuのapache2は、apacheというユーザーではなく、www-dataというユーザーで実行されています。確かにapacheというユーザーは、ログインするユーザーではなく、データの所有権のためだけにあるようなユーザーだったので、このような変更が入る意図も分からなくもないのですが、正直長い歴史のある常識が変化すると戸惑ってしまいます。

/var/www/html以下のファイルのオーナーグループを変更するといった、以下のようなコマンドを実行する場合には注意しましょう。

#CentOS (httpd)
chown -R apache:apache /var/www/html

#Ubuntu (apache2)
chown -R www-data:www-data /var/www/html

余談ですが、この定義は以下の場所にあって変更も可能です。

# cat /etc/apache2/envvars | grep RUN
export APACHE_RUN_USER=www-data
export APACHE_RUN_GROUP=www-data

Module

最後にModuleについて少し紹介します。

今回私が設定しているWebServerではModRewriteを使いたかったのですが、その設定の場所や有効にさせる方法がCentOSとは異なっていて調べる羽目になりました。

これはApache2全体の設計思想のようなのですが、設定ファイルがAvailabledとEnabledの2重構造になっています。Availabledはインストールされている・存在しているもので、Enabledがサービスとして有効なものという構造で、基本的にEnabledはAvailabledへのシンボリックリンクという構造のようです。サービス提供を止める際には、該当のシンボリックリンクを切れば(削除すれば)よいという構造です。

ModRewriteは、標準ではAvailabledにはあるけど、Enabledはないという状態のようなので、手動で有効化します。有効化するには以下のコマンドを利用します。

a2enmod rewrite

無効にするには[a2dismod rewrite]とします。上述のシンボリック云々の管理をこれらのコマンドで管理するのがApache2流ということなのですが、使用頻度が低すぎて覚えられる気がせず、いつか自分でこの記事を調べることになりそうな気がします。

結局違いはコアな所だけ

CentOSとUbuntuは、Linux DistributionとしてはRedHat系とDebian系と大きな違いがあるように感じますが、今回紹介したようなコアな部分での違いはあるものの、結局同じLinuxで動き始めてみれば大きな差は感じないでしょう。Linux自体に慣れているのであれば、インストールなど最初の部分の違いだけ乗り越えてしまえば、その後の使用感に差はあまり感じない気がします。

まさかCentOSのサービス提供が打ち切られて、将来使い続けることが難しいと判断する様な日が来ることは想像もしていませんでしたが、これぞ発展途上のIT業界ということで受け入れて前に進んでいくしかありません。

今回の記事が、CentOSからの移行を余儀なくされて苦労されている方たちの助けになれば幸いです。また、CentOSに染まった私の脳が、近い将来この記憶を忘れてしまった場合、備忘録としても役立ってくれることにも期待します。