第4回では、Ubuntuにおけるソフトウェアのインストール方法を紹介した。Ubuntuとしては、理想的にはAPTもしくはsnapシステムを用いて公式リポジトリ経由で、すべてのソフトウェアをインストールできるのが望ましい。しかしながら、実際にはそのような状態とは程遠いのが現実だ。今回はサードパーティのリポジトリを追加する方法と、リリース間のアップグレードについて紹介しよう。
Ubuntuにおけるパッケージのバージョンについて
非公式のリポジトリを使う最大の理由は、「リポジトリのパッケージバージョンが古い」ことだろう。そこでまずはUbuntuのパッケージのバージョンポリシーについて説明しておこう。
Ubuntuのパッケージはおおよそ次のようなフォーマットのバージョンが付いている。バージョンフォーマットを定めておくことで、パッケージ管理システムが機械的にバージョンの大小を判断できるようにするのが目的だ。
さて、まず大前提としてUbuntuは 「リリース後にはソフトウェアのバージョンは更新しない」 というポリシーを取っている。これはUbuntuのリリース後に広く使われるようになった状態において、不用意に特定のソフトウェアのバージョンを上げた結果、意図しない不具合が紛れ込んでしまわないようにするための措置だ。特にライブラリ系は下手に更新してしまうと、依存するほかのソフトウェアもすべてビルドしなおしになってしまう可能性がある。よって上図の「ソフトウェアのバージョン」は、Ubuntuの同じリリース内であれば(たとえば22.04同士であれば)変更はされない。
もちろんリリース後であっても不具合修正等は必要になる。この場合は、たとえばソフトウェアの開発元(Ubuntuを含むLinuxディストリビューションではこれを開発の上流側という意味で Upstream と呼ぶ)の修正内容をパッケージのバージョンに合わせたパッチという形でパッケージに取り込み、「Ubuntuの変更バージョン」をインクリメントして配布する。セキュリティアップデートも同様だ。ただしセキュリティアップデートの場合は、「Ubuntuの変更バージョン」の小数点以下を追加・インクリメントすることも多い。
このため特定のソフトウェアのバージョン「X.Y.Z」に重大な脆弱性が公開されたとき、開発元では「バージョンX.Y.(Z+1)で修正しました」とアナウンスされていても、Ubuntuのリリース済みのリポジトリではバージョン「X.Y.(Z+1)」のパッケージはリリースされない。その代わりX.Y.Zに変更点をバックポートし、「X.Y.Z-MubuntuN.1」のように「Ubuntuの変更バージョン」のみが更新される。さらに、これによりUbuntuのより新しいリリースにアップグレードする際には、「X.Y.(Z+1)」以降に問題なく更新できる、というわけだ。
ただしいくつかのパッチのバックポートが難しいソフトウェアについては、例外的にバージョンを上げることもある(SRU:Stable Release Update)。SRUするためには、SRUでないといけない理由や影響範囲等を報告しなくてはいけない。このあたりはソフトウェアごとの事情を勘案しながら、運用によって柔軟に対応している。
脆弱性対応については、一般的にはCVE番号が割り振られている。よってどの修正が、どのUbuntuバージョンで適用されているかはUbuntu Security NoticesをCVE番号で検索すると良いだろう。またCLIからなら「apt changelog パッケージ名」でパッケージの変更履歴を参照できる。この中をCVE番号で検索するというのも1つの手だ。
PPA:Personal Package Archive
公式リポジトリのソフトウェアは、サポート中のリリース版を使っている限りバージョンが上がることはない。もしもより新しいバージョンのソフトウェアをインストールしたくなった場合に、よく利用されるのが 「PPA(Personal Package Archive)」 を初めとした 「独自リポジトリ」 だ。
第4回でUbuntuのリポジトリはHTTPサーバーとリポジトリ鍵で構築されているという話をした。これはとどのつまりHTTPサーバーとリポジトリ鍵を自前で用意すれば、APTシステムに対応した独自のパッケージリポジトリを構築できることを意味する。また「/etc/apt/sources.list.d/」以下にファイルを適切に配置すれば、公式リポジトリとサードパーティのリポジトリの両方を同じパッケージ管理システム上で運用できるようになる。
Ubuntuが登場した当初、複数のリリースやCPUアーキテクチャやリポジトリ鍵に対応したリポジトリを作るには、そこそこの知識が必要で面倒な作業だった。しかしながらUbuntuの根幹がdebパッケージで構成されている以上、開発者が気軽にテスト版パッケージを公開する場所が必要になる。そこで出てくるのがPPAだ。これは適切なソースパッケージ(ソフトウェアのソースコードにパッケージ情報を追加したもの)をアップロードすれば、自動で指定したリリースの複数のCPUアーキテクチャ向けにバイナリパッケージをビルドし、APT用のリポジトリとして公開してくれる仕組みだ。
また、そのパッケージを利用したいユーザーは、個々のリポジトリのサイトに提示されている手順に従えば、簡単にシステムにそのリポジトリを追加できるようになっている。
具体的には次の手順でPPAのリポジトリを追加できる。
この処理はリポジトリ鍵を取り込むため、管理者権限が必要になる。そのため「ソースを追加」したときにパスワードの入力を求められるので、画面の指示に従おう。また、「ソフトウェアとアップデート」を終了する際に「リポジトリの情報が古い」旨を指摘されるため、「再読み込み」ボタンを押しておく。これでリポジトリの追加は完了だ。
GUIの手順に加えて、CLIを利用して追加する方法も紹介しておこう。
PPAのリポジトリを追加する方法
$ sudo add-apt-repository ppa:(PPA名)
このあたりは今後連載の中でも「PPAを導入する」というような表現で言及することもあるので、覚えておくと良いだろう。
独自リポジトリとdebファイル
DockerのようにUbuntuを公式にサポートするメジャーなソフトウェアの場合、PPAを使わずに自前で独自リポジトリを運用していることも多い。そのような場合も、「ソフトウェアとアップデート」からGUIリポジトリを追加可能ではあるが、リポジトリ鍵の取り込み等を手動で行なう必要があり、PPAと比べると若干手間が増える。このようなケースは、ソフトウェアのドキュメントに従ってCLIで実施するほうが楽だろう。
またソフトウェアによっては「debファイル」のみを提供しているものもある。こちらはWebブラウザでダウンロードすると、Ubuntu Softwareが立ち上がりそこからインストールできる。またCLIなら次の方法が使える。
debファイルをインストールする方法
$ sudo apt install ./foo.deb
ただしリポジトリの追加と異なり、パッケージ管理システムの仕組みを利用した自動的なアップデート等には対応できない点に注意が必要だ。
ちなみに、たとえばGoogle ChromeのダウンロードサイトにLinuxからアクセスするとdeb版かrpm版かを選択してダウンロードできる。このうちdeb版は、インストールすると自動的にChromeのパッケージリポジトリを追加し、そこからChrome本体をインストールする仕組みになっていたりする。
PPAや独自のリポジトリにしろdebファイルにしろ、サードパーティのパッケージは、Debian/Ubuntuに準拠したパッケージ品質が維持されているとは限らない。よってあまりにも追加しすぎると、システムの不安定性をもたらす点は留意しておこう。
リリース間のアップグレード
「Ubuntuはリリース後にソフトウェアのバージョンを変更しない」と説明したが、もちろんリリース間であれば別だ。具体的には2021年10月にリリースされたUbuntu 21.10から、2022年4月にリリースされたUbuntu 22.04 LTSにアップグレードすれば、カーネルを含むさまざまなソフトウェアのバージョンが一気に更新される。もし古いUbuntuを使っているのであれば、Ubuntuそのものを更新するのも1つの手だろう。
特に本連載が開始するきっかけとなったUbuntuの記事(人気Linuxディストリビューション、Ubuntuを触ってみよう！)では、まだUbuntu 22.04 LTSがリリースされていなかったこともあって、21.10をインストールする手順を紹介している。その記事を読んで早速Ubuntuをインストールしてみた、行動力のあるエクセレントな読者は、もしかするとまだ21.10のままかもしれない。
Ubuntuは2年に1度リリースされるLTS(長期サポート版)だと5年のサポートを謳っているが、21.10のようなそれ以外のリリースのサポート期間は9カ月になる。つまりUbuntu 21.10は7月14日に「End Of Life(EOL)」を迎える予定だ。21.10のユーザーはこの日までに22.04へアップグレードすることが強く求められている。
とは言え、21.10のユーザーならもうすでに、次のようなアップグレードの通知が届いているだろう。
画面左下のボタン(もしくは「Super(Windows)+a」)から「update」で検索すると表示される「ソフトウェアの更新」を起動しても、上記ダイアログを表示できる。あとは他のアプリケーションを一通り終了した上で、画面の指示に従ってアップグレードするだけで完了だ。
ちなみにアップグレード時は、公式リポジトリ以外のリポジトリはいったん無効化される。もし必要ならアップグレード後に、再度見直しておくと良いだろう。ただし、PPAやサードパーティのリポジトリをたくさん追加すると、アップグレードも失敗する可能性が高くなる点には注意が必要だ。
アップグレードを実施する際は、次の点に注意しておこう。
- あらかじめリリースノートを読んでおく
- 重要なデータはバックアップしておく
- 事前にソフトウェアのアップデートはすべて適用しておく
- 重要なデータはバックアップしておく(2回目)
- ネットワークとストレージと時間と気持ちに最大限の余裕を持たせておく
- 重要なデータはバックアップしておく(3回目)
「リリースノート」 は個々のリリースにおける変更点一覧だけでなく、リリース時点で判明している不具合やアップグレードの注意事項などが掲載されている。たまに「こういう状態のシステムでアップグレードすると致命的な問題が起きるから気をつけろ」みたいなことが、特に強調されることなく書いてあったりするから要チェックだ。慣習的にs390x(IBMのメインフレームコンピューター)向けの情報等も満載であるため全部を読む必要はないが、 「新機能」の前半にあるデスクトップ関連、および末尾にある「既知の問題」「日本語環境独自の記述」 あたりは一通り読んでおくと余計なトラブルを回避できる。
ちなみにUbuntuの場合、リリースノートは「リリースの目処が立ってから本格的に準備を始める」ことが多い。英語版だとリリース日にはそこそこのものができあがっているものの、その後も更新され続ける。また日本語版はその英語版の作成状況を見ながら翻訳するため、リリースから1週間程度ずれることになる。いわゆる「人柱」を目指さないのであれば、リリースから少し待ってからインストール作業を始めるのがおすすめだ。
アップグレードする際は、インターネット経由で大量の新しいパッケージをダウンロードすることになる。よってインストール済みのパッケージ数にもよるが、ネットワーク回線にそれなりに負荷がかかる点に注意が必要だ。デスクトップ版の場合、想定としてはUbuntuのインストールイメージをダウンロードするぐらいの通信量(数GiB程度)は覚悟しておいたほうがいいだろう。
最近のUbuntuは、公式リポジトリのみを使っている限り、リリース間のアップグレードで失敗することはほとんどない。また、失敗してもある程度元の状態に戻れるため、そこまでダメージは大きくない。しかしながら経験上、「油断してバックアップなどを取っていなかった」時に限って、致命的な失敗が起こりやすくなることが分っている。よってバックアップを取っておくことはとても重要だ。
詳細なバックアップのとり方はまた別の機会に紹介するとして、もし外付けストレージに余裕があるならストレージごとコピーをとってしまうというのも1つの手だろう。コピーデータを仮想マシンイメージ化して、アップグレード後と併用するという手もある。Ubuntuはフリーソフトウェアで構成されているため、こういう使い方をしてもライセンス的に問題になることはない。
Ubuntuの場合、アップグレードするのではなく、リリースの度に新規インストールするというユーザーも多い。インストール後の環境構築方法を確立しておけば、その方が「きれいになる」し、ほかのマシンに同じ環境を構築する際に手順を参照すれば良いだけになる。一歩進めてインストール後の作業を自動化するという手もあるだろう。また、インストールしてみたはいいものの、実際そんなに使わないパッケージなんかも整理できる。リリース毎に「断捨離」をするイメージだ。
前回から2回に渡って、ソフトウェアのインストールとアップグレードについて解説した。これでようやく「こんな風にソフトウェアを追加すれば、Ubuntuも便利に使える」という話に進める。次回からはもう少し実践的な話をする予定だ。
からの記事と詳細 ( 【第5回】Ubuntuのリポジトリの追加方法とアップグレード - PC Watch )
https://ift.tt/cgXLxKw
科学＆テクノロジー
No comments:
Post a Comment