必要 - みる会図書館


検索対象: UNIX MAGAZINE 2005年12月号
116件見つかりました。

1. UNIX MAGAZINE 2005年12月号

連載 /UNIX Communication Notes ーー O この重要度と上記の 6 つの過程についての表を作成し、 ますは誰カ舸をしてよいのかを定義する。そのうえで、取 扱い上のルールを決めていく。このようにすれば、情報の 重要度に応じた適切な処理が実現できるはすである。 以下では、各過程ごとのルールをみていこう。 作成 48 の重要度に応じた合理的な方法を提示する必要がある。 こでも、情報 法でアクセスするかを定めることになる。 する。具体的にいえば、誰が、どの情報に、どのような方 この段階では、格納された情報へのアクセス方法を定義 参照 るシステムの運用要件も決めなければならない。 さらに、バックアップや監査の実施など、情報を各内す ータベース自体の適切な取扱い方法も定義する。 手法などを定める。データベースロ内する場合には、デ 化する場合にはその方式、そして、適用するアクセス制御の ファイルを単位とするのであれば、暗引匕の有無や、暗号 作成された情報のオ内方法を定義する。 オ内 徹民させるべきである。 も、情報の作成段階から重要度の区分を意識した取扱いを で情報を作成するのはトラブルのもとである。その意味で 必要がある。いずれにせよ、重要度が定まっていない状態 に区分すべきかを判断するためのガイドラインも整備する なる。したがって、どのような情報をどの程度の重要度 情報の重要度は、一ヨ殳には情報の作成者が決めることに ようなことは禁止するのが当然である。 れていない、すなわち、誰でも使えるシステムで作成する えば、、、秘密情報 " に類する書類をアクセス制御がおこなわ さらに、情報の重要度に応じてルールを追加する。たと に使うアプリケーションを指定することもよくある。 織も多い。また、情報を効率的に管理するために、作成時 する情報を作成してはいけないという規則を定めている組 ともある。最近は、個人力所有する PC では糸目織内で利用 えば、使用するアプリケーションやシステムを限定するこ これには、いろいろな要素が考えられるであろう。たと める。 この段階では、情報作成にかかわる - ヨ殳的なルールを定 たとえば、コピーを作ってはならない秘密情報を対象と する場合には、アクセスが許可された者以外の参照を禁止 したうえで、コピーの作成カ坏可能な機構を用意しなけれ ばならない。また、参照の記録が必要とされるレベルであ れば、適切にログをとる仕組みも必要になる。 UNIX MAGAZINE 2005 . 12 ールも、この段階で定義しておく。 場合によっては、 CD-ROM などの媒体へのコピーのル ンタなど、紙に出力する際のルールを決める。 そして、プリントアウトしてよい情報、利用可能なプリ た管理規則への移行を念頭において再整備するのである。 の書類を前提とした規定から、コンピュータを中心に据え ことを明確に意識しなければならない。つまり、従来の紙 ・情報はコンピュータによって作成、十常内、運用される ただし、 らの文書管理規定をベースに作成するのが一ヨ殳的であろう。 じた取扱いルールを整備する必要がある。これは、従来か 紙の書類については、さきほど述べた情報の重要度に応 すべきであろう。 の書類と電子的なデータの、、情報としての整合性 " を考慮 って、プリンタの適正な利用方法を定義する場合には、紙 作成された情報の紙への出口はプリンタである。したが プリンタ出力 なければならない。 それぞれについて、ルールと取扱い方法を明確に定義し ・情報交換に使われるアプリケーション 暗号化したメールで交換すべき情報 ・電子メールで交換してよい情報のレベル は、次のような要素を考慮すべきである。 とを意識したルールも必要になる。これを規定する際に 電子メールも含めて日常的に情報の奐がおこなわれるこ 現在のようにネットワークの利用が当り前の環境では、 交換 ーとグループを識別する設定も必要になる。 ばならないだろう。いうまでもなく、その場合にはユーザ ューザーの認証方法やグループ設疋のルールも決めなけれ 参照を許可するユーザーやグループを限定するのなら、

2. UNIX MAGAZINE 2005年12月号

ロプログラミング・テクニック 多治見寿和 newsysIog(2) 前回は、 syslog システムをサポートするコマンドである newsyslog の概要や使い方などを紹介し、コマンド自身の 動作を説明しました。 ソースコードの解説に進む前に、今回は、ファイルのロ ーテーションをおこなったときにシグナルが必要になる理 由を説明します。それには、 UNIX でファイルへの書込み がどのように扱われているかを↓年しておく必要がありま す。ファイルに何かを書き込む際に、システムでどのよう な処理がおこなわれるかを確認しておきましよう。 カーネル内の表 最初におこなう処理はオープン操作です。ファイルをオ ープンするには、パス名を引数にして open システムコー ルを呼び出し、そのファイルを表すファイル・ディスクリプ タを取得します。その後、必要に応じて write システムコ ールでファイル・ディスクリプタを指定してファイルの内 容を書き出し、処理を終了するときには close システムコ ールでクローズ操作をおこないます。この叩 en—write —close という一連の処理が基本的な操作となります。 オープン操作の際に、システムの内部ではどのような処 理がおこなわれるかをみてみましよう。まず、パス名で指 定されたファイルが実際にはどこにあるかを調べます。 の処理は UNIX のカーネル内でおこなわれます。パス名 の 1 つ 1 つの要素について、対応するディレクトリ・エン トリからファイルを探しながら、目的のファイルがみつか るまで繰り返し処理がおこなわれます。ここでみつけるの は、指定されたファイル名に対応した i ノードと呼ばれる ものです。 104 ファイルに関する i ノードは、カーネル内では i ノード表 として管理されています。 i ノード表のエントリは 1 つの ファイルを表し、このエントリの情報から実際にデータが 置かれているディスク上の位置を判断したりします。 i ノ ード表はシステムに 1 つしかなく、すべてのプロセスは同 ーの表を利用します。ファイルシステム上のファイルのそ れぞれについて、 i ノード表にエントリがあります。 ファイルに関する情報はディスク上の位置だけではあり ません。 lseek システムコールにより返される、現在ファ イルのどの部分に注目しているかを示す値、つまり次に一 ⅱノし み書きするのはどこからになるのかといった情報も重要で す。ところが、この情報を i ノード表に含めてしまうと不 都合が生じます。あるファイルを表す i ノード表のエント リは 1 つしかありません。したがって、そのファイルをオ ープンするすべてのプロセスが同じ工ントリをみることに なります。もし、ファイル内の注目している位置などがこ のエントリに書かれていたら、ファイルをオープンしてい るすべてのプロセスが同じ位置に注目することになってし まいます。 この情報は、別の表に本内されます。それがファイル表 と呼ばれるデータ構造です。ファイル表には、上記のファ イル内の注目している位置だけでなく、ファイルをどのよ うなモードでオープンしているかの情報なども格納されま す。 ファイル表には、システム内でプロセスがオープンして いるすべてのファイルに関する情報が格納されます。実際 には、、、ファイル " ではなく、、オープン " という操作に対し て 1 っすっ工ントリが作られます。つまり、システム内で open システムコールが実行されるたびにエントリが作ら UNIX MAGAZINE 2005 . 12

3. UNIX MAGAZINE 2005年12月号

■ヒジネスルールの適用 品の特徴を強調しなければならない。 ただし、以下のような共通項もある。 車両の言当頁の算出 : 車両補償を追加する場合に必要に なる。 見積り額の算出 項目のチェック : 情報カ坏足していると、見積り計算は できない。したがって、選択したオプションに応じて 必須項目が入力されているか、入力間違いや項目間の 矛盾などがないかを確認する。 web アプリケーションでは、さまざまなプログラミ ング言語力吏われている。ユーザー・インターフェイス として、 JSP や ASP を用いている場合もある。ユーザ ・インターフェイスについて、上記の共通項 ( ビジネ スロジック ) を実装する方法は、大きく分けて次の 2 つ である。 実装言語を共通にしてモジュール化する。 ・ユーザー・インターフェイスを提供するシステムとは 別に、ビジネスロジックを処理するサーバーを用意す る ( 両者の実装を切り離す ) 。 最近は、後者のほうが多いようだ。その理由を考えて みよう。 ーロにユーザー・インターフェイスといっても、その実 装才翅は多種多様である。たとえば、 Flash などを用い た分かりやすく使いやすいインターフェイスは、今後も さらに広まっていくと思われる。そのような場合、ビジ ネスロジックの実装をインターフェイスに合わせてしま うと、画面構成を変更するたびに実装の修正が必要にな る。もっと大きな問題は、ユーザー・インターフェイスと ビジネスロジックのライフサイクルが異なる点にある。 両者の分離は、以前からオプジェクト指向設計でおこ なわれてきた MVC (ModeI View Control) 設計パ ターンと同じである。ユーザー・インターフェイスが View 、ビジネスロジックが Control に相当する。それ ぞれにライフサイクルが異なるから、相互に依存しない ようにすることが重要である。 バッチ系 バッチ系のアプリケーションは、高いパフォーマン スが求められるため、データを格納するデータベース (DB) サーバーに近いところで処理するのが一般的であ 20 ューザー・インターフェイスとビジネスロジックの実装分離 を支援するフレームワークとしては、前者については Struts などがある。分離したビジネスロジックの処理をメッセージン グ処理によって非同期でおこなう場合には、そのべースとなる 、メッセージバス " と呼ばれる製品がある。また、同期・非同 期処理の両方を連携 (collaborate) させる SOA (Service Oriented Architecutre) の製品がある。 一方、それぞれの実装の独立性を高める手法として、設計 を実装から分離し、設計にもとづいて実装コードを生成する MDA (ModeI Driven Architecture : モデル駆動アー キテクチャ ) や、サーバーでの実装をネ礬なサーバー・フレー ムワーク API から切り離すのを助ける DI (Dependency lnjection) コンテナがある。これらのキ翅孑を利用する際にも、 MVC のうリが基本となる。 る。 DB サーバーに負荷をかけられない場合は、いった ん別の DB やファイルに書き出し、ほかのマシンで処理 してから書き戻す手川頁をとる。 保険会社の例に戻ろう。更新前の通知に含めることの できる推奨保険構成の数は限られている。したがって、 あらかじめ顧客のセグメント化をおこない、セグメント ごとに推奨保険構成を割り当てる必要がある。この割当 て作業は統言 t 的な分析結果にもとづいておこない、さら に顧客ごとの状況をカⅢ未する。たとえば、あるオプショ ンカ噺しかったり、他社商品にはない特徴的なものであ れば、そのオプションを付けていない顧客に薦めたりす る。 保険構成が決まったら、算出処理の基本的な考え方は、 オンライン系の場合と同じである。 バッチ系アプリケーションのアーキテクチャでは、 DB のストアド・プロシージャや DB アプリケーションとし て作成し、それをジョブフロー制御アプリケーションか ら順に呼び出していく方法をとる。 ビジネスロシックの整理 バッチ系で例示した推奨保険構成の作成は、オンライ ン系の場合も必要になる。既存の顧客から電話で問合せ を受けることもあるので、電話オペレータ向けのアプリ ケーションにも組み込まねばならないし、保険代理店向 けのアプリケーションでも要るだろう。 推奨保険構成は、業務分析者 ( アナリスト ) が企画して 作成する。糸 t 的な分析結果と商品の方向性を照らし合 依存性を低める動き UNIX MAGAZINE 2005 . 12

4. UNIX MAGAZINE 2005年12月号

ー O 連載 /UNIX Communication Notes UNIX MAGAZINE 2005. 12 前提としてシステムを稼動させることはめったにない。と 甬であり、サーバーシステムを除けば、マルチューザーを 今日では、コンピュータを 1 人 1 台以上利用する環境が とはきわめて重要な未をもっている。 の環境整備も必要である。だが、 OS 自体に機能があるこ ではさまざまなアプリケーションが必要であり、そのため 報管理竟が構築できる。もちろん、実務をおこなううえ ている。これらを活用すれば、さきほど述べた基本的な情 種資源へのアクセス制御機構などが機能として組み込まれ ザーの識別やグループの設疋、ファイルをはじめとする各 マルチタスクの OS として言気 t された。したがって、ユー いまさらいうまでもないが、 UNIX はマルチューザー ステムはどのような未をもっているのだろうか。 ところで、このような情報管理竟において、 UNIX シ UNIX の意味 た処理↓竟の構築が重要であることカ吩かるだろう。 こうした身近な例をみるだけでも、レベルに応じ ろうか。 書類を誰でも覗ける可能性のある環境で作成したりするだ 書類を一緒にして机の上に放置したり、人事考課に関する 理由は簡単に分かる。たとえば、 - ヨ殳的な業務日誌と決算 自分が業務をおこなっている環境を考えてみれば、その イ / 「業環境ももちろん別々に言 t すべきである。 れる事項がレベルごとに大きく変わる。したがって、その 重要度の区分に応じて処理する場合には、管理に要求さ 用する処理系を明示しておくと、情報管理に役立っことが 情報の重要度に応じて区分する場合、各レベルごとに利 処理系の分離 認する手川頁も定めておくべきだ。 もちろん、それぞれの手川頁が正しく守られているかを確 する場合には、事前にデータを完全に消去する。 ディスクやテープから確実に削除し、ディスクなどを廃棄 いった方法があるだろう。電子的データであれば、ハード 紙の書類なら、シュレッダーにかけたり、焼却したりと 棄の方法を、それぞれの重要度に応じて定める。 ライフサイクルの最後の段階である。情報の最終的な破 はいえ、 UNIX ではユーザーの識別とグループ設定、ユーザ ーやグループに応じた資源アクセス制御カ河能だから、仮 にユーザーが 1 人であっても、業務に応じて環境を切り替 えながら作業することができる。また、最近はアクセス制 御に ACL (Access ControI List) を導入している UNIX システムもあり、よりきめ細かな設定も可能である。こう いった点をみれば、今日の情報管理の考え方に適合した環 境を提供しているといってもよい。 さらにいえば、現在使われている OS の多くは、 UNIX の機能を直接継承したり、あるいは UNIX の機能設言 t に影 響を受けて実装されている。 Linux や Mac OS x はもち ろん、 Windows XP なども、じつはマルチューザー、マ ルチタスクのシステムである。つまり、適切な運用をおこ なえば、情報管理において UNIX と同じように利用できる はずである。 ところが、現状をみると、これらの OS の機能を十分に理 解せす、管理者権限で通常の作業をおこなっていたり、そ もそもマルチューザーで利用することすら考えずにシステ ム設疋をおこなっている例があまりに多い。皆さんは、自 分が日常的に使っている OS がマルチューザー・システム であることを理解したうえで、その機能を適切に活用して いるだろうか。 この節で述べたような観からシステムを捉えるかどう かで、情報管理に適合した基盤環境の構築手法は大きく変 わる。いずれにせよ、最近利用されている大部分の OS は マルチューザー・システムであることを再認識すべきであ ろう。 ( やまぐち・すぐる奈良先端科判支術大学院大学 ) 49

5. UNIX MAGAZINE 2005年12月号

イル・ディスクリプタがクローズされると、ファイルの実 体も削除されることになります。プロセスが異常終了して しまった場合にも、プロセス終了にともなう自動的なクロ ーズ処理により、ファイルは確実に削除されます。 対処法 newsyslog プロセスによりなんらかの処理がおこなわれ たときに、正しく口グファイルを書き出すようにするには、 いくつか方法があります。 truncate によりファイルサイズが変更される可能性が ある場合には、ログファイルに書き出そうとするたびにフ ァイルの末尾に現在位置を移動する方法が考えられます。 write システムコールの直前に、かならず lseek システム コールを実行するのです。こうすることで、 i ノード表の工 ントリか変わらない truncate のケースであれば対処でき ます。 しかし、この方法は i ノード表工ントリカ竣わってしま う rename や unlink の場合には使えません。いずれの場 合も、旧いファイルの実体ではなく、現在のパス名に一致し たファイルの実体を処理対象としなければなりません。パ ス名とファイルの実体との関係はファイルのオープン時に しか検査されないため、これを一致させるにはファイルを オープンしなおす必要があります。 そこで、ログの出力をつねに正しくおこなうには、ログ を出力するたびにファイルの open—write—close の一連 の処理を実行します。こうすることで、 write の対象は直 前の open でオープンしたファイルになるので、パス名と ファイルの実体が -- - 一致していない状態を回避することがで きます。 ただし、この方法にも問題がないわけではありません。 ファイルへの書込みのたびに open と close 処理が加わる ため、処理のオーバーヘッドが問題となります。ログファ イルへの書込みがさほど頻繁でなければあまり気にならな いかもしれませんが、頻繁に書込みをおこなう場合には無 視できなくなる可能性があります。また、 newsyslog の処 理と syslogd のログの書込み処理が完全に独立におこなわ れていると、 syslogd がファイルをオープンしなおした直 後に newsyslog が処理を実行し、 syslogd が書込みをお 108 こなう時点ではパスとファイルの実体が -- - ・致しなくなる可 能性もあります。 これらの問題を回避するもっともよい方法は、 newsys- log と syslogd が協調することです。具体的には、 new- syslog がファイルを処理したら syslogd にそれを伝える のです。このようになっていれば、 syslogd では書出しの たびにファイルをオープンしなおす必要はなく、 newsys- log から通知されたときにのみファイルをオープンしなお せばよくなります。 前回説明した newsyslog コマンドの動作のなかで、フ ァイル・ローテーションの処理をおこなったあと、とくに 指定がなければ syslogd プロセスに SIGHUP シグナル を送る機能についても紹介しました。これは、ファイルの ローテーションをおこなったので、ファイルをオープンし なおしてほしいという要求だったわけです。 syslogd プロ グラムを解説した際にも、 SIGHUP シグナルを受け取っ たときにファイルをクローズしてオープンしなおすコード を紹介しています。 プロセス間での通知 プロセス間でやりとりをおこなう場合、いくつかの方法 が考えられます。 ・パイプを介した通信 ・ファイルを介した通信 ・不ットワークを利用した通信 ・シグナルによる通知 パイプを介した通信をおこなう場合、 2 つのプロセスの あいだに基本的には親子関係がある ( 厳密にいえば共通の 親をもつ ) 必要があります。パイプの作成は、 pipe システ ムコールにより簡単におこなえます。双方向の通信が必要 な場合には 2 本のパイプを用意し、送信用と受信用とに役 割を分担して利用するのが普通です。パイプを用意したあ とで fork システムコールによりプロセスを分け、送信用と 受信用の不要な端をクローズしてからそれぞれのプロセス の処理に移るというのが一ヨ殳的な処理方法になります。 今回の syslogd と newsyslog の場合には、パイプを用 意してからプロセスを分けるといった処理はおこなえませ ん。そのため、パイプを用いた通信は困難です。 UNIX MAGAZINE 2005. 12

6. UNIX MAGAZINE 2005年12月号

屈陣である。どちらも、急漣に発展しつつある。 太陽電池には、変換効率 ( 発電電力を光のパワーで割っ た値 ) が 15 ~ 30 % を超えられないという制約もあるが、コ ストあたりの発電電力は数十倍も伸びる可能性がある [ 3 ] 。 重要なのは発電効率ではなく、太陽電池を作るのに必要な エネルギーとの比率である。それには、太陽電池を薄くす ればよい。これは、自動車を例にとると分かりやすい。内 燃機関を利用する自動車のエネルギー効率は約 20 % でほば 限界に達しているが、車体の軽量化や運転方法の改善など により、燃費を何倍も改善できる余地がある。現在、出力 が IA の太陽電池は 15 , 000 円程度で買えるが、いずれは 1 , 000 円くらいに下がるだろう。そうなれば、もっと大き くて安い太陽電池を備えた中継器により、強い光を用いた 通信が可能になる。変換効率は落ちても、得られる電気は 多いのだ。 太陽電池は、夜間には稼動できない。日本では、太陽電 池による発電可能時間は 1 日平均で 3 時間といわれる。も ちろん、通信は夜間にもおこなわれるが、そのあいだは風 力を利用すればよい。 最近、、、風レンズ効果 " を利用した小型風車が開発された [ 4 ] 。風車の周囲に簡単な構造の羽根を付ければ、風が弱く ても十分な量の電気が得られる。 2 台のノート PC に相当 する 50W の電気が、 ( 東京でいつも吹いている ) 秒速 2m 程度の風で起こせるのである ( もちろん、風のない夜のた めに電池は必要だが ) 。 世界厘仂地図 [ 5 ] は、衛星や地上のセンサーなどから得 たデータをもとに作成した、地球ーヒの風力を表す地図であ る。ある程度強い風だけがプロットされており、現時点で は 8 , 000 強の地点しか記されていないが、悲観することは ない。風レンズなどの技術によって閾値が - ドがれば、風力 の利用が可能な地点は指数関数的に増加する。関西電力と 日本気象協会は、風力を効率よく利用するための風車配置 支援システムの開発・販売を始めている [ 6 ] 。ポトムアッ こういったソフトウェ プの通信ネットワークを作るには、 アカ坏可欠なはすである。 通信の遅さと著作権 可視 ) 甬信ネットワークでは、光ファイバーより高速に 拠点間を接続できる方法は現状ではみあたらないただ コンテンツ更新のためのトラックバック Ping や RSS の UNIX MAGAZINE 2005 . 12 2 利用が進み、著作権に関する意識やビジネスモデルカ畯わ っていけば、超高速の遠足旧甬信の必要性は薄れていく。 現在、遠距離間で超高速の通信が必要な理由は 2 つある。 1 つは技術の未成熟さ、もう 1 つは著イ信呆護である。前 者の問題は解決されつつある。たとえば、 GoogIe のロポ ットは私のプログページに 1 カ月に 1 , 000 回近くクロール してくる。私のプログは週に 1 ~ 2 回しか更新しないので、 1 , 000 回を 10 回、つまり 1 % に減らせるはすだ。 Google 側は、 Ping があったときだけクロールすればよい。 RSS の普及により、この効率化はさらに進むだろう。もう、同 じことを大量に繰り返し送信しなくてすむ。 10 年後、、、ク ローリング " は死語になっているかもしれない。 著作権については、たとえば複製を禁じていないデータ は近いところにキャッシュしておけばよい。データのコピ ーが許されないから、そのつど、サーバーにアクセスする 必要があるのだ。 Winny は、キャッシュがうまく機能す ることを証明した。 300GB のハードディスクが 100 ドル を切る時代である。 10 年もすれば、 5TB のディスクも 1 万円になるだろう。映画は 1 本で数 GB だから、 IOTB な ら 1 万本カ呆存できる言 1 になる。最近の Winny ネット ワークでは、 MP3 ファイルではなく CD イメージがその まま置かれている。 15 年後には、手許のマシンにすべての 映画と音楽、書籍、 TV 番組などを保存できるようになる だろう。 CODEC という言葉は死語になるかもしれない。 すでにネットワーク上にある情報とくらべると、新たに 追加される情報はごく少である。率でいえば、 1 日あたり 全体の 1 % 以下であろう。たとえば、 Mixi の日記は 4 , 000 万件保存されていて、 2 週間で 200 万件が追加される。 1 日にすると 1 % 以下である。保存されている情報にアクセ スしたいときは、近くのキャッシュを利用すればいいだろ う。人間は、近くにいる人とコミュニケーションすること が多い。遠くにいる人とリアルタイムに通信したいときだ け、有料の超高甬信を利用すればよい。そう考えれば、高 速な回線は現在ほど必要にならないのではないだろうか。 WIKIPEDIA[7] は、 GNU Free Documentation Li- cense というライセンスのもとで公開されており、キャッ シュの利用はもとより、コピーも可能だ。 mF247 [ 8 ] とい う音楽サイトは、コピーを許している。いす楸コピーを 許可する出版物も出てくるだろう。たとえば、 GoogIe は 2 , 000 万冊の本を電子化してネットワーク上に置くシステ なめらかなコンピューティング 153

7. UNIX MAGAZINE 2005年12月号

なめらかな コンピューティンク、 ボトムアップ型通信基盤 中嶋謙互 前回は、「遅くて安いコンピュータ」と題して、紙に印刷 できる、ごく安価なコンピュータについて述べた。今回は、 現代のコンピューティングにとって不可欠な基盤である通 信ネットワークをとりあげる。 インターネットの通信インフラ 現在、インターネットの通信インフラは、少数の比較的 大きな企業によって管理されており、ネットワーク接続の 選択肢も限定されている。たとえば、遅くて不安定でカバ ー範囲も狭いが安い、といった通信方法を選ぶ余地はほと んどない。通信をどんどん高速化し、カバーする範囲をひ ろげるための各社の投資の少なからぬ部分を、なぜかはよ く分からないままに私たちが支払うことになっている。 価格体系は、いろいろな要因の影響を受ける。たとえば 日本では、才を孑だけでなく、規模 ( 通信インフラの構築には 数千億円規模の投資が必要 ) 、法律 ( 諸外国よりも厳しい電 波法 ) 、政治やユーザーの知識不足などがコストを押し上げ る要因になっている。中国のように、情報統制や、都市間 の経済格差などによって問題カ辧隹化している例もある。 ところが、半導体のコスト・パフォーマンスの向上や周 辺才翅孑の進歩により、ポトムアップ ( 草の根 ) 的な通信イン フラの構築カ儚物語ではなくなってきた。 Wi-Fi 次の 10 年、 Wi-Fi の利用範囲は急速にひろがるだろう。 現在の Wi-Fi は 2.4GHz 帯を使う IEEE802. llb/g の無線 LAN が主流で、高速化に向けた競争も激しい。た だし、無線になっているのは、 ADSL などの高速有線回線 の末端からユーザーまでの数メートルぶんだけである。つ 152 まり、現状の Wi-Fi は有線の回線に依存している。先日、 Google とサンフランシスコ市によるⅥ Fi サーピスカ第舌 題になったが [ 1 ] 、広告料収入を前提にしているとはいえ無 料にできるのは、キャリア各社カ昿分の投資をして有線回 線を敷設しているからだ。 WiMax ( IEEE802.16 * ) はど うだろうか。日本でも規制緩和が進んで利用可能になるか もしれないが、免許が必要ということもあり、ボトムアッ プ的な成長には限界がある。 本当に自由な草の根ネットワークを構築するには、許認 可カ坏要な無線を使うか、国や企業か嗷設した有線の回線 に依存しない方法でインフラを構築する必要がある。それ には、どういった手段があるだろうか。 可視光通信 現在の Wi-Fi ほどの高速性や安定性はないが、法律や 企業などによる制約を受けずに通信インフラを構築する方 法がある。それが、目に見える光を利用して通信をおこな う、、可視光通信 " である。現時点では光を用いた通信に関 する法的規制はなく、許認可も不要である。したがって、 の分野における技術の進歩は、電波法の規制を受ける範囲 の電磁波などよりもはるかに速いと思われる。誰もカ蔀廾究 開発に参加し、通信ネットワークを利用できることになる。 日本でも、、可視光通信コンソーシアム (VLCC) [ 2 ] " が 設立され、研究が活発化している。この手法の基本的な原 理は、、、光を受けている太陽電池の出力が少ないときは 0 、 多いときは 1 " として通信することである ( 実際には、速度 と信頼性を向上させるためにさまざまな変調方式を組み合 わせる ) 。現在は到〕聟巨離が短く、通信速度も遅いが、これ カ吮展すれば数百数 km 間での通信が可能になるとい う。もちろん、実際には霧が出たり、動物などが光を遮る こともあるから、光ファイバー通信に匹敵する速度や安定 性は期待できないだろう。しかし、法規制がなく、糸各十 . の地権者との交渉も不要なので、可視信の中継器を数 多く設置してアドホック・ネットワークを構築すれば、、、遅 い通信ネットワーク " も実現できる。 だが、それにはいくつかの課題がある。 1 つは中継器の 中継器の電源として使えそうなのは、太陽電池と小型の 中継器の電源 電源、もう 1 つは通信速度である。 UNIX MAGAZINE 2005. 12

8. UNIX MAGAZINE 2005年12月号

の設疋をおこないます。 5. インストールの開始 newfs でファイルシステムを作成し、パッケージをイン ストールします。 6. インストール後の設疋 kterm 、 cvsup 、 rsync などをインストールします。 成します。また、 Configure → Packages から emacs 、 ユーザーのホーム・ディレクトリは、 /home の下に作 の設疋、グループとユーザーの追加をおこないます。各 root のパスワード、タイムゾーン、キーポードやマウス もうすこし細かく設定しなけ これで基本的なインストール作業は終了です。インスト サーバーとして使うには、 X の言又疋 ディスクにインストールした FreeBSD で起動します。 UNIX MAGAZINE 2005. 12 FreeBSD 5.4 のデフォルトの X 環境は Xorg で、 BD2 ムービーが再生できるなど、なにかと便利だからです。 りませんが、複数のターミナルが同時に使えたり、 MPEG しよう。サーバーマシンで X を動かす必要性はあまりあ ればなりません。しかし、その前に X を設定してしまいま 3. インストールするパッケージの選択 X も使うので、 X-Kern-Developer を選択しました。 4. インストール方法の選択 インストール方法は、、ネットワーク " を選びます。天文 台内はファイアウォールで守られているので、 FTPpasー sive を選択します。ネットワークに接続するわけですか ら、マシンの IP アドレス、ネットマスク、ゲートウェイや DNS サーバーの IP アドレスなどを入力する必要があり ます。また、 DHCP を選ぶこともできます。その場合 には、上記のネットワーク情報は基本的に DHCP サー バーカえてくれるので、入力する必要はありません。 前回お話ししたように、 BD2 の GbE には SysKonnect と lntel のチップを使った 2 系統があります。残念なが ら、 FreeBSD 5.4R は SysKonnect に対応していませ ん。そこで、 lntel の GbE カード (lntel PRO / 1000 GbE) を挿し、これをグローバル側との接続に使ってい ます。これは、 OS 側からは eml というデバイスとし て認識されるので、このデバイスに対してネットワーク ール・プログラムを終了し、 CD を取り出してからハード ーし 連載 / 天文学と UNIX 上の ATI RAGE XL ( メモリ 8MB) も使えます。 通常は、 xorgcfg や xorgconfig などを用いて設疋ファ イルを生成しますが、今回はプリミテイプな方法を使いま した。まず、雛形となる /root/xorg. conf. new を以下の コマンドで作成します。 #/usr/X11R6/bin/Xorg ——conf igure VGA カードに関する設定は自動的におこなわれますが、 上記の雛形ファイルはそのままでは使えません。といって も、 Screen セクションを使用している環境に合わせて修正 するだけです。今回のシステムでは、以下のように変更し ています ( 下線部を追加 ) 。 Section ldentifier "ScreenO" "CardC)l' Monitor "Monitor() " DefauItCOIorDepth 24 SubSection "Disp1ay" Viewport 0 0 Depth Modes EndSubSection 24 " 1280X1024 " 日本語 106 キーポードを利用していて、 Control キー と CapsLock キーを入れ替えたいときは、 kbd のエント リを以下のように修正します ( 天の川クラスタでは Happy Hacking Keyboard とロジテック ( ロジクール ) の 3 ポ ldentif ier "KeyboardO " Section t'InputDevice" タンマウスを使っているので、この修正は不要です ) 。 Driver 0ption Option Option EndSection " kbd " "XkbMode1 " " XkbLayout " "XkbOptions " " jP106 " "JP" "ctrl : swapcaps" 修正したファイルを /etc/xll/xorg. conf にコピ て X を起動すると、ぶじに X が立ち上がりました。 ファイルサーバーの言又疋 /usr/sbin/sysinstall に変更されていて、びつくりしました。 4 テストに使った FreeBSD 6.0 beta3 amd64 では、場所が ほとんどの設定変更をこのファイルだけでおこなえるので、 が、今回は /etc/rc. conf を編集します。 FreeBSD では、 多くのサービスは /stand/sysinsta114 から起動できます 次は、ファイルサーバー (NFS サーバー ) の設疋です。 119

9. UNIX MAGAZINE 2005年12月号

このあと、新しいログファイルを作成します。ファイル は mktemp コマンドを使って作成します。作成したファ イルの所有者とグループを調整し、さらにパー ミツンヨン を設定します。その後、実際のログファイル名に変更しま す。 mktemp logfile. ZXXXXXX chown user : group logfile . ZXXXXXX 続いて、ソースコードをみながら newsyslog コマンド chmod perm logfile . ZXXXXXX mv logfile . ZXXXXXX 10gfi1e がどのような処理をおこなっているかを紹介するつもりで したが、シグナルが必要な理由の説明に思ったより紙幅を これらの処理カ鮗了してログファイルが用意できたら、 とられてしまいました。そこで、 newsyslog コマンドがお syslogd プロセスにシグナルを送り、新しいログファイル こなう処理をシェルコマンドで表してみましよう。 が用意できたことを通知します。 もちろん、設疋ファイルの内容やログファイルの状態に kill ー 1 ' cat /var/run/syslog ・ pid' よって実際の処理は変わります。ここでは、ログファイル 最後に残っているのは、保存ファイルを圧縮する処理で 名は logfile 、保存ファイルは log 用 e. 0 ~ 10g 用 e. 3 の 4 つ す。処理を開始する前に、 syslogd がファイルを正しくオ で、 bzip2 で圧縮するものとします。さらに、所有者とグ ープンしなおすのを待っため、 sleep コマンドにより 10 秒 ループはそれぞれ user と group とし、ファイルのパー 待ちます。 ッションを、 perm " で表すことにします。 sleep 10 最初におこなうのは、不要になる保存ファイルの削除で bzip2 logfile . 0 chmod perm logfile . 0. bz2 す。 chown user:group logfile . 0 . bz2 rm logfile . 3 あとは bzip2 コマンドでファイルを圧縮し、パー rm logfile . 3 . gz rm logfile . 3. bz2 ョンや所有者を調整すれば処理は終了です。 実際に存在するのは上記のうち 1 つだけのはすですが、 ファイルがあるかどうかにかかわらず、 3 つのファイルす 今回は、 newsyslog コマンドがシグナルを使って sys- べてを削除しています。 logd コマンドに通知する理由を説明しました。 UNIX で 次はローテーション処理の本体です。この処理は、番号 のファイル操作は、最初にパス名を用いてオープン操作を、 が大きなファイルから順に 0 番まで繰り返されます。 その後はファイル・ディスクリプタを用いて書込みをおこ ないます。そのため、パス名とファイル・ディスクリプタ mv logfile . 2 . bz2 logfile . 3. bz2 chmod perm logfile . 3. bz2 の対応を管理するのに通知が必要になります。 chown user :group logfile . 3. bz2 また、実際に newsyslog コマンドがおこなう処理をシ mv コマンドで保存ファイルの番号を 1 増やし、ファイ ェル・プログラムのかたちで確認しました。この動作を理 ミッション、所有者やグループを調整しています。 ルのノヾー 解しておくと、プログラムの理解も容易になると思います。 同様の手順で、 10g 用 e. 1. bz2 から logfile. 2. bz2 を作る ( たじみ・ひさかす ) 処理、 10g 用 e. 0. bz2 から log 用 e. 1. bz2 を作る処理もおこ なわれます。 次は、ログファイルを保存ファイルに移す処理です。 の段階ではファイルの圧縮はおこなわず、 ln コマンドを使 ってディレクトリ・エントリだけをコピーします。 ln logfile logfile . 0 法と組み合わせるといった工夫が必要です。ファイルなど にやりとりしたい情報を用意し、準備カったことをシグ ナルで伝えるのです。 newsys 厄 g がおこなう処理 ツン ☆ 110 UNIX MAGAZINE 2005. 12

10. UNIX MAGAZINE 2005年12月号

ファイルサービスでは、サーバーを IJNIX とし、 NFS で負荷を低減させています。端末側では、イ反想計算機上の Linux から NFS をマウントし、さらに Samba を用いて 実計算機上の Windows からも同じ領域を使えるようにし ています。 仮想計算機はファイルサービスの利用に不可欠なので、 ユーザーが終了できない仕組みにしています。また、ユー ザーが仮想計算機を不必要に意識しないように、実行中の ウインドウを隠すといった工夫もなされています。 ・ Linux と VMware 内のⅥⅲldows@大阪市大 ・・安倍広多、石橋勇人、松浦敏雄 ( 大阪市立大学 ) 大阪市立大学の学術情幸既合センターにおける情報処理 教育用システムの紹介です。 京都大学の場合とは逆に、実計算機の OS を Linux と し、イ反想計算機上で Windows を稼動させています。 Linux の利用により、遠隔管理カ瑢易になり、管理者が 基本的な部分にも手を入れやすい環境となっています。仮 想言 t 算機上の Windows は遠隔管理しづらい部分もありま すが、実計算機七の Linux で遠隔管理を補助しています。 その他、ハードディスク故障時にディスクレスでプート させる工夫や、ヘルプデスクやサポート、バグやセキュリ ティ・パッチへの対応などについての説明がありました。 ・ iMac@東大・・・・・・安東孝二 ( 東京大学 ) 東京大学の教育用計算機システムの紹介です。 最初に、 1986 年度に駒場キャンパスに情報処理棟が作ら れてから、現在のシステムが導入されるまでの変遷が紹介 され、それぞれの時期のシステムのコストや安定性につい ての説明がありました。 現在のシステムは、端末に iMac を採用したことで話題 になりました。また、ディスクレス・プートにすることで ハードウェアの故障率を減らし、コスト削減を図っていま す。 GUI でも管理できるため、技術系職員の才亢も薄れ ています。 教育用システムとして Mac OS X を使う場合に特有の 工夫として、 UNIX のパーミッションの仕組みを用いてソ フトウェアの盗難に対処しているといった話がありました。 ・ディスクレス Linux@阪大 ・・・桝田秀夫倞都工芸繊維大学 / 大阪大学 ) UN 工 X MAGAZINE 2005. 12 大阪大学サイバーメディアセンターの・情報教育システム の紹介です。 端末の OS は Linux で、ディスクレスで動かしていま す。既存技彿 i の応用により、低コストでディスクレス化す ることができました。また、 uni 。 nfs の利用により、端末 にデータが保存できる仕組みにしています。 教育用端末では、いわゆる Office アプリケーションが 使えることも重要です。そこで、このシステムの端末では CrossOver Office を導入し、 MS Office を利用可能にし ました。 CrossOver Office は、 WINE をベースとして、 Linux 上で Windows アプリケーションを動かすために 開発された製品で、 Office アプリケーションなどを実用的 なレベルで動かすことができます。 ・個人所有ノート PC を用いた情報環境 ・・・齊藤明紀 ( 鳥取環境大学 ) 鳥取環境大学の教育用計算機環境の紹介です。 現在、大学の言 1 算機の需要は増加傾向にあります。授業 だけでなく、放課後などに就職活動や課題のために利用す るケースも増えているからです。そこで、大学が端末室を 用意するのではなく、学生にノート PC を持たせる方針を とりました。 これには、設置場所カ坏要、自宅でも環境カ駛えるとい った利点があります。一方、環境の統一についての問題や ソフトウェアのコストがユーザー数に比例して高くなると いった問題があります。 学生が異なる機種のノート PC を利用している場合、授 業やサポートを機種ごとにおこなう必要があります。この 問題を解決するために、鳥取環境大学では学生カ鎖冓入する ノート PC を 1 機種に限定しています。ソフトウェアのコ ストは、キャンパス・アグリーメントなどのライセンス体 系を利用して低減を図っています。 ・ KNOPPIX をもとにしたハードディスクレス・プログ ラミング演習室・・・・・・小菅貴彦 ( 日本電子専門物交 ) 日本電子専門学校の情報教育システムの紹介です。 このシステムでは、 CD などからも起動可能でカスタマ イズも容易な KNOPPIX を利用しています。また、カス タマイズした KNOPPIX を 1 枚の CD に収めれば、自 宅などでの自習に役立てることもできます。 149