HOMELinux道場Linux豆知識

Linux豆知識

このページでは、Linuxを学習する上で出てくる素朴な疑問や、便利なテクニックなどを紹介しています。
記載内容は記事執筆時のものであり、変更になっている場合があります。

Linuxに感染するウィルス

今回は、「Linuxに感染するウィルス」について。

書籍などを見ると、「Linuxに感染するウィルス（不正プログラム）は少なく、Linuxは安全だ」のように書かれていることがあります。

たしかに、デスクトップ用途でのLinuxはシェアが低く、またLinuxにはパーミッションという概念があり、root権限（管理者権限）なしにシステムを改ざん・破壊することは困難です。SELinuxのようなセキュリティを守る仕組みもあり、「Linuxはウィルスに感染しにくい」とも言えます。

しかし、油断することはできません。「Linuxに感染する不正プログラムは少ない」という情報は古い情報と言えます。デスクトップ用途でのLinuxのシェアが増えるにつれ、Linuxをターゲットとしたウィルスも増加傾向にあることが、セキュリティ企業から報告されています。また、セキュリティホールを突いて感染を試みる不正プログラムも存在するため、少なくとも「まったく無関心で良い」とは言えない状況になりつつあります。

なお、サーバ用途の場合は、不正プログラムには最大限の注意を払う必要があります。外部からアクセス可能なサーバソフトウェアの中にはroot権限で動作しているものもあり、セキュリティホールを突かれることによってroot権限を奪取されてしまう危険があります。また、メールサーバやファイルサーバとして利用する場合、Linuxに感染しなかったとしてもクライアントにメールが届く前にウィルスを除去するのが望ましいと言えます。

Linux向けにも、「Clam AntiVirus (ClamAV)」などのアンチウィルスソフトウェアが提供されています。Linuxを本格的に利用する際には、セキュリティ施策ソフトウェアの導入も検討して下さい。

インデックスに戻る

人工知能（AI）

「人工知能」あるいは「AI」という言葉は、ITに詳しくない人の口からもよく耳にするようになりました。そこで今回は「人工知能」（Artificial Intelligence）とは何かを簡単に紹介します。

「人工知能」とはそのまま「人工的な知能」と言えますが、何をもって「知能」と呼ぶのかが問題になります。実はここで「知能」が指すものは多々あり、時代背景によってもその指すものの内容は変わってきます。現在、「人工知能」が指すものは「機械学習」や「深層学習」であることが多いようです。「機械学習」では、大量のデータを基にコンピュータが学習を行います。そして、その結果を基にコンピュータが何らかの作業を行います。一番わかりやすい例としては、Webなどで表示される広告があります。Webブラウザを操作する人が何に興味を持っているのかをコンピュータが学習し、その人が興味を持ちそうな分野の広告が表示されることが、最近では当たり前になってきましたね。これも機械学習の成果です。

ただし、人工知能も万能ではありません。現在実現しているのは「特化型人工知能」と呼ばれているもので、たとえば広告を表示するであるとか、個人の顔を認識させる（顔認証など）など、ある用途に特化させた人工知能です。あらゆる目的に対して学習した成果を反映させ、適切に運用することができる「汎用人工知能」は未だ実現からは遠いというのが現状です。

ここで紹介したものは人工知能の簡単な説明ではありますが、「人工知能は何か凄いもの」「将来人間の仕事を全て奪ってしまうもの」のような認識では技術者として良いことではありません。幸いなことにAIに関わるソフトウェアはオープンソースになっているものが多く、Linux上で動作させることができます。簡単なものであればRaspberry Piのような安価なコンピューターを使って試すこともできますので、是非、もう少し突っ込んだ勉強をしてみて下さい。

インデックスに戻る

情報の古さ

今回は、「情報の古さ」ということを考えてみたいと思います。

コンピュータの情報革新のスピードは非常に早く、オープンソースやLinuxの世界も例外ではありません。それゆえ、勉強をする上では、いま目の前にある情報がどれだけ新しいものか？ということを確認することは大切なことです。

たとえば、Red Hat系のLinuxディストリビューションに「serviceコマンド」というコマンドがあります。Webサーバーなどのサービスの起動や停止を行うコマンドですが、本稿執筆時点(2019年5月)でRed Hat系最新のディストリビューションである「Red Hat Enterprise Linux 7」（RHEL7）では、サービスの起動や停止はserviceコマンドに代わって「systemctlコマンド」というコマンドが採用されています。これは新たにsystemdが採用されたことに伴うものです。では、serviceコマンドについての知識が不要かというと、必ずしもそうとは言えません。systemdではなくSysV init・Upstartで動作しているシステムも沢山あるからです。互換性の観点から、RHEL7ではserviceコマンドやsystemctlコマンドの命令に置き換えられて実行されます。

一方、ブートローダに「LILO」というものがあります。以前はブートローダといえばLILOで、数多くのディストリビューションに採用されていました。しかし、現在ではGRUBが使われており、LILOはほとんど使われていません。ほとんどの場面で「LILOのことはもう知らなくてもよい」と言えます。非常に限られた場面で必要になる可能性がないわけではないのですが、少なくとも最初にLinuxの学習を行うというときにはLILOのことはもう勉強する必要はないと言えます。

「情報の古さ」には、単に「この情報はもう古い」だけではなく、「この情報はもう使われていない」「この情報は最新とは言えないがまだ使われている」「この情報は最新」のように、ある程度段階があるということを認識しておきましょう。

インデックスに戻る

unameコマンド

unameコマンドは現在使用しているカーネルのバージョンなどについて調べるためのコマンドです。

unameコマンドは、すべての情報を表示したい場合には-aオプションをつけて実行します。

$ uname -a
Linux localhost.localdomain 3.10.0-862.11.6.el7.x86_64 #1 SMP Tue Aug 14 21:49:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux

シェルスクリプトの中で特定の情報だけ取り出したいような場合にはオプションによって表示する項目を絞り込むことができます。代表的なオプションを確認しておきましょう。

-r：カーネルのバージョンを表示します
-n：ホスト名を表示します
-p：プロセッサの種類を表示します。

unameコマンドは単純な動作環境の確認から、動作しているシステムによって挙動を変更したいシステム管理用のシェルスクリプトの中で使用など、幅広く活用できるコマンドです。表示の意味とオプションを覚えておきましょう。

インデックスに戻る

netstatコマンド

今回は「netstatコマンド」について解説します。
netstatコマンドは各種ネットワークの状況を確認するためのコマンドです。

オプションを付けずに実行すると、現在通信を行っている状況をすべて表示します。ただ、TCPだけでなくUNIXソケットと呼ばれるローカル通信についても大量に表示されるなど、あまり実用的ではありませんので、情報を絞り込むためのいくつかの主要なオプションを紹介します。

・-tオプション
TCP通信のみを表示します。

・-uオプション。
UDP通信のみを表示します。

・-lオプション
LISTEN状態を表示します。UDP通信はこのオプションと組み合わせる必要があります。

・-nオプション
ホスト名、ポート番号等を数値で表示します。

・-rオプション
ルーティング情報を表示します。

ネットワークの通信状況は目に見えにくいため、トラブル解決にはnetstatコマンドのようなツールを使って確認できる必要があります。各オプションの動作についてしっかりと把握しておきましょう。

インデックスに戻る

Linuxファイルシステム

2018年12月現在、Linuxでは「ext4」というファイルシステムが主流となっています。その他にも「ext3」「XFS」「Btrfs」などのファイルシステムもありますが、多くのディストリビューションが「ext4」をデフォルトのファイルシステムとしていますが、最近「Btrfs」を採用するディストリビューションが増えています。

「Btrfs」は、障害に強い、独自の修復機能を持つ、管理が容易などの特徴を持っています。Linuxカーネルが最初に「Btrfs」をサポートしたのが2009年。それから10年の間、改良を積み重ねてきました。当初と比べだいぶ安定性が向上したことも採用の理由でしょう。

当然というべきか、ext4もまだまだ広く使われているファイルシステムです。様々なファイルシステムがそれぞれ個性を持っていますので、特に大規模なシステムを構築する、信頼性の高いシステムを構築する必要があるなどの場合には、ファイルシステムの選択にも気を配る必要があることは覚えておきましょう。

インデックスに戻る

Linuxカーネルのバージョン番号

今回は、Linuxカーネルのバージョン番号について。

Linuxカーネルには、「Linux 4.19.0」のようにバージョン番号がついています。この番号が大きいと新しいカーネルということになります。このLinuxカーネルのバージョン番号の付け方のポリシーは、2011年に発表された「Linux 3.0」から変更になっており、少し注意が必要です。「Linux 3.0」以前は、「Linux 2.4.39」のような番号付けにおいて、1つ目の「2」がメジャー、「4」がマイナー、「39」がメンテナンスナンバーとなっており、特にこのマイナーナンバーが奇数の時は「開発版」、偶数の時は「安定版」という使い分けがなされていました。そして、大きな節目の変更ではマイナーバージョンが繰り上がり、それ以外のときはメンテナンスナンバーが繰り上がるというイメージで番号が更新されていました。

「Linux 3.0」以降は、まず、「開発版」と「安定版」の使い分けがなくなりました。そればかりではなく、1つ目の数値にもさほど大きな意味がなくなりました。簡単に言うと、2015年に「Linux 3.19」の後継バージョンとして「Linux 4.0」がリリースされ、かつ両者の間にはさほど大きな機能変化がなかったという形になったのです。これは、カーネルの開発に携わる人が増え、大きな機能変化が加わる頻度が高くなったことなどが影響していますが、開発者の「大きな番号は避けたい」という意図もあるようです。

なお、3番目の数字（「Linux 4.18.2」でいうところの「2」）は、機能の変化がない、もしくは微小なもので、バグやセキュリティフィクスなどが施されたメンテナンスリリースの際に繰り上がる数字となります。バージョン番号のつけ方も、時代背景と共に変化していくということですね。

インデックスに戻る

「Python」について

今回は、「Python」について。

「Python」は、近年急激にシェアを伸ばしているプログラミング言語です。特長は、シンプルな構文で比較的わかりやすいということ、そして「計算・統計処理で利用するライブラリが充実している」ということなどが挙げられます。後者の特長は最近注目されている深層学習（Deep learning）」に向いたプログラミング言語であるということにつながり、最近のシェア拡大の理由にもなっています。また、PythonはWebアプリケーションの作成にも活用されるようになってきており、Pythonを習得しておけば様々な場面で活用できます。

現在、日本国内でPythonを学習するための書籍などの情報も、以前に比べるとシェアの拡大に合わせて増えてきており、Web経由でPythonを習得するということもできます。システム管理者といえどもプログラミングのスキルは持っていたほうが何かと有利ですので、たとえばPythonを基本レベルまでは学習しておくとよいでしょう。

インデックスに戻る

ARMアーキテクチャ

今回は、「ARMアーキテクチャ」について。

「ARM Holdings」は、プロセッサの開発を手掛けるメーカーです。「ARM」はARM Holdingsによって提供されるアーキテクチャで、組み込み機器やスマートフォン、タブレットPCなどに向けて開発されています。そのシェアは拡大の一途を辿っており、iPhoneやAndroidなどにもARMアーキテクチャが採用されているものがあります。全世界的に家電製品、ゲーム機、医療機器などにも幅広く採用されています。

最近、オープンソースのニュースでもARMアーキテクチャ絡みのものが増えてきていますし、ARMアーキテクチャ向けのLinuxディストリビューションもいくつか現れてきています。ARM向けのLinuxディストリビューションは組み込み用途向けのものが多く、応用範囲も多岐に渡ります。ARMの今後がどのようになるかはわかりませんが、現在ではIntelアーキテクチャのように重要な位置を占めるアーキテクチャとなっていることは間違いありませんので、覚えておきましょう。

インデックスに戻る

/tmpディレクトリ

今回は「/tmpディレクトリ」について。

「/tmpディレクトリ」は、一時的（temporary）なファイルを置くディレクトリです。プログラムが動作する際に一時的に利用するファイルを保存しておくなどの用途で利用します。

このディレクトリは少し特殊な性質を持ちます。まず、システムのユーザであれば誰でも「読み書き」できるようになっています。read権限はともかく、write権限まですべてのユーザに与えられているのは珍しい存在です。
ただし、/tmpディレクトリには「スティッキービット」が設定されており、作成したファイルやディレクトリを削除することができるのは作成者（所有者）だけという特殊な動作をします。そのため、作成したファイルを他のユーザー（プロセス）から削除されてしまうことがないようになっています。

そして、システムを再起動すると、このディレクトリに存在するファイルはすべて消去されます。また、システムによっては一定期間アクセスがないファイルは削除されるようになっている場合もあります。

「/tmpディレクトリ」は、基本的にはプログラムのためのディレクトリで、ユーザが利用するディレクトリとは考えられていません。特に、システム再起動時にファイルが残っていることを前提にすることができませんので、「消えてしまっては困る」というファイルはこのディレクトリには絶対においてはいけません。たとえ一時的に置いておくにしても、意図しない再起動が起こってしまったら消えてしまうことを忘れないようにしましょう。

インデックスに戻る

「/usr/src」ディレクトリ

今回は、「/usr/src」ディレクトリについて。

「/usr/src」ディレクトリには、「プログラムのソースコード」が置かれます。カーネルのコンパイルを行う際に、ダウンロードしたカーネルのソースコードをこのディレクトリの下に配置したことがある、という経験のある方も多いのではないでしょうか。もちろん、Linuxカーネルだけでなく、インターネットなどから入手したソフトウェアをソースコードからコンパイルする場合、このディレクトリに配置することが慣例になっています。

ここで「慣例になっています」という表現を使いましたが、これは要するにソースコードは他のディレクトリに配置することも技術的には問題ないということです。ただし、ソースコードをどこに配置したのかがわからなくなってしまうこともあり得ますし、ソースコードを置くディレクトリを統一しておかないと、バージョンの管理もやりづらくなります。

ファイルも実生活と同じで整理整頓が大切！どこに置いても大丈夫だから適当な場所に置こうなどと考えず、たとえば他のユーザーが管理者としてシステムを見た時に、過去の作業を確認できるよう、慣例に従ってソースコードを適切な位置に置いておくことが望ましいでしょう。

また、最近ではバイナリパッケージでシステムを構成することがほとんどになっているため、カーネルやアプリケーションをソースコードからコンパイルしたことがない、という人も増えています。しかし、いつ何時、コンパイルが求められるか分かりませんので、自分の手でソースコードからコンパイルする方法をきちんと事前に確認しておきましょう。

インデックスに戻る

「/usr/share」ディレクトリ

今回は、「/usr/share」ディレクトリについて。

「/usr/share」ディレクトリには、「アーキテクチャに依存しないファイル」が置かれます。といいつつも、そう言われてもイメージが湧きにくいという方が多いと思いますので、具体的にどのようなファイルが置かれているかを見てみるとわかりやすいです。

一番わかりやすいのは、「マニュアル」です。すなわち、manコマンドで参照できるマニュアルがここに置かれています。このマニュアルは、多くの場合「/usr/share/man」に置かれています。

他にも、ロケールの設定ファイルが「/usr/share/locale」に置かれていたり、各種ライセンス条項が記述されたファイルが「/usr/share/licenses」に置かれています。

何らかのソフトウェアをインストールしたとき、そのソフトウェアに関するドキュメントがここに置かれる場合もあります。そのあたりは「/usr/share/doc」などが主なディレクトリになるでしょう。設定ファイルの雛形があることも多いので、覚えておくと役に立ちます。

このように、/usr/shareディレクトリは、主にドキュメント関係が置かれていることが多いので、必ず覚えておきましょう。

インデックスに戻る

「/lib」「/usr/lib」ディレクトリとライブラリ

今回は、「/lib」「/usr/lib」ディレクトリとライブラリについて。

「ライブラリ」とは、プログラミングを行う際によく利用するパーツをまとめたものです。そして、「/lib」「/usr/lib」ディレクトリは、標準的なライブラリを設置するディレクトリです。

標準的なライブラリは「/lib」や「/usr/lib」に置かれますが、これ以外のディレクトリにライブラリを置くこともあります。この場合、「/etc/ld.so.conf」にライブラリが配置されているディレクトリのパスを記述します(現在では「/etc/ld.so.conf」は「/etc/ld.so.conf.d/」配下のファイルをすべて読み込むという形式になっているので、このディレクトリの中にパスを記述したファイルを置くことになります)。このファイルを編集した場合、ldconfigコマンドを実行し、「/etc/ld.so.cache」ファイルを作成・更新する必要があります。ライブラリを必要とするプログラムは、「/etc/ld.so.cache」ファイルの中からライブラリを探し出すという仕組みになっています。

この作業の流れはLinuC レベル1の主題103の出題範囲となっているので、しっかりと押さえておきましょう。


インデックスに戻る

「/bin」「/usr/bin」「/usr/local/bin」ディレクトリの使い分け

今回は、「/bin」「/usr/bin」「/usr/local/bin」ディレクトリの使い分けについて。

これらのディレクトリには、コマンドやスクリプト、プログラムなどのバイナリファイルが置かれます。ところで、これらのディレクトリはどのように使い分けされているのでしょうか？

まず、「/bin」ディレクトリには、シングルユーザモードでも利用できるコマンドを置きます。逆の言い方をすると、「/usr/bin」や「/usr/local/bin」に置かれているコマンドなどはシングルユーザモードで利用できないということになります。シングルユーザモードは、基本的にOSが壊れて正常に起動できないなど非常時に利用するものですので、「/bin」にはごく基本的かつ非常時に利用するコマンドが置かれることになります。

「/usr/bin」には、「シングルユーザモードで利用しない」かつ「RPMやdebなどのパッケージ管理システムによって、システムに管理されるコマンドやプログラム」が置かれます。非常時に利用するものではないが、システムを構成する重要なコマンドやプログラムはここに置かれることになります。

「/usr/local/bin」には、「シングルユーザモードで利用しない」かつ「RPMやdebなどのパッケージ管理システムによってシステムに管理されないコマンドやプログラム」が置かれることになります。自作のスクリプトなどはこのディレクトリに置くことが一般的です。なお、Linuxディストリビューションをインストールしたばかりのときは、このディレクトリが空であることも多いと思います。

「/sbin」「/usr/sbin」「/usr/local/sbin」のディレクトリも基本的に同じ関係性です。ただし、「sbin」はシステム管理用のコマンドやプログラムを置くディレクトリだという点が「bin」と異なります。

それぞれのディレクトリの使い分け、いいかげんになっていると混乱のもとですので、しっかり区別しておきましょう。

インデックスに戻る

/usr

今回は、「/usr」ディレクトリについて。

このディレクトリは通常「ユーザーディレクトリ」と読みますが、「ユーザーのディレクトリ」ではありません。ユーザーの個人的なファイルは/home配下のホームディレクトリに置くことが通例になっています。このディレクトリは「各ユーザーが共通して利用するプログラムやライブラリなどが置かれるディレクトリ」です。「システムではない」という意味でのユーザーとでも考えれば良いでしょうか。ただし、管理者専用のファイルが置かれている場合もあり、一筋縄ではいかない重要なディレクトリです。

このディレクトリ、サブディレクトリも重要ですのでそれぞれ見てみましょう（ディストリビューションによって若干の差異がある場合もあります）。

--
/usr/bin/　　　　　ユーザが利用するコマンド
/usr/include/　　　ヘッダファイル（C言語で利用）
/usr/lib/　　　　　ライブラリ
/usr/local/　　　　ローカルで管理するファイル
/usr/sbin/　　　　　管理者専用のコマンド・プログラム
/usr/share/　　　　アーキテクチャに依存しないファイル
/usr/X11R6/　　　　X Window Systemに関するファイル
/usr/games/　　　　ゲームなど
/usr/src/　　　　　ソースコード
--

サブディレクトリの下にはさらにディレクトリが存在しており、とくに「/usr/local/」の下にはさらに「bin」「include」「lib」「sbin」「share」「src」といったディレクトリが存在することが多いようです。ソースコー
ドからビルドする時にはよく/usr/local/以下を使用していましたが、最近ではそのようなことも減ったようです。

「/usr」ディレクトリはシステムを構成する上できわめて重要なディレクトリですが、システムの起動に利用するファイルはここには置かれません。とはいえ、このディレクトリがなければシステムは全くといっていいほど使い物になりません。また、/usrディレクトリは巨大になる場合が多いので、システムを構築する際、/usrディレクトリだけ独立したパーティションに置くことも多いようです。

Linuxのディレクトリの中でも特別なディレクトリともいえる「/usr」ディレクトリ。このディレクトリをマスターすれば、初心者卒業ということも言えるでしょう。


インデックスに戻る

「Makefile」ファイル

今回は、「Makefile」ファイルについて。

makeコマンドは、コンパイル作業を行うために様々な作業を自動的に行うためのコマンドです。「Makefile」は、コンパイル、依存関係の管理、インストールなどのルールを記述しておくためのファイルで、makeコマンドが読み込んで処理を行います。Makefileには、ファイルの生成手順や、プログラムを構成しているファイル同士の関係を記述します。

なお、Makefileをうまく記述すれば、プログラムのコンパイル以外にもLaTeXによる文章の作成作業などを自動化することもできます。たとえば、メールを扱うソフトウェア（MTA）であるSendmailの設定ファイル「sendmail.cf」を生成するためのマクロ処理をmakeコマンドを使って行っています。

Makefileの書式は以下の通りです。

--
変数宣言

ターゲット名:依存ファイル名
        コマンド
--(注：コマンドの前のインデントはTAB）

ターゲットの記述例は以下の通りです。

--
lists:
        ls -al
--

これをmakeで実行するには以下のように、makeファイルにターゲット名を指定して実行します。

$ make lists
ls -al
drwx------  7 user    user        4096  2? 24 02:22 2018 .
drwxr-xr-x. 5 root    root        4096  7?  1 12:47 2015 ..
-rw-------  1 user    user       17624  2?  4 02:00 2018 .bash_history
-rw-r--r--  1 user    user          18  5? 27 00:46 2011 .bash_logout
-rw-r--r--  1 user    user         176  5? 27 00:46 2011 .bash_profile

カーネルや、様々なOSSのビルドにおいて重要な役割を果たすMakefile。
色々なソフトウェアのソースコードに含まれているので、機会ごとに中身を見てみるとよいでしょう。

インデックスに戻る

カーネル再構築

今回は、「カーネル再構築」について。

「カーネルの再構築（コンパイル）」は、Linuxの勉強をしているとどこかで必ず出会う言葉です。ところが、最近ではカーネルを再構築しなくても大抵のことはできてしまうので、「Linuxをそこそこの頻度で触っているけれどもカーネルの再構築をしたことがない！」という方が多いようです。
また、カーネルの再構築を失敗するとシステムが動作しなくなってしまうため、どうにも手が出ないと思われがちのようです。

カーネルの再構築は、デフォルトではカーネルに組み込まれていない機能を利用したい、あるいはカーネルがサポートしていないデバイスを利用したい場合に必要となります。「そのような場面がない」という場合であっても、この作業はすべてのLinuxを管理する方に、練習だと思ってやってみていただきたいと思います。

カーネルを再構築するためには、現在利用しているシステムではなく、専用の環境を用意するのがよいでしょう。といっても「新しいコンピュータを買え」ということではなく、VirtualBoxなどの仮想マシン作成・実行ソフトウェアを利用するのです。このこと自体が、「仮想環境でテストを行う」練習になります。また、カーネルの再構築は最初はLinuxディストリビューションに配布されているソースコードを利用するとよいでしょう。
Linuxディストリビューション向けにカスタマイズされているため、誤動作を起こしづらくなります。ある程度慣れてきたら、本家（http://www.kernel.org)からソースコードをダウンロードして、Linuxを動作させることを目指してみましょう。ここまでできるようになったらかなりのレベルだと言えます。

カーネルの再構築は、ソースコードを用意し、コンパイルしたのちに、これをインストールし、ブートローダの設定を行うことで完了します。インストールといっても「yum install」で終わるわけではありませんので、「コンパイル」の練習、「インストール」の練習、ブートローダの設定の仕方、コマンドの使い方、ファイルの配置など、得られるスキルは多岐に渡ります。「正しく動作しているかどうか」の確認も勉強ですし、正しく動作しないときに、うんうん唸りながら試行錯誤するのは紛れもない勉強になります。

また、単に「書籍に書いてある通りにやりました！」では得られるものが少ないので、できる限り操作の意味を考えながら作業を行うようにしてください。

インデックスに戻る

「/etc/sysconfig/iptables」ファイル

今回は、「/etc/sysconfig/iptables」ファイルについて。

このファイルはその名前から想像できるようにiptablesコマンドに関するファイルです。もっと詳しく言うと、「OS起動時に、システムに設定するiptablesのルールを指定するファイル」です。具体的にファイルの記述例を見てみましょう。

--
# cat /etc/sysconfig/iptables
*filter
:INPUT DROP [5:300]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [32:3205]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -j ACCEPT
COMMIT
--

この記述例では、INPUTチェインとFORWARDチェインのポリシーを「DROP」、OUTPUTチェインのポリシーを「ACCEPT」に指定し、INPUTチェインのTCP/22番ポートとTCP/8080番ポート宛てのパケットを受け入れるという指定を行っています（詳しくは、iptablesコマンドの利用法について参照してください）。

このファイルを作成するには、「iptables-save」コマンドを利用するのが簡単です。「iptables-save」コマンドを利用するには管理者権限が必要です。このコマンドを実行すると、現在コンピュータに適用されているiptablesのポリシーやルールが出力されます。

--
# iptables-save > filename
--

「> filename」を省略すると、標準出力（すなわち、ディスプレイ）に結果が出力されます。filenameに「/etc/iptables」を指定すると、このファイルに結果が書き込まれます（実行前に/etc/iptablesのバックアップを取る、いったん他のファイルに記述するなどの施策をとることをお勧めします）。この設定ファイルを一から書くとミスする可能性が大きく、設定をミスすると通信ができなくなる恐れがあるので、慣れていない人がこのファイルを設定するときにはまず「iptables-save」コマンドを利用し、必要に応じてエディタで編集するようにしましょう。


なお、このファイルは主にRed Hat系のLinuxディストリビューションに存在するファイルです。Linuxディストリビューションによっては、このファイルが無いか、別のディレクトリに存在する場合もあります。また、「iptables-save」の逆、すなわちファイルの内容をシステムのiptablesに反映させるコマンドは「iptables-restore」ですので、あわせて覚えておきましょう。

--
# iptables-restore < filename
--

インデックスに戻る

「/etc/sysconfig/clock」ファイル

今回は、「/etc/sysconfig/clock」ファイルについて。

このファイルは、システムクロックの設定を行うファイルです。記述例は以下の通りです。

--
ZONE="Asia/Tokyo"
UTC=true
--

「ZONE」には、システムクロックタイムゾーンを指定します。日本時間を利用するために"Asia/Tokyo"を指定します。なお、ここで指定できる設定値の一覧は、「/usr/share/zoneinfo」およびこれ以下のディレクトリを参照することで得られます。

--
$ ls -F /usr/share/zoneinfo
Africa/      Canada/  GB         Indian/    Mexico/   ROK        iso3166.tab
America/     Chile/   GB-Eire    Iran       NZ        Singapore  posix/
Antarctica/  Cuba     GMT        Israel     NZ-CHAT   Turkey     posixrules
Arctic/      EET      GMT+0      Jamaica    Navajo    UCT        right/
Asia/        EST      GMT-0      Japan      PRC       US/        zone.tab
（略）

$ ls -F /usr/share/zoneinfo/Asia/
Aden        Chongqing    Jerusalem     Novokuznetsk   Tbilisi
Almaty      Chungking    Kabul         Novosibirsk    Tehran
Amman       Colombo      Kamchatka     Omsk           Tel_Aviv
Anadyr      Dacca        Karachi       Oral           Thimbu
Aqtau       Damascus     Kashgar       Phnom_Penh     Thimphu
Aqtobe      Dhaka        Kathmandu     Pontianak      Tokyo
（略）

--

「UTC」には、ハードウェアクロック（ハードウェアに内蔵されている時計）をUTCにするか否かを指定します。trueに設定するとハードウェアクロックがUTCとなり、falseに設定するとハードウェアクロックがローカルタイムになります。
なお、この設定は「システムクロック」（OSが刻んでいる時計）の設定ではないことに注意してください。すなわち、「UTC=true」としてもその段階ではすぐにはシステムクロックはUTCになりません。

基本的に、OSが起動する際にハードウェアクロックから時刻が読み出され、システムクロックに記録されてシステムクロックが動き出します。この段階で、上記設定を反映してシステムクロックがUTC、あるいはローカルタイムに設定されます。

「/etc/sysconfig/clock」ファイルの設定を誤ると、時計が正しい時刻を示さなくなってしまう（日本であれば時間が9時間ずれるなど）可能性がありますので注意してください。

インデックスに戻る

「/etc/sysconfig/authconfig」ファイル

今回は「/etc/sysconfig/authconfig」ファイルについて。

「/etc/sysconfig/authconfig」ファイルは、その名の通り、ホストでの認証に関する設定を行うファイルです。ファイルの中身を見てみるとわかりますが、設定の仕方そのものはyesかnoで指定するという分かりやすいものになっています。

--
$ cat /etc/sysconfig/authconfig
CACHECREDENTIALS=yes
USESSSDAUTH=no
USESHADOW=yes
・
・
・
---

設定の意味を一部ですが具体的に追いかけてみましょう。

USEMKHOMEDIR=yes/no
初回ログイン時に、ユーザ用のホームディレクトリの作成を有効にするか否かを設定します。

USESSSDAUTH=yes/no
SSSD認証を有効にするか否かを設定します。

USESHADOW=yes/no
シャドウパスワードを有効にするか否かを設定します。

USEFPRINTD=yes/no
指紋認証を有効にするか否かを設定します。

PASSWDALGORITHM=(値)
パスワードアルゴリズムを指定します。値には、bigcrypt/descrypt/md5/sha256/sha512といったものが指定できます。

USELDAPAUTH=yes/no
LDAP認証を有効にするか否かを指定します。

「認証」に関する設定なので、言うまでもなく重要なファイルです。一方で、適切に設定しないとログインができなくなってしまう恐れがあるため、設定の変更を行うときには注意が必要です。またたとえばLDAPを新規に利用するようになった時などには設定を変更する必要が生じますので、覚えておいてください。

インデックスに戻る

ロケール設定ファイル　/etc/sysconfig/i18n

今回は、「ロケール設定ファイル/etc/sysconfig/i18n」について。

このファイル、ファイル名からは何を設定するものなのかがわかりにくいですね。このファイルは、「システムのロケール」を設定するファイルです。
i18nとは、「InternationalizatioN」のIとNの間に18文字あるので略してi18nとなっているのです。わかりやすく言えば、そのコンピュータがユーザとやりとりする言語（英語、日本語など）などの「ロケール」（Locale）を指定するファイルです。ただし、指定するのは「言語」だけではありません。

「ロケール」という言葉は知っておいたほうがよい用語です。ロケールとは、「その地域で使われる言語や通貨の単位などのまとまり」です。たとえば「日本」という地域であれば、言語に「日本語」、通貨の単位に「円」、長さの単位に「メートル（m）」、重さの単位に「グラム（g）」を利用するのが一般的ですね。これらのまとまりが「ロケール」です。さらに、日本語でも「文字コード」があり、最近では「UTF8」を利用するケースが多いため、このファイルには次のように記述されているケースが多いと思います。

--
# cat /etc/sysconfig/i18n
LANG="ja_JP.UTF-8"
--

ところで、最近のLinuxでは、このファイルがダミーになっており、ロケールの設定は「/etc/locale.conf」に行うようになっている、またロケール設定は「localectl」というツールを利用することになっているという場合があるので、注意してください。

インデックスに戻る

ネットワーク設定ファイル

今回は、「ネットワーク設定ファイル」について。

今回取り上げる題材ですが、ネットワークの設定は内容によってそれを記述するファイルが別になっており、またLinuxディストリビューションによってかなり異なります。

そこで今回は、主要なファイルを簡単にまとめてみようと思います。

■RedHat系の設定ファイル
RedHat系では、主に以下のファイルが使用されています。

・「/etc/sysconfig/network」
マシン全体の設定を行うファイルです。ネットワークを有効にするか否か、ホスト名の設定、デフォルトゲートウェイのIPアドレス、ルーティングを行うか否かの指定などを行います。

・「/etc/sysconfig/network/scripts/ifcfg-[NIC名](eth0、ens0、eno0など)」
NICごとの設定を行うファイルです。NICを有効にするか否か、IPアドレスを静的に割り当てるかDHCPで割り当てるか、静的に割り当てる場合のIPアドレスやネットマスクなどを記述します。

■Debian系の設定ファイル
Debian系では、主に以下のファイルが使用されています。
・「/etc/network/interfaces」
NICの設定などを行います。IPアドレス、ネットマスク、デフォルトゲートウェイの設定など、一括してこのファイルに行います。Debian系ディストリビューションのネットワーク設定で要となるファイルです。

・「/etc/networks」
ネットワーク名とネットワークアドレスの対応を指定するファイルです。


これらのファイルのほかに、/etc/resolv.confファイルにDNSリゾルバの指定を行うことで、最低限の通信ができるようになります。

ファイル構成がRed Hat系とDebian系で全く異なるのですが、最大の違いは「ネットワークインターフェイス（NIC）の設定」でしょう。Debian系では、すべてのNICの設定を「/etc/network/interfaces」ファイルで行いますが、RedHat系ではNICごとに異なるファイルに設定を行います。

ネットワーク設定という、コンピュータには欠かせない事項でありながら、ファイルの構成からしてディストリビューションごとに異なるというややこしい話になっています。違いを意識し、しっかり区別して頭に入れましょう。

インデックスに戻る

「/etc/sysconfig」ディレクトリ

今回は、「/etc/sysconfig」ディレクトリについて。

このディレクトリには見覚えがあるという方も多いと思います。
「/etc/sysconfig」ディレクトリには、Red Hat系列のLinuxディストリビューションではネットワーク関係のディレクトリが置かれています。そのため、CUIベースでネットワーク関係の設定を行う際には、ここのディレクトリに置かれたファイルを編集するのは必須となります。Red Hat系のLinuxのシステム管理を学習する際に、ここのファイルを編集したという方が多いのではないでしょうか。

また、このディレクトリは、当然ながらネットワーク関係のファイルのみが設置されているわけではありません。「/etc/sysconfig/」という名前が示す通り、「システムの設定」を行うファイルが設置されています。

「/etc/sysconfig」ディレクトリにあるファイルの役割は、少しわかりづらいと思います。たとえば「/etc/sysconfig/named」というファイルを見てみましょう。

このファイルが「named」（DNSサーバ「BIND」の本体）に関係しているということは容易に想像がつくと思います。しかし、その役割は「/etcの下にあるnamedだから、namedの設定ファイルではないのか？」と考えがちですが、namedの設定ファイルは「/etc/named.conf」です。

/etc/sysconfig/namedというファイルは、namedサービス起動時にnamedデーモンに渡す引数を記述するために使用されます。

このように、通常の設定ファイルとは別に、システムに関わる設定ファイルが配置されているのが/etc/sysconfigディレクトリです。設定を修正することは少ないと思いますが、どのような設定ファイルがあるのか、覗いてみてください。

インデックスに戻る

procディレクトリにあるその他のファイル

今回は「procディレクトリにあるその他のファイル」を見てみようと思います。

/procには数多くのファイルがあるのはこれまで見てきた通りです。まだ取り上げていないファイルの中でも知っておきたいものに、

「/proc/partitions」ファイル（パーティション情報が格納されたファイル）
「/proc/uptime」ファイル（システムの駆動情報が格納されたファイル）
「/proc/version」ファイル（カーネルのバージョン情報が格納されたファイル）

などがあります。

これらのファイルの内容は、稼働しているLinuxカーネルの内部情報に当たります。
これらの値はLinuxのコマンドが直接参照し、値を取得して統計を取るなどの加工を行ったり、そのままの状態で表示したりします。
これらのコマンドを実行することでシステムの状態を把握することができるのです。

このとき、コマンドはカーネルに直接値を参照するのではなく、これらのファイル、すなわち/proc/uptimeなどのファイルを参照するという仕組みになっていることが特徴です。
Linuxは、さまざまな統計情報を/proc/ディレクトリのファイルに書き出す仕組みが備わっており、カーネルに問い合わせることなく統計情報を得ることができるようになっているのです。
カーネルに直接問い合わせると、トラブルの元につながる恐れがあるので、いったんファイルを経由してトラブルの危険を軽減すると解釈することができます。

Linuxシステムを管理するために重要な技術が、さまざまな工夫で上手く作られているということを垣間見ることができると思います。

インデックスに戻る

「/proc/cmdline」ファイル

今回は、「/proc/cmdline」ファイルについて。

このファイルは、その名の通り「コマンドライン」に関係していますが、何のコマンドラインかというと、「OSがブートされたときに、ernelに渡されたパラメータ」です。

catコマンドで内容を確認してみると、たとえば次のような結果が得られます。

--
$ cat /proc/cmdline
ro root=/dev/mapper/vg_host01-lv_root rd_LVM_LV=vg_host01/lv_root
rd_NO_LUKS rd_NO_MD crashkernel=129M@0M  KEYBOARDTYPE=pc
KEYTABLE=jp106 LANG=ja_JP.UTF-8 rd_LVM_LV=vg_host01/lv_swap rd_NO_DM
--

この記述に見覚えがあるという方も多いのではないでしょうか。これらの文字列は、コンピュータを起動する際、GRUBなどのブートローダによってカーネルに渡されるパラメータです。

カーネルに渡されるパラメータは、OSの挙動を決める重要なものですから、「どのようなパラメータが渡されるか」を確認したいという場合、このファイルの内容をcatコマンドで確認するとよいのです。OSの挙動というと設定ファイルを確認することが多いと思いますが、ここにも大切なパラメータがあるということを覚えておいてください。

インデックスに戻る

/proc/<pid>/ディレクトリに存在するファイル

今回は、「/proc/<pid>/cmdlineなど」、/proc/<pid>/ディレクトリに存在するファイルをいくつか見ていきます。(<pid>はプロセスID（数字）)

たとえば、実行中のSSHサーバのプロセスIDが1489だとします。
このプロセスに対応するcmdlineをcatで参照してみましょう。

--
$ cat /proc/1489/cmdline
/usr/sbin/sshd
--

このファイルには、プロセスを開始したコマンドがフルパスで記述されており、catコマンドで参照することができます。
次に、このプロセスに対応するexeを見てみましょう。ls -l で確認してください。

--
# ls -l  /proc/1489/exe
lrwxrwxrwx 1 root root 0  4月 27 20:40 2017 /proc/1489/exe -> /usr/sbin/sshd
--

このファイルは、「プロセスの実行ファイルへのシンボリックリンク」なのです。シンボリックリンクとなっているファイルは他にも「cwd」（プロセスがカレントワーキングディレクトリとして利用しているディレクトリへのシンボリックリンク）、「root」（プロセスがルートディレクトリとして利用しているディレクトリへのシンボリックリンク）などがあります。

これらのファイルは、プロセスを開始したコマンドが「どのコマンドか」といったことがわかるというだけではありません。うまくスクリプトを書くことで、プロセスを管理・制御するということもできます。なんといってもプロセスが実際に利用しているファイルやディレクトリに直接アクセスできますので、上手に活用しましょう。

インデックスに戻る

「/proc/<pid>/status」ファイル

今回は「/proc/<pid>/status」ファイルについて(<pid>はプロセスID（数字）)について見てみましょう。

例として、プロセスIDが1489である、sshが走っているstatusのファイルを見てみましょう。

--
$ cat /proc/1489/status
Name:    sshd
State:    S (sleeping)
Tgid:    1489
Ngid:    0
Pid:    1489
PPid:    1
TracerPid:    0
Uid:    0    0    0    0
Gid:    0    0    0    0
FDSize:    64
Groups:    
VmPeak:       82472 kB
VmSize:       82468 kB
VmLck:           0 kB

（以下略）
---

他にも沢山の表示項目がありますが、以下に一部だけ紹介します。

Name: プロセスによって実行されたコマンド
State: プロセスの現在の状態
Tgid: スレッドグループID
TracerPid: 該当プロセスをトレースしているプロセスのID
FDSize: 割り当てられているファイルディスクリプタスロット数
Groups: 補助グループ一覧
VmPeak: 仮想メモリサイズのピーク値
VmSize: 仮想メモリサイズ
VmLck: ロックされているメモリサイズ

Stateの項目に表示される内容は、

「R (running)」＝実行中
「S (sleeping)」＝休眠状態
「D (disk sleep)」＝ディスク待ち休眠状態
「T (stopped)」＝停止状態
「T (tracing stop)」＝トレースによる停止
「Z (zombie)」＝ゾンビ状態
「X (dead)」＝死亡

を表します。

このファイルは、情報の宝庫です。「集計」「確認」「トラブルへの対処」などを行いたいというときに、とても役に立つファイルです。様々なシステム管理系のプログラムが、このような情報を参照しています。

システムの内部動作について理解を深めるための手がかりとして、このような情報が参照できることは覚えておいてください。

インデックスに戻る

/proc/(数字)ディレクトリ

今回は、「/proc/(数字)ディレクトリ」について。

lsコマンドで、/procディレクトリ直下を見てみると、名前が数だけでできている「ディレクトリ」がたくさんあるのが見て取れます。

--
$ ls /proc
1     142   2135  23    3688  64    7887       
10    15    2145  2309  370   65    7959       
（略）
--

この数字は、実行中のプロセスの「プロセスID（PID）」に対応しています。
これらのディレクトリは「プロセスディレクトリ」と呼ばれ、該当するプロセス固有の情報が格納されています。そのプロセスが起動しているときに作成され、プロセス終了時にディレクトリは削除されます。

以下にプロセスディレクトリに含まれるファイルの例と、ファイルの内容を示します。

--
cmdline    プロセスを開始したコマンド
cwd    プロセスのカレントワーキングディレクトリ（CWD）へのシンボリックリンク
exe    プロセスの実行ファイルへのシンボリックリンク
root    ルートディレクトリへのシンボリックリンク
cpu     各cpuでのCPUタイムと統計情報
environ    プロセスの環境変数の一覧
fd    プロセスが使用しているファイル・デバイスのファイル記述子
maps    プロセスのアドレス空間の状態
mem    プロセスのアドレス空間の内容
statm    プロセスのページ割り当て
stat     プロセスの状態
status     プロセスの状態（statより詳しい内容）
--

これらのファイルはプロセスの情報の宝庫と言ってもよく、このファイルを参照することによってプロセスの詳細を調べることができます。「status」ファイルなどを見るとプロセスの状態が詳しく手に入るため、頻繁に参照されるようです。ただし、これらのファイルの内容は誤って編集・削除などをするとシステムの不具合を引き起こすことがあるため、あくまで参照用として扱ってください。

種類が多く、内容も難しいものが多いため、まずは「どのようなディレクトリとファイルがあるか」を知ることから始めましょう。

インデックスに戻る

「/proc/meminfo」ファイル

今回は、「/proc/meminfo」ファイルについて。

前回取り上げた「/proc/cpuinfo」がCPUの情報が格納されていたファイルであるように、「/proc/meminfo」ファイルにはメモリーの情報が格納されています。得られる情報も多岐に渡ります。catコマンドで内容を参照してみましょう。

---
$ cat /proc/meminfo
MemTotal:        3933132 kB
MemFree:         1421704 kB
MemAvailable:    2155944 kB
Buffers:          108552 kB
Cached:          1097568 kB
（略）
---

「MemTotal」はその名の通り搭載しているメモリの総量、「MemFree」は空きメモリ量、「MemAvailable」はキャッシュなどを解放することで利用可能なメモリ量、「Buffers」はバッファのサイズ、「Cached」はキャッシュのサイズ・・・と、ぱっと見はわかりやすいですね。しかし、よく見ると気づくことがあります。たとえばですが、「MemFree」の値と、さまざまなプロセスで使われているメモリの量を足してみても、MemTotalの値にならないというようなことがことがよくあるのです。Linuxにおけるメモリの扱いはかなりややこしいので、一見すると「あれ、あの値とこの値を足しても計算が合わないぞ」となることがよくあります。

知っておくとよいことは「キャッシュ」として使われているメモリ領域と「Anonymous」として使われるメモリ領域、そしてカーネルが利用するメモリがあるということです。

「キャッシュ」として使われるメモリは、以下の項目に表示されます。
Active(file):     502556 kB
Inactive(file):   380956 kB

「Anonymous」として使われるメモリは以下の項目に表示されます。
Active(anon):    1086880 kB
Inactive(anon):   316996 kB

「キャッシュ」と「Anonymous」は、簡単に言えば「キャッシュ」は必要に応じてデータをディスクに書き出すことで開放できるタイプのメモリ領域、「Anonymous」はそれができない（開放する場合はSwapに書き出す必要がある）タイプのメモリ領域だと思うとよいです。

簡単なようでいてかなり奥が深く、詳しく学ぶとそれなりに時間がかかる分野ですので、Linuxの理解が深まってから詳しいことを勉強してみるとよいと思います。

インデックスに戻る

/proc/cpuinfoファイル

今回は、「/proc/cpuinfoファイル」について。

このファイルは、その名前の通りCPUの情報が格納されたファイルです。
/procディレクトリにあるファイルですので、メモリ上に作られる仮想的なファイルです。基本的には編集できないファイルですが、一方でさまざまな情報が得られるファイルでもあります。

ファイルの内容を見るにはcatコマンドを利用します。

---
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Pentium(R) 4              @3.20GHz  
stepping        : 10
microcode       : 2571
cpu MHz         : 2294.249
cache size      : 1024 KB
（略）
flags           : vme de pse tsc msr pae mce cx8 apic sep mtrr ht lm
（略）
---

内容についての詳細は書き切れないので省略しますが、いくつか知っておくとよいことを記しておきます。

たとえば、CPUのコアの数を確認するためには、「cpu core」という項目を検索します。この時、viエディタなどでファイルの中身を確認するのは/procディレクトリのファイルでやってはいけないことですので、catコマンドの結果をgrepコマンドに渡すように実行します。

○CPUコア数を確認する例
$ cat /proc/cpuinfo |grep "cpu core"
cpu cores       : 4


これで、コア数が4であることがわかりました。

もう1つ重要なのが「flags」の項目です。ここには、CPUがどのような機能に対応しているか？などが記されます。たとえば上の「vme」は「仮想モード拡張機能」をサポートしていることを表し、「de」は「デバッグ拡張機能」をサポートしていることを表します。「ht」はハイパースレッディングテクノロジーをサポートしており、「lm」はロングモードをサポートしている（64bit版のOSが利用できる）ことを表します。

「この機能はこのマシンで利用できるかな？」といったことは、様々なケースで出てきます。そのようなとき、/proc/cpuinfoを調べると解決することがある、ということを覚えておいてください。

インデックスに戻る

/etc/sysctl.conf

今回は、「/etc/sysctl.conf」について。

このファイルは、前回取り上げた「/proc/sys/」ディレクトリに存在するファイルの初期値を記述するファイルです。「/proc/sys/」ディレクトリには、カーネルの挙動を決める値が格納されたファイルが存在します。これらのファイルの値を参照するには「catコマンド」、書き込むには「echoコマンド」を利用します。

--
# cat /proc/sys/net/ipv4/ip_forward ←/proc/sys/net/ipv4/ip_forward
の値を参照
0 ←/proc/sys/net/ipv4/ip_forwardの値が表示される
# echo "1" > /proc/sys/net/ipv4/ip_forward ←/proc/sys/net/ipv4/
ip_forwardに値「1」を設定
--

なお、/procディレクトリのファイルは仮想ファイルであるため、このディレクトリのファイルをviなどのエディタで編集することは厳禁です。

さて、前回紹介したように、/proc/sys/ディレクトリのファイルはカーネルの挙動を決定するファイルですから、管理者は当然のことながら変更する必要に迫られる場合もあります。しかし、前述のechoコマンドを利用する方法では、OSをシャットダウンすると値が消えてしまい、次回起動時には元の値に戻ってしまいます。そこで、「/etc/sysctl.conf」ファイルの出番となります。

「/etc/sysctl.conf」は、OS起動時に/proc/sys/ディレクトリのファイルに設定する値を記述しておくファイルです。このファイル自体は/procディレクトリにあるファイルではありませんので、viエディタなどで編集することができます。

「/etc/sysctl.conf」の記述例は次の通りです。

--
# Controls IP packet forwarding
net.ipv4.ip_forward = 0
--

1行目の#に続く記述はコメントで、無視されます。
2行目がファイルに値を設定するための記述です。この記述は、「net.ipv4.ip_forward」がファイル名を表します。
「net.ipv4.ip_forward」は「/proc/sys/net/ipv4/ip_forward」を表します。つまり、ファイル名から「/proc/sys/」を除去し、「/」を「.」に変えたものを記述します。そして、「=」に続けて設定値を記述します。

このファイルは、初期値を記述しておくだけのファイルですので、このファイルを編集した場合、OSを再起動すれば設定が反映されますが、ファイルを編集しただけでは設定は反映されません。OSを再起動せずに設定変更を反映する、すなわち/proc/sys/にあるファイルに値を書き込むためには、sysctlコマンドを利用します。

--
# sysctl -p
--

システムの設定を行うために必須のファイルですので、しっかり押さえておきましょう。

インデックスに戻る

/procディレクトリのファイル

今回は、「/procディレクトリのファイル」について。

/procディレクトリは、普通のファイルシステムと違い、ハードディスクやSSDなどのストレージ上ではなく、メモリの中に作られるファイルシステムです。mountコマンドで確認してみると、/procディレクトリが他と異なる場所にある、他と異なるproc形式のファイルシステムであることがわかると思います。まずはこのことをしっかりと押さえてください。

--
$ mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
（略）
--

また、/procにあるファイルは普通のファイルではなく、「仮想ファイル」という特殊な形式となっています。lsコマンドで確認してみると、/procにあるファイルはサイズが0になっている上、タイムスタンプもほとんどのファイルで現在時刻になっています。

「/proc」ディレクトリにあるファイルは、システムをコントロールするために使われます。そのため、システムのさまざまな情報がここに格納されており、/procにあるファイルを参照することによって、システムの情報をリアルタイムで得ることができます。
また、/procにあるファイルを編集すれば、システムをコントロールすることもできます。
ただし、/procの内容を誤ると、システムを破壊する危険もありますので、意味もわからずに/procの内容を変更するということは絶対に避けてください。

たとえば「/proc/sys/」ディレクトリのファイルには、カーネルの諸設定をオン／オフが記載されており、ここのファイルの内容を書き換えることによって、さまざまなカーネル設定を有効化／無効化することができます。
ただし、ここのファイルを直接編集してシステムを調整するのは何かと面倒ですし、トラブルの元になります。そこで、「/etc/sysctl.conf」というファイルが用意されています。このファイルについては次回扱います。

/procディレクトリの内容はきわめて大切です。むやみに編集することなく、かといって一切触らないでもなく、しっかり学んでしっかりとつきあってください。

過去に掲載された「Linux豆知識」→　https://www.lpi.or.jp/lpic_all/linux/trivia/

■コラム作成者
株式会社びぎねっと　代表取締役社長　宮原徹氏
※上記の内容については、コラム作成者の監修です。

インデックスに戻る

「/var/crash」ディレクトリ

今回は、「/var/crash」ディレクトリについて。

「/var/crash」ディレクトリは、カーネルダンプを取得する際に利用されるディレクトリです。このカーネルダンプと呼ばれるものはあまり知られていないようですが、トラブル解決に有用なものですので覚えておくとよいでしょう。

カーネルダンプとは、カーネルがクラッシュした時に、メモリの状態をストレージに保存する機能です。通常のアプリケーションのクラッシュと異なり、カーネルのクラッシュでは通常の手段では状態の把握が難しいため、クラッシュの原因を突き止めることが難しくなります。そこで用意されたのが「カーネルダンプ」という仕組みです。

「カーネルダンプ」の方法としては、カーネルがクラッシュした際に、メモリダンプ用の別のカーネルが起動してシステムの状態を把握し、情報を採取するという方法がとられます。その情報をファイルに書き出すことで、システムをリブートしたときにユーザがクラッシュ時の状態を把握できるようになるのです。このファイルが書き出されるのが、「/var/crash」ディレクトリです。

カーネルダンプはデフォルトでは設定されていないことが多く、広く浸透しているとは言いがたい機能ではあります。しかし、重要なシステムを稼働させる場合にはトラブル解決が必要となるため、その際に非常に有用な機能ですので、ぜひ覚えておいてください。

インデックスに戻る

「/var/spool」ディレクトリ

今回は、「/var/spool」ディレクトリについて。

「/var/spool」ディレクトリは、「スプール」と呼ばれる一時的に作業用のファイルなどを置いておくためのディレクトリです。プリンターを例に挙げて説明します。

プリンターは処理速度が遅く、またデータを受け取って蓄えておく「バッファ」の容量が大きくありません。そのため、印刷したいデータをプリンターに直接送信すると、あるユーザーが印刷している間、他のユーザーは印刷処理待ちとなってしまいます。

そこで、データをプリンターに直接送信するのではなく、一時的にスプールの中にデータを書き出します。そして、プリント作業の進行に応じて、スプールの中のデータをプリンターに順次送信します。このように、一時的にデータを溜めておく領域を「スプール領域」と呼びます。スプールによって、ユーザーは他のユーザーの印刷作業が終了するのを待つことなく、他の作業を行うことができるようになります。このように、印刷データをスプールするサーバーを「プリントサーバ」と呼ぶこともあります。

「/var/spool」ディレクトリを直接操作することはそれほどありませんが、様々なサーバーが一時領域として使用しているため、トラブルの際に中身を確認することもあるでしょう。管理者として、その役割をしっかりと理解しておきましょう。

インデックスに戻る

「/var/run」ディレクトリ

今回は、「/var/run」ディレクトリについて。

「/var/run」ディレクトリは、システムを起動した後の情報が格納されるディレクトリです。このディレクトリには、主に実行中のプロセスに関する情報が格納された「pidファイル」が存在します。/var/runディレクトリは一般ユーザでも参照できますので、lsコマンドで参照してみてください。

--
$ ls /var/run
autofs.pid
crond.pid
messagebus.pid
--

「.pid」で終わっているファイルがpidファイルです。このファイルには、該当するプロセスのプロセスIDなどの情報が記述されています。たとえば、/var/run/crond.pidファイルには、crondのプロセスIDが記述されています。

このファイルは、スクリプトやほかのプロセスで利用されます。プロセスIDが記述されているので、このファイルはプロセスの制御（再起動や停止など）、プロセス同士の連携などに利用されます。

これらのファイルも、基本的には編集が必要になることはありません。むしろ、下手に編集するとシステムの誤動作を引き起こす場合があります。一方で、プロセスやシステムが異常終了したときにpidファイルが残っているせいでプロセスがうまく起動しないというトラブルもありえます。他方、たとえばRed Hat Enterprise Linux 7では、「/var/run」ディレクトリがtmpfsでマウントされるようになっており、システムをシャットダウンするとファイルが消えます。このことを頭に入れてスクリプトを組まないと、うまく動作しないといったトラブルも考えられます。

このディレクトリも前回の/var/locksと同じように縁の下の力持ち的な存在です。ぜひ覚えておきましょう。

インデックスに戻る

/var/lock

今回は、「/var/lock」ディレクトリについて。

「/var/lock」ディレクトリは、ファイルを操作する際にファイルをロックする目的で利用します。

システムの動作で、複数のプロセスから1つのファイルに対して同時に書き込みの要求が行われる、という場合があります。しかし、複数の要求を同時に処理してしまうとファイルの整合性が取れなくなり、思わぬトラブルになります。そこで「ロック」が行われます。

たとえば、ファイルの書き込みが行われる時、/var/lockディレクトリ内に新しいファイルが作成されます。このファイルは、「書き込みが行われている」ことを示すという役割を持ちます。そして、他のプロセスは、/var/lockディレクトリを参照することで、書き込みを行うかなどを決めることになります。

このディレクトリの内容は、基本的にユーザが編集することはありません。むしろ下手に触るとトラブルの元になりますから、下手にいじらないようにして下さい。ただし、このディレクトリの存在は知っておいたほうがよいでしょう。たとえば、何らかのアプリケーションが異常終了し、ファイルに書き込みができなくなったという時に、実は「/var/lock」内に本来あるべきではないファイルが残っているといったことがあるからです。

インデックスに戻る

「/var/cache」ディレクトリ

今回は、「/var/cache」ディレクトリについて。

このディレクトリの役割は、おそらく名前を見てピンとくる方も多いかと思います。「キャッシュ」、つまり一時的なファイル置き場として利用されます。キャッシュは、インターネットからダウンロードしたファイルを一時的に置いておく場所、プログラムが一時的に作成したファイルを置いておく場所として利用されます。

このディレクトリの内容を操作「しなければならない」、というケースは少ないと言えるかもしれません。下手に操作して、プログラムの誤操作を招くという危険もあるため、意味がわからないのであれば操作しないほうがよいと考えられます。

ただし、このディレクトリが問題になる場合もあります。大抵の場合、キャッシュは古くなるとクリアされるのですが、YumやAPTなどが利用した容量の大きなパッケージファイルが溜まってしまい、これによってディスクの容量を圧迫してしまうという問題です。

この問題は設定を適切に行うことで解決できることもありますし、専用のコマンド、たとえばAPTであれば「apt-get clean」、Yumであれば「yum clean all」などで解決できることもあります。これらのコマンドは、必要なファイルをきちんと残した上でキャッシュのクリアを行ってくれるので、rmコマンドで強引に消してしまうのではなく、コマンドでクリアするようにして下さい。

インデックスに戻る

認証に関する情報を記録するログファイル

今回は、認証に関する情報を記録するログファイルを紹介します。

認証に関するログファイルは、「/var/log/wtmp」「/var/log/lastlog」「/var/log/btmp」「/var/log/faillog」「/var/log/tallylog」などがあります。しかし、これらのファイルはいずれもバイナリファイルですので、エディタなどで直接参照することはできません。内容を参照するには、専用のコマンドを利用します。

「/var/log/wtmp」は、ログインに成功した場合にその情報が記録されるファイルです。このファイルを参照するには、lastコマンドが利用できます。

---
$ last
user01   pts/0        192.168.0.101    Sun Apr 17 03:29 - down   (00:03)
reboot   system boot  2.6.32-573.22.1  Sun Apr 17 06:33 - 13:46  (12+10:13)
---

このように、どのユーザが、どのコンソールを利用して、どのホストから、いつ接続してきたかがわかります。なお、２つ目のrebootの記述は、システムが再起動されたことを意味するので、「いつシステムが再起動されたか」ということもわかります。

「/var/log/lastlog」は、ユーザの最終ログイン時刻が記録されるファイルです。このファイルは、lastlogコマンドを利用します。

「/var/log/btmp」は、ログインを試みたが失敗した場合に、その情報が記録されるファイルです。このファイルを参照するにはlastbコマンドを利用しますが、このコマンドを実行するには管理者権限が必要です。システムに不正侵入が試みられていないかどうか？を確認するため、外部から意図不明のアクセスが確認されたときなど、あるいは何もなくても定期的に実行するとよいでしょう。

「/var/log/faillog」は、ログインの失敗回数がユーザごとに記録されるファイルです。「/var/log/btmp」では失敗したログインが（システムに存在しないユーザ名を用いた場合であっても）すべて記録するのに対し、「/var/log/faillog」ではシステムに存在するユーザのログイン失敗が記録されます。このファイルとPAMのpam_tallyモジュールを利用すると、予め決められた回数ログインに失敗したユーザにアカウントロックをかけることができるようになります。この操作はpam_tallyコマンドが利用できます。

「/var/log/tallylog」は、「/var/log/faillog」と同じ役割のファイルですが、「/var/log/faillog」がアーキテクチャごとに異なる形式となってしまっているため、アーキテクチャに依存しないファイルとして「/var/log/tallylog」ファイルが用意されています。「/var/log/tallylog」を利用する場合には、「pam_tally2モジュール」を利用することになります。アカウントロックなどの制御にはpam_tally2コマンドを利用します。

さまざまな情報が得られるログファイルですので、それぞれの役割と参照方法をしっかりと押さえておきましょう。

インデックスに戻る

「/var/log/dmesg」ファイル、「dmesg」コマンド

今回は、「/var/log/dmesg」ファイル、「dmesg」コマンドについて。

「/var/log/dmesg」ファイルは、Linuxがブート開始直後からファイルシステムがマウントされるまでのログが保存されるファイルです。すなわち、ブート時にカーネルが出力したメッセージが書きこまれたファイルであるということができます。

「/var/log/dmesg」ファイルは、「dmesg」コマンドによって生成されます。Linuxはブートされる際にカーネルがメッセージを一時的にバッファに描きだしますが、その内容を表示するコマンドが「dmesg」コマンドです。
このバッファはリングバッファ（循環バッファ）と呼ばれる構造になっており、容量の上限に達すると先頭に戻って古いメッセージが上書きされて消えてしまうようになっています。
Linuxは起動時に「/var/log/dmesg」ファイルに内容を書きだすことで起動時のカーネルのメッセージを残すようにしているのです。この処理は、ブート時にスクリプトによって行われます（Red Hat系ディストリビューションであれば/etc/rc.d/rc.sysinitに記述されています）。

ブート時の情報ですから、特に起動時のカーネル周りのトラブルが起こった時には参照が必須となるファイルです。どのような内容が出力されているか、一度目を通しておくと良いでしょう。

インデックスに戻る

「/var/log/messages」ファイル


今回は、「/var/log/messages」ファイルについて。

/var/logディレクトリには、さまざまなログファイルが格納されています。
そして、その中にあるこの「/var/log/messages」ファイルは、システムに
関する一般的なメッセージが格納されます。ユーザの認証情報や各種アプリ
ケーションに関するメッセージなど、さまざまなメッセージがこのファイル
に記述されます（『ここにどのようなメッセージが出力されるか？』は
syslogの設定によって変わります）。システムに何らかの不具合がある時に
はもちろん、日ごろからチェックしておくのが望ましいとも言えるファイルです。

出力の例は次の通りです。
--
Feb 16 17:18:19 station01 sshd[13863]: Accepted publickey for user01
from 192.168.0.2 port 45695 ssh2
--

フォーマットは「日　時　ホスト名　情報」となります。上の例は、「2月
16日　17時18分19秒にstation01で、sshdが192.168.0.2からの公開鍵認証を
受け付けた（ユーザ名はuser01）」ということを表します。
さて、非常に重要なこのファイル、日ごろからチェックするには、あまりにも量が多いという困った一面もあります。そのためには、まずsyslogを適切に設定し、必要なメッセージだけを/var/log/messagesファイルに出力するようにすること（何でもかんでも出力としてしまうと、見るのが手間で肝心のメッセージを見逃すというリスクもあります）が１つ。そしてもう１つ、スクリプトやツールを利用して、必要なメッセージを抽出して見るなどの工夫を行うことが考えられます。

システム管理を行う際には避けて通れないファイルです。必ず押さえましょう。




■コラム作成者
株式会社びぎねっと　代表取締役社長　宮原徹氏
※上記の内容については、コラム作成者の監修です。

インデックスに戻る

インストールISOイメージファイル

今回は、ファイル構成の話を一休みして、「インストールISOイメージファイル」について紹介します。

Linuxをインストールする際、ディストリビューションのISOイメージをWeb経由でダウンロードしてくることになります。このISOイメージは、ディストリビューションの公式サイトでも、そのミラーサイト（公式のISOイメージと全く同じものを置いてあるサイト）でも構いません。ダウンロード時の負荷を抑えるため、日本国内のミラーサイトからダウンロードするのがよいでしょう。なお、ミラーサイトは通常は公式サイトからリンクが張られていますので、そこから辿ると間違いが起こりにくいのでお勧めです。また、可能であればダウンロード時に「BitTorrent」という仕組みが利用できるのであれば、ネットワークの負荷軽減に貢献できるので、やはりお勧めです。

さて、インストールイメージはどのファイルをダウンロードするのがよいでしょう？ISOイメージのファイル名を見ると色々なものがありますね。たとえばCentOS 7であれば、ファイル名に「DVD」「Everything」「LiveGNOME」「LiveKDE」「Minimal」「NetInstall」などがあり、どれをダウンロードすればよいのか迷うことでしょう。

それぞれの特徴を簡単に言うと、以下のようになります。

○DVD…もっとも標準的なDVDイメージ
○Everything…全てのパッケージが収録されたイメージ
○Minimal…最小限のパッケージが収録されたイメージ
○Live…ライブCDもしくはDVDを利用するイメージ
○NetInstall…ネットワークインストールを行うためのイメージ

全てのパッケージが入っているので「Everythingがいい」と思ってしまうかもしれませんが、当然のことながらサイズが大きくなってしまうため、ダウンロード時の負荷が大きくなります。極端な話、「Minimal」でインストールしたとしても、インストール後にネットワーク経由で簡単にパッケージの追加が自力でできますので、そのことを勘案してイメージを選ぶことになります。

「NetInstall」を選ぶと、「ネットワークインストール」、すなわち必要なファイルをネットワーク経由でダウンロードしながらインストールを行う形式になります（厳密には、複数台のホストに同時インストールをするなどの進歩的な機能が利用できますが、ここでは割愛します）。「Live」が入ったイメージを選ぶと、ライブCD&DVDが作成できますが、ブート時のコマンドによって普通のインストールを行うこともできます。

結局のところ、どのファイルを選んでも、望みのシステムを構成することができると言ってよいでしょう。

ISOイメージを選ぶときには、「ISOイメージのダウンロードでどれだけネットワークに負荷をかけてよいか（この場合、負荷の大きさを選ぶことができません）」「インストール時にパッケージのダウンロードでどれだけネットワークに負荷をかけてよいか（この場合、負荷の大きさをある程度選ぶことができます）」「何台のコンピュータにインストールするのか」といった観点で選んでみて下さい。

インデックスに戻る

「/etc/localtime」ファイル

今回は、「/etc/localtime」ファイルについて。「/etc/timezone」ファイルについても少しだけ触れます。

「/etc/localtime」ファイルは、タイムゾーンを設定するファイルです。日本であれば特段の事情がない限り「日本標準時（JST）」を指定することになります。通常は、OSをインストールする際に自動的に設定されますので、意識する機会が少ないでしょう。

「/etc/localtime」ファイルは、バイナリ形式のファイルですので、中を見ても意味はわかりません（中身を参照するにはstringsコマンドを利用することになります）。しかし、タイムゾーンを変更するためには、このファイルを編集する必要があります（そのような機会は滅多にないと思いますが・・・）。その際は、「/usr/share/zoneinfo/」ディレクトリにあるファイルをコピーする必要があります。

○/etc/localtimeのファイル形式を確認
# file /etc/localtime
/etc/localtime: timezone data, version 2, 3 gmt time flags, 3 std
time flags, no leap seconds, 9 transition times, 3 abbreviation
chars


「/usr/share/zoneinfo/」ディレクトリには、各タイムゾーンに対応したファイルが格納されています。lsコマンドで確認してみましょう。

○/usr/share/zoneinfoディレクトリ内の確認
$ ls /usr/share/zoneinfo/
Africa      Canada   GB         Indian     Mexico    ROK        iso3166.tab
America     Chile    GB-Eire    Iran       NZ        Singapore  posix
Antarctica  Cuba     GMT        Israel     NZ-CHAT   Turkey     posixrules
（略）


「Africa」「America」「Asia」などのディレクトリや、「GMT」などのファイルが見えると思います。ディレクトリの下には、その地域のファイルが格納されています。JSTであれば「/usr/share/zoneinfo/Asia/Tokyo」ファイルになります。

「/etc/localtime」には、このファイルの中身をコピーするか、シンボリックリンクを張ることになります。作業例を以下に示します。

○/etc/localtimeの設定例
# date
Wed Dec  12 04:14:10 GMT 2015                       ←「GMT」で表示
# cp /usr/share/zoneinfo/Asia/Tokyo /etc/localtime  ←ファイルコピー
# date
Wed Dec  12 13:15:11 JST 2015                       ←「JST」で表示


さて、「/etc/localtime」とは別に、Debian系のLinuxディストリビューションでは「/etc/timezone」ファイルが利用されています。このファイルはテキストファイルで、中身は単純明快です。

○/etc/timezoneの確認
$ cat /etc/timezone
Asia/Tokyo


こちらには、「/usr/share/zoneinfo/」ディレクトリ内の「ファイル名」を指定することで、タイムゾーンを設定することになります。
なお、systemd環境ではtimedatectlコマンドを利用して設定を行うことができますので、こちらもチェックしておきましょう。

インデックスに戻る

「/etc/rc*.d」ディレクトリ

今回は、「/etc/rc*.d」ディレクトリについて見ていきましょう（*には0から6までの数字が入ります）。

通常であれば、「/etc/rc0.d」〜「/etc/rc6.d」まで、7つのディレクトリがあるはずです。そして、それぞれのディレクトリには、シンボリックリンクが存在します。lsコマンドで確認してみましょう。

--
$ ls -l /etc/rc3.d/
lrwxrwxrwx 1 root root 15 11月  7 03:50 2015 /etc/rc3.d/S85httpd -> ../init.d/httpd
・
--

これらのシンボリックリンクは、前回取り扱った「/etc/init.d」ディレクトリに存在する、サーバソフトウェアなどのサービスを起動するためのスクリプトに張られています。たとえば上の表示のように「/etc/rc3.d/S85httpd」というシンボリックリンクが、「/etc/init.d/httpd」ファイルに張られている、といった具合です。これらのディレクトリは、initプロセスによってシステムを起動・停止する際に参照されます。「rc」に続く数字はランレベルを表します。たとえば「/etc/rc3.d」ディレクトリは、ランレベル3でシステムを起動する際に利用されます。

さて、このディレクトリに収められるファイルは前述のようにシンボリックリンクですが、そのファイル名はたとえば「S85httpd」のように、「S○○」もしくは「K○○」（○○は2桁の数値）で始まるものになっています。ここで「S」で始まるシンボリックリンクがあると、リンク先のスクリプトが「サービス開始（すなわちstartオプションを付加した場合）」の処理が行われ、「K」で始まるシンボリックリンクがあると「サービス停止（すなわちstopオプションを付加した場合）」の処理が行われます。

SもしくはKの後ろの2桁の数値は、スクリプトの実行順を決めるのに利用されます。すなわち、数字が小さいものから大きいものへ、順番に実行されるということです。

このシンボリックリンクを作成する作業は、「chkconfigコマンド（RedHat系）」や「update-rc.dコマンド（Debian系）」などを利用するとほぼ自動で行ってくれます。

サービス起動の仕組み、しっかりと把握しておきましょう。

インデックスに戻る

「/etc/init.d」ディレクトリ

今回は、「/etc/init.d」ディレクトリについて見ていきましょう。

「/etc/init.d」は、デーモンなどの起動スクリプトが設置されているディレクトリです。

たとえば、apacheやbindなどのサーバソフトウェアを起動するためには、ここに置かれているスクリプトを実行します。たとえばapacheの本体であるhttpdを起動する場合は次のように「start」という引数を与えてスクリプトを実行します。

--
# /etc/init.d/httpd start
--

起動だけでなく、デーモンの停止、再起動などもこのスクリプトを使って行うことができます。もっとも、Red Hat系のLinuxディストリビューションでは「serviceコマンド」を利用してデーモンの起動・停止・再起動を行うことが多いので、実行した覚えがないという方もおられるかもしれません。

ここに置かれるスクリプトの内容について見てみると、1行目が「#!/bin/sh」や「#!/bin/bash」などで始まっています。すなわち、このスクリプトの正体は「普通のシェルスクリプト」です。実は内容もそれほど難しいものではないことが多く、シェルスクリプトの基本がわかっていれば、どのような処理を行っているのかがだいたいわかると思いますので、一回覗いてみてはいかがでしょうか。

さて、ここに置かれているスクリプトですが、OSを起動する際に重要な役割を担うことになります。OSを起動する際、複数のデーモンを起動するなど、さまざまな処理が行われますが、その処理は実はこのディレクトリにあるスクリプトが順次実行されることで行われているのです。このスクリプトの実行は、他のディレクトリおよびシンボリックリンクを利用して行われていますので、次回はそこを見てみたいと思います。

インデックスに戻る

「/etc/issue」ファイルと「/etc/motd」ファイル

今回は、「/etc/issue」ファイルと「/etc/motd」ファイルについて見ていきましょう。

「/etc/issue」ファイルは、ユーザがログインする前に、ログインプロンプトの前に表示される内容を記述するファイルです。たとえば、Debian GNU/Linux 8の「/etc/issue」ファイルには、以下のように記述されています。

--
Debian GNU/Linux 8 ＼n ＼l

--
（注：＼マークはバックスラッシュ）

これによって、CUIログインを行う際に次のような表示がなされます。

--
Debian GNU/Linux 8 station001.example.com tty1

station001 login:
--

ファイルに記述されている「＼n」や「＼l」はシーケンス文字と呼ばれています。たとえば「＼n」と書いた場合、「＼n」と表示されるわけではなく、ホスト名が表示されます。同様に、「＼l」と書いた場合は、仮想コンソールの番号が表示されます。この他にも、いくつかのシーケンス文字が利用できます。

なお、「/etc/issue.net」というファイルもあります。こちらは、SSHなどネットワーク経由でログインを試みる際に表示される内容を記述します。

「/etc/motd」ファイルは、ユーザがログインした後に、ログインプロンプトの前に表示される内容を記述するファイルです。この記述した内容は、ユーザのログイン処理が成功した後に表示されます。

さて、これらのファイルには何を記述するべきかを考えてみて下さい。ユーザに情報を提供するという意味では、さまざまな情報を書いておいた方が親切です。たとえば、システムメンテナンスの予告などをユーザに伝えたい場合、「/etc/motd」ファイルに記述しておくと、ログインに成功したユーザに伝えることができるため、実際によく行われています。しかし、「/etc/issue」と「/etc/issue.net」は、ログインに成功しなくても表示されてしまうメッセージなので、不特定多数、場合によっては悪意ある人物に対しても情報を提供してしまう可能性があります。そのことも頭に入れた上で編集を行うのが適切な活用方法でしょう。

「/etc/issue」ファイルはログイン前、「/etc/motd」ファイルはログイン後のメッセージを記述するファイル。しっかり覚えておきましょう。

インデックスに戻る

「/etc/hosts.allow」ファイル、「/etc/hosts.deny」ファイル

今回は、「/etc/hosts.allow」ファイル、「/etc/hosts.deny」ファイルについて見ていきましょう。

/etc/hosts.allow、/etc/hosts.denyは、自ホスト（つまり、自分のコンピュータ）へのアクセスを制御するためのファイルです。これらのファイルは「TCPWrapper」によって参照され、アクセス制御が実現します。基本的にはスーパーデーモン（xinetd）経由で起動されるデーモンへのアクセス制御を行いますが、「sshd」などスーパーデーモンを経由しないものでもアクセス制御を行えるものもあります。libwrapライブラリがリンクされていればTCPWrapperでのアクセス制御が行えます。

「/etc/hosts.allow」ファイルにはアクセスを許可するサービスとホストを、「/etc/hosts.deny」ファイルにはアクセスを拒否するサービスとホストを記述します。

記法は次の通りです。

--
デーモン名: IPアドレスまたはホスト名
--


例を見てみましょう。

○/etc/hosts.allowファイル設定例
--
in.telnetd: 192.168.0.
in.ftpd: 192.168.0.  host.example.com
sshd: 192.168.0.  host.example.com
--


○/etc/hosts.denyファイル設定例
--
ALL: ALL
--

(「#」で始まる行はコメントで、無視されます）


上の例でIPアドレスが「192.168.0.」となっていますが、これは書き間違いではなく、IPアドレスが「192.168.0.」で始まるホストすべてが該当するということです。「ALL」は全てのデーモン、全てのIPアドレスを意味します。

この設定は、以下のように働きます。

1. /etc/hosts.allow に記述されたホストからのアクセスが許可される
2. 1.に該当しなかった場合、/etc/hosts.denyに記述されたホストからのアクセスが拒否される
3. 1.にも2.にも該当しなかった場合、アクセスはすべて許可される

つまり、上のように記述すると、/etc/hosts.allowに記述されたホストからのサービスへのアクセスは許可され、それ以外はすべて拒否されるということになります。

上の設定例のように、「基本的にアクセスを拒否し、必要なものだけを許可する」という設定は、セキュリティを考える時に基本となる考え方です。ただし、正しく設定しないと必要なアクセスも拒否されてしまいますので、正しい設定を心がけてください。間違えて/etc/hosts.allowに「ALL:ALL」と記述して、すべてアクセスできる、というようなことのないようにしましょう。

インデックスに戻る

「/etc/services」ファイル

今回は、「/etc/services」ファイルについて見ていきましょう。

/etc/servicesファイルは、TCPやUDPのポート番号と、そのポートを利用するサービス（あるいはプロトコル名）の情報を対応させるファイルです。

実際に/etc/servicesファイルの内容を見てみましょう。

--
ssh            22/tcp                          # The Secure Shell (SSH) Protocol
ssh            22/udp                          # The Secure Shell (SSH) Protocol
--

「#」以降はコメントで、無視されます。


ポート番号22は、通常はSSHプロトコルの通信で利用されます。上の記述は、TCPとUDPの22番ポートに「ssh」という名前をつけています。これにより、ユーザは「22番ポートはSSHプロトコルで利用されるのだな」と分かります。

「/etc/services」ファイルが利用される例として、たとえばnetstatコマンドを実行してみると次のように表示されます。

--
$ netstat -atu
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 0.0.0.0:ssh                 0.0.0.0:*                   LISTEN
tcp        0      0 0.0.0.0:smtp                0.0.0.0:*                   LISTEN
--

ここで、「ssh」や「smtp」と表示されている部分がありますが、これは本来は「ポート番号22番」および「25番」を意味します。netstatコマンドが/etc/servicesを参照して、ポート番号からサービスの名前に変換を行っています。

netstatコマンドは-nオプションをつけて実行することで名前解決を行わなくなります。以下がその結果です。

--
$ netstat -atun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN
tcp        0      0 0.0.0.0:25                  0.0.0.0:*                   LISTEN
--

名前解決が行われなくなることで、ポート番号も/etc/servicesを参照せず、ポート番号をそのままで表示しています。

このように/etc/servicesがポート番号とサービスの紐付けをしていることは、実は以前紹介した/etc/nsswitch.confの中に書かれていますので、探してみてください。

なお、/etc/servicesファイルの内容は、IANAで管理されているポート番号とそのサービスの対応が記述されているわけですが、正式なものはWebサイトで参照できます。

○Service Name and Transport Protocol Port Number Registry
http://www.iana.org/assignments/port-numbers

インデックスに戻る

「/etc/shadow」ファイル

今回は、「/etc/shadow」ファイルについて見てみましょう。

「/etc/shadow」ファイルは、シャドウパスワードの仕組みで利用されています。シャドウパスワードとは、パスワードのデータを一般ユーザから見えないようするための工夫です。元々、パスワードは「/etc/passwd」ファイルに記述されていましたが、「/etc/passwd」ファイルはシステムのユーザであれば誰でも読み取りができてしまいます。

そこで、パスワードを「/etc/shadow」ファイルに格納し、「/etc/passwd」ファイルにはパスワードを記述しないという形をとっています。「/etc/shadow」ファイルは所有者（通常はroot）以外は読みとることができないようになっており、一般ユーザでは参照できないようにパーミッションが設定されています。

○/etc/shadowの内容（抜粋）
root:$6$Gqkj$ineQdmecDZmoHTIVdMujC2xc68xQ3MpYMts:15500:0:99999:7:::
bin:*:15204:0:99999:7:::
・
・
apache:!!:15500::::::
・
・
user1:$6$BTGO$QLWMfhH10k1nNpEOtYSRVbjEV4csksqrs0:16636:0:90:7:::


各行に、パスワード情報が記述されています。「:」で各情報が区切られています。記法は以下の通りです。

第1フィールド：ユーザ名
第2フィールド：パスワード
第3フィールド：パスワードを最後に変更した日
第4フィールド：変更可能最短期間
第5フィールド：未変更可能最長期間
第6フィールド：未変更時警告日
第7フィールド：ログインしない場合に無効になる日数
第8フィールド：アカウントが失効になるまでの日数
第9フィールド：フラグ

第2フィールドのパスワードは暗号化されていて、一見しただけでは元のパスワードは分からない文字列になっています。第2フィールドが「*」になっている場合は、パスワードが設定されておらず、そのユーザはログインできません。これは、システムがプログラムを動作させるために作成したユーザなどに使用されます。

パスワード欄の頭に「!!」を付けると、「アカウントロック」という状態になります。この場合は、そのユーザはログインできなくなります。

○アカウントロックの例
user1:!!$6$BTGO$QLWMfhH10k1nNpEOtYSRVbjEV4csksqrs0:16636:0:90:7:::

アカウントロックは、passwdコマンドに-lオプションを付けることで実現できます。第2フィールドが「!!」だけとなっている場合には、パスワードが未設定ということになります。

第4フィールドから第8フィールドの内容は、usermodコマンドやchageコマンドなどを実行することで設定できます。

現在ではほとんどのディストリビューションでシャドウパスワードを採用しています。LPICの試験範囲でもありますので、必ず押さえておきましょう。

インデックスに戻る

「/etc/passwd」ファイル

今回は、「/etc/passwd」ファイルについて見てみましょう。

「/etc/passwd」ファイルは、ユーザのアカウント情報が格納されたファイルです。
--
$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
・
・
user01:x:500:500::/home/user01:/bin/bash
--

各行に、アカウント情報が記述されています。「:」で各情報が区切られています。記法は以下の通りです。

第1フィールド：ユーザ名
第2フィールド：パスワード
第3フィールド：ユーザID
第4フィールド：グループID
第5フィールド：コメント欄
第6フィールド：ホームディレクトリ
第7フィールド：ログインシェル

このファイルは、各ユーザがシステムにログインする際などユーザ情報が必要なときに参照されるファイルです。そのため、パーミッションは一般ユーザでも参照できるよう、その他のユーザにも読み取り権限が付与されています。

ところで、このファイルの各行の第2フィールドは本来パスワードが記述されるのですが、大抵の場合、この部分が「x」となっています。「シャドウパスワード」と呼ばれる仕組みを利用している場合にこのようになります。
この場合、パスワードは「/etc/shadow」ファイル（次回取り上げます）に書かれています。

なお、この「/etc/passwd」ファイルを直接編集する際には、viなど普通のエディタで編集することは避け、「vipw」コマンドを利用するようにしてください。vipwコマンドは、「/etc/passwd」ファイルを編集している時に、他のプロセスから「/etc/passwd」ファイルが変更されないようにロックをかけるという役割があります。また、当然のことですが編集には十分注意してください。不適切な編集を行うと、ユーザがシステムにログインできなくなってしまいます。そのため、ユーザ情報を変更するにはvipwで直接/etc/passwdを編集するのではなく、usermodコマンドなどを使って行うのが望ましいでしょう。

インデックスに戻る

「/etc/nsswitch.conf」ファイル

今回は、「/etc/nsswitch.conf」ファイルについて見ていきましょう。

「/etc/nsswitch.conf」ファイルは、名前解決を行う優先順位を指定するファイルです。具体的に、/etc/nsswitch.confファイルの設定例を見てみましょう。

--
hosts: files dns
--

この設定は、「ホスト名に関する名前解決を行う順が、ローカルにあるファイル→DNSサーバ」ということを表します。具体的には、何らかの名前解決を行う際、まずfilesの指定によりローカルにあるファイル（/etc/hostsなど）が参照され、これに失敗するとdnsの指定により「/etc/resolv.conf」に指定したDNSサーバに問い合わせが行われる、という順になります。

この順番が大きな意味を持つのは、問い合わせた情報に対する応答が異なる場合です。たとえば、「/etc/hosts」には「www.example.com」のIPアドレスが「192.168.1.1」と記してあり、DNSサーバで問い合わせると「192.168.254.254」と返ってくる場合です。この場合、上記の設定では、名前解決の結果、「www.example.com」のIPアドレスは「192.168.1.1」が得られるということになります。

さて、実際の「/etc/resolv.conf」を見てみると、「passwd:」「shadow:」などで始まる行が存在することに気づくでしょうか。実はこのファイル、名前解決だけでなく、ユーザアカウント情報、シャドウパスワードなど、さまざまな情報を参照する際の優先順位を指定するために利用されるのです。
たとえば上記のpasswd:やshadow:は、OpenLDAPに認証情報を格納する場合などに書き換えることになります。

システムを動かすための情報の参照先を切り替えるnsswitch.conf、しっかりと覚えておきましょう。

インデックスに戻る

「/etc/resolv.conf」ファイル

今回は、「/etc/resolv.conf」ファイルについて見てみましょう。

「/etc/resolv.conf」ファイルは、名前解決（ホスト名からIPアドレスを調べること）の設定を行うファイルです。実例を見てみましょう。

--
nameserver     192.168.0.1
nameserver     192.168.0.2
domain         localdomain
search         dm1.example.org   dm2.example.org
--

「nameserver」の後ろには、そのコンピュータが名前解決に利用するDNSサーバのIPアドレスを記述します。記述するIPアドレスは、グローバルIPアドレスでもプライベートIPアドレスでも構いません。また、nameserverは複数指定することができます。複数指定した場合は、まず最初に指定したDNSサーバに問い合わせを行い、解決できなかった場合は2番目に指定したDNSサーバに問い合わせる、という具合に動作します。

「domain」の後ろには、通常はそのコンピュータが所属するドメインを指定します。このようにすると、名前解決の際にホスト名だけを入力したとき、domainの後ろに記述したドメイン名を付加して名前解決を行ってくれます。
たとえば、

--
$ ssh host01
--

のようなコマンドを実行すると、

--
$ ssh host01.localdomain
--

を実行したのと同じことになる、ということです。多くの場合、そのコンピュータが存在するネットワークの上にあるホストを頻繁に利用することになるため、domainにはそのホストが属するドメインを指定して、ホスト名（FQDNの最初のピリオドまでの部分）だけを指定すればそのホストにアクセスできるようにすることが一般的です。

「search」は、「domain」を複数指定できるようにしたものです。上の設定例の下で

--
$ ssh host01
--

を実行した場合、まず「host01」で名前解決を試み、失敗すると
「host01.localdomain」を、それも失敗すると
「host01.dm1.example.org」、「host01.dm2.example.org」の順で名前解決を試みます。

実は他にもいくつか記述できる項目があるのですが、最低限必須と言えるのは「nameserver」の記述です。DNSに対する名前解決の動作がおかしい場合には、nameserverが適切に設定されているかを確認する必要があるでしょう。また、domainやsearchは頻繁に使用するドメインなどがある場合に設定しておくと便利でしょう。

インデックスに戻る

/etc/hosts」ファイル

今回は、「/etc/hosts」ファイルについて見てみましょう。

「/etc/hosts」ファイルは、ホスト名とIPアドレスを対応させるためのファイルです。ひとまず実例を見てみましょう。

--
127.0.0.1   localhost localhost.localdomain
192.168.0.10  station10  station10.example.net
192.168.0.11  station11  station11.example.net
--

各行に、IPアドレスと、それに対応するホスト名が記述されています。したがって、たとえば上記のような/etc/hostsがあった場合、たとえば次のように実行すると、IPアドレス192.168.0.11のホストにSSHで接続できます。

--
$ ssh station11.example.net
--

さて、DNSのことを学んでいる方であれば、ここで「それはDNSに対応していれば、DNSがやってくれることでは？」と思うことでしょう。その通りです。/etc/hostsの存在を理解するには、その歴史的背景を理解しておく必要があります。

DNSが普及する前、名前解決（ホスト名をIPアドレスに変換すること）はDNSでなく、この/etc/hostsの記述に則って行われていたのです。すなわち、/etc/hostsにインターネット上のホストの一覧がずらりと並んでいたのです。
インターネットというものがまだそれほど大きくなかった時代の話ですので、それでも何とか名前解決というものができたのです。

しかし、インターネットが大きくなり、/etc/hostsに頼る方法では埒があかないという状態になってから、DNSが開発され、/etc/hostsはその役割をDNSに譲ったというわけです。

より詳細な経緯は、以下のページが参考になります。

○Domain Name System (DNS) History
http://www.livinginternet.com/i/iw_dns_history.htm

○DNSの歴史（第1回 「HOSTSファイルの崩壊」）
http://itpro.nikkeibp.co.jp/members/ITPro/ITARTICLE/20010223/1/

では/etc/hostsは無用の長物なのかというと、必ずしもそうとは言い切れません。DNSサーバを構築設定するほどでもない小規模な検証環境などでは、各ホストの/etc/hostsを設定すれば名前解決が行えます。ただし、ほとんどのディストリビューションではDNSよりも/etc/hostsを優先して名前解決を行います。実在するホスト名を/etc/hostsに記述した場合には、想定外のIPアドレスが返ることでホストにアクセスできない（別のIPアドレスに接続しようとする）ことがあるので、注意が必要でしょう。

インデックスに戻る

「/etc/fstab」ファイル

今回は、「/etc/fstab」ファイルについて見てみましょう。

「/etc/fstab」ファイルは、マウントするファイルシステムの情報を記述するファイルです。OSを起動する際には、システムがデバイスをディレクトリにマウントしますが、その際、どのデバイスにどのディレクトリをマウントするか、の処理は、「/etc/fstab」ファイルの記述に従って進行します。

「/etc/fstab」ファイルの内容は、mountコマンドと切っても切れない関係にあります。mountコマンドは、たとえば次のように実行します。

# mount -t ext4 /dev/sda1 /home

このコマンドは、「/dev/sda1デバイス」を、「/home」ディレクトリにマウントする、という操作を実行します。一方、「/etc/fstab」にたとえば次のような１行があったとします。

/dev/sda1        /home           ext4    defaults        1 1

この１行があると、OSを起動する際、上記のmountコマンドを実行したのと同じという状態になります。また、OSを起動した後でも、たとえば

/dev/cd0c       /cdrom           cd9660  ro,noauto       0 0

という１行があったとすると（4つ目の「noauto」は、OS起動時にマウントしないというオプションです）、

# mount /cdrom

と実行するだけで、

# mount -t cd9660 -o rdonly /dev/cd0c /cdrom

を実行したのと同じことになります。

「/etc/fstab」の記法は、以下の通りです。

第1フィールド：デバイス名
第2フィールド：マウントポイント
第3フィールド：ファイルシステムの種類
第4フィールド：各種オプション
第5フィールド：ファイルシステムをdumpするか否かの指定
第6フィールド：OS起動時にfsckチェックを行うか否かの指定を行う

OSを管理・運用する際に重要なファイルですので、必ず覚えておきましょう。

インデックスに戻る

「/etc/inittab」ファイル

今回から、Linuxで利用される重要なファイルを1つずつ見て行くという形でお送りします。1回目となる今回は、「/etc/inittab」ファイルについて。

/etc/inittabファイルはOSを起動する際、OSの起動を司る「initプロセス」が利用するファイルです。このファイルには、デフォルトのランレベルの指定、デバイスなどの初期化、initの起動、ブート時の処理、ランレベルごとのrcスクリプトの実行などを指示します。中には、[Ctrl]＋[Alt]＋[Delete]キーを押したときの処理の指示も記述されています。このように、/etc/inittabファイルは、OSを起動し、適切に設定するために必須のファイルと言えるのです。このため、LPIC 101の出題範囲にも含まれています。

それでは、/etc/inittabを実際に見てみましょう・・・と言いたいところなのですが、その内容はディストリビューションとバージョンによって大きく異なります。たとえばCentOS 6系列では、/etc/inittabには、デフォルトのランレベルを指定する「id:5:initdefault:」という記述しか見当たりません。これは、最近のinitプロセスは「/etc/init」というディレクトリに存在する、複数の設定ファイルに設定を記述するように変更されたためです。
したがって、OSの起動などに関する設定をカスタマイズしたい場合は、このディレクトリ配下にあるファイルを編集することになります。

また、CentOS 7系列では、「init」に代わって「systemd」と呼ばれる、新しい起動プログラムが採用されています。このため「/etc/inittab」ファイルは、互換性を保つためにのみ存在します。systemdが利用するファイルは、「/etc/systemd/」ディレクトリ配下に存在する複数のファイルです。

インデックスに戻る

FHS（Filesystem Hierarchy Standard）

今回から、Linuxを動作させるのに必須な「ファイル」を見ていくことにしましょう。その前準備として、「FHS（Filesystem Hierarchy Standard）」について紹介します。

「FHS」は、Linux（などのUNIX系OS）の標準的なディレクトリ構成を定めた標準仕様です。たとえば「/etcディレクトリには設定ファイルを置きましょう」など、ディレクトリの名前や構成、ファイルの名前などについての「標準」です。

いま現在Linuxをある程度勉強している人であれば、「/etcディレクトリ」は「設定ファイルを置くところ」というのは、ほぼ常識になっていると思います。しかし、以前はあくまで慣習であり、明確な明文化された取り決めがありませんでした。このため、システム、ディストリビューションによって、どのディレクトリにどのファイルがあるのかがまったく異なっているという状況だったのです。

このような状況は、「わかりにくい」というのが１つ困ったところになりますが、さらに「トラブルの原因になる」ということもあり得ます。たとえば共有ライブラリなどがどこにあるのかわからない、名前も違うという状況になってしまうと、ソフトウェアのインストールが上手くいかない、インストールできても正しく動作しないなどのトラブルが考えられるわけです。こういった不都合を少しでも減らそうと、FHSが策定されたのです。

現在のFHS（FHS 2.3）で規定された、ルートディレクトリ直下のディレクトリで必須とされているものは、「/bin」「/boot」「/dev」「/etc」「/lib」「/media」「/mnt」「/opt」「/sbin」「/srv」「/tmp」「/usr」「/var」の13個です（「/home」「/root」についてはオプションとして規定）。もちろん、FHSに策定されているものはこれだけではなく、さらに下層のディレクトリ（「/usr/share」など）についても言及されています。

FHSの仕様書は、Webサイト（http://www.pathname.com/fhs/）から入手することができます。少し長いのですが、時間があるときに一度目を通しておくとよいでしょう。

インデックスに戻る

Unity

今回は、デスクトップ環境「Unity」について紹介します。

Unityは、Ubuntuに標準搭載されているデスクトップ環境で、「GNOME 3」をベースとしたデスクトップ環境です。なお、厳密に言うと「Unity」はGUIシェルの名前だという議論もあるのですが、今回はデスクトップ環境の１つとして紹介します。

Unityが提供するユーザインターフェイスは、画面の左端に「ランチャー」と呼ばれる、アイコンを表示させる領域があり、ここからソフトウェアを起動させます。画面上部には「アプリケーションメニュー」があり、アプリケーションの操作を行うことができます。Unityでは、アプリケーションごとのウインドウでメニューを表示する形式ではなく、現在アクティブな状態になっているアプリケーションのメニューのみを、この画面上部領域に表示するという形式を取っています。

Unityは、PCのデスクトップとしての用途だけを睨んだものではなく、スマートフォンやタブレットなどでの利用も考えに入れた構成になっています。独特の使い勝手はこの方針のためだと言うことができます。

Unityを動作させるためには、3Dアクセラレーションが利用できるグラフィックハードウェアが必要になります。このため、動作させるためにはそれなりのスペックが必要となり、古いPCで動作させるのは厳しいといったケースもあります。

現在、UnityはUbuntuのデフォルトのデスクトップ環境ですので、Unityを試用したい場合はUbuntuを入手すれば簡単に使えます。是非、試してみてください。

インデックスに戻る

デスクトップ環境「Cinnamon」と「MATE」

今回は、デスクトップ環境「Cinnamon」と「MATE」について紹介します。

CinnamonとMATEはそれぞれ別のデスクトップ環境ですが、共通点があります。その共通点とは、どちらも「GNOME 2」系列に連なるデスクトップ環境であるということです。現在GNOMEは「GNOME 3」ですが、GNOME 2の使い勝手が良かったという評判から、「Cinnamon」はGNOME 3をベースにGNOME 2の使い勝手を実現する方向で開発され、MATEはGNOME 2をベースとして開発されました。

両者はGNOME 2の使い勝手を実現するのが目的のため外観が似ているとも言われますがいずれも独立したプロジェクトです。両者の違いを言うのは難しいのですが、あえて簡単に言うと、「Cinnamon」が多機能・高いカスタマイズ性を持っているのに対し、「MATE」は設計をある程度シンプルに絞り、低スペックなPCでも軽快に動作するようになっている、と言うことができます。

いずれも「Linux Mint」のデフォルトのデスクトップ環境として提供されていますので、一度試してみて下さい。

インデックスに戻る

デスクトップ環境「LXDE」「LXQt」

今回は、デスクトップ環境「LXDE」「LXQt」について紹介します。

LXDE、LXQt共に、GNOMEやKDEと同じようにウィンドウマネージャ、ファイルマネージャなどのソフトウェアをまとめたデスクトップ環境の1つです。
LXDEはC言語で実装され、GTK+ツールキットを利用しています。一方、LXQtはC++で実装され、Qtツールキットを利用しています。LXQtはLXDEをQtを用いて書き換えたもの、と言うことができます。

LXDE、LXQtは、Windowsに似たインターフェイスを提供し、初心者にも使いやすいデスクトップ環境となっています。また、軽量に作られており、スペックの低いPCでも動作します。前回紹介したXfceと同様、低スペックのPCでも動作しますので、古くなって使い道のなくなったPCを有効活用することができます。

Xfceと共に、軽快な動作をするデスクトップ環境として、是非覚えておいて下さい。

インデックスに戻る

Xfce

今回は、デスクトップ環境「Xfce」について紹介します。

Xfceは、GNOMEやKDEと同じように、ウィンドウマネージャ、ファイルマネージャなどのソフトウェアをまとめたデスクトップ環境の1つです。1997年に開発が開始されたデスクトップ環境で、当初はFormsツールキットを利用した「XForms Common Environment」の略として「XFce」と呼ばれていました。現在ではXFormsを利用していないため、「Xfce」が正式表記となっています。

Xfceは、KDEなどと異なり、Windowsとは少し異なる、昔ながらのインターフェイスを提供します。このため、初心者には若干とっつきづらいところがあるかもしれません。しかし、Xfceの特徴は何といっても「軽快に動作する」という点にあります。GNOMEやKDEと比べ機能数が特に少ないわけではないと言われますが、軽量であることは特筆に値します。かなり古い、あるいは低スペックなPCでも利用できます。

Linuxのメリットとして、低スペックPCでも動作するという点がありますので、Xfceは是非覚えておきたいデスクトップ環境です。

インデックスに戻る

KDE

今回は、デスクトップ環境「KDE」について紹介します。

KDE（K Desktop Environment）も、前回紹介した「GNOME」と同じく、ツールバーやウィンドウマネージャ、ファイルマネージャなどのソフトウェアをまとめたデスクトップ環境の1つです。GNOMEがGUIツールキットとしてGTK+を採用しているのに対し、KDEはQtを採用しています。

なお、KDEは、正式にはソフトウェアの名前ではありません。デスクトップ環境の名前は「KDE SC」（Software Compilation）であり、「KDE」は、KDE SCを中心としたアプリケーションを開発するプロジェクトの名称です。

KDEは、デフォルトではWindowsに似たインターフェイスを提供しますが、さまざまなテーマが用意されているため、様々な使い勝手のデスクトップを切り替えて利用できる点が１つの特徴です。

KDEの特徴は、もう1つ多機能であるという点が挙げられます。それゆえにKDEを動作させるために要求されるコンピュータのスペックも高いものが要求されます。以前はGNOMEのほうが軽量であったため、そこがKDEとGNOMEの大きな差異だと言われていた時代もありましたが、最近ではGNOMEも多機能になり、かつコンピュータのスペックが底上げされたため、最近ではそれほど大きな差がなくなってきたと言われています。

KDEも、GNOMEと双璧をなすデスクトップ環境ですので、必ず覚えておきましょう。

インデックスに戻る

GNOME

今回は、デスクトップ環境「GNOME」について紹介します。

まず、デスクトップ環境とは、以前も取り上げたように、「X Window System」や「Wayland」の上で動作する、GUIによる作業環境を提供するものです。ツールバーやアイコン、ウィンドウマネージャ、ファイルマネージャなどのソフトウェアをまとめたもので、「デスクトップ作業を行うのに必要なソフトウェアのセット」と言うことができます。

GNOMEは、GNUプロジェクトの一部として開発されており、すべてをフリーソフトウェアで作るというポリシーの下で開発されています。「グノーム」と読む人が多いのですが、Gを発音せず「ノーム」と読む人もいます。1999年に開発が始まっており、比較的長い歴史を持っています。

GNOMEは、登場当初、WindowsやMac OS Xに似たインターフェイスを提供したため、Linux初心者の人気を集めました。その反面、高いカスタマイズ性を持ち、ユーザの好みの通りのデスクトップを構築できるという特徴もあり、またWaylandとの親和性も向上していることから、今なお多くの人が利用するデスクトップ環境です。

GNOMEを語る上で忘れることができないのが、ファイルマネージャ「Nautilus」です。Nautilusは、ファイルやディレクトリのブラウズだけでなく、Webサイトのブラウズも行うことができるソフトウェアで、ファイルやアプリケーション、インターネット上のリソースなどを統合し、リソースに素早くアクセスできるようになっています。

多くのディストリビューションでも採用されているため、必ず覚えておきたいデスクトップ環境です。

インデックスに戻る

Wayland

サーバソフトウェア紹介の第18弾は、「Wayland」について。

「Wayland」は、「X Window System」の代替を目指しているシステム、およびライブラリです（ソフトウェアの名前ではなく、システムとライブラリを指す名前ですので注意して下さい）。X Window Systemのフォークという形ではなく、全く新しいシステムとして開発されています。一方、WaylandはXサーバと対話する仕組みを備えているため、X Window Systemで動作するツールは基本的にWaylandでも利用できるということが特徴です。なお、Waylandのリファレンス実装は「Weston」と呼ばれるソフトウェアです。

ただし、Waylandは、X.Org Serverが採用している「ネットワーク透過型」ではなく、基本的に同じコンピュータ上でアプリケーションの実行と描画を行うシステムになっています。そのため、X.Org Serverよりも軽量なシステムを実現でき、軽快で高速なウィンドウシステムを提供することを目的にしています。

WaylandとX Window Systemのどちらが優れているとは言えません。用途にもよりますし、またWaylandは2008年に開発が開始された歴史の浅いシステムで、発展途上にあるとも言えます。最近、UbuntuやFedoraなどで、X Window Systemの代わりにWaylandを採用するという動きも出ていますが、X Window Systemにもネットワーク越しに利用することができるという特徴がありますし、どちらが優れているかというのはケースバイケースということになるでしょう。Waylandの登場で、X Window Systemについても何らかの動きが見られるかもしれません。

今後のWaylandとX Window Systemの動向に注目しましょう。

インデックスに戻る

X.Org Server

サーバソフトウェア紹介の第17弾は、「X.Org Server」について。

「X.Org Server」は、UNIX系OSにおいてGUIを提供する「X Window System」のソフトウェアです。

「X.Org Server」は、その名前の通り、サーバ・クライアント方式を採用しています（このことに関しては以前にも少し触れました）。このため、ネットワーク経由でX Window Systemを利用する、リモートのコンピュータで実行しているアプリケーションを自分のモニターに表示させる、などといったこともできます。X.Org Server（Xサーバ）が画面表示などを担当し、各種アプリケーションがクライアント（Xクライアント）ということになります。一般的なサーバ・クライアントの形式とは若干異なるので間違えやすいところです。もし、サーバとクライアントの間をセキュアに接続したい場合には、OpenSSHを使ったポート転送で接続する、というテクニックもあります。

X.Org Serverが使用するプロトコルは「X11」と呼ばれることもあります。
これは、プロトコルのバージョン番号が11番であることに由来します。ただし、「X11」となったのは1987年ですから、このプロトコルになったのは実に25年以上も前だと言うことができます。

X.Org Serverは、歴史も古く、多機能であり、何といっても高い安定性を持っていることから、UNIX系OSでは事実上GUIを提供するための標準システムとなっています。しかし、最近はその有力な対抗馬と目される「Wayland」と呼ばれるアプリケーションが台頭してきました。次回はWaylandについて
紹介します。

インデックスに戻る

PostgreSQL

サーバソフトウェア紹介の第16弾は、「PostgreSQL」について。

SQLは、以前紹介したように、「リレーショナルデータベース」を制御するための言語です。多彩かつ柔軟にリレーショナル型データベースを操作できるため、広く採用されています。PostgreSQLは、リレーショナルデータベースを、SQLを利用して制御するためのソフトウェア、すなわち「リレーショナルデータベース管理システム（RDBMS）」の1つです。

「PostgreSQL」は、1986年に開発が始まった「Postgres」と呼ばれるソフトウェアが原型になっており、歴史のあるソフトウェアだと言うことができます。その長い歴史の中で、時代に合わせた進化を遂げています。並列実行の機能に力を入れており、複数のCPUで動作させる際のスケーラビリティが高いと言われています。安定性にも優れ、大規模システムでの利用にも耐えうる作りになっています。実際、大規模なシステムにおけるPostgreSQLの採用実績も数多く存在します。もちろん、小規模システムでも全く問題なく利用できます。

RDBMSは、動的Webサイトの構築などの際には欠かせないものですが、それ以外にもさまざまな場面で必須になってきます。PostgreSQLは、必ず押さえておきたいソフトウェアの1つだということができるでしょう。

インデックスに戻る

OpenSSH

サーバソフトウェア紹介の第15弾は、「OpenSSH」について紹介します。
以前、1度取り上げたソフトウェアですが、ソフトウェア紹介の一環として、改めて紹介します。

「SSH」は、暗号化通信を行う際に利用されるプロトコルです。認証も含め、ネットワーク上の全ての通信が暗号化された上でやりとりされます。

以前、ネットワークを流れる通信はすべて暗号化されない平文でやりとりされていましたが、インターネットが普及し、セキュリティへの意識の高まり、および脅威の増加に伴い、平文でのやりとりは行われなくなり、代わりにSSHなどを利用した暗号化通信がメインになってきています。

OpenSSHは、OpenBSD Projectによって開発が行われています。OpenBSD Projectは、高いセキュリティを提供することを目標に活動を行っており、その成果物の1つとして、OpenSSHが提供されているのです。

OpenSSHは、Linuxでも広く採用されており、事実上の標準ソフトウェアとなっています。OpenSSHには、サーバ・クライアントの双方が含まれており、OpenSSHはサーバ・クライアントのどちらとしても利用できます（別々にインストールすることも可能です）。また、サーバ・クライアントだけでなく、暗号化した上でftpのようにファイルのやりとりを行う「sftp」や「scp」などのツール群も含まれており、非常に多機能なソフトウェアとなっています。また、暗号化機能のついていない他のソフトウェアと連携させ、ソフトウェアに暗号化通信機能を持たせるということもできます。

危険地帯とまで言われるインターネットでは、今や必要不可欠と言えるようになったSSH。ひとまず利用するのは簡単なのですが、非常に多機能ですので、使いこなさないのは勿体ないですから、使い方をしっかり勉強しておくとよいでしょう。

インデックスに戻る

OpenLDAP

サーバソフトウェア紹介の第15弾は、「OpenLDAP」について紹介します。

LDAPは、「Lightweight Directory Access Protocol」の略で、階層型のディレクトリデータベースにアクセスするためのプロトコルです。ディレクトリサービスとは、ユーザ名やホスト名などの情報を管理することが目的となっており、複数のコンピュータでユーザ情報を一元管理したいという場合に利用します。たとえば、教育機関や企業などで複数のコンピュータがあり、ユーザも複数存在するというケースでよく利用されます。

「OpenLDAP」は、LDAPによるディレクトリサービスを提供するオープンソースソフトウェアです。1998年に開発が始まり、現在ではオープンソースのシステムで利用される事実上のLDAP標準ソフトウェアとなっています。

OpenLDAPは、LDAPサービスはもちろんのこと、LDAPを利用する上で非常に重要になるSASL認証への対応やレプリケーション機能など、数多くの機能を持っています。さまざまなソフトウェアとの連携にも対応しており、たとえばSambaと連携させてドメインコントローラを構築することもできます。

少々難易度が高いとも言われるOpenLDAPですが、LPIC 300などの出題範囲にも含まれますので、ぜひ学んでみてください。

インデックスに戻る

Samba

サーバソフトウェア紹介の第14弾は、「Samba」について紹介します。

「Samba」は、LinuxやBSDなどのUNIX系OSをWindows Networkに参加させるためのソフトウェアです。Sambaを利用すると、Linuxなどのマシンに、Windows Networkを経由したファイルサーバ、プリンタサーバ、ドメイン参加機能、ドメインコントローラ機能などを持たせることができます。

Windows Networkでは、Windows同士のファイル共有、プリンタ共有ができるほか、コンピュータ名の管理などを行うことができます。Windows Networkで利用されているプロトコルに「SMB（Server Message Block）」と呼ばれるものがあり、この「SMB」に母音をつけ足して「Samba」という名前になっています。

ファイル共有機能は、特に企業など団体でコンピュータを利用するときには必須と言えます。ファイルのやりとりを内部で頻繁に行うほか、ファイルの管理などを行うには、１箇所で重点的に管理するのが効率的だからです。
Windowsネットワークでファイルサーバやドメインコントローラの役割を持たせるのは、本来ではWindows Serverの役割ですが、これをUNIX系OSで実現できるのがSambaということができます。Sambaは、ほとんどの場合「イントラネットサーバ」、すなわちLAN内でのみ利用できるサーバとして運用されます。

UNIX系OSでファイルサーバやドメインコントローラを運用するメリットはいくつかあります。一つはライセンスコストの面でWindowsに比べて有利であること、Windows向けのウィルスに感染しにくいこと、他のサーバソフトウェアと共に一つのマシンで運用することができることなどが挙げられます。

SambaはLPIC 202や300の試験範囲にも入っていますし、Linuxを学んだ人ならば一度は使ってみて欲しいソフトウェアです。ぜひ取り組んでみてください。

インデックスに戻る

DNSサーバ「djbdns」

サーバソフトウェア紹介の第12弾は、DNSサーバ「djbdns」について紹介します。

「djbdns」は、BINDの代替を目指して開発が行われているDNSサーバソフトウェアです。BINDとは対照的にシンプルな構造で、その代わりセキュリティに大きな配慮がなされています。また、「Unbound」と異なり、キャッシュサーバ・コンテンツサーバのどちらとしても利用できます。キャッシュサーバとコンテンツサーバは別々に動作するため、コンテンツサーバとして公開していたのに意図せずキャッシュサーバとしても動作してしまった、というトラブルが予防できるようになっています。

開発者は、Daniel Bernstein氏です。qmailと呼ばれるSMTPサーバの開発者でもあります。qmailも、djbdns同様、シンプルでセキュアであることを特徴としたMTAです。Daniel Bernsteinは、djbdnsのセキュリティホールの第一発見者へ懸賞金を贈ると発表していたという経緯があります。セキュリティに関する自信の表れと言えるでしょう。もっとも、2009年にキャッシュポイズニング攻撃を受ける脆弱性が発見され、懸賞金が支払われました。

完璧とも思われるdjbdnsですが、Daniel Bernstein氏が新機能の導入、たとえばIPv6への対応やDNSSECなどの技術への対応などに消極的だという側面もあります。このため、実用導入には少し検討を要するでしょう。

とはいえ、面白い存在であるdjbdns。その存在は覚えておいて損はないでしょう。

インデックスに戻る

Unbound

サーバソフトウェア紹介の第11弾は、DNSサーバ「Unbound」について紹介します。

「Unbound」は、そのネーミングはずばり「BIND」を意識したもので、なんとも挑戦的なネーミングです。BINDの代替となるDNSサーバを目指して2008年に開発が開始されたもので、その歴史は浅いものの、BINDの有力な対抗馬として注目されています。

Unboundの特徴は、BINDと異なり、機能を絞って設計をシンプルにしている点が挙げられます。設計がシンプルであることから、セキュリティに強く、動作が軽く、また設定が簡単である（BINDと異なり1つの設定ファイルだけで設定が可能）といった特徴があります。ただし、機能を絞っているという点には要注意で、キャッシュサーバとしての機能は揃っているものの、コンテンツサーバとしては利用できません。ただし、DNSSECなどには対応しており、またキャッシュポイズニング攻撃に対する対策も施されているため、DNSキャッシュサーバとしてはBINDと並び立ち、良い選択肢となりうるでしょう。

同じDNSサーバでも、BINDとはまったく異なる立ち位置であるUnbound。キャッシュサーバを構築する際には、利用を検討してみてはいかがでしょうか。

インデックスに戻る

BIND

サーバソフトウェア紹介の第10弾は、DNSサーバ「BIND」について紹介します。

「BIND」とは、「Berkeley Internet Name Domain」の略で、カリフォルニア大学バークレー校で開発されたDNSサーバソフトウェアです。現在では、ISC（Internet Software Consortium）によって開発・配布が行われています。

DNSサーバは、競合するソフトウェアが少ないという状況が長期間に渡ったこともあり、1988年にBINDの開発が開始されて以来、長期間においてBINDがDNSサーバの事実上の標準となっていました。現在でも、DNSサーバの多くが、BINDで動作しています。

BINDの特徴に、その多機能さが挙げられます。DNSサーバとして必要な機能はほぼ全て揃っており、適切に設定すれば、個人用途から大規模向けのサーバ、またコンテンツサーバ・キャッシュサーバのいずれとしても動作します。

BINDは、これまで「BIND4」「BIND8」とリリースされてきましたが、セキュリティの問題、およびDNSSECと呼ばれる仕組みに対応するために、ソースコードが完全に書き直された「BIND9」が現在の最新リリースとなっています。また、正式リリースは未だ先ではありますが「BIND10」の開発が進んでいます。BIND10もまた、BIND9と大幅に異なる設計となっています。

DNSサーバの事実上の標準となっているBIND。現在では競合するソフトウェアも開発されてはいますが、LPICの試験範囲でもありますので、必ず押さえておきましょう。

インデックスに戻る

vsftpd

サーバソフトウェア紹介の第9弾は、FTPサーバ「vsftpd」について紹介します。

vsftpdも、前回紹介した「ProFTPD」と同じFTPサーバです。その名前の由来は「Very Secure FTP Daemon」。その名前が示す通り、セキュリティを強く意識して開発されているソフトウェアです。ProFTPDもセキュリティに高い意識を持って開発されており、FTPがいかにセキュリティに対して注意が必要なものであるかということの表れだと言えます。

vsftpdは、設定ファイル(vsftpd.conf)の記法がProFTPDと大きく異なります。ただし、それほど難解なものではなく、Sambaの設定ファイルなどに近い、比較的スタンダードな記述法です。インストールもそれほど難しくなく、導入の敷居はそれほど高くありません。

vsftpdは、CentOSなど、いくつかのLinuxディストリビューションで標準のFTPサーバとして採用されています。CentOSでは、yumコマンドだけでインストールが可能なため、初心者が学習に利用するにはProFTPDと並んで有力な選択肢になるでしょう。

ProFTPDと並び、FTPサーバとして代表的な存在であるvsftpd。是非覚えておいてください。

インデックスに戻る

ProFTPD

サーバソフトウェア紹介の第8弾は、FTPサーバ「ProFTPD」について紹介します。

FTPサーバは、FTP(File Transfer Protocol）を利用してファイルのやりとりを行うサーバです。ファイルを公開したり、個人的にやりとりをするときに利用されます。

ProFTPDは、1997年に開発が開始されたFTPサーバです。それまでにもUNIX系OSで動作するFTPサーバソフトウェアは他に存在していたのですが、これにはセキュリティに大きな問題がありました。これを受けて、高いセキュリティの下でFTPサーバを運用できることを目指して開発が開始されたのがProFTPDです。2014年現在でも開発が継続され、広く利用されているFTPサーバです。

ProFTPDの特徴の1つに、設定ファイルの記述法があります。設定ファイルは1つだけ(proftpd.conf)で、かつApacheの設定ファイルの記述に似せた形になっているため、Apacheを設定した経験のある人であれば、設定がしやすいということが1つの特徴です。メンテナンスもProFTPDプロジェクトによって継続して行われているため、セキュリティ面の不安も少ないと言えます。

FTPサーバは、さまざまな場面で活躍するもので、インターネットだけでなく、LAN内で応用するというケースもあります。是非チェックしておいてください。

インデックスに戻る

Squid

サーバソフトウェア紹介の第7弾は、プロキシサーバ「Squid」について紹介します。

企業の内部LANから外部のインターネットに接続する際に、プロキシサーバを通すようになっているケースは数多く存在すると思われます。Proxyは「代理」という意味で、外部とのデータのやりとりをチェックして不正な通信などがないかを監視したり、アクセスログを記録するなどの役割を持ちます。

Squidは、1996年に開発が開始されたキャッシュ型プロキシです。HTTP、HTTPS、FTPなどのプロトコルをサポートしており、リクエストの多いデータをキャッシュした上で再利用し、ネットワークの負担を軽減します。「不特定のクライアントから特定のサーバへのリクエストをプロキシする」という、普通のプロキシサーバとは逆の動作をするリバースプロキシとして動作させることもできます。キャッシングの性能が高速であることが特徴で、その他にもアクセス制限やロードバランサなど、さまざまな機能を持っています。

プロキシサーバは、主に企業のネットワークを管理する際に有用なもので、場合によっては必須ともなるものです。Squidは、LPIC 202の出題範囲でもありますので、是非押さえておきましょう。

インデックスに戻る

Courier Mail Server

サーバソフトウェア紹介の第6弾は、メールサーバ「Courier Mail Server」（以下、Courier）について紹介します。

Courierは、オープンソースのメール環境です。POP/IMAPだけでなく、SMTPサーバとしての機能も備えており、メールサーバとしての機能を網羅しているソフトウェアです。Courierは、「qmail」と呼ばれる、非常に堅牢なMTAの考え方を受け継ぎ、かつ設定が簡単なメールサーバを実現するために開発されました。

Courierは、POP/IMAPとしての機能を持たせることができるのが特徴です。
IMAPとして機能するため、クライアントはいちいちメールをダウンロードせずに読むことが可能になります。設定によってはPOP3とIMAP4両方が利用できるようになるため、ユーザの都合に合わせることができ、メールサーバのユーザに高い利便性を提供できます。SSLにも対応しており、セキュリティにも配慮がなされています。

メールサーバを構築する際には、有力な選択肢の一つとなるであろうCourier。MTAはPostfixなどで、POP/IMAPはCourierで、という利用方法もありますので、是非覚えておいてください。

インデックスに戻る

qpopper

サーバソフトウェア紹介の第5弾は、POPサーバ「qpopper」について紹介します。

qpopperは、アメリカのQualcomm社が開発・配布しているPOP3サーバです。
POP3の他、APOPにも対応しています。多くのLinuxディストリビューションで採用されており、SendmailやPostfixによって受信したメールであれば、殆どのメールクライアントから利用できます。設定も難しくないため、広く使われているPOPサーバです。

qpopperは基本的にinetd（スーパーデーモン）経由で動作しますが、スタンドアロンでも動作させることができるという特徴があります。ですから、CPUなどに負荷をかけたくない場合はinetd経由で呼び出し、とにかく高速な動作が必要な場合はスタンドアロンで動作させるというように、必要に応じて使い分けることができます。

APOPも利用できますので、アカウント情報を暗号化して通信させることも可能です。さらに、OpenSSLと組み合わせればメール本文を暗号化してクライアントに送ることもできます。

メールサーバというと、どうしてもMTAのほうに目が行きがちですが、他のクライアントから利用するとなるとMDA（Mail Delivery Agent）が必須となりますので、やはり覚えておきたいソフトウェアとなります。

インデックスに戻る

Postfix

サーバソフトウェア紹介の第4弾は、メール送受信ソフトウェア（MTA）の1つである「Postfix」について紹介します。

Postfixは、1999年に開発が開始されたMTAです。sendmailよりも歴史は浅いのですが、それゆえのメリットもあります。

sendmailは、多機能で柔軟な設定が可能だが設定が難しいという特徴がありました。これに対して、Postfixは設定ファイルの記述方法が「設定項目=値」というスタンダードな形式で、わかりやすいという特徴があります。その代わり、sendmailほどの柔軟さはないとも言われています（もちろん用途によって事情は変わってきます）。sendmailよりも後発であるがゆえ、sendmailのネックである、設定が困難である点が解消されているのは特筆すべき点だと言えます。

Postfixのメリットはもう1つ、sendmailと高い互換性がある、という点にあります。このため、移行が簡単で、またspamフィルターなどのソフトウェアと連携させることも容易です。サポートもこまめに行われており、セキュリティもしっかりしています。

sendmailと並び、MTAとして高いシェアを誇るPostfix。sendmailとともに、必ず押さえておきたいソフトウェアです。

インデックスに戻る

sendmail

サーバソフトウェア紹介の第3弾は、メール送受信サーバ（MTA）の1つである「sendmail」について紹介します。

sendmailは、1980年代に開発が開始された、極めて長い歴史を持つMTAです。その歴史の長さゆえ、MTAの中でもデファクトスタンダードと呼べる地位を築いています。現在では、Sendmail社によって開発・メンテナンスが行われています。

sendmailは、その多機能さに特徴があります。現在主流となっているSMTPによるメール送信だけでなく、現在では使われていないようなメール送信プロトコルもサポートしており、非常に多機能であり、また柔軟な設定を行うことができます。

一方で、その多機能さゆえ、設定するべき事項が多いという事実があります。それだけでなく、設定ファイルである「sendmail.cf」の記述が独特であり、適切な設定を行うためには高いスキルと多くの勉強量が必要になります。

その他、インターネットの普及により、メール流量の増加、高いセキュリティの要求などの問題も生じています。sendmailは歴史が古く、Sendmail社によるサポートもしっかりしているため、これらの問題への対応もしっかりと行われていますが、基本設計がインターネット黎明期のままであり、これに「問題が起こったら対応する」という方針であるため、アプリケーションが肥大化してしまっているという問題も抱えています。

とはいえ、歴史が古く、かつSendmail社によるサポートがしっかりしているというメリットは大きく、また設定ファイルの「sendmail.cf」も、まず「sendmail.mc」という、より簡単なファイルを記述し、これを「m4」というコマンドを通すことでsendmail.cfファイルを生成する、という方法が取れるようになっており、設定の難しさを緩和する方策もきちんと用意されています。

歴史の古さゆえ、シェアの大きなソフトウェアですので、必ずチェックしておきたいソフトウェアと言えるでしょう。

インデックスに戻る

nginx

サーバソフトウェアの紹介、第2弾は「nginx」です。

nginxはオープンソースのWebサーバソフトウェアです。nginxの読み方は「エンジンエックス」です。Webサーバとしての機能のほかに、HTTP、SMTP、POP3、IMAPリバースプロキシ、メールプロキシの機能も併せ持っています。Apacheよりも新しく、2004年に初版がリリースされ、開発が続けられています。2014年3月現在では、世界中のWebサーバのシェアの約16％（Apache、Microsoft IISに続く第三位）を握っているとされています。

nginxの特徴として、特に静的コンテンツに対する処理速度が高速であること、高性能であること、高効率なメモリ利用などが挙げられます。反面、日本ではシェアが低く、日本語の解説書が少ないため、導入の敷居が若干高いという側面もありますが、日本でも根強い愛好者がいます。

動的コンテンツ（Webアプリケーションなど）に対しては、nginxはプロキシサーバとして動作します。これを利用することで、各種Webアプリケーションを公開するWebサーバとして利用することも勿論できます。

Apacheに比べると知名度の点で少し遅れを取りますが、用途や使い方次第ではApacheの強力な対抗馬となりうるソフトウェアですので、チェックしてみてください。

インデックスに戻る

Apache HTTP Server

Linuxディストリビューション紹介も一段落しましたので、今回より、サーバソフトウェアの紹介をしてみたいと思います。第1弾は、「Apache HTTP Server」です。

Apache HTTP Server、単に「Apache」と呼ばれることも多いのですが、このソフトウェアは世界中で広く利用されているWebサーバソフトウェアです。
ほとんどのLinuxディストリビューションにパッケージとして提供されており、使ったことがあるという人も多いと思います。何といっても、大規模なサイトからごくごく内輪のためのサイトまで広い範囲で利用できるため、LinuxでWebサーバといえばApache、という感じもあります。

Apacheが有名な理由はそれだけではないでしょう。まず、Linuxだけでなく、UNIX系OS全般、さらにはWindowsまで、さまざまなOSに対応しているということが１点。そして、設定ファイルの書式が比較的わかりやすく、かつ、単純に動作させるだけならば非常に簡単な手順で済むので、サーバの学習を始める題材としてはもってこいだということがもう１つ挙げられるでしょう。

Apacheのもう１つの特徴として、モジュールによって機能追加を行えるという点が挙げられます。モジュールを追加することによって、機能をつけ足すことができるわけです。モジュールを外すこともできるため、不要な機能は外すことができ、プロセスの肥大化を防ぐこともできます。

また、設定ファイルを見るとわかりますが、設定項目が非常に多いです。すなわち、動作させる「だけ」であれば簡単なのですが、実際には機能の取捨選択やセキュリティの確保など様々なことを考えに入れなくてはいけないため、実際の運用を行うためには綿密な設定作業が必要になります。規模の大きなサーバとなると、パフォーマンスの調整が非常に大切なので、さらに数多くの作業が必要になります。

いずれにせよ、広く利用されている上に、学習をする題材としても最適なサーバであるApache。奥深いソフトウェアでもあるので、実際に利用する際には飽くなき探求心と共に向き合ってください。

インデックスに戻る

Arch Linux

今回は、Linuxディストリビューション紹介の第14弾、「Arch Linux」について紹介します。

「Arch Linux」については、以前この豆知識で紹介しました。軽量・シンプルであることが特徴、ローリング・リリースという特殊なリリース形式であること、pacmonと呼ばれるソフトウェア管理システムでソフトウェアを管理する、中級〜上級者向けLinuxディストリビューションということを前回は紹介しましたので、今回は少し違う切り口からArch Linuxを見てみようと思います。

Arch Linuxの特徴として、デフォルトでは必要最小限のソフトウェアしか入っていません。そしてユーザは、ユーザが必要なものを選んでシステムを構築していくことを要求されます。このことは、Arch Linuxはデスクトップ・サーバどちらの用途に向いているか？はユーザ次第ということを意味します。腕に自信があれば、どちらの用途でも利用できます。

デフォルトで必要最小限のソフトウェアしか入っていないということは、サーバ向けとしては魅力的な特徴と言えます。余計なソフトウェアが入っていればセキュリティホールになり得るため、ユーザは知らず知らずのうちにセキュリティホールの危険性を抱えているということを意味するからです。

ただし、「サーバとして安定したシステムが構築できるか」というと、それはユーザの腕次第ということになります。たとえば必要な設定ができていないとか、必要なライブラリが入っていなかったという場合は当然サーバとして適切なシステムとはならないわけです。APTなどのパッケージ管理システムが利用できる場合は、たとえば依存性のあるソフトウェアも一緒にインストールしてくれるので、こういったトラブルが少なくなります。Arch Linuxでは、自ずと「適切なシステムを構築するユーザのスキル」がものを言うことになります。

なお、セキュリティフィックスの提供などはかなりこまめに行われるため、「セキュリティアップデートの提供ができなくて困る！」ということは少ないと考えてよいと思います。

使いこなすには腕が必要ですが、腕が上がったら是非チャレンジしてみて欲しいLinuxディストリビューションです。

インデックスに戻る

Plamo Linux

今回は、Linuxディストリビューション紹介の第13弾、「Plamo Linux」について紹介します。

Plamo Linuxは、Slackwareをベースとして、こじまみつひろ氏が中心となって開発されている、国産のLinuxディストリビューションです。国産であることのメリットとして日本語環境が充実しているというのが１つの特徴です。そして、「Plamo」という名前が示す通り、プラモデルを組み上げていくようにシステムを構築していく、という感覚のLinuxディストリビューションです。

Plamo Linuxの用途としてはデスクトップ向けのパッケージが充実している、日本語環境が整っていることから、デスクトップ用途とされることが多いようですが、サーバソフトウェアもある程度は揃っていますので、使いようによってはサーバとしても十分利用できます。

2013年5月に「Plamo Linux 5.1」がリリースされており、2014年3月1日現在でこれが最新版になっています。このバージョンは、x86とx86_64アーキテクチャをサポートしており、64bit環境にも対応しています。

Plamo Linuxは、RPMなどのパッケージ管理システムを持たず、スクリプトによってソフトウェアをインストールしていくタイプのLinuxディストリビューションです。このため、初心者にはやや敷居が高く、中級者以上向けのLinuxディストリビューションと言えるでしょう。

歴史ある国産Linuxディストリビューションなので、腕が上達してきた暁には是非チャレンジしてみてください。

インデックスに戻る

Tiny Core Linux

今回は、Linuxディストリビューション紹介の第12弾、「Tiny Core Linux」について紹介します。

Tiny Core Linuxは、何といってもそのサイズの小ささに特徴があります。そのサイズは、現行の「Tiny Core Linux 5.0」本体で9MB。非常に小さなLinuxディストリビューションです。

それでいてGUIベースのデスクトップ環境が利用できます。これだけの小ささであることから、容量の小さなUSBメモリでも十分に起動が可能です（もちろんハードディスクなどにインストールして利用することも可能です）。

実行に必要なメモリも少なくて済むため、古くて性能の低いPCでも動作するという特徴があります。また、「エクステンション」と呼ばれるパッケージを追加していくことで、機能を増やすこともできます。そのパッケージも、極力サイズを小さくすることに拘って開発されています。

さらに、公式な派生種としてGUIを削った「Micro Core Linux」というものもあり、容量は6MBとなっています。

容量の小ささが特徴なだけに、機能の豊富さという点はあまり期待できませんが、古くなったPCでも動作するというのは大きなポイントとなります。普段はあまり使う機会がないかもしれませんが、いざというときに役に立つLinuxディストリビューションなので、ぜひ覚えておきたいですね。

インデックスに戻る

SystemRescueCd

今回は、Linuxディストリビューション紹介の第11弾、「SystemRescueCd」について紹介します。

日本での知名度は、これまで紹介したディストリビューションの中でもかなり低いかと思います。SystemRescueCdは、何といってもその名の通り「レスキュー目的特化型」のLinuxディストリビューションで、KNOPPIXのようにLive CDとして提供されます。USBメモリから起動することも可能です。

「SystemRescueCD」は、Gentoo LinuxをベースとしたLinuxディストリビューションで、クラッシュ時のデータの復旧、パーティションの管理、バックアップ、ファイル・パーティションのリカバリ、メモリテストなどの機能を備えています。逆に言うと、サーバやデスクトップ用途のアプリケーションはほとんど備えていません（ウィンドウマネジャーはシンプルなものを搭載しているので、一応GUIベースのインターフェイスは利用できます）。

様々なファイルシステムに対応しており、Linux以外のOSがクラッシュした場合にも利用できます。もちろん、常用するLinuxディストリビューションではありませんが、事故が発生したときには非常に頼りになるLinuxディストリビューションなので、是非覚えておいてください。

インデックスに戻る

KNOPPIX

今回は、Linuxディストリビューション紹介の第10弾、「KNOPPIX」について紹介します。

KNOPPIXは、CD-ROMやDVD-ROMから起動することができる、いわゆる「ワンCD Linux」です。ハードディスクにインストールすることなくLinuxを利用できるということで、様々な場面での活用が考えられます。

ワンCD Linuxのメリットはいくつかありますが、そのうち２つほどを紹介しましょう。１つは「既に他のOSなどがインストールされているPCでも、システムに変更を加えることなく、一時的にLinuxを利用できる」ということです。PCが1台しかないような人がLinuxに触れてみたい時にはピッタリでしょう。

もう１つは「レスキュー」、すなわちPCにおいてトラブルが発生し、ハードディスクからのブートが不可能になったというとき、ワンCD Linuxを利用してコンピュータをブートし、システムの復旧作業を行うことができるという点です。場合によってはハードディスク内のファイルをコピーするなどして、データを保護することができます。

DebianベースのLinuxディストリビューションで、ドイツのKlaus Knopperが開発に当たっています。また、日本の産業技術総合研究所が、日本語化および、日本の国情にあわせた様々な機能を追加して「日本語版」の配布を行っています。日本語版では、日本語化だけでなく、LCATと呼ばれる、起動時間を短縮する仕組みが独自に採り入れられています。

ワンCD Linuxではありますが、HDDやSSDにインストールして利用することもできます。さまざまな応用が考えられるディストリビューションですので、ぜひ活用してみてください。

インデックスに戻る

Gentoo Linux

今回は、Linuxディストリビューション紹介の第8弾、「Gentoo Linux」について紹介します。

Gentoo Linuxは、やや上級者向けのLinuxディストリビューションです。
Portageと呼ばれるパッケージ管理システムがその特徴と言えます。Portageでは、RPMやdebと異なり、ソースコードからソフトウェアのインストールを行います。パッケージにはインストール作業の手順が書かれているebuildというスクリプトがあり、これに従ってソースコードのコンパイル、インストールなどが行われます。

このようにインストールを行うことでシステムを構築していくため、必要なパッケージを自分で取捨選択し、自由度の高いシステム構築を行うことができます。コンパイル時にのみ設定できる機能の有無を切り替えることもできるので、カスタマイズ性が大きく、使う人の好みにシステムを作り上げることができます。

この、カスタマイズ性の大きさがGentoo Linuxの特徴ですが、それゆえに難易度はかなり高いと言えます。さまざまなパッケージについての理解がないと、使いこなすのが難しくなります。また、設定を適切に行わないとトラブル発生の危険も増え、最悪の場合はシステムの起動すらままならないという事態になりかねないので、初心者には使いこなすのが辛いLinuxディストリビューションだと言えます。逆の言い方をすると、システムを構築するだけでもスキルアップになりますので、ある程度Linuxに慣れてきた人には是非チャレンジして欲しいLinuxディストリビューションです。

インデックスに戻る

openSUSE

今回は、Linuxディストリビューション紹介の第7弾、「openSUSE」について紹介します。

openSUSEの前身である「S.u.S.E Linux」が最初にリリースされたのは1992年。歴史のあるLinuxディストリビューションと言えるでしょう。最初は、ドイツの有志によって開発・配布されていましたが、2004年に米Novellに買収され、同社の支援を受けた開発体制となりました。そして、同社が開発をLinuxコミュニティに開放、「openSUSE Project」の下で開発が進められることになりました。これによって、100％オープンソースのLinuxディストリビューションを目指すこととなり、名称も「SUSE Linux」、そして「openSUSE」と変わりました。なお、派生製品として、有償版のサポート付き「SUSE Linux Enterprise」も存在します。

SUSEは、元々はSlackwareをベースとして開発されていましたが、現在はパッケージは「RPM」形式で提供されます。そして、最大の特徴は、パッケージ管理システムに「YaST（Yet another Setup Tool）」と呼ばれる独自のシステムが採り入れられていることでしょう。YaSTは、SUSEのために開発されたシステムですが、これ自体もオープンソースであり、他のLinuxディストリビューションで利用することも可能です。YaSTの特徴としては、その機能の豊富さに加え、強力なGUIフロントエンドを備えていながらCUIでも利用できる、といった点があります。

openSUSEは、Slackwareをベースにしているとは言っても、長い間、独自に開発されてきたという経緯があります。そのため、「独自路線」ということができるでしょう。デスクトップ環境もKDE、GNOME、Xfceから選ぶことができますし、サーバとして利用するためのパッケージも取り揃っていますので、さまざまな用途に利用することができます。ただし、安定志向か、最新機能を積極的に採用する傾向か？と言うと、どちらかというと新機能を積極的に採り入れていくという傾向が強いと言われていますので、サーバとして利用する際には若干慎重に検討したほうがよいかもしれません。

なお、openSUSEには、1CDのLive版も用意されています。根強いファンもいるLinuxディストリビューションですので、選択肢に加えてみてはいかがでしょうか。

インデックスに戻る

Linux Mint

今回は、Linuxディストリビューション紹介の第6弾、「Linux Mint」について紹介します。

Linux Mintは、2006年に開発が開始されたLinuxディストリビューションです。Ubuntu同様、比較的新しいLinuxディストリビューションと言えます。

Linux Mintは、本来はUbuntuをベースとして開発されているLinuxディストリビューションですが、現在はDebianをベースとした「Linux Mint Debian Edition (LMDE)」なども開発・提供されています。Linux Mintの特徴として、採用されているコンポーネントや、デスクトップ環境によって「Linux Mint KDE」や「Linux Mint Xfce」など、いくつかのエディションが提供されていることが特徴です。それぞれのエディションは、Live形式で提供されています。このため、インストールしなくてもUSBメモリなどから動作しますので試用も簡単で、普段はLinux以外のOSで利用しているPCでも利用できます。

さて、このLinux Mintですが、その提供されているエディションからもわかるように、デスクトップ向けのLinuxディストリビューションと言うことができます。デスクトップ向けのアプリケーションは多数対応しており、マルチメディアやオフィスなど、多様な機能を持っています。

サーバ向けのパッケージも提供されているため、サーバとして利用すること自体は不可能ではありません。しかし、Linux Mintはデスクトップ用途に向けて作られているということ、Ubuntuと異なりサーバ版が提供されていないことから、サーバとして利用するためにはかなりのスキルが必要となります。初心者が勉強のためにサーバを構築するのはそれほど大変ではないかもしれませんが、セキュリティやトラブルの対応などには相応のスキルが必要になります。

とはいえ、とっつきやすいLinuxディストリビューションですし、Live形式で動作するという点からも、初心者が入門のディストリビューションとして選択するのは決して悪くないと言えるでしょう。

インデックスに戻る

Ubuntu

今回は、Linuxディストリビューション紹介の第5弾、「Ubuntu」について紹介します。

Ubuntuは、2004年に開発が開始されたLinuxディストリビューションです。
Debianの開発開始が1993年ですから、比較的新しいLinuxディストリビューションと言えるでしょう。

Ubuntuは、Debianのテスト版をベースに開発されています。このため、パッケージはdeb形式で提供されます。一方でUbuntuは「初心者にも使い易い」を目指しており、たとえばインストールは最小で４回のクリックで完了します。デスクトップ環境にはUnityが採用されており、独自の操作性を持っています。半年ごとにメジャーアップデートリリースがなされるため、きちんとアップデートリリースを適用すれば、セキュリティアップデートのサポートが切れてしまうという心配も少ないと言えます。

最近、Ubuntuはデスクトップ向けのOSとして人気を集めています。しかしながら、サーバ用途にUbuntuが向かないかというと、そうとは言い切れません。Ubuntuにはきちんとサーバ向けの「Ubuntu Server Edition」も提供されています。こちらはその名の通り、サーバ用途としてカスタマイズされているので、サーバを構築する際には有力な選択肢となるでしょう。

Ubuntuは最近人気を集めていますが、その理由としては「初心者にもとっつきやすい」という点が挙げられます。しかし、これは裏を返すと「初心者向けにカスタマイズされている」ということですから、たとえばサーバとして利用する際には留意するべきポイントがいくつかあります。特に有名なのが、Ubuntuでは「rootユーザになることができないようになっており、root権限が必要な操作はすべてsudoコマンドを介して行う必要がある」という点です。設定を変更すればrootでのログインも可能になりますが、システム全体がsudoを利用することを前提に作られていますので、リスクを伴う行為になってしまうということは留意しておいたほうがよいでしょう。また、その他にもいくつか独自のカスタマイズを施している点がありますので、Ubuntuを利用する時には「初心者には使い易いが、独自路線を行くLinuxディストリビューションなのだ」ということは念頭に置いておきましょう。

インデックスに戻る

Debian GNU/Linux

今回は、Linuxディストリビューション紹介の第4弾、「Debian GNU/Linux」について紹介します。

Debianは、1993年に開発が開始されたLinuxディストリビューションです。実に20年もの歴史を持っており、老舗Linuxディストリビューションと言うことができるでしょう。パッケージ管理にはdeb形式が採用されており、Red Hat Linuxとは別個の、独自の系列を形成しているということができます。
パッケージマネージャには多機能なAPTやaptitudeなどが採用されており、慣れると使い勝手のよいLinuxディストリビューションとなります。

Debianのもう一つの特徴として、非常に多くのアーキテクチャがサポートされていることが挙げられます。Intel x86のみならず、ARM、IA-64、PowerPC、SPARC、MIPSなど、幅広いハードウェアで利用することができるため、用途に合わせたアーキテクチャを選択できるほか、使われなくなったコンピュータにインストールして利用するなどということもできます。

そして、Debianの特徴の１つに、「安定版」「テスト版」「不安定版」がそれぞれリリースされていることが挙げられます。「不安定版」にはコードネーム「sid」と名付けられ、新しいソフトウェアが積極的に採り入れられます。セキュリティ専門のアップデートが提供されないため、実用には向きませんが、新機能の試用にはもってこいと言えます。「テスト版」は、「不安定版」で一定期間致命的なバグが発見されなかったソフトウェアが採り入れられる版で、次期安定版と位置付けられます。2013年10月現在、バージョンナンバーは8.0、コードネームは「jessie」です。「安定版」は正式リリースで、「テスト版」からバグを取り除き、安定性を向上させたものです。セキュリティフィクスなども積極的に提供されます。2013年10月現在、バージョンナンバーは7.0、コードネームは「wheezy」です。

Debianの安定版は、新機能よりも安定志向と言われています。しかし、提供されるパッケージの数が非常に多いため、サーバ用途、デスクトップ用途のいずれにも利用できます。最初に選択するディストリビューションとしては、有力な選択肢になるでしょう。

インデックスに戻る

「CentOS」と 「Scientific Linux」

今回は、Linuxディストリビューション紹介の第3弾、「CentOS」と「Scientific Linux」について紹介します。

CentOSの名前は、Fedoraの名前と同じくらい浸透しているのではないでしょうか。CentOSも、Red Hat Enterprise Linuxと関わりが深いディストリビューションです。しかし、その立ち位置は、Fedoraと全く異なります。

Fedoraは、Red Hat Enterprise Linuxの「開発」のための、実験的要素の強いLinuxディストリビューションでした。一方、CentOSは、Red Hat Enterprise Linuxのソースコードをベースとし、同社の商用パッケージや商標を取り除いて再構成されたLinuxディストリビューションです。このことから、「RHELクローン」とも呼ばれています。

以上のことから、CentOSは、Red Hat Enterprise Linuxがほぼそのまま（「商用」の部分が取り除かれている）ものなので、安定性で言えばFedoraよりも優れています。一方で新機能の採り入れは、Red Hat Enterprise Linuxに準じることになるため、Fedoraほど積極的ではありません。このことから、「安定性」を求めるユーザには良いディストリビューションだと言うことができるでしょう。

ただし、CentOSを利用する際には絶対に留意しておくべきことがあります。
それは、CentOSを開発している「CentOS Project」は、Red Hat社からの支援を受けているわけではありません（一方、Fedora ProjectはRed Hat社の支援を受けています）。そのため、たとえばセキュリティアップデートの提供が遅くなったり、（それほど高い可能性があるわけではないものの）提供打ち切りという事態になる可能性もあるのです。
---
※2014年1月、Red Hat社は「CentOS Project」に対する公式な支援を発表しました。
http://jp-redhat.com/centos_faq/

なお、同じような立ち位置にあるLinuxディストリビューションに「Scientific Linux」があります。これは、「Red Hat Enterprise Linux」をベースにしており、かつ、素粒子物理学で利用されるパッケージを追加したLinuxディストリビューションです。このパッケージを利用したいという人は少ないかもしれませんが、CentOSと共にRHELクーロンとしてチェックしておきたいLinuxディストリビューションです。CentOSとの違いとしては、開発元（フェルミ研究所）が違う点が大きい、と考えるとよいと思います。

「安定性のCentOS」。サーバ構築など、実戦で利用するには、良い選択肢となるでしょう。

インデックスに戻る

Fedora

今回は、Linuxディストリビューション紹介の第2弾、「Fedora」について紹介します。


Fedoraの名前は、聞いたことがあるという方も多いでしょう。Fedoraは、Red Hat社の支援を受けている「Fedora Project」によって管理・開発が行われているLinuxディストリビューションです。

2003年までは、Red Hat社は、「Red Hat Linux」という名前で、無償でLinuxディストリビューションを提供していました。同社は2003年に方針転換を行い、Red Hat Linuxの提供終了と、企業向けのRed Hat Enterprise Linux(RHEL)、および無償版のFedoraのリリース、そしてFedora Projectの発足を発表しました。当時はFedoraではなく「Fedora Core」と呼ばれていました。そして、Fedora Coreには積極的に新機能・新しいソフトウェアを採り入れ、十分な試験を行った後、安定化したものをRed Hat Enterprise Linuxに採り入れるという方針を取るようになりました。

このため、Fedoraには、積極的に新しい機能が採り入れられる、という特徴があります。このことは、常に新しい機能が利用できるということでもありますが、裏返すと、実験的要素が強いため、どうしてもある程度は安定性が犠牲になってしまうという側面もあります。これがFedoraの特徴と言えます。

各パッケージはrpm形式で提供され、パッケージ管理ツールはYUMですので、パッケージの導入は容易です。また、インストーラも初心者にとって簡単なものとなっているので、とっつきやすさという意味では初心者にも使い易いLinuxディストリビューションです。最新機能が使えるというのもポイントになるかもしれませんが、安定性には少々不安があります。また、メジャーバージョンアップも頻繁に行われるため、絶えずアップデート作業を行う必要も出てきます。

利用者が多いため、情報量も多く、最新機能を積極的に試してみたいという人には良い選択肢ですが、一方でサーバ用途として実戦利用するには、かなりのスキルを要求します。サーバとして利用するためには、信頼性・安定性が重要となるからです。

「最新志向のFedora」ということを頭に入れて、上手に使いこなして下さい。

インデックスに戻る

Slackware

今回は、「Slackware」について。

今回から、豆知識ではLinuxディストリビューションの紹介をしていきたいと思います。その第一弾として、「Slackware」を取り上げてみたいと思います。

Slackware、あまり聞き慣れないディストリビューションかもしれません。
正直、シェアはそれほど高くなく、目立たないディストリビューションでもあります。しかし、歴史は古く、1992年以来、実に20年以上の歴史を誇ります。数多くのアプリケーションをカバーしており、安定性にも定評があります。

Slackwareのパッケージ管理システムには、「Slackware package manager」と呼ばれる独自の管理システムが採用されています。しかし、パッケージはtar、gzip、bzip2でディレクトリをアーカイブ化しただけの簡単なものになっています。パッケージの内容は、ソースコード、解説ファイル、インストール時に実行するスクリプトのみからなるという、非常にシンプルなものです。RPMやdpkgのような多機能なパッケージ管理システムが無いため、使いこなすにはスキルが必要となります。初心者向けとは言い難いLinuxディストリビューションです。

一方で、Slackwareはそのシンプルさゆえ、カスタマイズ性に優れています。使いこなすことができれば、これ以上ないくらい自分好みの環境を手に入れることができます。Slackwareを使いこなすことは、Linuxスキルの習得につながります。インターネットサーバ用途に利用するためには、かなりの理解が必要になりますが、ある程度Linuxに慣れてきたら、LANの中で利用しみるとよいのではないでしょうか。

そのシンプルさゆえ、使いこなすだけでステップアップにもなるSlackware。上を目指すなら、ぜひチェックしておきたいディストリビューションです。

インデックスに戻る

Linuxディストリビューション選び

今回は、「Linuxディストリビューション選び」について。

Linuxディストリビューションとは何か、をご存知ない方は、過去の豆知識（https://www.lpi.or.jp/lpic_all/linux/trivia/details.shtml#6）をご参照ください。

さて、非常によくお寄せいただく質問が、「どのLinuxディストリビューションがいいの？」という相談です。インターネット上でも、この手の質問はよく見かけます。この質問に関しての答えは、「目的は？サーバ用途？デスクトップ用途？」「利用するマシンは？」「勉強用？実用？実験用？」などにより変わって来ます。「すべての用途において、このディストリビューションがベスト！」という選択肢はありません。もしそういう選択肢があるのならば、全ての人がそのディストリビューションを利用するでしょうし、他のディストリビューションは廃れるだけだからです。

それぞれのLinuxディストリビューションには、得意・不得意があります。

「サーバ向け・デスクトップ向け」
「小規模向け・大規模向け」
「安定志向・新機能の採用に積極的」
「サポートするアーキテクチャ」
「使い易さ」
「機能の多さ」
「アップデートの充実」
「パッケージ管理システム」

などなど・・・。そして、たとえば「安定志向」かつ「新機能を積極的に採り入れる」というのは極めて難しく、この両者は並立が難しいといえます。

Linuxディストリビューションを選ぶためには、各Linuxディストリビューションの個性を知り、自分のニーズに合わせて適切な選択を行うことです。

次回からは、Linuxディストリビューションの紹介をしていきます。

インデックスに戻る

API

今回は、「API」について。

APIとは、「Application Programming Interface」の頭文字をとったものです。「Interface」で終わっていることからもおわかりのように、インターフェイスの一種です。とはいうものの、キーボードやディスプレイのことではありません。APIは、いわば「ソフトウェアとソフトウェアの仲立ちを行うインターフェイスである」と言うことができます。

APIは、OSやアプリケーションが、自分の持つ機能の一部を、他のアプリケーションから簡単に利用できるようにするためのインターフェイスです。機能の呼び出し手順や記述方法などを定めた仕様を持っており、APIを利用することで、そのアプリケーションを、他のアプリケーションから簡単に操作することができます。

APIを利用することによって、同じような機能を何度も実行したり、少しずつ違う形で実行したりすることも簡単にできるようになります。これはプログラミングを行う際に非常に重要で、機能の操作を独自に記述する必要がないこと、同じような記述を何度も行う必要がないことから、プログラムの開発を効率的に行うことができるようになる、というメリットがあります。最近ではさまざまなAPIが揃っているため、プログラマーとしては有難い存在となっています。

アプリケーションが多様化し、それらの連携が１つのテーマとなっている現代。アプリケーションの連携を行うには欠かせない存在ですので、是非その存在を理解しておいてください。

インデックスに戻る

スケジューリング

今回は、「スケジューリング」について。

Linuxは、マルチタスクのOSです。したがって、多数のタスクを同時に処理する必要があります。といっても、本当に同時に多数のタスクを進めることは不可能ですので、CPUの処理時間を短い時間に区切り、1つのCPUを切り替えて利用する、というのは以前に取り上げた通りです。

スケジューリングは、このときに「どのような順番で、どのCPUで、どのタスクを処理するか」を決める作業です。ネーミングそのままですので、納得がしやすいのではないかと思います。

さて、このスケジューリングを行うために大切なことは、さまざまなタスクに対してCPUの処理時間を割り振るときに、「全体の効率を最大にするように割り振ること」です。

一番単純なのは、「実行しているタスクに、均等に時間を割り振る」という手法です。しかし、これはあまり上手い方法ではありません。タスクといってもさまざまなものがあります。複雑な演算を必要とするタスクから、CPUではほとんど何もしないタスクもあります。同じタスクでも、処理待ちの際はほとんどCPUを必要としないが、処理中にはCPUをフルパワーで活用しなくてはならない場合もあります。そうなると、均等に時間を割り振るのは良い方法ではありません。どれだけCPUを使うか？を考慮した時間の割り振りが必要になるわけです。この作業が「スケジューリング」です。

Linuxでは、kernel 2.6.22まで「O(1)スケジューラ（オーダワンスケジューラ）」と呼ばれるスケジューラを利用していましたが、Linux 2.6.23以降、Linux 3.10（現在）まで、Completely Fair Scheduler（CFS）がスケジューラとして提供されるようになりました。CFSでは、プロセスに実行優先度をつけ、優先度に応じて時間を割り振ります。実行優先度はいつでも等しいわけではなく、状況に応じて変動します。CFSのもう一つの特徴に、過去に割り当てられた時間が少ないプロセスに対しては優先度を上げる、などのように、「できるだけ公平性を確保する」工夫も施されていることが挙げられます。

縁の下の力持ちとも言えるスケジューラ。チューニングを行う際には重要になることも少なくないので、ぜひ知っておいてください。

○スケジューラーについて参考となる情報
Linuxカーネル開発者が語るスケジューラの最新動向
http://news.mynavi.jp/articles/2008/07/10/lfjs/index.html

openSUSEドキュメント: タスクスケジューラのチューニング
http://opensuse-man-ja.berlios.de/opensuse-html/cha.tuning.taskscheduler.html

インデックスに戻る

Linuxカーネルと割り込み処理

今回は、「Linuxカーネルと割り込み処理」について。

「割り込み」は、少し前に取り上げました。現在実行中の処理を中断し、強制的に別の処理を実行させることを「割り込み」と言います。キーボードなどインターフェイスから特定の動作が行われたり、ソフトウェアから指示があったときなどに「割り込み」が発生します。

Linuxカーネルは、実はこの「割り込み」を上手く活用しています。Linuxはマルチユーザ・マルチタスクOSであるため、いつ、どこからどのような指示が来ても的確に応答しなければならないということ、サーバ用途に代表されるように、ネットワーク経由でのリクエストにもいつでも応えなくてはいけないことなどから、割り込みを上手に利用することでさまざまな処理をこなすことができている、と言えます。

本来、CPUは「あらかじめ決められた手順で、処理を行う」のです。これを「順次処理」と呼びます。別の見方をすると、「あらかじめ決められた手順以外では、処理ができない」ということにもなるわけですね。このことからも、割り込みがいかに大切な機能かを窺い知ることができるかと思います。

もし、「割り込み」以外の方法でLinuxのさまざまな機能を実現しようとすると、「常時監視」が必要になります。すなわち、カーネルが常時インターフェイス（キーボード、マウス等々）、ネットワーク、各ソフトウェアを常に監視し、何かが起こらないかを常に見守る。そして、何かが起こったら、それに対して応答を返し・・・監視をすることにリソースを割く必要が生じます。最近のコンピュータの進歩、機能の多様性を見てみれば、常時監視を行うために割くリソースの量がとんでもなく大量なものになってしまうのがおわかりでしょう。しかし、割り込みを活用すれば常時監視をすることなく、「起こしたい時に処理を行う」ことができるようになります。

Linuxカーネルがどれくらい割り込みを利用しているか？については、「/proc/interrupts」ファイルを参照すればわかります。以下のコマンドを実行してみてください。割り込み発生の数が表示されます。

○割り込み回数の確認例
$ cat /proc/interrupts
           CPU0       
  0:       5133   IO-APIC-edge      timer
  1:          8   IO-APIC-edge      i8042
  3:          1   IO-APIC-edge    
（中略）
 56:    1630917   PCI-MSI-edge      eth0-rxtx-0
 57:          0   PCI-MSI-edge      eth0-event-1
 58:     328429   PCI-MSI-edge      vmw_pvscsi
 59:          1   PCI-MSI-edge      vmci
 60:          0   PCI-MSI-edge      vmci
NMI:          0   Non-maskable interrupts
LOC:   23884251   Local timer interrupts
（略）


Linuxカーネルが、いかにたくさんの割り込みを活用しているかがわかると思います。

インデックスに戻る

仮想コンソール

今回は、「仮想コンソール」について。

コンソールとは、乱暴に言ってしまえば、「キーボードとディスプレイの組み合わせ」のことを指します。キーボードとディスプレイさえあれば、LinuxをCUIで操作することができますので、私たちはコンソールを利用してLinuxにコマンドを入力し、同時に何らかの出力を得ることになるわけです。Linuxを操作するためには欠かせないものですね。

さて、「仮想コンソール」とは・・・「仮想」であるからには、「実際には存在しないけれども、あたかも存在するかのような」というニュアンスが含まれるわけです。これは一体どういう意味合いが含まれるか、ということになります。「いやいや、Linuxを操作するにはキーボードとディスプレイが必要じゃないか。存在しないなど、ありえない」・・・たしかにその通りです。

LinuxなどのUNIX系OSには、実は仮想コンソールが「複数」用意されています。そして、仮想コンソールを切り替えて利用することができます。これは「１セットの物理的なキーボードとディスプレイで、複数の仮想コンソールを切り替えて利用できる」という意味です。

LinuxでGUIが起動しているとき（注：ネットワーク経由ではなく直接接続されたキーボードとディスプレイ）に、Ctrlキー ＋ Altキー ＋ F1キーを同時に押すと、CUIログイン画面が表示されます。ここで表示されるのが、仮想コンソールのうちの1つ。ここでユーザ名とパスワードを入力すると、CUIでログインし、Linuxを操作することができます。

ここで、たとえば「Altキー＋F2キー」を押してみてください。画面が切り替わり、新しいログイン画面が表示されます。ここでログインし、また別の操作を行うことができます。同じように、Altキー＋F3キーで新しい仮想コンソール・・・同じように、Alt＋F6キーまで、合計で6個のコンソールが利用できます。

GUIに戻るには、Alt+F7キーを押します。

最近では、GUIを利用することが多く、またGUIから複数のターミナルを起動して操作することができるため、仮想コンソールの存在感は薄くなっています。しかし、主にサーバ用途では、X Window Systemをインストールしない場合も多く、このような場合は仮想コンソールがとても役に立ちます。

トラブル発生時、ある仮想ターミナルがフリーズした場合にも、別の仮想コンソールが生きているというケースもありますので、仮想コンソールの存在は是非知っておきましょう。

インデックスに戻る

モノリシックカーネルとマイクロカーネル

今回は、「モノリシックカーネルとマイクロカーネル」について。

「モノリシックカーネル」の「Monolithic」とは、「一枚岩である」という意味です。カーネルの設計において、OSのほとんどの機能をカーネルに盛り込み、一体化させたもの、ということができます。たとえば入出力の機能やネットワーク機能、デバイスのサポートなどの全てをカーネルが一手に引き受けます。この方法のメリットとしては、OS全体が一体化しているため、実行速度が速いという点が挙げられています。以前のUNIX系OSでは、このモノリシック方式のカーネルが採用されていました。

一方、「マイクロカーネル」は、文字通り「小さなカーネル」です。この方式では、カーネルは割り込み処理やプロセス間通信の処理など、OSの中核として必要最小限の機能だけを持っています。他の処理は「モジュール」に任せます。マイクロカーネルのメリットは、カーネルの肥大化を防ぐことができる、機能をモジュールの形にすることで開発効率を上げる、移植や機能追加を容易にすることができる、などです。

さて、それではLinuxはモノリシックカーネルでしょうか、マイクロカーネルでしょうか？書籍などを参照すると、「Linuxはモノリシックカーネルである」としてあるケースが多くあります。たしかに、カーネルをコンパイルする際に、さまざまな機能を選択することができるものの、それらの機能はカーネルの一部となりますので、モノリシックカーネルであると言うことができます。しかし、Linuxも、いくつかの機能をモジュールとして分割し、必要に応じてロードするというようなことも行うようになってきています。
すなわち、マイクロカーネルのような要素も持ち合わせているということになります。

実はこのことは、Linuxに限ったことではありません。マイクロカーネルの代表格と言われたWindowsでも、最近ではいくつかの機能をカーネルに組み込むようになっており、モノリシックカーネルのような要素も持ち合わせたカーネルになってきている、と言うことができます。

すなわち、「完全にモノリシックカーネル」「完全にマイクロカーネル」というのは、最近では少なくなってきたのです。アーキテクチャや機能の多様化・進化に伴い、「この機能はカーネルに組み込む」「この機能はモジュールにする」のように使い分けるほうが、設計上もパフォーマンスの上でも好ましいため、と言えるでしょう。

だからと言って、「マイクロカーネル」「モノリシックカーネル」の分類が意味をなさないわけではありません。性能を最大限に引き出すためには、カーネルの設計の基本として、このような２つの考え方があるということは知っておいたほうがよいでしょう。

インデックスに戻る

Arch Linux

今回は、「Arch Linux」について。

「Arch Linux」というLinuxディストリビューションは、ほとんど聞いたことがないという方も多いかもしれません。１つの理由としては、ニュースで「Arch Linux バージョン○○リリース」などというニュースが出ないことが挙げられます。それもそのはず、Arch Linuxには、他のディストリビューションに見られるような、明確な「バージョン」が存在しないのです。

Arch Linuxの特徴として、「ローリング・リリース」というシステムを採用していて、随時ソフトウェアがアップデートされ、システムが常に最新の状態に保つことができるという特徴があります。このため、「ここでバージョン○○のリリース」ということがないのです。

他の特徴としては、軽量シンプルであり、デフォルトではごく少数のソフトウェアしか入っていません（デスクトップ環境も全く入っていません）。しかし、pacmanと呼ばれるソフトウェア管理システムが用意されているため、ソフトウェアの導入が難しすぎるということはありません。

一方で、自分で細かくカスタマイズできるということは、裏を返すと自力でシステムを構築しなくてはならないということでもあります。システムのインストールも、CUIですので初心者には少しハードです。中級〜上級者向けのディストリビューションと言えるでしょう。

ニュースなどで取り上げられる機会がないので、豆知識で取り上げてみましたが、腕が上がった暁には試してみてはいかがでしょうか。

インデックスに戻る

割り込み

今回は、「割り込み」について。

「割り込み」は英語では「interrupt」と言います。もしかするとあまり良いイメージがない言葉かもしれません。「割り込みエラー」などというメッセージと共に、アプリケーションがクラッシュした・・・という経験がある方も多いでしょう。

割り込みとは、いま実行している処理を中断して強制的に別の処理を実行させることを言います。このように書くと「やはり何か緊急事態のときの話なのかな」と思ってしまうかもしれません。しかし、実は割り込みの発生は非常に頻繁に発生しています。

割り込みは「より優先度の高い処理」を行わせる必要がある際に起こります。CPUでは、処理の優先度は予め決まっているので、割り込みの発生は高い頻度で起こります。必ずしも異常事態で起こる事象ではないことは頭に入れておいて下さい。

割り込みには、ハードウェア割り込みとソフトウェア割り込みの２種類があります。ハードウェア割り込みは、周辺機器などのハードウェアが発生させる割り込みです。たとえばキーボードのキーを１つ叩いただけでも割り込みは発生します。ハードウェア割り込みはコントローラを経由してCPUにシグナルが送られ、必要な割り込み処理が行われます。これは、ハードウェアから「何かが起きた」ということを通知してもらう仕組みだと言うことができます。

また、ソフトウェア割り込みは、プログラムが発生させる割り込みです。こちらは、OSやBIOSに準備されている、さまざまな基本命令セットを呼び出すことに利用されるケースが多くなっています。また、0除算（割り算）や、書き込み禁止領域への書き込みを行おうとした場合など、禁止されている処理を行おうとしたときに、トラブルを防ぐという使い方も多くなっています。

意外と重要な「割り込み」。OSやコンピュータの仕組みを理解するには、必ず理解おいていただきたい用語です。

インデックスに戻る

マルチタスク

今回は、「マルチタスク」について。

「マルチタスク」とは、一度に複数のタスク（プログラムの処理単位）を実行することです。というと、そんなの当たり前じゃないか、と思うかもしれません。たとえば、最近では動画を再生しながらメールを打ち、そしてメッセンジャーも動作していて、実は裏でウィルス対策ソフトウェアも動いている・・・といったことが普通になっています。しかし、コンピュータが普及しはじめた1980年代などは、マルチタスクは当然のことでなく、一度に１つのタスクだけを実行する「シングルタスク」が主流でした。

1つのCPUは、ある瞬間には1つの処理しか実行できません。そこで、CPUの処理時間を短い時間に区切り、複数のタスクで1つのCPUを切り替えて利用します。このことによって、複数のタスクが同時並行で実行されることになります。すなわち、マルチタスクであっても厳密には「同時進行」ではなく、めまぐるしい速度で複数のタスクを順番にこなしているということになります。人間も複数の仕事を同時にこなそうとすると、どうしても「時間を区切って交互に作業する」というようにせざるを得ませんね。コンピュータでも、人間と同じことをやっているのです。ただ、その切り替えのスピードが非常に早い・・・ミリ秒で切ることができるので「同時進行に見える」ということなのです。

なお、Linuxは「マルチタスク」だけでなく、「マルチユーザ」であることが大きな特徴です。マルチユーザは、「一度に複数のユーザがOSを利用できる」ことを言います。すなわち、「一度に、複数のユーザが、複数のタスクを実行することができる」というわけです。

それほど難しい話ではないのですが、Linuxのカーネルの働きを理解するためには、この「マルチタスク」の理解が不可欠ですので、理解しておきましょう。

インデックスに戻る

組み込みシステム

今回は、「組み込みシステム」について。

「組み込み」という単語はよく耳にすると思います。その意味は比較的シンプルで、PC以外の用途に組み込んで利用するシステム、というニュアンスになります。多くが、家電製品などに組み込まれているシステムですね。医療機器や工業機器などにも採用されており、情報化が進んだ現代では、なくてはならないものになりつつあります。

PC以外のところでも、いたるところにコンピュータが使われている昨今。わかりやすいところで言えば、カーナビやデジタルテレビ、はては冷蔵庫や洗濯機にも採用されていることがあります。また、携帯電話に組み込まれているものも「組み込みシステム」と呼ぶことができます。もっとも、スマートフォンになると、「PC」なのか「組み込みシステム」なのか曖昧なところになり、どちらが正しいのか？という議論も出て来ますが、このような境界線の議論は、あまり意味のない議論だと言えるでしょう。

さて、この組み込みシステムに採用されているオペレーティングシステムは何でしょう？これにはさまざまな種類があり、独自に開発されたものも数多く存在しますが、ずばりLinuxをベースにした組み込み用OSも存在します。

元々、Linuxは移植性に優れたシステムです。そのため、さまざまなアーキテクチャに対応することができ、組み込みシステムには打ってつけと言えるのです。また、OSがLinuxでなくても、その上で動いているのはオープンソースソフトウェアであるという例も少なからず存在するようです。やはり、高い移植性がなせる技、ということができるでしょう。

パソコンやサーバを動作させるだけに留まらないLinux。意外なところに使われているかもしれませんので、探してみてはいかがでしょうか？

インデックスに戻る

Java

今回は、「Java」について。

Javaは、オブジェクト指向型と呼ばれるプログラミング言語です。また、広い意味で、プログラミング言語としてのJavaプログラムを実行する実行環境のことを指すこともあります。

Javaは、1990年代に、サン・マイクロシステムズ社によって開発された言語です。Javaのメリットは、広く使われているC言語、およびC++言語の構文を受け継いでいるため、これらの言語に習熟している開発者にとって習得が容易であることが１点ありますが、何と言っても大きなメリットは、「Java仮想マシン」の下で動作する、という点でしょう。

Java仮想マシン（Java Virtual Machine：JVM）は、その名の通り、Java言語で記述されたプログラムを実行する仮想マシン（ソフトウェア）です。Javaで記述されたプログラムは、Java仮想マシンによって、実行するプラットフォームに対応した形式に変換された上で実行されます。この時に、プラットフォームによる様々な相違がJava仮想マシンによって吸収されるため、Javaプログラムを記述・実行する時に、プラットフォームの違いを考慮する必要がない、というメリットがあります。そのため、特に様々なプラットフォームが入り乱れるインターネットでは、Javaで作られたプログラムが数多く存在しているという事情があります。

Javaを利用するには、注意すべき点もあります。もっとも大きな点は、セキュリティの問題でしょう。コード自身に潜むセキュリティホールも存在するでしょうが、JVMなど、Java自体にセキュリティホールが存在する場合もあり、被害実例も数多く報告されています。「Javaの利用は自己責任で！」という言い方をされることすらあります。こういったことを気にする必要があるのは、Javaがそれだけ広がっている証拠でもありますが、インターネットを活用する上では少し頭に入れておく必要があるでしょう。

開発をする人も、しない人も、サーバやインターネットの管理を行う立場であれば必ず「付き合う」ことになるJava。Javaに関係するオープンソースソフトウェアも多数利用されているだけに、その特性をよく知っておきましょう。

インデックスに戻る

bitとbyte

今回は、「bitとbyte」について。

コンピュータを扱っていると、記憶媒体の容量などを表す時に、1bit（ビット）だとか1byte（バイト）などの言葉が使われているのはよく耳にすることでしょう。これらは一体、何を表すのでしょうか。

まず、「bit」から。そもそもコンピュータ内部では、あらゆるデータを「0」と「1」だけで表現します。いわゆる「2進法」ですね。10進法の「1」はそのまま「1」ですが、10進法で「2」は2進法で「10」、「3」は2進法で「11」、「4」は2進法で「100」となります。

この、2進法で表したとき、何桁のデータまで扱えるか？を表したのが「bit」です。このときの桁数は2進法ですので、2bitであれば10進法の「0,1,2,3」を、3bitであれば「0,1,2,3,4,5,6,7」を表すことができる、ということになります。ただし、これはあくまで自然数を扱う場合の話です。
小数や負の数を扱うこともできますが、その場合も2bitでは「4通り」の数を扱えることになります。

そして「byte」。これは、bitがわかれば簡単で「1byte＝8bit」となります。すなわち、1byteならば2の8乗、「256通り」のデータを扱えるということになります。よく「1byte文字」と言われますが、これは英数字や記号、半角カタカナなど、256通りの文字を扱うことができるというわけです。なお、漢字などが含まれると256通りでは足りないので「2byte文字」（＝2の16乗、65536通り）を扱うことになります。

なお、「1KB（キロバイト）」は1024byte、「1MB（メガバイト）」は1024KB（＝1024×1024byte）、「1GB（ギガバイト）」は1024MB、「1TB（テラバイト）」は1024GBを意味します。コンピュータの世界以外の科学分野では、k（キロ）は1000（10の3乗）、M（メガ）は1000000（10の6乗）、G（ギガ）は1000000000（10の9乗）、T（テラ）は1000000000000（10の12乗）を表すことが多いのですが、それとはズレがありますので注意してください（コンピュータの世界でも、これらの扱いと、k＝1024・・・と扱う場合が混在していて、ややこしいので注意が必要です）。

知っているようで意外と知らない、これらの量。プログラミングを行う時などにはきちんと理解しておく必要が生じますので、しっかり理解しておきましょう。

インデックスに戻る

Long Term Support（LTS）

今回は、「Long Term Support（LTS）」について。

Ubuntuなどのディストリビューションでは、時々「LTS版」、すなわちLong Term Support版がリリースされます。最近では、カーネルでもLong Term Support版が存在します。これは、その名の通り長期間セキュリティアップデートが提供される版ということになります。

「そんなものを出さなくても、ディストリビューションを常に最新にすればいいじゃないか！」と思われるかもしれません（アップデートは面倒臭いからしない、というのは無しです！！）。しかし、「全体を丸ごと最新のものにする」というのは、手間もかかりますし、複雑なシステムを組んでいる場合は使用しているアプリケーションが大幅にアップデートするなどして互換性の問題が発生するなど、アップデートによる問題が発生するというリスクもあります。また、「最新のアプリケーション」では、未知のセキュリティホールが潜んでいるリスクが大きくなります。

サーバ用途に利用したいという場合には、「安定性が優先」という考え方もあります（もちろん、これはケースバイケースで、「必ず」という考え方ではありません）。最新機能などはいらないから、とにかく安定で安全なものを！という需要は、決して小さくないのです。そのような場合、Long Term Support版は良い選択肢です。

ただし、LTS版もやがてはサポートの打ち切りがやってきます。その場合は、システムをアップグレードする必要が出てきますが、この場合はシステムの更新間隔が開きますので、アップグレードに失敗するリスクが出てきます。このような場合は、むしろ「新しくシステムを組み直してそこに古いデータを載せ替える」ような手法のほうがよいでしょう。

Long Term Support版と通常版には、それぞれ一長一短がありますので、正しく特性を知った上で、上手に使い分けましょう。

インデックスに戻る

温度管理の方法

今回は、「温度管理の方法」について。

前回はサーバの温度をモニタする重要性について触れましたが、今回はLinuxからハードウェアの温度をモニタする方法について触れたいと思います。

１つは、/procディレクトリにあるファイルを読む方法が挙げられます。
具体的には、

/proc/acpi/thermal_zone/

配下に、CPU温度を示すファイルが存在します（環境にもよりますが、/proc/acpi/thermal_zone/THRM/temperatureなど）。これをcatコマンドで読めばよいでしょう（/proc配下のファイルですので、viなどで読まないようにして下さい！）。ただし、環境によってはこのファイルが存在しないこともあります。

もう１つは、「lm_sensors」というアプリケーションを利用することです。このアプリケーションを利用するには、少し準備が必要ですが、基本的には「yumもしくはaptを利用してインストール」→「sensors-detectコマンドを実行してセンサーを探す」→「sensorsコマンドで温度を取得する」という流れになります。

「sensors-detect」コマンドは、マザーボード上のセンサーを探し、読み取れるように準備を行うコマンドです。実行にはroot権限が必要です。このコマンドを実行するといくつかの質問が出てきますが、基本はYES/NOで答えます。また、実行した後には「/etc/modules.conf」や「/etc/rc*」に追加するべき事項が表示されることがありますので、指示に従ってファイルの編集を行います。最近のバージョンでは、この作業を自動で行ってくれる場合もあります。

なお、sensors-detectコマンドは、このアプリケーションを利用する最初の１回実行するだけで大丈夫です。

そして「sensors」コマンド。基本的には、パラメータをつけずに実行すれば、温度が得られます。このコマンドは、一般ユーザでも実行できます。実行例は以下の通りです。

$ sensors
coretemp-isa-0000
Adapter: ISA adapter
temp1:       +32.0°C  (crit = +107.0°C)

これで温度を取得することができます。

lm_sensorsは、便利かつ手軽に利用できるツールですので、是非利用してみて下さい。

インデックスに戻る

サーバの温度管理

今回は、「サーバの温度管理」についてコメントを。

以前も「熱暴走」というテーマで取り上げましたが、サーバ（に限らず、コンピュータ）は、機械ものです。半導体の塊と言ってもよいでしょう。その半導体ですが、「熱」は大敵です。高温になると、CPUをはじめとしたコンピュータの素子がダメージを受けます。故障の原因になることも珍しくありません。

さて、そのためには大原則「サーバは冷却する」「高温になるところに置かない」ということがよく言われます。実際、データセンターの内部に入ると、真夏ではクーラーがよく効いており、涼しくなっています（逆に冬は、人間にとっては少し寒いと感じるくらいの温度に保たれています）。

とはいえ、どんな対策を講じていたとしても、いつ何時、何かの拍子に温度が上がってしまうケースがないとも限りません。そこで、「温度管理」が必要になります。

サーバ内部…特にCPUの温度には、殆どの場合、きちんと温度計が搭載されています。そして、コマンドを利用すれば、簡単にサーバの温度を知ることができます。そこで、cronとスクリプトを利用して、定期的にサーバの温度を取得する、ということがよく行われます。温度はログに書きだしてもよいですし、定期的にメールで送るという手段もあります。温度が高くなりすぎたときに限って警告を発するというスクリプトを作成してもよいでしょう。

また、最近のサーバハードウェアでは、センサーがソフトウェアとは独立して管理されており、OSの動作状況に関係なく温度を監視・管理することもできる製品があります。このような製品を使うことができるのであれば、統合監視ソフトウェアなどと組み合わせることで、よりきめ細やかな管理が行えます。

温度管理にはいくつかの方法が考えられるのですが、サーバ管理を行う際には「温度管理」は避けて通れないのだということは、しっかりと覚えておいてください。

インデックスに戻る

SSDとサーバー

今回は、「SSDとサーバー」についてコメントを。

HDDに代わる新しい大容量記憶ストレージとして、フラッシュメモリを用いる「SSD（Solid State Drive）」が普及しつつあります。最近のPCではSSDが積極的に取り入れられており、実際に利用した経験がある方も少なくないと思います。

さて、このSSDですが、「高速」というメリットがある反面、「高価である」「書き込み・読み込み回数が多いと寿命がHDDよりも短くなる（約10分の1程度）」「HDDほどの大容量化が困難」といったデメリットもあります。
技術の進歩によりこのようなデメリットは少しずつ改善しつつありますが（特に価格は最近ずいぶんと下がってきました）、それでもまだまだ完全にHDDに取って代わるという状況ではないようです。また、「SSD＝高速」というのも、製品や利用の仕方によっては成立しないケースがあるようです。

このようなSSDですが、サーバに利用するメリットはあるのでしょうか？答えはもちろん「YES」です。しかし、特に大容量のデータを扱うサーバーで、すべての記憶装置をSSDにするとコストが膨大になりますし、データの書き込み・変更回数が多いサーバーではSSDの寿命が短くなるというデメリットも発生します。

現時点でサーバーでSSDを使うのであれば、「HDDと組み合わせて利用する」という方法が考えられます。具体的には、たとえば、高速に読み書きする必要のあるデータはSSDに保存し、高速に読み書きする必要の無いデータはHDDに保存する、というように使い分けるのです。

技術の進歩は目覚ましいので、1年後にはもしかするとSSDがHDD並のコスト・容量・寿命になるかもしれませんが、現時点でも上手に活用すれば大きな活躍をしてくれるSSD。上手に使って、高性能なサーバを構築してみて下さい。

インデックスに戻る

Linuxディストリビューターの一員になるには

新年最初の今回は、「Linuxディストリビューターの一員になるには」というテーマを取り上げます。

以前も、新年一回目に「Linuxカーネル開発者の一員になる」というテーマで取り上げましたが、やはりカーネル開発者の一員になるというのはハードルが高いと言えます。そこで、「Linuxディストリビューション配布者の一員になる」というテーマを取り上げます。

もちろん、企業が開発しているLinuxディストリビューション開発者になるには、その企業に就職する必要があります。しかし、コミュニティが開発に当たっているディストリビューションであれば、基本的にはボランティアの手によって開発がなされているわけで、特別にどこかの企業に就職していなくても（もっと言えば、今どこかに勤務している場合、その企業を辞めなくても）、開発者の一員になることはできるのです。

では、どうすればよいのか？

まずは、「開発者のメーリングリスト」に加入することが第一歩です。入るだけであれば、多くのコミュニティは広く門戸を開いていますので、簡単に入ることができると思います。

ただし、そこでいきなり「開発者の仲間に入れてください！」などと投稿してはいけません。おそらく相手にもされないでしょう。まずは、メーリングリストに投稿されてくるメールを読み、その内容を理解すること。おそらく、中級者でも、これだけで相当大変だと思います。しかし、そこは勉強！
ですので、わからないことは自分で調べて（注：メーリングリストで質問するのは止めて下さい、開発者向けのメーリングリストは誰かの疑問解決のためにあるものではありませんので）、とにかく話についていく努力をしてみて下さい。

ディストリビューションによっては、さまざまな作業を行なう人を募集しているケースもあります。ドキュメントの翻訳作業、バグの発見と報告など、比較的とっつきやすい作業もありますので、ある程度雰囲気に慣れてきたら、そのような作業から入っていくとよいでしょう。そのような作業から、徐々に難しい作業に入っていく、というのがよいと思います。

ここでキーポイントになるのは、「英語」です。

調べものをしたり、作業をスムーズに進行するためには、英語のスキルが必須と言えます。これはディストリビューション開発に限らず、システム管理などを行う上でも同じことです。さまざまなドキュメントはほとんどが英語で提供され、突っ込んだドキュメントは翻訳が提供されないことが多いので、英語の力は上げていきたいところです。

以上、Linuxディストリビューションでお話しをしましたが、さまざまなオープンソースソフトウェアでも全く同じことが言えます。「メーリングリストに加入」「その会話を理解するべく勉強を重ねる」「とっつきやすい作業から」「英語は大切」といったところがキーになりますね。

臆することなく、かといって甘く見ることなく、ディストリビューションの開発者、あるいはOSSの開発者の一員になることを、目指してみてください。

インデックスに戻る

chageコマンド

今回は、「chageコマンド」について。

chageコマンドは、「パスワードの有効期限を指定する」ためのコマンドです。

デフォルトでは、Linuxの一般ユーザ用パスワードに有効期限はありません。すなわち、一回パスワードを設定してしまうと、永久にそのパスワードを使い続けることができます。しかし、本来このことはセキュリティの観点から望ましくありません。長期間同じパスワードを使い続けていると、クラッキング被害に遭うリスクが増えます。パスワードは、定期的に変更するのが望ましい、と言えます。

そこで、パスワードに「○○日間の期限をつける」「期限が切れる前に警告を発する」ように設定することができます。これを実現するのがchageコマンドです。

chageコマンドにはいくつかのオプションがありますが、よく用いられるのは、パスワードの有効日数を指定する「-M 日数 ユーザ名」、パスワードの有効期限の前に警告を表示する「-W 日数 ユーザ名」、有効期限の後にアカウントがロックされるまでの日数を指定する「-I 日数 ユーザ名」でしょう。

ユーザ「foo」のパスワードの有効期限を「150日」に設定する場合は、以下のように実行します（root権限が必要）。

# chage -M 150 foo

また、パスワードが切れる「30日」前に警告を発するには

# chage -W 30 foo

とします。

パスワードの有効期限など、設定状況を知るためには、

$ chage -l foo

と実行します（これは一般ユーザ権限で実行可能です）。

なお、パスワードの期限をどれくらいの長さに設定するか？は、ユーザのログイン頻度を勘案して決めるのがよいでしょう。毎日必ずオンラインでログインするのであれば1〜3ヶ月程度に設定するのが現実的でしょう。一方、極端な話、年に１回しかログインされないという場合には、期限を設定しないというのも手です（いつのまにかログインできなくなっている、という恐れもあります）。

意外と知られていないのですが、本来はもっと活用されるべきこのコマンド、LPIC 102の試験範囲であるので、覚えておくだけでなく活用してみてください。

インデックスに戻る

ARMアーキテクチャ

今回は、「ARMアーキテクチャ」について。

ARMアーキテクチャは、イギリスARM社が開発に当たっているアーキテクチャです。主な用途は携帯電話や組み込み機器、ゲーム機器などで、消費電力を低く抑えていることが大きな特徴になっています。消費電力が少ないということは、省電力はもちろん、バッテリーが長く持つということにもつながります。ARMについては、現在は32ビットが主流ですが、64ビットに拡張された「ARMv8」と呼ばれているアーキテクチャも昨年発表されています。

さて、このようなARMアーキテクチャですが、このARMアーキテクチャとLinuxを組み合わせて利用するという動きは、一つの流れを形成しています。最近、普通にPCにLinuxをインストールするとさまざまな機能がインストールされるため見過ごされがちですが、Linuxは、カスタマイズ次第で機能を絞ることも容易なため、省電力にはもってこいとも言えます。また、オープンソースであることを生かして、ARM向けドライバの対応を強化したり、ARM向けの機能を増強することによって、ARMのメリットを最大限に引き出すことができるようになります。

LAN内サーバなど、大きなマシンパワーを必要としない用途であれば、サーバでの利用も考えられますし、実際に利用しているユーザも少なくないと言います。ここ最近では、LinuxカーネルのARMへの対応強化や、Linaro Enterprise Groupの活動開始など、ARMにおけるLinuxの利用に追い風が吹いています。「Linux 3.7」では、ARMへの対応に大きな改良が施される模様ですし、使い倒せることができれば様々な応用が考えられるアーキテクチャでもありますので、覚えておいてください。

インデックスに戻る

踏み台攻撃

今回は、「踏み台攻撃」について。以前も少し触れたのですが、時事的なトピックでもありますので、再度触れてみたいと思います。

日本では、最近物騒な事件が世の中を騒がせていますね。「PCにウィルス（バックドア）を仕込み、PCを乗っ取って操作し、そのPCから犯罪予告を書き込む」という事件です。この手法だと、乗っ取られたPCは真犯人の隠れ蓑として利用されることになります。いわば「踏み台」となります。今回、日本国内では事件が大きく報道され広く知られることになりましたが、この「踏み台攻撃」という手法自体は目新しいものではなく、（もちろん悪いことですが）以前から多用されてきた攻撃手法なのです。

そして、サーバ管理者としてこの踏み台攻撃に無関心であることは、決してあってはならないことです。今回の事件はクライアントとして使われていた普通のPCが踏み台として使われたようですが、サーバが踏み台として利用されるケースも数多く見つかっています。さらに注意するべきは、日本ではこのような事件が起きると「犯人が全て悪い。踏み台に使われた人は被害者」となりますが、海外では「踏み台に使われた場合、管理者の管理不行届」として、踏み台に使われた管理者が責任を問われるケースがあるという点です。

たとえば、日本のサーバが踏み台にされて最終的な被害者が海外だった場合、海外から責任を問われるという可能性もあります。踏み台として利用されたのが「サーバ」であれば尚更です。

インターネットは世界中に張り巡らされているため、このようなことも十分起こり得るのです。今回の事件の論調では、このような話は全く出ていませんが、サーバ管理者としては心に留めておくべき事項でもあります。

なんとも嫌な話ですが、トラブルに巻き込まれないためにも、セキュリティ施策は万全にしておきたいものです。

インデックスに戻る

チューニングの必要性

今回は、「チューニングの必要性」について。

チューニング、主に「パフォーマンスチューニング」は、サーバ管理で避けて通れない作業です。パフォーマンスチューニングは、可能な限り高いパフォーマンスを引き出し、効率的なサービスを提供するための作業です。

最近ではハードウェアの性能がどんどん上がっているため、チューニングを行わなくても十分なサービスが提供できてしまう、という状況が多くなっています。しかし、効率の悪い設定のままでサーバを動作させていると、コストの増加、思わぬトラブルの原因、ハードウェアへの負荷の増加による寿命の低下など、さまざまな弊害をもたらします。パフォーマンスのことを考えずにサーバを運用することは、良いことだとは言えません。

パフォーマンスチューニングを行うためには、ハードウェア・ソフトウェア双方について十分な理解が必要になります。設定ファイルについても、初心者の頃は全く気にも留めていなかったパラメータを調整するというケースも出てきます。また、「こうすればパフォーマンスが良くなる！」という正解がないケースが数多く出てきます。「サーバへのアクセス頻度は？」「提供しているサービスは？」「ハードウェアの性能は？」「ボトルネックはどこか？」などなど、様々な要因によりベストな設定は異なります。ですから、チューニングを行うには、テストを行ってその結果を元に設定を変えてみるなどの作業を行うこともあります。試行錯誤になることも珍しくありません。

面倒な作業なので敬遠されがちですが、裏を返すとスキルアップには絶好の
実戦作業だと言うこともできます。立派なサーバ管理者になるために、果敢
に挑戦してみてください。

インデックスに戻る

Btrfs

今回は、「Btrfs」について。

Btrfsは、現在開発途上にある、新しいファイルシステムです。カーネルのリリースのたびに機能の改善・強化が施されており、次世代のファイルシステムとして期待されています。

Btrfsは、「Solaris」に実装されていた「ZFS」の影響を強く受けており、スナップショットやコピーオンライトなどの機能を備えており、データの安全性を確保する試みが多く施されています。コピーオンライトは、データを書き換える際、元のデータを一時的に別の記録エリアにコピーし、そのコピーに対して書き換えを実施し、この書き換えが完了した後にメタデータが更新されます。このため、どの段階で処理が中断したとしても、データが失われるという事態が起こらない、とされています。

その他にも、ファイルシステムの管理の方法も新しいものが採り入れられており、ファイルシステムのチェックなども簡単になっています。さらにSSDの寿命を延ばす最適化機能を備えるなど、多数の新機軸が盛り込まれています。

Btrfsは発展途上であり、安定性にも疑問符がついていたため、実用には未だクリアするべきハードルがいくつか存在する、と言われて来ました。しかし、開発者の努力により安定性の向上も図られ、実用に供する日も近いと言われています。Linuxの次世代標準ファイルシステムとして採用される
であろう、とも言われており、注目を集めています。是非、チェックしておいて下さい。

インデックスに戻る

logrotate

今回は、「logrotate」についてコメントを。

logrotateは、ログの肥大化を防ぐためのツールです。ログファイルは、放置しておくとどんどん大きくなっていき、/var/logディレクトリを圧迫してしまいます。これを防ぐのがツール「logrotate」です。

このツールは、その名の通りログファイルをローテーションするツールです。たとえば、logというファイルを、log.1、log.2、log.3、のように定期的にローテーションします。ある時期（たとえば一週間）が経過すると、logはlog.1に、log.1はlog.2に、log.2はlog.3に・・・のように上書きされます。最後のファイルは（設定にもよりますが）削除されます。また、logファイルは空になり、ここに新たなログが書き込まれることになります。

logrotateの設定ファイルは/etc/logrotate.confファイルで、何世代のファイルをローテーションするか？どれだけの期間が経過するとローテーションするか？などを設定します。logrotateは、デーモンとしては動作しないため、cronを利用して定期的に実行します。

このようなlogrotateですが、多くのLinuxディストリビューションで、デフォルトでインストールされます。このため、知らないうちにログがローテーションされているということも多いでしょう。古いログは知らず知らずのうちに消去されてしまっていることもあります。

便利なツールですが、存在を知らない、あるいは動作しているという事実を知らないと困ったことになることがあります。一度、注意して見てみてください。

インデックスに戻る

「ハードウェアクロック」と「システムクロック」

今回は、「ハードウェアクロック」と「システムクロック」について。

クロック、すなわち時計は、コンピュータでは非常に重要です。何よりも、ファイル管理において、更新・アクセス時間を正確に取らないと、ファイルの消失など、とんでもないトラブルを抱える危険すらあります。サーバでも、時計が正確でないと、ソフトウェアが正しく動作しない、認証などの連携がうまく取れないなどの問題が発生します。

時計を正確に合わせるためにはNTPを利用します。NTPについては以前の豆知識でも触れましたが、ネットワークで時計を同期させるための仕組みです。一般に、NTPなどで得た正確な時刻を元に、コンピュータがクロックを管理します。そのときに利用されるクロック（時計）は、OSが管理する「システムクロック」です。システムクロックはメモリ上に置かれ、OSによって時が刻まれ、管理されます。また、OSがファイル管理などに利用するのは、システムクロックです。

このように重要な役割を担うシステムクロックですが、OSで管理されているため、OSをシャットダウンすると失われてしまいます。そこで、OSを起動するたびに、手動で時刻を入力する・・・のは大変ですよね（と言いつつ、実は、以前はOSを起動するたびに、手動で時刻を入力していたのです！）

ここで「ハードウェアクロック」の登場です。ハードウェアクロックは、その名前の通り、ハードウェアの上に実装された時計です。OSは、起動時にハードウェアクロックを参照し、その情報をシステムクロックに移して利用することになります。

システムクロックもハードウェアクロックも、残念ながら精度が優れているとは言い難いものです。そこで、サーバ用途ではNTPを利用して定期的に正確な時刻を得て、これをシステムクロックとハードウェアクロックに反映させるのが望ましい使い方だと言えるでしょう。ただし、NTPを使いすぎるとネットワーク及びサーバに負荷をかけることになりますので、たとえば２週間に１回NTPで時刻を取得し（ntpdateコマンド）、これをハードウェアクロックに反映させる（hwclock -wコマンド）ようにするのがよいでしょう。

ところで、ハードウェアクロックは、マザーボード上にある専用の電池によって稼働するようになっているケースがほとんどです。ここで注意したいのは、電池切れです。どうも時計がおかしい…という場合は、実はハードウェアクロック用の電池切れのせいだった、というケースが多いようです。
電池切れにはくれぐれもご注意を・・・。

インデックスに戻る

tmpfs

今回は、「tmpfs」について。

tmpfsは、意外と知られていないのですが、コンピュータのメモリに作成できるファイルシステムです。このように聞くと「RAMディスクのことか」と思う方もおられると思いますが、RAMディスクとは異なるものです。

tmpfsは、RAMディスクと異なり、１つのファイルシステムとして認識されます。そのため、フォーマットの必要がなく、また、好きなディレクトリにマウントして利用することができます。また、tmpfsは予めメモリ上にtmpfs用の容量を確保する必要はなく、容量は使用した分に合わせて自動的に変化します。なお、使用できる容量の上限を設定することもできます。

メモリ上に作成するファイルシステムですから、「アクセス速度が非常に速い」というメリットを享受することができます。ストレージにかける負担を減らすこともできますから、一時ファイルなどを置くのに適しています。
一方で、コンピュータの電源を落とすとファイルが消えてしまいますので、その点は十分な注意が必要です。

tmpfsは、ファイルシステムの一種として位置付けられていますので、mountコマンドを利用してマウントすることができます。たとえば、

# mount -t tmpfs -o size=64m /dev/shm /tmp

のようにすると、/tmpディレクトリがtmpfsを利用してメモリ上に置かれることになります（/dev/shmはtmpfs専用のマウントポイント、sizeは最大容量を指定）。

意外と影の薄いtmpfsですが、使いこなすことができれば非常に便利です。
是非、使ってみて下さい。

インデックスに戻る

netstatコマンド

今回は、「netstatコマンド」について。

netstatコマンドは、ホストのネットワーク接続状態やソケット・インターフェイスごとのネットワーク統計などを表示するコマンドです。コンピュータの、ネットワーク接続の一覧やそのステータス、統計、エラー状態なども表示できます。ネットワーク状態を調べるのに非常に便利かつ欠かせないコマンドだと言えます。

netstatは、引数なしで実行すると全ての有効な接続が表示されます。UNIXドメインソケットの情報も表示されるため、非常に数多くの行が表示され、少々見づらくなってしまいます。この対策としては、-t（tcp）、-u（udp）、-w（ICMP・RAW）オプションを使い、以下のように実行するとよいでしょう。

$ netstat -atuw
Proto Recv-Q Send-Q Local Address       Foreign Address        State
tcp        0      0 localhost:smtp      *:*                    LISTEN
tcp        0     52 192.168.1.10:ssh    192.168.1.12:65116     ESTABLISHED


「LISTEN」はリッスン状態であることを、「ESTABLISHED」は、接続が成立していることを表します。

netstatコマンドの出力を見て注視すべきは、状態が「LISTEN」となっているところです。-aオプションで出力されます。LISTENは、外部からの接続を、ポートを開放して待っているという状態です。netstatを実行し、LISTENの表示されているところを見ることで、思わぬポートがLISTEN状態になっていないか？を確認することは重要です。この作業により、思わぬポートが開いているとわかった場合、セキュリティに問題がありますので、原因を突き止めて対策をしたほうがよいでしょう。

netstatコマンドには、他にもさまざまなオプションがあります。LISTEN状態の接続のみを表示する「-l」オプション、詳細な情報を表示する「-v」オプション、インターフェイスごとのパケット統計を表示する「-i」オプション、ネットワークの統計を表示する「-s」オプション、マスカレード接続の表示を行う「-M」オプション、マルチキャストのグループ情報を表示する「-g」オプション、ルーティングテーブル情報を表示する「-r」オプションなどがあります。これらのオプションを利用すると、netstatはさまざまな情報を出力します。中には、他のオプションを指定したときとは全く異なる出力となるオプションもあります。これらをマスターすれば、ネットワークの状態を調べたいときに大きな力になってくれるでしょう。

使い方も多様なnetstatコマンド、それだけに得られる情報も多様になりますので、ぜひ負けずに取り組んでみてください。

インデックスに戻る

freeコマンド

今回は、「freeコマンド」について。

freeコマンドは、メモリの利用状況を調べるコマンドです。基本的なコマンドですので、ご存知の方も多いでしょう。しかし、その出力については、誤解しやすいところがありますので、取り上げてみたいと思います。

freeコマンドは、一般ユーザでも利用できるコマンドで、引数なしで実行すれば状況がわかります。

$ free

さて、その際の出力は次のようになります。各項目の単位はキロバイトです。

             total       used       free     shared    buffers     cached
Mem:       1999236    1949760      49476          0     131156    1682684
-/+ buffers/cache:     135920    1863316
Swap:      4030456        483    4029973

ここで、1行目（Mem:の行）を見て、少しぎょっとなる人も多いと思います。
意味をそのまま捉えると、「合計1,999,236キロバイトのうち、1,949,760キロバイトが使われていて、残りは49,476キロバイトしかない」となります。何か大きなプログラムが動いているわけでもないのに、メモリ利用率の高さが異常に大きいですね。ちなみに、Linuxシステムにログインできる方はfreeコマンドを実際に実行してみてください。おそらく、同じように、Mem:の行だけを見ると、利用率が異常に高く見えると思います。

実は、これは異常ではありません。Linuxは、各プロセスにメモリを割り振り、残った容量をバッファとキャッシュに利用し、HDDなどのデバイスへのI/Oを軽減するという仕組みになっています。実際に、上の例では、バッファとキャッシュにかなりのメモリ容量が使われていることがわかりますね。このため、1行目の項目を見ると、残り容量はわずかにしか残っていないように見えるのです。

大事なのは、2行目、「-/+ buffers/cache:」の行です。ここは、1行目のused/freeの値から、buffersとcachedを差し引いた値が表示されます。ここの「used」の項目が、実質的にカーネルやプログラムが利用しているメモリ容量を表し、「free」の項目が「実質的な空き容量」と見做せるところになります。上の例では、「実質的に135,920キロバイトを使用し、1,863,316キロバイトが空いている」となります。メモリには十分に余裕があり、問題がないことがわかります。

3行目の「Swap:」はそのままの意味で、スワップ領域の状況を表します。ここで「used」が大きい場合、スワップ領域に大きな負担がかかっていることになります。なお、0でなくても、値が小さければそれほど心配しなくても大丈夫です。あまり使われないプログラムがスワップ領域に常駐することがありますので、その状況だと考えることもできるからです。いずれにせよ、長期に渡る値の変化に注目することが必要です。

freeコマンドは見方を知らないと誤解してしまいますので、覚えておきましょう。

インデックスに戻る

vmstatコマンド

今回は、「vmstatコマンド」について。

vmstatコマンドは、メモリの空き容量、CPUの動作状況、ディスクI/Oなどを表示するコマンドです。システムのボトルネックがCPUにあるのか？Memoryにあるのか？ハードディスクにあるのか？といったことを判断するのに利用できます。また、サーバのどこを増強すればよいのか、といったことのヒントにも活用できます。-dオプションや-pオプションをつけると、パーティションやディスクへの読み書き状況が表示されます。

このvmstatコマンドですが、繰り返し実行することもできます。たとえば、2秒間隔で5回実行するには、

$ vmstat 2 5

のように実行します。引数なしで実行すると、情報を1回表示して終わりになります。回数を省略すると延々と情報を表示し続けます。これを終了するには、Ctrl+cを押します。

vmstatコマンドは、サーバが重くなったときや、日常的な運用管理で非常に便利なコマンドです。vmstatコマンドから得られる情報は多く、通常では16個もの項目が出力されます。たとえばディスクI/Oにしても、ブロックデバイスから受け取ったブロック数（1秒当たり、ioのbi）、ブロックデバイスに送られたブロック数（1秒当たり、ioのbo）の２つが表示されます。その他の項目についても、マニュアルなどを参考にして出力の見方を覚えておきましょう。

インデックスに戻る

topコマンド

今回は、「topコマンド」について。

topコマンドは、稼働中のシステムをリアルタイムかつ簡潔に監視することができるコマンドです。CUIで実行できるので、リモートでも簡単かつ便利に利用できます。

topコマンドは、ただ単にタスクの一覧を一覧表示するだけでなく、CPU利用率やメモリ利用率、優先度、タスクの状態（実行中、停止中、ゾンビ状態など）、プロセスの実行時間なども表示されます。また、様々な値を元にソートすることもできるため、どのプロセスがCPUやメモリに負担をかけているのか？といったこともできます。ソートするには、「Shift+o」を押した後に出てくるメニューでソートしたい項目を指定します。この操作もマウスは必要なく、キーボードのみで行うことができます。

topコマンドを利用する際に一つ注意するべき点があります。topコマンド自身がかけるシステムへの負荷です。通常時であれば問題にならないと思われますが（topコマンドを実行する程度の負荷でどうにかなるシステムは、根本から考え直すべきでしょう）、異常時には問題になる危険があります。リアルタイムで動作するツールなだけに尚更です。また、このままでは定期的にシステムの状態を監視したり、他のプログラムから呼び出すには不向きです。この場合、「バッチモード（-bオプション）」と「回数指定(-nオプション)」を利用します。たとえば、次のように実行すると、1回だけtopコマンドを実行して、その結果を「result.txt」に保存します。

$ top -b -n 1 >> result.txt

シェルスクリプトなどで利用できます。他にもさまざまなオプションがありますので、ぜひ使い倒してみてください。

インデックスに戻る

telnetコマンド

今回は、「telnetコマンド」について。

「Telnet」は、ネットワークを介して２つのホスト間で通信を行うためのプロトコルです。Telnetを使うと、遠隔地にあるホストを、仮想端末ソフトを利用して操作することができます。サーバ・クライアント方式で提供され、Telnetサーバが操作される側、クライアントが操作する側で動作します。

UNIXは、その登場当初から複数のユーザが同時に利用するという前提の下で開発されていたため、当初よりシリアルポート等に複数の端末を接続して使用できました。ここでの端末とホストの通信を、ネットワーク上でも可能にしたのがTelnetプロトコルだということができます。

しかし、Telnetには、「通信を平文で行う」という致命的な弱点があります。このため、通信内容が筒抜けになってしまう恐れがあり、セキュリティ上問題があります。このため、リモートホストを操作する際は「SSH」を利用する機会が多くなっています。ディストリビューションによっては、Telnetコマンドがデフォルトでインストールされていないものもあります。

それでも「Telnetコマンド」は利用価値があります。Telnetコマンドは、

$ telnet 192.168.0.1 80

のように、ホストに続けてポート番号を指定することで（この例ではホストに192.168.0.1、ポート番号80を指定）、指定したポートで通信を行うことができます。80番ポートは通常HTTPが利用するポートですから、この操作によって、サーバのHTTPプロトコルでの通信が行えるようになります。この時、サーバ側は、HTTPプロトコルでのコマンドを受け付けますので、ここでたとえば

GET /index.html

のようにコマンドを打つと、index.htmlファイルが帰ってきます。

この利用の仕方でTelnetコマンドを使うと、サーバが正常に動作しているのか、どのように動作しているのか、といったことがわかるため、使いこなせると非常に便利です。一方、自分が管理していないサーバに対しては、セキュリティ攻撃と間違われる可能性もありますので、このような使い方は、自分が管理しているサーバに対してのみ行うようにしてください。上手く使うとサーバ管理に強力な道具となります。是非、試してみてください。

インデックスに戻る

仮想端末（ターミナルエミュレータ）

今回は、「仮想端末（ターミナルエミュレータ）」について。

「端末」は前回触れたものですから「仮想端末」は意味がはっきりしていますね。仮想的な端末です(笑)。ただし、当然のことながら「仮想」ですのでソフトウェアとして提供されます。

「端末」は、主に大型コンピュータのUNIXに接続するためのハードウェアでしたが、それをソフトウェアでやってしまおうというわけです。最近ではPCの価格が大幅に下がり、「端末」を利用してもそれほどコスト削減にならないという事情があるため、UNIX系のOSに接続し、操作するためには、仮想端末（ターミナルエミュレータ）を利用することが多くなっています。

仮想端末は、UNIXであればxtermやkterm、GNOME端末などが有名で、皆さんも一回は利用したことがあるでしょう。主に自ホストにログインして、複数の作業を並行して行うときに使われます。

Windowsクライアント向けの仮想端末としては、Tera TermやPuTTYがあります。両者とも、SSHを介してUNIX系OSに接続することができます。UNIX系OSがなくてもUNIXを操作することができるため、UNIXサーバを管理する人にとってはもはや「必携」とも言えるソフトウェアです。

仮想端末を使いこなして、リモートからLinuxの操作を行う。これが日常になれば、立派なサーバ管理者と言えるかもしれません。

インデックスに戻る

端末

今回は、「端末」について。

「端末」とはハードウェアの一種であり、ユーザがデータをコンピュータに入出力するためのものです。主に、利用者がコンピュータを使うためのユーザインタフェース機能を備えた装置です。

以前、UNIXといえば、大規模コンピュータ（メインフレーム）で動作させ、そのコンピュータにネットワーク経由で接続して利用するものでした。その際に利用するのが「端末」というマシンでした。端末は、コンピュータほどの性能は持っていないものの、外見はコンピュータのようなもので、ディス
プレイとキーボード、マウスなどの入出力機器を備えていました。ユーザは、端末を介してUNIXの動作するコンピュータに接続して、そのコンピュータとの入出力を行うというという形でUNIXを利用していたのです。

ちなみに、現在でも、「シンクライアント」という機器が利用されていますが、このシンクライアントも「端末」の一種だと言うことができます。

さてこの「端末」、最近ではほとんど使わないため、その存在を知らなくても差し支えないと思われるかもしれません。しかし、実は、UNIXは以前「しばしば端末経由で利用していたもの」ということの名残りが随所に残っています。そのため、「端末」というものの存在を知っておくと色々と便利ですので、是非覚えておいて下さい。次回の豆知識では、「端末エミュレータ」について紹介します。

インデックスに戻る

ports

今回は、「ports」について。

portsとは、FreeBSDで採用されているソフトウェアのパッケージ管理システムです。YUMなどと異なり、/usr/ports 以下の「カテゴリ/パッケージ」ディレクトリに、portsスケルトンと呼ばれるMakefileなどに書かれたパッケージ情報が置かれおり、インストールしたいパッケージのディレクトリでmakeコマンドを実行することで、ソースファイルがダウンロードされ、パッチが当たり、ビルドされ、インストールが行われます。依存関係のチェックも行われます。

Linuxでは、「Gentoo Linux」において、「portage」と呼ばれるシステムが採用されています。このportageは、FreeBSDのportsをベースに、bashとpythonを使って構築されたシステムです。Gentoo Linuxは、portageがシステムの核と言っても過言ではなく、自分でシステムを構築していくというオペレーティングシステムですので、portageが無ければ成立しないと言っても過言ではありません。

portageは、ソースコードからソフトウェアをビルドするため、カスタマイズがしやすく、システムを自分の好みのものに作り替えることができます。一方で、取り扱いが難しく、設定を間違えるとシステムに異常が出ることも多く、上級者向けであると言えます。

portageは、腕に自信がついたら、一度は使って、その便利さを実感してみて欲しいシステムです。

インデックスに戻る

APT

今回は、「APT」について。

APT (Advanced Packaging Tool) とは、Debian向けに開発されたパッケージ管理システムです。高性能かつ使い易いという特徴があります。

APTは、パッケージを導入する際に「依存」、すなわち導入しようとしているパッケージを導入するために必要なパッケージを調べて導入する機能や、「衝突」すなわちパッケージを導入する上で障害となるパッケージを調べて削除する機能が備わっています。また、パッケージのアップデートを行ったり、情報を調べるなどの機能も備わっています。パッケージはCD-ROMなどにあるものだけでなく、インターネット上にあるリポジトリから取得してインストール・アップデートを行うこともできます。

APTの特徴に、「apt-get」コマンドや、「apt-cache」コマンドなど、シンプルなコマンドで利用できるということも挙げられます。コマンドラインで利用できますので、リモートから利用するのも容易です。また、apt-getと比べて、高機能な検索・対話的な操作など、より強力なパッケージ管理機能を持つ「aptitude」も利用できます。

なお、APTはDebianが発祥であり、Debian系列のLinuxディストリビューションで採用されている一方で、Red Hat系のLinuxディストリビューションでも利用できるものがあります（Vine Linuxなど）。

APTは、Debian系のLinuxディストリビューションを扱うには必須と言えます。非常に便利なシステムですので、是非使い倒して下さい。

インデックスに戻る

/etc/sysctl.conf

今回は、「/etc/sysctl.conf」ファイルについて。

このファイルは、カーネルパラメータを設定するファイルです。このファイルを適切に設定することで、システムのチューニングを行うことができます（裏を返すと、不適切な設定をするとシステムが滅茶苦茶になる危険があります）。

このファイルの設定は、「/proc」ディレクトリ下の、「/proc/sys/」以下に反映されます。例を示しますと、「/etc/sysctl.conf」に、「net.ipv4.ip_forward=1」という記述を行い、「sysctl -p」コマンドを実行します（当然、root権限が必要です）。すると、「/proc/sys/net/ipv4/ip_forward」ファイルの中身が「1」となります。設定の.（ドット）がディレクトリ区切りの/（スラッシュ）に相当します。ちなみに、この設定は、「IPフォワード」すなわちNIC間でのパケットのやりとりを許可する設定です。/proc以下に仮想ファイルとして設定されているので、catコマンドなどで設定を表示することもできます。

設定できる項目は枚挙にいとまがなく、メモリの使い方、プロセス管理、ネットワーク関係など、様々な項目が設定できます。まさに、Linuxの中核たるカーネルを支配・・・というと大げさなので・・・コントロールするためには欠かせないファイルです。

ちなみに、「sysctl -a」とすると、設定できる項目と、その値が一覧表示されます。一度試してみてください。あまりの数の多さに、びっくりすること請け合いです。

インデックスに戻る

/etc/login.defs

今回は、「/etc/login.defs」ファイルについて。

このファイルはいまひとつ影が薄いのですが、知っておきたい・知っておくと便利な設定ファイルです。このファイルは名前が示す通り、「システムへのログインにまつわる設定を行うファイル」です。

このファイルで設定できることは色々ありますが、たとえば「パスワードの文字数の最大値・最小値」（PASS_MIN_LEN・PASS_MAX_LENで設定します）であるとか、「一般ユーザのUID/GIDの範囲」（UID_MIN・UID_MAXで設定します）などが設定できます。特にパスワードの文字数の最小値などは大きく設定することで、（ユーザには嫌がられるかもしれませんが）パスワードを長く設定しなくてはいけなくなるため、セキュリティを厳しくすることができます。

他にも、パスワードの期限を設定するなど、さまざまな設定を行うことができます。是非、一度チェックしておくとよいでしょう。

インデックスに戻る

ReiserFS

今回は「ReiserFS」について。

ReiserFSは、ファイルシステムの一種で、日本では「ライザーエフエス」と読まれます。「Reiser」は、このファイルシステムの生みの親である「Hans Reiser」氏の名前に由来します。

ReiserFSは、1994年から開発が始まった歴史あるファイルシステムです。
「B-*Treeアルゴリズム」と呼ばれるアルゴリズムを採用しており、ジャーナリングに最大の特徴があります。ReiserFSは、ファイルシステム上のバッファやスーパーブロック、iノードの情報をB-*Treeで管理するため、ファイルのオープンや書き込み速度が速い、という特徴があります。また、異常終了時などの修復が速く、多数のファイルがあるディレクトリでのファイル検索も高速という特徴があります。

ext2/3/4の対抗馬としては、XFSと並ぶ存在とも言えるReiserFS。「ジャーナル」を搭載しているという観点からも、見逃せないファイルシステムです。ReiserFSも、独自のツールを利用してのメンテナンスが必要ですが、LPICレベル2の試験範囲でもありますので、その存在は意識しておいて欲しいところです。

インデックスに戻る

XFS

今回は、「XFS」について。

XFSは、SGI社が自社のUNIX系OS「IRIX」のために開発した、ジャーナリング機能をもつファイルシステムです。開発の開始は1994年で、歴史は古く、成熟したファイルシステムだと言われています。GPLライセンス下でソースコードが公開されており、Linuxなど、他のUNIX系OSへの移植も進んでおり、Linuxでも広く利用されています。

XFSの特徴の一つは、「64bitファイルシステムである」ということが挙げられます。このため、最大で1800TB（テラバイト）のディスクスペース・900TBのファイルを扱うことができます。大きな規模のサーバ用途に向いたファイルシステムだと言うことができます。

また、XFSは、データベース技術を応用した独自のジャーナリングシステムを採用しており、ファイルシステム内の変更履歴を保存し、ファイルシステムが破損した場合であっても、高速に修復できるという特徴があります。

この他、遅延アロケーション、B+-Tree、Direct I/Oなどの仕組みにより、堅牢かつ高速なファイルシステムとなっています。

LinuxでXFSを利用するためには、カーネルがXFSをサポートしている必要があります。また、独自のツールでメンテナンスを行うことになるため、少しだけ敷居が高いファイルシステムだと言えるかもしれません。しかし、使いこなせれば非常に便利なファイルシステムなだけに、一度は試してみていただきたいファイルシステムでもあります。

インデックスに戻る

IPマスカレード

今回は、「IPマスカレード」について。

マスカレード（MASQUERADE）とは「仮面舞踏会」の意味ですが、これだけだと何のことだかよくわからないですね。IPマスカレードは、実は前回取り扱った「NAT」を１歩進めた技術です。

IPマスカレードは、LAN内の「複数の」コンピュータをインターネットなどに接続する際によく用いられます。NATは、IPアドレスを付け替えるという技術で、LAN内のコンピュータをインターネットに接続するには必須の技術でした。しかし、逆に、複数のコンピュータをインターネットに接続するとなると、NATだけでは不可能です。それは、「どのコンピュータがインターネットと接続しているか」がわからなくなってしまうからです。また、ポートがかち合ってしまうという危険もあります。

そこで、IPアドレスだけでなく、ポートも組み合わせて変換し、処理しようというのが「IPマスカレード」です。たとえば、1番のコンピュータはゲートウェイの「1201」番ポートで、2番のコンピュータはゲートウェイの「1202」番のポートで…というように、ゲートウェイが各ホストとポート番号を対応づけます。こうすれば、ゲートウェイの1201番ポートの通信は1番のコンピュータの通信に、ゲートウェイの1202番ポートの通信は2番のコンピュータの通信に、という具合に、「複数の」ホストの役割を、ゲートウェイが担うことになります。ゲートウェイが仮面を被って踊っているかのごとく、複数のホストの役を一人でこなすわけですね。

正確には、この技術は「NAPT」（Network Address and Port Translation)と呼ばれているのですが、これをLinuxで実装したものが「IPマスカレード」となります。

IPマスカレードも「iptablesコマンド」で設定することができますので、ぜひチェックしてみてください。

インデックスに戻る

NAT

今回は、「NAT」について。

「NAT」とは、「Network Address Translation」、日本語に訳すと「ネットワークアドレス変換」のことです。

インターネットに接続されたLANは、ゲートウェイを介して両者のネットワークが接続されています。このとき、LAN側はローカルIPアドレスを、インターネット側はグローバルなIPアドレスが割り当てられます。このため、LANとインターネットを結ぶためには、工夫が必要になります。

単にルーティングするだけではダメなのでしょうか？ローカルIPアドレスを利用している限り、ダメです。ローカルIPアドレスはインターネットに流してはいけないと決まっている上、いくつものLANで同じローカルIPアドレスを利用しているのですから、インターネットから特定のローカルIPアドレスにパケットを送り届けるのは不可能なのです。

そこで登場するのが「NAT」です。NATは、送信元のIPアドレスもしくは送信先のIPアドレスを付け替える技術です。主に、ローカルIPアドレスを、グローバルIPアドレスに付け替えることで、インターネットとLANの通信を可能にします。Linuxでは、「iptables」で実現できます。

おそらく一番わかりやすいのが、「SNAT」（Source NAT：送信元IPアドレスを付け替える）です。たとえばLANからインターネットに接続する際、LANからのIPアドレスをゲートウェイのIPアドレスに付け替えるという技術です。

もうひとつは「DNAT」（Destination NAT：送信先IPアドレスを付け替える）です。たとえばLANの中にインターネットからアクセスしたいホストがある場合に使われる技術です。インターネットからLAN内のコンピュータに直接アクセスできるようになります。言うまでもなく、何も考えずにこの技術を利用するのは危険ですので、注意して下さい。

上手に使えば非常に便利な技術ですので、ぜひ学んでおいてください。

インデックスに戻る

Linuxディストリビューションを自分で作成する

「Linuxディストリビューションを自分で作成する」というお話しを取り上げてみましょう。

Linuxディストリビューションを自前で作成するなんてできるのだろうか？と思う方もおられるでしょう。たしかに、容易なことではありません。しかし、無理な注文でもないのです。というよりも、かつては、Linuxディストリビューションなどという便利なものは、配布されていなかったのです。

1991年、Linus Torvalds氏の手によって誕生したLinux。以前も紹介した通り、Linuxとは厳密には「カーネル」部分だけを指します。そして、そのLinuxカーネルは、インターネットに公開され、さまざまな開発者が参加して成長していった、というのも以前紹介した通りです。ところで、このLinuxカーネルの公開当初は、当然といえば当然ですが、カーネルのみの公開でした。すなわち、デスクトップ環境はおろか、シェルすらも一緒に配布されていなかったのです。

この当初、カーネルを入手したユーザは自力でさまざまなプログラムを追加し、Linuxを利用していたのです。もちろん、それが大変だからこそ、有志の手によって「Linuxディストリビューション」が組まれ、Linuxを利用する敷居が下がりました。しかし、かつてできた「自分の手でLinuxをOSとして組み上げる」ということが今できないはずはありませんね。

もちろん、高度な技術と知識、それに手間がかかることではあります。しかし、今でもカーネルが単独で入手できますし、さまざまなプログラムも個々に入手できます。スキルが上がったら挑戦してみてはいかがでしょうか。

インデックスに戻る

IDS（侵入検知システム）

今回は、「IDS（侵入検知システム）」について。

IDSとは、「Intrusion Detection System」の略で、訳すと「侵入検知システム」となります。IDSは、その名の通り、回線などを監視することで、ネットワークへの侵入を検知するシステムです。役割は言わずもがな、ネットワークのセキュリティを担保するためのソフトウェアです。前回の豆知識で「Linuxでゲートウェイを構築する」という内容を取り上げましたが、そのゲートウェイに搭載することで、ネットワークのセキュリティを保つことができます。

代表的なオープンソースのIDSに、「Snort」があります。「Snort」は、主にネットワークを流れるパケットを監視し、不正が疑われるパケットを発見した場合に、管理者に通知する形で侵入を検知します。不正侵入が疑われる手段をパターン化しておき、パケットをパターンと比較して、不正の有無を
判定します。

一方、「Tripwire」というソフトウェアもIDSに分類されることがあります。
こちらはネットワークではなく、ファイルシステムをチェックし、ファイルシステムに改ざんがないか？をチェックします。ネットワークを監視するわけではありませんが、侵入された場合、高い確率でファイルシステムに何らかの書き換えが加わるため、ファイルシステムを監視すれば、侵入を検知することが可能となります。

IDSは非常に強力なツールであるという側面もある一方、設定が難しいという一面もあります。設定を「厳しく」すると、誤検知、すなわち「不正でないのに不正とみなしてしまう」ケースが増えます。一方、設定を「ゆるく」すると、不正の見逃しが出てしまいます。適切に設定するのが難しく、またケースによって「適切な設定」が異なるので、どうしても「こうすればOK」というのがなく、手間がかかります。

とはいえ、非常に強力なツールであることに違いはありません。さまざまな知識を駆使して、使いこなしに挑戦してみてください。

インデックスに戻る

Linuxでルーター（ゲートウェイ）を作る

今回は、「Linuxでルーター（ゲートウェイ）を作る」という話題を取り上げます。

ルーターは、社内LANなどをインターネットに接続するために必須ですね。
このときに、Linuxマシンに2枚のNICを差し、ルーティングテーブルとIPマスカレードの設定をきちんと行えば、ゲートウェイが出来るというお話しをしました。

さて、このようにしてまでLinuxでルーターを作成するメリットは何か？
ずばりと言って、セキュリティのお話しです。

基本的な設定を行うだけでは、セキュリティ対策をまったく講じていないため、利用はお勧めできません。しかし、たとえばパケットフィルタリングを活用すれば、それだけでもセキュリティは上昇します。iptablesコマンドでは、ログを取るといった使い方もできるので、セキュリティ上怪しいパケットの監視もやりやすくなります。パケット監視ツールは他にもあるため、監視がやりやすいというのは利点の１つです。

さらに、ゲートウェイ用のウィルス検知ソフトウェアというものも存在しますので、これを用いると、ゲートウェイでウィルスを食い止めるということもできます。さらに、侵入検知ソフトウェア（IDS）というものも存在し、クラッカーの攻撃からLANを守ることもできます。

要するに、「ゲートウェイでセキュリティに関するソフトウェアを動かすことができるため、セキュリティを高めることが自在にできるようになる」ということが大きなメリットなのです。

もちろん、あまり安易な技術で実行するのは怪我のもとですが、技術力が向上してきた時には、実践してみてはいかがでしょうか。

インデックスに戻る

IPフォワード（IP Forward）

今回は、「IPフォワード（IP Forward）」について。前回、「ルーティング」について取り上げました。今回の話題は、そのルーティングをLinuxマシンで実現しようという話です。

Linuxのマシンに2枚のNIC（ネットワークインターフェイス）を差し、ホストが２つのネットワークに接続されているものとします。このとき、通常は、パケットは２枚のインターフェイスを超えて届くことはなく、片方のNICでやりとりするパケットは、もう片方のNICではやりとりされることはありません。

ここで、「IPフォワード」という技術が用意されています。この技術は、その名の通り、２つのNICの間でパケットを転送するという技術です。これにより、パケットが異なるネットワークの間を往き来できるようになります。

LinuxでIPフォワードを有効にするには、「/etc/sysctl.conf」ファイルに、「net.ipv4.ip_forward=1」という記述を行い（デフォルトではnet.ipv4.ip_forward=0）、ネットワークを再起動します。

これだけでは、あくまで2つのNIC間でパケットが転送できるようになっただけで、適切な通信が行われるようになったわけではありません。前回紹介したルーティングテーブルを適切に設定する必要があります。このためにはrouteコマンドを利用します。また、当然のことですがNICの設定が適切である必要があります。ここの詳細は、今回は割愛します。

実は、これらの設定を行い（プラス、プロバイダーとの接続を行う）、IPマスカレードの設定を行うだけで、簡単なルーター・・・少なくとも、一般の家庭や小規模なオフィスのゲートウェイとして利用することはできます。
が、このまま利用するのは、セキュリティ上の問題があるため、あまりお勧めできません。ここに、さらにセキュリティ上の施策を行うことで、セキュリティ上も強固なゲートウェイが出来あがります。次回は、そのあたりを紹介したいと思います。

インデックスに戻る

ルーティング

今回は、「ルーティング」について。

ルーティングは、ネットワークを運用する上で欠かせない知識です。ルーティング（routing）とは、パケットの「経路」（route）を適切に選択する技術で、IPネットワークにおいて、パケットを目的のホストまで正しく送信するためには欠くことのできない技術です。インターネットというのは、ネットワーク、すなわち「網の目」ですので、パケットが迷子になってはいけません。また、「届けばよい」というものでもなく、できるだけ短いルートでパケットを届けることが求められます。なぜなら、無駄に長いルートを通るということは、それだけ無駄なパケットを流すことになり、パケットの流量が増えてしまうからです。

パケットは、「ルーター」によって適切な経路を通じて送られます。パケットの経路を指示する装置が「ルーター」（router）というわけです。ただし、経路の設定（ルーティング）はすべてルーターが行うわけではなく、普通のホストもルーティングを行います。Linuxでは、「ルーティングテーブル」と呼ばれる情報に基づいてルーティングを行います。ルーティングテーブルを参照・閲覧するためには、「route」コマンドを利用します。

ルーティングはIPの中核を担う事項でもあるため、「ルーティング」といってもその中で理解するべき事項は数多く、そのすべてをここで紹介するのはきわめて困難です。しかし、ネットワークを理解するためにはルーティングの理解が必須ですので、その概略、できることならば深いところまで、理解しておきましょう。

インデックスに戻る

chroot

今回は、「chroot」について。

chrootとは、「CHange ROOT」のことで、ルートディレクトリを変更する技術です。ここでのROOTとは特権ユーザではなく、ファイルシステムのルートディレクトリのことを指します。

UNIX系のファイルシステムは、「/」すなわちルートディレクトリを頂上としたツリー構造をとっています。このルートディレクトリを、たとえばですが「/var/chroot/」ディレクトリに変更する技術が「chroot」です。

「ルートディレクトリを変更する」といっても、すべてのソフトウェアでルートディレクトリが変更になるというわけではありません。特定のソフトウェア（主にサーバソフトウェア）において、chrootを利用する環境が整っており、ソフトウェア側で設定を行った際のみchrootが行われます。有名なところでは、BINDでchrootが利用できます。

さて、この技術は何の役に立つのでしょうか。これは、「侵入阻止」など、セキュリティの確保を目的に行われます。たとえば、chroot環境下で動作していないBINDが乗っ取られた場合、侵入者はルートディレクトリ、すなわちファイルシステム全体に侵入することができてしまいます。一方、chroot環境で動作しているBINDが乗っ取られても、侵入者はchrootされたディレクトリの中だけで動作でき、外には出られません。

chrootの事例はこれだけではありません。FTPサーバでもchrootが利用されることがありますが、この場合、侵入者のみならず、FTPの利用者もchrootされたディレクトリの外に出ることができません。このため、無用なディレクトリに誤って迷い込んでしまうことがなくなり、トラブルの防止となります。

セキュリティ確保の技術としては基本的かつ比較的簡単に実現できる技術ですので、覚えておきましょう。

インデックスに戻る

ライブラリ

今回は、「ライブラリ」について。

ライブラリ（library）の日本語訳は、皆さんご存知の通り「図書館」です。では、ITの用語としての「ライブラリ」は、どのような意味なのか？
もちろん、「図書館」に通じるものがあります。コンピュータ用語でライブラリと言った場合、「汎用性のある複数のプログラムもしくはコードをまとめたもの」です。ちょうど、図書館が「複数の書籍をまとめた施設」というのになぞらえているわけです。

Linuxの場合、kernelがこなす処理は非常に細かいもののため、アプリケーションが直接処理を指示しようとすると、処理がきわめて複雑かつ指示量が多くなってしまいます。そこで、ライブラリを利用して、「大まか」に、少ない指示で処理を行わせることができるようになっています。

ライブラリを利用することのメリットに、もう一つ「標準化」があります。
たとえば、C言語などでは、「標準ライブラリ」として「GNU C ライブラリ」（glibc）といったものが用意されています。標準ライブラリを利用してコードを書けば、OSの違いを意識することなく利用できるプログラムが書けるのです。ライブラリを利用することのメリットはこういったところにも現れています。

主にプログラミングを行うときに重要となる「ライブラリ」。プログラミング以外でもライブラリの存在を意識する必要が出てくることがあるので、ぜひその役割を理解しておいてください。

インデックスに戻る

ジャーナリングファイルシステム

今回は、「ジャーナリングファイルシステム」について。

以前、ファイルシステムのお話しで簡単にジャーナリングファイルシステムについて触れましたが、今回はジャーナリングについてもう少し詳しく紹介します。

最近のLinuxではext4など「ジャーナリングファイルシステム」と呼ばれる、ジャーナリングを利用したファイルシステムが採用されることが多いようです。「ジャーナリング」は、ジャーナルと呼ばれるデータを定期的に記録する技術のことで、ファイルシステムで、更新内容だけをジャーナルに記録する、というものです。システム障害などが生じた際に、ログに記録された内容を確認するだけでよいので、起動が速く、かつ、その情報を基にした復旧ができるようになります。

ジャーナリングファイルシステムのメリットは、ただ単にデータを保護するだけでなく、ファイルシステム全体が保護できることにあります。ジャーナリングの目的は、「メタ・データ」（スーパーブロックやiノードテーブル、iノードテーブルからリンクされているデータなど）の整合性をとることにあります。

ジャーナリングファイルシステムでは、ジャーナルの変更記録のみを確認するので、ファイルシステムの整合性のチェックが非常に短時間で行え、また整合性が取れた状態に復帰するのも短時間で済みます。

ただし、システムによっては、ファイルの中身までは保護されないことがあります。たとえば、OSがクラッシュしてもファイルシステムの破壊は避けられるが、保存したはずの内容が保存されていなかった、という事態は起こり得ます。ext3やext4ではデータの中身まで保護するような機能が備わってい
ますが、すべてのジャーナリングファイルシステムにおいてデータの内容までが保障されるわけではないことは注意しておいてください。

インデックスに戻る

PAM

今回は、「PAM」について。

PAMとは「Pluggable Authenticaton Modules」の頭文字を取ったものです。
「Authentication」すなわちユーザ認証に用いられているシステムです。UNIX系のシステムで広く利用されています。

PAMの大きな特徴は、「Linux自体の認証だけでなく、アプリケーションの認証でも利用できる」という点にあります。たとえば、telnetやssh、sambaなどのアプリケーションにおいても、PAMを利用した認証ができるということになります。これによって、認証処理をアプリケーションから独立させることができ、認証方式を統一することができます（もちろんアプリケーションごとに異なる挙動をさせることも可能）。標準の状態では、PAMは/etc/passwd（また、これを暗号化した/etc/shadow など）の情報を元に認証を行います。

PAMをうまく操ると、たとえば「suコマンドで、特定のグループ（多くの場合wheel）にのみroot権限を得ることができる」といったことも、比較的簡単に行えます。PAMは複数のモジュールから成り立っており、さまざまな認証を実現することができます。PAMの設定ファイルは/etc/pam.d/ディレクトリにあり、ここにあるファイルを編集することで、認証の設定を行うことができます（ただし、編集を誤るとシステムにログインすることができなくなるので、編集するときには1つのコンソールでrootでログインしたままの状態で作業することをお勧めします）。

セキュリティ保持の観点からも、PAMを理解することは重要ですので、ぜひ理解しておいてください。

インデックスに戻る

udev

今回は、「udev」について。

udevは、Linuxカーネル用のデバイス管理ツールです。主な役割は、「/dev」ディレクトリにあるデバイスノードの管理を行うことです。

かつては、/devディレクトリには、利用される可能性のあるデバイスファイルを、予め/devディレクトリに用意しておく必要がありました。そのため、/devディレクトリには非常に多くのファイルが設置されていました。現在ではudevが、必要に応じて/devディレクトリにデバイスファイルを作成するようになっています。

udevは、ライブラリ「libudev」とデーモン「udevd」、そして管理コマンド「udevadm」などからなります。udevdデーモンがカーネルの内部情報を監視する役割を担っており、カーネルが新しいデバイスを検知したとき、そのデバイスに応じて適切なデバイスファイルを動的に作成するのです。

udevのおかげで、さまざまなデバイスを、コンピュータに自由に抜き差しして利用できる、というわけです。縁の下の力持ち的な存在ですが、LPIC 201の試験範囲に含まれるツールですので、是非覚えておいてください。

インデックスに戻る

LVM（logical volume manager：論理ボリューム管理）

今回は、LVM（logical volume manager：論理ボリューム管理）について。

LVMとは、複数のハードディスクやパーティションにまたがった記憶領域を、あたかも一つのディスクとして扱うことのできるディスク管理機能です。

LVMでは、ハードディスクやパーティションを「物理エクステント」と呼ばれる数十Mバイトの小さな領域に分割して管理します。そして、その物理エクステントの集団をまとめて、「論理ボリューム」を構成します。これによって、あたかも１つのハードディスクを分割したり、複数のハードディスクを結合したように利用したり、また、一度作った論理ボリュームの容量を変更したり、といったことができるようになります。

最近では、Linuxをインストールすると、インストーラーがLVMを利用したパーティションを作成するケースが多く見られます。この場合、/bootやswap領域など、サイズが限定される領域ではLVMが利用されませんが、/varや/homeなどの領域ではLVMが利用されるようです。

LPICレベル2の範囲でもありますし、実際に利用されている技術でもあるので、きちんと理解しておきましょう。

インデックスに戻る

fsckコマンド

今回は、「fsckコマンド」について。

fsckコマンドは、ファイルシステムにエラーがないかどうかのチェックと修復を行うコマンドで、ファイルシステムの管理には欠かせないコマンドだと言えます。

デフォルトの動作は、/etc/fstabに記述されているファイルシステムを対象に、エラーがないかどうかを逐次的にチェックします。エラーが見つかった場合、修復を試み、可能であれば修復をします。エラーが見つかるとダイアログで修復するか否かを聞いてくるので、ここで修復を行わないという使い方もできます。

注意点もあります。それは、このコマンドによるファイルシステムの修復は完全なものではなく、かえって問題を深刻化させてしまうケースもあるので、エラーが見つかったときに何も考えず修復を試みるのは却って危険なことがあるという点です。エラーが見つかったときにダイアログが出てくるのはそのためです。

コマンドには、「fsck /dev/hda1」のように、デバイス名を指定してチェックを行います。

さてこのfsckコマンドですが、基本的に「マウントされていない」ファイルシステムに対して実行します。fsckコマンド実行と同時にデータの書き換えが行われると、ファイルシステムを破壊してしまう恐れがあるためです。そのため、多くの場合は「シングルユーザモード」に移行してから実行することになります。また、システムをブートするプロセスの中で実行することもあります。

注意点も多いこのコマンドですが、ファイルシステムの管理を行う上で欠かせないツールですので、しっかり覚えておきましょう。

インデックスに戻る

syncコマンド

今回は、キャッシュの内容をディスクに書き込む「syncコマンド」について。

大抵のファイルシステムでは、ハードディスクにデータを書き込む・変更するときに、リアルタイムでハードディスクに書き込みを行っているのではなく、一時的にキャッシュに記録しておき、後でまとめてディスクに書き込む、という仕組みをとっています。これには、ディスクアクセスの頻度を下げることで負担を減らす、ジャーナルという仕組みを成立させる、などの意味があります。

しかしながら、この仕組みのせいで少し困ったことが起こる場合があります。
一番困るのが、停電などなんらかの原因でOSが落ちてしまったときです。キャッシュのデータをファイルシステムに書き込む前にOSが落ちてしまうと、ディスクのデータが整合せず、大きなトラブルの原因になることがあります。

「syncコマンド」は、キャッシュに存在する未処理のデータをディスクに書き込むコマンドです。オプションは必要なく、単に「sync」を実行するだけでファイルへの書き込みが行われます。

大切なのは、「shutdown」コマンドを利用した場合にも、この処理が行われるということです。「reboot」コマンドや「halt」コマンドでも同様です。
この事実を知っておいて下さい。裏を返すと、おかしな方法でシステムを停止した場合、この処理が行われず、データの不整合が起こる場合があるということです。システムの停止・再起動は適切な方法で行いましょう。

 

インデックスに戻る

ディレクトリサービス

今回は、「ディレクトリサービス」について。

「ディレクトリサービス」と言っても別に「ファイルシステムのディレクトリを提供してくれる」というわけではない、ということです。ディレクトリという用語が使われているので、ややこしいですね。

ディレクトリサービスとは、一般的に、「ネットワーク上に分散して存在する機器の情報を一元管理する」というサービスを指します。Linuxでは、主に「OpenLDAP」などがディレクトリサービスとして採用されています。
元々、「ディレクトリ（directory）」という言葉は、「住所録」や「電話帳」の意味を持ち、ファイルシステムのディレクトリと「ディレクトリサービス」のディレクトリは、語源は同じです。

ディレクトリサービスを利用すると、たとえばネットワークのリモートにあるアプリケーションを呼び出すときに、サーバの場所を意識する必要がなくなり、名前を指定するだけでアプリケーションを呼び出せるようになります。ユーザ名や所属グループ、パスワードなども一元管理でき、どのクライアントにログインする時にも共通のアカウントでログインできるようになります。

LDAPを中心としたディレクトリサービスは少々難しいのですが、利用できるようになれば非常に心強いシステムなので、是非挑戦してみてください。

インデックスに戻る

makeコマンド

今回は、makeコマンドについて。

makeコマンドは、Linuxにおいてソースファイルをコンパイルするのに必須のコマンドです。実際にはコンパイルだけでなく、ソースファイルの管理など、さまざまな役割を担っています。makeは、複数のファイルが依存して構成されているものをコンパイルする作業の負担を軽減する目的で作られました。開発を行う人はもちろん、Linuxを管理する人は必ず利用することになるコマンドです。

makeコマンドの特徴に、「大きなソースファイルの中で再コンパイルする必要がある部分を自動的に抽出し、再コンパイルのための手続きを実行する」というものがあります。この仕組みにより、再コンパイルを効率よく行うことができます。

makeコマンドを実行するためには、「Makefile」と呼ばれるファイルを記述しておく必要があります。このファイルには、プログラムを構成しているファイル同士の関係や、各ファイルの生成手順を記述します。

makeは、多くの場合C言語のソースコードに対して適用されますが、Makefileへの記述しだいでは、JavaのプログラムやTeXの文書など、さまざまなファイルに関してmakeを利用し、作業を効率化することができます。
たとえば、LinuxディストリビューションによってはSendmailの設定ファイルをマクロファイルから生成したり、各種設定ファイルを変換するためのMakefileを用意しています。

非常に奥の深いツールですので、ぜひ使いこなせるようになってください。

インデックスに戻る

IPv6への移行

今回は「IPv6への移行」について。

ニュースコメントでも触れたように、「IPv4」の新規アドレスの在庫が枯渇しました。

まず最初に知っておきたいことは、「IPv4」と「IPv6」は、全く異なるプロトコルだということです。ですから、両者を何の工夫もなしに、「混ぜて使う」ということはできません。ただし、「役割」は同じ…どちらもOSI参照モデルにおけるネットワーク層（第３層）にあり、データをホスト間でやりとりするために使われるという点では共通しているため、「共存する」ことは可能です。

では、「IPv6」に移行するためには、一体何が必要なのでしょうか。

まずは、物理的な問題があります。ルーターやレイヤー3のスイッチングをIPv6に対応させる必要があります。

次に、OSの対応が必要です。IPv6は、最近のOSであれば大抵対応しており、Linuxでは随分前から対応していますし、WindowsでもWindows XP/2003以降であれば対応しています（GUIでの設定ができるようになったのはWindows Vista以降）。Mac OS Xは10.2以降で対応しています。

そして、ソフトウェア側の対応が挙げられます。一部のソフトウェアはOSさえ対応してしまえばそのままIPv6で使えますが、ソフトウェア側に対策を講じないとIPv6が使えないという場面も発生します。ですから、ソフトウェア側についてもIPv6に対応しているか否かの注意が必要となります。

もっとも、ここに挙げた話が本当に必要になってくるのはもう少し先でしょう。
実際には「IPv4」アドレスの再利用（使われずに放置されているアドレスの再割り当てなど）の措置も取られる模様ですし、本当にIPv4を「新規で」使えなくなるまでにはもう少し時間があります。また、実際の運用では「IPv4」が浸透しすぎており、一斉に切り替えることが不可能なため、しばらく「IPv4」と「IPv6」を共存させながら移行する、ということになると考えられます。つまり、両方に対応した仕組みを作りあげながら、少しずつIPv6へ移行するということになるでしょう。

あまり急ぐ必要はないものの、全く無関心でも困る「IPv6」への移行。
ある日突然うろたえる、といったことのないよう、しっかり準備しておきましょう。

 

インデックスに戻る

RAIDによる信頼性の向上

今回は「RAIDによる信頼性の向上」について。

実はRAIDについては以前に触れたのですが、ずいぶん前ですし、今回、地震という災害に加えて計画停電の可能性があるため、改めてここで取り上げてみたいと思います。

RAIDとは、２台以上のHDDを組み合わせることで、信頼性を高める技術です。一口にRAIDと言っても、「RAID 0」「RAID 1」「RAID 5」などの種類があり、役割も違います。実用的なのはここに挙げた3つでしょう。そして、「信頼性の向上」という観点で見ると、「RAID 1」、すなわち「ミラーリング」の手法が重要になってきます。ミラーリングは、複数のHDDに全く同じデータを記録するという手法です。この場合、トラブルで片方のHDDが故障しても、もう片方を使えばデータやシステムの消失を抑えることができます。「冗長性を持たせる」という意味合いがあると考えるとよいでしょう。

また、復旧もそう難しくありません。故障したHDDを新しいものに入れ替え（システムを停止することなくできます）、データの書き込み作業を行えば、ふたたび利用できるようになります。

何かとデリケートなHDDですから、地震や停電の影響を受けやすく、トラブルも多いと言いわれます。一方、最近ではHDDが安価になってきたため、技術さえあれば簡単に導入できます。RAID1とRAID5を組み合わせる、などということも可能ですので、ぜひ導入を検討してみて下さい。

 

インデックスに戻る

電力不足対策

今回は「電力不足対策」について。

東北関東大震災の影響による電力不足によって、既に「計画停電」で苦労しておられる方も多いと思います。計画停電の時間になったら、サーバのシャットダウンを行わなければなりません。サーバにとって、電源をいきなり切ってしまうことは避けなければなりません。データの消失など、深刻なダメージを負う危険があるからです。最低でも「UPS（無停電電源装置）」の利用が好ましいといえます。

前回の豆知識で取り上げたデータセンターでは、大型のUPSや自家発電装置などによって、多少の停電でも停止しないように電源のバックアップを行っていますが、社内のサーバールームに置いているようなイントラネットのサーバではなかなかそうもいきません。イントラネットのサーバでバックアップサーバを運用しているのであれば、バックアップサーバだけでも別の拠点に移すという方法も考えられます。その場合、「VPN」などの技術が役に立ちます。

「節電」ということを考えると、新しいサーバーは性能に比較してかなりの電力消費節減が行えるようになっています。また、「仮想化」は１つのキーとなる技術になります。仮想化技術を駆使すれば、１つのマシンで複数のサーバを動作させることもできます。上手く活用すれば、かなりの節電効果が見込まれます。また、その他にも「節電ツール」をリリースしている企業もいくつか出てきています。

インデックスに戻る

データセンター

今回は「データセンター」について。

先日、大きな地震がありました。東北を中心に大きな被害が出ました。首都圏もかなり大きな揺れがありました。しかし、それでもサービスを停止できないインターネットサーバがあります。

大きな企業のWebサーバであれば、止まってしまうと死活問題になりかねません。そうでなくても、メールサーバが停止すれば、現代社会において重要な連絡手段である電子メールが使えなくなってしまいます。また、災害があるからこそ、情報を発信するべきサーバが動作していなくてはならない、ということも言えますね。

しかし、先日の地震では、多くのサーバが停止せず、情報を発信し続けました。「インターネットで情報を得た」という方も多かったのではないでしょうか。首都圏にあった数多くのサーバは、なぜ無事だったのか・・・

答えは、「データセンター」にあります。「データセンター」とは、サーバなどのコンピュータを設置することに「特化した建物」のことを言います。多くの企業、特に大企業は、データセンターにサーバを置いています。

このデータセンター、コンピュータを置くことに特化しているだけあって、ここにサーバを置くことのメリットは数多くあります。まず一つが「耐震」。震度７クラスの地震が来てもサーバが「停止しない」という作りになっている、というところもザラではありません。また、電源も非常用のものが確保されており、大容量の蓄電池が配備されています。すなわち「停電」のときでも停止しないというわけです。

このように、数多くのメリットがあるデータセンター。コストがかかる、サーバを手元においておくことができないという難点はありますが、「絶対に止められない」サーバであれば、利用しない手はありません。ぜひ覚えておいてください。

インデックスに戻る

トランザクション

今回は「トランザクション」について。

トランザクションとは、主にデータベースなどにおいて使われる用語で、「複数の処理を一つの処理としてまとめたもの」のことを指します。

よく引き合いに出されるのが、「銀行振り込み」の例です。たとえば、【A】という口座から【B】という口座に、3000円を振り込むという作業を考えます。この作業では、１）【A】から3000円を引き、２）【B】に3000円を足す、という操作を行うことになります。ここで、１）か２）のいずれか一方だけが失敗する、という事態は絶対に避けなければなりません。

もし１）だけが失敗すると【A】の残高が減らずに【B】の残高が増えてしまい、２）だけが失敗すると【A】の残高が減り【B】の残高は増えない、となってしまいます。これは、『１）と２）の両方の処理が失敗する』よりもはるかに性質の悪い事態となります。

そこで、『１）と２）の処理を、トランザクションとして１つにまとめる』ということを行います。この場合、トランザクションとしてまとまった処理は、「すべて成功」もしくは「すべて失敗」として処理されます。

このように、トランザクションとなった処理は、その中の１つでも失敗した場合、全部の処理を「失敗」として扱わせるところがポイントとなります。
全ての処理が成功したときのみ、全ての処理を「成功」として扱うことになるわけです。

トランザクションは、データベースのみならず、ファイルシステムなどにも応用される考え方ですので、その仕組みは是非理解しておいてください。

インデックスに戻る

冗長化

今回は「冗長化」について。

日常生活で「冗長」という単語は、「意味なく長い」という負のイメージをもって使われることが多いようです。しかし、ITで使われる「冗長化」は正のイメージを持ちます。

システムの冗長化とは、たとえばネットワーク上にまったく同じサーバを複数台用意することを指します。この場合、1つのサーバをメインとし、他のサーバはそのサーバの「コピー」「レプリカ」とします。すなわち
バックアップを取り、そのバックアップを普段から用意しておく、という手法を「冗長化」と言います。

冗長化には複数のメリットがあります。1つには「1台のサーバが故障しても、システムを継続することができる」、すなわち「耐障害性の向上」が挙げられます。趣味として運用しているWebサイトであればシステムが一時的にダウンしても問題ありませんが、企業のWebサイトがダウンするという事態は信用問題にかかわります。また、特に金融関係のWebサイトがダウンすることは、顧客に大きな損害を与えてしまうことがあるため、何としても避けなければなりません。ですからこのような重要なシステムでは冗長化は大きなメリットをもたらします。

もう1つが「負荷の分散」です。たとえば1台のWebサーバーに大量のアクセスが発生すると、それぞれのリクエストに対する応答が遅くなり、場合によってはまったくアクセスできなくなってしまいます。そこで、複数のサーバにアクセスを分散させるために、「冗長化」を行うのです。アクセスのリクエストを分散させる「ロードバランサ」を組み合わせて、複数のWebサーバーにリクエストを処理させます。

大きなシステムを運用するときには、冗長化は必須になります。コストや手間も増えますが、とても大切な技術ですので、ぜひ覚えておいてください。

インデックスに戻る

リポジトリ

今回は「リポジトリ」について。

「PersonalForge」のニュースでも紹介しましたが、ソフトウェアを公開する場として「リポジトリ」と呼ばれるデータベースが公開されています。

本来の「repository」という単語は「倉庫」「貯蔵庫」などの意味を持っています。オープンソースの世界で「リポジトリ」と言ったら、多くの場合、プログラムやバイナリの類が保管・公開されている場所を指します。

アプリケーションを開発する際、ただ単にソフトウェアを「置いておくだけ」というのは若干の危険が生じます。実際には、バージョンの管理や改ざんの防止などがネックになります。バージョンの管理は特に問題になります。
１つのソフトウェアを複数の開発者が開発するというケースも多く、この場合、特に「バージョン管理に関する混乱（たとえば、誰かがあるバージョンのコードにバージョンアップを施したことを知らずに、他の開発者が元のバージョンに別のバージョンアップを施してしまう、など）」が生じやすくなります。リポジトリでは、これらの問題をクリアするための「バージョン管理システム」など、ソフトウェアを公開するための機能を備えています。

また、ネットワーク経由で新しいソフトウェアを入手する、あるいはソフトウェアを新しいバージョンにバージョンアップするという操作を行う際、ネットワーク経由でバイナリもしくはコードをダウンロードしてくることになりますが、このときにバイナリ・コードが格納されているのは、多くの場合「リポジトリ」です。OSのパッケージ管理システムにリポジトリを登録しておくことで、ソフトウェアの格納場所を意識することなく、ソフトウェアをインストール・バージョンアップできることになります。

実はオープンソースソフトウェアを利用するときに欠かすことができない「リポジトリ」。特に開発者になったときには、その存在の大きさがわかることと思います。

インデックスに戻る

ディスククォータ（クォータ）

今回は「ディスククォータ」（「クォータ」）について。

個人でLinuxを利用していると忘れてしまいがちになるのが、「Linuxはマルチユーザ、すなわち複数のユーザが利用することを前提にして設計されたOSである」という点です。大企業や研究機関では、UNIX系OSを、それこそ何百人で同時に利用する、ということも珍しくありません。

このような場合に問題になるのが、ハードディスクの容量です。ハードディスクの容量が非常に大きくなった昨今ですが、無造作にファイルを置き続けると、ディスク容量が足りなくなってしまいます。多数のユーザが利用すると、悪意がなくてもハードディスクの容量を食いつぶしてしまうという危険が増します。そこで、UNIX系OSでは、「ユーザごとに、ハードディスクの容量制限をかける」という機能が提供されています。これが「ディスククォータ」です。

Linuxのディスククォータには、「ソフトリミット」と「ハードリミット」という、2種類の容量制限が設定できます。「ソフトリミット」は、ディスクの使用容量が、予め指定された容量に達した際に警告を発する（ただし警告するだけ）という制限、「ハードリミット」は、予め指定された容量に達した際に、ファイルへの書き込みができなくなるという制限です。ソフトリミットとハードリミットは同時に設定することができます。また、ソフトリミットに達した場合、一定時間が過ぎると、ファイルへの書き込みができなくなります。

多数のユーザが利用するUNIXマシンを管理する際には欠かせない機能である「ディスククォータ」。上手く活用して、快適なコンピュータ運用をしましょう。

インデックスに戻る

POSIX

今回は「POSIX」について。

POSIXとは、「Portable Operating System Interface for UNIX」の略です。
POSIXは、IEEEによって定められた、「UNIX系OSが備えるべき」とされる仕様の標準規格のことです。簡単に言うと、「あるOSがUNIX互換を名乗るために、そのOSが満たす標準規格」がPOSIXです。

前回までの豆知識で、FreeBSDとLinuxという、まったく異なるUNIX系OSが提供されていることを紹介しました。ほかにも、内部構造がまったく異なるUNIXライク（UNIXに似たOS）はいくつか存在しています。それぞれのOSは本質的にはまったく異なるものですから、下手をすると互換性が失われてしまい、「このアプリケーションはこのOSでは動作しない」といった事態が起きてしまいます。そこで、UNIXライクなOS間での互換性を保つために定義されたのが「POSIX」です。POSIXは、ANSI（アメリカ規格協会）やISOで標準規格として採用されています。

さて、このPOSIXですが、今回ニュースコメントで取り上げた「LSB」が、POSIXと整合するように作られています。そして、実は正式にPOSIXの認定を受けたLinuxディストリビューションはそれほど多くありません。多くのLinuxディストリビューションは、LSBを標準とすることで標準化を図っています。

色々とややこしい関係ですが、「POSIX」や「LSB」については「標準」となるべきものなだけに、知っておきたいところです。

インデックスに戻る

クラウドコンピューティング

今回は「クラウドコンピューティング」について。

「クラウド（Cloud）」は、「雲」の意味です。クラウドコンピューティングは、インターネット上のシステム全体を「雲」に見立てた形になります。
すなわち、「雲の中に隠れたシステムにアクセスして、さまざまなサービスを享受できる」のがクラウドコンピューティングです。「雲」の中に隠れたサーバを介してサービスが提供されるので、ユーザはサーバの存在を意識することなく、サービスを受けることになります。

クラウドコンピューティングの例として、「電子メール」を考えてみます。
従来は、ユーザがコンピュータにメールクライアントをインストールし、そのメールクライアントがメールサーバとデータをやりとりする形で電子ールを送受信していました。

一方、クラウドコンピューティングは、たとえばGmailなど、Webブラウザを介してインターネットと通信できる環境であれば、メールクライアントを利用することなくWebブラウザでメールの送受信を行うことができます。ここで、クラウドコンピューティングの要諦は「メールクライアントを介さない」という点でなく、「サーバの存在を意識しなくてよい（イメージとしては”雲の中にある”）」というところにあります。ただし、サーバの存在は「意識しない」だけであって、実際にはほとんどの処理を「サーバに丸投げしてしまっている」ことに注意してください。

このように、「ユーザがサーバにほとんどの作業を任せるが、そのことを意識しなくて済む」、というのがクラウドコンピューティングです。最近では、PCで行うことが当たり前であった表計算なども、クラウドコンピューティングによってインターネット越しにサーバに任せる、といったことも行われています。

クラウドコンピューティングを利用すると、サービス利用側の負担が軽くて済み、また専用のソフトウェアを必要としないため、たとえば携帯電話やPDAなど、それほど性能の高くない機器であってもサービスを享受できます。モバイル機器全盛の時代に合致した手法、ということができるでしょう。

クラウドコンピューティングは、今後重要度を増していく技術であることは間違いないでしょう。

インデックスに戻る

BSD

今回は「BSD」について。

「BSDはLinuxと違うのか」という質問は意外とあるようです。既にインストールされている場合、LinuxとBSDの間にいまひとつ差異が見出せないケースもあるようです。特にシェルだけを利用する場合、非常に似通っていて、違いを探すほうが大変かもしれません。

結論を言うと、「BSDとLinuxは、内部構造が全く違うOS」です。

Linuxは、元々Linus Torvalds氏が趣味でUNIXに倣って作り始めたプログラムが元になっていますが、BSD、すなわち「Berkeley Software Distribution」は、当時のUNIXをカリフォルニア大学バークレイ校が改良する形で始まったOSです。「BSDはUNIXの血を引いている、LinuxはUNIXに倣っている」という点で外見は似ていますが、内部は全く違います。ただし、OSは「ディストリビューション」という形で、さまざまなアプリケーションと一緒に配布されます。そのアプリケーションは、LinuxでもBSDでも同じように利用でき、実際に共通のものが採用されているケースも結構あります。
たとえば、セキュアに接続してコマンドラインを利用できる「OpenSSH」はBSDの一種であるOpenBSDから由来しています。他にも、Mac OS XはBSDの一種である「Darwin」をベースにしていますし、iPhoneやiPadのOSであるiOSもBSDの派生系をベースにしています。このあたり、LinuxをベースにしているAndroidと対照的です。

なお、LinuxやBSDが「UNIX」を名乗っていないのは、商標の都合です。
「UNIX仕様」を完全に満たしていないため、「UNIX系OS」という呼び方で括られています。

似ているようで違うLinuxとBSD。お互いに、良きライバルということができるかもしれません。

インデックスに戻る

Debian GNU/Linux

今回はLinuxディストリビューション「Debian GNU/Linux」について。

前回までに紹介した「CentOS」「Fedora」は、「Red Hat Linux」系統のLinuxディストリビューションです。一方の「Debian GNU/Linux」（以下、Debian）は、Red Hat Linuxとは全く異なる系譜のLinuxディストリビューションです。多くのLinuxディストリビューションが「Red Hat系列」か、「Debian系列」のどちらかに属しています。

Red Hat系列とDebian系列の何が違うかというと、一番大きいのは「パッケージ管理システム」です。Red Hat系列が「RPM」というパッケージ管理システムを使っているのに対して、Debian系列が「dpkg」というパッケージ管理システムを採用しています。両者の間に互換性はないため、基本的に
「Red Hat系列」のLinuxディストリビューションでDebian系列のパッケージを利用したり、「Debian系列」のLinuxディストリビューションでRed Hat系列のパッケージを利用することはできません。

そしてもう１つ知っておきたいことがあります。Debianは、常に「stable（安定版）」、「testing（テスト版）」、「unstable（不安定版）」の３つのバージョンがリリースされています。正式リリースとされるのは「stable」だけですが、「どんどん新しい機能が取り入れられるunstable版」、「次期正式リリース候補と位置づけられるtesting版」も、誰でも入手できるようになっています。

Debianでは、unstableの中に採り入れられた新しいパッケージが、一定期間致命的なバグが発見されなかった場合、testing版に組み入れられるという仕組みになっています。そして、stable版のリリースが近付くと更新が凍結され、すべてのRelease Criticalバグが解消されると、testingがstable（つまり正式版）としてリリースされます。

Debianの場合、stable版はその名の通り「安定」を重視されてリリースされるため、パッケージが少々「古い」ことが多いようです。一方のtesting版、unstable版は新しい機能が色々と使えますが、「正式リリースでないため、自己責任」となります。

Debianも、さまざまなLinuxディストリビューションのベースとして採用されています。正しく知っておきましょう。

インデックスに戻る

Fedora

今回は、Linuxディストリビューションの1つ、「Fedora」について。

前回は、「CentOS」について触れました。CentOSは、「Red Hat Enterprise Linux」との完全互換を目指したLinuxディストリビューションでした。一方で「Fedora」は、前回も少し触れたとおり、レッドハットが支援するコミュニティ「Fedora Project」によって開発されているLinuxディストリビューションです。ちなみに、バージョン6までは「Fedora Core」と呼称されていました。

「Fedora」は、新しい機能を積極的に取り入れる、という方針の下でリリースされています。Red Hat社は、自社の「Red Hat Enterprise Linux」を構築する上で、「Fedoraで新機能を採り入れ評価した後に、採り入れることが妥当と判断した機能を「Red Hat Enterprise Linux」に採用する」という方式を取っているため、「Fedora」には、実験的な機能も数多く含まれています。

「CentOS」と「Fedora」だと、どちらを使うのが良いですか？という質問が結構あります。「どちらが良い」と断じることはできませんが、特性として、「Fedoraは積極的に新しい機能を取り入れているが、そのためのリスク（不安定だったり、バグが存在する可能性）がある」ことを理解しておく必要があります（一方のCentOSは、「比較的安定しているが、搭載されているアプリケーションが最新でないことが多い、となります）」。

特性を正しく把握した上で、適切なLinuxディストリビューションを選択しましょう。

インデックスに戻る

CentOS

今回は、Linuxディストリビューションの1つ、「CentOS」について。

CentOSは、「Red Hat Enterprise Linux」との完全互換を目指したフリーのLinuxディストリビューションです。ただし、Red Hat Enterprise Linuxには、Red Hatが所有する商標や商用パッケージなどが含まれています。
CentOSは、Red Hat社が公開しているソースコードから、これらの商標や商用パッケージなどを除いた上でリビルドされているLinuxディストリビューションです。

CentOSは、Linuxに関わる上で１つの重要なディストリビューションだということができます。話しが少しさかのぼるのですが、2003年まではRed Hat社は「Red Hat Linux」というフリーのディストリビューションをリリースしていました。しかし、2003年に「Red Hat Linux」のリリースを打ち切り、「Fedora Core（現在のFedora）」に移行したのです。Fedora Coreは、Red Hat Linuxの事実上の後継ですが、「実験的」な側面が強い、すなわち不安定な機能やアプリケーションも積極的に採り入れています。Red Hat社は、Fedoraで新しい機能やアプリケーションを試した後、「Red Hat Enterprise Linux」に採り入れるという方式を取っているため、「CentOS」は、「最新機能は使えないが、比較的安定したOS」として利用できます。
また、メンテナンス更新期限もRed Hat Enterprise Linuxと同様7年程度と長くなっているため、サーバ向けに向いていると言われています。

Linuxディストリビューションは数多あれど、Red Hat系のディストリビューションの割合はやはり多いので、実戦段階で採用するかどうかは別として、Linuxを運用するのであれば常にその動向に注意しておきたいLinuxディストリビューションです。

インデックスに戻る

VPN

今回は、「VPN」について。

VPNとは、「Virtual Private Network」（仮想プライベートネットワーク）の略です。

企業などでも、大きな企業になれば、本社の他、いくつかの支社が存在するため、拠点が複数存在します。しかし、一つの組織である以上、これらの拠点を一つのネットワークにまとめることができれば便利です。すなわち、一つの組織で一つの大きなLANを構築できれば便利です。

このためにはどうすればよいでしょう？各拠点のLANを結び、一つにまとめてしまえばよいのです。このための仕組みが「VPN」です。

ただし、言うは易しく、行うは難しです。拠点を結ぶためには公衆インターネット回線を使うのが一番手っ取り早いですが、危険が氾濫している公衆インターネット回線を利用して結ぶのはあまりにもリスクが大きすぎます。

そこで、「公衆インターネット回線を利用し、通信の暗号化を組み合わせてVPNを実現する方法」や、「専用のネットワークを利用した、インターネットとは別に構成されたIPネットワークを利用する方法」などがあります。
VPNを実現するためのプロトコルとしてはPPTPやSSL、IPsecなどがあります。

技術的には少し難しいVPNですが、利用できるようになれば非常に便利な技術なので、是非頭に置いておいて下さい。

インデックスに戻る

オーバーヒート

今回は、「オーバーヒート」について。

オーバーヒートは、Linuxに限らず、コンピュータ全般に起こりえるトラブルですが、特にサーバにおいては注意しなければならないことと、時節柄の注意として、取り上げてみます。

「オーバーヒート」は、コンピュータなどを高温環境下に置くことで暴走するという現象です。特にコンピュータでは、CPUやメモリなどを稼動させるだけで発熱するので、ある程度以上の温度になると発熱がエスカレートし、温度の制御が効かなくなり、コンピュータが暴走するという危険があるのです。半導体には熱に弱いものが多いので、オーバーヒートを引き起こすと、コンピュータが暴走、強制停止、故障など、深刻なトラブルを引き起こします。

特にサーバには注意しなければなりません。サーバは24時間365日稼動させることも多いので、思わぬ時間に熱暴走を引き起こすこともあります。また、サーバの設置場所にも注意が必要です。部屋の隅など、熱が篭りやすい環境では、オーバーヒートを引き起こす危険が高くなります。

プログラムやクラッカーとはまた違うところに気を遣わなければいけないのですが、ゆめゆめ「サーバが夏バテして大切なデータが飛んだ」などということがないよう、気をつけて下さい。

インデックスに戻る

IPアドレスの枯渇問題

今回は、「IPアドレスの枯渇問題」について。

IPアドレスは、PCを管理したことがあるならば一度は目にしたことがあるでしょう。「192.168.1.254」のような番号です。「アドレス」という名前から「住所」と例えられることが多いのですが、「通し番号」というほうがぴったりくるかもしれません。また、「IPアドレス」は「PC」に割り当てられるというよりも「ネットワークインターフェイス」に割り当てられるという点も注目です。すなわち、一台のPCに1つとは限りません。1台のPCが複数のIPアドレスを持つこともあります。また、最近では家電製品もネットワークに接続できるものが現れてきており、ネットワークインターフェイスを持つ家電製品にも割り当てられます。

IPアドレスの割り当て方などには書籍などに譲りますが、現在主流になっているのは「IPv4」と呼ばれるプロトコルを元にしたものです。この方法ではIPアドレスは32ビットの数値で表されるため、「2の32乗」、すなわち約43億のネットワークインターフェイスにしか割り当てることができません。このため、インターネット上のIPアドレス、つまりグローバルIPアドレスの枯渇が心配されています。ある予測によると、2011年にもIPアドレスが枯渇すると言われています。

そこで、「IPv6」と呼ばれる新しいプロトコルが提唱されています。このプロトコルに依れば、IPアドレスが128ビットで表されるため、「2の128乗」、すなわち約34兆×10兆×1兆個のネットワークインターフェイスを接続することができます。この数であれば枯渇はまず心配ありません。

いいことづくめのようなIPv6ですが、問題点もあります。もっとも大きな問題は、「IPv4と互換性がないため、IPv4からの移行に手間と時間がかかる」という点でしょう。IPv4とIPv6は基本的に全く別のプロトコルですから、移行するためにはソフトウェアやネットワーク機器がIPv4とIPv6の両方に対応する必要があります。また、インターネット全体がIPv6に対応するにはかなりの時間がかかるため、本当に移行できるのかといった問題もあります。

いつかはやってくるであろうIPアドレスの枯渇、どうなるのか、避けて通れない問題と言えるでしょう。


インデックスに戻る

OpenSSH

今回は、OpenSSHについて。

「SSH」とは、暗号化通信を行うためのプロトコルです。パスワードなどの認証部分を含め、ネットワーク上の通信全てが暗号化されて行われます。
従来は、リモートホストとの通信にはTELNETと呼ばれるプロトコルが利用されていました。しかし、このプロトコルでは通信が全て平文で流されます。ネットワークを流れる通信は簡単に傍受できてしまうため、TELNETを用いた通信はパスワードも通信内容も流出してしまう危険が大きいものでした。
そのため、最近ではインターネット越しの通信でTELNETが利用されることはほとんどなく、SSHを用いたものに取って変わられつつあります。

OpenSSHは、SSHを利用した通信を行うためのソフトウェアで、OpenBSDプロジェクトにより開発が行われています。その名の通りオープンソースソフトウェアで、「BSDライセンス」の下で公開されています。実は、OpenSSHの開発が開始される前に、フリーのSSHソフトウェアは別のものが存在したのですが、これがオープンソースでなくなってしまったため、OpenSSHの開発が始まったという経緯があります。

皆さんのLinuxコンピュータでも、シェルで「ssh」コマンドを実行するとSSHプロトコルを利用した通信を行うことができますが、この時に起動するクライアントプログラムは、ほとんどの場合「OpenSSH」に含まれるものです。

OpenSSHには、SSHサーバ、SSHクライアントのほか、リモートホストとの間でファイルのやりとりを行う「scp」や「sftp」も含まれています。scpもsftpもOpenSSHのサブシステムとして提供されます。sshコマンドとあわせて、いずれもインターネットでの通信では非常に重要な機能なだけに、OpenSSHはいまや「重要」を通り越して「不可欠」といえるソフトウェアと言えるでしょう。

インデックスに戻る

暗号化鍵

今回は「暗号化鍵」について。

暗号化鍵（暗号鍵）とは、簡単な喩えで言うと次のような形になります。

たとえば、「アルファベット2文字分後ろにずらす」という暗号化を考えます。
「I love you.」という文章は、Iをアルファベットで後ろに2つずらすと「K」、「l」を2つずらすと「n」になる、「y」は「a」に戻る・・・これにより、「I love you.」は「K nqxg aqw.」となります。復号化するときには「2文字前にずらす」と良いわけです。

このときの、「何文字ずらすか」が「鍵」になります。同様の暗号化は、たとえば「3文字ずらす」「4文字ずらす」なども利用できるわけです。そこで、「何文字かずらす」という取り決めを行っておき、「では何文字ずらすのか」を「鍵」とすれば、「鍵」と「暗号化の取り決め」の両方がわからなければ、解読が不可能になります（注：当然、最近利用されている暗号化・暗号化鍵はこんな単純なものではありません）。

とはいえ、当然のことながら「鍵」が盗まれれば、簡単に第三者に解読されてしまいます。暗号化通信を行う際にはここが大きなネックになります。なぜならば、「鍵」をどう相手に伝えるか？という問題が発生するためです。鍵をネットワーク経由で送付すれば、盗まれる危険性が高くなるためです。

そこで「公開鍵暗号化法」という方法が考案されました。この方法は、「秘密鍵」と「公開鍵」の２つの鍵を用意し、たとえば「暗号化には公開鍵、復号化には秘密鍵を使う」というものです。公開鍵は外部に流してもよく、秘密鍵は外部に流さないという鍵です。こうすれば、公開鍵を第三者に盗まれても、復号化には使えませんから、暗号化された通信を解読することはできません。最近では、この「公開鍵暗号化法」が多くの場面で採用されています。

ちなみに、「公開鍵」とはいえ、解析などをされる恐れもあるので、公開鍵も不必要にばら蒔くのも考えものです。必要な時、必要な相手に限って公開するように心がけて下さい。

インデックスに戻る

暗号化通信

今回は「暗号化通信」について。

セキュリティの重要性は、今まで何度も説いてきた通りです。クラッキング行為の増加に伴って、その重要性はますます高まっています。そこで登場するのが「暗号化通信」です。

そもそもインターネットは、登場当初には「クラッカーの登場」というものを全く想定していませんでした。そのため、通信はほぼ「平文」、すなわち通信内容を何の加工もしないままネットワークに流す方式をとっていました。パスワードですら平文で流していたのですから、考えてみれば恐ろしいことです。ちなみに、現在でもPOPなどでは平文のままパスワードをやりとりすることがあります。クラッキングの実態などを考えると好ましいこととは言えませんね（パスワードを暗号化するAPOPや、SSL暗号化通信法の利用がセキュリティ上好ましいと言えます）。

そこで「暗号化」が登場します。「暗号化」といっても実にさまざまな方法があります。コンピュータの世界以外でも暗号化は使われていますね。原始的なところでは「山！」「川！」なども暗号化通信の一つです。しかし、単に「○○と言ったら××ということ」という取り決めだけでは、取り決めがわかってしまうだけで第三者に解読されてしまいます。そこで「鍵」を利用します。「鍵」を利用して暗号化・復号化するようにすれば、暗号化の取り決めがわかっただけでは解読が不可能です。暗号化・復号化のどちらにも、「鍵」が必要になるためです。

次回は、「暗号化鍵」について紹介します。

インデックスに戻る

USB

今回は「USB」について。

USBについては、使ったことが無いという方のほうが少ないでしょう。USBとは「Universal Serial Bus」の略で、その名の通り「統一規格」を目指しています。様々な機器を接続するために使われている規格で、最近では実に多くの機器がUSBに対応しています。１つのバスに、最大で127台の機器を接続できることが特徴の１つです。

もう一つは、「上位互換」が挙げられます。現在までに、「USB 1.0」、「USB 1.1」、「USB 2.0」、そして最新の「USB 3.0」が提供されていますが、下位規格のバスに上位規格の機器を接続（あるいはその逆）しても正しく動作します。

以前では、LinuxでUSBを利用するのは「鬼門」でした。技術的にも敷居が高く、USBで接続しようとしてもうまく動作しないということが多々あったのです。しかし、ここ数年でLinux側の対応が進み、LinuxでUSB機器を利用するための敷居は下がりました。kernel 2.4系列からサポートが始まり、最近ではさまざまなデバイスドライバも提供されているため、X Window System
を介せばプラグアンドプレイで動作することも少なくありません。とはいえ、まれに「うまく動作しない」ことがあるようです。この場合は、デバイスドライバなどを適切に組み込む必要が生じます。

当然のように普及しつつあるUSBですが、普及は急激でした。しかし、Linuxの進化も急激です。やがて、完全に対応する日がやってくることが期待されます。

インデックスに戻る

IEEE

今回は、「IEEE」について。

IEEEは、「The Institute of Electrical and Electronics Engineers, Inc.」の略で、「アイトリプルイー」と読むことが多いようです。

IEEEは、電子技術に関する学会の一つで、通信・電子・情報工学などから幅広い分野を取り扱っています。本部はアメリカにあり、世界各地に支部が分散しています。

同学会は、電子部品や通信方式などの「標準化」に取り組んでいることで知られています。標準を定めることによって、電子機器の利便性を増します。IEEEによって定められた標準は「IEEE 1394」のように、IEEEに数字を続けて表されます。ちなみに、IEEE 1394は、映像機器やコンピュータを接続するための高速シリアルバス規格の１つで、ビデオカメラなどをコンピュータに接続する、などに使われています。

IEEEは、Linuxに限らずコンピュータ、はては電子機器を使いこなすためには、今や避けて通ることができないものになっています。

Linuxで問題になる点で言えば、多くの場合は「ドライバ」でしょう。アプリケーションの側が対応しているかどうかの問題はもちろんですが、ドライバが正しくインストールされてロードされているか、kernelのバージョンと合致したドライバが導入されているか、といった点が問題になるようです。

「標準化」されたものだけに、つきあいを避けるわけにはいかないIEEE。上手に付き合えば、これほど心強い味方もいないでしょう。

インデックスに戻る

クラッカー

「クラッカー」（cracker：破壊者）は、「悪意を持ってコンピュータシステムを破壊・情報盗用・改ざんを行う人」を指す言葉として使われます。
「クラッカー＝悪意がある人」だと思ってよいでしょう。

さて、クラッカーが破壊行為を行う理由は何でしょうか？大きく分けて「愉快犯」と「利益目的」の２つがあります。「愉快犯」は、憂さ晴らしや、自分の技術力を誇示することが目的の人が多いようです。一方、「利益目的」のクラッカーは、たとえば企業の情報を盗み出して売り捌いたり、破壊して企業にダメージを与えるなどの目的があります。非常に厄介な存在です。ただし、クラッカーの内訳は、「ほとんどが愉快犯である」とされています。

クラッカーの技術力もさまざまです。以前は非常に高い知識を持っていないとクラッキング行為が行えませんでしたが、最近ではインターネット上にクラッキングツールなどが出回ってしまっているため、大した技術力がなくてもクラッキングができてしまいます。一方で、非常に高い技術力を持つクラッカーがいることも確かです。技術力をつける「動機」がはっきりとしていますので、なおのこと厄介なのです。

手口もさまざまです。単にサーバを停止に追いやるだけのもの、サーバの中身を消去・改竄してしまうもの、むしろサーバに手を入れずデータだけを盗み出すもの・・・。また、ツールを使って外部からサーバを攻撃するだけのものから、ウィルスやスパイウェアを利用したもの、サーバに侵入して徹底的に攻撃を仕掛けるなど、被害の度合いもさまざまです。

クラッカーにどう立ち向かうのか？は、サーバ管理を行う上で永遠の課題とも言えます。

インデックスに戻る

ハッカー

今回は、「ハッカー」について。

「ハッカー」（hacker）という用語は「誤用」が目立ちます。ハッカーを、「悪意を持ってコンピュータシステムを破壊・情報盗用・改ざんを行う人」、本来であれば「クラッカー（cracker：破壊者）」と呼ぶべき人を指す言葉で使っている場面が多いようです。しかし、本来のハッカーの意味は「クラッカー」とは全く違います。

「ハッカー」とは、コンピュータについて深い知識を持ち、その知識を持って高度な技術を駆使する人のことを指します。ここで技術を行使する場面は、「ソフトウェアを開発したり改良する」など、「破壊」とはほど遠い場面であることがほとんどです。また、かつてはクラッキングには高度な知識を必要としましたが、最近ではクラッキングは必ずしも高度な知識を必要としないことから考えても、「ハッカー」と「クラッカー」は全く別物と言ってよいでしょう。

「ハッカー」という用語にそれほど拘る必要性はないのですが、あえてもう少し解説をしてみたいと思います。

たとえば、ある開発プロジェクトで活動する、高度な技術を持つ開発者に対して「ハッカー」という呼び方はほとんどしません。「ハッカー」という用語は、個人的な活動を行う人や、趣味的に活動する人を指すことがほとんどです。

そして・・・Linuxなどのオープンソースソフトウェアは、「ハッカー」のおかげで今があると言っても過言ではありません。以前も紹介した通り、Linuxの生みの親、Linus Torvalds氏がLinuxの開発を行ったのも趣味が昂じてのものですし、Linuxの発展も、当初は非営利・趣味的に行われていたからです。

「Linuxはハッカーの手によって生み出された」・・・と言っても過言ではないでしょう。

インデックスに戻る

SQLとデータベース設計

今回は、「SQLとデータベース設計」について。

SQLとは、前回紹介した「リレーショナルデータベース」を制御するための言語です。リレーショナル型のデータベースからデータを検索したり、テーブル（表）を作ったり、データを入力・変更・削除するなどの作業を行うことができます。現在ではSQLは「事実上のリレーショナルデータベース制御の標準言語」となっており、SQLはリレーショナルデータベースの制御には絶対に欠かせないものになっています。

ちなみに、MySQL、PostgreSQLなどといったソフトウェアに「SQL」の文字が入っているため、「SQL」という用語は「リレーショナルデータベースのマネージメントシステムを指す用語」だと誤解されがちですが、実際にSQLが指しているのは「言語」です。

さて、このSQLという言語には少々厄介な面が存在します。それは、ソフトウェアによって若干の差異が存在するということです。「方言」と言えばわかりやすいでしょうか。たとえばMySQLとostgreSQLでは通じるSQLに違いがあるのです。そのため、SQLを習得するときに「これはどのマネージメント
システムでも通じる！」と思ってしまうと少し苦労するかもしれません。
とはいえ、大きな差異はないので、学ぶときに意識さえすれば問題ないでしょう。また、SQLはANSI(American National Standards Institute)で標準化が行われています。ANSIで標準化されているものとしてはC言語などがあります。興味があればANSI標準のSQLについても調べてみるといいでしょう。

データベースを学ぶ上で欠かせないのは「SQL」だけではありません。「データベース設計」についても学ぶ必要があります。設計せずに書かれたデータベースはたいてい「効率が非常に悪く」なります。SQLも同じで、効率の良い検索ができるようになるには、上手にデータベースを設計し、上手なSQL文が書けるようになるというスキルが必要になります。本当に小さなシステムを動かすだけならば問題になりませんが、少し込み入ったシステムとになると、「上手な設計、上手なSQL」が必須になります。学ぶときには「上手な設計と上手なSQL」を習得するように心がけてみて下さい。

インデックスに戻る

LAMP（ランプ）

今回は「LAMP（ランプ）」について。

LAMPとは、一つのソフトウェアを指す用語ではありません。「Linux」「Apache」「MySQL」、「PHP（PerlまたはPythonの場合もある）」の頭文字を取った用語です。

この組み合わせは、OSに「Linux」、Webサーバソフトに「Apache」データベースに「MySQL」、スクリプト言語に「PHP/Perl/Python」を使うというものです。この組み合わせは、「動的なWebサイトの構築に適したオープンソースソフトウェアの組み合わせ」なのです。

最近でこそ「動的」、すなわちユーザの入力によって出力内容が変化するWebサイトは当たり前になりつつあります。しかし、以前はWebサイトといえば「静的」なものがほとんどでした。すなわち、ユーザとの会話が成立しない、一方的に決まった情報を配信するというWebサイトばかりだったのです。
少しWebページの作成をしたことがある人ならわかると思いますが、静的なWebサイトを作成するにはHTMLの知識があれば事足ります。しかし、動的なWebサイトの作成には、PHPなどのプログラミングの知識が必要になります。さらに、膨大な量のデータをどう扱うか？というところがネックになります。

そこで、「Linux」と「Apache」を利用してWebサイトを公開できるようにし（静的コンテンツならばこの２つで十分）、スクリプト言語として「PHP/Perl/Python」を利用（動的コンテンツを組み立てるために必要）、そして大量なデータを格納・管理するためにMySQLを利用する、ということになります。この「LAMP」の組み合わせは動的なWebコンテンツを構築するのに強力な組み合わせで、現在では非常に多くのWebサイトに採用されています。

ちなみに、「MySQLの代わりにPostgreSQLを採用」した、「LAPP」というセットもあります。

インデックスに戻る

syslog

今回は、「syslog」について。

前回は「ログ」について取り上げました。syslogと言えば、ログを見たことがある方ならばピンと来るでしょう。syslogとは、システムのログを取るためのプログラムです。多くのUNIX系OSで採用されているプログラムで、「システム全体のログを採取する」という、システムを支える重要な役割を担っています。syslogの本体となるプログラムは「syslogd」というデーモンで、メモリに常駐してログを採取します。

syslogの特徴は、「/etc/syslog.conf」という設定ファイルで、「どのアプリケーションの、どの重要度のメッセージを、どのファイルに流すか？」といったことを細かく設定できるという点にあります。前回も少し触れましたが、あまりにも情報量が多いと管理者もログを見るのが大変なので、この機能をきちんと設定することで「特に注目したいアプリケーションに限って細かく情報を採取する」などといったことができます。

また、意外と知られていないのが、syslogは「ネットワークを通じて他のコンピュータとログを送受信する機能がある」という点です。SSLなどを利用して暗号化した通信を行うこともできるので、ログを１つのサーバに集約して集中管理するといったこともできます。

ログはシステムを使いこなすための必須アイテム、syslogはログ採取のための強力なツールです。ぜひ、使いこなせるようになって下さい。

インデックスに戻る

ログ

今回は、「ログ」について。

ログは、主にシステムやソフトウェアが残す「記録」のことです。語源は「航海日誌」を意味する「logbook」です。

良く「何かトラブルがあったり、自分の思い通りにならなかったら、ログを読め！」と言われます。たしかにシステムやソフトウェアが事細かに動作を記録している「ログ」は情報の宝庫で、ログを読めば問題解決の手がかりが得られるケースは非常に多いのです。

しかし「ログを読むのはどうも苦手」というユーザが多いというのも事実です。理由は単純で、ログの情報量が多すぎて、全部に目を通すのがあまりにも大変だというものが主なものでしょう。また、メッセージが英語であることも、英語が苦手な人からは敬遠されがちです。「ログには目を通す習慣をつけましょう」と言われてもなかなか実行できないかもしれません。

ログを読むときにはいくつかのコツがあります。まず「一番最後」を見てみること。ログファイルは、一番新しいログが一番最後に記録されています。
tailコマンドでもいいですし、lessコマンドで読み込んだ後、「G」（シフトキーを押しながら、大文字で）を入力すると一番最後の行が表示されます。

量が多すぎる時は「フィルタ」を通すこと。grepコマンドを使って、たとえば「warning」や「error」などのキーワードを探し出してそこを読む。
「Apacheが思ったように動かない」というのであれば「httpd」をキーワードにしてログを抽出し、手がかりを探すなどです。

また、「監視」も１つのコツです。ツールを使って、本当に大切なメッセージが出た場合にはメールで通知する（ただしこの場合は情報が漏れるのを防ぐために自ホスト内のユーザにメール送信するのがベストです）などです。

さらに、「集計」も有効です。ログ集計ツールも様々なものが出ていますから、たとえばアクセス解析や不具合がどのくらいの頻度で起きているのか？を集計するというのも使い方の一つです。

ログと上手く付き合って、システムをうまく使いこなしましょう。

インデックスに戻る

RFC

今回は、「RFC」について。

前回取り上げたNTPであれば「RFC1305に規定されている」、HTTPであれば「RFC2616に規定されている」のように使われるので、耳にしたことがある方も多いでしょう。

RFCはRequest For Commentsの略で、「IETF（Internet Engineering Task Force、http://www.ietf.org/）」によって公開された、インターネットで利用される技術についての標準を定めることを「目標とした」文書です。インターネットの技術のほとんどは、このRFCに記載された内容に則って成立しているといっても過言ではありません。

ところで、上で「目標とした」にカギ括弧をしたのには理由があります。実際にはインターネットで利用される技術は日々変化しており、標準化するのは難しい作業です。「これが標準だ」と定めても、状況に応じて変化することもあります。また、標準を定めても、何らかの不都合が生じる場合があります。

RFCは、「インターネットで利用される技術の標準を定めて」いますが、書き換わったり廃棄されたりする、ということもよく起こります。また、全てのRFCが「標準」ではなく、標準化の提唱や実験的なものもRFCとして発行されるため、注意が必要です。さらに、エイプリルフールにはジョークRFCが発行されることもあるため、「RFCの全部が完全に標準化されたものだ」と思い込んでいると大変な目に遭います。

とはいえ、RFCはインターネットの仕組みを支えている重要な文書であることに違いはありません。RFCは、http://www.rfcsearch.org/から検索することができますので、「RFCxxxx」という記述を見かけたら、一読してみることをお勧めします。

インデックスに戻る

NTP

今週は、「NTP」について。

前回、「タイムゾーン」、すなわち時間に関する話題を取り上げました。NTPは「Network Time Protocol」の略で、ネットワークを経由して、コンピュータが時計を正確な時刻に同期するためのプロトコルです。

PCに内蔵されている時計はかなり不正確なもので、一ヶ月も運用すると何秒かのずれが出てしまうこともあります。しかし、ネットワークサーバ用途で利用する場合、電子メールの送受信記録などで時計がずれていると異常が出る場合が多々あります。そのため、ネットワークで接続されたホスト同士は時計が互いに同期されている必要があります。これを解決するのがNTPです。

NTPはサーバ・クライアント方式で提供されます。「NTPサーバ」では、原子時計などを利用した正確な時計を持っており、NTPを通じてクライアントに正確な時刻を提供します。クライアント側は、Linuxでは「ntpdate」コマンドを利用するとNTPサーバと時計を同期することができます。ntpdateコマンドはrootユーザで利用します。下のようにntpdateにNTPサーバ名を指定すれば、指定したNTPサーバと同期されます。

# ntpdate ntp.nict.jp

これをcronで定期的に実行することで、サーバの時計を正確に保つことができます。

問題は、NTPサーバはどのサーバを使うか？です。「NICT 独立行政法人情報通信研究機構」では、「日本標準時プロジェクト」を行っており、公開NTPサーバを提供しています。

NICTの公開NTPサーバについて
http://www2.nict.go.jp/w/w114/stsi/PubNtp/

毎秒100万リクエスト以上をこなすことができるNTPサーバですが、むやみとアクセスしてもよいというわけではありません。ある程度の台数がまとまる場合には、ネットワーク内にNTPサーバを設置して、その他のコンピュータは自前のNTPサーバを参照するようにするとよいでしょう。

インデックスに戻る

LDAP

今回は「LDAP」について。

LDAPは、「Lightweight Directory Access Protocol」のことで、名前からわかるようにプロトコルの一つです。LDAPは、データベース（階層型DB）にアクセスする仕組みです。管理されるデータは、ユーザ名やパスワードなどの「アカウント情報」や、その他のユーザ情報が主となります。

LDAPは、「多くのコンピュータで、ユーザ情報などを一元管理したい」という場合に使われます。たとえば、教育機関や企業などで複数のマシンがあり、ユーザも多数存在するというときに有効です。

LDAPのような一元管理の仕組みが無いと、一つ一つのマシンにユーザ情報をいちいち登録する必要が出てきます。もちろん、ユーザ情報に変更が生じた場合には全部のマシンで変更作業が必要です。これはあまりに非効率的ですね。そこでLDAPの出番です。

LDAPは、ユーザ情報をサーバに一元的に管理することができ、各ホストはLDAPサーバに接続すれば共通のアカウント情報を利用することができます。
こうすれば、ユーザ情報に登録・変更が生じてもほとんど手間がかかりません。以前はこの仕組みを「NIS」と呼ばれるシステムで提供していましたが、最近ではLDAPが主流になっています。

LDAPを利用したときに得られるメリットはこれだけではありません。LDAPは、一元管理できる情報が他にもあり、アカウントだけでなくWebサーバの基本認証情報などを共有する、LDAPとメールサーバを連携させるといったこともできます。

多くのメリットがあるLDAP、一人でLinuxを利用するにはあまり縁がありませんが、少し人数とホストが増えただけでも導入するメリットは大いにあるので、ぜひ覚えておいてください。

インデックスに戻る

SCPとSFTP

今回は「SCPとSFTP」について取り上げたいと思います。

SCPもSFTPも、SSHの機能の１つとして提供されます。いずれも、SSHプロトコルを利用したファイル転送を実現します。ファイルの内容はもちろん、ログイン時のアカウント情報を平文でなくSSHによって暗号化された情報としてネットワークに流すことができ、セキュアなファイル転送を実現します。

SCPはCPコマンドに似せて、SFTPはFTPでのファイルのやり取りに似た方法で利用できます。SCPもSFTPも、「SSHを利用して暗号化したファイル転送を行うことができる」という点では共通しています。「WinSCP」や「FileZilla」などのクライアントもリリースされており、これを利用すれば、Windowsとの間でファイル転送を行うこともできます。

SCPとSFTPの相違点は、先に述べたように使い方、すなわちSCPは「SCPコマンド」に、SFTPは「FTPでファイルをやり取りする」のに似たように利用することができるという点が第一に挙げられます。違いはそれだけではなく、「SCPは比較的シンプルに作られており軽い、SFTPは多機能」という点があります。詳しく書き出すとキリがなくなりますが、両者の違いで大きな点が一つ「SFTPはファイル転送が中断しても再開が可能、SCPは不可能」という点が挙げられます。何らかの原因でファイルの転送が中断してしまうというのはよくある話ですので、この違いは大きな違いと言えます。

いずれにしても、ファイルの内容は知られたくないが転送はしたいという場合、FTPなどを利用するよりもSCPもしくはSFTPを利用するのがセキュリティ上は好ましいと言えます。

インデックスに戻る

BitTorrent

今回は、BitTorrentについて。

BitTorrentは、ファイルを転送するためのプロトコルの一種です。サーバの負担が少なくて済み、高速でファイルを転送することができます。BitTorrentの大きな特徴は、サーバはファイルを断片的にクライアントにアップロードするという点にあります。クライアントは、サーバから断片を受け取ると同時に、自分が持っている断片を、他のクライアントに渡すという方式でファイルをダウンロードします。いわば、多くのクライアントが「協力して」ファイルをダウンロードすることになるのです。すなわち、BitTorrentでは、多くのクライアントがあればあるほど、ダウンロード速度が向上するという特徴があります。このため、BitTorrentは、CD-ROMやDVD-ROMのISOイメージなど、サイズが大きく、かつ多くのユーザに配布する際に使われます。

BitTorrentは以上のような仕組みから成っているため、従来であれば「ファイルのダウンロードはクライアントが多いほど遅くなる」となるところを、逆に「クライアントが多いほど早くなる」という特徴を実現させました。
コロンブスの卵的な発想ということができるでしょう。

BitTorrentのクライアントには、「BitTornado」「Transmission」と呼ばれるソフトウェアのほか、KDEに含まれる「KTorrent」など、数多くのソフトウェアがあります。また、Firefoxなど、BitTorrentに対応したWebブラウザもあります。使う人が多ければ多いほどメリットがあるというBitTorrent、大きなファイルをダウンロードする際には是非活用してみて下さい。

インデックスに戻る

ダイナミックDNS（DDNS）

今回は、ダイナミックDNS（DDNS）について。

DNSは、先週も紹介した通り、ホスト名とIPアドレスを対応づける仕組みを提供します。「ダイナミックDNS」は、ホスト名とIPアドレスの対応を「動的に」管理する仕組みを提供するものです。

従来のDNSは、IPアドレスが変わることは考慮されていません。しかし、この状況では、DHCPを利用したネットワークでは、ホストに割り当てられたIPアドレスが変わることがたびたび発生します。これでは、ホスト名が毎回異なるホストを指すことになってしまいます。ここで「ダイナミックDNS」を利用すると、IPアドレスが変更されても、その変更が反映され、ホスト名とIPアドレスの対応がきちんと取れるようになっています。

ダイナミックDNSは、個人的なサーバを運用する際によく利用されます。多くのブロードバンド回線では、個人向けにはプロバイダから動的にIPアドレスが割り当てられます。そのため、接続が切断されるたびにホストに異なるIPアドレスが割り当てられてしまうということがたびたび生じます。このような場合でも、ダイナミックDNSを利用すれば、ホスト名と変更されたIPアドレスの対応を自動的に取ってくれます。このため、固定IPアドレスがなくてもサーバの運用が可能になります。

このように、ダイナミックDNSを利用すれば、きちんとホスト名がついたサーバを運用することが簡単にできます。ただし、問題点もあります。ダイナミックDNSでは、IPアドレスが変更されたときに、その変更がDNSに反映されるまで少し時間がかかります。その間には、ホスト名とIPアドレスが正しく対応できておらず、ホスト名が別のホストを指してしまうことになります。このため、サーバの運用にダイナミックDNSを利用するのは少々危険を伴うことになります。ダイナミックDNSを利用したサーバ運用には、セキュリティ面からの否定的な意見も少なからず存在します。営利目的のサーバ運用にダイナミックDNSを利用するのは危険ですし、個人用途でのサーバ運用で利用する際も、危険性を考慮した上で利用するようにして下さい。

インデックスに戻る

DNSサーバー

今回は、「DNSサーバー」について。

DNS（Domain Name System）サーバーは、ネームサーバーとも呼ばれます。
インターネットを利用する際、DNSサーバー（ネームサーバー）は必ず指定するので、その名前を一回は耳にしたことがあるでしょう。

さて、このDNSサーバーですが、この役割は何でしょう？

インターネットでホストに接続する際、ユーザーはホストを「www.lpi.or.jp」のようなドメイン名で指定します。このドメイン名は、ユーザーにとってわかりやすい名前になっています。しかし、コンピューターは、ネットワーク上にあるホストを「202.218.212.222」のようなIPアドレスで識別します。この、ドメイン名とIPアドレスを対応づけるのがDNSサーバーの役割です。

DNSサーバーの役割は、大雑把に言って２つの役割があります。
１つは、クライアントからの問い合わせに応じて、ドメイン名からIPアドレスを調べる（あるいはその逆）という役割。これを「フルサービスリゾルバ」と呼びます。問い合わせを行うクライアントを「スタブリゾルバ」と呼びます。
もう１つは、ドメイン名とIPアドレスの対応データを管理・提供するという役割です。これを「コンテンツサーバー」と呼びます。
DNSサーバーによっては、両方の役割を兼ねているものもありますし、片方だけの役割をこなすものもあります。

DNSの仕組みは複雑ですが、一つ言えることは、DNSサーバーはほとんどの場合、1台だけではその意味をなさないということです。インターネットでは、複数台のDNSサーバーが連携して「ドメイン名とIPアドレスを関連付ける」という目的を達成します。この理由は比較的単純です。インターネットに接続されたホストは膨大な数に上りますので、1台のDNSサーバーで全てのドメイン名を管理することは不可能なのです。このため、DNSサーバーでは「分散管理」、すなわちドメイン名とIPアドレスの対応は1台のDNSサーバーあたり数個〜数十個程度に留めるのです。そして、「複数台のDNSサーバーが連携して動作することによって」ドメイン名からIPアドレスを調べる、という作業を行うわけです。

DNSサーバーの仕組みは少し難しいですが、「複数のDNSサーバーが連携する」ということを頭に入れておくと理解しやすくなると思います。

インデックスに戻る

メールサーバー

今回は、「メールサーバー」について。

メールサーバーには、通常２つのサーバーソフトウェアが動作しています。
「SMTPサーバー」と、「POPサーバーやIMAPサーバーなど」の２つのソフトウェアです。

このことは、メールクライアントを利用している方ならピンと来るかもしれません。メールクライアントをセットアップする時に、「送信サーバー」と「受信サーバー」を指定します。同一のサーバーを指定することも少なくありませんが、「送信サーバー」と「受信サーバー」を指定するということは、メールの送受信には「メール送信のサーバーソフト」「メール受信のサーバーソフト」が必要だということです。

メールを送信する際、メールの経路を単純に表すと

[送信者側のSMTPサーバー]
→
[受信者側のSMTPサーバー]
↑
↓
[送信メールクライアント]
[受信メールクライアント]

の順に渡ります。すなわち送信者はSMTPサーバーにメールを渡し、SMTP（Simple Mail Transfer Protocol）プロトコルを利用して目的のメールサーバーへ送り届けます。そして、受信メールクライアントは、POPサーバーからメールを受け取る、という手順でメールがやりとりされます。

SMTPサーバーのことをMTA(Mail Transfer Agent)、メールクライアントのことをMUA(Mail User Agent)と呼ぶこともありますので、覚えておくとよいでしょう。

インデックスに戻る

GCC

今回は、「GCC」について。

GCCとは、「GNU Compiler Collection」の略で、C、C++、FORTRAN、Javaなどいくつかの言語のコンパイラ、およびこれらのライブラリから構成されています。コンパイラ本体だけでなく、コンパイルに必要なライブラリも含まれていますので、GCCを利用すれば、さまざまな言語で書かれたソースコードをコンパイルすることができるのです。

GCCはフリーソフトウェアであり、ほとんどのLinuxディストリビューションに含まれているので、Linuxを利用すれば手軽に利用することができます。
というよりも、「Linuxを語る上でGCCを外すことはできない」といったほうが正しいかもしれません。

GCCを利用する重要な場面の一つに、「Linuxカーネルの構築」があります。
Linuxカーネルをコンパイルする際には、ソースコードをGCCを利用してコンパイルを行います。卵が先か鶏が先か、のような話になりますが、GCCはLinuxの環境を構築する際に欠かせないツール、ということになるのです。

最近では、Linuxカーネルの構築という作業をほとんど行うことなしにLinuxを利用することもできます。このため、Linuxカーネルのコンパイルを経験したことがないという方も多いかもしれません。しかし、細かいチューニングや最適化を施す、機能を追加するなどの際にはカーネルの構築は避けて通れない作業です。

カーネルの構築以外にも、さまざまなアプリケーションのコンパイルにGCCを使うことになります。「開発をやらないからGCCには縁がない」ということはありません。長くLinuxを利用するのであれば、GCCを利用したコンパイルという作業には必ず出会うことになりますので、覚えておきましょう。

インデックスに戻る

コンパイラとインタプリタ

今回は、「コンパイラとインタプリタ」について。

プログラミング言語は、C言語などに代表されるコンパイラ型言語と、Perlなどに代表されるインタプリタ型言語があります。どちらも、プログラミングは人間が理解できる形で記述しますが、このままではコンピュータには理解できません。そこで、コンパイラとインタプリタの出番です。

コンパイラ型言語は、人間が読めるコードを「コンパイラ」を使ってコンピュータが理解できる形の「機械語」によるファイルに変換し、そのファイルを実行することでプログラムを実行します。一方、インタプリタ型言語の場合は、人間が読めるコードを「インタプリタ」を使って、コードを「逐次解釈しながら」プログラムを実行します。

なお、言語によってはコンパイラとインタプリタの両方が使えるものも存在します。

コンパイラ型は、インタプリタを介さないため一般に高速です。一方で開発の際、コードを書き換えるたびにコンパイル作業が必要になるため、コードの記述やデバッグに時間がかかります。インタプリタ型は一般にコンパイラ型よりも速度に劣りますが、コードを記述すればすぐに実行に移すことができるという利点があります。

コンパイル型とインタプリタ型はそれぞれに一長一短がありますので、どちらが優れているかという話よりも、シチュエーションに合わせた選択が重要になります。

インデックスに戻る

プロキシサーバー

今回は、プロキシサーバーについて。

会社からはプロキシサーバーを通さないとインターネットの接続ができなかったり、そのプロキシのせいで一部のサービスが利用制限を受けたり・・・。

何のためにこんなものが存在するのだろう？という方もおられるかと思います。

そもそもProxyとは、「代理」という意味です。プロキシサーバーの役割は、クライアントとサーバーの間に入って、サーバーに対してはクライアントの、クライアントに対してはサーバーの働きをするというものです。

もっともわかりやすいのが、HTTPプロキシは「クライアントからリクエストがあった場合、プロキシサーバーはリクエストを受け取って、クライアントの代わりにWebサーバーにアクセスし、結果を取得する。そしてその結果をクライアントに返す」となります。

この作業は何のために行うのでしょう？1つには、Webサーバーが送ってきたデータを保存しておき、次回同じアクセスがあった場合にはプロキシサーバーに保存されたデータをクライアントに返すことで、データの取得を高速化するという「キャッシュ」の役割があります。しかし、インターネットの高速化が進んだ現在ではこの意味は薄れています。

現在のプロキシサーバーの大きな意味は、セキュリティにあると言えます。外部とのやりとりがすべて一旦プロキシを経由することになりますので、プロキシが不正な通信などがないかを逐一チェックすることで、内部ネットワークを守るといったイメージです。もちろん、アクセスログを記録しておくということもできます。

このほかにも、会社で利用する場合などにはフィルタリング、すなわち就業時間内に閲覧することが相応しくないWebサイトへのアクセスを制限する、などの用途があります。

ネットワークの利用を適正化するためには、なくてはならない存在といえるでしょう。

インデックスに戻る

パッチ

今回は、「パッチ」について。

バグやセキュリティホールがあると、パッチが公開されます。そのパッチを適用することで、バグやセキュリティホールへの対処とします。

それでは、「パッチ」とは一体何でしょうか。

パッチとは、プログラムの一部だけを更新・追加することで、バグの修正・セキュリティホールの修正・機能追加や変更を行なうため、小さいプログラムコードのことです。もちろんパッチだけではプログラムは動作しません。
本体となるプログラムにパッチを「付け加える」ことで、プログラムが更新され、動作するようになります。

「パッチ（patch）」とは元々「継ぎ当ての小さい布」のことを指します。
すなわち、まさにプログラムに付け足して、穴を塞ぐ「当て布」がパッチだ、ということができるでしょう。

ちなみに、パッチの適用にはpatchコマンドなどを利用する必要があります。
エディタなどでパッチを適用するということもできますが、慣れていないと危険な方法です。

パッチは、元々ネットワーク環境が未発達だった時代に、大きなプログラムをダウンロードすることなく更新ができるということで考え出されたものです。
ネットワーク環境が発達した現在でも、差分のみを適用すれば十分という状況では、良く使われる手法です。

インデックスに戻る

サーバー

今回は、「サーバー」という用語について。

「何を唐突に」と思う方もおられることでしょう。そこで次のお題について少し考えてみて下さい。

A) 「Webサーバーとは、Webページのデータを提供するためのソフトウェアを指す」
B) 「Webサーバーとは、上記のソフトウェアが動作しているハードウェアを指す」

さて、どちらの文章が正しいでしょうか？

答えは、「両方正解」です。

つまり、「サーバー」と言った場合、ソフトウェアを指す場合と、ハードウェアを指す場合があるのです。たとえば、「Apache」というソフトウェアは「Webサーバー」ですし、「Apacheが稼動しており、Webページの情報を提供するハードウェアも「Webサーバー」と呼ぶことができます。

専門用語というのはなかなかややこしい面もあり、たとえば「Linux」といった場合には厳密にはカーネルの部分のみを指す、というのは有名な話です。「サーバー（Server)」という用語の場合は、「サービスの提供者」を指しますので、ハードウェア、ソフトウェアのどちらも、サービスを提供するもの、という意味合いで「サーバー」と呼ぶことができるわけです。

このように、専門用語はかなりややこしい一面を持っています。常時神経質になる必要はないと思いますが、たまには専門用語の正確な意味を把握する機会を持つとよいでしょう。

インデックスに戻る

/procディレクトリ

今回は、/procディレクトリについて。

/procディレクトリは、システムの状態などがファイルとして保管されている特殊なディレクトリで、このディレクトリにあるファイルは、メモリ上に作られる仮想的なファイルです。/procディレクトリ配下にあるファイルは、さまざまなプロセスを動作させる際にたびたび参照されます。ですから、Linuxの動作を決める上でとても大切なディレクトリと言えます。

ここのファイルを参照すると、さまざまな情報を得ることができます。たとえば、コマンドラインから「cat /proc/cpuinfo」と入力してみて下さい。
CPUの情報を得ることができます。他にも、メモリの情報、ドライバの情報、その他ハードウェア面・ソフトウェア面についてさまざまな情報を得ることができます。

そして、/procにあるファイルを編集すれば、システムの状態を調整することもできます。たとえば、iptablesを使ってルーターを作る場合に/proc/sys/net/ipv4/ip_forwardの値を変更します。ただし、これはかなり高度な知識を必要とします。正しく知れば非常に便利なのですが、裏を返せば、誤った改変をするとシステムを破壊することにもなりかねません。曖昧な知識のまま、むやみに変更することは避けて下さい。

インデックスに戻る

cron

今回は、「cron」について。

cronとは、「定期的にタスクを自動実行するためのツール」です。「クーロン」と読みます。cronを利用すると、時間を指定して、予め決まった時間にタスクを実行してくれます。

時間の指定は、「一時間に一回」などのような単純なものだけではなく、ある曜日のある時刻にだけタスクを実行する、とか、8時〜22時の間だけ一時間に一回タスクを実行するなどの処理を行うこともできます。時刻は具体的に指定することができます。使い方は少し特徴的であるものの、それほど難しくありません。

cronは、Linuxを運用する上で欠かせないツールと言えます。定期的にログを取ったりソフトウェアの管理を行ったり、システムをチェックするのに使われています。また、プロセスや他ホストが正しく動作しているかどうかを「監視」するためにも使うことができます。非常に便利で、かつ、なくてはならないツールです。

このcronですが、意外と知られていないことに、一般ユーザでも利用できます。一般ユーザで実行できるタスクであれば、ユーザごとに独自のcronを設定することができます（ただし、システムの設定によっては利用できない場合もあります）。ですから、cronとシェルスクリプトを組み合わせれば、root権限を持たないホストから、自分のホストを監視するといった使い方もできます。

cronの利用方法は、LPIC 102試験の範囲にも含まれています。必ずマスターしておきたい事項です。

インデックスに戻る

仮想化技術

今回は、「仮想化技術」の続きです。

仮想化技術とは、前回紹介したように「コンピューターの数と異なる数のOSを動作させることを可能にする技術」ということができます。今回は、この技術がどのように利用されているのかを紹介したいと思います。

一つには、「1台のコンピューターで、複数OSを動作させることができる」という点。個人ユーザーの視点からすれば、この使い方がもっとも身近な利用法でしょう。あるOSから、仮想化ソフトウェアを利用してLinuxを動作させて利用し、Linuxの勉強をしているという方も多いようです。

もう一つ、実はこちらの利用法も大きな注目を浴びているのですが、「複数のコンピューターで1つのシステムを構成する」ということもできます。この利用法では、複数のコンピューターの能力を集約させてシステムを作ることができるため、1台では実現が難しい性能を引き出すことができます。しかし、それだけではありません。この方法のメリットは、「必要に応じて、リソースを調整することができる」という点にもあるのです。

普通、何らかのサービスを提供するときには、そのサーバが要求される最大の能力を持たせます。そうでないと、リクエストが集中したときにサーバーがダウンしてしまいます。しかし、仮想化技術を使うと、リクエストに応じて動的にリソースを割り当てることができるため、リソースの節約、もしくは余ったリソースを他に回すなど、効率的なシステム運用が可能になるのです。このため、大規模なシステムを構成する技術として注目を浴びているのです。

Linuxと仮想化技術の関係では、XenやLinux LVMなどが注目されているので、今後のスキルとして是非身につけていくといいでしょう。

インデックスに戻る

仮想化技術

今回は、「仮想化技術」について。

仮想化技術、単に「仮想化」と呼ばれることもありますが、最近よく見かける言葉となりました。しかし、その意味は意外と知られていません。一体なにを仮想するのか？そもそも何の役に立つのか？

仮想化ソフトウェアで有名なものに、VMwareやVirtualBoxといったものがあります。これらのソフトウェアは、簡単に言えば、あるOSの上に仮想的なコンピュータを作成し、そこで別のOSを動作させるソフトウェアです。すなわち、1つのコンピュータの上で複数のOSを動作させることができるのです。

この仕組みを提供するのが仮想化技術ですが、仮想化技術は「1つのコンピュータで複数のOSを動作させる」だけではありません。「複数のコンピュータで1つのOSを動作させる」といったこともできるのです。すなわち、仮想化技術を利用すると、「コンピュータの数と異なる数のOSを動作 させることができる」のです。

仮想化技術によって、コンピュータの数とOSの数のバランスを適宜調整することも可能です。必要に応じて、OSに割り当てるコンピュータの数を変えることもできます。「必要に応じて、コンピュータの能力を適切に割り振る仕組みを提供してくれる」のが仮想化の効用だということができるでしょう。

仮想化の具体的な効用については、次回取り上げたいと思います。

インデックスに戻る

シェルスクリプト

今回は、「シェルスクリプト」について。

シェルは前回取り上げた通り、「Linuxとユーザーをつなぐインターフェイスとなるソフトウェア」です。Linuxでは、シェルを通じてシステムを操作するという局面が多くなります。

ここで、定期的にシステムを監視するなど、「何度も類似の操作を繰り返して行いたい」というケースを考えます。このケースでは、シェルに対して何度も同じようなコマンドを入力することになります。これは手間がかかります。

そこでシェルには、事前に一連の操作（実行するコマンドなど）をプログラムのような形でファイルに記述しておき、そのファイルの内容を実行するという機能が備わっています。このファイルを「シェルスクリプト」と呼びます。

「スクリプト」とは「台本」という意味です。つまり、予めシェルスクリプトという「台本」を用意しておき、その台本に則った操作を行える、というわけです。シェルスクリプトは「シェルを言語としたプログラム言語」という言い方もできます。

シェルスクリプトでは、変数や条件判定など、さまざまなプログラミング的なテクニックが利用できます。つまり、毎回同じ操作を行うだけではなく、状況に応じて処理を変えたり、ユーザからの入力を促す、数値計算を行うなど、一般のプログラミング言語と同じようなことがシェルを利用して実現できます。

Linuxでは、システムを動作させるためにシェルスクリプトを多用しています。
たとえば、ブート時の処理やログの管理などにシェルスクリプトを利用しています。ですから、Linuxを本格的に管理・運用するためには、シェルスクリプトの理解が必要になります。シェルスクリプトを勉強することは、シェルスクリプトとシステム管理の両方の理解につながるので、一石二鳥。
それほど難しくはないので、是非チャレンジしてみましょう。

まずは/etc/init.dディレクトリに格納されている各種サービスを起動するためのスクリプトの内容をチェックしてみるとよいでしょう。

インデックスに戻る

シェル

今回は、「シェル」について。

「シェル」とは実体が見えにくいので、意外と理解しづらい概念かもしれません。最近のLinuxディストリビューションはほとんどがデフォルトでX Window Systemによって操作できるため、余計「シェルって何だ？」というのが見えづらくなっています。

UNIX系OSで言うシェルとは、「OSのカーネルとユーザを結びつける、コマンドラインインターフェイス」を指します。コマンドラインインターフェイスというのは、マウスを使わず、キーボードからコマンドを入力し、「文字」でやりとりするインターフェイスのことです。すなわち、シェルは、カーネルとユーザが文字で入力・出力を行うためのプログラムです。

X Window Systemが起動しているところからCtrl+Alt+F1キーを押すと、テキストベースのログイン画面が現れます。この画面でユーザ名とパスワードを入力すると、シェルが起動します。シェルが起動すると、プロンプトが表示されます。このプロンプトに続けてコマンドを入力すると、さまざまな操作を行うことができます。このとき、ユーザのコマンドをカーネルに伝え、またカーネルからの実行結果をユーザに伝えるのが、シェルです。ちなみに、シェルは、X Window Systemの「GNOMEターミナル」などを起動したときにも動作します。

Linuxを使いこなすためにはシェルの理解が欠かせません。シェルから様々なコマンドを実行することでできることも多いからです。デスクトップ環境などでさまざまなツールが用意されており、シェルを使わなくてもさまざまな作業ができるようになってはいますが、シェルを使ってコマンドを入力し、Linuxを操ることができるようになれば、さらにいろいろなことができるようになります。

また、インターネットサーバでは、セキュリティの観点からX Window Systemが利用できないようになっているケースもあります。このような場合、シェルが使いこなせないとサーバを操ることは不可能に近くなります。

シェルは思ったほど難しくありません。キーボードで全てを操るのであると割り切れば、あとは練習あるのみです。果敢にアタックしてみて下さい。

補足ですが、「シェル」にはもう一つの意味があります。ユーザがカーネルに指示を与え、またカーネルからの結果をユーザに伝えるプログラムは、コマンドラインベースでなくてもすべて「シェル」と呼ぶこともできます。
この場合、X Window Systemのアプリケーションなどもシェルとして捉えることができてしまいます。とはいえ、Linuxで「シェル」と言った場合はほとんどが「コマンドラインベースのインターフェイス」を指す、と思って構わないでしょう。

インデックスに戻る

デスクトップ環境

今回は「デスクトップ環境」について。

前回、X Window Systemについて取り上げましたが、X Window Systemとデスクトップ環境の違いは意外と見えにくいですね。少し考えてみて下さい。

X Window Systemは、GUI環境を提供するソフトウェアあるいはプロトコルのことを指すのでした。これに対し、「デスクトップ環境」は、ツールバーやアイコン、ウィンドウマネージャ、ファイルマネージャなど、様々なソフトウェアをまとめたGUIソフトウェア群ということができます。言い換えると、そのまま「デスクトップ作業を行うのに必要なソフトウェア群をまとめたもの」とも言えるでしょう。

デスクトップ環境で有名なものは、「GNOME」「KDE」などがあります。最近では、使っているデスクトップ環境がGNOMEだとかKDEだとか、そういったことを意識させないような造りになっているLinuxディストリビューションも数多く見られます。これは、UNIX系向けのデスクトップ環境の多くが、柔軟なカスタマイズができるように作られているためです。この特徴を生かして、自分が使いやすい、好みのデスクトップを作り出すことすらできるわけです。

さて、これらのデスクトップ環境ですが、動作させるためにはやはり「X Window System」が必要になります。X Window Systemの上でデスクトップ環境が動作しているとも言えるのです。普段はデスクトップ環境とX Window Systemの違いをあまり気にしなくても良いのですが、時にはこういったことにも目を向けてみるとよいと思います。

インデックスに戻る

X Window System

今回は、「X Window System」について。

X Window Systemは、UNIX系OSにてウィンドウシステムを提供するソフトウェア、あるいは仕組みを指します。LinuxにおいてGUI環境を利用する上で欠かせないものとなっています。

X Window Systemは、マサチューセッツ工科大学の研究グループにおいて生まれ、現在ではX.Org Foundationが開発の中心を担っています。現在のバージョンは「X11」（version 11）です。

さて、ここまではご存知の方も多いかと思いますが、X Window Systemにおいて意外と知られていないのが「サーバー・クライアントシステムを採用している」点です。このため、ネットワーク越しにX Window Systemを利用することが可能です。
たとえば、あるコンピュータで走らせているアプリケーションを、ネットワーク経由でリモートの画面に表示させることもできます。

ここからが紛らわしい話になるのですが、X Window Systemにおいては、ユーザが利用しているコンピュータで「Xサーバー」が動作しており、これがさまざまな「クライアント」と通信します。クライアントは、Webブラウザなどのアプリケーションです。すなわち、多くのサーバー・クライアントシステムと逆で、「ユーザが操作しているのがサーバ、リモートで動作するのがクライアント」となります。なぜこうなるかというと、X Window Systemの「機能を提供する」のが「サーバー」であり、その機能が、ユーザが操作する側に存在するためです。

知っているようで知らないX Window System、意外なほど奥が深いのです。

インデックスに戻る

続・アーキテクチャ

前回、「コンピュータの内部構造」として、「アーキテクチャ」という用語を紹介しました。今回は、アーキテクチャの中でもとりわけ良く聞くであろう「i386アーキテクチャ」およびそれに続くものとして「i486」「i586」といったアーキテクチャについても紹介します。

Linuxをインストールする際、「よくわからないけれどi386というアーキテクチャは良く聞くな」という方も多いでしょう。そのため、「自分のPCのアーキテクチャはi386アーキテクチャなのだ」と誤解するケースもあります。しかし、現在i386を利用している人はごく僅かです。

i386のiは、「Intel」の頭文字です。そして、i386は、なんと1985年に発表されたアーキテクチャです。ですから、今i386のコンピュータを利用している人は・・・20年近く同じPCを使い続けていることになります。

実はi386のCPUは正式には「80386」と呼ばれます。そして、80386の前には8086、80286があり、80386の後には80486が発表されています。80386というのは、実は「80x86」と呼ばれるシリーズの一つという位置づけなのです。
この「80x86シリーズ」は、いわゆる「パーソナルコンピュータ」として世に広がったPCの多くに採用されています。

※8086の後に80186というCPUも存在していましたが、PCでの採用は少なく、あまり一般的ではありません。

そして、i386は「80x86シリーズ」の中で、初の32bit CPUなのです。
更に、Linuxの誕生は、このi386で達成されたのです。

その後、x86シリーズは進化を遂げ、80486へ受け継がれます。その後は・・

実は公式には80586というCPUは存在しません。商標の問題から、80486の後継は「Pentium」、その後継は「Pentium Pro/Pentium II/Pentium III」となります。しかし、これらは80x86の流れを汲むものですから、Pentiumを「俗称」で「i586」、「Pentium Pro/Pentium II/Pentium III」を「i686」などと呼びます。

さらにPentium IIIをベースとしたXeonもi686に含まれます。この後はさまざまなアーキテクチャが発表され、i786と「俗称」されるものはどれなのか？はいくつかの議論がありますが（Pentium 4をi786と呼ぶことが多いようですが）、もはやi786やi886という名前はほとんど使われていません。

しかし、基本的にこれらのアーキテクチャはi386の流れを汲んでいるので、「i386向けOS・アプリケーション」も動作するのです。IA-64など、特に64bitアーキテクチャではi386向けアプリケーションは動作しないことが多いので、「とりあえずi386」という認識は少し危ないと思っておいたほうがよいですが、普通のコンシューマ向けPCであれば「i386」向けのアプリケーションが動作する、と考えてよいでしょう。

インデックスに戻る

アーキテクチャ

今回は、「アーキテクチャ」という用語について。

PCに関する文書などで、「x86アーキテクチャ」などというフレーズに出会ったことがある方も多いのではないでしょうか。しかしこの用語、わかったようなわからないような・・・そんな感想をお持ちの方もおられるでしょう。

アーキテクチャ・・・英語で「architecture」のこと。これには「建築」、「建築様式」、「構造」といった意味があります。実はアーキテクチャという用語自体は、いろいろな分野で使われている「構造」という意味合いの用語だ、ということができます。

そして、さらに実はコンピュータの世界でも「アーキテクチャ」と言った場合、いくつかの使い方があるようです。ソフトウェアの設計に関しても「アーキテクチャ」という用語が使われますし、ハードウェアに関しても「アーキテクチャ」という用語が使われます。使われ方が多岐に渡るため、一概にはいえませんが、前述の「構造」や「設計様式」といた意味では概ね共通しているようです。

さて、「x86アーキテクチャ」というのは何を指すのか・・・「x86」は、コンピュータの頭脳とも呼べるCPUの一種です。そして、「x86アーキテクチャ」と言った場合、x86 CPUを中心としたハードウェアの構成のこと、と言えるでしょう。要するに、CPUだけではコンピュータは動作しませんし、CPUによって、どのようなハードウェア構成にするか（どのようなマザーボードを使えばよいのか？どのようなメモリを使えばよいのか？などなど）が変わってきます。このハードウェアの設計全体を「アーキテクチャ」と呼ぶ、と考えればよいでしょう。

（ハードウェアの）アーキテクチャという用語がよく出てくる理由は、ソフトウェアも「ハードウェアのアーキテクチャによって変わってくるから」ということができます。すなわち、同じソフトウェアでも、あるアーキテクチャに対してのみ動作し、ほかでは動作しない、あるいは動作するが最適化されていない、という事態が考えられるわけです。このような事情があるので、現場では、扱おうとしているコンピュータがどのアーキテクチャなのか？といったことは、必ず把握しておく必要が生じることになります。

インデックスに戻る

小型モバイルPC

今回は、ニュースでも取り上げた「小型モバイルPC」について。

最近は、日本の量販店でもよく目にする小型のモバイルPC。小型で軽く持ち運びやすいだけでなく、価格が安いという特徴もあります。また、省電力機能が充実しており、バッテリーが長時間持続するという工夫も施されています。ただし、サイズが小さいため、長時間の作業を行うにはあまり向かないかもしれません。

さて、この小型モバイルPC、ニュースのコメントでも述べたように、外国ではOSにLinuxを搭載したものも多く流通しています。その要因の一つに「コスト削減」があります。

ネットブックなどとも呼ばれるこのPC、その発祥は実はOLPCと呼ばれるアメリカのNPOが、発展途上国の子供たちに、Webや電子書籍の閲覧など基本的な操作ができるように安価なPCを開発しよう、というプロジェクトが立ち上がったのが先駆け、とも言われています。OLPCは「100ドルPC」という目標を掲げて開発を進めるも、「100ドル」は今のところ達成できていないようです。

この動きの中で、さまざまなメーカーやベンダーなどが「小型で廉価なPCを作ろう」という動きを見せています。ネットブックの誕生は、こうした動きの中で誕生したものだといえます。

ネットブックは、まだ歴史の浅いジャンルです。日本ではネットブックのOSにLinuxを搭載したものはそれほど多くはないのですが、ネットブック向けのLinux OSの開発を行っているプロジェクトも数多く存在しますし、海外ではLinux搭載のネットブックも流通しています。今後、Linuxを搭載したネットブックは一つの大きな流れを作ることになるかもしれません。

インデックスに戻る

カーネル（kernel）

前回は、Linus Torvalds氏についてのお話しでした。今回は、そのLinus Torvalds氏が開発した「カーネル（kernel）」についてです。

Linux kernelという言葉はよく耳にすると思います。しかし、「じゃあkernelって何？」と聞かれると、意外と答えられないと思います。では、kernelとは何か？「kernel」とは「中核」という訳語が当てはまりますが、簡単に言えばその通り「Linuxの中核となるプログラムがLinux kernelです」となります。そして、これはよく言われることですが、厳密には「Linux」と言った場合、このLinux kernelのことを指します（最近では、後述する「Linuxディストリビューション」をLinuxと呼ぶケースも増えてきています）。

さて、そのLinux kernel、「OSの中核となるプログラムです」と説明してもいまひとつピンと来ないかもしれません。具体的に何をやっているのか？というと、「ハードウェアを稼動させる指示を出す、もっと具体的には、メモリー管理、ファイルの管理、デバイスドライバとしての役割、プロセスの管理」などを担っています。例えて言えば、「ユーザからの指示に従ってハードウェアを稼動させる"頭脳"の役割を担っている」、という言い方ができるでしょうか。

さて、OSの中核を担う大切な大切なカーネルですが、カーネルだけではOSは動作しません。人の体が、脳だけでは動かないのと同じです。必要なものの一つが「インターフェイス」です。インターフェイスとは「仲介役」のことで、人の体で例えると神経に当たるでしょうか。「ユーザーインタフェイス」といえば「ユーザーとカーネルの仲介を行うプログラム」のことを指します。ユーザインタフェイスによって、ユーザの指示がカーネルに反映され、またさまざまな処理の結果がユーザに返ってくることになります。

Linuxディストリビューションとは、Linuxカーネルと、ユーザインターフェイスなどさまざまなプログラムをひとまとめにし、OSとしてユーザがすぐに使えるようにまとめたもののことを指します。初学者は、ほとんどの場合、このLinuxディストリビューションを入手して、Linuxを利用することになります。カーネルだけをOSとして動作させることはできません。もちろん、自分で他のアプリケーションを入手するなり自作するなりして・・・ということを行えばできますが、「カーネルだけを使って」というのは不可能だと思ってよいでしょう。

インデックスに戻る

Linuxの産みの親　Linus氏

さて、今回は新年一回目ということで、このLinus氏についての簡単な紹介をしてみたいと思います。

Linuxの産みの親にして、現在でもLinuxカーネル開発の最終調整を担う人物が「Linus Torvalds」（リーナス・トーバルズ）氏です。「Linux」という名前自身が、Linus氏の名前から取られています。

Linus Torvaldsは、1969年12月生まれ、フィンランド出身のプログラマー。そして、そのLinusがLinuxの始祖となるプログラムを開発したのは、彼がフィンランドのヘルシンキ大学在学中のこと。Linusは、当時PCにおいて主流だったIntel i386コンピュータで動作するUNIX互換のOSの必要性を感じ、Linuxの開発に着手。Linuxの開発といっても、それはLinusの自宅で、しかも趣味として始まったものだと言われています。

Linuxが成長を遂げるきっかけになったのは1991年、LinuxがFTPサーバにアップロードされ、さまざまなプログラマーに公開されたこと。当時はまだ現在のように誰でも使えるというものではなく、腕の立つなプログラマーたちが利用できるOSでしたが、多くのプログラマーの手によって進化し、現在のような姿になっていったのです。

Linuxが進化した要因はいくつかありますが、そのうちの一つがLinusの「趣味」から始まっているという点にあるでしょう。趣味だったからこそ、さまざまなプログラマーの協力を広く得ることができ、大きく発展していくことができたのです。

Linus氏は、最近では「積極的にLinuxカーネルのコードを書く」作業は行っていないと言われますが、Linuxカーネルに新たなコードが追加される際の最終決定は彼の仕事になっています。

インデックスに戻る

ポートを塞ぐ

前回は、ポート番号について取り上げました。今回は、「ポートを塞ぐ」というお話しです。

良くセキュリティ関係の書籍などを見ると「余計なポートは開けてはいけない」と言われますが、ではポートはどのように塞げばよいのでしょうか？

実は、ポートの塞ぎ方については大きく分けて二つの方法があります。

一つは、「アプリケーション側の対応を行う」です。そもそも、「ポートが開く」とはどういうことなのかを考えてみましょう。たとえば、ApacheなどのWebサーバアプリケーションを起動すると、（特別な設定をしない限り）Well known portsである80番ポートが開き、80番ポートでの通信の待ちうけを開始します。

これを考えると、サーバアプリケーションを停止すれば、自動的にポートが閉じます。「余計なアプリケーションを起動してはいけない」というお話しにつながりますね。

もう一つは、「通信を制限する」という方法です。代表的なのが「パケットフィルタリング」という手法です。パケットフィルタリングを利用すると、特定のポートの通信、特定のIPアドレスの通信をシャットアウトすることができます。Linuxでは「iptables」というコマンドによってパケットフィルタリングを行うことができます。iptablesコマンドを利用すると、どのような通信を遮断するのかなどを細かく指定できるので、「あるホストから、特定のポートを遮断する」といったこともできます。

どのポートが開いているか？を調べるには、「netstatコマンド」「lsofコマンド」「nmapコマンド」などのコマンドがあります。ここではそれぞれのコマンドについての詳細は割愛しますが、netstatとlsofは「自分がどのポートを開けているか？」を知るために、nmapは「他ホストがどのポートを開けているか？」を知るために使われます。パケットフィルタリングを施した場合、netstatやlsofではポートが空いているように見える場合もあるので注意が必要になります。

インデックスに戻る

「ポート」と「ポート番号」

今回は、「ポート」と「ポート番号」について。

よく、「80番ポートが開いている」などという言い方がされますし、セキュリティ上「余計なポートは開けないようにしましょう」とも言われます。さて、このポートあるいはポート番号とは何者でしょう？

まず、「ポート」とはTCPやUDPで使われる概念で、よく「窓口」に例えられます。また、「ポート番号」は「窓口番号」に例えることができます。例を挙げましょう。たとえば郵便局へ行って振り込みを行うとき、どの窓口でも振り込みが行えるわけではなく、ある特定の窓口でのみ振り込みを受け付けています。そして、窓口には番号がついていますね。

ポート番号もこれと似たものだと考えるとよいでしょう。たとえば、WebサーバがHTTPによる通信を受け付ける際は、Webサーバの80番ポートを通じて通信を行います。同じようにSMTPは25番ポート、SSHは22番ポートを通じて通信を行います。ポートは「通信の窓口」と考えるとよいでしょう。

ちなみに、クライアント側もポートを利用して通信を行います。ただし、サーバ側のポート番号は大抵決まっていますが、クライアント側のポートは通信の度に変わるケースがほとんどです。

さて、サーバ側のポート番号は「決まっている」と書きましたが、実はやろうと思えば所定のポート番号以外で通信を行うこともできます。しかし、「あるサーバでは25番ポートでHTTPを受け付け、あるサーバでは80番ポートでHTTPを受け付ける」のように、サーバごとにばらばらなポート番号を利用しているようでは、当然混乱を招きます。そのため、サーバが利用するポート番号はある程度決まっています。これを「Well known ports」と呼びます。そして、ほとんどのサーバでは、所定のWell known portsを利用して通信を行っています。前述の「SSHサーバは22番ポート、HTTPサーバは80番ポート」がWell known Portです。

Well known ports 0-1023
Registered ports 1024-49151
Dynamic and/or private ports 49152-65535

ちなみに、Well known portsの管理は、「Internet Assigned Numbers Authority (IANA）」という組織が行っています。IANAは、Well known portsの管理のほか、IPアドレスやドメイン名の標準化などに取り組んでいます。

インデックスに戻る

エイリアス

「エイリアス」という言葉は、実は色々な場面で使われます。たとえば、「コマンドのエイリアス」「メールアドレスのエイリアス」など。ですから、一言「エイリアス」と言った場合、場面場面でそれが指すものは変わってきます。

ですが、意味としてはどれも似たものを指します。
エイリアスとは英語で「alias」と書き、日本語訳すると「別名」という意味になります。
「メールアドレスのエイリアス」といった場合も、別名の意味合いが出てきます。
たとえば、「foo@example.com」というメールアドレスのエイリアスに「bar@example.com」を設定しておくと、bar@example.com宛のメールはfoo@example.comに届くようになります。この例のように、何かの「別名」を「エイリアス」と呼びます。

Linuxでよく出てくるのは、メールアドレスのエイリアスのほか、コマンドのエイリアスです。Linuxなど、UNIX系OSではコマンドにエイリアス（別名）をつけることができます。

そんなものが何の役に立つのか？ということですが、コマンドのエイリアスでは、「オプションも含めて別名をつけることができる」という点が便利な点です。たとえば、「ls -al」をよく実行する場合に備えて、これにエイリアスをつけることができます。

エイリアスをつけるには、「alias」コマンドを使います。「ls -al」に「ll」というエイリアスをつけるには、以下のように実行します。

$ alias ll='ls -al'

これで、プロンプトに「ll」と入力すると、ls -alに読み替えられて実行されるようになります。コマンドエイリアスの便利なところは、エイリアスに更に引数をつけても、その引数が有効になるという点です。

たとえば、上のようなエイリアスをつけた上で、

$ ll /etc/

と実行すると、

$ ls -al /etc/

を実行したのと同じことになるのです。

ログインするたびにエイリアスをつけるためには、ホームディレクトリの.bashrcファイルの末尾に、

alias ll='ls -al'

などのような記述を追加しておきます。これで、ログイン時にaliasコマンドが自動的に実行されます。

また、現在設定されているエイリアスの一覧を見るには、aliasコマンドを引数なしで実行します。実はLinuxでは（ディストリビューションによりますが）デフォルトでエイリアスがついていることが多いので、一回見てみるとよいでしょう。

$ alias
alias l.='ls -d .* --color=tty'
alias ll='ls -l --color=tty'
alias ls='ls --color=tty'

インデックスに戻る

TCP/IP

前回は、「プロトコル」のお話しでした。その続きで、「TCP/IP」のお話しをしたいと思います。

ここでのテーマは、「TCP/IPって何？」です。TCP/IPそのものの解説をするのではなく、TCP/IPが何を意味し、どこで使われているのか？にスポットを当ててみます。これは、意外と触れられていない事項です。

TCPやIPは、前回も紹介したように、プロトコル、すなわち通信のときの決めごとです。では、「TCP/IP」は？誤解されやすいのですが、TCP/IPは単独のプロトコルではなく、「プロトコルの集合体で、現在インターネットなどのネットワークで、標準として利用されているもの」です。

前回も少し触れたのですが、１つのプロトコルだけで通信は行えません。
いくつかのプロトコルを利用してはじめて、通信を行うことができるのです。
もっと言うと、現在のインターネットにおける通信のほとんどは、HTTPなどのプロトコルとTCP/IP、そしてネットワークでデータの送受信のしかたを既定したプロトコルを組み合わせて行われています。

TCP/IPの他にも、通信を行うためのプロトコル群というのは一応存在するのですが、現在インターネットではほとんどの通信がTCP/IPを利用して行われています。

ちなみに、TCP/IPの「IP」とはInternet Protocolのこと。インターネットにおいて情報の送受信を司るプロトコルであり、正しいホストへパケットを届ける役割を担っています。「TCP」は、データをインターネットへ送るために加工したり、逆に受信した加工済みデータを元に戻したり、といった役割を持ちます。同じような役割を担うプロトコルには、TCPのほかにUDPなどがあり、状況によって適切に使い分けられます。なお、UDPなどのプロトコルも「TCP/IP」に含めるケースが多いようです。

詳細はともかく、「TCP/IPという独自のプロトコルがある」という誤解は、どうしてもしてしまいがちです。勉強するときには、この点をまず頭に置いてください。

インデックスに戻る

プロトコル

今回は、サーバやネットワークの理解に欠かせない「プロトコル」のお話しです。

「プロトコル」（protocol）には、「決めごと」という意味があります。
実はプロトコルの意味は広いのですが、通信で「プロトコル」というと、「通信を行う際、どのような状況で、どのような順番で、どのようなデータをどのようにやりとりするのか」といったことが決められています。

抽象的でわかりにくいかもしれません。例を挙げましょう。Web上でHTML文書をやりとりする際に使われるプロトコルに「HTTP」（Hyper Text Transfer Protocol）があります。このプロトコルでは、要するにサーバとクライアントがHTML文書をやりとりする際の決めごとが定められているのです。たとえば、クライアントがWebサーバに接続した後、クライアントからサーバに

GET /

と送信すると、WebサーバはサーバのルートにあるHTML文書を送信する、というように決められているのです。このような取り決めの集合が「プロトコル」です。

当たり前のことですが、この取り決めはインターネットどこへ行っても共通です。すなわち、「プロトコル」というのは、「共通の決めごと」であると言い換えることもできます（ただし、バージョンによる相違などがある場合もあります）。

さて、インターネットの通信に使われるプロトコルには、HTML文書のやりとりを行う「HTTP」、メールの送信を行う「SMTP」、ファイルの転送を行う「FTP」の他に、1対1でのデータ伝送を行う際に用いられる「TCP」、インターネットでのデータ伝送プロトコル「IP」など、さまざまなプロトコルがあります。そして、多くのプロトコルは名前が「P」で終わっており、名前からプロトコルであることが想起できるようになっています。

ところで、たとえば「インターネット経由でWebサイトを閲覧する際に使われるプロトコル」は、HTTPなのかTCPなのかIPなのか？どれなのでしょうか。答えは・・・「通常HTTPもTCPもIPもすべて使われる」です。通信は一つのプロトコルのみで成立しているのではなく、複数のプロトコルが組み合わせて使われるのです。このあたりは、初学者が混乱しやすいところです。

インデックスに戻る

ワンCD Linux

今回は、「ワンCD Linux」について取り上げてみたいと思います。

ワンCD Linuxは、インストールをしなくても、CD-ROMからブートすれば利用できるLinuxのことを言います。有名なものにKNOPPIXがありますが、Puppy Linuxなどのディストリビューションもありますし、最近ではFedoraやGentooといったディストリビューションにも「Live CD版」あるいは「Live DVD版」といった形で、「インストールなしで利用できるLinux」が配布されています。

さて、このワンCD LinuxあるいはLive CDですが、どのようなメリットがあるのでしょうか？基本的にCD-ROMをセットしてブートすればLinuxが利用できるようになりますから、「評価用途に最適」というメリットが一つ、すなわち「このLinuxはどんなLinuxなのか」ということがわかります。そして「手軽」というメリットが一つ。すなわち、いつもは他のOSで利用しているPCで、簡単にLinuxが利用できます。更に、「外出先でLinuxが利用できる」などの応用も考えられます。また、カスタマイズすれば、「自分専用の環境を、他のPCでも実現できてしまう」という使い方もあります。

しかし、ワンCD Linuxには意外な使い方もあります。それは、「レスキュー用途」。すなわち、システムがトラブルで起動しなくなったときに、そのPCをワンCD Linuxで起動させるという使い方ができます。こうすれば、まずはハードディスクドライブに取り残されたデータを救済することができますし、さらに応用すればトラブルの修復さえできてしまうのです。

意外と馬鹿にならないワンCD Linux（Live CD）。Linuxを利用するからには、是非覚えておきたいものです。

インデックスに戻る

プロンプト

今回は、「プロンプト」について解説します。

bashなどのシェルは、Linuxを操作する上で欠かせないものです。そのbashにおいて「プロンプト」は重要な役割をします。「prompt」には「促す」という意味があり、その名の通りシェルがユーザにコマンドの入力を促すのがプロンプトです（以下、今回はシェルにbashを利用するものとして進めます）。

さて、最近のLinuxディストリビューションは、プロンプトが

[user@host001 /etc]$

のように表示されるようになっています。上の例では、「ログインしているユーザ名」「ホスト名」「カレントディレクトリ」などが表示されます。このように、コマンドの入力を促すと同時に、ユーザに役に立つ情報を表示するのです。

プロンプトに表示される内容は、カスタマイズすることができます。ユーザ名やホスト名、カレントディレクトリのほか、時間、日付、コンソール番号、接続時間などさまざまな情報を表示させることが可能です。逆に、セキュリティに配慮して、「$」や「#」のみにすることもできます。

具体的な設定の詳細については省略しますが、プロンプトの表示を変更するには、シェル変数「PS1」を変更します（コマンドが複数行に亘る際にはPS2に設定されたプロンプトが表示されます）。たとえばシェル変数PS1に、

PS1='?$ '

と設定すると、余計な情報を一切表示せず、$マーク（rootユーザのときは#マーク）のみがプロンプトとして表示されることになります。ちなみに先ほど紹介した「[user@host001 /etc]$ 」のようなプロンプトを表示するには、PS1に

$ PS1='[?u@?h ?w]?$ '

と設定します。

さて、PS1変数はログイン後に変更することもできますが、ログインする時に表示するプロンプトを設定するには、ホームディレクトリにある「.bashrc」ファイル（シェルにbashを利用する時）の末尾に、その設定を記述しておきます。具体的には、.bashrcファイルの末尾に

export PS1='[?u@?h ?w]?$ '

を追記すれば、次回ログイン時からこのプロンプトが利用できるようになります。

インデックスに戻る

パスを通す

今回は、「パスを通す」という話です。ちなみに、この時の「パス」は、「コマンドサーチパス」の略称です。

Linuxでは、コマンドを実行する際には、本来「/usr/bin/passwd」のように、フルパス、すなわちコマンドがあるディレクトリまですべて含めてコマンドを指定してやる必要があります。しかし、よく使うコマンドでいちいちフルパスを指定するのはあまりに面倒ですね。

そこで、Linuxのシェルは、ユーザがコマンドをフルパスで指定しなくても、そのコマンドを、ある特定のディレクトリに対して探しにいくようになっています。このとき、シェルが探しに行くディレクトリを設定する作業を、「パスを通す」と言います。正確には「コマンドサーチパス」、すなわちコマンドを探しにいくパスの設定をする、ということですね。

パスを通すためには、環境変数「PATH」に対して、通したいパスを「:」記号区切りで指定します。この設定には、先週紹介した「export」コマンドを利用します。たとえば、現在の設定に加えて「/usr/sample」というディレクトリにもパスを通したい場合は、次のように実行します。

$ export PATH=$PATH:/usr/sample

さて、Linuxでは「カレントディレクトリ」にパスが通っていません。このため、たとえばカレントディレクトリの「hogehoge.cmd」というコマンドを実行する場合、「./hogehoge.cmd」のように指定してやる必要があります。少々面倒なのですが、では「カレントディレクトリにパスを通せばよいではないか」というと、これはセキュリティ上問題があり、やってはいけないとされています。

まず、セキュリティの大原則に、「余計なディレクトリにパスを通してはいけない」というものがあります。これは、パスを通しすぎると、たとえば2箇所に「ps」というファイルがあった場合、どちらのファイルが実行されるのか・・・混乱します（実際には、PATH変数の、より先頭に指定されたパスが優先されます。が、ユーザは混乱しますね）。

ここでカレントディレクトリにパスを通すとどうなるか。

極端な話、ユーザはほとんどのディレクトリをカレントディレクトリにすることになってしまいます。つまり、どのディレクトリもコマンドサーチパスになり得てしまいます。こうなると、混乱を招くだけでなく、「悪意のあるプログラムが置かれていた場合、意図せず実行される危険が極めて高くなってしまう」のです。通常、一般ユーザが出入りすることができるディレクトリは限られており、そのディレクトリにパスを通さないことでシステムを守っているのですが、一般ユーザでも出入りできるディレクトリにパスを通してしまうと、悪意のあるコマンドを仕掛けられた時に攻撃されてしまう危険性が大きく増してしまうのです。

コマンドサーチパスは、「便利だから」という理由であれこれ指定せず、安全なディレクトリに絞って指定することが大切です。

インデックスに戻る

環境変数

今回は、「環境変数」についてです。

変数とは、プログラムなどにおいて、メモリなどに用意する「データを記憶しておく箱のようなもの」ということができます。すなわち、プログラムは変数に値を記憶させ、変数の中身を参照することによって、さまざまな計算などの処理を行うことになります。

「環境変数」も変数の一種です。普通の変数とどこが違うか？というと、「普通の変数はそのプロセスでのみ有効、環境変数は他のプロセスと共有できる変数」と言えます。Linuxのシェルで言うと、「シェルが呼び出した子プロセスでも利用できる変数」が環境変数です。

環境変数の名前は、大文字のアルファベットを利用するのが通例となっています。実は小文字で変数名をつけても構わないのですが、環境変数であることを示すためにも大文字で設定するのがよいと言えます。

さてこの環境変数ですが、システムの挙動を決定するものがあります。
たとえば、「PS1」という環境にはコマンドプロンプトに表示する文字列を決定する値を格納します。プロンプトに表示する文字列を変更したい場合は環境変数PS1の値を変更すればよいのです。また、コマンドの履歴をいくつ保存しておく「HISTSIZE」変数や、パスを指定する「PATH変数」など、さまざまな環境変数があります。環境変数を変更することにより、システムを使いやすいものにカスタマイズすることもできます。ただし、環境変数の中にはシステムの動作に重要な役割を担っているものもあるため、無闇に変更すると誤動作の原因となることもあるので注意して下さい。

環境変数を操作するコマンドは、「export」コマンドです。exportコマンドを引数なしで実行すると環境変数の一覧が表示されます。また、通常の変数を環境変数に昇格させるためには「export $変数名」のように、環境変数を設定すると同時に値を格納するには「export $変数名＝値」のように実行します。

環境変数およびexportコマンドは、Linuxを管理する上でも重要なものですから、しっかり理解しておきましょう。

インデックスに戻る

パーティション

Linuxをインストールする際、ハードディスクのパーティションを作成します。さてこの「パーティション」とは一体何でしょうか？

「パーティション」は、日本語で「仕切り」を意味します。コンピュータの用語で「ハードディスクにパーティションを作成する」と言うと、その名の通りハードディスクに仕切りを設けることを言います。もっとも、多くの場合は「ハードディスクにパーティションを作成する」などという場合に用いられる「パーティション」とは、仕切られてできたハードディスクの「分割されてできた個々の領域」を指すことが多いのが現状です。ハードディスクをパーティショニング（パーティションに区切ること）すると、１つのハードディスクをあたかも複数のハードディスクがあるかのように扱うことができます。

さて、Windowsをインストールする際にはパーティションを作成しないことも多いのですが、Linuxをインストールする際にはパーティションを作成することがほとんどです。では、パーティションを作成する目的は一体何でしょうか？

パーティションを作成することには、実はいくつかの目的があります。もっとも理解しやすい理由は、「あるパーティションに何らかのトラブルが生じ、データが消失するなどしても、他のパーティションにはトラブルが波及せずに被害を小さく抑えることができる」というものです。例えば、システム領域とデータ領域を分けておけば、システム領域に何かのトラブルが起こっても、データを置いておく領域が別のパーティションになっていれば、データをトラブルから守ることもできるのです。また、再フォーマットが必要になった際、トラブルが起きたパーティションのみをフォーマットすることができ、他のパーティションをフォーマットせずに済む、というメリットもあります。

他にもメリットがありますが、Linuxの場合はメモリのデータを一時的に保存しておく「スワップ領域」が必要となり、このスワップ領域は独立したパーティションとして作成する必要があるという事情があります。

このように、いくつかの事情がある「パーティショニング」ですが、一旦パーティショニングを間違えると修正することが（できないわけではありませんが）困難なので、Linuxをパーティションを作成するときには注意が必要です。よくあるトラブルに、「パーティションを作成したら、あるパーティションだけ空きがなくなってしまった！」というものがあります。ちなみに、どのようにパーティショニングするのがベストなのかは、「どのディストリビューションを利用するのか？」「どのようなハードウェア構成でLinuxを利用するのか？」「どの用途で利用するのか？」などによって変わってきます。パーティショニングは十分計画して行いましょう。

インデックスに戻る

ファイルシステムの種類

現在Linuxでは、「ext3」というファイルシステムが主流となっています。しかし、ファイルシステムにはそれ以外にも「ReiserFS」「XFS」「ZFS」などのファイルシステムもあります。ちなみにWindowsでは「NTFS」というファイルシステムが、CD-ROMでは「ISO9660」と呼ばれるファイルシステムが主流です。また、Linuxにおいてはext3の後継と言える「ext4」と呼ばれるファイルシステムも開発が進んでいます（kernel 2.6.19以降で利用可能）。

ところで、ext3やXFSなどのファイルシステムには、「ジャーナリング」と呼ばれるシステムが採用されています（ext3以前のext2ファイルシステムにはジャーナリングが搭載されていません）。このジャーナリングと呼ばれるシステムは、簡単に言うと、「ファイルに何らかの更新を施す際、前もってファイル更新の内容をジャーナルと呼ばれる領域にログとして記録した後に、ファイル更新処理を行う」というものです。ジャーナリングシステムの利点は、電源の供給が止まったなど、何らかの原因でファイル更新処理が止まってしまったときに発揮されます。OSが正常にシャットダウンされなかった場合、その後にOSをブートする時に、ジャーナルを参照してファイルシステムのチェックを行います。その際、ジャーナルとファイルの内容が矛盾していれば、そのファイルが正常に更新されなかったということがすぐにわかります。ジャーナルを見れば「どのファイルが更新されていない可能性があるか」がわかるため、ファイルシステム全体のチェックをする必要もなく、チェック時間も短くて済みます。

とはいえ、ジャーナリングシステムはファイルの内容を100％保証するものではありません。OSの異常終了はできるだけ避けるようにしましょう。

インデックスに戻る

クローン

最近のディストリビューションで人気があるのが、ニュースでも新版のリリースを取り上げた「CentOS」です。CentOSはRed Hat EnterpriseLinuxのクローンと呼ばれますが、これはどういう意味でしょうか。

Linuxのディストリビューションの多くは、オープンソースソフトウェアで構成されています。インストールメディアはすでにコンパイルされているバイナリパッケージが含まれていますが、別途元になって使用されたソースコードも提供されています。クローンは、このソースコードから、独自にコンパイルを行って構成したディストリビューションの事を指します。

もちろん、完全に同じですと、商標権や固有の著作権に抵触してしまう場合があるので、そのような部分は表記を書き換えたり、データを入れ替えたりすることで、知的所有権を侵害しないようにしているので、100%同じというわけではありませんが、ソフトウェアとして見たときには機能は100%同じ状態のもの、と言ってもよいでしょう。

ディストリビューションは、それぞれファイル配置やコマンドの有無などに癖がありますので、Red Hat Enterprise Linuxに馴染んだ人が、気軽に使用するような場合に使用するディストリビューションとして、クローンに人気が集まるわけです。

インデックスに戻る

RAID

最近では比較的有名な用語になってきたRAID。複数のHDDを組み合わせることで、信頼性を高める技術として知られています。

さて、そのRAIDですが、「RAID 0」「RAID 1」「RAID 5」などいくつかの種類があるのをご存知でしょうか？RAIDとしてもっともわかりやすいのはミラーリング（RAID 1）でしょう。ミラーリングは、複数台のドライブに同じ内容を書き込む技術で、片方のドライブが故障しても、もう片方さえ残っていればデータの損失が防げる、というものです。

さて、そのRAIDですが、「RAID 0」から「RAID 6」までの7種類の区分があります。先に述べたミラーリングの他に、RAID 0（ストライピング）、すなわち複数台のディスクに均等に分散させたデータを同時に読み書きすることで高速化を図る技術や、RAID 5、すなわちパリティというエラー検出符号を複数台のディスクに分散して記録するなどがあります。つまり、RAIDはミラーリングだけではないのです。ちなみに、たとえばRAID 0とRAID 1を組み合わせて利用する、などということもできます。

ところで、RAIDというシステムは、実は1988年に発表された論文の中で提唱されたシステムなのです。この論文の中では、RAID 1からRAID 5が提唱されています。RAIDには7種の区分があると書きましたが、パフォーマンスや信頼性などのメリットがRAID 5に比べて劣ることなどから、RAID 3とRAID 4は現在ほとんど使われていません。RAID 3とRAID 4が欠番のようになっているのは、このような事情があってのことなのです。

そのようなRAIDですが、最近ではハードディスクの価格も下がってきたこともあり、多くの人が利用しているようです。理解してしまえば難しい技術ではありませんし、比較的手軽に導入できる技術ですので、機会があれば試してみてはいかがでしょうか。

インデックスに戻る

モジュール

moduleには、「交換可能な部品」という意味があります。Linuxでモジュールと言えば多くの場合カーネルに組み込むモジュールを指しますが、モジュールという概念はハードウェアやプログラミングなどの分野で広く取り入れられている概念です。今回は、例の一つとしてカーネルのモジュールを取り上げます。

カーネルのモジュールとは、簡単に言えば「メインとなるカーネルのプログラムに組み込んで使用する、小さなパーツのようなプログラム」といえます。すなわち、モジュールだけでは何もできません。カーネルに「取り付けて」利用するというイメージです。

モジュールが利用されるのは、たとえば新しいデバイスや新たな機能を追加するときに利用されます（デバイスに対するドライバはモジュールとして提供される、と考えるとよいでしょう）。このようなとき、対応するモジュールをカーネル本体に取り付けて利用します。これをモジュールとせずにカーネル本体に直接組み込んでしまうと、いつ、どのデバイスが必要になるかわかりませんから、多数のプログラムを付け加えることになり、カーネルのサイズが巨大なものになってしまいます。それだけでなく、メモリ消費量が非常に大きなものになってしまいます。また、新しいデバイスがリリースされ、これを利用したい場合、カーネルにプログラムを書き加えた上でコンパイルする必要が生じることになるので、大きな手間がかかります。

ここで「モジュール」を利用すると、必要なデバイスや機能だけを選択して組み込むことができますので、カーネルのサイズをコンパクトにできます。また、新しいデバイスや機能がリリースされても、カーネルをコンパイルし直す手間がありません。

このようにメリットの多いモジュールという仕組みですが、欠点がないわけではありません。そもそもモジュールにすることができない機能も数多くありますし、モジュールとするとパフォーマンスが落ちる、ということもあります。

モジュールを管理するコマンドとして「modprobeコマンド」があります。このコマンドは、モジュールをロード（取り付け）することができるコマンドです。モジュールには依存関係が存在するものがありますが、modprobeコマンドはこの依存関係をチェックしながらモジュールをロードするので、モジュールをロードする場合にはmodprobeコマンドを利用するのが良いでしょう。

インデックスに戻る

なぜセキュリティがインターネットで問題なのか？

もちろん「悪用する人がいるからセキュリティに注意しなければならない」のですが、一方で「インターネット自体がセキュリティに配慮した作りになっていれば、ユーザがセキュリティの心配をしなくても良い」と考えることもできます。よく、「リモートホストと通信するときに、通信を暗号化しないtelnetを利用するのは避けましょう、通信を暗号化するSSHを使いましょう」と言われますが、そもそも通信を容易に盗み見できてしまう仕組みそのものに問題がある、という言い方もできます。

これは、インターネットの生い立ちに秘密があります。インターネットの前身は、「ARPANET」と呼ばれる、アメリカ国防総省が中心となって研究を行っていた軍事用通信ネットワークでした。このネットワークは、研究目的のため使う人はごく限られた人だけでしたから、そもそも「クラッカー」などの存在がありようもなかったのです。また、インターネットが発達しつつあった1980年台でも、ユーザは技術者や研究者しかいなかったため、やはりユーザに「悪い人」がいなかったのです（もちろん例外もあるでしょうが）。

インターネットが一般に広まってきたのは、実はせいぜいここ十数年。一般に開放されるにつれ、さまざまな人が入ってくるようになってきたため、悪用する人が出てきたのです。ARPANETの開発は1969年と30年近く前で、今のように、誰でも使えるネットワークに進化するなど、まったく想定されていなかったのです。つまり、生い立ちそのものが、「悪用されようがない環境の下で開発された」のです。

それにしても、便利になればなるほど悪用者も増えるというのは、因果なものですね。

インデックスに戻る

「UNIX」「UNIX互換OS」

よく、「LinuxとUNIXってどう違うの？」「LinuxはUNIXではないのか？」といった疑問をよく聞きます。結論から言うと、「LinuxはUNIXに倣って作られたOS」「LinuxはUNIXとは似て非なるOS」ということになります。

これには少し深い事情があります。そもそもUNIXというOSは、1970年頃にアメリカAT&T社のベル研究所が開発し、開発を推し進めてきたOSです。
現在、「UNIX」という商標はThe Open Groupが持っていることもあり、「LinuxはUNIXではない」と言うことができます。

一方で、もう一つLinuxが「UNIXでない」という理由があります。Linuxの生い立ちは、1991年、当時まだ学生であったフィンランドのLinus Torvalds氏が、当時高価であったUNIXの機能を実現しようと、ゼロから開発を始めたものなのです。すなわちLinuxは、元祖UNIXのコードなしで開発されたものです。つまり、プログラムとしては全く別物なのです。しかし、UNIXとよく似た機能を持ち、よく似た動作をするため、「UNIX互換OS」と呼ばれているのです。

http://www.unix.org/
http://www.opengroup.org/openbrand/register/

UNIXの詳細情報とUNIXとしての登録を受けている製品については、以下のサイトを参照してください（英語）。

インデックスに戻る

バージョン番号のつけ方

OSを含め、ソフトウェアにはバージョン番号がついています。番号が大きくなるほど機能向上やバグフィクスが施され、新しくなっていることを表すのが一般的です。

バージョン番号のつけ方に、統一ルールはありません。ソフトウェアによってさまざまです。ほとんどの場合、バージョン番号を「X.Y」や「X.Y.Z」のように付けており、大幅な機能向上があった場合は「X」の数値を、微細な改変に留まる場合は「Y」や「Z」の数値を増やすことが一般的です。このため、「X」をメジャーバージョン番号、「Y」や「Z」をマイナーバージョン番号と呼ぶこともあります。

しかし、バージョン番号には別の意味があることもあります。たとえばLinuxカーネルのバージョン番号は、現在「X.Y.Z」のように番号をつけており、2008年4月20日現在で「2.6.24」が最新版です。一方、実はLinuxカーネル「2.5.75」というものもリリースされています。これは、いわゆる「開発版」と呼ばれるもので、安定性に関するテストが十分になされていない代わりに、先進的な機能がどんどん取り込まれています。Linuxカーネルのバージョン番号の「Y」の数値が偶数のものが一般向けの「安定版」であることを、奇数のものが開発者向けの「開発版」であることを意味します。このように、数値が意味を持っていることもあるのです。

また、たとえばUbuntuというディストリビューションは、バージョン番号を「Ubuntu 7.10」のようにつけています。これは、実は「2007年の10月にリリースした」ということを意味します。このように、バージョン番号の付け方はさまざまで、ものによってはバージョン番号から他の意味を読み取ることもできるのです。一方で、先日OpenSSH 4.9がリリースされて数日後にOpenSSH 5.0がリリースされました。今回の場合、「4.9」と「5.0」の間に大きな差はなく、セキュリティの修正のみに留まりました。このように、バージョンナンバー付加方法のポリシーはソフトウェアごとに異なりますので、注意が必要です。

インデックスに戻る

パケット

携帯でメールやWebにアクセスできるようになってから、「パケット代」という言葉が一般化したせいか、ネットワークに詳しくない人でも知っている「パケット」という用語。さてこのパケットとは一体何でしょうか？

パケットとは英語でpacketと書きます。辞書で引いてみると、「小さな包み、小荷物」と書いてあります。パケットとは、インターネットで通信を行う際、やりとりするデータを分割したもの、ということができます。

大きなデータを送受信するとき、小さなデータに分割すると、データを送信する際にネットワークを独占することがありません。実際、複数の通信を同時に行おうとする際には、パケットが交互に送信されるため、１つの通信がネットワークを独占することがなくなり、同時送信が可能になるのです。
また、ノイズなどが入ってデータの送り損ねが出たとき、大きなデータのまま送ってしまうとデータを全部再送しなければなりませんが、パケットに分割しておけば、送り損ねたパケットだけを送り直せばよいので効率的、というメリットもあります。

「パケット」は、IPを利用した通信の基礎となるものです。ちょうど、先日リリースされた「Wireshark」（旧Etereal）などのソフトウェアを利用すれば、パケットを直接見ることも可能ですので、一度自分のPCがやりとりするパケットを実際に見てみてはいかがでしょうか。

インデックスに戻る

Linuxとウイルス

「Linuxをターゲットとしたウイルス（などの不正ソフトウェア）」は、Windowsをターゲットにしたものに比べるとはるかに少ないといえます。普及度から考えれば当然で、Linuxをターゲットにした不正ソフトがばら撒かれたところで、被害を受ける範囲は限定的になります。

しかし、「ではLinuxに感染するウイルスなどは存在しないのか？」「Linuxではウイルス対策が必要ないのか」というと、そんなことはありません。Linuxに感染する不正ソフトウェアも発見されています。それだけではありません。特にサーバ用途で顕著ですが、たとえばWindowsを標的にしたウイルスがLinuxサーバに紛れ込んでしまった場合、Windowsがウイルスを持っていってしまうケースも少なくありません。

Linuxを利用する際、どうしても見落としがちなウイルス対策なのですが、上述のような理由で「全く考えなくてよい」ということは決してないのです。

では、どのように対策するのか？これは他のOSと同様、対策ソフトウェアを利用するのがベストでしょう。対策ソフトウエアは、商用のものもありますが、実は「Clam AntiVirus（ClamAV）」など、オープンソースのウイルス対策ソフトウエアも存在するのです。

サーバの運用・管理にあたって、セキュリティはどうしても切り離して考えることができません。ウイルス対策など見逃しがちなところにも、目を向けてみてください。

インデックスに戻る

「Linux」と「ディストリビューション」の関係

Linuxとは、本来は「カーネル」のみを指す用語です。5年くらい前はこのことがよく言われたものですが、最近はあまり聞かなくなりました。「LinuxはOSである」という誤解？が一般的になってしまった、ということでしょうか。
ここでの「OS」とは、コンピュータの環境全体を指しています。

しかし、カーネルは、本来はハードウェアとソフトウェアの仲介を行うのが役割ですから、カーネルだけではPCは動作しません。ですから、これに様々なソフトウェアを組み合わせ、OSとして動作するようなパッケージを作るわけです。これが「Linuxディストリビューション」です。最近では、Linuxディストリビューションを「Linux」と呼ぶケースも多いようです（繰り返しになりますが、厳密な意味での呼び方ではありません）。

さて、Linuxカーネルは基本的に1つしかありません（バージョンの違いはありますが）が、Linuxディストリビューションは複数あります。なぜならば、カーネルと組み合わせるソフトウェアは膨大な数存在し、また組み合わせ方 もさまざまだからです。このようにして、さまざまなLinuxディストリビューションが出来上がるのです。

さらにLinuxカーネルも実は複数あります。様々なパッチを当てたもののほか、ディストリビューションごとに独自のカーネルを使っている場合もあります。そこで、kernel.orgで配布されている素のカーネルのことを「vanillaカーネル」と呼んで区別しています。

では、Linuxディストリビューションの数はどれくらいあるのでしょうか。

答えは、ほぼ無限と言えるでしょう。

ディストリビューター（ディストリビューションの配布者）は世界中に存在します。また、商用／非商用、サーバ用途／デスクトップ用途、ある機能に特化したものなどのように考えてもさまざまなものがあります。ディストリビューターが複数のディストリビューションを配布している例もあります。また、あまり知られていないディストリビューションもあるほか、最近ではLinuxディストリビューションの「自作」も流行っています。ですから、ディストリビューションの数は、まさに星の数といえるでしょう。

Linuxディストリビューションの自作。難しそうに聞こえますが、書籍なども出版されていて、皆さんが想像するほど難しくないと思います。機会があればチャレンジしてみてはいかがでしょう？

インデックスに戻る

Linuxのマスコットのペンギンは何者？

今回は、Linuxのマスコットであるペンギンについてお話しします。

＃もちろん、試験には出ません。

Linuxのマスコットといえばペンギンですが、あのペンギンは一体何者なのでしょうか。あのペンギンは名前を「Tux」（タックス）と呼びます。税金を意味する「Tax」とは別です。

調べてみると、Wikipediaにも記述があります。
○Wikipedia: Tux（タックス）

Linuxカーネルがバージョン2になる時に、ロゴのデザインコンテストが行われ、あのペンギンが選ばれたわけです。その他の作品も含めて以下のサイトに候補作品が並んでいます。

○ロゴ候補

見てみると、いくつかのロゴには「Linux 2.0」の文字が見えるのが分かるかと思います。

Tuxは、Linuxカーネル起動時に画面に現れることがあります。これはLinuxカーネルがフレームバッファ（画像表示の仕組み）をサポートしており表示が行われています。Tuxの数はCPUの数を表しているので、たとえばPlayStation 3のLinuxのようにCPUを沢山識別するシステムの場合、大量のTuxが起動画面に並ぶことになります。

○PS3 Linux起動時に沢山並んだTux

インデックスに戻る

LinuxとCPUの互換性とは？

Linuxは元々、インテル製のCPU「i386」で動作するPOSIX互換のカーネルとして開発が始まりました。それもあって、現在でもいわゆる「PC」で動作するLinuxが主流となっています。これらのPCを「IA（インテル・アーキテクチャ）」のマシンと呼んでいます。

IAは、名前にインテルと入っていますが、実際にはインテル製以外のCPUでも動作します。たとえばAMDはIA互換CPUを製造しているCPUメーカーとして非常に大きな企業ですし、その他省電力などを謳ったIA互換CPUは沢山出ています。それら全てをひっくるめて「IA」と呼んでいます。ですから、IAなマシンを用意すれば、その上でLinuxを動かすことは可能というわけです。

ただ、その時に注意しないといけないのが、「その1」の時に少し触れましたが、そのCPUがどの種類（世代）のCPUか、そして動かそうとしているソフトウェアがどのCPUに対応しているか、ということです。
一言でIAといっても、一番最初の「i386」に互換性を持つCPUもあれば、より機能が進化して「i586」や「i686」と呼ばれるCPUもあります。

特に問題になるのが前者で、最近のLinuxディストリビューションではi586以上を前提にしたLinuxカーネルしか入っておらず、IA互換CPUに多いi386互換CPUでは動作しない点です。
たとえば、インストーラーを動かすために使用しているLinuxカーネルはi386用でも、実際にインストールされるLinuxカーネルはi586以上でないと動かない、というようなことがあります。

最近、省電力CPUを採用した小型PCなどが流行していますが、そのようなマシンでLinuxを動かすときには、CPUの互換性に気をつけましょう。

インデックスに戻る

Linuxって何て読むの？

そもそもLinuxって何て読むのか、を考えてみたいと思います。考えないといけないぐらい、Linuxの読み方は諸説紛々です。代表的な説として、以下のようなものがあります。

A) リナックス
B) リヌックス（リヌクスと短くする場合も）
C) ライナックス

まず、A説とB説に共通しているのが「Li」を「リ」と発音することです。これはLinuxの最初の開発者である Linus Torvalds氏の名前をカタカナ表記すると「リーナス・トーバルズ」とするあたりに由来しているのでしょう。

では「nu」をどう読むかです。Linux Onlineのページには"LIH-nucks"と説明されています。また、Linus Torvalds氏のスピーチの音声データがリンクされています。

http://www.linux.org/info/index.html
http://www.linux.org/info/sounds/english.au

聞いてみると、日本語のカタカナ表記では表現できない音、ちょうど「ナ」と「ヌ」の間ぐらい、あえて表記すれば「ヌワァ」（ヌは小さめ）ぐらいでしょうか。ということもあって、A説、B説ともにどっちが正しいとも言えないのが実情ではないでしょうか。

皆さんはどのように読んでいますか？廻りの人の呼び方も聞いてみると、面白いかも知れません。

インデックスに戻る

「UTC」と「JST」

今週は、「UTC」と「JST」について解説します。

地球上の国には、それぞれ時差があります。ところがインターネットは世界中に張り巡らされたネットワークですし、国境を跨いだデータのやりとりも頻繁にあります。そうなると、インターネットに接続されたサーバに共通の時刻が必要になります。

実際、インターネットに接続されたサーバは、多くの場合「協定世界時（UTC：Universal Time Coordinated））」を利用します。学校の地理の授業で習ったかもしれませんが、イギリスで利用されているGMTがUTCと一致していることで有名です。厳密にはUTCとGMTは異なります。UTCは、セシウム原子が振動する時間を基準とし、GMTにおける1958年1月1日0時0分0秒からの経過時間をカウントして定めた時刻です。ただし、地球の自転は一定ではないため、この決め方ではGMTとUTCの間にズレが生じてしまいます。このため、およそ1年に1回「うるう秒」を追加してGMTとUTCのズレを調整しています。

そして、世界中の時計は、UTCを基準に決められています。日本であれば、UTCに9時間を足した「日本標準時」（JST）が用いられています。逆の言い方をすると、JSTから9時間を引けば、UTCが得られます。

JSTは、かつては兵庫県明石市を通過している「東経135度」の子午線の時刻を基準に定められていました。現在では、原子時計を基準にしてUTCを定めており、これに9時間を足したものをJSTと定めています。もっとも、東経135度の子午線で決まる時間と現在の決め方にはほとんど差がありません。

サーバを管理する際には、サーバが取り扱っている「時間」が、JSTなのかUTCなのか、はたまた別のタイムゾーンなのかを意識する必要が出てくることがあります。アメリカなど、同一国でも場所によって複数のタイムゾーンが存在する国もありますから、特に海外のサーバを取り扱う際には注意が必要となります。

インデックスに戻る

i386って何？

今回は、色々なところで目にする「i386」という言葉についてです。
i386とは、CPUの種類を指しています。「アーキテクチャ」と呼び変えてもいいでしょう。今ではCPUの名前というと「Core 2 Duo」とか「Athlon」、あるいは「Xeon」や「Opteron」といったかっこいい名前で呼ばれるように なりましたが、Linuxが産声を上げた頃はCPUは重要なパーツではありますが一部品でしかなく、型番で呼ばれるものでした。

i386のiは、インテル(Intel)のiです。インテルが最初に生み出した4004から続くCPUの系譜の中で、386（80386）は初めて32ビットを取り扱えるようになったCPUです。

○参考：インテルミュージアム - マイクロプロセッサーの歴史

Linuxは、この386上で動作するPOSIX互換のカーネルとして開発が始められました。また、その後のCPUは基本的に386と互換性を持つ形で高速化などがはかられているため、Linuxやその上で動く各種プログラムは、386上で動作するようにコンパイルしておきさえすれば、多くのPC上で動作するというわけです。

ただし、386は1985年に生まれたCPUであるため、現在ではいささか古いということは否めません。そこでいくつかのディストリビューションでは、動作対象をPentium以降に絞っているものがあります。その場合、Pentiumを表す「i586」という名前がパッケージのファイル名などにつけられています。
また、現在のインテル系CPUはunameコマンドなどで調べると「i686」と表示されます。これはPentium Pro以降のアーキテクチャを示しています。

i586やi686が存在するならば、動作させるバイナリもきちんとCPUの種類に合わせた方が良いように感じられるかも知れませんが、実際にはCPUの種類に合わせたとしても、大幅な性能向上などは見られないようです。むしろ、汎用性を考慮して、LinuxカーネルはCPUの種類に合わせたものをインストールして、その上で動く各種プログラムは互換性のあるi386用にコンパイルしたものを提供するというのが、現在のディストリビューションのやり方のようです。きちんと動作するのが最も良い、ということですね。

インデックスに戻る

Linuxカーネルの開発者になるには

新年のスタートに、「Linuxカーネルの開発者になるにはどうしたらよいのか？」という話題を取り上げます。

Linuxのカーネルを開発しているのは、ボランティアの開発者たちです。
特別な企業などに所属しているかというと、そういうわけではありません。
ですから、あなたもLinuxカーネル開発に参加する資格があるのです。もちろん、卓越したプログラミング技術と、開発する機能についての一定以上の知識が必要であることはいうまでもありません。しかし、技術、知識のほかにコミュニケーション能力があれば、あなたが書いたコードがLinuxカーネルに取り込まれる！ということもありうるのです。

そもそも、Linuxカーネルは、Linus Torvalds氏がインターネット上にカーネルのコードを公開し、それが開発者たちの間に広がり、多数の開発者がカーネルの開発に携わるようになったという経緯があります。

しかし、当然のことながらLinuxのカーネル開発なんてどうやればいいのか？情報がないと難しいですよね。その大きな情報源となるのが、「Linux Kernel Newbies」というサイトです。
このサイトは、Linux カーネル開発に役立つFAQなどの情報が集められており、また開発に関する質問ができるIRCチャンネル、メーリングリストなどがあります。

また、Linuxカーネル開発に伴い、今なにが問題になっているのか？何をしなければならないのか？などの情報が集まっているのが、「Linux kernel Janitor's Project」です。

そして、もしLinuxカーネルにマージ（混合）したいコードが書けた場合、「Kernel Mentors」というメーリングリストに報告します。
基本的に、Linuxカーネルをはじめ、ボランティアの手で書かれているソフトウェアの多くは、メーリングリストによる活動が中心になっています。

このように書いても、Linuxカーネルの開発に参加することはあまり現実的でないと思われるかもしれません。たしかに世界中の開発者と共にこのようなプロジェクトに参加するのは気がひけるという方がほとんどでしょう。
また、カーネル開発に限らず、多くの人が参加しているソフトウェア開発に携わるには、前述のようにプログラミングの能力、知識の他、「コミュニケーション能力」が大切になります。作業のほとんどが顔の見えないメーリングリストという場で行われているのですから尚更大切になります。
敷居はたしかに低くはありません。

しかし、それでもLinuxカーネルの開発作業に山積する問題は大量にあります。
もしかしたら、あなたが書いたコードが、Linuxカーネルの一部になる日がやってくるかもしれません。

インデックスに戻る

Linux道場

コラム

お役立ち情報

  • 受験予約をする
  • ポスタープレゼント
  • 大人気！LPI-Japan特製ペンギングッズ販売
  • OSS-DB技術者認定試験
  • HTML5プロフェッショナル認定試験
  • ACCEL認定試験
  • OPCEL認定試験

このページのトップへ

Facebook like

twitter lpijapan

twitter ossdblpijapan

twitter html5Cert