ドットインストール代表のライフハックブログ

Apacheについて知ろう 連載：ApacheによるWebサーバ構築（1）　「Apache」でWebサーバを構築。今回は、「なぜApacheなのか？」を改めて確認するとともにApacheの概要を解説する

mod_rewrite はすげー色んなことができて楽しい。でもけっこう難しい。 そこで、オイラ用メモで簡単なサンプル集をば。 ■シンプルなリダイレクト例 ■/hoge/ を /fuga/ に rewrite(リダイレクト)する。 RewriteEngine on RewriteRule ^/hoge/$ /fuga/ ■/hoge/ 以下を /fuga/ 以下にまとめて rewrite(リダイレクト)する。 RewriteEngine on RewriteRule ^/hoge/(.*)$ /fuga/$1 ■/hoge/ 以下で末尾が .jpg のリクエストのみを /fuga/ 以下に rewrite(リダイレクト)する。 RewriteEngine on RewriteRule ^/hoge/(.*\.jpg)$ /fuga/$1 ■/hoge/ 以下で末尾が .jpg か .gif

概要 この Status モジュールによりサーバ管理者はサーバがどのくらい の性能で動作しているかを知ることができるようになります。 現時点でのサーバの統計情報を読みやすい形式で現した HTML ページが 表示されます。必要であれば、このページは自動的にリフレッシュさせる こともできます (互換性のあるブラウザを使用している場合)。 別に、現時点でのサーバの状態を単純な機械読み取り可能なリストで 現すページもあります。 表示される情報は: リクエストを扱っているワーカーの数 アイドル (訳注: リクエストを扱っていない) ワーカーの数 各ワーカーの状態、ワーカーが扱ったリクエストの数、 ワーカーが送った総バイト数 (*) 総アクセス数と総バイト数 (*) サーバが起動もしくは再起動された時刻と動作している時間 平均の 1 秒あたりのリクエスト数、1 秒あたりの送られたバイト数、 リクエスト

#"inetd"かstandaloneかを設定 ServerType standalone #Apacheのトップディレクトリ #(注)ディレクトリ最後には/(スラッシュ)をつけないこと ServerRoot "/usr/local/apache" #PidFile #プロセス番号を記録するファイル PidFile /usr/local/apache/logs/httpd.pid #内部のサーバプロセス番号の格納先 ScoreBoardFile /usr/local/apache/logs/httpd.scoreboard #タイムアウトを送受信するまでの時間 Timeout 300 #持続型接続を許可するかを指定 KeepAlive On #KeepAliveを有効にした場合のリクエスト最大数を指定 MaxKeepAliveRequests 100 #持続接続をする場合に1つのコネクショ

Linux Squareフォーラムに掲載されている全記事にアクセスできるインデックスです。このページを見れば、Linux Squareフォーラムのすべてが分かります。また、インデックスは記事の追加とともに拡充していきます。

Linuxサーバ運用マニュアル 第6話「リソースをチェックしよう！」 サーバ運用について，リソースのチェックは重要です。マシンそのものがトラブルをかかえていては，どんな優秀なアプリケーションも役にははたちません。また，運用していく上でマシンのスペックが不足しているなら，対応する必要がありますし，普段からチェックしていれば，マシンの異常を早期発見することもできます。 ここでは，サーバマシンの何をチェックするべきなのか，また，それにはどのようなコマンドを用いるのかを紹介していきます。 CPUのチェック CPUはコンピューターの心臓部であり，性能に関係するため，重要なチェック対象です。CPUそのものと，プロセスの状態についてチェックします。チェックしたいのは次の項目です。 CPU使用率 CPUがどれだけ使われているかを%で表わしたものです。IDLE（待機）の値をチェックします。 IDLE（待機）

処理が遅い場合, 問題が, ディスク I/O, CPU能力, ネットワ−ク, メモリ不足, NFS 等のうちどこにあるかが問題になる.(いや,他にもありうるけど) ディスク I/O や ネットワ−クが問題になることが多いと思う. ネットワ−ク関連では, hosts ファイル や DNS に無登録のマシンだったり, NIS 参照に問題が出ていたり, また, 自分自身でなく NFS サ−バが遅いのが原因の例もあった. 機材の故障やケ−ブル不良で, ネットワ−クに大量のエラ−がでているのが 原因のことも多い. 複数の DNS サ−バを参照しているばあい, DNS サ−バの参照順が適切か考え直してみる. 使用する tool vmstat, free, top, netstat,tcpdump 等は普通に使えると思う. 負荷のモニタは procmeter が気に入っている. ネットワ−クの状況は I

（１）SWATCHアクションスクリプト作成 SWATCHが検知したIPアドレスからの累積不正アクセス数が3回以上になった場合または、引数でlock※と指定された場合、該当IPアドレスからのアクセスを24時間規制するシェルスクリプトを作成する ※Ping of Death等悪意のあるアクセスを即規制するためのオプション [root@fedora ~]# vi /usr/local/bin/swatch_action.sh　←　SWATCHアクションスクリプト作成 #!/bin/bash PATH=/bin:/sbin:/usr/bin LANG=C # 規制IPアドレス情報メール通知先設定 # ※メール通知しない場合は下記をコメントアウト mail=root # ログを標準入力から取得 read LOG # ログからIPアドレスを抽出 IPADDR=`echo $LOG|cut -d " "

SSHのログを監視して怪しいIPを止める /var/log/secure(または/var/log/messages)をみると適当な名前でログインを試みられている形跡があるので、自動で監視してアクセスを禁止にする． 必要なもの swatch IPtables 自前のスクリプト(後述) Swatchのインストール Perl5はインストールしておく． perlで必要なもの DateManip Bit-Vector Date-Calc Time-HiRes File-Tail Time-Date それぞれはtar.gzを解凍したフォルダで perl Makefile.pl make make test make install でインストールする．swatch本体も同様にインストールする． swatchの設定 http://www.atmarkit.co.jp/flinux/rensai/ro

あなたは「マシンがボロいせいで性能がでない」と感じたことはありますか？ マシンがボロいということはハードウエアを増強すればプログラムをいじらなくても性能向上するわけです。 ただし，どこがボトルネックかを把握せずに闇雲にハードウエアを増強しても高いコストパフォーマンス得られません。 今回はハードウエアのボトルネックの追求方法を考えます。ネットワークを使用する場合はネットワークがボトルネックとなることがありますが今回は考えません。 全体像を把握するためにPCの構成を書いてみます。 PCではCPU,メモリ，ハードディスクの3箇所がボトルネックの容疑者となります。 CPUがボトルネックの場合：CPU利用率を監視する メモリがボトルネックの場合：所要メモリを監視する ハードディスクがボトルネックの場合：DISK I/Oを監視する ボトルネックを判断する最初のツールはtopコマンドです。topコマンド

swatchといっても時計ではありません。UNIXのログ監視プログラムのことです。 syslog-ngがあればswatchは要らないかともおもったのですが、最近のswatchは便利な機能がついています。 プログラムでログ監視をしていて任意のメッセージにマッチしたらメールを送る、とか何かのプログラムを実行するようにしていて困るのが、同じメッセージが秒間何十と連続して出てしまった時。 1秒間に何十もメールが送信されてしまいます。。。それが数十秒～数分続くとものすごい数のメールが送られてしまいます。 メールサーバにも負担になりますし、何よりログ監視をしていてメール送信負荷でサーバが過負荷になってしまいます(T_T) それはsyslog-ngを使った場合でも同じ。 メッセージをfilter()でフィルタしてmatch()でマッチさせるのだけれど、マッチしたときにprogram()へメッ