linux boxなど、コンソールからsshで接続したときに、idleしても自動切断されないようにするkeepaliveパケットを送信する設定
powerd by matsumoto sho
↓60秒おきにkeepaliveパケットを送信する場合
sendmail / qmail / postfix の接続元制限
特に、DNS関連(正引きできないと...、逆引きできないと...というケース)について確認した内容をメモしておきます
sendmailの場合
- 接続元IPアドレスを逆引きし、逆引きできたホスト名に対して正引きを行ったが、答えが一致しない場合にreject
⇒mcのLOCAL_RULESETSのRFORGEDで設定
- 接続元IPアドレスを逆引きし、逆引きできたホスト名に対して正引きを行ったが、答えが一致しない場合にreject
⇒tcpserverの-p(小文字)オプションで設定
- 接続元IPアドレスの逆引きができない場合、または接続元IPアドレスを逆引きした結果を正引きした時にAレコードが存在しない場合にreject
⇒main.cfのreject_unknown_clientで設定 - HELO/EHLOのFQDNを正引きした時、そのホスト名がAレコード・MXレコードのいずれでもない場合にreject
⇒main.cfのreject_unknown_hostnameで設定 - Envelope Fromのドメイン部分がAレコード・MXレコードのいずれでもない場合にreject
⇒main.cfのreject_unknown_sender_domainで設定 - ルール：RCPTのドメイン部分がAレコード・MXレコードのいずれでもない場合にreject
⇒main.cfのreject_unknown_recipient_domainで設定
と、いうわけで
- sendmailとqmailの制限は一緒。postfixは微妙に違います。
- 「HELO/EHLOのFQDNの正引き結果」と「接続元IPアドレス」をマッチさせるルールはないみたい。
- 「MAIL From:のFQDNの正引き結果」と「接続元IPアドレス」をマッチさせるルールはないみたい。
DNS逆引きチェックを入れちゃった場合に問題になりそう(だと言われている)ケースは
- 共有ホスティングの場合
- NAT構成の場合
- 逆引きが自分で設定できない場合
[Read More]
BPStudyに参加してきました
少し前の話ですが、BPStudyに参加してきました。
BP Study#14第14回： 集合知 と Django Admin
MC : 松風敬 「集合知」
MC : 岡野真也(id:tokibito) 「Djangoの紹介とAdminカスタマイズ」
[Read More]
PHPでSessionの生成が遅い場合の注意点
webサーバのパフォーマンスについて、PHPでセッション生成が遅い場合、
php.iniの設定を確認してみてください。
session.entropy_file = /dev/random
となっている場合、この/dev/randomからの読み取りの遅延が原因で動作が遅くなっている可能性が高いです。⇒使うのであれば /dev/urandom を使いましょう。
/dev/randomからの読み込みが遅くなる原因は、
- /dev/randomは、十分なエントロピーが得られない場合には応答をwaitすること
- エントロピーの素として「人間の利用するキーボードなどの入力デバイスのタイミングの「ぶれ」などを活用」していること
⇒iDC設置のサーバ機器だとエントロピーがたまらない！
⇒from: Linusのクリスマスプレゼントが引き起こした問題 - @IT
この場合、サーバの負荷は高くないものの応答が遅い状態になります。
みなさまご注意ください。
[Read More]
稼働中のMySQLの情報収集
稼働中のMySQLの情報収集の方法です。
show status like 'Max%';
のように、絞り込みも使えるので便利ですね。値を読む際には単位に注意しましょう。
公式ドキュメントには、単位がキッチリ書いてないものが結構あって難儀します。。。
mysql> show status;
mysql> show variables;
innodbの場合
[Read More]
PHPをAPCで高速化
OpenXで広告配信システムを構築したとき、APCの導入で負荷が1/100くらいに下がったのでメモ。
LoadAverage60→0.6になりました。
導入は簡単です。
# pecl install APC
でokです。php.iniに設定を追加して完了。
[apc]
extension=apc.so
apc.enabled=1
apc.optimization=1
apc.ttl=10
apc.gc_ttl=10
apc.shm_size=96
ポイントは、apc.shm_sizeを大きめにとらないとgcが正常に動作しないようです。extension=apc.so
apc.enabled=1
apc.optimization=1
apc.ttl=10
apc.gc_ttl=10
apc.shm_size=96
apc.shm_sizeが足りないと、apacheのエラーログに
[Mon Oct 10 08:15:45 2008] [apc-warning] GC cache entry '/var/www/openx/var/cache/deliverycache_1184f8a13xxx4b67eb68c969e9e5740.php' (dev=64769 ino=0) was on gc-list for 2852984 seconds
なんてのが出続けます。。。[Read More]
webサーバをチューニング
webサーバのチューニングのポイントをまとめておきます。
TIME_WAIT待機時間を短くする
アクセスが多いシステムだと、ソケットの開放が追い付かなくなって
ポートを使いきってしまいます。
⇒特にKeep Alive OFFのwebサーバなど
net.ipv4.tcp_fin_timeout
の値になります。(単位は秒)
オンラインで変更する場合、sysctlを使って調整します。
設定値の表示
# sysctl -a
設定値の書き換え# sysctl -w net.ipv4.tcp_fin_timeout=30
# sysctl -w net.ipv4.tcp_tw_reuse=1
# sysctl -w net.ipv4.tcp_tw_recycle=0
# sysctl -w net.ipv4.tcp_tw_reuse=1
# sysctl -w net.ipv4.tcp_tw_recycle=0
↑なんか勘違いしていた可能性があるので修正。現状では大きな問題は起きていないですが、tcp_tw_recycleはNATで問題が起きることがあるようなので最終手段です。
@2008/12/11追記
↑tcp_tw_recycleを1にすると問題が多くて地雷祭りなので、基本0にしておきます。
@2010/10/29追記
いまさらですけど、tcp_fin_timeoutはtime_waitの数と関係ありません(60秒でハードコードされているとのこと)。tcp_fin_timeoutが関係あるのはFIN_WAIT_2の数で、FIN_WAIT_2が多い場合はtcp_fin_timeoutを短くすると改善するかもしれません。
また、起動時に設定されるように
/etc/sysctl.conf
を編集して設定しておきましょう。
参考図書 [Read More]
auto negotiationの仕組み
旧サイトからの移設分エントリです。
最近はインターネットも一般的になってきたこともあって、その仕組みについての知識もだいぶ普及してきたようです。
パケット通信とはなんぞや、や、 HTTP, FTP, SMTP, POP等のプロトコルレベルの話からTCP/IPの仕組みぐらいまでが一般的ですかね。
OSI参照モデルなんかは大学でも情報系の学科なら必修ですね。
実践的な話ではTCPの場合のコネクションをはるまでの過程やルーティングの話がありますね。私も基本的な話はだいぶ分かっていたつもりなので すが、最近ひとつ疑問につきあたりました。
オートネゴシエーションの仕組みはどうなっているのか、です。
あのHUB< ->NIC間等で通信スピードと方式の検出を行うあれです。まさに基礎の基礎。なにしろ最初の一歩・ケーブルを挿す、の直後ですから。
というわけで調べてみました。
今回は一次情報の場所がわからなくて困りました。まずRFCを調べたけど空振り。ということでgoogleからあさってみました。で、見つけたのがここ(⇒Charles Spurgeon's Ethernet Web Site)。ここが一次情報源だと思います。
で、 肝心のauto negotiationの仕組みはというと、詳しくは分かりませんでした。(といってもただじっくり読んでないだけですが。)おおざっぱに言うと、FLP (fast link pulse)やNLP(normal link pulse)と呼ばれる既定のパルス波を用いて以下の優先順位で検出を行っているらしいです。