cat /path_to/access_log | awk '{print $4}' | sort | uniq -c | less
投稿者: chamu222
xrea、coreserverでのWP Super Cacheの運用方法
xrea,coreserverでのインストール、運用方法。
1. wp-content/plugins/にwp-super-cacheフォルダをそのままアップロード
2. 管理画面のプラグインからWP Super Cacheを有効に。
3. 設定画面のWP Super Cacheを開くと英文で色々書かれてて設定項目が何も出てきません。
ftpでwp-contentディレクトリの中に「cache」ディレクトリを手動で作りパーミッションを「777」等にする。
4. wp-super-cacheフォルダに入ってる「wp-cache-phase1.php」を「advanced-cache.php」にリネームしてwp-contentディレクトリに保存。
5. wp-contentディレクトリに書き込み権源がない場合設定ファイルが作れないとのエラーが出るのでwp-contentディレクトリのパーミッションを「777」等に変更。
パーミッションを変更してから設定画面のWP Super Cacheをリロードするとwp-content ディレクトリのパーミッションが「777」になってるから「755」にしろみたいな警告が出てきます。
この時にwp-content ディレクトリの中に「wp-cache-config.php」と言うファイルが作られてると思います。作られてるのが確認できたらwp-content ディレクトリのパーミッションを「755」に戻します。
6. 設定画面のWP Super Cacheを開くと色々設定項目があります。「WP Super Cache Status」をON (WP Cache and Super Cache enabled)にして「update status」ボタンを押して設定を保存。
7. サイトを表示してみると下の部分に色々と警告文が出てきます。ftpでwp-content/cacheを開くと中に「meta」「supercache」ディレクトリなどが出来ていますがファイル所有者がapache になっているのでパーミッションの変更が出来ません。そこでxrea(coreserver)の管理画面の「ツール」を開き「ファイル所有者の修正」を実行します。
数分待ってからftpでディレクトリのファイル所有者情報がapache以外に変更されたのを確認後再びサイトを表示すると下の部分に表示されていた警告文は消えます。
8. 再び設定画面のWP Super Cacheを開くと下の方にあるCache Contentsの部分に「Warning: glob() [function.glob]: SAFE MODE Restriction in effect. The script whose uid is〜〜」といった警告文が出てきます。
ftpで「supercache」ディレクトリにアクセスすると新たにディレクトリが作られていると思います。この中にキャッシュファイルが作られるのですが先ほどを同様にファイル所有者情報がapacheなのでxrea(coreserver)の管理画面の「ツール」から「ファイル所有者の修正」を実行します。
9. ファイル所有者情報が変更されたのを確認後サイトを表示し各ページを一通り表示してみます。
ftpで「supercache」ディレクトリの中に作られたディレクトリの中にさらに「category」や「tag」といったディレクトリが作られます。これもまたファイル所有者情報を修正してやる必要があります。
10. このように一通りディレクトリが作成されるまでファイル所有者情報の修正を何度か行う必要があります。
カテゴリーの階層を深くしてるときなどは修正回数が増え大変になるので時間をおいてゆっくりやるのもいいと思います。
すぐにキャッシュページが作られるわけでもないみたいなので１日１回ファイル所有者情報を修正するのを1週間ぐらい続けるのがいいかもです。
statコマンドで更新日付等の確認
statコマンドで、ファイルのatime、mtime、ctimeを表示できます。（atimeはAccessTime、mtimeはModifyTime、ctimeはChangeTimeです。）
statコマンドを実行すると以下の様に表示されます。
# stat a.txt
File: `a.txt’
Size: 533 Blocks: 80 IO Block: 4096 Regular File
Device: 802h/2050d Inode: 224314 Links: 1
Access: (0644/-rw-r–r–) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2007-08-21 12:10:05.000000000 +0900
Modify: 2007-08-21 12:30:00.000000000 +0900
Change: 2007-08-21 12:30:00.000000000 +0900
そこそこ使えます。
[Linux]loggerコマンドでsyslogへの書込み方法
loggerコマンドで、任意のメッセージをsyslog(/var/log/messages)へ書込むことができます。他とば、lsコマンドやdfコマンドの結果を書込む場合は、以下の通り実行することで、実行結果が複数行のログとしてsyslogへ書込めます。
# df -m | logger
た だ、上記の通り実行すると、‘logger: ********************’とメッセージが出力され、味気ないものになってしまします。loggerコマンドのオプションで、以下の様に 指定したほうが後でシステムログを参照した時に、幾分わかりやすいと思います。
# df -m | logger -t dfm -i
‘dfm[4332]: ********************’とメッセージが出力されるので、dfmというキーワードからどういった意図で出力されたメッセージかが想像できます。
また、シェルスクリプト内でloggerコマンドを使う場合、以下の通り、環境変数にオプションを含んで設定していたほうが便利です。
# LOGGER=’/usr/bin/logger -t abc.sh -i’
# df -m | $LOGGER
# $LOGGER “********************”
また、利用場面は少ないと思いますが、コマンドラインで使用する場合は、aliasコマンドで、オプションを含めた設定をしておくほうが便利です。
# alias logger=’/usr/bin/logger -t cmdline -i’
# logger “********************”
# logger -s “********************”
[Linux]ipcsコマンドでメッセージキューの確認
ipcsコマンドで、メッセージキューの状態を確認することができます。 # ipcs -q キー msqid 所有者 権限 使用バイト数 メッセージ 0x99999999 0 root 666 0 0 0x99999999 9999999 root 666 7 1
ipcsコマンドで、メッセージキューの状態を確認することができます。
# ipcs -q キー msqid 所有者 権限 使用バイト数 メッセージ 0x99999999 0 root 666 0 0 0x99999999 9999999 root 666 7 1