Linux豆知識

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

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

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

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

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

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

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

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

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

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

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

今回は、「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」について。

コンピュータを扱っていると、記憶媒体の容量などを表す時に、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）」について。

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とサーバー」についてコメントを。

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

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

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

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

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

今回は、「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は、意外と知られていないのですが、コンピュータのメモリに作成できるファイルシステムです。このように聞くと「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は、引数なしで実行すると全ての有効な接続が表示されます。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

さて、その際の出力は次のようになります。各項目の単位はキロバイトです。

             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コマンドは、メモリの空き容量、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コマンドは、稼働中のシステムをリアルタイムかつ簡潔に監視することができるコマンドです。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サーバが操作される側、クライアントが操作する側で動作します。

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とは、FreeBSDで採用されているソフトウェアのパッケージ管理システムです。YUMなどと異なり、/usr/ports 以下の「カテゴリ/パッケージ」ディレクトリに、portsスケルトンと呼ばれるMakefileなどに書かれたパッケージ情報が置かれおり、インストールしたいパッケージのディレクトリでmakeコマンドを実行することで、ソースファイルがダウンロードされ、パッチが当たり、ビルドされ、インストールが行われます。依存関係のチェックも行われます。

Linuxでは、「Gentoo Linux」において、「portage」と呼ばれるシステムが採用されています。このportageは、FreeBSDのportsをベースに、bashとpythonを使って構築されたシステムです。Gentoo Linuxは、portageがシステムの核と言っても過言ではなく、自分でシステムを構築していくというオペレーティングシステムですので、portageが無ければ成立しないと言っても過言ではありません。

portageは、ソースコードからソフトウェアをビルドするため、カスタマイズがしやすく、システムを自分の好みのものに作り替えることができます。一方で、取り扱いが難しく、設定を間違えるとシステムに異常が出ることも多く、上級者向けであると言えます。

portageは、腕に自信がついたら、一度は使って、その便利さを実感してみて欲しいシステムです。

今回は、「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」ファイルについて。

このファイルは、カーネルパラメータを設定するファイルです。このファイルを適切に設定することで、システムのチューニングを行うことができます（裏を返すと、不適切な設定をするとシステムが滅茶苦茶になる危険があります）。

このファイルの設定は、「/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」ファイルについて。

このファイルはいまひとつ影が薄いのですが、知っておきたい・知っておくと便利な設定ファイルです。このファイルは名前が示す通り、「システムへのログインにまつわる設定を行うファイル」です。

このファイルで設定できることは色々ありますが、たとえば「パスワードの文字数の最大値・最小値」（PASS_MIN_LEN・PASS_MAX_LENで設定します）であるとか、「一般ユーザのUID/GIDの範囲」（UID_MIN・UID_MAXで設定します）などが設定できます。特にパスワードの文字数の最小値などは大きく設定することで、（ユーザには嫌がられるかもしれませんが）パスワードを長く設定しなくてはいけなくなるため、セキュリティを厳しくすることができます。

他にも、パスワードの期限を設定するなど、さまざまな設定を行うことができます。是非、一度チェックしておくとよいでしょう。

今回は「ReiserFS」について。

ReiserFSは、ファイルシステムの一種で、日本では「ライザーエフエス」と読まれます。「Reiser」は、このファイルシステムの生みの親である「Hans Reiser」氏の名前に由来します。

ReiserFSは、1994年から開発が始まった歴史あるファイルシステムです。
「B-*Treeアルゴリズム」と呼ばれるアルゴリズムを採用しており、ジャーナリングに最大の特徴があります。ReiserFSは、ファイルシステム上のバッファやスーパーブロック、iノードの情報をB-*Treeで管理するため、ファイルのオープンや書き込み速度が速い、という特徴があります。また、異常終了時などの修復が速く、多数のファイルがあるディレクトリでのファイル検索も高速という特徴があります。

ext2/3/4の対抗馬としては、XFSと並ぶ存在とも言えるReiserFS。「ジャーナル」を搭載しているという観点からも、見逃せないファイルシステムです。ReiserFSも、独自のツールを利用してのメンテナンスが必要ですが、LPICレベル2の試験範囲でもありますので、その存在は意識しておいて欲しいところです。

今回は、「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マスカレード」について。

マスカレード（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」とは、「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ディストリビューションなどという便利なものは、配布されていなかったのです。

1991年、Linus Torvalds氏の手によって誕生したLinux。以前も紹介した通り、Linuxとは厳密には「カーネル」部分だけを指します。そして、そのLinuxカーネルは、インターネットに公開され、さまざまな開発者が参加して成長していった、というのも以前紹介した通りです。ところで、このLinuxカーネルの公開当初は、当然といえば当然ですが、カーネルのみの公開でした。すなわち、デスクトップ環境はおろか、シェルすらも一緒に配布されていなかったのです。

この当初、カーネルを入手したユーザは自力でさまざまなプログラムを追加し、Linuxを利用していたのです。もちろん、それが大変だからこそ、有志の手によって「Linuxディストリビューション」が組まれ、Linuxを利用する敷居が下がりました。しかし、かつてできた「自分の手でLinuxをOSとして組み上げる」ということが今できないはずはありませんね。

もちろん、高度な技術と知識、それに手間がかかることではあります。しかし、今でもカーネルが単独で入手できますし、さまざまなプログラムも個々に入手できます。スキルが上がったら挑戦してみてはいかがでしょうか。

今回は、「IDS（侵入検知システム）」について。

IDSとは、「Intrusion Detection System」の略で、訳すと「侵入検知システム」となります。IDSは、その名の通り、回線などを監視することで、ネットワークへの侵入を検知するシステムです。役割は言わずもがな、ネットワークのセキュリティを担保するためのソフトウェアです。前回の豆知識で「Linuxでゲートウェイを構築する」という内容を取り上げましたが、そのゲートウェイに搭載することで、ネットワークのセキュリティを保つことができます。

代表的なオープンソースのIDSに、「Snort」があります。「Snort」は、主にネットワークを流れるパケットを監視し、不正が疑われるパケットを発見した場合に、管理者に通知する形で侵入を検知します。不正侵入が疑われる手段をパターン化しておき、パケットをパターンと比較して、不正の有無を
判定します。

一方、「Tripwire」というソフトウェアもIDSに分類されることがあります。
こちらはネットワークではなく、ファイルシステムをチェックし、ファイルシステムに改ざんがないか？をチェックします。ネットワークを監視するわけではありませんが、侵入された場合、高い確率でファイルシステムに何らかの書き換えが加わるため、ファイルシステムを監視すれば、侵入を検知することが可能となります。

IDSは非常に強力なツールであるという側面もある一方、設定が難しいという一面もあります。設定を「厳しく」すると、誤検知、すなわち「不正でないのに不正とみなしてしまう」ケースが増えます。一方、設定を「ゆるく」すると、不正の見逃しが出てしまいます。適切に設定するのが難しく、またケースによって「適切な設定」が異なるので、どうしても「こうすればOK」というのがなく、手間がかかります。

とはいえ、非常に強力なツールであることに違いはありません。さまざまな知識を駆使して、使いこなしに挑戦してみてください。

今回は、「Linuxでルーター（ゲートウェイ）を作る」という話題を取り上げます。

ルーターは、社内LANなどをインターネットに接続するために必須ですね。
このときに、Linuxマシンに2枚のNICを差し、ルーティングテーブルとIPマスカレードの設定をきちんと行えば、ゲートウェイが出来るというお話しをしました。

さて、このようにしてまでLinuxでルーターを作成するメリットは何か？
ずばりと言って、セキュリティのお話しです。

基本的な設定を行うだけでは、セキュリティ対策をまったく講じていないため、利用はお勧めできません。しかし、たとえばパケットフィルタリングを活用すれば、それだけでもセキュリティは上昇します。iptablesコマンドでは、ログを取るといった使い方もできるので、セキュリティ上怪しいパケットの監視もやりやすくなります。パケット監視ツールは他にもあるため、監視がやりやすいというのは利点の１つです。

さらに、ゲートウェイ用のウィルス検知ソフトウェアというものも存在しますので、これを用いると、ゲートウェイでウィルスを食い止めるということもできます。さらに、侵入検知ソフトウェア（IDS）というものも存在し、クラッカーの攻撃からLANを守ることもできます。

要するに、「ゲートウェイでセキュリティに関するソフトウェアを動かすことができるため、セキュリティを高めることが自在にできるようになる」ということが大きなメリットなのです。

もちろん、あまり安易な技術で実行するのは怪我のもとですが、技術力が向上してきた時には、実践してみてはいかがでしょうか。

今回は、「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とは、「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ではデータの中身まで保護するような機能が備わってい
ますが、すべてのジャーナリングファイルシステムにおいてデータの内容までが保障されるわけではないことは注意しておいてください。

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

udevは、Linuxカーネル用のデバイス管理ツールです。主な役割は、「/dev」ディレクトリにあるデバイスノードの管理を行うことです。

かつては、/devディレクトリには、利用される可能性のあるデバイスファイルを、予め/devディレクトリに用意しておく必要がありました。そのため、/devディレクトリには非常に多くのファイルが設置されていました。現在ではudevが、必要に応じて/devディレクトリにデバイスファイルを作成するようになっています。

udevは、ライブラリ「libudev」とデーモン「udevd」、そして管理コマンド「udevadm」などからなります。udevdデーモンがカーネルの内部情報を監視する役割を担っており、カーネルが新しいデバイスを検知したとき、そのデバイスに応じて適切なデバイスファイルを動的に作成するのです。

udevのおかげで、さまざまなデバイスを、コンピュータに自由に抜き差しして利用できる、というわけです。縁の下の力持ち的な存在ですが、LPIC 201の試験範囲に含まれるツールですので、是非覚えておいてください。

今回は、LVM（logical volume manager：論理ボリューム管理）について。

LVMとは、複数のハードディスクやパーティションにまたがった記憶領域を、あたかも一つのディスクとして扱うことのできるディスク管理機能です。

LVMでは、ハードディスクやパーティションを「物理エクステント」と呼ばれる数十Mバイトの小さな領域に分割して管理します。そして、その物理エクステントの集団をまとめて、「論理ボリューム」を構成します。これによって、あたかも１つのハードディスクを分割したり、複数のハードディスクを結合したように利用したり、また、一度作った論理ボリュームの容量を変更したり、といったことができるようになります。

最近では、Linuxをインストールすると、インストーラーがLVMを利用したパーティションを作成するケースが多く見られます。この場合、/bootやswap領域など、サイズが限定される領域ではLVMが利用されませんが、/varや/homeなどの領域ではLVMが利用されるようです。

LPICレベル2の範囲でもありますし、実際に利用されている技術でもあるので、きちんと理解しておきましょう。

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

fsckコマンドは、ファイルシステムにエラーがないかどうかのチェックと修復を行うコマンドで、ファイルシステムの管理には欠かせないコマンドだと言えます。

デフォルトの動作は、/etc/fstabに記述されているファイルシステムを対象に、エラーがないかどうかを逐次的にチェックします。エラーが見つかった場合、修復を試み、可能であれば修復をします。エラーが見つかるとダイアログで修復するか否かを聞いてくるので、ここで修復を行わないという使い方もできます。

注意点もあります。それは、このコマンドによるファイルシステムの修復は完全なものではなく、かえって問題を深刻化させてしまうケースもあるので、エラーが見つかったときに何も考えず修復を試みるのは却って危険なことがあるという点です。エラーが見つかったときにダイアログが出てくるのはそのためです。

コマンドには、「fsck /dev/hda1」のように、デバイス名を指定してチェックを行います。

さてこのfsckコマンドですが、基本的に「マウントされていない」ファイルシステムに対して実行します。fsckコマンド実行と同時にデータの書き換えが行われると、ファイルシステムを破壊してしまう恐れがあるためです。そのため、多くの場合は「シングルユーザモード」に移行してから実行することになります。また、システムをブートするプロセスの中で実行することもあります。

注意点も多いこのコマンドですが、ファイルシステムの管理を行う上で欠かせないツールですので、しっかり覚えておきましょう。

今回は、キャッシュの内容をディスクに書き込む「syncコマンド」について。

大抵のファイルシステムでは、ハードディスクにデータを書き込む・変更するときに、リアルタイムでハードディスクに書き込みを行っているのではなく、一時的にキャッシュに記録しておき、後でまとめてディスクに書き込む、という仕組みをとっています。これには、ディスクアクセスの頻度を下げることで負担を減らす、ジャーナルという仕組みを成立させる、などの意味があります。

しかしながら、この仕組みのせいで少し困ったことが起こる場合があります。
一番困るのが、停電などなんらかの原因でOSが落ちてしまったときです。キャッシュのデータをファイルシステムに書き込む前にOSが落ちてしまうと、ディスクのデータが整合せず、大きなトラブルの原因になることがあります。

「syncコマンド」は、キャッシュに存在する未処理のデータをディスクに書き込むコマンドです。オプションは必要なく、単に「sync」を実行するだけでファイルへの書き込みが行われます。

大切なのは、「shutdown」コマンドを利用した場合にも、この処理が行われるということです。「reboot」コマンドや「halt」コマンドでも同様です。
この事実を知っておいて下さい。裏を返すと、おかしな方法でシステムを停止した場合、この処理が行われず、データの不整合が起こる場合があるということです。システムの停止・再起動は適切な方法で行いましょう。

 

今回は「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とは、２台以上のHDDを組み合わせることで、信頼性を高める技術です。一口にRAIDと言っても、「RAID 0」「RAID 1」「RAID 5」などの種類があり、役割も違います。実用的なのはここに挙げた3つでしょう。そして、「信頼性の向上」という観点で見ると、「RAID 1」、すなわち「ミラーリング」の手法が重要になってきます。ミラーリングは、複数のHDDに全く同じデータを記録するという手法です。この場合、トラブルで片方のHDDが故障しても、もう片方を使えばデータやシステムの消失を抑えることができます。「冗長性を持たせる」という意味合いがあると考えるとよいでしょう。

また、復旧もそう難しくありません。故障したHDDを新しいものに入れ替え（システムを停止することなくできます）、データの書き込み作業を行えば、ふたたび利用できるようになります。

何かとデリケートなHDDですから、地震や停電の影響を受けやすく、トラブルも多いと言いわれます。一方、最近ではHDDが安価になってきたため、技術さえあれば簡単に導入できます。RAID1とRAID5を組み合わせる、などということも可能ですので、ぜひ導入を検討してみて下さい。

 

今回は「データセンター」について。

先日、大きな地震がありました。東北を中心に大きな被害が出ました。首都圏もかなり大きな揺れがありました。しかし、それでもサービスを停止できないインターネットサーバがあります。

大きな企業の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とは、「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は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。お互いに、良きライバルということができるかもしれません。

今回は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ディストリビューションのベースとして採用されています。正しく知っておきましょう。

今回は、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ディストリビューションを選択しましょう。

今回は、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とは、「Virtual Private Network」（仮想プライベートネットワーク）の略です。

企業などでも、大きな企業になれば、本社の他、いくつかの支社が存在するため、拠点が複数存在します。しかし、一つの組織である以上、これらの拠点を一つのネットワークにまとめることができれば便利です。すなわち、一つの組織で一つの大きなLANを構築できれば便利です。

このためにはどうすればよいでしょう？各拠点のLANを結び、一つにまとめてしまえばよいのです。このための仕組みが「VPN」です。

ただし、言うは易しく、行うは難しです。拠点を結ぶためには公衆インターネット回線を使うのが一番手っ取り早いですが、危険が氾濫している公衆インターネット回線を利用して結ぶのはあまりにもリスクが大きすぎます。

そこで、「公衆インターネット回線を利用し、通信の暗号化を組み合わせてVPNを実現する方法」や、「専用のネットワークを利用した、インターネットとは別に構成されたIPネットワークを利用する方法」などがあります。
VPNを実現するためのプロトコルとしてはPPTPやSSL、IPsecなどがあります。

技術的には少し難しいVPNですが、利用できるようになれば非常に便利な技術なので、是非頭に置いておいて下さい。

今回は、「オーバーヒート」について。

オーバーヒートは、Linuxに限らず、コンピュータ全般に起こりえるトラブルですが、特にサーバにおいては注意しなければならないことと、時節柄の注意として、取り上げてみます。

「オーバーヒート」は、コンピュータなどを高温環境下に置くことで暴走するという現象です。特にコンピュータでは、CPUやメモリなどを稼動させるだけで発熱するので、ある程度以上の温度になると発熱がエスカレートし、温度の制御が効かなくなり、コンピュータが暴走するという危険があるのです。半導体には熱に弱いものが多いので、オーバーヒートを引き起こすと、コンピュータが暴走、強制停止、故障など、深刻なトラブルを引き起こします。

特にサーバには注意しなければなりません。サーバは24時間365日稼動させることも多いので、思わぬ時間に熱暴走を引き起こすこともあります。また、サーバの設置場所にも注意が必要です。部屋の隅など、熱が篭りやすい環境では、オーバーヒートを引き起こす危険が高くなります。

プログラムやクラッカーとはまた違うところに気を遣わなければいけないのですが、ゆめゆめ「サーバが夏バテして大切なデータが飛んだ」などということがないよう、気をつけて下さい。

今回は、「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について。

「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とは「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は、「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はリレーショナルデータベースの制御には絶対に欠かせないものになっています。

ちなみに、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とは、一つのソフトウェアを指す用語ではありません。「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とは、システムのログを取るためのプログラムです。多くのUNIX系OSで採用されているプログラムで、「システム全体のログを採取する」という、システムを支える重要な役割を担っています。syslogの本体となるプログラムは「syslogd」というデーモンで、メモリに常駐してログを採取します。

syslogの特徴は、「/etc/syslog.conf」という設定ファイルで、「どのアプリケーションの、どの重要度のメッセージを、どのファイルに流すか？」といったことを細かく設定できるという点にあります。前回も少し触れましたが、あまりにも情報量が多いと管理者もログを見るのが大変なので、この機能をきちんと設定することで「特に注目したいアプリケーションに限って細かく情報を採取する」などといったことができます。

また、意外と知られていないのが、syslogは「ネットワークを通じて他のコンピュータとログを送受信する機能がある」という点です。SSLなどを利用して暗号化した通信を行うこともできるので、ログを１つのサーバに集約して集中管理するといったこともできます。

ログはシステムを使いこなすための必須アイテム、syslogはログ採取のための強力なツールです。ぜひ、使いこなせるようになって下さい。

今回は、「ログ」について。

ログは、主にシステムやソフトウェアが残す「記録」のことです。語源は「航海日誌」を意味する「logbook」です。

良く「何かトラブルがあったり、自分の思い通りにならなかったら、ログを読め！」と言われます。たしかにシステムやソフトウェアが事細かに動作を記録している「ログ」は情報の宝庫で、ログを読めば問題解決の手がかりが得られるケースは非常に多いのです。

しかし「ログを読むのはどうも苦手」というユーザが多いというのも事実です。理由は単純で、ログの情報量が多すぎて、全部に目を通すのがあまりにも大変だというものが主なものでしょう。また、メッセージが英語であることも、英語が苦手な人からは敬遠されがちです。「ログには目を通す習慣をつけましょう」と言われてもなかなか実行できないかもしれません。

ログを読むときにはいくつかのコツがあります。まず「一番最後」を見てみること。ログファイルは、一番新しいログが一番最後に記録されています。
tailコマンドでもいいですし、lessコマンドで読み込んだ後、「G」（シフトキーを押しながら、大文字で）を入力すると一番最後の行が表示されます。

量が多すぎる時は「フィルタ」を通すこと。grepコマンドを使って、たとえば「warning」や「error」などのキーワードを探し出してそこを読む。
「Apacheが思ったように動かない」というのであれば「httpd」をキーワードにしてログを抽出し、手がかりを探すなどです。

また、「監視」も１つのコツです。ツールを使って、本当に大切なメッセージが出た場合にはメールで通知する（ただしこの場合は情報が漏れるのを防ぐために自ホスト内のユーザにメール送信するのがベストです）などです。

さらに、「集計」も有効です。ログ集計ツールも様々なものが出ていますから、たとえばアクセス解析や不具合がどのくらいの頻度で起きているのか？を集計するというのも使い方の一つです。

ログと上手く付き合って、システムをうまく使いこなしましょう。

今回は、「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は「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は、「Lightweight Directory Access Protocol」のことで、名前からわかるようにプロトコルの一つです。LDAPは、データベース（階層型DB）にアクセスする仕組みです。管理されるデータは、ユーザ名やパスワードなどの「アカウント情報」や、その他のユーザ情報が主となります。

LDAPは、「多くのコンピュータで、ユーザ情報などを一元管理したい」という場合に使われます。たとえば、教育機関や企業などで複数のマシンがあり、ユーザも多数存在するというときに有効です。

LDAPのような一元管理の仕組みが無いと、一つ一つのマシンにユーザ情報をいちいち登録する必要が出てきます。もちろん、ユーザ情報に変更が生じた場合には全部のマシンで変更作業が必要です。これはあまりに非効率的ですね。そこでLDAPの出番です。

LDAPは、ユーザ情報をサーバに一元的に管理することができ、各ホストはLDAPサーバに接続すれば共通のアカウント情報を利用することができます。
こうすれば、ユーザ情報に登録・変更が生じてもほとんど手間がかかりません。以前はこの仕組みを「NIS」と呼ばれるシステムで提供していましたが、最近ではLDAPが主流になっています。

LDAPを利用したときに得られるメリットはこれだけではありません。LDAPは、一元管理できる情報が他にもあり、アカウントだけでなくWebサーバの基本認証情報などを共有する、LDAPとメールサーバを連携させるといったこともできます。

多くのメリットがあるLDAP、一人でLinuxを利用するにはあまり縁がありませんが、少し人数とホストが増えただけでも導入するメリットは大いにあるので、ぜひ覚えておいてください。

今回は「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は、CD-ROMやDVD-ROMのISOイメージなど、サイズが大きく、かつ多くのユーザに配布する際に使われます。

BitTorrentは以上のような仕組みから成っているため、従来であれば「ファイルのダウンロードはクライアントが多いほど遅くなる」となるところを、逆に「クライアントが多いほど早くなる」という特徴を実現させました。
コロンブスの卵的な発想ということができるでしょう。

BitTorrentのクライアントには、「BitTornado」「Transmission」と呼ばれるソフトウェアのほか、KDEに含まれる「KTorrent」など、数多くのソフトウェアがあります。また、Firefoxなど、BitTorrentに対応したWebブラウザもあります。使う人が多ければ多いほどメリットがあるというBitTorrent、大きなファイルをダウンロードする際には是非活用してみて下さい。

今回は、ダイナミック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（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とは、「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ディレクトリ配下にあるファイルは、さまざまなプロセスを動作させる際にたびたび参照されます。ですから、Linuxの動作を決める上でとても大切なディレクトリと言えます。

ここのファイルを参照すると、さまざまな情報を得ることができます。たとえば、コマンドラインから「cat /proc/cpuinfo」と入力してみて下さい。
CPUの情報を得ることができます。他にも、メモリの情報、ドライバの情報、その他ハードウェア面・ソフトウェア面についてさまざまな情報を得ることができます。

そして、/procにあるファイルを編集すれば、システムの状態を調整することもできます。たとえば、iptablesを使ってルーターを作る場合に/proc/sys/net/ipv4/ip_forwardの値を変更します。ただし、これはかなり高度な知識を必要とします。正しく知れば非常に便利なのですが、裏を返せば、誤った改変をするとシステムを破壊することにもなりかねません。曖昧な知識のまま、むやみに変更することは避けて下さい。

今回は、「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は、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、ニュースのコメントでも述べたように、外国ではOSにLinuxを搭載したものも多く流通しています。その要因の一つに「コスト削減」があります。

ネットブックなどとも呼ばれるこのPC、その発祥は実はOLPCと呼ばれるアメリカのNPOが、発展途上国の子供たちに、Webや電子書籍の閲覧など基本的な操作ができるように安価なPCを開発しよう、というプロジェクトが立ち上がったのが先駆け、とも言われています。OLPCは「100ドルPC」という目標を掲げて開発を進めるも、「100ドル」は今のところ達成できていないようです。

この動きの中で、さまざまなメーカーやベンダーなどが「小型で廉価なPCを作ろう」という動きを見せています。ネットブックの誕生は、こうした動きの中で誕生したものだといえます。

ネットブックは、まだ歴史の浅いジャンルです。日本ではネットブックのOSにLinuxを搭載したものはそれほど多くはないのですが、ネットブック向けのLinux OSの開発を行っているプロジェクトも数多く存在しますし、海外ではLinux搭載のネットブックも流通しています。今後、Linuxを搭載したネットブックは一つの大きな流れを作ることになるかもしれません。

前回は、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として動作させることはできません。もちろん、自分で他のアプリケーションを入手するなり自作するなりして・・・ということを行えばできますが、「カーネルだけを使って」というのは不可能だと思ってよいでしょう。

さて、今回は新年一回目ということで、この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は単独のプロトコルではなく、「プロトコルの集合体で、現在インターネットなどのネットワークで、標準として利用されているもの」です。

前回も少し触れたのですが、１つのプロトコルだけで通信は行えません。
いくつかのプロトコルを利用してはじめて、通信を行うことができるのです。
もっと言うと、現在のインターネットにおける通信のほとんどは、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-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。複数の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年近く前で、今のように、誰でも使えるネットワークに進化するなど、まったく想定されていなかったのです。つまり、生い立ちそのものが、「悪用されようがない環境の下で開発された」のです。

それにしても、便利になればなるほど悪用者も増えるというのは、因果なものですね。

よく、「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をターゲットとしたウイルス（などの不正ソフトウェア）」は、Windowsをターゲットにしたものに比べるとはるかに少ないといえます。普及度から考えれば当然で、Linuxをターゲットにした不正ソフトがばら撒かれたところで、被害を受ける範囲は限定的になります。

しかし、「ではLinuxに感染するウイルスなどは存在しないのか？」「Linuxではウイルス対策が必要ないのか」というと、そんなことはありません。Linuxに感染する不正ソフトウェアも発見されています。それだけではありません。特にサーバ用途で顕著ですが、たとえばWindowsを標的にしたウイルスがLinuxサーバに紛れ込んでしまった場合、Windowsがウイルスを持っていってしまうケースも少なくありません。

Linuxを利用する際、どうしても見落としがちなウイルス対策なのですが、上述のような理由で「全く考えなくてよい」ということは決してないのです。

では、どのように対策するのか？これは他のOSと同様、対策ソフトウェアを利用するのがベストでしょう。対策ソフトウエアは、商用のものもありますが、実は「Clam AntiVirus（ClamAV）」など、オープンソースのウイルス対策ソフトウエアも存在するのです。

サーバの運用・管理にあたって、セキュリティはどうしても切り離して考えることができません。ウイルス対策など見逃しがちなところにも、目を向けてみてください。

Linuxとは、本来は「カーネル」のみを指す用語です。5年くらい前はこのことがよく言われたものですが、最近はあまり聞かなくなりました。「LinuxはOSである」という誤解？が一般的になってしまった、ということでしょうか。
ここでの「OS」とは、コンピュータの環境全体を指しています。

しかし、カーネルは、本来はハードウェアとソフトウェアの仲介を行うのが役割ですから、カーネルだけではPCは動作しません。ですから、これに様々なソフトウェアを組み合わせ、OSとして動作するようなパッケージを作るわけです。これが「Linuxディストリビューション」です。最近では、Linuxディストリビューションを「Linux」と呼ぶケースも多いようです（繰り返しになりますが、厳密な意味での呼び方ではありません）。

さて、Linuxカーネルは基本的に1つしかありません（バージョンの違いはありますが）が、Linuxディストリビューションは複数あります。なぜならば、カーネルと組み合わせるソフトウェアは膨大な数存在し、また組み合わせ方 もさまざまだからです。このようにして、さまざまなLinuxディストリビューションが出来上がるのです。

さらにLinuxカーネルも実は複数あります。様々なパッチを当てたもののほか、ディストリビューションごとに独自のカーネルを使っている場合もあります。そこで、kernel.orgで配布されている素のカーネルのことを「vanillaカーネル」と呼んで区別しています。

では、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「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の読み方は諸説紛々です。代表的な説として、以下のようなものがあります。

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：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とは、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カーネルは、Linus Torvalds氏がインターネット上にカーネルのコードを公開し、それが開発者たちの間に広がり、多数の開発者がカーネルの開発に携わるようになったという経緯があります。

しかし、当然のことながらLinuxのカーネル開発なんてどうやればいいのか？情報がないと難しいですよね。その大きな情報源となるのが、「Linux Kernel Newbies」というサイトです。
このサイトは、Linux カーネル開発に役立つFAQなどの情報が集められており、また開発に関する質問ができるIRCチャンネル、メーリングリストなどがあります。

また、Linuxカーネル開発に伴い、今なにが問題になっているのか？何をしなければならないのか？などの情報が集まっているのが、「Linux kernel Janitor's Project」です。

そして、もしLinuxカーネルにマージ（混合）したいコードが書けた場合、「Kernel Mentors」というメーリングリストに報告します。
基本的に、Linuxカーネルをはじめ、ボランティアの手で書かれているソフトウェアの多くは、メーリングリストによる活動が中心になっています。

このように書いても、Linuxカーネルの開発に参加することはあまり現実的でないと思われるかもしれません。たしかに世界中の開発者と共にこのようなプロジェクトに参加するのは気がひけるという方がほとんどでしょう。
また、カーネル開発に限らず、多くの人が参加しているソフトウェア開発に携わるには、前述のようにプログラミングの能力、知識の他、「コミュニケーション能力」が大切になります。作業のほとんどが顔の見えないメーリングリストという場で行われているのですから尚更大切になります。
敷居はたしかに低くはありません。

しかし、それでもLinuxカーネルの開発作業に山積する問題は大量にあります。
もしかしたら、あなたが書いたコードが、Linuxカーネルの一部になる日がやってくるかもしれません。