Difference between revisions of "Enhancing Arch Linux Stability (日本語)"

From ArchWiki
Jump to: navigation, search
m (pacmatic の使用)
m (開発中のパッケージを使わない)
Line 49: Line 49:
 
特に、カーネルや glibc などの重要なシステムパッケージの開発バージョンをインストールするのは止めましょう。
 
特に、カーネルや glibc などの重要なシステムパッケージの開発バージョンをインストールするのは止めましょう。
  
makepkg を使ってカスタムパッケージをビルドするときは、PKGBUILD の provides 行などが [[Arch Packaging Standards]] に従っているか確認してください。生成された .tar.gz や PKGBUILD ファイルをチェックするには namcap を使います。
+
makepkg を使ってカスタムパッケージをビルドするときは、PKGBUILD の provides 行などが [[Arch Packaging Standards (日本語)]] に従っているか確認してください。生成された .tar.gz や PKGBUILD ファイルをチェックするには namcap を使います。
  
 
==== linux-lts パッケージをインストール ====
 
==== linux-lts パッケージをインストール ====

Revision as of 14:34, 23 March 2013

この記事の目的は Arch Linux を可能な限り安定にするヒントを提供することです。Arch の開発者と Trusted User は高品質なパッケージを作成するために日夜励んでいますが、Arch のローリングリリースシステムと、パッケージがコロコロと変わるのが理由で、ミッションクリティカルな・商業用の本番環境には Arch が適さないと考えられても詮無きことかもしれません。

ただし、設定のシンプリシティ、素早いバグレポート・バグフィックスサイクル、そしてアップストリームのソースコードにパッチをあてないで利用することを約束している Arch は本質的に安定しているものなのです。従って、Arch の設定やメンテナンスで以下のアドバイスに従えば、ユーザーは非常に安定したシステムに恵まれるでしょう。さらに、問題が起こった時にシステムを修復するのを楽にするアドバイスもあります。

実際のところ Arch はどれくらい安定していると言えるのでしょうか?Arch を本番サーバーに問題なく使えているという、熟練したシステム管理者による報告が Arch フォーラムにはごろごろあります。Archlinux.org はその一例と言えます。デスクトップでも、正しく設定されメンテナンスされている Arch は素晴らしいスタビリティを発揮します。

Contents

Arch のセッティング

Arch Linux を始めてインストール・設定するとき、ユーザーは設定・ソフトウェア・ドライバについて多くの選択肢を持っています。これらの選択はシステム全体の安定性に大きな影響を与えます。

Arch 特有のヒント

/var パーティションを大きくとって古いパッケージをキープする

インストール中にパーティションを設定する時はいつでも、/var パーティションに十分に大きい容量を割り当てるようにしましょう。/var パーティションにたっぷり6から8GBのスペースを持たせるべきです - サーバーとして使うならもっと容量を与えましょう。Pacman は前にインストールしたパッケージを全て /var/cache/pacman/pkg に保管しています。そのために容量をかなり喰うのです。これらのパッケージを維持しておけば、パッケージアップグレードで不安定になった時に保存しておいた古いパッケージにダウングレードできます。下のセクションを見て下さい。

推奨設定を使う

Arch Linux のインストールと設定のドキュメントでは、システムの特定の部分を設定するのに複数の方法を提示していることがよくあります。システムを設定する時はいつでも、推奨の・デフォルト設定を選ぶようにしてください。推奨・デフォルト設定はシステムの安定や修理に最適な、ベストプラクティスを反映しています。

非公式のパッケージ・テストされていないパッケージに気をつける

testing リポジトリや testing 内のパッケージの使用を止めましょう。testing のパッケージは開発やテストのためにあり、安定なシステムには適しません。

AUR からパッケージをインストールするときは用心してください。AUR のパッケージのほとんどはユーザーによって供給されており公式リポジトリのパッケージのようなパッケージング標準は持っていません。AUR のパッケージをビルド・インストールする前に、PKGBUILD に悪意のあるコードや間違いがないか毎回確認しましょう。

AUR パッケージのインストールを簡単にする AUR Helpers (日本語) にも気をつけましょう、悪意のある PKGBUILD を含むパッケージをビルド・インストールしてしまう恐れがあります。パッケージをビルド・インストールする前には必ずサニティチェックをするべきです。

最後に、AUR Helpers (日本語)makepkg コマンドを root ユーザーとして実行するのは全く持って愚かな行為だと言っておきます。

サードパーティのリポジトリについては、どうしても必要な時だけ、もしくはそれが何かよくわかってるときだけ使うようにしてください。サードパーティのリポジトリは信用のおけるソースから使って下さい。

最新のミラーを使う

メインの Arch FTP サーバーと最新のパッケージを頻繁にアップデートしているミラーを使って下さい。Mirror Status webpage を使えばミラーが最新かどうか確認できます。素早く rsync されてるミラーを使うことで、日々のメンテナンスでフレッシュなパッケージとパッケージデータベースを使うことができるようになります。

また、/etc/pacman.d 内のミラーリストを編集してあなたの国や地域に位置するミラーをリストの一番上に置いてください。特定のミラーを有効にするを参照してください、また rankmirrors スクリプトを使うことで最速のミラーを有効にできます。

アップデートに使用するミラーサーバーを変えた後は、pacman -Syu を実行してシステムを最新の状態にするようにしましょう。

開発中のパッケージを使わない

システムに深刻なダメージを与えるのを防ぐために、開発中のパッケージをインストールしてはいけません。こうしたパッケージは通常 AUR にあり、時には community にも存在します。アップストリームの開発ブランチから直接作られるパッケージには次のような単語がパッケージ名に付けられます: dev, devel, svn, cvs, git, hg, bzr, darcs。

特に、カーネルや glibc などの重要なシステムパッケージの開発バージョンをインストールするのは止めましょう。

makepkg を使ってカスタムパッケージをビルドするときは、PKGBUILD の provides 行などが Arch Packaging Standards (日本語) に従っているか確認してください。生成された .tar.gz や PKGBUILD ファイルをチェックするには namcap を使います。

linux-lts パッケージをインストール

linux-lts パッケージは Linux カーネル 3.0 をベースにした Arch カーネルパッケージで [core] リポジトリで利用できます。このカーネルバージョンはアップストリームの、セキュリティフィックスや機能のバックポートなど長期間サポート (LTS) を受けられます。Arch をサーバーとして使っていたり、新しいカーネルバージョンで問題がおこるときなどに有用です。

ブートオプションとして使えるようにするには、ブートローダの設定ファイルを更新する必要があります。例えば、Syslinux の場合は、/boot/syslinux/syslinux.cfg を編集して現在のエントリを vmlinuz-linux-ltsinitramfs-linux-lts.img にします。GRUB の場合、.cfg を自動で再生成するのが推奨される方法です。

標準の linux パッケージに加えて linux-lts パッケージをインストールして Fallback エントリを LTS カーネルにすることもできます。

一般的なベストプラクティス

パッケージマネージャを使ってソフトウェアをインストールする

パッケージマネージャ (Arch では: pacman (日本語)) はファイルを管理することについてあなたよりも良い仕事をします。手動でソフトウェアをインストールすると、遅かれ早かれ何を何処にインストールしたのか忘れて、ソフトウェアを衝突させたり誤った場所にインストールしたりするでしょう。

安定性の観点からは、サポートされていないパッケージやカスタムソフトウェアを使うのはやめるべきですが、どうしてもそうしたパッケージが必要なときは、パッケージを作成したほうが手動でコンパイル・インストールするよりマシです。

/root/.bashrc で make install コマンド(たいてい全ての問題の根源になります)を無効にしたほうがいいかもしれません

 make() {
   [ "$1" == 'install' ] &&
     echo -e "WARNING:\nDON'T INSTALL SOFTWARE MANUALLY\nDON'T USE unset make TO OVERRIDE" &&
     echo "Tip: It's easy to make own custom package see: man PKGBUILD makepkg" &&
     return 1;
   /usr/bin/make $@;
 }

メインストリームのソフトウェアパッケージを使う

成熟したメインストリームのソフトウェアをインストールして、最先端 (cutting edge) のバグまみれ (buggy) のソフトウェアを使うのを避けましょう。"ポイントオー"、つまり x.y.0 のように最後に0がつくバージョンのソフトウェアリリースをインストールしないよう心がけて下さい。例えば、Foobar 2.5.0 をインストールするかわりに Foobar 2.5.1 がリリースされるのを待ちましょう。新しく開発されたソフトウェアは信頼性が証明されるまで利用してはいけません。例えば、PulseAudio の初期のバージョンは信頼性がないことがあります。スタビリティを出来る限り高めたいユーザーは代わりに ALSA サウンドシステムを使うのがいいでしょう。最後に、開発コミュニティが強固で活発なソフトウェアを使いましょう。

オープンソースドライバを選ぶ

出来る限り、オープンソースドライバを選んで下さい。プロプライエタリドライバは避けましょう。大抵、オープンソースドライバはプロプライエタリドライバよりも安定していて信頼性があります。オープンソースドライバのバグは素早く修正されます。プロプライエタリドライバはより多くの機能があるかもしれませんが、それには安定性のコストがつきまといます。このジレンマに陥らないために、成熟したオープンソースドライバがフルにサポートしているハードウェアコンポーネントを選ぶようにしてください。オープンソースの Linux ドライバとハードウェアの情報は linux-drivers.org にあります。

Arch のメンテナンス

Arch を安定に設定するのに加えて、ここではメンテナンスの際にスタビリティを高める方法を記述します。システムの信頼性を高めるのに役立つシスアドの細部に注意してください。

Arch 特有のヒント

適度な頻度でシステムをアップグレード

多くの Arch ユーザーは頻繁にアップデートをします、毎日 pacman -Syu を使ってシステムをアップデートする人さえいます。そんなに頻繁にアップデートする必要はないですが、最新のバグフィックスやセキュリティアップデートを得るために適切な頻度でアップグレードするべきでしょう。一週間ごと、もしくは隔週ごとのアップデートがグッドです。

AUR パッケージがある場合は、注意して全ての AUR パッケージをアップグレードしてください。

システムをアップグレードする前に読むもの

Arch をアップグレードする前に、必ず最新の Arch News を読んで最新のパッケージで主要なソフトウェアや設定の変更がないか知っておくべきです。カーネルや xorg、glibc などの重要なソフトウェアを新しいバージョンにアップグレードする前には、適切な webforum を見てなにか問題が報告されていないか調べましょう。

アップグレード中の警告に対処する

システムをアップグレードする時、pacman によって表示された警告を注意して見て下さい。ユーザーによる追加の行動が必要な場合は、正しくそれに対処してください。pacman の警告の意味がわからない時は、フォーラムや最近の news から具体的な指示を検索してください。

迅速に .pacnew, .pacsave, .pacorig ファイルを処理する

設定ファイルを持っているパッケージを pacman によって削除すると、普通は設定ファイルのバックアップコピーが作られファイル名の最後に .pacsave が付けられます。同じく、現在インストールされているファイルとは異なる(メンテナによって作られた)新しいファイルを含むパッケージにアップグレードされると、pacman は .pacnew 設定ファイルを書き込みます。特別の事情があるときは、.pacorig ファイルが作成されます。Pacman はこうしたファイルが作られたことを知らせます。

pacman がこれらファイルを作成したときは、システムの安定を保つために、ユーザーは素早くファイルを処理しなければなりません。詳しい解説は Pacnew and Pacsave Files ページを参照してください。

.pacnew や .pacsave ファイルを処理するのに役立つツールはさまざまです。ファイルを比較するには標準の diff ユーティリティ (もしくは、colordiff) が楽な方法でしょう。pacman-contrib パッケージはこうしたファイルを調節するのに役立つ pacdiff が含まれています。最後に、pacnews bash script は同じような機能を提供します。pacdiff と pacnews はどちらも vimdiff を使って .pacnew や .pacsave ファイルを比較・編集します。

pacmatic の使用

Pacmatic はアップグレードの前の Arch News の確認プロセスを自動化する pacman ラッパーです。Pacmatic はローカルの pacman データベースがオンラインミラーと正しく同期されているか確認することも行うので、下手な pacman -Sy によるデータベースアップデートの潜在的な問題を回避できます。最後に、pacmatic はアップデートされたり使われなくなった設定ファイルについて厳格な警告を発します。pacmatic は pacman のエイリアスとして使うことが可能で、様々な AUR Helpers (日本語) で pacman の代わりに pacmatic を使うよう設定できます。

特定の pacman コマンドを使わない

Arch はローリングリリース・ディストリビューションなので、フルシステムアップグレードをしないで pacman データベースを更新するのは危険です。パッケージをインストールするのに pacman -Sy package を使うのはやめて、代わりに pacman -S package を使うようにしてください。また、定期的に pacman -Syu でシステムをアップグレードしてください。

pacman に -f オプションを使うのは避けてください。特に pacman -Syuf のように複数のパッケージが関わるコマンドで使ってはいけません。--force オプションはファイルの衝突を無視するのでファイルが再配置されたときにファイルが消失する可能性さえあります!正しくメンテナンスされているシステムでは、使う必要は絶対にないはずです。

pacman -Rdd package を使ってはいけません。-d フラグはパッケージを削除するときに依存関係のチェックを飛ばします。結果として、クリティカルな依存関係のパッケージを削除してしまい、システムを破壊してしまう恐れがあります。

ディスク容量に貧窮していたり、圧縮済みのパッケージファイルが不要な場合以外は pacman -Scc を実行してはいけません。キャッシュとして古いパッケージを保持していれば、アップグレードによって問題が発生した時に安全にパッケージをリバートできます。代わりに、pacman -Sc を使えば、以前に pacman データベースから削除したパッケージの pacman キャッシュ内の圧縮されたパッケージを掃除できます。

最近削除したパッケージを再インストールすることがなさそうな時にだけこのコマンドを使うようにしてください。このコマンドを実行した後にパッケージを再インストールしても、pacman キャッシュにパッケージの古いバージョンは残っていません。

/var のディスク容量が逼迫している時は、fduparch.sh script を使って全ての圧縮パッケージを home ディレクトリに移してください。fduppkg script では pacman キャッシュアーカイブの最後にインストールしたバージョンだけが home ディレクトリに移動されます。

不安定になるパッケージアップグレードを戻す

特定のパッケージアップグレードでシステムが不安定になる場合は、以下のコマンドを使ってローカルの pacman キャッシュから最後の安定していたバージョンのパッケージをインストールしてください:

pacman -U /var/cache/pacman/pkg/Package-Name.pkg.tar.gz

古いパッケージの取得について詳しくは Downgrading Packages (日本語) を見て下さい。

パッケージを戻した時は、パッケージのアップデートの問題が解決されるまで、一時的にパッケージを pacman.conf の IgnorePkg セクションに追加してください。必要ならば、Arch wiki を参照したりフォーラムを使ったりバグレポートを送って下さい。

インストールしたパッケージのリストの定期バックアップ

定期的に、インストールしたパッケージのリストを作成して USB スティックや外部ハードドライブなどのオフラインメディアにコピーしてください。以下のコマンドでパッケージリストを作成します:

pacman -Qqe | grep -vx "$(pacman -Qqm)" > /path/to/chosen/directory/pkg.list

致命的なシステムの問題が発生して完全に再インストールする必要があるときに、以下のコマンドを使って素早くパッケージを再インストールできます:

xargs -a /path/to/chosen/directory/pkg.list pacman -S --needed

pacman データベースの定期バックアップ

以下のコマンドを使ってローカルの pacman データベースをバックアップできます、クローンジョブとして実行することもできます:

tar -cjf /path/to/chosen/directory/pacman-database.tar.bz2 /var/lib/pacman/local

バックアップした pacman データベースファイルは USB スティックや外部ハードドライブ、CD-R などに保存してください。

pacman-database.tar.bz2 ファイルを / ディレクトリに移動して以下のコマンドを実行することで pacman データベースをリストアできます:

tar -xjvf pacman-database.tar.bz2

pacman のデータベースファイルが壊れていたり、バックアップファイルを作っていなかったときでも、pacman データベースを復旧する望みはまだあります。How To Restore Pacman's Local Database を参照してください。

Systemd による自動化

Systemd (日本語) の設定によって、新しいパッケージがインストール・アップデートされるたびに pacman データベースをバックアップすることができます。ここを見て下さい。

一般的なベストプラクティス

NVD/CVE を購読してセキュリティアラートが出たらアップグレードする

National Vulnerability Database による Common Vulnerabilities and Exposure を講読する。インストールしたパッケージのセキュリティアラートが出された時にだけ Arch システムをアップデートします。

これは頻繁にシステム全体をアップグレードするのとは異なった方法です。様々なパッケージのセキュリティ問題を迅速に解決しつつ、安定した設定で他の全てのパッケージを凍らせておくことができます。ただし、どのパッケージをアップグレードすべきか知るために頻繁に CVE アラートを見るのは退屈で時間の取られることかもしれません。

本番環境で行う前にアップデートをテストする

可能であれば、設定ファイルの変更だけでなく、ソフトウェアパッケージのアップデートも、まず本番環境でない複製したシステムでテストしてください。それから、問題が起こらなかったら、本番環境に変更をロールアウトしてください。

設定ファイルは編集する前にバックアップする

設定ファイルを編集する前に、その設定ファイルのちゃんと機能するものをバックアップします。設定ファイルの変更によって問題がおこったときに、前の安定した設定ファイルに戻すことが可能になります。テキストエディタでファイルのバックアップコピーを保存するか、以下のコマンドを実行:

cp config config.bak

.bak を使うことで pacman が .pacnew, .pacsave, .pacorig ファイルを作成したときでも目で区別できるでしょう。

/etc, /home, /srv, /var ディレクトリの定期バックアップ

/etc, /home, /srv, /var ディレクトリにはシステムの重要なファイルと設定が含まれているので、定期的にこれらのフォルダのバックアップを作るのが懸命でしょう。以下はこれを行うためのシンプルなガイドです。

  • /etc: root やクローンジョブで以下のコマンドを実行することで /etc ディレクトリをバックアップします:
tar -cjf /path/to/chosen/directory/etc-backup.tar.bz2 /etc

/etc のバックアップファイルは USB スティック、外部ハードドライブ、CD-R などのオフラインメディアに保存してください。時にはオリジナルのファイル・ディレクトリとバックアップを比較してバックアップの整合性を確認してください。

壊れた /etc ファイルを復旧させるには、まず etc-backup.tar.bz2 ファイルを一時的な作業ディレクトリに展開して、それから必要なファイルやディレクトリをそれぞれ上書きコピーします。root で、以下のコマンドを実行して下さい:

tar -xvjf etc-backup.tar.bz2
  • /home: 定期的に、/home ディレクトリを外部ハードドライブ、NAS、またはオンラインのバックアップサービスにバックアップしてください。時にはオリジナルのファイル・ディレクトリとバックアップを比較してバックアップの整合性を確認してください。
  • /srv: サーバーをインストールすると /srv ディレクトリが作られるので定期的にバックアップしてください。
  • /var: /var 下の /var/spool/mail や /var/lib などのディレクトリもバックアップが必要です。

バックアップを素早くしたい場合は (並列圧縮、SMP を使う)、pbzip2 (Parallel bzip2) を使って下さい。手順はほとんど変わりません。

まずファイルを圧縮のないプレーンの tarball にバックアップします:

tar -cvf /path/to/chosen/directory/etc-backup.tar /etc

それから pbzip2 を使って並列で圧縮します (pbzip2 を pacman -S pbzip2 でインストールしておいてください):

pbzip2 /path/to/chosen/directory/etc-backup.tar.bz2