Linux をインストールする際に、まず最初に悩むのは、パーティションではないかと思います。パーティションは、日本語訳としては「区画」と呼ばれます。誤解を恐れずに言えば、パーティションは、Windows で言うところのドライブに相当する、といえます（厳密には異なります）。
パーティションを作成する際には、容量を指定することになります。この容量の設定に悩まされることは少なくありません。見積もりを誤って、少ない容量を指定すると、動作しなくなるおそれがありますし、一方で大きすぎる容量を割り当てても、宝の持ち腐れとなってしまいます。
このパーティション、Linux 独自のもの、というわけではありません。Windows にもパーティションは存在します。パーティション自体は、Windows も Linux も同じように作成されますが、その内部構造が異なるため、パーティション ID というもので、中身が何であるかを判断するようになります。このため、Windows では、Windows で使われるパーティション ID 以外のものについては、無視をするようになっています。Windows と Linux を Dual Boot(二重起動) に設定した場合、Windows 起動時に Linux の存在が見えないのは、このためです。Linux は柔軟なシステムのため、Windows の使うパーティション ID のものの、中身を参照することができるようになっています。
さて、パーティションの容量に戻ると、どう設定するのが良いのでしょうか？これには、一定の解は存在しません。その方の使い方次第で、最適解は異なってくるからです。とはいえ、これではパーティションの容量を決定することなどできませんので、一つの道筋だけは立てます。
それは、「どう分ければよいか分からないときは、全容量を一つのパーティションにする」ということです。Windows でも、搭載されているハードディスク(HDD) が、すべて Ｃ ドライブとなっているものが少なくありません。これは、個々に最適な分割を見つけることができないため、単一のパーティションとしていることに他なりません。必要があれば、ユーザーが改めてパーティションを分割すれば良い、という考え方でもあるわけです。
ただ、全容量を単一のパーティションとすることは、一つの危険性ももたらします。それは、パーティションの崩壊＝データの喪失、ということです。パーティションが壊れてしまった場合に、パーティション内に存在したデータは、特別な方法を使わなければ、データを取り出すことができません。システムとデータを別のパーティションに分けておけば、万一システムのパーティションが壊れてしまった場合にも、データのパーティションは安全に保つことができます。そういった意味では、最低限システムをおくパーティションとデータをおくパーティションは、分割しておくべき、といえます。
Windows では、データの保存先は マイドキュメントフォルダが初期設定されています（アプリケーションによっては、この初期設定を利用しないものもあります）。Linux では、ユーザーのデータは、基本的にホームディレクトリと呼ばれる、それぞれのユーザー専用のディレクトリに保存されます。この各ユーザーにとってのホームディレクトリが作成されるトップが /home となります。なので、個人的には、/home は単独のパーティションを割り当てておきたいところです。なお、データの保存先ということは、どのようなデータを扱うかにより、必要とされる容量が異なってくることになりますので、その容量見積もりには注意する必要があります。一般的な Office データであれば、1GB もあれば十分ですが、サウンド、静止画、動画、などのデータは、消費単位が大きいので、より大きな容量とする必要があります。個人的には、動画を扱う場合には、さらに別のパーティションをマウントするようにすべき、と考えます。
/home 以外のパーティションを、分割せずに一つのパーティションとした場合、どのような問題点があるのでしょうか？これは、Disk Full による、システム起動不能となる問題点です。Windows でもそうですが、Linux でも各種のログが /var というディレクトリに保管されています。このディレクトリは、基本的には増加する一方のため、ログが増加することによって、パーティション内の空き容量が不足し、起動するために必要な空き容量までも食いつぶしてしまう、ということが発生してしまうことがあります。これは、Linux に限った問題ではなく、Windows でも発生するおそれのある問題です。私が経験したものでは、Windows からテキストファイルを印刷しようとしたところ、印刷用のイメージファイルが100倍の容量に膨れ上がり、空き容量をすべて食いつぶしたあげく、Windows がハングアップする羽目になりました。スワップファイルの容量を固定化していたおかげで、起動不能に陥ることは回避されましたが、再起動時に空き容量がわずか 100KB しか残っていないことを知ったときには、顔が青ざめました。
/var に使用させる容量を限定するためには、独立のパーティションを割り当てることが望ましいのですが、どれだけの容量を割り当てればよいか、ということを見立てるには、一定の経験が必要となります。従って、初めて Linux を使おうとする場合には、あえて分割をしないで状況をみるということも必要です。
実際に割り当てる容量としては、次の二つの案があります。使用する HDD の容量を 30GB とします。
(1) /home に 2GB 、残り 28GB を / に割り当てる。 (2) /home に 2GB 、/var に 10GB 、残りを / に割り当てる。
/var に 10GB も割り当てるのはもったいない、と思われるかもしれません。クライアントベースでは、それほど多くのログを取る必要性は少ないかもしれませんが、なくて困るよりは、多少余裕を見て割り当てておいたほうが、安全だと私は考えます。
さて、先ほどから / （スラッシュ）がよく出てきていますが、Linux におけるディレクトリの区切りは、/ が使われます。Windows では \ （円記号、環境によってはバックスラッシュが表示されます）を使いますが、Linux では / となります。Windows でいうところのドライブ名は Linux にはなく、パーティションはディレクトリに接続されるようになります。従って、Linux ではルートディレクトリを頂点にした、単一のディレクトリツリーとなります。このため、使用容量の見立ては、どのパーティションがどれだけ使っているか、を想定することになり、Windows とは見立てが異なりますので、注意が必要です。
[目次へ戻る]Linux をインストールするときに、多くのディストリビューションでは、インストールするパッケージ構成を選択するようになっています。これも最初は戸惑うことと思います。これも使い方に依存するところが大きく、どれが最適とは一口でいうことはできません。ただ、初めて Linux に触る、あるいは触れて間もないというのであれば、すべてのパッケージを一気に導入してしまった方が、良いでしょう。導入するパッケージを選択して、不要なものは入れないということは、たしかに拾得すべきことですが、最初からそれを要求するのは、少々酷な話ではないか、と感じます。ある程度慣れてくると、後からパッケージを導入することも可能になりますが、最初のうちは、一括ですべていれるか、ディストリビューションの初期設定でインストールしてしまった方が良いと思います。
さて、ここまではクライアントとして Linux を使う場合の話です。サーバーとして Linux を使う、特に外部公開する Web サーバーや Mail サーバーとして Linux を使おうとする場合には、すべてのパッケージを導入する方法は、論外です。公開サーバーとする場合には、不要な deamon を起動させていると、それがセキュリティホールとなってしまう危険性があります。サーバー運用の上で必要ではない機能であると、運用時にも注意がおろそかになってしまい、ともすると、入れたままの状態が維持されてしまい、新たなセキュリティホールなどが見つかっていても、対応から漏れてしまうことが生じてしまうためです。
ディストリビューションのパッケージ更新に合わせて、バージョンアップをしていれば、セキュリティホールが見つかっても、大丈夫では？という意見を耳にすることもあります。ただ、これを鵜呑みにすることは、半分危険です。なにかというと、パッケージを更新することで、既存の機能が使用できなくなる危険性があるためです。特に、パッケージのメジャーバージョンが更新されているような場合には、更新情報を確認し、既存の環境に副作用が生じないかを確認した上で、更新をしないと、パッケージをあげた → 機能が使えなくなった、ということさえ、発生しますので、バージョンアップは、かなり負担のかかる作業になります。場合によっては、ディストリビューションのパッケージではなく、配布元のパッケージを独自 build して使う場合さえあります。
それでは、絶対に入れておく必要があるものはなにでしょうか？これにはいろいろな意見はあるでしょうが、私は開発環境は必須インストールだと考えています。開発環境は、kernel の再構築でのみ使用されるわけではなく、ドライバやモジュールのコンパイルなど、いろいろな場面で必要となります。意外なところで開発環境が使われているな、と感じたのは perl のモジュールインストールでした。perl のモジュールは、パッケージをダウンロード後に、コンパイルを行うものがあり、開発環境が入っていないと、モジュールのインストールにも失敗してしまう、ということになります。また、VMware Server では、配付パッケージのインストールはソースのインストールのみで、導入後のスクリプトの実行で、使用するバイナリを作成するようになっており、これも開発環境なしでは、使用できないことになります。このように、直接自分でプログラムを作成しない場合でも、開発環境が必要となることが多くありますので、開発環境は最低限導入しておく必要がある、と私は考えています。
[目次へ戻る]Linux を導入したいが、マシンが一台しかない、という場合、Dual Boot を行わざるを得ないわけですが、Linux から Windows のパーティションを操作することができてしまうため、誤った操作で、Windows 側にダメージを与えてしまうことになるので、お勧めはしません。
現在では、VMware Server や Virtual PC などの仮想環境が無償で入手できますので、Linux を初めて試す場合には、これらの仮想環境を構築して、その上で Linux をインストールしてみることをお勧めします。仮想環境内であれば、事実上の Single Boot になりますので、実機が１台でも２台以上のマシンがあることと同様になります。
Dual Boot の盲点となりがちなことに、Windows でパーティション操作を行ってしまい、Linux が起動不能になる、ということがあります。ブートローダに lilo を使っている場合、HDD 上の物理位置を記録しているため、パーティションの位置変更などを行うと、kernel を読み出せなくなります。ブートローダとして grub を使っている場合は、ファイルシステムを理解するため、パーティションを移動しても、起動不能になることはありませんが、パーティション番号を変更するようなことがあると、設定変更を行う必要は生じます。
[目次へ戻る]Windows を使っている分には、その存在をあまり気にする必要はありませんが、Linux を使うようになると、選択肢が複数あることから、一気に注目することになります。Windows にもブートローダは存在しています。Windows 2000 以降は OS Loader と呼ばれるものがそれで、通常はあまり意識する必要はありません。
Linux におけるブートローダは、古くから使われているものに lilo (LInux LOader) と grub があります。lilo は、かなり古くからあるブートローダで、多くのディストリビューションで使われていました。現在は grub を使っているディストリビューションが増えています。
lilo の特徴は、kernel を読み込む際に物理番地にて直接読み込む方法を取っている、ということに付きます。これは、kernel の物理位置が変更となった場合に、lilo の再設定が必要になる、ということです。ファイルシステムを理解するわけではないので、kernel を納めているパーティションの番号が変わない場合であっても、他のパーティションの容量変更により、パーティションの使用している物理位置が変化すると、lilo が kernel を見つけられず、Linux の起動に失敗することことことなります。反面、ファイルシステムがクラッシュしている場合であっても、kernel を物理的に読み込みできれば、起動できる、ということになります。とはいえ、Windows に慣れた身には、少々扱いにくい側面があるといえます。
grub の特徴は、ファイルシステムを理解している、というところにあります。このため、grub は、起動時に設定ファイルを再読込し、lilo のように、事前にコマンドを実行して環境設定を lilo に埋め込む必要はなくなっています。さらにありがたいことに、grub の shell において、キー入力が可能となっており、設定に誤りがあって、起動できなくなったとしても、grub の shell から、正しい設定を打ち込むことで、起動可能になります。自由度が高いブートローダともいえます。
インストール時点で、grub が選択できる場合は、grub を選択しておくと良いですが、lilo しかない場合は、素直に lilo を導入しておきましょう。Vine Linux のように、grub のパッケージを別に用意しておいて、後から更新できる場合もあります。
ブートローダの存在を意識するのは、kernel に変化をあたえた時です。kernel の変化とは、大きくわけると、kernel の再構築と kernel のアップグレードになります。kernel 再構築を行うと、再構築後の kernel の物理位置が変化することになるため、lilo を使っている場合には、再度 lilo に設定内容を書き込む作業(/sbin/lilo)を行う必要があります。kernel 再構築を行っても、新たに組み込んだ機能が有効になっていない、という場合には、lilo の実行し忘れが考えられます。なお、再構築した kernel のファイル名は、現在使用しているものと同じにしてはいけません。万が一、再構築の失敗により、元に戻る必要が生じた場合に、元に戻れなくなります。かつて、新しい kernel の再構築を行うため、現行の kernel source を削除したところ、その時インストールされていた kernel ではネットワークはもちろん、CD-ROM も使えない状態となっていて、新たな kernel source を取り込むことができない、という状態に陥りました。これは極端な例かもしれませんが、再構築した kernel で問題なく動作することを確認するまでは、純正の kernel は残しておきましょう。また、kernel をアップグレードすれば、ファイル名が変更されますので、lilo だけでなく、grub にも設定変更が生じます。
[目次へ戻る]そんなことはありません。ただ、ネットワークがあったほうが、Linux を使うメリットが増えますので、使えるに越したことはありません。出先で、ネットワークが利用できない場合などでも、通常の使用は可能です。
ただ、一部のディストリビューションにおいて、ネットワークデバイスが有効で、かつ、ネットワークへの接続がなされていない場合に、再ログオンしないと、日本語変換機能(IM) が利用できない、という場合がありました。初期設定で、ネットワークデバイスを起動時に有効にしなければ良いのですが、自宅で使用する場合に、ネットワークを手動で有効にしなければならないため、手間が増えるという弊害が生じます。どちらが多いか、によって、対応するしかありません。
[目次へ戻る]Linux においても、GUI が大分利用可能になっています。以前からすれば、大分コマンド入力を求められることは少なくなってきています。とはいえ、コマンドを使えるようにすることで、GUI で行うよりも、容易に操作できるものもありますので、覚えておくことをお勧めします。Windows ユーザーでも、熟練者は、デスクトップにコマンドプロンプトへのショートカットがあったり、タスクバーにコマンドプロンプトがあったりします。
[目次へ戻る]Linux は、そもそもは kernel だけの存在です。このため、Linux を使おうとすると、kernel の Linux だけでは不足し、ブートローダから、基本的なコマンド類（X Window Systemを含む）をそろえなくてはなりません。これは、結構面倒な作業です。このため、Linux では、基本的なコマンドをセットにしたディストリビューションというものが用意されています。
ディストリビューションは、どのような構成にするかは、ディストリビューションを作る人（これをディストリビュータと呼びます）の考えに一存されます。あるディストリビューションを元に、新たなディストリビューションを作成することも可能です。
Linux における代表的なディストリビューションには、Redhat 、debian 、SuSE 、Slackware などがあります。これらをベースにして派生したディストリビューションとして、Fedora Core(Redhat系)、Vine Linux(Redhat 系)、KNOPPIX(debian系)、OpenSuSE(SuSE系)、Plamo Linux(Slackware 系)などがあります。なぜこのように区別するかというと、元となるディストリビューションによって、設定ファイルの位置や、コマンドを保管するディレクトリ配置などが異なるため、設定を変更しようとする際に、頭を悩めることになります。正直、私は debian 系のディストリビューションは、設定ファイルを変更することができません。
なお、上記の分類で FedoraCore を Redhat 系としていますが、そもそも、Redhat の公開ディストリビューションの後継が FedoraCore であることからすれば、FedoraCore も一つの系統として示すべきかもしれません。現時点で、FedoraCore をベースにしたディストリビューションとして、BerryLinux があります。また、Vine Linux は Redhat をベースとはしていますが、Fedora Core ベースではなく、独自の進化の道をたどっているので、厳密な意味では Redhat 系に分類すること自体、無理があるかもしれません。上記の分類は、私の中で行っているものであり、一般的に層呼ばれていることを保証するものでははありません。
[目次へ戻る]Linux には、もともとはパッケージ管理システムが存在していませんでした。流通するソースファイルは、tar というアーカイバにより一つにまとめられ、gzip による圧縮をされていたため、その拡張子に tar.gz が用いられました。最近は、tar.bz2 という拡張子を持つものが登場していますが、圧縮プログラムに bzip2 を用いたものです。なお、tar.gz 形式となっているものを、tarball（たーぼーる、たー玉とも）と呼ぶこともあります。余談ですが、Windows の zip や lha などをアーカイバと呼んでいるのは、複数のファイルをまとめる機能を持つためであり、本来のアーカイブの意味には、圧縮は含まれていなかったことは、予備知識として知っておくと良いです。なぜなら、tar のバージョンによっては、gzip を呼び出す機能を持っていないものがあり、gzip の圧縮を解いてから、tar で分割することが必要となる場合があるためです。
tarball での流通は、ソースを自前でコンパイルすることが当然とされた時代にはそう問題ではなかったのですが、使われるプログラムが増加していくとともに、次第にバージョン管理する方法が必要となってきました。その結果として、パッケージ管理システムが登場してきました。このパッケージ管理システムは、ディストリビューションによって異なりますが、大きくは前述した元となるディストリビューションによって、決定されます。Redhat 系は RPM 、debian 系は dselect 、というパッケージ管理システムが登場しました。
debian の dselect は、あまりユーザーに優しくなかったため、バックエンドでは dselect の機能を使い、フロントエンドを担当する APT(Advanced Packaging Tool)が登場しました。APT の登場により、debian のパッケージ管理のしやすさは飛躍的に増加し、その利便性の火の粉は、RPM にも飛び火しました。その結果、バックエンドを RPM にした APT for RPM が登場するまでにいたりました。なお、debian には、alian という rpm ファイルを deb ファイルに変換するツールも登場しており、非常に広い受け口があります。
rpm ファイルには、.i386.rpm のような形式と .src.rpm という形式があります。前者はコンパイル済みのファイルで後者はソースファイルとなっています。コンパイル済みのものは、rpm -ivh コマンドですぐに導入できるのですが、rpm ファイルを作成した環境に依存するため、rpm ファイルを作成した環境と異なる場合には、単純にインストールできない場合があります。特に、同じ Redhat 系だからと、Fedora Core 用の rpm を Vine Linux に入れようとした場合に、依存関係などの問題から、そのままは入らないということが、往々にしてあります。.src.rpm ファイルを入手して、rebuild できれば、動く可能性は高いです。
なお、SuSE や Gentoo などでは、また別のパッケージ管理システムを使用しています。ディストリビューションが新たに登場する場合に、新たなパッケージ管理システムが登場する可能性は高いです。
Last Update is 2006/10/07. CopyRights Tazoe Kazuya 2006.