NAKAMURA Minoru の日記 (2003年9月)

先月の日記(2003年08月) 今月の日記(2003年09月)
2002 | 10 | 11 | 12
2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
2024 | 1 | 2 | 3 | 4
ホームページ | 最新のコメント50
インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
はてな ダイアリー アンテナ ブックマーク ブログ
Twitter | mixi | Facebook | slideshare | github | Qiita



9/30 (火)

不正アクセスの集計

今月も終わりなので不正アクセスの分析を行う。 先月以来、 BlasterNachi の影響でログは爆発しているので、 分別して集計する。

今月の閉鎖ポートへのアクセスは 7万弱。 そのうち 99% までが Blaster によるものと思われるの Port 135 へのアクセス。 7/31 の データと較べられるように Port 135 とそれ以外を分けて集計してみる。

Port 135 以外への不正アクセス
アクセスホスト(IP)数
順位国別割合
1US (アメリカ)35.97%
2CN (中国)12.59%
3JP (日本)7.82%
4BR (ブラジル)4.61%
5KR (韓国)4.38%
6CA (カナダ)3.52%
7TW (台湾)2.89%
8UK (イギリス)2.42%
9DE (ドイツ)2.11%
10IT (イタリア)1.72%
     
アクセス数
順位国別割合
1US (アメリカ)46.24%
2CN (中国)11.46%
3JP (日本)9.47%
4KR (韓国)3.70%
5CA (カナダ)3.43%
6BR (ブラジル)3.08%
7TW (台湾)2.73%
8UK (イギリス)1.89%
9AU (オーストラリア)1.68%
10DE (ドイツ)1.50%

こちらのリストは、あまり変化が見られない。

一方、Port 135 へアッタクを掛けてきたのは以下の通り。

Port 135 への不正アクセス(W32.Blaster.Worm 系ワーム)
アクセスホスト(IP)数
順位国別割合
1US (アメリカ)45.80%
2JP (日本)27.64%
3UK (イギリス)4.04%
4CA (カナダ)3.21%
5DE (ドイツ)1.82%
6ES (スペイン)1.58%
7HK (香港)1.55%
8CN (中国)1.39%
9AU (オーストラリア)1.11%
10KR (韓国)0.84%
     
アクセス数
順位国別割合
1JP (日本)51.86%
2US (アメリカ)32.24%
3UK (イギリス)2.71%
4CA (カナダ)2.11%
5CN (中国)1.08%
6HK (香港)0.98%
7DE (ドイツ)0.83%
8AU (オーストラリア)0.73%
9ES (スペイン)0.60%
10KR (韓国)0.60%

Blaster は攻撃先アドレスの生成に 40% の確率で近距離(IPアドレスの上位が一致するパターン)、 60% の確率で遠距離(完全ランダムなパターン) を行うそうなので、 日本以外の国からのアクセスは すべて遠距離のパターンであろう。 上のリストの割合が、Blaster に感染したコンピュータの分布だと思われる。

HTTP(Port 80) 番への不正アクセスは 7,184件。

Port 135 への不正アクセス(W32.Blaster.Worm 系ワーム)
アクセスホスト(IP)数
順位国別割合
1US (アメリカ)61.22%
2JP (日本)7.38%
3CA (カナダ)6.05%
4CN (中国)5.59%
5UK (イギリス)5.26%
7HK (香港)1.96%
8KR (韓国)1.60%
9TW (台湾)1.46%

Apache の改造を行った 9/20 以降は Nachi のアクセスが記録に残るようになったのでごちゃ混ぜのデータ。 とにかくアメリカからの攻撃が増えている。 とりあえず、 日本からのアクセスのものは 端からプロバイダーに通告。

追記:10/5
9/6 から3日に一度程度の割り合いで /scripts/nsiislog.dll にアクセスしてくる輩がいるのを発見。
IIS の拡張機能 の脆弱性を探しているようだ。

訂正:12/5
Port 135 を 115 と書いていたのを訂正。


9/28 (日)

[Prog] ビットの立っている位置を数えるアルゴリズム

(この日記の内容は このページ にまとめました)

ビット数を数えるアルゴリズム を ろくに知らなかったことにダメージを受けたので、 「正解」を見る前に Number of Leading Zero (NLZ)Number of Training Zero (NTZ) を 求めるアルゴリズムだけでも自力で考えてみようとがんばる。

NLZ (NTZ) はビット列の左側 Leftmost bit (右側 Rightmost bit) から 0 がいくつ並んでいるかという値(0 の場合には、32 が返る)。 言い替えれば最初に 1 が立っている位置を求めるアルゴリズム。

NLZ  こっちから 0 の数を数える → 0010010010000100
NTZ 0010010010000100 ← こっちから 0 の数を数える

NTZ の方はなんとか自分で考えついた。
x&(-x) を行うと 左側から最初に 1 が立っているアドレスのみを残して 他のビットは 0 で埋まるので、 (x&(-x))-1 を計算しそのビット数を数えればよい。

x&(-x)    0101100 0000100
(x&(-x))-1    0101100 0000011
count_bits((x&(-x))-1)    0101100 2

一方の NLZ にも、 NTZ と同様の最初に 1 が出現する以降のビットが 全部 1 で埋まる演算があるはずだと 色々考えあぐねるが発見できず。

そうこうするうちに Amazon.co.jp で注文していた Hacker's Delight が届く。 あきらめて読んでみる。
NTZ の最適化されたアルゴリズムは 以下のようになる。

  • NTZ(x) = count_bits((~x)&(x-1)) (これは count_bits((x&(-x))-1) と等価)。
  • 最適化な CLZ がすでに見つかっている場合には、 NTZ(x) = 32 - NLZ((~x)&(x-1))

となり、 正解には接近していた模様。

一方、 NLZ のようにビットを並べる場合には、

バージョン1: ビットカウント問題に帰着させる
int nlz1(unsigned x) {
  x = x | ( x >>  1 );
  x = x | ( x >>  2 );
  x = x | ( x >>  4 );
  x = x | ( x >>  8 );
  x = x | ( x >> 16 );
  return count_bits( ~x );
}

nlz1~x までの操作で、 上位のビットが下位にコピーされてゆき 以下のようにビットが立つことになる。

入力   出力
0000 → 1111
0001 → 1110
0010 → 1100
0011 → 1100
0100 → 1000
0101 → 1000
0110 → 1000
0111 → 1000
1000 → 0000
1001 → 0000

ただし、 nlz1 は ほとんどのアーキテクチャで最速ではないようだ。
Hacker's Delight に掲載されている nlz2nlz3 のアルゴリズムと比較すると、 Linux の AMD Duron 800MHz / gcc 2.95.3 (-O2) 環境で nlz2 (7.7秒) > nlz3 (11.7秒) > nlz1 (18.1秒) と 分岐命令の多い nlz2 が最速という結果になった (括弧内は 0x10000000 回 実行した実行時間)。
無論、結果はコンパイラやアーキテクチャによって 左右されると思われる (分岐ペナルティが大きい Pentium4 では nlz2 は不利?)。

バージョン2: 分岐を使うバージョン
int nlz2(unsigned x) {
  unsigned y;
  int n = 32;
  y = x >> 16; if (y != 0){ n = n - 16 ; x = y; }
  y = x >>  8; if (y != 0){ n = n - 8 ; x = y; }
  y = x >>  4; if (y != 0){ n = n - 4 ; x = y; }
  y = x >>  2; if (y != 0){ n = n - 2 ; x = y; }
  y = x >>  1; if (y != 0){ return n - 2; }
  return n - x;
}
   
バージョン3: 分岐を消したバージョン
int nlz3(unsigned x) {
  int y, m, n;

  y = - (x >> 16);
  m = (y >> 16) & 16;
  n = 16 - m;
  x = x >> m;

  y = x - 0x100;
  m = (y >> 16) & 8;
  n = n + m;
  x = x << m;

  y = x - 0x1000;
  m = (y >> 16) & 4;
  n = n + m;
  x = x << m;

  y = x - 0x4000;
  m = (y >> 16) & 2;
  n = n + m;
  x = x << m;

  y = x >> 14;
  m = y & ~(y >> 1);
  return n + 2 - m;
}


P.S.
NLZ を求める方法の中で最も奇抜なのは 浮動小数点演算を利用する方法だと思われる。
まずはコードをご賞味あれ。

バージョン4 : 浮動小数点演算を利用するバージョン
// LE は big-endian なら 0、little-endian なら 1

int nlz4(unsigned x)
  union {
    unsigned as_int[2];
    double as_double;
  } data;

  int n;
  data.as_double = (double)x + 0.5;
  n = 1054 - (data.as_int[LE] << 20);
  return n;
}

これは IEEE 754 形式の浮動小数点フォーマットを利用した方法。
倍精度浮動小数(64ビット)のメモリイメージは 以下のようなビット配置になり、 その値は (-1)^S × 1.xxxxxx × 2^(yyyy) の形になるので、 整数を浮動小数点に変換すると一番左に 1 が立っている位置が仮数部に現れる。

63 62〜52 51〜0
符号(S) 指数(yyy...) 仮数(xxx...)

これは結局、整数 → 浮動小数への変換が log2 の演算に相当するから。
nlz4 で 0.5 を足すのは x = 0.0 の時 正しく 32 を返させるためのおまじない。 浮動小数点の 0.0 のメモリ表現は すべてのビットが 0 となる特殊な値なので、 1.0 × 2^(-1) となる 0.5 をストッパーとして足しておく。

整数  浮動小数点
0001 → 1.000 × 2^(0)
001x → 1.x00 × 2^(1)
01xx → 1.xx0 × 2^(2)
1xxx → 1.xxx × 2^(3)

ただし C 版の nlz4 のコードを実際にコンパイルすると、 共用体部分に load / store 命令部分が出現するため あまり速度は出てないと予想される。 SPARC 系を除く大概の CPU には 整数レジスタ ⇔ 浮動小数点レジスタ命令があるので、 アセンブラを使ってごりごり記述するが吉。
この方法はかなり奇天烈だが、 結局のところビットの検索を 浮動小数点演算器というブラックボックスに任せただけなので アルゴリズムとは言い難いかも。

覚え書き

IBM Think Pad T40 を購入。
T 氏のつてで 社員販売価格で購入。


9/27 (土)

チーズケーキファクトリー三宿店 ⇒ 百人町屋台村 (大久保)

「エンゲル係数を高める会」の会合。
14:00 頃から総勢 10 人で チーズケーキファクトリー 三宿店に行きチーズケーキバイキング。
チーズケーキとはいえ 食べれば血糖値が急上昇する代物。 メンバー全員 数個のケーキを食べた時点でまったり。
チーズケーキファクトリーのバイキングの教訓: N.Y. チーズケーキを一人で食べるのはやめよう

その後、 徒歩で渋谷に移動。 メンバーは 4 人が抜けるが 大久保の 百人町屋台村 へ。
エンゲル係数を高める会では、 同じ百人町にあるアジア屋台料理 「富翁」 へ ずいぶん足を運んでいるが、 百人町屋台村のほうは 改装中だったり休みだったりが重なって行きそびれていた。 両者 同じような雰囲気の屋台料理屋だが、 日本語があんまり通じない富翁と較べて、 百人町屋台村の方は非常に達者。 しかもすごい接客熱心で、 少しでもメニューを広げるそぶりをみせると ものすごい勢いで近づいて来て 「これがうまい」、「これが美味しい」と勧めてくる。 これが亜細亜的なのか?
値段はいろいろ食べて一人 2,000円くらいしか掛からなかったので、 富翁よりも安いかもしれない。


9/26 (金)

[Tips] Web ブラウザのプロキシ設定

Microsoft Internet Explorer(IE) や Netscape Navigator (NN) の プロキシの設定に関する雑記。

自動プロキシ構成スクリプト
IE や NN では Java Script の書かれた設定ファイルを与えることによって プロキシの構成を自動的に設定することができる。 また、 設定ファイル自体が Java Script で書かれているため いろいろ programmable にプロキシ設定を変更することも可能なようだ。

自動プロキシ構成スクリプトとして与える Java Script ファイルは、 FindProxyForURL(url,host) を含む必要がある。 このメソッドが "PROXY 192.168.0.1" のように "PROXY" + アドレスを 返してきた時はブラウザはプロキシサーバーに接続する。 "DIRECT" を返す場合には、プロキシなしで直接接続を試みる。 もし、 "PROXY 192.168.0.1; PROXY 192.168.0.2; DIRECT" のようにセミコロンで区切られ設定が列挙された場合、 左側のサイトから順にプロキシをチェックしにいくようだ。

自動プロキシ設定ファイルは 簡単なものであれば IE と NN で共用できそうだが、 Java Script の方言の違いもあるので 設定を分けた方がよさそうだ。
IE の設定ファイル : proxy_for_IE.js
function FindProxyForURL(url, host) {
  if (url.substring(0, 5) == "http:") {
    if( shExpMatch(url, "http://www.nmnioru.jp/") )
      return "DIRECT";
    return "PROXY 192.168.0.1:8080";
  } else if (url.substring(0, 4) == "ftp:") {
    return "PROXY 192.168.0.1:8080";
  } else if (url.substring(0, 6) == "https:") {
    return "PROXY 192.168.0.1:8080";
  } else if (url.substring(0, 7) == "gopher:") {
    return "DIRECT";
  }
}
ただし、 IE は FindProxyForURL の結果をキャッシュしてしまうので (KB:271361)、 同一ホストに対して複数のプロキシを切り替えながら使うようなことは 通常はできない。

NN の場合には Navigator Proxy Auto-Config File Format に 詳しい解説がある。
以下のような感じで設定ファイルが記述できる。
NN の設定ファイル : proxy.pac
function FindProxyForURL(url, host) {
  if (isPlainHostName(host) ||                       // "www" のようにドット(.)のない形式
    isInNet(host, "192.168.1.0", "255.255.255.0") || // IP アドレスがある範囲内なら
    dnsDomainIs(host, "nminoru.jp") )                // あるドメインの一部なら
    return "DIRECT";
  } else {
    return "PROXY 192.168.0.1:8080; DIRECT";
  }
}

WAPD(Web Proxy AutoDiscovery protocol) プロトコルによるプロキシ構成の自動検出
IE の 5.0 以降では 上述の自動プロキシ構成スクリプトの位置を自動的に検出する機能が備わっている。
この機能は IE の「インターネットオプション」の 「接続」タブ → 「LANの設定(L)」 → 「設定を自動的に検出する(A)」を 有効にすると機能するようになる。

WAPD が有効になった Web ブラウザは DHCP (Dynamic Host Configuration Protocol)、 SLP (Service Location Protocol)、 DNS (Domain Name Service) に 順にプロキシ構成スクリプトのあるサーバーの位置を訪ねて行く。 そのためプロキシの自動構成を行いたい場合には、 LAN 内に DHCP サーバーか、SLP サーバー、DNS サーバーを立てる必要がある。
MS としては Windows2000 Server を用いて DHCP で運用することを推奨しているようだが (KB: 252898)、 UNIX 系の OS を使っている場合には DNS サーバーを用いた方が簡単。

やり方は、
  1. LAN 内の適当なサイトで Web サーバーを運用。 その /wpad.dat の位置に 以下のプロキシ自動構成ファイルをおく。
    Web サーバーは wpad.dat に対して "application/x-ns-proxy-autoconfig" の MIME タイプを指定するのが望ましい。
  2. LAN 内のホストが nminoru.jp というドメインに所属している場合には、 担当 DNS サーバーに 1. のサーバーを wpad.nminoru.jp で登録してもらう。 wpad はエイリアスでも構わない。
    一応、DNS は内外で分けた方が安全。
WPAD の詳細は ドラフト にある。

IE のプロキシ設定をマシンで統一する方法
1 台の Windows マシンを複数人で共有したりすると、 アカウントが変わる毎に IE の設定を新たに行う必要がある。
これを省くために、 同一マシンのプロキシ設定を統一してしまう設定が可能。
以下のレジストリを修正する。
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CurrentVersion\Internet Settings]
"ProxySettingsPerUser"=dword:00000000
ただし誰でもマシン設定を変更できるという 危険性もある。

9/24 (水)

[Bench] 久しぶりに新しい CPU の SPEC CPU2000 スコアが登録される

www.spec.org に AMD の AMD64 の石 Athlon64 FX-51 (2,200MHz) と Athlon64 3200+ (2,000MHz) が 正式公開された模様。
SPEC への登録は 2週間前ぐらい前になされたようだが、 AMD からの御披露目があるまでは伏せられていた模様 (いろいろリークされていたが)。 その間、 管理人は毎日 SPEC のページを詣でていたが、 先に IBM から eServer 325 (2.0 GHz Opteron) の CINT2000 (1,226) が登録されるなど、 一日千秋の思いであった。

問題の測定は、 Athlon 64 FX-51 は同じ構成のマシンを IA-32 版の Windows XP 上で Intel C/C++/Fortran Compiler と Compaq Visual Fortran (DVF) を 用いてコンパイルしたスコアと、 AMD64 にネイティブに対応した SuSE Linux 9.0 Professional for AMD 64 上で gcc33 (のカスタム) と PGI Fortran 5.0-2 でコンパイルしたスコアの 2 通りが公開されている。

Windows XP のスコアは CINT2000 が 1,447 で Itanium2 1.5GHz の 1,322 を抜いてトップに踊り出た。 CFP2000 は 1,423 で IA-32 系の中では最強。 とはいえ 2,000 台を越えて独走している Itanium2 には大きく水をあけられている。

一方、 SuSE Linux でのスコアは CINT2000 が 1,395、 CFP2000 が 1,378 と Windows XP のスコアにわずかに敗けている。
とはいえ LP32 から LP64 になってこの性能低下で済むのだから GCC の AMD64 最適化はがんばっているようだ。 個別のベンチマークでみると CINT では 181.mcf、186.crafty、252.eon、256.bzip2、CFP では 168.wupwise、172.mgrid、177.mesa、178.galgel、183.equake、191.fma3d は SuSE Linux のうほうが性能が高い。

性能は期待した以上に高くて驚きだ。 だが自分で買いたいかといわれると、どうも食指が動かない。
ホスティングをやるには IA-32 で十分だし、 SOHO 系のビジネルサーバーとして使うには、ちゃんとした製品が(IBM ぐらいしか)ない。 計算パワーが必要なだけだったら IA-32 のクラスタサーバーがあるし。 とりあえず仕事のためには Itanium2 が、 個人的には PowerMac G5 が欲しい。。。

P.S.
自分のサイト SPECcpu2000 にみるプロセッサの性能自分のページも更新。


9/23 (火)

ディスクレスクラスタに関する雑考

ネットブートを行うディスクレス クラスタシステムを作ると ディスクイメージの共有方法で苦しむ。 8/25 の日記 にも書いたが Linux では /dev/var は独立させる必要があるし、 プログラムによっては /etc/usr/opt 以下に 動的にファイルを生成するものがあり共有を困難にしている。

無論、 クラスタのノード毎に別々のディスクイメージを用意するという方法があるが、 ほとんど同じディスクイメージを大量に抱えこまなければいけない。 回避方法を考えてみると、

  • RAID や VMWare のスナップショット機能のように、 基準イメージをもとにして それ以降に行われた変更を差分イメージとして扱える機構を作って 各ノードは差分イメージのみを保持。
  • ノード分のイメージを作成するが 各イメージ内のファイルは hard link し 実体を共有させる。
    ファイルへの書き込みがある場合には copy-on-write のように、 マスターを複製して対処する。

既存ソフトで 1. 2. を実現可能なものがないか調査しているが、 Cluster Manager など微妙に異なるものはあも うまく合致したものは見つからず。

覚え書き

夜は元住吉のハンバーグ & オムライス屋さんビッグアップルで ふんわりオムライスを食す。

「ビッグアップル」のふんわりオムライス
ふんわりオムライス

9/22 (月)

[OS] Solaris のプロセス終了に関するメモ書き

UNIX は子プロセスがなんらかの原因で終了する場合、 OS が親プロセスに SIGCHLD を送信して 子プロセスの終了を通知する。
Solaris の場合には SIGCHLD が親プロセスに送られた時点で、 子プロセスのメモリ空間からはメモリや lwp が剥ぎ取られ「死んだ」状態になっているが、 procfs 上にはまだ情報が残っているので 緑色 の部分で色々情報が採取可能。

void signal_handler_for_SIGCHLD(int sig, siginfo_t* siginfo, void* p){
  switch (siginfo->si_code) {
    case SI_USER:
    case SI_LWP:
      /* 子プロセスの終了とは関係ない場合 */
      break;

    case CLD_EXITED:
    case CLD_KILLED:
    case CLD_DUMPED:
      /* 子プロセスが死亡(exit/kill/abort) */
      break;

    case CLD_TRAPPED:
    case CLD_STOPPED:
    case CLD_CONTINUED:
      /* 子プロセスが ptrace などによって待機・再開させている */
  }
  /*     この地点で子プロセスのメモリ等は剥ぎ取られている。     しかし procfs には子プロセスに関する情報がまだ残っている。     /usr/include/sys/procfs.h の psinfo_t や prusage_t の     情報を引き上げることが可能。   */   /* waitpid: 子プロセスを本当を完全に終了させる */   if (waitpid(siginfo->si_pid, &status, WNOHANG) < 0) {     /* エラー処理 */   } }

9/21 (日)

「《大至急御連絡致します》必ずお読み下さい」

と言うタイトルの有料サイト利用料金の督促メールが我が家にも届く。

追記:9/24

「平成15年9月24日(水)必着」の支払い期限がきてしまう (^_^;


9/20 (土)

[Tips] Apache の mod_setenvif モジュールの改造

管理人の管理している公開サイトは Apache のログを「外部からの正規のアクセス(access_log)」、「内部からのアクセス(local_log)」、「コンピュータビールス・ワームとみられるアクセス(worm_log)」に分割して記録している(昨年の10/15の日記)。 しかし、8/19 頃から Nachi ワームからとみられるアクセスが激増してアクセスログを汚して非常に不快であった。

問題のアクセスは "Mozilla/4.0 (compatible; MSIE 5.5; Windows 98)" という User Agent フィールドを持ち、"/""HTTP/1.1" で GET してくるという特徴がある。 ここまで分かっているのだから、この 3 つの条件を全部 満たすアクセスは worm_log に叩き込みたい。 しかし、Apache の機能不足のようで、これをうまくこなす設定ができない。 SetEnvIf ディレクティブと CustomLog ディレクティブだけでは OR 条件を作れるが AND 条件が作れないことが原因だ。

しょうがないので SetEnvIf を提供している mod_setenvif を hack して機能を拡張することにした。
追加したのは SetEnvIfAllSetEnvIfEither のディレクティブ。

SetEnvIfAll name  value  expr1 [expr2 [expr3 [...]]]
SetEnvIfEither name  value  expr1 [expr2 [expr3 [...]]]

SetEnvIfAllexpr(n) の条件が全部 成立した場合に name という名前の変数を定義し、 その値を value にセットする。value は定数・定数文字列である必要がある。 逆に SetEnvIfAll は条件うちどれかが成立していれば 変数をセットする。
条件部分である expr(n) には変数名を書いて、 その変数が定義されている場合の条件を書くことができる。 変数名の頭の前に "!" を付けたものも書けて、 この場合 変数が定義されていない場合に条件が成立する。 変数の値をチェックする機能はない (SetEnvIf を使えば間接的にできるから)。

この機能を使うと 以下のように http.conf が書けるようになって ログを分類できるようになる。

# 10.0.0.0/24 の IP はローカルとみなす。
SetEnvIf Remote_Addr	"^10\." 	                     local_site_access

# 画像ファイルの識別
SetEnvIf Request_URI	"\.(jpg)|\.(gif)|\.(xbm)|\.(png)"    image_file

# default.ida、root.exe、cmd.exe を含 URL に含むアクセスはワーム
SetEnvIf Request_URI	"default\.ida|root\.exe|cmd\.exe"    worm

# Nachi ワーム対策  3 つの条件を列挙
SetEnvIf Request_URI	  "^/$"					                 nachi1
SetEnvIf Request_Protocol "^HTTP/1.1"				                 nachi2
BrowserMatch		  "^Mozilla/4\.0 \(compatible; MSIE 5\.5; Windows 98\)"  nachi3

# nachi1、nachi2、nachi3 がすべて定義されていれば worm を定義してその値を 1 にする
SetEnvIfAll worm 1 nachi1 nachi2 nachi3

# 画像ファイルではなく(!image_file)、ワームでもない(!worm) アクセスを分類
SetEnvIfAll output_access_log 1 !local_site_access !image_file !worm
SetEnvIfAll output_local_log  1 local_site_access  !image_file !worm   

# 条件に応じて出力する
CustomLog logs/worm_log   combined env=worm
CustomLog logs/local_log  combined env=output_local_log
CustomLog logs/access_log combined env=output_access_log

ログが奇麗に分かれてしあわせだ。

P.S.

とりあえず mod_setenvif.c をハックしたパッチを ここ においておく。 このパッチは Apache 1.3.28 の src/modules/standard/mod_setenvif.c に対するも。
mod_setenvif.c はあまりバージョンアップを受けていないようなので 他のバージョンでもうまくいくかもしれない。
Vine Linux 2.6 (x86) / Apache 1.3.27 で確認。

(apache_1.3.28.tar.gz をどこからか入手しておく)
> tar xzvf apache_1.3.28.tar.gz
> cp  apache_1.3.28/src/modules/standard/mod_setenvif.c  . 
> patch mod_setenvif.c < mod_setenvif.c.patch

(mod_setenvif の コンパイル)
> apxs -c mod_setenvif.c

(mod_setenvif.so ができたのでこれを入れ替え。モジュールのあるディレクトリは適当に読みかえること)
> su
# mv /usr/lib/apache/mod_setenvif.so /usr/lib/apache/mod_setenvif.so.orig
# cp mod_setenvif.so /usr/lib/apache/mod_setenvif.so

自分の必要な部分しか実装していないし、 十分なテストはしていなのでバグがあるかも。
分かっている範囲では Directory ディレクティブを使った 多層的な設定にはちゃんと対応していない。

[時事] 地震

午前中に地震が起きて棚から荷物が落ちた。


9/19 (金)

同じ失敗をまた繰り返す…

出張から帰ってきた後にサーバーセットアップの続き
4U サーバーに RedHat Linux AS 2.1 をインストールするのだが、 GbE のネットワークカード Intel/ Express1000 がどうしても通信できない。 さんざん悩んだ末にNIC カードの差し込みが甘かったということに気づく。

昔 同じようなことがあったはずだと デジャブーに襲われて日記を見直してみると、 7/22 の日記の記載が。
二ヶ月前のことだぞ > オレ。


9/18 (木)

[MyWeb] もっと見栄えを

9/8 に CSS を導入して日記のタイトル部分が水色にハイライトしたが、 その中にぽっちりを付けて各日付のアンカーを出そうと試行錯誤する。

もともと日記は日付部分は 以下のように囲ってあったので、

<a name="2003-09-18"><h3><u>9/18 (木) ほげほげ</u></h3></a>

最初は、 CSS を使って <h3><u> タグの先頭に <a href="#2003-09-18"><img src="URL"></a> を 挿入すればいいと思っていたのだが、 CSS や JavaScripot には「いま自分の書かれている場所がデータ構造のどこにあたるのか」を調べる方法がないため、 "2003-09-18" という文字列を取得するすべがないことに気づく。 その上、 文字列を挿入する CSS 機能の content: は とんどのブラウザで未対応だ。

結局、 <a href="#2003-09-18"><img src="URL"></a> 自力で挿入することにする。 以前の日記をぼちぼち対応中。
しかし、 Netscape Navigator 4.78 でスタイルシートを有効してみると ぽっちりの位置と日付の文字列の間に改行が入っているのが奇妙だ。。。

覚え書き

論文の校正が返ってきたので修正をする。
マシンの仕込み 2 日目。


9/17 (水)

サーバーセットアップの履歴

9/9 に来たマシンのセットアップ。

某 1U の IA-32 サーバー

1U の IA-32 サーバーをセットアップ。
Promise Fasttrack IDE RAID Controller を載せたこのマシン。 内蔵している IDE HDD は 1 台だけなのに、 マザーボード上の IDE コントローラの口がないため 嫌でも Fasttrack (ft) の厄介にならざる得ない。 2.4.9 系カーネルがベースの RedHat Linux AS 2.1 は そのままでは ft を認識しないので、 ドライバーのインストール作業で四苦八苦する。

ft で RAID を構成せずにインストールを開始すると、 当然ながら RAID はみえず IDE-HDD は /dev/hde として認識される。 このままインストールは完了させることができるのだが、 ブートを行うと vmlinuz は読み込みカーネルは動作するもの /dev/hde にある /(ルート) がマウントできずに パニックを起こしてしまう。

叱らずんばと ft の BIOS 画面で RAID を構成し Install CD 起動直後に boot: linux noprobe dd と打って インストーラが始まる前に ft のドライバーをいれると /dev/sda と RAID は認識される。 が、物理的には同一の /dev/hde までも一緒に見えてしまっている。

いろいろ調べたところ /dev/hde を認識させないためには Install CD 起動後に

boot: linux noprobe dd ide0=0x1f0,0x3f6,14 ide1=0x170,0x376,15 ide2=0 ide3=0 ide4=0 ide5=0 ide6=0 ide7=0 ide8=0 ide9=0

と入力するらしい。

某 4U の IA-32 サーバー

こっちのサーバーは全面には 6 本の SCSI HDD を取り付けてある。 とりあえず運用時の信頼性はいらないサーバーなので、 システム 1本 + DB データ 5 本に分けて、 5 本は RAID5 1 本はただの SCSI HDD として使おうと考える。
しかし RAID カードは Adaptec の I2O RAID は、 RAID0 を行う場合でも最小 2 本の HDD グループが必要で 1本の HDD で RAID0 を組むことができない。 このあたりはマニュアルの記述と食い違う。 HDD を単体で論理ディスクとしてみせることもできないようなので、 さてどうしたものか?


9/14 (日)

Gigabit Ethernet Switch

昨日は研究室に泊まって荷物の整理をして、 今日は昼前に起き上野のカレー店『デリー』で カシミールカレー(ソース大盛り)を食べてから 秋葉原に向かう。

中央通り沿いの Citi バンクがあった辺りに 『中華福万来』 という中華料理屋ができているのに気づく。 カレーを食べてお腹がいっぱいなので今回はパス。 中央通り沿いは 台湾風(?) 喫茶『Easy Way 喜楽茶』『米沢ラーメン 愛愛』『モスバーガー』『フレッシュネスバーガ』 と食べ物屋の開店ラッシュだ (あと、神田よりには『ペッパーランチ』とピザ屋ができている)。

とりあえず今回の目的は Gigabit Ethernet のスイッチ。 マシンの大量導入により GbE スイッチの口が足らなくなったので ポート数の多いスイッチの価格を調べきた。
8 ポート以下の GbE スイッチは価格破壊が進んでいるようで、 一番安い I/O Data の 8 Port GbE スイッチは 14,800円。 容赦ない価格破壊だ。 インテリジェントなものでも PLANEX の FXG-08TE のように 5 万円台の品が存在する世界なり。
一方、8 ポートを越すと値段は跳ね上がるようで 16 ポートの NETGEAR GS516T は売り値で 12 万円は切らないようだし、 同じく 16 ポートの PLANEX の FXG-16TX でも定価 59,800。 沈思黙考して 8 ポートのスイッチを 3 台買った方がよいと思い付き、 その場を引き上げる。

P.S.

『中華福万来』はもっと前からあったらしい。 気づかなかった…


9/13 (土)

ジャンボマッシュルームを食す

管理人は 前々からジャンボ・マッシュルームに興味を持っていたが、 いかんせん日本では扱い少ない食材のため 近所のスーパーやオンラインショップでは発見できなかった。

思いったって「エンゲル係数を高める会」の会員の hide-m 氏と二人で、 ジャンボマッシュルームを出してくれるという フレンチレストラン『マッシュルーム』に出かける。 名前から分かる通り 『マッシュルーム』(お店のページぐるなび) はキノコがメインのお店。 日比谷線の恵比寿駅を降りて徒歩2〜3分のところにある。 20席程度のこじんまりしたフレンチレストランだ

コースの詳細は別の場所で書いたので置いておくと、 肝心のジャンボマッシュルームは 径 8cm 〜 10 cm ぐらいの大きさのものが パルメザン焼きで出てくる。 初めて食べるジャンボマッシュルームは外側と内側で味が違い、 外はマッシュルーム、内はシイタケといった味だ。 食感も (大きさが大きいためか) ずっしりした肉質で きのこ特有の繊維ぽさがなく不思議な感じだ。

P.S.

今回は結構いい値段のする店で食べたが、 ジャンボマッシュルームは海外では普通に売っているご家庭の食材らしい。 パックで売っている店を探して探して、 色々な調理方法を試し長靴いっぱい食べることにしよう。


9/12 (金)

[Tips] SNMP モニタツールを探して

サーバーの諸元やネットワークを流れるトラフィック量の モニタリングのために SNMP を使おうと調査中。
ネットワーク状況がリアルタイムに表示されてグラフィカルなものは、 Windows には存在するが Linux にはなかなか見つからないようだ。
最近、 Java ベースの SNMP マネージャーソフトがぼちぼち出はじめているので、 そちらを探したほうが早いかも?

  • OpenNMS ... オープンソースのネットワークモニターシステム。 SNMP に限らず JMX や CIM/WBEM にも対応しているようだ。 フロントエンドとして Tomcat を、 バックエンドとして PosgreSQL を使用する。 IBM の developerWorks の 記事 が参考になる。
  • TWSNMPマネージャ ... トゥワイズ・ラボ が公開している フリーの Windows の SNMP マネージャ。 いろいろ使ってみたがこれで十分いけそう。
  • SNMP sniff ... SNMP トランザクションを分析するソフト。 公式ページがロストしている。
  • ntop ... top コマンドのようにネットワークの様々なデータを リアルタイムに可視化してくれるツール。
    SNMP の監視も行えるが、SNMP 以外がメイン。
  • MTRG: The Multi Rounter Traffic Grapher ... SNMP のデータを観測し、それをグラフ化してくれるツール。 SNMP 以外の統計量にも応用可能。 ただし、表示は非リアルタイム。
  • Scotty ... TCL/TK ベースへ SNMP 拡張機能を提供する。
  • JMGMT ... Java で SNMP を扱うためのクラスライブラリ。

その他、参考になるページ。

アイスクリームは食べられない

近場にサーティーワン・アイスクリームを発見。 ストロベリーチーズケーキフレーバーを試食す。


9/11 (木)

[Prog] ビット数を数えるアルゴリズム

(この日記の内容は このページ にまとめました)

PowerPC 系や Alpha などには population count と呼ばれる レジスタ中の立っているビット数を数える命令が実装されている。 集合演算を計算機で実装したい場合などに重宝する命令である。 某所で population count 命令について話をしているうちに ビットカウント操作をハードウェアで実装するのが得なのか?という話題に転じ、 整数データ中の立っているビット数をどうやって数えるかというアルゴリズムの話に発展した。

CPU の設計をできるだけシンプルにするためには、 複雑で使用頻度の低い命令は極力減らした方がよい。 その方向で SPARC は 命令セット中にビットカウント演算があるが、 CPU 内には実装しないという方針をとっている (population 命令を実行すると不正命令例外が発生し、 それを OS がトラップして処理する)。
それはおいておいて、 ビットカウント演算が十分に使用頻度が高い場合に、 CPU がハードウェア処理してペイするかどうか?が問題である。 ビットカウント演算を CPU で実装するなら おそらく整数乗算器を用いるであろう。 そのレイテンシは普通の乗算命令より、 やや小さい程度ですむはずである。 すると CPU にビットカウント命令があれば ソフトウェア処理するよりも高速になりそうに 管理人には思わる。
しかし識者の意見では、 ビットカウント演算は乗算命令以下のコストで ソフトウェア処理することができるので CPU にビルドインしたビットカウント命令は無駄であるとのこと。 実際のコードを見て、かなりショックを受けた。

まず、 整数変数中のビットをカウントするプログラムとしては、 プログラマーなら誰でも 以下のようなプログラムが反射的に考えつくはず。
ただ、 このアルゴリズムは非常に大きな時間コストが掛かる ダメアルゴリズムだ。

バージョン1
int numofbits1(int bits) {
  int num = 0;
  int mask = 1;
  
  for( ; mask != 0 ; mask = mask << 1 ){  
    if( bits & mask )
      num++ ;
  }
  return num;
}

次に考えつくのは、 バージョン2のようなテーブルを用いたやり方だろう。
実際にはあまり大きなテーブルは作成できないので 0 〜 255 までの 8 ビット分のビットカウントテーブルを作成しておいて、 ビットカウントしたデータを 8 ビットづつに区切って 処理することになるだろう。
(ループをまわす回数が一定ならループを展開しても構わないので、 条件分岐は不要となるかもしれない。)

バージョン2
const int BITS_COUNT_TABLE[256] = { /* 予めプリセット */ } ;

int numofbits2(int bits) {
  int num = 0;
  
  for( int i=0 ; i     num += BITS_COUNT_TABLE[ ((unsigned char*)&bits)[i] ]
  }
  return num;
}

第 3 のバージョン。
以下のようなアルゴリズムまでは 自力で考えつくかも知れない。
このアルゴリズムでは 立っているビットが疎な場合には かなり素早く収束する。

バージョン3
int numofbits3(int bits) {
  int num = 0;
  
  for( ; bits != 0 ; bits &= bits - 1 ){  
    num++ ;
  }
  return num;
}

ここからが管理人がショックを受けたアルゴリズム。
バージョン 4 ではループを使用しないでも ビットカウント操作ができてしまっている。

バージョン4
int numofbits4(int bits) {
  int num;

  num = (bits >> 1) & 03333333333;
  num = bits - num - ((num >> 1) & 03333333333);  
  num = ((num + (num >> 3)) & 0707070707) % 077;
  return num;
}

そして最後のバージョン。
このアルゴリズムではループ・条件分岐がないばかりか、 剰余命令まで消失している。 現在のスーパースカラープロセッサでは 演算を畳み込めるので、 CPU にビルトインしたビットカウント命令よりも このアルゴリズムを用いた方が 高速に処理ができると思われる。

バージョン5
int numofbits5(long bits) {
  bits = (bits & 0x55555555) + (bits >> 1 & 0x55555555);
  bits = (bits & 0x33333333) + (bits >> 2 & 0x33333333);
  bits = (bits & 0x0f0f0f0f) + (bits >> 4 & 0x0f0f0f0f);
  bits = (bits & 0x00ff00ff) + (bits >> 8 & 0x00ff00ff);
  return (bits & 0x0000ffff) + (bits >>16 & 0x0000ffff);
}

バージョン5 までのアルゴリズムは 1950 年代にはすでに発見されていたらしい。
ビットを数えるアルゴリズムを知らないようでは計算機屋失格か…

P.S.

結局、今日は徹夜。

追記と訂正:9/18

上記のアルゴリズムはバージョン4 が Knuth の本に、バージョン5 が Henry S. Warren の Hacker's Delight に載っていたもの。

あとバージョン5 までたどり着いたのは 1960 年代だったようだ。 IBM の研究者が IBM Stretch 用のプロセッサのために count populationcount leading zero に関して徹底的な調査を試みた古典的な論文があるそうだ(Count leading zero は、ビット列を MSB から順に読んで最初に1になったビットが現れるまで 0 がいくつ連続して出てくるかを数える操作。LSB から数えるのは count trailing zero)。

当然、count leading zero にも高速アルゴリズムがあるらしいので、悔しいので答を見ずに考えてみることにする。


9/10 (水)

ラックマウントって誰が考えたのか知らないが、もう少しどうにかならなかったのかしら?

昨日、 データセンターに設置する IA-32 サーバーが届いたので、 ラックにマウントする作業を行う。
新規に購入したのは 4U の IA-32 サーバーが 2 台、 1U の IA-32 サーバーが 1 台、 コンソール・キーボード切替器、 引出し式のコンソール(ディスプレイ & キーボード)。

4U のサーバーは 1 台 50kg でこれを取り付けるのは一苦労。 説明書を見てもレールの取り付け方が判然としないので、 レールを仮り付けしては サーバーを取り付ける作業を繰り返す。 腰が痛くなる。
メーカー毎にマウンターやレールの作り方が 違うのはどうにかならないかしら?

今回の拡張で、 前からあったサーバーと合わせて 170kg 程度の装備になる。 一応、 ラックの最大荷重は 550kg だが、 この後 ブレードサーバー擬、 PowerEdge 1600SC、 自家製 PC クラスタを ラック内に格納することを考えたら心許ない。

P.S.
ついでに VMWare4 Desktop のライセンスもきた。


9/8 (月)

ブラウザの映りをもう少しよくしようと

nminoru のページは全体的に素っ気ないが、もう少し見栄えを良くしてみようととりあえず日記のページに CSS を導入してみた。 一応、Netscape 4.x 系や w3m のような CSS に対応していないブラウザでは今まで通り見えているはず。 CSS に対応した Web ブラウザでは、日付け部分が水色の枠で囲まれ、下線と <HR> が見えなくなっているはず。

P.S.

表示の確認のために Netscape Navicator 7.1 をインストール。 だが、すさまじく遅い…

覚え書き

健康診断は健康診断を受けた。


9/7 (日)

TMPGenc Plus 2.5 を購入

メルコの PC-MV5/U2 を購入してからは、TV 放送を MPEG2 エンコーディングで録画して TMPGenc の フリー版 を使って MPEG1 にエンコードしていた。 フリー版の TMPGenc は自前の MPEG2 デコーダを持っていないので、他の DVD プレイヤーのエンコーダーを利用する。 そのせいかどうかは分からないが特定の mpeg2 の特定の位置までデコードが進むと必ずハングアップして処理が帰ってこなくなる問題があった。

製品版の TMPGenc Plus 2.5 は MPEG2 デコーダー内蔵と分かったのでダウンロード版を購入。
Plus では今まで途中で止まっていた mpeg2 ファイルが全部最後までエンコーディング可能に。 エンコード時間も微妙に短くなったような気がする…


9/6 (土)

クレジットカードのポイントを初めて消費してみる

管理人が所有するクレジットカードは、(旧) 富士銀行に口座を開いた時に作ったミズホ UC カードだけである。
このカードも使用金額に応じてポイントがつくようだが、これまでプロバイダーの支払い程度しか使っていなかったためまともにポイントが溜ったことがない。
それでも最近は Amazon.jp で本を買う機会が増え(忙しいので本屋にいく暇さえない)、 516 ポイント溜ったようだ。 そのうち 213 ポイントが 9 月末日までに換金(?) しないと失効してしまうらしいので、プレゼント(?)に交換してみる。

UC カードは アットユーネット というオンラインサービスをやっているようだ。 良く見ればクレジットカードの請求書の閲覧とかができるみたい。 知らんかった。。。
額面の分かる品目についた交換ポイントと比較すると、1 ポイント 5 円のもよう。 とりあえずユニセフの寄付に 300 ポイント、ユネスコの寄付に 200 ポイント入れてお終しまいにする。


9/5 (金)

いろいろアップデートする

自宅のパソコンに導入している Virus Buster のサポート契約の期限が近づいたのでサポートの延長を申し込む。 3,150円 / 年なり。 一種の税金だが、アンチウィルスソフトは使わざる得ないので 2 台分を購入。

ついでに、無線 LAN 付きルーターの AirStation WLAR-L11-L のファームウェアもアップデート。
折りからのネットワークワーム攻撃によって弱点が露呈したのか、ここ数週間はファームウェアのアップデートのペースがずいぶん速かった。 ファームウェアを更新したことで Air Station が再起動しにくくなる現象が改善されたはず。 ここ一ヶ月ほど ADSL ルーターがハングアップしたまま数時間の間通信が断絶してしまう症状が出ていたので、これが改善すると嬉しい。
あと、ファームウェアアップデートで「VPN マルチパススルー」機能が使えるようになっていた。 プライベートネットワークの内側のマシンが、外側にある VPN サーバーに VPN 通信を行おうとする場合、内→外は NAT で通信できるが、外→内のために特定のポートをフォワーディングしてやる必要があった。 VPN マルチパススルーはフォワーディングを自動化してくれるようだ。
対応している VPN は PPTP と IPsec の一部のみ。 NORTEL の Contivity VPN Client が使えるといいのだが。。。

ついでに Canopus の MPEG Craft が アップデートした模様。
ただしアップデートファイルのダウンロードにはユーザー登録が必要な模様。 Windows98 では動作しないので、出てすぐ(7/12) 購入したけど使っていない。 どうしよう?


9/3 (水)

本日も出張

毎度の新横浜から三島まで新幹線で往復する出張。

ここ1ヶ月は毎週出張が入っていて、 出張の前日は徹夜になってしまうので ボロボロである。


9/2 (火)

[Prog] 私の知らない Perl の仕様

相変わらず「極めた」というのが難しい Perl 言語。
5/26 以降、また言語仕様だか実装依存だか分からない機能に遭遇。
確認は Linux 版の Perl v5.6.1 で。

Perl は、変数名をあらわすプレフィックス($@%) や 文字列をあらわす括弧(''""q{}qq{}qw{}) のないシンボルは、 ラベルかファイルハンドラかサブルーチン名だと思っていたが、 場所によっては文字列として解釈されることがある。
例えば、 $map{KEY}=VALUE; という表現は $map{'KEY'}='VALUE'; と等価な模様。

ただし、これも use strict を導入すると変わるようだ。

use strict;
use vars qw{ %map };

$map{KEY} = VALUE;   # 許されない
$map{KEY} = 'VALUE'; # 許される

P.S.
後から調べてみると、 {bar} # with bar のような文法があるようなので {KEY}{'KEY'} が等価なのはいいが、 VALUE を文字列と見なすのは抵抗がある。

追記:9/17
というか $map{KEY} の用法は、 ラクダ本の中に普通に載っていたよ。。。

備忘録

  • $value =~ s/ pattern / expression /eg を使うと、 $value 中の pattern にマッチする箇所を全てを、 expression を評価した値とで置換する。 expression 中でマッチしたい 文字列を引きたい場合には $& を使えばよい。
  • $#days は配列の最後のインデックスを返す表現。
  • local変数と my 変数の違いは、 local 変数は動的スコープを持ち my 変数はレキシカルスコープを持つ点。
    local $a = 1;
    my    $b = 2;

    subroutine();

    sub subroutine {
      print "\$a = $a\n";
      print "\$b = $b\n";
    }
    実行結果
    $a = 1
    $b = 0


9/1 (月)

[Linux][Tips] Linux に関するメモ

今月もいきなり備忘録から。

ネットワーク転送速度に関する Tips
Linux マシンでネットワーク転送速度を計測するには、 以下の方法を組み合わせて行う。
  • NIC が 10/100/1000 M bps のどのモードで動いているかは カーネルで動作するドライバーのパラメータで、 /proc には出力されていない。 この情報を読み出したい場合には、 gkernel プロジェクトの一部である ethtool を使うことになる。
    ただし、 このツールは読み出すことのできるネットワークカードが限定されていて、 対応していない NIC もある。

  • 隣接する 2 つの Linux ノードのネットワークに最大の負荷を掛けるには rcp コマンドを用いるのがベスト。 この方法だと HDD に影響を与えず CPU 負荷も比較的小さい。
    # rsh remote-host cat /dev/zero > /dev/null
    
  • Linux のデータ転送量は /proc/net/dev により知ることができる。 /proc/net/dev には 送信・受信したデータをバイト数・パケット数等がカウントされているので、 定期的に open して値を読み出せば観測可能。
    ただしこの値は符号なし 32 ビット値でオーバーフローを起こすと 0 にリセットされる。 最短の場合、 100BASE-TX だと 6 分強で、1000BASE-T だと 35 秒弱で 一周すること意識する必要がある。

    root-NFS マウントの問題
    pxelinux を使った root-NFS マウントでは /dev 以下の特殊ファイルが 障害となることに気づく。
    例えば syslog は ホスト内での syslog メッセージの受渡しを /dev/log という名前付きパイプ(FIFO) を利用して行っている。 /dev/log が NFS 上にある場合、 前のホストが開いた /dev/log を 後のホストが再度開こうとすると、 前のホストの名前付きパイプ通信が壊れてしまい、 以降 syslog が使えなくなってしまう。

    この問題を回避するには、
    1. /(root) と周辺ディレクトリは ramdisk 上に作成し、 /usr/opt/home などだけ NFS で共有する。
    2. 名前付きパイプが NFS で問題なく使えるように NFS サーバー / NFS マウントを 修正する。
    3. root-NFS する場合でも、/dev は ramdisk などを使ってローカルに展開する。
    とりあえず initrd と linuxrc を用いて 3. の方針で行く予定。

    追記:9/7
    3. の方針を行うためには /sbin/portmap/bin/mount を initrd に入れる必要があるのだが、これが結構面倒なことが分かった。 ld-linux.so、libc.so などの shared library を要求してくる コマンドがある場合、 これらも一緒に initrd にいれてやる必要があるようだ。
    initrd は忘れて、 root-NFS で起動して syslogd が動き出す前に ramdisk に展開した /dev を 上書きマウントしてやったところうまくいった。 具体的には rc.sysinit 中で ramdisk を作成し適当なディレクトリにマウント、 /dev の内容を ramdisk に展開。 ramdisk をアンマウントした後、 /dev にマウントし直す。

    SNMP
    Linux 側に SNMP マネージャー兼エージェントの NET-SNMP、 統計・グラフ化ソフトの MRTG をインストール。

  • 先月の日記(2003年08月) 今月の日記(2003年09月)
    2002 | 10 | 11 | 12
    2003 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2004 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2005 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2006 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2007 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2008 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2009 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2010 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2011 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2012 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2013 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2014 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2015 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2016 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2017 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2018 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2019 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2020 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2021 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2022 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2023 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12
    2024 | 1 | 2 | 3 | 4
    ホームページ | 最新のコメント50
    インデックス: 食べ歩き | Java | プログラム | UNIX | 画像
    最新の日記へのリンク | この日記ページをはてなアンテナに追加 この日記ページをはてなブックマークに追加
    はてな ダイアリー アンテナ ブックマーク ブログ
    Twitter | mixi | Facebook | slideshare | github | Qiita


    Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp