Ubuntu Weekly Recipe

第331回パッケージ管理のハウツー集

UbuntuはおもにデスクトップLinuxの初心者ユーザーをターゲットにした使いやすさを重視して開発、発展していきました。今では初心者かどうかに関係なく数多くのユーザーを獲得した結果、Ubuntuの使い方や流儀について質問されることも多くなりました。

今回はそんな「こんなときどうすればいいの?」と質問を受ける項目のうち、とくにパッケージ管理まわりのあれやこれやを紹介します。

Aptをプロキシ内部で使うときに注意すべきこと

Ubuntuはシステム設定の「ネットワーク」からネットワークプロキシの設定を行えます。この設定を行えば、環境変数が設定され、Firefoxを含む各種ソフトウェアはプロキシ経由で接続するようになります。しかしいくつかのケースにおいて、プロキシ設定について留意する必要があります。

図1 システム設定のネットワークプロキシの設定画面
図1 システム設定のネットワークプロキシの設定画面

サーバー環境での設定

システム設定はデスクトップ環境のみ存在し、サーバー環境の場合は自分でプロキシ設定を行う必要があります。もしデスクトップ環境と同じように設定したい場合は、次のファイル[1]を編集してください[2]⁠。

/etc/environment
http_proxy="http://proxy.example.com:8080/"
https_proxy="https://proxy.example.com:8080/"
ftp_proxy="ftp://proxy.example.com:8080/"
socks_proxy="socks://proxy.example.com:1080/"
/etc/apt/apt.conf
Acquire::http::proxy "http://proxy.example.com:8080/";
Acquire::https::proxy "https://proxy.example.com:8080/";
Acquire::ftp::proxy "ftp://proxy.example.com:8080/";
Acquire::socks::proxy "socks://proxy.example.com:1080/";

ちなみに、apt.confの場合は未設定の場合、環境変数の値が使用されます。ただし、aptコマンドは原則としてsudo経由で実行することになるので、環境変数の値を使いたい場合は後述の「sudoコマンド実行時のプロキシ設定」が必要です。

sudoコマンド実行時のプロキシ設定

sudoコマンドを使って何かコマンドを実行した場合、http_proxyなどの環境変数は引き継がれません。このため一般ユーザーだとwgetは成功するもののsudoで実行すると失敗する、というケースがよくあります[3]⁠。

一番手っ取り早いのは、-Eオプションを使って、sudoを実行するユーザーの環境変数をsudoの対象のユーザーに引き継いでしまうことです。

$ sudo -E env
(http_proxyなどが引き継がれていることがわかる)

http_proxyなど特定の環境変数のみ引き継ぎたい場合は、sudoersを編集しましょう。

$ sudo visudo -f /etc/sudoers.d/proxy
(以下を追加する)
Defaults env_keep="http_proxy"
Defaults env_keep+="https_proxy"
Defaults env_keep+="ftp_proxy"
Defaults env_keep+="socks_proxy"

wgetなら/etc/wgetrcgitならgit-configのcore.gitproxyやhttp.proxyなど、アプリケーションごとの設定も存在しますので、必要に応じて使い分けてください。

プロキシのユーザー名とパスワード

これまで説明したいずれのケースにおいても、プロキシのユーザー名とパスワードはURLに埋め込むことで設定できます。

http_proxy="http://user:password@proxy.example.com:8080/"

ただし/etc/environmentや/etc/apt/apt.confに書く場合、このままだとパスワードを平文で保存する必要があります。平文で保存したくない場合は、どこかに暗号化した状態で保存しつつ、ログイン時に復号しhttp_proxyを設定するスクリプトを~/.profileに記述すると良いでしょう。⁠sudoコマンド実行時のプロキシ設定」と併せて使用すれば、apt.confへの設定は不要になります。

apt-get update時に「ハッシュサムが適合しません」と出る

プロキシ環境の内部から「apt-get update」などでパッケージリストを更新しようとすると、⁠ハッシュサムが適合しません」といったエラーが表示されることがあります。これはプロキシでキャッシュされているデータとキャッシュされていないデータの不整合が生じるために起こる問題です。

プロキシ内部からアップデートする場合は、/etc/apt/apt.confで、キャッシュを使わない設定にしておきましょう。

Acquire::http::No-Cache "true";
Acquire::https::No-Cache "true";

No-Cache以外にも、apt.confにはキャッシュコントロール用の設定が存在します。プロキシ内部のaptについては、単純にNo-Cacheにするだけでなく第315回でも紹介しているapt-cacher-ngを使って、プロキシの負荷を下げることも考慮してみてください。

パッケージを再インストールしたい

パッケージ管理されているファイルの一部を誤って消してしまった場合、そのパッケージを再インストールすることで復旧できます。

$ sudo apt install --reinstall パッケージ名

設定ファイルも含めて元に戻したい場合は、一度完全削除してからインストールし直しましょう。

$ sudo apt remove --purge パッケージ名
$ sudo apt install パッケージ名

この場合、削除するパッケージに依存しているパッケージも削除されてしまうため、インストールし直したあとに手動で対応する必要があることに注意してください。

ここでいう「完全削除」とはDebianパッケージにおける「設定ファイル」も含めて削除することを意味しています。各パッケージの設定ファイルのリストは次のコマンドで確認できます。

$ dpkg-query --control-show パッケージ名 conffiles

ここにリストアップされていない設定ファイル、たとえばソフトウェアが起動時にユーザーのホームディレクトリに自動生成するファイル、などは完全削除でも削除されません。

古いバージョンを使いつづけたい

パッケージシステムでアップグレードすると、インストールされているすべてのパッケージが最新バージョンに更新されます。しかし、何らかの理由により特定のパッケージだけ古いバージョンを使いつづけたいこともあるでしょう。

そんなときは、Pinを設定します。たとえばFirefoxの状態が次のような内容だったとします。

$ apt-cache policy firefox
firefox:
  インストールされているバージョン: 30.0+build1-0ubuntu0.14.04.3
  候補:               30.0+build1-0ubuntu0.14.04.3
  バージョンテーブル:
 *** 30.0+build1-0ubuntu0.14.04.3 0
        500 http://jp.archive.ubuntu.com/ubuntu/ trusty-updates/main amd64 Packages
        500 http://security.ubuntu.com/ubuntu/ trusty-security/main amd64 Packages
        100 /var/lib/dpkg/status
     28.0+build2-0ubuntu2 0
        500 http://jp.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages

ここで候補となるパッケージは、上からtrusty-updatesとtrusty-securityの30.0+build1-0ubunt0.14.04.3(優先度500⁠⁠、インストール済みの同じパッケージ(優先度100⁠⁠、trustyにある28.0+build2-0ubunt2(優先度500)の4つが存在します。aptではもっとも高い優先度のうち、バージョンが新しいものがインストールされますので、上記の例ですと優先度500のうち、一番新しい30.0がインストールされることになります(trusty-updatesとtrusty-securityはこの場合、中身が同じです⁠⁠。

もし28.0を使いつづけたい場合は、次のように設定します。

$ sudo editor /etc/apt/preferences.d/firefox
Package: firefox*
Pin: version 28.0*
Pin-Priority: 1001
$ sudo apt update
$ sudo apt upgrade

Pin-Priorityが1000以上の場合、現在のバージョンよりバージョンが古くても、そのバージョンへのアップグレード(つまりダウングレード)を行います。

単純にバージョンを指定してインストールしたいだけであれば、次のようにインストール時にバージョンを指定する方法もあります。

$ sudo apt install firefox=28.0+build2-0ubuntu2

より実用的な要望として特定のPPAのパッケージは、Ubuntuの公式リポジトリのパッケージより優先度を上げたいことがあるでしょう。

$ sudo add-apt-repository ppa:foo/bar
$ sudo editor /etc/apt/preferences.d/ppa-foo-bar
Package: *
Pin: release o=LP-PPA-foo-bar
Pin-Priority: 600

これにより公式リポジトリのパッケージのアップデートにより、一時的に公式リポジトリのバージョンがPPAより新しくなったとしても、PPA側が更新されるまではアップグレードされなくなります。また、逆にPin-Priorityを500より小さくしておけば、明示的にPPAのパッケージを指定しない限りは、インストールされなくなります。これはUbuntu Backportsで指定されている設定と同じです。

どうしても古いリリースを使いたい

UbuntuはLTSで5年、通常リリースで9ヶ月というサポート期間を設けています[4]⁠。サポート期間を終了すると(EOL:End Of Lifeを迎えると⁠⁠、公式のアーカイブサーバーからはそのリリース用のパッケージが順次削除され、aptコマンドによる公式リポジトリからのインストールやアップグレードもできなくなってしまいます。

しかしなんらかの理由により、EOLを迎えたUbuntuをインストールし、場合によってはaptコマンドでパッケージをインストールする必要が出てくることもあるでしょう。そんな用途向けに、old-releases.ubuntu.comが存在します。

/etc/apt/sources.listの⁠jp.archive.ubuntu.com⁠などを⁠old-releases.ubuntu.com⁠に置き換えれば、サポート期間を終了したリリースであっても、パッケージのインストールやアップグレードを行えます。また、4.10以降のインストールイメージも配布しています

当然のことながら、これらのリポジトリにはサポート期間終了後のセキュリティアップデートは提供されていません。これらを利用するPCをインターネットに直接接続することは危険な行為であることを理解したうえで利用してください。

パッケージを整理したい

バイナリパッケージのキャッシュを削除する

Aptを使ってパッケージをインストール/アップグレードするとき、リポジトリからダウンロードしたバイナリパッケージファイルが/var/cache/apt/archives以下にローカルリポジトリとして保存されます。ローカルリポジトリはパッケージの再インストールの際にキャッシュとして使われるため便利ではあるのですが、放っておくとどんどんと容量が増えていきます。

apt-getのcleanコマンドやautocleanコマンドを使うとこのリポジトリを整理できます。

$ sudo apt-get autoclean

autocleanコマンドは、ローカルリポジトリのうち(より新しいバージョンがリリースされたために)公式リポジトリに存在しないバイナリパッケージのみを削除します。cleanコマンドはすべてのバイナリパッケージを削除します。

autocleanは設定によって定期的に実行することが可能です。

$ sudo editor /etc/apt/apt.conf.d/10periodic
(中略)
Apt::Periodic::AutocleanInterval "0";

AutocleanIntervalの値を0から、任意の数字に変更してください。cronによって、その指定した数字の日数ごとに、autocleanがバックグラウンドで実行されます。

使われなくなったパッケージを削除する

autocleanと似たような名前のコマンドにautoremoveも存在します。こちらは、⁠依存関係にしたがって暗黙的にインストールされたものの、依存元のパッケージが存在しなくなったために、不要であると思われる」パッケージをアンインストールします。clean/autocleanがキャッシュファイルの削除なのに対して、autoremoveは実際にパッケージのアンインストールが発生します。

推奨パッケージをインストールしない

そもそも自動的にインストールするパッケージを抑制するという方法も存在します。Ubuntuは8.10から、インストールしようとしているソフトウェアが依存しているパッケージだけでなく「推奨パッケージ」一緒にインストールするようになりました。これは大抵の場合はユーザーにとって便利ではあるものの、たまに必要以上に多くのパッケージが一緒にインストールされてしまうこともあります。

aptコマンドに--no-install-recommendsオプションを渡すことで、推奨パッケージのインストールを抑制できます。

$ sudo apt install texlive-lang-cjk
(中略)
アップグレード: 0 個、新規インストール: 143 個、削除: 0 個、保留: 16 個。
866 MB のアーカイブを取得する必要があります。
この操作後に追加で 1,683 MB のディスク容量が消費されます。

$ sudo apt install --no-install-recommends texlive-lang-cjk
(中略)
アップグレード: 0 個、新規インストール: 50 個、削除: 0 個、保留: 16 個。
139 MB のアーカイブを取得する必要があります。
この操作後に追加で 575 MB のディスク容量が消費されます。

サーバー環境などで恒常的に--no-install-recommendsオプションを付けたい場合は、/etc/apt/apt.confに「Apt::Install-Recommends "false";」と記述してください。ちなみに提案パッケージも「Apt::Install-Suggests」で同じようにコントロールできます。

パッケージセットをインストールしたい

Ubuntu Serverをインストールしたことがある人なら、インストールするサーバーの目的ごとにパッケージの集合を選択できる画面を見たことがあるでしょう。

図2 サーバーの用途ごとにソフトウェアコレクションを選択できる
図2 サーバーの用途ごとにソフトウェアコレクションを選択できる

これはtaskselというソフトウェアが提供している機能で、インストール後であってもtaskselをインストールすればいつでも呼び出すことが可能です。

$ sudo apt install tasksel
$ sudo tasksel
(グラフィカルなタスク選択画面が出てくる)

●タスクの一覧表示
$ tasksel --list-tasks
i server        Basic Ubuntu server
i openssh-server        OpenSSH server
u dns-server    DNS server
u lamp-server   LAMP server
(後略)

●タスクの概要表示
$ tasksel --task-desc lamp-server
Selects a ready-made Linux/Apache/MySQL/PHP server.

●タスクでインストールされるパッケージの一覧
$ tasksel --task-packages lamp-server
php5-common
libwrap0
apache2-bin
apache2
(後略)

●タスクのインストール
$ sudo tasksel install lamp-server

タスクの内容は、Ubuntu Seedsプロジェクトと各フレーバーのチームが、フレーバーごとに管理しています。たとえばUbuntu本体の場合はこちらにあるファイルが使われます[5]⁠。

Seedに列挙されているパッケージは、アーカイブサーバーに送られるときにTaskフィールドが付与されます。たとえばUbuntu ServerやCloudイメージに含まれるbyobuの場合は次のようになります。

$ apt show byobu
(中略)
Task: ubuntu-usb, cloud-image, server, edubuntu-usb

このTaskフィールドを使えば、taskselがなくてもaptコマンドでタスクセットをインストールできます。たとえばUbuntu Serverはデスクトップと異なり「ubuntu-server」のようなメタパッケージがありません。Ubuntu Core環境から直接Ubuntu Serverを構築したい場合は、serverタスクとstandardタスクをインストールする方法が一番簡単です。aptコマンドでタスクを選択したいなら、パッケージ名の代わりにタスク名を指定し、最後に「^」を追加します。

$ sudo apt install server^ standard^

CUIの標準エディタを変更したい

Ubuntuをインストールした直後の環境だとeditorコマンドなどで起動するCUI向けのテキストエディタはGNU nanoです。いろいろ異論はあるかと思いますが「GNU nano」です。このためeditorコマンドを直接叩くだけでなく、visudoやvipwといったコマンドを実行した時もnanoが起動します。

ただエディタは人によって好みがわかれるだけに、標準で起動するエディタはその人にあったものに変更した方がストレスがないでしょう。editorコマンドは、update-alternativesを使って起動するエディタを切り替えることができます。

●候補の表示
$ update-alternatives --list editor
/bin/ed
/bin/nano
/usr/bin/vim.basic
/usr/bin/vim.tiny

●対話的に選択
$ sudo update-alternatives --config editor
alternative editor (/usr/bin/editor を提供) には 4 個の選択肢があります。

  選択肢    パス              優先度  状態
------------------------------------------------------------
  0            /bin/nano            40        自動モード
  1            /bin/ed             -100       手動モード
  2            /bin/nano            40        手動モード
* 3            /usr/bin/vim.basic   30        手動モード
  4            /usr/bin/vim.tiny    10        手動モード

現在の選択 [*] を保持するには Enter、さもなければ選択肢の番号のキーを押してください: 3

●非対話的に選択
$ sudo update-alternatives --set editor /usr/bin/vim.basic

sensible-editorというコマンドをもあります。これはEDITORやVISUALといった環境変数を元に起動するエディタを切り替えます。select-editorコマンドを使えば、EDITOR/VISUALが存在しないときの値も設定できますし、最終的にそれも存在しなければeditorコマンドを実行します。どんなエディタがインストールされているかわからない環境のスクリプトとして使うと便利でしょう。

64bit版の上で32bit版パッケージを使う

そろそろ64bit版のUbuntuを使っている人もだいぶ増えてきたかと思いますが、WineやAndroidエミュレーターなどで32bit版の環境が必要になることはまだ存在します。そんなとき今実行しているのが64bit環境であれば、VirtualBoxやLXCといった仮想環境の上に32bit環境を作ってしまうのが一番わかりやすいでしょう。

ただし、UbuntuはMulti-archに対応しているため、32bit版パッケージを64bit環境にインストールして利用できます。その方が手間もリソースの消費も少なくなりますので、お勧めです。

過去にはia32-libsパッケージを使って一括して大量の32bitパッケージをインストールする手順が紹介されていましたが、現在はこのパッケージはなくなりました。現在は、普通のパッケージインストール時と同じように、必要なパッケージのみを選択してインストールします。

$ sudo dpkg --add-architecture i386
$ sudo apt update
$ sudo apt install package1:i386 package2:i386

このときpackage1がi386版のパッケージに依存している場合は、自動的にi386版のパッケージがインストールされます。

他にも

これまでにも第173回では自動アップデートの機能や、第312回ではパッケージに関する情報収集などいろんなハウツーを紹介してきました。パッケージ管理システムについては設定項目が多岐に渡っており、まだまだ便利な機能が存在します。

「こんなことがやりたいんだけど?」と思ったら、ぜひぜひmanページなどでそんな機能がないかどうか調べてみてください。

おすすめ記事

記事・ニュース一覧