UnixClassWiki - 利用者の投稿記録 [ja]

このサイトについて

2014-02-11T15:48:25Z

UnixWikiMaster:

本サイトはUNIXオペレーティングシステムの授業で使うテキストを用意しているサイトです。
授業の進め方に沿って書いているので必ずしもまんべんなくGNU/Linuxに関する内容を取り上げているわけではないことをあらかじめ断っておきます。

=== UNIXオペレーティングシステムテキスト作成方針 ===

本テキストは、大学1-2年生レベルの人が「UNIXオペレーティングシステムを通して今日的なオペレーティングシステム像を理解」し、また「UNIXの背景にある技術、文化、思想について学ぶ」ために作成しているものです。
サンプルのオペレーティングシステムとして GNU/Linux を取り上げています。
一方、本テキストはUNIXやGNU/Linuxの操作方法やその上で動くアプリケーションの設定方法を学ぶためのものではありません。
なぜならば、我々は1年が7年に換算されるドッグイヤーの世界に生きており、
若い頃の貴重な時間を使って特定のアプリケーションの操作方法を使い方を学んだとしても、
その知識が利用できる時間は、きわめて短時間だからです。
あと10年もすれば次世代システム、あるいは現在まだ存在しないような新しいアイデアによるシステムに換わっていることでしょう。
しかし、背景となる技術や文化、あるいは思想というのはそうそう廃れるものではありませんし、これらのものは次世代に脈々と引き継がれていくものです。
<ref>
初めてUNIXを触ったのは1984年ですが、自分の経験を振り返っても、その時のベーシックな知識は今でも役に立っています。
</ref>

本テキストは、このような観点から内容を組み立ています。

=== 脚注 ===
<references/>

----

[[目次]]へ

パスワードファイル

2014-02-11T15:47:44Z

UnixWikiMaster: /* パスワードファイル /etc/passwd */

本章を読む前に、まずパスワードを使った認証メカニズムについての一般論である[[システムにおけるパスワード管理の概要]]のページを先に読んでから本章に進むことをお薦めします。

== パスワードファイル /etc/passwd ==

ユーザIDとアカウント名を対応させているのがパスワードファイル
/etc/passwdです。パスワードファイルのフォーマットは次の通りです。

* パスワードエントリのフォーマットのフィールドは":"で区切られる
* アカウント名 : ログイン時に使用するアカウント名
* パスワード : パスワードをハッシュ値に置き換えたもの
* ユーザID : ユーザを認識するための数値
* グループID : グループを認識するための数値
* コメントフィールド([[GECOSフィールド]]) : 名前等の情報を記述するフィールド
* ホームディレクトリ : ホームディレクトリ
* シェルパス : 利用するシェルのパス、もしくはシェルに相当するコマンド

<pre>
/etc/passwd のエントリー例
hironobu:x:1825:2000:Hironobu SUZUKI,,,:/home/hironobu:/bin/bash
</pre>

このエントリー例は実際運用しているシステムのパスワードファイルから抜き出したものです。
パスワードのフィールドは"x"が入っています。
これは利用しているシステムがシャドーパスワードを導入しているからです。

元々のパスワードファイルには2つの情報が入っています。
一つは公開して誰でも知って良い情報、もう一つは知られてはいけない情報です。
その知られてはいけない情報とはパスワードの情報です。

=== パスワードの生成 ===

もちろんこのパスワードは、すでに一方向性ハッシュ関数によって撹拌されている値となってなっています。
したがって、パスワードファイルの中にあるすでに撹拌されているパスワードのハッシュ値だけ持っていても、
そこから元のパスワードを逆算することはできません。
総当たりで見つける方式しか使えません。
ただし、このままでは同じパスワード入力が同じハッシュ値になってしまいます。
パスワードのパターンを事前に計算し、逆引きのテーブルを用意することが可能となってしまします。
そのため、同じパスワード入力が同じハッシュ値にならないようにSalt（塩）と呼ぶランダムな初期値を加えます。

現在のGNU/Linuxではディストリビューションにより、オリジナルのUNIXが使っていたパスワードのメカニズムをベースとしたパスワード認証の方法を用いているものと、Linux-PAMと呼ばれる包括的なパスワード認証のためのフレームワークを用いているものがあります。ただし、メジャーなディストリビューションはLinux-PAMを採用しています。

UNIX オリジナルの方法では暗号化するためのDESを用いたメッセージ認証コード方式DES-CBC-MAC
<ref> CBC-MACに関しては[http://en.wikipedia.org/wiki/CBC-MAC wikipedia(英語版)]を参照のこと。 </ref>
を一方向性ハッシュ関数として利用してます。
<ref>このDES-CBC-MACの暗号学的安全性に関しての議論は http://www.cs.berkeley.edu/~daw/talks/crypt3-asia00-slides.ps‎ を参照のこと。</ref>
glibcで実装されているパスワード認証のためのアルゴリズムでは、DES-CBC-MACではなく一方向性ハッシュ関数としてMD5、SHA1やSHA-256を使います。
オリジナルの方法では、DESを使う場合は25回繰り返して計算します。glibcでは一方向性ハッシュ関数を使う場合は最低1000回繰り返して計算します。
<ref>これは計算負荷をあげているものですが、これはDESを使っていた時は乱雑さとして有効となるビット数が少なかったためで、一方向性ハッシュ関数の場合、暗号学的には繰り返して計算負荷をあげるよりもランダムなパスワード文字数を増やす方法の方が優れています。</ref>

[[ファイル:Password-hash.png|450px|thumb|center|パスワードの生成]]

; 捕捉 : 図中では「暗号化したパスワード」という表現を使っていますが、本来は復号することができないので暗号化という言葉は暗号の考え方からして適切ではありません。しかし慣用的に「暗号化したパスワード」という言葉を使うので、ここではあえて使っています。正しくは「パスワードのハッシュ値」あるいは「パスワードのMAC値」です。

=== パスワードの保管 ===

オリジナルのUNIXではパスワードファイル/etc/passwdの中にユーザ名やユーザIDと共にパスワードのハッシュ値が格納されており、誰でも参照することが可能でした。
攻撃側は、パスワード候補を用意し、その出力をパスワードファイルの中にあるパスワードのハッシュ値と比較することによって効率的にパスワードを見つけることが可能です。

そこで変換後のパスワードを一般ユーザが直接は参照できない別ファイルに取っておき、認証するコマンドやメンテナンスのコマンドのみがアクセスできるようにしました。これがシャドーパスワードの仕組みです。

<pre>
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 789 Oct 22 2003 /etc/shadow
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 24616 Nov 3 04:56 /usr/bin/passwd
$ ls -l /usr/bin | grep shadow
-rwxr-sr-x 1 root shadow 32584 Nov 3 04:56 chage
-rwxr-sr-x 1 root shadow 15976 Nov 3 04:56 expiry
-rwxr-sr-x 1 root shadow 6628 Jun 28 05:20 kcheckpass
</pre>

== 脚注 ==

<references/>

----
[[目次]]へ

パスワードファイル

2014-02-11T15:47:19Z

UnixWikiMaster: /* パスワードの保管 */

本章を読む前に、まずパスワードを使った認証メカニズムについての一般論である[[システムにおけるパスワード管理の概要]]のページを先に読んでから本章に進むことをお薦めします。

== パスワードファイル /etc/passwd ==

ユーザIDとアカウント名を対応させているのがパスワードファイル
/etc/passwdです。パスワードファイルのフォーマットは次の通りです。

* パスワードエントリのフォーマットのフィールドは":"で区切られる
* アカウント名 : ログイン時に使用するアカウント名
* パスワード : パスワードをハッシュ値に置き換えたもの
* ユーザID : ユーザを認識するための数値
* グループID : グループを認識するための数値
* コメントフィールド([[GECOSフィールド]]) : 名前等の情報を記述するフィールド
* ホームディレクトリ : ホームディレクトリ
* シェルパス : 利用するシェルのパス、もしくはシェルに相当するコマンド

/etc/passwd のエントリー例
hironobu:x:1825:2000:Hironobu SUZUKI,,,:/home/hironobu:/bin/bash

このエントリー例は実際運用しているシステムのパスワードファイルから抜き出したものです。
パスワードのフィールドは"x"が入っています。
これは利用しているシステムがシャドーパスワードを導入しているからです。

元々のパスワードファイルには2つの情報が入っています。
一つは公開して誰でも知って良い情報、もう一つは知られてはいけない情報です。
その知られてはいけない情報とはパスワードの情報です。

=== パスワードの生成 ===

もちろんこのパスワードは、すでに一方向性ハッシュ関数によって撹拌されている値となってなっています。
したがって、パスワードファイルの中にあるすでに撹拌されているパスワードのハッシュ値だけ持っていても、
そこから元のパスワードを逆算することはできません。
総当たりで見つける方式しか使えません。
ただし、このままでは同じパスワード入力が同じハッシュ値になってしまいます。
パスワードのパターンを事前に計算し、逆引きのテーブルを用意することが可能となってしまします。
そのため、同じパスワード入力が同じハッシュ値にならないようにSalt（塩）と呼ぶランダムな初期値を加えます。

現在のGNU/Linuxではディストリビューションにより、オリジナルのUNIXが使っていたパスワードのメカニズムをベースとしたパスワード認証の方法を用いているものと、Linux-PAMと呼ばれる包括的なパスワード認証のためのフレームワークを用いているものがあります。ただし、メジャーなディストリビューションはLinux-PAMを採用しています。

UNIX オリジナルの方法では暗号化するためのDESを用いたメッセージ認証コード方式DES-CBC-MAC
<ref> CBC-MACに関しては[http://en.wikipedia.org/wiki/CBC-MAC wikipedia(英語版)]を参照のこと。 </ref>
を一方向性ハッシュ関数として利用してます。
<ref>このDES-CBC-MACの暗号学的安全性に関しての議論は http://www.cs.berkeley.edu/~daw/talks/crypt3-asia00-slides.ps‎ を参照のこと。</ref>
glibcで実装されているパスワード認証のためのアルゴリズムでは、DES-CBC-MACではなく一方向性ハッシュ関数としてMD5、SHA1やSHA-256を使います。
オリジナルの方法では、DESを使う場合は25回繰り返して計算します。glibcでは一方向性ハッシュ関数を使う場合は最低1000回繰り返して計算します。
<ref>これは計算負荷をあげているものですが、これはDESを使っていた時は乱雑さとして有効となるビット数が少なかったためで、一方向性ハッシュ関数の場合、暗号学的には繰り返して計算負荷をあげるよりもランダムなパスワード文字数を増やす方法の方が優れています。</ref>

[[ファイル:Password-hash.png|450px|thumb|center|パスワードの生成]]

; 捕捉 : 図中では「暗号化したパスワード」という表現を使っていますが、本来は復号することができないので暗号化という言葉は暗号の考え方からして適切ではありません。しかし慣用的に「暗号化したパスワード」という言葉を使うので、ここではあえて使っています。正しくは「パスワードのハッシュ値」あるいは「パスワードのMAC値」です。

=== パスワードの保管 ===

オリジナルのUNIXではパスワードファイル/etc/passwdの中にユーザ名やユーザIDと共にパスワードのハッシュ値が格納されており、誰でも参照することが可能でした。
攻撃側は、パスワード候補を用意し、その出力をパスワードファイルの中にあるパスワードのハッシュ値と比較することによって効率的にパスワードを見つけることが可能です。

そこで変換後のパスワードを一般ユーザが直接は参照できない別ファイルに取っておき、認証するコマンドやメンテナンスのコマンドのみがアクセスできるようにしました。これがシャドーパスワードの仕組みです。

<pre>
$ ls -l /etc/shadow
-rw-r----- 1 root shadow 789 Oct 22 2003 /etc/shadow
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 24616 Nov 3 04:56 /usr/bin/passwd
$ ls -l /usr/bin | grep shadow
-rwxr-sr-x 1 root shadow 32584 Nov 3 04:56 chage
-rwxr-sr-x 1 root shadow 15976 Nov 3 04:56 expiry
-rwxr-sr-x 1 root shadow 6628 Jun 28 05:20 kcheckpass
</pre>

== 脚注 ==

<references/>

----
[[目次]]へ

パスワードファイル

2014-02-11T15:41:49Z

UnixWikiMaster: /* パスワードの保管 */

本章を読む前に、まずパスワードを使った認証メカニズムについての一般論である[[システムにおけるパスワード管理の概要]]のページを先に読んでから本章に進むことをお薦めします。

== パスワードファイル /etc/passwd ==

ユーザIDとアカウント名を対応させているのがパスワードファイル
/etc/passwdです。パスワードファイルのフォーマットは次の通りです。

* パスワードエントリのフォーマットのフィールドは":"で区切られる
* アカウント名 : ログイン時に使用するアカウント名
* パスワード : パスワードをハッシュ値に置き換えたもの
* ユーザID : ユーザを認識するための数値
* グループID : グループを認識するための数値
* コメントフィールド([[GECOSフィールド]]) : 名前等の情報を記述するフィールド
* ホームディレクトリ : ホームディレクトリ
* シェルパス : 利用するシェルのパス、もしくはシェルに相当するコマンド

/etc/passwd のエントリー例
hironobu:x:1825:2000:Hironobu SUZUKI,,,:/home/hironobu:/bin/bash

このエントリー例は実際運用しているシステムのパスワードファイルから抜き出したものです。
パスワードのフィールドは"x"が入っています。
これは利用しているシステムがシャドーパスワードを導入しているからです。

元々のパスワードファイルには2つの情報が入っています。
一つは公開して誰でも知って良い情報、もう一つは知られてはいけない情報です。
その知られてはいけない情報とはパスワードの情報です。

=== パスワードの生成 ===

もちろんこのパスワードは、すでに一方向性ハッシュ関数によって撹拌されている値となってなっています。
したがって、パスワードファイルの中にあるすでに撹拌されているパスワードのハッシュ値だけ持っていても、
そこから元のパスワードを逆算することはできません。
総当たりで見つける方式しか使えません。
ただし、このままでは同じパスワード入力が同じハッシュ値になってしまいます。
パスワードのパターンを事前に計算し、逆引きのテーブルを用意することが可能となってしまします。
そのため、同じパスワード入力が同じハッシュ値にならないようにSalt（塩）と呼ぶランダムな初期値を加えます。

現在のGNU/Linuxではディストリビューションにより、オリジナルのUNIXが使っていたパスワードのメカニズムをベースとしたパスワード認証の方法を用いているものと、Linux-PAMと呼ばれる包括的なパスワード認証のためのフレームワークを用いているものがあります。ただし、メジャーなディストリビューションはLinux-PAMを採用しています。

UNIX オリジナルの方法では暗号化するためのDESを用いたメッセージ認証コード方式DES-CBC-MAC
<ref> CBC-MACに関しては[http://en.wikipedia.org/wiki/CBC-MAC wikipedia(英語版)]を参照のこと。 </ref>
を一方向性ハッシュ関数として利用してます。
<ref>このDES-CBC-MACの暗号学的安全性に関しての議論は http://www.cs.berkeley.edu/~daw/talks/crypt3-asia00-slides.ps‎ を参照のこと。</ref>
glibcで実装されているパスワード認証のためのアルゴリズムでは、DES-CBC-MACではなく一方向性ハッシュ関数としてMD5、SHA1やSHA-256を使います。
オリジナルの方法では、DESを使う場合は25回繰り返して計算します。glibcでは一方向性ハッシュ関数を使う場合は最低1000回繰り返して計算します。
<ref>これは計算負荷をあげているものですが、これはDESを使っていた時は乱雑さとして有効となるビット数が少なかったためで、一方向性ハッシュ関数の場合、暗号学的には繰り返して計算負荷をあげるよりもランダムなパスワード文字数を増やす方法の方が優れています。</ref>

[[ファイル:Password-hash.png|450px|thumb|center|パスワードの生成]]

; 捕捉 : 図中では「暗号化したパスワード」という表現を使っていますが、本来は復号することができないので暗号化という言葉は暗号の考え方からして適切ではありません。しかし慣用的に「暗号化したパスワード」という言葉を使うので、ここではあえて使っています。正しくは「パスワードのハッシュ値」あるいは「パスワードのMAC値」です。

=== パスワードの保管 ===

オリジナルのUNIXではパスワードファイル/etc/passwdの中にユーザ名やユーザIDと共にパスワードのハッシュ値が格納されており、誰でも参照することが可能でした。
攻撃側は、パスワード候補を用意し、その出力をパスワードファイルの中にあるパスワードのハッシュ値と比較することによって効率的にパスワードを見つけることが可能です。

そこで変換後のパスワードを一般ユーザが直接は参照できない別ファイルに取っておき、認証するコマンドやメンテナンスのコマンドのみがアクセスできるようにしました。これがシャドーパスワードの仕組みです。

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 789 Oct 22 2003 /etc/shadow
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 24616 Nov 3 04:56 /usr/bin/passwd
$ ls -l /usr/bin | grep shadow
-rwxr-sr-x 1 root shadow 32584 Nov 3 04:56 chage
-rwxr-sr-x 1 root shadow 15976 Nov 3 04:56 expiry
-rwxr-sr-x 1 root shadow 6628 Jun 28 05:20 kcheckpass

== 脚注 ==

<references/>

----
[[目次]]へ

パスワードファイル

2014-02-11T15:41:32Z

UnixWikiMaster: /* パスワードの生成 */

本章を読む前に、まずパスワードを使った認証メカニズムについての一般論である[[システムにおけるパスワード管理の概要]]のページを先に読んでから本章に進むことをお薦めします。

== パスワードファイル /etc/passwd ==

ユーザIDとアカウント名を対応させているのがパスワードファイル
/etc/passwdです。パスワードファイルのフォーマットは次の通りです。

* パスワードエントリのフォーマットのフィールドは":"で区切られる
* アカウント名 : ログイン時に使用するアカウント名
* パスワード : パスワードをハッシュ値に置き換えたもの
* ユーザID : ユーザを認識するための数値
* グループID : グループを認識するための数値
* コメントフィールド([[GECOSフィールド]]) : 名前等の情報を記述するフィールド
* ホームディレクトリ : ホームディレクトリ
* シェルパス : 利用するシェルのパス、もしくはシェルに相当するコマンド

/etc/passwd のエントリー例
hironobu:x:1825:2000:Hironobu SUZUKI,,,:/home/hironobu:/bin/bash

このエントリー例は実際運用しているシステムのパスワードファイルから抜き出したものです。
パスワードのフィールドは"x"が入っています。
これは利用しているシステムがシャドーパスワードを導入しているからです。

元々のパスワードファイルには2つの情報が入っています。
一つは公開して誰でも知って良い情報、もう一つは知られてはいけない情報です。
その知られてはいけない情報とはパスワードの情報です。

=== パスワードの生成 ===

もちろんこのパスワードは、すでに一方向性ハッシュ関数によって撹拌されている値となってなっています。
したがって、パスワードファイルの中にあるすでに撹拌されているパスワードのハッシュ値だけ持っていても、
そこから元のパスワードを逆算することはできません。
総当たりで見つける方式しか使えません。
ただし、このままでは同じパスワード入力が同じハッシュ値になってしまいます。
パスワードのパターンを事前に計算し、逆引きのテーブルを用意することが可能となってしまします。
そのため、同じパスワード入力が同じハッシュ値にならないようにSalt（塩）と呼ぶランダムな初期値を加えます。

現在のGNU/Linuxではディストリビューションにより、オリジナルのUNIXが使っていたパスワードのメカニズムをベースとしたパスワード認証の方法を用いているものと、Linux-PAMと呼ばれる包括的なパスワード認証のためのフレームワークを用いているものがあります。ただし、メジャーなディストリビューションはLinux-PAMを採用しています。

UNIX オリジナルの方法では暗号化するためのDESを用いたメッセージ認証コード方式DES-CBC-MAC
<ref> CBC-MACに関しては[http://en.wikipedia.org/wiki/CBC-MAC wikipedia(英語版)]を参照のこと。 </ref>
を一方向性ハッシュ関数として利用してます。
<ref>このDES-CBC-MACの暗号学的安全性に関しての議論は http://www.cs.berkeley.edu/~daw/talks/crypt3-asia00-slides.ps‎ を参照のこと。</ref>
glibcで実装されているパスワード認証のためのアルゴリズムでは、DES-CBC-MACではなく一方向性ハッシュ関数としてMD5、SHA1やSHA-256を使います。
オリジナルの方法では、DESを使う場合は25回繰り返して計算します。glibcでは一方向性ハッシュ関数を使う場合は最低1000回繰り返して計算します。
<ref>これは計算負荷をあげているものですが、これはDESを使っていた時は乱雑さとして有効となるビット数が少なかったためで、一方向性ハッシュ関数の場合、暗号学的には繰り返して計算負荷をあげるよりもランダムなパスワード文字数を増やす方法の方が優れています。</ref>

[[ファイル:Password-hash.png|450px|thumb|center|パスワードの生成]]

; 捕捉 : 図中では「暗号化したパスワード」という表現を使っていますが、本来は復号することができないので暗号化という言葉は暗号の考え方からして適切ではありません。しかし慣用的に「暗号化したパスワード」という言葉を使うので、ここではあえて使っています。正しくは「パスワードのハッシュ値」あるいは「パスワードのMAC値」です。

=== パスワードの保管 ===

オリジナルのUNIXではパスワードファイル/etc/passwdの中にユーザ名やユーザIDと共にパスワードのハッシュ値が格納されており、誰でも参照することが可能でした。
攻撃側は、パスワード候補を用意し、その出力をパスワードファイルの中にあるパスワードのハッシュ値と比較することによって効率的にパスワードを見つけることが可能です。

そこで変換後のパスワードを一般ユーザが直接は参照できない別ファイルに取っておき、認証するコマンドやメンテナンスのコマンドのみがアクセスできるようにしました。これがシャドーパスワードの仕組みです。

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 789 Oct 22 2003 /etc/shadow
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 24616 Nov 3 04:56 /usr/bin/passwd
$ ls -l /usr/bin | grep shadow
-rwxr-sr-x 1 root shadow 32584 Nov 3 04:56 chage
-rwxr-sr-x 1 root shadow 15976 Nov 3 04:56 expiry
-rwxr-sr-x 1 root shadow 6628 Jun 28 05:20 kcheckpass

== 脚注 ==

<references/>

----
[[目次]]へ

パスワードファイル

2014-02-11T15:37:09Z

UnixWikiMaster:

本章を読む前に、まずパスワードを使った認証メカニズムについての一般論である[[システムにおけるパスワード管理の概要]]のページを先に読んでから本章に進むことをお薦めします。

== パスワードファイル /etc/passwd ==

ユーザIDとアカウント名を対応させているのがパスワードファイル
/etc/passwdです。パスワードファイルのフォーマットは次の通りです。

* パスワードエントリのフォーマットのフィールドは":"で区切られる
* アカウント名 : ログイン時に使用するアカウント名
* パスワード : パスワードをハッシュ値に置き換えたもの
* ユーザID : ユーザを認識するための数値
* グループID : グループを認識するための数値
* コメントフィールド([[GECOSフィールド]]) : 名前等の情報を記述するフィールド
* ホームディレクトリ : ホームディレクトリ
* シェルパス : 利用するシェルのパス、もしくはシェルに相当するコマンド

/etc/passwd のエントリー例
hironobu:x:1825:2000:Hironobu SUZUKI,,,:/home/hironobu:/bin/bash

このエントリー例は実際運用しているシステムのパスワードファイルから抜き出したものです。
パスワードのフィールドは"x"が入っています。
これは利用しているシステムがシャドーパスワードを導入しているからです。

元々のパスワードファイルには2つの情報が入っています。
一つは公開して誰でも知って良い情報、もう一つは知られてはいけない情報です。
その知られてはいけない情報とはパスワードの情報です。

=== パスワードの生成 ===

もちろんこのパスワードは、すでに一方向性ハッシュ関数によって撹拌されている値となってなっています。
したがって、パスワードファイルの中にあるすでに撹拌されているパスワードのハッシュ値だけ持っていても、
そこから元のパスワードを逆算することはできません。
総当たりで見つける方式しか使えません。
ただし、このままでは同じパスワード入力が同じハッシュ値になってしまいます。
パスワードのパターンを事前に計算し、逆引きのテーブルを用意することが可能となってしまします。
そのため、同じパスワード入力が同じハッシュ値にならないようにSalt（塩）と呼ぶランダムな初期値を加えます。

現在のGNU/Linuxではディストリビューションにより、オリジナルのUNIXが使っていたパスワードのメカニズムをベースとしたパスワード認証の方法を用いているものと、Linux-PAMと呼ばれる包括的なパスワード認証のためのフレームワークを用いているものがあります。ただし、メジャーなディストリビューションはLinux-PAMを採用しています。

UNIX オリジナルの方法では暗号化するためのDESを用いたメッセージ認証コード方式DES-CBC-MAC
<ref> CBC-MACに関しては[http://en.wikipedia.org/wiki/CBC-MAC wikipedia(英語版)]を参照のこと。 </ref>
を一方向性ハッシュ関数として利用してます。
<ref>このDES-CBC-MACの暗号学的安全性に関しての議論は http://www.cs.berkeley.edu/~daw/talks/crypt3-asia00-slides.ps‎ を参照のこと。</ref>
glibcで実装されているパスワード認証のためのアルゴリズムでは、DES-CBC-MACではなく一方向性ハッシュ関数としてMD5、SHA1やSHA-256を使います。
オリジナルの方法では、DESを使う場合は25回繰り返して計算します。glibcでは一方向性ハッシュ関数を使う場合は最低1000回繰り返して計算します。
<ref>これは計算負荷をあげているものですが、これはDESを使っていた時は乱雑さとして有効となるビット数が少なかったためで、一方向性ハッシュ関数の場合、暗号学的には繰り返して計算負荷をあげるよりもランダムなパスワード文字数を増やす方法の方が優れています。</ref>

[[ファイル:Password-hash.png|450px|thumb|center|パスワードの生成]]

; 捕捉 : 図中では「暗号化したパスワード」という表現を使っていますが、本来は復号することができないので暗号化という言葉は暗号の考え方からして適切ではありません。しかし慣用的に「暗号化したパスワード」という言葉を使うので、ここではあえて使っています。正しくは「パスワードのハッシュ値」です。

=== パスワードの保管 ===

オリジナルのUNIXではパスワードファイル/etc/passwdの中にユーザ名やユーザIDと共にパスワードのハッシュ値が格納されており、誰でも参照することが可能でした。
攻撃側は、パスワード候補を用意し、その出力をパスワードファイルの中にあるパスワードのハッシュ値と比較することによって効率的にパスワードを見つけることが可能です。

そこで変換後のパスワードを一般ユーザが直接は参照できない別ファイルに取っておき、認証するコマンドやメンテナンスのコマンドのみがアクセスできるようにしました。これがシャドーパスワードの仕組みです。

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 789 Oct 22 2003 /etc/shadow
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 24616 Nov 3 04:56 /usr/bin/passwd
$ ls -l /usr/bin | grep shadow
-rwxr-sr-x 1 root shadow 32584 Nov 3 04:56 chage
-rwxr-sr-x 1 root shadow 15976 Nov 3 04:56 expiry
-rwxr-sr-x 1 root shadow 6628 Jun 28 05:20 kcheckpass

== 脚注 ==

<references/>

----
[[目次]]へ

システムにおけるパスワード管理の概要

2014-02-11T15:33:44Z

UnixWikiMaster: /* 一方向性ハッシュ関数を導入する */

== はじめに ==

パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。

その前に、パスワードに123456やpasswordといったものやアカウント名adminでパスワードがadminといったものを使っている「これはひどい」といいたくなるパスワードでは、さしたる事前の準備も必要なく、いくつか試せばいいので、いくらパスワードの管理をシステム側で頑張っても無理です。

これはさすがに、ウカツなパスワードとしか呼びようがありませんが、これはユーザだけが悪いわけではなく、システムがこのようなパスワードを許容すること自体が、システムの欠陥だと私は思います。最近のシステムではユーザがパスワードを選ぶ際に一定の強度を満たしていない場合は警告を出したり受け付けないといったものも多く、ずいぶんと状況は改善されつつあります。

ある程度の複雑さをもったパスワードに関しては、これはパスワード管理ファイルをサイトから流出させ、専用のコンピュータを用意してパスワードを見つける処理を行うというのが前提となります。 2012年に発生した45万件のパスワードを流出させた[http://www.zdnet.com/the-top-10-passwords-from-the-yahoo-hack-is-yours-one-of-them-7000000815/ Yahooのケース]、2013年に発生した3,800万件のパスワードを流出させた[http://www.zdnet.com/adobe-admits-2-9m-customer-accounts-have-been-compromised-7000021546/ Adobeのケース]などがこれにあたります。

以下に3つのパスワード管理のパターンを説明し、次に、どのような方法でパスワードを見つけていくかの説明を加えます。

=== パスワードを防御なしに管理 ===

[[ファイル:Pwd-pic-1.png|300px|thumb|right|保存されているパスワードは保護されない]]

パスワード認証というと、ユーザからの入力の文字列と、既に登録しているパスワードの文字列を突き合わせることだと思っている人も意外といるのではないかと思います。
簡単に実装することができますが、ただし、このパスワードファイルが外部に流出した時点で、サービスの存続にかかわるレベルで、システム全体のユーザ認証が崩壊します。なぜならば、そのままの形ですべてのパスワードを利用することが出来るからです。

ファイルへのアクセスをコントロールすることで安全性を保っていると理解してしまう人がいるでしょうが、逆をいえば、それだけしか保護をしておらず、情報流出する可能性の前提に立っていません。潜在的に1つのエラーがシステム全体をカタストロフな状態に導く可能性がある脆弱な状態におかれています。

このシステムは、大きな問題をはらんでいるのは、改めて強調しなくとも多くの方には理解されているだろうと思います。その一方で、このようなシステムは、そんなに多くはないだろうと楽観的に考えるかも知れません。でも、パスワードを忘れたときに親切にも元々のパスワードを教えてくれるタイプのシステムは、まわりを見渡せばけっこうあるはずです。

* 利点: パスワードを忘れたときに、パスワードを教えることができる。
* 欠点: パスワードファイルが流出するとユーザ認証は壊滅的なダメージとなる。

=== 一方向性ハッシュ関数を導入する ===

[[ファイル:Pwd-pic-2.png|300px|thumb|right|一方向性ハッシュ関数のみ導入]]

一方向性ハッシュ関数とは、値xに対しハッシュ関数Hを用いて計算した値H(x)から、逆をたどってxを見つけることは極めて困難であるという性質を持つ関数です。一方向性ハッシュ関数にはSHA256、SHA512といったものだけではなく、暗号化関数を使ったメッセージ認証コードなども同様に使えます。たとえば古典的UNIXのパスワード生成にはDES暗号を使っているDES-CBC-MACというメッセージ認証コード法が使われています。

よく「パスワードを暗号化」するという表現を使うので、暗号化するなら、復号もできるだろうと類推してしまいそうになりますが、これは一方向にしか計算できません。
パスワードを入力し、それを一方向性ハッシュ関数で計算した値を、事前に登録しておいた一方向性ハッシュ関数で計算した値と比較します。たとえばWindowsXPなどで使っていたLMハッシュ(LAN Manager hash)は、この方式です。

生の文字列を持っている先ほどの方法よりは格段に安全性は上がりますが、例えば同じ入力のものは同じ出力値を持ってしまう弱点を持っています。そのため辞書に載っているようなパスワードであれば、事前に処理してハッシュ値辞書を作成することが出来きます。つまり、辞書攻撃には極めて脆弱なパスワードシステムだといえます。

辞書を作るのに膨大な時間がかかると考えるかも知れませんが、英数字8文字のすべての文字の組み合わせのための逆引き辞書を作るのに秋葉原で手に入る機材レベルで30時間もあれば十分作成できます。しかも[http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/ ophcrack]サイトでは既にWindows XPやVistaのための辞書テーブルが既に用意されており、それを使えば検索成功率99パーセントだそうです。

先ほどの紹介したAdobeの流出したパスワード情報は、このタイプで、さらに悪いことには、ユーザが入力するパスワードのヒント情報も入っており、そこからまず類推可能なパスワードを探し当て、次に同じパスワードを持つユーザをピックアップしてゆくということが出来てしまうという、極めて憂慮すべきシステムでした。

* 利点: パスワードを見つけるためにはパスワード解析をする必要がある。
* 欠点: 同じパスワードは同じ出力なので事前に辞書を作ることが可能。

=== ソルトを加えたパスワード管理 ===

[[ファイル:Pwd-pic-3.png|300px|thumb|right|Salt(ソルト)を加えることにより同じパスワードの類推を困難にする]]

一方向性ハッシュ関数だけだと逆引きの攻撃辞書が使えるので、それを困難にするようにソルト(salt)と呼ばれる、ユーザ毎に異なるランダムな値を加えたのちに一方向性ハッシュ関数に入力する方法をとります。

このソルトは隠さなくてもかまいません。長ければながいほど逆引きの攻撃辞書のサイズが巨大になります。ソルトはランダムデータですが、そんなに大きなものは必要なく70年代では12ビット程度が使われており、もし将来的にも使うと考えるとしても64ビット(8バイト)程度あれば十分でしょう。

古典的なUNIXのパスワード処理法では、さらに一方向性ハッシュ関数を複数回呼び出し計算時間をより多くかけさせるという手法を使っています。ただし一度に多数のユーザの対応をしなければならないようなシステム、例えばウェブサイトのパスワード認証などで行うのは、認証するサーバー側に負荷がかかりすぎる可能性があるので、本当にこの手法を選択すべきかどうかは熟慮が必要です。基本的には、複雑さを増すにはパスワードに使える文字種類を多くしたり、文字数を増やすことが重要です。

これでやっと普通のパスワード管理の基準を満たすことができます。ここでの普通っていうのは、ただ単純に数として多くあるいう意味ではなく、理想に近い意味での普通です。 (cf. Dream Fighter by Y. Nakata)

* 利点: 事前のパスワード解析を無効にできる。
* 欠点: - (必要な基準は満たしている。）

ファイル:Pwd-pic-3.png

2014-02-11T15:32:06Z

UnixWikiMaster:

システムにおけるパスワード管理の概要

2014-02-11T15:30:26Z

UnixWikiMaster: /* 一方向性ハッシュ関数を導入する */

システムにおけるパスワード管理の概要

2014-02-11T15:30:03Z

UnixWikiMaster: /* 一方向性ハッシュ関数を導入する */

ファイル:Pwd-pic-2.png

2014-02-11T15:29:01Z

UnixWikiMaster:

システムにおけるパスワード管理の概要

2014-02-11T15:27:59Z

UnixWikiMaster: /* パスワードを防御なしに管理 */

== はじめに ==

パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。

その前に、パスワードに123456やpasswordといったものやアカウント名adminでパスワードがadminといったものを使っている「これはひどい」といいたくなるパスワードでは、さしたる事前の準備も必要なく、いくつか試せばいいので、いくらパスワードの管理をシステム側で頑張っても無理です。

これはさすがに、ウカツなパスワードとしか呼びようがありませんが、これはユーザだけが悪いわけではなく、システムがこのようなパスワードを許容すること自体が、システムの欠陥だと私は思います。最近のシステムではユーザがパスワードを選ぶ際に一定の強度を満たしていない場合は警告を出したり受け付けないといったものも多く、ずいぶんと状況は改善されつつあります。

ある程度の複雑さをもったパスワードに関しては、これはパスワード管理ファイルをサイトから流出させ、専用のコンピュータを用意してパスワードを見つける処理を行うというのが前提となります。 2012年に発生した45万件のパスワードを流出させた[http://www.zdnet.com/the-top-10-passwords-from-the-yahoo-hack-is-yours-one-of-them-7000000815/ Yahooのケース]、2013年に発生した3,800万件のパスワードを流出させた[http://www.zdnet.com/adobe-admits-2-9m-customer-accounts-have-been-compromised-7000021546/ Adobeのケース]などがこれにあたります。

以下に3つのパスワード管理のパターンを説明し、次に、どのような方法でパスワードを見つけていくかの説明を加えます。

=== パスワードを防御なしに管理 ===

[[ファイル:Pwd-pic-1.png|300px|thumb|right|保存されているパスワードは保護されない]]

パスワード認証というと、ユーザからの入力の文字列と、既に登録しているパスワードの文字列を突き合わせることだと思っている人も意外といるのではないかと思います。
簡単に実装することができますが、ただし、このパスワードファイルが外部に流出した時点で、サービスの存続にかかわるレベルで、システム全体のユーザ認証が崩壊します。なぜならば、そのままの形ですべてのパスワードを利用することが出来るからです。

ファイルへのアクセスをコントロールすることで安全性を保っていると理解してしまう人がいるでしょうが、逆をいえば、それだけしか保護をしておらず、情報流出する可能性の前提に立っていません。潜在的に1つのエラーがシステム全体をカタストロフな状態に導く可能性がある脆弱な状態におかれています。

このシステムは、大きな問題をはらんでいるのは、改めて強調しなくとも多くの方には理解されているだろうと思います。その一方で、このようなシステムは、そんなに多くはないだろうと楽観的に考えるかも知れません。でも、パスワードを忘れたときに親切にも元々のパスワードを教えてくれるタイプのシステムは、まわりを見渡せばけっこうあるはずです。

* 利点: パスワードを忘れたときに、パスワードを教えることができる。
* 欠点: パスワードファイルが流出するとユーザ認証は壊滅的なダメージとなる。

=== 一方向性ハッシュ関数を導入する ===

一方向性ハッシュ関数とは、値xに対しハッシュ関数Hを用いて計算した値H(x)から、逆をたどってxを見つけることは極めて困難であるという性質を持つ関数です。一方向性ハッシュ関数にはSHA256、SHA512といったものだけではなく、暗号化関数を使ったメッセージ認証コードなども同様に使えます。たとえば古典的UNIXのパスワード生成にはDES暗号を使っているDES-CBC-MACというメッセージ認証コード法が使われています。

よく「パスワードを暗号化」するという表現を使うので、暗号化するなら、復号もできるだろうと類推してしまいそうになりますが、これは一方向にしか計算できません。
パスワードを入力し、それを一方向性ハッシュ関数で計算した値を、事前に登録しておいた一方向性ハッシュ関数で計算した値と比較します。たとえばWindowsXPなどで使っていたLMハッシュ(LAN Manager hash)は、この方式です。

生の文字列を持っている先ほどの方法よりは格段に安全性は上がりますが、例えば同じ入力のものは同じ出力値を持ってしまう弱点を持っています。そのため辞書に載っているようなパスワードであれば、事前に処理してハッシュ値辞書を作成することが出来きます。つまり、辞書攻撃には極めて脆弱なパスワードシステムだといえます。

辞書を作るのに膨大な時間がかかると考えるかも知れませんが、英数字8文字のすべての文字の組み合わせのための逆引き辞書を作るのに秋葉原で手に入る機材レベルで30時間もあれば十分作成できます。しかも[http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/ ophcrack]サイトでは既にWindows XPやVistaのための辞書テーブルが既に用意されており、それを使えば検索成功率99パーセントだそうです。

先ほどの紹介したAdobeの流出したパスワード情報は、このタイプで、さらに悪いことには、ユーザが入力するパスワードのヒント情報も入っており、そこからまず類推可能なパスワードを探し当て、次に同じパスワードを持つユーザをピックアップしてゆくということが出来てしまうという、極めて憂慮すべきシステムでした。

ファイル:Pwd-pic-1.png

2014-02-11T15:25:52Z

UnixWikiMaster:

システムにおけるパスワード管理の概要

2014-02-11T15:24:59Z

UnixWikiMaster: /* パスワードを防御なしに管理 */

== はじめに ==

パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。

その前に、パスワードに123456やpasswordといったものやアカウント名adminでパスワードがadminといったものを使っている「これはひどい」といいたくなるパスワードでは、さしたる事前の準備も必要なく、いくつか試せばいいので、いくらパスワードの管理をシステム側で頑張っても無理です。

これはさすがに、ウカツなパスワードとしか呼びようがありませんが、これはユーザだけが悪いわけではなく、システムがこのようなパスワードを許容すること自体が、システムの欠陥だと私は思います。最近のシステムではユーザがパスワードを選ぶ際に一定の強度を満たしていない場合は警告を出したり受け付けないといったものも多く、ずいぶんと状況は改善されつつあります。

ある程度の複雑さをもったパスワードに関しては、これはパスワード管理ファイルをサイトから流出させ、専用のコンピュータを用意してパスワードを見つける処理を行うというのが前提となります。 2012年に発生した45万件のパスワードを流出させた[http://www.zdnet.com/the-top-10-passwords-from-the-yahoo-hack-is-yours-one-of-them-7000000815/ Yahooのケース]、2013年に発生した3,800万件のパスワードを流出させた[http://www.zdnet.com/adobe-admits-2-9m-customer-accounts-have-been-compromised-7000021546/ Adobeのケース]などがこれにあたります。

以下に3つのパスワード管理のパターンを説明し、次に、どのような方法でパスワードを見つけていくかの説明を加えます。

=== パスワードを防御なしに管理 ===

パスワード認証というと、ユーザからの入力の文字列と、既に登録しているパスワードの文字列を突き合わせることだと思っている人も意外といるのではないかと思います。
簡単に実装することができますが、ただし、このパスワードファイルが外部に流出した時点で、サービスの存続にかかわるレベルで、システム全体のユーザ認証が崩壊します。なぜならば、そのままの形ですべてのパスワードを利用することが出来るからです。

ファイルへのアクセスをコントロールすることで安全性を保っていると理解してしまう人がいるでしょうが、逆をいえば、それだけしか保護をしておらず、情報流出する可能性の前提に立っていません。潜在的に1つのエラーがシステム全体をカタストロフな状態に導く可能性がある脆弱な状態におかれています。

このシステムは、大きな問題をはらんでいるのは、改めて強調しなくとも多くの方には理解されているだろうと思います。その一方で、このようなシステムは、そんなに多くはないだろうと楽観的に考えるかも知れません。でも、パスワードを忘れたときに親切にも元々のパスワードを教えてくれるタイプのシステムは、まわりを見渡せばけっこうあるはずです。

* 利点: パスワードを忘れたときに、パスワードを教えることができる。
* 欠点: パスワードファイルが流出するとユーザ認証は壊滅的なダメージとなる。

=== 一方向性ハッシュ関数を導入する ===

一方向性ハッシュ関数とは、値xに対しハッシュ関数Hを用いて計算した値H(x)から、逆をたどってxを見つけることは極めて困難であるという性質を持つ関数です。一方向性ハッシュ関数にはSHA256、SHA512といったものだけではなく、暗号化関数を使ったメッセージ認証コードなども同様に使えます。たとえば古典的UNIXのパスワード生成にはDES暗号を使っているDES-CBC-MACというメッセージ認証コード法が使われています。

よく「パスワードを暗号化」するという表現を使うので、暗号化するなら、復号もできるだろうと類推してしまいそうになりますが、これは一方向にしか計算できません。
パスワードを入力し、それを一方向性ハッシュ関数で計算した値を、事前に登録しておいた一方向性ハッシュ関数で計算した値と比較します。たとえばWindowsXPなどで使っていたLMハッシュ(LAN Manager hash)は、この方式です。

生の文字列を持っている先ほどの方法よりは格段に安全性は上がりますが、例えば同じ入力のものは同じ出力値を持ってしまう弱点を持っています。そのため辞書に載っているようなパスワードであれば、事前に処理してハッシュ値辞書を作成することが出来きます。つまり、辞書攻撃には極めて脆弱なパスワードシステムだといえます。

辞書を作るのに膨大な時間がかかると考えるかも知れませんが、英数字8文字のすべての文字の組み合わせのための逆引き辞書を作るのに秋葉原で手に入る機材レベルで30時間もあれば十分作成できます。しかも[http://lasecwww.epfl.ch/~oechslin/projects/ophcrack/ ophcrack]サイトでは既にWindows XPやVistaのための辞書テーブルが既に用意されており、それを使えば検索成功率99パーセントだそうです。

先ほどの紹介したAdobeの流出したパスワード情報は、このタイプで、さらに悪いことには、ユーザが入力するパスワードのヒント情報も入っており、そこからまず類推可能なパスワードを探し当て、次に同じパスワードを持つユーザをピックアップしてゆくということが出来てしまうという、極めて憂慮すべきシステムでした。

システムにおけるパスワード管理の概要

2014-02-11T15:23:02Z

UnixWikiMaster: /* はじめに */

システムにおけるパスワード管理の概要

2014-02-11T15:22:07Z

UnixWikiMaster: ページの作成:「== はじめに == パスワード管理の方法と、パスワードを入手された時の問題点を整理してみましょう。その前に、パスワード...」

パスワードファイル

2014-02-11T15:18:38Z

UnixWikiMaster: /* パスワードファイル /etc/passwd */

パスワードシステムについて基礎的知識である[[システムにおけるパスワード管理の概要]]を先に読んでから本文を読むことをお薦めします。

== パスワードファイル /etc/passwd ==

ユーザIDとアカウント名を対応させているのがパスワードファイル
/etc/passwdです。パスワードファイルのフォーマットは次の通りです。

* パスワードエントリのフォーマットのフィールドは":"で区切られる
* アカウント名 : ログイン時に使用するアカウント名
* パスワード : パスワードをハッシュ値に置き換えたもの
* ユーザID : ユーザを認識するための数値
* グループID : グループを認識するための数値
* コメントフィールド([[GECOSフィールド]]) : 名前等の情報を記述するフィールド
* ホームディレクトリ : ホームディレクトリ
* シェルパス : 利用するシェルのパス、もしくはシェルに相当するコマンド

/etc/passwd のエントリー例
hironobu:x:1825:2000:Hironobu SUZUKI,,,:/home/hironobu:/bin/bash

このエントリー例は実際運用しているシステムのパスワードファイルから抜き出したものです。
パスワードのフィールドは"x"が入っています。
これは利用しているシステムがシャドーパスワードを導入しているからです。

元々のパスワードファイルには2つの情報が入っています。
一つは公開して誰でも知って良い情報、もう一つは知られてはいけない情報です。
その知られてはいけない情報とはパスワードの情報です。

=== パスワードの生成 ===

もちろんこのパスワードは、すでに一方向性ハッシュ関数によって撹拌されている値となってなっています。
したがって、パスワードファイルの中にあるすでに撹拌されているパスワードのハッシュ値だけ持っていても、
そこから元のパスワードを逆算することはできません。
総当たりで見つける方式しか使えません。
ただし、このままでは同じパスワード入力が同じハッシュ値になってしまいます。
パスワードのパターンを事前に計算し、逆引きのテーブルを用意することが可能となってしまします。
そのため、同じパスワード入力が同じハッシュ値にならないようにSalt（塩）と呼ぶランダムな初期値を加えます。

現在のGNU/Linuxではディストリビューションにより、オリジナルのUNIXが使っていたパスワードのメカニズムをベースとしたパスワード認証の方法を用いているものと、Linux-PAMと呼ばれる包括的なパスワード認証のためのフレームワークを用いているものがあります。ただし、メジャーなディストリビューションはLinux-PAMを採用しています。

UNIX オリジナルの方法では暗号化するためのDESを用いたメッセージ認証コード方式DES-CBC-MAC
<ref> CBC-MACに関しては[http://en.wikipedia.org/wiki/CBC-MAC wikipedia(英語版)]を参照のこと。 </ref>
を一方向性ハッシュ関数として利用してます。
<ref>このDES-CBC-MACの暗号学的安全性に関しての議論は http://www.cs.berkeley.edu/~daw/talks/crypt3-asia00-slides.ps‎ を参照のこと。</ref>
glibcで実装されているパスワード認証のためのアルゴリズムでは、DES-CBC-MACではなく一方向性ハッシュ関数としてMD5、SHA1やSHA-256を使います。
オリジナルの方法では、DESを使う場合は25回繰り返して計算します。glibcでは一方向性ハッシュ関数を使う場合は最低1000回繰り返して計算します。
<ref>これは計算負荷をあげているものですが、これはDESを使っていた時は乱雑さとして有効となるビット数が少なかったためで、一方向性ハッシュ関数の場合、暗号学的には繰り返して計算負荷をあげるよりもランダムなパスワード文字数を増やす方法の方が優れています。</ref>

[[ファイル:Password-hash.png|450px|thumb|center|パスワードの生成]]

; 捕捉 : 図中では「暗号化したパスワード」という表現を使っていますが、本来は復号することができないので暗号化という言葉は暗号の考え方からして適切ではありません。しかし慣用的に「暗号化したパスワード」という言葉を使うので、ここではあえて使っています。正しくは「パスワードのハッシュ値」です。

=== パスワードの保管 ===

オリジナルのUNIXではパスワードファイル/etc/passwdの中にユーザ名やユーザIDと共にパスワードのハッシュ値が格納されており、誰でも参照することが可能でした。
攻撃側は、パスワード候補を用意し、その出力をパスワードファイルの中にあるパスワードのハッシュ値と比較することによって効率的にパスワードを見つけることが可能です。

そこで変換後のパスワードを一般ユーザが直接は参照できない別ファイルに取っておき、認証するコマンドやメンテナンスのコマンドのみがアクセスできるようにしました。これがシャドーパスワードの仕組みです。

$ ls -l /etc/shadow
-rw-r----- 1 root shadow 789 Oct 22 2003 /etc/shadow
$ ls -l /usr/bin/passwd
-rwsr-xr-x 1 root root 24616 Nov 3 04:56 /usr/bin/passwd
$ ls -l /usr/bin | grep shadow
-rwxr-sr-x 1 root shadow 32584 Nov 3 04:56 chage
-rwxr-sr-x 1 root shadow 15976 Nov 3 04:56 expiry
-rwxr-sr-x 1 root shadow 6628 Jun 28 05:20 kcheckpass

== 脚注 ==

<references/>

----
[[目次]]へ

OS誕生からLinuxまでの歴史

2014-02-11T14:51:59Z

UnixWikiMaster: /* なぜLinuxがこれだけ広まったか */

; 注意: 本文は1994年にソフトウェアデザイン誌に連載していたOS入門の原稿をベースにしています。ですからこの文章は1994年当時の状況をベースにしてかかれています。現在ではGNU/Linuxをシステム全体、Linuxをカーネルと区別しますが、本文中ではGNU/LinuxシステムをLinuxと呼んでいます。これは1994年当時の状況をそのまま残しているためです。

== OS誕生 ==

OSの歴史は、コンピュータが産まれてから20年ほど経った1960年代中期からスタートします。1960年中期にIBMが開発した商用コンピュータ・システム IBM System/360は、本格的なOS (OS/360)を搭載していました。それ以前のコンピュータ・システムは、部分的にはOSとしての機能を満たしたものがありますが、OS として機能及び概念が確立はしていません。IBM System/360が始めてOSの機能と概念を確立させました。

:60年代のアメリカは公民権運動、ベトナム反戦運動、ウッドストックなどを後世に残すと同時にOSも後世に残したのでした。

それまでのIBMのコンピュータは、そのハードウェアの製品ライン毎にソフトウェアが必要で、各々の製品ラインの違うコンピュータ・システムには、ソフトウェアの互換性がありませんでした。

これは、私たちが現在、アプリケーション・プログラムと呼んでいるような、ある特定目的のために動作するソフトウェアが、OSというクッションを持たず、システム全体のソフトウェアと密接に絡み合っていたからです。つまり、アプリケーションがリソースを管理しなければならなかったのです。

例えば、事務には事務専用システムおよびソフトウェアを、科学計算には科学技術専用システムおよびソフトウェアを用意していました。また、同じ専用システムでも最大メモリやプロセッサのスピード、IOデバイスの数などのシステムの構成が違えば、それだけでソフトウェアの互換性は保てませんでした。

OSを導入することによってリソース管理をアプリケーションから切り離します。以前のシステム構成に特化したソフトウェアしか動かないコンピュータ・システムの世界から今度は色々なソフトウェアを動かすことができる、汎用なコンピュータ・システム世界に変化していきます。

その後System 360は、370、4300、3080、3090といったIBMシリーズに続き継がれます。それらのシステムは『汎用機』と呼ばれるコンピュータ・システムの代表です。

=== MULTICSも忘れちゃいけない ===

同世代で、忘れてはいけないのがタイムシアリング・システムと呼ばれる処理方法を用いたCTSSと、それに引き続く今日のOSの原型でともいえるMULTICS<ref>http://www.multicians.org/</ref><ref>http://web.mit.edu/multics-history/</ref> です。CTSSは1963年にMITで使われていた原始的なOSでIBM System / 360よりも古いIBM 7094というシステム上で実現されています。

タイムシアリング・システムとは、複数のユーザが実行している各々のプログラムの処理をある一定時間毎(あるいは入出力が発生しI/O待ちになった場合)に切替えて、各々のユーザがあたかも同時に1つのコンピュータを使っているかのように見せかせるシステムです。

CTSSのプログラムの切替えは非常に単純です。ユーザの動かしているプログラムをまるごと主記憶装置から補助記憶装置に追い出し、次に動かすプログラムをロードしてくるというものでした<ref>これは、まだマルチプログラミングまで進化していません。混同しやすいので要注意のこと。 </ref>。複数のプログラムを切替える能力はありましたが、リソース管理という点では、OSと呼ぶには十分ではありません。

CTSSがうまくいったので1965年にMITとAT&Tベル研究所とジェネラル・エレクトリック社
<ref>当時のジェネラル・エレクトリックは大手コンピュータ・メーカーであった。 </ref>
が、共同で、現在のOSと比較しても見劣りしないような数々のスペックを持った、多目的なOSを作ろうとしました。それがMULTICSです。現在、私たちがOSの機能と呼んでいる数々の機能はMULTICSで現れたものです。

がしかし、1965年当時それらを実現するにはそもそもハードウェアの能力が足りませんし
<ref>あまりに古くて、正確な資料がないのですが、MULTICSのターゲット・ハードウェアだったGE-645の処理パワーは、i386マシンぐらいだったようです。 </ref>
、それだけのアイデアを完全に実現するだけのソフトウェア技術もまだ存在しないという、かなり無謀なプロジェクトでした。

途中でベル研がプロジェクトから抜け、ジェネラル・エレクトリック社がコンピュータ市場自体から撤退しました。MULTICSはその後、MIT内部と数十のサイトで利用されました。おどろくことに細々とまだ存在しているのですが、多くの人の記憶からは既に消え去ってしまっています。しかしMULTICSで考えられた数々のアイデア、例えば、仮想記憶、プロセスの概念、プロテクションの概念、他にも多くの重要なアイデアが、今日のOSの中に生きています。

== UNIX誕生! ==

MULTICSプロジェクトにはベル研のKen ThompsonとDennis Ritchieがいました。彼らはベル研に戻り、廃棄同然のDEC PDP-7という小型のコンピュータの上に OSを書きます
<ref>Ken ThompsonはMultics上で動いていたスペースゲームをベル研に持ち帰ってきたはいいがのですが、遊ぶのに適当なマシンがなかったので放置されていたDEC PDP-7を使い始めたと言われています。 </ref>。
1968年のことです。それはMULTICSのような大きなスペックを持つOSではなく、もっとコンパクトなOSなので、彼らはMULTICSをもじってUNICSと命名します。後にUNICSはUNIXと改名し、そのままの名前が定着します。

たまに『UNIXはMULTICSの否定である』とか、その反対に『MULTICSの後継がUNIXである』とか書いてある説明を見かけます。これは正しくもあり間違ってもいます。思い出して欲しいのですが今日的なOSの基礎となる沢山のアイデアが導入されているのがMULTICSです。つまり今日的なOSの多くのアイデアそのものはMULTICSを源流にもちます。ただし、MULTICSは、たくさんのアイデアをつめこんだためにシステムが肥大化しプロジェクト自体は失敗に終っています。

もちろん今日的OSであるUNIXにはMULTICSの数々のアイデアが採り入れています。しかしながらUNIXはMULTICSの最大の特徴(かつ致命的な問題となっていた)である多目的で複雑である部分を否定しています。言うまでもないですがUNIXはMULTICSをもう一度作ろうとしたものでもありません。もしUNIXと MULTICSの関係性を表現するとするならば「MULTICSの失敗を教訓にしたOS」と言えるでしょう。

ちなみにMULTICSが複雑で大きなOSでUNIXがシンプルで小さいOSだったというのは初期のUNIXを指していうことであって、現在の基準では当てはまりません。その後のUNIXは肥大化の道を歩んでいます。

現在、UNIXを作ったKen ThompsonやDennis Ritchieといったベル研の人達は既にUNIXは利用せずPlan9という異なるタイプの新しいOSを開発し、利用しています。

=== BSDへの分岐 ===

PDP-7の上で産声をあげたUNIXは、まだ正式なバージョンが付けられていません。ですから、正確にはまだUNIXではないとしてカッコつきで(PDP-7)として分類している本もあります。First Editionと呼ばれるのは、PDP-11/20上で動き始めたUNIXからです。それまでアセンブラで書かれていたUNIXがCで書き換えられFourth Editionとなります。

どうしてEditionという言葉を使っているかというと、ベル研究でのバージョンはマニュアルのバージョンで区別しているのだそうです。なぜなら、いつもUNIXのソースコードに手を入れていたため常にソースコードが変わっていてソースコードでのバージョン管理は不可能だったためだそうです。唯一のバージョンコントロールというのはマニュアルだったというわけです。一般には Sixth Edition と言わずにV6 (Version 6)という具合にVersion を使う方を目にする方が多いかも知れません。

1976年のSixth EditionをベースとしてUNIXはPWB3.0とBSDが分岐します。PWB はProgrammer Work Banechの略です。この流れは、後にSystem IIIへつながります。BSDはBerkeley Software Distributionsの略で、UCB (University of California Berkeley)のCSRG (Computer System Research Group)で作られていました。

1BSDと呼ばれる、最初のバージョンはPDP-11上で動いていました。これが2BSD になり2.xBSDになります(xは1,2,3といった数字が入ります)。2.xはPDP-11をプラットフォームにしています。

一方、2BSDからVAXで動く3BSDに分岐し、後に4.0BSDになります。以降、 4.1BSD、4.2BSD、4.3BSD、4.4BSDとなります。もともとのUNIXのプログラムワークベンチとしての使い勝手の良さはもとより、CSRGで加えられた仮想記憶の能力、高速なファイルシステム、TCP/IPの実装プラットフォーム
<ref>これらの研究は国防総省傘下の研究組織であるDARPAからの研究資金の援助で開発されています。</ref>
などの数々の最新技術の投入によるアドバンテージにより、BSDは研究所や大学を中心に急速に広がります。

BSD自体は自由にコピーできるのですがベル研で作られたコードが含まれていますので、UNIXを動かすにはAT&Tへのライセンス費用が発生しました。この1980年代前半、AT&Tへのライセンス費用は研究施設では配布実費程度($800)、商用サイトでは($43000)でした。しかしながら高額な科学計算用コンピュータ VAXを所有している所では、この料金は大した問題ではありませんでした。

最後のリリースが4.4BSDです。ここでCSRGでのBSDの研究開発は終了します。この頃になるとBSDは技術的に研究と呼べる部分が少なくなってきたのは確かですが、それ以上にAT&Tとライセンセンス問題がこじれて研究者の中のモチベーションが保てなくなったのではと筆者は考えています。

1992年1月、UNIXライセンスを管理するAT&Tの子会社URL社が4.3BSD NET/2をベースに商用BSDを作ったBSDI社を相手に製品出荷差し止め訴訟をおこします。それが判事に却下されたので、今度はUCBとBSDIの両方を相手に製品出荷差し止め訴訟を繰り広げます。また裁判途中でURL社がAT&Tからノベル社に買収されたりとったこともあって、なかなか訴訟も、和解案も進みません。やっとのこと1994年の1月に解決します。

貴重なCSRGメンバーの労力が、このバカバカしい訴訟で浪費されたといっても過言ではありません。1995年6月の4.4BSD-Lite Release 2を最後にCSRGは解散します。もちろん表向きは「新しい時代、新しい人達へのバトンタッチ」ですが、実際は、この世にもバカバカしい訴訟で燃え尽きたといっても過言ではないでしょう。

=== まぼろしのSystem IV ===

Sixth Editionから分岐してPWBが作られます。ベル研にはリサーチとは関係のないUNIXをソフトウエアの開発のために使おうというグループがあって、そこがUNIXをプログラマーのための道具として使うためのに改良しました。 1979年のことです。これがPWB/UNIX 1.0として研究所の外部にもライセンスされるようになります。PWBから分岐して1982年にSystem IIIが作られます。PWB はその後何度かバージョンがアップされますが、1984年にSystem V Relase 2 に統合されます。

一般市場向けに販売された最初のAT&TブランドUNIXがSystem IIIです。筆者は1983,4年頃にCPUにMC68000を使ったNCR社製マシンでSystem IIIを使った経験があります。GUIもネットワークもありませんが、使い心地は今のLinuxや FreeBSDなとどおなじです。

その後、後継バージョンとしてSystem Vが出てきます。System IVという名前は幻になっています。実は発売寸前までSystem IVは進んでいたのですが、その内容のひどさにUNIXを生み出したベル研のメンバーは激怒し「今後一切関係はない」といって、マニュアルなどすべてから名前の削除を求めたそうです。それでSystem IVは余儀なく大量の変更が発生し、発売できなくなりました。
世界最大のUNIXベンダマイクロソフト
1980年代前半、世界で最もUNIXの出荷が多かったのは実はマイクロソフト社でした。その頃、SCO (Santa Cruz Operation)社と共同でマイクロソフトは XENIXというIntel 8086上で動くUNIXのバージョンを作成していました。その頃、他はVAXのような大きなマシンばかりでしたので、出荷数から見るとXENIX の数が最大のように見えるのです。

=== UNIXの人口爆発 ===

1985年から1995年までの10年間は、色々なバージョンのUNIXが増殖した時代といえるでしょう。UNIXの流行とともに、色々な会社が色々なUNIXを実装して売り出していきます。日本でも通産省の大失敗プロジェクトであるΣプロジェクトが行われていた頃です。色々な会社のUNIXマシンを製造し、少しでも自分のシェアを独占しようと奔走していたころです。このような背景があってAT&Tが BSDIの邪魔をし、その邪魔ができないと見るやいなや、UCBも含めて訴えていた頃です。なんと情けない時代でしょう。そんなAT&Tや他の企業のドタバタも 95年以降は鎮静化します。理由は簡単です。Windows がディスクトップUNIXのシェアを食い、Windows NTがサーバのシェアを食ったからです。

== Linux ==
=== Linuxの誕生前夜 ===

Linuxが生まれる1991年前夜、既にOSのトレンドは新しい世界に入っていました。それはマイクロカーネル技術を使ったOSです。マイクロカーネルのポイントは提供するサービスと、最小限のコントロールのみしか残していない小さなカーネルから出来上がっている所です。最小限のコントロールとは、メモリ、タスク、プロセス間通信、(最小限必要なハードウェアの)デバイスドライバなどです。ファイルシステム、ネットワーク機能、プロセス管理、仮想記憶管理などなどはサーバプログラムとして動作しています。それまでのUNIXカーネルはOSが果たすべき機能はすべて1つのカーネル内で行われているモノリシック・カーネルとよばれるタイプでした。

=== Linux誕生 ===

フィンランドの大学生 Linus Torvaldsが1991年にLinux version 0.02をリリースしました。1994年にLinux 1.0をリリースしました。 Linuxを一躍有名にしたのは、使い勝手でもなく、新規性でもなく、処理能力でもありません。1992年にあったネットニュース上での大喧嘩でした。

=== Torvalds vs. Tanenbaum ===

1992年にcomp.os.minixで行われたLinuxの生みの親Torvaldsとオペーレーティングシステム研究者の大御所Tanenbaum教授との論争です。"Linux is obsolete"というタイトルで書いた教授の記事の趣旨は「90年代に70年代の技術であるモノリシックカーネルであること」「ポータビリティに欠けること」の2点です。これは
オープンソフトウェア<ref>http://www.oreilly.com/catalog/opensources/book/appa.html</ref>
(オライリージャパン)に収録されいるので、みなさんも是非1度目を通されることをお勧めします。

正直に筆者の意見をいうと教授の言い分は正しいです。ただし、その時代遅れな構造こそがLinuxに味方しました。誰もが知っている時代遅れの枯れた技術を使ったからこそLinuxのカーネルをハックできる人口が多く、そしてまた実現方針も建てやすく、早く簡単に作れたといえます。

マイクロカーネルはモノリシック・カーネルよりオーバーヘッドが発生し処理効率が落ちると言われていますが、これはLinuxができてきた91年であっても古い話です。80年代後半ごろマイクロカーネルの草分けであるMachはのオーバーヘッドの問題はありましたが90年に入るとマイクロカーネル技術は既に、その問題を克服しています。いまだにこの「マイクロカーネルは遅い」という神話を信じている人がいて驚くことがあります。

またマイクロカーネルの提供する「粒度」というモノリシックカーネルでは存在しえない概念も入っています。ここでの粒度とはマイクロカーネルが実行する処理のサイズだと考えてください。マイクロカーネルはこの粒度という処理を分散する考え方を導入しているためたとえばCPUを何十、何百、何千個搭載した並行処理マシン上で1つ1つのCPUでマイクロカーネルが各々動き、個々のタスクが割り当て、さらに全体としてプロセスを管理するプロセス管理サーバがあるような実装が可能になります。たぶん、このようなことをしたいために日立の並列スーパーコンピュータ SR8000シリーズの OS は Machをベースとしたマイクロカーネルで実装しています。

Windows NTもマイクロカーネルで作られているので同じような効果がでます。たとえばCOMPAQ ProLiant 8500というマルチプロセッサマシンを多数と Microsoft Windows 2000 Advanced Server と Microsoft SQL Server 2000 Enterpriseの組合せでデータベースのベンチマークであるTPC-Cの最高レコードを何度か書き換えています。

2とか4程度のプロセッサ数ならモノリシックカーネルでも使えるでしょうが、このようなプロセッサ数が多いマルチプロセッサマシンでは上手に動けません(このような劇的なパフォーマンスが出る実装はまだ存在していません)。

== LinuxはUNIXではない ==

こう書くと混乱する人がいるかも知れません。まずLinuxはUNIXではありません。BSDにしても、他の多くのUNIXベンダのOSにしても、前身となるUNIXシステムがあるものがほとんどです。その前身をたどっていくと、最後はベル研の UNIXにたどり着きます。Linuxは、その流れから完全に独立しています。現在のLinuxの原点は、今や伝説ともなったLinus Torvaldsというフィンランドの1 大学生が386CPUベースのPC上で勉強のために作り始めたものです。それ以前をひきついでいません。LinuxはLinuxから出発しているのです。つまり元祖なのです。これは、かなりユニークなポジションにいます。たとえばThe Design and Implementation of the 4.4BSD Operating SystemのHistory of the UNIX Systemの章にあるUNIXの家系図を見ると、前身がないOSはPlan9とLinuxしかありません。家系図の解釈にはいろいろな流儀があり、たとえばPlan9がUNIX V8から分岐したとか、Linuxがminixから分岐したと表現しているものがあります。しかし、影響を受けたというならまたしも、これらのあいだではソースコードの流用はありません。

=== LinuxはUNIX互換ではない ===

LinuxはUNIX互換として作られたわけではなくPOSIX 1003.1仕様のOSです。 POSIX 1003.1とはポータブルOSの互換性を保つための規格です。POSIX 1003.1 はUNIXを参考にして作られていますがUNIXの規格ではありません。よって POSIX 1003.1準拠のOSであるLinuxはUNIX互換ではないということです。

=== LinuxはLinuxではない ===

システムはカーネルだけあっても、何もサービスはできません。サービスを行うためのソフトウェア環境が揃って始めてシステムとなります。その取り巻く環境をミドルウェアと呼ぶ場合もありますが、ここではもっと広い意味でユーザにサービスを提供する総体としてシステムと呼びます。Linuxはカーネルです。そのカーネル上でサービスを提供するための数々のソフトウエアはフリーソフトウェアであるGNUが使われています。よってシステムとして呼ぶ場合は GNU/Linuxと呼ぶのが正しい呼び方です。

=== Linuxは新しいOSなのか ===

誕生した時期は「新しい」と言えますが、その中身の構造は非常に「古典的」です。それはTanenbaumがLinuxを切捨てた通りです。ではLinuxの目標は何なのでしょうか?それは「POSIX準拠した本格的な機能を持ったフリーのOSを作ること」だと言えます。技術的野心に燃えて新しいことをするのではなく、自分達が自由に使えるOSを作るということが明確だったのです。

Torvaldsは最初は、そんなに目標が明確だったわけではなかったと思います。しかし、Torvalds vs. Tanenbaumの論争の中でLinuxの方向性は決っていきます。それは完全にフリーソフトウェアであること、将来の発展よりまず現在のマシン上で十分に動かせることです。

フリーソフトウェア運動の指導者リチャード・ストールマンがGNUプロジェクトの性質に対してこういったのを筆者は聞いたことがあります。「GNUソフトウェアはわくわくするような新しいものを研究し画期的なソフトウェアを生みだすためのプロジェクトではない。ソフトウェアをフリーなものに置き換えるむしろ後追いの地味なプロジェクトだ」

=== なぜLinuxがこれだけ広まったか ===

Linuxが現れた頃、既に同様にフリーである386BSDがありました。しかしLinux の開発の方が一歩リードしていたようです。FSFの機関誌であったGNUダイジェストのバックログをおってみるとよくわかります。386BSDとLinuxがGNUダイジェスト(GNU's Bulletin)に紹介されるのは、1992年6月発行の13号です。<ref> GNU's Bulletinは次のURLから入手できます。ftp://ftp.sra.co.jp/pub/gnu/sra/Bull-j/ アクセス出来ない場合はコピー版を参照ください。 http://uc2.h2np.net/misc/bull13j.txt</ref>

GNUダイジェスト1992年6月号から引用してみましょう。

<BLOCKQUOTE>
* Linux (386マシン用のフリーなUnixシステム)
:Linux (Linus Torvalds にちなんで名前が付けられた) は、フリーな Unix システムのクーロンであり、System V や POSIX の機能のサブセットを実現する。 Linux はまったく最初から作成され、カーネル内には独占的なコードを含まない。非常に多くのユーティリティやライブラリは、GNU ソフトウェアを使っている。 Linux は 386/486 AT バスマシンでのみ動作する。Intel 386 以外への移植は非常に困難であろう。カーネルで広範囲に、386 メモリ管理システムやタスク・プリミティブを使っているからである。Linux は次のサイトから anonymous FTP で入手可能である。`tsx-11.mit.edu:/pub/linux' (アメリカ)、 `nic.funet.fi:/pub/OS/Linux' (ヨーロッパ)。 Linus に関して討論する `comp.os.linux' というニュース・グループがある。メイリング・リストに関する問い合わせは `linux-activists-request@niksula.hut.fi' まで。

* フリーな 386 BSD
:経験のあるハッカーは、William F. Jolitz らによって移植された BSD Unix の 386 へ移植したバージョンのアルファ・テストに興味を抱くかもしれない。このカーネルは AT&T コードを含まないフリーなもので、自由に再配布可能である。詳細な情報は `sokol@reyes.stanford.edu' から入手可能である。初期のバージョンは安定していないので、あるシステムではブート時に問題が発生する点に注意されたい。
</BLOCKQUOTE>

ここからわかるのは、386BSDよりもLinuxの方が安定して動作していることと、既にftpサーバが用意されていて、誰でも容易に入手できる体制がアナウンスされていたことです。

この文章からもLinuxはIntel CPUアーキテクチャーにべっとり依存していたことがわかります。この頃のUNIXユーザはパワーのないPCアーキテクチャーのマシン、いわゆるパソコンなど使わず、SUNやVAXといったワークステーションを使っていました。

教科書通りの考え方だと単一アーキテクチャーしか使えないOSかつ、パワーないCPU上でしか動かないOSなので魅力がなさそうに見えます。ところが、実際は既にたくさんのPCが世の中に存在していて、かつ、その後のウインテルと揶揄されるWindowsとIntel CPUの組合せでIntel CPUの能力が格段に発達しました。その時流にLinuxはちょうど乗っかったのです。

386BSDは4.3BSD NET/2からブランチしています。ここが利用者を躊躇させる1 つの要因になったようにみえます。既に本家4.3BSD NET/2は4.4BSDへアップするための作業が進んでいました。その後、386BSDはFreeBSDとNetBSDという2つにカーネルが分岐してしまいます。また本家4.4BSD自体がIntel CPUをサポートする予定です。

このような状況でユーザはどれがステーブルなBSDであるかを選択できるでしょうか。筆者なら386BSD(FreeBSDやNetBSD)を選択しません。4.4BSDまで待ちます。一方で、今、手元にあるPCでフリーのUNIXを使いたいと思ったら? 筆者なら将来のマップが見えない386BSDよりもLinuxを選びます。筆者の目からみれば、出発点で技術的に不利と思われていたLinuxですが、今振り返ると広がるべくして広がったように見えます。

== 1994年以降 ==

1994年以降のLinuxの繁栄に関しては筆者よりもきっとSoftwareDesignの読者のみなさんの方が色々な情報を知っていると思います。ではLinuxの現代史は、また別の機会に。

== 脚注 ==

<references/>

----
[[目次]]へ

OS誕生からLinuxまでの歴史

2014-02-11T14:43:11Z

UnixWikiMaster: /* なぜLinuxがこれだけ広まったか */

; 注意: 本文は1994年にソフトウェアデザイン誌に連載していたOS入門の原稿をベースにしています。ですからこの文章は1994年当時の状況をベースにしてかかれています。現在ではGNU/Linuxをシステム全体、Linuxをカーネルと区別しますが、本文中ではGNU/LinuxシステムをLinuxと呼んでいます。これは1994年当時の状況をそのまま残しているためです。

== OS誕生 ==

OSの歴史は、コンピュータが産まれてから20年ほど経った1960年代中期からスタートします。1960年中期にIBMが開発した商用コンピュータ・システム IBM System/360は、本格的なOS (OS/360)を搭載していました。それ以前のコンピュータ・システムは、部分的にはOSとしての機能を満たしたものがありますが、OS として機能及び概念が確立はしていません。IBM System/360が始めてOSの機能と概念を確立させました。

:60年代のアメリカは公民権運動、ベトナム反戦運動、ウッドストックなどを後世に残すと同時にOSも後世に残したのでした。

それまでのIBMのコンピュータは、そのハードウェアの製品ライン毎にソフトウェアが必要で、各々の製品ラインの違うコンピュータ・システムには、ソフトウェアの互換性がありませんでした。

これは、私たちが現在、アプリケーション・プログラムと呼んでいるような、ある特定目的のために動作するソフトウェアが、OSというクッションを持たず、システム全体のソフトウェアと密接に絡み合っていたからです。つまり、アプリケーションがリソースを管理しなければならなかったのです。

例えば、事務には事務専用システムおよびソフトウェアを、科学計算には科学技術専用システムおよびソフトウェアを用意していました。また、同じ専用システムでも最大メモリやプロセッサのスピード、IOデバイスの数などのシステムの構成が違えば、それだけでソフトウェアの互換性は保てませんでした。

OSを導入することによってリソース管理をアプリケーションから切り離します。以前のシステム構成に特化したソフトウェアしか動かないコンピュータ・システムの世界から今度は色々なソフトウェアを動かすことができる、汎用なコンピュータ・システム世界に変化していきます。

その後System 360は、370、4300、3080、3090といったIBMシリーズに続き継がれます。それらのシステムは『汎用機』と呼ばれるコンピュータ・システムの代表です。

=== MULTICSも忘れちゃいけない ===

同世代で、忘れてはいけないのがタイムシアリング・システムと呼ばれる処理方法を用いたCTSSと、それに引き続く今日のOSの原型でともいえるMULTICS<ref>http://www.multicians.org/</ref><ref>http://web.mit.edu/multics-history/</ref> です。CTSSは1963年にMITで使われていた原始的なOSでIBM System / 360よりも古いIBM 7094というシステム上で実現されています。

タイムシアリング・システムとは、複数のユーザが実行している各々のプログラムの処理をある一定時間毎(あるいは入出力が発生しI/O待ちになった場合)に切替えて、各々のユーザがあたかも同時に1つのコンピュータを使っているかのように見せかせるシステムです。

CTSSのプログラムの切替えは非常に単純です。ユーザの動かしているプログラムをまるごと主記憶装置から補助記憶装置に追い出し、次に動かすプログラムをロードしてくるというものでした<ref>これは、まだマルチプログラミングまで進化していません。混同しやすいので要注意のこと。 </ref>。複数のプログラムを切替える能力はありましたが、リソース管理という点では、OSと呼ぶには十分ではありません。

CTSSがうまくいったので1965年にMITとAT&Tベル研究所とジェネラル・エレクトリック社
<ref>当時のジェネラル・エレクトリックは大手コンピュータ・メーカーであった。 </ref>
が、共同で、現在のOSと比較しても見劣りしないような数々のスペックを持った、多目的なOSを作ろうとしました。それがMULTICSです。現在、私たちがOSの機能と呼んでいる数々の機能はMULTICSで現れたものです。

がしかし、1965年当時それらを実現するにはそもそもハードウェアの能力が足りませんし
<ref>あまりに古くて、正確な資料がないのですが、MULTICSのターゲット・ハードウェアだったGE-645の処理パワーは、i386マシンぐらいだったようです。 </ref>
、それだけのアイデアを完全に実現するだけのソフトウェア技術もまだ存在しないという、かなり無謀なプロジェクトでした。

途中でベル研がプロジェクトから抜け、ジェネラル・エレクトリック社がコンピュータ市場自体から撤退しました。MULTICSはその後、MIT内部と数十のサイトで利用されました。おどろくことに細々とまだ存在しているのですが、多くの人の記憶からは既に消え去ってしまっています。しかしMULTICSで考えられた数々のアイデア、例えば、仮想記憶、プロセスの概念、プロテクションの概念、他にも多くの重要なアイデアが、今日のOSの中に生きています。

== UNIX誕生! ==

MULTICSプロジェクトにはベル研のKen ThompsonとDennis Ritchieがいました。彼らはベル研に戻り、廃棄同然のDEC PDP-7という小型のコンピュータの上に OSを書きます
<ref>Ken ThompsonはMultics上で動いていたスペースゲームをベル研に持ち帰ってきたはいいがのですが、遊ぶのに適当なマシンがなかったので放置されていたDEC PDP-7を使い始めたと言われています。 </ref>。
1968年のことです。それはMULTICSのような大きなスペックを持つOSではなく、もっとコンパクトなOSなので、彼らはMULTICSをもじってUNICSと命名します。後にUNICSはUNIXと改名し、そのままの名前が定着します。

たまに『UNIXはMULTICSの否定である』とか、その反対に『MULTICSの後継がUNIXである』とか書いてある説明を見かけます。これは正しくもあり間違ってもいます。思い出して欲しいのですが今日的なOSの基礎となる沢山のアイデアが導入されているのがMULTICSです。つまり今日的なOSの多くのアイデアそのものはMULTICSを源流にもちます。ただし、MULTICSは、たくさんのアイデアをつめこんだためにシステムが肥大化しプロジェクト自体は失敗に終っています。

もちろん今日的OSであるUNIXにはMULTICSの数々のアイデアが採り入れています。しかしながらUNIXはMULTICSの最大の特徴(かつ致命的な問題となっていた)である多目的で複雑である部分を否定しています。言うまでもないですがUNIXはMULTICSをもう一度作ろうとしたものでもありません。もしUNIXと MULTICSの関係性を表現するとするならば「MULTICSの失敗を教訓にしたOS」と言えるでしょう。

ちなみにMULTICSが複雑で大きなOSでUNIXがシンプルで小さいOSだったというのは初期のUNIXを指していうことであって、現在の基準では当てはまりません。その後のUNIXは肥大化の道を歩んでいます。

現在、UNIXを作ったKen ThompsonやDennis Ritchieといったベル研の人達は既にUNIXは利用せずPlan9という異なるタイプの新しいOSを開発し、利用しています。

=== BSDへの分岐 ===

PDP-7の上で産声をあげたUNIXは、まだ正式なバージョンが付けられていません。ですから、正確にはまだUNIXではないとしてカッコつきで(PDP-7)として分類している本もあります。First Editionと呼ばれるのは、PDP-11/20上で動き始めたUNIXからです。それまでアセンブラで書かれていたUNIXがCで書き換えられFourth Editionとなります。

どうしてEditionという言葉を使っているかというと、ベル研究でのバージョンはマニュアルのバージョンで区別しているのだそうです。なぜなら、いつもUNIXのソースコードに手を入れていたため常にソースコードが変わっていてソースコードでのバージョン管理は不可能だったためだそうです。唯一のバージョンコントロールというのはマニュアルだったというわけです。一般には Sixth Edition と言わずにV6 (Version 6)という具合にVersion を使う方を目にする方が多いかも知れません。

1976年のSixth EditionをベースとしてUNIXはPWB3.0とBSDが分岐します。PWB はProgrammer Work Banechの略です。この流れは、後にSystem IIIへつながります。BSDはBerkeley Software Distributionsの略で、UCB (University of California Berkeley)のCSRG (Computer System Research Group)で作られていました。

1BSDと呼ばれる、最初のバージョンはPDP-11上で動いていました。これが2BSD になり2.xBSDになります(xは1,2,3といった数字が入ります)。2.xはPDP-11をプラットフォームにしています。

一方、2BSDからVAXで動く3BSDに分岐し、後に4.0BSDになります。以降、 4.1BSD、4.2BSD、4.3BSD、4.4BSDとなります。もともとのUNIXのプログラムワークベンチとしての使い勝手の良さはもとより、CSRGで加えられた仮想記憶の能力、高速なファイルシステム、TCP/IPの実装プラットフォーム
<ref>これらの研究は国防総省傘下の研究組織であるDARPAからの研究資金の援助で開発されています。</ref>
などの数々の最新技術の投入によるアドバンテージにより、BSDは研究所や大学を中心に急速に広がります。

BSD自体は自由にコピーできるのですがベル研で作られたコードが含まれていますので、UNIXを動かすにはAT&Tへのライセンス費用が発生しました。この1980年代前半、AT&Tへのライセンス費用は研究施設では配布実費程度($800)、商用サイトでは($43000)でした。しかしながら高額な科学計算用コンピュータ VAXを所有している所では、この料金は大した問題ではありませんでした。

最後のリリースが4.4BSDです。ここでCSRGでのBSDの研究開発は終了します。この頃になるとBSDは技術的に研究と呼べる部分が少なくなってきたのは確かですが、それ以上にAT&Tとライセンセンス問題がこじれて研究者の中のモチベーションが保てなくなったのではと筆者は考えています。

1992年1月、UNIXライセンスを管理するAT&Tの子会社URL社が4.3BSD NET/2をベースに商用BSDを作ったBSDI社を相手に製品出荷差し止め訴訟をおこします。それが判事に却下されたので、今度はUCBとBSDIの両方を相手に製品出荷差し止め訴訟を繰り広げます。また裁判途中でURL社がAT&Tからノベル社に買収されたりとったこともあって、なかなか訴訟も、和解案も進みません。やっとのこと1994年の1月に解決します。

貴重なCSRGメンバーの労力が、このバカバカしい訴訟で浪費されたといっても過言ではありません。1995年6月の4.4BSD-Lite Release 2を最後にCSRGは解散します。もちろん表向きは「新しい時代、新しい人達へのバトンタッチ」ですが、実際は、この世にもバカバカしい訴訟で燃え尽きたといっても過言ではないでしょう。

=== まぼろしのSystem IV ===

Sixth Editionから分岐してPWBが作られます。ベル研にはリサーチとは関係のないUNIXをソフトウエアの開発のために使おうというグループがあって、そこがUNIXをプログラマーのための道具として使うためのに改良しました。 1979年のことです。これがPWB/UNIX 1.0として研究所の外部にもライセンスされるようになります。PWBから分岐して1982年にSystem IIIが作られます。PWB はその後何度かバージョンがアップされますが、1984年にSystem V Relase 2 に統合されます。

一般市場向けに販売された最初のAT&TブランドUNIXがSystem IIIです。筆者は1983,4年頃にCPUにMC68000を使ったNCR社製マシンでSystem IIIを使った経験があります。GUIもネットワークもありませんが、使い心地は今のLinuxや FreeBSDなとどおなじです。

その後、後継バージョンとしてSystem Vが出てきます。System IVという名前は幻になっています。実は発売寸前までSystem IVは進んでいたのですが、その内容のひどさにUNIXを生み出したベル研のメンバーは激怒し「今後一切関係はない」といって、マニュアルなどすべてから名前の削除を求めたそうです。それでSystem IVは余儀なく大量の変更が発生し、発売できなくなりました。
世界最大のUNIXベンダマイクロソフト
1980年代前半、世界で最もUNIXの出荷が多かったのは実はマイクロソフト社でした。その頃、SCO (Santa Cruz Operation)社と共同でマイクロソフトは XENIXというIntel 8086上で動くUNIXのバージョンを作成していました。その頃、他はVAXのような大きなマシンばかりでしたので、出荷数から見るとXENIX の数が最大のように見えるのです。

=== UNIXの人口爆発 ===

1985年から1995年までの10年間は、色々なバージョンのUNIXが増殖した時代といえるでしょう。UNIXの流行とともに、色々な会社が色々なUNIXを実装して売り出していきます。日本でも通産省の大失敗プロジェクトであるΣプロジェクトが行われていた頃です。色々な会社のUNIXマシンを製造し、少しでも自分のシェアを独占しようと奔走していたころです。このような背景があってAT&Tが BSDIの邪魔をし、その邪魔ができないと見るやいなや、UCBも含めて訴えていた頃です。なんと情けない時代でしょう。そんなAT&Tや他の企業のドタバタも 95年以降は鎮静化します。理由は簡単です。Windows がディスクトップUNIXのシェアを食い、Windows NTがサーバのシェアを食ったからです。

== Linux ==
=== Linuxの誕生前夜 ===

Linuxが生まれる1991年前夜、既にOSのトレンドは新しい世界に入っていました。それはマイクロカーネル技術を使ったOSです。マイクロカーネルのポイントは提供するサービスと、最小限のコントロールのみしか残していない小さなカーネルから出来上がっている所です。最小限のコントロールとは、メモリ、タスク、プロセス間通信、(最小限必要なハードウェアの)デバイスドライバなどです。ファイルシステム、ネットワーク機能、プロセス管理、仮想記憶管理などなどはサーバプログラムとして動作しています。それまでのUNIXカーネルはOSが果たすべき機能はすべて1つのカーネル内で行われているモノリシック・カーネルとよばれるタイプでした。

=== Linux誕生 ===

フィンランドの大学生 Linus Torvaldsが1991年にLinux version 0.02をリリースしました。1994年にLinux 1.0をリリースしました。 Linuxを一躍有名にしたのは、使い勝手でもなく、新規性でもなく、処理能力でもありません。1992年にあったネットニュース上での大喧嘩でした。

=== Torvalds vs. Tanenbaum ===

1992年にcomp.os.minixで行われたLinuxの生みの親Torvaldsとオペーレーティングシステム研究者の大御所Tanenbaum教授との論争です。"Linux is obsolete"というタイトルで書いた教授の記事の趣旨は「90年代に70年代の技術であるモノリシックカーネルであること」「ポータビリティに欠けること」の2点です。これは
オープンソフトウェア<ref>http://www.oreilly.com/catalog/opensources/book/appa.html</ref>
(オライリージャパン)に収録されいるので、みなさんも是非1度目を通されることをお勧めします。

正直に筆者の意見をいうと教授の言い分は正しいです。ただし、その時代遅れな構造こそがLinuxに味方しました。誰もが知っている時代遅れの枯れた技術を使ったからこそLinuxのカーネルをハックできる人口が多く、そしてまた実現方針も建てやすく、早く簡単に作れたといえます。

マイクロカーネルはモノリシック・カーネルよりオーバーヘッドが発生し処理効率が落ちると言われていますが、これはLinuxができてきた91年であっても古い話です。80年代後半ごろマイクロカーネルの草分けであるMachはのオーバーヘッドの問題はありましたが90年に入るとマイクロカーネル技術は既に、その問題を克服しています。いまだにこの「マイクロカーネルは遅い」という神話を信じている人がいて驚くことがあります。

またマイクロカーネルの提供する「粒度」というモノリシックカーネルでは存在しえない概念も入っています。ここでの粒度とはマイクロカーネルが実行する処理のサイズだと考えてください。マイクロカーネルはこの粒度という処理を分散する考え方を導入しているためたとえばCPUを何十、何百、何千個搭載した並行処理マシン上で1つ1つのCPUでマイクロカーネルが各々動き、個々のタスクが割り当て、さらに全体としてプロセスを管理するプロセス管理サーバがあるような実装が可能になります。たぶん、このようなことをしたいために日立の並列スーパーコンピュータ SR8000シリーズの OS は Machをベースとしたマイクロカーネルで実装しています。

Windows NTもマイクロカーネルで作られているので同じような効果がでます。たとえばCOMPAQ ProLiant 8500というマルチプロセッサマシンを多数と Microsoft Windows 2000 Advanced Server と Microsoft SQL Server 2000 Enterpriseの組合せでデータベースのベンチマークであるTPC-Cの最高レコードを何度か書き換えています。

2とか4程度のプロセッサ数ならモノリシックカーネルでも使えるでしょうが、このようなプロセッサ数が多いマルチプロセッサマシンでは上手に動けません(このような劇的なパフォーマンスが出る実装はまだ存在していません)。

== LinuxはUNIXではない ==

こう書くと混乱する人がいるかも知れません。まずLinuxはUNIXではありません。BSDにしても、他の多くのUNIXベンダのOSにしても、前身となるUNIXシステムがあるものがほとんどです。その前身をたどっていくと、最後はベル研の UNIXにたどり着きます。Linuxは、その流れから完全に独立しています。現在のLinuxの原点は、今や伝説ともなったLinus Torvaldsというフィンランドの1 大学生が386CPUベースのPC上で勉強のために作り始めたものです。それ以前をひきついでいません。LinuxはLinuxから出発しているのです。つまり元祖なのです。これは、かなりユニークなポジションにいます。たとえばThe Design and Implementation of the 4.4BSD Operating SystemのHistory of the UNIX Systemの章にあるUNIXの家系図を見ると、前身がないOSはPlan9とLinuxしかありません。家系図の解釈にはいろいろな流儀があり、たとえばPlan9がUNIX V8から分岐したとか、Linuxがminixから分岐したと表現しているものがあります。しかし、影響を受けたというならまたしも、これらのあいだではソースコードの流用はありません。

=== LinuxはUNIX互換ではない ===

LinuxはUNIX互換として作られたわけではなくPOSIX 1003.1仕様のOSです。 POSIX 1003.1とはポータブルOSの互換性を保つための規格です。POSIX 1003.1 はUNIXを参考にして作られていますがUNIXの規格ではありません。よって POSIX 1003.1準拠のOSであるLinuxはUNIX互換ではないということです。

=== LinuxはLinuxではない ===

システムはカーネルだけあっても、何もサービスはできません。サービスを行うためのソフトウェア環境が揃って始めてシステムとなります。その取り巻く環境をミドルウェアと呼ぶ場合もありますが、ここではもっと広い意味でユーザにサービスを提供する総体としてシステムと呼びます。Linuxはカーネルです。そのカーネル上でサービスを提供するための数々のソフトウエアはフリーソフトウェアであるGNUが使われています。よってシステムとして呼ぶ場合は GNU/Linuxと呼ぶのが正しい呼び方です。

=== Linuxは新しいOSなのか ===

誕生した時期は「新しい」と言えますが、その中身の構造は非常に「古典的」です。それはTanenbaumがLinuxを切捨てた通りです。ではLinuxの目標は何なのでしょうか?それは「POSIX準拠した本格的な機能を持ったフリーのOSを作ること」だと言えます。技術的野心に燃えて新しいことをするのではなく、自分達が自由に使えるOSを作るということが明確だったのです。

Torvaldsは最初は、そんなに目標が明確だったわけではなかったと思います。しかし、Torvalds vs. Tanenbaumの論争の中でLinuxの方向性は決っていきます。それは完全にフリーソフトウェアであること、将来の発展よりまず現在のマシン上で十分に動かせることです。

フリーソフトウェア運動の指導者リチャード・ストールマンがGNUプロジェクトの性質に対してこういったのを筆者は聞いたことがあります。「GNUソフトウェアはわくわくするような新しいものを研究し画期的なソフトウェアを生みだすためのプロジェクトではない。ソフトウェアをフリーなものに置き換えるむしろ後追いの地味なプロジェクトだ」

=== なぜLinuxがこれだけ広まったか ===

Linuxが現れた頃、既に同様にフリーである386BSDがありました。しかしLinux の開発の方が一歩リードしていたようです。FSFの機関誌であったGNUダイジェストのバックログをおってみるとよくわかります。386BSDとLinuxがGNUダイジェスト(GNU's Bulletin)に紹介されるのは、1992年6月発行の13号です。<ref> GNU's Bulletinは次のURLから入手できます。ftp://ftp.sra.co.jp/pub/gnu/sra/Bull-j/</ref>

GNUダイジェスト1992年6月号から引用してみましょう。

<BLOCKQUOTE>
* Linux (386マシン用のフリーなUnixシステム)
:Linux (Linus Torvalds にちなんで名前が付けられた) は、フリーな Unix システムのクーロンであり、System V や POSIX の機能のサブセットを実現する。 Linux はまったく最初から作成され、カーネル内には独占的なコードを含まない。非常に多くのユーティリティやライブラリは、GNU ソフトウェアを使っている。 Linux は 386/486 AT バスマシンでのみ動作する。Intel 386 以外への移植は非常に困難であろう。カーネルで広範囲に、386 メモリ管理システムやタスク・プリミティブを使っているからである。Linux は次のサイトから anonymous FTP で入手可能である。`tsx-11.mit.edu:/pub/linux' (アメリカ)、 `nic.funet.fi:/pub/OS/Linux' (ヨーロッパ)。 Linus に関して討論する `comp.os.linux' というニュース・グループがある。メイリング・リストに関する問い合わせは `linux-activists-request@niksula.hut.fi' まで。

* フリーな 386 BSD
:経験のあるハッカーは、William F. Jolitz らによって移植された BSD Unix の 386 へ移植したバージョンのアルファ・テストに興味を抱くかもしれない。このカーネルは AT&T コードを含まないフリーなもので、自由に再配布可能である。詳細な情報は `sokol@reyes.stanford.edu' から入手可能である。初期のバージョンは安定していないので、あるシステムではブート時に問題が発生する点に注意されたい。
</BLOCKQUOTE>

ここからわかるのは、386BSDよりもLinuxの方が安定して動作していることと、既にftpサーバが用意されていて、誰でも容易に入手できる体制がアナウンスされていたことです。

この文章からもLinuxはIntel CPUアーキテクチャーにべっとり依存していたことがわかります。この頃のUNIXユーザはパワーのないPCアーキテクチャーのマシン、いわゆるパソコンなど使わず、SUNやVAXといったワークステーションを使っていました。

教科書通りの考え方だと単一アーキテクチャーしか使えないOSかつ、パワーないCPU上でしか動かないOSなので魅力がなさそうに見えます。ところが、実際は既にたくさんのPCが世の中に存在していて、かつ、その後のウインテルと揶揄されるWindowsとIntel CPUの組合せでIntel CPUの能力が格段に発達しました。その時流にLinuxはちょうど乗っかったのです。

386BSDは4.3BSD NET/2からブランチしています。ここが利用者を躊躇させる1 つの要因になったようにみえます。既に本家4.3BSD NET/2は4.4BSDへアップするための作業が進んでいました。その後、386BSDはFreeBSDとNetBSDという2つにカーネルが分岐してしまいます。また本家4.4BSD自体がIntel CPUをサポートする予定です。

このような状況でユーザはどれがステーブルなBSDであるかを選択できるでしょうか。筆者なら386BSD(FreeBSDやNetBSD)を選択しません。4.4BSDまで待ちます。一方で、今、手元にあるPCでフリーのUNIXを使いたいと思ったら? 筆者なら将来のマップが見えない386BSDよりもLinuxを選びます。筆者の目からみれば、出発点で技術的に不利と思われていたLinuxですが、今振り返ると広がるべくして広がったように見えます。

== 1994年以降 ==

1994年以降のLinuxの繁栄に関しては筆者よりもきっとSoftwareDesignの読者のみなさんの方が色々な情報を知っていると思います。ではLinuxの現代史は、また別の機会に。

== 脚注 ==

<references/>

----
[[目次]]へ

OS誕生からLinuxまでの歴史

2014-02-11T14:37:53Z

UnixWikiMaster: /* MULTICSも忘れちゃいけない */

; 注意: 本文は1994年にソフトウェアデザイン誌に連載していたOS入門の原稿をベースにしています。ですからこの文章は1994年当時の状況をベースにしてかかれています。現在ではGNU/Linuxをシステム全体、Linuxをカーネルと区別しますが、本文中ではGNU/LinuxシステムをLinuxと呼んでいます。これは1994年当時の状況をそのまま残しているためです。

== OS誕生 ==

OSの歴史は、コンピュータが産まれてから20年ほど経った1960年代中期からスタートします。1960年中期にIBMが開発した商用コンピュータ・システム IBM System/360は、本格的なOS (OS/360)を搭載していました。それ以前のコンピュータ・システムは、部分的にはOSとしての機能を満たしたものがありますが、OS として機能及び概念が確立はしていません。IBM System/360が始めてOSの機能と概念を確立させました。

:60年代のアメリカは公民権運動、ベトナム反戦運動、ウッドストックなどを後世に残すと同時にOSも後世に残したのでした。

それまでのIBMのコンピュータは、そのハードウェアの製品ライン毎にソフトウェアが必要で、各々の製品ラインの違うコンピュータ・システムには、ソフトウェアの互換性がありませんでした。

これは、私たちが現在、アプリケーション・プログラムと呼んでいるような、ある特定目的のために動作するソフトウェアが、OSというクッションを持たず、システム全体のソフトウェアと密接に絡み合っていたからです。つまり、アプリケーションがリソースを管理しなければならなかったのです。

例えば、事務には事務専用システムおよびソフトウェアを、科学計算には科学技術専用システムおよびソフトウェアを用意していました。また、同じ専用システムでも最大メモリやプロセッサのスピード、IOデバイスの数などのシステムの構成が違えば、それだけでソフトウェアの互換性は保てませんでした。

OSを導入することによってリソース管理をアプリケーションから切り離します。以前のシステム構成に特化したソフトウェアしか動かないコンピュータ・システムの世界から今度は色々なソフトウェアを動かすことができる、汎用なコンピュータ・システム世界に変化していきます。

その後System 360は、370、4300、3080、3090といったIBMシリーズに続き継がれます。それらのシステムは『汎用機』と呼ばれるコンピュータ・システムの代表です。

=== MULTICSも忘れちゃいけない ===

同世代で、忘れてはいけないのがタイムシアリング・システムと呼ばれる処理方法を用いたCTSSと、それに引き続く今日のOSの原型でともいえるMULTICS<ref>http://www.multicians.org/</ref><ref>http://web.mit.edu/multics-history/</ref> です。CTSSは1963年にMITで使われていた原始的なOSでIBM System / 360よりも古いIBM 7094というシステム上で実現されています。

タイムシアリング・システムとは、複数のユーザが実行している各々のプログラムの処理をある一定時間毎(あるいは入出力が発生しI/O待ちになった場合)に切替えて、各々のユーザがあたかも同時に1つのコンピュータを使っているかのように見せかせるシステムです。

CTSSのプログラムの切替えは非常に単純です。ユーザの動かしているプログラムをまるごと主記憶装置から補助記憶装置に追い出し、次に動かすプログラムをロードしてくるというものでした<ref>これは、まだマルチプログラミングまで進化していません。混同しやすいので要注意のこと。 </ref>。複数のプログラムを切替える能力はありましたが、リソース管理という点では、OSと呼ぶには十分ではありません。

CTSSがうまくいったので1965年にMITとAT&Tベル研究所とジェネラル・エレクトリック社
<ref>当時のジェネラル・エレクトリックは大手コンピュータ・メーカーであった。 </ref>
が、共同で、現在のOSと比較しても見劣りしないような数々のスペックを持った、多目的なOSを作ろうとしました。それがMULTICSです。現在、私たちがOSの機能と呼んでいる数々の機能はMULTICSで現れたものです。

がしかし、1965年当時それらを実現するにはそもそもハードウェアの能力が足りませんし
<ref>あまりに古くて、正確な資料がないのですが、MULTICSのターゲット・ハードウェアだったGE-645の処理パワーは、i386マシンぐらいだったようです。 </ref>
、それだけのアイデアを完全に実現するだけのソフトウェア技術もまだ存在しないという、かなり無謀なプロジェクトでした。

途中でベル研がプロジェクトから抜け、ジェネラル・エレクトリック社がコンピュータ市場自体から撤退しました。MULTICSはその後、MIT内部と数十のサイトで利用されました。おどろくことに細々とまだ存在しているのですが、多くの人の記憶からは既に消え去ってしまっています。しかしMULTICSで考えられた数々のアイデア、例えば、仮想記憶、プロセスの概念、プロテクションの概念、他にも多くの重要なアイデアが、今日のOSの中に生きています。

== UNIX誕生! ==

MULTICSプロジェクトにはベル研のKen ThompsonとDennis Ritchieがいました。彼らはベル研に戻り、廃棄同然のDEC PDP-7という小型のコンピュータの上に OSを書きます
<ref>Ken ThompsonはMultics上で動いていたスペースゲームをベル研に持ち帰ってきたはいいがのですが、遊ぶのに適当なマシンがなかったので放置されていたDEC PDP-7を使い始めたと言われています。 </ref>。
1968年のことです。それはMULTICSのような大きなスペックを持つOSではなく、もっとコンパクトなOSなので、彼らはMULTICSをもじってUNICSと命名します。後にUNICSはUNIXと改名し、そのままの名前が定着します。

たまに『UNIXはMULTICSの否定である』とか、その反対に『MULTICSの後継がUNIXである』とか書いてある説明を見かけます。これは正しくもあり間違ってもいます。思い出して欲しいのですが今日的なOSの基礎となる沢山のアイデアが導入されているのがMULTICSです。つまり今日的なOSの多くのアイデアそのものはMULTICSを源流にもちます。ただし、MULTICSは、たくさんのアイデアをつめこんだためにシステムが肥大化しプロジェクト自体は失敗に終っています。

もちろん今日的OSであるUNIXにはMULTICSの数々のアイデアが採り入れています。しかしながらUNIXはMULTICSの最大の特徴(かつ致命的な問題となっていた)である多目的で複雑である部分を否定しています。言うまでもないですがUNIXはMULTICSをもう一度作ろうとしたものでもありません。もしUNIXと MULTICSの関係性を表現するとするならば「MULTICSの失敗を教訓にしたOS」と言えるでしょう。

ちなみにMULTICSが複雑で大きなOSでUNIXがシンプルで小さいOSだったというのは初期のUNIXを指していうことであって、現在の基準では当てはまりません。その後のUNIXは肥大化の道を歩んでいます。

現在、UNIXを作ったKen ThompsonやDennis Ritchieといったベル研の人達は既にUNIXは利用せずPlan9という異なるタイプの新しいOSを開発し、利用しています。

=== BSDへの分岐 ===

PDP-7の上で産声をあげたUNIXは、まだ正式なバージョンが付けられていません。ですから、正確にはまだUNIXではないとしてカッコつきで(PDP-7)として分類している本もあります。First Editionと呼ばれるのは、PDP-11/20上で動き始めたUNIXからです。それまでアセンブラで書かれていたUNIXがCで書き換えられFourth Editionとなります。

どうしてEditionという言葉を使っているかというと、ベル研究でのバージョンはマニュアルのバージョンで区別しているのだそうです。なぜなら、いつもUNIXのソースコードに手を入れていたため常にソースコードが変わっていてソースコードでのバージョン管理は不可能だったためだそうです。唯一のバージョンコントロールというのはマニュアルだったというわけです。一般には Sixth Edition と言わずにV6 (Version 6)という具合にVersion を使う方を目にする方が多いかも知れません。

1976年のSixth EditionをベースとしてUNIXはPWB3.0とBSDが分岐します。PWB はProgrammer Work Banechの略です。この流れは、後にSystem IIIへつながります。BSDはBerkeley Software Distributionsの略で、UCB (University of California Berkeley)のCSRG (Computer System Research Group)で作られていました。

1BSDと呼ばれる、最初のバージョンはPDP-11上で動いていました。これが2BSD になり2.xBSDになります(xは1,2,3といった数字が入ります)。2.xはPDP-11をプラットフォームにしています。

一方、2BSDからVAXで動く3BSDに分岐し、後に4.0BSDになります。以降、 4.1BSD、4.2BSD、4.3BSD、4.4BSDとなります。もともとのUNIXのプログラムワークベンチとしての使い勝手の良さはもとより、CSRGで加えられた仮想記憶の能力、高速なファイルシステム、TCP/IPの実装プラットフォーム
<ref>これらの研究は国防総省傘下の研究組織であるDARPAからの研究資金の援助で開発されています。</ref>
などの数々の最新技術の投入によるアドバンテージにより、BSDは研究所や大学を中心に急速に広がります。

BSD自体は自由にコピーできるのですがベル研で作られたコードが含まれていますので、UNIXを動かすにはAT&Tへのライセンス費用が発生しました。この1980年代前半、AT&Tへのライセンス費用は研究施設では配布実費程度($800)、商用サイトでは($43000)でした。しかしながら高額な科学計算用コンピュータ VAXを所有している所では、この料金は大した問題ではありませんでした。

最後のリリースが4.4BSDです。ここでCSRGでのBSDの研究開発は終了します。この頃になるとBSDは技術的に研究と呼べる部分が少なくなってきたのは確かですが、それ以上にAT&Tとライセンセンス問題がこじれて研究者の中のモチベーションが保てなくなったのではと筆者は考えています。

1992年1月、UNIXライセンスを管理するAT&Tの子会社URL社が4.3BSD NET/2をベースに商用BSDを作ったBSDI社を相手に製品出荷差し止め訴訟をおこします。それが判事に却下されたので、今度はUCBとBSDIの両方を相手に製品出荷差し止め訴訟を繰り広げます。また裁判途中でURL社がAT&Tからノベル社に買収されたりとったこともあって、なかなか訴訟も、和解案も進みません。やっとのこと1994年の1月に解決します。

貴重なCSRGメンバーの労力が、このバカバカしい訴訟で浪費されたといっても過言ではありません。1995年6月の4.4BSD-Lite Release 2を最後にCSRGは解散します。もちろん表向きは「新しい時代、新しい人達へのバトンタッチ」ですが、実際は、この世にもバカバカしい訴訟で燃え尽きたといっても過言ではないでしょう。

=== まぼろしのSystem IV ===

Sixth Editionから分岐してPWBが作られます。ベル研にはリサーチとは関係のないUNIXをソフトウエアの開発のために使おうというグループがあって、そこがUNIXをプログラマーのための道具として使うためのに改良しました。 1979年のことです。これがPWB/UNIX 1.0として研究所の外部にもライセンスされるようになります。PWBから分岐して1982年にSystem IIIが作られます。PWB はその後何度かバージョンがアップされますが、1984年にSystem V Relase 2 に統合されます。

一般市場向けに販売された最初のAT&TブランドUNIXがSystem IIIです。筆者は1983,4年頃にCPUにMC68000を使ったNCR社製マシンでSystem IIIを使った経験があります。GUIもネットワークもありませんが、使い心地は今のLinuxや FreeBSDなとどおなじです。

その後、後継バージョンとしてSystem Vが出てきます。System IVという名前は幻になっています。実は発売寸前までSystem IVは進んでいたのですが、その内容のひどさにUNIXを生み出したベル研のメンバーは激怒し「今後一切関係はない」といって、マニュアルなどすべてから名前の削除を求めたそうです。それでSystem IVは余儀なく大量の変更が発生し、発売できなくなりました。
世界最大のUNIXベンダマイクロソフト
1980年代前半、世界で最もUNIXの出荷が多かったのは実はマイクロソフト社でした。その頃、SCO (Santa Cruz Operation)社と共同でマイクロソフトは XENIXというIntel 8086上で動くUNIXのバージョンを作成していました。その頃、他はVAXのような大きなマシンばかりでしたので、出荷数から見るとXENIX の数が最大のように見えるのです。

=== UNIXの人口爆発 ===

1985年から1995年までの10年間は、色々なバージョンのUNIXが増殖した時代といえるでしょう。UNIXの流行とともに、色々な会社が色々なUNIXを実装して売り出していきます。日本でも通産省の大失敗プロジェクトであるΣプロジェクトが行われていた頃です。色々な会社のUNIXマシンを製造し、少しでも自分のシェアを独占しようと奔走していたころです。このような背景があってAT&Tが BSDIの邪魔をし、その邪魔ができないと見るやいなや、UCBも含めて訴えていた頃です。なんと情けない時代でしょう。そんなAT&Tや他の企業のドタバタも 95年以降は鎮静化します。理由は簡単です。Windows がディスクトップUNIXのシェアを食い、Windows NTがサーバのシェアを食ったからです。

== Linux ==
=== Linuxの誕生前夜 ===

Linuxが生まれる1991年前夜、既にOSのトレンドは新しい世界に入っていました。それはマイクロカーネル技術を使ったOSです。マイクロカーネルのポイントは提供するサービスと、最小限のコントロールのみしか残していない小さなカーネルから出来上がっている所です。最小限のコントロールとは、メモリ、タスク、プロセス間通信、(最小限必要なハードウェアの)デバイスドライバなどです。ファイルシステム、ネットワーク機能、プロセス管理、仮想記憶管理などなどはサーバプログラムとして動作しています。それまでのUNIXカーネルはOSが果たすべき機能はすべて1つのカーネル内で行われているモノリシック・カーネルとよばれるタイプでした。

=== Linux誕生 ===

フィンランドの大学生 Linus Torvaldsが1991年にLinux version 0.02をリリースしました。1994年にLinux 1.0をリリースしました。 Linuxを一躍有名にしたのは、使い勝手でもなく、新規性でもなく、処理能力でもありません。1992年にあったネットニュース上での大喧嘩でした。

=== Torvalds vs. Tanenbaum ===

1992年にcomp.os.minixで行われたLinuxの生みの親Torvaldsとオペーレーティングシステム研究者の大御所Tanenbaum教授との論争です。"Linux is obsolete"というタイトルで書いた教授の記事の趣旨は「90年代に70年代の技術であるモノリシックカーネルであること」「ポータビリティに欠けること」の2点です。これは
オープンソフトウェア<ref>http://www.oreilly.com/catalog/opensources/book/appa.html</ref>
(オライリージャパン)に収録されいるので、みなさんも是非1度目を通されることをお勧めします。

正直に筆者の意見をいうと教授の言い分は正しいです。ただし、その時代遅れな構造こそがLinuxに味方しました。誰もが知っている時代遅れの枯れた技術を使ったからこそLinuxのカーネルをハックできる人口が多く、そしてまた実現方針も建てやすく、早く簡単に作れたといえます。

マイクロカーネルはモノリシック・カーネルよりオーバーヘッドが発生し処理効率が落ちると言われていますが、これはLinuxができてきた91年であっても古い話です。80年代後半ごろマイクロカーネルの草分けであるMachはのオーバーヘッドの問題はありましたが90年に入るとマイクロカーネル技術は既に、その問題を克服しています。いまだにこの「マイクロカーネルは遅い」という神話を信じている人がいて驚くことがあります。

またマイクロカーネルの提供する「粒度」というモノリシックカーネルでは存在しえない概念も入っています。ここでの粒度とはマイクロカーネルが実行する処理のサイズだと考えてください。マイクロカーネルはこの粒度という処理を分散する考え方を導入しているためたとえばCPUを何十、何百、何千個搭載した並行処理マシン上で1つ1つのCPUでマイクロカーネルが各々動き、個々のタスクが割り当て、さらに全体としてプロセスを管理するプロセス管理サーバがあるような実装が可能になります。たぶん、このようなことをしたいために日立の並列スーパーコンピュータ SR8000シリーズの OS は Machをベースとしたマイクロカーネルで実装しています。

Windows NTもマイクロカーネルで作られているので同じような効果がでます。たとえばCOMPAQ ProLiant 8500というマルチプロセッサマシンを多数と Microsoft Windows 2000 Advanced Server と Microsoft SQL Server 2000 Enterpriseの組合せでデータベースのベンチマークであるTPC-Cの最高レコードを何度か書き換えています。

2とか4程度のプロセッサ数ならモノリシックカーネルでも使えるでしょうが、このようなプロセッサ数が多いマルチプロセッサマシンでは上手に動けません(このような劇的なパフォーマンスが出る実装はまだ存在していません)。

== LinuxはUNIXではない ==

こう書くと混乱する人がいるかも知れません。まずLinuxはUNIXではありません。BSDにしても、他の多くのUNIXベンダのOSにしても、前身となるUNIXシステムがあるものがほとんどです。その前身をたどっていくと、最後はベル研の UNIXにたどり着きます。Linuxは、その流れから完全に独立しています。現在のLinuxの原点は、今や伝説ともなったLinus Torvaldsというフィンランドの1 大学生が386CPUベースのPC上で勉強のために作り始めたものです。それ以前をひきついでいません。LinuxはLinuxから出発しているのです。つまり元祖なのです。これは、かなりユニークなポジションにいます。たとえばThe Design and Implementation of the 4.4BSD Operating SystemのHistory of the UNIX Systemの章にあるUNIXの家系図を見ると、前身がないOSはPlan9とLinuxしかありません。家系図の解釈にはいろいろな流儀があり、たとえばPlan9がUNIX V8から分岐したとか、Linuxがminixから分岐したと表現しているものがあります。しかし、影響を受けたというならまたしも、これらのあいだではソースコードの流用はありません。

=== LinuxはUNIX互換ではない ===

LinuxはUNIX互換として作られたわけではなくPOSIX 1003.1仕様のOSです。 POSIX 1003.1とはポータブルOSの互換性を保つための規格です。POSIX 1003.1 はUNIXを参考にして作られていますがUNIXの規格ではありません。よって POSIX 1003.1準拠のOSであるLinuxはUNIX互換ではないということです。

=== LinuxはLinuxではない ===

システムはカーネルだけあっても、何もサービスはできません。サービスを行うためのソフトウェア環境が揃って始めてシステムとなります。その取り巻く環境をミドルウェアと呼ぶ場合もありますが、ここではもっと広い意味でユーザにサービスを提供する総体としてシステムと呼びます。Linuxはカーネルです。そのカーネル上でサービスを提供するための数々のソフトウエアはフリーソフトウェアであるGNUが使われています。よってシステムとして呼ぶ場合は GNU/Linuxと呼ぶのが正しい呼び方です。

=== Linuxは新しいOSなのか ===

誕生した時期は「新しい」と言えますが、その中身の構造は非常に「古典的」です。それはTanenbaumがLinuxを切捨てた通りです。ではLinuxの目標は何なのでしょうか?それは「POSIX準拠した本格的な機能を持ったフリーのOSを作ること」だと言えます。技術的野心に燃えて新しいことをするのではなく、自分達が自由に使えるOSを作るということが明確だったのです。

Torvaldsは最初は、そんなに目標が明確だったわけではなかったと思います。しかし、Torvalds vs. Tanenbaumの論争の中でLinuxの方向性は決っていきます。それは完全にフリーソフトウェアであること、将来の発展よりまず現在のマシン上で十分に動かせることです。

フリーソフトウェア運動の指導者リチャード・ストールマンがGNUプロジェクトの性質に対してこういったのを筆者は聞いたことがあります。「GNUソフトウェアはわくわくするような新しいものを研究し画期的なソフトウェアを生みだすためのプロジェクトではない。ソフトウェアをフリーなものに置き換えるむしろ後追いの地味なプロジェクトだ」

=== なぜLinuxがこれだけ広まったか ===

Linuxが現れた頃、既に同様にフリーである386BSDがありました。しかしLinux の開発の方が一歩リードしていたようです。FSFの機関誌であったGNUダイジェストのバックログをおってみるとよくわかります。386BSDとLinuxがGNUダイジェスト(GNU's Bulletin)に紹介されるのは、1992年6月発行の13号です。 GNU's Bulletinは次のURLから入手できます。 ftp://ftp.sra.co.jp/pub/gnu/sra/Bull-j/

GNUダイジェスト1992年6月号から引用してみましょう。

<BLOCKQUOTE>
* Linux (386マシン用のフリーなUnixシステム)
:Linux (Linus Torvalds にちなんで名前が付けられた) は、フリーな Unix システムのクーロンであり、System V や POSIX の機能のサブセットを実現する。 Linux はまったく最初から作成され、カーネル内には独占的なコードを含まない。非常に多くのユーティリティやライブラリは、GNU ソフトウェアを使っている。 Linux は 386/486 AT バスマシンでのみ動作する。Intel 386 以外への移植は非常に困難であろう。カーネルで広範囲に、386 メモリ管理システムやタスク・プリミティブを使っているからである。Linux は次のサイトから anonymous FTP で入手可能である。`tsx-11.mit.edu:/pub/linux' (アメリカ)、 `nic.funet.fi:/pub/OS/Linux' (ヨーロッパ)。 Linus に関して討論する `comp.os.linux' というニュース・グループがある。メイリング・リストに関する問い合わせは `linux-activists-request@niksula.hut.fi' まで。

* フリーな 386 BSD
:経験のあるハッカーは、William F. Jolitz らによって移植された BSD Unix の 386 へ移植したバージョンのアルファ・テストに興味を抱くかもしれない。このカーネルは AT&T コードを含まないフリーなもので、自由に再配布可能である。詳細な情報は `sokol@reyes.stanford.edu' から入手可能である。初期のバージョンは安定していないので、あるシステムではブート時に問題が発生する点に注意されたい。
</BLOCKQUOTE>

ここからわかるのは、386BSDよりもLinuxの方が安定して動作していることと、既にftpサーバが用意されていて、誰でも容易に入手できる体制がアナウンスされていたことです。

この文章からもLinuxはIntel CPUアーキテクチャーにべっとり依存していたことがわかります。この頃のUNIXユーザはパワーのないPCアーキテクチャーのマシン、いわゆるパソコンなど使わず、SUNやVAXといったワークステーションを使っていました。

教科書通りの考え方だと単一アーキテクチャーしか使えないOSかつ、パワーないCPU上でしか動かないOSなので魅力がなさそうに見えます。ところが、実際は既にたくさんのPCが世の中に存在していて、かつ、その後のウインテルと揶揄されるWindowsとIntel CPUの組合せでIntel CPUの能力が格段に発達しました。その時流にLinuxはちょうど乗っかったのです。

386BSDは4.3BSD NET/2からブランチしています。ここが利用者を躊躇させる1 つの要因になったようにみえます。既に本家4.3BSD NET/2は4.4BSDへアップするための作業が進んでいました。その後、386BSDはFreeBSDとNetBSDという2つにカーネルが分岐してしまいます。また本家4.4BSD自体がIntel CPUをサポートする予定です。

このような状況でユーザはどれがステーブルなBSDであるかを選択できるでしょうか。筆者なら386BSD(FreeBSDやNetBSD)を選択しません。4.4BSDまで待ちます。一方で、今、手元にあるPCでフリーのUNIXを使いたいと思ったら? 筆者なら将来のマップが見えない386BSDよりもLinuxを選びます。筆者の目からみれば、出発点で技術的に不利と思われていたLinuxですが、今振り返ると広がるべくして広がったように見えます。

== 1994年以降 ==

1994年以降のLinuxの繁栄に関しては筆者よりもきっとSoftwareDesignの読者のみなさんの方が色々な情報を知っていると思います。ではLinuxの現代史は、また別の機会に。

== 脚注 ==

<references/>

----
[[目次]]へ

TCP/IP

2014-02-11T14:12:33Z

UnixWikiMaster:

== まずはじめに ==

本章でのTCP/IPの取り上げるスタンスについて説明します。
本章では、UNIXとTCP/IPの関係性を取り上げ、GNU/Linuxの中でどう扱われているかの議論を試みます。TCP/IP自体の説明、また、インターネット自体の説明は本章の趣旨ではないので本章では扱いません。またTCP/IPに関する基本知識(例えば 3 way handshakeなど)は既に学習しているものとして話を進めます。

GNU/LinuxはTCP/IPだけではなく、Appletalk、DECNETなど多数のプロトコルをサポートしていますが、本章では主要な論点であるTCP/IPのみ取り上げます。

== UNIXとTCP/IP ==

TCP/IPとは1970年代初頭にDRAPAの研究成果として既に出来上がったネットワーク通信用プロトコルで、元々はUNIXにはなかった機能です。米カリフォルニア大学バークレー校の研究グループ<ref>What, a real UNIX®? http://www.freebsd.org/doc/en/articles/explaining-bsd/what-a-real-unix.html</ref>がDARPAからの研究資金を得て、4.1bBSD(1982年8月)に対してBBN Technologiesで実装されていたTCP/IPコードをベースとして組入れるという作業が始まり4.2BSDで正式にTCP/IPを含んでリリース(1983年8月)となりました。ここでは「BBNの実装ベースで」とあっさり書いていますが、実際にはもうちょっと複雑な話になっています。
<ref>
詳しくは Open Sources: Voices from the Open Source Revolution に納められているMarshall Kirk McKusickが書いたTwenty Years of Berkeley Unix From AT&T-Owned to Freely Redistributable を読むことをお勧めします。
</ref>

TCP/IPというとインターネット用プロトコルというイメージがありますが、当時のBSDの実装はイーサーネット接続されたLANやキャンパスネットワークで高速に情報を伝達するのに適したものになっています。一方でオリジナルのBBNの実装は広域なネットワークであるインターネットで使うことを前提としているもので、そのため80年代当時の低速なネットワーク向けに作られています。このようにターゲットとなるネットワークの前提が違うため、BBNの実装をそのままBSDに組み込んだような単純な話ではありません。

この期間でのエポックとしては1983年1月1日にARPANETの公式プロトコルはTCP/IPに切り替わっています。 <ref> 核戦争にも耐えうる軍事ネットワークを作るためにインターネットを作ったという俗説がまことしやかに流れていますが、そのような事実はありません。Internet Society のサイトにある [http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet Brief History of the Internet] に目を通して正しいインターネットの歴史の全体像を知っておきましょう。 </ref> 当時TCP/IPの実装を持っていたオペレーティング・システムはそんなに多くはなく、BSDの他の名の知れたシステムはDEC社のTOPS-20 system <ref> http://panda.com/tops-20/ by Mark Crispin </ref> ぐらいです。当時、DARPAの資金で開発した、他に参考となる実装が多くなく、ソースコードが公開されているなどのいくつかの要因により実質BSDがコンピュータにおけるTCP/IPのリファレンス実装となっていました。

リファレンス実装であったというおもしろい傍証は1997-8年頃に問題となった [http://en.wikipedia.org/wiki/Ping_of_death Ping of Death] のケースが良いかも知れません。これは規定外サイズのICMPパケットを脆弱性を持つシステムに送るとオペレーティングシステムごとハングアップしてしまうというものです。そもそもの原因はBSDのコードがパケットの分割を考えていなかった実装だったからです。分割されるケースを設計時点で考慮に入れなかったある意味、単純なバグで、そんなに深い意味はありません。もし、IPパケットとICMPパケットの仕様<ref>[http://tools.ietf.org/html/rfc791 RFC791]</ref>だけで作っていたら設計時に考慮し、この脆弱性はたぶん現れないでしょう。しかし実際にはGNU/LinuxだけではなくMacintoshやWindowsにも同じ脆弱性が現れました。このことから仕様ドキュメントから設計をしたわけではなく、商用のオペレーティングシステムもオープンなコードであるBSDのTCP/IPコードをリファレンスとしていたのではないかといわれています。

Xerox PARCで開発されたイーサーネット、TCP/IP、そしてBSDの組み合わせによって構築されたLANがARPANET経由でエンド・ツー・エンドで接続し広域ネットワークを構築してしまうという当時は技術的にかなり画期的な仕組みであり、これこそ今日私たちがインターネットと呼んでいるものそのものです。ですからUNIXの存在はインターネットの大きな礎としての存在であったといっても決して過言ではありません。

=== Internet Protocol Suite ===

BSD由来のTCP/IPの特徴は、クライアントだけでなく、サーバだけでもなく、ルーターだけでもない、TCP/IPの機能一式をもったInternet Protocol Suiteの実装であるということです。つまり、UNIXはサーバとしても使え、クライアントとしても使え、そしてまたルーターとしても使えるということです。もちろんその上で動作するアプリケーションは、TCP/IPの機能をフルに使うことができます。

GNU/Linuxベースのサーバーやクライアントはインターネットにおける日常の風景的な部分ではありますが、形をかえて組み込み系でも市販のルータの中身がGNU/Linuxベースであったりするものよく見かけます。もちろんGNU/Linuxは、Internet Protocol Suiteで一式揃えているので、サーバとクライアントとルータやブリッジを同時に兼ねることも当然可能です。

典型的なのがGNU/Linux上で動作するバーチャルマシン・モニタXenのネットワーク構成です。Xenのドメイン0 (他の仮想マシンを動かすためのベースとなる環境）では、内部的にブリッジの機能を作り、ドメインU（個々の仮想マシン）からはそこに仮想的に接続する形を取りネットワークを形成します。このために特別なプロトコルスタックを用意するわけではありません。既にGNU/Linuxには必要なネットワークの能力が用意されているのです。

一般にTCP/IPのようなプロトコルが重ねられている構造のことをプロトコルスタック ( Protocol Stack ) と呼びます。
そして各々のプロトコルのメカニズムあるいは実装のことを、その層のスタック、たとえばTCPであればTCPスタック、IPであればIPスタックと呼びます。意味は、TCPの層だけではなく、その下層も含めたメカニズムあるいは実装をさしています。

== GNU/Linux での TCP/IP ==

まずEthernetを前提に基本的な部分を説明したいと思います。
GNU/LinuxではEthernetのデバイスは基本的にeth0から順番に割り当てられます。
むかしはNIC (Network Interface Card)に対応するデバイスファイル /dev/eth0 というのがあったのですが、今ではそれが存在せず内部的にeth0、eth1という仮想的なネットワークデバイスになっています。
慣用的にloはローカルホスト、eth0はEternet、wlan0は無線LANの仮想ネットワークデバイスとして命名されていますが、これは任意な名前であり、たとえば、新たにPPP (シリアル経由でpoint-to-point接続するプロトコル)で接続を作る時はppp0や、 easytether (AndroidをUSBで接続しテザリングをするツールを利用)など仮想ネットワークデバイスは自由度の高い名前をつけることができます。同種類のデバイスが増えるたびに番数が増えます(eth0, eth1, ... )。

* lo ローカルホストのための仮想ネットワークデバイス
* eth0 Ethernetのための仮想ネットワークデバイス
* wlan0 無線LANのための仮想ネットワークデバイス

その仮想ネットワークデバイスにIPアドレスを設定しTCP/IPで利用する形にします。

=== ifconfig ===

仮想ネットワークデバイスにTCP/IPに必要なパラメータを設定するのはifconfigコマンドです。これは米カリフォルニア大学バークレー校でBSDに組み込んだTCP/IPの実装が作られた時に、IPアドレスやネットマスクなどのパラメータを設定する、あるいは参照するのに作られたコマンドですが、そのまま今もスタイルを変えず使われています。グラフィカルインタフェース〜といっても項目をリストアップする程度のものですが〜を使って設定するツールは存在しますが、システムがブートする段階でIPの制御を行うのがifconfigです。

低いレベルでコントロールする方法を理解したい、あるいはツールを作成したいと思った時は netdevice のオンラインマニュアルにヒントがあります。

/sbin/ifconfigをオプションなしに実行すると、現在のeth0やloが表示されます。

$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:15:c5:41:95:a0
inet addr:192.168.100.18 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::215:c5ff:fe41:95a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:350974 errors:0 dropped:0 overruns:0 frame:0
TX packets:291913 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:329347998 (329.3 MB) TX bytes:36362966 (36.3 MB)
Interrupt:18
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:340 (340.0 B) TX bytes:340 (340.0 B)

仮想ネットワークデバイスeth0はEthernetに接続され、IPアドレス192.168.100.18が設定されています。

loはローカルホストです。これは127.0.0.1が割り当てられます。127.0.0.1は特殊なアドレスでこれは自分自身のマシンを指します。
ホスト名はlocalhostとなっています。

ブート時にはIPアドレスの設定などifconfigコマンドを使っています。デスクトップやノートパソコン、特にモバイルのように色々なネットワーク上で動作させるようなコンピュータはDHCP
<ref>
ISC DHCP
https://www.isc.org/downloads/dhcp/
ここにDHCPのリファレンス実装があります。
</ref>
を使ってそのネットワーク上で自動割り当てされるのが一般的ですが、ここではまず固定IPの話から進めましょう。

# ifconfig eth0 up

これはeth0のインタフェースを利用可能にします。

# ifconfig eth0 192.168.201.3/24

こう実行することによってeth0にはIPアドレス192.168.1.3、ブロードキャスト:192.168.1.255、マスク:255.255.255.0が設定されます。

ここではeth0に設定していますが物理的に1つのNICに複数のIPアドレスを付与できます。
むかしならNIC(network interface card)に1つのIPアドレスしか付加できませんでしたが、
複数のIPアドレスが設定する場合、eth0:1、eth0:2といった形でMACアドレスが同じである
eth0のインタフェースが作られます。

$ sudo ifconfig eth0:1 192.168.100.99/24
$ ifconfig eth0:1
ifconfig eth0:1
eth0:1 Link encap:イーサネットハードウェアアドレス 14:da:e9:71:cd:35
inetアドレス:192.168.100.99 ブロードキャスト:192.168.100.255 マスク:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 メトリック:1
割り込み:47 ベースアドレス:0xc000

(TBD)

== 脚注 ==
<references/>
----
[[目次]]へ

TCP/IP

2014-02-11T14:09:24Z

UnixWikiMaster: /* ifconfig */

== まずはじめに ==

本章でのTCP/IPの取り上げるスタンスについて説明します。
本章では、UNIXとTCP/IPの関係性を取り上げ、GNU/Linuxの中でどう扱われているかの議論を試みます。TCP/IP自体の説明、また、インターネット自体の説明は本章の趣旨ではないので本章では扱いません。またTCP/IPに関する基本知識(例えば 3 way handshakeなど)は既に学習しているものとして話を進めます。

GNU/LinuxはTCP/IPだけではなく、Appletalk、DECNETなど多数のプロトコルをサポートしていますが、本章では主要な論点であるTCP/IPのみ取り上げます。

== UNIXとTCP/IP ==

TCP/IPとは1970年代初頭にDRAPAの研究成果として既に出来上がったネットワーク通信用プロトコルで、元々はUNIXにはなかった機能です。DARPAからの研究資金を得て、4.1bBSD(1982年8月)に対してBBN Technologiesで実装されていたTCP/IPコードをベースとして組入れるという作業が始まり4.2BSDで正式にTCP/IPを含んでリリース(1983年8月)となりました。ここでは「BBNの実装ベースで」とあっさり書いていますが、実際にはもうちょっと複雑な話になっています。
<ref>
詳しくは Open Sources: Voices from the Open Source Revolution に納められているMarshall Kirk McKusickが書いたTwenty Years of Berkeley Unix From AT&T-Owned to Freely Redistributable を読むことをお勧めします。
</ref>

TCP/IPというとインターネット用プロトコルというイメージがありますが、当時のBSDの実装はイーサーネット接続されたLANやキャンパスネットワークで高速に情報を伝達するのに適したものになっています。一方でオリジナルのBBNの実装は広域なネットワークであるインターネットで使うことを前提としているもので、そのため80年代当時の低速なネットワーク向けに作られています。このようにターゲットとなるネットワークの前提が違うため、BBNの実装をそのままBSDに組み込んだような単純な話ではありません。

この期間でのエポックとしては1983年1月1日にARPANETの公式プロトコルはTCP/IPに切り替わっています。 <ref> 核戦争にも耐えうる軍事ネットワークを作るためにインターネットを作ったという俗説がまことしやかに流れていますが、そのような事実はありません。Internet Society のサイトにある [http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet Brief History of the Internet] に目を通して正しいインターネットの歴史の全体像を知っておきましょう。 </ref> 当時TCP/IPの実装を持っていたオペレーティング・システムはそんなに多くはなく、BSDの他の名の知れたシステムはDEC社のTOPS-20 system <ref> http://panda.com/tops-20/ by Mark Crispin </ref> ぐらいです。当時、DARPAの資金で開発した、他に参考となる実装が多くなく、ソースコードが公開されているなどのいくつかの要因により実質BSDがコンピュータにおけるTCP/IPのリファレンス実装となっていました。

リファレンス実装であったというおもしろい傍証は1997-8年頃に問題となった [http://en.wikipedia.org/wiki/Ping_of_death Ping of Death] のケースが良いかも知れません。これは規定外サイズのICMPパケットを脆弱性を持つシステムに送るとオペレーティングシステムごとハングアップしてしまうというものです。そもそもの原因はBSDのコードがパケットの分割を考えていなかった実装だったからです。分割されるケースを設計時点で考慮に入れなかったある意味、単純なバグで、そんなに深い意味はありません。もし、IPパケットとICMPパケットの仕様<ref>[http://tools.ietf.org/html/rfc791 RFC791]</ref>だけで作っていたら設計時に考慮し、この脆弱性はたぶん現れないでしょう。しかし実際にはGNU/LinuxだけではなくMacintoshやWindowsにも同じ脆弱性が現れました。このことから仕様ドキュメントから設計をしたわけではなく、商用のオペレーティングシステムもオープンなコードであるBSDのTCP/IPコードをリファレンスとしていたのではないかといわれています。

Xerox PARCで開発されたイーサーネット、TCP/IP、そしてBSDの組み合わせによって構築されたLANがARPANET経由でエンド・ツー・エンドで接続し広域ネットワークを構築してしまうという当時は技術的にかなり画期的な仕組みであり、これこそ今日私たちがインターネットと呼んでいるものそのものです。ですからUNIXの存在はインターネットの大きな礎としての存在であったといっても決して過言ではありません。

=== Internet Protocol Suite ===

BSD由来のTCP/IPの特徴は、クライアントだけでなく、サーバだけでもなく、ルーターだけでもない、TCP/IPの機能一式をもったInternet Protocol Suiteの実装であるということです。つまり、UNIXはサーバとしても使え、クライアントとしても使え、そしてまたルーターとしても使えるということです。もちろんその上で動作するアプリケーションは、TCP/IPの機能をフルに使うことができます。

GNU/Linuxベースのサーバーやクライアントはインターネットにおける日常の風景的な部分ではありますが、形をかえて組み込み系でも市販のルータの中身がGNU/Linuxベースであったりするものよく見かけます。もちろんGNU/Linuxは、Internet Protocol Suiteで一式揃えているので、サーバとクライアントとルータやブリッジを同時に兼ねることも当然可能です。

典型的なのがGNU/Linux上で動作するバーチャルマシン・モニタXenのネットワーク構成です。Xenのドメイン0 (他の仮想マシンを動かすためのベースとなる環境）では、内部的にブリッジの機能を作り、ドメインU（個々の仮想マシン）からはそこに仮想的に接続する形を取りネットワークを形成します。このために特別なプロトコルスタックを用意するわけではありません。既にGNU/Linuxには必要なネットワークの能力が用意されているのです。

一般にTCP/IPのようなプロトコルが重ねられている構造のことをプロトコルスタック ( Protocol Stack ) と呼びます。
そして各々のプロトコルのメカニズムあるいは実装のことを、その層のスタック、たとえばTCPであればTCPスタック、IPであればIPスタックと呼びます。意味は、TCPの層だけではなく、その下層も含めたメカニズムあるいは実装をさしています。

== GNU/Linux での TCP/IP ==

まずEthernetを前提に基本的な部分を説明したいと思います。
GNU/LinuxではEthernetのデバイスは基本的にeth0から順番に割り当てられます。
むかしはNIC (Network Interface Card)に対応するデバイスファイル /dev/eth0 というのがあったのですが、今ではそれが存在せず内部的にeth0、eth1という仮想的なネットワークデバイスになっています。
慣用的にloはローカルホスト、eth0はEternet、wlan0は無線LANの仮想ネットワークデバイスとして命名されていますが、これは任意な名前であり、たとえば、新たにPPP (シリアル経由でpoint-to-point接続するプロトコル)で接続を作る時はppp0や、 easytether (AndroidをUSBで接続しテザリングをするツールを利用)など仮想ネットワークデバイスは自由度の高い名前をつけることができます。同種類のデバイスが増えるたびに番数が増えます(eth0, eth1, ... )。

* lo ローカルホストのための仮想ネットワークデバイス
* eth0 Ethernetのための仮想ネットワークデバイス
* wlan0 無線LANのための仮想ネットワークデバイス

その仮想ネットワークデバイスにIPアドレスを設定しTCP/IPで利用する形にします。

=== ifconfig ===

仮想ネットワークデバイスにTCP/IPに必要なパラメータを設定するのはifconfigコマンドです。これは米カリフォルニア大学バークレー校でBSDに組み込んだTCP/IPの実装が作られた時に、IPアドレスやネットマスクなどのパラメータを設定する、あるいは参照するのに作られたコマンドですが、そのまま今もスタイルを変えず使われています。グラフィカルインタフェース〜といっても項目をリストアップする程度のものですが〜を使って設定するツールは存在しますが、システムがブートする段階でIPの制御を行うのがifconfigです。

低いレベルでコントロールする方法を理解したい、あるいはツールを作成したいと思った時は netdevice のオンラインマニュアルにヒントがあります。

/sbin/ifconfigをオプションなしに実行すると、現在のeth0やloが表示されます。

$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:15:c5:41:95:a0
inet addr:192.168.100.18 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::215:c5ff:fe41:95a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:350974 errors:0 dropped:0 overruns:0 frame:0
TX packets:291913 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:329347998 (329.3 MB) TX bytes:36362966 (36.3 MB)
Interrupt:18
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:340 (340.0 B) TX bytes:340 (340.0 B)

仮想ネットワークデバイスeth0はEthernetに接続され、IPアドレス192.168.100.18が設定されています。

loはローカルホストです。これは127.0.0.1が割り当てられます。127.0.0.1は特殊なアドレスでこれは自分自身のマシンを指します。
ホスト名はlocalhostとなっています。

ブート時にはIPアドレスの設定などifconfigコマンドを使っています。デスクトップやノートパソコン、特にモバイルのように色々なネットワーク上で動作させるようなコンピュータはDHCP
<ref>
ISC DHCP
https://www.isc.org/downloads/dhcp/
ここにDHCPのリファレンス実装があります。
</ref>
を使ってそのネットワーク上で自動割り当てされるのが一般的ですが、ここではまず固定IPの話から進めましょう。

# ifconfig eth0 up

これはeth0のインタフェースを利用可能にします。

# ifconfig eth0 192.168.201.3/24

こう実行することによってeth0にはIPアドレス192.168.1.3、ブロードキャスト:192.168.1.255、マスク:255.255.255.0が設定されます。

ここではeth0に設定していますが物理的に1つのNICに複数のIPアドレスを付与できます。
むかしならNIC(network interface card)に1つのIPアドレスしか付加できませんでしたが、
複数のIPアドレスが設定する場合、eth0:1、eth0:2といった形でMACアドレスが同じである
eth0のインタフェースが作られます。

$ sudo ifconfig eth0:1 192.168.100.99/24
$ ifconfig eth0:1
ifconfig eth0:1
eth0:1 Link encap:イーサネットハードウェアアドレス 14:da:e9:71:cd:35
inetアドレス:192.168.100.99 ブロードキャスト:192.168.100.255 マスク:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 メトリック:1
割り込み:47 ベースアドレス:0xc000

(TBD)

== 脚注 ==
<references/>
----
[[目次]]へ

TCP/IP

2014-02-11T14:07:51Z

UnixWikiMaster: /* UNIXとTCP/IP */

== まずはじめに ==

本章でのTCP/IPの取り上げるスタンスについて説明します。
本章では、UNIXとTCP/IPの関係性を取り上げ、GNU/Linuxの中でどう扱われているかの議論を試みます。TCP/IP自体の説明、また、インターネット自体の説明は本章の趣旨ではないので本章では扱いません。またTCP/IPに関する基本知識(例えば 3 way handshakeなど)は既に学習しているものとして話を進めます。

GNU/LinuxはTCP/IPだけではなく、Appletalk、DECNETなど多数のプロトコルをサポートしていますが、本章では主要な論点であるTCP/IPのみ取り上げます。

== UNIXとTCP/IP ==

TCP/IPとは1970年代初頭にDRAPAの研究成果として既に出来上がったネットワーク通信用プロトコルで、元々はUNIXにはなかった機能です。DARPAからの研究資金を得て、4.1bBSD(1982年8月)に対してBBN Technologiesで実装されていたTCP/IPコードをベースとして組入れるという作業が始まり4.2BSDで正式にTCP/IPを含んでリリース(1983年8月)となりました。ここでは「BBNの実装ベースで」とあっさり書いていますが、実際にはもうちょっと複雑な話になっています。
<ref>
詳しくは Open Sources: Voices from the Open Source Revolution に納められているMarshall Kirk McKusickが書いたTwenty Years of Berkeley Unix From AT&T-Owned to Freely Redistributable を読むことをお勧めします。
</ref>

TCP/IPというとインターネット用プロトコルというイメージがありますが、当時のBSDの実装はイーサーネット接続されたLANやキャンパスネットワークで高速に情報を伝達するのに適したものになっています。一方でオリジナルのBBNの実装は広域なネットワークであるインターネットで使うことを前提としているもので、そのため80年代当時の低速なネットワーク向けに作られています。このようにターゲットとなるネットワークの前提が違うため、BBNの実装をそのままBSDに組み込んだような単純な話ではありません。

この期間でのエポックとしては1983年1月1日にARPANETの公式プロトコルはTCP/IPに切り替わっています。 <ref> 核戦争にも耐えうる軍事ネットワークを作るためにインターネットを作ったという俗説がまことしやかに流れていますが、そのような事実はありません。Internet Society のサイトにある [http://www.internetsociety.org/internet/what-internet/history-internet/brief-history-internet Brief History of the Internet] に目を通して正しいインターネットの歴史の全体像を知っておきましょう。 </ref> 当時TCP/IPの実装を持っていたオペレーティング・システムはそんなに多くはなく、BSDの他の名の知れたシステムはDEC社のTOPS-20 system <ref> http://panda.com/tops-20/ by Mark Crispin </ref> ぐらいです。当時、DARPAの資金で開発した、他に参考となる実装が多くなく、ソースコードが公開されているなどのいくつかの要因により実質BSDがコンピュータにおけるTCP/IPのリファレンス実装となっていました。

リファレンス実装であったというおもしろい傍証は1997-8年頃に問題となった [http://en.wikipedia.org/wiki/Ping_of_death Ping of Death] のケースが良いかも知れません。これは規定外サイズのICMPパケットを脆弱性を持つシステムに送るとオペレーティングシステムごとハングアップしてしまうというものです。そもそもの原因はBSDのコードがパケットの分割を考えていなかった実装だったからです。分割されるケースを設計時点で考慮に入れなかったある意味、単純なバグで、そんなに深い意味はありません。もし、IPパケットとICMPパケットの仕様<ref>[http://tools.ietf.org/html/rfc791 RFC791]</ref>だけで作っていたら設計時に考慮し、この脆弱性はたぶん現れないでしょう。しかし実際にはGNU/LinuxだけではなくMacintoshやWindowsにも同じ脆弱性が現れました。このことから仕様ドキュメントから設計をしたわけではなく、商用のオペレーティングシステムもオープンなコードであるBSDのTCP/IPコードをリファレンスとしていたのではないかといわれています。

Xerox PARCで開発されたイーサーネット、TCP/IP、そしてBSDの組み合わせによって構築されたLANがARPANET経由でエンド・ツー・エンドで接続し広域ネットワークを構築してしまうという当時は技術的にかなり画期的な仕組みであり、これこそ今日私たちがインターネットと呼んでいるものそのものです。ですからUNIXの存在はインターネットの大きな礎としての存在であったといっても決して過言ではありません。

=== Internet Protocol Suite ===

BSD由来のTCP/IPの特徴は、クライアントだけでなく、サーバだけでもなく、ルーターだけでもない、TCP/IPの機能一式をもったInternet Protocol Suiteの実装であるということです。つまり、UNIXはサーバとしても使え、クライアントとしても使え、そしてまたルーターとしても使えるということです。もちろんその上で動作するアプリケーションは、TCP/IPの機能をフルに使うことができます。

GNU/Linuxベースのサーバーやクライアントはインターネットにおける日常の風景的な部分ではありますが、形をかえて組み込み系でも市販のルータの中身がGNU/Linuxベースであったりするものよく見かけます。もちろんGNU/Linuxは、Internet Protocol Suiteで一式揃えているので、サーバとクライアントとルータやブリッジを同時に兼ねることも当然可能です。

典型的なのがGNU/Linux上で動作するバーチャルマシン・モニタXenのネットワーク構成です。Xenのドメイン0 (他の仮想マシンを動かすためのベースとなる環境）では、内部的にブリッジの機能を作り、ドメインU（個々の仮想マシン）からはそこに仮想的に接続する形を取りネットワークを形成します。このために特別なプロトコルスタックを用意するわけではありません。既にGNU/Linuxには必要なネットワークの能力が用意されているのです。

一般にTCP/IPのようなプロトコルが重ねられている構造のことをプロトコルスタック ( Protocol Stack ) と呼びます。
そして各々のプロトコルのメカニズムあるいは実装のことを、その層のスタック、たとえばTCPであればTCPスタック、IPであればIPスタックと呼びます。意味は、TCPの層だけではなく、その下層も含めたメカニズムあるいは実装をさしています。

== GNU/Linux での TCP/IP ==

まずEthernetを前提に基本的な部分を説明したいと思います。
GNU/LinuxではEthernetのデバイスは基本的にeth0から順番に割り当てられます。
むかしはNIC (Network Interface Card)に対応するデバイスファイル /dev/eth0 というのがあったのですが、今ではそれが存在せず内部的にeth0、eth1という仮想的なネットワークデバイスになっています。
慣用的にloはローカルホスト、eth0はEternet、wlan0は無線LANの仮想ネットワークデバイスとして命名されていますが、これは任意な名前であり、たとえば、新たにPPP (シリアル経由でpoint-to-point接続するプロトコル)で接続を作る時はppp0や、 easytether (AndroidをUSBで接続しテザリングをするツールを利用)など仮想ネットワークデバイスは自由度の高い名前をつけることができます。同種類のデバイスが増えるたびに番数が増えます(eth0, eth1, ... )。

* lo ローカルホストのための仮想ネットワークデバイス
* eth0 Ethernetのための仮想ネットワークデバイス
* wlan0 無線LANのための仮想ネットワークデバイス

その仮想ネットワークデバイスにIPアドレスを設定しTCP/IPで利用する形にします。

=== ifconfig ===

仮想ネットワークデバイスにTCP/IPに必要なパラメータを設定するのはifconfigコマンドです。これはバークレー大学でBSDに組み込んだTCP/IPの実装が作られた時に、IPアドレスやネットマスクなどのパラメータを設定する、あるいは参照するのに作られたコマンドですが、そのまま今もスタイルを変えず使われています。グラフィカルインタフェース〜といっても項目をリストアップする程度のものですが〜を使って設定するツールは存在しますが、システムがブートする段階でIPの制御を行うのがifconfigです。

低いレベルでコントロールする方法を理解したい、あるいはツールを作成したいと思った時は netdevice のオンラインマニュアルにヒントがあります。

/sbin/ifconfigをオプションなしに実行すると、現在のeth0やloが表示されます。

$ ifconfig
eth0 Link encap:Ethernet HWaddr 00:15:c5:41:95:a0
inet addr:192.168.100.18 Bcast:192.168.100.255 Mask:255.255.255.0
inet6 addr: fe80::215:c5ff:fe41:95a0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:350974 errors:0 dropped:0 overruns:0 frame:0
TX packets:291913 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:329347998 (329.3 MB) TX bytes:36362966 (36.3 MB)
Interrupt:18
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:6 errors:0 dropped:0 overruns:0 frame:0
TX packets:6 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:340 (340.0 B) TX bytes:340 (340.0 B)

仮想ネットワークデバイスeth0はEthernetに接続され、IPアドレス192.168.100.18が設定されています。

loはローカルホストです。これは127.0.0.1が割り当てられます。127.0.0.1は特殊なアドレスでこれは自分自身のマシンを指します。
ホスト名はlocalhostとなっています。

ブート時にはIPアドレスの設定などifconfigコマンドを使っています。デスクトップやノートパソコン、特にモバイルのように色々なネットワーク上で動作させるようなコンピュータはDHCP
<ref>
ISC DHCP
https://www.isc.org/downloads/dhcp/
ここにDHCPのリファレンス実装があります。
</ref>
を使ってそのネットワーク上で自動割り当てされるのが一般的ですが、ここではまず固定IPの話から進めましょう。

# ifconfig eth0 up

これはeth0のインタフェースを利用可能にします。

# ifconfig eth0 192.168.201.3/24

こう実行することによってeth0にはIPアドレス192.168.1.3、ブロードキャスト:192.168.1.255、マスク:255.255.255.0が設定されます。

ここではeth0に設定していますが物理的に1つのNICに複数のIPアドレスを付与できます。
むかしならNIC(network interface card)に1つのIPアドレスしか付加できませんでしたが、
複数のIPアドレスが設定する場合、eth0:1、eth0:2といった形でMACアドレスが同じである
eth0のインタフェースが作られます。

$ sudo ifconfig eth0:1 192.168.100.99/24
$ ifconfig eth0:1
ifconfig eth0:1
eth0:1 Link encap:イーサネットハードウェアアドレス 14:da:e9:71:cd:35
inetアドレス:192.168.100.99 ブロードキャスト:192.168.100.255 マスク:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 メトリック:1
割り込み:47 ベースアドレス:0xc000

(TBD)

== 脚注 ==
<references/>
----
[[目次]]へ

ファイル:DRM20080110.pdf

2014-02-11T13:47:50Z

UnixWikiMaster: UnixWikiMaster 「ファイル:DRM20080110.pdf」の新しい版をアップロードしました

DRM 今そこにある危機
講演資料

ファイル:FreeSoftware20080110.pdf

2014-02-11T13:45:06Z

UnixWikiMaster: UnixWikiMaster 「ファイル:FreeSoftware20080110.pdf」をアップロードしました

フリーソフトウェアをめぐる状況 2008年1月版

UNIXオペレーティングシステム

2014-02-11T12:43:43Z

UnixWikiMaster: /* QRコード */

__NOTOC__

このサイトはGNU/Linuxを通してUNIXオペレーティングシステムを学ぶ授業で使うテキストを掲載しています。詳しくは[[このサイトについて]]のページを参照ください。また何故Linuxを取り上げるのかは「[[なぜUNIXオペレーティングシステムの授業にGNU/Linuxを取り上げるのか]]」を参照してください。

=== テキストの[[目次]] ===

* 第一章 [[オペレーティングシステムとは何か]]
** 第一章:補遺:1 [[UNIXとは何か]]
** 第一章:補遺:2 [[OS誕生からLinuxまでの歴史]]
* 第二章 [[実際にLinuxを使ってみよう]]
** 第二章:補遺:1 [[KNOPPIXを使ってみよう]]
** 第二章:補遺:2 [[Ubuntuインストール方法]]
* 第三章 [[システム環境を考えてみる]]
* 第四章 [[カーネルの構造と機能]]
* 第五章 [[プロセス管理]]
* 第六章 [[記憶管理]]
* 第七章 [[デバイススペシャルファイル]]
** 第七章: 補遺:1 [[Linux LVM]]
* 第八章 [[ファイルシステム]]
* 第九章 [[ユーザ権限とアクセス制御]]
** 第九章: 補遺:1 [[パスワードファイル]]
* 第十章 [[プロセス間通信]]
* 第十一章 [[TCP/IP]] (TBD)

テキストの[[目次]]はこちらからも参照できます。

=== QRコード ===

このページへのQRコードです。
iPhone や Android からアクセスする際にお使いください。

[[image:QRcode.png|150px]]

=== 授業用Wikiページ ===

課題、授業スケジュール、連絡など授業に関する情報は以下のURLからたどることができるpukiwikiに掲載しています。尚、こちらのpukiwikiはbasic認証が必要です。

* http://uc.h2np.net/senshu-u/

* 2008年1月11日の講演スライドはこちらで公開しています [[外部向け資料配布用ページ]]

=== 参考になる本 ===

参考になる本をアマゾンでピックアップしておきました。

* http://astore.amazon.co.jp/h2npbook-22

=== 過去の資料 ===

* [[2007年リチャードストールマン講演会]]

過去に掲示した内容等は[[過去掲示分]]からもたどれます。

ファイル:QRcode.png

2014-02-11T12:43:01Z

UnixWikiMaster: UnixWikiMaster 「ファイル:QRcode.png」の新しい版をアップロードしました

このサイトへのQRコード

ファイル:QRcode.png

2014-02-11T12:39:17Z

UnixWikiMaster: UnixWikiMaster 「ファイル:QRcode.png」の新しい版をアップロードしました

このサイトへのQRコード

Ubuntuマシンインストール:Step 1

2014-02-11T12:32:48Z

UnixWikiMaster: /* キーボードを選択する */

[[Ubuntuマシンインストール方法]]

== CDでブートしてからキーボード設定まで ==
ここではCDでブートしてからキーボード設定までのステップを説明します。約３〜５分で程度で終了します。

== 何を行うか選択する ==
[[画像:Ubuntu_804_3.png]]

CDからブートするためにはBIOSで"CDROMからブート"を最優先にする設定を行うか、
立ち上がり時にファンクションキー
<ref>
DELLのLATITUDEシリーズだとF2キーがBIOSへ、F12がブートメニューの画面に入ります。
</ref>
を押しブートメニュー画面に入り"CDROMからブート"を選択します。

* コンピュータに変更を加えないで Ubuntu を使ってみる
* Ubuntu インストール
* CDの異常をチェック
* メモリーテスト
* 一番目のハードディスクから起動

インストールですから「Ubuntu インストール」を選択します。

;ちょいアドバイス:最初の「コンピュータに変更を加えないで Ubuntu を使ってみる」は、LiveCDとしてUbuntuを使うことができます。自分でUbuntuインストーラーのISOイメージをダウンロードしCDメディアに焼き付けた人は念のために「CDの異常をチェック」を行うのも良いかもしれません。自作PCで初めて利用する時はメモリーテストを最初に行うのも良いでしょう。

== 言語を選択する ==

[[画像:Ubuntu_804_4.png]]

日本語を選択するとシステムのデフォルト言語が日本語に設定されます。ここでは日本語を選択していますが、あなたのお好きな言語を選択してください。

== 利用地域を選択する ==

[[画像:Ubuntu_804_5.png]]

これは利用している地域を選択します。都市名で選択します。これによって自動的に最寄りの（日本なら、日本国内の）ダウンロードサーバーが選択されます。また時間帯など地理情報に関係する設定がこの情報によって設定されます。

== キーボードを選択する ==

[[画像:Ubuntu_804_6.png]]

キーボードを選択します。

------

<p style="text-align:right">
[[Ubuntuマシンインストール:Step_2]]
</p>

== 脚注 ==
<references/>