2011/12/30(金)配布元の munin 1.4.6 は、FreeBSD8.x のLANトラフィック監視にはそのまま使えない
2017/10/12 4:46
ところが、パッチをいろいろ入れていたのを忘れていて、更新だけしてしまったものだから、嵌ってしまったのです・・・orz しかも、まる２日間。。
具体的には、LAN カードのトラフィック計測が全く駄目。
具体的には以下 ↓
この計測を行うプラグインは、 [MUNINBASE]/lib/plugins ディレクトリの中の if_ というスクリプトです。
どうやら、スクリプト内で netstat コマンドを実行して、送信バイト数、受信バイト数を、sed で切り出している仕組みのようです。
手動で netstat コマンドを実行してみて、スクリプトが意図している内容と、実際の netstat コマンドの出力が異なることが分かりました。
具体的には、
72行目：
rsum += $7; osum += $10;
→ rsum += $8; osum += $11;
87行目と88行目：
print "rbytes.value", $7;
print "obytes.value", $10;
→ print "rbytes.value", $8;
print "obytes.value", $11;
のように修正すると、機能するようになります。
修正後はこんな感じ ↓
＃年末・年始でアクセスが少なく静かです :-)
ここまでやって気づいたのですが、FreeBSD の Ports に munin が収録されているようで、Portsでは、この類のパッチが当てられているのかどうか気になったので確認してみました。、
うーーむ。既に対応されとる。最初からこっち見てれば早かったなorz
こんな感じです：
--- plugins/node.d.freebsd/if_.in.orig 2009-12-30 13:55:55.000000000 +0100
+++ plugins/node.d.freebsd/if_.in 2010-02-24 18:59:15.670282185 +0100
@@ -81,9 +81,12 @@
if (NF == 10) ｛
print "rbytes.value", $6;
print "obytes.value", $9;
- ｝ else ｛
+ ｝ else if (NF == 11) ｛
print "rbytes.value", $7;
print "obytes.value", $10;
+ ｝ else ｛
+ print "rbytes.value", $8;
+ print "obytes.value", $11;
｝
｝'
fi
＃表示が崩れるので、中括弧は全角文字にしています。実際は半角文字の中括弧です。
--- plugins/node.d.freebsd/if_errcoll_.in.orig 2009-12-30 13:55:55.000000000 +0100
+++ plugins/node.d.freebsd/if_errcoll_.in 2010-02-24 19:00:26.026407278 +0100
@@ -59,9 +59,13 @@
print "ierrors.value", $5;
print "oerrors.value", $8;
print "collisions.value", $10;
- ｝ else ｛
+ ｝ else if (NF == 11) ｛
print "ierrors.value", $6;
print "oerrors.value", $9;
print "collisions.value", $11;
+ ｝ else ｛
+ print "ierrors.value", $6;
+ print "oerrors.value", $10;
+ print "collisions.value", $12;
｝
｝}'
＃表示が崩れるので、中括弧は全角文字にしています。実際は半角文字の中括弧です。
他にも、幾つかのプラグインにて FreeBSD用のパッチがあるようです。
2011/12/22(木)CPUの消費電力低減法
2017/10/12 4:45
これは、負荷が少ない時にＣＰＵクロックを自動調整で下げ、性能を可能な限り維持しつつＣＰＵの消費電力を下げるものです。
設定は簡単です：
/etc/rc.conf に
powerd_enable="YES"
を追加するだけです。設定後は、再起動が一番手っ取り早いでしょう。
ＣＰＵのクロックは、お使いのマシンにて、
% sysctl -a dev.cpu.0.freq
とすると、MHz 単位で表示できます。
ちなみに弊社サーバの３台に対して導入すると・・・
2600 → 150 (約17分の１)
2400 → 1000 (約５分の２）
900 → 450 (ちょうど半分)
のようになりました。常にこうなるわけではありませんが :-)
現在のＣＰＵは C-MOS 構成なので、消費電力は周波数に正比例します。
ほぼ、ＣＰＵはこの割合で消費電力低減になるはずです。
毎月の電力使用量にどう反映するか様子を見たいと思います。
2011/11/28(月)ProFTPD 1.3.4 以降の mod_ldap 関連設定
2017/10/12 4:42
サーバ側の /var/log/messages に以下のメッセージが残っていました：
proftpd[10975]: Fatal: unknown configuration directive 'LDAPDNInfo'
on line 35 of '/usr/local/etc/proftpd.conf'
最初はバグか？と思っていたのですが、つたない英文読解能力で google 先生の情報を漁ってみると・・ディレクティブが一部変わっている模様・・orz
日本語の情報が見当たらないので、今回遭遇した変更点をまとめてみました。
以下のように変更しないと LDAPを利用したユーザ認証が機能しません。
＜変更前＞
LDAPDNInfo 〔管理者DN〕 〔管理者パスワード〕
LDAPDoAuth on "dc=user,dc=account,dc=isp" "(&(uid=%v)(status=valid))"
LDAPDoUIDLookups on "dc=user,dc=account,dc=isp" "(&(uidNumber=%v)(status=valid))"
LDAPDoGIDLookups on "dc=group,dc=account,dc=isp" "(&(gidNumber=%v)(status=valid))"
＜変更後＞
LDAPBindDN 〔管理者DN〕 〔管理者パスワード〕
LDAPUsers "dc=user,dc=account,dc=isp" "(&(uid=%v)(status=valid))"
LDAPGroups "dc=group,dc=account,dc=isp" "(&(gidNumber=%v)(status=valid))"
・LDAPDNInfo → LDAPBindDN
・LDAPDoAuth → LDAPUsers
・LDAPDoUIDLookups → 削除
・LDAPDoGIDLookups → LDAPGroups
書式もちょっと変わったようなので、よく見て比較してみてください。
また、ここに記載されている内容は、弊社独自のものなので、各自の環境に合わせて適宜変更してください。そのままコピーしても無駄です。
また、ここに出てこないディレクティブは変更不要のようです。
当たり前の話ですが、意味を理解してから使いましょう。
2011/11/22(火)Apache 2.0 はサポート終了？
2017/10/12 4:41
昨年２月に Apache 1.3 系がサポート終了していますが、今後は Apache 2.0系も、サポート体制に注意する必要があります。
サポート終了のものをそのまま使い続けると、セキュリティ問題関連や、サーバ障害の際に対応ができない場合があります。
弊社サーバは既に全て Apache 2.2系へ移行済みです。
来年には Apache 2.4 が登場し、移行時期を模索することになります。
2011/09/03(土)SSL 証明書要求の際の 2048bit長キーの生成方法
2017/10/12 4:35
パスフレーズなしの秘密鍵（通常はこちら）
openssl genrsa -out www.example.com.key 2048
パスフレーズありの秘密鍵（専用サーバの場合）
openssl genrsa -des3 -out www.example.com.key 2048
トリプルDESでパスフレーズ設定。
途上で、設定したいパスフレーズを２回設問されるので、２回とも設定したいパスフレーズを入力。このとき、パスフレーズは２回とも同じものを入力しましょう。
忘れるとお手上げです。
あとはＣＳＲ（証明書要求）を作成。
openssl req -new -key www.example.com.key -out www.example.com.csr
設問に従って入力。
特に common name のところは間違わないように。
パスフレーズを設定した場合は、ここでパスフレーズの入力を求められます。
2011/09/01(木)SSL サーバ証明書の怪
2017/10/12 4:34
更新自体は先ほど終えましたが、何回か Apache が起動できなくて悩みました。
どこにもエラーメッセージが出ません。
が、なんと、原因はサーバ証明書の書式。
ご存知の方も多いと思いますが、サーバ証明書は暗号化されており、実態はテキストファイルです。そして、そのテキストファイルは
-----BEGIN CERTIFICATE-----
の行で始まり、
-----END CERTIFICATE-----
の行で終わります。
コピー＆ペーストのミスで、最後の行が
-----END CERTIFICATE----
になっていただけで、 Apache が起動しません。
よーぅく見れば判りますが、最後のハイフン '-' が１個足りないだけなのです。
「サーバ証明書入れたら Apacheが起動しない」
と言う場合、証明書のフォーマットも疑って見るべきのようです。
2011/07/30(土)FreeBSD 9.0R のリリース作業開始
2017/10/12 4:33
9.0R の目玉となりそうなものは、
＊ OpenSSH に HPNサポート導入 ― SSL/SSH の転送速度が最大10倍くらいになる。
＊ Capsicum を導入 ― 本当に「唐辛子」を組みこむわけではありません。新たなセキュリティ機構の名称で、プログラムモジュール単位で細かなアクセス制御ができるようになるらしいです。
あと、
＊ BIND をベースシステムから外すか否かの検討 ― 今のところは実施保留
という話もあるようです。
予定通りに進んだことは一度も無いですが、一応、予定は組まれています。
http://www.freebsd.org/releases/9.0R/schedule.html
また、インストーラーが変わるようです。
名称も今までの sysinstall から bsdinstall に変わります。
画面などが変わるらしい上に、従来どおり日本語はサポートされない／日本語対応が間に合わないため、リリース後に時間とれれば、弊社サイトか、このブログで紹介したいと考えています。
2011/07/06(水)ルータの修理
2017/10/12 4:32
先日、筐体の一部が素手で触れないほど熱くなっており、
様子を見てみると、１台は３つある冷却ファン全てが逝っており、もう一台は３つある冷却ファンのうち、２つが逝っていて、もうひとつは逝くのが時間の問題であるのが確認できました。
このままでは、熱故障してしまう。
急遽、予備のスイッチングHUB をセットアップし、通信サービスを維持しつつ、調査開始。
ここにはお見せできないくらい、酷い綿ゴミの山（約１０年分 orz）が築かれておりましたが、掃除機で吸い取った状態が以下：
コンデンサ膨張もなく、問題ありません。
さすがに連続稼動を意図した設計になっているみたい。
電源部も問題なさそうで、よくあの灼熱状態で動作していたなぁと。
早速、交換用ファンを調達し、修理・復旧しました。
冷却ファンは、大きさ 40mm で統一されていましたが、5V が １つ、12V ものが 2つ。
12V ものは ATXパソコン用のものが使えます。これは比較的入手容易。
5V ものはやや特殊で、価格も高め。電子部品を扱っている販売店でないと入手困難です。
復旧後は生温かい感じになっています。
2011/07/01(金)perl 5.14.0 以降のバージョン + PostgreSQL 9.0.4 以前のバージョンにおける構築
2017/10/12 4:31
perl サポートを組み込むのであれば、再構築する必要があります。
また、perl 5.14.0 以降のバージョンと postgreSQL 9.0.4 までのバージョンの組み合わせでは、plperl の構築でコンパイルエラーになります。
postgreSQL 側のソースコードを以下の様に修正すると良いようです。
※該当行番号は、PostgreSQL のバージョンによって異なります。
修正後、再度コンパイルすることで解決します。
PostgreSQL 9.0.5 で解決されることが期待されます。
2011/06/25(土)/usr/local/lib/libldap.so: undefined reference to `fetchGetURL'
2017/10/12 4:29
openLDAP サポートを必要とする他のアプリケーションを構築しようとすると、
/usr/local/lib/libldap.so: undefined reference to `fetchGetURL'
のようなリンクエラーが出て構築できないという状況になる場合があります。
日本語での情報が全く無いため、記録しておきます。
google のお世話になりました。英語が苦手なのでちと苦労を。。（爆）
これは、openLDAP 2.4.24 以降の新しいバージョンで fetch(3) ライブラリをデフォルトで組み込まなくなったことによります。
FreeBSD の場合は、fetch(3) ライブラリはＯＳ標準で用意されています。
OpenLDAP 2.4.23 以前と同じ挙動にするためには、openLDAP 2.4 コンパイルの configure 時に、
--with-fetch
をconfigure オプションに追加します。
しかし、FreeBSD の場合、これだけでは駄目なのです。
コンパイル、インストールは何の問題もなくされるのですが、なんと、configure スクリプト自身にバグが潜んでいます。
以下のパッチを当てる必要があります：
@@ -22234,7 +22234,7 @@
if test $ol_cv_lib_fetch != no ; then
- LUTIL_LIBS="$LUTIL_LIBS $ol_link_fetch"
+ LIBS="$LIBS $ol_link_fetch"
> ol_link_fetch=freebsd
elif test $ol_with_fetch != auto ; then
上記の修正後、--with-fetch オプションを追加した状態にて、いつもどおり configure から openLDAP 2.4 を構築することで解決します。
(追記 2011/07/14)
OpenLDAP 2.4.26 に於いて、このバグは解消されているようです。