次回開発会議のお知らせ

[Masahiko Ishikawa]

NGMS ML 参加のみなさま

石川です。

昨日、予定通り NGMS 開発会議が開催されました。
議事録は今とりまとめ中で、作成し次第このMLにお送りします。

次回開発会議は、11月17日(火)15:00 - (午後3時-) です。
場所は、名古屋大学東山キャンパス内で選定中とのことです。

よろしくお願いします。

---------------------------------------------------------------------------
次世代ネットワーク情報基盤管理システム　開発会議 議事録(案)
---------------------------------------------------------------------------

■日時: 2009年10月28日(水) 13:00 - 16:30
■場所: 名古屋大学情報基盤センター 4F 会議室

■議題名

1. 開発言語決定を受けて
- 今後の開発プロセス、課題、留意点、など。

2. 内部設計 検討状況 報告(平野さん、今井さん)
- ネットワーク監視用config作成
- ネットワーク自動取得
3. 次回予定調整

4. 仕様検討 状況報告
- インストーラ・アップデートシステム
- インシデント管理
- 資産管理ファイル構造整理
- 基盤データ構造管理系
- コマンド体系

[Hironobu SUZUKI]

昨日の会議で、相手がどんなOSを使っているか、パケットからある程度判定でき
るという話をしましたが、その関連資料です。

http://www.sans.org/security-resources/idfaq/tcp_fingerprinting.php

http://nmap.org/book/osdetect.html

----
鈴 木 裕 信 (Hironobu SUZUKI)
E-Mail: hironobu @ h2np.net
URL: http://h2np.net

[Masahiko Ishikawa]

NGMS ML 参加のみなさま

石川です。

昨日の会議、議事録を作成しました。
参照くださり、何かありましたらこの ML までお寄せいただければ幸いです。

よろしくお願いします。

石川雅彦 masahiko[at]sra.co.jp Software Research Associates, Inc.

---------------------------------------------------------------------------
次世代ネットワーク情報基盤管理システム　開発会議(第5回)　議事録
---------------------------------------------------------------------------
■日時: 2009年10月28日(水) 13:00 - 16:45
■場所: 名古屋大学情報基盤センター 4F 会議室
■出席:(敬称略)
名古屋大学 : 河口、山口、情報基盤センター職員
とりまとめ担当: SRA 石川、山本
(以下順不同、敬称略)
ITプランニング(以下"ITP")
兼松エレクトロニクス
SRA(13:00-15:00, TV会議システによる参加)
鈴木裕信事務所(以下"SH") (15:00-参加)
他、ストリーミングにて傍聴者あり。

■資料
・議事次第
・ネットワーク自動取得設計資料
- perl プログラム、ruby プログラム、DeviceTreeとのAPI案
・コマンド体系.mm
・課題管理票
■議題
1. 導入(会議方針、経緯の説明)
2. 議論詳細
2.1. 開発言語決定を受けて
2.2. 内部設計 検討状況 報告(平野、今井)
2.3. 仕様検討 状況報告
3. 次回予定調整

■議事内容

1. 導入(会議方針、経緯の説明)
* 過去の会議経緯と、会議方針の再確認

2. 議論詳細
2.1 開発言語決定を受けて
・これから開発を進めていく上で、決めていくべき項目を提起・検討。

・検討項目とディスカッション結果
* ドキュメンテーション
- 初期構築から完成度の高いものを記述していく。

* パッケージ名
- "info.ngms"とする。

* コーディング規約
- 文字コード : UTF-8
- 改行コード : DOS(CR+LF) 汎用性を考慮
- インデント : 4タブ
- コメント : 内容充実のため日本語で記述

* ネーミング規約
- スコープに応じて命名規約を変えていく。
- 小文字・大文字を組み合わせる。(例) "doSomethingElse"
- ただし、Class や Trait は大文字始まりとする。

* リリースのイメージ
- trunk/ はプロジェクトごとに管理する。
- 混在を避けるため、release/ と trunk/ は分けて置くようにする。

* 開発環境
- 推奨環境 : Windows + IDE(Eclipse + プラグイン)
ただし、方針としては様々な環境での開発を許容する。
- ビルダー選定 : Ant または Maven
+ 先ずは Ant を使用する。
+ Maven の使用も視野に入れる。
+ MavenはScalaDocやhtmlへの出力機能が充実している。

* 情報共有ツール : Trac を使用
- Trac環境は大学内で構築し、構築後にアクセス方法はアナウンスする。
- 初期構築からの情報共有については、wikiベースで議論結果を蓄積する。
- 機能要望は Ticket で管理する。
- 情報公開の是非について
+ 方針としてはできるだけ公開していく。
+ ただし、ソースやテストデータに機密情報を載せないよう留意すること。

* マイルストーン
- バージョン0(直近のリリース版)に盛り込むべき機能イメージを共有した。
+ 最低限のネットワーク自動取得機能
-> 処理イメージ：取得対象のネットワークを指定
+ Shell 起動による操作や統計処理機能
+ nagios の config ファイル自動作成機能
+ Device Tree の操作機能
- 作成目標 : 11月末

・課題
* 開発環境
- Eclipseを使う場合はprjファイルが作られるが、それが最新化されなければファイル追加時に不整合が発生する

* ディレクトリ構成の検討
- info.ngms以下にプロジェクト単位でディレクトリが分かれるべき
- jarファイルが同じ場所に整理されればよいのでは？

* リファクタリング
- Subversion で Directory の変更を行うと不整合の恐れがある

* NGMSシステムとして、Device Treeの構成管理をどうするか？

・その他
* インストーラパッケージ
- config ファイルの作成が出来ても対象のツールがインストールされていないと意味が無いため、
nagios も含めてインストールが出来るのが良い。

2.2. 設計検討 状況発表
・ネットワーク自動取得および、ネットワーク監視用config作成に関して
設計、サンプル実装の結果を発表(SRA)

(1) サンプル実装プログラム(Perl版)説明&ディスカッション
同一セグメント内の SNMP から情報を取得し、取得情報の標準出力への出力までを作成
(2) サンプル実装プログラム(Scala版)説明&ディスカッション

(3) Device Tree API検討結果発表&ディスカッション
Device Tree操作 との APIを検討した。

・今後の検討作業

(1) Perl版サンプル実装のScala化(担当:SRA)
* サンプルではネットワーク全体を取得しようとしているが、実際には範囲を絞り込んで自動取得を行うよう変更。
* コマンドラインに記述すべき情報、configファイルに設定すべき情報の整理
* pipe や標準出力の使用を考慮
(2) Device Tree・クラス設計の整理(担当:SRA)
* 先ずは構築を進めていきそこから随時、課題を出して修正を進める。
=> 成果物は 随時 Subversion にアップし、MLでの議論を行う。

・プロジェクト全体の検討課題
(1) 設計文書の記法:
* scala実装に落とすための、十分な表現力を持つ設計記述方法は？

2.3. 仕様検討 状況発表

・開発項目の進捗状況と担当 (()内は担当。)
- インストーラ・アップデートシステム(担当未定)
+ 作業着手はまだ早い。
+ 開発と関連が深い。
+ 要件抽出には
+ 仕様策定未完。

- インシデント管理(担当未定)
+ 作業着手はまだ早い。
+ 今年度の目標は自動通知機能、エスカレーション機能の構築
+ 8-9月の会議で要件抽出可能
+ 仕様策定未完。

- コマンド体系(担当未定)
- 資産管理ファイル構造整理(ITP?)
- 基盤データ構造管理系(ITP?)
- ネットワーク監視用config作成(SRA)
- ネットワーク自動取得(SRA)
+ トポロジ推定(SH?) ... 次フェーズ？

・検討作業
* コマンド体系について説明(石川)
- コマンド体系は開発項目共通の体系が必要。
体系のたたき台を9月のソフトウェア構成WGで説明した。(-->NGMSコマンド体系.mm)
これはトップダウン的なアプローチ.
- 一方で、ボトムアップ的なアプローチとして、
開発項目個別のユースケースを、Device Treeを題材に検討してみた。これが今回の説明対象。
- 機器構成を管理するDESC.txt に対する操作、初期構築後のDevice Tree は必要となる操作が異なる。
DESC.txtでは、「あるネットワーク機器にIPアドレスを付与する」「あるネットワーク機器群に設置年月日を設定する」
などの操作が必要。
- 一方、Device Treeに対する操作は 挿入、移動、集約、分割、削除などの操作が必要。
+ 挿入とは、/a/b/1F → /a/x/b/1F とする(xを挿入)
+ 移動とは、mv 相当
+ 集約とは、a/b/1F/rt01,a/b/2F/rt02 の 1F と 2Fを集約し、a/b/rt01, a/b/rt02 とする
+ 分割とは、a/rt01, a/rt02 を, a/1F/rt01と a/2F/rt02 に分割する処理
+ 削除とは、rm 相当

* コマンド体系についてディスカッション
- unixのコマンドで出来ることを敢えてツール化する必要があるのか？
(例) 挿入する場合、mkdirとmvコマンドを人が入力するだけ
=> Device Treeは構成管理を行なう。ので、unixコマンド使用と共に行なうべき構成管理操作(commitなど)をツールに
組み込めば、操作が楽になることが期待できる。
- コマンド引数をどのように指定するか？
+ -(マイナス)オプション方式
+ CISCO IOS CLI方式
+ -(マイナス)の主なオプションの種類
1. Posix オプション (例) -a -z
2. GNUオプション (例) --x
3. Javaライク (例) -D xxxxx=yyyyyy
+ CISCO IOS CLI方式
コマンドの引数位置が意味を持つ。 show config, show int eth0/1 , conf t のように
show の後は config, int など

+ UNIX系のオプション記法は、オプション順に制約が少なく柔軟性が優れる。
-> プログラムの改修によりオプションを追加する場合も対応しやすい。
-> 人によっては、引数の並びが固定してしまう場合もある。 -v の位置。-i の位置などを常にコマンドの次に置くなど
+ シスコのコマンド記法は、引数の順番が固定されているのでオペレーションミスは少ない。

=> オプション系の機能をベースに、シスコの書き方を踏襲した仕組みを目指していく。

- コマンド補完の方法
+ CISCO CLI : conf t のように 1) conf は configure の略。2) conf の後 t で始まるコマンドは terminal しか
ないため、後の文字を省略可能。
+ Zシェル : 補完機能により、オプションや引数入力を支援可能

・課題管理状況
* 説明要旨(石川)
・開発個別項目と開発共通項目とで分けた
-開発個別項目(資産管理ファイル構造整理、基盤データ構造管理系、ネットワーク自動取得...)
-開発共通項目(コマンド体系、開発環境...)
* ディスカッション
- 必要に応じて閲覧していくレベルで良い。
- スキーマ仕様の策定：DMTF Schema Documentation(CIM)を調査するが、名称の参考程度とする。

3. 次回予定調整

* 次回開催日時: 2009/11/17(火) 15:00～ (午後3時～)
場所: 調整中 (名古屋大学東山キャンパス内で）

------------------------------------------------------------------------------------------------------------------

[Masahiko Ishikawa]

NGMS ML 参加のみなさま

石川です。

>昨日の会議、議事録を作成しました。
>参照くださり、何かありましたらこの ML までお寄せいただければ幸いです。

1) 誤記訂正
■出席:(敬称略)
誤> SRA(13:00-15:00, TV会議システによる参加)
正> SRA(13:00-15:00, TV会議システムによる参加)

2) 資料訂正
■資料
・ネットワーク自動取得設計資料
誤> - perl プログラム、ruby プログラム、DeviceTreeとのAPI案
正> - perl プログラム、scala プログラム、DeviceTreeとのAPI案

以下、訂正版をお送りします。

参照くださり、何かありましたらこの ML までお寄せください。

よろしくお願いします。

石川雅彦 masahiko[at]sra.co.jp Software Research Associates, Inc.

---------------------------------------------------------------------------
次世代ネットワーク情報基盤管理システム　開発会議(第5回)　議事録
作成 2009/10/29
訂正 2009/10/30

---------------------------------------------------------------------------
■日時: 2009年10月28日(水) 13:00 - 16:45
■場所: 名古屋大学情報基盤センター 4F 会議室
■出席:(敬称略)
名古屋大学 : 河口、山口、情報基盤センター職員
とりまとめ担当: SRA 石川、山本
(以下順不同、敬称略)
ITプランニング(以下"ITP")
兼松エレクトロニクス

SRA(13:00-15:00, TV会議システムによる参加)

鈴木裕信事務所(以下"SH") (15:00-参加)
他、ストリーミングにて傍聴者あり。

■資料
・議事次第
・ネットワーク自動取得設計資料
- perl プログラム、scala プログラム、DeviceTreeとのAPI案

■議事内容

* NGMSシステムとして、Device Treeの構成管理をどうするか？

・今後の検討作業

(1) Perl版サンプル実装のScala化(担当:SRA)
- サンプルではネットワーク全体を取得しようとしているが、実際には範囲を絞り込んで自動取得を行うよう変更。
- コマンドラインに記述すべき情報、configファイルに設定すべき情報の整理
- pipe や標準出力の使用を考慮

(2) Device Tree・クラス設計の整理(担当:SRA)

- 先ずは構築を進めていきそこから随時、課題を出して修正を進める。

=> 成果物は 随時 Subversion にアップし、MLでの議論を行う。

・プロジェクト全体の検討課題
(1) 設計文書の記法:
- scala実装に落とすための、十分な表現力を持つ設計記述方法は？

2.3. 仕様検討 状況発表

・開発項目の進捗状況と担当 (()内は担当。)
- インストーラ・アップデートシステム(担当未定)
+ 作業着手はまだ早い。
+ 開発と関連が深い。

+ 要件抽出にはまだ早い。

[tak...@users.sourceforge.jp]

NGMS ML 参加のみなさま

長谷川です。

> (2) Device Tree・クラス設計の整理(担当:SRA)
> - 先ずは構築を進めていきそこから随時、課題を出して修正を進める。

弊社で Device Tree の検討を行いました。
まずはクラス設計の前に要件定義をまとめる必要があると考え、
ネットワーク自動取得および、ネットワーク監視用config作成のために
必要な要件をまとめました。

要件定義は下記になります。

- Device Tree と Device Tree の
実体(UNIX ファイルシステム、subversion、DB)は切り離し可能とする
- 論理パス <-> 物理パス変換機能
- 追加機能(論理パス or 物理パス or ユニークIDで追加)
- 取得機能(論理パス or 物理パス or ユニークIDで取得)
- 検索機能(論理パス or 物理パス or ユニークIDで検索)
- ユニークID割り当て機能
ユニークIDとは: ファイルシステムの i ノードに相当する。

ユニークIDが必要な理由は、
IP アドレスや置き場所に依存せずに機器を特定するためです。

よろしくお願い致します。

[Satoshi Ogasawara]

長谷川様
小笠原です。

On 2009/11/04, at 13:52, tak...@users.sourceforge.jp wrote:
> - Device Tree と Device Tree の
> 実体(UNIX ファイルシステム、subversion、DB)は切り離し可能とする
> - 論理パス <-> 物理パス変換機能
> - 追加機能(論理パス or 物理パス or ユニークIDで追加)
> - 取得機能(論理パス or 物理パス or ユニークIDで取得)
> - 検索機能(論理パス or 物理パス or ユニークIDで検索)
> - ユニークID割り当て機能
> ユニークIDとは: ファイルシステムの i ノードに相当する。

ありがとうございます。私の方でも現在必要なTreeの抽象化（Device
Treeより抽象的なTree）について検討中ですが、似たようなことを考え
ておりました。

ただ、物理パスというのはこの場合何を意図していらっしゃいますでしょうか。
もしTreeの実体における内部的なパスなら、直感的には外部に晒す必要はない
ように疑問に思いました。

また、Treeの要素に対するアクセスコントロールも必要かもしれません。以前
のお打ち合わせでは権限管理はOSレベルではなくアプリケーションレベルでも
行った方が柔軟であるとの議論がありました。

加えて私の方ではシンボリックリンク機能もTree構造に導入する予定です。

まだ構想段階ですが、Treeの"ファイル"に対応する要素には種類を持たせて、
単なるバイト列と構造を持つデータを区別したいと考えています。

---
(有)ITプランニング 小笠原　啓
| - Email: ogas...@itpl.co.jp

[Masahiko Ishikawa]

石川です。権限管理について補足します。

From: Satoshi Ogasawara <ogas...@itpl.co.jp>
Subject: [ngms:0034] Re: 10/28開発会議 議事録
Date: Wed, 4 Nov 2009 14:25:58 +0900
> また、Treeの要素に対するアクセスコントロールも必要かもしれません。以前
> のお打ち合わせでは権限管理はOSレベルではなくアプリケーションレベルでも
> 行った方が柔軟であるとの議論がありました。

9月28日開催会議で議論しました。資料を参照ください。
http://ngms.info/bbs/viewtopic.php?f=3&t=21

NGMS開発会議まとめ.pptx P.27 です。
------------------------------------------------------------------
アクセス権限管理
------------------------------------------------------------------
・ＯＳレベルか、アプリレベルか
- デフォルトはなし（スーパーユーザのみ）
- User Tree / AAA Treeが、あれば、それを利用

- アプリレベルのユーザ管理
- ファイル操作ライブラリは、権限チェックを　行えるように拡張可能としておく。
- 最初から例外処理を用意しておくべき

------------------------------------------------------------------

[tak...@users.sourceforge.jp]

小笠原様
長谷川です。

On Wed, 4 Nov 2009 14:25:58 +0900
Satoshi Ogasawara <ogas...@itpl.co.jp> wrote:
> ただ、物理パスというのはこの場合何を意図していらっしゃいますでしょうか。
> もしTreeの実体における内部的なパスなら、直感的には外部に晒す必要はない
> ように疑問に思いました。

物理パスは Tree の実体における内部的なパスを意図しております。
小笠原様がお書きになられておりますように、
外部に晒す必要はないというのは私も同意見です。
ですが、物理パスを指定することができると便利な場合が
あるのではないかと考え、要件定義に入れさせていただきました。

よろしくお願い致します。

[Masahiko Ishikawa]

石川です。

Device Tree・クラス設計の整理に関する議論ですが、その後いかがでしょうか?

要件定義がまとまったようですね。その後、どのように進めましょう? > みなさま、(特に開発チームのみなさま)

この件、詳細な経緯は
http://groups.google.co.jp/group/ngms/browse_thread/thread/11ad5b6b833a9e05?hl=ja
で追うことができます。

以下は要約です。

(1) 前回開発会議において、以下の担当、作業項目が決まった。

| (2) Device Tree・クラス設計の整理(担当:SRA)
| - 先ずは構築を進めていきそこから随時、課題を出して修正を進める。

(2)これを受けて、長谷川さんが、要件定義をまとめた。

|弊社で Device Tree の検討を行いました。
|まずはクラス設計の前に要件定義をまとめる必要があると考え、
|ネットワーク自動取得および、ネットワーク監視用config作成のために
|必要な要件をまとめました。

要件定義は以下の通り

| - Device Tree と Device Tree の
| 実体(UNIX ファイルシステム、subversion、DB)は切り離し可能とする
| - 論理パス <-> 物理パス変換機能
| - 追加機能(論理パス or 物理パス or ユニークIDで追加)
| - 取得機能(論理パス or 物理パス or ユニークIDで取得)
| - 検索機能(論理パス or 物理パス or ユニークIDで検索)
| - ユニークID割り当て機能
| ユニークIDとは: ファイルシステムの i ノードに相当する。

補足として、
|ユニークIDが必要な理由は、
|IP アドレスや置き場所に依存せずに機器を特定するためです。

(3) 要件定義について、小笠原さんから reply

|ありがとうございます。私の方でも現在必要なTreeの抽象化（Device
|Treeより抽象的なTree）について検討中ですが、似たようなことを考え
|ておりました。

.....

|加えて私の方ではシンボリックリンク機能もTree構造に導入する予定です。
|
|まだ構想段階ですが、Treeの"ファイル"に対応する要素には種類を持たせて、
|単なるバイト列と構造を持つデータを区別したいと考えています。

(4) 要件定義の内容について、小笠原さん、長谷川さんで質疑応答。
# 最後のメールが以下。

[Satoshi Ogasawara]

石川様、開発者各位
小笠原です。

On 2009/11/13, at 14:34, Masahiko Ishikawa wrote:
> Device Tree・クラス設計の整理に関する議論ですが、その後いかがでしょうか?
> 要件定義がまとまったようですね。その後、どのように進めましょう? > みなさま、(特に開発チームのみなさま)

はい、実は木構造に対する操作自体は難しくないのですが、この木構造を
操作する実装を入れ替えることが出来る設計（内部的にファイルシステム
にマッピングしたり、いざとなればDBにもマッピングできる設計）が意外
と難しく、ややコミットが遅れておりました。

Scalaには構造的部分型（存在型）がありますので、まずそれを応用した
クラス設計を進めました。ところが、Scalaの構造的部分型の機能ではバイ
ナリメソッドがうまく扱えない事が分かり、急遽abstract classと型パラメ
ータの組み合わせに移行したという経緯を踏んでおります。

本日にはこれらのクラス設計を整理してコミットしようと考えています。

宜しくお願い申し上げます。