表紙のアイデアを持って楽しさと賞を目指してご参加下さい！　LJ のメンバーは６年間も Linux Journalの表紙を考え続けていささか疲れました。そこで、読者から表紙のアイデアを募ることとしました。 次の号と特集に合った表紙のアイデアを求めます。

・84号、４月−−インターネット／イントラネット

・85号、５月−−Linux の研修と認証

・86号、６月−−国際化と新たな市場

Mojolin は、そのオンライン求人／履歴書データベースに国際サポートを加えた。求人情報ト及び履歴書が全地域の仕様で登録出来るようになった。この新機能により、国、及び米国とカナダの州による検索が可能になった。加えて、リンクはサイトをドイツ語、フランス語、イタリア語、スペイン語、ポルトガル語に翻訳するための BabelFish を備えている。求職者に最終機会を与える夜間ｅ−メール代行の機能、 ウェブマスターが自分のサイトに、Mojolin の求人情報を含めさせる機能が含まれている。

LinuxITは、ソフトウエア、ハードウエア、文書、求職、及びユーザー・フォーラムのディレクトリを含む Linux portal を有し、Linuxのユーザーと専門家にサービスを提供している。

この吸収は、ヨーロッパにおける LinuxITの主要ベンダー−中立ソリューションプロバイダとしての地位を強化する。 01Linux はソリューション及びサービスのプロバイダとして自体のマーケティングを広範に進めて来ており、優れた技術専門家による質の高いことで名声を博して来た。

LinuxIT専務取締役Peter Dawesは、「01Linux の LinuxIT への統合により、我が社のサポートと専門家サービスが向上し、一つのサーバーから数百の重要使命システムを有するコーポレートまであらゆる型の顧客にトータルLinuxサポートを提供出来るようになった。我が社の受注開発、アプリケーションのLinuxへの連結、訓練計画と結びついて、linuxITが成長する需要に対しLinuxとオープンサービス・ノウハウにつき独特の地位を占めることを意味する」と語った。

Writing GNOME Applications
by John R. Sheets
ISBN: 0-201-65791-0

Writing GNOME Applications は Linux プログラマーが GNOME の基礎を習得し、これを用いて実際のアプリケーションを書く方法を理解するのに役立つ。本書は、重要事項に絞って、GNOMEの基本要素全体を説明し、これらが働く様相と理由を説明する。大量の参照資料として役立つよりも、本書は、最重要のファンクション呼び出しを詳細に説明し、、アプリケーション開発で働かせる方法を示している。まもなく OpenBook ライセンスの下であらわれるので、これと他の表題につき.　OpenBooks website に注意されたい。

PostgreSQL: Introduction and Concepts
by Bruce Momjian
ISBN: 0-201-70331-9

PostgreSQL: Introduction and Concepts, PostgreSQL 世界開発チームの創立メンバーが書いた。複雑だが肝要なこのシステムを理解し使用するため需要の多い指導書と実用案内になっている。本書はここlocationの PostgreSQL ウェブさいとから入手出来る。

Manning Books の新しい書名Data Munging with Perl が注目されている。曰く「一つのフォーマットから別のフォーマットへの転換、俗語で 'munging'、は最も普通のプログラミング作業の一つである。新しい Manning book, Data Munging with Perlは、この重要過程を詳細に検討して、Perlがこの仕事に如何に適しているかを示す。本書は、任意のプログラム言語を使って日常的にmungingを行うプログラマーを対象としている。Perlに習熟したプログラマーは、仕事が楽になる新Perl技術を学習出来る」。

Data Munging with Perl閲覧希望者には、Manning はブックスオンラインの成分をおすすめする：目次、見本用に二つの章、索引及びソースコードが www.manning.com/cross/ で閲覧出来る。付属として、読者と著者 Dave Crossとの間の討論のため著者オンライン討論フォーラムを出版社が運営している。

本書は、現在PDFフォーマットで、間もなく売り出される印刷書物より割り引いた価格で入手出来る。ソフト装丁印刷版、304 頁、$36.95 。E−ブック版 - PDF format, 2 MB, $13.50

最後に、 CMP Books は KDE 2.0用プログラミングの新しい書名を紹介する。

Programming KDE 2.0
By Lotzi B�l�ni
ISBN: 1-929629-13-3, Price: US$39.95 、CD-ROM付き印刷書 265頁で販売。

本書は、Ｋデスクトップ環境(KDE)でのアプリケーションを開発のすべての側面の説明を目的とするとCMP は言う。これはイベント起動プログラミングの基本から出発して KDE 開発を基礎から説明する。GUIウィジットおよびダイアログの設計と管理を経て、フォントとテキストのコントロール及びピクチャーディスプレーで終わる。著者は、オブジェクト／コンポネント・モデルと新Kannosa共有ライブラリ技術を用いるアプリケーション・プログラミング・インターフェイス(API)の用法、多重タスク・アプリケーションの管理法、埋め込みアプリケーションの構築法を説明する

ZF Linux Devices は、「最軽量PC」と呼びたいMachZを創り出した。MachZは、一インチ平方のチップに適合しながらも、Linuxを搭載した完全コンピュータである。MachZを巡って、医療装置や工場設備から家電、自動販売機まで６０社以上が製品を設計している。

MachZチップ上PCの用途は

・無線ネットワーク・ハブ

・インターネット／ウェブ接続

・位置決めシステム

このウェブペイジ上でのセキュリティに関する最近のご意見によると、(／で指定される.)Linux Security FAQ に興味を持ったことのある人には役立つと思われます。

ShowMeLinux's 一月号が特別記事、ニュース、サポート満載で販売中です。

The Duke of URL に幾つか興味のある項目があります。

・Linux Buyer's Guide #7 このガイドは、Linuxで最も良く働く（万人に強調したいのはATI分野）三つのシステムとペリフェラルの（一般需要による）リストを含んでいる。別のセクションには、本月のトピックと、Linuxの将来計画を少し概観している。

・The Duke of URLに WinLinux 2000 review があって、Windows 9x のトップに位置する管理をおこなうディストリビューションのメリットを検討している。

・kernel 2.4の新発表に伴い、kernelのコンパイル方法から Linux 2.4、 Linux 2.2、 Windows 2000 SP1の間のベンチマークやLinux, 2.4.0の最大最新版における変更までを含む overview がある。突入や更新を検討中なら見る価値がある。

最後に、Slashdot には、LinuxがＭＳに取って最も脅威であると述べた Steve Ballmeran article がある。

PlugSys International は、本日新Max サーバーペイジ (MSP) 製品を発表した。これはＸベース開発者にLinuxに移植しサーバー側スクリプトを行う信頼性の高い経済的な方法を与える。古典Ｘベース・コマンドとファンクションを用いて、開発者は、DBFファイル又はODBCファイルに記憶されたデータにアクセスし、その結果をHTML及びJava文書と混合するすることが出来 る。Max サーバーペイジ開発は、埋め込みＸベース、コントロール構造体、説明、コマンド及びファンクションを用いてHTMLテンプレートを創ることにある。ベータテストの最終段階が進行中である。試験希望者は申し込まれたいapply. 会社は、Red Hat 6.2で働くウェブサーバーマシンに対しウェブ開発とアクセスの経験があるＸベース開発者に特に関心がある。

ソフトウエア販売業者及び消費者のための世界一の評価サービスプロバイダRunaware, は、オンライン試験と補完資料通じてLinuxへの関心を深めるため英国資本オーブンソース・プロバイダSlashTCO との提携を本日発表した。

Runaware を用いてソフトウエア購入者はダウンロードすることなくウェブブラウザを通じてLinux製品を試験出来る。SlashTCO が提供する説明書などが評価プロセスを助ける。

世界的言語ソフトウエアプロバイダー WordWalla, Inc.が、, 新しいEmbedded Linux Consortium, LISA と Unicode Consortium 開発、普及のため三つの主要企業に合流した。

三つの主要企業のメンバーとして、WordWalla はLinuxアプリケーションとUnicodeスタンダードの最新開発に協力する。

VMware, Inc. 世界で300社が参加したGSXサーバー・ベータプログラムを完了し、本日から http://www.vmware.com/で購入出来ると発表した。

VMwareの特許申請中MultipleWorlds に基づいて、 GSX サーバーは情報技術(IT) 組織メインフレーム・コントロールをインテルベースのサーバー上で与える。このソフトウエアは、必要なサーバーを減らし、サーバー申し込みを試験して設定と管理を自動化することにより、増大する新規申し込みとサービス応答に当たってIT技術者がリソースを強化するのを助ける。

Linuxシステム用VMware GSX サーバーは、単一ライセンス用に $2,499の価格で、電子販売網を通じてVMwareから直接本日より入手出来る。シルバー、ゴールド及びプラチナ・レベルのプレミアム・サポートが事態毎に登録により得られる。GCXサーバーのパケージ版はVMware と近所の小売店で入手出来る。

・認証は、本来のUNIXパスワードファイル、PAM（したがってNIS又はNTも）又は完全にSQLに基づくことが出来る。SQLに基づく認証は、ユーザーが多くても認証が早くなるよう、スケールを工夫しなければならない。

・ISPdを通じる地域認証。現在Cistron radiusd 1.6.4 を用いているが、オープンソースは任意の地域サーバーが迅速にISPdに組み込まれることを意味する

・顧客情報の完全管理は、簡単なウェブベースのインターフェイスを用いて、得られる。

・パスワード維持のような一定の機能に付いてコマンドライン・ツールが利用出来る。

・請求書発行は cron ジョブとして走らせることが出来る。ISPdは、出来るだけ少ないメンテナンスを要求する設計となっている。

・ISPdは、UNIXドメインソケットとTCPドメインソケットの双方を聞く。ISPdはその認証計画の利点を生かすので同一マシン上でサービスを走らせる必要がない。

オンライン記憶、データアクセス及びe−メール管理ソリューションのソフトウエア開発者 OTG Softwareが 、Red Hat　Linux　ソリューションをサポートするLinux用新ソフトウエアDiskXtenderを発表した。この新製品は、真の不均質集中記憶管理を可能にすることを目的とする。OTG はWindows 2000/NT記憶システムの専門知識をLinuxに拡張して最近発表したUNIX用 DiskXtender 上に構築している。

Copyright © 2001, James "Badger" Bajgar.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 62 of Linux Gazette, February 2001

英国の学校におけるLinux

By James "Badger" Bajgar

コンピュータとそのハードウエア／ソフトウエアに関してここ数年技術は急速に変化したが、学校と教育において、どんな変化があっただろうか？

英国の中等学校を見てみよう。この学校は、約２年前に新型PCに更新したときまで、386上で GCSEと A-レベル作業を完成するのが常であって、それ以来定期的に新型PCを入手して来た。したがって、現在、（6学年を含む）1500名の生徒に対し150台以上のPCを持っている。他の学校では30名しか生徒のいない一学級用に十分なだけ得るのにくろしている処もある。

これらのシステムはまた良好な状態である。現場技術者が稼働状態に保っている。仕様も、特に、主として基礎を生徒に教えるため使うとき、良好である。 By the time they are doing GCSE/A-レベルの作業をするとき、単純事務作業、特にワープロ作業が多いので、高度の仕様は必要ないのだが、彼らは極めて高速のシステムを持っている。

これらコンピュータすべてはネットワーク化されており、生徒達は校内どのコンピュータからも文書を記録出来、前にセーブした文書を取り出すことが出来る。これはまた、生徒達がBIOSやコントロールパネル設定などをいじるのを防止している。生徒達それぞれが追跡出来る固有名を持っているからである。

これら全部のセンターには何があるか？ウインドウズは多くの生徒達が見やすいので、良い選択かと思われる。しかしLinux版が同じくらい易しくなったので、最早大量の知識を必要としない。そこで、これらコンピュータがすべてネットワーク化されているので、LINUXが良い選択肢になる。また、教育の重点が職業の資格取得にあるなら、Linuxの方がウインドウズより（未だそうでなくとも）普及すし、次第に多くの事務用コンピュータがLinuxで働くので、どんな分野に進むにせよLinuxの経験は生徒達の利益になるに違いない。また、これは良好なネットワーク特性を持っており、目的に合わせられるので、生徒達は、その競争相手より安定に働くと考える。価格の違いも忘れてはならない。競争相手のネットワーク化OSは数百ポンドもするのに比べ、SuSE Linux 6 の完全6-CD版は｣30 （持っている知人がいればもっと安く）で手に入れられ、それで金儲けさえ出来る。

したがって、この学校はLinux Red Hat 又は SuSEを働かせている。その通りか？違う！ウインドウズを働かせている。筆者はこの質問を英国政府にした。生徒達が、Red Hat 又は SuSE　Linuxのような別のグラフィカルOSの少なくとも基礎を少なくとも経験する機会さえ持たなかったら、今日のコンピュータ「大世界」で生き残る方法があるだろうか。

良かろう、Linuxを把握するのは易しい、だが、今日の雇い主は、習熟していない限り君を二倍には見ない、何をしようとするのか、嘘をつくのか？

したがって、GCSE及びA−レベルを得る方法につき政府が新ガイドラインを作り、複数OSに関する知識を支援するのを許す時期ではないのだろうか？これはまたLinuxとオープンソースのの全可能性を広く示すのに役立つ筈だ。通常のソフトウエアの代わりにオープンソース・ソフトウエアつかうことで政府の金が節約出来ることを忘れまい。利益は明らかだ。高価なサイト・ソフトウエア・ライセンスなど不要だ。

これは、若い世代の間にオープンソースに対する興味を生じる筈だ。また、政府と地方自治体が、税収を多くしたいため偏見を持っているのではなく、自分たちがそれ程多くを得なくとも廉価なソフトウエアを支援することも示す。だが、彼らはいずれにせよ、そんなに多くを必要としない筈だ。ソフトウエア購入に多くの資源を投資する必要がないのだから。

Copyright © 2001, James "Badger" Bajgar.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 62 of Linux Gazette, February 2001

Linuxの下でのPalmOS 開発

By David "Scooter" Lukens

要約

本記録はLinuxマシン上で機能する開発環境を得ようとの筆者の努力から生まれた。開発環境を共にCygwin環境下に置こうとの試みが不満足だったので、Linuxの下で働くすべてを得ることに集中した。これは搭載する必要のあるソフトウエアを説明する。その中には、エミュレータ、コンパイラ、ＳＤＫが含まれる。これはまた解決すべきコンフィギュレーション問題を説明する。

緒言

ある日、友人と語った「自分でPalmアプリケーションが書けたら良いな」

大した考えでもないように見えたので、開発環境を得るのに集めるものを調べた。友人は主にwin32ユーザーで筆者は専ら*nixユーザーだった。両者が共通に利用出来るプラットホームはwin32だったので、利用出来るツールの調査から始めた。

win32 に関し、Ｃ開発には二つの主な方法がある。一つはMetrowerkのPalm用 CodeWarriorで、これは我々の趣味型計画には大変高価だった。他の選択肢はPRCの使用で、これはCygwin環境下で働く。Cygwinパケージはhttp://sources.redhat.com/cygwin/ で入手出来る。Cygwinパケージにより、win32マシンが*nixマシンに似た感じとなり、win32に多数の*nix共通ツール(ls, dd, gccなど)のポートが作られる。

週の大部分をwin32上のツールと格闘した後、win32上で開発との考えは捨てた。したがってLinux、特にRedHat 6.0と6.2が次の選択肢で究極の解決策だった。

すべてをLinux上で働かせ使用出来るようにするには組立なければならない部品が幾つかあった。必要なものは下記である。

・Palmエミュレータ(POSE)

・POSE用ROM 画像

・PRCツール (PalmOS用出力のあるGCC )

・PilRC (リソース・コンパイラ)

・PalmOS SDK

開始(エミュレータの搭載)

先ず取り掛かったのはPOSE Palmエミュレータであった。これは各種のスキン（ハードウエアのグラフィック表現）と共にhttp://www.palmos.com/dev/tech/tools/emulator/から引き出せる。前にコンパイルされたプログラムを持っているとき、これは早い。POSEは兎に角FLTKライブラリを必要とする。FLTKはhttp://www.fltk.org/から入手出来る。ここでも別のコンパイルされたプログラムを持っているときは、直截である。

POSEをコンパイルして搭載したら、先に進めると思うだろう？だが、そうは行かない。POSEには未だROM画像が含まれていない。ROM画像はPalm自体の中のフラッシュROM上に常駐するPalmOSのスナップショットである。

ROM画像を得るため二つのことを行うことが出来る。第一に、エミュレータと共にやって来るPalmアプリケーションがあり、これによりPalmOS装置を離れてROM画像をPOSEが吸い込むことが出来る。第二の方法はhttp://www.palmos.com/dev/program/にあるpalm社のソリューション・プロバイダ・プログラムに合流することである。一旦合流すると、各種のROM画像を有するhttp://www.palmos.com/dev/pavilion/にあるプロバイダー・プログラムにアクセス出来る。ここの画像の幾つかは、正常画像とともに試験用とデバッグ用なので、どれを取るか注意を要する。また、この開発領域にある画像は、通常PalmOS装置上に置かない筈のものである。このサイトの別の場所で別のPalm更新及びROM更新が入手出来る。

さて、働くエミュレータが出来た。File: Newを右クリックして使用するROM、エミュレートする装置、グラフィック・スキン、及びramサイズを指定する。次のようなものが見える筈である。

コンパイラと付属品の搭載

全部を働かせるには幾つかの部品を搭載する必要がある。これらは、PRCツール,palmからのSDK、及びPilRCツールである。PRCツールは周知のGCCツールのポートであるが、Palmに関する出力を生じる。SDKは小数のライブラリでPalm API用のヘッダファイルの全群である。最後のPilRCツールはリソース・コンパイラである。

PRCツールはhttp://sourceforge.net/projects/prc-tools/で見出せる。これはbinutils、gdb、及びGCCへのパッチ群ならびにPalmOSをサポートするリンカーツールである。RPMもまた下記で入手できる

http://www.palmos.com/dev/tech/tools/gcc/dist/prc-tools-2.0-1.Linux-i386.rpm

次にくるのはSDKである。これらは、Palm.comのサイトから得られる。 PalmOS 3.5 SDK (執筆時現在最新）は 、Palm.comのプロバイダ・パビリオンに登録した開発者のみ利用出来る。早期のSDKは下記で入手できる。

http://www.palmos.com/dev/tech/tools/gcc/dist/palmos-1-2-3.1-sdks-1.tar.gz

3.5SDKは、これらの文書を含まない。

PRCを搭載すると、/usr/local/palmdev と呼ばれるディレクトリが出来る。sdkはここに入れなければならない。"sdk"と呼ばれるシンボリックリンクが、使用したいSDKを指すようにしなければならない。例えば、これは筆者の/usr/local/palmdev がどう見えるかを示す。

[scooter@scooter scooter]# ls -l /usr/local/palmdev/ 


total 28


drwxr-xr-x    4 root     root         4096 Mar  8  2000 Palm OS 3.5 Support


drwxr-xr-x    3 root     root         4096 Nov  1 10:03 doc 


drwxr-xr-x    2 root     root         4096 Dec 21  1999 include 


drwxr-xr-x    3 root     root         4096 Nov  1 10:02 lib 


lrwxrwxrwx    1 root     root            7 Nov  1 10:07 sdk -> sdk-3.1 


drwxr-xr-x    3 root     root         4096 Feb  9  2000 sdk-1


drwxr-xr-x    3 root     root         4096 Feb  9  2000 sdk-2 


drwxr-xr-x    3 root     root         4096 Feb  9  2000 sdk-3.1 

必要な最後のツールはPilRCで、これは、すべてのリソースファイルをコンパイルしてバイナリを生じる。これらの殆どは、ボタン、メニュー、及びグラフィックをスクリーン上に置いて行う。これらは、http://www.ardiri.com/index.cfm?redir=palm&cat=pilrcで見出すことが出来る。

これらすべてのツールをまとめると、機能的開発環境が出来上がる。ＣプログラムをLinux上でコンパイルするためgccを使うのには慣れているので、PalmOS用Ｃコンパイラは m68k-palmos-gccである。殆どのPRCコンパイラ・ツールは、m68k-palmos-*と命名されている。

Copyright © 2001, David "Scooter" Lukens.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 62 of Linux Gazette, February 2001

Spam撃退法!

("fetchmail"と"mutt"上のチップを用いる

"procmail"に基づく解決策 )

By Ben Okopnik

Spamは、今日ｅ−メールアドレスを持つ代償になった。ニュースグループに投書したり、オンライン顧客簿に登録したり、何かの方法でネット上にｅ−メールアドレスを持つと、間もなくspambotに刈り取られる。そうでなくともspamに金を取られる。さもなければ本当の情報交換に使われる帯域幅を占めて、ISPの全体費用を上げ−その結果、各利用者の利用料を上げる。この費用は、月当たり数千万ドルにも達し（優れた概観として、http://www.techweb.com/se/directlink.cgi?INW19980504S0003を参照）、これらは各利用者の月当たり請求額では約２ドルになる。アクセスを「バイト当たり」で支払っていると、さらに別のコストが掛かり、それらすべては利用者自身の消費時間に加算される。

何か出来ることがあるだろうか？答えはイエスだ。シェル・アカウントにアクセスし簡単なツールを使使って貰えば（シェル・アカウントを設けている殆どのISPがしてくれ

っｚ）Spamが我らのメールボックスを汚すのを止めることが出来、それらをISPで遮断することが出来る。spamを根絶やしにしたい人にはhttp://www.cauce.org/をご覧になることをお薦めする。これらはspamに対する立法措置を唱道している人達で、この人亜達のサイトは皆様に助けて頂ける方法をお知らする。しかし本文では、皆様のシェルアカウント又は皆様自身のマシンでspamを止める方法に絞る。

それには幾つかの方法があるが、最も普及しており−既にシェルアカウントを持つISPが提唱するのは−Stephen R. van den Bergによる"procmail" と呼ばれるプログラム、即ち保存すべきもの、篩い分けすべきもの、別のメールボックスに転送するものを知らせる 「レシピ」を用いるe-メールプロセッサである。したがって、二つのことを行う必要がある。第一に、 "procmail"の使用を自分のシステムに知らせる必要がある。第二に、したいことの出来る「レシピ」を一緒になって作る必要がある。

筆者の場合、"fetchmail"を経由して、daemonの用に働かせながら筆者のｅ−メールを受けた。これは通常Netscape経由でメールを受けている人にも推奨したいことの一つである。fetchmail は一つの仕事（メール受け取り）を行い、Netscapeがしようともしないこと（例えば、異なるプロトコルで異なるユーザーネームを持つマルチサーバー）、及びIPSの代わりにNetscapeが喜んであなたのメールボックスを読んでしまう、最悪で複雑な状況を大変うまく処理する。

通常、筆者の"fetchmail" は、五分ごとに作動して、使っている幾つかのサーバーからメールを引き出した上 "sendmail" に送ってから、筆者のメールボックスに入れる。ヒューと音がするのは、無駄な努力のように思えるが、大量バッチを処理する目的のMTAの規模祖小さくしていると推測する。・・・実際、"procmail" を使って、最後のステップを除去している。

筆者の"~/.fetchmailrc"、"fetchmail" が働いているときすることを制御するリソースファイル、の中には、簡単に

mda "procmail"

と書いた行がある。これは メール配達人として"sendmail"の代わりに"procmail"を使うことを"fetchmail" に知らせている。

これを行う別の方法ーIPSマシンでメールを篩い分けするときに推薦する方法−は、ホーム・ディレクトリの中に ".forward"ファイル（これはメールを「送る」こと−この場合は自分のプロセッサに−をMTAに知らせる）を作ることである。

".forward"を編集して、次の行の一つを入れる。

"sendmail" を使っているなら(この場合は引用符が必要)

"|exec /usr/bin/procmail"

I "exim"を使っているなら、代わりに

|/usr/bin/procmail

［注記：Mike Orrによれば、 "exim" はそれ自体のprocmail類似篩い分けランゲージを持っている。筆者は見たことがないが、"exim" ドキュメントにある筈だ］

"procmail"への実際のパスをタブルチェックするする必要がある。コマンドプロンプトで

which procmail

とタイプすれば良い。

これでメールがprocmailを通るようになった。効果は？・・・無しだ。えっ？そうなのだ−さらにレシピを設定しなければならない。レシピの入っている極めて簡単なファイル、".procmailrc"を見てみよう。、

PATH=$HOME/bin:/usr/local/bin:/usr/bin:/bin
MAILDIR=/var/spool/mail　　　 # 正しいことを確認のこと
DEFAULT=$MAILDIR/username　　 #完全にオープション
LOGFILE=/var/log/procmail.log # 推奨

:0:
* ^Sender:.*owner-linux-kernel-announce@vger.rutgers.edu
linux-kernel-announce

:0:
* ^Resent-Sender.*debian-user-request@lists.debian.org
debian-user

これらの始めの四行は、自分のシステムにとって変数が正しいと点検を済ませたら、すべての".procmailrc"に入れなければならない。次に来るのは−主要米国郵便局より多い分類をする膨大な".procmailrc"にも−（殆どの人が使う）spam篩い分けだけの全く複雑でないものにもｰ望の通り複雑さにに出来る。上記のレシピはメールを単に二つのボックス、"linux-kernel-announce" 及び"falling off the end"前に "debian-user" と、その他全部を$DEFAULTに入れると、の二つに分類する。

レシピは以下のように構築する。

:0:
* ^題名:.*test

joe

記号　　　　　　　　意味

========　　　　　　=======
:0　　　　　　　　　レシビ開始
　:　　　　　　　　 ファイルを使用 (強く推奨)
*　　　　　　　　　 条件開始
　^　　　　　　　　 行頭に合わせる....が続く
　 Subject:　　　　 ``題名:'' ....が続く
　　　　　 .　　　　任意の文字 (.) ....が続く
　　　　　　*　　　 0 以上の先行文字(この場合任意の文字）....が続く
　　　　　　 test　 ``test''
joe　　　　　　　　 整合に成功したら, フォルダーに $MAILDIR/joe を置く

ここでなされるのは、幾人かのソリューションである。この論文を書くため、筆者は Answer Gangのメンバーを呼び出したが、その答えの幾つかを−理由付けと共に−下記に示す。

筆者自身のレシピは、使ってから間がない。最初に基本的なものを作ったが、これは直ちにspam容量を少なくとも95%は減少した。後に、ブラックリストとホワイトリストを付け加えて、一定のアドレスからのメールを常に受信／拒絶した。ブラックリストは、spammer、特に大量の時間を浪費するゴミを送るもの、を撃退するのに有用である。ホワイトリストは、友人からのもので題名が如何に変でも（私には変な友人がいる）篩い分けしようとは思わないものである。

"mutt"を使う人のために、"/etc/Muttrc"に人名を付け加える方法を示す。次の行を加える。

macro index \ew '| formail -x From: | addysort >> ~/Mail/white.lst'
macro pager \ew '| formail -x From: | addysort >> ~/Mail/white.lst'
macro index \eb '| formail -x From: | addysort >> ~/Mail/black.lst'
macro pager \eb '| formail -x From: | addysort >> ~/Mail/black.lst'

そして筆者の "/usr/local/bin"に "addysort"と言うスクリプトを入れる。

#!/usr/bin/perl -wn
# Picks out the actual address from the "From:" line

unless (/\</) { print; } else { print /<([^>]+)/, "\n"; }

上記を与えられて、与えられたspammerに対してすることは'Esc-b' を叩くことだけで、以後会うことはなくなる。同じように、ホワイトリストに載せたいものには、'Esc-w' を叩くと永久に歓迎される。

筆者の"~/.procmailrc"を示すと、、

PATH=/usr/local/bin:/usr/bin:/bin
MAILDIR=/var/spool/mail
DEFAULT=/var/spool/mail/ben
LOGFILE=/var/log/procmail
SPAMFILE=/var/spool/mail/spam

# e-メール送り手がホワイトリストにあるか点検、そうならば直接

# $DEFAULTに送る。これがどのフィルタより前に来ることに注意

:0:
* ? formail -x"From" -x"From:" -x"Sender:" \
　　-x"Reply-To:" -x"Return-Path:" -x"To:" \
　　| egrep -is -f $MAILDIR/white.lst
$DEFAULT

#　e-メール送り手がブラックリストにあるか点検、そうならば

#"/dev/null"に送る
:0
* ? formail -x"From" -x"From:" -x"Sender:" \
　　-x"Reply-To:" -x"Return-Path:" -x"To:" \
　　| egrep -is -f $MAILDIR/black.lst
/dev/null

# Danの例より遙かに改善された実際の spam-killerを以下に示す：これらが

# 私のアドレスの一つに当てられていなければ−それら全部に−"fuzzybear"

# 又は "ulysses" が含まれている−それはspamである。整合方程式の頭に

# '!'があるのに注意。これは整合の意味を変える。それは「行がこれらの

# wordに合わな#ければ# $SPAMFILEに送る」である。 "^TO" は procmail変数で

# "To:", "Cc:","Bcc:"及びその他の "To:"-type headers に整合する

# （'man procmailrc'参照）

:0:
* !^TO .*(fuzzybear|ulysses).*
$SPAMFILE

# X-Advertisement header = spam!
:0:
* ^X-Advertisement:.*
$SPAMFILE

# 誰宛でもない!
:0:
* To:[ ]*$
$SPAMFILE

# 全く "To:" ヘッダーがない!
:0:
* !^To: .*
$SPAMFILE

多くの人にとって必要なのは、（最初の変数は勿論）上の最後の四節だけで、その最初の節で仕事の９５％をしてしまう。終わりの三つはDanから盗んだが、簡略に出来る場所は判っている。

とにかく、別の有用なことは、spammerを知らせるのに行ったメカニズムである。筆者の"/etc/Muttrc"に、私は、

send-hook (~s\ Spammer) 'set signature="~/.mutt/spammer"'と書いた行と

前略　貴兄から来たと思われるspammerからのメールを受け取りました。こんなことを始めた奴を攻撃して八つ裂きにして下さい。彼のガラクタはヘッダーと一緒に改変しました。早々　　Ben Okopnik
-=-=-=-=-=-

と書いた署名ファイル"~/.mutt/spammer"を持っている。

（笑い）私はspammersが嫌いだ。

だから、苦情を送るため、'h'キイを使って題名を見て、発信アドレスの 'whois' を走らせ、メールを送る 'm' を叩いて、プロンプトで下記をタイプする。

To:　　　　 abuse@<domain.com>
Subject:　　Spammer

ヘッダーの中のキイワードを与えられて、 "mutt" が私の"spammer" の署名ファイルを引き出しました。それをセーブし、 'A' キイを使って改変して送ります。約15秒のタイピングでいつでもspamをやっつけます。

（丁度この文書を送ろうとしたとき、別のspamをやっつけた。今度はUUnetからだ。（笑い）たたき直してやるぞ）

別の人のレシビに進むに当たり、LG自体がどちらかと言うとspamに関して弱い立場にある。 アドレスがNetに数千回（今は数百万回）も載っているので、いつでもspammerの餌食になる。つまり、今まで述べた「堅固な」フィルタは活用出来ない。spamに対する安全な「フィルタ」で我々の読者のメールの何割かを閉め出さないのは何か？を考えて見よう。人々は世界中から色々な方法で各種の顧客について（滅茶滅茶なヘッダーを作るものをも含めて）メールを送る。LGにとってのspam率は、Mike Orrによると月当たり28％である。良い"mirror"フィルタになり得る"優先:大量" メールの排除は良い選択肢ではない。多くの"News Bytes" エントリが（大量メール、ニュース発表であるため）この方法で送られるからである。HelpDex マンガシリーズの公刊に至る照会さえもこの方法で入る。

何をなすべきか？

返答は慎重であると思われる、殆どの人より頻繁に"spam"を篩い分け点検した上で「疑わしければ受信する」である。LGのスタッフにとって、仕事を進める上の余分な費用になる。彼らの「緩やかな」フィルタでさえもその負担を幾らか軽くするのが望ましい。

総括担当でシステム魔術師のDan Wilderは、その "~/.procmailrc"に以下の「スパムキラー」を持っていた。

:0:
* !^(To:|From:|Cc:|Resent-From:|Resent-To:).*(eskimo\.com\
|ssc\.com\
|linuxjournal\.com\
)
$SPAMFILE

その前は例外を許すルールである。メーリングリストについては、

:0:
* ^(From:|To:|Cc:) .*(-list\
|debian\
|networksolutions\
|ciac\

...

|bugs\
)
$DEFAULT

筆者のホワイトリストの同じことより多いが".procmailrc"自体にハードコードされている。そこに新人を加えるのは難しくないので、自動的でないのが多分詰まらないが、筆者のと同じくらい良い解決策と思われる。

LGの編集者Mike Orrは 、彼のレシピで（設計はDan Wilder)spam排除と同様に少々の分類を行っている。

LOG=$HOME/log
#LOGFILE=$LOG/procmail-log
VERBOSE=no
SPAMFILE=$LOG/spam
UMASK=077
LOGABSTRACT=on
COMSAT=no
DEFAULT=$HOME/Mail/Maildir/new

# 実際の働き者.
# 偽の受信者 .. To: or From: or Cc: ssc.com, でないので
# To: の中に "@" がある(壊れたMUAからのローカルメールにはない)

:0:
* !^(To:|From:|Cc:) .*(\
ssc\.com\
|linuxjournal\.com\
|linuxgazette\.com\
)
* ^To: .*@
$SPAMFILE

ふむ、ここでspammerをブラックリストに載せたようだ...

:0:
* From: .*john@songpeople.com
$SPAMFILE

# X-Advertisementヘッダーを持っていれば、spamだ!

:0:
* ^X-Advertisement:.*
$SPAMFILE

#誰宛でもない!

:0:
* To:[　　　　 ]*$
$SPAMFILE

# 全く To: がない!
:0:
* !^To: .*
$SPAMFILE

# でなければ、end に行き default。

随分詰め込んだようだが、実際は大したことでない。

１）受信メール全部を"procmail"にパイプする。

２）レシピを作る。

それだけだ。別のspam関連素材を行う沢山の破片を投げ込んだが、上の二つのステップが、spam撃退に必要なすべてだ。

もし、メールボックスがspamで一杯になっていて、上の二つのステップを行うなら、一発で全部の篩い分けがが出来る：

cat mbox | formail -s procmail

それで、メールボックスからspam撃退だ。Linuxと"procmail"の力のお陰で、洪水に悩んだのは昔の話になるだろう。　良いspam狩りを！

Copyright © 2001, Ben Okopnik.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 62 of Linux Gazette, February 2001

広域ネットワークのパケット捕捉と解析

By Jon Meek
American Home Products Corporation

緒言

システムとネットワークの管理者はtcpdump [McCa97] や ethereal [Ether00] のようなイーサネットパケット捕捉ツールを用いてネットワーク・アプリケーションのデバッグを行うことが多い。アプリケーションの作動が遅かったり回線利用率が高い原因を探るため回線上の通信量観察が必要になることがある。問題の回線がWAN （広域ネットワーク）二点間接続（T-1など）又はフレームリレーアクセスラインのときは、イーサネットセグメント上でパケット全部が観測できる地点はない。

本論文では、「生の」フレームリレーと二点間T-1パケットの記録・解析システムを述べる。データはルーターとCSU/DSUとの間のHDLC送受信線上で"eavesdropping''で捕捉する。データ解析により、回路とアプリケーションの利用情報が一秒以内で得られる。グローバルシステムとネットワークスタッフが容易にアクセス出来るようWebインターフェイスを通じて定期及び注文報告を結びつけることが出来る。パケットデータはまた在来のパケット捕捉システムと同じ方法でアプリケーションのデバッグに使用することが出来る。

このシステムが必要な理由

フレームリレー・ネットワークは、遠距離にわたるサイトを柔軟で経済的に相互接続する方法を持つ組織を与える。柔軟性のもとは、多くの回線を、T-1 (1.5 Mbps) 又は E-1 (2Mbps, 欧州で使用)のような、単一アクセスラインで接続する能力にある。PVC (Permanent Virtual Circuit)と呼ばれる各回路はCIR (Committed Information Rate)と呼ばれる保証帯域幅を有する。殆どのフレームリレー・キャリヤは、PVCをアクセスラインの全帯域幅に「CIR以上にバースト」することが出来る。PVCの瞬間的帯域幅は勿論アクセスラインの帯域幅を超えることは出来ない。これは面白い通信量管理問題を生じる。

複合フレームリレーネットワークは ``hub and spoke'' 配置で作られることが多い。多数のハブが傘下事務所図１のように接続する。次いでハブを、通常は高帯域幅相互接続でまとめる。

フレームリレー・ネットワーク問題を、帯域幅管理とアプリケーション問題についてデバッグする間、トップダンプを使用してイーサネットにおけるルーターのパケットを記録した。T-1/E-1アクセスラインに流れているデータを正確に知りたいと思った。多くのパケットがルーターを通るフレームリレー・ハブについては特にそうだったが、それらはネットワーク上の別のサイト宛なのでイーサネットに現れることはなかった。加えて、フレームがイーサネット・パケットに変換されると、有用なフレームリレー・ヘッダー情報は失われる。

図１は問題の図を示す。示した三つの型の通信について、ERP (Enterprise Resource Planning)通信だけが``UK Data Center''に入る。他の二つのアプリケーション、LANメール及びインターネットに関するパケットは、イーサネット部分には現れないのに、この「ハブサイト」で利用出来る帯域幅の膨大な部分を食ってしまう。

アプリケーション・デバッグと通信量解析を進めるにつれ、ルーター外の生のフレームを、通信ラインから直接記録するシステムの必要が明らかになった。そうすれば、任意のフレームリレー・ヘッダ情報とIPヘッダやペイロードなどもっと沢山のデータを検査することが出来る筈だ。を

市販システムには、生のフレームリレー・パケットを数分以上記録するものは見つからなかった。我が社は二つ以上の``WAN Probes''ブランドを使っていたが、これらはリアルタイム診断とRMON (Remote Network Monitoring Management Information Base)型履歴データに有用であった。ネットワーク・フライトレコーダ[Ranu97]の使用も検討したが、これはWAN通信ラインからはデータを記録しなかった。

殆どのルーターはヘッダのフレームリレー渋滞通知ビット(FECN と BECN, Forward and Backward Explicit Congestion Notification)を計数するが、廃棄適格（DE）ビットは計数しない。SNMP経由で記録したFECNs とBECNの５分間計数では、特定秒又は特定パケットの現象を指定する方法は何も得られなかった。生のパケットデータ無しでアプリケーション／ネットワーク相互作用問題をデバッグするのは極めて難しい。

この論文では、先ずハードウエア要件とパケット取得ソフトウエアを概観する。次いで、通信量解析ソフトウエア、続いて「渋滞と回線容量計画」、「生のパケットデータ使用」及び「アプリケーション素描」を論じる。T-1二点間回線のためのシステムの拡張及び、LAN上で問題パケットが得られるとき同様解析を行うためのtopdumpの使用を少し説明する。将来の応用に関する考えを締め括りとする。

ハードウエア

システムは RedHat Linux (version 5.2 or 6.x)で働く低価格デスクトップ・プラットホーム上に構築される。ハードウエアの心臓部は、カナダの sangoma.comの通信ボードである。傍受のため最初に使ったのはSangoma WANPIPE S508 ISA カード二枚だったが、今はWANPIPE S5142 PCI カード一枚を使っている。これで、通信ライン四本を4Mbps まで「聴取のみ」モードで取り扱うことが出来る。、

双方向データの取得には、Sangomaカード上に受信ライン二本とそれに結合したクロック信号が必要である。カードの送信ラインは接続しない。通信ラインに直接着けた短いケーブルを用いてうまくT-1/E-1ラインに接続出来たけれども、「マルチインターフェイスタップ」の使用をお薦めする。これらのタップは、信号ラインに対し高インピーダンスを示すので、タップとコンピュータの間に長いケーブルを使うことが出来る。単一T-1/E-1傍受のシステムに掛かる費用は、ＰＣ、通信ボード、及びWANタップを含めて、約2000米ドルである。800米ドルを追加すると、二番目の T-1/E-1が傍受出来る。

取得と解析

システム用の基本モデルは、パケットを双方向（発信と着信）で１５分間記録することである。各周期の終わりにパケットファイルを閉じて、新しい取得処理を開始する。次いで要約プログラムが前の周期からのデータを処理する。

このモデルは、リアルタイム・システムに比べ１５分遅れるだけで、大変簡単になる。また要約結果の便利なまとめと、詳しい解析が必要なとき生のパケットを見付け出すことが出来る。後処理用ハードウエアの要件は、パケット喪失なしに入力流を扱いながら１５分以内で要約処理を完了することである。

取得ソフトウエア

ソフトウエアは、Sangoma提供のドライバー、Sangomaのデータ捕捉用例示Ｃプログラムの修正版、及びデータの取得と解析を制御するPerlプログラムのセットである。

Sangomaのドライバー・ソフトはCHDLC (Cisco HDLC)用に設定した。パケット捕捉プログラム、frpcapは、tcpdump フォーマットに極めて近く真似たファイルを書く。重要な相違は、イーサネット・ヘッダの代わりにフレームリレー・ヘッダが書かれることだけである。生パケットの最初の15バイトは通常、アプリケーション解析中の文脈情報を作るため保存される。

パケット取得過程は、 frcap_run、15分毎に走るPerlスクリプトにより駆動される。 frcap_runは、現在の frpcap処理（各データ方向に一つ）を止めて直ちに別の対を開始する。次いで通信要約プログラム、fr_decodeが、二つのパケットファイル上で働く。要約に続いて生パケットが圧縮され、ディスク容量維持のため所定期間より古いファイルが削除される。T-1アクセスライン上で程々に繁忙なフレームリレーのセットでは、八日分の生パケットファイルが3-6GBのディスク容量を消費する。

解析ソフトウエア

15分生パケットファイルは、出力をXMLフォーマットで日毎の要約ファイルに変えるPerl プログラムを用いて要約する。XMLファイルは、表示と解析のため別のプログラムが読む。XMLデータをフォーマットするWebアプリケーションにより表示された15分要約出力を図２に示す。図２のサイズを小さくするため、カテゴリ毎に、細かいPVCは省いて最初の5数字だけを示す。

フレームリレー通信要約（フィラデルフィア）

フィラデルフィア発信

捕捉時刻：2月10日木 11:00:00 2000 - 2月10日木 11:15:01 2000 GMT

PVC 要約 (フィラデルフィア発信)


 DLCI   Packets       Bytes    %    FECNs       BECNs       DEs DE  No DE


  460   79,648   12,422,725  30.2 %   0  0.0 %    0  0.0 %   0   0    328  London


  490  119,404   28,677,448  69.8 %   0  0.0 %    0  0.0 %   0   0  1,321  Paris


  All  199,052   41,100,173





プロトコル計数 (フィラデルフィア発信)


DLCI   Protocol           Packets        Bytes  % of PVC     TCP ReTransmits


460 London


       0800 06 IP TCP      40,291    9,068,685  ( 73.0%)       328 (  0.8%)


       8137    IPX         34,675    2,805,741  ( 22.6%)


       0800 11 IP UDP       1,671      316,118  (  2.5%)


       0800 01 IP ICMP      2,593      197,600  (  1.6%)


       809b    ATALK          203       15,000  (  0.1%)


       0800 58 IP IGRP        200       14,616  (  0.1%)


490 Paris


       0800 06 IP TCP      70,203   21,871,361  ( 76.3%)      1321 (  1.9%)


       8137    IPX         46,048    6,228,881  ( 21.7%)


       0800 11 IP UDP       2,051      498,644  (  1.7%)


       0800 01 IP ICMP        882       58,936  (  0.2%)


       0800 58 IP IGRP        205       14,886  (  0.1%)

アクセスライン最繁忙秒 (フィラデルフィア発信)


      Time          Bytes        kbps


    11:08:11      125,513      1,004.1


    11:08:09      118,855        950.8


    11:08:13      116,336        930.7


    11:02:53      108,926        871.4


    11:08:14      104,754        838.0





PVC 最繁忙秒(フィラデルフィア発信)


460 London


    11:02:53       77,873        623.0


    11:02:52       76,221        609.8


    11:02:54       47,667        381.3


    11:02:56       46,748        374.0


    11:00:07       44,487        355.9


490 Paris


    11:08:11      112,854        902.8


    11:08:13      105,761        846.1


    11:08:09       95,425        763.4


    11:08:14       92,765        742.1


    11:08:10       85,951        687.6


アクセスライン閑散秒 (フィラデルフィア発信)


    11:12:53       11,366         90.9


    11:12:52       14,118        112.9


    11:12:54       15,371        123.0


    11:12:55       22,993        183.9


    11:11:48       23,544        188.4





PVC閑散時 (フィラデルフィア発信)


460 London


    11:05:14        3,640         29.1


    11:04:55        3,859         30.9


    11:05:33        4,068         32.5


    11:07:48        4,118         32.9


    11:06:20        4,170         33.4





490 Paris


    11:12:53        3,460         27.7


    11:12:54        6,613         52.9


    11:12:52        8,187         65.5


    11:13:18       14,021        112.2


    11:12:55       14,065        112.5





最多発信元(フィラデルフィア発信)


                                    Bytes  % of Total


   1 TCP 155.94.114.164  1867    4,673,580  11.0   Philadelphia GroupWise


   2 TCP 10.2.71.201     1494    2,644,817   6.2


   3 TCP 155.94.155.23   1521    1,671,696   3.9   ra01u04 - Philadelphia DCG


   4 TCP 192.233.80.5    80      1,272,224   3.0


   5 TCP 209.58.93.100   1494      931,341   2.2   MARTE WinFrame 1





最多宛先 (フィラデルフィア発信)


                                    Bytes  % of Total


   1 TCP 10.248.107.217  7100    4,742,966  11.2


   2 TCP 10.247.113.201  4498    1,272,224   3.0


   3 IPX 0451 01000105 1         1,138,074   2.7   NCP


   4 TCP 10.248.89.1     7100      952,921   2.2


   5 TCP 10.247.66.76    1073      931,341   2.2





アプリケーション要約 (全 PVC、フィラデルフィア発信)


                            　新 TCP   　 全 TCP


 アプリケーション           　セッション  セッション  パケット    バイト


 インターネットTCP           4,684        4,817       41,455    13,128,752


 IPX                                                 90,631     9,785,697


 未知 TCP　                  1,016        1,167       41,305     7,141,942


 グループ化TCP                 98          138       12,106     6,722,084


 DCG TCP                          138          150        7,370     1,824,223


 MARTE WinFrame TCP                 2            5        4,428     1,041,713


 IP Protocol  0b NVP-II                                   3,894       839,902


 EDMS TCP                          13           20        3,075       775,923


 MARTE Oracle TCP                   1            3        1,882       472,541


 MLIMS TCP                         38           22          850       255,473


 Internet ICMP                                            3,255       214,690


 Unknown ICMP                                               780        78,666


 ProbMan TCP                        0            4          181        48,826


 IP Protocol 3a IPv6-ICMP                                   598        43,012


 未知ATALK　                                              203        15,000


 ASTROS TCP                         2            6           62         9,963





TCP SYNs (接続要求): 5996         全 TCP 再送信: 1662

レポートは五つの主要部分から構成される。第一部分は、DLCI（回線数）、パケット数とバイト数、アクセスライン上全回路に対する回路当たりバイトの百分比、渋滞通知計数、DE（廃棄適格）計数及びTCP再送信計数を示すPVC要約である。このルートは渋滞通告とDEビットを設定しないので（もっと下流のフレームリレー交換がそこで設定）、発信方向については０となる。いくつかルーターは、インターネット通信について優先度を低くするためDEを設定する（DE設定は、キャリヤにネットワークが渋滞していれば通信を無視して良いと告げ、交換に当たりキャリヤは、一定量まで計数しない）。TCP再送信計数は、DEが設定されたときのフレームリレー・ネットワーク内のパケット喪失への影響を判定するため、DE付きと無しのパケットについて別に行う。

レイヤー2と3のプロトコル計数は第二部分に要約する。イーサネット/802.2型フィールドにおいて観測された各プロトコルについて、数字によるIP型（IPプロトコルのとき）、プロトコル名、パケットとバイトの数、及びPVCに付いての利用率をバイトで、示す。 TCP/IP については、パケット再送信計数を表示する。

第三部分では、アクセスライン及び各PVCについて繁忙時と閑散時を表示する。これらデータの作成と利用は、後に「渋滞と回線容量計画」の項で説明する。

データの最多発信元と最多宛先を第四部分に示す。プロトコル、IP宛先、ポート番号、バイト数、及びアクセスライン上全通信量に関する総計の百分比が含まれる。サーバー名が判っているときはこれも、アプリケーションと簡単な説明と共に、表示する。

レポートの第五部分では、アプリケーション毎のアクセスライン利用を一覧表にする。可能な場合は、サーバーのIPアドレスを用いてアプリケーションを同定する。ポート番号でアプリケーションを決めるのは分かり安いが、我が社のサーバーの多くは単一アプリケーションを働かせている。事実、二つのサーバーが同一アプリケーションを働かせていることが多いので、この場合はいずれのIPアドレスもそのアプリケーションに計数する。データベースサーバーは、すべてが同一IPアドレス／ポート番号の対を用いる多数のアプリケーションを走らせることが多いので、ポート番号を加えてもアプリケーションは一義的に同定されない。将来は、アプリケーション毎に割り当てた仮想IPアドレスを用いて簡単な計数方法を備えることを奨励した。「新TCPセッション」欄は、15分間に示されたセッション数を示し「全TCPセッション」欄は新規及び進行中両方ののセッション数を示す。Webベース・アプリケーションについては、ヒット・カウンタの型として以外はあまり役立たないが、繰り返し接続のあるアプリケーションについては、期間中に接続したユーザー数の目安となる。

レポートの最後の二項目は、初期TCP SYNの計数で、不法進入検出用と、すべてのPVCに関するTCP再送信計数に使用される。

図３は、着信方向のレポートの始まりを示す。この方向に流れるパケットに関する沢山のFECN、BECN、及びDE情報があることに注意されたい。FECNとBECNは、キャリヤのフレームリレー・ネットワーク[Blac95]における渋滞度に関する情報を与える。レポートの残りの部分には、図２に示したような情報が含まれる。

フィラデルフィア着信データ

捕捉時刻: 2月10日、木 11:00:00 2000 - 2月10日、木  11:15:01 2000 GMT


PVC 要約 (フィラデルフィア着信)





DLCI  Packets      Bytes    %    FECNs         BECNs          DEs DE No DE


 460  62,915   6,453,502  36.9 %  515  0.8 %     31  0.0 % 2,211   6  111 London


 490 109,900  11,024,584  63.1 %   39  0.0 % 11,800 10.7 %     0   0  656 Paris


 All 172,815  17,478,086

１５分要約データを利用した特注レポートが入手出来る。Webフォームを利用して、単一アプリケーションを選び、次いでそのアプリケーションだけの「アプリケーション要約」参加のリストを作ることが出来る。このアプリケーション利用状況リストは、一つのアプリケーションの帯域幅インパクトと利用者数の判定に有用である。「フィラデルフィア・ベースのアプリケーションにヨーロッパからアクセスするユーザーが400名いる」と言われることが多いので、このツールを同時ログインユーザー数判定と、利用率成長の観測に用いることが出来る。別のプログラムは、アプリケーション毎に利用を集計して、毎日又は毎月「アプリケーション要約」を発行する。

上記例示データは、繁忙アクセスラインの一つに関するものであるが、殆どの集合体から離れている。我が社の欧州フレームリレー・ハブサイトは単一アクセスライン上に13個のPVCを有している。通信の一部は、子サイトとハブサイトのAS/400との間の事務用重要テレネット通信である。しかし、通信の多くは、一つのPVCに入るイントラネット・メール又はインターネット・データで、そこから別のPVC上で米国に向かう。フレームリレー・モニターがないと、どのアプリケーションとプロトコルがPVCとアクセスライン帯域幅を消費するかを判定するのは困難であろう。ある場合には、単一PVCに関するアプリケーション要約を入手して特定回線で何が起こっているかを判定する必要がある。レポートのサイズを複雑さを程々に保つため、PVC当たりのアプリケーション及びプロトコルの利用率は定期的には報告しない。

渋滞と回線容量計画

多くの組織と同様に、我が社はルーター統計をSNMP経由で5分毎に集める。5分平均は、帯域幅との関連で行う回線行動の目安ではあるが、相互作用特性を支配する回線の瞬間的（一秒以下の時間尺度の）状態は告げない。回線が5分の間に数十秒だけバーストで飽和したとき、平均利用率は程々と思われる。しかし、相互作用ユーザーは、私のパケットがルーターバッファで待っている間ネットワークは遅かったと言うであろう。

我が社のモニターは、1秒毎の間隔で送受信バイト数を加算して、15分間内の最大ピークを測定する。加算プログラムは、アクセスラインと回線毎に最繁忙秒十傑を報告する。一日の繁忙秒のサンプル描画を図４に示す。時間帯は広い方が良い。15分間に最繁忙秒十傑に大きい変動があり、最繁忙秒より少ないものがあることを示す。T-1 (1536 kbps)の全速以下の繁忙秒が12:45 GMT から欠けていることは、重要な渋滞の進行を示す。1536 kbpsライン以上の繁忙秒が幾つかある。これらは多分パケットがバッファに保留されたことによる。中断を保守するに当たり、データ取得過程に優先度を付けて遅延を減少したいと願う。同様の方法で閑散秒を測定した。通常繁忙の回線にゼロ又はバイト数の少ない秒があるなら、回線又は経路決定に問題があることを示す。

一日の繁忙時に低い利用率を示す多数の閑散秒があるとの問題がある。ユーザーの苦情もあるので、パケットデータの詳細解析を行った。IPXが正常に流れているのに、IP通信全部が周期的に約8秒間止まることを示した。IP経路決定問題の原因を追及した。IPX通信が無ければ、忙しい筈の回線に8秒間だけ通信量ゼロの時間があるので問題を絞るのは易しい。

未だ正式ルールは開発していないけれども、繁忙秒データを用いて実際の通信量に関しPVCとアクセスラインのサイズを決める方法を決めるのは可能な筈だ。明らかに、重要使命相互作用アプリケーションが最重要通信であるとき、回線上の繁忙秒を観察することは、5分平均データより重要である。

生パケットデータの利用

生パケットデータは、着信と発信の方向について別のファイルに記憶されているので、在来パケット追跡解析のためには、二つのファイルを結合しなければならない。ユティリティ・プログラムが一対のファイルからこのパケットを時間順に置きtcpdumpフォーマットを書いてここ課題を実行する。フレームリレー・ヘッダ情報を含むー「フレームリレー情報」ファイルもまた書かれる。

我が社は、元々 tcpdumpファイル用に書かれ、任意選択で「フレームリレー情報」読み込み、各パケット用 DLCI (回線ID)、 FECN、 BECN、及び DE を表にすることの出来る、パケット追跡解析プログラムを持っている。これを使って、幾つかのアプリケーションが非対称ルートを通じて作動していることを発見した。我が社自身の解析プログラムに加え、tcpdumpフォーマットファイルはtcpdump自体又はethereal [Ether00]のようなプログラムを用いて検査することが出来る。etherealとその同伴プログラムeditcapは、パックしたデータを他のフォーマットに移出できるので、普及版の市販製品を用いて解析することが出来る。セッションに多数の15分間続く必要があるときは、多数のtcpdumpファイルを繋ぐ簡単なプログラムを用いる。

以前の論文[Meek98] で、我が社の通信ベンダーと行った興味深い問題を論じた。遅い回線についての我が社の苦情に対し、ベンダーの返答は「顧客は、回路の過剰使用が過剰期間続くことを意味する160%もCIRを超えている」と言うようなものであった。生パケット情報を用いて秒当たりベースで帯域幅利用を計算し、同じアルゴリズムを通信装置として、何時、どれだけCIRを超えたかを検証することが可能な筈である。図６は、30分周期について回線の秒当たり帯域幅利用及びBECNビット設定を持つ着信パケットの百分比をを示して、発信回線の渋滞をあらわす。BECNはキャリヤの交換機から送られて、発信方向に渋滞があるので、CIRを超えクレジット外になったら帯域幅利用を絞ることを通知する。将来は、契約帯域幅を超えた時期及びサービス品質実現の方法を正確に判定して、通信を優先扱いし帯域幅破裂を管理するためこのデータを利用することを望む。

パケット喪失は何れのデータネットワークにおいても重要なパラメータである。パケット喪失の一つの目安は、送信すべきTCPパケット数である。図７は、我が社繁忙回線上の数ヶ月にわたるTCP再送信率を示す。TCPパケット10,000以下の時間は示していない。この回線は、多数の下流フレームリレー回線と多くのLANセグメントに送るので、パケット喪失は幾つかの場所で起こる。６月下旬の間、T-1インターフェイスに大部分の再送信が起こる問題を抱えた。新パケットデータの追加利用により、再送信に責任のあるIPアドレスを判定することが出来た。標準レポート（図２）に、再送信十傑を一覧する新しい部分を加え、問題のあるホスト又はサブネットを同定する助けとした。再送信パケットは、ペイロードを持つパケット（受領通知のみのパケットでなく）についてセッション毎にTCPシーケンス数を追跡して計数した。

アプリケーション素描

アプリケーションの帯域幅要求の素描は、ソフトウエア製品の開発又は評価中に実行するのに有用な試験である。元々LAN上で使用するため開発されたアプリケーションがWAN又はインターネットに動かされたとき難しい問題を持つのを何度も見出した。問題は大量に送られるデータ、過剰な往復待ち時間を生じるアプリケーションレベル整合、又はプログラムエラーで同一データが何度も要求され（引き渡される）ことからさえも生じる。これらの問題は自社開発にも購入ソフトウエアにも起こった。

アプリケーション素描のためWANパケット捕捉システムを利用する一つの利点は、同時に回線中を流れるその他のデータ全部に沿って試験中のアプリケーションを観測出来ることである。我が社は監視回線上の全部の通信を定期的に捕捉するので、殆どのアプリケーション素描試験に予め準備を必要としない。しかし、会話的アプリケーションを試験するとき、ユーザーがハードウエアに全く触らない休止時間が15秒から30秒あると非常に助かることを見出した。休止はパケット追跡中でアプリケーションのフェーズを分離して、アイドルのときクライアントとサーバーが「チャット」するか否かを判定するのに用いる。

アプリケーション素描のためWANパケット捕捉システムを利用する欠点は、我が社が一般的にヘッダーとペイロードが複合したの150バイトしか捕捉しないことである。この少数のペイロードバイトがアプリケーションの文脈決定に十分ではあるけれども（特にASCII又はEBCDICデータが含まれるとき）、同じペイロードを持つ多数のパケットがセッション内で送信されていることを確信を持って判定するには不十分である（ペイロード内容[Meek98]上のMD5チェックサムを計数して決定）。

アプリケーション素描の例を図示的に図8と9に示す。図8のアプリケーション素描は、ユーサーインターフェイスとしてペイジバースのターミナルを用いるERP (Enterprise Resource Management)システムである。ユーザーは、文書フォームに書き込み、画面ペイジをサーバーに送ってシステムと会話する。この方法は、最新Webアプリケーションと同様に、適正規模の一連データが一度に送られるので、WAN上で会話的アプリケーションを実行するのに効率の良い方法である。

単一ユーサーが消費する帯域幅の量を判定するため、個々のセッションを時間の関数として眺めた。上の描画は各方向についてのパケットサイズ分布を示し、下の描画は秒当たりに使用された帯域幅を示す。数字を詳しく見ると、400パケット中で143,473バイトがクライアントからサーバーに送られ、348パケット中で112,560バイトがサーバーからクライアントに送られている。会話的データ解析ツール [Grace00]を用いて細かく検査して、典型的処理が１､2秒で終わることを見出した。最大使用帯域幅はクライアントからサーバーで43kbps 、逆方向で22kbps であった。

この解析のパケット・データは、PVC13個を有するフレームリレー・アクセス回線からの30分生パケット捕捉データから抽出した。第一ステップは着信と発信のパケット流を単一tcpdump フォーマットファイルに結合することであった。セッションを覆うに必要な15分周期二回のこのtcpdump ファイルを次いで連結した。最後に、結合ファイルを前フィルタとして働くtcpdump で処理し、対象セッションを選んで、セッションを要約する我が社自身のソフトウエアにそれを送り、パケットと帯域幅データを描画用に作成した。

図9の描画は「まばらなクライアント」からのものである。実際のアプリケーションはサーバー上で働き、Xウインドウズのように、クライアント上で表示されるが、もっと効率の良いプロトコルを用いる。クライアントとサーバーの間の通信は、キイボードとマウスのデータ、画面リフレッシュ、及び場合により、ファイル転送から構成される。この例では、ファイル転送はセッションに入って2100秒で始まっている。

ここに示したツールは、1秒間にアプリケーションが使用する実際の帯域幅を定量し、各種アプリケーションの帯域幅要求の基本的相違を示す完全な仕事を行う（「爆発的」帯域幅使用は臨時に二つの方向に分けたり分けなかったりする）。このツールはしかし、アドレス模擬のアプリケーション測定は行わない。多分、我が社のデータは、ネットワーク・シミュレーション・ツールに入力して多数ユーザーへのスケーリング・シミュレーションを行うのに用いられると思われる。我が社のツールは、しかし、発信元、宛先、ポート番号などに基づいて、記録された実際のネットワーク通信量を選ぶことが出来る。加えて、アプリケーションへのネットワーク待ち時間の影響を考慮する [Meek98]のは重要である。

アプリケーション利用の時間変化判定のため、利用度を示すパラメータに注目することが出来る。図10に、一つのアプリケーションについて週毎のセッション数を示す。このアプリケーションの利用はビジネスサイクルと休日日程により変化する。アプリケーション利用の目安として有用なその他のパラメータは転送バイト又はパケット数である。バイト又はパケットは、Web又はセッション起源でないアプリケーションに特に有用である。

T-1 二点間回線への拡張

ハードウエアとソフトウエアが修正なしでT-1二点間回線に利用出来ることを見出して喜んだ。二点間回線上のパケットはフレームリレー・ヘッダと酷似したヘッダを有する。フレームリレー・ヘッダの最初の２バイトはDLCI番号とFECN, BECN, 及びDEビットをあらわすデータを含む[Blac95]。二点間シリアル回線の最初のバイトは、ユニキャスト・パケットについては 0x0F「ブロードキャスト」パケットについては 0x8Fで、第二バイトは常にゼロである [Cisc00]。フレームリレーと二点間の双方で第三ビットはイーサネット・プロトコル・コードを含む。これらの約束は一定の型の装置に特有であることを注意する。

関連技術

対象交信全部にLANからアクセス出来るとき、交信記録には簡単なツールと技術を使うべきである。tcpdumpの開始には簡単なスクリプトを用いパケット捕捉ファイルをcron (ユーザサーモード・コマンドのスケジューラ)により時間割通り回転する。取得データはここにWANについて述べた方法で解析することが出来る。

将来の作業

T-1/E-1 とフレームリレー帯域幅限界を克服するため主要回線をATMに移動中なので、ここで述べた技術をATMに拡張したいと考える。これはATMインターフェイスカードがATMセルを完全IPパケットに再組立するなら直截な筈である。ATMモニタの設計と実現は[Api96]で述べる。

このシステムで測定したパラメータの幾つかは、多分しきい値を超えたときのアラームとして使用される。TCP再送信率と閑散／繁忙秒はアラームの候補になるであろう。フレームリレーはLMI(Local Management Interface)を使用するパケットについての情報を提供する。今のところこれを解読していないが、将来の能力に加える計画である。

パケットにのルーターを通じる遅延を異なるサービスクラスで測定することによりQoS (サービス品質)の効率を測定したいと考える。これはルーターのイーサネット側でtcpdump を、シリアル回線側でWAN捕捉を測定すれば良いらしい。繁忙期間のパケット遅延ヒストグラムが、高優先度通信は低優先度通信より早くルーターを通過することを示す筈である。この結果をQoSパラメータとして使える筈である。

結語

メモリの大きい低価格フレームリレー及びT-1パケット捕捉システムを組み立てて実際の問題に応用した。このモニターの使用は、WANのアプリケーション・レベルでの使用状態を管理者に知らせる助けになった。また繁忙秒と閑散秒の解析を通じて最悪の場合の交信の情報を与える。ピーク利用状況データの解析にしたがって回線の帯域幅を変え、経路決定異常問題を見出し、アプリケーションのネットワークへのインパクトを描写した。大容量メモリと生パケットデータの長時間保持により、発生の数日後に故障処理が出来た。大規模世界的組織には重要なことである。本論文で述べたデータ解析は、WAN回線からの生パケットデータの可能な使い方の一つに触れたに過ぎない。将来は新しい方法で情報を掘り出すことを期待している。

利用法

補足情報と、ここで用いたソフトウエアの幾つかは at http://wanpcap.sourceforge.net/.で得られる。

謝辞

ツール開発中のご協力に対しJim Trocki、 Kevin Carroll、 Kim Takayama、 Jim French、及び Sangoma Technologies Inc. の技術スタッフに感謝する。本論文の草稿はBill Brooks、Kevin Carroll、Edwin Eichert及び William LeFebvreが校閲した。.

参考文献

[Blac95] Uyless Black, Frame Relay Networks: Specifications and Implementations, McGraw-Hill 1995.

[Cisc00] Cisco Systems, WAN Group, private communication.

[Ether00] Ethereal, A network protocol analyzer, http://ethereal.zing.org/, 2000.

[Grace00] ``Grace, a WYSIWYG 2D plotting tool for the X Window System and M*tif'', http://plasma-gate.weizmann.ac.il/Grace/, 2000.

[McCa97] Steve McCanne, Craig Leres, Van Jacobson, ``TCPDUMP 3.4'', Lawrence Berkeley National Laboratory Network Research Group, 1997.

[Meek98] Jon T. Meek, Edwin S. Eichert, Kim Takayama, ``Wide Area Network Ecology,'' Proceedings of the Twelfth Systems Administration Conference (LISA '98), USENIX, Boston, 1998.

[Ranu97] Marcus J. Ranum, Kent Landfield, Mike Stolarchuk, Mark Sienkiewicz, Andrew Lambeth, and Eric Wall. ``Implementing a Generalized Tool for Network Monitoring,'' 11th Systems Administration Conference (LISA), 1997.

``当初 USENIX Association が 2000年12月3-8日の Proceedings of the 14th Systems Administration Conference (LISA 2000)''で発表。 (www.usenix.org/events/) s 本論文は原文を改訂。

Copyright © 2001, Jon Meek.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 62 of Linux Gazette, February 2001

Linux Managment は偉大な時を迎える:

Craig Burtonとのインタビュー

By Doc Searls

Calderaの新Volution 製品について初めて聞いたの−beta に入ろうとした−昨年秋で、登録しなかったことを謝らなければならない。色々誤解していた。

"Linux Management"とは二律背反だと思った。ネットワークの企業モデルは、各種サービスの集まりだ。多くの企業がLinuxインフラストラクチャを整えるにつれ、management呼ばれるサービスが必要になる。

ここで言うmanagement は管理だけではない。多くのシステムが直ちに備えるべき効率とノウハウを持ち込むことだ。

このマーケットの顧客は、規模が大きくなるにつれ価値の上がるネットワークサービスを望む。Volution のようなマネージメントシステムだけが、ネットワークにコンピュータなどが付け加えられるにつれ価値を上げる。

ネットワーク・マネージメントは、既にネットワーク・マネージメントの提案を持っているIBM、HP、Computer Associates 及びIntelに取っては着古しだが、Linux に取っては新しく−有名企業環境内ののLinuxに取って新しい。

Volutionに注目し始めたとき、Linuxを売れる企業インフラストラクチャに引き上げるかどうか疑った。Volutionは有名ベンダーの提案と直接競合する。少なくとも他のLinux分布に関する限り、独占性もない。どれとでも働く。Caldera はまた去年購入したSCOの UnixWare (元の AT&T UNIXから下降）を用いて働くようにする計画がある。

この見通しの一部は、Volutionが標準インターネットプロトコルSLP (Service Location Protocol )を使用したことによる。CalderaはOpenSLP と呼ばれる OpenSLPのバージョンを開発して、オープンソース・コミュニティ(www.openslp.org)に貢献した。OpenSLPにより、サービスが自然にVolutionを有名にした。

マネージメント・コンソールは普通のブラウザである。システムはLDAP (Lightweight Directory Access Protocol)ディレクトリを用いて起動する。LDAP V3 ディレクトリを用いて単一クライアントが任意の数のサービスを管理することが出来る。

主要Linuxベンダー（例えばRed Hat Network Services, SuSEの Email Server II）と同じく、製品戦略は発信元に近づくことだ。

Caldera がVolutionを用いて行っていることを理解するため、ネットワークサービスの権威者Craig Burton に会った。１月末に訪ねた。

シール: Volutionの新しいところは?

バートン: 二つあります。アーキテクチャとストラテジーです。

シール: では、アーキテクチャから始めましょう。

マネージメント・システムを進めるとき、Volutionアーキテクチャは優雅で、良く考えてあり、有用です。

第一に、ディレクトリ起動です。Volutionは、システム設計に汎用ディレクトリ・サービスを使うコンセプトに基づくと以下に強力で優雅なインフラストラクチャが得られるかの偉大な事例です。Volutionは、ネットワーク・インフラストラクチャを−汎用ディレクトリとセキュリティの構造を用いて構築し時間と空間を超えてネットワーク対象の位置、アイデンティティ、状態を管理する方法の例です。

第二に、標準に基づくインフラストラクチャを使って、本当に難しいこと行うことが出来、それを非会話的方法で行います。例えば、沢山の行政的作業と管理しようとするシステム構成の変更がなしで、管理に適したネットワークを作るのは難しいし殆どありません。VolutionはOpenSLPにより、サービスを見出して接続します。このプロトコルは、問題を生じる可能性を最小にして管理に適した環境をさわやかに作ります。

シール:例えば?

バートン: 管理適性にするためLinux OSのクライアントにVolution を搭載しなければなりませんが、OpenSLPを使って、目標Linux OSのコンフィギュレーションを何も変えないで済みます。これはOpenSLPを用いると、サービス−マネージメントサーバー−とクライアント−マネージメント・ワークステーション−がネットワーク上で互いに相手を見付け出してお互いの情報を交換するからです。双方の側のLinux OSコンフィギュレーションに関わりなく行います。これには三つの魔法があります。第一は、Linuxに生まれつきのロケーション・プロトコルがないこと、第二に、Linuxであろうがなかろうが、他の誰かが使うプロトコルは、遙かに指令的で複雑なこと、最後に、OpenSLPは手の伸びたRFC状態を持つ唯一のサービス・ロケーション・プロトコルであることです。誰もそうしなかたし、そんなアーキテクチャを持っていません。NovellだけがOpenSLPをマネージメント製品とともに使ったベンダーです。これが、Novellのサービス・ロケーション・プロトコル(Service Advertising Protocol [SAP])をTCP/IPベース好適にはRFCである何かに変える方法を持たなければならなかった理由です。Sunはしなければならないが未だ進んでいないと言っています。これは双方向ではなく、仕事をするRFC状態をもった簡単な機能的プロトコルです。

シール: Red Hatはどうでしょう? ここで何かしていますか?

バートン: Red Hatのマネージメント・システムは横領システムの良い例です。Red Hat システムはNovellのNDS−これは Linuxと一緒に使うとき eDirectory と呼ばれます−を使っています。ディレクトリ起動だからです。ディレクトリを走らせて−カスタマには実際に選択をさせず−彼らのエージェントを埋め込むんでシステム変更をします。Red Hat 7 だけになります。マネージメントへの遙かに良い方法は、スタッフを管理すのとは別に、スタッフに管理をさせることです。彼らはここでサービス事業も運営しています。ディスクリートなネットワークサービスとしてマネージメント又はディレクトリを行っている訳ではありません。

シール: アーキテクチャについて何か他には?

バートン: オブジェクト指向の設計です。オブジェクト指向設計の利点のすべては、再使用性、継承性、単純性、及び普遍性のような結果として働くことです。基本的にVolutionは、ネットワークがどう見えるかをあらわすオブジェクトを作り、それをディレクトリに入れます。例えば、何か不具合−マシンが作動を止めた−があると、マネージメント・システムはシステムのオブジェクト表現を（ディレクトリ内で）観察することが出来、それと実際のシステムとの間の相違を点検して、何が壊れたかを確定します。少なくともそれらを一致させて、システムがうまく働いていたときの状態に戻す試みをします。オブジェクト指向戦略の唯一の欠点は、自分自身のオブジェクトモデルを作ることです。幸いに、ディレクトリ起動の方法で行ったので、後でもっと長期的な解決策に移行るることが出来ます。

もう一つは、XMLベースのエンコードです。Volutionはクライアントとサーバーの間の連絡にXMLを使います。これはXMLを使うJabberなどと同じ理由で良いことです。

シール: ブラウザ・インターフェイスがありますね。.

バートン: サービスへのインターフェイスはWebサーバーを通じます。Apacheに似ています。これはマネージメントサーバーが任意のwebベースのクライアントと通話することを意味し、ブラウザを働かせることの出来る何からでも管理が出来ることを意味します。インフラストラクチャの巧い利用で、物事が働く方法です。

シール: 最初の作品として満足ですか、何か見掛けを損なうところがありますか?

バートン: Volutionが完成マネージメントシステムになるには時間が掛かるけれども−実際にサービス利用のプリけーションとして満開ではありません−Linux 社会を大きく飛躍させ、私が基礎構築的マネージメントアーキテクチャ考えるもの、私が推奨して設計する一種のインフラストラクチャ用いてそれを行います。多くの方に役立つと思います。

シール: それはまた大きい保証ですね。

バートン: 色々考えましたが、悲観的になる要素はありませんでした。Volution は良く考えてあります。ベテランのチームがいます。Novellでこの仕事をしていた時語りましたが、ZEN Workより遙かに少ない時間で作り上げる自信を持っていました。アーキテクチャを見直す時期が来たのと、汎用OSとツールに基づくのが理由でしょう。

シール: 戦略については?

バートン: Linuxは役立つものです。重要なインフラストラクチャにもなりつつあります。

Linux地域ベンダーがどのように価値を持ち込むか？地域ベンダーが顧客ニーズをサービス水準内に持ち込むのに十分な規模を計る方法はありません。するべきことは、Linux 上で走るインターネットサービスの次世代を受け止めることです。Calderaは、マネージメントを用いてそれを行っており、断定的に行っています。

シール: つまり、サービス事業をしようと試みるより、インターネットサービスを提供する製品で道を切り開くことですね。

バートン: その通りです。他の誰より遙かに進歩的でアーキテクチャ的に健全な方法でLinuxを使うインフラストラクチャを構築する製品を持って、やって来ました。地域ベンダーする必要のある賭金を上げているところです。

シール: open sourceではありませんね、その戦略については?

バートン: 本当のところVolution 全部が open sourceではなくopen-sourceベースです。それが実際の戦略です。Red Hatのサービス戦略はopen-sourceではなく、NovellのeDirectoryに基づいています。Netware以外のプラットホームで働くNDSです。月額を払うとRed Hat がディレクトリを管理してくれます。eDirectoryはopen-source製品ではありません。Red Hatがそれを一つにする方法は分かりません。ただ、自分たちの最新版を使う会社にだけサービスを提供しています。他のLinuxベンダーが使えない品に意味はありません。open-sourceでないのと同じです。.

シール: だが、何かを提供する点では戦略的です。

バートン: 彼らの目標はLinuxそのものになることです。今の大きいシェアを維持しようとすると、差別化しなければならなりません。これも一つの道です。それもまた封じ込め戦略であると気付こうが気付くまいが。

シール: そこで、Calderaは違うネットワークサービスを提供しておりっそれを製品の形−切り開く戦略−で行っているから、より戦略的だと仰るわけですね.

バートン: そうです。万歳です。Linux地域ベンダーは産業にネットワークマネージメントでインパクトを与えられますが、それがCalderaのすることです。このアーキテクチャは十分に強力で、考え抜かれており、産業主導の動きです。それがLinuxでもCalderaでもなければ、もっと多くの人が元気者と呼ばれていたでしょう。マネージメントの問題を解く人は誰でもこの道を進んだ筈です。

シール: セキュリティについては?

バートン:セキュリティはこれに本質的です。セキュリティとディレクトリは関連サービスです。セキュリティとディレクトリはすべてのサービスの基礎になるサービスです。Calderaはディレクトリ・ベースの確実なマネージメント・インフラストラクチャを持っています。強力です。

シール: その点では他の Linux システムに無関係ですね。

バートン: そうです。だがLinuxだけです。Linux上でだけ走り、Linuxシステムだけを管理します。だが、Linux網全体を包含し、これが重要なのです。

シール: IBMについては、Linuxを沢山売っており自分をLinux 会社だと言っていますが?

バートン: 彼らの解答はTivoliです。これ程クリーンではありません。IBMは間もなくTivoliを引っ込めるでしょう。Calderaより多くのスタッフを抱えていますが、Calderaはインフラストラクチャを育てるのでもっと優雅です。

シール: Egenera のような会社はどうでしょう、Linuxを囲むデータセンターを作っていいますが？このセンターはLinuxと他のプラットホームを取り込むでしょう。こんなこと注目する筈ですが？

バートン: それら全部を飛び越える筈です。広範なLinux実現をするものは誰でも、このインフラストラクチャに注目します。Linuxに取って他に良いものはないからです。

シール: 多少なりともLinuxを本質的に管理適性にするものが他にありますか？

バートン: Linuxの中にコンフィギュレーションを発見するインフラストラクチャはありません。だからCalderaは、その中に入ってLinuxアーキテクチャの配線的発見をするものを作りました。デバイス、デバイスドライバ及びシステム装置の形で何があるかを指摘します。Volutionはこれを使います。これはOpenLinuxに結びつけられます。これはopensourceですが、これを行うエージェントはそうではありません。実際のマネージメントサービスを行うことによりカーブの前で外に出ようとしています。有力な強さです。

シール: 次のステップは？

バートン: 幾つか浮かぶ問題があります。Linux以外のプラットホームのため誰がCaldera Volutionのクライアントを構築するか？どのLinux分布がVolutionクライアントをまとめるか？などです。

シール: クライアントはブラウザではありませんか?

バートン: 「クライアント」の用語が紛らわしいのです。ブラウザからアクセス出来るVolutionマネージメントサーバーがあります。この点でブラウザはvolutionにとって「アドミニストレーション」クライアントです。アドミニストレーション・クライアントは、volutionのセットアップ、コンフィギュレーション及びメンテナンスのようなことをします。他に実際の「マネージメント」クライアントがいます。これはvolutionがLinuxプラットホームを管理出来るようにする一つのソフトウエアです。マネージメント・クライアントは問題に注目し、サーバーと連絡し、マネージメント機能を実行します。両クライアントの機能は、物事を確実にするのとパスワードの要求です。　

シール: LDAPについては?　LDAP ディレクトリに注目しますか?

バートン:セキュリティモデルを持つLDAP v3 ディレクトリを使います。Volutionの使える場所にV3 LDAPインフラストラクチャがあると要求を正当化するのに十分です。問題はV3が応答を定義しないことです。LDAPディレクトリに欠けているのは、命名問題の扱いと、LDAPサーバーが互いに通話することです。

シール: LDAPはプロトコルです。何故ですか、代わりにプロトコルがあったら−

バートン: LDAPはクライアントがサーバーと通話する方法をだけ決めます。サーバーがサーバーと通話する方法ではありません。

シール: 重要な相違ですね。出来ること出来ないことを図示できますか？Volutionコンソールを持っていて、複数ディレクトリに注目しているときは、出来ます。サーバーと通話するクライアントだからです。しかし−

バートン: −しかし、いやでも、異質のLDAPソリューションの支配下にあります−。

場所毎に一つのLADPを持つ沢山のLinux回線のある二つの会社を与えられたとしましょう。カリフォルニアのものは別のLinuxもあるが、ほとんどRed Hatで、LDAPディレクトリ・インフラストラクチャとしてNetscapeを使っています。ここで、ユタ州の人がNovellのLDAPディレクトリ・インフラストラクチャであるeDirectoryを買ったとしましょう。これら二つのシステムを一つの管理実体に統合することは出来ません。

シール: 未だそうですね。

バートン: 何時までもです。これらのサーバーが互いに話し合うことはないからです。

シール: そのためメタディレクトリが必要ですね。

バートン: その通りです。メタディレクトリがないと出来ませんが、下流の話です。

シール: だが、ここにメタディレクトリ製品があります。

バートン: NetscapeのものだったSunのiPlanetメタディレクトリが、自分の各種LDAPディレクトリを買ったベンダーを融合する方法を考えています。どうやって統合しますか？計画も人員も違うから話し合ってもまとまりません。問題は、ディレクトリがLDAPでないのと同じです。

シール: つまり、LDAPは必要だが 不十分。

バートン: そうです。私には、LDAPさえも、二つの島に見えて、一つには見えないのです。LDAPクライアントは任意のサーバーの任意のLDAPディレクトリを覗けますが、別の島を作っています。サーバーは統合されていません。

シール: だから今は出来ない

バートン: その通りです。Microsoftのメタディレクトリを買ってご覧なさい。その通りのものです。

シール: これは、Microsoftが数年前に買ったZoomitのVIAですが、すべてのディレクトリを含む建前になっています。

バートン: その通り

シール: だからWindows 2000サーバーを働かせている多数プラットホームショップを持っているなら、VIAを買って、サーバーに置けば、多数のLDAPを結合出来ますね。

バートン: そうです。だが、貴方が正統なLinux政策に従おうとする顧客だったら、出来ません。

シール: しかし全部がopen sourceだったら、Volutionさえ働かせないでしょう。.

バートン: その通りです。全部がopen source環境だったら、マネージメントを水に流すでしょう。全部がopen sourceのマネージメント・インフラストラクチャはありません。確かにVolutionのようなものはありません。

シール: Volutionだけが政策的に認められる、出来ると信じるすべてをオープンにする方針で、今なお存続する会社が作ったものだから。

バートン: そうです。人々は常にソフトウエアを求めています。open source だけが普遍的なインフラストラクチャを作るので、会社は−ベンダーも顧客も−open source 戦略を持たなければなりません。問題は、何をオープンにし、何をしないか、ではなく、普遍性と共有価値の双方を生み出す方法　です。Calderaには戦略があります。Red Hatもです。彼らは役者です。今日演じる open source戦略を持たなければなりません。それが現実性を持ち始めました。何もかもopen sourceにとは誰も反対しない理想です。open source支持者はopen sourceの価値の販売に良い仕事をして来ました。だが市場でそれを証明する場がなく、これからも無いでしょう。Calderaは、この問題を抱えています。Volutionのような製品を紹介しながら、すべてをopen sourceに持ち込む仕事を注意深く進めています。共有価値を高めながら、ひょっとして、closed sourceになるかも知れません。

シール: プロトコルとしてOpenSLP を使う理由ですね。

バートン: その通りです。これが明日には誰もが使える普遍性を生み出す何かだからです。Microsoft は同じことをSOAPでやりました。

シール: 他社と一緒に作りましたね。

バートン: そうです、だが open source 戦略に変わりありません。

シール: でも、まだ我々には新しい。

バートン: 未知の世界です。その世界で普遍なのはopen source材料で満ちていることですが、事業が繁栄しなければなりません。全部をclosed sourceソフトウエアにしてやって行けますか？会社が儲けようとするなら、否です。

シール: GNU Manifesto でRichard Stallmanは、無料0Sの背後にある事業アイデアは「0Sソフトウエアを競争社会から排除すること」である。「互いに利益を得ながら、別の分野で競争する、・・・OSを売る高価な商売からGNUが救い出してくれるだろう」と書いています。複数OSの管理はこの分野かも知れませんね。

バートン: その方向に進みましょう。Linuxの役割はクライアントを捕まえて優勝者になることだといいますが、馬鹿な話です。Linuxは既にインフラストラクチャ用プラットホームでは優勝者を超えた存在です。Linuxに基づくインフラストラクチャの次の目標を立てなければなりません。Linux社会で既に二つの会社がこの目標を立てています。Red Hat がeDirectory に基づく独占的サービスを提供しています。Caldera は、Volutionを提供します。これは、Red Hatを含むあらゆる種類のLinuxシステムで働くマネージメント・システムです。どちらが戦略的、長期的で産業に役立つでしょうか？Calderaの筈です。

シール: Red Hat はより良いものが見つかるまで、今出来ることをしているのではないでしょうか？

バートン: そうです。だが、サービスに当たって、スタンダードに基づく、ディレクトリ起動のサービスをする方法を模索しています。サービスではありません。そこにあるものだけです。大きい相違です。

シール: これはCalderaに有利な点ですが、欠点は？今のままのVolutionに悪いところはありませんか？

バートン: Volutionオブジェクト・モデルは、均質で長期的観点に立っていません。Desktop Management Task Force (DMTF)の Common Information Model (CIM) を使うべきだと思っています。Microsoftがどっぷり浸かっているのでLinux社会はCIMに抵抗しています。そこにいたのは、他がないからです。別のオブジェクトモデルを無理に働かせようとするのは時間の無駄ですが、政治家は何とかこれをかき混ぜようとしています。Linuxの他のプラットホームをサポートすべきと考えています。この製品はCalderaがインフラストラクチャ事業をするのかマネージメント事業をするのかとの疑問も起こします。誰でもがアプリケーションを置けるインフラストラクチャを提供するのは一つのことです。いずれ選ぶでしょうが、私はインフラストラクチャ事業に止まるべきと思います。

シール: Volution は両方は出来ませんか？

バートン: マネージメント・アプリケーションで始まるインフラストラクチャが殆どです。在庫とアプリケーションの販売、ハードウエアとソフトウエア在庫、健康監視、Linuxプリンタの構成と管理、これらはVolutionに伴うアプリケーションです。ヘルプも故障修理体制もありません。問題は、これらを行う誰かのパートナーになるか、自分でするかです。パートナーになるべきと思います。

シール: 明らかに製品であるものに付加価値を付けるべきでないのは何故ですか？

バートン: いけないわけではありません。自分達と産業の双方に最も良いからです。インフラストラクチャ戦略はそのルーツとの整合です。Linuxからマネージメント・インフラストラクチャに行くのは飛躍ではありません。Linuxからマネージメント・アプリケーションに行くのが飛躍です。全く違う事業です。細道を辿ることになるでしょう。企業にネットワーク・マネージメントを売るLinuxベンダーは、新しい概念で手探りなのです。

Copyright © 2001, シール.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 62 of Linux Gazette, February 2001

By Charles Shapiro

Copyright © 2001, Charles Shapiro.
Copying license http://www.linuxgazette.com/copying.html
Published in Issue 62 of Linux Gazette, February 2001

Linux Boxにビデオアプリケーションを

By Anderson Silva

Linuxの下で$50ドルのTVカードが出来ることを述べる。Kernelのコンパイル方法と、Linuxに一般アプリケーションを搭載する方法を述べる。各章にWeb上で入手出来る文書を多数示した。

Pinnacle Studio PCTV の設定を終わった。このTVカードは殆どのオンラインコンピュータ店で約$50で買える。

最初に私の設定を示す。

1 GHz Athlon、　　　　256 MB の RAM、　　60 GB HD

VIA 97 サウンドカード、　　　　　　　　　　Nvidia TNT2

Red Hat 7で作動中、　Kernel 2.4.1、　　　　　Xfree86 4.0.2
Pinnacle Studio PCTV、

必要なものは下記である：

1.Linuxの下で働くサウンド

　　これは /usr/sbin/setup を(Red Hatシステムの下で)ランさせるか、又は /sbin/insmodを用いて手動でサウンド・ドライバをロードする。

　　上記二つを試みてサウンドがLinuxの下で働かないときは http://www.opensound.com/ を参照。

2.bttvドライバをサポートするよう構成されたKernel　(http://www.strusel007.de/linux/bttv/) 　 Red Hatからのオリジナルkernel 2.2.x とともに、bttvドライバは、コンパイルされ使える状態で入っている筈。

　　2.4.0を（再）コンパイルする必要があるときは、次のオプションを起動する。

・/span> Under Character Devices-> I2C support, turn on I2C support, and I2C bit-banging interfaces

・/span> Under Multimedia Devices, turn on Video For Linux, and under Video For Linux, set BT848 Video For Linux as a module.

　　他に、ヘルプ以外で、必要なものがあれば、いつでもkernelの文書を読む。

　　Kernelとそのモジュールのコンパイルが済んだら、マシンを再ブートして、 /sbin/insmod bttvをランする。エラーのメッセージがでなければ、設定は終わり。

　　さて、ここで、TVドライバとインターフェイスするアプリケーションが必要になる。

　　　　　　So, now we need an application to interface with the TV drivers.　　　

3. xawtv

　　このアプリケーションは: http://www.strusel007.de/linux/xawtv/index.html　でダウンロードする。

　　変わったことはない。ダウンロードして、解凍して、

・/span> ./configure

・/span> ./make

・/span> ./make install

　　注記：このアプリケーション示した唯一のエラーは、: /etc/X11/app-defaults/ディレクトリ又はパスに何か不具合があると働かない。

3.1. xawtvを走らせる:

　　xawtvを走らせるには、 Xterminal 上でxawtvを走らせるだけで、懐かしい朦朧としたTVノイズが出る（これまでのステップすべてを正しく踏み、TVカード:-Dが搭載されていると仮定して）。

　　TVスクリーン上で右クリックするとメニューがあらわれ、ここでアプリケーションに対し何事