かけまわる子犬。

最近の tacacs+ は x86_64 対応ってのが(あんまり)無いのねぇ。その昔の tacacs+ のコードってのは x86 向けなので x86_64 上でコンパイルすると、随分色々なソースのコードを書き換えなければならない。

幸いにして FreeBSD には ports で net/tac_plus-libradius ってのがあるのですが、こいつは tac_plus.F5.0.0.alpha.tar.gz と言うソースコードを使っていて、このバージョンのソースコードは色々問題もあるんだけど、radius・LDAP、そして MySQL に対応している。なおかつ、FreeBSD/amc64 でも make が通るので非常に嬉しいのであります;-)。

書き出しの「x86_64 対応ってのが(あんまり)無いのねぇ。」ってのは外部のツールを使って管理する tacacs+ のソースコード。って意味です;-)。

net/tac_plus-libradius な tacacs+ は radius サーバと連携するように特化されているみたいなので、MySQL サーバに接続できる版の ports を作ってみました。以下の URL に転がしておきます。

http://www.icmpv6.org/Prog/FreeBSD_ports/ports-tac_plus-mysql-20100311.tgz

make install ができて、デーモンが起動したことは確認していますが、激しく使い込んではいないのでもしかしたら何かあるかもしれません。その場合はソースコードを見直してください(^^;;。

後、上にも書きましたが、そもそも元祖となる tacacs+ のコードは x86_64 に対応してないので随分と改修が必要です。Linux で make する時は随分苦労するでしょうねぇ。と、言うことで Linux 版のパッチも書いておきました。

http://www.icmpv6.org/Prog/Linux_x86_64-tac_plus.F5.0.0.alpha.patch.bz2

Centos5.4 ですけど、こちらも一応 make は通るようにて、起動までは確認しました。 Linux の x86_64 で tacacs+ と MySQL を連携したシステムを構築してみたい方、試してみてください。色々動かない場合はソースコードを見直して頂ければと思います(^^;;。

あ。見直して更新したソースコードは是非頂けると嬉しいです。宜しくお願いしますf(^^;;。

まさか三回目を書くとは思いもしませんでした・・。apache ベースで作成したキャッシュ用 Proxy サーバですが、設定に問題があり無事に動作していたのは約一ヶ月半ほど・・。あまりにも情けないので、ちょっと書いておくことにします。

今回は第一回目のネタを参照する 必要があります。第二回目の掲載はこちら。

さて、二回目にまとめたことで apache の Proxy サーバは mod_cache を利用してディスク上にキャッシュして行くことができたのだけど、運用してしばらくしたら error.log に以下のメッセージが出力されるようになってきた。しかも大量に・・。orz (長いので改行しています)

[warn] (2)No such file or directory: disk_cache: 
    rename tempfile to hdrsfile failed: 
    /data/httpd/cache/aptmp6ac9NS -> /data/httpd/cache/ASm@m/8xF@v/7XxKH/X8yCPfQ.header

よくよく調べてみると、サブディレクトリがもう作れない状態になっているらしい。なので、これ以上はディクス上にデータをキャッシュをできない状態になっている。と言うメッセージが延々と error.log に出力されている状態。

/data/httpd/cache の下にディレクトリが 32,000 個できている。と言う状態なんですねー。Linux では一つのディレクトリの下には 32,000 個しかディレクトリが作れないそうです。 /usr/include/linux/ext3_fs.h の以下の行がまさしくそれ。

#define EXT3_LINK_MAX           32000

でもって 32,000 個のサブディレクトリのあるディレクトリで mkdir すると Too many links. mkdir: cannot create directorys と言われて怒られる。うひー。

と、言うことで、僕はこの上限 32,000 と言う値を知らなかったのでありました。

愕然としつつ httpd.conf の設定を見直します。第一回目に書いた設定では以下のように記述していました。抜粋です。

<IfModule mod_disk_cache.c>
    :
    CacheDirLevels          3
    CacheDirLength          5
</IfModule>

ディレクトリの深さは三階層、ディレクトリの文字列は五文字。この「五文字」と言うのは簡単に 32,000 を超えてしまうのですね。

ディレクトリにランダムに利用される文字は A-Z,a-z,0-9 と一部の特殊文字で約 80 個位と想定した場合、五文字と言うのは 80^5 通りあるので、こらー簡単に 32,000 個を超えてしまいます。 32,000 個以内に抑えるのは CacheDirLength は 2 を指定しなければならない。3 を指定したとしても 80*80*80=512,000 個のディレクトリが作成されることになります。あれー・・。

/data/httpd/cache の下には 80*80=6,400 個にしてその下の階層を深くしたほうが良いと言うことなんですねぇ・・。

ディレクトリを自動生成してくれるアプリケーションの場合、ディレクトリ長は二文字にしないと簡単に 32,000 個があふれてしまう。今後はこれを頭の片隅に入れておきたいと思います。

HP の 1U サーバで ProLiant DL320 G5p と言うのが、今、手元に四台あるのだけど、こいつには現在、以下の OS がインストールされている。

・FreeBSD/amd64 6.4-RELEASE-p3
・FreeBSD/amd64 7.0-RELEASE-p9
・CentOS release 5.2 x86_64(後にバージョンアップして CentOS release 5.3 x86_64)
・Windows Server2003 EPE

でもって、このサーバの FreeBSD で見た場合のスペックはこんな感じ。

CPU: Intel(R) Xeon(R) CPU            3075  @ 2.66GHz (2660.01-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x6fb  Stepping = 11
  Features=0xbfebfbff
  Features2=0xe3fd
  AMD Features=0x20000800
  AMD Features2=0x1
  Cores per package: 2
usable memory = 2132668416 (2033 MB)
avail memory  = 2058006528 (1962 MB)
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP): APIC ID:  1

今回は CPU のお話です。

今まで僕個人的には、これらのサーバ群は FreeBSD で利用していたので特には気にしていなかったことがあります。それは CPU クロック。FreeBSD の場合 powerd を動作させるといとも簡単に SpeedStep(正確には EIST・Enhanced Intel SpeedStep Technologyですね) が動き出すので sysctl で後は見るだけ。って感じだった。

FreeBSD で見た CPU クロック、今はこんな感じ。

dev.cpu.0.freq: 330
dev.cpu.0.freq_levels: 2647/-1 2316/-1 1985/-1 1654/-1 1323/-1 992/-1 661/-1 330/-1

でもって CeotOS でも SpeedStep 動かないかなぁ？とか思い格闘したのだけど、ダメみたいねぇ。
CeotOS 5.2 ではダメで 5.3 なら OK よ。ってのをみつけて yum upgrade して試したのだけど・・。

# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/drivers/cpufreq/cpufreq_conservative.ko
# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/drivers/cpufreq/cpufreq_ondemand.ko
# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/drivers/cpufreq/cpufreq_powersave.ko
# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/drivers/cpufreq/cpufreq_stats.ko
# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/drivers/cpufreq/freq_table.ko
# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/arch/x86_64/kernel/cpufreq/acpi-cpufreq.ko
# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/arch/x86_64/kernel/cpufreq/powernow-k8.ko
# modprobe /lib/modules/2.6.18-128.1.10.el5/kernel/arch/x86_64/kernel/cpufreq/speedstep-centrino.ko

関連しそうな全てのモジュールをロードしてみたけど FATAL: Module hoge not found. だそうです・・。Linux のこの辺りのこと、僕はあんまり良く解らないのだけどもね。

でもって cpufreq-selector と言うのは無いので cpufreq-info と言うのを実行してみたら以下の通り。

# cpufreq-info
cpufrequtils 005: cpufreq-info (C) Dominik Brodowski 2004-2006
Report errors and bugs to cpufreq@vger.kernel.org, please.
analyzing CPU 0:
  no or unknown cpufreq driver is active on this CPU
analyzing CPU 1:
  no or unknown cpufreq driver is active on this CPU

なんか「Xeon には対応してねーんじゃねぇの？」とか思えて来た段階で Linux についてはしゅーりょー。だって動かないんだもの。ちなみにカーネルは 2.6.18-128.1.10.el5 の x86_64 です。CeontOS release 5.3。

続いて Windows Server2003 EPE エディション行ってみましょう。どうすれば WindowsServer で SpeedStep が有効になるんだ？とか思ったのですが、考えてみると、僕は普段から FreeBSD と AMD のプロセッサしか使ってないので Intel の Xeon なんざ今まで気にしたことも無かった。

で、ググってみたら以下の URL を発見。

http://www.intel.com/cd/channel/reseller/asmo-na/eng/203838.htm

コントロールパネルの電源管理で「ポータブル/ラップトップ」を選択すると SpeedStep が有効になるのかと思いきや全然ダメ。BIOS の設定を見ても EIST の設定なんざありゃしない。困りはてて HP のサポートに電話して聞いたら、ドキュメント番号 232907191 の P.21 を参照してみてくれ。とのことでこのドキュメントを探そうとしたけど、全然みつかんないじゃーん。と、言うことでこれまたしゅーりょー。

ちなみに Windows Server2003 EPE 上で CPU-Z を起動したキャプチャをアップしておきます。

Core Speed って所が 0.3MHz 程度なら変動するんですが、大きく、上記の FreeBSD のようには可変にはなりません。でもって大体 2GHz のちょっと下辺りでふらついている。って感じでしょうか。

あ、あれーー？？ DL320G5p って Xeon 3075 で MAX が 2.66GHz の CPU なんだけどっ!! それが 2GHz も出ていないってどーいうことーーっ!!??

さてと。そろそろ結論フェーズに持っていくことにしましょう。

CeontOS も Windows Server2003 も本当に地球環境に優しくない OS ですねぇ。FreeBSD なら OS をインストールして再起動した直後(正確には powerd を起動した直後だけど;-)から CPU 速度は抑えられて運用が始まるのになぁ。そして、何も設定せずに CPU クロックが下げられる。けど、どうして FreeBSD だけかまともに動作するんだ？ OS がちゃんとしていると言うことか？ Linux は NotePC メインに考えていて サーバの SpeedStep にまでまだ手が回ってないとか？(まぁ "Linux" って言ってしまうと範囲が広すぎるので "SentOS" って書いたほうが良いかな。この場合。)

あー。後、今回はワットチェッカーとか科学的な根拠に基づいては書いていません。ただ単におのおのの OS 上で動作したプログラムが示した値を基準にしています。が・・。そー考えると Linux はカーネルモジュール自体がロードできなかったので値は取れていない状態だなぁ・・。