ネットワーク管理 1
金山 典世, 原 元司
2011 年 4 月 1 日
iii
目次
第 1 章 オープンソースソフトウェア概論
1.1
オープンソースソフトウェアとは?
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1
1.2
1.3
OSD の定義とオープンソース . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
オープンソースのライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
4
MIT(X11) ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSD ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
1.3.3 GPL ライセンス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GNU プロジェクトとオープンソースの歴史 . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
R.Stallman と GNU の発足 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
1.3.1
1.3.2
1.4
1.4.1
第 2 章 FreeBSD8.2R のインストール
2.1
2.2
2.3
2.4
BSD 系の Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
インストールの前の検討と準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
8
2.2.1
機器の選定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2.2
2.2.3
インストール方法の選択 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2.4
2.2.5
ISO ファイルのダウンロード . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
VMplayer の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
PC 特有の問題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
インストール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1
FreeBSD のインストール画面 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.2
2.3.3
Partition (パーティション) の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
インストール後の作業 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
終了方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
第 3 章 環境の整備
3.1
sysinstall を使ったインストール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 コマンドでのインストール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
当面の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.1
3.3
27
パッケージの導入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1
3.2
7
X-window の起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2.2 その他の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
第 4 章 UNIX リテラシ
4.1
39
コンピュータシステムと OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2
4.3
シェルと簡単な UNIX コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
UNIX の歴史と特徴 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
iv
4.3.1
4.4
4.5
簡単な UNIX コマンド . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
ファイルとディレクトリの基本 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.5.1
4.5.2
4.5.3
4.5.4
4.5.5
4.5.6
4.6
シェル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
ファイルとディレクトリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
UNIX のディレクトリ構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
ファイルとディレクトリの操作 (その 1)
ファイルとディレクトリの操作 (その 2)
. . . . . . . . . . . . . . . . . . . . . . . . 49
. . . . . . . . . . . . . . . . . . . . . . . . 54
シェルによる文字列補完とワイルドカード . . . . . . . . . . . . . . . . . . . . . . . 58
ファイルとディレクトリを検索する . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
第 5 章 テキスト編集
5.1
63
テキスト編集とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2
5.1.1 vi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
第 6 章 UNIX システム管理
6.1
6.2
6.3
73
管理者の役割 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
システム管理者とネットワーク管理者 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
UNIX システム管理の実際 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
ユーザ・グループ管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3.3
6.3.4
プロセス管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.3.5
6.3.6
6.4
6.5
起動とシャットダウン . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3.1
6.3.2
ファイルシステム管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
バックアップ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
ネットワークサービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Ports/Packages によるソフトウェア管理 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
6.4.1
6.4.2
Ports/Packages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Ports ディレクトリの準備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
6.4.3
6.4.4
カテゴリ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
インストール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
第 7 章 TCP/IP の基礎 1 — TCP/IP の概略
105
7.1
7.2
簡単なインターネットの歴史 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.3
7.4
パケットの必要性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.5
7.6
ネットワークと TCP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
階層化通信モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
階層モデルとパケット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
パケットの実際 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.6.1
Wireshark の導入 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
7.6.2
7.6.3
Wireshark とフィルター設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
Wireshark で見るパケット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
v
第 8 章 TCP/IP の基礎 2 — 階層
8.1
8.2
8.3
8.4
8.5
121
物理層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.1.1
イーサネット . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
8.1.2
8.1.3
UTP5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
光メディア . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
8.1.4
その他の規格 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
データリンク層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
8.2.1
8.2.2
MAC アドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
CSMA/CD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
8.2.3
トークンパッシング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
8.2.4 ARP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
ネットワーク層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.3.1
8.3.2
セグメント間通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
8.3.3
8.3.4
IP アドレスの階層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
ICMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
IP アドレス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
トランスポート層 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.4.1
サーバ・クライアントモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
8.4.2
8.4.3
アプリケーション間通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
信頼性のある通信 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
アプリケーション層
第 9 章 ルーティング
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
145
経路制御が必要な理由 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
9.1
9.2
ルーティングとネットマスク . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
9.3
静的ルーティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
9.4
9.3.1 IP forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
動的ルーティング . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
9.5
9.6
ネットワークのセキュリティ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
第 10 章 FreeBSD と WWW
157
10.1 apache のインストール . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.2 apache の設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.2.1 httpd.conf . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
10.3 起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
10.4 ページ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
第 11 章 NAT(NAPT)
161
11.1 NAT とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
11.2 IPFilter の NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
11.3 フィルタリングとカーネル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
11.3.1 カーネルの再構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
11.3.2 カーネルの設定ファイル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
vi
11.3.3 カーネルの再構築 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
11.3.4 natd, フィルタリングの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
11.4 演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
第 12 章 SSH(Secure SHell)
169
12.1 SSH の基本設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
12.2 SSH の進んだ使い方 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.2.1 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.3 ファイル転送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.4 Forward . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
12.5 演習 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
第 13 章 DNS I
177
13.1 名前解決とは . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
13.2 ローカルな名前解決 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
13.3 Domain Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
13.3.1 DNS サービス . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
13.4 サーバの設定 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
13.4.1 プライマリゾーンサーバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
13.4.2 セカンダリゾーンサーバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
13.4.3 ファイルのチェック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
13.5 rndc.key の生成 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
13.6 ネームサーバの起動 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
13.7 リゾルバ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
13.8 DNS への問い合わせツール、メンテナンスツール . . . . . . . . . . . . . . . . . . . . . . . 193
13.9 演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
第 14 章 DNS II
197
14.1 逆引きのゾーン情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
14.2 DNS メンテナンスツール II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
14.2.1 CIDR に対する逆引きのゾーン情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
14.3 演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
第 15 章 DNS III
203
15.1 BIND9 の新機能 — view . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
15.2 演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
第 16 章 mail の設定
209
16.1 mail の仕組みと Postfix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
16.1.1 配送 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
16.1.2 mail aliases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
16.1.3 DNS と Mail . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
16.1.4 Postfix の情報 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
16.1.5 Postfix の構造 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
16.1.6 Postfix のインストール、設定の準備 . . . . . . . . . . . . . . . . . . . . . . . . . . 214
vii
16.2 メイルのヘッダー . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
16.3 メイル環境の設計 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
16.3.1 ハブホストで受信、それぞれが外部に配送 . . . . . . . . . . . . . . . . . . . . . . . 218
16.3.2 ハブホストに全て集中する場合 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
16.3.3 Other Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
16.3.4 設定のチェック . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
16.4 起動とテスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
16.4.1 起動方法 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
16.4.2 テスト . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
16.5 その他のメイル環境整備 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228
16.6 演習課題 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
1
第 1 章 オープンソースソフトウェア概論
1.1
オープンソースソフトウェアとは?
オープンソースソフトウェア (Open Source Software,OSS) の定義は、大まかに言うと「プログラムの
ソースコードが公開されており、それが無償で参照、改変、再配布可能なもの」となります。1998 年に設
立された非営利団体のオープンソースイニシアティブ (Open Source Initiative) 1 では、オープンソースソ
フトウェアの定義として以下の条件をあげています [?]。
1. 自由な再配布ができる
2. ソースコードを入手できる
3. 派生物が存在でき、派生物に同じライセンスを適用できる
4. 差分情報の配布を認める場合には、同一性の保持を要求してもよい
5. 個人やグループを差別しない
6. 適用領域に基づいた差別をしない
7. 再配布において、追加ライセンスを必要としない
8. 特定製品に依存しない
9. 同じ媒体で配布される他のソフトウェアを制限しない
10. 技術的な中立を保っている
これらの定義を The Open Source Definition(以下 OSD と略記) と呼んでいます。一方、オープンソースソ
フトウェアと同義としてよくフリーソフトウェア (Free Software) という言葉をよく耳にします。GNU(GNU
is NOT UNIX) の活動で知られるフリーソフトウェア財団 (Free Software Foundation,FSF[?]) では、フ
リーソフトウェアと OSS は異なると主張しています。本章では、OSS の歴史やライセンスなど OSS の概
要を解説します。
1 B. ペレンズ、E. レイモンドらによって設立されたオープンソースを推進する団体。 Netscape のソースコードが公開されたこと
が設立の背景と言われる。
第 1 章 オープンソースソフトウェア概論
2
図 1.1: ソースプログラムとオブジェクトプログラム
babababababababababababababababababababab
(One Point) プログラムのソースコードとは？
プログラミング言語によって記述されたプログラム (ソースプログラム) を指します。私たちが普
段利用する OS(オペレーティングシステム, 基本ソフト)、アプリケーション (ゲーム、ワープロ、
ブラウザ等) の多くはソースプログラムが存在します。ソースプログラムは人間にとって可読な英
字、記号を用いて記述され、コンピュータに行わせるべき仕事の手順が記述されています。しか
し、コンピュータは元々0 あるいは 1 という記号 (2 進数) しか理解できません。このために、図
1 のように、「コンパイラ」と呼ばれるプログラムを用いてコンピュータが理解可能なプログラム
(機械語) に翻訳する必要があります。コンパイルは「翻訳する」あるいは「変換する」という意
味です。また、変換後のプログラムは「オブジェクト (目的) プログラム」、
「機械語プログラム」、
あるいは単に「バイナリ (プログラム)」とも呼ばれます。バイナリとは、「2 進数」を意味しま
す。ソースプログラムを記述するプログラミング言語は多種のものがありますが、代表的なもの
で Linux などの UNIX 系 OS を記述するために開発された C 言語、BASIC、Fortlan、COBOL、
Ruby、Java、Perl、Pascal などがあり、目的によってそれぞれ使い分けられています。図 1.1の
ソースプログラムは C 言語で記述されています。
1.2
OSD の定義とオープンソース
はじめに、OSD の定義を簡単に解説してみましょう。まずはその前に簡単に「ソフトウェアのライセン
ス」について説明しましょう。ライセンスとは一般には「免許」といった意味で用いられていますが、と
くにソフトウェアのライセンスは「利用許諾条件」あるいは「使用許諾条件」と訳されます。
1.2. OSD の定義とオープンソース
3
やや硬い表現になりますが、法律では思想や感情を表現したもののうち、文芸、学術、美術、音楽など
の範囲にあるものを「著作物」と呼び、その著作物の作者に与えられる権利を「著作権」と呼びます [?]。
簡単に言えばここで扱うソフトウェアや小説、絵画、写真、楽曲などが著作物に相当します。著作物の作
者は、主張すればその作品を勝手にコピーされない、改変されない、といった権利が「著作権法」という
法律によって保証されます。また、日本をはじめほとんどの国々が加盟する「ベルヌ条約」では、国際的
に著作権を保護することが義務づけられています2。
ソフトウェアのライセンスとは、そのソフトウェアを利用する人 (利用者) にどのような形で利用を許す
のか、ということを作者が規定するものです。言い変えれば、著作者が主張する著作権の表現手段だと考
えればいいでしょう。さて、OSD で規定されるオープンソースのライセンスは、どのような特徴を持つの
でしょうか？
1. 自由な再配布ができる 「オープンソース」であるソフトウェアは、さまざまなプログラムを集めた配
布物 (ディストリビューション) の一部であって、そのソフトウェアを販売あるいは無料で配布 (コ
ピー) することを制限してはいけません。このとき、 オープンソースのライセンス (後述) は、販売
に関して印税その他の報酬を要求してはいけません。
2. ソースコードを入手できる 「オープンソース」であるプログラムはソースコードを含んでいなければ
なりません。 コンパイル済の形式と同様にソースコードでの頒布も許可されていなければなりませ
ん。何らかの事情でソースコードと共に頒布しない場合には、 ソースコードを複製に要するコスト
として妥当な額程度の費用で入手できる方法を用意し、それを公表しなければなりません。その方
法としては、インターネッ トを通じての無料ダウンロードがあります。たとえば、商用のワープロ
ソフトなどは、ソースコードが公開されていません。これは、ソースコードを公開すると、自社で
開発した技術も公開することになり、自社の技術的優位性が失われてしまう可能性があるからです。
オープンソースの概念はこのようなビジネスモデルとは対極にあります。「オープンソース」である
ソフトウェアは、さまざまなプログラムを集めた配布物 (ディストリビューション) の一部であって、
そのソフトウェアを販売あるいは無料で配布 (コピー) することを制限してはいけません。このとき、
オープンソースのライセンス (後述) は、販売に関して印税その他の報酬を要求してはいけません。
3. 派生物が存在でき、派生物に同じライセンスを適用できる ライセンスは、ソフトウェアの変更と派生
ソフトウェアの作成を許可しなければなりません。また、派生ソフトウェアを元のソフトウェアと同
じライセンスの下で頒布することも許可しなければなりません。
4. 差分情報の配布を認める場合には、同一性の保持を要求してもよい オブジェクトプログラム (バイナリ)
構築の際にプログラムを変更するため、ソースコードと一緒に 「パッチファイル」を頒布することを
認める場合に限り、ライセンスによって変更されたソースコードの頒布を制限することができます。
パッチファイルとは、プログラムの変更部分のみの情報で、プログラムの修正やバージョンアップな
どに利用されるデータの一種です。自分が作成したソースコードは一切変更を許さず、変更部分はす
べてパッチファイルで与えるように義務づけることが可能、という意味です。このようにすると、自
分で開発した部分と、他人が改良・改変した部分が明確になります。
5. 個人やグループを差別しない 特定の個人やグループ (国を含む) に対して差別してはいけません。暗号
化アルゴリズムについては、米国のように「輸出規制」を課す国もありますが、プログラムのライセ
ンス自身にそのような制限を課してはなりません。
2 1886 年にスイスのベルヌで締結されました。現在 163 カ国が批准しており、たとえ非加盟国であっても国際貿易機構 (WTO)
に参加する国であればベルヌ条約のほとんどを受け入れざるを得ません。
第 1 章 オープンソースソフトウェア概論
4
6. 適用領域に基づいた差別をしない 5. と同様に利用する領域 (たとえば医療、バイオテクノロジーといっ
た分野や領域) についても差別してはいけません。
7. 再配布において、追加ライセンスを必要としない プログラムに付随する権利はそのプログラムが再頒
布された者全てに等しく認められなければなりません。したがって、改変・改良されたプログラムを
利用する場合に、何らかの追加的ライセンスに同意するこ とを必要としてはなりません。
8. 特定製品に依存しない プログラムに付与された権利は、それがある特定のソフトウェア頒布物の一部
である、ということに依存してななりません。プログラムをその頒布物から取り出したとしても、そ
のプログラム自身のライセンスの範囲内で使用あるいは頒布する権利と同等の権利を有することを
保証しなければなりません。
9. 同じ媒体で配布される他のソフトウェアを制限しない ライセンスはそのソフトウェアと共に頒布され
る他のソフトウェアに制限を設けてはなりません。たとえば、ライセンスは同じ媒体で頒布される他
のプログラムが全てオープンソースソフトウェアであることを要求してはなりません。
10. 技術的な中立を保っている ライセンス中に、特定の技術やインターフェースに強く依存するような規
定があってはなりません。
1.3
オープンソースのライセンス
それでは、OSS で用いられている代表的なライセンスをいくつか紹介しましょう。
1.3.1
MIT(X11) ライセンス
これは、MIT(マサチューセッツ工科大) を起源とするソフトウェアライセンスです [?]。とくに X Window
システムで導入されていることで知られており、X11 ライセンスとも呼ばれます。非常に制限が緩いのが
特徴で、著作権およびライセンス表示を義務づけていること以外は、商用システムに組み込むことも可能
です。
1. このソフトウェアを誰でも無償で無制限に扱って良い。ただし、著作権表示および本ライセンスの表
示を、ソフトウェアのすべての複製または重要な部分に記載しなければならない。
2. 作者または著作権者は、ソフトウェアに関して何ら責任を負わない (無保証)。
1.3.2
BSD ライセンス
BSD(Barkley Software Distribution, カリフォルニア大学バークレー校で開発されたソフトウェア群) ラ
イセンスは [?]、無保証であることの明記と著作権表示のみを再頒布の条件としています。この条件さえ満
たせば、BSD ライセンスのソースコードを複製・改変して作成したバイナリプログラムを、ソースコード
を公開せずに頒布できます。具体的には、無保証ということと著作権表示さえしておけば、BSD ライセン
スのソースコードを他のプログラムに組み込んで、しかも組み込み後のソースコードを非公開にできます。
したがって、組込みシステムなどで商用化する場合などに適しています。
この応用としては、FreeBSD(NetBSD,OpenBSD など BSD 系 OS)、Darwin (カーネルとサブシステム
を含む Mac OS X の基礎となるシステムで、Mach3.0 と FreeBSD をベースに開発された)、ブロードバン
1.4. GNU プロジェクトとオープンソースの歴史
5
ドルータなどネットワーク機器の一部 (中身はコンピュータ)、Microsoft Windows(TCP/IP のネットワー
ク部分のソースコードに利用)、PostgreSQL(オープンソースのデータベースソフト) などがあります。
1. このソフトウェアを誰でも無償で無制限に扱って良い。ただし、著作権表示および本ライセンスの表
示を、ソフトウェアのすべての複製または重要な部分に記載しなければならない。
2. 派生物の広告には、必ずオリジナルの著作者が紹介されていること (宣伝条項)
3. 作者または著作権者は、ソフトウェアに関して何ら責任を負わない (無保証)
また、BSD ラインセンスの宣伝条項を撤廃した修正 BSD ライセンス (新 BSD ライセンス) もあり、多く
利用されています。
1.3.3
GPL ライセンス
図 1.2: コピーレフト
GNU プロジェクトの一環として FSF によって広く配布されているライセンスです [?]。GPL は、GNU
General Public License の略語となっています。前述の BSD ライセンスなどとの違いは、派生物に対して
もソースコードの公開や誰でも無償で利用できることを保証する点にあります。このライセンスは、オー
プンソースが再頒布される際にも「オープンソース」であることを保証するものです。
このようなライセンス形態を著作権の Copyright をもじって、Copyleft(図 1.2) と呼んでいます。ただ
し、自分でソースコードを修正して使うだけの場合にはソースコードを公開する義務はありません。この
義務は、あくまで他人に渡す (頒布する) 場合にのみ発生するものです。
もしも、他のライセンスを持つプログラムと GPL を持ったプログラムを組み合わせる場合には、その派
生物も GPL としなくてはなりません。このことを避けるために、GPL とその他のライセンスを組み合わ
せたデュアルライセンスという形態も近年普及してきています。
1.4
GNU プロジェクトとオープンソースの歴史
GNU[?] の名前は GNU is Not UNIX(GNU は UNIX に非ず) という語源を持ちます3。この GNU は「グ
ニュー」と読みます。動物の「ヌー」と同じスペルであることから、マスコットキャラクターとして、図
3 コンピュータの世界で解説すると、
「再帰構造」となっており (名前の中に自分の名前が含まれる)、非常に wit に富んだ名前に
なっています。
第 1 章 オープンソースソフトウェア概論
6
図 1.3: GNU イメージキャラクタ
1.3のようなヌーの絵がしばしば使われています [?]。ここでは、オープンソースの原型とも言える GNU プ
ロジェクトによるフリーソフトウェアの概念とオープンソースの歴史について解説します。
1.4.1
R.Stallman と GNU の発足
GNU プロジェクトの創始者である R.Stallman は米国生まれのプログラマで、ハーバード大学で物理学
を専攻しました。同大学のコンピュータ研究所が「ソースの公開されていないプログラムはシステムに組
み込まない」という方針を堅守していることに、深く感銘しました。1971 年には、MIT の人工知能研究所
にプログラマとして職を得た Stallman は Emacs と呼ばれる有名なフルスクリーンエディタ (テキスト編
集ツール) を作成しました。この Emacs は評判を呼び、多くの人に (現在でも) 無償で使われるようになり
ましたが、Stallman はひとつだけ条件を出しました。それは、「ソースコードを改良したら必ず作者の自
分に知らせる」というものでした。
一方、時代の流れでパーソナルコンピュータが販売されるようになり、ソフトウェア作成・販売がビジ
ネスとして普及し始めました。元々無償で入手可能であった UNIX というオペレーティングシステム (OS)
ですら高額で販売されるようになり、Stallman は心を痛めていたと言われています。Stallman は 1983 年
に MIT 人工知能研究所を退職し、フリーソフトウェア財団 (FSF,Free Software Foundation) を設立しま
した。この組織の目的は、UNIX で優れている部分を作り直して、それを全部ソフトウエアのコピー代程
度で入手可能にすることでした。FSF 設立と同時に、そのソフトウエアを作るための GNU プロジェクト
を立ち上げました。
7
第 2 章 FreeBSD8.2R のインストール
2.1
BSD 系の Unix
TCP/IP が普及したひとつの要因は、TCP/IP を実装した BSD OS を配布した点にありました。もちろ
ん、これが動くためには、PDP-11 というミニコンが必要であり、大型計算機ほどではありませんが、当
時としてはかなり高価なものであったようです (70 年代から 80 年代にかけて多くのモデルが作られ、テー
プやパンチなどの周辺もあるためにかなりの高額でした)。
図 2.1: Bell labs, Dennis Richie 氏のページより [?]
写真は、Dennis Richie(立っている人) と、Ken Thompson (UNIX の最初の開発者です。Thompson は
B 言語を作り、Richie が C 言語を作りました。二人とも伝説的プログラマー) で、前にあるのが PDP-11
のシステムです。
UNIX 自体は、AT&T(アメリカの電話会社) で開発配布され、BSD もこの AT&T の上で開発されました。
そのために UNIX が商用化されるようになると、ライセンスの問題が表面化し、一時 BSD が配布できな
い状態に追い込まれましたが、その後 AT&T の UNIX である SystemV にも BSD のコードが含まれている
ことが判明し、和解が成立しました。これ以降、BSD は AT&T のコードを全く含まない 4.4BSD-Lite を出
し、これが多くの BSD 系のオープンソースの元になっていいます (誕生間もない Linux がオープンな世界
で支持されたのは、この BSD の係争問題が影響していると言われています)。
BSD は Berkeley Software Distribution の略で、カリフォルニア大学バークレー校において開発され
た UNIX 系 OS です。その後変遷を経ていますが、この BSD を始祖とするものが現在 BSD の名前を冠して
第2章
8
FreeBSD8.2R のインストール
いる OS になります (FreeBSD, NetBSD, OpenBSD,PC-BSD, DesktopBSD, DragonFly BSD, BSD/OS,
386BSD, 他にも BSD 系の OS としては初期の SunOS や、OpenDarwin, Mac OS X などもあります)。ま
た、BSD はさまざまなツールも含んでおり、Linux や商用製品の多くがそれを継承しているため、現在の
オープンソースの始祖と言っても過言ではありません。
図 2.2: UNIX の系譜 (http://commons.wikimedia.org/wiki/File:Unix history-simple.svg より [?])
FreeBSD の開発に関して、とくにその開発姿勢について理解している必要があるでしょう。FreeBSD は、
メジャーバージョン（例えば 8.x）がリリースされた後は、そのメジャーバージョンでは新たな機能は盛り
込まれず、安定化とバグフィックスを目的としてマイナーバージョンアップが行われます (8.0,8.1,8.2 のよ
うにアップしていく)。また、開発は、CURRENT、STABLE、RELEASE と言う段階を踏んで行われ、誰
でもが開発中のそれぞれのステージのソースコードを手に入れることができるようになっています。通常
使う場合には、RELEASE 版を利用し、同じメジャーバージョン内でバージョンアップすれば良いでしょ
う。また、セキュリティホールについても活発に改善がなされ、マイナーバージョンアップが数回されて
いるものについてはセキュリティホールなどの問題はほぼなくなっていると言えます。
Linux はディストリビューションが乱立しているためにカーネルとしての Linux とシステムとしての
Linux とは全く異なっている点に注意する必要があります。一方、FreeBSD はシステムまで含めてセキュ
リティが考慮され、システムが一体となってバージョンアップされている点で安心感があります。多くの
著名なサイトでも採用され、安定性とセキュリティが必要とされる分野では定評があります。
2.2
インストールの前の検討と準備
FreeBSD のインストールの詳細については多くの書籍が出されているので、ここでは簡単に述べること
にします。
2.2. インストールの前の検討と準備
2.2.1
9
機器の選定
まず、マシンを準備する必要があります。一般に市販されているものが全て利用可能かどうかは組み込
まれている VGA カードや、ディスク、ネットワークカードの問題があり、一概には言えません。しかし、
一般的には最新のものはまだサポートされていない可能性があるので、ある程度こなれたハードウェアの
方が良いでしょう。詳しくは、[?] に対応したハードが掲載されているので、インストール対象のリリース
ノートを参照して下さい。
CPU
CPU は、Intel 系ならばほとんどがサポートされています。486,Pentium 系は全て動作し、AMD などの
互換 CPU もハードウェアレベルでの互換性を持つものならば、ほとんど動作します。また、64bit の機能
を利用したい場合には、amd64 で AMD の Athlon64,Phenom,Opteron などと Intel Xeon などの EM64T
サポート CPU に対応しています。
メモリ
メモリアーキテクチャに対する制約はありませんが、32bitCPU では 4Gbyte までの制限がありますの
で、それ以上のメモリを利用したい場合には先に上げた 64bit 対応版を利用する必要があります。
バス
ISA, EISA, PCI, PCI Express バスなどがサポートされていますが、PCI, PCI Express が無難でしょう。
ディスク
ハードディスクは通常 IDE が用いられることが多く、最新の E-IDE(あるいは ATA,SATA) ならばまっ
たく問題なく動作します。ハードウェア RAID カードも一部サポートされているので、クリティカルな業
務ではそうしたものの利用も検討した方が良いでしょう。
ディスプレイカード
FreeBSD を走らせるだけならば、VGA カードは何でもかまいません。しかし、X ウィンドウを利用す
る必要があるならば、XFree86 でサポートしているカードでなければなりません。一般に最新のカードは
すぐにはサポートされない場合が多く、メジャーなカードを利用した方が良いでしょう (Nvidia あるいは
ATI などがお勧めです)。
ネットワークカード
最近では、100M Ether から Gigabit Ether が標準へと変わりつつあります。Gigabit Ether はほとん
どのカードに対してサポートされていますが、チップセットごとにサポートされているので、リリース
ノートを参照しましょう。メジャーな所では、Intel, 3Com, 旧 DEC チップなどがあげられますが、安い
RealTek,VIA チップなども利用可能です (ただし、サーバ用途を考えるならば、これらのチップは止めた
方が良いでしょう。通常は Intel あるいは Broadcom などのチップのパフォーマンスが良いと言われてい
ます。あまり安いチップでは十分なバッファがないのでサーバには不向きです)。
第2章
10
FreeBSD8.2R のインストール
CD-ROM
最近の ATAPI CD/DVD-ROM は全てサポートされています。SCSI CD-ROM の場合には、SCSI ボー
ドがサポートされていれば問題ありません。一方、古い CD-ROM はサポートされていない独自のものが
あるので注意が必要ですが、よほど古くない限り問題ないでしょう。また、SATA の CD-ROM もサポー
トしています (DVD-ROM も同様)。
2.2.2
インストール方法の選択
FreeBSD は、FDD, CD-ROM, DVD-ROM, DOS パーティション, FTP, NFS などを用いてインストー
ルができますが、いずれもインストール用のブート可能なメディアが必要である (特殊にはネットワーク
ブートを使った方法もあるが)。もっとも単純な方法は、CD-ROM(DVD-ROM) インストールであろう。通
常、CD-ROM インストールならば、配布ファイルは全て CD-ROM に入っているので、CD-ROM のみで
全て足りる (最近は CD だとフルには 3 枚が必要で、DVD ならば 1 枚で収まる)。
2.2.3
PC 特有の問題
歴史で少し触れたように、BSD は本来専用ワークステーションに対して開発され、それを PC (PC/AT
互換機) で動作するように改良されました。そのために、PC 特有の問題を特殊な方法で解決しています。
それはパーティションと呼ばれるディスク内部の論理的な切り分けに関しての問題です。PC では、ディス
クを複数の領域に分けて管理することができます。これを DOS パーティションと呼びましょう (DOS,Win
では単にパーティションと呼ばれていますが)。 DOS パーティションは基本的には一つのディスクに 4 つ
まで作成でき、そのそれぞれに異なる OS をインストールして利用することが可能です (特別なツールを使
うとさらに増やせますが)。
一方、UNIX でも、ディスクは用途別に切り分けて使うことが習慣になっていますが、Windows 系 OS
と違ってその切り分けの数には制限はありません (本当はありますが、実用上問題になりません)。そのた
めに、UNIX での分け方をそのまま PC に持ち込むと DOS の制限に直ぐに抵触してしまうことになりま
す。そこで、考えられたのが、DOS パーティションをさらに分割するという方法です (図 2.3 参照)。つま
り、DOS のパーティションの中をさらにパーティションに分けるという方法です。ここで、問題になるの
がこのパーティション (パートは部分ですから、部分に分けることをパーティションと言います) という言
葉で、DOS のパーティションと BSD のパーティションを区別するために、BSD では、DOS のパーティ
ションをスライスと呼びます。したがって、PC のディスクを使う際には、まずスライスに分けます (既に、
DOS, Windows 上で DOS パーティションを切ってあれば問題ありません)。次に、BSD で使うスライス
(最低一つ必要です) を、BSD で使うために複数のパーティション (BSD のパーティション) に分けます。
DOS,Win で使うパーティションが意味していることと、BSD で言うところのパーティションは意味が違
うので、混乱しないようにしましょう。
2.2.4
ISO ファイルのダウンロード
自分で最初からインストールする場合には、ブラウザで、http://www.jp.freebsd.org に行き、配
布 (詳細) 日本の FreeBSD 関連サーバー のリンクから、適当なサーバを探し、FreeBSD8.2R の iso イ
メージをダウンロードします。このイメージを CD-ROM あるいは DVD に焼いてから、次節のようにイ
ンストール作業を行います [?],[?]。
2.2. インストールの前の検討と準備
11
ディスク
BS D-.ディスク
D O Sパ ーテ ィ シ ョン
/
パ ーテ ィ シ ョン
SW AP
ス ライ ス
パ ーテ ィシ ョン
/var
パ ーテ ィ シ ョン
D O Sパ ーテ ィ シ ョン
/ t m p パ ーテ ィシ ョン
ス ライ ス
/usr
パ ーテ ィ シ ョン
D O Sパ ーテ ィ シ ョン
ス ライ ス
スライス とパーティションの12
図 2.3: パーティション
VMplayer の設定
2.2.5
ここでは、既にインストールされている VMplayer 用の仮想 PC(前期で用いた FreeBSD) に再インストー
ルする方法をとることにします。
まず、Windows 上で自分の VM のあるフォルダにある FreeBSD-09.vmx ファイルを適当なエディタで
開きます (もしかするとファイル名を変更している人もいるかも知れませんが、拡張子は vmx です)。
以下の行を見つけて下さい。
ide1:0.fileName = "C:\home\FreeBSD\6.4-RELEASE-i386-disc2.iso"
ide1:0.deviceType = "cdrom-image"
この 2 行を以下のように書き換えます。
ide1:0.fileName = "D:"
ide1:0.deviceType = "cdrom-raw"
但し、上の書き換えで、D: は Windows 上で DVD が D ドライブである場合の例です。多くの場合、
DVD-ROM は D ドライブですが、必ず確認をして下さい。もしも、ドライブ名が D ではない場合には、
DVD のドライブ名にして下さい。
書き換えが終了したら、保存をして、PC に DVD-ROM を入れて、VMplayer で先に書き換えた vmx ファ
イルを動かして下さい。なお、前回レジューム状態にしている場合には、前にインストールした FreeBSD
が動作した状態で立ちあがりますから、その場合には
#
reboot
12
第2章
FreeBSD8.2R のインストール
のように再起動をして下さい (reboot コマンドは単に再起動をします)。
この際、DVD が入っていることを確認してから再起動させて下さい。
通常の PC の設定ならば、これで CD/DVD から立ちあがる筈ですが、残念ながら VMplayer では標準
設定で CD/DVD から起動するようには BIOS 設定がされていないようです。従って、CD/DVD から立ち
上げるためには、BIOS 設定が必要です。
再起動したら、素早く F2 を押して下さい。うまく行けば次のような BIOS 設定画面になります。
この画面にならなければ、FreeBSD の起動画面になりますので、7 を押して再起動を再度するようにし
ます。
上の画面で、右矢印キーを使って、Boot メニューに移動して下さい。すると、下の画面のように起動順
序が Removable Devices, Hard Drive, CD-ROM Drive になっていると思います。
このままでは、CD-ROM から起動しませんので、CD-ROM の起動順序を早くする必要があります。ま
2.2. インストールの前の検討と準備
13
ず、下向きの矢印キーで反転している所を CD-ROM に合わせ、次に + キーを一度だけ押して下さい。す
ると、下のように Removable Device の次に CD-ROM が来る筈です。行き過ぎたり、間違えて下に動か
してしまった場合には - キーと+ キーを使って下の画面のようにして下さい。
これで設定は終わりですので、この設定を BIOS に記憶させて終了します。まず、右矢印キーで EXIT
メニューに移動して下さい。
この画面で、一番上にある ’Exit Saving Chnages’ を選べば、確認画面が出ますので、YES にカーソル
を合わせて、エンターキーを押せば、設定を記憶した上で、再起動されます。
これで、CD を読み込み始める筈です。
第2章
14
2.3
FreeBSD8.2R のインストール
インストール
2.3.1
FreeBSD のインストール画面
CD,DVD から立ち上げると、FreeBSD の最初のインストール画面が出てきます。
国の選択
キーボード選択のために、国を選択します。国は、アルファベット順に並んでいますので、Japan を選
びます。なお、項目は PageUp,PageDown キーで一画面ごとにスクロールさせることもできます。
キーマップの選択
Keymap をカーソルで選び、出てきた画面の中から Japanese 106(日本語 106 型キーボードのことです)
を選択します。
2.3. インストール
15
カスタムインール
ここでは色々なインストールオプションを自分で選べるカスタムインストール ( Custom ) を選びます
(for experts とありますが、難しくはありません)。
するとつぎの画面に移ります。
この画面では、一行めから順にいろいろな設定項目を設定して行きます。
オプションの設定
Options をカーソルで選択し、出てきた画面にたいして以下の項目を設定する。
第2章
16
FreeBSD8.2R のインストール
a) Editor の設定
標準ではエディタは /usr/bin/ee になっているので、ee をバックスペースを使って消し、/usr/bin/vi
に変更します。
b) Media Type の設定
CD-ROM(DVD-ROM) を選択します。
c) Q を押してオプションの設定は終わります。
2.3.2
Partition (パーティション) の設定
FreeBSD で使用するディスクの領域を設定することが出来ます。
パーティションの作成の基本的な方法は C で作成 (Create) で、D で削除 (Delete)、A で (ディスク全体
を使用) となります。C で作成するときには容量を聞いてくるので MegaByte 単位で指定したい時には、
100M のように後ろに M を付けて指定します。ここでは 10G 取るとすると、 10000M のように指定し
ます。
下のサンプル画面は一つのパーティションのみが存在する場合のものです (ディスクサイズも 6G と小さ
いです)。
2.3. インストール
17
上の図で、ディスクの大きさは、512byte 単位の大きさで表示されています。ここでは 6Gbyte なので、
12, 582, 801 のサイズがありますので、注意しましょう (2 で割れば大体 Kbyte 単位になっている)。50 G
だと、100,000,000 のサイズになります。
ここでは、既にディスク全体が FreeBSD の領域に設定されているので、何もせずに終了して構いません。
終了するには、Q を押します。
つぎに、ブートマネージャーのインスト画面に移ります。
複数の OS をインストールするときには、 BootMgr が必要ですが、ここでは不要ですので、Standard を
選んでください (一つの OS のみを立ち上げるモードです。間違っても、None を選んではいけません)。
18
第2章
FreeBSD8.2R のインストール
Label (ラベル) の設定
1) で設定したパーティションをさらに細かく区切ります (これをスライスと言います)。
(上の例も全体の大きさが違うので、少し実習環境とは異なります）
基本的な使い方は、C でパーティションを作成します。パーティションの大きさには Mbyte 単位を使
う事ができます（例えば、50M だと 50Mbyte の大きさになります）。一番最後の/usr の時には、単にリ
ターンを押すだけで、残りの容量が全部確保されます。ここでは、推奨の値で問題ないので、’A’ を押して
デフォルトに設定して構いません (自分で全て設定する場合でも一度 A で標準設定を設定し、各パーティ
ションの大きさを確認してから、すべてのパーティションを削除し、標準設定を参考にして、各パーティ
ションとその大きさを設定すれば良いでしょう)。
終わったら、Q で終了します。
Distribution(配布ファイル)
配布ファイルの内、どういう組合せをいれるのかをここで決定します。ここでは、Kern-Developer をス
ペースキーを使って選びます。
2.3. インストール
19
スペースキーを押すと、別の画面になります。これは、色々な言語のドキュメントがあるので、どの言
語を入れるかという設定です。通常は、en (English) と ja (Japanese) を選びます。すると、次に以下の画
面になります。
これはポーツ (Ports) と呼ばれるソフトウェアを自動でダウンロードして、コンパイル、インストール
を行うためのファイルを導入するか否かの選択です。YES で問題ありません。
これで、一つ前の画面の Distribution の画面に戻りますので、一番上の Exit を選択して、このメニュー
を終了します。
20
第2章
FreeBSD8.2R のインストール
Commit (インストール実行)
Commit(コミット) でディスクの準備、インストール作業を一度に行います。その前の 6.Media につい
ては既に Options 画面で設定 (CD,DVD に設定) しているので飛ばして良いでしょう。
Commit を選ぶと、次のように警告がでます。安全のためなので、YES を押して確認します。
インストールにはそれなりに時間がかかります。
2.3. インストール
2.3.3
21
インストール後の作業
パスワードの設定
すべてが終わると、インストール後の設定画面に移ります。
YES を選択し、最低限のものは先に設定しておきます。特に、絶対設定しなければならない項目が root
のパスワードの設定で、画面では上から３つめに Root Passwd という項目です。root のパスワードを設定
していないと、色々とセキュリティ上の問題が生じることになりますので、忘れないようにしましょう。
22
第2章
FreeBSD8.2R のインストール
ここでは root は全員同じパスワードにすることにします。パスワードは admin11 にします。
選択すると実際には passwd root が実行されるだけです。パスワードは間違えないように同じものを 2
回入力します。(画面には Unix パスワードの常として、何も表示されないので注意してください。)
これでリブートしても良いのですが、Time Zone は設定しておいた方が良いでしょう。
2.3. インストール
タイムゾーンの設定
UTC ではないので、No を選択します。
次に、以下のように Asia, Japan を選択します。
23
24
第2章
FreeBSD8.2R のインストール
最後に JST で良いかと聞いて来ますので、YES を答えます。
リブート
以上でインストールは終りです。Exit を選んで、インストールを終了します。
2.4. 終了方法
25
Yes を選ぶと、リブートします。
この時に、DVD-ROM を必ず抜いておいて下さい。でないと、再度インストールをするモードになっ
てしまいます。
参考 時間のある人は、先の VMplayer の BIOS を出して、CD-ROM の起動順序を下げておけば、CD-ROM から起
動しなくなります。
すると、FreeBSD のカーネルなどを読み込み、うまく立ち上がれば、’login:’ プロンプトが出てきます
ので、そこにユーザ名’root’ をいれ、パスワードに先のパスワードを入れれば良いでしょう。
終了方法
2.4
BSD 系でのシステムの終了は、root 権限で、以下のように入力します。
#
shutdown
-p
now
-p は電源まで切るという意味です。リブート (再起動) をするときには、
# shutdown
とします。
-r
now
27
第 3 章 環境の整備
パッケージの導入
3.1
sysinstall を使ったインストール
3.1.1
FreeBSD では、様々なアプリケーションがあり、Unix ではそうしたアプリケーションはソースで提供さ
れています。それらのソースを各ユーザがコンパイルして、実行可能なプログラムを作成し、それをイン
ストールして使うのですが、それはそれでなかなか手間がかかります (マニュアルを読んで、コンパイルオ
プションを考えて等など。昔は全部そうでした)。こうした手間を無くすために、最近の Unix ではあらか
じめコンパイルされたものをダウンロードし、それをコマンド一発でインストールできるようになってき
ています。FreeBSD では、このような既にコンパイルされ、簡単にインストールできるアプリケーション
を パッケージ ( package) と呼んでいます。
パッケージは、pkg_add コマンドで追加したり、pkg_delete コマンドで削除したり、あるいはその情報
を pkg_info コマンドで見たりすることが出来ます。これらのコマンドの使い方は後で詳しく勉強をしま
すが、こうしたコマンドを知らなくても簡単に使う方法が提供されており、それが sysinstall というコマ
ンドです。実は、sysinstall は最初に FreeBSD をインストールするときに使ったメニューそのもので、こ
れを用いてパッケージを導入することができるようになっているのです。
まず、最初にネットワークの設定がされているかどうかをチェックします。ifconfig コマンドを入力し、
# ifconfig
le0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=389b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC>
ether 00:30:18:af:30:c6
inet 10.120.110.100 netmask 0xffff0000 broadcast 10.50.255.255
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
上の例のように le0 の下に IP アドレス (今の場合は 10.120.110.100) が表示されているかどうかをチェッ
クして下さい。もし、IP アドレスがなければ、IP が取れていませんので、以下のコマンドを実行しなさい。
# dhclient le0
実行後、少し待つとプロンプト (今の場合は # ) が表示されるので、もう一度先のように ifconfig を実
行し、IP アドレスがついたかどうかを見て下さい。(dhclient コマンドは DHCP サーバから IP アドレス
を取得するコマンドです)
うまく IP アドレスが取得できたら、sysinstall を起動してみて下さい。
#
sysinstall
(sysinstall では基本的に、Enter または Space キーで選択をし、上矢印↑、下矢印↓キーで上下のメニュー
28
第3章
環境の整備
の移動、PageUp,PageDown キーでメニュー画面の送りが出来ます。また、メニューの他にいくつかの選
択が出来るような場合には Tab キーを用いて、それらの間を移動することが出来ます。)
メニューから、Configure -> Packages を選び、インストールメディアの選択画面になったら (Choose
Installation Media)、そこで FTP を選びます。すると、インターネット上で FreeBSD8.2 のパッケージを
置いているサイトの一覧が出て来ます。但し、今回は学内のサーバから FTP(ファイル転送) を使って取得
してみることにしましょう。
ここでは、学内のサーバからダウンロードするために、一番上から２番目の URL というメニューを選
択してください。
すると、
ftp://
と表示された画面になりますので、ここで以下のように入力します。
ftp://10.50.18.200
(これは、guru.it.matsue-ct.jp のアドレスで、この学内サーバは FreeBSD の配布サーバのミラーになって
います。)
次に、ネットワークの設定に関する注意が出て来ますが、既に最初に設定しているので
YES を選択し、少し待つとリストが出て来ます。リストは膨大にあるので、カテゴリー毎に分類されて
います。
3.1. パッケージの導入
29
ここでは、試しに日本語でマニュアルを表示できるようにするためのコマンドを導入してみます。まず、
japanese カテゴリーを探し (アルファベット順に並んでいるので、PageDown キーで下に動かして)、Enter
キーでそのメニューに入ります。ここから ja-man-1.1j_8 と ja-man-doc-5.4.20050911_2 を探して下
さい (これもアルファベット順に並んでいます)。見つけたら、スペースキーを使って、下のように選択状
態にしてから、Tab キーで [OK] メニューに移動し、Enter キーで実行させると、自動的にこれらのコマン
ドをダウンロードしてきて、導入してくれます。
終了するには、Exit メニューを選び (何度か選ぶ必要があります) 続けると、終了出来ます。
第3章
30
3.1.2
環境の整備
コマンドでのインストール
こうしたメニューでのパッケージのインストールは最初の内は分かりやすいのですが、慣れてくると逆
に面倒です。
そこで、sysinstall 以外に別の導入方法についても紹介しておきましょう。
まず、最初に以下の用に入力します。
# setenv PACKAGEROOT ftp://guru.it.matsue-ct.jp
但し、これは guru.it.matsue-ct.jp からダウンロードするという意味で、もし設定していないと本家本
元からダウンロードしようとします (つまり、海外サイトからダウンロードしようとしますので、非常に遅
くなります)。また、この設定はもしログアウトしたりすると忘れられてしまいます。常に、これを覚えて
おくようにする設定は後でやることにします。(あるいは名前の代わりに、先の sysinstall の時と同じよう
に IP アドレス 10.50.18.200 を入れます。)
こうした上で、pkg_add でパッケージ hogehoge をインストールするには以下のようにします。但し、
hogehoge はありません (あくまでも例です)。
# pkg_add
-r
hogehoge
このコマンドが終了すると新しいパッケージ (例えば新しいコマンド) を使う準備が整いましたが、BSD
系の OS では、コマンドの検索を早くするためにハッシュというものを使って、あらかじめどのコマンド
がどこに存在するのかを記憶しておくようになっています。このために、新しく導入したコマンドがハッ
シュにないために、導入した直後ではコマンドが見つからないことになってしまいます。この記憶された
ハッシュを再構築するためのコマンドが rehash です。つまり、パッケージを導入したら、必ずこのコマ
ンドを実行しておかないといけないという訳です。たくさんパッケージを入れた場合には、最後に一度だ
け実行すれば良いでしょう。
# rehash
さて、後で便利なように日本語関係の以下のパッケージを導入しておきます。
ja-canna-server ja-cannadic
ja-kinput2
ja-kterm
firefox35
ja-jvim
fvwm2
次に、同様に pkg_add コマンドで、X-window を動かすために必要なパッケージを導入します。
xorg
ja-font-ipa
xf86-input-vmmouse
ja-font-ipa-uigothic
fvwm2-i18n-imlib
firefox35-i18n
以下のファイルを全て導入して下さい。
xf86-video-vmware
ja-font-ipaex
ja-font-mona-ipa ja-font-sazanami
なお、パッケージには、依存関係というものがあります。一つの A というソフトを動かすために別のソ
フト B が必要な時に、A は B に依存していると言います。当然、A を導入するためには、先に B を導入
する必要があります。こうした依存関係をパッケージでは自動的に解決できるようになっており、例えば、
xorg は多くのパッケージに依存しているので、それらの依存パッケージも自動的に導入されるようになっ
ています。このおかげで、たくさんのパッケージを指定しなくても、大元のパッケージをインストールす
3.2. 当面の設定
31
れば関連パッケージも入る仕組みになっているのです。という訳で、xorg のインストールには少し時間が
かかります。また、VMware 上で X を動かすためのドライバや、日本語フォントなどはこれらの依存関係
には含まれていないので、それは別途導入しています。
3.2
3.2.1
当面の設定
X-window の起動
Unix で用いられている X-window は長い歴史がありますが、その開発も紆余曲折を経て、現在オープン
ソースの X-window は Xorg が担っています。FreeBSD も Xorg 版を利用していますが、これを使うため
にはいくつかの設定が必要です。
これからの作業は良く注意して行い、間違わないようにして下さい。最悪の場合には、システムが起動
しなくなる場合もあるからです。
以下のコマンドを注意深く実行してください。
echo ’canna_enable="YES"’ >>
echo ’ifconfig_le0="DHCP"’ >>
echo ’hald_enable="YES"’
echo ’dbus_enable="YES"’
> my.conf
>> my.conf
my.conf
my.conf
うまく実行すれば、my.conf というファイルの中身が以下のようになっています。(cat はファイルの中
身を表示するコマンドです)
# cat my.conf
hald_enable="YES"
dbus_enable="YES"
canna_enable="YES"
ifconfig_le0="DHCP"
次に、現在の設定 /etc/rc.conf を保存します。これは安全のために行います。
なお、余分なスペースなどがあってもいけませんし、タイプミスは致命的です。注意して下さい。
# cp
/etc/rc.conf
/root/rc.conf.org
これで、/root/rc.conf.org が有る筈ですので、ls コマンドで確認をします。(ls コマンドはファイル
のリストを表示するコマンドです)
# ls
/root/rc.conf.org
/root/rc.conf.org
上のように rc.conf.org があれば大丈夫です。
さて、それでは以下のコマンドを注意深く実行してください。
# cat
my.conf
>>
/etc/rc.conf
第3章
32
環境の整備
このコマンドは作成した my.conf を /etc/rc.conf に追加します。特に >> と二つ大なり記号が重ねて
いることが大事で (スペースが間にあってもいけません!)、これによって、追加になります。
cat コマンドで、/etc/rc.conf の最後に先ほど打ち込んだ内容が追加されているかどうかを確認して
ください。
# cat
/etc/rc.conf
...
...
hald_enable="YES"
dbus_enable="YES"
canna_enable="YES"
ifconfig_le0="DHCP"
#
うまく追加出来ていれば、システムを再起動します。
#
reboot
システムが再び立ちあがったら、root でログインし、以下の作業を行います。もし、うまく立ち上がら
なかったら、教員を呼んで下さい。
次に、Xorg 用の設定ファイルを作成します。これは、以下のコマンドで自動的に生成されます。
#
Xorg
-configure
次に、この作成した設定ファイル ( xorg.conf.new ) の動作をチェックします。上のコマンドを実行する
と、最後に以下のコマンドを実行するように画面に出ますが、これを使ってはいけません。
To test the server, run ’X -config /root/xorg/conf.new’
これは古いタイプの実行方法で、画面が真っ黒になり、何も映りません。正しくは以下のように行います。
#
Xorg
-config
xorg.conf.new
-retro
もし、オプションが間違っていると画面が変わらずエラーとなりますので、正しいオプションを入力し
て実行して下さい。
うまく動くと以下のような画面になり、マウスが動かせる筈です。
3.2. 当面の設定
33
もし、うまくマウスが動かなければ、最初の /etc/rc.conf の追記がうまく行っていないか、何かでミ
スをしたのでしょう。教員を呼んで下さい。
ここではテストだけですので、X-window でアプリケーションは動いていません。通常、X-window を終
了させるために Ctrl+Alt+F1 を押して、Ctrl+C で終了させられるのですが、残念ながら VMplayer の
キーと競合しているためにうまく行きません。そこで、Ctrl+Alt+Space を押してから Ctrl+Alt+F1
キーを押して、Ctrl+C で X-window を終了させて下さい。
X-Window が終了したら、以下のように先ほど作成した設定ファイルが全体に有効になるようにデフォ
ルトの場所にコピーします。
# cp /root/xorg.conf.new
必ず、確認しましょう。
/etc/X11/xorg.conf
# ls /etc/X11
xorg.conf
ファイルがあることを確認したら、X-window を起動します。
# startx
少しすると以下の画面になる筈です。
第3章
34
環境の整備
これは、最も古い twm という X-window のウィンドウマネージャーです。X-window では、ウィンドウ
の外観や操作方法 (Loog & Feel と言います) も変更出来るのです。
さて、流石にこの twm では色々と面倒ですし、今のままではキーボードも実は英語キーボードになって
いるために、記号の位置が日本語キーボードと異なっています。そこで、設定を変更し、ウィンドウマネー
ジャーも変更することにしたいのですが、設定ファイルを変更するためのエディタがまだありません (vi が
使える人は vi を使っても構いません)。そこで、まず、グラフィカルなエディタを導入しましょう。
一度、X-window を終了させます。それには、login と書かれたウィンドウに以下のように入力します
(マウスをウィンドウに入れればフォーカスが変わります)。
#
exit
これで、X-window が終わるので、以下のコマンドを以前やっとのと同じように入力し、
# setenv PACKAGEROOT ftp://guru.it.matsue-ct.jp
pkg_add コマンドで gedit を導入します。
# pkg_add
-r
gedit
導入したら、以下のように rehash を実行してから、
# rehash
(新しいコマンドを導入しても、シェルがそれを覚えていないので、そんなコマンドはないと勘違いして、
3.2. 当面の設定
35
実行してくれません。その記憶をクリアして新しく覚えさせるためのコマンドが rehash です。)
X-window を起動します。
トリにコピーしてから編集をします。
# startx
次に、X-window の動作をデフォルトから変更するために、以下のように種ファイルを自分のディレク
# cp
# cd
/usr/X11R6/lib/X11/xinit/xinitrc
/root
/root/.xinitrc
# gedit .xinitrc
.xinitrc の一番下の 5 行は以下のようになっています。
twm &
xclock
-geometry
50x50-1+1
xterm
-geometry
80x50+494+51 &
これを以下のように書き換えます。
#twm &
-geometry
-geometry
&
xterm
-geometry 80x20+494-0 &
exec xterm -geometry 80x66+0-0 -name login
#xclock
#xterm
50x50-1+1 &
80x50+494+51 &
#xterm
-geometry 80x20+494-0 &
#exec xterm -geometry 80x66+0-0 -name login
setxkbmap -rules xorg -layout jp -model jp106
kinput2 -canna &
kterm
kterm
exec
-km
-km
euc
euc
&
&
fvwm2
# や & キーの位置が少し違うので (左右にずれた所にあります)、それを探して入力してください。終わっ
たら、ファイルを保存してから、X-window を終了し、再度 startx を実行して下さい。
第3章
36
環境の整備
うまく上の画面になれば成功です。また、キーボードも英語キーボードではなく、日本語キーボードに
なっているかどうかをチェックしてみて下さい。
3.2.2
その他の設定
キーボードがまともに動くようになったので、いくつかの自分の環境設定のファイルを設定します。ま
ず、自分のシェルの環境を以下のように変更しておきます。
そのために、/root/.cshrc ファイルを gedit で開きます。
以下の場所を見つけて、
# 編集前のオリジナル
setenv EDITOR vi
setenv
setenv
PAGER
more
BLOCKSIZE K
次のように変更して下さい。
3.2. 当面の設定
37
# 編集後
alias vi jvim
setenv EDITOR jvim
setenv PACKAGEROOT
ftp://guru.it.matsue-ct.jp
setenv PAGER jless
setenv LANG ja_JP.eucJP
setenv XMODIFIERS "@im=kinput2"
これで、新しいパッケージを入れる時には pkg_add -r だけで、常に学内からダウンロードします。
また、これで、jman man などと打てば、日本語マニュアルが利用出来ます。但し、ログインしなおす
か、上の設定を読み込み直さないとこの設定が反映されませんので、
# source ~/.cshrc
としておきます (今の場合、ターミナル毎にしないといけません)。
また、firefox も導入していますので、以下のコマンドで実行することが出来ます。
# firefox3
&
なお、コマンド (firefox3) の後ろにつけている & の意味は、シェル上ではそのコマンドをパラレル
に実行 (Unix ではバックグラウンドで実行と言う) する意味です。もし、&をつけないと、firefox を終
了しない限り、このコマンドを入力した端末は使えなくなります。ですから、gedit を動かす場合でも、
gedit
hogehoge.txt & などのように動かす方が良い訳です。
第3章
38
環境の整備
演習課題
3.3
演習 3.1 fvwm が動いたら、その状態で、 kterm を開いて、
#
ps auxw |grep fvwm
を実行し、その結果を提出しなさい。
39
第 4 章 UNIX リテラシ
本章では一般的な UNIX の基本的な使い方を学びます。
4.1
コンピュータシステムと OS
コンピュータシステムは、簡単に言えば「ハードウェア」，
「ソフトウェア」の 2 つの要素から成り立っ
ています。ハードウェアはコンピュータを構成する電子回路などコンピュータ本体、マウス、キーボード、
ディスプレイなどの周辺機器を指します。一方で、ソフトウェアはコンピュータを動作させるための手順
を記述したデータのことを指しています。そのソフトウェアは大きく分けて「基本ソフトウェア」(OS) と
「応用ソフトウェア」(アプリケーション) があります。
図 4.1: オペレーティングシステムの役割
一般に、基本ソフトウェアはオペレーティングシステム (Operating System,OS) とも呼ばれ、その基本
ソフトウェアの上で動作する各種のソフトウェア (ワープロ、表計算、ゲーム、各種ユーティリティ) を応用
ソフトウェア (アプリケーション) と呼びます。正式名称を使うとイメージが掴みにくいのですが、
「OS」、
「アプリ」といった略称で普段私たちが呼んでいるもの、と言った方が馴染みやすいかも知れません。図
4.1にオペレーティングシステム の位置付けを示します。この図から、普段私たちユーザはコンピュータを
直接操作しているのではなく、必ず OS を経由していることがわかります1。
前置きが長くなってしまいましたが、簡単に言えば OS とは「ユーザとコンピュータ ( ハードウェア) の
間にあって、プログラミングやコンピュータの操作をより簡単にしてくれるシステム」と言うことができ
1 たとえば、複数の文書を並行して印刷する場合を考えます。このとき、順序を調整するしくみがなければ、印刷の操作をする度
に印刷中の文書が中止してしまうでしょう。OS はこのように周辺機器 (ハードウェア資源) の利用順を調整したりする役割も持って
います。
第 4 章 UNIX リテラシ
40
ます。もう少していねいに書けば、
「コンピュータハードウェアの有効活用を行なうため、多くのプログラムを同時並行的に、かつ高速に
実行させるための基本的なしくみを提供するシステム」
となります。このため、OS の仕事は各種資源 (ハードウェア、ソフトウェア、周辺機器など) の割り当て
と保護、プログラムの実行、入出力操作、ファイル操作などになります。また、オペレーティングシステ
ムで、もっとも核となる機能を提供するプログラムを「カーネル」と呼びます。
4.2
UNIX の歴史と特徴
図 4.2に UNIX 系 OS の系統図を示します ([?] より引用)。
図 4.2: UNIX の歴史
UNIX は 1969 年に AT & T のベル研究所ではじめて開発されました。当時、MIT（マサチューセッツ
工科大学）と GE（ゼネラルエレクトリック）社が共同開発した Multics という斬新な OS が UNIX 開発
のもとになりました。UNIX は、当初コンピュータの能力を最大限生かすために直接機械語で書かれてい
ましたが、1973 年に D. リッチーによって C 言語で書き換えられました。C 言語は UNIX を記述するため
に開発されたハードウェア依存の非常に少ないコンピュータ言語です。現在では、C 言語が UNIX 上はも
ちろん他の OS でも標準的なプログラミング言語となっているのは周知の通りです。UNIX が C 言語で書
き換えられたことから、UNIX はメインフレームからパソコンまでのあらゆるコンピュータ上で動作可能
な非常に拡張性の高い OS となりました。
1978 年に発表された UNIX 第７版になって，ほぼ現在の UNIX と同じ機能が装備されました。この AT
& T のベル研究所によって開発されてきた UNIX は一般に System V（システムファイブ）系の UNIX
と呼ばれます。一方で、UNIX 第 7 版が発表されたのと同時期から、カリフォルニア大学バークレイ校に
4.2. UNIX の歴史と特徴
41
よって本格的な UNIX の改造が行なわれています。結果として、AT &T の System V 系とバークレイ校の
4.2BSD （Barkley Software Distribution）系の 2 種類の UNIX が世界に普及することになります。とくに
System V 系の UNIX は、米国政府がコンピュータ調達基準の標準 OS として採用したことから、現在の
商用 UNIX のほとんどが System V 系の UNIX をベースにしています (IBM 社の AIX、Sun 社の Solaris、
HP 社の HP-UX、日立の HI-UX など)。
BSD 系の UNIX は、とくに ARPA（米国高等研究計画局）のプロジェクトとしてネットワーク機能が強
化されており2 、UNIX 自身のソースコード（もちろん C 言語で書かれた）の大半が入手できるなどの理由
で、主として教育・研究用としての位置付けがなされてきました。現在、利用されている UNIX 系 OS は、
いずれも System V 系と BSD 系のそれぞれの優れた特徴を合わせ持つ統合化 UNIX となっています。し
かし、BSD 系 UNIX は一部 AT & T で開発された System V 系 UNIX のライセンスを必要としていたた
めに、System V 系 UNIX に依存しない 4.3BSD Net/2 という OS が 1991 年に開発されました。しかし、
これも完全ではなく、1992 年に AT & T の子会社である USL(Unix Systems Laboratories) 社によってラ
イセンス違反の訴訟を起こされてしまいます。結果として、1994 年に System V 系のソースコードに一切
抵触しない 4.4BSD-Lite が苦難の上に開発されました。この 4.4BSD-Lite が、現在の BSD 由来のオープ
ンソースとなる PC-UNIX (FreeBSD, NetBSD, OpenBSD など) の元になっています。
また、以上の UNIX の歴史とは別に、オープンソースである PC-UNIX の Linux が 1991 年頃から現在
にかけて広く発展・普及してきています。この Linux(リナックス、リヌークス、ライナックスなど呼称多
数) は、本来スウェーデンのＬ（リナス）．トーバラスが開発した UNIX 風カーネルの名称です。そのカー
ネルに GNU で開発された各種の周辺ソフトウェア、ツール群を組合せて一つの OS パッケージとしたも
のを「Linux ディストリビューション」と言い、現在ではそれらのディストリビューションを Linux と言
う場合がほとんどです3 。
UNIX 系 OS の特徴をまとめるなら、つぎのようなものになるでしょう。
1. 会話型マルチユーザ／マルチタスク 複数ユーザによる対話処理、複数のプログラムを同時実行可能
2. 階層構造ファイルシステム フォルダ中にフォルダを配置できるなど、階層的なファイルシステム em 柔
軟性の高いシェル（コマンドインタプリタ）のプログラムを同時実行可能
3. 会話型マルチユーザ／マルチタスク コマンド入力やシェルスクリプト (MS-DOS でいうバッチプログ
ラム)
4. 柔軟性の高いプロセスシステム プロセスシステムの生成・消滅、プロセス間通信、優先順位決定機能
など
5. 豊富なコマンドおよびソフトウェアツール 言語や各種言語の開発システムが充実
6. 会話型マルチユーザ／マルチタスク 複数ユーザによる対話処理、複数のプログラムを同時実行可能
7. ウィンドウ環境 X.org(XFree86) など X ウィンドウシステムによる GUI
8. 高い移植性 メインフレームからパソコンまで，どのマシンを使ってもコマンド体系の大半は同じ。汎
用の大型コンピュータから、PDA(携帯端末) に至るまで動作可能
2 TCP/IP を世界で初めて標準実装した OS として知られています。また、インターネットの祖先である ARPANET では BSD
系 UNIX が全面的に使用されていました。
3 したがって、Linux 系 PC-UNIX のことを「GNU/Linux と呼ぶべきである」
、と GNU プロジェクトでは主張しています。
第 4 章 UNIX リテラシ
42
以上のように並べていくといかにも難しい機能のように思えるのですが、実は現在ユーザが対話的4 に利
用する OS の基本機能をすべて網羅しているだけのことです。これだけとってみても、1970 年代に考えら
れた OS としては革新的であったことがうかがえます。
シェルと簡単な UNIX コマンド
4.3
4.3.1
シェル
端末でキーボードから入力された文字列を理解し、コマンドを実際に実行してくれているプログラムを
「シェル」(Shell) と呼びます5。別名を「コマンドインタプリタ」(コマンドを受け付けて逐次実行するも
の、という意味) とも呼びます。シェルは UNIX のあらゆる処理を手助けすることを目的として作られて
おり、UNIX を利用する限りは何らかの形でお世話になっている重要なプログラムです。
最初に、# のような文字が表示されますが、この記号を「プロンプト」と呼びます6 。このプロンプトは、
シェルがユーザにコマンド入力を求めている状態です。
一方、コマンド & と入力すると、シェルは自分自身とは別の裏でプログラムを動作させることができま
す。このように起動されたプログラムをバック (裏) グラウンドプロセスと呼びます。これは、複数のプロ
グラムを同じシェルで並行して動作させる場合によく用いられる方法です。
UNIX は、いくつか代表的なシェルを備えていますが、どのシェルを利用するかはユーザ登録時に管理
者によって決められています。もちろん、ユーザが自分で利用するシェルを変更することも可能です。表
4.1に代表的なシェルを示します。
ユーザはいったんシステムにログインすると、予め設定された種類の「ログインシェル」と呼ばれるシェ
ルに入ります。また、「端末」などを起動するとその度に同じシェルが起動することになります。自分がど
の種類のシェルが起動するようになっているのか確かめてみましょう。
演習 4.1 以下のコマンドによってシェルの種類を確認してみましょう。
echo
$SHELL
を実行してみましょう。echo はシェルの上で利用可能な、画面に文字列を表示するためのコマンドです。
このコマンドはシェルそのものに組み込まれており、「シェルコマンド」と呼ばれます。また、「$文字列」
はシェルの起動や動作を制御する「環境変数」を示します。ここで、「echo $SHELL」は、$SHELL とい
う環境変数の内容を画面に表示せよ、という意味になります。$SHELL という環境変数は、ユーザが現在
利用しているシェルのプログラム名が格納されています。
演習 4.2 参考までに、
echo
echo
”GNU is not UNIX ”
GNU is not UNIX
とそれぞれ実行してみましょう。なお、ダブルクォーテーション「 ”」で囲まれた部分をコンピュータは
文字列と見なします。echo コマンドは「 ”」なしでも文字列を認識してくれますが、空白を含む文字列を
指定する場合はしばしば「 ”」が用いられることに注意しましょう。
4 「対話的でない OS」のイメージがつかみにくいと思いますが、以前のコンピュータは高価で短寿命だったために専任のオペ
レータによって操作されていた時代があります。つまり、オペレータがユーザの代わりにコンピュータを操作し、プログラムの実行
を行う、という形です。このオペレータの操作を自動化したものが OS である、とも言えます。
5 Windows の世界だと「MS-DOS コマンドプロンプト」がこのシェルに相当します。
6 MS-DOS コマンドプロンプトでは、C:\ のようなコマンドプロンプトが現われます。
4.3. シェルと簡単な UNIX コマンド
43
表 4.1: UNIX の代表的シェル
Shell プログラム
正式名称
説明
sh
Bourn(ボーン) シェル
1979 年に UNIX System V に付属していたシェルで、
現在のあらゆる UNIX 系 OS は標準で備えている。た
だし、低機能。
ksh
Korn シェル
sh に履歴やエイリアス (コマンドの別名定義) などの
機能を拡張したもの。Bell 研究所の D.Korn 氏が開発
した。
csh
C シェル
BSD UNIX 開発の際に作られたシェル。sh,ksh を発展
させたもので、設定方法などがそれらとはかなり異
なる。
bash
Bourn Again シェル
FSF(Free Software Foundation) によって作成された
シェル。sh 系でありながら、csh などの利点を取り込
んでいる。多くの Linux で標準として採用されている。
zsh
Z シェル
ksh に似ているが、プログラミング可能なコマンド補完
機能など、「究極のシェル」とも呼ばれる。
tcsh
拡張 C シェル
csh を拡張した高機能化シェル。BSD 系で標準として採用
されている。
演習 4.3 シェルの上でキーボード入力した文字列は、Backspace(左側 1 文字削除)、Delete(右側 1 文字削
除) によって削除できます。また, 矢印キー「←」、
「→」によって、それぞれ左、右に移動できます。また、
「↑」や↓」によって過去に入力したコマンドに移動できます。
第 4 章 UNIX リテラシ
44
babababababababababababababababababababab
(One Point)
文字の削除キー、矢印キーによって各種のコマンドを入力してもいいのですが、これだとせっか
く極めたタッチタイピングが無意味になってしまいますa。そこで、bash や tcsh といったシェル
では、emacs ライクなキーバインドが利用できるようになっています (表 4.2)。
これらのキーバインドは覚えておかなくても大丈夫ですが、マスターしておくと非常に強力な武
器になります。たとえば、Windows では Xkeymacs
http://www.itmedia.co.jp/enterprise/articles/0508/17/news003.html
というオープンソースがあります。この Xkeymacs によると、Windows 上のすべてのアプリケー
ション上で emacs ライクなキーバインドが利用できるようになります。また、CapsLock と Ctrl
キーの入れ換えなどもできます。また、Ubuntu でも、Firefox で firemacs というアドオンを追加
すると Firefox 上のキー入力が emacs 風になるなど、emacs キーバインドはいたるところで利用
可能になっています。
となると、CapsLock キーが「A」の文字の隣にあると、非常に不便ですねb。矢印キーに慣れて
しまっていると、少々ハードルが高いですが、emacs キーバインドを極めるとパソコンライフが
一変するでしょう。
a タイピングの基本は、ホームポジション (「F」,「J」のキーにそれぞれ左手の人指し指、右手の人指し指) を置き、
それから可能な限り手を離さないことです。タイピングの際に、いちいち矢印キーに右手を持っていくと、その後の文字
入力がスムーズにいかなくなります。
b かつての NEC 9801 シリーズ、Sun 社のワークステーションなどのキーボードはすべて「A」の隣が Ctrl キーで
した。めったに使わないキーをわざわざタイプミスしやすい「A」の隣に配置するなど、現在の JIS キーボードの設計は
かなりダメだと言われています。UNIX 系 OS のユーザにはキーボードにこだわる人が多いのが特徴です。
4.4
簡単な UNIX コマンド
それでは、シェルの上で実行するいくつかの基本コマンドを体験してみましょう。
4.4. 簡単な UNIX コマンド
45
表 4.2: bash,tcsh,zsh のキーバインド
キー
効果
キー
効果
Ctrl+n
(↓)
1 つ次のコマンドへ
Ctrl+p
(↑)
一つ前のコマンドへ
Ctrl+f
1 つ右の文字へ
Ctrl+b
一つ左の文字へ
(→)
(←)
Ctrl+a
行頭へ移動
Ctrl+e
行末へ移動
Ctrl+k
行末まで削除
Ctrl+h
左 1 文字削除 (BS)
Ctrl+d
右 1 文字削除 (DEL)
Ctrl+Space
範囲指定 (始点)
(↓)
(↑)
Esc+w
ヤンク
Ctrl+w
カット
Ctrl+y
ペースト
—
—
演習 4.4 日付表示コマンド
単に
date
を実行します。出力される JST という文字列は、日本での時間を意味しています。
演習 4.5 オンラインマニュアルコマンド
man コマンド名
を実行します。但し、この場合英語のマニュアルが表示されます。既に、日本語マニュアルとそのコマン
ドを導入していますので、日本語 man を使ってみましょう。日本語 man のコマンドは jman です。既に、
これを使うための設定はしていますので、次のようにして使います。
jman date
を実行してみて下さい。終了する場合は「q」のキーを押します。改行キーで 1 行ずつ、space キーで 1 画
面ずつ進みます。また、emacs キーバインドのカーソル移動キーが使えます (Ctrl + f,b,n,p)。さらに、/
を押した後に文字列を入力すると前方検索になります (？を押した後で文字列を入力すると後方検索)。表
4.2の emacs キーバインドで示していませんが、Esc + < でマニュアルの先頭に、Esc + > でマニュアル
の最後にジャンプします。それぞれ試してみましょう。
演習 4.6 パスワード変更コマンド7
まず、一旦 X-window を終了して下さい。そのうえで、
7 NIS と呼ばれるシステムを用いてユーザアカウントをネットワーク上で共有管理している組織内では passwd コマンドは yppasswd
を用います。また、 LDAP と呼ばれるシステムを用いてユーザアカウントを共有管理している組織内では ldap-passwd あるいは
smbldap-passwd というコマンドが用いられることがあります。この方法は組織によって異なりますので、みなさんの組織のネット
ワーク管理者に尋ねましょう。
第 4 章 UNIX リテラシ
46
図 4.3: コマンドによるパスワード変更
passwd
を実行してみて下さい。現在のパスワードを入力した上で、新しいパスワードを確認を含めて 2 回入力す
ることでパスワードを変更できます (図4.3)。パスワードを変更したら、 ALT + F2 キー (ALT キーを押
しながら F2 キー) を押して下さい。再度、ログインの画面になります。これは、一台の FreeBSD のコン
ソール画面が仮想的に複数あるようになっているからです。(標準では F1 から F8 までの 8 台が装備され
ており、一台のマシンに 8 台の画面があると思えば良いでしょう。)
ここで、先に変更したパスワードでログインできるかどうかを確かめて下さい。当然、user は root です。
うまく、ログイン出来ることを確かめたら、再度 passwd コマンドで、元のパスワード netadmin にパ
スワードを戻して、今度は ALT+F3 を押して、この画面で元のパスワードでログイン出来るかどうかを
確かめて下さい。
多くのユーザのパスワードやその他の管理では、コマンドによる設定変更などの作業は、シェル上のプ
ログラム (シェルスクリプト) によって、かなりの部分自動化が可能です。パスワードは 8 文字以上でつぎ
の原則に気をつけましょう。
1. 英文字だけでなく、数字、特殊文字（記号）を必ず含める
2. 大文字と小文字を区別するので、適宜大文字を含める
3. 電話番号や生年月日、英単語など、分かりやすいパスワードを付けない
4. パスワードを他人に教えない
5. パスワードを電子メールで送付しない
6. パスワードを忘れない（ログインできなくなる）
7. パスワードを定期的に変更することが望ましい
短かいパスワードは変更が拒否されることがあります。上記の条件は、簡単にパスワードを推測されたり、
他人にパスワードを不正利用されないために必要です。みなさんは、これまでに生年月日などをパスワー
ドにしてはいけない、ということは聞いたことがあると思います。しかし、英単語はなぜでしょう？
4.5. ファイルとディレクトリの基本
47
これは、「辞書攻撃」や「総当たり攻撃」というパスワードクラック (パスワーを推測で入力して他人に
なりすますこと) で簡単に破られてしまうためです。コンピュータにとっては、パスワードとして辞書の数
万語を繰り返し試す作業は苦もありません。
演習 4.7 現在コンピュータを利用しているユーザを表示、自分のユーザ名表示
who
whoami
をそれぞれ実行してみて下さい。whoami は Who am I?で英語そのままですね。who コマンドでは、ユー
ザが利用している端末番号やログインした時間などが表示されます。これらはいずれも複数ユーザが利用
している場合には役立つコマンドです。
演習 4.8 カレンダーを表示する
cal
cal
9
2009
をそれぞれ実行してみて下さい。前者は今月のカレンダーを、後者は 2009 年 9 月のカレンダーを表示し
ます。既に体験して頂いていますが、UNIX コマンドはいくつかのパラメータを指定することができ、そ
のパラメータは「空白」によって区切られることに注意しましょう。
4.5
ファイルとディレクトリの基本
さて、前節で簡単な UNIX コマンドを体験してもらいましたが、もう一歩進んでファイルとディレクト
リの概念をマスターしましょう。UNIX ではプログラムやデータ、電子メールはもちろん、コンピュータや
周辺機器 (プリンタ、ディスプレイ、キーボード、マウス、サウンドカード、ネットワークインターフェー
スなど) についてもファイルで表現します。このため、UNIX コマンドの多くがファイルやディレクトリの
概念に関連して用いられます。これらの概念は初心者には少々やっかいですが、Windows での例も含めて
説明していきましょう。
4.5.1
ファイルとディレクトリ
コンピュータシステムにおけるファイルは、ハードディスク、CD、DVD、USB メモリ等の記録媒体上
に記録されたデータのまとまりのことを指します。このデータにアクセス8 するためには、何らかの方法
でそのデータを指定する必要がありますが、一般にファイルには名前がつけられいて、その名前を用いて
アクセスが行なわれます。この名前を「ファイル名」、ファイルを保管する場所を「ディレクトリ (住所、
所属)」と言い、こちらにも「ディレクトリ名」という名前がつけられています。厳密に言えば、ディレク
トリも特殊なファイルとして扱われます9。
ファイルの種類としては、通常ファイル、ディレクトリ、リンク、特殊ファイルの 4 種類があります。
(1) 通常ファイル テキスト (文字) ファイル、テキストファイルの中でもとくにアプリケーションで処理さ
れるテキストファイルをデータファイルと呼ぶことがあります。また、スクリプト言語と呼ばれる言
8
データの読み・書き・操作をコンピュータ用語でアクセスと言います。
ファイルは Windows など他の OS でも導入されていますが、ディレクトリは「フォルダ」と呼ばれます。紙のファイルとその
ファイルを入れるフォルダのアイコン (絵) がよく用いられていますが、感覚的には「フォルダ」の方が理解しやすいですね。
9
第 4 章 UNIX リテラシ
48
図 4.4: ディレクトリの階層構造
語で書かれたプログラムは、テキストファイルと同じ形式となっていますが、スクリプトファイル
(コマンドファイル) と呼ぶことがあります。さらに、コンピュータが理解可能な 2 進数形式のデータ
ファイルは、バイナリ (2 進数) ファイルと呼ばれます。
(2) ディレクトリ ディレクトリはその中に複数のファイルを格納できる特殊なファイルです。
(3) リンク 簡単に言えば、リンクはファイルやディレクトリにつけられる別名です。たとえば、同じデー
タを何箇所も保存するとそれだけでディスク領域が無駄になります。この場合、ファイルやディレク
トリを一箇所に置き、そのファイルやディレクトリをリンクによって別名を関連づけることで目的が
達成されます。Windows のショートカットがこのリンクに相当します。
(4) 特殊 (デバイス) ファイル UNIX で扱う物理的なハードウェア (プリンタ、ネットワークカードなどの
周辺機器を含む) を表すファイルです。
ファイル (ディレクトリ) 名は最大 255 文字までで、名前に「.」(ピリオド) が複数利用できるなど、柔軟
に設定できます。また、一部の Windows ではファイル名に大文字、小文字の区別ができないものがありま
すが、UNIX は区別されます。
また、UNIX でのファイル名にはいくつか規則があります。
(規則 1) ファイル名として用いると好ましくない文字 (文字列)
! @ # $ % ^
& ( ) [ ] ’ “ ? \ | ; < > ‘ + - % ..(ピリオド 2 つの連続)
(規則 2) ファイル名の先頭に.(ピリオド) がつくファイルは各種設定ファイルとして利用します。
(例).bashrc .xinitrc .cshrc .emacs など
必ずしもこの規則に従う必要はありませんが、ファイル名の表示の際に「.」が先頭につくファイル名は
表示されな い場合があります。
(規則 3) 拡張子の規則
ファイル名の最後につけられる「. 文字列」の文字列を拡張子と言います。Windows でも、.doc, .bat、
.c、.lzh などの拡張子が用いられていますが、UNIX システムでは拡張子によってそのファイルの処理方法
を暗黙のうちに知らせることができます。必ずしもこの規則に従う必要はありませんが、他のユーザとの
データ交換の際に困ることになります。表 4.3に代表的な拡張子を示します。
4.5.2
UNIX のディレクトリ構造
UNIX や Windows など多くの OS で、ディレクトリ (フォルダ) が階層構造となっています。図 4.4に
UNIX ディレクトリの階層構造を示します。
4.5. ファイルとディレクトリの基本
49
表 4.3: UNIX で用いられる代表的な拡張子
拡張子
意味
.txt
通常のテキスト (文字、文字列) ファイル
.html
HTML(Hyper Text Markup Language) 形式のファイル
.xml
XML(Extensible Markup Language) 形式のファイル
.odt
OpenOffice などで生成されるオープンドキュメントのファイル (xml)
.Z
UNIX 標準のデータ圧縮ファイル
.tar
UNIX の tar コマンドによってまとめられた (archived) ファイル
.gz
gzip コマンドによって圧縮されたファイル
.zip
zip コマンドによって圧縮されたファイル (zip 以外にも作成可能なソフトあり)
.bz2
bzip2 コマンドによって圧縮されたファイル
.gif,.jpg,.png
各 GIF,JPEG,PNG 形式の画像ファイル
.ps, .eps
Postscript 言語で記述されたファイル (eps は埋め込み用)
.avi,.mpg,.rm,.wmv
各 AVI, mpeg、Realmedia, WMV 形式の動画ファイル
.mp3, .aac
MP3、AAC 形式の音声 (音楽) ファイル
.c ,.cpp,.pl,.rb,.php,.java,.a
C 言語、C++、Perl、Ruby などプログラムに関するファイル
.dev, .rpm
Debian/GNU Linux, RedHat Linux で開発されたソフトウェアパッケージ
UNIX では、ユーザがログインするとあらかじめ用意された自分専用のディレクトリに入ります。この
ディレクトリを「ホームディレクトリ」と呼びます。また、階層の最上位（ツリー構造の根）にあたる部
分を「ルートディレクトリ」と呼び「 / （スラッシュ）」で表します。たとえば yamada というユーザを
最上位ディレクトリ（ルートディレクトリ）から数えると、「 / 」の下の「home」の下の「yamada」とい
うことになります。また、UNIX では取り扱われるファイルは機能や性質ごとにさまざまなディレクトリ
に整理して保管しています (表 4.4参照)。また、ディレクトリの中のディレクトリを「サブディレクトリ」
と呼びます。
4.5.3
ファイルとディレクトリの操作 (その 1)
それでは、ファイルとディレクトリの操作コマンドの紹介と演習を行いましょう。早速ですが、端末を
開いておきましょう。
演習 4.9 カレンドディレクトリを調べる
UNIX のシェル、MS-DOS コマンドプロンプト共に、現在作業の対象とするディレクトリ (フォルダ) を
カレントディレクトリと呼びます。カレントディレクトリを調べる方法は、Print Working Directory の略
である
pwd
というコマンドを実行することです。すべて小文字であることに注意しましょう。また、MS-DOS コマン
ドプロンプトでも同じ役割を果たすコマンド cd があります11 。
11 MS-DOS
コマンドプロンプトでは, 「C:\Document and Setting\ ユーザ名」のように表示されます。 MS-DOS では、UNIX
第 4 章 UNIX リテラシ
50
表 4.4: UNIX の主要なディレクトリと保管ファイル
ディレクトリ
保管ファイル
/bin
UNIX の基本的コマンド (binary)
/boot
システム起動時に使用されるファイル群
/dev
物理デバイスを示す特殊ファイル群
/etc
システム固有の設定ファイル群。原則システム管理者が編集可能。
/lib
システムが備えるライブラリ群
/media
リムーバブルメディアアクセス用 (Linux 特有)
/mnt
一時的に利用するファイルシステムを関連づけるディレクトリ
/opt
追加アプリケーション用のディレクトリ (Linux,SysV 系 UNIX 特有)
/sbin
システム管理に利用されるユーティリティ群 /tmp
作業ファイル等を一時的に保存するためのディレクトリ /usr
さまざまなプログラムファイル群
/var
可変データが置かれる (メール、データベース、プリンタキューなど)
/home
一般ユーザのホームディレクトリ群
10
たとえば、みなさんがログイン直後に端末を起動して、pwd コマンドを実行するとつぎのような文字列
が表示されるはずです。これが、みなさんの「ホームディレクトリ」です。
/home/ユーザ名
この表示をながめてみると、
「 ”/ ”(ルートディレクトリ) の下の ”home ”ディレクトリの下の ”ユーザ名 ”ディレクトリ」
という意味になります。
但し、まだユーザは作成していないので、root のホームだけは特別で /root になっています。
演習 4.10 カレンドディレクトリを変更する
それでは、作業の対象となるカレントディレクトリを変更してみましょう。方法は、Change Directory
の略語である
cd
移動したいディレクトリ名
というコマンドを実行することです。一つ上の階層のディレクトリに移動する場合は「..」(ピリオド 2 つ)
を指定します。実際につぎのようにコマンドを実行してみましょう。
でいう/が \(バックスラッシュ、フォントによっては Y) となることに注意しましょう。
4.5. ファイルとディレクトリの基本
51
pwd
(「/home/ユーザ名」と表示)
cd ..
pwd
(「/home」と表示。/home に移動したことになる)
cd ..
pwd
(「/」と表示。/(ルートディレクトリ) に移動したことになる)
cd
pwd
usr
(「/usr」と表示。/usr に移動したことになる)
cd
pwd
(オプションなしで cd コマンドを実行)
(「/home/ユーザ名」と表示。ホームディレクトリに一気に移動した！)
cd
../..
pwd
(「/」と表示。../.. は一気に 2 つ上のディレクトリへ移動する)
また、MS-DOS コマンドプロンプトでも同じ cd コマンドが実行できます。ただし、
cd
c:\Document and Setting\hara
のように、ディレクトリ (フォルダ) の区切りである/の代わりに \ あるいは Y を使います。
演習 4.11 相対パスと絶対パス
ディレクトリには「絶対パス」と「相対パス」という概念があります。ここで、「パス」というのは通り
道という意味があります。たとえば、
/home/ユーザ名
のようなディレクトリ表示は、先頭に /（スラッシュ）が付いていますが、このディレクトリの表現方法
を「絶対パス」と呼びます。このディレクトリにたどりつくためのパス (通り道) は、
「先頭の /（スラッシュ）=最上位ディレクトリ（ルートディレクトリ）」
「/ディレクトリの下にある home ディレクトリ」
「/home ディレクトリの下の ユーザ名ディレクトリ」
という順序を表わしています。最初に /（スラッシュ）の付かないディレクトリは、今自分のいるディレ
クトリ（カレントディレクトリ）から相対的に見たディレクトリを示します。このようなディレクトリの
表し方を「相対パス」と言います。図4.5は、絶対パスと相対パスの関係を示しています。たとえば、カレ
ントディレクトリが「yamada」だとすると、「usr」というディレクトリは、
/usr
../../usr
絶対パス
相対パス
と表わされます。
それでは、つぎの演習をやってみましょう。
第 4 章 UNIX リテラシ
52
図 4.5: 絶対パスと相対パス
cd
pwd
(「/root」と表示)
cd /usr
pwd
(「/usr」と表示)
(再度、ホームディレクトリに戻りましょう。方法は書かなくてもわかりますね？)
cd ../etc
pwd
(「/etc と表示)
演習 4.12 ファイルのリスト (その 1)
カレントディレクトリにあるディレクトリあるいはファイルの内容をリスト (list) するためのコマンド
がオプションなしの ls です。単にオプションなしで cd を実行してホームディレクトリへ移動し、ls コマン
ドを実行してみましょう。恐らく
.cshrc
.k5login
.history .lesshst
.login
.profile
と表示されるはずです。ディレクトリ名やファイル名がアルファベット順に表示されます。しかし、こ
れだけではファイルかディレクトリか区別がつきません一般には、ls コマンドは、
ls
[オプション]
[見たいディレクトリ名]
と表わされます。[ ] 内のオプションとディレクトリ名は省略できますが、その場合はカレントディレクト
リが対象となります。では、
ls
/usr
を実行してみましょう。
X11R6 bin games include lib local sbin share src
のように表示されるはずです。
演習 4.13 ファイルのリスト (その 2)
4.5. ファイルとディレクトリの基本
53
図 4.6: ls -a および ls -l コマンドの実行例
それでは、ls コマンドについて、各種のオプションを利用してみましょう。オプションは非常に多いの
ですが、よく使われるパターンを紹介します。
(1) ディレクトリとファイルを区別して表示
ls -F /usr
を実行します。すると、
X11R6@
bin/
games/
home/
lib/
libdata/
local/
obj/
sbin/
share/
compat/
include/
libexec/
ports/
src/
という形で、ディレクトリには最後に/がつきます。また、リンクにはが、実行可能なバイナリファイルに
は*がつきます。
(2) 隠しファイル・ディレクトリを含めてすべて表示 (図4.7参照)
ls -a
を実行すると、隠しファイルを含めてすべて (a は all の略) 表示します。とくに、先頭に「.」(ピリオド)
がつくファイルが表示されることに注意しましょう。(root で ls を実行すると、デフォルトで全ての隠し
ファイルが見えるようになっています。)
(3) ファイル、ディレクトリの詳細情報を表示する (図4.6参 照)
ls
-l
を実行すると、ファイル名やディレクトリ名などファイルに関する全情報を表示します。
(4)(1)∼(3) のオプションの組合せ
たとえば、 (2)、(3) のオプションを組合せると、
第 4 章 UNIX リテラシ
54
図 4.7: ls -al コマンドの実行例
ls -al
を実行できます (図4.7参照)。
ここで、ls -l と ls -al に「.」と「..」が表示されていることに注意しましょう。
「.」はカレントディレク
トそのものを表わしており、「..」は一つ上のディレトリそのものを表わしています。
4.5.4
ファイルとディレクトリの操作 (その 2)
演習 4.14 ファイルの内容を表示する
個々のファイルの内容を表示するコマンドには， cat， more があります。いずれもテキストファイルの
み表示可能ですが、使用法はいずれも似ています。それは、
[-オプション]
[-オプション]
cat
more
[見たいファイル名]
[見たいファイル名]
となりますが、オプションを使う機会はほとんどありません。cat は、ファイルの全内容を一気に表示し
ようとします。一方、more は一画面ずつ表示を停止してくれます。more の場合は、改行で 1 行ずつ進み、
space キーで一画面ずつ進みます。
では、「ホームディレクトリ」中のファイルの内容を覗いてみましょう。実は、みなさんのホームディレ
クトリにはまだディレクトリ、リンク、隠しファイルしか存在していないかも知れません。ですので、
ls
-al
を実行し、.cshrc というファイルがあるのを確認した上で、つぎのコマンドを実行してみましょう。
cat
.cshrc
more
.cshrc
4.5. ファイルとディレクトリの基本
55
演習 4.15 ファイルのコピー
ファイルとディレクトリのコピー方法について説明します。ファイルを複製（コピー）するには cp コマ
ンド（copy）を用います。使用方法は以下の通りです。
cp
［-オプション］
［ファイル名 1］
［ファイル名 2］
cp コマンドはこのようにファイル１をファイル２をコピーします。もしファイル２がなかったら新しい
ファイルが作られ、既にファイル２が存在すればファイル１の内容に書きかえます（ファイル２の内容は
消えてしまうことに注意しましょう！）。
それでは、つぎの手順で cp コマンドを試します。ホームディレクトリに移動した状態で実験しましょう。
(1) ファイルのリダイレクション (> あるいは >>) によるテキストファイル作成
cat
>
test.txt
Welcome to UNIX World!!
--> この内容は適当に変更しても OK です。
Ctrl + d
--> Ctrl キーと「d」を同時に押す
1 行目は、cat(ファイルの内容を表示) コマンドの特殊な使い方です。2 行目以降のキーボード入力をその
まま画面表示する、という意味で用いられています。また、> は本来画面表示すべき内容を画面ではなく、
ファイルに出力する場合に用います。簡単に言えば、2 行目の Welcome to UNIX World!という文字列が
記述されたファイルをコマンドのみを用いて作成する方法だと理解しておいて下さい12
(2) ファイルが実際にできたかどうか確認します。
test.txt
(3) コピーを実行します。
ls
more
cp test.txt
test-new.txt
(4) コピーされたファイルを確認します
ls
more
test-new.txt
ls
演習 4.16 ディレクトリのコピー
ディレクトリをコピーするのも cp コマンドですが、オプションを指定する必要があります。それでは、
作業の対象となるカレントディレクトリにディレクトリを作成してみましょう。(1) ディレクトリを作成し
ます
mkdir
testdir
12 別の方法として、 「echo “ Welcom to UNIX world! ” > test.txt」でもかまいません。こちらの方が直感的かも知れません。
> を用いると、test.txt が存在していれば上書き (ファイルの内容を消去した上で書き込む)、存在しなければファイルを新規作成し
て書き込みます。> を >> に変更すると、test.txt が存在していればファイルの内容を消去せずに最後に内容を追加、存在しなけれ
ばファイルを新規作成して書き込みます。
第 4 章 UNIX リテラシ
56
(2) 作成したディレクトリがあるかどうか確認します
ls
-F
(3) 作成したディレクトリ内に空のファイルを作成します
cd
testdir
touch
cd
test3.txt
--> ホームディレクトリに戻っておきます。
touch コマンドは空 (データが入っていない) ファイルを作るコマンドです。
(4) 作成したディレクトリ (ディレクトリ内に空ファイルを作成済み) を確認します
ls
cat
-al testdir
-->調べるディレクトリを指定
testdir/test3.txt -->空なので何も表示されないはず
(5) 作成したディレクトリをコピーします
cp
-r
testdir
testdir2
「-r」というオプションは「再帰的」という意味で、コピーの対象となるディレクトリ内のファイル、ディ
レクトリについてもすべてコピーする、という意味になります。
「-r」を忘れると OS に怒られてコピーで
きませんので、注意して下さい。
演習 4.17 ファイルとディレクトリの移動∼名称変更∼
ファイル名（またはディレクトリ名）を変更／移動するためには mv コマンド (move) を用います。使用
方法は以下の通りです。
mv
［-オプション］
［ファイル名 1］
［ファイル名 2］
mv コマンドはファイル 1 の名前をファイル 2 という名前に変更します。もし、既にファイル 2 が存在して
いる場合、元のファイル名２は削除され、新しいものに上書きされます。
(1) ホームディレクトリの ファイルを確認します。
ls --> test.txt,test-new.txt,testdir,testdir-new があるはずです。
(2) そのうちの一つを用いて実験してみます。
mv
test.txt
test-move.txt
(3) 元のファイル test.txt がなくなって、test-move.txt ができたのを確認しましょう。
4.5. ファイルとディレクトリの基本
57
ls
more test-move.txt
ディレクトリについてもオプションなしで同様に名称変更が可能です。
演習 4.18 ファイルとディレクトリの移動∼移動∼
(1) 作成したファイルを演習 23 で作成したディレクトリ内に移動してみましょう。
mv
test-move.txt
testdir/
n 移動先のディレクトリのみ指定していますので、testdir/フォルダの下に test-move.txt というファイルが
移動しました。(2) 移動したファイルを確認してみましょう
ls
more
testdir/
testdir/test-move.txt
(3) 今度は移動と同時にファイル名も変更してみましょう。
mv
ls
test-new.txt
testdir/
more
testdir/test-move.txt
testdir/test-newname.txt
演習 4.19 ファイルとディレクトリの削除 (ファイルの削除)
ファイルやディレクトリを削除する場合は rm コマンド（remove）を使用します。
rm ［-オプション］ ［ファイル名］
(1) とりあえず空ファイル test-rm.txt というファイルを新規に作成し、確認しましょう。
touch
ls -al
test-rm.txt
(2) 作成したファイルを削除します。
rm test-rm.txt
(3) ファイルが削除できたことを確認しましょう。
ls -al
(4) 続いて、ディレクトリを削除してみましょう。rm -r コマンドでディレクトリを削除するとディレクト
リ内のファイルもすべて削除されます13 。-r オプションを忘れるとディレクトリは削除できませんので注
意しましょう。
rm
-r
testdir
(5) ディレクトリが削除できたことを確認しましょう。
13 ディレクトリの中にファイルがない場合は、rmdir コマンド、つまり「rmdir ディレクトリ名」でディレクトリを削除できます。
「rm -r ディレクトリ名」は問答無用にディレクトリを削除してしまうため、時として一度に誤ってたくさんのファイルを削除してし
まうことがあります。慎重に削除を行いたい場合は rmdir を用いるといいでしょう。
第 4 章 UNIX リテラシ
58
4.5.5
ls
-al
シェルによる文字列補完とワイルドカード
これまで、ファイルやディレクトリ操作を学んできました。しかし、対象とするファイルがたくさんあ
る場合、コマンドをいちいちすべてタイプしたくない場合はちょっとめんどうです。シェルには、コマンド
入力で楽をする方法がいくつか提供されています。
演習 4.20 シェルによってコマンド名、ファイル名の補完を行ってみましょしょう。
(1)「端末」を起動し、ホームディレクトリでつぎの文字列をタイプしてみましょう。
pass[Tab キー]
wd という文字列が補完されて、 passwd コマンドになったはずです。コマンドを実際に実行したくない場
合は、Ctrl+c(プログラムの実行を強制的に中止する「割込み文字」を発生する) を押します。このように
bash,tcsh,zsh などの高機能シェルでは、コマンドの一部の文字列を入力して [Tab キー] を押すと、残りの
文字列を補完してくれます。なお、sh,ksh,csh は補完機能がありません。
(2) 続いて、
more
/etc/add[Tab キー]
とタイプしてみましょう。このとき、user.conf という文字列が補完され、/etc/adduser.conf となったはず
です。このように、ファイル名の補完も行えます。
演習 4.21 ファイル/ディレクトリ操作に利用できるワイルドカード
各種のコマンドを実行する際に、ファイル名やディレクトリ名を必要とする場合があります。このとき、
ファイルやディレクトリの名前の条件を決めて指定できると操作が簡略できます。その例をいくつか示し
ましょう。
(1) 任意の文字列*
ls
/usr/share/skel/*rc
これは、ファイル名の最後が rc となる/usr/share/skel にある ファイル名すべてをリストせよ、という
意味になります。*は MS-DOS プロンプトでも同様な利用ができますが、
「すべて記号かを使って作ること
ができる任意の長さの文字列」という意味になります。結局、*の部分は空でもかまいませんし、「どのよ
うな文字列でもマッチする」ことになります。結局、
/usr/share/skel/dot.cshrc
/usr/share/skel/dot.shrc
/usr/share/skel/dot.mailrc
などの出力が得られるはずです。ちなみに、
ls
/etc/*rc
も実行して結果を確認しておきましょう。
4.5. ファイルとディレクトリの基本
59
(2) 任意の 1 文字？
ls
ad???
?は「任意の文字 1 文字」という意味になります。これは、「ファイル名の先頭に「ad」がつき、しかも最
後の 3 文字が任意の文字で、合計 5 文字となるファイル名すべて」をリストせよ、という意味になります。
(3) 正規表現によるパターンマッチ
一部ですが、簡単な正規表現14 も利用できます。
ls
[a-c]*
この表現は、先頭が a,b,c のいずれかが続くファイル名すべてをリストせよ、という意味になります。以上
のワイルドカードはすべてのシェルで利用できます。
4.5.6
ファイルとディレクトリを検索する
たとえば、
「yamada」という文字列を含んだファイルを探したい、
「networking」という名前のファイル
を探したい、といった検索するにはどうしたらいいでしょうか？たとえば、GNOME、KDE といったデス
クトップ環境ですと、Windows での検索と同じ方法で可能です。しかし、遠隔地にあるネットワークサー
バですとデスクトップ環境は使えないので、この方法ではお手上げです。ここでは、コマンドによる検索
と GUI による検索の両方を試してみましょう。
演習 4.22 コマンドによるファイル検索
コマンドでファイルを探すために、find コマンドで試してみましょう。
find コマンドの書式はつぎの通りです。
[オプション]
find
[検索パス]
[検索パターン] [オプション]
(1) つぎのコマンドで/(ルート) ディレクトリへ移動します。
cd
/
(2)find コマンドによって、mail というファイルを /etc ディレクトリ以下で検索してみましょう。
find
/etc
-name
mail
-print
Permission denied(許可されていない) という表示が出ますが、/etc/mail のようにファイルの場所を発見
しています。ここで、find の後の「.」は検索パスで、
「カレントディレクトリ」という意味で、-name、-print
はそれぞれ「名前の文字列による検索」、
「結果を標準出力 (画面) に表示」ということを表わしていますが、
「おまじない」として覚えておきましょう。また、つぎのようにワイルドカードを用いることも可能です。
14
find
find
/usr/local -name "*work" -print
/usr/local -name "???work ” -print
文字列を表現する方法の一つで、Perl 言語などに実装されいています。たとえば、迷惑メールの送信元のアドレスをすべて列挙
しているとデータ量が膨大になってしまいます。しかし、迷惑メールを送信してくるアドレスの特徴に共通点があれば、その特徴の
共通点に一致したアドレスからのメールを排除できます。正規表現は、迷惑メールのアドレスに一致するかしないか、というパター
ンマッチングに応用されています。
第 4 章 UNIX リテラシ
60
演習 4.23 コマンドによるパターンマッチ
ある文字列を含むテキストファイルを調べたい場合には、grep コマンドを用います。grep コマンドは応
用が広いのですが、つぎの書式を用います。
grep [オプション] [検索パターン] [対象ファイル]
早速試してみましょう。(1) ホームディレクトリへ移動します。
cd
(2)grep コマンドによって、「EDION」という文字列を含むテキストファイル (設定ファイル) を検索して
みましょう。
grep
EDION *
何も表示されないので、対象を変えましょう。
grep
EDITOR .*
Ubuntu では、.cshrc がヒットします。
最初は対象ファイルとして、ワイルドカード (*、すべてのファイル) を対象としました。また、つぎに
「.」(ピリオド) が先頭につくファイルすべてを対象として検索しました。このように、検索対象を絞り込
むことによってより詳細な検索が可能となります。なお、検索を行うディレクトリに含まれるサブディレ
クトリに対しても同じ検索をかけていく場合は、
grep
-r
[検索パターン] [対象ファイル]
のように-r オプション ( recursive の意味です) を指定します。
4.6. 演習課題
4.6
61
演習課題
演習 4.24 libX11.txt というファイルがどこにあるかを探して、その場所を答えなさい。
演習 4.25 あるディレクトリに以下のようなファイルがあり、
8.0/
Mail/
dlmalloc-2.8.4.tbz
hogehoge
quagga-0.99.17_8.tbz
samba
_insideweb
libgomp.so
kanji-utf
libroken.a
ssl
pam_unix.so.5
libgomp.so.1
libgomp_p.a
libroken.so
libroken.so.10
snmp_atm.so
snmp_atm.so.6
libgpib.a
libgpib.so
libroken_p.a
librpcsec_gss.a
snmp_bridge.so
snmp_bridge.so.6
libgpib.so.3
librpcsec_gss.so
snmp_hostres.so
fingerd
ftpd
mail.local
make_index
smrsh
ssh-keysign
_outsideweb
college
moodle-node.sh
moodle.sh
tex
xorg.conf
www/
これらのファイルの内、頭の文字が a から t までのファイルを全て、www/ ディレクトリに移動させた
い。これを一行のコマンドで行うにはどうすれば良いかを答えなさい。
63
第 5 章 テキスト編集
テキスト編集とは
5.1
私たちが普段コンピュータ上で行う作業の大半がテキストの作成と編集ではないでしょうか。例えば、
メール編集、メモ、レポート作成などはもちろんテキスト編集と言えます。テキスト編集を行うソフトウェ
アを一般にエディタと呼びます。Windows の世界では「メモ帳」などがこのエディタにあたりますし、ワー
プロは文字修飾などの機能を備えた「多機能エディタ」と呼べるでしょう。PC-UNIX を含むすべての UNIX
では、vi(ブイ・アイ) と呼ばれるエディタ1 が標準で実装されています。オープンソースの父とも言える R.
ストールマンは emacs という多機能エディタを作成していますが、現在でも人気で多くの人が利用してい
ます。
5.1.1
vi
vi は VIsual editor の略で、開発当時 1 行単位でしか編集作業を行なえないラインエディタの代替として
開発されました。ラインエディタでは、文書をカーソル移動によって編集することができず、1 行単位で入
力や文字の修正などの編集を行なっていました。現在では、ワープロなどでも当たり前となっているスク
リーンエディタ、つまり 1 画面の単位 (行や文字) でカーソル移動による直接編集が初めて実現したのです。
Windows や MacOS などでワープロや各種エディタしか利用したことがない方にとっては、これから利
用する vi はある意味カルチャーショックを受けるかも知れません。しかし、「あらゆる UNIX 系 OS で利
用できる」、「ネットワーク経由でログインした時も利用できる」といった点でネットワークサーバに関わ
る人にとっては必須の習得事項と言えるでしょう。では、早速利用してみましょう。
シェル (端末) 上で実行可能な vi は、つぎの書式で実行できます。
vi
[オプション]
[ファイル名]
Unix では、オリジナルの vi というコマンドが基本ですが、多くの PC-UNIX では vim あるいは jvim と
いった vi のクローンが実装されています。vim や jvim については「日本語入力」について拡張されてい
ます。vim あるいは jvim のいずれが利用できるかは PC-UNIX によって異なりますので、実際にコマンド
入力してみて試すといいでしょう。
演習 5.1 vi の起動
オプション等なしで単に vi と入力してみましょう (図 5.1参照)。
図 5.1の左端には (チルダ) という記号が見えますが、これは「空行」(何も文字が入力されていない状態)
を示します。既存のファイルを開く場合、新規に作成するファイル名が決まっている場合には、vi(vim) コ
マンドに続いて、ファイル名を指定します。また、既存のファイルを読み込み専用モードで開く場合はそ
れぞれつぎのように実行します。
1 実際には、vi クローンと呼ばれる高機能型の vim(特に日本語化された vim を jvim と呼ぶことがあります) が実装されている
場合がほとんどです (先に導入した vim はこれでした)。
第 5 章 テキスト編集
64
図 5.1: vi の実行例
vi
vi
ファイル名
-R
ファイル名 -->読み取り専用の場合
演習 5.2 vi 事始め
それでは、この vi 上で何も考えずに Hello! World とタイプしてみましょう。数回ビープ音が鳴り、図
5.2のような表示になるはずです。
図 5.2: vi で Hello! World を入力すると？
このような表示になるのは、vi は「コマンドモード」と「入力モード (インサートモード)」の 2 つのモー
ドを持つためです。
コマンドモードは、ほとんどユーザにフィードバック (表示等) がないので、わかりづらいかも知れませ
んが、コマンドモードの状態でキー入力を行っても文字は挿入されませんし、画面にもその文字は表示さ
れません。つまり、このモードでは入力した文字がある意味を持つ“ コマンド ”として処理されます。コマ
ンドは、文字を入力する箇所を変更したり、文字を削除したり、文字をコピー／ペーストしたりする作業
を指します。一方、
「入力モード」の場合は一番下に「–INSERT–」という文字列が表示されます (図 5.2参
5.1. テキスト編集とは
65
照)2 。この状態でキー入力を行った場合、通常のエディタと同様にキー入力がそのままカーソル位置に挿
入されます。
コマンドモード、入力モード (インサートモード) への変更方法を図 5.3に示します。この図 5.3からもわ
かるように、vi コマンドを実行した直後は自動的に「コマンドモード」になります。また、
「Esc キー」を
押すと「入力モード」から「コマンドモード」になります。どちらのモードかわからなくなった場合は、と
りあえず「Es1c キー」を押す、ということを覚えておいて下さい。では、つぎの演習を行いましょう。
図 5.3: vi のモード変化
2
実際には、初期状態ではこの「INSERT」表示が行われない vi もあるので注意しましょう。
第 5 章 テキスト編集
66
演習 5.3 それでは、図 5.3の状態から、「Esc キー」を 1 度押して、dd(d キーを 2 回) 押してみましょう。
このとき、画面上の「World!」の文字列が消え、画面の左上にカーソルが移動するのが確認できます。い
かなる状態でも、「Esc キー」を 1 度押すと「コマンドモード」へ切り替わります。 dd は 1 行削除を行う
コマンドです。
(1) 入力モード
文字をファイル中に入力する場合には、
「コマンドモード」で i,I,o,a,A,o,O のいずれかを押します。そ
れぞれのコマンドの意味は表 1 の通りです。このうち、実際によく用いられ、覚えておくと便利なのは、
i,a,o,O です (表 5.1)。
表 5.1: vi の入力モード
コマンド
意味
i
現在のカーソルの前に文字を挿入する
I
現在の行の先頭に文字を挿入する
a
現在のカーソルの後に文字を挿入する
A
現在の行の最後に文字を挿入する
o
現在の行の下の行に文字を挿入する
O
現在の行の上の行に文字を挿入する
演習 5.4 前の演習の状態から、
「i」を 1 度押して、次の文章を入力してみましょう。i で入力モードになっ
ていますから、キーボードから入力した文字がそのまま挿入されます。また、入力中は矢印キー (←、→、
↑、↓) でカーソル移動ができます。また、改行は通常通り「Enter」キーで行います。「Delete」キーは効
きませんので、タイプミスはそのままにしておきましょう3。
This is the first line in the file,
followed by the second line,
and last line.
(2) コマンドモード
カーソルの移動、文字の削除・変更、ファイルへの保存、ファイルからの読み込みなどの作業は、コマ
ンドモードで行います。主要なコマンドを順に練習してみましょう。
(a) 文字の削除
文字の削除は表 2 のようなコマンドで行います。このうち、よく用いられて覚えておくと便利なのは、
x,dd,D, 数字 dd です (表 5.2)。
演習 5.5 表 5.1、5.2のコマンドを用いて、前の演習で入力した文章にスペルミスがあった場合は修正して
正しい内容にしましょう。
文字入力は i、1 文字削除は x となることを覚えておけば最低限の編集は可能です。h,j,k,l を使ったカー
ソル移動が出来ない時には、とりあえずは矢印キーを使っても構いませんが、なるべく慣れるようにして
下さい。
3 Backspace キーは使える場合と使えない場合があります。少なくとも後で紹介する x コマンド (１文字削除) は覚えておきま
しょう。
5.1. テキスト編集とは
67
表 5.2: 文字の削除
コマンド
意味
x
現在のカーソル上の文字を 1 文字削除
X
現在のカーソル上の左側の文字を 1 文字削除
dd
現在のカーソル上の行を 1 行削除
dw
現在のカーソル上の単語を削除
D
現在のカーソル上から行末までを削除
数字 dd
現在のカーソル上の行から数字の行数を削除
数字 x
現在のカーソル上の行から数字の文字数を削除
演習 5.6 いったん、
「数字 dd」という行削除のコマンドを利用して、ファイルの内容を全て削除しましょ
う。この上で、つぎの文字入力を練習しましょう。
(i) ファイルの先頭で「My name is」までを入力します (i コマンドでできます。ここでは、最後の is の後
に空白を入れないことに注意しましょう)。
(ii)My name is に続いて、自分の名前を英語で書きましょう。このとき、i コマンドを使うとどうなるで
しょうか？
(iii) いったん、dd コマンドで行削除を行ない、再度「My name is」までを入力します。つぎは、a コマン
ドを用いて自分の名前を入力してみましょう。
babababababababababababababababababababab
(One Point)
表 5.3でも説明しますが、2 つの行を 1 つの行に合成するには「J」コマンドを用います。カーソ
ルのある行で J をタイプすると、下の行が行末に移動します。Backspace や Delete キーではでき
ないことに注意しましょう。これまでに利用したエディタとは趣がかなり違うと思いますが、
「慣
れ」が大切です。最初はビープ音が連発しますが頑張りましょう。
(b) カーソルの移動方法
コマンドモードでカーソルを移動する方法は、矢印キーが利用できます。しかし、ホームポジションから
指を離す行為は、タッチタイピングの効率を著しく落とすことになります。作業効率を上げたい方は、と
くに h,j,k.l キーの使い方をマスターしましょう (表 5.3)。
(c) ファイルの保存と終了
vi でファイルへの保存、終了を行うコマンドを表 4 に示します。何はともあれ、常に保存・終了を行う
場合は、「:wq!」を入力するようにすればいいでしょう (表 5.4)。
演習 5.7 現在作成中のファイルを名前をつけて保存してみましょう。Esc キーを押してコマンドモードに
移ってから、:wq test.txt のようにファイルを保存して終了します。その後、ls -al、more test.txt で実際に
ファイルが作成されて内容が保存されていることを確認しましょう。なお、入力に失敗が多く、保存するの
が嫌な場合は:q!とタイプして下さい。また、一時的に書き込んでから編集を継続したい場合は、:w test.txt
第 5 章 テキスト編集
68
表 5.3: カーソルの移動方法
コマンド
意味
h
←、左へ移動
l
→、右へ移動
j
↓、下へ移動
k
↑、上へ移動
G
ファイルの最後の行へ移動
数字 G
数字の行へ移動。先頭行への移動は「1G」とタイプ
0
現在の行の先頭へ移動
$
現在の行の最後へ移動
w
現在の単語の先頭へ移動
とします。
演習 5.8 再度 vi を起動して、test.txt を開いてみます。
vi
test.txt
適当に一部を修正した上で、上書き保存をします。この場合、:w、:wq(ファイル名を指定しない) を実行し
てみましょう。:w!あるいは:wq!として保存、保存・終了してみましょう。more test.txt で修正が正しく行
われたことを確認して下さい。
(d) コピー、ペースト、アンドゥ
つぎに、テキスト編集中でよく用いるコピー、ペーストについて説明します。一部の文字をバッファ(一時
的にデータを保存するメモリ) へ取り込む作業を yank(ヤンク)、そのデータを貼り付ける作業を past(ペー
スト) と呼びます。これらの頭文字の y と p がキーワードになります。最低でも Y、数字 Y、p、P、J を
覚えておくと便利です (表 5.5)。
また、
「u」コマンドを実行すると、前回の編集が元に戻ります (undo:アンドゥ)。複数回入力すると vim
の場合は複数回の編集作業を元に戻せます。また、アンドゥした結果を戻す場合には redo (Ctrl+r) が vim
では使えます。
演習 5.9 vi を適当なファイル名をつけて起動します。
vi
test2.txt
つぎの内容のファイルを作成し、保存・終了してみましょう。2Y、p を用いると便利です。
5.1. テキスト編集とは
69
表 5.4: ファイルの保存、終了方法
コマンド
意味
:q
vi の終了。ただし、ファイル保存が行われていないと終了できない
:q!
!は「強制的」という意味。ファイルを保存していなくても強制的に終了する
:w
ファイルを保存する4
:w ファイル名
指定したファイル名に保存する
:w!
ファイルを強制保存
:w! ファイル名
指定したファイル名に強制保存
:q
終了
:q!
強制終了
:x
ファイルを保存、終了
:wq
ファイルを保存、終了 (:x と同じ)
:wq!
ファイルを強制保存、終了 (:x と同じ)
ZZ
:wq と同じ
Today is fine!
Hello UNIX World!
Today is fine!
Hello UNIX World!
Today is fine!
Hello UNIX World!
Today is fine!
Hello UNIX World!
Today is fine!
Hello UNIX World!
Today is fine!
Hello UNIX World!
(d) 文字列検索、置換
テキストファイル中の文字列検索や置換のコマンドを表 6 に示します。覚えにくいですが、必要があれ
ば利用すると便利です (表 5.6)。
(e) その他
実は、vi にはコマンドモード、入力モード以外に ex モードというモードがあります。既に、密かに ex
モードは使っており、コマンドモードで: を用いると ex モードに移ります。そうです。:w などは実は全
て ex モードのコマンドだったのです。そして、vi の本当の真価は ex モードにあり、そこでは正規表現と
呼ばれる汎用的な文字列との一致を表現する方法を用いた、文字列の置換や検索、コマンドの実行やその
結果の受け取りなど多彩な編集が可能になっており、これを使いこなすことが出来れば、vi 使いと呼ばれ
るようになるでしょう。また、これまでに説明していないこととして名前付きバッファや、マークなども
ありますが、ここでは説明を省きます。
第 5 章 テキスト編集
70
表 5.5: コピー、ペースト、アンドゥ
コマンド
意味
Y
現在のカーソル行を 1 行分をバッファに取り込む。yy でも等価
数字 Y
現在のカーソル行から数字行分をバッファに取り込む。yy でも等価
yw
現在のカーソルが置かれている単語をバッファに取り込む
y$
現在のカーソルから行末をバッファに取り込む
p
バッファ中のデータをカーソルの右側に貼り付ける。
数字 p とすると数字分繰り返し貼り付け
P
バッファ中のデータをカーソルの左側に貼り付ける
J
カーソル行と下の行を連結する
u
アンドゥ
Ctrl+r
リドゥ
表 5.6: 文字列検索、置換
コマンド
意味
r
現在のカーソル上の文字を 1 文字だけ置換
/文字列
現在のカーソルから後方への文字列検索。連続して検索する場合
は単に n を連続してタイプする
?文字列
現在のカーソルから前方への文字列検索。連続して検索する場合
は単に n を連続してタイプする
1,$s/置換前文字列/置換後文字列/
1,$s →開始行、終了行で最初から最後までを示す
ファイル中に現われる文字列をすべて一括して置換する
演習 5.10 前の演習で作成した test2.txt の文章の fine を前方検索してみましょう。その後、1,$s/fine/rain/
とコマンド入力し、fine を rain に全置換してみましょう。
演習 5.11 それでは、ネットワークサーバを構築する際に、よく行うことになるファイルの編集を少しだ
け体験してみましょう。以下は、apache2(WWW サーバ) の設定ファイルの一部です。いったん、下記の
内容のテキストファイル (httpd.conf という名前をつけます) を作成します。このファイル中の admin@∼
をみなさんのメールアドレスに、www.example∼を www.netedu.jp に変更して保存してみましょう。
ServerAdmin [email protected]
ServerName www.example.com:80
5.2. 演習課題
5.2
71
演習課題
演習 5.12 演習 5.7 で作成した test2.txt の文章の fine を前方検索してみましょう。その後、1,$s/fine/rain/
とコマンド入力し、fine を rain に全置換し、その結果を提出しなさい。
演習 5.13 vi で以下のような文章を編集している際に、
created the C programming language and, with long-time colleague,
Ken Thompson, the UNIX operating system.
Dennis MacAlistair Ritchie (September 9, 1941 ? October 12, 2011),
この 3 行の文章を、10 回コピーする (つまり、33 行にする) ための方法を vi で答えよ。但し、カーソル
は、最初の行の行頭 D にあるものとする。
73
第 6 章 UNIX システム管理
6.1
管理者の役割
ネットワーク管理はサーバ、ネットワーク機器、ケーブルを含めたネットワークシステム全体に関する
もので、(UNIX) システム管理は単体のコンピュータ (サーバ) に関わる管理という位置づけがあります。
しかし、その前に管理について一度考えてみましょう。本来「管理」(administration) という言葉は、
「あ
る規定の範囲から外れないように統制したり維持したりすること」という意味で用いられます。しかし、
管理者はユーザーがネットワークやコンピュータシステムの構成によってどのような利益を、あるいは不
利益を被るのかと言うことを常に考えておく必要があります。いくら能力的には非常に高く、システムや
ネットワークに関する知識が豊富であっても、ユーザの視点に立っていない管理者は不適格と言えるでしょ
う。管理が一体誰のためのものか、という視点を常に持って管理にあたるのが優れた管理者の第一要件で
しょう。
また、一般に管理者はともすれば日常の様々なトラブルや業務に追われがちで、す。しかし、管理者は
様々な新しい技術や理論を学び、より良いシステムを構築し、現状を本質的に打開することが求められま
す。したがって、対象とする業務について、常日頃から知見を広げて問題解決能力を磨くことが優れた管
理者の第二の要件となります。
さらに、システムやネットワークを設計・維持する上では単純さを保つように心掛けなければなりませ
ん。複雑な構成はそれだけでトラブルの元です。そして、そのことは結果として管理者の時間を自ら奪う
結果になります。矛盾するようですが、個々のネットワークやシステムの独自性を追求しつつも、それを
実現する上ではもっとも単純かつ標準的な解決を目指すべきです。このような設計・維持ができることが
優れた管理者の第三の要件と言えるでしょう。
以上の事を念頭に置いた上で、管理者の役割について簡単に説明してみましょう。
6.2
システム管理者とネットワーク管理者
UNIX 系 OS では、システムを管理する特別なユーザをスーパー・ユーザと呼んでいます。スーパー・ユー
ザは root とも呼ばれます。root は既にファイルシステムのところで「根」として扱いましたが、UNIX で
はこれをシステムに対して全権を持ったシステム管理者のログイン・ユーザ名として使うという習慣があ
ります1 。
システム管理者の役割には、システムで利用可能なサービスやコマンドの管理、ユーザの管理、ファイ
ルシステムの管理、ハードウェアの管理などがあります。
ネットワーク管理者はコンピュータやネットワーク機器を含めたシステム全体の管理という事になりま
す。このように書くとネットワーク管理者の方が上にあるような印象がありますが、ネットワークはサー
ビスを利活用するためにあるので、ネットワーク管理とシステム管理 (サーバ管理) は切り離すことはでき
ません。
1 Windows
系 OS では Adminstrator に当たります
第6章
74
UNIX システム管理
ネットワーク管理者の役割は、ルータやスイッチの管理、ネットワーク・トラフィックの監視、ネット
ワーク・トラブルへの対処、ファイアーウォールの管理、DNS,mail の管理、セキュリティの確保などがあ
りますが、中でも重要なのが新しい技術についての勉強もネットワーク管理者の重要な任務です。
6.3
UNIX システム管理の実際
それでは、インストールした FreeBSD を用いて UNIX システム管理を学んでみましょう。Linux に比べ
て比較的 UNIX 由来の機能や構造を多く残している FreeBSD ですが、すべての操作が手動のコマンドで
行われる訳ではありません。GUI ならぬ TUI（Terminal User Interface）も活用することを前提に説明し
ていきましょう。
6.3.1
起動とシャットダウン
まず FreeBSD を起動すると、Windows との共存環境 (デュアルブート環境) であれば、「F1 DOS F2
FreeBSD」(DOS は Windows 系 OS を示す) のようなメニューが表示されているはずです。この場合は、
F1 キーあるいは F2 キーで起動する OS を選択できます。共存環境でなければ自動的に FreeBSD が起動し
ます。Ubuntu など Linux 系 OS で多く採用されている Grub とは違い、FreeBSD では BootEasy という
ブートマネージャがインストールされます。このブートマネージャは、前回起動した OS を記憶しますの
で、放っておくと前回起動した OS が勝手に選択されて起動することになります。
FreeBSD が起動すると、図 6.1のような FreeBSD 起動メニューが現れます。ここで、図 6.1の各項目の
説明を表 6.1に示します。
図 6.1: FreeBSD の起動メニュー
6.3. UNIX システム管理の実際
75
表 6.1: FreeBSD の起動メニューの内容
項目
説明
1.Boot FreeBSD [default]
FreeBSD の通常起動
2.Boot FreeBSD with ACPI disabled
パソコンの電源制御機能 ACPI を無効にして FreeBSD を起動 ACPI
の動作によって起動に失敗する場合に選択。
3.Boot FreeBSD in Safe Mode
現在 ACPI の無効化、ATA/ATAPI デバイスの DMA 禁止、ATA デ
デバイスのキャッシュの無効化などを行う。
4.Boot FreeBSD in single user mode
シングルユーザモードで起動。シングルユーザモードは、UNIX の起
動過程の一つで、この状態では一般ユーザが無効になり、管理者のみ
のユーザで OS が起動している状態。シングルユーザモードではパス
ワードなしで管理者権限での作業ができるので注意。exit コマンドを
入力するとシングルユーザモードからマルチユーザモード（通常の
FreeBSD 起動）に移行する。
5.Boot FreeBSD with verbose logging
カーネルが出力するメッセージを詳細に表示
6.Escape to loader prompt
ブートローダプロンプトを表示。ハードディスクにインストールされ
た OS を起動するためのプログラムがブートローダである。
再起動を行う
7.Reboot
起動メニュー (図 6.1) では、何もしないと「1.Boot FreeBSD[default]」が自動選択されますが、コンピュー
タハードウェアの関係で起動に失敗する場合、システムのメンテナンスを行う場合は適宜別の項目を選択
します。
1.Boot FreeBSD[default] で起動した場合は、システム管理者であるスーパー・ユーザ root でログイン
して下さい。なお、ログアウトの方法は、exit あるいは logout コマンドを利用します2 。また、システムの
終了 (シャットダウン) は root でつぎのいずれかのコマンドを実行します。なお、FreeBSD では Windows
系 OS や Ubuntu Linux のように一般ユーザではシステムの終了ができません3。
(a) システムの停止システムの終了はつぎの shutdown コマンドで行います。
shutdown -p now
now のところに数値を入力すると数値 [分] 後に停止します。このコマンドでは、複数のユーザが利用して
いる場合には、それぞれにシステム停止のメッセージが表示されます。-p は ACPI 機能が有効なら電源を
落とすオプション。-p now の代わりに
shutdown
-r
now
とすると再起動を行います。また、
shutdown
2 Ctrl+D
-h
now
の組み合わせでログアウトできる場合もあります
というグループにユーザを登録すると一般ユーザでもシャットダウンが可能になりますが、特殊な使い方と言えるで
しょう。FreeBSD ではシステム終了は root で、というのが基本です
3 operators
第6章
76
UNIX システム管理
babababababababababababababababababababab
とすると単にシステム停止のみを行います。
(One Point) 日曜日にメンテナンス停電が・
・
・
よくある話ですが、業務に支障がない日曜日に電気設備のメンテナンスが行われ、会社や学校が
停電になることがあります。Windows をはじめ、最近の OS はシステム停止の作業をせずに、電
源を切るとファイルシステムが破損する場合があります。FreeBSD のファイルシステム (UFS) は
Linux の ext3,ext4 よりも強靱で、少々なことで破損は起きにくいのですが、絶対安全とは言い
切れません。かと言って、休日出勤するもの・
・
・と思っている方は、shutdown コマンドにつぎの
ような日時指定をしましょう。
shutdown -p 0910301000
と指定すると、2009 年 10 月 30 日 10 時 00 分に停止 (電源切断) を行います。
(b) 再起動
システムの再起動はつぎの reboot コマンドで行います。
reboot
(c) シングルユーザモードへの移行
シングルユーザモードへの移行は shutdown コマンドで行います4 。
shutdown now
シングルユーザモードの際には、
Enter full pathname of shell or RETURN for /bin/sh:
と起動するシェルを聞いてきますので、ここで「改行キー」をタイプします。ここでは低機能な/bin/sh が
起動しますが、
「tcsh」と入力すると高機能な tcsh を起動させることができます5。シングルユーザモード
では、管理者 (root) として、各種の管理作業が行えます。
4 システム設定 (/etc/rc.conf) を変更した場合、再起動するよりいったんシングルユーザモードに移行し、 exit をタイプする方
が早く設定変更が反映されます。
5 exit と入力すると元の sh に戻ります。質問の際に/bin/tcsh と入力すると tcsh が直接起動しますが、コマンドパスなどの情報
が読み込まれないため少々不便です
babababababababababababababababababababab
6.3. UNIX システム管理の実際
77
(One Point) シングルユーザモードでの作業
シングルユーザモードでは、パスワード変更などを含めた管理作業を行うことができます。とな
ると、
「え？それは危ない！」と思いませんか？たとえば、root のパスワードを忘れた場合もシン
グルユーザモードでは変更ができます。ということは、シングルユーザモードにできれば、デー
タを盗んだり破壊もできてしまう、ということになります。サーバコンピュータは鍵がかかる部
屋に置くのが安全ですが、それができない場合にはシングルユーザモードで root のパスワードを
要求するように設定を行います。たとえば、FreeBSD では/etc/ttys というファイル中の console
の行の「unknown off secure」というキーワードを「unknown off insecure」に変更します。Linux
でも同様な設定が可能です。
また、シングルユーザモードで vi などの一部のコマンドが効かない場合は、
mount
-a
6
を実行してみて下さい。これはファイルシステムのマウントを行うコマンドです 。また、キーボードが、
印字通りに入力されませんが、シングルユーザモードでは、自動的にキーボードが英語キーボードにセッ
トされてしまうためです。気になる場合は、
を入れ替えたキーマップで動作します。いちいちこのコマンドを入力したくない方は、
kbdcontrol -l jp.106.kbd
とタイプして日本語キーボードの設定に変更して下さい。jp.106x.kbd と指定すると Ctrl キーと CapsLock
vi
/root/.login
を起動して、.login ファイル内に上記の kbdcontrol コマンドを書いておきましょう。
シングルユーザモードの状態で、
exit
とタイプすると、マルチユーザモード (通常の UNIX が起動した状態) に移行します。
演習 6.1 実際に FreeBSD を起動してみて下さい。ここでは、1.Boot FreeBSD[default] でいったん起動し
た後に停止させてみます。また、つぎに起動する場合は 4.Boot FreeBSD in single user mode(シングルユー
ザモード) で起動してみて下さい。この際に、キーボードを適当に入力して、キーマップが英語になってい
るのを確認しましょう。その後、mount、kbdcontrol などのコマンドを試してみましょう。最後は exit でマ
ルチユーザモードに戻しておきます。
6.3.2
ユーザ・グループ管理
まず最初に管理者ユーザについて説明します。Ubuntu では、管理者権限で行う作業では sudo コマンド
を利用しました。また、sudo コマンドを使わない場合でも、管理作業にはユーザのパスワードが要求され
ます。
6 ファイルシステムに異常がある場合は、fsck
コマンドを実行してから mount -a を行います。
第6章
78
UNIX システム管理
一方で、本来の UNIX は既に述べた通り管理者ユーザの名前が「root」(根) と決められています。この
管理者ユーザはすべての権限が許可されることから、別名スーパーユーザとも呼ばれています。UNIX 系
OS では必ず root ユーザが存在しており、Ubuntu でも root ユーザにパスワードを設定すると、許可され
たユーザであれば root ユーザになることができるようになっています7。なお、Ubuntu などの Linux で
は、セキュリティの関係で root ユーザは直接ログインすることができないようになっています。それでは、
早速 FreeBSD でのユーザ・グループ登録方法を紹介しましょう。
ユーザ、グループの登録方法
FreeBSD や UNIX 系 OS でのユーザ・グループ登録方法は大きく分けて 4 種類存在します。
1. OS 由来のツールによって登録する方法
2. ユーザ管理コマンド (pw,adduser,rmuser) を用いて登録する方法
3. vipw コマンドなどによるユーザ・グループ登録ファイルを直接編集、ホームディレクトリを手動で
作成する方法
4. GNOME、KDE といったデスクトップ環境に付属する管理アプリケーションを利用する方法
です。このうち、GNOME、KDE に付属するユーザ管理アプリケーションは、ウィンドウ環境を組み込ま
ないネットワークサーバでは利用できません。最初の 1,2 の 2 つについて解説しましょう。
1.FreeBSD 由来の sysinstall を用いる方法
FreeBSD 標準で添付インストールされる sysinstall という統合管理アプリケーション sysinstall8 を用い
ます。この sysinstall は OS のインストール時にも利用しました。単純に、root でログインした後で、
sysinstall
とタイプしてみましょう。
演習 6.2 自分自身のユーザ・グループを登録してみましょう。
(i) ログイン後の画面で、sysinstall を起動します。
(ii) ここで、「Configure」∼「User Management」を選択します (図 6.2)。
7
Ubuntu でも su(switch user) コマンドを実行すると、root のパスワードが求められて root になることができます。
著者の一部の研究グループでは、GUI と対比するために Terimnal User Interface(TUI) という用語 (造語) で呼んでいます。
sysinstall はエスケープシーケンスなどを用いて実装されてい るために、ネットワーク経由の遠隔ログイン時でも利用できるという
メリットがあります。
8
6.3. UNIX システム管理の実際
79
図 6.2: sysinstall の User Management
(iii) 続いて、自分自身のユーザを登録してみます。Group はとりあえず空欄のままで結構です。パスワー
ドには 6 文字以上のパスワード、Full Name には自分の名前を、Login Shell には、お気に入りのシェルを
指定しますが、/bin/sh ではなく/bin/tcsh に変更することをお勧めします (図 6.3)。
図 6.3: ユーザ登録画面
以上で、ユーザ hara(グループ名はユーザ名と同じ hara に自動的に設定されます) の登録が完了しまし
た。管理者ユーザ (root) からログアウトして実際にログイン・ログアウトできることを確認してみましょう。
演習 6.3 登録されたユーザ情報の確認
第6章
80
UNIX システム管理
いったん登録したユーザの情報がどこに保存されているのか確認してみます。root で再ログインして下
さい。UNIX では、ユーザ情報は/etc/passwd 9 、グループ情報は/etc/group ファイルに保管されています。
実際に登録されたユーザが存在しているかどうかをつぎのコマンドで確認します。
more
/etc/passwd
more
/etc/group
それぞれの内容は、つぎのような形式になっています。
○/etc/passwd 内のエントリ
hara :*:1001:1001:Motoshi Hara:/home/hara:/bin/tcsh
ここでは、
：
（セミコロン）でデータが区切られていますが、それぞれのデータの意味は
ユーザ名：パスワード：ユーザ ID:グループ ID：一般情報 (フルネーム) ホームディレクトリ：シェル
となります。UNIX システムでは、ユーザ、グループ共に番号で管理されていることに注意しましょう。し
たがって、ユーザが異なれば、ユーザ ID は重複してはならないということを意味しています。また ID は
0∼65535 の値が使用できます (ただし、0 は管理者・管理者グループで使用されます)。別の言い方をすれ
ば、/etc/passwd ファイルはユーザ名とユーザ ID を結びつける働きもしていると言えます。逆に、passwd
ファイルからユーザを削除した場合、そのユーザの所有していたファイルの所有者の表示などは ID として
表示されるようになります (本来、ファイルは ID で管理されており、ID がユーザ名に置き換えられてい
る)。
○/etc/group 内のエントリ
hara:*:1001:
ここでも：
（セミコロン）によってデータが区切られていますが、それぞれのデータの意味は
グループ名：パスワード：グループ ID:メンバー（, で区切って列挙します)
となります。グループにもパスワードを設定することができますが、一般には利用しないので＊ (アスタリ
スク) を記入します。sysinstall のユーザ管理ツールですと、メンバーが記入されませんが、ユーザは複数
のグループに所属できます（最大 26 グループまで）。その場合は、
hara:*:1001:hara,yamada,sato
bsdgroup:*:1002:hara,taro,hanako
のように記述する所属するメンバーを列挙して記述します。ここでも、グループ ID の重複があってはなり
ません。また、登録されているユーザ情報を表示する id コマンドがあります。書式は
9 /etc/passwd ファイルは誰でも参照できますが、このファイルにパスワードに関する情報を保存するとセキュリティ上問題があり
ます。そこで、パスワード情報を含めてユーザ情報を管理するファイルを別に用意し、パスワード情報などを除いた情報を/etc/passwd
ファイルにコピーしています。Linux は/etc/shadow ファイル、FreeBSD や BSD 系 UNIX は/etc/master.passwd がパスワード
情報を含めた本当のユーザ情報ファイルです。もちろん、このファイルは管理者ユーザにしか読めないようになっています。
6.3. UNIX システム管理の実際
id
です。
81
登録されているユーザ名
演習 6.4 id コマンドを実行してみて下さい。uid（ユーザ ID）、gid（グループ ID）などの情報を表示で
きます。
演習 6.5 root ユーザで登録したユーザアカウントを消去してみましょう。ただし、ユーザの削除は sysinstall
からではできませんので、つぎの特別なコマンドを利用します。
vipw
vipw では、/etc/master.passwd ファイルを開いて直接編集することができます。ここでは、/etc/master.passwd
の中で、先ほど登録したユーザの情報が書かれている行を削除します。/etc/master.passwd ファイルは、
FreeBSD でユーザ情報を管理するファイルで、管理者ユーザのみ編集ができるようになっています。この
時、vi と同じコマンドが利用できます (dd コマンドで 1 行削除,:wq!で保存・終了でしたね)。
また、グループは
vi
/etc/group
を実行し、該当する行を削除してしまいます。削除後、root からログアウトし、登録したユーザではログ
インできなくなっていることを確認しましょう。
また、削除したユーザのファイルの属性がどのように見えるのかを ls -l コマンドで確かめて見てくだ
さい。
babababababababababababababababababababab
vipw で表示されるエントリは/etc/passwd と異なる点があります。
hara:$1$Ysp3FnEu$.kC(略)m0Wt2.:1001:1001::0:0:Motoshi Hara:/home/hara/bin/tcsh
ユーザ名の次に書かれているでたらめな文字列はパスワードが暗号化されたものです。グループ
ID の次に 3 つ:（セミコロン）で区切られたエントリが追加されていますが、それぞれ「ログイン
クラス（とりあえず空白で OK)」、
「パスワード変更時間（秒）」、
「パスワード有効時間（秒）」を
示しています。時間のエントリに 0 が入っていると「無期限」という意味になります。パスワー
ドを間違えて登録してしまい、ログインができなくなってしまった場合には、この暗号のような
でたらめな文字列を削除して、
hara::1001:1001::0:0:Motoshi Hara:/home/hara/bin/tcsh
とすると、パスワードなしでログインできるようになります。緊急時の対処方法として覚えてお
きましょう。
第6章
82
UNIX システム管理
2. ユーザ管理コマンド (pw,adduser,rmuser) を用いて登録する方法
ユーザ管理コマンドを用いてユーザ登録・削除を行うこともできます。この場合は、root でログインし
た上で、
adduser
を実行します (図 6.4)。
図 6.4: adduser コマンド
この例のように、必要な項目を入力していきます。変更の必要がない、入力の必要がない場合は単純に
改行を入力していきます。ここでは、
「Username」と「Shell(sh を tcsh に変更)」、
「パスワードの入力」以
外は改行あるいは yes の入力で OK です。登録に成功すると
Successfully added
というメッセージが表示されます。また、Add another user?と聞かれますので、さらに登録する必要が
なければ、no を選択すれば adduser コマンドを終了できます。この反対でユーザを削除するコマンドが
rmuser というコマンドです。
rmuser 削除するユーザ名
で実行します。
演習 6.6 adduser コマンドによってユーザを登録し、rmuser コマンドで登録したユーザを削除してみま
しょう。
adduser コマンドを利用するのは簡単でいいのですが、ネットワークサーバを管理していると数百名∼
数千名単位でユーザを登録することがあります。さすがにこの作業は対話方式ではできません。プログラ
6.3. UNIX システム管理の実際
83
ムを用いて大量にユーザ登録を行う方法として、pw コマンドがあります10 。
pw
pw
useradd オプション
groupadd オプション
の形式で用います。オプションは表 6.2のようになります。オプションを指定しない場合はデフォルト設定
が用いられます。ただし、この pw コマンドで作成されたユーザにはパスワードが設定されません (空のま
まです)。したがって、パスワードについては別途 passwd コマンド等で指定する必要があります。
表 6.2: pw コマンドのオプション
オプション
内容
-n ユーザ名
ユーザ名の指定
-d ディレクトリ
ホームディレクトリの指定
-g グループ名
グループ名の指定
-L ログインクラス
ログインクラスの指定
-k 初期設定ファイルの格納ディレクトリ
初期設定ファイルの雛形が置いてある
ディレクトリの指定
-s シェル名
シェルの指定
-w random
ランダムなパスワードを指定
-m
ユーザのホームディレクトリを作成
演習 6.7 pw コマンドによってユーザを登録してみましょう。
pw
useradd
-n 登録したいユーザ名 -s tcsh -m
passwd 登録したユーザ名
ここでは、passwd コマンドで登録したユーザのパスワードを設定しています。しかし、大量のユーザ登録
時にいちいち管理者がパスワード指定していては大変です。
pw
useradd
-n 登録したいユーザ名 -s tcsh
-w random -m
を実行してみましょう。ランダムにパスワードを設定した上で、そのユーザのパスワードを画面表示しま
す。ここで生成されるパスワード長は 8∼15 文字になります。最近の Linux や FreeBSD は最大で 127 文
字までのパスワードを認識できるようになっています。
10 詳しく紹介しませんが、adduser コマンドは対話処理だけではなく、pw と同じように 1 行でユーザ登録を行うことも可能に
なっています。一方、adduser コマンドは UNIX 共通のコマンドではないことに注意しましょう。
babababababababababababababababababababab
第6章
84
UNIX システム管理
(One Point) ユーザ登録が 1000 人・
・
・
大量のユーザを登録する場合には、つぎの方法 (手順) を用いることができます。
(i) ユーザ登録用のシェルスクリプト (プログラム) を vi で作ります。
例：ファイル名「user-add-script.sh」
#!/bin/sh
if [ -f
./passwdlist ]; then
rm ./paswdlist
fi
while
do
read LINE
pw useradd -n $LINE
done
-s tcsh
-w random -m >> passwdlist
(ii)list というファイルを作成し、登録したいユーザを列挙します。
(list の例)
j0801
j0802
j0803
(iii) 作成したシェルスクリプトを実行可能にし、つぎのコマンドを実行します。
chmod +x
user-add-script.sh
user-add-script.sh < list
(iv)list に列挙したユーザが追加され、passwdlist にランダムに登録されたパスワードのリストが
作成されます。
また，一般ユーザから他のユーザ (たとえば管理者ユーザ root) に移行することが可能です。マンドの書
式はつぎの通りです。
su
[移行したいユーザ名 (省略時は root を指定したのと同じ)]
UNIX システム管理を行う場合、一般ユーザからわざわざログアウトして root で再ログインを行うのは
少々めんどうです。ただし、wheel グループに属していない一般ユーザが、su コマンドで root になること
はできません。したがって、システム管理のために su コマンドで root になりたいユーザは、/etc/group
の中の wheel グループに登録を行う必要があります。
演習 6.8 root でログインを行い、/etc/group ファイルをつぎのように編集しましょう。
wheel:*:root,hara ・
・
・su コマンドで root になれるユーザ名を列挙。
続いて、root からログアウトし、group に登録したユーザで再ログインします。そこで
6.3. UNIX システム管理の実際
85
su
を実行し、root のパスワードを入力すると root になれることを確認しましょう。whoami というコマンド
を実行すると現在どのアカウントでログインしているのかが確認できます。
6.3.3
ファイルシステム管理
ファイルシステムの管理について、いくつかのコマンドを習得しておきましょう。
ファイルシステムのマウント
UNIX では、ファイルシステムについて「ディレクトリ」を作成した上に物理的なファイルシステムを
「マウント」(乗せる) することで利用します。現在のファイルシステムがどのようにマウントされているの
か状態を調べたり、実際にファイルシステムをマウントするのが mount コマンドです。このコマンドの書
式はつぎの通りです。
mount
[オプション]
なお、UNIX は起動時に自動的にファイルシステムのマウントを行いますが、この情報を記述しているの
が、/etc/fstab ファイルです。
演習 6.9 root でログイン（あるいは su コマンドを用います) 単に mount コマンドを実行してファイルシ
ステムのマウント状況を見てみましょう (図 6.5)。
図 6.5: mount コマンドの実行例
mount コマンドからは下記のような情報が得られますが，この結果から/(ルートディレクトリ) が/dev/ad0s1a
というファイルシステム (デバイスファイルで表現されていますが、ハードディスクに作成された論理的な
領域の一部です) にマウントされていることがわかります。また、/etc/fstab の内容を vi で開いてみましょ
う。つぎのような情報が表示されます。
第6章
86
# Device
Mountpoint FStype
/dev/ad0s1b none
swap
Options
sw
Dump Pass#
0
0
/dev/ad0s1a /
/dev/ad0s1e /tmp
ufs
ufs
rw
rw
1
2
1
2
/dev/ad0s1f /usr
/dev/ad0s1d /var
ufs
ufs
rw
rw
2
2
2
2
cd9660
ro,noauto
0
0
/dev/acd0
/cdrom
UNIX システム管理
マウントポイントがファイルシステムをマウントするディレクトリ、FS タイプが ufs(UNIX File System)、
nfs(Network File System), cd9660(CD のファイルシステム) などを示します。起動時にマウントしたいファ
イルシステムがあれば、ここに書き込んでおきます。
演習 6.10 USB メモリを持参している方は、つぎのコマンドでマウントしてみましょう (図 6.6参照)。
mkdir
/mnt/usbmem
mount
mount
-t msdosfs
/dev/da0s1
※
cd /mnt/usbmem
ls (などを実行してみて下さい)
※ 他のデバイスを利用していると名前が変わってきますので、このコマンドでダメな場合は、ls /dev/da*
を実行して近い名前のデバイスを指定して下さいなお、利用が終了した場合には、必ず
を実行するのを忘れないで下さい。
cd / ・
・
・/usbmem に移動しているとアンマウントできません
umount /mnt/usbmem
図 6.6: usb メモリのマウント例
ファイルシステムの利用状況の確認
現在のファイルシステムの利用状況を調べるためのコマンドが、df、du コマンドです。df コマンドは
ファイルシステムのパーティション単位での利用状況を調べます。このコマンドの書式はつぎの通りです。
6.3. UNIX システム管理の実際
87
df [オプション] [ファイルシステム|ファイル]
ここで、オプションとしては、-k,-m,-g、-h が指定できます。それぞれ K ブロック、M ブロック、G ブロッ
ク e 単位を表しています。-k,-m,-g オプションはいずれもブロック（512KByte）単位での表示となり、わ
かりにくいので、M バイト、K バイト単位で表示してくれる-h が使いやすいと思われます。
演習 6.11 みなさんが利用しているコンピュータのファイルシステムの利用状況をパーティション単位で
見てみましょう (図6.7参照)。
df -h
図 6.7: df コマンドの実行例
続いて、ディレクトリ単位でのファイルシステム利用状況を調べるためのコマンドが、du コマンドです。
このコマンドの書式はつぎの通りです。
du
[オプション] [ディレクトリ]
ここで、オプションとしては、-k(キロバイト単位),-h(容量に見合った単位),-a(階層内のファイル単位で表
示)、-d(調査するディレクトリの階層の深さ) 、-c（総計を表示)，-s（カレントディレクトリの総量表示)
が指定できます。とくに-k、-h を指定しなければこのコマンドもブロック単位で表示します。
演習 6.12 皆さんが利用しているコンピュータのディレクトリの利用状況を見てみましょう。
du
-h
du
-ah
/usr/bin
/usr/bin | more
を実行してみて下さい。— は、パイプ文字と呼ばれ、本来画面に出力される情報を右となりに記述した
more コマンドに引き渡します。この結果、出力結果が 1 画面ずつ停止して見やすくなります (図 6.8,6.9)。
第6章
88
UNIX システム管理
図 6.8: du -h コマンドの実行例
図 6.9: du -ah コマンドの実行例
ファイルシステムのチェック、修復
PC-UNIX を利用していると、ファイルシステムの不具合や不調が発生することがあります。たとえば、
まれですが正規のシャットダウンの作業を行わずにコンピュータの電源を切った場合などです。停電など不
測の自体でコンピュータが停止してしまった場合、FreeBSD は起動後に裏でファイルシステムのチェック
と修復を行っています。このファイルシステムのチェックと修復に用いられるのが fsck コマンドです11 こ
のコマンドの書式はつぎの通りです。
fsck
[オプション]
[ファイルシステム]
演習 6.13 みんさんが利用しているコンピュータのファイルシステムのチェックを実際に行ってみましょう。
11 最近の OS の多くは、データの書き換えが行われた際に直接ディスク上のデータを書き換えるのではなく、メモリ上でいったん
書き換えておいて、後でディスク上のデータを更新するようなしくみを取り入れています。このことで、ユーザは高速なデータ書き
換えが可能で、ストレスなくコンピュータ利用ができます。しかし、実際にディスクのデータを更新する前にパソコンの電源が停止
すると、実際のデータと書き換えたデータの間に矛盾が生じてしまいます。このような場合に整合をとる、という修復機能を fsck は
備えています。
6.3. UNIX システム管理の実際
89
fsck
を実行してみて下さい。ファイルシステムを指定しなければ、/etc/fstab ファイルに書かれているファイル
システムについて fsck を実行します。また、
fsck /dev/ad0s1f
のように直接ファイルシステム（/dev/ad0s1f は/usr にマウントされています）を指定して fsck をかける
こともできます12 。
図 6.10: fsck コマンドの実行例
但し、実際にディスクがダメージがある場合には、シングルユーザモードで修復をしなければなりませ
ん。多くの場合、立ち上がり時にディスクに問題がある場合に自動的にシングルユーザモードで止まるよ
うになっています。また、単に fsck を実行した場合、異常を見付けるたびにどういう処置を取るべきか質
問されます。非常に多くのエラーが見付かる場合には、大変なので −y オプションをつけて動かすと、す
べての処理を YES で修復してくれますが、その結果復旧できないファイルや、復旧できてもディレクト
リのどこにあるかが分からない迷子のファイルなどができる場合もありますので、最後の手段であること
を忘れないでください。
6.3.4
プロセス管理
プロセスとは、コンピュータ上で動作している状態にあるプログラムを指します。動作中のプロセスに
ついては、Ubuntu などの GNOME、KDE などではモニタプログラムが存在しているために、GUI の上で
12 デバイス名はシステムによって異なる場合があります (ad2s1f など)。df コマンドや mount コマンドで名前を確認してから実
行しましょう。
第6章
90
UNIX システム管理
簡単に確認できます。しかし，ネットワークサーバ等ですと，GUI ツールは利用できない場合が多く，そ
の場合はコマンドによるプロセス管理が有効です．そのコマンドを説明しましょう．
(1)ps コマンド
現在実行中のプロセスの状態を表示するコマンドが ps です。このコマンドの書式はつぎの通りです。
ps
[オプション]
オプションは多くの組み合わせがありますが、典型的な組み合わせである aux、auxww を紹介しておきま
しょう．
演習 6.14 ps コマンドについて 2 つのオプション
ps aux | more
ps auxww | more
を実行してみましょう。後者は、プログラム名などが表示上切れてしまわないように 1 行を折り返して表
示する機能を持っています。| と more は 1 画面ずつ停止させるためです (図 6.11,6.12)。
図 6.11: ps aux コマンドの実行例
6.3. UNIX システム管理の実際
91
図 6.12: ps auxww コマンドの実行例
これらの表示中で、USER がプログラムの実行ユーザ (プロセスの所有者)、PID がプロセスの識別番号
(プロセス ID)、%CPU が CPU 使用率、%MEM がメモリ使用率、%VSZ が仮想メモリの使用量、RSS が
メモリの%使用量、TTY が制御端末、STAT がプロセスの%状態、STARTED TIME が実行された日・時
間、%COMMAND がプログラム名、となります。
(2)kill コマンド
実行中のプロセスに対して割り込み信号を送信するコマンドが kill コマンドです。読んで字のごとく実
行中のプロセスを kill(殺す) したり、設定ファイルを再読み込みさせて再起動させたりすることができま
す。書式は、
kill [オプション] プロセス ID
となります。オプションは多くのものがありますが、
「オプションなし」、「-9」、「-HUP」がよく用いられ
ます。-9 は強制的にシグナルを送信するオプションで、-HUP はプロセスの停止と再起動を同時に行う場
合に用います。（ただし、再起動せずに終了だけしてしまう場合がありますので注意しましょう）。
演習 6.15 つぎの実験をやって見ましょう。
ps aux
| grep
csh
を実行します。grep は文字列検索コマンドですが、画面に出力されるプロセス情報を |(パイプ文字) で grep
コマンドに渡しています。このとき、csh という文字列にマッチする行だけ取り出して表示してくれます
(図 6.13)。
第6章
92
UNIX システム管理
図 6.13: csh のプロセスのみを選択表示
ここで、一番上の csh というプロセス（シェル）に強制的に信号を送ってみましょう。
kill
-9 901
・
・
・ただし、皆さんのコンピュータでは PID が異なります
何が起きたでしょうか？
babababababababababababababababababababab
(One Point) シグナル文字
実行中のプログラムを強制的に終了する方法は、 kill コマンドでもかまいませんが、プログラム
を実行している端末（シェル）の上で Ctrl+c（Ctrl キーと c を同時に押す）ことでも同じことが
できます。Ctrl+c によってプロセスにシグナルを送信できますので、この組み合わせを「シグナ
ル文字」と呼びます。
(3)top コマンド
各プロセスによる負荷やメモリ使用量、CPU 負荷などを逐次表示するためのコマンドが top です。この
コマンドによって、負荷を与えているプロセスやシステムの情報を観測できます。書式は
top [オプション]
となります。オプションなしで起動すると、CPU 負荷が高いプロセスの順に表示されます。なお、このコ
マンドの終了方法は Ctrl+c です。
演習 6.16 実際に，top コマンドを実行してみましょう (図6.14)。
6.3. UNIX システム管理の実際
93
図 6.14: top コマンドの実行例
6.3.5
バックアップ
ファイルシステムは物理的に破損したり、ソフトウェア的に壊れてしまう可能性があります。24 時間稼
働させっぱなしのハードディスクでは、早かれ遅かれ必ず壊れてしまいます。このような場合には、バック
アップを定期的にとるほか対策の方法がありません。実際にバックアップを取る作業は行いませんが、方
法について紹介したいと思います。
(1) 物理的にバックアップを取得する方法
単純には、ハードディスクを 2 重化して、常にバックアップを取る方法があります。FreeBSD そのもの
はソフトウェア的に極めて安定したファイルシステムが実装されていますので、ハードディスクを物理的
に 2 重化することは極めて有効です。最も単純な 2 重化の方法は、同時に 2 台のハードディスクに同じデー
タを書き込む方式（RAID-1 と呼びます）です。最近は、2 台のハードディスクのうち、1 台が故障した場
合にシステムを停止することなく、故障したハードディスクを交換可能な装置がほとんどです（ホットス
ワップ方式と呼びます）。RAID-1 方式のような単純な 2 重化を行うモジュールは 5∼7 万円程度で購入で
きます。この方法が最もお勧めです。
一方で、ハードディスクのバックアップデータを複数のハードディスクに分散させる RAID-5 方式があ
ります。性能も良く、負荷分散の上でも好ましいのですが、機器がやや高価であることが難点です。また、
最近コンピュータのマザーボードで 2 重化ができるものがあります。しかし、一方のハードディスクが故
障していてもモニタがないためにわからず、気がついたら 2 台のハードディスクが両方故障している、と
いった事態がありました。2 重化に対応したマザーボードを購入してパソコンを組み立てるのが最も安価
に 2 重化を行う方法の一つです。しかし、注意深くハードディスクの状態をチェックしていないといけま
せん。
(2) 物理メディアによってバックアップする方法
最近は、ハードディスクも 1T(=1000GB 超）の世界になってきました。DVD-R で一枚あたり 4.7GB 程
度バックアップがとれますが、やはり大容量なデータのバックアップは物理メディアではとりにくくなっ
第6章
94
UNIX システム管理
ています。ごく一部分のデータのバックアップには問題ないのですが・
・
・。
(3)rsync によるリモートバックアップ
ハードディスクを物理的に 2 重化できない場合にお勧めなのは、ネットワーク経由で別のコンピュータ
にデータのバックアップをとることです。時間の関係上実習が難しいのですが、バックアップを取る側、
データを保存する側のコンピュータ双方に rsync と呼ばれるプログラムを導入します。その上で、バック
アップを取る側のコンピュータで、
rsync -avz --delete -e ssh /usr/home [email protected]:/back
のようなコマンドを入力します。rsync というのは、データを保存する側のコンピュータのユーザ名で、
/usr/home のディレクトリ内のデータをリモートのコンピュータ（test.matsue-ct.ac.jp) の/back という
ディレクトリに保存することを意味しています。前回バックアップしたデータがあれば、バックアップする
時点で変更があったデータ (差分) のみを転送しますので、高速なバックアップが可能です。詳しくはホー
ムページ等で利用方法を調べてみましょう。
6.3.6
ネットワークサービス
(1)sysinstall によるネットワーク設定
コンピュータのネットワーク設定ですが、sysinstall という統合管理プログラムを用いて、「Congfigure」
∼「Networking」∼「Interfaces」を選択すると、FreeBSD をインストールした時点で行ったネットワー
ク設定作業を行うことができます。
演習 6.17 sysinstall によるネットワーク設定を実際に行ってみましょう．
まず、sysinstall を起動し、「Configure」∼「Networking」を選択します (図 6.15)。
図 6.15: sysinstall:Configure∼Networking の選択
つぎに，
「Interfaces」を選択します (図 6.16)．
6.3. UNIX システム管理の実際
95
図 6.16: sysinstall:Interfaces の選択
すると、OS で認識されているネットワークインターフェースのデバイス名が表示されます。EPSON
NJ1000 では「rl0」を選択します (図 6.17では em0 となっています。HP ProBook 4710s/CT は別紙のド
ライバインストールによって myk0 が表示されます)。
図 6.17: sysinstall:NIC の選択
続いて、「IPv6 設定を行うかどうか」を問われますので No を選択します (図 6.18)．
第6章
96
UNIX システム管理
図 6.18: sysinstall:IPv6 設定の選択
さらに、「DHCP(ネットワーク設定の自動取得)」を問われますので YES を選択します (図 6.19 図では
NO にカーソルがあります)。
図 6.19: sysinstall:DHCP 設定の選択
すると、DHCP サーバを検索し、IP アドレスなどを自動的に取得し、図のホスト名のみが空白の画面に
なりますので、ホスト名のみを入力すれば良いでしょう。(図 6.20)。
6.3. UNIX システム管理の実際
97
図 6.20: sysinstall:IP アドレス等の入力
OS のインストール後で sysinstall を起動すると以上で設定が終わりですが、OS のインストール時です
と、下記のような質問が出てきます。この場合は、それぞれつぎのように入力します。
○ gateway となるかどうか？
・
・
・No
○ inetd を起動するかどうか？
・
・
・No
○ SSH ログインを許すかどうか？
・
・
・Yes
SSH(Secure SHell) によるリモートログインを許します
○ FTP サーバとなるかどうか？
・
・
・No
○ NFS サーバとなるかどうか？
・
・
・No
○ NFS クライアントとなるかどうか？
・
・
・No
NFS は「Network File System」の略で、UNIX においてネットワーク経由で遠隔のコンピュータのファ
イルシステムを共有 (マウント) するためのしくみです。セキュリティホールになりやすいので、インター
ネット上からアクセスできるマシンでの利用は極力避けます。
(2)/etc/rc.conf などのファイル書き換えによるネットワーク設定
一方で、手動でネットワーク関連の設定を変更することができます。ネットワーク設定で書き換えが必
要なファイルは
/etc/rc.conf
/etc/hosts
/etc/resolv.conf
の 3 つです。それでは、それぞれのファイルを開いて設定方法を実習してみましょう。
演習 6.18 上記の 3 つのファイルを開いて一部修正を行ってみます。
(a)/etc/rc.conf
このファイルを開くと、既にネットワーク設定されている場合には、つぎのような 3 行が存在します。
第6章
98
UNIX システム管理
hostname="kana.matsue-ct.ac.jp"
ifconfig_rl0="DHCP"
ここでは、最初の行 (hostname) がこのコンピュータの名前です。2 行目はネットワークインターフェース
(rl0,em0,myk0 等) に対する IP アドレス (inet) とネットマスクなどを指定しますが、ここでは DHCP を選
択したので、”DHCP” になっています。sysinstall を起動しなくても、ここを編集するとネットワークの
設定を変更できます。慣れてくると、この作業の方が簡単です。
(b)/etc/hosts
このファイルには、コンピュータ名と IP アドレスの対応が記述されています。もしも、自分の IP アド
レスを変更した場合には、この内容も修正します。なお、このファイルの書式はつぎの通りです。
IP アドレス
ホスト名
(c)/etc/resolv.conf
このファイルには、DNS サーバの情報を記述します。
search
cc.matsue-ct.ac.jp
nameserver 10.100.1.6
のように記述されているはずです。先頭行は、ネットワークコマンド等で指定する名前の後に、cc.matsuect.ac.jp を補完して IP アドレスを調べます、という意味になります。2 行めはネームサーバの情報です。
ネームサーバの情報を変更する場合にはこのファイルを直接編集します。 DHCP で IP アドレスを取得し
た場合には、このファイルも自動的に設定がされますので、確認だけで良いでしょう。
もし、(a)∼(c) の情報を手動で修正したならば、簡単には、
shutdown now
exit
・
・
・シングルユーザモードに移行
あるいは
reboot
といった操作をすると、修正したネットワーク設定がすべて反映されます13。
システム時刻
最後に、システム時刻を同期させる方法を紹介しましょう。ネットワーク上で時刻を同期させるしくみ
は、ntp(network time protocol) があります。インターネット上に公開 ntp サーバがいくつか存在してお
り、それらのコンピュータは電波時計など極めて正確な時間に同期をとっています。インターネット上に
接続する機器は、これらの公開 ntp サーバに同期をとることで、ある程度正しい時間に同期させることが
できます 1。単に date コマンドで直接システム時刻を修正することもできます。この場合は、
13 /etc/rc.conf という設定ファイルを直接手で修正して、 ifconfig=の設定が 1 行だけになっている場合は、 /etc/netstart という
コマンドでも設定が反映できます。この netstart というコマンドは既にメンテナンスされていないので極力利用しないようにしま
しょう。
6.3. UNIX システム管理の実際
date
99
200910311000
のように、年 (西暦)、月、日、時間、分を並べて設定を行います。
演習 6.19 ntp プロトコルで時刻同期の設定を行ってみましょう。
(1) インターネット上で公開 ntp サーバの IP アドレスを調べます。家庭などでは、みなさんのプロバイダ
などで準備されている場合がありますので、その場合はご利用になっているプロバイダの ntp サーバを用い
ましょう。松江高専内では、ntp.matsue-ct.ac.jp が ntp サーバとなっていますので、こちらを利用します。
(2)/etc/rc.conf の最後に、
ntpd_enable= ”YES ”
を追加します。
(3)/etc/ntp.conf を作成します。
vi
/etc/ntp.conf
(ntp.conf の内容)
server ntp.matsue-ct.ac.jp
driftfile /etc/ntp.drift
(3) 空の/etc/ntp.drift ファイルを作成します。
touch /etc/ntp.drift
以上の操作が終わったら、システムを再起動しましょう。しばらくすると、ntp.drift に時間の誤差に関す
る情報が記録されるようになりますが、この時点で時刻が同期していることになります。また、
ps
aux | grep ntp
で ntp 関連のプログラムが動作していることを確認してみましょう。■
第6章
100
6.4
UNIX システム管理
Ports/Packages によるソフトウェア管理
前章までで、FreeBSD のインストールとネットワーク設定が終わり、ユーザやパーミッションの概念を
学びました。ネットワークサーバの構築に向けて、今度は FreeBSD でのソフトウェアパッケージの管理方
法について学習します。
従来、UNIX 系 OS では次のような手順でソフトウェアをインストールしていました。
1. ソフトウェアのソースファイルやオブジェクトファイルが含まれたアーカイブファイル14 を入手する
2. アーカイブファイルからソフトウェアを取り出す (展開する)
3. INSTALL や README という名前のファイルを探して中身を読み、インストール方法を調べる
4. 入手したのがソースファイルの場合、指示された方法に従いビルド（オブジェクトファイルの構築）
する
5. オブジェクトファイルが正しく動作することを確認し、指示のとおりにインストールする
FreeBSD でも上記の手順でソフトウェアをインストールできますが、面倒な上、FreeBSD で使うことを
考慮して作られたソフトウェアでなければ正しく動作しないかもしれません。こんなことをしなくても、
FreeBSD には Ports/Packages という便利なパッケージ管理システムがあります。同等なシステムに、Linux
の apt-get、yum 等があります。以下では、Ports、Packages それぞれについて、その概要と使い方を説明
します。
6.4.1
Ports/Packages
Ports とは
Ports の正式名称は「The FreeBSD Ports Collection」です。コンピュータ用語で、ソフトウェアを
別のコンピュータ上で動作するようにすること、あるいはしたものを port(日本語で言えば「移植する」、
「移植版」) と呼びます。つまり、「The FreeBSD Ports Collection」とは、FreeBSD 上で動作するように
した移植版ソフトウェアを集めたもので、それを通称 Ports と呼んでいるのです。2009 年 10 月現在では、
20000 以上のソフトウェアが利用可能となっています。
といっても、Ports にはソフトウェアそのものが収録されているのではなく、ソフトウェアをインストー
ルするための情報、すなわち、ソースファイルの取得先、ビルドの方法、FreeBSD 上で動作させるための
パッチファイル (ソースファイルへのつぎあて)、他のソフトウェアとの依存関係などの情報が収録されて
います。そして、Ports を使ってソフトウェアをインストールするようコマンドを実行すると、ソースファ
イルのダウンロード、パッチの適用、ビルドが行われます。指定したソフトウェアが別のソフトウェアに
依存している場合には、そのソフトウェアも自動的にインストールされます。また、Ports の内容は日々更
新されているので、常に最新のソフトウェアを使用することができます。
Ports は「/usr/ports/」というディレクトリに収録されています。このディレクトリの中にはカテゴリ
ごとのディレクトリがあって、さらにその中にカテゴリに属するソフトウェアごとのディレクトリがあり、
各ソフトウェアの Port が収められています。この、/usr/ports/にあるファイルやディレクトリを「Ports
ツリー」と呼びます。また、ソフトウェアの Port が収められているディレクトリを「Port ディレクトリ」
と呼びます。
14 「アーカイブファイル」とは、zip ファイルのように複数のファイルやディレクトリをまとめた 1 つのファイルです。ただし、
UNIX 系の OS では zip 形式はあまり使わません。tar という形式で 1 つのファイルにまとめた後に gzip や bzip2 という形式で圧
縮されることが多く、その場合、アーカイブファイルの名前は∼.tar.gz や∼.tgz、∼.tar.bz2 や∼.tbz になります。
6.4. Ports/Packages によるソフトウェア管理
101
Packages とは
Packages は、上記の Ports システムからコンパイルして作成された、バイナリの詰め合わせキットのよ
うなものを言います (実際、make packages で作成できます)。FreeBSD では、基本的に Ports からソフ
トウェアをインストールをするのが基本ですが、大きなソフトウェアでは時間がかかるのが難点です。そ
のために、パワーが貧弱な PC やインストールに時間をかけたくない場合に用います。元々は Ports です
ので、インストール後の管理方法も Ports と同じになっているという訳です。
6.4.2
Ports ディレクトリの準備
FreeBSD をインストールした際に、Ports を導入する作業を行っていれば既に Ports ディレクトリが作
成されていますが、そうでない場合には新たに Ports 関連のツリー (ディレクトリ) を取得する必要があり
ます。また、Ports 自体 もソフトウェアのアップデートや、セキュリティホールの発見、新しいソフトの
移植などがされるごとに、アップデートされるために、最新の Ports にする必要などがあります。このた
めのコマンドとして、cvsup、csup と呼ばれるものがありますが、よりセキュアで効率がよい portsnap を
用いるのが最近では主流となっています。ここでは portsnap のみ解説します。
まず、一番最初に Ports ツリーを取得する際には、下記のコマンドを実行します。
portsnap fetch
・
・
・Ports ツリーのデータを取得 (fetch)
portsnap extract ・
・
・Ports ツリーのデータを展開 (extract)
portsnap update ・
・
・Ports ツリーのデータを更新 (update)
また、2 回目以降では extract オプションの行を省略でき、
portsnap fetch
portsnap update
・
・
・Ports ツリーのデータを取得 (fetch)
・
・
・Ports ツリーのデータを更新 (update)
となります。この作業で Ports ツリーが最新のものに更新されます。2 回コマンドを叩くのがめんどうな場
合は、
portsnap fetch &&
portsnap update
と&で区切ると一回でコマンド入力が可能となります。
演習 6.20
portsnap fetch &&
portsnape extract && portsnap update
で Ports ディレクトリを取得してみましょう。ただし、初回は少々時間がかかりますので気長に待ちましょう。
6.4.3
カテゴリ
/usr/ports 以下には、表 6.3のようなカテゴリ (Ports ディレクトリ) があります。
第6章
102
UNIX システム管理
表 6.3: Ports/Packages のカテゴリ
カテゴリ
内容
カテゴリ
内容
accessibility
アクセス補助
arabic
アラビア語
archivers
アーカイバ
astro
天文学
audio
音声
benchmarks
性能測定
biology
生物学
cad
CAD
chinese
中国語
comms
通信
converters
データ変換
databases
データベース
deskutils
デスクトップユーティリティ
devel
開発
dns
DNS
editors
エディタ
emulators
エミュレータ
finance
財務
french
フランス語
ftp
FTP
games
ゲーム
german
ドイツ語
graphics
画像
hebrew
ヘブライ語
hungarian
ハンガリー語
irc
IRC
japanese
日本語
java
Java
korean
韓国語
lang
プログラミング言語
mail
メール
math
数学
mbone
Mbone
misc
雑多
multimedia
マルチメディア
net
ネットワーク
net-im
インスタントメッセンジャ
net-mgmt
ネットワーク管理
net-p2p
P2P
news
ネットニュース
palm
Palm
polish
ポーランド語
ports-mgmt
Ports 管理
portuguese
ポルトガル語
print
印刷
russian
ロシア語
science
科学
security
セキュリティ
shells
シェル
sysutils
システムユーティリティ
textproc
テキスト処理
ukrainian
ウクライナ語
vietnamese
ベトナム語
www
WWW
x11
X11
x11-clocks
X11 時計
x11-drivers
X11 ドライバ
x11-fm
X11 ファイルマネージャ
x11-fonts
X11 フォント
x11-servers
X11 サーバ x11-themes
X11 テーマ
x11-toolkits
X11 ツールキット
x11-wm
X11 ウィンドウマネージャ
演習 6.21 /usr/ports ディレクトリに移動して、どのカテゴリにどんな名前のソフトウェアが収録されて
いるのか見てみましょう。また、日本語のコード変換を行うフィルタプログラム nkf(Network Kanji Filter)
が収録されている Port ディレクトリがどこにあるのか探してみましょう。
(hint)「日本語」ですから・
・
・。解答はつぎの演習問題にあります。
6.4. Ports/Packages によるソフトウェア管理
6.4.4
103
インストール
ports から簡単にソフトウェアをインストールする方法は、希望のソフトの Ports のディレクトリに移動
して、以下のように実行します。
cd /usr/ports/[カテゴリー]/[Ports ディレクトリ]
make install clean
この作業で、必要なソースプログラムをダウンロードし、パッチ等を当ててビルド (コンパイル、翻訳と
も呼びます) を行い、インストール (install) を行います。また、この作業の後で作業ディレクトリを削除
(clean) します。
演習 6.22 それでは、nkf を実際にインストールしてみましょう。
cd /usr/ports/japanese/nkf
make install clean
ここで利用している make というツールは、元々はプログラムの分割コンパイルなどのために作成され
たもので、Ports では色々な作業を行うのにこの make を利用しています。make は標準では、Makefile と
いうファイルに従って動作します (実際、Ports のディレクトリにはそのソフトごとの Makefile が用意され
ています)。make コマンドは、後ろに指定されたターゲットと呼ばれるものを作成するために、 Makefile
や標準で定められた方法に従って動作します。Ports では、何も指定せずに、make のみを動かすと、ファ
イルをダウンロード、パッチ当て、ビルドまでを行います。従って、上の指定は次のように順番に実行す
るのと同じです。
make
make install
make clean
なお、パッケージ自体も make package で作成することが出来るようになっている。
第6章
104
6.5
UNIX システム管理
演習課題
課題 6.1 adduser または pw コマンドでユーザを作成し、そのユーザの権限で適当なファイルを作成しな
さい。その後、そのユーザを vipw コマンドで削除したならば、先に作成したそのユーザのファイルの情報
(ls -l の結果) はどう見えますか。削除前と削除後の変化が分かるように答えなさい。 adduser または pw
コマンドでユーザを作成し、そのユーザの権限で適当なファイルを作成しなさい。その後、そのユーザを
vipw コマンドで削除したならば、先に作成したそのユーザのファイルの情報 (ls -l の結果) はどう見えま
すか。削除前と削除後の変化が分かるように答えなさい。
課題 6.2 /usr/local の下のディレクトリで、もっとも大きな容量を消費しているディレクトリを見つける
ための方法について考え、答えよ。
（少なくとも、一画面に収まり、一目で分かる方法でないといけません）
課題 6.3 NTP サービスを走らせて、時刻合わせをしなさい。うまく時刻が合わせられたら、
# ps auxww | grep ntpd
の結果を提出しなさい。
105
第 7 章 TCP/IP の基礎 1 — TCP/IP の概略
7.1
簡単なインターネットの歴史
多くの書物にあるようにインターネットは米国国防総省 (DOD) の高等研究計画局 (DARPA) が資金を
提供した ARPANET プロジェクトに端を発しています。これをもって、インターネットは軍事研究から出
発したとか、ARPANET は軍事ネットワークであったという議論もありますが、これは非常に皮相的な見
方であり、実際には間違っているとも言えます。この理由は、ひとつには当時の DARPA は非常に多くの
先端的技術と思われるものに資金を提供していたということ (資金提供の目的が軍事的であったことを否
定している訳ではありませんが、’60 年代のソ連との人工衛星打ち上げ競争の敗北から基礎技術への重視と
いう事がアメリカ全体として行われた一環であり、ソフトウェア品質や人工知能、ロボットなど非常に広
い分野の基礎技術に先行投資がなされていました)、二つ目には元となるパケット交換理論は ARPANET
プロジェクト (’68) に先立つ’61 には発表され、’62,’63 年はこうした分散型情報通信網は活発に研究される
ようになっていたことがあげられます。そうした経緯はありつつも、ARPANET プロジェクトによってパ
ケット交換ネットワークは非常に発展を遂げます。同時に、こうしたネットワーク研究は国際的な広がり
を持ち、当初 4 台のコンピュータから始まった接続実験 (UCLA, UCSB, スタンフォード大学、ユタ大学)
は’73 年にはイギリス、ノルウェーを繋ぐ国際接続へと成長していきます。こうした相互接続ネットワーク
はそれ自身が相互接続のための仕組みを要することは当然で、必然的に相互接続に必要なプロトコル (通信
のための手順のこと) の開発がその後の TCP/IP を生み出していくのでした [?], [?] 。このインターネット
の夜明けにおいて、当初から今日注目されている重要な要素が含まれていました。それはオープンであっ
たという点と、相互接続性が当初から重要な関心であったという点です。この２者は相互的に関連している
ものですが、広域ネットワークを成り立たせるためには決定的なものであると言って良いでしょう (一方、
ARPANET と同じようなメカニズムでありながら、学術ネットとして CSNET が’81 に発足し、ARPANET
に加盟できない大学などを接続して行きます)。
その後、’82 には TCP/IP が完成し、同時に’83 年に 4.2BSD 上で TCP/IP が実装され、配布されていき
ます。Unix とインターネットの親密な関係はここで決定されたと言えます (それ以前は NCP というプロト
コルを採用しており、’83 年に TCP/IP に切り替えられたので、この年を持って Internet の始まりと定義
する場合もあります)。そして、その後も Unix は TCP/IP の実装研究の中心的な舞台でありつづけ、今日
でも IPv6 実装の中心でありつづけています。ともあれ、TCP/IP を接続プロトコルとするネットワークは
各国で生まれ、ARPANET と相互接続されながら、研究・実験が進められました。’90 年には ARPANET
はその役割を終え、既に設立されていた他の機関がその役割を完全に取って代わっていました。この当時
(’89) で接続台数は約 10 万台程度であったとされています。筆者の経験でも、当時は国内のネットワーク
を研究していた機関だけではなく、国際的な科学研究機関の多くが何らかの形でインターネットへの接続
を果たしていましたが、あくまでも一部に限られ、科学者一般に普及していた訳でもありませんでした。
こうした状況が一変し、インターネットの爆発的成長が始まるのが、’93 年からです。この年に先立つ
’91 年に CERN において WWW が発明され、’93 年に初めてのブラウザである Mosaic が発表されます。
そして、この年には WWW のトラフィックは三千倍以上に増加したのでした。そしてその後の数年間でイ
ンターネットは世界中を覆う単一巨大ネットワークへと成長し、多くの企業・学校・家庭へと普及すると
第7章
106
TCP/IP の基礎 1 — TCP/IP の概略
共に、それぞれの接続もブロードバンドと呼ばれる高速接続へと形態を変化させ、その変化は現在も社会
に大きな影響を与えています。
1957
1961
7.2
表 7.1: インターネット技術の歴史
ARPA 発足
L.Kleinrock, パケット交換理論
1962
1963
J.C.R.Licklider & W.Clark, オンラインコンピューティング理論
P.Baran, 分散型情報通信理論
1968
1969
ARPANET プロジェクト
ARPANET 始動 ４台 50Kbps
1970
1971
ALOHA system(ハワイ大学) 無線によるパケット通信
米国２３台１５箇所接続
1971
ARPANET で mail
1973
1973
国際接続 イギリス・ノルウェー
1973
1974
V.Cerf & B.Kahn, TCP 理論
TCP 設計
1978
1982
TCP/IP 策定
TCP/IP 完成 Internet が実質的に定義
1983
1983
4.2BSD に TCP/IP が実装・配布
ARPANET TCP/IP に切り替え
1984
1989
DNS の導入
100,000 台突破 Internet 接続
1991
1992
WWW の発明 (CERN)
1,000,000 台突破
1993
1993
InterNIC 設立
ブラウザ (Mosaic) の発明 WWW トラフィック 341,634 ％増加
1995
Java,RealAudio, 商用 Internet ラジオ局
2000
ブロードバンドの始まり
PaloAlto 研究所, Ethernet 理論 (CSMA/CD 3Mbps)
ネットワークと TCP/IP
詳しい話に入る前にもう少し一般的な話をしておきます。通常我々はネットワークという場合非常に広
い意味で使っています。たとえば、被災者救援ネットワークというようなコンテキストで使う場合は、人
間組織としてのネットワークという意味で利用しています。しかし、ここで問題にしているネットワーク
は具体的には情報機器を相互接続したネットワークという意味です。もっと簡単には、相互接続された実
体全部を指してネットワークと呼んでいます。つまりは、このネットワークという言葉で重要になってく
るのは、相互接続のための言語、あるいは接続方法、専門的にはプロトコルが問題となってくるのです。
なぜならば、相互接続されても、相互通信が出来ないのならばそれはネットワークとは呼べないからであ
り、ネットワークという限り相互通信が可能であることを意味しているからです。もちろん、相互通信が
可能であればその方法がどんなものでもネットワークと呼ぶ訳であり、実際にさまざまな情報ネットワー
クが過去には存在していました。しかし、今日ではそれらの多くはインターネット上のプロトコルである
7.3. パケットの必要性
107
TCP/IP との闘争に敗れ、かえりみられなくなっています。これは一言で言えば、普遍性を巡る戦いに負け
たからと言えますし、ネットワーク技術も (むしろネットワーク技術だからと言うべきか)、普遍的、オー
プン技術へとシフトしていった結果であると言えます。
一方、携帯電話自体などはまだ独自の通信技術の世界にあります。電子メイルは確かにインターネット
と相互にやりとりが出来、i-mode では Web へもアクセス出来ますが、携帯自体はインターネットに直接
接続されている訳ではありません。とは言え、IP 電話と同じように携帯も TCP/IP の上でのデバイスへと
変化して行くでしょう。
ここまでインターネット上のプロトコルとして TCP/IP を紹介してきましたが、実は TCP/IP は一つ
ではなく、複数のプロトコルからなるプロトコルのファミリーを総称して TCP/IP と呼ばれています。詳
しくはおのおのの節で説明をしますが、主には以下のようなプロトコルから構成されています。
1. Transmission Control Protocol (TCP)
2. User Datagram Protocol (UDP)
3. Internet Control Message Protocol (ICMP)
4. Address Resolution Protocol (ARP)
5. Reverse Address Resolution Protocol (RARP)
なお、現在のインターネットで利用されているプロトコルには多くのものがありますが、TCP/IP はそ
の中でも最も基盤となるプロトコルであると言えます。
7.3
パケットの必要性
TCP/IP についてお話しする前に、その基本構造を構成している技術的要請について簡単な説明をして
おきましょう。
2 点間で通信をしようとする場合について考えましょう。最も原始的なものとしては糸電話のようなも
のを考えれば、その場合には相手を判別する必要はありません。相手は予め分かっているのですから。こ
のような通信における回線という点に着目すれば、機能的にはこれは専用線と言われるものです。電話の
システムも機能的には同じです。一度相手に電話が通じて、話し始めれば、相手の確認をいちいち行う必
要はありません。もちろん、現在の電話は大昔の電話のように本当に専用線を確保している訳ではありま
せんが、機能の面では同じなのです。このような通信方式は一般に回線交換方式と呼ばれています。回線
交換方式の利点は占有することによる品質の高さですが、それは一方では回線の使用率という点では無駄
が多いことを意味しています。たとえば、2 点間に専用の回線を用意しなければならないという点だけを
とってみても無駄が多いことは明らかです。
回線交換の問題は突き詰めれば専用線、あるいは占有するという点にあります。つまり、対案は共有に
あることになる訳です。では、どのようにすれば共有できるのでしょうか。実は搬送路を共有するような
システムは既に我々の回りに馴染み深いものとして存在しています。それは郵便あるいは宅配のシステム
です。以下では、データ通信を郵便になぞらえて考えてみます。郵便で配達される手紙に書かれた情報が
データ通信におけるデータに対応します。多くの手紙が多地点間でやりとりされますが、郵便局の間では
それらは同じ郵便配送車や列車、飛行機に袋詰めされて配送されます。つまり、配送路が共有されている
訳です。このように、共有のための第一条件は情報がある小さな単位に分割されている事です。電話では
相手からの応答がある間も含めて回線は占有されていますが、手紙や葉書で相手とやりとりする場合相手
から返事が返るまで配送路を占有している訳ではありません。データ通信においてこれと同じ考え方をし、
第7章
108
TCP/IP の基礎 1 — TCP/IP の概略
通信データを適当な大きさに分割します。これをパケットと呼びます (パケットは英語で小包という意味で
す)。つまり、パケット化を行う事で、多くの多地点間通信と同じ配送路を共有する訳です。勿論、郵便が
局で適宜仕訳され配送されるのと同じように、データ通信でも局に相当する部分が必要なのですが、それ
が可能であるためには郵便における宛名や差出人に相当する情報が必要であることが分かります。
このような宛名や差出人名あるいは住所に相当するものはどうあるべきなのかについては後に詳しく説
明しますが、ここでは単純に住所 (アドレス) について考えてみましょう。我々が通常用いている住所は多
数の情報を非常に短く簡潔に表すために、階層構造を採用しています。こうした階層構造はデータ構造で
は良く利用されるものですが、IP でもこうした階層構造を採用しています。但し、残念ながら現在利用さ
れている IPv4 では２階層のみの構造になっていますが、IPv6 では大幅に階層構造が採用されています。
一方、宛名や差出人名はデータ通信では言わば個体の識別に対応していますが、日常生活で我々が使って
いるものと１対１対応するかと言うと少し違いがあります。一つはアドレスがある種の個体識別的役割を
担っている点と、次に説明する階層による識別方法の相違、第三に個体の認証をどうするかという点です。
最後の点は少し難しい問題で、郵便でもそれほど厳格な訳ではありません (普通の郵便ではポストに投げる
だけですし、書留でも印鑑程度です)。ここまでの段階ではアドレスについては、この程度に留めておき、
アドレスを理解する前に通信で重要な別の問題について考えてみましょう。
通信方式と進歩
回線交換とパケット交換方式は当初においては確かに全く違う技術でしたが、近年の進歩は両者の違いをなく
しつつあります。回線を高速でスイッチする (当然、バッファなどでその間は支える) ような考え方をとると、
占有という古典的な考え方とは異なってきます。つまり、回線が固定的にあるのではなく、仮想的な回線へと変
化してきているのです (回線自体のパケット化とも言えるかも知れません)。専用線のデメリットがなくなれば、
メリットのみが残ると考える人々も当然出て来る訳です (コストなどの問題は別ですが)。TCP/IP は確かにパ
ケット交換に基づいていますが、それを仮想的な回線交換に載せても問題はありませんし、むしろパケットのア
ドレスに関する処理の冗長な部分を大幅に少なくすることも出来ます。このように、技術の進歩が元々は異なる
技術を一つのものに融合させていくという局面は、歴史に度々登場することです。従って、回線交換やパケット
交換を固定的に見るのではなく、その出現の必然性を基本的に理解するという事が重要なのです。
7.4
階層化通信モデル
一般に通信全体をシステムとして考えると非常に複雑なシステムであることが分かります。電話ですら
も現在では複雑な交換機が利用されており、情報ネットワークでは更にプロトコルの問題が付加されます。
このような複雑なシステムが、たとえばたった一つのハードウェアで構成されていて、それを動かすプロ
トコルも全てハードウェア上に実装されていたとしたら、どうなるでしょうか？もちろん、使う側に取っ
ては別に問題はありません。例えば、PC のインターフェースカードを買ってきたら即座に通信できるで
しょう。しかし、作る側に立って考えれば問題が明らかになります。つまり、作る側からすると、新しいイ
ンターフェースカードを作るたびごとに最初からソフトウェアをそれに合わせて作り直す必要があるので
す。もちろん、さすがにこんな面倒なことはしないでしょうが、メーカが違えば当然全ての過程が異なる
事になります。初めてそうしたカードを製造しようとするメーカにとっては非常に大きな障壁となります。
さらには、もしプロトコルに変更があった場合には、ハードウェアごと買い替える必要があります。これ
が非常な無駄であることは自明の理であると言えます。したがって、何らかの分離が必要です。そのよう
な分離では、ハードの構造はプロトコルへの依存が無いか、あるいは最小であることが望ましいでしょう。
また、こうしたハードを駆動するドライバソフトについても同じように、プロトコルからは一定の分離が
行われている方が望ましいでしょう。すると、ハードから離れたプロトコルを解釈し、実行するような部
分は別に存在するべきです。同時に、こうした通信システムを利用するアプリケーション・プログラムの
立場から見ても同じことが言えます。このような流れは、実はプログラミングの構造化と同じような流れ
であったと言えますし、そこにたどり着くまでに色々なベンダー毎の取り組みや研究が背景にあったのも
忘れてはなりません。
7.4. 階層化通信モデル
109
さて、以上のように考えると、必要とされる分離はいくつかの階層を持つ必要があることがわかります。
こうした考え方を階層化通信モデルと言います。では、いくつの階層があるべきなのでしょうか。実は、こ
れは結構難しい問題なのです。あるいは、別の言葉で言えば、十人いれば十通りの考えがあっても良いと
言えます。実際、こうした階層化は 70 年代後半から 80 年代にかけて研究をされ、後で述べる OSI の７階
層モデルや、TCP/IP の階層モデル、さらにはメーカ独自の階層モデルも存在したのです。
ここに掲げるのは、国際標準化機構 (ISO) が開発をしたオープンシステム相互参照モデル (Open System
Interconnect Reference Model: OSI model) と言われるものです。これは 7 階層を持つので、OSI 7 階層
モデルとも呼ばれています。
表 7.2: OSI7 階層モデル
アプリケーション層
プレゼンテーション層
セッション層
トランスポート層
ネットワーク層
データリンク層
物理層
OSI の階層モデルは非常に美しく、整理されたものですので、未だにこうした階層モデルの基本的な説明
として出てきますし、避けては通れないものです。しかし、現実の世界では OSI モデルではなく、TCP/IP
が生きて使われており、それは OSI とは少々異なるものであるのです。なぜ、OSI が生き残らなかったの
かは後で述べることにして、TCP/IP の階層モデルをつぎに掲げましょう。
表 7.3: TCP/IP4 階層モデル
アプリケーション層
トランスポート層
インターネット層
ネットワーク・アクセス層
OSI のモデルと比較すると全体に簡潔ですが、省略された所、同じ所、2 つが一緒になっているような
所がある事がわかります。より詳細に比較するとわかるのですが、結論的には、OSI モデルと TCP/IP の
階層とはあくまでも違うモデルであり、したがって、OSI モデルで説明すると TCP/IP とは少し違う部分
が出てきてしまうのですが、多くの場合 OSI モデルを TCP/IP に当てはめて解説がされています。もし、
皆さんが今までに TCP/IP の説明を聞いて、それがどうも納得できないでいたとしたら、もしかするとこ
れが原因であるかも知れません。では、なぜわざわざ OSI のモデルを使って解説するのでしょうか。一つ
は、OSI のモデルが基本であると多くの人が考えているのと、二つ目としては実は TCP/IP 自体はモデル
ではなく、あくまでも実装であるという事があげられると思います。前者はいかにもそれらしい説明です
が、後者について少し筆者の考えを説明したいと思います。
先に、OSI はモデルで実際には使われていないという事を言いましたが、実は OSI を実装したシステム
がない訳ではなかったのです。しかし、それらのシステムは一部を除いては使えないものであったのです
(動作しなかったり、遅すぎたり...)。つまりは、モデルとしては良かったが、現実はそれほど甘くはなかっ
たという訳です。一方、TCP/IP は OSI モデルと比較して実際に動くシステムとして実装されて行きまし
第7章
110
TCP/IP の基礎 1 — TCP/IP の概略
た。また、同時に、TCP/IP は階層モデルで説明するには少し不純な部分を持っているという面もありま
す。のちほど紹介する ARP や RARP と言ったプロトコルは、ネットワーク・アクセス層とインターネッ
ト層の中間の性質をもっており、きれいな説明が難しいのです。つまり、実装としての性格が優先された
結果だと言えるのではないでしょうか。このような理由で、TCP/IP の説明の多くは OSI 階層モデルを援
用して、5 階層あるいは 4 階層のモデルで説明されるという訳なのです。したがって、モデルはあくまで
もモデルで、大体の理解をするためのものであると思えば良いでしょう。
理論と現実
このような事情は、プログラミングにおけるオブジェクト指向と良く似ていると言えます。モデルとしてはオブ
ジェクト指向は美しいのですが、純粋なオブジェクト指向言語は実行速度が遅い事が知られています。したがっ
て、ある程度不純なオブジェクト指向言語の方が一般には良く使われています。さらに、そうした不純なオブ
ジェクト指向言語のプログラミングでも、純粋にカプセル化を行ったり、継承を重ねるのは、実行速度の面で不
利であることが良く知られています。別の見方をすると、通信階層のモデルも言語モデルと同じように速度やプ
ログラミングのしやすさという点で考えると、適当な所で折り合いを付けるのが現実的だという風にも言えま
す (もっとも、今の技術で７階層を作れば十分使えるものが作れそうでもありますし、いずれ再びそういう技術
の段階が訪れるのも必然でしょう)。
さて、以上のような理由からここでは以下のようなモデルで TCP/IP を説明することにします。
表 7.4: TCP/IP5 階層モデル
アプリケーション層
トランスポート層
ネットワーク層
データリンク層
物理層
見ればわかる通り、下の２階層が TCP/IP 本来のネットワークアクセス層にあたる OSI モデルから借用
した部分です。ネットワーク層から上はほぼインターネット層と同じです。それぞれの層の役割は下から
順につぎのようになります。
1. 物理層
物理層とは、イーサネット・ケーブル上の電気信号にかかわるような、プロトコルのハードウェア的
なレベルの階層です。物理層では、「パケット」(フレームと呼ぶ事もあります) の形で、データを送
受します。ここにはケーブルなどの性質の定義なども含まれます。
2. データリンク層
データリンク層は、物理的に接続された端末間のデータの通信を行います。最も低レベルでの通信を
提供していると言っても良いでしょう。ここでは、Ethernet(イーサネット) が代表的なデータリンク
層のプロトコル (実際には TCP/IP は 4 層モデルですので、Ethernet の規格は物理層を含んでいま
す) です。個体の識別には MAC アドレス (イーサネットアドレスとも言う) が用いられます。
この層と次のネットワーク層の中間に、IP アドレスをイーサネット・アドレスに変換する ARP プロ
トコルや、この逆の、イーサネット・アドレスを IP アドレスに変換する RARP プロトコルが含まれ
ます (ARP は基本的なプロトコルですが、RARP は IP を持たない X 端末などが IP を取得するため
に考案された少し古いプロトコルです)。
3. ネットワーク層
7.5. 階層モデルとパケット
111
IP (Internet Protocol) が、ネットワーク層に属します。この層は端末間の通信プロトコルである IP
を提供します。IP は、伝送経路の確立や、IP アドレス・クラスによるネットワークの論理的な管理
等を担当しています。IP ヘッダーには、さまざまな情報が含まれますが、その中で最も重要なもの
は、データの送り手と受け手のそれぞれの IP アドレスです。また、通信状態を検知したり、管理す
るためのプロトコルである ICMP (Internet Control Message Protocol) もここに属しています。
4. トランスポート層
この層は、別々のマシンのそれぞれのプロセスのあいだの通信を保障します (つまりはアプリケーショ
ン間通信を保証します)。この層には、TCP や UDP が含まれます。
TCP は、通信中にエラーが起こればデータの再送をするなど、確実なデータの伝送を保障します。
しかし、その分 TCP は、コネクションの確立などに手間がかかります。 UDP では、エラー回復は
行われず信頼性は劣りますが、コネクションなしのデータグラムの通信を行います。
TCP も UDP も、プロセスを特定するのにポート番号を使います。
5. アプリケーション層
TCP/IP のプロトコルの上で走るたくさんのアプリケーションがあります。また、berkley ソケット・
ライブラリーという、ライブラリーを用いて、自由に、TCP/IP 上のアプリケーションを開発すること
ができます。なお、この層ではアプリケーション毎に特有のプロトコルがあることに注意しましょう。
例えば、Web のアクセスのために用いられるプロトコルは HTTP(Hyper Text Transfer Protocol) で
あり、メイルの配送に使われるプロトコルは SMTP(Simple Mail Transfer Protocol) です。
とは言え、これを聞いてすぐにわかる人も少ないでしょう。ここではあくまでも説明の都合上、簡単に
紹介しただけで、詳しくは後の章で説明しますので、そういう階層があるという事だけを理解すれば大丈
夫です。
7.5
階層モデルとパケット
先の階層モデルの詳細について見る前に、この階層モデルはどのような働きをするのかという点につい
て説明し、それとデータとの関係について見てみましょう。
階層モデルでは一番上位にあるのがアプリケーションです。そこで、アプリケーションからデータを送
信する場合について考えてみましょう。プログラム的には、アプリケーションはネットワークの API や、
クラスを通じて、この階層から下のトランスポート層へとアクセスをします。この時、トランスポート層
は受け取ったデータに一連の処理の結果を加えます。このように、一番下位の層を除き、中間の層での処
理のほとんどは何らかの形でのデータ処理であり、その結果はヘッダという形で上位から渡されたデータ
へと付加されます。ここで、上位から渡されたデータをペイロードと呼び、ペイロードにヘッダを加えた
ものが、更に下の層へとデータ (ペイロード) として渡されてゆきます。
ペイロードとは貨物の意味です。つまり、ここではヘッダによって運ばれる貨物がデータである訳です。
最後に物理層では伝送路に送り出されて行きます。なお、物理層でのみヘッダのみならず、パケットの
後尾にチェックサムがつきます。また、物理層ではパケットが大きな場合には分割が行われる場合 (この場
合特にフレームと呼びます) がありますが、説明の都合上省略します。
これらの処理では各層においてカプセル化が行われている点に注意してください。つまり、トランスポー
ト層で作成されたヘッダとその上位から渡されたペイロードは、その下の層であるネットワーク層から見
たら処理すべきデータであり、従ってネットワーク層でのペイロードとなる訳です。この時、ネットワー
ク層ではトランスポート層での詳細とは無関係に処理が行われます。
第7章
112
TCP/IP の基礎 1 — TCP/IP の概略
aplication
ƒf [ ƒ^
ƒw ƒb ƒ_
ƒg ƒ‰ ƒ“ ƒX ƒ| [ ƒg ‘w
ƒw ƒb ƒ_
ƒl ƒb ƒg ƒ [ ƒN w‘
ƒw ƒb ƒ_
ƒf [ ƒ^ ƒŠ ƒ“ ƒN ‘w
•¨ — w‘
ƒw ƒb ƒ_
ƒf [ ƒ^
ƒf [ ƒ^
ƒf [ ƒ^
ƒf [ ƒ^
ƒ` ƒF ƒb ƒN
CRC
ŠK w‘ ‚Æ ƒf [ ƒ^ E wƒ ƒb ƒ_ ‚Ì ŠÖ ŒW
図 7.1: 階層とヘッダの関係
さて、このように送出されたパケットは最終的に目的の端末に着くと、この階層を下から上へと逆に上っ
て行きます。その際には、送出の場合の反対に各階層でそこに関係するヘッダが取り出され、処理された
後にペイロードが上位の層に渡されます。上位層は再び同じようにして自らの層に関連するヘッダを処理
し、最終的にアプリケーションへと渡される訳です。
このカプセル化と同時に、各層はそれぞれの上位の層とは分離して存在するために、異なる上位プロト
コルを扱うことが出来るようになっています。つまり、ある層の上にあるプロトコルは TCP/IP で期待す
るものと異なっていても良い訳です。これによって、既存プロトコルを上位層のみ異なるプロトコルとし
て受け入れる事が可能になりますし、将来の変化を柔軟に吸収できるようになっているのです。
さて、各層における情報がヘッダとして追加されることを見てきたのですが、何故ヘッダ (頭に付けるの
でヘッダ、末尾につけるのはフッタ) なのでしょうか。勿論、末尾につけてはいけない理由はありません。
単に頭につける方が取り出す際の処理が簡単になるからです。もしフッタならば、ペイロードが固定長で
無い限り、データの後ろから検索し、フッタ部分の情報を取り出さなければなりません。もしくは、フッタ
が固定長ならば処理は簡単ですが、さまざまなヘッダ情報を全て固定長にするのは面倒ですし、将来的に
柔軟性を損なうことになります。従って、固定長が困難であるとすると、後ろから走査するしかなく、そ
れならば頭から行う方が簡単である訳です。さて、このように考えると、将来的には固定長のフッタはあ
り得るという事が良く分かります。それはヘッダ処理に何の影響も与えず、独立して行えるがゆえにいろ
いろと便利そうです ( もしくは筆者の気づいていない何か別の問題があるのかも知れませんが)。
最近話題になりつつある MPLS (MultiProtocol Label Switching) ではシムラベルヘッダを従来のリン
クヘッダとネットワーク層ヘッダの間に挿入しています。
もちろんこうした新しいヘッダは TCP/IP スタックからすると処理不能なものなのですが、TCP/IP ス
タックが関与しない通信路の途中で挿入し、相手にパケットが到着するまでに取り除けば TCP/IP スタッ
クはそれを関知できない訳ですから、別に問題ではないのです。
7.6. パケットの実際
113
ƒg ƒ‰ “ ƒX ƒ| [ ƒg ‘w
ƒl ƒb ƒg ƒ [ ƒN ‘w
ƒf [ ƒ^ ƒŠ “ ƒN ‘w
•¨ — ‘w
TCP UDP
Apple
Talk
IP
Ethernet
‘½ d ‰» ‚Æ ŠK ‘w
図 7.2: 多重化と階層
ƒŠ ƒ“ ƒN ‘w Vƒ ƒ€ ƒ‰ ƒx ƒ‹ IPw
ƒw ƒb ƒ_ wƒ ƒb ƒ_ ƒ ƒb ƒ_
IP
ƒy ƒC ƒ [ ƒh
図 7.3: MPLS におけるパケット
スタック
階層モデルは良く積木の積み上げたイメージであるので、スタックとも呼ばれ、
「TCP/IP スタック」のように
使われます。
7.6
7.6.1
パケットの実際
Wireshark の導入
ここまで簡単に TCP/IP の背景や基本について見てきましたが、こうしたものを勉強する際にはやはり
実際のパケットを見ながら勉強する方が具体的にわかりやすいでしょう。以前は、こうしたパケットをの
ぞいてみるのはなかなか骨の折れる作業でした (パケットダンプと言います)。パケットダンプした結果は
16 進数で、しかもヘッダもペイロードも全て自分で分離して解読しなければなりませんでしたから、全て
を理解してからでないとできないことだったのです。しかし、最近ではこうした分離やプロトコルの解釈
なども全て自動的に行ってくれるツールが利用でき、それは MS-Windows でも利用できるようになってい
ます (ついこの間までは、Unix でないとできなかった)。そこで、細かい点はさておいて、こうしたツール
を用いて実際にパケットを覗いてみることにしましょう。
しかし、その前に少し注意があります。まず第一に共有ネットワーク上で他人の通信を覗き見ることは、
紛れもなく盗聴行為です。したがって、共有ネットワーク上でこうしたツールを一般の人が使ってはいけ
ません。必ずスイッチドネットワーク上で自分に関するパケットのみを見るようにするか、自宅のネット
ワークなどで行うようにしましょう (管理者は必要のあるときにはこうしたパケットダンプを行いますが、
極力自分が構築した実験用のパケットに対して行います)。
オリジナルは、www.wireshark.org に置かれています。また、こうした GUI 以前の Unix 用のツール
では tcpdump が有名です。
第7章
114
TCP/IP の基礎 1 — TCP/IP の概略
• [参考]
Wireshark は以前は Ethereal という名前で知られていましたが、商標登録されていたために製作者の転職と共
に名前を変更せざるを得なくなったようです。
FreeBSD で Wireshark を使うには、パッケージからインストールしなければなりません。
# pkg_add
-r
wireshark
また、その他に sudo を導入しておくと良いでしょう。sudo コマンドは、root にならずに、root 権限で
プログラムを動かすためのツールで、一般ユーザに対してプログラムごとに指定することが出来るもので
す (例えば、一般ユーザでも shutdown コマンドを実行できるように指定できます)。
# pkg_add
-r
sudo
sudo の設定は、/usr/local/etc/sudoers.default というファイル (サンプルファイルがあります) を
コピーして以下のように 2 行を追加します。
# cd /usr/local/etc
# cp sudoers.default sudoers
# vi
sudoers
# sudoers ファイルの末尾
User_Alias
FULLTIMERS=kanayama
FULLTIMERS
ALL=(ALL) ALL
上記の設定によって (kanayama は自分のユーザ名に変更してください)、指定したユーザ (今の場合は
kanayama) は、root 権限でプログラムを実行出来るようになりますが、それでも実行時にパスワード (root
ではなく、kanayama の) を聞いてきます。もし、パスワードを聞かずに実行するようにしたい場合には、
最後の行を以下のように変更します。
FULLTIMERS
ALL=(ALL) NOPASSWD: ALL
さて、先に入れた Wireshark は管理者権限がなければ動かすことができません (正確にはパケットをキャ
プチャの権限がなければなりません)。管理者権限で Wireshark を動作させるには、su あるいは sudo コ
マンドを使います。sudo は、端末コンソール (アプリケーションメニューのアクセサリにあります) から、
以下のようにして実行します。
$ sudo wireshark
パスワード:
上記のようにパスワードを聞いてきますので、自分のログインパスワードを入力します (インストール
時に作成したものです)。すると、Wireshark が起動する筈です。
root パスワードを設定している場合には、以下のようにして root になってから実行しても良いでしょう。
$
su root
# wireshark &
7.6. パケットの実際
115
図 7.4: ipconfig の実行画面
7.6.2
Wireshark とフィルター設定
実際にキャプチャを始める前に、自分のマシンの IP アドレスをチェックします。Windows での IP アド
レスの確認は NT,2000,XP ならばコマンドプロンプトを出してその中で、ipconfig /all を実行します。
Unix などでは、端末上で、ifconfig を入力します。
BSD 系の OS では以下のような表示になります。
# ifconfig
lnc0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=9b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM>
ether 00:10:18:01:55:e5
inet 192.168.1.10 netmask 0xffffff00 broadcast 192.168.1.255
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3
inet6 ::1 prefixlen 128
inet 127.0.0.1 netmask 0xff000000
この場合は、自分の IP アドレスは、lnc0 の 3 行下の 192.168.1.10 になります。それぞれ、自分のマ
シンで自分の IP アドレスを確認してください。
自分の IP アドレスを確認したら、いよいよパケットをキャプチャします。まず、Wireshark のメニュー
Capture から Options を実行します。
第7章
116
TCP/IP の基礎 1 — TCP/IP の概略
図 7.5: Wireshark メニュー
すると、つぎのようなウィンドウが現れます。もし、インターフェースなどが異なっている場合にはこ
こで指定することもできます。
図 7.6: Wireshark オプション
このまま、Start を押して、キャプチャをしても良いのですが (単に Start を押すだけなら、メニューの
Capture の Start でも同じです)、このままでは必要のないパケットもキャプチャして見づらくなるので、
以下のように必要のないものをキャプチャしないように設定します。
Capture Filter の右横のテキストボックスに先に調べた自分の IP を使って、host 192.168.24.73 の
ように設定をします。これは、自分宛かあるいは自分が発信したか、いずれかに一致するパケットをキャ
プチャすると言う意味です。このように Filter に指定した式で必要なパケットのみをキャプチャすること
が出来ますが、詳しくはプロトコルについての知識が必要です。今のところは、以下のパターンのみを知っ
ていれば良いでしょう。
host 192.168.0.1 and host 192.168.0.2
上記の場合には、192.168.0.1 と 192.168.0.2 の間で交換されるパケットのみに一致します (and は
host 192.68.0.1 という条件と、host 192.168.0.2 という条件が同時に満たされるという意味です)。
一方、以下の例では、192.168.0.1 か、または 192.168.0.2 に関係するパケットのみがキャプチャされます。
7.6. パケットの実際
117
図 7.7: Wireshark キャプチャ結果
host 192.168.0.1 or host 192.168.0.2
Wireshark での条件には、or, and, !(not) などが指定でき、それらの論理式は (
とができます。
) でまとめるこ
host 192.168.0.3 and ( host 192.168.0.1 or host 192.168.0.2 )
さて、先の host [my IP] というフィルタで Start ボタンを押すと、キャプチャが始まりますが、当然何
も通信していないと何も表示されません。そこで、ブラウザで適当なサーバへとアクセスしてみましょう。
(何時までもキャプチャしても仕方ないので、一通りページが表示されたら Stop ボタンを押してキャプチャ
を停止させておきましょう。)
7.6.3
Wireshark で見るパケット
Wireshark は３つのペインから成り立っています。一番上のペインは一行が一つのパケットに相当しま
す。発信者アドレス (Source)、受信者アドレス ( Destination)、プロトコル (Protocol: TCP,UDP や更に
上の層のプロトコル HTTP など) 、パケット情報などです。２つめのペインには、カーソルのある行のパ
ケットのヘッダ情報が表示されます。３つめのペインにはパケットの中身が完全に表示されます。
まず、一番上のペインについて見ると、最下行のパケットは 192.168.0.1 から 192.168.0.2 に飛んだ
HTTP(したがって当然 TCP) でのパケットで、中身は HTTP の GET 命令であることが分かります。
第7章
118
TCP/IP の基礎 1 — TCP/IP の概略
図 7.8: Wireshark キャプチャ結果詳細 1
図 7.9: Wireshark キャプチャ結果詳細 2
つぎに、2 番目のペインには、各階層ヘッダがそれぞれ分けて表示されます。
Frame, Ethernet, IP, TCP, HTTP のように上のものが下層の、下のものが上位の階層のプロトコルを
表示し、+ の部分をクリックすると、それらの階層ヘッダの中身を表示するようになっています。
さて、実際にウェブのページを見ると、どのくらいのパケットが交換されるかを見てみましょう。
まず、見たいウェブのページを決めてください (最初にどこかを見て、そのリンクを見るようにしても
構いません)。決まったら、いったん Wireshark のキャプチャを終了させ ( メニューの Capture の中の
Stop を押すか、キーボードで Ctrl + E を押し) ます。つぎに、最初に Wireshark を動かした時と同様
に、Capture メニューの Options de で、Options ダイアログを出し、Capture Filter: の右のボックス
に先に説明した IP アドレスのフィルタルールを書きます。たとえば、
host www.watch.impress.co.jp and host 192.168.1.1
のように指定します (自分が見ようとしているサイトと、自分の IP アドレスを指定してください)。
参考 実は、ホスト上では自分を指定する必要はありません。なぜなら、今ではほとんどがスイッチドネットワークに
あるために、自分以外宛のパケットが自分のインターフェース宛に来ることはないからです。但し、ルータや
NAT などの通信路上のホストでは別です。
これでキャプチャをはじめると、
図 7.10: Wireshark キャプチャ結果詳細 3
7.6. パケットの実際
119
Save capture file before starting a new capture?
というメッセージの書かれたダイアログがでます。このメッセージの意味は、「新しいキャプチャを始め
る前に、キャプチャしたファイルを保存しますか？」という意味ですが、つまりは先ほどキャプチャした
ものを保存するかという意味ですので、保存しない場合には、Continue without Saving ( 保存せずに
続ける) ボタンを押してください。
これで、キャプチャが始まりますが、実際に何の通信もなければ全くパケットは飛ばないので、キャプ
チャもされません。ここで、先に見ようと思ったウェブを見るか、リンクをクリックしてください。
さて、うまくキャプチャできたでしょうか？うまくキャプチャが出来ると、自分と相手との間で、パケッ
トが行ったり来たりしているのが目で確認できると思います。また、一枚のウェブページを表示するため
に、多くのパケットが交換されていることもわかるかと思います。
121
第 8 章 TCP/IP の基礎 2 — 階層
前の章で簡単に、通信階層が必要であることを学習し、 TCP/IP の階層と OSI の階層について触れまし
たが、もう少し詳しく階層について学び、ネットワークについての理解を深めることにしましょう。
8.1
物理層
物理層では信号や、ケーブル、インターフェースなどを定義していますが、通常ネットワークを構築す
る上で重要なのは通信方式とケーブルとの関係です。同時に、ケーブル自体の問題について知っておく必
要もあります。
8.1.1
イーサネット
イーサネットあるいは IEEE802.3(本当は少し違いがありますが、本書では触れません) には複数の種類
があります。また、本来の TCP/IP での階層ではデータリンク層までが一つになっているので、その上で
の規格であり、そのためにデータリンク層での通信方式もイーサネットでは決められていますが、ここで
はその物理層としての側面でのみ見てみることにします。
初期のイーサネットは一本の同軸ケーブルを共有するものでした。そのために、それを利用するプロト
コルである TCP/IP には共有ネットワーク (シェアードネットワーク) の考え方が色濃く、それは今も同じ
なのです ( それを取り巻く技術は変化しているために、実際には同じであって、同じでないという面白い
状況でもあります)。そのような訳ですので、イーサネットの古い規格を理解しておくことは重要ですし、
未だにネットワーク図は共有型で書かれていたりします。
初期のイーサネットの速度は 10Mbps でした。そして、この速度に対して利用するケーブルによって種
類が分かれていました。
種類
表 8.1: イーサネットの種類
ケーブルタイプ
ケーブル名称
10BASE-5
太い (1cm) 同軸ケーブル
イエローケーブル
10BASE-2
細い (5mm) 同軸ケーブル
RG-58
10BASE-T
撚対線
UTP (シールド無しの撚り対線)
10BASE-5 と 10BASE-2 は同じ同軸のケーブル (テレビなどに利用される同軸ケーブルと構造は同じで
抵抗値が違うもの) で、太さが違うだけですが、直径で 2 倍も違うと敷設の際の手間が大きく違います (太
いと曲げにくい)。こうした同軸のケーブルは外部からのノイズに対する対策としてシールドがされており、
通常は金属の線で編み組まれたもので中心の芯線が電磁波的に保護されています。
同軸の名称は芯線、シールド、外側のジャケットが一つの中心を有していることから来ています。初期
においては、ノイズに非常に強いことが必要であったためにこのような同軸ケーブルが利用されました。
第8章
122
TCP/IP の基礎 2 — 階層
同軸ケーブルを用いたネットワークは、簡単に言えば、一本の銅線を共有していたと言えます。そのた
めに、この銅線をネットワークにつながった端末から利用するためには工夫が必要でした。この点につい
てはデータリンク層の所でもう一度解説することにします。
こうした同軸ケーブルを用いたネットワークでは、初期の敷設やその後のネットワーク変更が難しかっ
たのですが、その後 UTP ケーブル (Unshealded Twist Pair cable) が登場します。ネットワークで利用す
る UTP ケーブルは品質などの点で、満たすべき規格があり、利用するイーサネットによって以下のように
なっています。
種類
表 8.2: UTP ケーブルの種類
スピード
ケーブル規格
10BASE-T
10Mbps
カテゴリー 3 以上 (Cat.3)
100BASE-TP
100Mbps
カテゴリー 5 以上 (Cat.5)
1000BASE-T
1000Mbps
拡張カテゴリー 5 以上 (enhanced Cat.5)
これらの規格の中身については通常知る必要はありませんが、現在利用しているケーブルがどの規格な
のかは良く知っておく必要があります。簡単には、100Base ではカテゴリー 3 のケーブルを使ってはいけ
ないのです。もちろん、この場合使うと罰せられるというのではなく、100Mbps の速度が全く保証されず、
大きな速度低下やその他様々なトラブルに巻き込まれることになるということです。ケーブルの規格は、
ケーブルに必ず書かれていますから、良く注意して見ておきましょう。また、既に敷設されたケーブルも
良く把握しておかなければなりません。今後、新しく敷設するのであれば、拡張カテゴリー 5 以上にして
おけば良いでしょう。
8.1.2
UTP5
この UTP ケーブルの構造は以下のようになっており、2 本の銅線が一つに撚り合わせられ、4 対が入って
いるので、合計 8 本の銅線で構成されます (Cat.5 以上では 4 対が更に撚り合わせられています)。100BASE
以下では、通信に用いられるのは 4 本までで、1 対を送信に、1 対を受信に用います。一方、1000BASE で
は 8 本全部を送受信に用いています1 。
さて、このような事を何故長々と話すのかと言うと、 ネットワークでのトラブルが、ケーブルとその配
線に起因することが非常に多いからです (経験的には 5 割以上がそうです)。特に、UTP ケーブルが主流の
現在では UTP ケーブルにまつわる問題をきちんと把握しておくことが必要で、そのために原理を知るこ
とが必要なのです。
先に、同軸ケーブルがシールドされている事に触れましたが、 UTP ケーブルはその名の通り、アンシー
ルド (Unshealded)、つまりシールドされていません。では、どうやってシールドされていないのに大丈夫
なのでしょうか。実は、２本の銅線を撚り合わせている事に秘密があり、２つの点で効果があるようになっ
ています。
一つは、平衡型と呼ばれる手法によって、外部のノイズに強くなっています。一本の銅線にはプラスの
信号を流し、もう一方の対になった銅線には同じ信号をただしマイナスで同時に流します。この状態で、
ケーブルの途中でノイズが乗ったとしても、プラス側では例えば 5 が信号で 1 がノイズの効果だと 6 にな
る訳ですが、マイナス側では逆に -5 の信号に 1 のノイズが乗る訳ですので -4 になります。すると、プラ
ス側とマイナス側の差はノイズが乗らない時と同じ 10 の差ですので、結局ノイズの効果を打ち消している
事になります (下図)。とは言え、余りにも大きなノイズが来てしまうと役には立ちませんので、UTP ケー
14
本しか使わず残りを使っていない理由は、初期においては電話線に 4 本を使うことを考えたためです。
8.1. 物理層
123
図 8.1: UTP ケーブルの中身
ブルを大電力が流れる電線の近くや、落雷の恐れがある場所に張ってはいけませんし、大きなビルでは落
雷時に避雷針で受けた電流がアースに落ちるまでの流れ (多くの場合、鉄骨などを流れるように設計されて
いるようです) についても考慮しなければならない時もあるでしょう。
2 つめの工夫は、撚り合わせ自体にあります。これは、一般にクロストークと呼ばれる、近くの通信か
らの影響を軽減することに役立ちます (最も近いのは送信に対する受信側の影響、あるいはその逆)。なぜ
ならば、銅線の中を通過する電気信号は簡単に言えば、電子の流れです。そして、電子が動くとその痕跡
が、まるで船の航跡が作るさざ波のように広がって行くのです (正確には加速度運動に伴います)。これが
電磁波と呼ばれるものです。そして、航行する船の近くを通れば、その波の影響を受けるのと同様に、こ
の電磁波を受けると、近くを流れる電子の流れも乱れます。ところが、先に平衡型では１対の銅線にはプ
ラスとマイナスが同時に流れていると説明しましたが、このプラス側とマイナス側で作られる波は当然逆
になっていますので、うまく打ち消し合うように配置すれば完全に消すのは難しいですが、かなり穏やか
なものになるでしょう2 。このような理由で、銅線は撚られているのですが、当然コネクタ付近では撚りは
ほぐされているので、そこでは距離の差に伴うクロストークが発生します。このために、規格ではほぐす
場合でも 12.5mm 以内 (正確には 0.5 インチ) と規定されています。したがって、自作ケーブルなどでこの
ほぐしが多すぎるものなどは要注意であると言えます。
2 凸の波と凹の波が同じ高さならば打ち消すのと同じで、最近のイヤホンなどにもこれと同じ原理を用いたノイズキャンセル機能
がついています。
第8章
124
TCP/IP の基礎 2 — 階層
babababababababababababababababababababab
図 8.2: UTP ケーブル上の電気信号
(参考)
その他に、芯線自体による違いもあります。芯線が多くの細い銅線からなるもの (より線) をスト
ランデッドと言い、一本の銅線からなるものをソリッドと言います。ストランデッドは柔らかく、
取り扱いが楽ですが、品質的には一本の銅線からなるソリッドタイプの方が上だと言われていま
す。そのために、ストランデッドタイプはラック内などでパッチケーブルとして良く使われてお
り、長距離を引く際にはソリッドタイプが利用されています。
さて、UTP ケーブルと同軸ケーブルの決定的な違いは、送信と受信のラインが分離されていることです。
これによって、まず第一にトポロジー的な問題が生じます（トポロジーは難しい言葉ですが、一筆書きや、
あやとりの糸のようなつながりを数学的に言った言葉だとここでは理解しておけば十分です）。それは、同
軸が同じ線に全てがぶら下がるのに対して、UTP では送信と受信が分離されているために、２台を結ぶ場
合には送信と受信を入れ替えることで対応できるのに対して (図)、３台以上を結ぶことはできないという
点です。もちろん、ループ状にすればできますが、それは UTP ケーブルで結べたとは言えないでしょう。
図 8.3: 送信ラインと受信ライン
8.1. 物理層
125
8
1
babababababababababababababababababababab
図 8.4: RJ-45 プラグ
(参考)
ちなみに、2 台の間を結ぶ際には図のように送信ラインと受信ラインがクロスしているので、ク
ロスケーブルと言います。最近はクロスとストレートを自動で区別するスイッチもあり、その機
能は AUTO-MDI/MDIX と呼ばれています。ただし、これでトラブルが起こると非常に厄介で、
ストレート接続を勝手にクロスと解釈されたりしますので、注意が必要です。
3 台以上を UTP ケーブルを用いて接続する際には、ハブと呼ばれる装置を用います。ハブは当初は共有
型ネットワークの装置でしたが、その後スイッチの登場によって重要な変化がもたらされます。それは、送
信と受信がケーブルのみならず、スイッチを含む通信路全体で分離されたことです。これによって、共有
型ネットワークでありながら、１対１の通信に関しては占有型に近い形態へとネットワークは変化したの
です。
最後に、UTP ケーブルの両端には、RJ-45 というプラグをつけます (図 8.4)。RJ-45 には 8 個の電極と
なる金属ブレードがあり、UTP ケーブルの 8 本の芯線はこのブレードに圧着によって接続されるように
なっています。
それぞれのケーブルのカラーと役割は 10,100Base では以下のように決められています (TIA/EIA-568B)。
なお、1000BaseT では、8 本全部を送受信に使うので、全てがきちんと結線されていなければいけませ
んので、注意して下さい。ストレートケーブルでは両端が共にこの配列になっています。
第8章
126
TCP/IP の基礎 2 — 階層
表 8.3: UTP ケーブルのカラーと役割
ピン番号 役割
カラー
1
送信 (+)
White( pair of Orange )
2
送信 (-)
Orange
3
受信 (+)
White( pair of Green )
4
None
Blue
5
None
White( pair of Blue )
6
受信 (-)
Green
7
None
White( pair of Brown )
8
None
Brown
babababababababababababababababababababab
(参考)
TIA/EIA-568A のカラーコードでは、 Green pair と Orange pair が交換されます。一方の端子
を TIA/EIA-568B、もう一方の端子を TIA/EIA-568A としたものをクロスケーブルと呼び、コ
ンピュータ間やハブ同士を直接接続する際に利用します。
なお、標準規格は A の方で、B の方は別名 AT&T 規格とも言われています3。実際にケーブルを自作し
てみるとわかりますが、TIA/EIA-568B の方がストレートが作りやすい規格になっています。ケーブルの
自作で注意するべきは、緑のペアが青のペアをまたいでいる点にあります。それ以外は全てペアが隣に並
んでいるので、この部分をしっかりと作るのが最大のコツだと言えます。筆者のお勧めの方法は、まず緑
ペアのみをほぐして、緑が青をまたぐ部分のみを先に作り (図参照)、後は順番にほぐしていく方法です。
8.1.3
光メディア
光での通信は電磁波ノイズに非常に強いという特徴がありますが、その一方で特有の問題もあります。
まず、光を用いた規格にはたとえば以下のようなものがあります。
種類
表 8.4: 光ケーブルの規格
スピード
ケーブル規格
最大伝送距離
100BASE-FX
100Mbps
マルチ, シングルモード
412,2000,20000m
1000BASE-SX
1000Mbps
マルチモード
550m
1000BASE-LX
1000Mbps
シングルモード
5Km
光ファイバケーブルは、いずれの場合でもコアと呼ばれる光が伝播する部分と、その周囲を覆うクラッ
ドと呼ばれる部分からできています。
ここで、100BaseFX は 100BaseTX と媒体が違うだけのものです。一方、1000Base においては、SX と
LX などが規定されています。本来、SX と LX は利用する光の波長の違いだけなのですが、SX では光の波
3
AT&T が後から規格に押し込んだと言われています
8.1. 物理層
127
図 8.5: UTP ケーブルの作り方
図 8.6: 光ファイバケーブルの構造
第8章
128
TCP/IP の基礎 2 — 階層
図 8.7: ステップインデックス
図 8.8: グレーデッドインデックス
長が短いために、マルチモードと呼ばれる光ファイバーケーブルしか利用できません。一方、LX はそれよ
りも長い波長の光を用い、原理的にはマルチモード光ファイバーケーブルも使えますが (この場合には最大
伝送距離は 550m になります)、あまり意味はないでしょう。この光ケーブルの違いは、光が走るコアと呼
ばれる中心にある媒体の径の太さにあります。そして、径が太いものは光が屈折のために色々なモードが
混じることが避けられないためにマルチモードと呼ばれており、伝送到達距離は 550m と短くなりますが、
プラスチックなどを使って作ることができるために安価で、折り曲げなどに強いという性質があります。
現在ではあまり使われていませんが、ステップインデックスというタイプの光ケーブルもありました (音
声やビデオの短距離伝送に使われています)。
このような光ケーブルでは、図のように光はコアとクラッドの境界部分で、反射することによって伝播
するタイプですが、原理的に直線的に進むものと、反射して進むものでは道のりが異なるために (反射す
ると長い距離を走ることになる)、出口で光の位相がずれてしまい (光も波の一種なので、道のりが異なる
と、波の山や谷の位置がずれてしまう)、伝送品質が非常に悪くなってしまいます。
このような問題を解決したのが、グレーデッドインデックスと呼ばれる光ファイバーで、マルチモード
で使われる光ケーブルは現在では全てこれが使われています。
グレーデッドインデックスでは、コアの中心から離れるにしたがって徐々に屈折率を変えて作ってあり、
このために光は中心から離れていくものはゆっくりと曲げられて、再び中心を通る軌道へと戻るようになっ
ています。さらに、こうした物質中での光の速度は屈折率によって異なるので、それを利用して、遠回り
した光は早く進み、中心を直線的に進んだ光が少し遅く進むことで、二つの経路による位相のずれを非常
に小さく抑えています。このことによって、マルチモードはステップインデックスに対して伝送距離が長
くなり、接合など取り扱いが楽なケーブルになっていますが、ある程度の損失はやはりあるために、長距
離には利用できません。
いずれにせよ、マルチモードのモードは光が走る経路のことであり、多くのモードが伝送に関与すると
いう意味で、マルチモードと呼ばれています。
マルチモードのケーブルとしては、ガラス製では、コア径が、50µm のものと 62.5µm のものが使われてい
8.1. 物理層
129
ます。プラスチック製では、コア径 120µm が利用されています。一方、光の波長としては、1000BASE-SX
では 850nm の波長の光が利用されています。
径の細いシングルモード光ファイバーは物理的に一つのモードの光のみを伝達するために、非常に損失
が少なく、超長距離の伝送が可能になっています。これは極微の世界の物理法則について勉強しないと中々
理解しづらいのですが、言わばコアの径の太さが光の粒子の大きさぎりぎりに作ってあるために、反射も
せずに、真っ直ぐ進むのだと思えば良いでしょう。つまり、反射できないので、単一の経路を進んだ光し
かないという意味で、シングルモードと言います。。1000BaseLX は規格上は 5Km となっていますが、シ
ングルモード光ファイバー自体は数十 Km の到達も可能になっています。しかし、材質的にはガラスのた
めに、折り曲げに非常に弱く、取り扱いが難しいと言われています。シングルモードファイバーのコア径
は大体 10µm で、1310nm 程度の波長の光を利用しています (FTTH ではこれが用いられています)。
babababababababababababababababababababab
また、光を用いた 10G などの規格も実用化されつつあります。
(参考) 長さの単位
µm マイクロメートル
ナノメートル
nm
8.1.4
10−6 m = 0.001mm
10−9 m = 1000 µm
その他の規格
• FDDI
主に光を用いた 100M の規格で、通常はリング状にネットワークを構成し、トークンパッシングをア
クセス制御に用いていた。100Base の登場以前では、基幹ネットワークに多く採用された。
• ATM
電話交換技術から発展した技術で、パケットは固定長の非常に小さなものに分割し、電話と同じよう
に予め相手との回線を仮想的に作成してから、通信を行うために、効率的な転送が可能であるとさ
れた。
• 10G Base
ギガビットでの転送が端末にまで下りてくると、当然基幹ラインはそれ以上のスピードが要求され
る。これに対応した規格が 10G で、既に製品も出ているが、まだまだ高価である。
第8章
130
8.2
TCP/IP の基礎 2 — 階層
データリンク層
最初に述べたように、データリンク層は最低限の通信を保証するものです。ここで最低限とは、簡単に
言えば、直接銅線などで結ばれたマシン間の通信のような場合を言います。逆に言えば、インターネット
のような世界中の任意のマシン間の通信は、最低限の通信では実現できない訳です。
8.2.1
MAC アドレス
通信においてまず必要な事は相手を知ることです。例えば、電話では相手の電話番号を知っていなけれ
ばいけません。電話番号は電話帳で調べたり、相手から直接教えて貰ったりします。データリンク層で、こ
の電話番号に相当するものは MAC アドレス (Ethernet アドレス) です。MAC アドレスは、48bit(6byte)
の大きさを持ち、通常ハードウェアに番号が書き込まれています（例えばインターフェースカードに）。
もちろん、電話番号と同じように同じ番号があっては困りますので、この MAC アドレスは世界中で唯一
な番号であることが保証されています。では、どうやって唯一であるようにしているのかと言うと、上位
24bit(3byte) がベンダーに付与され、下位 24bit はベンダーが個々に製品を管理し、唯一な番号になるよう
にして出荷しています。これらのベンダーアドレスは以下の場所で調べることができます。
http://www.iana.org/assignments/ethernet-numbers
いくつのベンダーアドレスの例を下に挙げます。
表 8.5: ベンダーアドレス
アドレス ベンダー
00000C
00000E
Cisco
Fujitsu
000093
Proteon
00AA00
080002
Intel
3Com (Formerly Bridge)
080009
080020
Hewlett-Packard
Sun Microsystems
babababababababababababababababababababab
また、Intel などいくつかのベンダーは複数のベンダーアドレスを取得しています。
(参考)
MAC アドレスを元にしてある程度ベンダーが絞れるので、障害時に参考になる場合があります。
また、MAC アドレスの上位 3byte からベンダーをサーチするようなページもあります。
http://standards.ieee.org/develop/regauth/oui/public.html
MAC アドレスは通常 16 進表記で、8bit づつに区切って表記します。
00:00:39:00:2f:04
8.2. データリンク層
131
Unix では、ifconfig コマンドなどでインターフェース情報を取得でき、そこに MAC アドレスなども表
示されるようになっています。
BSD 系では以下のようになります。
> ifconfig
fxp0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=3<rxcsum,txcsum>
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:90:27:50:fa:1c
media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
Windows などでもインターフェースの詳細表示か、ipconfig コマンドなどで表示されます。
ちなみに、MAC アドレスを設定するのはあくまでも OS の役割です。インターフェースカードなどにそ
の情報があっても、MAC アドレスを故意に書き換えることができますので、 MAC アドレスを以って個体
の識別に用いる場合過信は禁物です。
さらに、ベンダーアドレスなどとは別に特別なアドレスを示すために、特別に決められた MAC アドレ
スもあります。
表 8.6: 特別な MAC アドレス
01:00:5E:00:00:00
Internet Multicast [RFC1112]
01:80:C2:00:00:00
09:00:4E:00:00:02
Spanning tree (for bridges)
Novell IPX
CF:00:00:00:00:00
Ethernet Configuration Test protocol
(Loopback)
FF:FF:FF:FF:FF:FF
IP (e.g. RWHOD via UDP) as needed
FF:FF:FF:FF:FF:FF
FF:FF:FF:FF:FF:FF
ARP (for IP and CHAOS) as needed
EtherTalk
なお、MAC アドレスだけではなく、ヘッダの TYPE field という領域にも、それぞれの役割の区別のた
めのコードが記されるようになっていますので、最後の３つのように同じ MAC アドレスであっても区別
babababababababababababababababababababab
がつくようになっています。
(参考)
上の例のうち、4 つはマルチキャストと呼ばれるもので、下の三つはブロードキャストと言うもの
です。通常、ブロードキャストはネットワーク全体に対して送られるもので、 0 をここ、1 を全
ての意味に使う習慣になっていることから、MAC アドレスの全ての bit を 1 にしたものが Ether
ブロードキャストアドレスとして使われます。
第8章
132
TCP/IP の基礎 2 — 階層
図 8.9: バス共有型ネットワーク
8.2.2
CSMA/CD
物理層では Ethernet の物理的な側面について述べましたが、ここでは上位の層に関連する部分について
取り出しましょう。特にここで重要なのは、Ethernet は同じ銅線を共有するという、共有型のネットワー
クであるという点です。したがって、その通信のための仕組みも共有型を前提にして考えられています。
共有されたネットワーク上で、通信を確実に行うための通信モデルの一つが CSMA/CD 方式です (Carrier
Sense Multiple Access with Collision Detection)。Ethernet は CSMA/CD を採用しています。CSMA/CD
は簡単に言えば、井戸端会議方式だと言えます。つまり、みんなでワイワイガヤガヤと話をするような方
式なのです。しかし、そうは言っても、二人が同時に喋ると何を言っているのか良くわからなくなります。
したがって、あるルールを定めています。そのルールを簡単にまとめると、下のようになります。
• 誰かが話しているかどうか、常に聞き耳を立てる。
• 静かであれば、話す。
• もし、誰かと会話がぶつかったら、黙る。
• 一定時間黙って、静かであれば話す。
ここで、ネットワーク上で聞き耳を立てるというのは、全てのパケットを監視するという意味です (Carrier
Sense)。会話がぶつかるという例えは、Ethernet では信号が衝突して (Collision Detection) 理解できない
ような信号になることを指します (磁波を使うと波なので重ね合わさってしまうのです)。共有型ですから、
監視をすることも、監視をしていれば衝突したかどうかもわかりますね。最後に、一定時間黙る場合に、衝
突をした相手と同じ時間だけ黙ったのでは、もしかすると再び衝突するかも知れません。そこで、衝突回避
の確率を高めるために、黙る時間は一定の範囲内で乱数で決めます。もちろん、それでも衝突する場合は
ありますので、その場合にはさらに長い時間沈黙した上で、話そうとします。ちなみに、Multiple Access
とは、このように誰が優先でもなく、平等にアクセス権限を持っていることを意味しています。
このように、CSMA/CD 方式では衝突を避けることはできず、衝突後いかにうまく回避するかというこ
とに重点をおいています。したがって、うまく回避できないほど混み合って来ると、必然的に通信効率が落
ちていきます。これは簡単には、いくら通信しようとしても必ず誰かが話しているし、うまく割り込んで
も必ず衝突が起こってしまうような状況になると考えれば良いでしょう。このように、元々の Ethernet で
は通信効率は 30%程度が良いところで、通信量が帯域の 50%前後を越えると極端に効率が悪くなることが
知られていました。ところが、ツイストペアケーブルとスイッチによる、全二重で衝突のないネットワー
クが実現することで、帯域は一気に理論限界に迫るようになったのです。
8.2. データリンク層
8.2.3
133
トークンパッシング
CSMA/CD 方式に対して、円卓会議方式とも言うべき通信モデルです。主に、TokenRing や FDDI な
どのネットワークで用いられました。CDMA/CD は誰もが勝手に喋れるために衝突が防げないのですか
ら、優先権を設定したのがトークンパッシング方式です。各ノードはトークン (発言権) が回ってくるまで
黙っています (もちろん、通信したいデータはその間に貯めています）。トークンが回ってくると、自分宛
の通信を全てそこから取り出し、代わりに自分が通信したいデータをそこに詰め込みます。作業が終わる
と、次のノードにトークンを渡します。
このようにして、トークンが来ない限り発言しないために、本質的に衝突はありません。CSMA/CD 方
式では、通信量がある程度を越えるといきなり落ちるのに対して、トークンパッシングではそのような急
激な落ち込みは防げています。もちろん、トークンパッシングと言えども、通信量が多くなると、トーク
ンが回ってきたときの処理に時間がかかるようになり、相対的にネットワークが使われていない時間が増
えるために、通信効率は下がります。
一般に、トークンの受け渡し方法さえ規定していれば色々なネットワークで使える方式ですが、もっと
も使われたのは実装が簡単なリング状のネットワークで、隣から隣にトークンを渡すという形で利用され
ていました。
トークンパッシングは理論的にも実際にもなかなか優れた方式で、100M Ether が普及する以前の基幹
ネットワークを担っていましたが、100M Ether や、その直ぐ後に登場する Gigabit Ether によって、早々
と退場せざるを得ませんでした。
8.2.4
ARP
MAC アドレスの節で述べたように、MAC アドレスがわかれば最低限の通信は可能になります。した
がって、ここでのポイントは MAC アドレスをどうやって知るかという点にあります。ところが、先に学
習したように、一つのネットワークセグメント上の MAC アドレスには系統性がありません。実際、ベン
ダーアドレスは、ベンダーが違えば異なるのですから、ばらばらに導入されたネットワークカードには何
の系統性もない MAC アドレスが振られていることになります。もちろん、人間が手で MAC アドレスを
登録することも考えられますが、あまりにも手間がかかりすぎます。ここでの問題は、自動的に登録する
点にあるのです。
このように、自動的に相手の MAC アドレスを取得するためのプロトコルが ARP( Address Resolution
Protocol) です。ARP は正確にはネットワーク層とデータリンク層にまたがったプロトコルであると言え
ます (そういう階層分類をしているからです)。
さて、この ARP でポイントになるのは、Ethernet の物理的な特徴です。それは、相手は同じ銅線につ
ながっている点にあります。ですから、叫べば、相手がそこにいれば必ず届くと考えて良いのです。ネッ
トワーク上で「叫ぶ」に相当するのが、先に出てきたブロードキャストです。ブロードキャストを受け取っ
た相手は、自分の MAC アドレスを発信先に知らせるのです。非常に単純ですが、大事な点は、世界中に
対して叫ぶ訳にはいかないという点です。叫んでも良いという考え方は、逆に言えば、そうしても大して
迷惑にはならないということを前提としているからです。つまり、ブロードキャストは局地的であり、狭
い限定されたネットワークにのみ伝達されなければならない訳です。これが、より高次のネットワーク通
信階層が必要な理由なのです。
同時に、ここまで、「発信元」とか「相手」という言葉で説明してきましたが、何を以って「相手」とす
るのでしょうか (ARP で解決する前です)、また、どうやってその「相手」は同じネットワーク上に存在す
ると考えるのでしょうか。この疑問に答えるには実は IP が必要です。最初に、ネットワーク層にまたがっ
134
第8章
TCP/IP の基礎 2 — 階層
ていると言いましたが、この場合の相手とは、相手の IP のことを意味します。また、この IP を使って、
自分が通信相手と同じネットワークにいるかどうかを判断できるようになっているのです。
このようにして、ARP で解決された MAC アドレスは、その対となる IP アドレスと共にキャッシュに
記憶されます。キャッシュはある一定時間ごとにクリアされるようになっています。そうしなければ、ネッ
トワークから取り外されたノードを認識できなくなってしまうからです。キャッシュにある ARP テーブル
は Unix でも、Windows でも arp コマンドで知ることができます。
> arp -a -n
? (192.168.24.1) at 00:00:87:bf:44:65 [ether] on eth0
? (192.168.24.254) at <不完全> on eth0
? (192.168.24.87) at 00:1f:16:1b:1e:5c [ether] on eth0
ここでオプション -a は ARP テーブルを表示するオプションで、-n は IP アドレスを番号で表示するオ
プションです。Windows のコマンドでは -n オプションはありませんので、注意してください。ARP に
よって、MAC アドレスが取得できなかった場合には以下のような行が表示されます。
%BSD での表示
? (10.16.164.10) at (incomplete) on fxp0 [ethernet]
このような場合には、相手がつながっていない、またはケーブル、インターフェースにトラブルがある、
相手が IP を取得できていない、もしくは相手の持つ IP に関係する情報に間違いがある等の理由が考えら
れます。
なお、ARP は通信しようとする際に、同一セグメントである場合に発せられるものですので、相手が同
一セグメントにいないと思われる場合 (どうやって判定するかは別の章で述べます) には発せられません。
単純に、相手が存在するかどうかを調べるには、ping wo を利用すると良いでしょう。ping は、相手の
IP アドレスに対して発せられ、通常の場合 OS はそれに対して返事を返しますので、相手が生きているか
否かや、相手まで到達できるかどうかを調べたいときに利用されます (OS によっては、フィルタなどで意
図的に落としている場合もあります)。
$ ping 192.168.24.1
PING 192.168.24.1 (192.168.24.1) 56(84) bytes of data.
64 bytes from 192.168.24.1: icmp_seq=1 ttl=64 time=1.17 ms
64 bytes from 192.168.24.1: icmp_seq=2 ttl=64 time=0.920 ms
64 bytes from 192.168.24.1: icmp_seq=3 ttl=64 time=0.775 ms
64 bytes from 192.168.24.1: icmp_seq=4 ttl=64 time=0.788 ms
^C
--- 192.168.24.1 ping statistics --4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.775/0.915/1.178/0.163 ms
(終了は、Ctrl + C を押します。)
当然、相手が同一セグメントにあれば、ARP が発せられます。
8.3. ネットワーク層
135
IP:
Rx
MAC: rx
ƒ‹ [ ƒ^
IP:
Ry
MAC: r y
Host: Anon
IP:
A
MAC: a
Host: Blue
IP:
B
MAC: b
図 8.10: セグメント間通信
8.3
ネットワーク層
前の節では同じネットワークセグメント内部での通信が可能になることを見てきましたが、セグメント
を越えた異なるネットワーク間の通信はこのネットワーク層で保証されます。
8.3.1
セグメント間通信
セグメントを越えた通信は IP アドレスと MAC アドレスの両方をうまく使うことで成り立っています。
IP アドレスについては次の節で詳しく説明しますが、ここでは IP アドレスはインターネット上の唯一性
を保証するアドレスであるというだけの前提で解説をします。
ホスト Anon は図のように、IP アドレス A ,MAC アドレス a を持ち、ホスト Blue ( IP B, MAC b )
と通信しようとしているとします。ただし、ホスト Anon の属するセグメントとホスト Blue の属するセ
グメントは異なっていますが、Router を介してつながっているとします。
この状況で、まずホスト Annon は、自身の IP A と相手の IP B を比較し、同じセグメントにないこと
を発見します（IP のどこを見れば同じセグメントか否かがわかるかはつぎの節で解説します）。すると、
ホスト Annon は、直接通信はできないので、Router(IP Rx) に中継を頼むことにします。ここで、ホスト
Annon は、中継をしてくれる Router (IP Rx) は最初から知っているとします (実際の設定でも、静的に設
定することもありますし、半動的に DHCP などで設定ファイルが書かれる場合もあります。もちろん、さ
らに進んで常に動的に決定される場合もあります）。そこで、Router の IP Rx を自身の IP A と比較して、
同じセグメントであることを発見すると、Router 宛に Blue 宛の通信パケットを送ります。この際に、ま
ず、ARP を用いて、Router の MAC アドレス rx を取得し、データパケットのヘッダとして、宛先 IP ア
ドレスは Blue の B であるにもかかわらず、宛先 MAC アドレスとしては Router の MAC アドレス rx を
指定して、パケットを送り出します。当然、Router は自身宛の MAC アドレスが宛先に書いてある訳です
から、このパケットを受け取って、データリンク層からネットワーク層に送ります。Router のネットワー
第8章
136
TCP/IP の基礎 2 — 階層
ク層では、自分宛ではなく、ホスト Blue (IP B) であることを発見しますが、中継をするように設定され
た Router は親切にも、自身の内部にある表 (ルーティングテーブルという) を検索し、Blue が自分のイン
ターフェースの先にあることを発見し (同じセグメント)、ARP を用いて相手先の MAC アドレス b を解
決して、ホスト Blue 宛にパケットを送り出し、これによってめでたく、ホスト Annon から ホスト Blue
宛のパケットが到着した訳です。
このようにして、中継機能をもったマシンを一般にルータと呼んでいます。ルータは、中継機能を持っ
ていれば良く、専用ルータである場合もあれば、通常の Unix やあるいは Windows である場合もあります
(最近の Windows2000 や XP には中継機能が実装されています）。この中継自体は IP フォワーディング
(IP forwarding) と呼ばれ、どの方向に向かって送り出すかを予め決定することをルーティング (経路制
御) と言います。今の例では、ルータは Router で、２つのインターフェースを持つだけ (足が２つという
言い方をします) でしたが、たくさんの足があっても構いません。また、上記のメカニズムによれば、ルー
ティングテーブルさえ正しく管理されていれば、インターネット上のどこにでもパケットは正しく届く筈
です。つまり、実は重要なのはこのルーティングテーブルだと言う事になりますが、これを正しく保つの
は中々大変なことで、自動的なツールを使っても設定間違いでネットワークの一部が止まることが今でも
時々あります。
Unix 上でも Windows 上でも、ルーティングテーブルを見るには以下のようにします (表示は違います
が、コマンドは同じです)。
%BSD での表示
> netstat -rn
Routing tables
Internet:
Destination
default
Gateway
192.168.24.1
192.168.23.5/24
192.168.24.4
192.168.24.5
192.168.24.1
Flags
UGSc
Refs
4
Use
68
Netif Expire
nge0
link#1
UC
00:00:39:00:00:01 UHLW
3
1
0
25675
nge0
nge0
1121
00:90:cc:01:c0:11 UHLW
00:00:0c:02:d0:21 UHLW
6
5
402346
3
lo0
nge0
418
127.0.0.1
127.0.0.1
UH
5
448
lo0
上で表示をしているマシンは Unix ですが、単なるクライアントですので、多くの足を持っている訳ではな
く、単純に先の例と同じく、同一セグメント以外のホストに対しては、Ubuntsu では 2 行目の 0.0.0.0 の行の
ゲートウェイの欄にある 192.168.23.1 に、 BSD 系では一行目の default の次の列にある 192.168.24.1
に全てのパケットを中継して貰うように設定されています。
8.3.2
IP アドレス
最初に説明したようにインターネット上の住所は数で表現されています。そして、この IP アドレスは
IPv4 では、32bit の長さを持っています。
通常、IPv4 では IP アドレスを 8bit ごとに区切り、十進数で表記します。 8bit のデータは負の数を入
れなければ、0∼255 までの 256 通りの数を表現できるので、IPv4 のアドレスはつぎのように書かれるこ
とになります。
8.3. ネットワーク層
137
0∼255.0∼255.0∼255.0∼255
たとえば、202.11.100.1 のように書く訳です。
では、この 32bit はどの位の大きさかと言うと、2bit では 00,01,10,11 (二進数表現) の 4 通りの数が表
せることから分かるように 22 です。従って、32bit では、232 通りの数が表せます。これは一体どの程度の
大きさなのでしょうか。
232
= 22 (210 ) 3
≃ 4 × 10003
= 4 × 109 = 40 億
(ここで、210 = 1024 なので、大体 1000 として計算している。)
つまり、世界人口よりも少ないのである。もちろん、インターネットの始まりにおいてはこれは十分大
きな数であると思われた訳であるが、今となってはいかにも小さい数である。更に、問題なのは IP アドレ
スの構造のために、この 40 億余りのアドレスにはかなりの無駄がある上に、IP アドレスのほとんどをア
メリカが独占しているという問題があります。下の表は国別の IPv4 アドレス割り当てリストです。ここで
は上記の無駄のために、IP アドレスの残りはもうあまりなく、ほとんどが割り当てられてしまっている状
態の中でアメリカの突出ぶりと、最下位のランクにも登場しない国もまだまだあるという点、それらの最
低のランクでは 256 個の IP すらないというのが現実なのです。
第8章
138
TCP/IP の基礎 2 — 階層
表 8.7: IPv4 アドレス国別割り当てランキング (2003 年 4 月 7 日現在)
順位
CC
国名
合計 IP 数
割合
1
2
US
JP
アメリカ
1,246,274,560
103,830,016
66.90%
5.57%
3
4
CA
GB
カナダ
62,013,952
50,894,080
3.33%
2.73%
5
6
DE
FR
ドイツ
フランス
48,699,648
37,210,112
2.61%
2.00%
7
CN
中国
30,719,744
1.65%
1,024
256
0.00%
0.00%
0.00%
0.00%
日本
イギリス
中略
169
173
SR
BZ
スリナム
173
173
GD
NE
グレナダ
ニジェール
256
256
173
SZ
スワジランド
256
0.00%
173
TO
トンガ
256
345,088
0.00%
0.02%
1,858,318,336
100.00%
ベリーズ
判定不能
合計
サイバーエリアリサーチ株式会社提供データより
一方、5 年後の 2008 年 10 月 1 日の NIC からのデータ調査では以下のようになっています。
表 8.8: IPv4 アドレス国別割り当てランキング (2008 年 10 月 1 日現在)
順位
国名
合計 IP 数
割合
1
US
1,445,547,776
52.24%
2
3
中国
日本
167,045,888
149,272,064
6.15%
5.49%
4
5
EU
イギリス
120,298,556
86,213,976
4.43%
3.17%
6
7
ドイツ
78,563,888
73,655,552
2.89%
2.71%
カナダ
このように、中国がほんの数年の間に 1 億以上の IP アドレスを持って接続していることがわかります
が、まだアジアでもインドは IT 先進国であるにもかかわらず、上位 7 位にも入っていません。実際、ここ
数年のうちの調査で、IPv4 アドレスの枯渇は現実的なものとして捉えられており、日本でも 2012 年ぐら
いには完全に IPv4 アドレスがなくなるものと見られています。日本の JPNIC(IP アドレスを管理してい
る日本の団体) では既に「IPv4 アドレス枯渇に向けた提言」という文書を出しており、IPv4 がなくなるそ
の日が目前に迫っていること、そのために IPv6 への移行を準備することを勧告しています。
ちなみに、IPv6 ではどの程度の IP アドレスを用意しているかというと、IP アドレスの長さとしては
128bit を用意しています。このため、IPv4 アドレスの大きさを 4 乗した大きさになるので、先と同じよう
に計算すると、以下のようになります。
8.3. ネットワーク層
139
2128
= (232 )4
≃ (4 × 109 )4
= 256 × 1036
ただし、さすがにこれだけの大きさになると、IPv4 の時とは違い、1000 と 1024 の違いが大きくなり、
256 ではなく 340 ほどに膨らみます。それはさておき、注目すべきは 0 が 36 個も続く数であるという点
です (ちなみに日本語ではちゃんと読み方があって、340 澗 (カン) というのだそうですが、あまり実感は湧
きませんね)。真偽のほどは確かではありませんが、無駄になる部分を見積もった上で、地球の全表面積で
この大きさを割っても、1m2 当たり数千個の IP アドレスがあるという試算もあるそうです。これだけの数
があるために、ありとあらゆる機器に全て IP を振るとう話が出ています。洗濯機や冷蔵庫、テレビや AV
機器は言うに及ばず、冷蔵庫に入れる食品にまで全て IP を振ってしまおうと言うのです。技術的には、非
常に小さな大きさのチップとアンテナに、無線でエネルギーを与えると自動的に自分の ID(RFID) を返す
ようなものが既に安価に製作できるようになってきているために、食品の製造元や流通過程、スーパーで
のレジなど全ての過程を追跡するようなことが考えられています。こうした仕組みはある意味では便利か
も知れませんが、知らない内に自分の居場所や、持ち物など全てが筒抜けになるために、どのように IP を
使うのかという問題も広く社会との関係で今後考えなければならない問題でしょう。
8.3.3
IP アドレスの階層
データリンク層や、この節のセグメント間の通信で出てきたように、IP アドレスの中にセグメントを区
別するための仕組みが入っています。これは一般的に考えると、住所構造という問題として考えられます。
たとえば、私たちが通常使っている住所の構造は、木のように枝分かれしていくような構造を持っていま
す。こうした仕組みは大量のデータを分類する上では非常に優れた方法です。実際、このような構造は情
報科学では、ツリー構造として知られており、近代的な OS ではファイルシステムに使われていますし、後
に紹介する DNS と呼ばれるインターネット上の名前の構造でも利用されています。このように優れた方法
ではありますが、当然それを処理するにはある程度のコストが必要となるために、IP アドレスのようなパ
ケットの配送過程で何度も参照されるようなものに大量に導入すると処理上の問題も出てくるので、IPv4
では非常に単純に、2 つの階層のみを導入しています。このような IP アドレスの構造については後の章で
詳しく見ることにしますが、ここではその 2 層の構造は次のようになっていることを知れば十分です。
ネットワーク部
ホスト部
たとえば、202.11.100.1 というアドレスは、202.11.100 がネットワークを表すネットワーク部であ
り、最後の 8bit の 1 がそのネットワークの中の個別のホストを表すホスト部になっているのです。データ
リンク層や、セグメント間通信で出てきた、同じネットワークか否かの判断は、このネットワーク部が同
じであるかどうかによって判断していたという訳なのです。しかし、このネットワーク部が何 bit あるかと
いうと、なかなか面倒な話になっているので、それについては次の章で詳しく説明することにしましょう。
8.3.4
ICMP
ここまでの階層では、パケットがネットワーク上のどこかで失われるようなネットワーク上のトラブル
に対しての保証は一切ありませんでした。別の言い方をするならば、インターネットはその低レベルの階
140
第8章
TCP/IP の基礎 2 — 階層
層においては、そのような高度な機能は用意していないとも言えます。もちろん、そうした機能がないの
は困りますから、必要なのは論を待たないのですが、肝心な点は低レベルではそうした機能を用意してい
なかった点です。つまり、ネットワーク上のトラブルは元々の関心として、より高位の階層で処理しよう
と考えた点にポイントがあるといえます。そういう意味で、ネットワーク層には、パケットが何らかの原
因により消えたり、あるいは消されたりした場合や、あるいはサービスが提供されていなかった場合に対
する、ある種の通知を保証する仕組みが用意されています。これを、ICMP(Internet Control Messaging
Protocol) と言います。ICMP には、従って、インターネットでの通信を保証するためのさまざまな通知シ
ステムが備わっていますが、重要なのはそれを保証するのではなく、保証するための通知システムに過ぎ
ない点です。
ちなみに、先に取り上げた ping は実際には ICMP を利用したツールで、ICMP 自体に通信相手の確認
のためのメッセージが用意されているのでした。
8.4. トランスポート層
8.4
141
トランスポート層
さて、ここまでの階層によってインターネット上の任意のホストはお互いに通信が可能になっています。
では、これで十分なのでしょうか。
8.4.1
サーバ・クライアントモデル
現実のインターネット上のサービスの多くはサーバ・クライアントモデルという手法に従って作られて
います。メイルやウェブなどのサービスもそうしたサービスなのです。このサーバ・クライアントモデル
とは、簡単に言えば、サービスをする側のプログラム (サーバプログラム) と、サービスを受ける側のプロ
グラム (クライアントプログラム) に分かれています。ウェブでは、ウェブサーバ (例えばアパッチ) に対
して、クライアントはブラウザと呼ばれるソフト (たとえば IE や Netscape) です。つまり、ネットワーク
上のサービスにおいて行われる通信は、このようなサーバプログラムとクライアントプログラム間の通信
であり、アプリケーション間の通信であると言えます。そして、今までの段階で与えられているのは、そ
のようなアプリケーションが走っているホストまでの通信が保証されているだけなのであり、アプリケー
ション間の通信はまだ与えられていないことがわかります。それを行うのが、トランスポート層の役割で
babababababababababababababababababababab
ある訳です。
(参考)P2P
サーバ・クライアントモデルに対する新しいモデルが、ピアツウピア (P2P) のモデルです。P2P
では、全てのホストは対等であり、サーバであると同時にクライアントとしての機能を持ってい
ます。したがって、特別なサーバ用のホストは必要としませんが、現在のインターネットの制約
のために、自由に P2P が可能な訳ではない点と、ネットワークに対する負荷が高い点が泣き所
です。
8.4.2
アプリケーション間通信
ホスト間の通信を他のホスト間の通信と区別するには、 2 つのホストの IP アドレスを指定すれば区別す
ることができます。つまり、2 つの IP アドレスを指定したならば、そのホスト間通信がインターネット上
で唯一である訳です。しかし、そのホストの上では様々なアプリケーションが動いているのですから、ホ
ストに届いた通信内容をどのアプリケーションに届けるかという点についての一貫した方法がないと、実
際にはサービスとして成り立ちません。逆に、そうしたアプリケーションの識別は、各ホスト上で独立し
て行えば十分です。なぜならば、IP アドレスを指定したならば、そのホストはインターネット上では唯一
のホストであるのですから。このように、ホストはその上で動くアプリケーションに対して (正確には通信
を行うアプリケーションの通信のための出入り口に対して)、ある番号を与えます。これをポート番号と呼
び、0 以上の整数を用います。
このようにして、あるホストのあるアプリケーションと通信したいならば、そのホストの IP アドレス
と、そのアプリケーションのポート番号を知れば、そのアプリケーションに対して通信パケットを送るこ
とができす。当然、そのアプリケーションまで通信パケットが届けば、そのアプリは逆にそのパケットの情
報から発信者の IP アドレスやポート番号を知ることができますから、逆の通信も可能になります。そこで
第8章
142
TCP/IP の基礎 2 — 階層
問題は、相手の IP アドレスやポート番号をどうやって知るのかということになります。IP アドレスに関し
ては予め調べておくしか方法はありません。一方、ポート番号についても同じようにすることも出来ます
が、通常サーバ・クライアントモデルでは、最初のパケットは必ずクライアントからサーバへと飛ぶので、
サーバのポート番号が分かれば良い事になります。そこで、便利なように、代表的なアプリケーション毎に
ポート番号を決めておくことにしました。これを、Well-Known port address と言います。Unix などでは、
こうしたポート番号とアプリケーションとの対応は /etc/services に書かれています。下に/etc/services の
一部を掲げます。
ftp-data
ftp-data
20/tcp
20/udp
#File Transfer [Default Data]
#File Transfer [Default Data]
ftp
ftp
21/tcp
21/udp
#File Transfer [Control]
#File Transfer [Control]
ssh
telnet
22/tcp
23/tcp
#Secure Shell Login
smtp
...
25/tcp
mail
http
80/tcp
www www-http
#Simple Mail Transfer
#World Wide Web HTTP
babababababababababababababababababababab
(参考)
実は、/etc/services はアプリとポート番号の対応を書いているのではなく、単にポート番号に
http などの名前を与えているだけです。実際に、80 番ポートで本当にウェブサーバが動いてい
るかどうかは分かりません。それを保証するのは、ホストの管理者であり、プログラム自体なの
です。
このようにして、ブラウザは、サーバの IP アドレスがわかったならば、そのサーバのポート 80 番にア
クセスをします。一方、ブラウザの使っているポート番号はそのホストの OS から与えられる適当な番号
です。サーバは最初の通信パケットからブラウザのポート番号がわかるのですから、そのクライアントの
IP アドレスの、そのポート番号に返信を返せば良い訳です。つまり、2 つのホストの IP アドレスと、ポー
ト番号を指定すれば、そのアプリケーション間通信は世界で唯一であり、完全に他のアプリケーション間
通信とは区別されるものであることが保証される訳です。
8.4.3
信頼性のある通信
ここまでの段階でアプリケーション間の通信が可能となった訳ですが、インタネット上での通信におい
ては、パケットが行方不明になったり、壊れる場合もあります。もちろん、ICMP などによってその問題が
わかる場合もありますが、分からないままパケットが消失するようなことも当然考えに入れておかねばな
りません。このような通信の信頼性を保つための仕組みもトランスポート層で提供しています。逆に、そ
うした信頼性が必要ない場合もあるでしょうから、それも提供されています。
信頼性のある通信方式を TCP(Transmission Control Protocol) と言います。TCP では、パケット
の順序性や、欠落を発見するメカニズムが提供されており、二点間の通信に一時的あるいは一部的障害が
あっても、それらによって生じる欠落を埋めたり、あるいは訂正したりする機能があります。一方、こう
8.5. アプリケーション層
143
した信頼性を必要としない通信については UDP(User Datagram Protocol) が用意されています。た
とえば、リアルタイムで映像を送るような場合において、一部的にデータに欠落が生じたとしても、映像
が少し乱れる程度でしょう。そのような場合であっても、いちいち先のデータに欠損があるからといって、
前に戻ってデータを修復されても却ってリアルタイム性を損なうだけで、邪魔なだけです。このような場
合に信頼性には少し欠けるが、出来るだけ早く相手にパケットを送る UDP が使われます。TCP,UDP の詳
細なメカニズムについては、つぎの章で述べることにします。
8.5
アプリケーション層
階層概念的には、最後の一番上にある層がアプリケーション層ですが、この層は TCP/IP で仕組みを提
供しているのではなく、個々のアプリケーションに任されています。つまり、TCP/IP が提供するのはト
ランスポート層までで、その後は直接アプリケーションプログラム自体にデータは渡され、そのアプリの
管轄となります。したがって、アプリ間での通信のやり方自身はアプリの独自の方法によって行われるこ
とになり、アプリごとに色々なプロトコルが存在します。ウェブのデータのやり取りは、HTTP (Hyper
Text Transfer Protocol) というやり方で行われ、メイルの配送は SMTP (Simple Mail Transfer Protocol)
によって行われます。多くのアプリケーションプロトコルは簡単なものですので、代表的なものについて
は後の章で扱うことにします。
145
第 9 章 ルーティング
この章では、ホスト間の通信がどのようにしてなされるのかを簡単に理解します。
9.1
経路制御が必要な理由
ホスト間の通信において、パケットを正しいネットワークに送出し、それが中継されるための制御、つま
りは通信相手までの経路が選択され、最終的にパケットが到着するためのメカニズムを経路制御と呼びま
す (実際にパケットを経路に従って送ることはパケット転送と言います)。経路制御 (routing) が必要な理由
は TCP/IP の構造に根ざしています。ここでは簡単にその理由についてスケッチをして見ます。まず、ホ
スト同士が TCP/IP を用いて通信する場合には、相互のホスト間のネットワークへの接続状態に応じて、
同一ネットに属する場合と、属さない場合によって違いが生じます。以下それぞれの場合について簡単に
説明します。
同じネットワークセグメントに属する場合
同じクラス、又は同じサブネットに属すると IP アドレスから判断出来る場合、発信側はネットワー
クにブロードキャストを流し、必要とする IP に対応する受信側の イーサネット・アドレスを聞き
ます。受信側は同じセグメントに属するのですから、そのブロードキャストを受け取ることが出来、
受け取ると発信側に対して自分の MAC アドレスを報告します（このプロトコルを ARP と言いま
す）。送信側はこれをテーブルに覚えておいて、次からの転送に使用します (一定期間以上経つと捨
てます)。このテーブルは、/usr/sbin/arp コマンドによって参照することができます (arp -a を使い
ます)。以上のようにして、発信側は受信宛へのパケットを送信する事ができる訳です。
一方、ARP の逆に、イーサネット・アドレスから IP アドレスを参照するプロトコルを RARP と
言いますが、これは既に述べたように通信そのものには使われません。
違うネットワークセグメントに属する場合
違うセグメント同士のマシン間の通信では、どういう経路を通るかという情報が必要です。この経路
情報の事をルーティング情報と言い、この情報に基づいて経路選択をする事をルーティングと言い
ます。ルーティングには、あらかじめマシンの設定ファイルに経路情報を設定する静的ルーティング
と、動的にルーティングの情報を流す方法などがあります。いずれの場合でも、相手先の MAC アド
レスは取得出来ないので、代わりにその経路を知っているルータ (ルーティングが出来る機器の事を
ルータと言います。従って、専用機器である場合もありますし、通常のワークステーションである場
合もあります。) を経路情報から取り出し、その MAC アドレスに向かってパケットを流します。パ
ケットを受け取ったルータは自身の持つ経路情報に従って、更に次のルータへパケットを送り出した
り、受信先がルータから直接到達可能な場合は直接受信先へとパケットを送ります。ここで重要な事
は、幾つかのルータを経ないと到達できないような場合でも発信先はその経路全てをあらかじめ知っ
ている必要はない点です。それぞれのルータは、自身が直接到達出来るネットワークへのルーティン
グ情報を持っていれば良いだけなのです。勿論、こうした TCP/IP でのルーティングは最短経路を
第 9 章 ルーティング
146
通る事は保証されていません。また、復路において同じ経路を通るとも限りません。(もっと極論す
るならば、相手に届くか否かは送り出してみなければ分かりません。)
9.2
ルーティングとネットマスク
第２章で説明したように、IP にはクラスという概念が当初ありました。まず、クラスを用いたルーティ
ングについて概略を説明した後、簡単にクラスを用いないルーティングについて説明します。
クラスには、現在の所 A,B,C,D,E の５つがあります。このようなクラスがある理由は、TCP/IP の歴史
の当初において、ルーティングを高速に行なうために少ない情報で判断しようとした所に起源を持ってい
ます。実際、クラス A であるか否かの判断は、IP の最初のビットを見れば分かるからです。以下に、IP
の最初の５ビットとクラスの関係を掲げます。
クラス
先頭のビット
A
0
B
10
C
110
D
1110
E
11110
つまり、クラスの判別を考えるならば、先頭 4 ビットを見ればクラスの判断ができる訳です。クラスの
判断ができたならば、どのネットマスクを適用すれば良いかが分かります。ここでは、仮にクラス C であ
る宛先 IP を考えることにします。この宛先 IP アドレスをネット部分 X とホスト部分 Y に分けて考える
と (X が 3byte、Y が 1byte になっています）。
IP address = X.Y
これに対して、クラス C のネットマスク 255.255.255.0(/24) でマスクします。
dest net address = X.Y & 255.255.255.0
結果の dest net address は、X.0 となります。これで、ネット部分が取り出せたので、後はテーブルと比
較して、どこに送出するかを決定するわけです。
ドメイン内部では、このマスクの情報を自分たちの都合の良いように、個々のルータに覚えさせる事が
できるので、ホスト部分の 4bit をネット部分と考えるような設定をしても構いません。つまり、外部から
はクラス C としてルーティングされてきた IP パケットを、内部では以下のように考え直します。ここで
は、ホスト部分 Y を前半の 4 bit Y1 と後半の 4bit Y2 に分けて、Y1 Y2 と表記します。つまり、
IP address = X.Y 1 Y 2
です。これに対して、通常のクラスフル・ルーティングアルゴリズムを適用した結果は、ネット部が X.0 である
事が分かり、X.0 はサブネットに切っている事を知っているので、改めて 255.255.255.240 (240 = 11110000
binary, /28) が適用されて、
dest net address = X.Y 1 Y 2 & 255.255.255.240
結果の dest net address は、X.Y1 0 となる訳です。後は、クラスフルの場合と同じくテーブルと比較する
ことで送出先が決定されます。
9.3. 静的ルーティング
147
クラスフルとクラスレスのルーティングの最大の違いは上に述べた通りですが、実際にはクラスフルで
あっても、一致するネット部の行き先がない場合にはデフォルトルーティング (0.0.0.0 のマスク、つまり
は/0) を適用します。これに対して、クラスレスルーティングではマスクの長い順にテーブルと比較をし、
一致しなければ順にマスクを短くしてテーブル比較をする訳です。
一方、こうしたルーティングではインターネットの拡大に伴いルーティング・テーブルが肥大化すると
共に、最低でもクラス C での配置となるのでアドレス空間に無駄が生じます。これを短期的に解決する方
策として登場したのが、CIDR(Classless Inter-Domain Routing) です。CIDR では、クラスの概念を廃止
し、アドレスとマスクの対によって実現する方法です。ルーティング情報に関しては、例えば、クラス C
16 個を束ねる場合、そのクラスが 202.11.16 から 202.11.31 までであったとすると、3byte 目 (16∼31) は
2 進法で表記すると、
0001 0000∼0001 1111
となります。そこで、先頭 4bit までをマスクして、
202.11.16.0/20
をネットワークアドレスとして考えます。つまり、202.11.(0001) までをネット部分であると考えるわけで
す。これによって、クラスフル・ルーティングならば 16 個のテーブルを持たなければならなかったのが、
1 個のテーブルで代用できる訳です。勿論、どこかのルータでこれを小分けにしなければなりませんが、中
央のルータに関してだけ言えば、ルーティングテーブルは飛躍的に小さくなります。
次に、アドレス空間ですが、CIDR のようにマスクを一般に採用すれば、従来のようにクラス C のサブ
ネット以上に細かい IP の付与が可能になります（勿論、制約はありますが）。
9.3
静的ルーティング
FreeBSD でルーティングのテーブルを見るには、/usr/bin/netstat コマンドを使います。
# netstat -rn
Routing tables
Internet:
Destination
Gateway
Flags
default
10.16.128/24
10.16.128.254
link#1
10.16.128.101
10.16.128.254
127.0.0.1
192.168
192.168.0.150
202.11.99.16/28
Ref
Use
Netif
UGSc
UC
3
0
0
0
em0
em0
0:40:5:17:64:73
0:0:c:7:ac:21
UHLW
UHLW
0
3
324
0
em0
em0
127.0.0.1
link#2
UH
UC
0
0
3
0
lo0
sk0
link#2
10.16.128.10
UHLW
UGSc
3
0
417
0
sk0
em0
Expire
945
433
(途中までを表示しています。実際には、IPv6 のルーティングテーブルも表示されます。Internet6: から
始まる表です。)
ここで、Destination の欄は、宛て先のネットワークまたはホストをあらわしています。例えば、最後の
行の 202.11.99.16/28 は、28bit のマスク値を持つサブネットワークを表しており、そのネットワークに行
第 9 章 ルーティング
148
くには 10.16.128.10 のゲートウェイ (Gateway) を通る事が次の Flags の欄の G フラグが立っていること
から分かります。
Flags の意味
U
Up
使用可能
H
G
Host
Gateway
一つのホストのみに到達可能
別のネットワークに行くために Gateway を通過する
D
Dynamic ICMP redirect によって経路が時動的に変更された
S
Static
手動で経路が追加された
(その他、FreeBSD には多くのフラグがありますが、詳しくは man route を参照してください。) 一方、
default は、上記以外のネットワークまたはホストへ行く場合は、10.16.128.254 に転送する事を示してい
ます。10.16.128 は 24bit のマスク値を持っており、更に em0 で link が生成されているので、自分のイン
ターフェース (em0) を使って直接到達出来る事が分かります。
ちなみに、FreeBSD では同一ネットにホストを検知すると (ARP で調べた場合)、それも netstat で表
示されます。その際に、Gateway 欄には MAC アドレスが表示されるようになっています。
最後に、127.0.0.1 はループバックアドレスで、常に自分自身を意味しています。
自分のマシンに実装されているインターフェースとインターフェース名との対応は、そのインターフェー
スに振られた IP アドレスを介して、/etc/hosts によって関係づけられています。インターフェースの設定
状態は ifconfig コマンドで見ることが出来ます。
fwe0: flags=108802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
ether 02:90:f5:d6:0e:2b
ch 1 dma -1
em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
inet6 fe80::290:f5ff:fe2b:ed6%em0 prefixlen 64 scopeid 0x2
inet 10.16.128.16 netmask 0xffffff00 broadcast 10.16.128.255
ether 00:90:f5:2b:0e:d6
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
plip0: flags=108810<POINTOPOINT,SIMPLEX,MULTICAST> mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
sk0: flags=108802<BROADCAST,SIMPLEX,MULTICAST> mtu 1500
options=8<VLAN_MTU>
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
ether 00:09:5b:bc:01:8f
media: Ethernet autoselect (1000baseTX <full-duplex>)
status: active
これを見ると、em0 のインターフェースの IP アドレスは 10.16.128.16 で、ネットマスクが 0xffffff00(255.255.255.0)
であり、ブロードキャストアドレスは 10.16.128.255 であることが分かります。更に、sk0 があり、それら
9.3. 静的ルーティング
149
のアドレスなども分かるでしょう。その他のインターフェースについては今の場合関係ありません (fwe0
は FireWire つまり、IEEE1394 です)。
外部に到達するための出入り口が１箇所しかないような単一のネットワークならば、その出入り口を
default gateway に指定しておけばいいでしょう。一方、出入り口へ到達するために、幾つかの内部のネッ
トワークを経由する必要がある場合には、そのセグメントの出入り口を gateway に指定しなければなりま
せん。そして、出入り口に指定されたマシンまたはルーター上でも、必要な経路情報を指定する必要があ
ります。(動的な経路選択には本講義の最後で取り扱います。効率の点から言うと全てを動的に行うよりも、
静的なルーティングと組み合わせるのが一般的です。)
ホストが静的に一つの gateway を default として記憶している場合でも、その default router に新しいルーティン
グ・テーブルを設定すれば、その default router がクライアントホストに新しい gateway を ICMP redirect を使って
指示してくれます。つまり、少し効率は悪いですが、通常のホストに static に default router を覚えさせても (例え
ば DHCP で配っても)、一時的なルーティング変更には耐えることが出来るわけです。
FreeBSD で、静的な経路情報の設定を行うには、/sbin/route コマンドを使います。例えば、10.0.0.0 の
ネットワークに行くために、10.16.128.101 の gateway に投げる場合には、次のように設定します。
route add -net 10.0.0.0 10.16.128.101
(但し、この例はクラスフルルーティングとして解釈されるので、意図した通りには動作しません。)
一般の書式は次の通りです。
route add -net destination gateway
静的なルーティングで、他の router を経由して、サブネットに行く場合で、サブネット毎に router が
違うような場合は destination にサブネットであることを明示するために -netmask オプションをつけ
る必要があります。
route add -net 202.11.99.16 -netmask 255.255.255.240 10.16.128.101
上の例では、202.11.99.16/28 のサブネットに行くために、10.16.128.101 を通っていく事を示していま
す。このサブネットの指定を忘れると、netstat -rn コマンドで見た時に、マスク値が Destination に表示
されないので直に分かります。
なお、FreeBSD では netmask オプションでの設定 (多くの Unix で共通です) 以外に、/ を用いたマスク
長による指定方法があるので、少し楽が出来ます。
route add -net 202.11.99.16/28 10.16.128.101
これらのルーティングがブート時に反映されるためには、/etc/rc.conf に以下のような記述が必要です。
static_routes="0 1"
route_0="-net default 10.16.128.254"
route_1="-net 202.11.99.16/28 10.16.128.101"
すぐに分かるように route_0, route_1 の内容が直接 route コマンドに渡されているだけです。
デフォルトルータだけの設定の場合には、defaultrouter に記述しておけば、自動的に設定されます。
defaultrouter="10.16.128.254"
# Set to default gateway (or NO)
第 9 章 ルーティング
150
defaultrouter は慣例的な名前で、実際には常に一致する宛先の意味で、それは具体的には 0.0.0.0/0
の意味です。ちなみに、ルーティングの経路選択においては、最長一致で比較されます。つまり、宛先
のマスク長が長いものからマッチするというルールになっています。最も長いマスク長は 32bit ですか
ら、例えば 10.16.128.20/32 という宛先は 10.16.128.20 に同一であるときにマッチします。従って、
192.168.1.0/24 という表記と、192.168.0.0/16 があり、パケットのデスティネーションが 192.168.1.1
であったならば、192.168.1.0/24 がマッチする訳です。こうして、マスク長が長いものから検査され、最
終的に全てのディスティネーションがマッチするのが、マスク長０の defaultrouter になるという訳です。
これらの設定は起動時に /etc/rc.d/routing スクリプトで処理されています (なお、/etc/default/rc.conf
では defaultrouter は ”NO”に設定されています。)
route コマンドでは、ネットワークへの経路だけではなく、特定のホストへのルーティングを指定するこ
とも出来ます (実際には /32 というネットマスクの指定と同じです)。
route add -host destination gateway
この場合、このホストへ行くときだけは、指定された経路を通るように出来ます。設定した経路情報を
削除する場合は、add の代わりに delete を使います。
9.3.1
IP forwarding
多くの Unix と同じように FreeBSD でもデフォルトでは routing がされません。これは、カーネルの IP
Forwading 機能がデフォルトでは設定されていないからです。もし、当該ホストが複数のインターフェー
スを持ち (仮想インターフェースを含む)、ルータにしたいならば IP Forwarding されるように設定しなけ
ればなりません。FreeBSD では、/etc/rc.conf に以下のように記述します。
になります。
gateway_enable="YES"
# Set to YES if this host will be a gateway
ちなみに、この設定をすると起動時に /etc/rc.d/routing で以下のようにして IP Forwarding 機能が ON
case ${gateway_enable} in
[Yy][Ee][Ss])
echo -n ’ IP gateway=YES’
sysctl net.inet.ip.forwarding=1 >/dev/null
;;
esac
つまり、sysctl net.inet.ip.forwarding=1 を手で実行すれば、再起動しなくても、IP Forwarding 機
能は ON になる訳です。(通常は、/etc/rc.conf に設定をしたら /etc/rc.d/routing restart を実行します。)
設定が完了したら必ずテストをするようにしましょう。テストには、普通 ping コマンドを使います。ping
では、相手との通信が出来る場合は、以下のようになります。
9.3. 静的ルーティング
151
$ /sbin/ping guru.it.matsue-ct.jp
PING guru.it.matsue-ct.jp (10.50.18.200): 56 data bytes
64 bytes from 10.50.18.200: icmp_seq=0 ttl=254 time=0.395 ms
64 bytes from 10.50.18.200: icmp_seq=1 ttl=254 time=0.284 ms
64 bytes from 10.50.18.200: icmp_seq=2 ttl=254 time=0.328 ms
64 bytes from 10.50.18.200: icmp_seq=3 ttl=254 time=0.285 ms
64 bytes from 10.50.18.200: icmp_seq=4 ttl=254 time=0.295 ms
64 bytes from 10.50.18.200: icmp_seq=5 ttl=254 time=0.294 ms
64 bytes from 10.50.18.200: icmp_seq=6 ttl=254 time=0.321 ms
^C
--- 10.50.18.200 ping statistics --7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.284/0.315/0.395/0.036 ms
ping では ICMP を送り続けるので、終了する時には Ctrl+C を押してください。
ここで、packet loss が異常に多い場合は、ネットワークのトラフィックが混雑しすぎているか、あるいは
何らかのトラブルが考えられます。まったく通信出来ない場合は、ケーブルトラブルか設定ミスでしょう。
複雑な経路をトレースするには traceroute というパブリックなコマンドがあります。 Unix で実装され
ている traceroute の仕組みは、大体以下のようなものです。
FreeBSD では標準で/usr/sbin に導入されています。
$ /usr/sbin/traceroute 202.218.13.138
traceroute to 202.218.13.138 (202.218.13.138), 30 hops max, 40 byte packets
1
10.50.254.254 (10.50.254.254) 0.631 ms 0.496 ms 0.451 ms
...
...
13 202.218.13.138 (202.218.13.138) 27.351 ms 27.411 ms 27.355 ms
この場合、202.218.13.138 へのルーティングは、10.50.254.254 という経路を通っていることが分かり
ます (他の経路は省略しています)。この経路が、意図した通りかも確かめておく必要があります。また、
TCP/IP では行きと帰りの経路が異なっていても構わないのですが、自サイトのネットワークの中で、こ
れが違っている場合は設定ミスである場合が多いので、片方を調べるだけではなく、双方向で確かめる必
要があります。
ちなみに、traceroute は、UDP パケットを宛て先 IP に向けて、TTL(Time To Live) を小さくして (最
初は 1 に設定し、次々と一つづつ大きくしていきます)、TTL が 0 になるとそれ以上ルーティングされずに
ICMP TIME EXCEEDED が帰ってくることを使って (ルータは TTL を一つ減らし、0 になるとルーティ
ングをせずに ICMP を返します)、近い順にルータを探します。従って、ICMP TIME EXCEEDED を返
さないルータは探索出来ません。こうした返事をしない、あるいは返事を返せないルータは、traceroute
では* * * のように表示されます。
例えば、最近では traceroute をかけられたくないプロバイダーや、プライベートアドレスを経路上の
ルータに利用している場合に、traceroute に答えないようにしている事があります。この場合、traceroute
の表示にはそのルータから返事がない旨が表示されます。勿論、この場合でも、TTL を増やして次のルー
タにトライすることは可能です。
第 9 章 ルーティング
152
• 参考
ネットワーク上のパケットの状態を監視するには、 tcpdump があります。更には、簡単な GUI ツールとして
wireshark が FreeBSD のパッケージにあります。これらのツールを使えば、２点間で実際にパケットが流れて
いるのかということや、あるホストからパケットが流れているかということを調べることができます。パケット
の中を全て知る事が出来る訳ですから、一般ユーザには使用出来ないようにしておかないといけません。また、
ネットワークに接続されたワークステーションからは、こうした packet snooping が可能な訳ですから、セキュ
リティを重視する場合には物理的なセグメントの分割やスイッチの多用などを考える必要があります。
ちなみに、tcpdump は元は SunOS4.x にあった etherfind に端を発しています (作者が同じです)。SunOS5.x
では、snoop というコマンドが用意されています。また、wireshark は最近作者の職場の変更に伴い ethereal
から Wireshark に名称が変更され、web ページもそちらに移管されています (商標登録の関係のため)。
9.4
動的ルーティング
動的なルーティングを可能にするプロトコルには様々なものがありますが、主なものとして、内部ルー
ティング用には RIP,OSPF が、外部ルーティング用には EGP,BGP などが利用されます。内部ルーティン
グでは、このうち RIP が良く用いられ、多くのルータが対応していますが、 15 個を越えてネットワーク・
セグメントを伝達することは出来ません (RIP の改良である RIPv2 でもこれは同じです)。また、経路情報
が確定するまで (これを収束と言います) が非常に遅いという欠点があるので、構成機器が少ない小規模ネッ
トワーク用であると言えます。ある程度の規模のネットワークでは RIP の欠点を改善した OSPF(Open
Shortest Path First) を用いた方が良いでしょう。特に、OSPF は収束性が良く、回線故障時の回避、復
旧、複数経路のロードバランシングなどに見るべきものがあります。 FreeBSD では、routed が RIP を用
い、Zebra が RIP,OSPF,BGP など多くのプロトコルに対応しています。
しかし、動的ルーティングは制御の負荷が高いので (RIP は特にネットワーク負荷が高くなる傾向にあ
り、OSPF は CPU への負荷が高い傾向がありますが、今の CPU ならば OSPF の方が良いでしょう)、静
的ルーティングをうまく使い、動的ルーティングを極力最小限度に保つのがポイントです。
更には、ドメイン間でのルーティング方法は現在急速に IPv6 への対応が進んでおり、BGP(Border Gate-
way Protocol) などの IPv6 への実装もされています。
9.5
ネットワークのセキュリティ
セキュリティを考える場合、幾つかの観点があります。ひとつは、出入口でのセキュリティの確保、これ
は外部に対してのセキュリティと内部に対するセキュリティがあります。もう一つは、回線自身のセキュ
リティの確保、これには VPN などの物理層での暗号回線技術と SSH などのアプリケーション層での暗号
回線技術があります。
外部に対してのセキュリティは、自らのサイトと Internet の出入口に当たるルータで確保するもので、
FireWall(防火壁) と呼ばれています。簡単な FireWall は、IP の filtering やトランスポート層で行えます。
この場合、ある種のポートへの外部からのアクセスの禁止や、場合によってはある IP domain からのア
クセス制御を含みます。しかし、FireWall で全てがまかなえる訳ではありません。例えば、sendmail や
News システムのバグを利用したパスワード・クラックや、WWW の CGI を用いたクラックなどに対し
ては個別に対処するしかないでしょう (一部の攻撃にはアプリケーションゲートウェイが有効ですが)。つ
まり、内部に対するセキュリティは個々のワークステーション単位でのセキュリティになりますが、大き
なサイトでは内部ルータの filtering によって安全性を高める場合もあります。
暗号技術は、ハードウェアレベルは２地点間を専用ルータなどで結ぶ場合で、それなりのコストがかか
ります (但し、VPN に対して過信は禁物であることが最近明らかになりつつあります)。一方、アプリケー
9.5. ネットワークのセキュリティ
153
ション層での対応はソフトでできる事ですので、今後導入を考えた方が良いでしょうが、その場合でも、
外側に対して護るのか、それとも内側に対してかという切り分けは良く考えた方が良いでしょう。
内部のセキュリティは、個々のセキュリティホールを潰すことや、ある種のサービスへの外部からのア
クセスを禁止したりすることによって強化します。この場合には、あるポートに割り当てるデーモンをセ
キュリティ強化した別のデーモンに置き換えるなどの対処をします。
一般に、セキュリティと使いやすさとは反比例する関係にあり、使いやすさを追求すればセキュリティ
上の弱点が拡大し、逆に、セキュリティを強めれば、使いにくくなっていきます。また、管理者がセキュリ
ティをどれだけ高めようと、ユーザーが単純なパスワードを使用したり、パスワードを教えあっていたり
したのでは元も子もありません。反対に、セキュリティを強化ばかりして、ユーザーに使いにくい環境で
は何のためのネットワークか分からないばかりか、管理者がそれに追われることにもなりかねません。う
まくバランスを取るように心がけることが肝要です。
第 9 章 ルーティング
154
演習課題
9.6
演習 9.1 まず、グループを作ります。グループのうちのいずれかの人が代表者となります。グループを作っ
たら、グループに番号を振ります (こちらで指示します)。まず最初に代表者 (マスター) の PC でルーティ
ングを行ない、その他の PC は代表者からルーティングされて、別のサイトへと到達するようになります。
まず、すべてのマシン上で、現在の自分のホスト名, 現在の IP, default gateway の IP を書き留めなさい。
演習 9.2 dhclient (DHCP のクライアント) が停止しているかどうか確認をしなさい。
# /etc/rc.d/dhclient stop
但し、必ず以下のように実際に動いていないかどうか確認すること。
#
ps aux | grep dhclient
もし、動いていたら、手動で終了させる必要があります。(kill コマンドで殺します。)
演習 9.3 グループをつなぐためのケーブルを作成しなさい。スイッチをグループごとに用意してあります
ので、全員自分のグループのスイッチに作成したケーブルで接続しなさい (現在繋がっているケーブルは一
旦外します)。
演習 9.4 次に、lnc0 に手動で 192.168.N.X/24 を設定しなさい。但し、N はグループの番号で、X は組
の中で重複しないように、1,2 と順に振りなさい。代表者は、192.168.N.1/24 です。お互いにグループ内
部で ping を打って、接続されていることを確認しなさい。
演習 9.5 代表者は、USB Ether を本体にさしなさい。さした後に、VMplayer 上で、”取り外し可能デバ
イス” メニューで、”asix ax88772”にチェックを入れなさい。これで、FreeBSD 上で認識される筈です。
ifconfig コマンドで、インターフェース ue0 が認識されるかを確認しなさい。その他の人たちも、USB
Ether が認識されるかを確認しなさい。
演習 9.6 以下の設定を新たにつけたインターフェース ue0 に代表者は次の操作をします。
# ifconfig ue0 inet 10.120.150.N/24
但し、N はグループごとに異なります。
設定を確認した上で、既存のネットワークのスイッチと自分の ue0 を接続しなさい。ルータ (10.120.254.254)
との導通を確認しなさい。
演習 9.7 マスターは、ue0 と lnc0 の設定を/etc/rc.conf に設定し、IP Forward の設定をしなさい。de-
faultrouter には、10.120.254.254 を設定し、終ったらリブートをすること。
マスター以外の人も、lnc0 への設定を /etc/rc.conf に行い、マスターの内側のアドレス (192.168.N.1)
にデフォルトルータを設定し、FreeBSD をリブートしなさい。
演習 9.8 全員、10.50.18.200 の接続が出来ているかどうかを確認しなさい。確認したら、全員、
#
traceroute
の結果を提出しなさい。
10.50.18.200
9.6. 演習課題
155
演習 9.9 他のグループと通信できるようにマスター上のルーティングテーブルを編集せよ。
> route add -net 192.168.N.0/24 10.120.150.N
この例では、192.168.N.0/24 のネットワークに行くためには、10.120.150.N のゲートウェイを使う設定
になっている。但し、すべてのグループと通信できるように、グループの数だけ (全グループ数から自分の
グループの 1 を引いた数) 同じように設定をしなさい。
演習 9.10 いろいろなグループに対して ping を打って見て問題がないかどうかを調べよ。問題のあるグ
ループについては、自分のサイトが間違っている場合と、相手が間違っている場合があるので、相談の上
究明せよ。問題なければ、最低 2 つ以上のグループのいずれかのホストへの ping の結果を提出しなさい。
157
第 10 章 FreeBSD と WWW
WWW サーバには多くの実装があるが、世界で最も使われているのは Apache であろう。Apache には
多くの機能があり、それら全てを説明していると一冊の本になってしまうので、ここでは基本的な設定方
法に絞ることにする。
apache のインストール
10.1
FreeBSD8.2R のパッケージには Apache2.2.17 が用意されており、Appache のインストールは以下のよ
うに行う。
# pkg_add
-r
apache22
参考 FreeBSD には、Apache 1.x, 2.0, 2.1, 2.2 などの各バージョンの最新のものが用意されており、それ
ぞれが使えるようになっているために、パッケージからインストールする場合、apache, apache20,
apache21, apache22 のようにして指定することになっている。
apache の設定
10.2
WWW サーバはインストールしただけでは動作せず、自分で設定ファイルを作成しないといけません。
そのために、/usr/local/etc/apache22 にさまざまな設定ファイルの雛型が用意されている。まず、標
準の設定ファイルを必ず別のファイルにコピーしてとっておく。こうしておくと、httpd.conf を編集し
て、途中で分からなくなっても、その元ファイルコピーすれば戻すことが出来るからです。
# cd
# cp
10.2.1
/usr/local/etc/apache22
httpd.conf httpd.conf.org
httpd.conf
httpd.conf はサーバの基本設定ファイルであり、全ての設定はこのファイルで行う (別のファイルで設定
する場合でも、このファイルで include などを行うことで、他のファイルを読み込んでいる)。
Apache を動かすためには、最低以下の設定のみを行えば良い。
ServerName
DNS などに登録されている場合には、以下のように名前を登録すれば良い。
ServerName pc5-1.group1.matsue-ct.jp:80
：の後ろはポート番号で、標準は 80 番である。
第 10 章
158
FreeBSD と WWW
DNS に登録されていない場合には、IP アドレスを指定しなければならない。
ServerName 10.120.110.10:80
自分の IP アドレスが一定でない場合 (DHCP などで動的に管理) や、NAT などによってアクセスさ
れる IP と自分の IP とが異なるような場合には localhost(127.0.0.1) を設定すると良い。
ServerName 127.0.0.1:80
一応、その他の代表的な設定項目について解説をしておきます。
ServerRoot サーバの設定ファイル、ログファイルなどが置かれるディレクトリのトップのツリーを設定
する。デフォルトのままで良い。なお、conf ファイルにも書かれている注意だが、末尾に / を付け
てはならない。
ServerRoot
"/usr/local"
User,Group サーバプロセスである httpd は最初 root で立ち上がり、クライアントリクエストに応える
ためにチャイルドプロセスを立ち上げるが、そのチャイルドプロセスをセキュリティのために別の
ユーザ、グループの権限で動かす事ができる。デフォルトは www.www になっているので、デフォ
ルトで良いだろう。
ServerAdmin サーバ管理者のメイルアドレスを指定する。サーバが作成するエラーページなどに利用さ
れる。
DocumentRoot
サーバのページデータを置くトップツリーを指定する。シンボリックリンクであっても良い。実際に
は、パッケージでは/usr/local/www/apache22/data/ が実ディレクトリとして存在している。
# ls -l /usr/local/www/apache22
drwxr-xr-x 2 root wheel
drwxr-xr-x 2 root wheel
512 Feb 1 11:45 cgi-bin
512 Feb 1 11:45 data
drwxr-xr-x 3 root wheel 1024 Feb 1 11:45 error
drwxr-xr-x 3 root wheel 3584 Feb 1 11:45 icons
/usr/local/www/apache22/data から変更する必要はない。
もし変更した場合には、後で出てくる
<Directory "/usr/local/www/apahe22/data">
セクションもそれに応じて変更する必要がある。
UserDir ユーザのホームディレクトリに関する設定は、extra/httpd-userdir.conf にある。但し、標準では
その設定を読み込まないので、利用する場合にはまず httpd.conf の中の以下の場所コメントを外す。
# User home directories
Include etc/apache22/extra/httpd-userdir.conf
10.3. 起動
159
(上の Include の前に # がついているので、それを取る。)
次に、httpd-userdir.conf の中にある設定の
UserDir
public_html
がユーザーのホームディレクトリの下の ~/public_html/ をユーザーの公開用ホームページディレ
クトリとする設定であるので、このディレクトリは www.www (user www, group www) のサーバプ
ロセスが読めるパーミッションを持っていなければならない。デフォルトは、public html なので、
適当に変更すれば良い。
UserDir www
...
なお、httpd-userdir.conf の設定を、httpd.conf にコピーしても同じである。
ErrorLog エラーログの場所の指定。
ErrorLog /var/log/httpd-error.log
10.3
起動
一般的に Apache は/usr/local/sbin/apachectl start で起動させるのだが (root で行う) 、FreeBSD
では起動用スクリプトが提供されるので、それを使うようにする。
但し、起動用スクリプト ( /usr/local/etc/rc.d/apache22 ) は、/etc/rc.conf の変数 apache22_enable="YES"
が設定されていないと、手動でも起動しないので注意しよう。最初に、/etc/rc.conf に設定を行う。
###### /etc/rc.conf の末尾に以下の一行を追加 #######
apache22_enable="YES"
次に、スクリプトで起動させる。
# /usr/local/etc/rc.d/apache22 start
止める時には、stop オプションで終了させることができる。
なお、起動したかどうかはプロセスリストを見て確かめる。
# ps auxw |grep http
876 ?? Ss
0:00:04 /usr/local/sbin/httpd
877 ?? S
878 ?? S
0:00:04 /usr/local/sbin/httpd
0:00:04 /usr/local/sbin/httpd
879 ?? S
880 ?? S
0:00:04 /usr/local/sbin/httpd
0:00:04 /usr/local/sbin/httpd
881 ?? S
0:00:04 /usr/local/sbin/httpd
第 10 章
160
FreeBSD と WWW
デフォルトでは、６つのプロセスが立ち上がっている。これは、親のプロセス 876 が自分自身のコピー
をあらかじめ用意しておき、アクセスがあったらそのコピー達にそのアクセスへの対応を任せることによ
り、素早くサービスを行うための仕組みである。
もし、これらのプロセスが動いていなかったら、/var/log/httpd-error.log を見て原因を探る。
多くの間違いは、ServerName に自分の IP が書かれていなかったり、間違っていた場合、あるいは host-
name が設定されていない場合である。 hostname で設定した名前は必ず IP との対応をチェックするよう
になっており、これが間違っていたり、実際の IP と異なっていると apache が起動しない。
10.4
ページ
FreeBSD での Web ページの標準は、/usr/local/www/apache22/data 以下になります。従って、http://localhost/
のようにアクセスした場合には、/usr/local/www/apache22/data/index.html が参照されます。デフォ
ルトでは、ここには以下のようなファイルが用意されています。
<html><body><h1>It works!</h1></body></html>
つまり、これをブラウザで表示すると、ちょっと大きな文字で ”It works!” と表示されるだけです。通常
のサイトでは、この index.html にサイトの表玄関のページを設定し、ここからリンクで他の html ファイ
ルを参照できるようにします。
HTML(Hyper Text Markup Language) の詳細についてはここでは触れませんが、最近の多くのサービ
スでは Web で操作したり、見たりするものが増えていますので、WWW サーバにするつもりがないサー
バであっても、導入だけはしておいた方が良いでしょう。
161
第 11 章 NAT(NAPT)
Internet の爆発的な普及は IP 資源の枯渇とルーティング情報の肥大化という危機を招きました。後者に
ついては CIDR によって部分的には回避され、前者についてはプライベートアドレスの利用によって当面
回避されていますが、このプライベートアドレスの簡便な利用を可能にしたのが NAT という技術です。
11.1
NAT とは
NAT(Network Address Translation) はネットワーク層での一種のプロクシーだと言えます。通常、Internet
上ではパケットは全て発信元、送信先共にグローバルな IP でなければなりません。しかし、IP 資源の枯
渇によって全ての通信においてグローバルな IP を用いることは破綻しかけていました。そこで、ルータ
などのグローバルなネットワークとの接合部分において、IP のすり替えを行う仕組みが開発され、これが
NAT と呼ばれるものです。従って、この NAT は、内部において発信されたプライベートアドレスを発信
源に持ち、グローバルアドレスを送信先に持つパケットを外部に流す際に、プライベートアドレスについ
て変換を行います。勿論、プライベートアドレスはグローバルアドレスへと変換し (変換の際のグローバ
ルアドレスは NAT マシンが知っている) て外へと送り出します。そのパケットに対する返信パケットは逆
に変換を行ったグローバルアドレスに戻ってくるので、先のすり替えテーブルを参照して、本来のプライ
ベートアドレスに直して内部に送り出すわけです。これによって、グローバルなネットワークにはまった
くプライベートアドレスは現れないという事が実現できたのですが、この際にプールしておくグローバル
アドレスを一対一対応で行うと、接続している内部のプライベートアドレスの数に対応するだけのグロー
バルアドレスが必要になります (一見アドレスの枯渇には役に立たないように見えますが、これでも接続さ
れていない台数分の IP アドレスは節約できますし、何よりもセグメントに分けた際に生じる無駄を抑制で
きるという利点があります)。この考えを更に推し進めて、よりグローバルアドレスの消費を劇的に押さえ
たのが NAPT(Network Address Port Translation) と呼ばれるものです。NAPT は Linux での実装がもっ
とも有名なためにその実装名である IP マスカレードとも呼ばれますが、IP マスカレードはあくまでも実
装名であって、機能の名前ではありません。また、NAPT という名前も近年古典的な NAT との区別のた
めに言われ始めたもので、機能的には NAPT でありながら NAT と呼ばれているものもあります。そうい
う意味では、広義の NAT と狭義の NAT があると言って良いでしょう。ともあれ、NAPT が NAT と違う
点は、プライベート側の発信を IP だけではなく port 番号まで含めて識別に利用した点です。これによっ
て、狭義の NAT に比べて、グローバル IP の消費が押さえられ、グローバル IP が一つでも運用が可能に
なっています (NAT マシン上のグローバル IP を使うことも出来ます)。
更に、この書き換えを行うことによって、接続されていない (NAT 上のグローバルとプライベートの対
応表にない) 接続は原理的に接続が成立しないので、内部を一定程度保護するというセキュリティ上の利点
も生じます。しかし、この原理を見れば分かる通り、もしコネクションのパケット自体にアドレスなどの
情報を載せて出ていった場合 (当然そのアドレスを別のコネクションを張るために利用したい訳ですが)、
NAPT はそれに関知しないのですから、そうしたアプリケーションは利用できなくなります。一部のアプ
リケーション (例えば、FTP など) については NAPT が特別にアプリケーション層のプロトコルまで解釈
することで対応する場合もありますが、個別的対応しか手がなく、そういう意味でプライベートアドレス
第 11 章 NAT(NAPT)
162
のネットワークはインターネットではないという人もいます (IPv6 が待望されるのはそうした意味もある
のです)。
11.2
IPFilter の NAT
FreeBSD では利用可能なフィルタリングソフトが 3 種類あり、それぞれ IPFW と IPFilter, PF と呼ば
れています (実は、PF は IPFilter を参考に作られています)。そして、NAT(NAPT) はこのフィルタリン
グソフトによって違い、IPFW には natd が、IPFilter には NAPT が内蔵されています。IPFilter では内
臓されていることによって、他のツールとは違い、最初から NAT との親和性は良いと言えます。IPFilter
の NAT で用いるコマンドは、ipnat コマンドです。以下の例では、NAT のルールを/etc/ipnat.rules から
読み込み、設定をします。
# ipnat -CF -f /etc/ipnat.rules
FreeBSD ではシステムが立ち上がる際に、/etc/rc.d/ipnat で ipnat が設定されるようになっています。
設定ファイルは、/etc/ipnat.rules が標準のファイル (/etc/defaults/rc.conf の設定) ですが変更することも
出来ます。従って、このスクリプトを利用する方が簡単でしょう。
# /etc/rc.d/ipnat start
(ルールの再読み込みは reload で、再起動は restart、停止は stop を指定します。)
ipnat 自体のオプションの意味は、-C が現在の NAT ルールの削除を意味し、-F が NAT 変換テーブル
のクリアを意味します。最初に動かす際には意味はありませが、念のために指定した方が良いでしょう。
ipnat.rules に書かれる NAT ルールの指定方法は、以下の通りです。
map le0 192.168.1.0/24 -> 10.120.150.20/32
map le0 192.168.1.0/24 -> 10.120.150.20/32 portmap tcp/udp 49152:65535
この場合、インターフェース le0 上で 192.168.1.0/24 のプライベートアドレスを持った外へのパケット
は全て 10.120.150.20 のアドレスに書き換えられます。逆に、入って来るパケットがこの変換テーブルに該
当する場合には逆向きに書き換えられます。ここで、IP アドレスに対してはマスクは必ず必要ですので、
忘れないで下さい。この変換において、使われるポートは 49152∼65000 までのポートが使われます。一
方、TCP/UDP 以外のプロトコルに関しては 2 行目のルールで処理されます。従って、1,2 行目の両方が
必要です。
利用されるポートについて自動的に処理したい場合には auto が使えます。また、代替用のグローバル
IP には複数の IP も使う事が出来ます。
map le0 192.168.1.0/24 -> 10.120.150.16/28 portmap tcp/udp auto
map le0 192.168.1.0/24 -> 10.120.150.16/28
この例では、代替用の IP には 10.120.150.16∼10.120.150.31 が利用されます (正確には 16 と 31 は使え
ず、14 個のアドレスが使えます)。但し、この場合、10.120.150 が通常の 24bit マスクならばサブネットマ
スクについては嘘をつくことになるので、少し注意が必要です。
こうした NAT や IPFilter によるフィルタリングで少し困るのは active FTP です (active に対しては
passive もある)。active FTP では、実際のファイル転送の際には、サーバからクライアントに向かって新
11.2. IPFilter の NAT
163
たにコネクションが張られます。これは通常の NAT やフィルタリングの関知していないデータパケット内
部のプロトコルによってなされるものです。従って、active FTP に対応するには、一種のプロクシ−が必
要となりますが、幸い IPFilter の NAT にはこうしたものが用意されています。
map le0 192.168.1.0/24 -> 10.120.150.20/32 proxy port ftp ftp/tcp
但し、このルールについては他の全てのルールの前に置かなければなりません。何故ならば、先に portmap
が働いてしまうと proxy が動かない事になるからです。
これらを設定した後、NAT の変換の様子を見るには、ipnat -l コマンドを使います。
なお、IPFilter における NAT の変換はフィルタリングルールの前に行われます。つまり、もし外側イ
ンターフェースで入ってくるパケットに対して NAT を行えば、IPFilter では変換された後のパケットが
入ってくる事になります。逆に、内部から外側に出て行く場合には、IPFilter ではまだ変換されていない
パケットについて見る事になります。従って、フィルタリングルールにおいては NAT を使っている場合、
該当するプライベートアドレスについても考慮しなければならない点に注意して下さい。
以上をまとめると、通常の NAT のルールは以下のようになります。
map le0 192.168.1.0/24 -> 10.120.150.20/32 proxy port ftp ftp/tcp
map le0 192.168.1.0/24 -> 10.120.150.20/32 portmap tcp/udp auto
map le0 192.168.1.0/24 -> 10.120.150.20/32
IPFilter の NAT 機能には、その他にも redirect や、redirect する際にロードバランシングを行う機
能などもあります。redirect 機能は簡単に言えば、IP global A, port X 宛に来たパケットを、内側の IP
private B, port Y に透過的に送る機能です。これによって、内部に立てた private アドレスを持つ Web
server を外部に公開するような事が出来ます。
rdr le0 10.120.150.20/32 port 81 -> 192.168.1.2 port 80 tcp
この例では、10.120.150.20 の port 81 (つまり Web) に来たパケットは、全て 192.168.1.2 の port 80 に振
り向けるようになっています。(当然、外からアクセスする場合の URL には http://10.120.150.20:81/
を使わなければなりません。)
更には、そうした Web server を複数内部に立て、それらに次々と巡回的にパケットを振り分ける (round
robin) ことなども出来るようになっています。
rdr le0 10.120.150.20/32 port 81 -> 192.168.1.3 port 80 tcp round-robin
rdr le0 10.120.150.20/32 port 81 -> 192.168.1.4 port 80 tcp round-robin
rdr le0 10.120.150.20/32 port 81 -> 192.168.1.2 port 80 tcp round-robin
この例では、10.120.150.20 の Web に来たパケットは最初は 192.168.1.2 に送り、次に来たコネクショ
ンは 192.168.1.3 に、その次は 192.168.1.4 にと巡回的に送ります。
これらの NAPT の設定とは異なり、古典的 NAT の設定も IPNAT では提供されています。古典的 NAT
では 1 対 1 に IP アドレスを対応させ、ポート番号は利用されません。古典的 NAT の設定には bimap を
利用します。以下の設定では、192.168.1.1 を 10.120.150.21 に対応させ、192.168.1.2 を 10.120.150.22 に
対応させています。いずれも /32 を利用している点に注意して下さい。
第 11 章 NAT(NAPT)
164
bimap le0 192.168.1.1/32 -> 10.120.150.21/32
bimap le0 192.168.1.2/32 -> 10.120.150.22/32
11.3
フィルタリングとカーネル
FreeBSD では、先に述べたように NAT は IPFilter の中に実装されています。従って、NAT を利用し
たい場合にはフィルタリングの設定をしなければなりません。但し、この章ではフィルタリングと言って
も、全てを通す設定をすることで NAT のみを実質的には使う設定を行います。
11.3.1
カーネルの再構築
IPFilter は非常に多くの OS に対応したソフトです。多くのソフトに対応出来ている理由は、現代的な
カーネルの持つモジュールに対応しているからで、カーネルを再構築せずにモジュールをダイナミックに
カーネルに組み込む事が出来る仕組みによっています。しかし、きちんとしたファイアーウォールを作る
場合には、カーネルを再構築出来る場合には再構築した方が良いでしょう。FreeBSD では、カーネルの再
構築は非常に容易に行えるようになっているので、ここではカーネルを再構築した上で設定することにし
ます。
カーネルを再構築する場合には、まずカーネルの設定ファイルを編集し、どのようなカーネルを作成す
るのかを指定します。
11.3.2
カーネルの設定ファイル
カーネル設定ファイルは様々なカーネル組み込みデバイスやカーネル機能を変更するための基本の設
定ファイルです。このファイルは必ず/sys/i386/conf/ ディレクトリになければなりません (通常、/sys
は/usr/src/sys にリンクされています。従って、実ディレクトリは/usr/src/sys/i386/conf/ になります)。
標準配布のカーネルは /sys/i386/conf/GENERIC ファイルを用いて作成されたものです。また、様々な
カーネル設定のオプションは LINT に詳しく掲載されていますが、LINT 自体はカーネル構築用のファイ
ルではありませんので、LINT からカーネルは構築できません (LINT 自体は make LINT で生成されま
す)。ファイアーウォールを作成する際には、GENERIC をコピーして (例えば MYKERNEL)、以下の内
容を付け足せば良いでしょう。慣れてくれば、必要のないデバイスなどを削除することなどもしますが、当
面はこれだけで十分です。
options
IPFILTER
#ipfilter support
options
options
IPFILTER_LOG
#ipfilter logging
IPFILTER_DEFAULT_BLOCK #block all packets by default
options
IPSTEALTH
#support for stealth forwarding
最後に、これらの変更を施した MYKERNEL の識別名を GENERIC から変更します。(これは例えば
/var/log/messages やブート時のメッセージとして残りますので、 GENERIC カーネルではないカーネル
から立ち上がっている事が分かるようにという配慮です。)
ident
MYKERNEL
11.3. フィルタリングとカーネル
11.3.3
165
カーネルの再構築
基本的には以下の流れになります。
1. 編集
先ほど述べたようにカーネルの設定ファイルの編集を行います。
2. コンフィグ
カーネル設定ファイルに従って必要なディレクトリやファイルを用意します。これは config コマン
ドが自動的に行ってくれます。カーネル設定ファイルの名前が MYKERNEL だったならば、
# config
で終りです。
MYKERNEL
3. make
config の最後に指示が出ますが、../compile/MYKERNEL に移動し、
#
make depend
# make
を実行します。カーネル設定ファイルに誤りがなければ、新しいカーネルが出来ます。(なお、カー
ネルの再構築を 2 度以上行う場合には、make cleandepend を先に実行し、以前の依存関係を消去
しておく必要があります)
4. カーネルのインストール
カーネルがうまく出来れば、それをインストールします。
#
make install
但し、make install コマンドは現在ある /boot/kernel/ を /boot/kernel.old/ に移動しますので、成
功した時の /boot/kernel.old/ を取っておきたい場合には、予め名前を変更しておきましょう。ま
た、/kernel も /kernel.old も共にブートしない場合にはカーネルを再インストールしなければなり
ません。
従って、通常は一度だけ再起動を行う前に、以下のように GENERIC カーネルを取っておきます。
# mv
/boot/kernel.old
/boot/kernel.generic
この後に再起動を行います。
#
shutdown
-r
now
5. 再起動時に失敗したら
うまく再起動出来なかった場合には以前のカーネルが、/boot/kernel.old ( 上記のように移動した場
合には /boot/kernel.generic) に残っていますので、起動時に以下のメッセージが出ている間に、
第 11 章 NAT(NAPT)
166
Welcome to FreeBSD!
カウントダウンを止めたい場合には、SPACE キーを押せば止まりますので、ゆっくりとメニューを
みて ”Escape to loader prompt” を選びます。
ブートローダに入ると ”OK” プロンプトが出ますので、以下のように失敗したカーネルを unload し
てから、前にブートに成功したカーネルを load して、boot します。
OK unload
OK load /boot/kernel.old/kernel
/kernel.old text= ...
OK boot
...
(OK 以降を入力。移動した場合には、kernel.old の代わりに kernel.generic を指定します)
11.3.4
natd, フィルタリングの設定
カーネルの再構築が済んだら、再起動する前に、設定ファイル (/etc/rc.conf) を編集し、再起動後すぐ
に NAT になるように設定をしておきます。カーネルの設定はデフォルトでは立ち上がった際に、安全のた
め全てのパケットの受け入れを拒否するようになっています。今の場合には、NAT のみを使い、フィルタ
リングは素通しの設定にします。この設定の詳細については次の章で詳しく見ることにして、ここでは素
通しの設定は /etc/ipf.rules に次のように書いておきます。
pass in all
pass out all
次に、これらの設定に従って、フィルタリング、NAT を起動時に動くように/etc/rc.conf に設定をします。
ipfilter_enable="YES"
ipnat_enable="YES"
# Set to YES to enable ipfilter functionality
# Set to YES for ipnat; needs ipfilter, too!
ipmon_enable="YES"
tcp_drop_synfin="YES"
# Set to YES for ipmon; needs ipfilter, too!
# Set to YES to drop TCP packets with SYN+FIN
icmp_drop_redirect="YES" # Set to YES to ignore ICMP REDIRECT packets
icmp_log_redirect="YES" # Set to YES to log ICMP REDIRECT packets
なお、タイプミスが心配な方は、/etc/default/rc.conf から該当行をコピーしてきて、必要な箇所のみを
編集すれば良いでしょう。
設定が終ったら、再起動して、プライベート側にマシンを用意してテストして見てください。基本的に
は、プライベートからルーティングされていないグローバル側に出て行き、コネクションが成立すれば大丈
夫でしょう (例えば telnet で試す)。詳しくは、tcpdump や Wireshark などで、グローバル、プライベー
ト両方のパケットを監視して見てください。
11.4. 演習課題
11.4
167
演習課題
演習 11.1 全員、カーネルを再構築しなさい。
演習 11.2 マスターは 192.168.X.0/24 への静的ルーティングテーブルを全て削除しなさい。また、/etc/rc.conf
からそれらを削除しなさい。(実際にはコメントアウトするように。)
演習 11.3 マスターは/etc/ipnat.rules, /etc/ipf.rules を設定し、マスターが NAT マシンになれるように
設定しておきなさい。それ以外の人は、 ipnat.rules は設定せずに、ipf.rules のみを設定しなさい (つま
り、ipnat_enable を NO にしておくこと)。
演習 11.4 マスターが再起動をしたら、NAT の動作を確認し、外との接続を確認しなさい (学外にも出れ
ることを確認しなさい)。
演習 11.5 更に、その様子を wireshark などで監視してみなさい。
演習 11.6 apache22 を導入し、apache を立ち上げた上で、/usr/local/www/apache22/data/index.html
を編集し、自分のページだと分かるようにしなさい (学生番号、名前は最低入れること)。内部で apache の
動作を確認しなさい。
演習 11.7 マスターは redirect 設定を NAT に行いなさい。但し、ポート番号は、順に 81, 82, ... を割り
当てなさい (自分は 80 番です)。外部からそれぞれのウェブページが見えることを確認しなさい。また、外
部のグループのページが見えることを確認しなさい。問題なければ、空いている PC の Windows 上からア
クセスして表示される自分の Web ページのソースを提出しなさい。
演習 11.8 先のチェックで問題なければ、今度はロードバランスの設定を行い、外部からどう見えるかを
チェックしなさい。問題なければ、先と同様に空いている PC の Windows 上から最初に表示される自分達
のグループのページのソースを提出しなさい (グループ内では違うページがそれぞれ提出されるように)。
169
第 12 章 SSH(Secure SHell)
ここでは、公開鍵暗号を実際に利用しているアプリケーションとして SSH を取り上げ、公開鍵暗号で重
要な、公開鍵、秘密鍵の概念を理解することを目標としましょう。(本章は情報ネットワークで学習した内
容と同じですが、演習のために再掲しています。)
12.1
SSH の基本設定
SSH(Secure SHell) は認証に公開暗号鍵を用い、アプリケーション層で暗号回線を可能にするソフトウェ
アです。認証メカニズムが強力で、回線の暗号化により全ての通信が秘匿されるので、外部からのアクセ
スや内部からのファイアーウォールのアクセスなどに用いるのに最適です。FreeBSD では、Fsecure 社の
SSH ではなく、OpenSSH を標準で搭載し、通常のインストールでは、標準で /etc/rc.conf に
sshd_enable="YES"
と設定され、 SSH のサーバが自動で走るようになっています。(SSH v1,v2 に対応しており、サーバの
RSA,DSA キーは自動で生成されます)
SSH の概念は下の図のように考えれば良いでしょう。
telnet
telnetd
mail
sendmail
imap
client
ˆÃ † ‰ñ ü
imapd
server
まず、telnet を用いて、クライアントからサーバにアクセスすることを考えます。このコネクションを
SSH の作った暗号回線を通すために、クライアント自身のあるポートに暗号回線の入口を作ります (これ
は SSH のクライアントソフトの役割です)。そして、telnet を用いて、この入口に入ると (例えば、telnet
localhost 3000) などのようにして、SSH が暗号回線を通してサーバの SSH 側へと自動的に送り、サーバ
第 12 章
170
SSH(Secure SHell)
の適当なポートから現れます。つまり、サーバから見れば、サーバから telnet をユーザがかけているよう
に見える訳です。クライアントから見れば、自分自身の変なポート (3000) にアクセスしているだけのよう
に見えます。これは、telnet だけに限らずに、どんなアプリケーションであろうと、全て同じように扱え
ます。そういう意味で、SSH の作る暗号回線は土管のようなものだと思えば良いでしょう。
さて、では SSH を使うために必要な事ですが、SSH では公開鍵と秘密鍵とパスフレーズの組合せを用
います。パスフレーズはパスワードのようなものですが、パスワードと違うのは空白を含む非常に長いフ
レーズを使える点が違います。そして、サーバ側に自分の公開暗号鍵を、それに対応する秘密鍵を自分の
クライアントマシンにおき、SSH client を使ってサーバにアクセスします。従って、まず、鍵を生成しな
ければなりません。
鍵の生成は FreeBSD では、ssh-keygen コマンドで行います。OpenSSH では SSH version1 と SSH
version2 に対応していますが、それぞれ RSA1 と RSA2 という少し異なる暗号キーを利用しますので、両
方のプロトコルを使いたい場合には、オプションを変えて 2 回 ssh-keygen コマンドを走らせる必要があり
ます。(DSA 鍵にも対応していますが、現在では推奨されていません。 ) オプションはそれぞれ、RSA1 な
らば -t rsa1 を、RSA2 ならば -t rsa を指定します (普通は RSA2 を作成します)。
%ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kanayama/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/kanayama/.ssh/id_rsa.
Your public key has been saved in /home/kanayama/.ssh/id_rsa.pub.
The key fingerprint is: d5:7e:39:97:18:a1:dd:ea:5f:f7:2c:ff:90:2a:bd:47
[email protected]
%ssh-keygen -t rsa1
Generating public/private rsa key pair.
Enter file in which to save the key (/home/kanayama/.ssh/id_rsa):
...
どちらも最初の質問には単にリターンを入力するだけです。デフォルトで、公開鍵は~/.ssh/id_rsa.pub
(RSA2 の場合) あるいは~/.ssh/identity.pub (RSA1 の場合) に、秘密鍵は~/.ssh/id_rsa (RSA2) ま
たは、~/.ssh/identity (RSA1) に保存されます。次の質問にはパスフレーズを 2 回入力します。公開暗
号鍵方式では、公開鍵と秘密鍵のペアで暗号化と復号化を行います。公開鍵は文字通り誰にでも公開する
ので、秘密鍵を秘密にすることが重要になります。もし、秘密鍵が流出してしまったら、即座にそのペア
の使用を止めなければなりませんが、気づかなかったらお終いです。そこで、秘密鍵を共通鍵暗号で暗号
化して、もしも流出しても、直ぐには解読できないようにします。そして、その共通鍵はどこにも電子的
にはおいておかないようにします。こうすれば、この共通鍵が盗まれる心配は格段に減りますので、結果
として秘密鍵の安全性も高まります。この秘密鍵を暗号化する共通鍵が、パスフレーズなのです。
パスフレーズは空白を用いることもできますが、以上のことから推奨されません。また、あまりにも短
いと簡単に解読されてしまいます。そこで、なるべく長いものを入力する必要があります (勿論、忘れたら
公開鍵を再度作成しなおすしか方法はありません)。パスワードとの違いは、空白を含めて入力でき、事実
上長さに制限がないことです。ですから忘れないもので、なるべく長い (16 文字程度以上が良い) ものが必
要です。もし、あまりにも短いパスフレーズを入力すると、下の画面のように
12.1. SSH の基本設定
171
passphrase too short: have 4 byetes, need > 4
Saving the key failed: /home/kanayama/id_rsa
というメッセージが出て、鍵の保存が出来ません。
なお、鍵を複数持ちたい場合には、鍵を入れておくファイルの名前を変更しないと、以前のファイルを上
書きしてしまいます。そのような場合には、ssh-keygen に -f オプションを使ってファイル名を指定します。
%ssh-keygen -t rsa -f other_rsa
...
こうすると、other rsa に秘密鍵が格納され、id rsa.pub に公開鍵が入ります。
次に、これらの鍵を、サーバ側には公開鍵のみを以下のファイルに入れておきます。秘密鍵はクライアント
に用いるマシンのみにおいてください。公開鍵を入れるファイルは誰からも読めるファイルでなければなりま
せんが、公開鍵はいくつでも必要なだけ入れておく事が出来ます。一般には、クライアントマシン側で鍵は生
成し、公開鍵のみをサーバのホームディレクトリに置くようにします。公開鍵は ~/.ssh/authorized_keys
に入れます。秘密鍵はサーバ側に置いていてはいけません。
以下では、ftp などで、サーバ側の ~/.ssh ディレクトリに id_rsa.pub が置かれているものとします。
(勿論、samba などでファイル共有されている場合には、直接サーバ側の.ssh ディレクトリを作成して、
authorized_keys に id_rsa.pub の中身をコピーしてもかまいません。)
> cd
> mkdir .ssh
> cd .ssh
> touch
> chmod
#
authorized_keys
644 authorized_keys
ftp などで、.ssh ディレクトリに id_rsa.pub を転送する
> cat id_rsa.pub
>> authorized_keys
最初に説明したように SSH では様々なコネクションを暗号回線を通じてサーバ側に送る事ができるよう
になっています (X-Window プロトコルですら転送出来ます)。そのために SSH のクライアントソフトに
は多くのオプションがあります。しかし、ここでは SSH を用いて、サーバにログインする方法のみを紹介
します。
SSH version1 でログインする場合には、コマンド ssh を用いて、
> ssh dns.matsue-ct.ac.jp
Enter passphrase for RSA key ’[email protected]’:
のようにします。パスワードの代わりにパスフレーズを聞いて来ます。
SSH version2 の場合は、オプション -2 を指定します。(鍵が RSA2 のみならば、自動で選択されます)
第 12 章
172
SSH(Secure SHell)
> ssh -2 dns.matsue-ct.ac.jp
The authenticity of host ’stu’ can’t be established.
RSA key fingerprint is 0a:c0:43:fe:4f:ab:72:b4:51:e1:f0:08:81:f6:4c:a7.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added ’dns.matsue-ct.ac.jp’ (RSA) to the list of known hosts.
Enter passphrase for RSA key ’/home/kanayama/.ssh/id_rsa’:
なお、始めて入るサーバの場合には相手のサーバ側の公開鍵を確認するメッセージが出て来ます。これ
は、SSH では rsh と同じことを安全に行うために、マシン自体の認証も行うからです。yes と答えておけ
ば良いでしょう。すると、パスフレーズの入力が促されます。後は、通常の telnet と同じように使う事が
出来ます。
参考
相手サーバの公開鍵は~/.ssh/known_hosts に保存されます。
また、クライアントでのユーザ名と、サーバでのユーザ名が異なる場合には、陽にサーバ側でのユーザ
名を指定しなければなりません。その場合には以下のようにホスト名の前にユーザ名を指定します (区切り
には@を用います)。
> ssh -2
[email protected]
ちなみに、サーバ鍵が異なっている場合、サーバが DNS クラックやその他の攻撃による成り済ましの
可能性があるために、通常はサーバ鍵が違うことが表示されて接続が出来ません。もし、サーバの入れ替
えやサーバの SSH のアップデートなどのために鍵が変更されていることが確実である場合には、新たに
サーバ鍵を受け入れる必要があります。これには、~/.ssh/known_hosts からそのサーバの鍵を削除すれ
ば良いでしょう。サーバ鍵は known hosts の中に、ひとつのサーバが一行に対応する形で保存され、行頭
にサーバ名が書かれています。
dns.matsue-ct.ac.jp ssh-rsa
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXX
表示では数行あるが、改行がないため実際には一行
XXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX==
12.2
SSH の進んだ使い方
SSH(Secure SHell) を使って他の通信を暗号化したり、便利に使うための tips を紹介する。
12.2.1
Agent
ssh を使う度にパスフレーズを入力しなければならないのは面倒である。しかし、かと言ってパスフレー
ズをファイルに保存しておくのは危険である。何故ならば、SSH では公開暗号鍵方式を利用しているが
(RSA や DSA は暗号の方式の違い)、秘密鍵が盗まれてはセキュリティは簡単に破られてしまう。そこで、
秘密鍵自身を更に暗号化し、秘密鍵を読めなくしてしまう事が考えられた。当然、正式なユーザーはソフ
12.2. SSH の進んだ使い方
173
トウェアを通じてその秘密鍵が読めなければ困るので、秘密鍵を読めるようにするための更なる鍵がパス
フレーズなのである。従って、パスフレーズだけは保存されてはならないのである。保存してはならない
が、何度も入力するのが面倒だという事から、メモリ上に常駐したソフトがメモリ内部にのみパスフレー
ズを記憶するという方法が考え出された。このソフトウェアが ssh-agent である。ssh-agent は一度だけ
キーボードからの入力が必要であるが、以降は復号した秘密鍵を用いて認証を行うようにしてくれる。但
し、Unix 上のどのプロセスに対してだったら、そうした肩代りをしても良いのかを判断するのは非常に困
難であるので、ssh-agent が謂わば親プロセスである場合にのみ (つまり、自分の子プロセスに対して) 肩
代りするようになっている。
> ssh-agent kterm -km euc &
上の例は、Kterm を子プロセスとして走らせ、その中での認証を agent を通じて行えるようにする (但
し、次の ssh-add を実行しないとやはり通常通りパスフレーズを聞いているので注意！)。
次に、肝心のパスフレーズの入力であるが、以上のようにして走らせた kterm の中で ssh-add を実行す
ればそのパスフレーズを元にして秘密鍵の復号を試み、成功すれば認証エージェントにその秘密鍵を追加
する。
> ssh-add
もし、端末を一時的に離れるような場合には agent にパスワードロックをかけることができる。
> ssh-add -x
Enter lock password:
Again:
Agent locked.
解除する場合には、
> ssh-add -X
Enter lock password:
Agent unlocked.
とする (X は大文字)。勿論、ここでロックしているのは認証エージェントのみなので、 ssh を起動して
正しくパスフレーズを入力すれば、やはり利用できるのは言うまでもない。
ここまでは子プロセスとして kterm などを指定してきたが、X のセッション自体を ssh-agent の子プロ
セスとすることもできる。この場合、以下のように使う。
> ssh-agent startx
これを alias として登録しておくのも良い。.cshrc などに、
alias startx
などとする。
ssh-agent startx
一方、KDE などのようなものの場合には、.xinitrc の最後の行を以下のように書き換えるのも良い。
exec ssh-agent startkde
第 12 章
174
12.3
SSH(Secure SHell)
ファイル転送
SSH のプロトコルを用いて、ファイルを転送するために sftp や scp というプログラムが用意されてい
ます。それぞれ、sftp は ftp の代わりとして、scp は rcp の代わりとして使う事が出来ます。
# sftp [email protected]
sftp で RSA1 を利用したい場合にはオプション -1 を指定します。接続すると、パスフレーズを聞かれ
ます (ssh-agent を使っていれば聞かれません)。後は、通常の ftp と同じようにインターラクティブにコマ
ンドを入力します。
sftp> get
...
hogehoge
sftp> quit
一方、scp はターゲットを指定してファイルをコマンドレベルで転送します。
# scp
kanayama@wiz:/home/kanayama/hogehoge
./hogehoge
ターゲットの指定は、
(ssh ユーザ名)@(サーバ名):(ディレクトリ)
なお、ssh ユーザ名はローカル名と同じであれば、省略しても構いません。ファイルを相手先に転送する場
合には、逆に、
# scp ./horehore kanayama@wiz:/home/kanayama/horehore
のようにします。
12.4
Forward
SSH には最初に説明したように、別の通信を暗号化して相手に送る ( あるいは逆) を行うためのいわば
土管のような機能がある。自分のあるポート番号へのアクセスを土管に通して、相手のホストのあるポー
ト番号へのアクセスへと結合させることをローカルフォワード (local forward) と言う。逆に、相手のホス
トのあるポート番号への誰かからの通信を、土管を通して自分のあるポート番号へのアクセスへと結合さ
せることをリモートフォワード (remote forward) と言う。
まず、ローカルであろうと、リモートであろうとフォワードの設定は ssh の起動時に一度に行う。
ローカルフォワードの設定は以下のように行う。
て、HOST の HISPORT に送られる。具体的には、
ssh -2 -l kanayama -L MYPORT:HOST:HISPORT dns.matsue-ct.ac.jp
この設定によって、クライアント (自分のマシン) の MYPORT にアクセスする通信は全て暗号化され
ssh -2 -l kanayama -L 2025:dns.matsue-ct.ac.jp:25 dns.matsue-ct.ac.jp
12.4. Forward
175
は、自分の 2025 番ポートへのアクセスは、dns.matsue-ct.ac.jp の 25(mail) 番ポートへのアクセスへと
届けられる。
但し、この場合でも dns.matsue-ct.ac.jp への ssh 仮想端末は割り当てられるので、これを禁止すること
もできるが、単に ^Z を押して中断し、bg コマンドでバックグラウンドジョブにしても良い。
以下の例はリモートフォワードの例であるが、dummy の 8080 番へのアクセスは、暗号回路を使って
クライアント (自分の) マシン上から hogehoge まで届けられ、その後 dummy の 8080 ポートへのアクセ
スへと届けられる。つまり、hogehoge から dummy までの間では全く暗号化はされていない点に注意し
よう。これは、ローカルフォワードの場合でも同じで、上の例ではポートの転送先が ssh で接続している
サーバと同じであったので、そうした問題がなかったのである。
ssh -2 -l kanayama -R 8080:dummy:8080 hogehoge
参考
サイトの外部から、サイトの内部に ssh でアクセスするが、更に別のマシンに ssh でアクセスした
いような場合には、ssh の土管の中に、ssh のアクセスを通すというトリッキーなことをすれば可能
になる。
第 12 章
176
12.5
SSH(Secure SHell)
演習
演習 12.1 全員、同じグループのメンバーのアカウントを作成しなさい。パスワードは共通で作成しなさい。
演習 12.2 /etc/rc.cof に
sshd_enable="YES"
を設定した上で、
# /etc/rc.d/sshd start
を実行しなさい。
演習 12.3 同じグループの他のマシン全てに ssh でログイン (共通パスワードで) し、パスワードを自分独
自のものに変更しなさい。
演習 12.4 SSH の設定を行い、公開鍵、秘密鍵を作成して下さい。作成したら、sftp を用いて、公開鍵を
同じグループの全てのマシンに転送しなさい。
sftp>
sftp>
mkdir
cd
sftp>
put
.ssh
.ssh
id_rsa.pub
authorized_keys
のようにして、相手 PC に公開鍵を送ります。
その上で、今度は ssh でログイン出来るかどうかチェックして下さい。(今度は公開鍵が相手側にあるの
で、パスフレーズで入れる筈です)
演習 12.5 ssh-agent を用いて、パスフレーズの入力を簡略化してみよ。出来たら、コマンドラインで、ssh
を入力するところから、’Welcome to FreeBSD!’ が表示されるまでをカット＆ペーストして提出しなさい。
(当然、パスフレーズの入力が表示されていない筈です)
177
第 13 章 DNS I
DNS(Domain Name System) は分散型データベースであり、その役割はホスト名と IP アドレスを対応
づけることにあります。本章では、この DNS の基本的な理解と通常使うために必要な設定について述べ
ます。
13.1
名前解決とは
名前解決 (name resolution) とは、その名前のとおり、インターネット上で使われる名前から実際の IP
アドレスを割り出し、目的のサービスに接続するための直接的アドレス (IP アドレスなど) などを言う。勿
論、一般的にはインターネットだけには限らず、何らかの情報空間でそれを行うことを意味しているが、こ
こではネットワーク上での問題解決を指すものとする (これ以外ではプログラミング言語における名前解
決などもある)。
13.2
ローカルな名前解決
名前解決にはその名前を解決しようとしている範囲が問題になる。例を挙げるなら、松江高専の 4 年生
の中で田中という人の名前が誰かというのを特定する場合、その範囲は、4 年生という範囲であるが、松
江市内全体で田中を解決しようとすると該当者は非常に多数の人数に上るだろう。このように名前が特定
のものを指しているかどうかは、その対象としている範囲に大きく依存している。
インターネットの初期の段階でも、少ないとは言え IP アドレスをそのまま指定するのは面倒であったの
で、覚えやすい名前で代用することが考えられたが、その際に名前と IP アドレスの対応は、ローカルファ
イルに記憶させ、従ってローカルに解決 (自分が覚えているかどうか) させるという手段が最初になされた。
このローカルなファイルは hosts ファイルと言い、Unix などでは /etc/hosts に Windwos などでは C:
￥WINDOWS￥system32￥drivers￥etc￥hosts にある。以下に、FreeBSD での例を掲げる。
# Host Database
#
# This file should contain the addresses and aliases for local hosts that
# share this file.
# machine.
Replace ’my.domain’ below with the domainname of your
#
# In the presence of the domain name service or NIS, this file may
# not be consulted at all; see /etc/nsswitch.conf for the resolution order.
#
#
::1
127.0.0.1
localhost localhost.my.domain
localhost localhost.my.domain
第 13 章
178
DNS I
行頭の # はコメント行の意味で、実際に有効になっているのは最後の 2 行の ::1 localhost と 127.0.0.1 localhost
のみである。前者の ::1 は、IPv6 における自分自身を表すアドレスであるので、ここでは省略する。次
の行の意味は、localhost という名前は IP アドレス 127.0.0.1 だという意味で、このアドレスは常に自分自
身を表す特別な IP アドレス (IPv4) として決められている。従って、次のような URL は、
http://localhost/
自分自身のウェブサーバへのアクセスを意味している。
さて、インターネットの初期の話に戻ると、このような hosts ファイルに全てのマシンの IP アドレスを
記述するというやり方は、もし新しいマシンの登録や、更新があった場合、全ての関係するマシンの hosts
ファイルを書き換えるという作業を意味していた。実際、初期においては、全てこの hosts ファイルを毎
回毎回配布するという作業をしていたのだが、接続するマシンが増えるに従って、こうした作業に要する
手間は無視できなくなり、非現実的な作業にとなっていったのである。そこでこれを解決するために、ネッ
トワーク上で名前を解決するシステムが考案されたのだが、それは次の節で解説することにして、上記の
ようなローカルに置かれたファイルを参照して、名前を解決することをローカルな解決と呼んでいる。
さて、実は多くのテキストには名前解決でローカルな解決というとここまでであるのだが、実際には先の
URL などを解決しようとすると、このローカルな IP アドレスの解決だけでは済まないことが分かる。それ
は、http:// にある http という略語である。これは一体どういう意味なのかというと、実はこれもローカ
ルに解決がされているもので、Windows では先の C:￥WINDOWS￥system32￥drivers￥etc￥services
に記述があり、Unix では/etc/services に記述があるのだが、ポート番号と名前の対応表となっている。
以下に FreeBSD にあるファイルの一部を掲げる。
ftp-data
20/tcp
#File Transfer [Default Data]
ftp-data
ftp
20/udp
21/tcp
#File Transfer [Default Data]
#File Transfer [Control]
ftp
ssh
21/udp
22/tcp
#File Transfer [Control]
#Secure Shell Login
ssh
telnet
22/udp
23/tcp
#Secure Shell Login
telnet
#
23/udp
24/tcp
any private mail system
#
smtp
24/udp
25/tcp
any private mail system
mail
#Simple Mail Transfer
smtp
# 中略
25/udp
mail
#Simple Mail Transfer
http
80/tcp
www www-http #World Wide Web HTTP
http
80/udp
www www-http #World Wide Web HTTP
このようにサービスのポート番号とサービスの名前も一種の名前解決であるが、実際にはどのようにし
て解決するかは OS によって異なっている。Windows でのサービスの名前の解決は非常に複雑であり、こ
こでは取り上げないが、Unix などでは古くからローカルな名前解決 (つまりは /etc/services を参照する)
が中心になっている。
以上のようにして、URL の http という名前は、ポート番号 80 番に関連付けられているのである。
では、80 番以外の番号で動いているウェブサーバへのアクセスはどうすれば良いのかというと、以下の
ように URL を指定することになっている。
13.3. Domain Name Service
179
http://hogehoge:8080/
ホストの名前の後ろにコロンをつけて、その後ろに 8080 とポート番号を指定することで、このサービ
スは http だがポート番号は標準と異なり、8080 番であることを明示しているのである。
参考 hosts ファイルでのローカルな解決は Windows でも有効で、全ての名前解決よりも優先して用いら
れる。つまり、hosts ファイルに存在すれば、それが用いられて、他の解決は利用されない。それを
悪用して、ウィルスの一部ではアンチウィルスソフトのアップデートが不能になるように、アンチ
ウィルスサーバの名前を以下のように自分自身に指定するというものがあった。
127.0.0.1
update.server
# update.server がアップデートで用いられるサーバ
勿論、自分自身にそのようなサービスはインストールされていないので、毎回アップデートに失敗
し、その結果アンチウィルスソフトのデータは古いままで、新しいウィルスを駆除できなくなったの
である。
13.3
Domain Name Service
名前の IP アドレスを解決するために、ローカルなファイルによる解決を続けられなくなったときに、イン
ターネット上で IP アドレスを解決するためのサービスとして登場したのが DNS (Domain Name Service)
である。ここで DNS に求められた機能は、名前を IP アドレスに変換することであるが、IP アドレスは唯
一なものであるので、対応する名前もインターネット上で唯一であることを保証することであった。同時
に、サービスとしての DNS はインターネット上で分散して稼動している必要があった。実際、一台に集中
しているとそのサーバが落ちた場合にも困難が生じるし、管理としてもインターネット上の名前をたった
一台サーバで管理するのは困難であるからである。 DNS はこれを解決するために、階層構造を採用するこ
とで、これらを同時に解決している。
DNS では、全ての名前をファイルシステムのようにして管理する。ファイルシステムでは、名前は、
/home/staff/kanayama
のように左から / をセパレータとして一意に決まる。同時に、最初のセパレータ/はツリー構造の出発点
であるルートの意味も持つ。一方、DNS では右から出発する。
www.matsue-ct.ac.jp.
は、jp,ac,matsue-ct,www の順に、名前構造としてはより深い名前へと並び、ディレクトリ構造における
ルート/の役割は、一番右の . が持ち、. は同時にセパレータとしての役割も持っている。ディレクトリに
相当する jp や matsue-ct という名前はドメインと呼ばれる。各ドメインは、より下位のドメインを含む
（例えば、jp ドメインは ac ドメインを含む）。しかしながら、ドメインのサーバは下位の全てのドメイン
のデータを持つわけではなく、下位のドメインの情報を掌握するサーバのデータのみを持ち、そのドメイ
ン内部のデータはそのサーバが持つ。このように、ドメインは下位のドメインの情報を最小化して持つの
で、ドメインという言葉に対して、実際にドメインのサーバが管理する情報範囲をゾーンと呼ぶ。このよ
うな方法によって、各ゾーンはそれぞれの名前を管理しながら、同時に下位のゾーンは下位のサーバに、
その名前の管理を任せることができるようになっているのである。
第 13 章
180
DNS I
. (root DNS)
de.
jp.
com.
fr.
google.com.
ne.jp.
co.jp.
go.jp.
ac.jp.
matsue-ct.ac.jp.
www.matsue-ct.ac.jp.
上の図のように、DNS における名前は上位からツリーがたどれるようになっており、例えば図の www.matsue-ct.ac.jp.
のような名前は FQDN (Fully Qualified Domain Name) と呼ぶ (通常、com. などは FQDN とは呼
ばず、IP アドレスに変換できるような名前を FQDN と呼ぶ)。このように名前（FQDN) は厳密にはルー
トからの順位を表す. を末尾に持つ。これはディレクトリ構造の絶対パスに相当する。一方、我々は通常
こうした絶対パスを使用せず、www.matsue-ct.ac.jp , www のように末尾のルートドメインや自ドメイン
名を省略して利用しているが、これは一つにはデフォルトドメインが適用されて解釈されていることと、
DNS 自身にある程度のドメイン名に対する補完機能があることに由来する。つまりは、こうした省略は、
DNS サーバの提供する機能によって実現しており、 DNS 的には末尾のドットがついたものが正式なもの
である。
実際に、DNS における名前 (FQDN:Fully Qualified Domain Name, 完全修飾ドメイン名) は、厳密には
ルートからの順位を表す. を末尾に持ちます。これはディレクトリ構造の絶対パスに相当します。
先の例に戻ると、www.matsue-ct.ac.jp は matsue-ct.ac.jp の DNS が管理しており、この DNS サーバ
に問い合わせることで最終的に IP アドレスを得ることができるようになっている。従って、mastue-ct.ac.jp
の管理者が IP アドレスを変更する必要があれば、上位の DNS には無関係に、IP アドレスを変更できる
ようになっており、新しい名前を作成したければそれも上位に断りなく作成できるようになっている。こ
のように DNS での管理と名前は密接に関係しており、それぞれのゾーンで独自に拡張や保守が可能になっ
ている点に特徴がある。逆に言うと、各ドメインの管理者が管理すべき情報は、ゾーンについての情報と
なりますが、少なくとも下位ドメインのサーバについての情報を含まれなければなりません。このことか
ら、DNS サーバは任意に立ち上げても意味を持たず、上部のゾーンへの登録が必要です (もちろん、勝手
に立ち上げても実際には利用されませんので、あまい良いことはありません)。
DNS において、ホスト情報を保持しリクエストに対して情報を提供するものを DNS サーバ、あるいは
ネームサーバと呼んでいる。一方、リクエストを出す側をリゾルバと呼び、これは個々のノードに実装さ
れている (例えば Windows や Mac にも標準で入っている)。従って、アプリケーションがある FQDN を指
定した場合、そのマシン上のリゾルバが、設定された DNS(通常そのネットワーク内のローカル DNS) に
問い合わせを行う。DNS サーバは、そうした問い合わせに対して、自身が持っている情報では応えられな
い場合には、ルート DNS から順に検索を行い、それぞれの DNS に問い合わせを行いながら、最終的に
13.4. サーバの設定
181
IP アドレスを得て、クライアントのリゾルバに応答を返すようになっている。
DNS サーバは通常一度応答した結果に対しては一定時間それを記憶しておくことで、再度の問い合わせ
に対して効率的に応答するようになっているが、それでもルート DNS には世界中からの問い合わせに応え
なければならないので、非常に大きな負荷がかかることになる。そのために、ルート DNS は同じ内容を
持った複製が世界中に 13 台あり、その 13 台も国によっては更に複製されて大きな負荷に対応するように
なっている。また、このキャッシュというシステムは一方では、DNS 情報がある時点で変更された場合、
それがすぐには反映されないことにもなりますので、注意する必要があります。
通常、DNS においては名前から IP アドレスへの変換が主ですが、逆に IP アドレスから名前への変換
も提供されています。前者を表引き (正引き) と呼び、後者を逆引きと呼ぶこともあります。IP アドレスを
DNS のメカニズムで検索するためには、FQDN と同じ名前空間を考えます。FQDN では上位のものは右
にあることを思い出せば、IP アドレスもより上位の区分を右に配置すれば DNS の検索アルゴリズムに適
合することがわかります。たとえば、172.16.0 は DNS 的には 0.16.172 となります。もちろん、これだ
けでは FQDN との区別がつかないので、末尾に (DNS の世界での上部に).in-addr.arpa を付け加えてホ
スト名と区別します。つまり、0.16.172.in-addr.arpa が DNS 的な 172.16.0 のゾーンの名前になる訳
です。
13.3.1
DNS サービス
DNS はサービスである。従って、そのプロトコルが決められており、ここではその詳細には立ち入らな
いが、UDP によって通信を行うことになっている。UDP では、TCP のような開始や終了の手続きが不要
であるために、非常に簡単に利用することができ、負荷の集中しやすい DNS にとって少しでも軽く処理を
行うための方法となっている。DNS に対するリクエストは、一つのパケットで飛び、DNS もその返答 (リ
プライ) を一つのパケットで返すようになっている。DNS サービスのポート番号は 53 番を用いることに
なっているのだが、当然 DNS サーバが落ちていたり、DNS サーバに到達できない場合には名前を解決す
ることができず、そのためにウェブやメイルが利用できないこともある。このような場合には、IP での通
信は可能であり、インターネットに到達できない訳ではないので、区別が必要である。
13.4
サーバの設定
ネームサーバは複数置くことができ、それによって負荷の分散を図ることができます。それら複数のネー
ムサーバのうち、情報の変更などの権限を持つ主となるサーバをプライマリ (ゾーン) サーバと呼び、プラ
イマリサーバと同じ情報を持ち、サービスとしてはプライマリサーバが故障などの場合に同じ役割を果た
すサーバをセカンダリ (ゾーン) サーバと呼びます。
DNS サーバの Unix における、そして世界的に最も普及している実装は BIND (Berkeley Internet Name
Domain) です (一説によれば 80%以上のシェアを占めていると言われています)。FreeBSD8.2R での標準
は 9.6.3 であり、既に標準でインストールされているので、以下のようにしてバージョンをチェックでき
ます。
# named
-v
BIND 9.6-ESV-R3
babababababababababababababababababababab
第 13 章
182
DNS I
(One Point)
新しい BIND10 では、プログラムが全面的に書き直され、全く新しいものになる予定で、DHCP
などとの一体化や高速化など様々な機能を持つことが検討されています。
以下、BIND9 について説明を行います。
BIND の最新ソースや情報は [?] から入手できます。BIND を実際に動かすには、インストールが終了し
た後にさらに設定ファイルを書かなければなりません (もちろん、本格的に動かすには上位のドメインでの
登録などが必要です)。
BIND9 のサーバプログラムは/usr/sbin/named です。設定ファイルは、named 自身の設定ファイル
/etc/namedb/named.conf (実は、FreeBSD5.0-RELEASE から/var/named/etc/namedb/ 以下に本体は
移されており、シンボリックリンクが張られています) と、ゾーン情報を記述したマスターファイル、及び
ルートネームサーバの位置情報を記述したヒントファイルから構成されます。
13.4.1
プライマリゾーンサーバ
conf ファイル 1 (BIND8,9)
プライマリゾーンサーバにおける /etc/namedb/named.conf の簡単な例をつぎに示します。
なお、デフォルトで用意されているファイルを編集するのは止めた方が良いでしょう。 なぜなら、コメ
ントアウトなどが複雑にされているので、初めて編集する場合ミスが多くなってしまいます。デフォルト
ファイルを利用したいならば、カット＆ペーストする方が良いでしょう。
13.4. サーバの設定
183
options {
directory "/etc/namedb";
// query-source address * port 53;
allow-query { any; };
allow-transfer { 172.16.1.1; 172.16.1.2; 172.16.1.3; };
};
zone "." {
type hint;
file "named.matsue";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};
zone "j4-00.matsue-ct.ac.jp" {
type master;
file "j4-00.zone";
};
zone "1.16.172.in-addr.arpa" {
type master;
file "172.16.1.rev";
};
新しい BIND から C 言語的な記述になっており、コメントは C 言語的な/* comment */ や、C++的な
// comment [行末] 、さらにシェル的な # comment [行末] が利用できます。
各設定は全て C 言語的な { }で囲み、それぞれの記述は ; で終わります。さらに、}も; で終わる事に
注意しましょう。
オプション設定
オプション設定は、全て options {...}; の中に記述します。さまざまなオプションが指定できま
すが、基本的には上に上げた 4 つ程度で良いでしょう。
directory
ゾーン情報が置かれるディレクトリを指定します。デフォルトは、named.conf と同じディレク
トリ (標準では /etc/namedb )。
query-source
問い合わせをする際に以前の DNS は発信元ポートが 53 に固定されていましたが、新しい BIND
では通常の発信と同じく固定されていません。ファイアーウォールなどでこの 53 番ポートが禁
止されている場合に指定します。
第 13 章
184
DNS I
allow-query
このサーバへの問い合わせに答えるホストアドレスのリストを指定します。このリストにマッ
チしない相手からの問い合わせは全て拒否されます。内部 DNS などで外からの問い合わせに答
えてはいけない場合や、セキュリティ上答えたくない場合などに指定します。例では、any(す
べての問い合わせ) に答える (実はこれがデフォルト設定)。172.16.0.0/16 からの問い合わせ
のみに答えるような場合には、つぎのように書きます。
allow-query { 172.16.0.0/16; };
allow-transfer
ゾーン転送に応じる相手を指定します。相手はアドレスリストで指定できます。ゾーン転送は、
プライマリサーバからセカンダリサーバ間で DNS サーバが保持するデータを同期する際に行わ
れます。通常、ゾーン内部、あるいはセカンダリのみを指定しておくと良いでしょう。例では、
172.16.1.1, 172.16.1.2, 172.16.1.3 に対してのみゾーン転送を許可しています。
アドレスリスト
アドレスリストは ; で区切って複数指定でき、最初の指定からマッチするまで順にトライしま
す。IP ネットワークで指定したい場合には、ネットマスクを/の後ろに指定します。たとえば、
172.16/16 は 172.16.*.*にマッチします。逆に、除外する場合には先頭に!を書きます。たと
えば、!10/8 は 10.*.*.*を全て否定します。注意するべきは、先頭から順にマッチするかどう
かを調べるので、any; !10/8; は先に全てにマッチしてしまい 10/8 を除外できません。正し
くは、逆に!10/8; any; と書かねばなりません。
ヒントファイルの指定
ルートネームサーバのリストが書かれたファイルを指定します。実際に Internet に接続して動かす場合
には、InterNIC から最新のファイルを入手する必要があります (最新のファイルは ftp.rs.internic.net
の/domain/named.root に置かれています)。通常、最新版の BIND が入っている場合にはデフォル
トで既に設定されており、名前は named.root になっています。また、通常は入手したファイルを変
更する必要はありません。ただし、独自のルートサーバを内部 DNS 用に立ち上げる場合には変更が
必要となります。
ゾーンファイルの指定
ゾーンのドメイン名を zone の後に記述し、その情報についての指定をブロック内部に行います。こ
こに書かれるドメイン名をデフォルトとして、ゾーンの処理が行われます。
type
ゾーンのプライマリ、セカンダリの指定を行います。プライマリの場合は master、セカンダリ
の場合は slave です。
file
ゾーン情報が記述されたファイルを指定します。ファイル名は任意ですが、わかりやすい名前が
良いでしょう (マスターファイルという)。なお、最近の BIND の書き方としては、/etc/namedb
の下の master ディレクトリの下にゾーンファイルを置くようにしているようです。そのため
に、標準のファイルでは、以下のような指定を行っています。
file "master/sample.zone";
この場合、標準のディレクトリは ’/etc/namedb’ で、file で’master/sample.zone’ を指定して
いるので、実際のファイルは’/etc/namedb/master/sample.zone’ になります。
13.4. サーバの設定
185
ちなみに、options で指定した allow-query や allow-transfer をここのブロック内部に記
述することもできます。何も書かなければ、options で指定された内容が適用されます。一方、
新しい Dynamic DNS に関連した指定で、allow-update がありますが、Dynamic DNS はこ
こでは利用していません。デフォルトでは allow-update は {none;}になっています。
oss00.zone
named.conf
zone
"oss00.matsue-
ct.ac.jp" {
zone の "#
メ ンバ ー (
の )*
type master;
file "oss00.zone";
};
zone
"1.16.172.in-
172.16.1.rev
addr.arpa" {
type master;
file "172.16.1.rev";
};
zone の" #
メン バ ー(
の) *
+ ,zoneの - .
図 13.1: DNS の設定ファイルの構造
逆引き
先に説明した逆引きも必要に応じて指定します。とくに、localhost の逆引きは通常必要なので注
意しましょう。また、逆引きの際のドメイン名の指定方法にも注意しなければなりません。
ゾーン情報
j4-00.matsue-ct.ac.jp ドメインのゾーン情報ファイルの例をあげます。
第 13 章
186
DNS I
$TTL 86400
@
IN
SOA
dns.j4-00.matsue-ct.ac.jp. admin.j4-00.matsue-ct.ac.jp. (
2009110401
10800
;
;
Serial
Refresh after 3 hours
3600
604800
;
;
Retry after 1 hours
Expire after 1week
86400 )
IN
; Minimum TTL of 1day
NS
dns.j4-00.matsue-ct.ac.jp.
IN
IN
NS
MX
localhost
IN
IN
MX
A
pc01
IN
A
mail
dns
IN
A
86400 IN
pc02
www
IN
IN
A
A
172.16.1.2
172.16.1.2
pc03
pc04
IN
IN
A
A
172.16.1.3
172.16.1.4
10
20
pc02.j4-00.matsue-ct.ac.jp.
pc01.j4-00.matsue-ct.ac.jp.
pc02.j4-00.matsue-ct.ac.jp.
127.0.0.1
172.16.1.1
A
172.16.1.1
172.16.1.1
ゾーンの情報ファイルのれぞれのエントリは DNS 資源レコードと呼ばれます。資源レコード (RR) には
本来順序はありませんが、通常 SOA レコード、NS レコード、その他のホストに関するレコードの順に書
かれます (これは省略などの関係で守った方が良いでしょう)。
各レコードは空白 (スペース、タブ) によってフィールドに分けられます。情報ファイルにおいては、フィー
ルドの位置は固定であり、したがって、行頭に空白があるかないか (第 1 フィールドを省略したと見なす)
は決定的に重要である点に注意しなければなりません。
コメントは; で始まり、行末までです。
各レコードはつぎのようなフィールドからなりますが、第 1 フィールドが$ で始まるときはディレクティ
ブと呼ぶ指令で、資源レコードとは異なります。
表 13.1: DNS 資源レコード
名前
TTL
クラス
資源レコードのタイプ
.
— ドメイン名 空白
数値、空白
IN
SOA NS A PTR CNAME MX など
レコードの情報
さらに、レコードは行単位で記述されますが、行末が ( で終っている場合には続く行は継続行とみなさ
れ、 ) が出現するまで継続されます。
1. $TTL
全てのレコードは TTL(time-to-live) を持ち得るが、明示的に指定されていない場合は、この $TTL
13.4. サーバの設定
187
で指定した値がデフォルトとして利用されます。 $TTL 文がない場合には、SOA の最小値が使用さ
れますが、警告が出るようになります。なお、ここで言う TTL は、全てのネームサーバで該当レ
コードがどれだけの時間キャッシュしておいて良いかを示すものです。この値が短ければ、自サイト
の DNS レコードの変更は素早く他のサイトに反映されますが、一方で当然 CPU 資源はその分消費
されることになります。
2. $INCLUDE
例には記述していませんが、別のマスターファイルを $INCLUDE を記述した位置に取り込む事ができ
ます。その際に、後で説明するオリジンの解釈が変更されると困る場合があるので、取り込むファイ
ルのオリジンを指定できるようになっています。もし、取り込んだファイル自身の内部にオリジンの
記述も、このオプションでのオリジンの指定も無ければ、カレントオリジンが設定されます。
$INCLUDE
filename
[origin]
[comment]
3. SOA レコード
SOA は Start Of Authority の略で、そのゾーンに関するもっとも信頼できる情報源であることを示
し、必ず一つのエントリが各ゾーンファイルに対して必要です。例の SOA レコードでは、( ) で囲
むことによって、レコードを複数行に拡張していますが、何もなければ通常一行が一レコードに対応
します。第 1 フィールドの @はカレントオリジン (起点名) の省略形で、例では conf ファイルで指定
したこのゾーンのドメイン名 j4-00.matsue-ct.ac.jp. のことを意味しています。第 4 フィールド
はこのデータを作成したホストマシン名であり、第 5 フィールドは最初の . を @ に変更すると、通
常 DNS マスターのメイルアドレスとなります。ここで、FQDN が絶対名で (つまり、末尾に. がつ
いた形で）書かれていることに気づいたでしょうか？DNS では、FQDN で書く場合には必ず絶対名
で書かねばなりません。その理由は後述します。
また、括弧 (( )) で囲まれた値のうち、Serial は named が読み込み記憶するデータに対して付けら
れるシリアル番号です。もしも、ゾーンファイルを修正してそれらを実行中の named に反映させた
い場合には、必ずシリアルを変更した上で、kill -HUP を named に送らなければなりません。なぜ
なら、シリアルが変更されていない場合には、そのゾーン情報には変更がないと見なされ、データの
再初期化が行われないからです。シリアル番号は、整数値として扱われ、新しいものは必ず以前より
番号が大きくなければならない点に注意して下さい。また、値は１０桁までです。そのほかの値は全
てセカンダリサーバとのゾーン転送に関するもので、ここでは詳しくは触れません。
4. NS レコード
NS レコードはネームサーバに関する情報です。この例では、第 1 フィールドが空白であることに注意
して下さい。これは省略記法で、空白である場合には、直前のレコードの名前が適用されます。今の
場合には、直前のレコードは、SOA レコードであるので、@ (つまり起点名 - j4-00.matsue-ct.ac.jp.)
が使われます。第 4 フィールドはネームサーバの FQDN です (ここでも絶対名が使われている点に
注意)。この名前は、後のホスト情報のレコードで解決されます。また、ネームサーバは複数を指定
することができ、例のように順に列挙すればその順にアクセスされます。
5. MX レコード
MX(Mail eXchanger) レコードはメイル配送のための特殊なもので、他のレコードとは違い第 4 フィー
ルドにプリファレンスという非負の整数値を持ちます。メイルの配送において、配送プログラムはメ
イルアドレスのホスト部を DNS から決定しようとしますが、もし、そのメイルサーバが落ちていた
場合は配送されずエラーとなってしまいます。こうした事態を避けるために、複数のメイルサーバを
第 13 章
188
DNS I
用意するのは良い考えですが、送る側はどうやってそのメイルサーバを検出したら良いのでしょう
か？この問いに答える仕組みが MX です。つまり、具体的なホスト名ではなく、仮の名前を用いる
ことにし、DNS を使ってその仮の名前に対する実際のホストを答えるようにしているのです。もし、
そうやって得られた最初のメイルサーバが応答しない場合には、つぎのホストを答えます。つまり、
先のプリファレンス値はその優先順位を表しています。では、この仮の名前はどういう名前が良いの
か、という事ですが、通常はドメイン名そのものにしておけば良いでしょう。つまり、この例では、
MX レコードの第 1 フィールドは空白なので、それ以前の名前である j4-00.matsue-ct.ac.jp が使
われます。したがって、メイルアドレスは [email protected] のようなものになり
ます。もちろん、仮の名前は dummy.j4-00.matsue-ct.ac.jp のようなものでもかまいません。メ
イル配送プログラムは、最初はこれがホスト名だと仮定して DNS を検索し、失敗したらつぎに MX
レコードから検索するからです。しかし、もし、この名前が実際に存在するホスト名だったら困った
ことになります。そうした事態を避けるために、通常はドメイン名そのものを用いて、ユーザーから
見ても簡便なメイルアドレスとなっています。なお、プリファレンス値は 0 以上であれば小さいもの
から順になるので、0,1,2... とつけても良いし、この例のようにしてもかまいません。ただ、現実
には、緊急時に他の MX を追加できるように例のような書き方の方が推奨されています。
6. A レコード
A レコードはホスト情報に関係するものであり、実際の IP アドレスはここに記述します。ここで、第
1 フィールドに単なる一語のホスト名を使っている点に注意しましょう。ゾーン情報では絶対名 (末
尾に. がつかない) を使ってない場合には、自動的にカレントオリジン (起点名) が自動的に補われる
ようになっています。先に、絶対名を強調したのはこのためです。実際に、もしここで第 1 フィールドに
pc01.j4-00.matsue-ct.ac.jp と書いてしまうと、pc01.j4-00.matsue-ct.ac.jp.j4-00.matsue-ct.ac.jp.
と解釈されてしまいます。
なお、同じ名前に対して、別の A レコードを書く場合、標準ではサイクリックに順序が変わるよう
になっています。つまり、問い合わせの度に返すアドレスの値が異なる、という意味になります。こ
れは、たとえば同じコンテンツを有した複数の WWW サーバなどを用意し、クライアントからのア
クセスに対して負荷を分散するためなどに利用します。たとえば、
www
IN
A
172.16.1.1
www
www
IN
IN
A
A
172.16.1.2
172.16.1.3
のように設定を行うと、query 毎に答える IP アドレスの順序が変わっていくようになっています。
この動作は、options で変更が可能ですが、今のバージョンでは順序を固定するオプションにバグが
あり、順序の固定はできないようです。なお、これはあくまでも DNS の response の結果であり、そ
れをどう使うかはクライアントに依存します。
7. CNAME レコード
別名を定義するレコードです。第 4 フィールドのホスト名は A レコードで解決できなければなりま
せん。特殊なマルチホームルータなどの場合については、CNAME レコードの第 4 フィールドに IP
アドレスが用いられる場合もあります。
pc01
IN
CNAME
mail
ただし、CNAME は最近では徐々に使わない傾向にあります。とくに、IPv6 の導入の際に深刻な矛
13.4. サーバの設定
189
盾に陥ることもあるので、今後は使用を控えた方が良いとされています。例には、CNAME を用い
ずに、A レコードで書いており、DNS は単方向に検索を行うので、2 つの FQDN に対して同じ IP
アドレスがあってもかまいません。
pc01
mail
IN
IN
dns
A
A
86400 IN
A
172.16.1.1
172.16.1.1
172.16.1.1
更に、ローカルホストファイルを用意しておく。これは SOA 以外ではどんな DNS サーバでも同じで
ある。
@
IN
SOA
2009110401
dns.j4-00.matsue-ct.ac.jp.
; Serial
10800
3600
;
;
Refresh after 3 hours
Retry after 1 hours
604800
86400 )
;
;
Expire after 1week
Minimum TTL of 1day
IN
13.4.2
A
admin.j4-00.matsue-ct.ac.jp.
(
127.0.0.1
セカンダリゾーンサーバ
セカンダリゾーンサーバはプライマリサーバよりゾーン情報を自動的に転送し、それを用いてクライア
ントに対してはプライマリサーバと同じ役割を果たします。セカンダリサーバに用いる際の設定ファイル
は、マスターの設定ファイルをコピーして、以下のように書き換えれば良いことになります。
zone "." {
type hint;
file "named.matsue";
};
zone "j4-00.matsue-ct.ac.jp" {
type slave;
file "slave/matsue.zone.bak";
masters { 172.16.0.1; };
};
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};
// 以下同様
重要な点は、ループバックアドレス (127.0.0.1) に対するゾーンの設定や、root ゾーンに対する hint な
どの設定は、マスターとまったく同じです。しかし、自ドメインのゾーンはプライマリサーバが authority
を持っているので、type slave; を指定し、そのマスターの位置を指定します。同時に、キャッシュファ
イルを指定しておきます (キャッシュファイルはゾーン転送によって自動生成されます)。
第 13 章
190
13.4.3
DNS I
ファイルのチェック
BIND9 では、ここでは紹介しきれない程の多数のオプションや、機能が追加されています。このために
一方では、設定ファイルの間違いや、マスターファイルの記述が難しくなっています。こうした事情もあ
り、公式に conf ファイルや、マスターファイルの文法チェッカが付属しています。
まず、 設定ファイルのチェックは以下のように行います。
# named-checkconf -t /etc/namedb /etc/namedb/named.conf
ここで、-t オプションは、設定ファイル中に include 指令があった場合のカレントディレクトリを合わ
せるためのものであり、include 指令を利用していなければ指定してはいけません。
# named-checkconf /etc/namedb/named.conf
つぎに、マスターファイルのチェックのために named-checkzone が用意されています。このプログラム
は引数が 2 つ必要で、ゾーンの名前とそれに該当するマスターファイルを指定します。
# named-checkzone j4-00.matsue-ct.ac.jp. master/j4-00.zone
13.5
rndc.key の生成
Bind9 では、named の制御のために認証が導入されており、それに使う鍵が rndc.key です。named と
rndc 自体が利用しています。通常、FreeBSD では、この鍵の生成はスタートアップスクリプトが自動的
に生成してくれるので、意識する必要はありませんが、他のシステムでは問題になるかも知れませんので、
簡単に触れておきます。
rndc.key は、rndc-confgen プログラムが作成してくれます。
# /usr/sbin/rndc-confgen -a
ところが、システムによってはシステムの乱数生成が異常に時間がかかる場合があります。このような場
合、そのまま動かすと恐ろしく待たされるようです。そこで、ここではキーボードから乱数を入力します。
# /usr/sbin/rndc-confgen -a -r keyboard
start typing:
...............................
...........................
...........................
...........................
...........................
...........................
...........................
...........................
stop typing.
最後の ’stop typing.’ というメッセージが出るまで、適当にキーボードを叩いてください。プログラム
が終了すると、/etc/namedb/rndc.key が生成されているはずです。
13.6. ネームサーバの起動
191
ネームサーバの起動
13.6
FreeBSD でネームサーバを動かす場合には、次のように /etc/rc.conf に記述した上で、
named_enable="YES"
以下のようにして named を起動します (この際に、rndc などは自動で設定されます)。
# /etc/rc.d/named start
一方、他のシステムなどで、ネームサーバを手動で動かす場合にはつぎのようにして起動します。
/usr/sbin/named -c
/etc/namedb/named.conf
ちなみに -c オプションは conf ファイルの指定です (BIND8 では -c でも、-b でも同じ意味でしたが、BIND9
では-c になっているので注意しましょう)。
プライマリマスタ上でゾーン情報を書き換えた場合には、一般には named に kill -HUP を送ってゾー
ンファイルを再度読み込ませなければなりません。この際に、当該のゾーンファイルのシリアルを変更し
ておく事を忘れないようにしましょう。一方、FreeBSD では、/etc/rc.d/named スクリプトにこれらの処
理も組み込まれているので、以下のようにして再読み込みを行います。
#
/etc/rc.d/named
reload
FreeBSD 特有のこうした操作以外にも、BIND9 では rndc を用いてこうした操作が行えるようになって
います。rndc は動作中の named を制御する目的でつくられたプログラムで、先に rndc.key を作成してあ
るので、rndc.key を読めるユーザ (通常は、root のみが読めるように設定してあります) からなら誰でも制
御できます。
# rndc
reload
rndc のコマンド (rndc の後ろにコマンドは指定) の主なものには以下のものがあります。
reload conf ファイルとゾーンファイルを読み直します。
reload ゾーン名 特定のゾーンのみを読み直します。
reconfig conf ファイルとそこに新たに指定されたゾーンのみを読み直します
status サーバの状態を表示します
flush サーバのキャッシュをクリアします
stop サーバを停止します
その他のコマンドについては、rndc をオプション、コマンドの指定無しで動かすと表示されます。
なお、FreeBSD ではセキュリティのために sandbox (砂場) というメカニズム (ftpd で使われているも
のと似ています) が用意され、上記の設定ではこの sandbox で named が動くようになっています。こ
のために、named は /var/named/ 以下を/ と考えるプロセスとして動き、そのために /etc/namedb/
が/var/namedb/etc/namedb/ にリンクされています (pid なども考慮されています)。
なお、named を動かした場合には、必ずエラーがないかどうかをチェックしてください。
もし、問題がある場合には以下のようにメッセージが /var/log/messages に出力されています。
第 13 章
192
DNS I
# tail /var/log/messages
Jul 31 18:11:33 localhost named[1651]: starting BIND 9.6.3 -t /var/named -u bind
Jul 31 18:11:33 localhost named[1651]: command channel listening on 127.0.0.1#953
Jul 31 18:11:33 localhost named[1651]: command channel listening on ::1#953
Jul 31 18:11:33 localhost named[1651]: zone 168.192.IN-ADDR.ARPA/IN:
loading master file master/192.168.rev: file not found
Jul 31 18:11:33 localhost named[1651]: zone g1.matsue-ct.ac.jp/IN:
loading master file master/g1.zone: file not found
Jul 31 18:11:33 localhost named[1651]: running
上の例では、master/192.168.rev や master/g1.zone がないというメッセージが出ています (named.conf
の設定ミスがあります)。 named が走っていてもこのように問題があることがありますので、こうしたエ
ラーやワーニング (Warning、警告) が出ていないかどうかをチェックして下さい。
間違いを修正したら /etc/rc.d/named で restart をかけ、再び /var/log/messages を見ます。
Jul 31 18:20:31 localhost named[1741]: starting BIND 9.6.3 -t /var/named -u bind
Jul 31 18:20:31 localhost named[1741]: command channel listening on 127.0.0.1#953
Jul 31 18:20:31 localhost named[1741]: command channel listening on ::1#953
Jul 31 18:20:31 localhost named[1741]: running
上のようになれば、設定ファイルに矛盾はないことになります (もちろん、矛盾がないことは正しいこと
を保証するものではありませんが)。
13.7
リゾルバ
ネームサーバを引く全てのクライアントで/etc/resolv.conf を設定して置かなければなりません (も
ちろん、ネームサーバ自身でも)。
domain j4-00.matsue-ct.ac.jp
nameserver 172.16.0.1
もし、スレーブ DNS を設定している場合はそれらの IP アドレスも載せるようにします。
domain j4-00.matsue-ct.ac.jp
nameserver 172.16.0.1
nameserver 172.16.0.2
ここで注意は、もし dhclient (DHCP のクライアント) が走っていると、resolv.conf を書いても定
期的に消されてしまうことです。もし、確かに設定したにもかかわらず、resolv.conf の中身が消されるよ
うでしたら、dhclient が走っていないかどうか必ずチェックして下さい。また、/etc/rc.conf で、
ifconfig_re0="DHCP"
となっていないかどうかをチェックし、正しく IP アドレスが設定されるように変更をしておかなければ
なりません (re0 は、インターフェース名ですので、環境によって異なりますので、必ず自分のインター
13.8. DNS への問い合わせツール、メンテナンスツール
193
フェースを指定してください)。
DNS への問い合わせツール、メンテナンスツール
13.8
DNS に対して実際に問い合わせを送り、その結果をチェックすることは重要です。通常、こうした問い
合わせのツールとしては nslookup が一般的に用いられてきましたが、最近では dig が標準となりつつあ
ります。その他に、dnsquery のようなフリーのツールなどもあります。
nslookup の簡単な使い方は以下の通りです。
# nslookup - dns.j04-00.matsue-ct.ac.jp
ネームサーバを指定する際には、- server_name とします。省略した場合には、デフォルト (/etc/resolv.conf
の設定) に従います (もちろん、IP アドレスで指定してもかまいません)。起動すると、インタラクティブ
モードに移るので、
合には、
> dns.j4-00.matsue-ct.ac.jp
のようにホスト名を入力すれば、その情報が返ってきます。MX などのタイプを指定して検索をしたい場
> set type=mx
> j4-00.matsue-ct.ac.jp
のようにします。ネームサーバを変更するには、
> server dns.j4-00.matsue-ct.ac.jp
とします。終了するには exit コマンドを入力します。
一方、dnsquery も良く似たコマンドですが、インタラクティブではなく一度の問い合わせで終了します。
dnsquery
[-n namesever]
[-t type]
hostname
なお、DNS のゾーンファイルを作成するときには良くタイプミスをしてしまいます。このため、ゾーン
ファイルの自動生成プログラムを利用し、その出力結果を編集するのが効率的であす。 dnsutl は dns カ
テゴリーに納められており、まず以下のようにホストファイルを作成します。
# sample host file
172.16.0.1
pc01
172.16.0.2
pc02
172.16.0.3
172.16.0.4
pc03
pc04
このファイルを host.sample とすると、表引きのゾーンファイルは以下のようにして生成できます。
# dns-hosts-import host.sample > j4-00.zone
生成された matsue.zone は以下のようになっています。
第 13 章
194
DNS I
$origin example.com.
@
in
soa
example.com. hostmaster.example.com. (
3
10800
; serial
; refresh: 3 hours
1800
604800
; retry: 30 minutes
; expire: 1 week
pc01
in
a
86400 ) ; minimum: 1 day
172.16.0.1
pc02
pc03
in
in
a
a
172.16.0.2
172.16.0.3
pc04
in
a
172.16.0.4
最初の行の $origin が不要ですが、つぎの工程では必要とされるので、この行とつぎの行の example. com.
を j4-00.matsue-ct.ac.jp に書き換え、NS および、MX レコードを追加します。
ホストの数が多い場合や、なれていないためにタイプミスが心配な場合にはこうしたツールが役に立つ
でしょう。
その他の便利なツールとして、パッケージに dns/dlint や、dns/zonecheck がある。dlint は、DNS の設
定エラーをチェックしてくれるツールで、逆引きが設定されていないなどさまざまな問題を指摘してくれ
ます。ただ、このツールも万能ではないので、その点では注意しなければならないでしょう。インストー
ルすると、/usr/local/sbin/dlint あるいは、/usr/local/sbin/zonecheck にインストールされるの
で試して見ると良いでしょう。
13.9. 演習課題
195
演習課題
13.9
演習 13.1 各自が DNS を立てます。マスターはプライマリー DNS サーバを立てなさい。それ以外の人は、
スレーブサーバを立てますが、最初はマスターサーバを作成するために、マスター以外の人はマスターの
マシンに SSH で入って、作業をします。混乱をしないように、それぞれの人の作業分担を最初に決めて下
さい。例えば、named.conf を作成する人、自分のドメインのゾーンファイルを作成する人、localhost 用の
ゾーンファイルを作成する人、ヒントファイルを作成する人などです。各人の担当を確認してから作業を
して下さい。
各ドメイン名は j4-N.matsue-ct.ac.jp のように j4- の後の数字で区別します。数字はグループの番号 N
を利用し、j4-N とすることにします。(グループの番号 N は必ず 2 桁とします。例えば、グループ１は 01
とします。) つまり、N 番グループは j4-N.matsue-ct.ac.jp となります。
自分の PC の正式名称には、dns を用いて下さい (つまり、dns.j4-N.matsue-ct.ac.jp などになり
ます)。
各自 named の設定ファイルを dnsutl を使って、設定しなさい ( dnsutl では表引きで、同じ IP アドレス
に別の名前は付けられませんので、後で必要ならば追加してください。たとえば、pcNN などを任意で決
定します)。設定するのは、自分のゾーン (マシンは一台だけ) の表引き、localhost の逆引き、下記の root
の記述を行いなさい。
ただし、ヒントファイル ”named.root” には Internet に接続する際には正規のものを使う必要がありま
すが、ここでは仮想的なドメインを構築するので、以下のものを named.root に使いなさい。
; for matsue-ct oss admin course
.
dns-root.matsue-ct.ac.jp.
99999999
99999999
IN
IN
NS
A
dns-root.matsue-ct.ac.jp.
10.120.150.199
演習 13.2 /etc/resolv.conf の設定を各マシン上で行いなさい。
演習 13.3 nslookup を用いて、自ドメインの DNS の設定を確認しなさい。また、名前解決ができている
か確認しなさい。
演習 13.4 設定ができている他のドメインとの間で、 ping を使って名前解決されているかどうかを確認し
なさい。
# ping dns.j4-00.matsue-ct.ac.jp
PING dns.j4-00.matsue-ct.ac.jp (10.120.150.2): 56 data bytes
64 bytes from 10.120.150.2: icmp_seq=0 ttl=63 time=0.175 ms
^C
--- red ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.175/0.175/0.175/0.000 ms
演習 13.5 マスター以外の人は、スレーブの設定をして見なさい。
演習 13.6 設定が出来ている他のドメインとの間で、 ping を使って名前解決されているかどうかを確認し
なさい。
第 13 章
196
DNS I
問題がなければ、各自自分の作成した DNS に対して、以下のコマンドを実行し、コマンドラインと出力
内容を提出しなさい。
#
dig @localhost any j4-00.matsue-ct.ac.jp
197
第 14 章 DNS II
前章に続いて、IP アドレスから名前を逆に引く (逆引き) 設定について学びます。特に、逆引きは、DNS
の構造に無理やりあてはめているために、少しとっつきにくいですが、基本的にはキーに対して値がある
という構造であることには変わりありません。
逆引きのゾーン情報
14.1
$TTL
@
86400
IN
SOA
dns.j4-0.matsue-ct.ac.jp. admin.j4-0.matsue-ct.ac.jp. (
2009110401
; Serial
10800
3600
;
;
Refresh after 3 hours
Retry after 1 hours
604800
;
Expire after 1week
86400 )
IN
; Minimum TTL of 1day
NS
dns.j4-0.matsue-ct.ac.jp.
1
IN
PTR
dns.j4-0.matsue-ct.ac.jp.
逆引きの場合には、IP アドレスに対してホスト名を指定しますが、この場合に使うのが PTR(domain
name PoinTR) レコードです。ここで、第 1 フィールドの指定に省略記法が使われている点に注意しなけ
ればならなりません。ここでは、カレントオリジン (起点名) が 150.120.10.in-addr.arpa. であるので、
150.120.10.in-addr.arpa. が省略されています。したがって、1.150.120.10. のように誤って書かな
いように留意しなければなりません。同時に、第 4 フィールドには絶対指定の FQDN を書いている点にも
注意しなければなりません。
また、表引きのゾーンファイルには複数の名前に対して、同じ IP アドレスを割り振っていますが、それ
をそのまま逆引のゾーンファイルに載せてはいけません。 つまり、以下のような例は深刻な事態を引き起
こす可能性があります。通常は、IP アドレスに対しては一つの正式名称 (FQDN) を記載しておけば良いで
しょう。
// 良くない例
1
1
IN
IN
PTR
PTR
pc01.j4-0.matsue-ct.ac.jp.
dns.j4-0.matsue-ct.ac.jp.
なお、実際には上の例では、自ドメインが 150.120.10.in-addr.arpa に対する権限を持っていないと
意味を持ちません (書いても良いが、上からの権限委譲がないので自分で自分を引く以外の意味はありませ
ん)。きちんとするには、次の CIDR に対応した設定方法が必要です。
babababababababababababababababababababab
第 14 章
198
DNS II
(One Point)
上のような場合、特別な設定をしていない限り、1.150.120.10.in-addr.arpa の問い合わせに
対して、サイクリックに pc01.j4-0.matsue-ct.ac.jp と、dns.j4-0.matsue-ct.ac.jp を順序を変えて
名前を答えるようになってしまいます。これは、正確には間違いではありませんが、このような
場合にも対応可能なように全ての DNS が実装されているかどうかという問題や、アプリケーショ
ンの対応の問題がありますので、今のところは間違っていると思った方が良いでしょう。
一方、もしも答える順序が変わらなければ、こうした問題はあまり起こらないとも考えられます。
先に述べたように、BIND の標準はサイクリックに順序を変えることになっていますが、この動
作を rrset-order を設定することで、変更することが出来るように設計されていますが、残念
ながら BIND9 ではまだこの機能に問題があり、実装されていません。
localhost に対する逆引きのゾーンファイルも同様に記述すれば良いでしょう。
$TTL
@
86400
IN
SOA
dns.j4-0.matsue-ct.ac.jp. admin.j4-0.matsue-ct.ac.jp. (
2009110401
; Serial
10800
3600
;
;
Refresh after 3 hours
Retry after 1 hours
604800
86400 )
;
;
Expire after 1week
Minimum TTL of 1day
IN
IN
1
NS
PTR
dns.j4-0.matsue-ct.ac.jp.
localhost.j4-0.matsue-ct.ac.jp.
なお、この場合のカレントオリジンは 0.0.127.in-addr.arpa になっている点に注意して下さい。
14.2
DNS メンテナンスツール II
DNS の逆引きの設定も、手動で設定すると間違う場合も多くなるので、やはり自動的な設定ツールを使
うと良いだろう。
先に紹介した dnsutl のツールによって作成された表引きのゾーンファイルが j4-0.zone だとすると、次
のようにして、逆引きのファイルを生成できます。
# dns-rev j4-0.zone > 10.120.150.rev
この結果、つぎのようなファイルが得られます。
14.2. DNS メンテナンスツール II
199
; Do not edit this file. It is generated
; by a ’dns-rev matsue.zone -’ command.
$origin 16.172.in-addr.arpa.
@ in soa j4-0.matsue-ct.ac.jp. dns.j4-0.matsue-ct.ac.jp. (
1
14.2.1
3
10800
; serial
; refresh: 3 hours
1800
604800
; retry: 30 minutes
; expire: 1 week
in
ns
86400 ) ; minimum: 1 day
dns.j4-0.matsue-ct.ac.jp.
in
ptr
dns.j4-0.matsue-ct.ac.jp.
CIDR に対する逆引きのゾーン情報
古典的な逆引きのゾーンの記述はクラスフルに対応しており、オクテット (8bit) 毎に階層化しています。
しかしながら、CIDR が普及した現在では、こうした記述方法は問題でしょう。なぜなら、従来の記述で
は親ドメインが (つまりは、クラス C を管理して、それを細分して配布しているドメイン) 逆引きゾーンに
ついて管理しなければならないからです。
これに対するちょっとした解決方法が RFC2317 に提案されています。ここではこの記法について紹介
します。ただし、当然、親ドメインがこの記法にしたがって管理している場合に限る点に注意して下さい。
実際の運用に当たっては必ず上位ドメインに問い合わせる事が必要です。
以下では、10.120.150.0/24 のクラス C を保有している matsue-ct.ac.jp. ドメインが、このクラスを /29 に
分割し、CIDR で管理する場合について記述しています。この場合、まず親ドメインである matsue-ct.ac.jp.
は、逆引き用ゾーンファイルとして以下のように設定します。
第 14 章
200
DNS II
; matsue-ct.ac.jp.(10.120.150) zone での逆引きの設定ファイルの抜粋
; 40-47 zone
40-47.150.120.10.in-addr.arpa. 86400
;
IN
NS
pc01.j4-0.matsue-ct.ac.jp.
40.150.120.10.in-addr.arpa. 86400
41.150.120.10.in-addr.arpa. 86400
IN
IN
CNAME 40.40-47.150.120.10.in-addr.arpa.
CNAME 41.40-47.150.120.10.in-addr.arpa.
42.150.120.10.in-addr.arpa. 86400
43.150.120.10.in-addr.arpa. 86400
IN
IN
CNAME 42.40-47.150.120.10.in-addr.arpa.
CNAME 43.40-47.150.120.10.in-addr.arpa.
; 中略
47.150.120.10.in-addr.arpa. 86400
IN
CNAME 47.40-47.150.120.10.in-addr.arpa.
;
; 48-55 zone
48-55.150.120.10.in-addr.arpa. 86400
;
IN
NS
dns.j4-0.matsue-ct.ac.jp.
48.150.120.10.in-addr.arpa. 86400
IN
CNAME 48.48-55.150.120.10.in-addr.arpa.
49.150.120.10.in-addr.arpa. 86400
; 中略
IN
CNAME 49.48-55.150.120.10.in-addr.arpa.
IN
CNAME 80.80-87.150.120.10.in-addr.arpa.
; 80-87 zone
80.150.120.10.in-addr.arpa. 86400
; 以下省略
つまり、40.150.120.10.in-addr.arpa. を解決しようとして、matsue-ct.ac.jp ゾーン ( 正確には 150.120.10.inaddr.arpa. ゾーン) にまでたどり着いた時点で、matsue-ct.ac.jp のネームサーバは、40.150.120.10.inaddr.arpa. は CNAME で、40.40-47.150.120.10.in-addr.arpa. が本当の名前であると答えます。このこと
によって、新しい階層 40-47 が存在するように見え、この階層を管理するネームサーバへの権限委譲が可能に
なっています。このようにして、40.150.120.10.in-addr.arpa. の解決は、40.40-47.150.120.10.in-addr.arpa.
の解決へとすり替えられ、40-47.150.120.10.in-addr.arpa. ゾーンは pc01.j4-0.matsue-ct.ac.jp. に権限委譲
されているので、そこへと問い合わせることになります (ちなみに、上の例では、プライマリ DNS のみを
指定しています)。
プライマリとセカンダリの両方を上位 DNS で指定する際には、以下のようになります。
40-47.150.120.10.in-addr.arpa. 86400 IN NS pc01.j4-0.matsue-ct.ac.jp.
40-47.150.120.10.in-addr.arpa. 86400 IN NS pc02.j4-0.matsue-ct.ac.jp.
この権限委譲を受けた j4-0.matsue-ct.ac.jp ゾーン (正確には、40-47.150.120.10.in-addr.arpa. ゾーン)
では、以下のようにゾーンマスターファイルを作成しておけば良く、これは実際にはゾーンファイル名の
レベルでは 40-47 のようなダミーの階層が追加されたことはわからないようになっています。このため、
問題はゾーンファイルではなく、named.conf の設定にあります。
14.2. DNS メンテナンスツール II
201
$TTL 86400
@ 86400 IN SOA pc01.j4-0.matsue-ct.ac.jp. admin.j4-0.matsue-ct.ac.jp. (
40
41
2009110401
10800
;
;
Serial
Refresh after 3 hours
3600
604800
;
;
Retry after 1 hours
Expire after 1week
86400 )
86400
;
IN
86400
86400
IN
IN
Minimum TTL of 1day
NS
pc01.j4-0.matsue-ct.ac.jp.
PTR
PTR
pc01.j4-0.matsue-ct.ac.jp.
pc02.j4-0.matsue-ct.ac.jp.
42
86400
IN
PTR
pc03.j4-0.matsue-ct.ac.jp.
43
86400
IN
PTR
pc04.j4-0.matsue-ct.ac.jp.
このように CIDR で IP アドレスを割り当てられ、その逆引が可能であるような場合には、上位の ISP
から指定されたゾーン名を named.conf に設定することがポイントになります。この例では、ゾーン名
を 40-47.150.120.10.in-addr.arpa. に変えなければならない点に注意しましょう。
また、各レコードにおいて、これまでは省略してきた第 2 フィールドの TTL 値を上の例では陽に指定
しています。もちろん、$TTL を指定しているので、省略してもかまいません。
第 14 章
202
DNS II
演習課題
14.3
演習 14.1 マスターの外側 IP アドレスに対応する逆引きと、127.0.0.1 の逆引きを作成して、動作をチェッ
クしなさい。動作したら、報告して下さい。チェックします。
演習 14.2 マスター上で、グループで協力して、以下の設定を行いなさい。
外側インターフェース (ue0) に、10.120.150.N を設定しなさい。但し、N は、グループごとに、8∗N +32
で計算され、/29 で割り当てられているセグメントです。つまり、グループ 1 ならば、8 ∗ 1 + 32 = 40 と
なり、10.120.150.40/29 が割り当てセグメントとなります。マスターは、自分を含むメンバー全員分の
IP アドレスを alias として、ue0 に設定しなさい (メンバーが 2 名ならば 10.120.150.40,10.120.151.41 を
ue0 に alias で設定します)。但し、少し特殊な設定ですので、マスク長は 32bit で行います。
#
ifconfig
ue0
inet
10.120.150.40/32 alias
# ifconfig
...
ue0
inet
10.120.150.41/32 alias
即ち、上のようにして、メンバー全員分のアドレスを設定します。
次に、NAT にこれらの IP アドレスに対応するメンバーのプライベートアドレス 192.168.N.M を設定
し、例えば 10.120.150.40 にアクセスすると、必ず 192.168.N.1 にアクセスできるように設定します。こ
れもメンバー全員分の設定が必要です。NAT をリロードして、動作すれば、他のグループの端末を借りて
自分の端末に外部から traceroute を打ち (つまり例えば traceroute 10.120.150.40 など)、その結果を
提出しなさい。
演習 14.3 マスターは先の設定を /etc/rc.conf に対して設定をしておきなさい。
ifconfig_ue0_alias0="inet 10.120.150.40/32"
ifconfig_ue0_alias1="inet 10.120.150.41/32"
...
演習 14.4 ここまでの設定で、外部から見ると、10.120.150.N が存在するように見えますが、実際にはそ
れは内部のプライベートのマシンに対応するようになっています。そこで、新たに、CIDR に対応した逆引き
(10.120.150.N) を協力して作成しなさい。但し、上位 DNS からは、例えば 40-47.151.120.10.in-addr.arpa
を権限移譲したように設定しています。(グループ N では、(32 + 8 ∗ N ) − (40 + 8 ∗ N − 1).150.120.10.in −
addr.arpa になります。)
演習 14.5 設定ができているか、確認をしたら、以下のような自分の IP の逆引き結果を表示する、dig の
出力結果を提出しなさい。
# dig @dns.j4-01.matsue-ct.ac.jp 40.150.120.10.in-addr.arpa ptr
勿論、IP アドレスや DNS の名前は、グループ及び自分の IP アドレスによって異なります。
203
第 15 章 DNS III
ここでは、BIND9 で提供されている新しい機能について学ぶ。
15.1
BIND9 の新機能 — view
さて、ここまでは BIND8 と同じ部分であったが、更に BIND9 で新たに付け加わった機能について以下
では紹介する。
BIND8 までの機能では、今日ごく当り前となったプライベートアドレスの名前解決が面倒であった (例
えば２つの DNS を外向け用と内向け用に用意するなど)。こうした部分が view という機能によって簡単
に解決出来るのも BIND9 の魅力の一つである。
以下の例では、202.11.0.0/29 (つまり、202.11.0.0-7 が自サイトに割り当てられたグローバルアドレ
スで、192.168.0.0/24 が自サイトの内部のプライベートアドレス、10.0.0.1 が外部に接続されたゲート
ウェイの外部インターフェースのアドレスで、上位 DNS にはこのアドレスが登録されているものとする。
第 15 章
204
DNS III
acl "mynet" {
{ 192.168.0/24; 10.0.0.1/32; 127/8; 202.11.0.0/29; };
};
options {
directory "/etc/namedb";
allow-transfer { mynet; };
};
view "internal" {
match-clients { mynet; };
allow-query { mynet; };
zone "." {
type hint;
file "named.root";
};
zone "oss00.matsue-ct.ac.jp" {
type master;
file "oss00.zone";
};
zone "0-7.0.11.202.in-addr.arpa" {
type master;
file "202.11.0.0-7.rev";
};
zone "0.168.192.in-addr.arpa" {
type master;
file "192.168.0.rev";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};
};
view "external" {
match-clients { any; };
zone "." {
type hint;
file "named.root";
};
zone "oss00.matsue-ct.ac.jp" {
type master;
file "oss00-ex.zone";
};
zone "0-7.0.11.202.in-addr.arpa" {
type master;
file "202.11.0.0-7.rev";
};
zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};
};
15.1. BIND9 の新機能 — view
205
(この例では、0-7.0.11.202.in-addr.arpa という CIDR での逆引きに対応した書き方をしている。)
1. アクセスコントロールリスト
アドレスリストに名前をつけて、アドレスリストをその名前で代用出来る。
acl "NAME" {
[IP アドレスリスト];
};
IP アドレスリストは、/ を用いた CIDR での表記ができる他、127.0.0.0/8 は 127/8 と略記が可
能である。複数の IP アドレスを掲げる場合、{ } で囲むことで、複数を列記できるが、それぞれの
アドレスの末尾に ; を忘れない事。
2. view
view は言わば相手の所属によって、同じゾーンであっても違う見せ方を可能にする。但し、view を
導入すると、zone 文は必ずいずれかの view エントリの中に書かなければならない。
(a) match-clients
後ろにアドレスリストを伴い、この view に言わば所属するホストを定義する。従って、このリ
ストにマッチするホストからは、この view に定義したゾーン情報が見える。
なお、アドレスマッチの場合と同じく順序性を持っているので、例のように ”external” view で
は、any で良い。
3. マスターファイル
view を用いると、同じゾーンでも相手によって違うので、それを積極的に用いるならば、マスター
ファイルは別個に作成しなければならない。この例では、”oss00.zone” と ”oss00-ex.zone” ファイル
がそうである。この場合、oss00-ex.zone にはグローバルアドレスを持つホストのみを列挙するが、
oss00.zone では内側のみで意味を持つプライベートアドレスに対応するホスト名を載せても良い。ま
た、プライベートを使う場合には”192.168.0.zone” のようにプライベートの逆引きも載せておくと良
いだろう。
但し、オフィシャルな名前に変更があれば”oss00.zone”,”oss00-ex.zone”の両方のファイルを変更し
なければならない (include を使って同一性を保つようなテクニックもあるが)。
$INCLUDE
ゾーンファイルを記述する際に、別のファイルを $INCLUDE を記述した位置に取り込む事が出来る。
その際に、オリジンの解釈が変更されると困る場合があるので、取り込むファイルのオリジンを指定
出来るようになっている。もし、取り込んだファイル自身の内部にオリジンの記述も、このオプショ
ンでのオリジンの指定も無ければ、カレントオリジンが設定される。
$INCLUDE
filename
[origin]
[comment]
具体的には、あるゾーンファイルの中に external.zone を取り込み、オリジンを oss00.matsue-
ct.ac.jp. にして取り込む場合には、以下のようになる。この際、external.zone の中で、dns の
ように相対表現で書かれていた場合、 dns.oss00.matsue-ct.ac.jp. として取りこまれること
になる。
第 15 章
206
DNS III
$INCLUDE
external.zone oss00.matsue-ct.ac.jp.
つまり、先程 view によってファイルが二重になり管理の問題が生じるかも知れない点について述べ
たが、この $INCLUDE を用いる事でそれを回避出来るであろう。
とは言え、サーバの名前が view によって異なったり、IP アドレスが異なる場合には残念だが使えな
い (当然、サーバの interface が異なる場合にはそうした事もある)。
なお言わずもがなであるが、オリジンの指定には注意しなければならない。
15.2. 演習課題
15.2
207
演習課題
演習 15.1 先に、設定したマスターファイルを view を用いて更に、プライベートアドレスに対応するよ
うにせよ。すなわち、外部から参照される場合には 10.120.150 のアドレスが見えるようにし、内部から
参照される場合には 192.168.x.x のアドレスが見えるようにせよ。また、その逆引きにも対応せよ。
設定できたら、課題 13.1 と同様に、但し、自分の FreeBSD 上で実行した、dig の結果を提出しなさい
(つまり、自分のプライベートアドレスが見える筈です)。
# dig @localhost any j4-00.matsue-ct.ac.jp
209
第 16 章 mail の設定
電子メイル (e-mail) は、Internet 上でのコミュニケーションの基本であると言って良いですが、DNS と
並んで設定が難しいとされています。その困難のほとんどは、電子メールを扱うサーバプログラムである
sendmail の難解さに起因すると言っても良いでしょう。実際、sendmail は UUCP 接続やその他の多様な
接続形態も内包し、非常に大きな柔軟性を有していたが故に、その設定ファイルが必要以上に複雑なもの
となっていました。しかし、Internet の普及と共に、逆に多くのサイトの接続形態は同様な形式となり、メ
イル接続も共に一様化しつつあります。こうした状況が、セキュリティに対する要求と共に、新しいメイ
ルシステムの登場を促したと言えるでしょう。こうした流れの中で、とくに qmail や Postfix のような簡
単設定でありながら、セキュアなツールが登場して来たと思われます。本章では、sendmail と互換性が高
く、sendmail からの移行が楽な Postfix を使って設定する方法を説明します。
16.1
mail の仕組みと Postfix
16.1.1
配送
図 16.1: メール転送のしくみ
電子メイルを送る場合、上図のとおり通常 2 つのプログラムが必要です。1 つは、MUA( Mail User
Agent) で、MUA はユーザーインターフェースを担当します。今一つは、MTA ( Mail Transfer Agent )
で、E.P.Allman の sendmail が有名ですが、近年では qmail や Postfix、その他 ZMailer,Exim なども登
場し、とくに qmail,Postfix がユーザを増やして来ています。MUA と MTA を用いた電子メイルの配送方
法は、下図のように考えることができます。
順番に経路をたどると、
第 16 章 mail の設定
210
1. MUA から電子メイルの発送
2. MTA による配送 ( SMTP, UUCP,...)
3. MTA による受理
4. MUA によるスプールへの書き込み
のようにメイルは配送されます。したがって、その配送に関しては MTA が非常に重要な訳です。しか
し、MTA に用いられる sendmail はその動作を sendmail.cf と呼ばれる設定ファイルによって定義さるの
ですが、この sendmail.cf の構文は非常に複雑怪奇であり、その歴史性故に Unix の中でも特異な存在と化
しています。これに対して、 qmail や Postfix の特徴は、MTA が担うべき多くの役割を sendmail で行っ
ていたような一つのプログラムで担うのではなく、多くのプログラムに分割している点です。これによっ
て、各々のプログラムの守備範囲が明確となり、同時に各々のプログラムのサイズの減少や単純化がなさ
れ、セキュリティ的な安全度が上がる結果となっています。また、最初に説明したように、Internet 上で
の配送を中心に考えているために、設定が非常に簡単で、時には何も設定せずに問題なく動作したりもし
ます ( 既に sendmail で運用していた場合は特に)。
しかしながら、メイルを配送するに当たっては、通常いくつかの作業が必ず必要です。たとえば、発信
人のアドレスを正確に記述しなければ受け取った側からの返信ができないという事態が生じることもあり
ますので、発信人のアドレスをどうするかという問題があります。最も簡単なアドレスは、つぎのような
マシン名を含むアドレスですが ( j4-00.matsue-ct.ac.jp がドメイン名です)、
From: [email protected]
発信人が返信をこのホスト dummy で受け取りたくないと思っている場合や、そのサイトの運用として、
mail spool host を別に設定している場合などもあるでしょう。さらには、この dummy というマシンが、
DNS に登録されていない場合も考えられます (DNS に登録されていないと、相手側が最初から dummy の
IP address を知らない限り返信を返すことができません)。このことは、同時にメイルを受け取る場合にも
生じます。したがって、メイルの設定をすることは取りも直さず、メイルシステム自身の設計から始めけ
ればならないのです。
16.1.2
mail aliases
受け取ったメイルを mail aliases で再配送するにあたり、重要となるのは、どの程度のサーバ間でメイ
ルシステムを構築するかによります。これには、ユーザのメイルスプール用のシステムや、外とのやり取
りを行うためのメイルゲートウェイが含まれます。こうしたシステムが多数ある場合の問題は、ドメイン
の外からは通常こうした多数のホストの存在は隠蔽されていなければならないという問題です。実際、こ
のようなホストが全て外からも参照可能であるならば、このようなホスト各々に外からメイルが届く状態
を考えなければならなくなり、セキュリティ的にも設計的にも非常に複雑になってしまいます。つまり、こ
こで問題になっているのは、外からは隠蔽されたシステムが、内部においていかにして協調動作を行うか
という問題であり、その解決のキーとなるのが実は mail aliases です。このように内部協調動作の鍵とな
る mail aliases ですが、その際に協調性を保障するのは単純に mail aliases の同一性の保障です。簡単に言
えば、サイト内部の配送において、ある人へのメイルは全て同一の行き先を示していなければ、最悪の場
合はループやピンポンを起こす結果となります (もちろん、もっと高度な、いわゆる隠蔽をサイトの中の部
門別に行うという方法も考えらますが、実はそれは部門をサイトと考える方法とそれほど大きな違いはあ
りません)。このように、mail aliases の同一性、あるいは同じデータを利用しているというメカニズムを
16.1. mail の仕組みと Postfix
211
保障する方法として、NIS(Network Information System) を用いる方法があります。幸い、Postfix には最
初から NIS への対応がなされているので、NIS は常に利用できますが、NIS のデータセキュリティモデル
は非常に脆弱です。このため、NIS を実際に用いるかどうかはサイトの選択によります。また、近年では
LDAP(Lightweight Directory Access Protocol) の環境も整備されて来ており、Postfix も LDAP に対応し
ているので、これからシステムを構築するという場合や、システムの見直しを考えている場合には LDAP
を検討するのが良いでしょう (認証も LDAP に対応しつつあるので)。とは言え、本章では原始的ではある
が、ファイルベースで同一性が保障されていると仮定します (この条件は小さなサイトではそれほど困難で
はないでしょう)。
ローカルの /etc/aliases の例を下にあげます (sendmail の標準では /etc/mail/aliases であるので、注
意が必要です。通常、Postfix を導入した場合には シンボリックリンクになっています。)
#
staff: kanayama,hara,hirose
kanayama: [email protected]
hara: [email protected]
hirose: [email protected]
きちんと aliases が同一であるように pc01.j4-00.matsue-ct.ac.jp などの個々のホストを調整していた
ならば (通常、必ずどちらかで編集して、コピーするようにすれば良いのですが)、pc02 についた kanayama
宛のメイルは必ず [email protected] へと転送されます。つまり、このことで個々
人の mail spool ホストを固定することが可能になります (ちなみに、上の staff のように複数の人を一つの
aliases として登録する事もできます)。この aliases がないと、あるホストに到着したメイルが受け取って
良いと考えられるメイルならば (つまり、ユーザー登録されたユーザー)、そのホストはメイルを受け取って
しまいます。その結果、複数のホストに個人宛のメイルが分散されてしまうようなことが起きます。ちなみ
に、メイルの届く可能性のある全てのホスト上ですべてのユーザーのホームディレクトリが参照すること
ができる場合には、~/.forward も参照されます。したがって、メイルの転送においては、/etc/aliases,
~/.forward が順に参照されますが、基本的に.forward ファイルはユーザーの自由にできます。つまり、
カスタマイズ可能なので、この.forward ファイルに配送を頼るのは得策とは言えません (ただし、管理者
が正しく設定していても、ユーザが間違った設定を~/.forward にしてしまえばメイルの無限ループが生
じたり、メイルが着かないということは起こり得ます。一方、~/.forward を見ないという設定も可能で
すが、これはこれでユーザにとっては不便になるので止める訳にも行かないでしょう)。
注意 後でも述べますが、実際には Postfix や sendmail は aliases ファイルを直接みるのではなく、aliases
ファイルから作成したデータベースファイルを参照します (aliases.db)。これによって、高速に aliases
データの中身を検索できるようになっているのですが、問題があります。それは、自動ではこのデー
タベースファイルを作成したり、更新したりしないので、必ず手動でデータベースファイルの作成更
新を行わなければならない点です。通常、これは newaliases コマンドで行います (オプションはあ
りません)。つまり、/etc/aliases ファイルを編集した場合には、かならず newaliases を行うことを
忘れてはいけません。
16.1.3
DNS と Mail
メイルシステムは一般に host name の IP address を解決するために DNS を参照します。しかし、DNS
には自分のサイトの IP address テーブル以外にメイルに関して重要な情報を提供することができます。こ
れが、前章で説明した MX レコードで、メイルの受け取りにおけるドメインマスターを指定しておくこと
第 16 章 mail の設定
212
ができるようになっています。これによって、ドメイン・ネームのみのメイルを指定したマシン上で受け
取る事が可能になります。もちろん、内部で再配送する必要がありますが、受け取りを一つのマシンに集
中することによって管理の手間を大幅に減らすことが可能です。また、MX レコードには複数のドメイン
マスターを指定することができます。したがって、プライマリのドメインマスターが保守点検などで停止
中も、メイルサービスを停止させないようにすることができます (もちろん、プライマリのマシン上にス
プールがあるユーザーにとっては別ですが、その場合でもセカンダリのマスター上のキューにたまるので、
babababababababababababababababababababab
マシンの復旧と共に配信されることになります)。
(参考)
MX レコード自体は、ドメイン自体に設定することも、マシン名 (FQDN) に対して設定するこ
ともできますが、マシン名に対して設定するのはあまり感心しません。マシン名にたいして設定
しても、そのマシン宛の SMTP コネクションを他の MX レコードに指定したホストに回すこ
とができるだけです。プロバイダーの中には、内部メイルサーバと外部の受け口を分離するため
に、この機能を使っている場合もありましたが、本質的にはサブドメインを作り、内側と外側の
DNS を別個に立てて対応すべきでしょう (あるいは BIND9 の view 機能などを使います)。また、
CNAME に対して MX レコードを設定してはいけません。これは、RFC 的に間違った設定です。
16.1.4
Postfix の情報
Postfix のホームページは、
http://www.postfix.org/start.html
にありますが、実際には日本にもミラーサイトがあります。上のページからたどることができます。
Postfix の現在の 安定版バージョンは、2.8.7 です。FreeBSD8.2R のパッケージの mail カテゴリーに
は Postfix 2.8.0,1 が収録されています。
postfix-2.8.0,1.tbz
日本語のページは qmail に比較すると少ないのですが、以下の池田さんのページに多くの情報がありま
す。INSTALL や sample の cf の和訳もここにありますので、原文を読むのが大変な方はここを見れば良
いでしょう。
http://www.kobitosan.net/postfix/
16.1.5
Postfix の構造
最初に触れたように Postfix は複数のプロセスが協調して動作するようになっています。通常、こうし
たプロセスや、プロセスから起動されるファイルについてはきちんと管理されていれば意識する必要はあ
りませんが、管理者としては一応流れは理解しておいた方が良いでしょう (図参照)。
なお、こうした情報は全て /usr/local/share/doc/postfix/ 以下にあります。
16.1. mail の仕組みと Postfix
213
local
local mail
master
local
pickup
cleanup
qmgr
pipe
smtpd
smtp
Receiving
Delivering
SMTP
SMTP
図 16.2: Postfix の処理の流れ
まず、Postfix では、図の中のコマンド類は master デーモンの管理下にあります。つまり、Postfix の中
心は master です。個々のプログラムはこの master からデーモン、あるいはプログラムとして起動されま
す。実際の処理の流れは、まず入って来たメイルについては pickup または smtpd が処理をします。pickup
はローカルなメイルの処理を担当し、smtpd は SMTP(Simple Mail Transfer Protocol) による処理を担当
します。面白いのは、メイルのポート 25 番も master の管理下に置かれていて、master が監視している点
です。アクセスがあると、smtpd が起動され、処理をするのです。つぎにこうした受け入れ処理プログラ
ム (もちろん、受け取りを拒否することもありますが) は、メイルを cleanup プロセスに渡します。cleanup
プロセスはアドレスの書き換えなどの処理を行った後に、/var/spool/postfix/incoming キューにメイルを
おきます。Postfix の構造では、ここまでで一区切りになっていて、receiving(受け取り) のプロセス群を成
しています。
つぎに、delivering(配送) のプロセス群は、まず先程の incoming キューを処理する qmgr が、これらの
配送待ちメイルを、配送方法の決定や実際の配送処理プロセス、配送エラー、再送処理のリクエストを各
プログラムに対して行うようになっています。つまりは、受け取り処理では cleanup が中心で、配送処理
では qmgr が中心であると考えてかまいません。実際の配送においては、ローカルに配送される場合には
local が、UUCP などでは pipe が、SMTP 配送では smtp に処理が渡されます。
以上のように、Postfix では各々のプロセスが協調して動作していますが、その際に使われるキューの場所
が FreeBSD では、/var/spool/postfix/ ディレクトリです。そして、このディレクトリの所有者は、Postfix
のプロセスの多くが root ではなく、postfix というユーザによって行われるために、/var/spool/postfix/
以下全ての所有者は postfix となっています。
なお、Postfix ではローカルユーザへのメイルの書き込みは、標準では/var/mail 下に mbox 形式で書き
込むようになっていますが、設定によって qmail と同じ maildir 形式でユーザのディレクトリに直接書き
込むこともできます (ちなみに、Postfix はほとんど SUID の必要がありません。ローカルに書き込む際に
も LMTP を使うようにデフォルトではなっています。さらに、安全性を目指したい場合には FeeBSD で
第 16 章 mail の設定
214
は、Jail を使えば良いでしょう。Jail は従来の chroot がファイル空間のみの分離であったのに対して、プ
ロセス空間も分離しています (だから監獄))。
16.1.6
Postfix のインストール、設定の準備
Postfix のインストールについては、 sendmail などとの違いもあり、注意する点が多いのですが、幸い
FreeBSD のパッケージでインストールを行えば、ほとんどを全て実行してくれるので、パッケージからイ
ンストールした方が簡便で、誤りもありません (NetBSD や VineLinux では最初から標準でインストール
されています)。
以下では、パッケージから導入した場合の注意点についてのみ述べます。
Postfix は sendmail を交換する形で導入できますが、パッケージからのインストールでは、それぞれ以
下の場所にインストールされます。
1. 設定ファイル /usr/local/etc/postfix/
2. プログラム /usr/local/sbin/
3. 内部用プログラム /usr/local/libexec/postfix/
4. ドキュメント /usr/local/share/doc/postfix/
通常、これらの場所は変更してはなりません (パッケージからインストールする場合には)。
また、インストールの最後に、以下のような質問が出るが、それぞれ yes を答えます。
You need user "postfix" added to group "mail".
Would you like me to add it [y]? y
Done.
Would you like to activate Postfix in /etc/mail/mailer.conf [n]? y
特に、最後の質問には yes にしないと、以下の設定を手動で行わなければならなくなるので注意しよう。
きちんと yes と答えると、以下の sendmail という名前の代替プログラム (実はダミーで、sendmail を手
動で動かす場合のみのための代替) が/usr/local/sbin/ に導入される。これはシステムが sendmail を呼び
出すような場合や、システムをバージョンアップした場合などに問題となることがあるので、以下のよう
なデフォルトのファイル (/etc/mail/mailer.conf) は、
# オリジナルの mailer.conf; sendmail を用いる
#
# Execute the "real" sendmail program, named /usr/libexec/sendmail/sendmail
#
sendmail
send-mail
/usr/libexec/sendmail/sendmail
/usr/libexec/sendmail/sendmail
mailq
newaliases
/usr/libexec/sendmail/sendmail
/usr/libexec/sendmail/sendmail
hoststat
/usr/libexec/sendmail/sendmail
purgestat
/usr/libexec/sendmail/sendmail
以下のように変更されなければなりません。
16.2. メイルのヘッダー
215
# postfix を利用する場合の mailer.conf
sendmail
/usr/local/sbin/sendmail
send-mail
mailq
/usr/local/sbin/sendmail
/usr/local/sbin/sendmail
newaliases
/usr/local/sbin/sendmail
先に注意したように、package や ports から導入した場合は、自動的に書き換えてくれるようになってい
ます (2 回目の質問に y を入力した場合。ただし、デフォルトでは書き換えないので、注意が必要。もし、
忘れた場合には、上のように自分で書き換えなければなりません。)
参考 ここを見て分かるように、newaliases コマンドは、実は sendmail あるいは postfix 自身です。
少し戸惑いますが、実は FreeBSD では /usr/sbin/sendmail は以下のようになっています。
wiz# ls -l /usr/sbin/sendmail
lrwxrwxrwx
1 root
wheel
21
10/16
2009 /usr/sbin/sendmail ->
/usr/sbin/mailwrapper
つまり、/usr/sbin/sendmail を呼び出すと、実際には mailwrapper プログラムが動き、mailwrapper プ
ログラムは /etc/mail/mailer.conf を見て、実際に呼び出すプログラムを決めています。これによって、単
純に、/usr/libexec/sendmail/sendmail を書き換えるよりもスマートに置き換えができるようになってい
ます (本当の用途はそうではなく、プログラム名が同じプログラムを別の機能で呼ぶという手法を互換性を
持たしたまま温存するためのものです。本来、そうしたやり方そのものを無くした方が良いと man には記
述されています。 cf. man mailwrapper)。
つぎに、/etc/aliases が Postfix の標準 aliases ファイルなので、以下のように/etc/mail/aliases にシン
ボリックリンクが張られているかを確認します。
# ls -l /etc/aliases
lrwxrwxrwx
1 root
wheel
12
1 21 03:02 /etc/aliases -> mail/aliases
以上で設定のための準備は終りです。
16.2
メイルのヘッダー
これまでメイル自身については何も触れてきませんでしたが、実際にメイルシステムを動作させテスト
するには、メイルがどのような形式で送られてくるかを知っておく必要があります。すべてのメイルはヘッ
ダーとメッセージ本体からなり、ヘッダーとメッセージ本体はひとつの空行で区切られます。ヘッダーは、
行頭から始まり、[ヘッダー名]: とフィールドからなります (最初の From 行は特別）。ここで、コロン (:)
の後ろの空白以外の文字からがフィールドです。行頭が空白ならば、前の行の継続として解釈されます。
実際のメイルは、
第 16 章 mail の設定
216
From [email protected] Fri Aug 1 17:08:08 2009
Received: from pc01.j4-00.matsue-ct.ac.jp ([192.168.0.1])
by pc02.j4-00.matsue-ct.ac.jp (R8/cf1.0) with ESMTP id f6U9c8k89707
for <[email protected]>; Mon, 30 Jul 2009 18:38:08 +0900 (JST)
(envelope-from [email protected])
Received: from mytest@localhost)
by pc01.j4-00.matsue-ct.ac.jp (R8/cf1.0) with ESMTP id RAA01100
for <[email protected]>; Mon, 30 Jul 2009 18:38:07 +0900 (JST)
Date: Mon, 30 Jul 2009 18:38:05 +0900 (JST)
From: mytest <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: test
[ メッセージ本体 ]
のような形式ですが、その外のヘッダーがついていることもあります。メイルシステムのテストで、特に
重要なヘッダーにしぼって以下解説をします。
From
あってもなくてもかまいません。ローカルメーラー (着信時にユーザーのスプールに配送するエージェ
ント) に Unix スタイルのローカルメーラ ( local, LMTP, /bin/mail, mail.local など) を使った場合
には通常付加されます。Unix From 行とも呼ばれ、ucbmail 等のクライアントソフトでは、個々の
メイルの区切りとして判別されます。
Received:
発信人から受信人に届くまでにメッセージを処理した MTA によって付加されます。したがって、複
数の MTA を経由して来たならばそれらが全てここに表示されます。実際の配送経路を知るために
非常に重要です。
Date:
発信日時を表します。その他のマシンの時刻とずれている場合もありますが、細かな時間の相違はマ
シンの時計のずれに起因する場合もあるので気にしなくても良いでしょう。しかし、この日時が受信
と数日ずれている場合は、配送経路のどこかのマシンに問題があるか、過負荷になっている場合が多
いので注意を要します。
From:
発信人の e-mail アドレスと Full Name が記載されています。Full Name は、/etc/passwd の GECOS
フィールドから取得されます。
From: Georg Hogehoge <[email protected]>
また、順序は逆にしても良く、その場合は以下のように記載されます。
From: [email protected] (Georg Hogehoge)
16.3. メイル環境の設計
217
もちろん、GECOS フィールドに何もない場合や、MUA にパソコン上のソフトを使っている場合な
どに、GECOS 情報が記載されていない時もあります。その場合は、単純なアドレスのみになります。
From: [email protected]
Internet mail address では、この３つの場合以外のアドレスは許されません。
実際の配送のテストでは、この From: 行のアドレス書き換えにも注意する必要があります。
Subject:
題名ですが、あってもなくても構いません。発信人の選択項目です。
Message-Id:
日時、ファイル名、マシン名、ドメイン名などから生成される一意の文字列です。特に、指定しない
場合は、MTA が自動的に付加しますが、一部のパソコン用クライアントでは設定によっては不正な
ID を生成するものがあります。基本的には、こうしたメイルを外部に発信することは禁物です。
To:
受信人のリストです。複数ある場合には、カンマによって区切られます。
To: name1,name2,[email protected]
ここのアドレスにも注意が必要です。
これがメイルのヘッダーなのですが、実はこれ以外に、MTA の間での送受信時のみ存在し、local に落
ちると消えてしまうものがあります。これがエンベロープで、Received 行に書き残されているものは、エ
ンベロープの写しだったのです。よく、メイルのヘッダーを見て、そこから発信が分かると勘違いしてい
る人がいますが、途中の MTA が信用出来ない場合や、ヘッダーを偽造した場合には、ヘッダーからは判
定出来ません。真の送り状は、エンベロープにあるのです。ですから、Received 行にはなるべく多くの情
報を残すようにしましょう。少なくとも、自分の管轄下の MTA は正しい筈ですから。
16.3
メイル環境の設計
先に述べたように、メイルの設定を行う前に自分のサイトのメイル環境の設計をしなければなりません。
非常に大きなサイトでは、全てのユーザーの管理を行わず各部門に管理を任せている場合もあります。こ
のような場合は、むしろメイル環境の設計は簡単で、内部再配送もせずに済ませても良いくらいです。し
かし、多くの場合、ユーザー管理は集中して行っており、複数のマシンが存在していることでしょう。その
ような場合、自サイトのすべてのマシンへメイルが配送されるのは好ましくありません。何故ならば、そ
れらすべてのマシンのメイル環境を管理しなければならなくなるからです。したがって、メイルをスプー
ルするマシンは適度に少なくすることが望ましいことになります (匙加減が難しいのですが)。よって、す
べてのマシンが DNS によって管理されており、さらに複数のメイルスプールを設定する場合について具体
的な設定を解説することにします。ここで想定しているのは、メイルはドメイン名宛に届くものとし、内
部で再配送を行うものとします (内部再配送を行う方が、ネットワーク変更の際に混乱が少ないのです)。
さらには、プライベートアドレスを使用している場合で、ある程度の規模がある場合には、内側の DNS
と外側の DNS をたてるような設計もあります。そのような場合のメイルの配送の設計の問題もあります
が、現在ではむしろ DNS のところで取り上げた allow-query やさらには view を用いて、外と中を分離
した DNS を作ることができるので、全てを DNS で処理をしても問題なく運用が可能になっています。し
第 16 章 mail の設定
218
たがって、特別な内部用 DNS (自分自身がルートネームサーバであるようなタイプ) の必要性はありませ
ん。つまりは、DNS に起因するメイル設計の問題もなくなり、様式化した設定で十分対応できるように
なってきているのが現状です (とは言え、複雑なアドレス書き換えはやはり Postfix には難しいので、そう
したアドレス書き換えが独自かどうかが、選択の基準になるでしょう)。
16.3.1
ハブホストで受信、それぞれが外部に配送
次の図のとおり、MX レコードに指定されたドメイン・マスターへ全てのメイルが届き、それを内部へ
再配送します。内部への配送では直接/etc/mail/aliases に従って再配送が行われます。内部から外部へメ
イルを送る場合は、それぞれのサーバが直接外部に配送を行います。
図 16.3: メール配送
この場合、ドメイン・マスターに届いたメイルは、ドメイン・マスターの Postfix がローカルの aliases
map を参照して適切なスプール・ホストに再配送することになります。したがって、ドメインマスターの
/etc/aliases に各メンバーごとの aliases が記述されていなければなりません。
# /etc/aliases
#
中略
member01:[email protected]
member02:[email protected]
member03:[email protected]
member04:[email protected]
...
さて、ここで Postfix の具体的な設定を行いますが、Postfix は sendmail などと違い、main.cf を直接記
述するだけでかまいません (主な設定は全て main.cf にあります)。main.cf は多くの場合、変数とその値の
定義という形で行います。sendmail と違って、定義ファイルからマクロファイルの生成のようなことはし
なくても良いので、非常に簡単であり、その上、定義しなければならない項目も非常に少ないのが特徴で
す。sendmail.cf を知っている人が見ると、簡単すぎて拍子抜けする程です。
main.cf は FreeBSD では、/usr/local/etc/postfix/ にあります。まず、現在の main.cf のバックアップ
を取ってから、編集を行いましょう (なお、/usr/local/etc/postfix/main.cf.default がありますが、これは
16.3. メイル環境の設計
219
デフォルトを決めたもので、編集してはなりません)。
# cd /usr/local/etc/postfix
# cp main.cf main.cf.org
Postfix では、多くの場合デフォルトで良いので、上記のように直接オリジナルの main.cf を編集すれば
良いでしょう (Postfix では postconf というコマンドで編集をするようになっていますが、少し面白くない
点があるので、本テキストでは直接編集をお勧めします)。
以下では編集が必要な設定箇所のみを紹介します。
#ドメインマスターの編集箇所
myorigin = j4-00.matsue-ct.ac.jp
mydestination = $myhostname, localhost.$mydomain, $mydomain, mail.$mydomain
mynetworks = 127.0.0.0/8, 172.16.0.0/24
masquerade_domains = $mydomain
masquerade_exceptions = root
以下、必要な項目について解説します。
myhostname
自ホストの名前が自動的に設定されるので、通常は設定しなくても良いのですが、別名にしたい場合
などには設定しなければなりません。
myhostname = alias.j4-00.matsue-ct.ac.jp
mydomain
myhostname から 1word の名前を削除したものに自動的に設定されます。上の例では、j4-00.matsuect.ac.jp となります。通常は設定しなくてもかまいません。
mydomain = j4-00.matsue-ct.ac.jp
myorigin
このシステムで受信され、外に出て行くメイルの送信元アドレス表記を [email protected]
のようにドメイン名にしたい場合に、上記のように設定します。なぜならば、外からの返信にマシン
名がついたものであると困る場合があり、返信先アドレスが MX を参照するようにしなければなら
ないからです。デフォルトの設定は、
myorigin = $myhostname
となっています。
陽に指定せずに、以下のように変数を用いても同じです。
myorigin = $mydomain
mydestination
自分宛のメイルの解釈を行う際に、どういう宛先を受け取るべきかを指定します。先の myorigin で
第 16 章 mail の設定
220
指定した場合、返信は domain 宛に返って来ます (つまりは、[email protected] 宛のよう
に)。このメイルを受け取るために、j4-00.matsue-ct.ac.jp 宛は自分宛であると解釈させなければな
りません。さらに、Postfix では、別名などメイルの宛先に使われると思われる全ての名前を列挙し
ておかなければなりません (もちろん、そのメイルを受け取りたい場合には)。特に、DNS に記載し
たホスト名は全てここに載せるようにします。今の場合には $myhostname,localhost.$mydomain,
$mydomain,mail.$mydomain 宛は全て受け取る設定になっている。
この部分の設定に洩れがあり、たとえば、$mydomain が抜けていると、[email protected]
宛にメイルが来たが、ここに列挙されていなければ受け取りを拒否するか、後で出て来るリレーホス
トに転送してしまうようなことが起こるので注意が必要です。
デフォルトの設定は、myhostname 宛を受け取ります。
ちなみに、複数の値があるときには、空白あるいはカンマで区切って書くようになっています。
また、一桁目が空白の場合には継続行と見なされます。
mynetworks
中継を許す (つまりは信頼出来る) ネットワークを IP で指定します。自分のサイトのネットワークに
対しては中継を許可するのが通常です。
これは、メイルサーバを踏台にされないようにするために、中継機能を制限するためのものです。一
般に、外から外への中継を禁止し、外から内、内から外は許可したいので、内側のネットワークをメ
イルシステムに教える必要があります。もちろん、ここに列挙されたネットワークは内部と同等に考
えられるので、外部ネットを安易にここに付け加えてはなりません。
この項目の簡易設定として、mynetworks_style があります。この変数は、class,subnet,host の
いずれかの値を取り、class はホストが接続されているクラス A or B or C 全体を信頼します (どの
クラスかは接続されているクラスによります)。一方、subnet は自分が接続されているネットワー
クのみを信頼します (つまりは、インターフェースのサブネットの範囲)。最後の host は自分のみを
信頼します。mynetworks が定義されていた場合には、mynetworks_style は無視されます。通常、
mynetworks を使うようにした方が良いでしょう。
その他 relay_domains が更にあるが、各自ドキュメントを確認して下さい。
inet interfaces
どのインターフェースからの接続に応答するべきかを決定します。デフォルトは全てのインターフェー
スに対して応答します。この項目は、複数のインターフェースを持つマシン (マルチホーム) 上でメ
イル接続要求に答えたくないインターフェースがある場合や、あるいはバーチャルインターフェース
上でメイルを動かしているような場合に待ち受けインターフェースを指定するためにあります。つま
りはバーチャルドメインでメイルを運用しない限りは指定しなくてもかまいません。
masquerade domains
発信者エンベロープとヘッダについて、この値から来たように書き換えます。通常、ヘッダーのさま
ざまな部分に発信者ホストの情報が残されますが、そうした情報を隠蔽し、外から見た場合に、その
ドメインあるいは、特定のホストから来たかのように見せかけるためのものです。ただし、受信者エ
ンベロープは書き換えの対象外です。これは受信者エンベロープも書き換えてしまうと、個別のホス
トへの転送が不可能になるからです。
Postfix は全般にカノニカル、マスカレードが弱く、十分な書き換え機能が存在しません。これは
sendmail のような書き換え言語を持っておらず、テーブルレベルの置換であることによります。も
し十分な書き換えを必要とするならば、sendmail を使うより他ありません。
16.3. メイル環境の設計
221
ちなみに、この設定と次の設定に関しては、sample-rewrite.cf にサンプルがあり、main.cf には書か
れていませんので、自分で main.cf に書き足すか、カット＆ペーストをしなければなりません。
masquerade exceptions
先の masquerade_domains の例外として、root へのメイルを指定した方が良いでしょう。デフォル
トでは例外はありません。
16.3.2
ハブホストに全て集中する場合
それぞれが外部に配送を行うのではなく、全てハブホスト (ドメインマスター) に集中するような場合に
は、ドメインマスター以外に以下の設定を追加すれば良い。但し、この設定のみを行った場合には、内部
の配送も全て一旦ドメインマスターに転送するようになるので注意しよう。
図 16.4: ドメインマスターに集中
relayhost = pc01.j4-00.matsue-ct.ac.jp
#その他のメイルシステム
#ドメインマスターの編集箇所に以下を加える
relayhost
自分宛ではなく、ドメイン宛のメイルでもないような場合 (トランスポートテーブルにマッチしない
場合)、$relayhost に転送します。通常、ドメインマスターを指定すると良いでしょう。指定方法
は、名前で指定しても良いし、内部参照用 DNS の MX フィールドがドメインマスターを指していれ
ばそれを指定するのも可能です。名前解決などがうまく行かない場合などの最終解決方法としては、
IP アドレスを生で直接指定することもできます。
第 16 章 mail の設定
222
# ホスト名を指定
relayhost = dns.j4-00.matsue-ct.ac.jp
# MX を利用
relayhost = $mydomain
# IP 指定
relayhost = [10.16.48.20]
ただし、内側から外側に出て行けるように mail についてもファイアーウォールを設定している場合
には、nat で変換されるので実は外にも配送されます。ただ、そうしたファイアーウォールの設定が
良いかどうかは考えなければなりません (内部ネットワークから外部ネットワークへの spam などが
あり得ます)。
16.3.3
Other Setting
Maildir
Postfix は sendmail 互換を意識しているために、ユーザーのメイルの格納形式はデフォルトでは
sendmail と同じ、mbox 形式で、格納場所は通常/var/mail/$USER になっています。mbox 形式は
一つのファイルに From で区切られたメイルを継ぎ足していく形式になっているために、ファイル
のロックなどの問題が元々あるのと、/var/mail の共有場所にファイルを置くための問題が指摘され
ています。これに対して、qmail などではユーザのあるディレクトリ以下に、メイル毎に別々のファ
イルとして置く方法が取られており、これを Maildir 形式と呼びます。Postfix でも Maildir 形式で
利用することが可能です。これを行いたい場合には、以下のように設定します。
home_mailbox = Maildir/
末尾の / を忘れてはなりません。この場合、$USER/Maildir/ の下にメイルが格納されます。
Maildir 形式は確かに優秀な方法ですが、これまでのアプリケーションとの互換性が最大の問題であ
り、既に mbox 形式で運用しているサイトが Maildir 形式に移行するには、未だに障壁が高いのが難
点です。
アドレスエクステンション
配送的には一人のユーザでありながら、最終的なローカル配送の段階で複数に分かれるようなメイル
のアドレスの拡張が行えます。具体的には、
recipient_delimiter = +
のように設定します (デフォルトでコメントアウトされているので、コメントを取るだけです)。これ
によって、hoge も hoge+foo も同じアドレス hoge として扱われ、配送されます。したがって、振り
分けソフトで自分で振り分けても良いが、通常 .forward+foo というファイルを用意すると、hoge
宛のメイルは .forward が参照されます。しかし、hoge+foo については .forward+foo が参照され
るという仕掛けがあるので、この仕組みを使ってメイリングリストなども簡単に運営できるように
なっています。
16.3. メイル環境の設計
223
コマンドへのパイプ
aliases におけるコマンドへのパイプ ( |command ) 機能はメーリングリストなどで良く使われます。
しかし、より管理の柔軟性のために include 機能と共に用いられることが多いです。
include は以下のような形で使います。
# /etc/aliases
mailinglist: :include:/home/mailinglist/hogemail
イルの中でさらに以下のように使う場合があります。
"|/home/mailinglist/hogemail/fml.pl /home/mailinglist/hogehoge"
のように設定します。
つまり、mailinglist の aliases として /home/mailinglist/hogemail が使われるのですが、このファ
# /home/mailinglist/hogemail の中身
このような場合に、デフォルトでは Postfix はコマンドを実行しません。これを変更するには、以下
allow_mail_to_commands = alias,forward,include
一方デフォルトでは、以下のようになっています。
allow_mail_to_commands = alias,forward
ただし、実行権限は include したファイルの権限で実行されます。しかし、これには例外があり、その
ファイルの所有者が root であった場合のみ default_privs に指定した値 (デフォルトでは nobody) の
権限で実行されます。これは root 権限での実行などをそれまでに期待した設定をしていて、sendmail
から Postfix に移行した場合に問題となるので注意して下さい。
バーチャルドメイン
Postfix は qmail と同様にバーチャルドメインに対応しています。こうした機能が sendmail と比較
した場合、新しい MTA の優位な部分であると言えます。バーチャルマップは、main.cf に以下の設
定をし、
virtual_maps = hash:/usr/local/etc/postfix/virtual
ここで指定した /usr/local/etc/postfix/virtual に以下のように記述します。
[email protected] hoge
[email protected]
user1,user2
左に記述したバーチャルドメインのユーザ宛にメイルが来たならば、右のリストのユーザにメイルは
送られるようになります。
詳細についてはドキュメントを参照して下さい。
local recipient
これは Postfix バージョン 2.0 になってからの問題ですが、2.0 からは$mydestination 宛のメイルで
第 16 章 mail の設定
224
も、宛先ユーザを Postfix が知らない場合には全てユーザーを知らないとして拒否します。したがっ
て、/etc/aliases や、/etc/passwd などにユーザがあるには問題ありませんが、バーチャルホストや、
その他いくつかの場合に問題になる場合があります。このチェックを外したい場合には、以下のよう
に設定します。
local_recipient_maps =
つまり、陽にパラメータを空にする訳です。ちなみに、デフォルトでは以下のようになっています。
local_recipient_maps = proxy:unix:passwd.byname $alias_maps
詳しくは、LOCAL RECIPIENT README にあります。
16.3.4
設定のチェック
Postfix では設定にタイプミスなどがあっても、そのまま起動してしまうので、設定には注意がいりま
す。postconf コマンドで現在の設定 (デフォルト設定を含む) を表示してくれるので、必ず自分で設定した
項目に問題がないかどうかをチェックしなければなりません。
/usr/local/sbin/postconf | more
デフォルトも含めて全て出力されるので、ファイルにリダイレクトしてもかまいません。デフォルト以
外のパラメータのみを出力したい場合には、
/usr/local/sbin/postconf -n | more
とすれば良いでしょう。
16.4
起動とテスト
16.4.1
起動方法
Postfix を起動する前に、sendmail が自動的に起動しているかも知れないので、最初にこれを止めてお
きましょう (順番を間違えると kill でしか止められなくなります)。
# /etc/rc.d/sendmail stop
Stopping sendmail_submit
Stopping sendmail_clientmqueue.
つぎに、/etc/rc.conf に以下のように設定をします。
16.4. 起動とテスト
225
# /etc/rc.conf への追加
postfix_enable="YES"
sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"
定を追加します。
なお、sendmail 用のメンテナンスルーティンも必要がないので、以下のように/etc/periodic.conf に設
# /etc/periodic.conf への追加
daily_clean_hoststat_enable="NO"
daily_status_mail_rejects_enable="NO"
daily_status_include_submit_mailq="NO"
daily_submit_queuerun="NO"
これで、再起動時に sendmail が完全に動かないようになりましたので、安心して Postfix の起動テスト
に移ります。
まず最初に newaliases コマンドを使って、aliases データベースファイルを作成します (aliases ファイル
の編集が終わっているとします)。
# newaliases
newaliases コマンドは通常何も表示しません。出来たか否かは自分で確認して下さい。
# ls -l /etc/aliases.db
-rw-r--r-- 1 root wheel
65536 Jan
6 15:50 aliases.db
出来ていれば、Postfix のテストに移ります。
Postfix の起動は全て /usr/local/sbin/postfix コマンドを使って行う。オプションを指定せずに起動する
と、現在利用可能なオプションを示してくれます。また、何らかの問題がこの時点で分かればそれも表示
されます。とくに注意するのは、/etc/hosts に登録した名前、 hostname コマンドで設定された名前など
が、main.cf と矛盾ないようにしておくべき点です (全て、FQDN で設定するのが基本です)。
postfix/postfix-script: fatal: usage: postfix start \
(or stop, reload, abort, flush, or check)
start
起動
stop
停止
# postfix
reload
abort
定義ファイルの再読み込み
強制終了
flush
再送待ちメイルの強制的再処理
check
Postfix システムの検証
通常パッケージからインストールすれば、ユーザ名、ファイルのパーミッションなどは自動的に調整し
てくれるので問題になることはありませんが、手動でインストールした場合などには check が役立つで
第 16 章 mail の設定
226
しょう。
定義ファイルを修正した場合には、もちろん停止して再起動しても良いのですが、reload すれば十分
です。
つぎに、postfix start で立ちあげ、
# postfix start
/var/log/maillog に以下のような Postfix の起動ログがあれば大丈夫です。
# tail /var/log/maillog
Aug 7 15:09:04 mail postfix/postfix-script:\
16.4.2
starting the Postfix mail system
テスト
Postfix がポート番号 25 で、デーモンとして動いているはずですから、まず、その動作を確認します。
その際に、MUA を用いるのではなく、telnet を用いて直接 SMTP で Postfix と会話するようにします (こ
のようにするのには理由があります。mail のテストでは、MUA と MTA が関係して来るので、単に配送
されないというだけでは問題がわからないからです)。
# telnet localhost 25
Trying 127.0.0.1...
Connected to localhost.
Escape character is ’^]’.
220 dns.j4-00.matsue-ct.ac.jp ESMTP Postfix
このように Postfix からの返事が返ってくれば、少なくとも postfix は動いている訳です。もし、動いてい
なければ、aliases.db を newaliases コマンドで作成していない可能性がありますので、チェックしてくだ
さい。エラー情報は、/var/log/messages あるいは /var/log/maillog に表示されます。
まず、SMTP で話をするときには、最初に HELO か EHLO のどちらかを使います。EHLO を使うと
拡張 SMTP を自分が話すことが出来ることを示すことにります。ここは、HELO を使うことにします。ま
た、相手ドメインのオプションも忘れずに付けて下さい。
helo j4-00.matsue-ct.ac.jp
250 dns.j4-00.matsue-ct.ac.jp
きちんと自分のホスト名、ドメイン名になっているか確認します。(DNS や hostname などの名前の
不整合があると、ここの表示がおかしくなります)。ではつぎに、いよいよメイルを出してみましょう。
16.4. 起動とテスト
227
mail from:<[email protected]>
250 Ok
rcpt to:<hogehoge>
250 Ok
data
354 End data with <CR><LF>.<CR><LF>
subject: test001
this is a test 001.
.
250 Ok: queued as BBAC486E
221 Bye
Connection closed by foreign host.
mail from: が差出人のアドレス指定で、< > でくくらなければなりません。つぎに、rcpt to: が受取人
のアドレス、data が本文のメッセージです。メッセージの終わりは、ピリオッド (.)、リターンで示します。
Postfix との会話を終わらせるには、quit と入力します。
うまく hoge 宛にメイルが届いたかどうかを確認します (/var/mail/hoge にメイルは届きますので、more
などで直接読めば良いでしょう)。とくに、/var/log/maillog の出力は良く読んで下さい。最初は、ローカ
ルのユーザからメイルを出して届くか否かをチェックします。これがうまく行かない場合は /etc/aliases
や mydestination, mynetworks などの定義が正しいかをチェックして下さい。
つぎに、設定の終っている同じドメイン内の他のユーザーについてチェックします。とくに、/etc/aliases
には全てのユーザの設定をしないとローカルにメイルが落ちるので注意して下さい。
ここまでで問題なければ、次からは mail コマンドを使ってテストしても構わないでしょう。
以下のように、メイルコマンドでは、オプション -s の後ろに件名を書き (空白を含めたい場合には ’ で
くくる必要があります)、その次に宛先を指定します。すると、入力モードに切り替わり、メイル本文を書
くことができ、終わりに行頭に ピリオッド . を打つと、相手にメイルが送られます。
% mail -s
test001
[email protected]
this is a test.
.
EOT
%
上の例では、EOT は mail コマンドが表示しています。
既にあるファイルを送りたい場合には、以下のようにリダイレクトを用いると良いでしょう。
% mail -s
test003
[email protected] <
test-file
%
この場合、test-file の中に . はなくても良く、ファイルの終わりを認識してくれます。
また、必ず到着したメイルのヘッダを確認して、思ったと通りに書き換えられているかどうかをチェック
して下さい。
自ドメイン内での配送に成功したならば、同じように他のドメインの管理者と連絡を取り、他のドメイ
第 16 章 mail の設定
228
ンとの配送を調べます。この時、まず、ハブホストからの配送を試し、つぎに他のマシンからの配送とい
う具合に順に調べていきます。当然、配送するたびに、ドメイン内でのテストと同じようにメイルのヘッ
ダーをチェックし、経路、アドレス書き換えに問題がないかをチェックします。うまく行かないときには、
まず相手先の DNS がうまく引けているかをチェックします。DNS 自体は動作していても、MX フィール
ドの設定がおかしいのかも知れません。また、自分のサイトの DNS がおかしい場合もあります。双方向
で調べて下さい。DNS でメイルを配送出来ない理由の多くは、設定のミスか、DNS の設定がおかしい場
合です (もちろん、ネットワークがつながっていることを前提とします)。そうした場合には、dead letter
あるいは差出人に戻ってきたメイル、あるいはキューにたまっているメイルをチェックします。キューにた
まったメイルは、mailq あるいは postqueue でチェックできます。
キューのリストは mailq コマンドで表示されます。
# mailq
-Queue ID- --Size-- ----Arrival Time---- -Sender/Recipient------110F15F6C6
21259 Sat Mar 31 17:16:14 [email protected]
(alias database unavailable)
[email protected]
1B4A65F6C7
21263 Sat Mar 31 17:16:14
[email protected]
(alias database unavailable)
[email protected]
...
また、表示されたキュー ID のメイルを表示するには、postcat -q コマンドを利用します。
# postcat -q
110F15F6C6
...
その他、詳しくは man(または jman) を参照して下さい。
16.5
その他のメイル環境整備
POP, IMAP
近年、パソコンを端末として使う環境が徐々に整備されてきており、利用者も急速に増加しています。
そのために、UNIX 側でもこれらのパソコンからの利用に対応していくことが管理者の仕事となって
きていますが、メイルに関しては Post Office Protocol (POP) と呼ばれる仕組みを用い、スプール
は UNIX におき、MUA はパソコン側のソフトを用いるのが便利です。従って、POP を UNIX 側
にインストールしておけば良いでしょう。POP には、qpop, popper, UW-IMAP 附属の ipop など
があります。しかし、ローカルネットワーク内でのメイルの管理は、最近では IMAP が主流となり
つつあります。IMAP を使えば、サーバ側につねにメイルスプールは残したまま、整理や検索がで
きるので、仕事場でも家庭にいても同じメイルを参照出来ます。サーバのリソースを使うという欠点
はありますが、ディスクは安くなりつつあるので、導入を検討してみてはどうでしょうか。
16.6. 演習課題
16.6
229
演習課題
演習 16.1 各グループ毎に、/etc/aliases を編集し、各ユーザのスプールホストを決めなさい。当然、ク
ライアントマシン上では各自のユーザ登録は終っていなければなりません。
また、/etc/hosts に自分のマシンの IP, ホスト名を FQDN で書いてあるかどうかを確認しなさい。更
に、DNS で設定した自分のホスト名が hostname に登録されているか確認しなさい。
ここで、hostname は以下のようにして確認します。
# hostname
hogehoge.domain.com
hostname を手動で設定するには、以下のように FQDN を引数に与えます。
# hostname dns.j4-00.matsue-ct.ac.jp
設定されたか確認できたら、これを再起動しても有効であるようにするために、/etc/rc.conf に登録します。
hostname="dns.j4-00.matsue-ct.ac.jp"
マスター以外の人のマシンは、pc02.j4-00.matsue-ct.ac.jp などのように外側 DNS 及び内側 DNS で一致
した名前を DNS に登録し、それを hostname に登録しなさい。
演習 16.2 /usr/local/etc/postfix/main.cf を main.cf.org にコピーしてから、main.cf を編集をしなさい。
但し、全員外部に自分でメイルを送るドメインマスターの設定をしなさい。
演習 16.3 本文に従って設定のチェックをし、ローカルでの配送テストをしなさい。特に、内部用ホスト
名 (pcXX) が/etc/hosts に登録されているか、main.cf にこれらの名前でメイルを受け取る設定がされ
ているかどうかに注意して下さい。
またこの際、telnet で配送チェックをまず行って下さい。telnet でのチェックが大体大丈夫ならば、以降
は mail コマンドを利用して構いません。
> mail -s ’sample-subject’ [email protected]
this is a test mail from kanayama.
.
演習 16.4 グループ内部のホストとの配送テストを行いなさい。テスト時には、ヘッダーをチェックする
のを忘れないように。
配送が出来るようになったら、自分が出したメイル本体 (ヘッダを含む) を送り返して貰い、そのメイル
を提出しなさい。
演習 16.5 ここまでの演習が全て終った別のドメインを探して、そことの間でのメイルの配送を相互に行
いなさい。ドメインマスター間での配送をまずチェックし、次に、ドメインマスターでないホストとドメ
インマスターの配送を、最後に任意のホスト間での配送をチェックしなさい。
同様に、外部との配送が出来るようになったら、先と同じように、自分が出したメイル本体 (ヘッダを含
む) を送り返して貰い、そのメイルを提出しなさい。
230
第 16 章 mail の設定
演習 16.6 relayhost を使ってマスターを経由して外部と配送する設定を行い、上と同様にテストし、これ
までと同様に外のグループに出したメイルを返送して貰い、そのメイルを提出しなさい。

インターネット接続ウィザードの設定（Windows XP 用）

NSM10ご利用にあたって - NetSHAKERシリーズサポート

UNIX演習

「Infoblox DNS Firewall データーシート」 をご覧ください。

SPOOKY CUP 帆走指示書 1

UNIX用汎用入出力パッケージ - セイコーソリューションズ株式会社

OSの説明資料 - 高知工科大学情報学群

2016江の島キールボートチャンピオンシップシリーズレース得点計算要項

SK Hynixが洗浄技術の将来を展望 新材料登場で再びFEOL洗浄に脚光