2008/12/30(火)サーバやネットワークトラフィックの管理ツール― Munin 【後編】

2017/10/11 7:42 サーバ運営・管理
Munin には、インストールされた機器自身の構成をチェックし、ある程度の情報が最初から取得できるようにすることができます。

root で以下のコマンドを実行します。
# /usr/local/munin/sbin/munin-node-configure --shell | sh

そうすると、/usr/local/etc/munin/plugins 配下にシンボリックリンクの形で取得できそうな情報がプラグインの形で設定されます。

次に /usr/local/etc/munin/munin-node.conf を編集。
変更箇所は、

user munin
group munin
allow ^127\.0\.0\.1$
allow ^172\.16\.1\.20$
← 他ホストで情報収集する場合、そのホストのIPアドレスを追加。

この程度で良いはず。
その次に /usr/local/etc/munin/munin.conf を編集。
変更箇所は、

dbdir /db/munin
htmldir /home/webroot/hankakusai.basekernel.co.jp/htdocs/munin
logdir /var/log/munin
rundir /var/run/munin

[hankakusai.basekernel.co.jp]
address 127.0.0.1
use_node_name yes


こんな感じです。
情報取得対象ホストがそれ自身の場合は、 address に 127.0.0.1 を指定します。そうでない場合は、該当ホストの IP アドレスを指定します。そのとき、対象ホスト上で munin を稼動させ、munin-node.conf の allow ディレクティブにて、アクセス許可しておく必要があります。

dbdir は、取得情報を保存するディレクトリ
htmldir は、生成する html ファイルを保存するディレクトリ
(このディレクトリは外部からWebブラウザで閲覧できる位置にする必要あり)
logdir は、munin の動作ログ格納ディレクトリ
rundir は、pid などを格納するディレクトリ

で、全て UID munin で書き込みできるようにディレクトリパーミッションを設定しておく必要があります。

最後に crontab -u munin -e で、
*/5 * * * * /usr/local/munin/bin/munin-cron
として、5分毎に実行するようにして、設定完了です。
5分ごとにグラフが描画され、更新しているのが確認できれば、正常稼動できています。

ということで、20台ほどのサーバを munin で集中管理する環境が構築できました。

2008/12/13(土)サーバやネットワークトラフィックの管理ツール― Munin 【前編】

2017/10/11 7:44 サーバ運営・管理
数ヶ月前、この手のツールに Zabbix を導入したのですが、想像をはるかに超える勢いで取得情報のデータベースが肥大化し、貧弱な設備では半年も持たないことが判明した(爆)ので、急遽管理ツールの変更を迫られたのでした。
一度、採用候補にしていたのですが、日本語の情報が少ないので、Zabbix導入の際、ボツにしたこの Munin を何とかインストールしたのです。
メモリ状況 Munin は、「ムーニン」と言うのでしょうか? どうしても「ムーミン」と読んでしまうのは、自分だけでは無い と思うのだが、、
左記のような感じで、いろいろな情報を表示できるようです。

Munin は、perl スクリプトの集合体です。
入手場所はこちら → [トップページ] [ダウンロード]
ダウンロードの際は、最初は stable版で。




インストールの際は、予め以下のものが必要です。
・RRDTool 1.2.x
・Net::SNMP (Perl モジュール)
・Net::Server(perl モジュール)
・Crypt::DES(perl モジュール/ Net::SNMP が依存)
・Digest::HMAC(perl モジュール/ Net::SNMP が依存)
・Digest::SHA1(perl モジュール/ Net::SNMP が依存)
・HTML::Template(perl モジュール)

インストールの際は、更にいくつか前作業が必要。
・ユーザ名 munin, グループ名 munin を作成。UID,GID は 4949 あたりで良い。
・tar.gz ファイルを解凍し、作成されたディレクトリの中の Makefiie.config をインストールしたい対象マシンに合わせて編集。
・環境変数 PATH の中に './' (カレントパス) が入っていたら、削除したものを再設定しておく。
 カレントディレクトリが環境変数 PATH に入っていると、perl の環境汚染チェック(-T スイッチ) に引っかかり、動作に支障が出る。← これに填まりました。。

準備が出来たら、
gmake install-main
gmake install-node install-node-plugins

で本体をインストール。

インストール自体はこれで完了ですが、利用できるようにするためには、更に設定が必要。

2008/11/29(土)FreeBSD 6.4R リリース

2017/10/11 7:48 サーバ運営・管理
日付は昨日になると思われます。
6.x系はあと1~2回リリースあると思います。(一応、6.x 系最後とされてはいる)
6.3R → 6.4R の主な変更点は、リリース案内によると以下のような感じです:

- 新しくて大きく改良されたNFS Lockマネージャ(NLM)クライアント
- Camellia暗号サポート
- ブートローダの変更。USBとGPTによってラベルされ、BIOSにて有効になっている場合、それらのデバイスからのブートを可能にします。
#ちょっと意味解らない部分が...orz

- amd64/i386のための DVD用インストールISOイメージが利用可能です。
- KDE を 3.5.10にアップデート。 GNOME を 2.22.3 にアップデートしました。
- BIND、sendmail、OpenPAM、など色々アップデート

ウチは既にメインが 7.x系なので、直接関係ない情報ですが、6.xR をご利用のユーザはOSアップデートをしましょう。

2008/11/25(火)ProFTPD 1.3.1 LDAP サポート構築時の注意点

2017/10/11 7:50 サーバ運営・管理
確認したのは、FreeBSD 7.0 amd64 環境に OpenLDAP 2.3.41 を別サーバに用いる環境です。

現在、ProFTPD のStable バーションは 1.3.1 ですが、これに同梱されている LDAP サポートは localhost 以外だと、LDAP 認証する時点でSegmentation halt(Signal 11) でプロセスごとダウンします。

これは、同梱の mod_ldap.c に問題があり、最新版にすることで対処可能です。
最新版の mod_ldap.c は http://horde.net/~jwm/software/mod_ldap から取得できます。
上記サイトの下のほうに、現在の最新版 mod_ldap 2.8.19 のダウンロードリンクがあるのでそこから取得します。

取得した mod_ldap.c を ソースコードツリーの contrib ディレクトリ配下へ上書きコピーし、通常どおりコンパイル・インストールします。

2008/05/11(日)PostgreSQL-32bit CPU環境から 64bit CPU環境への移行

2017/10/11 8:13 サーバ運営・管理
先月は、ライフサイクルの寿命に起因する、ハードウェアトラブルが複数発生し、1つのサーバを Athron から amd64 環境へ移行しました。
amd64 環境へ移行したサーバは、まる4年稼動。もう1台は約10年稼動していました。
蛇足ですが、昔のハードウェアの方が発熱量も消費電力も少なく、長持ちします。

FreeBSD の場合、amd64 環境でも 32bit アプリケーションは一応動作するものもありますが、基本的には再構築した方が無難に決まっています。
PostgreSQL は、本体バイナリは 32bit ものでも lib32 互換ライブラリのお陰で動作するようですが、やはり起動しません。
「checksum error」

これが出てしまって起動しません。
データベース自体がクラッシュしていると、この表示になりますが、32bit環境で構築したデータベースをそのまま 64bit 環境で動作させようとしてもこの表示が出て使えないです。
いくつか検索してみると、同じようなことで、填まっている管理者が結構多いようです。

いったん、32bit 環境にて SQL 形式でdb_dump を行ってから、64bit 環境構築後にリストアする形を取るのが最も確実な手段と言えます。

2008/03/30(日)「LAMP環境が一般的」と思い込む日本人偽技術者

2017/10/11 8:16 サーバ運営・管理
「一般的」というなら、むしろ Windows だろうという突っ込みが予想されるが、これはサーバ環境での話し。
西欧、特に米国あたりでは「LAMP環境」が一番普及しており、それ以外は商用ベースにならないかのような扱いに言われてることも珍しくない。
これは経験の浅いソフトウェアしか知らない技術屋か、商売勘定にしか興味が無いような商業市場主義者が現状を知らずに言いふらしているだけである。だが、発言の影響は大きいので間違った現状が認識されているのです。

「LAMP環境」とは、 Linux、Apache、MySQL、PHP で構成した、主にWebサーバのことを指す。
この環境は、アメリカあたりでは一般的な安価(今風にいうと、サブプライムな)レンタルサーバでの構成。ところが、日本ではアホとしか言いようが無いくらい何でも「アメリカに右に倣え」で、とにかく「LAMP環境」といって過言ではない。
#Java にも同じことが言える。

そういうことは、我々のようなサーバ運用に永年関わっている人種には知れ渡っているようなもので、レンタルではない業務用サーバ、となると、やはり FreeBSD か Solaris が使われることが多い。それは、「他でも使っているから」ではなく、「高負荷に強いから」「メンテナンスの自由が利くから」「ライセンスが利用環境に適するから」というような積極的な理由の方が多いわけで。

当方は、「LAMP環境」に関しては否定的な方で、特にライセンスやメンテナンスに責任を持つことが困難であれば、「LAMP環境」は選択肢から外した方が懸命。特にメンテナンス環境とライセンス問題はこの構成ではかなり不安です。

先ず、Linux だが、色々なディストリビューションが乱立しており、更にディストリビューション同士で考え方が全く違うので、どれが良い?なんて質問されても答えようが無いか、自分が使っているディストリビューションをとりあえず使ってみたら?程度の回答しか出来ない。加えて独自の改良が仇となって、メンテナンスがバイナリ更新で簡単な一方で、ソースコードからのインストールなど、細かいことがすぐにできないことが結構あるので、運用には今ひとつかな、という感じです、

Apache は特に問題は無い。

次に、MySQL。これがなかなか曲者で、ライセンスがころころ変わり良く判らない。知らず知らずのうちにライセンス違反を犯してしまうと、システムとして使えなくなるので、「ライセンスに責任持つ」(そして、そういう顧客は少ない)という顧客でないと使わせることは怖くて出来ない。更に日本語環境を含めたマルチバイト文字環境は使えるとはいっても、正直今ひとつである。使ったことあるが正直言って「かなり使いにくい」。ただ、西欧圏のような1バイト文字圏を想定すると、確かに手っ取り早い感はある。
MySQLに関しては、他にも技術的な問題があるが、ここでは割愛。

最後に、PHP。日本語ドキュメントが早くから整備されていたこともあって、大きな欠点はあるが、今でも結構多用されている。当方も当初は PHP メインで開発案件をこなしていたが、PHP3 から PHP4 へ移行しだした数年前の時点で、この路線は危険だと見切ってPerl に移行した。
それは以下の理由が大きい:
・下位互換性を考慮しないため、バージョン上がる度に検証、テスト、修正といった膨大なメンテナンス工数がかかる。この工数にかかる費用(金銭的なものだけではありません)を誰が負担するのか? サーバ運用だけにしわ寄せ行く現状なら使えない。
・文字列操作が弱い。
・メモリを大量に食う。だから、はっきり言って高負荷なサイト運用に向かない。潤沢な設備を用意できる大手業者ならたいした問題でもないのだろうが・・・

上記のような考え(遭遇した欠点を克服する手段の選定)もあって、当方は「BAPP環境」である。
FreeBSD、Apache、PostgreSQL、Perl で「BAPP」。
(勝手に作った造語です)

ところで、最近は FreeBSD とか PostgreSQL とか Perl とか判る技術者がいない、という話を聞く。
それは、絶対的な数が減っているというよりは、まともな技術者が他へ取られていることの証そのもの。
絶対的な数もそう増えていないのも事実でしょう。FreeBSD や PostgreSQL や Perl を色眼鏡で見るからです。

資金を出す方々はいつも正しい判断をするとは限りません。
むしろ、この業界の特徴でもあるが、周囲に流されて間違った判断をすることが多い。それが実態であることを認識することだけで、だいぶ違うと思うのですけれどね。
「LAMP環境」にこだわる技術者が近くにいたら、その技術者はスキル的に要注意です。
早いはなし、FreeBSD をいじれる技術者は Linux もなんとかいじれるのですが、逆は大抵当てはまりません。

2008/03/19(水)余計なつまらない設定はしない方が、、( /etc/ttys の設定 )

2017/10/11 8:21 サーバ運営・管理
Unix のシェルコマンドのひとつに w というアルファベット1文字のコマンドがあります。
これは、以下のような感じで、現在ログインしているリアルユーザのアカウント一覧を表示するものだったりします:
 1:19AM  up 4 mins, 1 user, load averages: 0.06, 0.20, 0.10
USER       TTY      FROM            LOGIN@  IDLE  WHAT
lifekrnl   p0       northwall       1:18AM   -     w


主に一番最初の行の右側にある小数点2桁の3つの数字を見るのに使っています。
上記の例だと 0.06 0.20 0.10 とある数字列です。
順に1分間,5分間,15分間の平均実行プロセス数。
数値が 1を超えなければ、このサーバはそんなに忙しい状態ではないことを意味します。

とあるサーバを FreeBSD 7.0 にしたら、このコマンドが機能しなくなってしまって、
代わりに /var/log/messages に以下のメッセージを延々と吐いていた模様:

Mar 19 01:02:05 **** init: can't exec getty 'none' for port /dev/ttyp1: No such file or directory
Mar 19 01:02:35 **** init: can't exec getty 'none' for port /dev/ttyp0: No such file or directory

原因は /etc/ttys の以下の赤い文字の部分:
# Pseudo terminals
ttyp0   none                    network  on secure
ttyp1   none                    network  on secure
ttyp2   none                    network

赤い文字の部分を削除して再起動したら、あっさりと解決。。orz
どうも設定間違えたみたいです。
下手すると、場合によってはリモートログインが出来なくなったりする可能性あるので、注意するにこしたことありません。

2008/03/16(日)FreeBSD 7.0R で csh が segmantation fault(SEGV)

2017/10/11 8:24 サーバ運営・管理
順次サーバOSを FreeBSD 7.0R に更新しているわけですが、 samba を使うために libiconv 1.12 をインストールして再起動したら、
ログインが全く出来なくなってしまった..orz

シングルユーザモードにしたら何とかシェル(csh)を使うことが出来たので、ログを見てみると、

kiew kernel: pid 13642 (csh), uid 1001: exited on signal 11 (core dumped)

のようなメッセージが出ている。
共有ライブラリ回りだというのは何となく判るが、何が問題なのか判らないので、先ずはOSをバイナリインストールしなおしてみる。。
上手く行かない。
試しにシェルを sh に変えてみると、core dump は出ない(使用できる)。

この現象は libiconv をソースコードからコンパイルにてインストールしてからでたので、libiconv と csh の関係を調べる。
ここしか有用な情報に突き当たらなかったが、やはり libiconv が問題の可能性が高いことに確信を得ました。

それでわ、、ということで、強引に /usr/local/lib 配下の libiconv.so.3,libiconvso.6 とそのリンクを削除し、その上で csh を起動してみる。そうすると正常に起動しました。これで libiconv.so の問題ということは判りました。

ここで、libiconv-1.12 をインストールしてみます。そうすると、 libiconv.so.6 がインストールされます。
こうすると、csh は再び segmantation fault を出し、ライブラリ依存する gmake を叩いてみると、'llbiconv.so.3 が 要ります' のようなメッセージを出す。

ということは、 csh は libiconv.so.3 を前提にしたバイナリパッケージ、ということが簡単に予測できます。
実際、packages にて libiconv-1.11_1 をインストールすると、 libiconv.so.3 がインストールされました。
この状態で csh を起動すると、segmantation fault は出ません。

原因は判ったのですが、今度は samba が上手く使えないのでないか?という疑問が、、
packages にて libiconv-1.11_1 をインストールした状態で、

$ iconv -l | grep MS
とすると、
kiew-lifekrnl% iconv -l | grep MS
40:CP1250 MS-EE WINDOWS-1250
41:CP1251 MS-CYRL WINDOWS-1251
42:CP1252 MS-ANSI WINDOWS-1252
43:CP1253 MS-GREEK WINDOWS-1253
44:CP1254 MS-TURK WINDOWS-1254
45:CP1255 MS-HEBR WINDOWS-1255
46:CP1256 MS-ARAB WINDOWS-1256
66:ARMSCII-8
85:MS_KANJI SHIFT-JIS SHIFT_JIS SJIS CSSHIFTJIS
92:CP936 MS936 WINDOWS-936

となり、使えそうな感じ。
わざわざソースコードから最新の libiconv 入れる行為が却って仇になる模様。。

pakages/ports 使うと、セキュリティバージョンアップの対応の遅さや、インストールディレクトリなどが環境に微妙に合わなかったりすることが結構多かったりして、使いにくいので、出来るだけ使わない方向でいるんですが、、

いまのところ、packages の libiconv-1.11_1 で samba 3.0.28a が一応利用出来ているみたいです。

2008/03/15(土)安全なサイトの作り方

2017/10/11 8:27 サーバ運営・管理
当方では、IPA(独立行政法人 情報処理推進機構) が定期的に発信するセキュリティインシデント情報なんかを電子メールで受け取っている訳ですが、そのなかに こんなものがありました。 → 「安全なウェブサイトの作り方 改訂第3版」を公開 〔PDFファイル〕

いつもWebサイトを利用したシステム構築を行う際は、セキュリティ対策には充分に検討して手抜かりの無い様にしているつもりだが、それでも想定外のことは起きるもので。。
上記資料では、9種類の主な脆弱性を挙げて対策手法の注意点などを挙げています:

1)SQLインジェクション(IPAに報告された全体の3割がこれらしい)
2)OSコマンドインジェクション
3)パス名パラメータ未チェック/ディレクトリトラバーサル
4)セッション管理の不備(セッションハイジャック)
5)クロスサイトスクリプティング(XSS、IPAに報告された全体の4割がこれらしい)
6)CSRF
7)HTTPヘッダインジェクション
8)メールの第3者中継
9)アクセス制御や認可制御の欠落

現状で注意が必要なのは、5)のクロスサイトスクリプティングですかね。
これははっきり言って、CGIなりで対処するだけでは不十分で、不審な振る舞いをしていないかどうか、偽サイトの有無のチェックとかにも目を光らせる必要があり、クライアントにも協力をしてもらわないといけません。

当方では過去に8)の脆弱性で 1999年に作成したCGI に関して一度外部から報告を受けて対処しただけです。このときは、 spam メールの発信基地になってしまっていたのでした。根本的原因の対処をしまし た。
他の脆弱性で報告を受けたことはありません。

特に1)、3)、4)、9)は、当方が 1998年に営利事業としてWebアプリケーション構築を始めてから注意している点で、今までに問題は起きていません。2003年以降は、1)~9)全て網羅の上で、構築を手がけているつもりです。

9)は、オペレート(運用)する人が全くの素人だと、いくら仕組みを作っても管理がずさんになりがちで、問題が起きる確率は高いのですが、幸いにも情報漏えいの事故の報告は無く、これはクライアントの皆さんが危険をそれなりに認知してもらっているのだろうと考えています。

2008/03/08(土)FreeBSD 7.0 における Cyrus-SASL インストール

2017/10/11 8:29 サーバ運営・管理
このライブラリをコンパイル・構築する際に、libtool という構築ツールを使用するようだが、FreeBSD 7.0 ではこれが悪さをして、Postfix で動作しない SASL 認証ライブラリが構築されてしまい、更に電子メール送受信が不可能になります。

google などで検索すると結構出てくるのですが、以下のようなログを /var/log/maillog に出します。

Mar 7 04:27:34 clione postfix/smtpd[5267]: warning: xsasl_cyrus_server_get_mechanism_list: no applicable SASL mechanisms
Mar 7 04:27:34 clione postfix/smtpd[5267]: fatal: no SASL authentication mechanisms
Mar 7 04:27:35 clione amavis[2970]: (02970-07) (!)FWD via SMTP: -> , 451 4.
5.0 From MTA([127.0.0.1]:10025) during fwd-connect (Negative greeting: at (eval 103) line 442, line 37.): id=02970-07
Mar 7 04:27:35 clione postfix/master[3021]: warning: process /usr/libexec/postfix/smtpd pid 5266 exit status 1
Mar 7 04:27:35 clione amavis[2970]: (02970-07) Blocked TEMPFAIL, -> , Message-ID: <20080306184755.9175867841@clione.lifekernel.ne.jp>, mail_id: XLLnLafANNab, Hits: -, 1298 ms
Mar 7 04:27:35 clione postfix/master[3021]: warning: /usr/libexec/postfix/smtpd: bad command startup -- throttling
Mar 7 04:27:35 clione amavis[2971]: (02971-04) (!)FWD via SMTP: -> , 451 4.5.0 From MTA([127.0.0.1]:10025) during fwd-connect (Negative greeting: at (eval 103) line 442, line 34.): id=02971-04

SASL ライブラリが上手く動作しないと出る現象。
ところが本当の原因は /var/log/maillog をみたのでは駄目。

/var/log/messages を眺めましょう。すると直接的原因が判ります:

Mar 7 05:37:33 clione postfix/smtpd[8462]: Could not find a dlname line in .la file: libsasldb.la
Mar 7 05:37:33 clione postfix/smtpd[8462]: Could not find a dlname line in .la file: libdigestmd5.la
Mar 7 05:37:33 clione postfix/smtpd[8462]: Could not find a dlname line in .la file: libotp.la
Mar 7 05:37:33 clione postfix/smtpd[8462]: Could not find a dlname line in .la file: libgssapiv2.la
Mar 7 05:37:33 clione postfix/smtpd[8462]: Could not find a dlname line in .la file: libplain.la
Mar 7 05:37:33 clione postfix/smtpd[8462]: Could not find a dlname line in .la file: liblogin.la
Mar 7 05:37:33 clione postfix/smtpd[8462]: Could not find a dlname line in .la file: libldapdb.la

これは、shared ライブラリが構築されていないと出ます。
調査すると、どうも Cyrus-SASL に同梱されている libtool のバージョンが古過ぎて(1.35) 、FreeBSD 7.0 にが対応していないようです。

pakeages にて libtool-1.5.24 (2008/03/08 現在)をインストールし、configure 後に、libtool を削除して、pakages でインストールした libtool を使用するようにすると、あっさり解決しました。
具体的には、
# ./configure
# rm libtool
# ln -s /usr/local/bin/libtool

としてから、通常の make , make install をやれば良いです。