Linuxにソフトウェアをインストールする際にやってしまいがちな失敗10選

　Linuxにソフトウェアをインストールするという作業には、かつてほどではないものの、注意すべき落とし穴がまだいくつか存在している。しかし、本記事で紹介している項目を参考にすることで、あなたのLinuxライフはよりシンプルで安全なものとなるはずだ。

＃1：.rpmや.debを採用しているシステムにもかかわらず、ソースコードからイントールを行う

　Linux初心者の中には、OS上にインストールされるすべてのアプリケーションが、rpmやapt（あるいはdpkg）といったパッケージ管理システムによって管理されるということすら知らない人も多い。とは言うものの、こういったシステム（rpmやapt、dpkg）が管理できるものは、当該システムを用いてインストールしたアプリケーションに限られるのである。このため、ソースコードだけが提供されているようなアプリケーションを入手し、自分自身でコンパイルしたとしても、パッケージ管理システムはそれらを管理してくれないのだ。このようなインストール方法を採用するのではなく、ソースから.rpmファイルや.debファイルを作成し、パッケージ管理システムを用いてそのパッケージをインストールすることで、インストールされているものすべての管理をパッケージ管理システムに任せることができるようになるのである。

＃2：パッケージ管理システムのGUIフロントエンドアプリケーションを使用しない

　ほとんどの人は、Linuxのパッケージインストール時に、さまざまな当て推量をしなくても済むようにしてくれるGUIフロントエンドが存在しているということを知らない。yum（rpm用のコマンドラインパッケージ管理システム）の場合、Yumex（「yum install yumex」というコマンドでインストールできる）を利用することができる。また、aptの場合にはSynapticもしくはAdeptを利用することができる（それぞれ「apt-get install synaptic」と「apt-get install adept」というコマンドでインストールできる）。

＃3：利用可能なパッケージ一覧のアップデートを忘れる

　apt-getやyumを使用する際には、利用可能なパッケージ一覧のアップデートを忘れないようにしよう。さもなければあなたのシステムにおけるインストール済みパッケージは、最新版がリリースされてもアップデートされないことになってしまう。apt-getの場合、アップデートは「apt-get update」というコマンドを用いればよい。また、yumの場合には「yum check-update」というコマンドを用いればよい。

＃4：yumやapt-getへのリポジトリ追加を行わない

　yumとapt-getはともに、利用可能なパッケージの場所を知るためにリポジトリリストを使用するようになっている。しかし、デフォルトのリポジトリ（しばしば「レポ」と呼ばれる）には、Linuxのありとあらゆるパッケージが含まれているわけではないのだ。このため、あなたがアプリケーションのインストールを行うコマンドを実行した時に、yum（あるいはapt-get）がそのパッケージを見つけられなかった場合、リポジトリをソースリストファイルに追加することになるはずだ。ソースはyumの場合には/etc/yum.confに、apt-getの場合には/etc/apt/sources.listに記述されている。新規リポジトリを追加したのであれば、アップデートを実行して、aptあるいはrpmが新たなソースを認識できるようになったことを確認してほしい。

＃5：ブラウザからのインストールを利用しない

　Windowsの場合と同様に、ユーザーがインストール可能なアプリケーションをダウンロードしようとするとOSによってそのことが検知され、該当ファイルをパッケージ管理システムにインストールさせるのか、それともディスクに保存するのかを尋ねるダイアログボックスが表示される。いずれの場合にも、rootパスワードの入力が要求されることになる（つまり、この操作を行うにはrootパスワードが必要となるのだ）。私がこの方法で気に入っているのは（yumベース、あるいはdpkgベースに関係なく）、ほとんどの場合に依存関係の検出と追加が正しく行われるという点である。

　この方法は当然のことながら、対象OSに適用可能なファイルをダウンロードしようとした場合にのみ動作するようになっている。Debian系のシステムにrpmファイルをダウンロードしようとしても、そのファイルをインストールするという選択肢はないのである。

　このステップをさらに推し進め、Firefoxが表示するダイアログボックス上の「Always Do This...」チェックボックスをチェックしておくことで、パッケージ管理システムに関連付けられたファイルをダウンロードするたびに、rootパスワードを尋ねるダイアログボックスが自動的に表示され、パッケージのインストールに進むことができるようになる。これによって、インストールプロセスの効率を少し向上させることができるわけだ。

＃6：コマンドラインの存在を忘れてしまう

　あなたは、UbuntuやDebianのヘッドレスサーバ（Linuxにおける一般的なサーバ設定である）をインストールしたところであると考えてほしい。そしてまだ、GUIのインタフェースやデスクトップをインストールしていなかったとしよう。こういった場合にメンテナンス作業を行うには、sshを使ってログインし（telnetを使ってログインする管理者などいないのだ）、コマンドラインのみを使うという制約が課されることになる。そういう場合であっても、OSを最新の状態に保ったり、新たなアプリケーションをインストールしたりする作業に制約が課されることはないのだ。というのもyumやapt-getを用いてパッケージ管理を行うことができるからである。

　Debianベースのシステムでは、aptitudeというもう1つの選択肢も存在している。コマンドラインから「aptitude」というコマンドを実行すると、Cursesベース（キャラクターとエスケープシーケンスを用いたCUI）の優れたapt用インタフェースが使えるようになる。このシステムは使いやすく、GUIの無いサーバにおいてすべての管理機能にアクセスできる素晴らしい選択肢となる。aptitudeはセキュリティアップデートやアップグレード可能なパッケージ、新しいパッケージ、まだインストールされていないパッケージ、陳腐化したパッケージ、仮想パッケージ、タスクを一覧で表示してくれる。こういった一覧をスクロールしていくと、インストールされているパッケージと、新たにリリースされたパッケージのリリース番号の対比だけでなく、パッケージの説明も表示されていることが判るはずだ。aptitudeを使うことで、Linuxパッケージのアップデートは、コマンドラインからであったとしてもとても簡単になるのだ。

＃7：手当たり次第にtarファイルを展開する

　私自身、tarファイルとして提供されているソースパッケージをダウンロードし、その内容を調べることなく考えなしに展開したことが何度もある。たいていの場合は、これで問題が発生するようなことはない。しかし、パッケージの作成者／管理者が、パッケージのコンテンツすべてを1つのディレクトリにまとめることを忘れている場合もあるのだ。そういった場合、tarファイルのコンテンツ（何百という数のファイルやディレクトリ）を格納したディレクトリが新たに作成されるのではなく、tarファイルの展開作業を行っているカレントディレクトリにそれらのファイル群が展開されるのである。

　こういったことを避けるために、私はいつも一時ディレクトリを作成し、tarファイルをそのディレクトリ内へと移動させることにしている。そして、そのディレクトリ内でtarファイルの展開を行うようにすれば、そのコンテンツが独立したディレクトリに格納されていようがいまいが関係なくなるのだ。この方法を用いることで、tarファイルの作成者がすべてを1つのディレクトリにまとめていなかったとしても、後始末に追われるという事態を避けることができるのである。

＃8：Makefileを削除してしまう

　ソースからインストールを行う場合、あなたは不要なソースファイルをすべて削除するために「make clean」コマンドを実行することになるはずだ。しかし、Makefileを削除してしまうと、アンインストールは骨の折れる仕事になるのである。Makefileを残しておけば、通常はそれが格納されているディレクトリから「make uninstall」コマンドを実行するだけで、プログラムのアンインストールを行うことができる。ただし、ここで忠告しておくことがある：すべてのMakefileを1つのディレクトリにまとめてしまうようなことをするべきではない。先にファイル名を変更し、それぞれがどのアプリケーションのものであるかを識別できるようにしておかなければならない。そして、アプリケーションをアンインストールする段階になって、そのMakefileを他のディレクトリへと移動し、元のファイル名に戻してから、「make uninstall」コマンドを実行すればよいのである。アプリケーションをアンインストールした後であれば、そのMakefileを削除することができる。

＃9：アーキテクチャの異なるファイルをインストールしてしまう

　多くのrpmファイルにはi386やi586、i686、PPC、64といった文字列が付加されているということに、あなたも気付いておられるかもしれない。これには理由があるのだ。rpmファイルはファイル名にnoarchという文字列が入っていない限り、特定のアーキテクチャ用に作成されたものなのである。特定のアーキテクチャ用にファイルを作成する理由は、そのようにすることで該当アーキテクチャ向けの最適化を行い、効率的に動作できるようにするためである。このことは、i586と表示されているファイルを標準的な386マシンにインストールできないということを意味しているのだろうか？もちろん、そのようなことはない。しかし、表示されているアーキテクチャで実行させる場合ほど効率的には動作しないだろう。ただし、PPC向けのrpmをx86アーキテクチャのマシンにインストールすることはできない。PPCは、Motorolaのチップセットが採用しているアーキテクチャなのである。また、64ビット用のrpmを32ビットマシンにインストールすることもできない。しかし、32ビット用のrpmを64ビットマシンにインストールすることは可能である（64ビットのマシン上でFirefoxのFlash Playerを利用したい場合にはこういったインストールを行うことになる）。

＃10：カーネルのアップデートに伴う問題への対処が悪い

　カーネルのアップデートは昔、筋金入りのギークが行う作業と相場が決まっていた。ところが今は違う。新しいパッケージ管理システムのお陰で、誰でもカーネルをアップデートできるようになっている。しかし、知っておくべき落とし穴がいくつかあるのだ。まず、スペースの問題である。カーネルのアップデートではすべて、古いカーネルが保存されるようになっている。このため、カーネルのアップデートを何度も行うと、システム領域があっという間に使い果たされてしまうことになりかねない。削除できる古いカーネルがあるかどうかを必ずチェックするようにした方がよいだろう。あなたがrpmを使用しているのであれば、「rpm -qa | grep kernel」というコマンドを実行することで、インストールしてきたカーネルを確認することができる。直近にインストールした2つを除く、その他すべてのカーネルは削除しても構わない。現在使用しているカーネルに致命的な障害のあることが判った場合に備えて、現在使っているカーネルとその1つ前のバージョンのカーネルを保存しておくだけで十分だろう。

　もう1つ別の落とし穴にNvidiaのドライバに関するものがある。あなたがLivnaリポジトリを使用しているのであれば、Livnaのカーネルリリースに縛られてしまっているはずだ。これは望ましくない状況だろう。こういったことを避けるために、次のように2段階に分けてインストールを行うことをお勧めする：まずカーネルをアップデートしてから、そのカーネルに対応しているNvidiaのドライバをダウンロード、インストールするのである。この方法では適切なNvidiaのドライバ（rpmファイル）を自分で検索しなければならないものの、Livnaのカーネルを使用しなくても済むようになる。私も過去に、Livnaに縛られたことがあり、カーネル／ビデオが引き起こす摩訶不思議な問題に悩まされたことがある。こんなことは避けるべきだろう。もちろん、あなたがUbuntuシステムを使用しているのであれば、Envyを利用することでNvidiaにまつわる問題から解放されるだろう。この便利なツールを用いることで、あなたの愛用しているカーネルを台無しにすることなく、最適なNvidiaドライバのインストールが行えるようになるのである。

　そして、これは当たり前のことだが、カーネルをアップグレードした後は再起動を忘れないようにしなければならない。これはLinuxマシンを再起動「しなければならない」という限られた状況の1つなのである。あなたのマシンは再起動しなくても正常に動作し続けるだろうが、それは古いカーネルで動作しているのであり、新しい機能やセキュリティ対策（あるいは新しいカーネルが提供するすべてのもの）の恩恵を受けている状態にはないのである。