トップ > 受験準備をしよう > Linux豆知識

Linux豆知識

このページでは、Linuxを学習する上で出てくる素朴な疑問や、便利なテクニックなどを紹介しています。

Linux豆知識（Linuxを学習する上で出てくる素朴な疑問や、便利なテクニックなど）

『syslog』

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

前回は「ログ」について取り上げました。syslogと言えば、ログを見たことがある方ならばピンと来るでしょう。syslogとは、システムのログを取るためのプログラムです。多くのUNIX系OSで採用されているプログラムで、「システム全体のログを採取する」という、システムを支える重要な役割を担っています。syslogの本体となるプログラムは「syslogd」というデーモンで、メモリに常駐してログを採取します。

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

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

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

『ログ』

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

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

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

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

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

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

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

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

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

『RFC』

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

前回取り上げたNTPであれば「RFC1305に規定されている」、HTTPであれば「RFC2616に規定されている」のように使われるので、耳にしたことがある方も多いでしょう。

RFCはRequest For Commentsの略で、「IETF（Internet Engineering Task Force、http://www.ietf.org/）」によって公開された、インターネットで利用される技術についての標準を定めることを「目標とした」文書です。インターネットの技術のほとんどは、このRFCに記載された内容に則って成立しているといっても過言ではありません。

ところで、上で「目標とした」にカギ括弧をしたのには理由があります。実際にはインターネットで利用される技術は日々変化しており、標準化するのは難しい作業です。「これが標準だ」と定めても、状況に応じて変化することもあります。また、標準を定めても、何らかの不都合が生じる場合があります。

RFCは、「インターネットで利用される技術の標準を定めて」いますが、書き換わったり廃棄されたりする、ということもよく起こります。また、全てのRFCが「標準」ではなく、標準化の提唱や実験的なものもRFCとして発行されるため、注意が必要です。さらに、エイプリルフールにはジョークRFCが発行されることもあるため、「RFCの全部が完全に標準化されたものだ」と思い込んでいると大変な目に遭います。

とはいえ、RFCはインターネットの仕組みを支えている重要な文書であることに違いはありません。RFCは、http://www.rfcsearch.org/から検索することができますので、「RFCxxxx」という記述を見かけたら、一読してみることをお勧めします。

『NTP』

今週は、「NTP」について。

前回、「タイムゾーン」、すなわち時間に関する話題を取り上げました。NTPは「Network Time Protocol」の略で、ネットワークを経由して、コンピュータが時計を正確な時刻に同期するためのプロトコルです。

PCに内蔵されている時計はかなり不正確なもので、一ヶ月も運用すると何秒かのずれが出てしまうこともあります。しかし、ネットワークサーバ用途で利用する場合、電子メールの送受信記録などで時計がずれていると異常が出る場合が多々あります。そのため、ネットワークで接続されたホスト同士は時計が互いに同期されている必要があります。これを解決するのがNTPです。

NTPはサーバ・クライアント方式で提供されます。「NTPサーバ」では、原子時計などを利用した正確な時計を持っており、NTPを通じてクライアントに正確な時刻を提供します。クライアント側は、Linuxでは「ntpdate」コマンドを利用するとNTPサーバと時計を同期することができます。ntpdateコマンドはrootユーザで利用します。下のようにntpdateにNTPサーバ名を指定すれば、指定したNTPサーバと同期されます。

# ntpdate ntp.nict.jp

これをcronで定期的に実行することで、サーバの時計を正確に保つことができます。

問題は、NTPサーバはどのサーバを使うか？です。「NICT 独立行政法人情報通信研究機構」では、「日本標準時プロジェクト」を行っており、公開NTPサーバを提供しています。

NICTの公開NTPサーバについて
http://www2.nict.go.jp/w/w114/stsi/PubNtp/

毎秒100万リクエスト以上をこなすことができるNTPサーバですが、むやみとアクセスしてもよいというわけではありません。ある程度の台数がまとまる場合には、ネットワーク内にNTPサーバを設置して、その他のコンピュータは自前のNTPサーバを参照するようにするとよいでしょう。

『「UTC」と「JST」』

今週は、「UTC」と「JST」について解説します。

地球上の国には、それぞれ時差があります。ところがインターネットは世界中に張り巡らされたネットワークですし、国境を跨いだデータのやりとりも頻繁にあります。そうなると、インターネットに接続されたサーバに共通の時刻が必要になります。

実際、インターネットに接続されたサーバは、多くの場合「協定世界時（UTC：Universal Time Coordinated））」を利用します。学校の地理の授業で習ったかもしれませんが、イギリスで利用されているGMTがUTCと一致していることで有名です。厳密にはUTCとGMTは異なります。UTCは、セシウム原子が振動する時間を基準とし、GMTにおける1958年1月1日0時0分0秒からの経過時間をカウントして定めた時刻です。ただし、地球の自転は一定ではないため、この決め方ではGMTとUTCの間にズレが生じてしまいます。このため、およそ1年に1回「うるう秒」を追加してGMTとUTCのズレを調整しています。

そして、世界中の時計は、UTCを基準に決められています。日本であれば、UTCに9時間を足した「日本標準時」（JST）が用いられています。逆の言い方をすると、JSTから9時間を引けば、UTCが得られます。

JSTは、かつては兵庫県明石市を通過している「東経135度」の子午線の時刻を基準に定められていました。現在では、原子時計を基準にしてUTCを定めており、これに9時間を足したものをJSTと定めています。もっとも、東経135度の子午線で決まる時間と現在の決め方にはほとんど差がありません。

サーバを管理する際には、サーバが取り扱っている「時間」が、JSTなのかUTCなのか、はたまた別のタイムゾーンなのかを意識する必要が出てくることがあります。アメリカなど、同一国でも場所によって複数のタイムゾーンが存在する国もありますから、特に海外のサーバを取り扱う際には注意が必要となります。

『Linuxカーネルの開発者になるには』

新年のスタートに、「Linuxカーネルの開発者になるにはどうしたらよいのか？」という話題を取り上げます。

Linuxのカーネルを開発しているのは、ボランティアの開発者たちです。
特別な企業などに所属しているかというと、そういうわけではありません。
ですから、あなたもLinuxカーネル開発に参加する資格があるのです。もちろん、卓越したプログラミング技術と、開発する機能についての一定以上の知識が必要であることはいうまでもありません。しかし、技術、知識のほかにコミュニケーション能力があれば、あなたが書いたコードがLinuxカーネルに取り込まれる！ということもありうるのです。

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

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

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

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

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

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

『LDAP』

今回は「LDAP」について。

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

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

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

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

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

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

『SCPとSFTP』

今回は「SCPとSFTP」について取り上げたいと思います。

SCPもSFTPも、SSHの機能の１つとして提供されます。いずれも、SSHプロトコルを利用したファイル転送を実現します。ファイルの内容はもちろん、ログイン時のアカウント情報を平文でなくSSHによって暗号化された情報としてネットワークに流すことができ、セキュアなファイル転送を実現します。

SCPはCPコマンドに似せて、SFTPはFTPでのファイルのやり取りに似た方法で利用できます。SCPもSFTPも、「SSHを利用して暗号化したファイル転送を行うことができる」という点では共通しています。「WinSCP」や「FileZilla」などのクライアントもリリースされており、これを利用すれば、Windowsとの間でファイル転送を行うこともできます。

SCPとSFTPの相違点は、先に述べたように使い方、すなわちSCPは「SCPコマンド」に、SFTPは「FTPでファイルをやり取りする」のに似たように利用することができるという点が第一に挙げられます。違いはそれだけではなく、「SCPは比較的シンプルに作られており軽い、SFTPは多機能」という点があります。詳しく書き出すとキリがなくなりますが、両者の違いで大きな点が一つ「SFTPはファイル転送が中断しても再開が可能、SCPは不可能」という点が挙げられます。何らかの原因でファイルの転送が中断してしまうというのはよくある話ですので、この違いは大きな違いと言えます。

いずれにしても、ファイルの内容は知られたくないが転送はしたいという場合、FTPなどを利用するよりもSCPもしくはSFTPを利用するのがセキュリティ上は好ましいと言えます。

『BitTorrent』

今回は、BitTorrentについて。

BitTorrentは、ファイルを転送するためのプロトコルの一種です。サーバの負担が少なくて済み、高速でファイルを転送することができます。BitTorrentの大きな特徴は、サーバはファイルを断片的にクライアントにアップロードするという点にあります。クライアントは、サーバから断片を受け取ると同時に、自分が持っている断片を、他のクライアントに渡すという方式でファイルをダウンロードします。いわば、多くのクライアントが「協力して」ファイルをダウンロードすることになるのです。すなわち、BitTorrentでは、多くのクライアントがあればあるほど、ダウンロード速度が向上するという特徴があります。このため、BitTorrentは、CD-ROMやDVD-ROMのISOイメージなど、サイズが大きく、かつ多くのユーザに配布する際に使われます。

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

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

『ダイナミックDNS（DDNS）』

今回は、ダイナミックDNS（DDNS）について。

DNSは、先週も紹介した通り、ホスト名とIPアドレスを対応づける仕組みを提供します。「ダイナミックDNS」は、ホスト名とIPアドレスの対応を「動的に」管理する仕組みを提供するものです。

従来のDNSは、IPアドレスが変わることは考慮されていません。しかし、この状況では、DHCPを利用したネットワークでは、ホストに割り当てられたIPアドレスが変わることがたびたび発生します。これでは、ホスト名が毎回異なるホストを指すことになってしまいます。ここで「ダイナミックDNS」を利用すると、IPアドレスが変更されても、その変更が反映され、ホスト名とIPアドレスの対応がきちんと取れるようになっています。

ダイナミックDNSは、個人的なサーバを運用する際によく利用されます。多くのブロードバンド回線では、個人向けにはプロバイダから動的にIPアドレスが割り当てられます。そのため、接続が切断されるたびにホストに異なるIPアドレスが割り当てられてしまうということがたびたび生じます。このような場合でも、ダイナミックDNSを利用すれば、ホスト名と変更されたIPアドレスの対応を自動的に取ってくれます。このため、固定IPアドレスがなくてもサーバの運用が可能になります。

このように、ダイナミックDNSを利用すれば、きちんとホスト名がついたサーバを運用することが簡単にできます。ただし、問題点もあります。ダイナミックDNSでは、IPアドレスが変更されたときに、その変更がDNSに反映されるまで少し時間がかかります。その間には、ホスト名とIPアドレスが正しく対応できておらず、ホスト名が別のホストを指してしまうことになります。このため、サーバの運用にダイナミックDNSを利用するのは少々危険を伴うことになります。ダイナミックDNSを利用したサーバ運用には、セキュリティ面からの否定的な意見も少なからず存在します。営利目的のサーバ運用にダイナミックDNSを利用するのは危険ですし、個人用途でのサーバ運用で利用する際も、危険性を考慮した上で利用するようにして下さい。

『DNSサーバー』

今回は、「DNSサーバー」について。

DNS（Domain Name System）サーバーは、ネームサーバーとも呼ばれます。
インターネットを利用する際、DNSサーバー（ネームサーバー）は必ず指定するので、その名前を一回は耳にしたことがあるでしょう。

さて、このDNSサーバーですが、この役割は何でしょう？

インターネットでホストに接続する際、ユーザーはホストを「www.lpi.or.jp」のようなドメイン名で指定します。このドメイン名は、ユーザーにとってわかりやすい名前になっています。しかし、コンピューターは、ネットワーク上にあるホストを「202.218.212.222」のようなIPアドレスで識別します。この、ドメイン名とIPアドレスを対応づけるのがDNSサーバーの役割です。

DNSサーバーの役割は、大雑把に言って２つの役割があります。
１つは、クライアントからの問い合わせに応じて、ドメイン名からIPアドレスを調べる（あるいはその逆）という役割。これを「フルサービスリゾルバ」と呼びます。問い合わせを行うクライアントを「スタブリゾルバ」と呼びます。
もう１つは、ドメイン名とIPアドレスの対応データを管理・提供するという役割です。これを「コンテンツサーバー」と呼びます。
DNSサーバーによっては、両方の役割を兼ねているものもありますし、片方だけの役割をこなすものもあります。

DNSの仕組みは複雑ですが、一つ言えることは、DNSサーバーはほとんどの場合、1台だけではその意味をなさないということです。インターネットでは、複数台のDNSサーバーが連携して「ドメイン名とIPアドレスを関連付ける」という目的を達成します。この理由は比較的単純です。インターネットに接続されたホストは膨大な数に上りますので、1台のDNSサーバーで全てのドメイン名を管理することは不可能なのです。このため、DNSサーバーでは「分散管理」、すなわちドメイン名とIPアドレスの対応は1台のDNSサーバーあたり数個～数十個程度に留めるのです。そして、「複数台のDNSサーバーが連携して動作することによって」ドメイン名からIPアドレスを調べる、という作業を行うわけです。

DNSサーバーの仕組みは少し難しいですが、「複数のDNSサーバーが連携する」ということを頭に入れておくと理解しやすくなると思います。

『メールサーバー』

今回は、「メールサーバー」について。

メールサーバーには、通常２つのサーバーソフトウェアが動作しています。
「SMTPサーバー」と、「POPサーバーやIMAPサーバーなど」の２つのソフトウェアです。

このことは、メールクライアントを利用している方ならピンと来るかもしれません。メールクライアントをセットアップする時に、「送信サーバー」と「受信サーバー」を指定します。同一のサーバーを指定することも少なくありませんが、「送信サーバー」と「受信サーバー」を指定するということは、メールの送受信には「メール送信のサーバーソフト」「メール受信のサーバーソフト」が必要だということです。

メールを送信する際、メールの経路を単純に表すと

[送信者側のSMTPサーバー]	→	[受信者側のSMTPサーバー]
↑		↓
[送信メールクライアント]		[受信メールクライアント]

の順に渡ります。すなわち送信者はSMTPサーバーにメールを渡し、SMTP（Simple Mail Transfer Protocol）プロトコルを利用して目的のメールサーバーへ送り届けます。そして、受信メールクライアントは、POPサーバーからメールを受け取る、という手順でメールがやりとりされます。

SMTPサーバーのことをMTA(Mail Transfer Agent)、メールクライアントのことをMUA(Mail User Agent)と呼ぶこともありますので、覚えておくとよいでしょう。

『GCC』

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

GCCとは、「GNU Compiler Collection」の略で、C、C++、FORTRAN、Javaなどいくつかの言語のコンパイラ、およびこれらのライブラリから構成されています。コンパイラ本体だけでなく、コンパイルに必要なライブラリも含まれていますので、GCCを利用すれば、さまざまな言語で書かれたソースコードをコンパイルすることができるのです。

GCCはフリーソフトウェアであり、ほとんどのLinuxディストリビューションに含まれているので、Linuxを利用すれば手軽に利用することができます。
というよりも、「Linuxを語る上でGCCを外すことはできない」といったほうが正しいかもしれません。

GCCを利用する重要な場面の一つに、「Linuxカーネルの構築」があります。
Linuxカーネルをコンパイルする際には、ソースコードをGCCを利用してコンパイルを行います。卵が先か鶏が先か、のような話になりますが、GCCはLinuxの環境を構築する際に欠かせないツール、ということになるのです。

最近では、Linuxカーネルの構築という作業をほとんど行うことなしにLinuxを利用することもできます。このため、Linuxカーネルのコンパイルを経験したことがないという方も多いかもしれません。しかし、細かいチューニングや最適化を施す、機能を追加するなどの際にはカーネルの構築は避けて通れない作業です。

カーネルの構築以外にも、さまざまなアプリケーションのコンパイルにGCCを使うことになります。「開発をやらないからGCCには縁がない」ということはありません。長くLinuxを利用するのであれば、GCCを利用したコンパイルという作業には必ず出会うことになりますので、覚えておきましょう。

『コンパイラとインタプリタ』

今回は、「コンパイラとインタプリタ」について。

プログラミング言語は、C言語などに代表されるコンパイラ型言語と、Perlなどに代表されるインタプリタ型言語があります。どちらも、プログラミングは人間が理解できる形で記述しますが、このままではコンピュータには理解できません。そこで、コンパイラとインタプリタの出番です。

コンパイラ型言語は、人間が読めるコードを「コンパイラ」を使ってコンピュータが理解できる形の「機械語」によるファイルに変換し、そのファイルを実行することでプログラムを実行します。一方、インタプリタ型言語の場合は、人間が読めるコードを「インタプリタ」を使って、コードを「逐次解釈しながら」プログラムを実行します。

なお、言語によってはコンパイラとインタプリタの両方が使えるものも存在します。

コンパイラ型は、インタプリタを介さないため一般に高速です。一方で開発の際、コードを書き換えるたびにコンパイル作業が必要になるため、コードの記述やデバッグに時間がかかります。インタプリタ型は一般にコンパイラ型よりも速度に劣りますが、コードを記述すればすぐに実行に移すことができるという利点があります。

コンパイル型とインタプリタ型はそれぞれに一長一短がありますので、どちらが優れているかという話よりも、シチュエーションに合わせた選択が重要になります。

『プロキシサーバー』

今回は、プロキシサーバーについて。

会社からはプロキシサーバーを通さないとインターネットの接続ができなかったり、そのプロキシのせいで一部のサービスが利用制限を受けたり・・・。

何のためにこんなものが存在するのだろう？という方もおられるかと思います。

そもそもProxyとは、「代理」という意味です。プロキシサーバーの役割は、クライアントとサーバーの間に入って、サーバーに対してはクライアントの、クライアントに対してはサーバーの働きをするというものです。

もっともわかりやすいのが、HTTPプロキシは「クライアントからリクエストがあった場合、プロキシサーバーはリクエストを受け取って、クライアントの代わりにWebサーバーにアクセスし、結果を取得する。そしてその結果をクライアントに返す」となります。

この作業は何のために行うのでしょう？1つには、Webサーバーが送ってきたデータを保存しておき、次回同じアクセスがあった場合にはプロキシサーバーに保存されたデータをクライアントに返すことで、データの取得を高速化するという「キャッシュ」の役割があります。しかし、インターネットの高速化が進んだ現在ではこの意味は薄れています。

現在のプロキシサーバーの大きな意味は、セキュリティにあると言えます。外部とのやりとりがすべて一旦プロキシを経由することになりますので、プロキシが不正な通信などがないかを逐一チェックすることで、内部ネットワークを守るといったイメージです。もちろん、アクセスログを記録しておくということもできます。

このほかにも、会社で利用する場合などにはフィルタリング、すなわち就業時間内に閲覧することが相応しくないWebサイトへのアクセスを制限する、などの用途があります。

ネットワークの利用を適正化するためには、なくてはならない存在といえるでしょう。

『パッチ』

今回は、「パッチ」について。

バグやセキュリティホールがあると、パッチが公開されます。そのパッチを適用することで、バグやセキュリティホールへの対処とします。

それでは、「パッチ」とは一体何でしょうか。

パッチとは、プログラムの一部だけを更新・追加することで、バグの修正・セキュリティホールの修正・機能追加や変更を行なうため、小さいプログラムコードのことです。もちろんパッチだけではプログラムは動作しません。
本体となるプログラムにパッチを「付け加える」ことで、プログラムが更新され、動作するようになります。

「パッチ（patch）」とは元々「継ぎ当ての小さい布」のことを指します。
すなわち、まさにプログラムに付け足して、穴を塞ぐ「当て布」がパッチだ、ということができるでしょう。

ちなみに、パッチの適用にはpatchコマンドなどを利用する必要があります。
エディタなどでパッチを適用するということもできますが、慣れていないと危険な方法です。

パッチは、元々ネットワーク環境が未発達だった時代に、大きなプログラムをダウンロードすることなく更新ができるということで考え出されたものです。
ネットワーク環境が発達した現在でも、差分のみを適用すれば十分という状況では、良く使われる手法です。

『サーバー』

今回は、「サーバー」という用語について。

「何を唐突に」と思う方もおられることでしょう。そこで次のお題について少し考えてみて下さい。

A) 「Webサーバーとは、Webページのデータを提供するためのソフトウェアを指す」
B) 「Webサーバーとは、上記のソフトウェアが動作しているハードウェアを指す」

さて、どちらの文章が正しいでしょうか？

答えは、「両方正解」です。

つまり、「サーバー」と言った場合、ソフトウェアを指す場合と、ハードウェアを指す場合があるのです。たとえば、「Apache」というソフトウェアは「Webサーバー」ですし、「Apacheが稼動しており、Webページの情報を提供するハードウェアも「Webサーバー」と呼ぶことができます。

専門用語というのはなかなかややこしい面もあり、たとえば「Linux」といった場合には厳密にはカーネルの部分のみを指す、というのは有名な話です。「サーバー（Server)」という用語の場合は、「サービスの提供者」を指しますので、ハードウェア、ソフトウェアのどちらも、サービスを提供するもの、という意味合いで「サーバー」と呼ぶことができるわけです。

このように、専門用語はかなりややこしい一面を持っています。常時神経質になる必要はないと思いますが、たまには専門用語の正確な意味を把握する機会を持つとよいでしょう。

『/procディレクトリ』

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

/procディレクトリは、システムの状態などがファイルとして保管されている特殊なディレクトリで、このディレクトリにあるファイルは、メモリ上に作られる仮想的なファイルです。/procディレクトリ配下にあるファイルは、さまざまなプロセスを動作させる際にたびたび参照されます。ですから、Linuxの動作を決める上でとても大切なディレクトリと言えます。

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

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

『cron』

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

cronとは、「定期的にタスクを自動実行するためのツール」です。「クーロン」と読みます。cronを利用すると、時間を指定して、予め決まった時間にタスクを実行してくれます。

時間の指定は、「一時間に一回」などのような単純なものだけではなく、ある曜日のある時刻にだけタスクを実行する、とか、8時～22時の間だけ一時間に一回タスクを実行するなどの処理を行うこともできます。時刻は具体的に指定することができます。使い方は少し特徴的であるものの、それほど難しくありません。

cronは、Linuxを運用する上で欠かせないツールと言えます。定期的にログを取ったりソフトウェアの管理を行ったり、システムをチェックするのに使われています。また、プロセスや他ホストが正しく動作しているかどうかを「監視」するためにも使うことができます。非常に便利で、かつ、なくてはならないツールです。

このcronですが、意外と知られていないことに、一般ユーザでも利用できます。一般ユーザで実行できるタスクであれば、ユーザごとに独自のcronを設定することができます（ただし、システムの設定によっては利用できない場合もあります）。ですから、cronとシェルスクリプトを組み合わせれば、root権限を持たないホストから、自分のホストを監視するといった使い方もできます。

cronの利用方法は、LPIC 102試験の範囲にも含まれています。必ずマスターしておきたい事項です。

『仮想化技術』

今回は、「仮想化技術」の続きです。

仮想化技術とは、前回紹介したように「コンピューターの数と異なる数のOSを動作させることを可能にする技術」ということができます。今回は、この技術がどのように利用されているのかを紹介したいと思います。

一つには、「1台のコンピューターで、複数OSを動作させることができる」という点。個人ユーザーの視点からすれば、この使い方がもっとも身近な利用法でしょう。あるOSから、仮想化ソフトウェアを利用してLinuxを動作させて利用し、Linuxの勉強をしているという方も多いようです。

もう一つ、実はこちらの利用法も大きな注目を浴びているのですが、「複数のコンピューターで1つのシステムを構成する」ということもできます。この利用法では、複数のコンピューターの能力を集約させてシステムを作ることができるため、1台では実現が難しい性能を引き出すことができます。しかし、それだけではありません。この方法のメリットは、「必要に応じて、リソースを調整することができる」という点にもあるのです。

普通、何らかのサービスを提供するときには、そのサーバが要求される最大の能力を持たせます。そうでないと、リクエストが集中したときにサーバーがダウンしてしまいます。しかし、仮想化技術を使うと、リクエストに応じて動的にリソースを割り当てることができるため、リソースの節約、もしくは余ったリソースを他に回すなど、効率的なシステム運用が可能になるのです。このため、大規模なシステムを構成する技術として注目を浴びているのです。

Linuxと仮想化技術の関係では、XenやLinux LVMなどが注目されているので、今後のスキルとして是非身につけていくといいでしょう。

『仮想化技術』

今回は、「仮想化技術」について。

仮想化技術、単に「仮想化」と呼ばれることもありますが、最近よく見かける言葉となりました。しかし、その意味は意外と知られていません。一体なにを仮想するのか？そもそも何の役に立つのか？

仮想化ソフトウェアで有名なものに、VMwareやVirtualBoxといったものがあります。これらのソフトウェアは、簡単に言えば、あるOSの上に仮想的なコンピュータを作成し、そこで別のOSを動作させるソフトウェアです。すなわち、1つのコンピュータの上で複数のOSを動作させることができるのです。

この仕組みを提供するのが仮想化技術ですが、仮想化技術は「1つのコンピュータで複数のOSを動作させる」だけではありません。「複数のコンピュータで1つのOSを動作させる」といったこともできるのです。すなわち、仮想化技術を利用すると、「コンピュータの数と異なる数のOSを動作させることができる」のです。

仮想化技術によって、コンピュータの数とOSの数のバランスを適宜調整することも可能です。必要に応じて、OSに割り当てるコンピュータの数を変えることもできます。「必要に応じて、コンピュータの能力を適切に割り振る仕組みを提供してくれる」のが仮想化の効用だということができるでしょう。

仮想化の具体的な効用については、次回取り上げたいと思います。

『シェルスクリプト』

今回は、「シェルスクリプト」について。

シェルは前回取り上げた通り、「Linuxとユーザーをつなぐインターフェイスとなるソフトウェア」です。Linuxでは、シェルを通じてシステムを操作するという局面が多くなります。

ここで、定期的にシステムを監視するなど、「何度も類似の操作を繰り返して行いたい」というケースを考えます。このケースでは、シェルに対して何度も同じようなコマンドを入力することになります。これは手間がかかります。

そこでシェルには、事前に一連の操作（実行するコマンドなど）をプログラムのような形でファイルに記述しておき、そのファイルの内容を実行するという機能が備わっています。このファイルを「シェルスクリプト」と呼びます。

「スクリプト」とは「台本」という意味です。つまり、予めシェルスクリプトという「台本」を用意しておき、その台本に則った操作を行える、というわけです。シェルスクリプトは「シェルを言語としたプログラム言語」という言い方もできます。

シェルスクリプトでは、変数や条件判定など、さまざまなプログラミング的なテクニックが利用できます。つまり、毎回同じ操作を行うだけではなく、状況に応じて処理を変えたり、ユーザからの入力を促す、数値計算を行うなど、一般のプログラミング言語と同じようなことがシェルを利用して実現できます。

Linuxでは、システムを動作させるためにシェルスクリプトを多用しています。
たとえば、ブート時の処理やログの管理などにシェルスクリプトを利用しています。ですから、Linuxを本格的に管理・運用するためには、シェルスクリプトの理解が必要になります。シェルスクリプトを勉強することは、シェルスクリプトとシステム管理の両方の理解につながるので、一石二鳥。
それほど難しくはないので、是非チャレンジしてみましょう。

まずは/etc/init.dディレクトリに格納されている各種サービスを起動するためのスクリプトの内容をチェックしてみるとよいでしょう。

『シェル』

今回は、「シェル」について。

「シェル」とは実体が見えにくいので、意外と理解しづらい概念かもしれません。最近のLinuxディストリビューションはほとんどがデフォルトでX Window Systemによって操作できるため、余計「シェルって何だ？」というのが見えづらくなっています。

UNIX系OSで言うシェルとは、「OSのカーネルとユーザを結びつける、コマンドラインインターフェイス」を指します。コマンドラインインターフェイスというのは、マウスを使わず、キーボードからコマンドを入力し、「文字」でやりとりするインターフェイスのことです。すなわち、シェルは、カーネルとユーザが文字で入力・出力を行うためのプログラムです。

X Window Systemが起動しているところからCtrl+Alt+F1キーを押すと、テキストベースのログイン画面が現れます。この画面でユーザ名とパスワードを入力すると、シェルが起動します。シェルが起動すると、プロンプトが表示されます。このプロンプトに続けてコマンドを入力すると、さまざまな操作を行うことができます。このとき、ユーザのコマンドをカーネルに伝え、またカーネルからの実行結果をユーザに伝えるのが、シェルです。ちなみに、シェルは、X Window Systemの「GNOMEターミナル」などを起動したときにも動作します。

Linuxを使いこなすためにはシェルの理解が欠かせません。シェルから様々なコマンドを実行することでできることも多いからです。デスクトップ環境などでさまざまなツールが用意されており、シェルを使わなくてもさまざまな作業ができるようになってはいますが、シェルを使ってコマンドを入力し、Linuxを操ることができるようになれば、さらにいろいろなことができるようになります。

また、インターネットサーバでは、セキュリティの観点からX Window Systemが利用できないようになっているケースもあります。このような場合、シェルが使いこなせないとサーバを操ることは不可能に近くなります。

シェルは思ったほど難しくありません。キーボードで全てを操るのであると割り切れば、あとは練習あるのみです。果敢にアタックしてみて下さい。

補足ですが、「シェル」にはもう一つの意味があります。ユーザがカーネルに指示を与え、またカーネルからの結果をユーザに伝えるプログラムは、コマンドラインベースでなくてもすべて「シェル」と呼ぶこともできます。
この場合、X Window Systemのアプリケーションなどもシェルとして捉えることができてしまいます。とはいえ、Linuxで「シェル」と言った場合はほとんどが「コマンドラインベースのインターフェイス」を指す、と思って構わないでしょう。

『デスクトップ環境』

今回は「デスクトップ環境」について。

前回、X Window Systemについて取り上げましたが、X Window Systemとデスクトップ環境の違いは意外と見えにくいですね。少し考えてみて下さい。

X Window Systemは、GUI環境を提供するソフトウェアあるいはプロトコルのことを指すのでした。これに対し、「デスクトップ環境」は、ツールバーやアイコン、ウィンドウマネージャ、ファイルマネージャなど、様々なソフトウェアをまとめたGUIソフトウェア群ということができます。言い換えると、そのまま「デスクトップ作業を行うのに必要なソフトウェア群をまとめたもの」とも言えるでしょう。

デスクトップ環境で有名なものは、「GNOME」「KDE」などがあります。最近では、使っているデスクトップ環境がGNOMEだとかKDEだとか、そういったことを意識させないような造りになっているLinuxディストリビューションも数多く見られます。これは、UNIX系向けのデスクトップ環境の多くが、柔軟なカスタマイズができるように作られているためです。この特徴を生かして、自分が使いやすい、好みのデスクトップを作り出すことすらできるわけです。

さて、これらのデスクトップ環境ですが、動作させるためにはやはり「X Window System」が必要になります。X Window Systemの上でデスクトップ環境が動作しているとも言えるのです。普段はデスクトップ環境とX Window Systemの違いをあまり気にしなくても良いのですが、時にはこういったことにも目を向けてみるとよいと思います。

『X Window System』

今回は、「X Window System」について。

X Window Systemは、UNIX系OSにてウィンドウシステムを提供するソフトウェア、あるいは仕組みを指します。LinuxにおいてGUI環境を利用する上で欠かせないものとなっています。

X Window Systemは、マサチューセッツ工科大学の研究グループにおいて生まれ、現在ではX.Org Foundationが開発の中心を担っています。現在のバージョンは「X11」（version 11）です。

さて、ここまではご存知の方も多いかと思いますが、X Window Systemにおいて意外と知られていないのが「サーバー・クライアントシステムを採用している」点です。このため、ネットワーク越しにX Window Systemを利用することが可能です。
たとえば、あるコンピュータで走らせているアプリケーションを、ネットワーク経由でリモートの画面に表示させることもできます。

ここからが紛らわしい話になるのですが、X Window Systemにおいては、ユーザが利用しているコンピュータで「Xサーバー」が動作しており、これがさまざまな「クライアント」と通信します。クライアントは、Webブラウザなどのアプリケーションです。すなわち、多くのサーバー・クライアントシステムと逆で、「ユーザが操作しているのがサーバ、リモートで動作するのがクライアント」となります。なぜこうなるかというと、X Window Systemの「機能を提供する」のが「サーバー」であり、その機能が、ユーザが操作する側に存在するためです。

知っているようで知らないX Window System、意外なほど奥が深いのです。

『続・アーキテクチャ』

前回、「コンピュータの内部構造」として、「アーキテクチャ」という用語を紹介しました。今回は、アーキテクチャの中でもとりわけ良く聞くであろう「i386アーキテクチャ」およびそれに続くものとして「i486」「i586」といったアーキテクチャについても紹介します。

Linuxをインストールする際、「よくわからないけれどi386というアーキテクチャは良く聞くな」という方も多いでしょう。そのため、「自分のPCのアーキテクチャはi386アーキテクチャなのだ」と誤解するケースもあります。しかし、現在i386を利用している人はごく僅かです。

i386のiは、「Intel」の頭文字です。そして、i386は、なんと1985年に発表されたアーキテクチャです。ですから、今i386のコンピュータを利用している人は・・・20年近く同じPCを使い続けていることになります。

実はi386のCPUは正式には「80386」と呼ばれます。そして、80386の前には8086、80286があり、80386の後には80486が発表されています。80386というのは、実は「80x86」と呼ばれるシリーズの一つという位置づけなのです。
この「80x86シリーズ」は、いわゆる「パーソナルコンピュータ」として世に広がったPCの多くに採用されています。

※8086の後に80186というCPUも存在していましたが、PCでの採用は少なく、あまり一般的ではありません。

そして、i386は「80x86シリーズ」の中で、初の32bit CPUなのです。
更に、Linuxの誕生は、このi386で達成されたのです。

その後、x86シリーズは進化を遂げ、80486へ受け継がれます。その後は・・

実は公式には80586というCPUは存在しません。商標の問題から、80486の後継は「Pentium」、その後継は「Pentium Pro/Pentium II/Pentium III」となります。しかし、これらは80x86の流れを汲むものですから、Pentiumを「俗称」で「i586」、「Pentium Pro/Pentium II/Pentium III」を「i686」などと呼びます。

さらにPentium IIIをベースとしたXeonもi686に含まれます。この後はさまざまなアーキテクチャが発表され、i786と「俗称」されるものはどれなのか？はいくつかの議論がありますが（Pentium 4をi786と呼ぶことが多いようですが）、もはやi786やi886という名前はほとんど使われていません。

しかし、基本的にこれらのアーキテクチャはi386の流れを汲んでいるので、「i386向けOS・アプリケーション」も動作するのです。IA-64など、特に64bitアーキテクチャではi386向けアプリケーションは動作しないことが多いので、「とりあえずi386」という認識は少し危ないと思っておいたほうがよいですが、普通のコンシューマ向けPCであれば「i386」向けのアプリケーションが動作する、と考えてよいでしょう。

『アーキテクチャ』

今回は、「アーキテクチャ」という用語について。

PCに関する文書などで、「x86アーキテクチャ」などというフレーズに出会ったことがある方も多いのではないでしょうか。しかしこの用語、わかったようなわからないような・・・そんな感想をお持ちの方もおられるでしょう。

アーキテクチャ・・・英語で「architecture」のこと。これには「建築」、「建築様式」、「構造」といった意味があります。実はアーキテクチャという用語自体は、いろいろな分野で使われている「構造」という意味合いの用語だ、ということができます。

そして、さらに実はコンピュータの世界でも「アーキテクチャ」と言った場合、いくつかの使い方があるようです。ソフトウェアの設計に関しても「アーキテクチャ」という用語が使われますし、ハードウェアに関しても「アーキテクチャ」という用語が使われます。使われ方が多岐に渡るため、一概にはいえませんが、前述の「構造」や「設計様式」といた意味では概ね共通しているようです。

さて、「x86アーキテクチャ」というのは何を指すのか・・・「x86」は、コンピュータの頭脳とも呼べるCPUの一種です。そして、「x86アーキテクチャ」と言った場合、x86 CPUを中心としたハードウェアの構成のこと、と言えるでしょう。要するに、CPUだけではコンピュータは動作しませんし、CPUによって、どのようなハードウェア構成にするか（どのようなマザーボードを使えばよいのか？どのようなメモリを使えばよいのか？などなど）が変わってきます。このハードウェアの設計全体を「アーキテクチャ」と呼ぶ、と考えればよいでしょう。

（ハードウェアの）アーキテクチャという用語がよく出てくる理由は、ソフトウェアも「ハードウェアのアーキテクチャによって変わってくるから」ということができます。すなわち、同じソフトウェアでも、あるアーキテクチャに対してのみ動作し、ほかでは動作しない、あるいは動作するが最適化されていない、という事態が考えられるわけです。このような事情があるので、現場では、扱おうとしているコンピュータがどのアーキテクチャなのか？といったことは、必ず把握しておく必要が生じることになります。

『小型モバイルPC』

今回は、ニュースでも取り上げた「小型モバイルPC」について。

最近は、日本の量販店でもよく目にする小型のモバイルPC。小型で軽く持ち運びやすいだけでなく、価格が安いという特徴もあります。また、省電力機能が充実しており、バッテリーが長時間持続するという工夫も施されています。ただし、サイズが小さいため、長時間の作業を行うにはあまり向かないかもしれません。

さて、この小型モバイルPC、ニュースのコメントでも述べたように、外国ではOSにLinuxを搭載したものも多く流通しています。その要因の一つに「コスト削減」があります。

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

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

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

『カーネル（kernel）』

前回は、Linus Torvalds氏についてのお話しでした。今回は、そのLinus Torvalds氏が開発した「カーネル（kernel）」についてです。

Linux kernelという言葉はよく耳にすると思います。しかし、「じゃあkernelって何？」と聞かれると、意外と答えられないと思います。では、kernelとは何か？「kernel」とは「中核」という訳語が当てはまりますが、簡単に言えばその通り「Linuxの中核となるプログラムがLinux kernelです」となります。そして、これはよく言われることですが、厳密には「Linux」と言った場合、このLinux kernelのことを指します（最近では、後述する「Linuxディストリビューション」をLinuxと呼ぶケースも増えてきています）。

さて、そのLinux kernel、「OSの中核となるプログラムです」と説明してもいまひとつピンと来ないかもしれません。具体的に何をやっているのか？というと、「ハードウェアを稼動させる指示を出す、もっと具体的には、メモリー管理、ファイルの管理、デバイスドライバとしての役割、プロセスの管理」などを担っています。例えて言えば、「ユーザからの指示に従ってハードウェアを稼動させる"頭脳"の役割を担っている」、という言い方ができるでしょうか。

さて、OSの中核を担う大切な大切なカーネルですが、カーネルだけではOSは動作しません。人の体が、脳だけでは動かないのと同じです。必要なものの一つが「インターフェイス」です。インターフェイスとは「仲介役」のことで、人の体で例えると神経に当たるでしょうか。「ユーザーインタフェイス」といえば「ユーザーとカーネルの仲介を行うプログラム」のことを指します。ユーザインタフェイスによって、ユーザの指示がカーネルに反映され、またさまざまな処理の結果がユーザに返ってくることになります。

Linuxディストリビューションとは、Linuxカーネルと、ユーザインターフェイスなどさまざまなプログラムをひとまとめにし、OSとしてユーザがすぐに使えるようにまとめたもののことを指します。初学者は、ほとんどの場合、このLinuxディストリビューションを入手して、Linuxを利用することになります。カーネルだけをOSとして動作させることはできません。もちろん、自分で他のアプリケーションを入手するなり自作するなりして・・・ということを行えばできますが、「カーネルだけを使って」というのは不可能だと思ってよいでしょう。

『Linuxの産みの親　Linus氏』

さて、今回は新年一回目ということで、このLinus氏についての簡単な紹介をしてみたいと思います。

Linuxの産みの親にして、現在でもLinuxカーネル開発の最終調整を担う人物が「Linus Torvalds」（リーナス・トーバルズ）氏です。「Linux」という名前自身が、Linus氏の名前から取られています。

Linus Torvaldsは、1969年12月生まれ、フィンランド出身のプログラマー。そして、そのLinusがLinuxの始祖となるプログラムを開発したのは、彼がフィンランドのヘルシンキ大学在学中のこと。Linusは、当時PCにおいて主流だったIntel i386コンピュータで動作するUNIX互換のOSの必要性を感じ、Linuxの開発に着手。Linuxの開発といっても、それはLinusの自宅で、しかも趣味として始まったものだと言われています。

Linuxが成長を遂げるきっかけになったのは1991年、LinuxがFTPサーバにアップロードされ、さまざまなプログラマーに公開されたこと。当時はまだ現在のように誰でも使えるというものではなく、腕の立つなプログラマーたちが利用できるOSでしたが、多くのプログラマーの手によって進化し、現在のような姿になっていったのです。

Linuxが進化した要因はいくつかありますが、そのうちの一つがLinusの「趣味」から始まっているという点にあるでしょう。趣味だったからこそ、さまざまなプログラマーの協力を広く得ることができ、大きく発展していくことができたのです。

Linus氏は、最近では「積極的にLinuxカーネルのコードを書く」作業は行っていないと言われますが、Linuxカーネルに新たなコードが追加される際の最終決定は彼の仕事になっています。

『ポートを塞ぐ』

前回は、ポート番号について取り上げました。今回は、「ポートを塞ぐ」というお話しです。

良くセキュリティ関係の書籍などを見ると「余計なポートは開けてはいけない」と言われますが、ではポートはどのように塞げばよいのでしょうか？

実は、ポートの塞ぎ方については大きく分けて二つの方法があります。

一つは、「アプリケーション側の対応を行う」です。そもそも、「ポートが開く」とはどういうことなのかを考えてみましょう。たとえば、ApacheなどのWebサーバアプリケーションを起動すると、（特別な設定をしない限り）Well known portsである80番ポートが開き、80番ポートでの通信の待ちうけを開始します。

これを考えると、サーバアプリケーションを停止すれば、自動的にポートが閉じます。「余計なアプリケーションを起動してはいけない」というお話しにつながりますね。

もう一つは、「通信を制限する」という方法です。代表的なのが「パケットフィルタリング」という手法です。パケットフィルタリングを利用すると、特定のポートの通信、特定のIPアドレスの通信をシャットアウトすることができます。Linuxでは「iptables」というコマンドによってパケットフィルタリングを行うことができます。iptablesコマンドを利用すると、どのような通信を遮断するのかなどを細かく指定できるので、「あるホストから、特定のポートを遮断する」といったこともできます。

どのポートが開いているか？を調べるには、「netstatコマンド」「lsofコマンド」「nmapコマンド」などのコマンドがあります。ここではそれぞれのコマンドについての詳細は割愛しますが、netstatとlsofは「自分がどのポートを開けているか？」を知るために、nmapは「他ホストがどのポートを開けているか？」を知るために使われます。パケットフィルタリングを施した場合、netstatやlsofではポートが空いているように見える場合もあるので注意が必要になります。

『「ポート」と「ポート番号」』

今回は、「ポート」と「ポート番号」について。

よく、「80番ポートが開いている」などという言い方がされますし、セキュリティ上「余計なポートは開けないようにしましょう」とも言われます。さて、このポートあるいはポート番号とは何者でしょう？

まず、「ポート」とはTCPやUDPで使われる概念で、よく「窓口」に例えられます。また、「ポート番号」は「窓口番号」に例えることができます。例を挙げましょう。たとえば郵便局へ行って振り込みを行うとき、どの窓口でも振り込みが行えるわけではなく、ある特定の窓口でのみ振り込みを受け付けています。そして、窓口には番号がついていますね。

ポート番号もこれと似たものだと考えるとよいでしょう。たとえば、WebサーバがHTTPによる通信を受け付ける際は、Webサーバの80番ポートを通じて通信を行います。同じようにSMTPは25番ポート、SSHは22番ポートを通じて通信を行います。ポートは「通信の窓口」と考えるとよいでしょう。

ちなみに、クライアント側もポートを利用して通信を行います。ただし、サーバ側のポート番号は大抵決まっていますが、クライアント側のポートは通信の度に変わるケースがほとんどです。

さて、サーバ側のポート番号は「決まっている」と書きましたが、実はやろうと思えば所定のポート番号以外で通信を行うこともできます。しかし、「あるサーバでは25番ポートでHTTPを受け付け、あるサーバでは80番ポートでHTTPを受け付ける」のように、サーバごとにばらばらなポート番号を利用しているようでは、当然混乱を招きます。そのため、サーバが利用するポート番号はある程度決まっています。これを「Well known ports」と呼びます。そして、ほとんどのサーバでは、所定のWell known portsを利用して通信を行っています。前述の「SSHサーバは22番ポート、HTTPサーバは80番ポート」がWell known Portです。

Well known ports  0-1023
Registered ports  1024-49151
Dynamic and/or private ports 49152-65535

ちなみに、Well known portsの管理は、「Internet Assigned Numbers Authority (IANA）」という組織が行っています。IANAは、Well known portsの管理のほか、IPアドレスやドメイン名の標準化などに取り組んでいます。

『エイリアス』

「エイリアス」という言葉は、実は色々な場面で使われます。たとえば、「コマンドのエイリアス」「メールアドレスのエイリアス」など。ですから、一言「エイリアス」と言った場合、場面場面でそれが指すものは変わってきます。

ですが、意味としてはどれも似たものを指します。
エイリアスとは英語で「alias」と書き、日本語訳すると「別名」という意味になります。
「メールアドレスのエイリアス」といった場合も、別名の意味合いが出てきます。
たとえば、「foo@example.com」というメールアドレスのエイリアスに「bar@example.com」を設定しておくと、bar@example.com宛のメールはfoo@example.comに届くようになります。この例のように、何かの「別名」を「エイリアス」と呼びます。

Linuxでよく出てくるのは、メールアドレスのエイリアスのほか、コマンドのエイリアスです。Linuxなど、UNIX系OSではコマンドにエイリアス（別名）をつけることができます。

そんなものが何の役に立つのか？ということですが、コマンドのエイリアスでは、「オプションも含めて別名をつけることができる」という点が便利な点です。たとえば、「ls -al」をよく実行する場合に備えて、これにエイリアスをつけることができます。

エイリアスをつけるには、「alias」コマンドを使います。「ls -al」に「ll」というエイリアスをつけるには、以下のように実行します。

$ alias ll='ls -al'

これで、プロンプトに「ll」と入力すると、ls -alに読み替えられて実行されるようになります。コマンドエイリアスの便利なところは、エイリアスに更に引数をつけても、その引数が有効になるという点です。

たとえば、上のようなエイリアスをつけた上で、

$ ll /etc/

と実行すると、

$ ls -al /etc/

を実行したのと同じことになるのです。

ログインするたびにエイリアスをつけるためには、ホームディレクトリの.bashrcファイルの末尾に、

alias ll='ls -al'

などのような記述を追加しておきます。これで、ログイン時にaliasコマンドが自動的に実行されます。

また、現在設定されているエイリアスの一覧を見るには、aliasコマンドを引数なしで実行します。実はLinuxでは（ディストリビューションによりますが）デフォルトでエイリアスがついていることが多いので、一回見てみるとよいでしょう。

$ alias
alias l.='ls -d .* --color=tty'
alias ll='ls -l --color=tty'
alias ls='ls --color=tty'

『TCP/IP』

前回は、「プロトコル」のお話しでした。その続きで、「TCP/IP」のお話しをしたいと思います。

ここでのテーマは、「TCP/IPって何？」です。TCP/IPそのものの解説をするのではなく、TCP/IPが何を意味し、どこで使われているのか？にスポットを当ててみます。これは、意外と触れられていない事項です。

TCPやIPは、前回も紹介したように、プロトコル、すなわち通信のときの決めごとです。では、「TCP/IP」は？誤解されやすいのですが、TCP/IPは単独のプロトコルではなく、「プロトコルの集合体で、現在インターネットなどのネットワークで、標準として利用されているもの」です。

前回も少し触れたのですが、１つのプロトコルだけで通信は行えません。
いくつかのプロトコルを利用してはじめて、通信を行うことができるのです。
もっと言うと、現在のインターネットにおける通信のほとんどは、HTTPなどのプロトコルとTCP/IP、そしてネットワークでデータの送受信のしかたを既定したプロトコルを組み合わせて行われています。

TCP/IPの他にも、通信を行うためのプロトコル群というのは一応存在するのですが、現在インターネットではほとんどの通信がTCP/IPを利用して行われています。

ちなみに、TCP/IPの「IP」とはInternet Protocolのこと。インターネットにおいて情報の送受信を司るプロトコルであり、正しいホストへパケットを届ける役割を担っています。「TCP」は、データをインターネットへ送るために加工したり、逆に受信した加工済みデータを元に戻したり、といった役割を持ちます。同じような役割を担うプロトコルには、TCPのほかにUDPなどがあり、状況によって適切に使い分けられます。なお、UDPなどのプロトコルも「TCP/IP」に含めるケースが多いようです。

詳細はともかく、「TCP/IPという独自のプロトコルがある」という誤解は、どうしてもしてしまいがちです。勉強するときには、この点をまず頭に置いてください。

『プロトコル』

今回は、サーバやネットワークの理解に欠かせない「プロトコル」のお話しです。

「プロトコル」（protocol）には、「決めごと」という意味があります。
実はプロトコルの意味は広いのですが、通信で「プロトコル」というと、「通信を行う際、どのような状況で、どのような順番で、どのようなデータをどのようにやりとりするのか」といったことが決められています。

抽象的でわかりにくいかもしれません。例を挙げましょう。Web上でHTML文書をやりとりする際に使われるプロトコルに「HTTP」（Hyper Text Transfer Protocol）があります。このプロトコルでは、要するにサーバとクライアントがHTML文書をやりとりする際の決めごとが定められているのです。たとえば、クライアントがWebサーバに接続した後、クライアントからサーバに

GET /

と送信すると、WebサーバはサーバのルートにあるHTML文書を送信する、というように決められているのです。このような取り決めの集合が「プロトコル」です。

当たり前のことですが、この取り決めはインターネットどこへ行っても共通です。すなわち、「プロトコル」というのは、「共通の決めごと」であると言い換えることもできます（ただし、バージョンによる相違などがある場合もあります）。

さて、インターネットの通信に使われるプロトコルには、HTML文書のやりとりを行う「HTTP」、メールの送信を行う「SMTP」、ファイルの転送を行う「FTP」の他に、1対1でのデータ伝送を行う際に用いられる「TCP」、インターネットでのデータ伝送プロトコル「IP」など、さまざまなプロトコルがあります。そして、多くのプロトコルは名前が「P」で終わっており、名前からプロトコルであることが想起できるようになっています。

ところで、たとえば「インターネット経由でWebサイトを閲覧する際に使われるプロトコル」は、HTTPなのかTCPなのかIPなのか？どれなのでしょうか。答えは・・・「通常HTTPもTCPもIPもすべて使われる」です。通信は一つのプロトコルのみで成立しているのではなく、複数のプロトコルが組み合わせて使われるのです。このあたりは、初学者が混乱しやすいところです。

『ワンCD Linux』

今回は、「ワンCD Linux」について取り上げてみたいと思います。

ワンCD Linuxは、インストールをしなくても、CD-ROMからブートすれば利用できるLinuxのことを言います。有名なものにKNOPPIXがありますが、Puppy Linuxなどのディストリビューションもありますし、最近ではFedoraやGentooといったディストリビューションにも「Live CD版」あるいは「Live DVD版」といった形で、「インストールなしで利用できるLinux」が配布されています。

さて、このワンCD LinuxあるいはLive CDですが、どのようなメリットがあるのでしょうか？基本的にCD-ROMをセットしてブートすればLinuxが利用できるようになりますから、「評価用途に最適」というメリットが一つ、すなわち「このLinuxはどんなLinuxなのか」ということがわかります。そして「手軽」というメリットが一つ。すなわち、いつもは他のOSで利用しているPCで、簡単にLinuxが利用できます。更に、「外出先でLinuxが利用できる」などの応用も考えられます。また、カスタマイズすれば、「自分専用の環境を、他のPCでも実現できてしまう」という使い方もあります。

しかし、ワンCD Linuxには意外な使い方もあります。それは、「レスキュー用途」。すなわち、システムがトラブルで起動しなくなったときに、そのPCをワンCD Linuxで起動させるという使い方ができます。こうすれば、まずはハードディスクドライブに取り残されたデータを救済することができますし、さらに応用すればトラブルの修復さえできてしまうのです。

意外と馬鹿にならないワンCD Linux（Live CD）。Linuxを利用するからには、是非覚えておきたいものです。

『プロンプト』

今回は、「プロンプト」について解説します。

bashなどのシェルは、Linuxを操作する上で欠かせないものです。そのbashにおいて「プロンプト」は重要な役割をします。「prompt」には「促す」という意味があり、その名の通りシェルがユーザにコマンドの入力を促すのがプロンプトです（以下、今回はシェルにbashを利用するものとして進めます）。

さて、最近のLinuxディストリビューションは、プロンプトが

[user@host001 /etc]$

のように表示されるようになっています。上の例では、「ログインしているユーザ名」「ホスト名」「カレントディレクトリ」などが表示されます。このように、コマンドの入力を促すと同時に、ユーザに役に立つ情報を表示するのです。

プロンプトに表示される内容は、カスタマイズすることができます。ユーザ名やホスト名、カレントディレクトリのほか、時間、日付、コンソール番号、接続時間などさまざまな情報を表示させることが可能です。逆に、セキュリティに配慮して、「$」や「#」のみにすることもできます。

具体的な設定の詳細については省略しますが、プロンプトの表示を変更するには、シェル変数「PS1」を変更します（コマンドが複数行に亘る際にはPS2に設定されたプロンプトが表示されます）。たとえばシェル変数PS1に、

PS1='\$ '

と設定すると、余計な情報を一切表示せず、$マーク（rootユーザのときは#マーク）のみがプロンプトとして表示されることになります。ちなみに先ほど紹介した「[user@host001 /etc]$ 」のようなプロンプトを表示するには、PS1に

$ PS1='[\u@\h \w]\$ '

と設定します。

さて、PS1変数はログイン後に変更することもできますが、ログインする時に表示するプロンプトを設定するには、ホームディレクトリにある「.bashrc」ファイル（シェルにbashを利用する時）の末尾に、その設定を記述しておきます。具体的には、.bashrcファイルの末尾に

export PS1='[\u@\h \w]\$ '

を追記すれば、次回ログイン時からこのプロンプトが利用できるようになります。

『パスを通す』

今回は、「パスを通す」という話です。ちなみに、この時の「パス」は、「コマンドサーチパス」の略称です。

Linuxでは、コマンドを実行する際には、本来「/usr/bin/passwd」のように、フルパス、すなわちコマンドがあるディレクトリまですべて含めてコマンドを指定してやる必要があります。しかし、よく使うコマンドでいちいちフルパスを指定するのはあまりに面倒ですね。

そこで、Linuxのシェルは、ユーザがコマンドをフルパスで指定しなくても、そのコマンドを、ある特定のディレクトリに対して探しにいくようになっています。このとき、シェルが探しに行くディレクトリを設定する作業を、「パスを通す」と言います。正確には「コマンドサーチパス」、すなわちコマンドを探しにいくパスの設定をする、ということですね。

パスを通すためには、環境変数「PATH」に対して、通したいパスを「:」記号区切りで指定します。この設定には、先週紹介した「export」コマンドを利用します。たとえば、現在の設定に加えて「/usr/sample」というディレクトリにもパスを通したい場合は、次のように実行します。

$ export PATH=$PATH:/usr/sample

さて、Linuxでは「カレントディレクトリ」にパスが通っていません。このため、たとえばカレントディレクトリの「hogehoge.cmd」というコマンドを実行する場合、「./hogehoge.cmd」のように指定してやる必要があります。少々面倒なのですが、では「カレントディレクトリにパスを通せばよいではないか」というと、これはセキュリティ上問題があり、やってはいけないとされています。

まず、セキュリティの大原則に、「余計なディレクトリにパスを通してはいけない」というものがあります。これは、パスを通しすぎると、たとえば2箇所に「ps」というファイルがあった場合、どちらのファイルが実行されるのか・・・混乱します（実際には、PATH変数の、より先頭に指定されたパスが優先されます。が、ユーザは混乱しますね）。

ここでカレントディレクトリにパスを通すとどうなるか。

極端な話、ユーザはほとんどのディレクトリをカレントディレクトリにすることになってしまいます。つまり、どのディレクトリもコマンドサーチパスになり得てしまいます。こうなると、混乱を招くだけでなく、「悪意のあるプログラムが置かれていた場合、意図せず実行される危険が極めて高くなってしまう」のです。通常、一般ユーザが出入りすることができるディレクトリは限られており、そのディレクトリにパスを通さないことでシステムを守っているのですが、一般ユーザでも出入りできるディレクトリにパスを通してしまうと、悪意のあるコマンドを仕掛けられた時に攻撃されてしまう危険性が大きく増してしまうのです。

コマンドサーチパスは、「便利だから」という理由であれこれ指定せず、安全なディレクトリに絞って指定することが大切です。

『環境変数』

今回は、「環境変数」についてです。

変数とは、プログラムなどにおいて、メモリなどに用意する「データを記憶しておく箱のようなもの」ということができます。すなわち、プログラムは変数に値を記憶させ、変数の中身を参照することによって、さまざまな計算などの処理を行うことになります。

「環境変数」も変数の一種です。普通の変数とどこが違うか？というと、「普通の変数はそのプロセスでのみ有効、環境変数は他のプロセスと共有できる変数」と言えます。Linuxのシェルで言うと、「シェルが呼び出した子プロセスでも利用できる変数」が環境変数です。

環境変数の名前は、大文字のアルファベットを利用するのが通例となっています。実は小文字で変数名をつけても構わないのですが、環境変数であることを示すためにも大文字で設定するのがよいと言えます。

さてこの環境変数ですが、システムの挙動を決定するものがあります。
たとえば、「PS1」という環境にはコマンドプロンプトに表示する文字列を決定する値を格納します。プロンプトに表示する文字列を変更したい場合は環境変数PS1の値を変更すればよいのです。また、コマンドの履歴をいくつ保存しておく「HISTSIZE」変数や、パスを指定する「PATH変数」など、さまざまな環境変数があります。環境変数を変更することにより、システムを使いやすいものにカスタマイズすることもできます。ただし、環境変数の中にはシステムの動作に重要な役割を担っているものもあるため、無闇に変更すると誤動作の原因となることもあるので注意して下さい。

環境変数を操作するコマンドは、「export」コマンドです。exportコマンドを引数なしで実行すると環境変数の一覧が表示されます。また、通常の変数を環境変数に昇格させるためには「export $変数名」のように、環境変数を設定すると同時に値を格納するには「export $変数名＝値」のように実行します。

環境変数およびexportコマンドは、Linuxを管理する上でも重要なものですから、しっかり理解しておきましょう。

『パーティション』

Linuxをインストールする際、ハードディスクのパーティションを作成します。さてこの「パーティション」とは一体何でしょうか？

「パーティション」は、日本語で「仕切り」を意味します。コンピュータの用語で「ハードディスクにパーティションを作成する」と言うと、その名の通りハードディスクに仕切りを設けることを言います。もっとも、多くの場合は「ハードディスクにパーティションを作成する」などという場合に用いられる「パーティション」とは、仕切られてできたハードディスクの「分割されてできた個々の領域」を指すことが多いのが現状です。ハードディスクをパーティショニング（パーティションに区切ること）すると、１つのハードディスクをあたかも複数のハードディスクがあるかのように扱うことができます。

さて、Windowsをインストールする際にはパーティションを作成しないことも多いのですが、Linuxをインストールする際にはパーティションを作成することがほとんどです。では、パーティションを作成する目的は一体何でしょうか？

パーティションを作成することには、実はいくつかの目的があります。もっとも理解しやすい理由は、「あるパーティションに何らかのトラブルが生じ、データが消失するなどしても、他のパーティションにはトラブルが波及せずに被害を小さく抑えることができる」というものです。例えば、システム領域とデータ領域を分けておけば、システム領域に何かのトラブルが起こっても、データを置いておく領域が別のパーティションになっていれば、データをトラブルから守ることもできるのです。また、再フォーマットが必要になった際、トラブルが起きたパーティションのみをフォーマットすることができ、他のパーティションをフォーマットせずに済む、というメリットもあります。

他にもメリットがありますが、Linuxの場合はメモリのデータを一時的に保存しておく「スワップ領域」が必要となり、このスワップ領域は独立したパーティションとして作成する必要があるという事情があります。

このように、いくつかの事情がある「パーティショニング」ですが、一旦パーティショニングを間違えると修正することが（できないわけではありませんが）困難なので、Linuxをパーティションを作成するときには注意が必要です。よくあるトラブルに、「パーティションを作成したら、あるパーティションだけ空きがなくなってしまった！」というものがあります。ちなみに、どのようにパーティショニングするのがベストなのかは、「どのディストリビューションを利用するのか？」「どのようなハードウェア構成でLinuxを利用するのか？」「どの用途で利用するのか？」などによって変わってきます。パーティショニングは十分計画して行いましょう。

『ファイルシステムの種類』

現在Linuxでは、「ext3」というファイルシステムが主流となっています。しかし、ファイルシステムにはそれ以外にも「ReiserFS」「XFS」「ZFS」などのファイルシステムもあります。ちなみにWindowsでは「NTFS」というファイルシステムが、CD-ROMでは「ISO9660」と呼ばれるファイルシステムが主流です。また、Linuxにおいてはext3の後継と言える「ext4」と呼ばれるファイルシステムも開発が進んでいます（kernel 2.6.19以降で利用可能）。

ところで、ext3やXFSなどのファイルシステムには、「ジャーナリング」と呼ばれるシステムが採用されています（ext3以前のext2ファイルシステムにはジャーナリングが搭載されていません）。このジャーナリングと呼ばれるシステムは、簡単に言うと、「ファイルに何らかの更新を施す際、前もってファイル更新の内容をジャーナルと呼ばれる領域にログとして記録した後に、ファイル更新処理を行う」というものです。ジャーナリングシステムの利点は、電源の供給が止まったなど、何らかの原因でファイル更新処理が止まってしまったときに発揮されます。OSが正常にシャットダウンされなかった場合、その後にOSをブートする時に、ジャーナルを参照してファイルシステムのチェックを行います。その際、ジャーナルとファイルの内容が矛盾していれば、そのファイルが正常に更新されなかったということがすぐにわかります。ジャーナルを見れば「どのファイルが更新されていない可能性があるか」がわかるため、ファイルシステム全体のチェックをする必要もなく、チェック時間も短くて済みます。

とはいえ、ジャーナリングシステムはファイルの内容を100％保証するものではありません。OSの異常終了はできるだけ避けるようにしましょう。

『クローン』

最近のディストリビューションで人気があるのが、ニュースでも新版のリリースを取り上げた「CentOS」です。CentOSはRed Hat EnterpriseLinuxのクローンと呼ばれますが、これはどういう意味でしょうか。

Linuxのディストリビューションの多くは、オープンソースソフトウェアで構成されています。インストールメディアはすでにコンパイルされているバイナリパッケージが含まれていますが、別途元になって使用されたソースコードも提供されています。クローンは、このソースコードから、独自にコンパイルを行って構成したディストリビューションの事を指します。

もちろん、完全に同じですと、商標権や固有の著作権に抵触してしまう場合があるので、そのような部分は表記を書き換えたり、データを入れ替えたりすることで、知的所有権を侵害しないようにしているので、100%同じというわけではありませんが、ソフトウェアとして見たときには機能は100%同じ状態のもの、と言ってもよいでしょう。

ディストリビューションは、それぞれファイル配置やコマンドの有無などに癖がありますので、Red Hat Enterprise Linuxに馴染んだ人が、気軽に使用するような場合に使用するディストリビューションとして、クローンに人気が集まるわけです。

『RAID』

最近では比較的有名な用語になってきたRAID。複数のHDDを組み合わせることで、信頼性を高める技術として知られています。

さて、そのRAIDですが、「RAID 0」「RAID 1」「RAID 5」などいくつかの種類があるのをご存知でしょうか？RAIDとしてもっともわかりやすいのはミラーリング（RAID 1）でしょう。ミラーリングは、複数台のドライブに同じ内容を書き込む技術で、片方のドライブが故障しても、もう片方さえ残っていればデータの損失が防げる、というものです。

さて、そのRAIDですが、「RAID 0」から「RAID 6」までの7種類の区分があります。先に述べたミラーリングの他に、RAID 0（ストライピング）、すなわち複数台のディスクに均等に分散させたデータを同時に読み書きすることで高速化を図る技術や、RAID 5、すなわちパリティというエラー検出符号を複数台のディスクに分散して記録するなどがあります。つまり、RAIDはミラーリングだけではないのです。ちなみに、たとえばRAID 0とRAID 1を組み合わせて利用する、などということもできます。

ところで、RAIDというシステムは、実は1988年に発表された論文の中で提唱されたシステムなのです。この論文の中では、RAID 1からRAID 5が提唱されています。RAIDには7種の区分があると書きましたが、パフォーマンスや信頼性などのメリットがRAID 5に比べて劣ることなどから、RAID 3とRAID 4は現在ほとんど使われていません。RAID 3とRAID 4が欠番のようになっているのは、このような事情があってのことなのです。

そのようなRAIDですが、最近ではハードディスクの価格も下がってきたこともあり、多くの人が利用しているようです。理解してしまえば難しい技術ではありませんし、比較的手軽に導入できる技術ですので、機会があれば試してみてはいかがでしょうか。

『モジュール』

moduleには、「交換可能な部品」という意味があります。Linuxでモジュールと言えば多くの場合カーネルに組み込むモジュールを指しますが、モジュールという概念はハードウェアやプログラミングなどの分野で広く取り入れられている概念です。今回は、例の一つとしてカーネルのモジュールを取り上げます。

カーネルのモジュールとは、簡単に言えば「メインとなるカーネルのプログラムに組み込んで使用する、小さなパーツのようなプログラム」といえます。すなわち、モジュールだけでは何もできません。カーネルに「取り付けて」利用するというイメージです。

モジュールが利用されるのは、たとえば新しいデバイスや新たな機能を追加するときに利用されます（デバイスに対するドライバはモジュールとして提供される、と考えるとよいでしょう）。このようなとき、対応するモジュールをカーネル本体に取り付けて利用します。これをモジュールとせずにカーネル本体に直接組み込んでしまうと、いつ、どのデバイスが必要になるかわかりませんから、多数のプログラムを付け加えることになり、カーネルのサイズが巨大なものになってしまいます。それだけでなく、メモリ消費量が非常に大きなものになってしまいます。また、新しいデバイスがリリースされ、これを利用したい場合、カーネルにプログラムを書き加えた上でコンパイルする必要が生じることになるので、大きな手間がかかります。

ここで「モジュール」を利用すると、必要なデバイスや機能だけを選択して組み込むことができますので、カーネルのサイズをコンパクトにできます。また、新しいデバイスや機能がリリースされても、カーネルをコンパイルし直す手間がありません。

このようにメリットの多いモジュールという仕組みですが、欠点がないわけではありません。そもそもモジュールにすることができない機能も数多くありますし、モジュールとするとパフォーマンスが落ちる、ということもあります。

モジュールを管理するコマンドとして「modprobeコマンド」があります。このコマンドは、モジュールをロード（取り付け）することができるコマンドです。モジュールには依存関係が存在するものがありますが、modprobeコマンドはこの依存関係をチェックしながらモジュールをロードするので、モジュールをロードする場合にはmodprobeコマンドを利用するのが良いでしょう。

『なぜセキュリティがインターネットで問題なのか？』

もちろん「悪用する人がいるからセキュリティに注意しなければならない」のですが、一方で「インターネット自体がセキュリティに配慮した作りになっていれば、ユーザがセキュリティの心配をしなくても良い」と考えることもできます。よく、「リモートホストと通信するときに、通信を暗号化しないtelnetを利用するのは避けましょう、通信を暗号化するSSHを使いましょう」と言われますが、そもそも通信を容易に盗み見できてしまう仕組みそのものに問題がある、という言い方もできます。

これは、インターネットの生い立ちに秘密があります。インターネットの前身は、「ARPANET」と呼ばれる、アメリカ国防総省が中心となって研究を行っていた軍事用通信ネットワークでした。このネットワークは、研究目的のため使う人はごく限られた人だけでしたから、そもそも「クラッカー」などの存在がありようもなかったのです。また、インターネットが発達しつつあった1980年台でも、ユーザは技術者や研究者しかいなかったため、やはりユーザに「悪い人」がいなかったのです（もちろん例外もあるでしょうが）。

インターネットが一般に広まってきたのは、実はせいぜいここ十数年。一般に開放されるにつれ、さまざまな人が入ってくるようになってきたため、悪用する人が出てきたのです。ARPANETの開発は1969年と30年近く前で、今のように、誰でも使えるネットワークに進化するなど、まったく想定されていなかったのです。つまり、生い立ちそのものが、「悪用されようがない環境の下で開発された」のです。

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

『「UNIX」「UNIX互換OS」』

よく、「LinuxとUNIXってどう違うの？」「LinuxはUNIXではないのか？」といった疑問をよく聞きます。結論から言うと、「LinuxはUNIXに倣って作られたOS」「LinuxはUNIXとは似て非なるOS」ということになります。

これには少し深い事情があります。そもそもUNIXというOSは、1970年頃にアメリカAT&T社のベル研究所が開発し、開発を推し進めてきたOSです。
現在、「UNIX」という商標はThe Open Groupが持っていることもあり、「LinuxはUNIXではない」と言うことができます。

一方で、もう一つLinuxが「UNIXでない」という理由があります。Linuxの生い立ちは、1991年、当時まだ学生であったフィンランドのLinus Torvalds氏が、当時高価であったUNIXの機能を実現しようと、ゼロから開発を始めたものなのです。すなわちLinuxは、元祖UNIXのコードなしで開発されたものです。つまり、プログラムとしては全く別物なのです。しかし、UNIXとよく似た機能を持ち、よく似た動作をするため、「UNIX互換OS」と呼ばれているのです。

http://www.unix.org/
http://www.opengroup.org/openbrand/register/

UNIXの詳細情報とUNIXとしての登録を受けている製品については、以下のサイトを参照してください（英語）。

『バージョン番号のつけ方』

OSを含め、ソフトウェアにはバージョン番号がついています。番号が大きくなるほど機能向上やバグフィクスが施され、新しくなっていることを表すのが一般的です。

バージョン番号のつけ方に、統一ルールはありません。ソフトウェアによってさまざまです。ほとんどの場合、バージョン番号を「X.Y」や「X.Y.Z」のように付けており、大幅な機能向上があった場合は「X」の数値を、微細な改変に留まる場合は「Y」や「Z」の数値を増やすことが一般的です。このため、「X」をメジャーバージョン番号、「Y」や「Z」をマイナーバージョン番号と呼ぶこともあります。

しかし、バージョン番号には別の意味があることもあります。たとえばLinuxカーネルのバージョン番号は、現在「X.Y.Z」のように番号をつけており、2008年4月20日現在で「2.6.24」が最新版です。一方、実はLinuxカーネル「2.5.75」というものもリリースされています。これは、いわゆる「開発版」と呼ばれるもので、安定性に関するテストが十分になされていない代わりに、先進的な機能がどんどん取り込まれています。Linuxカーネルのバージョン番号の「Y」の数値が偶数のものが一般向けの「安定版」であることを、奇数のものが開発者向けの「開発版」であることを意味します。このように、数値が意味を持っていることもあるのです。

また、たとえばUbuntuというディストリビューションは、バージョン番号を「Ubuntu 7.10」のようにつけています。これは、実は「2007年の10月にリリースした」ということを意味します。このように、バージョン番号の付け方はさまざまで、ものによってはバージョン番号から他の意味を読み取ることもできるのです。一方で、先日OpenSSH 4.9がリリースされて数日後にOpenSSH 5.0がリリースされました。今回の場合、「4.9」と「5.0」の間に大きな差はなく、セキュリティの修正のみに留まりました。このように、バージョンナンバー付加方法のポリシーはソフトウェアごとに異なりますので、注意が必要です。

『パケット』

携帯でメールやWebにアクセスできるようになってから、「パケット代」という言葉が一般化したせいか、ネットワークに詳しくない人でも知っている「パケット」という用語。さてこのパケットとは一体何でしょうか？

パケットとは英語でpacketと書きます。辞書で引いてみると、「小さな包み、小荷物」と書いてあります。パケットとは、インターネットで通信を行う際、やりとりするデータを分割したもの、ということができます。

大きなデータを送受信するとき、小さなデータに分割すると、データを送信する際にネットワークを独占することがありません。実際、複数の通信を同時に行おうとする際には、パケットが交互に送信されるため、１つの通信がネットワークを独占することがなくなり、同時送信が可能になるのです。
また、ノイズなどが入ってデータの送り損ねが出たとき、大きなデータのまま送ってしまうとデータを全部再送しなければなりませんが、パケットに分割しておけば、送り損ねたパケットだけを送り直せばよいので効率的、というメリットもあります。

「パケット」は、IPを利用した通信の基礎となるものです。ちょうど、先日リリースされた「Wireshark」（旧Etereal）などのソフトウェアを利用すれば、パケットを直接見ることも可能ですので、一度自分のPCがやりとりするパケットを実際に見てみてはいかがでしょうか。

『Linuxとウイルス』

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

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

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

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

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

『「Linux」と「ディストリビューション」の関係』

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

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

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

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

では、Linuxディストリビューションの数はどれくらいあるのでしょうか。

答えは、ほぼ無限と言えるでしょう。

ディストリビューター（ディストリビューションの配布者）は世界中に存在します。また、商用／非商用、サーバ用途／デスクトップ用途、ある機能に特化したものなどのように考えてもさまざまなものがあります。ディストリビューターが複数のディストリビューションを配布している例もあります。また、あまり知られていないディストリビューションもあるほか、最近ではLinuxディストリビューションの「自作」も流行っています。ですから、ディストリビューションの数は、まさに星の数といえるでしょう。

Linuxディストリビューションの自作。難しそうに聞こえますが、書籍なども出版されていて、皆さんが想像するほど難しくないと思います。機会があればチャレンジしてみてはいかがでしょう？

『Linuxのマスコットのペンギンは何者？』

今回は、Linuxのマスコットであるペンギンについてお話しします。

＃もちろん、試験には出ません。

Linuxのマスコットといえばペンギンですが、あのペンギンは一体何者なのでしょうか。あのペンギンは名前を「Tux」（タックス）と呼びます。税金を意味する「Tax」とは別です。

調べてみると、Wikipediaにも記述があります。
○Wikipedia: Tux（タックス）

Linuxカーネルがバージョン2になる時に、ロゴのデザインコンテストが行われ、あのペンギンが選ばれたわけです。その他の作品も含めて以下のサイトに候補作品が並んでいます。

○ロゴ候補

見てみると、いくつかのロゴには「Linux 2.0」の文字が見えるのが分かるかと思います。

Tuxは、Linuxカーネル起動時に画面に現れることがあります。これはLinuxカーネルがフレームバッファ（画像表示の仕組み）をサポートしており表示が行われています。Tuxの数はCPUの数を表しているので、たとえばPlayStation 3のLinuxのようにCPUを沢山識別するシステムの場合、大量のTuxが起動画面に並ぶことになります。

○PS3 Linux起動時に沢山並んだTux

『LinuxとCPUの互換性とは？』

Linuxは元々、インテル製のCPU「i386」で動作するPOSIX互換のカーネルとして開発が始まりました。それもあって、現在でもいわゆる「PC」で動作するLinuxが主流となっています。これらのPCを「IA（インテル・アーキテクチャ）」のマシンと呼んでいます。

IAは、名前にインテルと入っていますが、実際にはインテル製以外のCPUでも動作します。たとえばAMDはIA互換CPUを製造しているCPUメーカーとして非常に大きな企業ですし、その他省電力などを謳ったIA互換CPUは沢山出ています。それら全てをひっくるめて「IA」と呼んでいます。ですから、IAなマシンを用意すれば、その上でLinuxを動かすことは可能というわけです。

ただ、その時に注意しないといけないのが、「その1」の時に少し触れましたが、そのCPUがどの種類（世代）のCPUか、そして動かそうとしているソフトウェアがどのCPUに対応しているか、ということです。
一言でIAといっても、一番最初の「i386」に互換性を持つCPUもあれば、より機能が進化して「i586」や「i686」と呼ばれるCPUもあります。

特に問題になるのが前者で、最近のLinuxディストリビューションではi586以上を前提にしたLinuxカーネルしか入っておらず、IA互換CPUに多いi386互換CPUでは動作しない点です。
たとえば、インストーラーを動かすために使用しているLinuxカーネルはi386用でも、実際にインストールされるLinuxカーネルはi586以上でないと動かない、というようなことがあります。

最近、省電力CPUを採用した小型PCなどが流行していますが、そのようなマシンでLinuxを動かすときには、CPUの互換性に気をつけましょう。

『Linuxって何て読むの？』

そもそもLinuxって何て読むのか、を考えてみたいと思います。考えないといけないぐらい、Linuxの読み方は諸説紛々です。代表的な説として、以下のようなものがあります。

A) リナックス
B) リヌックス（リヌクスと短くする場合も）
C) ライナックス

まず、A説とB説に共通しているのが「Li」を「リ」と発音することです。これはLinuxの最初の開発者である Linus Torvalds氏の名前をカタカナ表記すると「リーナス・トーバルズ」とするあたりに由来しているのでしょう。

では「nu」をどう読むかです。Linux Onlineのページには"LIH-nucks"と説明されています。また、Linus Torvalds氏のスピーチの音声データがリンクされています。

http://www.linux.org/info/index.html
http://www.linux.org/info/sounds/english.au

聞いてみると、日本語のカタカナ表記では表現できない音、ちょうど「ナ」と「ヌ」の間ぐらい、あえて表記すれば「ヌワァ」（ヌは小さめ）ぐらいでしょうか。ということもあって、A説、B説ともにどっちが正しいとも言えないのが実情ではないでしょうか。

皆さんはどのように読んでいますか？廻りの人の呼び方も聞いてみると、面白いかも知れません。

『i386って何？』

今回は、色々なところで目にする「i386」という言葉についてです。
i386とは、CPUの種類を指しています。「アーキテクチャ」と呼び変えてもいいでしょう。今ではCPUの名前というと「Core 2 Duo」とか「Athlon」、あるいは「Xeon」や「Opteron」といったかっこいい名前で呼ばれるようになりましたが、Linuxが産声を上げた頃はCPUは重要なパーツではありますが一部品でしかなく、型番で呼ばれるものでした。

i386のiは、インテル(Intel)のiです。インテルが最初に生み出した4004から続くCPUの系譜の中で、386（80386）は初めて32ビットを取り扱えるようになったCPUです。

○参考：インテルミュージアム - マイクロプロセッサーの歴史

Linuxは、この386上で動作するPOSIX互換のカーネルとして開発が始められました。また、その後のCPUは基本的に386と互換性を持つ形で高速化などがはかられているため、Linuxやその上で動く各種プログラムは、386上で動作するようにコンパイルしておきさえすれば、多くのPC上で動作するというわけです。

ただし、386は1985年に生まれたCPUであるため、現在ではいささか古いということは否めません。そこでいくつかのディストリビューションでは、動作対象をPentium以降に絞っているものがあります。その場合、Pentiumを表す「i586」という名前がパッケージのファイル名などにつけられています。
また、現在のインテル系CPUはunameコマンドなどで調べると「i686」と表示されます。これはPentium Pro以降のアーキテクチャを示しています。

i586やi686が存在するならば、動作させるバイナリもきちんとCPUの種類に合わせた方が良いように感じられるかも知れませんが、実際にはCPUの種類に合わせたとしても、大幅な性能向上などは見られないようです。むしろ、汎用性を考慮して、LinuxカーネルはCPUの種類に合わせたものをインストールして、その上で動く各種プログラムは互換性のあるi386用にコンパイルしたものを提供するというのが、現在のディストリビューションのやり方のようです。きちんと動作するのが最も良い、ということですね。

サイトマップ

プライバシーポリシー

LPI規約に対する懲戒手順について

カナダ本部サイト

採用情報