投稿者「ロコモコ堂 フルタ」のアーカイブ

ロリポップとhetemlのレスポンス(ping編)

サーバやCMSについて、いろいろテストしたものをまとめたいと思っている今日この頃。

皆さん、いかがお過ごしでしょうか?

さて、以前から何度か調べていたレンタルサーバの通信速度とレスポンス具合ですが、うちでも多くのサイトで利用させてもらっている「ロリポップ!」と「heteml」の最近の具合をちょっとチェックしてみました。

2ヶ月前に大規模なアタックを受け、セキュリティーをアップさせた様で、パーミッションに手を入れられたり、CGIやPHPをフルパス指定で利用できなくしたり、その他色々変更されているみたいなので、レスポンスにも影響が出てるかと思われます。

そして、「ロリポップ!」の上級モデルである「heteml」とが、コスト相応の性能を出しているのか?

それをレスポンスの面で調べてみました。

テストサーバには管理している「ロリポップ!」サイトと「heteml」サイトを置いているサーバから、無作為に10サイトづつを選びました。

テスト方法はフレッツ光回線でインターネットに接続してあるMac OS 10.8のiMacから、Terminalを使ってpingを飛ばし、10回の平均値を取る事を数度繰り返し、最大値と最小値を出した回を省いた残りからデータの平均値です。

lolipop-heteml_ping_test_2013-10-28

table-01はロリポップ!hetemlが大規模なアタックを受けた約2ヶ月後にテストしたデータです。table-02はその半年前にテストしたデータで、今回の攻撃前のデータです。

どちらも同じ場所の同じMacでテストしています。

これを見る限りは、ロリポップ!は若干レスポンスがアップしています。
ttlは、起点の64から、ルータ間の受け渡し回数(ホップ数)を引いた数になるので、数値が小さい程多くのルータを通過している事になるんですが、何故か通過するルータ数が少なくなっています。これがレスポンスアップの原因だと思われます。
ロリポップ!はSSDを一部導入したりしているので、それが影響しているのかもしてません。

hetemlの方は、table-02よりtable-01の方がレスポンスが落ちています。table-01は早朝5時代、Table-02は深夜の12時前ですので、回線が込み合うTable-02よりTable-01の方が有利な筈です。
またttlも同じなので、セキュリティーアップによる影響が出ているのかもしれません。

因にtable-03はtable-02の約4時間20分前の夜の早い時間帯に、少し離れた事務所で、同じくフレッツ光とMac OS 10.7のiMacで、同様に調べた結果です。
回線が込み合う時間帯と、事務所内のローカルネットの設定の所為でレスポンスが悪いですが、やはりhetemlのレスポンスが良くないです。

ロリポプラン 詳細はこちら」でのサーバ使用料は¥525/月(税込)。
heteml」のサーバ使用料は¥1575/月(税込)。

単純にpingでの結果だけ見ると「ロリポップ!」の方がお徳感が有ります。
(でも、サイトを置いているサーバの、他の利用者へのアクセスが多い場合など、やはりhetemlが有利ですね)

ちなみにうちの環境では、tracerouteすると、ロリポップ!に辿り着く直前ははinterQ、hetemlに辿り着く直前がさくらインターネットでした。

PHPによるWordPressカスタマイズブック 3.x対応

WordPressでサイトやブログを運用していて、もっと自分好みにカスタマイズしたいと思った事はありませんか?

この書籍「PHPによるWordPressカスタマイズブック―3.x対応(著者・藤本壱)」は一般的なWordPressの書籍と違い、インストール方法とか記事の打ち込み方、基本的なテンプレートや関数の説明と言った事にはほとんど触れられていません。

また、サイトやブログのサンプルを作りながらの解説書とは違い、関数のプロパティーやパラメーターの一覧、割り当てられたグローバル関数の値などが載せてあり、それらがどう関係し、実行結果はどうなるかまで載せられているので、WordPressの内部の動きに興味のある人には、とても面白い内容だと思います。

ひと工夫・ふた工夫して、他とはひと味違うオリジナルのブログやサイトを作りたい人や、WordPressの仕組みについてもっと良く知りたいけど、普通のWordPressの解説書では物足りなくなっている人に読んでもらいたい本です。

関数を使ったカスタマイズの説明や、関数を使わずデータベースから直接データを取得する方法、またプラグインの作り方をの説明を中心に書かれています。

特に面白いのが

①データベースに直接アクセスしてデータを取得する方法
②プラグインの作り方

です。

①データベースに直接アクセスしてデータを取得する方法

「単一ブログの場合」と「ネットワーク機能で複数ブログが管理されている場合」それぞれのテーブル構造の解説が、「コンテンツ系」「分類系」「ユーザー」「コメント/トラックバック関係」を中心に、テーブルの結合も含め、わかり易くまとめられています。

 また、wpdbクラス(ezSQLクラスライブラリをWordPress用に改良したもの)のオブジェクトを割り当てたグローバル変数$wpdbを通してデータベースにアクセする方法も書かれています。

WordPressのバージョンアップでデータベース構造に変更が有るかもしれない危険性はありますが、WordPressの標準関数では指定できない複雑な条件設定が出来たり、関数を使わない分、高速かも図れたりするので、試してみたくなります。

wpdbクラスを使ったデータベースへのアクセスは、他の書籍ではあまりお目にかかった事が無いので、貴重な資料だと思います。

wpdbクラスを使った実例として、「最近90日間でコメントが多い投稿リストの表示方法」「画像一覧のページを作る方法」「ネットワーク機能で管理している複数ブログの、各ブログ最新5記事の一覧を作る方法」「ネットワーク機能で管理している複数ブログの、全ブログをまとめて最新一覧をサイドバーに表示する方法」が載せられています。

②プラグインの作り方

WordPressのプラグインの基本であるアクションとフィルター、フックの使い方について、実例を元に説明しています。

サイドバーに、表示しているページの記事が所属するカテゴリーの、投稿の一覧を表示するプラグインの制作実例で、フィルターの使い方を説明。

自動的にHTMLのヘッダー(〜)内にmetaタグを追加し、時刻を表示させるJavaScriptを組み込むプラグインの実例で、アクションと、WP_headの使い方を通してフックの使い方を説明しています。

この書籍が他書とはちょっと違うのが、プラグインの制作方法自体を最初から最後迄載せている事です。

まず仕様を決め、プラグインファイルにプラグイン情報を記述し、仕様に合わせて関数やパラメーターを定義し、HTML部分の組み立てを行い、結果を出力する部分を作るという、プラグインを完成させる手順を、コードやフローチャートも使いながら説明してくれます。

また、プラグインが他国語で使える様に、複数言語化する方法も教えてくれます。

複数言語化するには、プログラム自体のメッセージは英語で書いておき、各言語ファイルを用意して、対応させるのます。日本語も各言語ファイルの一つとして扱います。そして言語ファイルは複数言語ツールgettextに対応したものにします。

その為の具体的な方法の

  1. プラグインプログラムにある英語のメッセージを各国語に対応させるアプリ「Poedit」のインストール方法
  2. 英語のメッセージを持つ完成したプラグインに各言語ファイルを読み込ませる方法
  3. 「__関数」と「_e関数」を利用して翻訳できる様にする方法
  4. 環境を構築し言語ファイルを作成し、読み込ませる方法
  5. 「Poedit」を使って各言語ファイルを作成する方法

を全て教えてくれます。

WordPressプラグインの複数言語化に関する書籍にも、なかなかお目にかかれ無いので、これも貴重な資料だと思います。

また、他に

  1. 自己完結型ショートコード [ ショートコード名 属性=”値” 属性=”値”…… ] や囲み型ショートコード [ ショートコード名 属性=”値” 属性=”値”…… ]テキスト[ /ショートコード名 ] のプラグインの作り方。
  2. WP_Widgetクラスを使ったショートコードでウィジェットのプラグインの作り方。
  3. プラグイン用設定画面の作り方。
  4. プラグインのアンインストールに対応さる方法。

が説明されています。

 感想・・・初級から中級に上がろうとしている人向けの書籍です。

ですので、PHPとSQLについて基本的な事が分かっていて、WordPressのテーマも作ったり、カスタマイズした経験がある人を対象としています。

初歩的なPHPやWordPressの関数などの知識がある事が前提で説明がされている為と、ページ数の制限の為か、なぜそうするのか?なぜそうなるのか?の細かな説明が省かれていたり、具体的にどんな事をしているのかを細かく説明せず、「いくつかの初期化をまとめて行う。」などと省略している箇所が所々有ります。意味が分かり難くく、他の書籍やネットで調べ直した部分も有りました。もうちょっと上手く説明してもらえれば、ありがたいです。
先生のペースでどんどん進んでいく授業を連想しました。

PHPによるWordPressカスタマイズブックは2009年9月にWordPress 2.8対応版が出され、翌年2010年9月に、このPHPによるWordPressカスタマイズブック―3.x対応が出版されました。

3.0対応版なので、参考に使われているテーマもTwenty tenです。またWordPressループもTwenty Tenのループが使われているので、最近、WordPressのカスタマイズを初めたユーザーは、最初、書かれているコードに少し違和感をかんじるかもしれません。

WordPressのバージョンは、既に3.5.1から3.6になりますが、ここ迄技術的に踏み込んだWordPressの解説書は無いので、まだ貴重な資料として、参考になると思います。

同じ著者がWordPressの関数について解説しているWordPress関数リファレンスガイドはWordPress標準関数について書かれていますので、合わせて読まれるとお互いを補完し合って、よりWordPressの事が理解できる様になると思います。

まだまだ使える書籍です。


PHPによるWordPressカスタマイズブック―3.x対応

 

MAMPのMySQLサーバが起動しない件 – MySQL DatabaseのUpgradeでOK

MacでWebアプリ開発環境を作ろうとする時、手軽に始められるのでユーザーも多いMAMP

Apache(Webサーバ)・MySQL(SQLデータベースサーバ)・Webプログラミング言語のPHP・MySQL管理ツールのphpMyAdminSQLiteなど、いくつかの補助的なソフトウェアとライブラリモジュールを、まとめて一発でMacにインストールできちゃうという優れものです。

MacintoshApacheMySQLPHPの頭文字 を並べてMAMPっちゅうわけです。

世間的には、Webプログラミング言語のPerlもセットされていて、WindowsでもMacでもLinuxでも使えるXAMPPの方が有名で、ユーザーも多いんですが、私はもっぱらMAMPを使っています。

MAMP ver 2.1.3にバージョンアップしたが・・・

さて、ここから本題。

サイトを置いているレンタルサーバが皆PHP 5.4を使える様にしてくれたので、自分のローカル環境でもPHP 5.4がテスト出来る様にと、MAMPを2.1.3にバージョンアップしました。

まず、今まで使っていたMAMPをフォルダごとApplicationsフォルダ外に退避させ、新たにMAMP ver 2.1.3をインストール(デフォルトでApplicationsフォルダにインストールされます)します。

そして新しくインストールされたMAMPフォルダから「db」フォルダと「htdocs」フォルダはゴミ箱へ移動させます。

代わりに古い方のMAMPフォルダから「db」フォルダと「htdocs」フォルダを新しいMAMPのフォルダに移動させ、今まで作った実験サイトやアプリを丸ごと引っ越しさせます。(「db」フォルダにはMySQLとSQLiteのデータが、「htdocs」フォルダには自分が作成したサイトを構成する各ファイルやWebアプリのファイルが入っとります。)

これでバージョンアップは完了。MAMP.appを起動させ、localhost内の実験サイトにアクセス・・・としたところ、MAMPのMySQLサーバが立ち上がらない!

MySQLが起動しないMAMP

MySQLサーバがが起動しないMAMP

前回、MAMPを終了させた時、MySQLサーバが停止されないままになっていて、一部のプロセスが終了せずに残っていた時、こんな現象が起るんですよね。(と、またなっちゃったかと思う自分)

まずはKillall -9 mysqldなのだ

この場合はターミナルを使い、MySQLサーバの全てのプロセスを一旦終了させる為

を実行します。

ターミナル画面上では、

となります。

killallは「プロセス名を指定してプロセスを終了させる」。は「オプションの意味」で、9が付くと「Killシグナルによるプロセスの終了」。mysqldは「MySQLサーバのプロセス名」という事です。

これを実行しようとターミナルを起動させると、想定外のターミナルのトラブル発生です。bashのコマンドが見つからないと、ターミナルでエラーメッセージが出ます。MAMPのメンテナンス以前にターミナルのメンテをしなくちゃ。

これはbashのPATHがおかしくなっていたので、これを片付けて(詳細はこちら→ターミナルで-bash: 1: command not foundが出た。→PATHがおかしいんでしょ)、ターミナルで

を試してみたんですが、

No matching processes belonging to you were found(そんなプロセスはないよ)

との返答です。つまりMySQLサーバは起動していない→終了しているって事です。MySQLサーバが起動できない原因は別に有る様です。

MySQL ver 5.5からは’default-charactor-set’は’character-set-server’に

となると、まずMAMPを起動させた時のMySQLの状態をチェックしなければなりません。MySQLのエラーメッセージを調べてみます。

MAMPのMySQLのlogは、MAMP > logs > mysql_error_log.errに有ります。

MAMPのMySQLのエラーメッセージ unknown-variable 'default-character-set=utf8'

unknown variable ‘default-charactor-set=utf8’(default-charactor-set=utf8という宣言されていない変数がある)というエラーメッセージが出ています。

MySQLの起動時に、初期設定ファイルから設定を呼び込む時、未宣言の変数’default-charactor-set=utf8’がファイルに有ったという事ですね。

MAMPがバージョンアップすると共に、その中のMySQLのバージョンもアップしている筈です。

調べてみると、MAMP2.1.3のMySQLのバージョンは5.5.29でした。バージョンアップによる変更点を調べてみると、バージョン5.5では今迄使っていた変数’default-charactor-set’は使えなくなり、代わりに’character-set-server‘を使えとの事。

1.4. What Is New in MySQL 5.5 – MySQL

MAMPのMySQLの初期設定ファイルは、MAMP > db > mysql > my.cnfにありますが、このmy.cnfの[client]と [mysqld] セクション(グループ)に記述した

に変更・保存して、MAMPを再起動させます。

しかし、まだMySQLは起動しません。

my-medium.cnfを使ってmy.cnfを初期化する

エラーメッセージを開くと、

MAMPのMySQLのエラーメッセージ Found option without preceding group in config file

found option without preceding group in config file(初期設定ファイル内の先のグループにないオプションが見つかった)

と言う警告になっていますが、ちょっと意味が判り難いですね。

MySQLの初期設定ファイルmy.cnf内には[client]・ [mysqld] ・[mysqldump]・[mysql]・ [mysqlhotcopy] のグループ(セクション)毎にオプションの設定をまとめて記述する様になっています。

my.cnf中のグループの中に、他のグループとは違オプションが有るという事です。

見落とし箇所が有る様なので、とりあえずmy.cnfをMySQL ver 5.5.29用のもので初期化し、そこから文字コードの設定をした方が間違いがなさそうです。

my.cnfをver 5.5.29用に初期化するには、my.cnfの中身を消去し、

MAMP > Library > Support-file > my-medium.cnf

の中身をコピーしてやるだけでいいです。

初期化後、[client]と [mysqld] セクション(グループ)に

を付け加えてやります。

さて、これでMAMPを再起動させればMySQLも起動するだろうと思ったんですが、またもや起動せず。

mysql_upgradeするんですね

エラーメッセージは、

MAMPのMySQLのエラーメッセージ mysql_upgrade

please run mysql_upgrade to create it(mysql_upgradeして下さい)です。

MySQLのバージョンがアップしたから、以前のデータベースのシステムテーブルのmysqlプロキシーが無くなったので、それを作る為にmysql_upgradeするってことですか。

具体的なやり方は、

MAMP PRO, MySQLをアップグレード – biginsprite log

で紹介されていました。ターミナルを使わなくても、簡単な方法で出来るんですね。

私の使っているのはPRO版じゃない無印のMAMPなんですが、メニューバーのTools > Upgrade MySQL databasesを選択し、

MAMPのupgrade MySQL databasees

出てきたウインドウ下部の「Upgrade」ボタンをクリックすとmysql_upgradeできます。

MAMPのupgrade MySQL databaseesのUpgradeボタン

さあこれでMySQLも起動できるでしょうと、MAMPを再起動させます。

MAMP 起動

やっとこさ、MySQLを起動させられました。時間がかかりましたー。

 

参 考

エラーメッセージ – unknown variable ‘default-charactor-set=utf8’で悩まされた人が多いんですね。

[MySQL] “[ERROR] /usr/libexec/mysqld: unknown variable ‘default-character-set=utf8″の対処法 – DQNEO起業日記

でも、解決の過程を丁寧に書かれています。

ターミナルで-bash: 1: command not foundが出た。→PATHがおかしいんでしょ

terminal_vi

メインマシンをMacにしているので、作業はMac上で完結した方が手っ取り早くなってしまいます。

だもんで、WindowsやCentOSに分散させたシステムまで、どんどんMacに移してしまってます。

ですが、これが細々としたトラブルを引き起こす原因になってます。

この前も、MAMPのMySQLサーバの不具合を直す為に起動させようとしたターミナルでエラーが起きたんですが、これも全ての作業環境をMacに持ち込んだ為に起きたトラブルでした。

事の始まりはMAMPのバージョンアップ後、MAMPのMySQLサーバが立ち上がらないので、とりあえずMySQLのプロセスを終了させようと、ターミナルを起動させた事です。前回のMAMPの終了が不完全で、MySQLサーバのプロセスがまだ生きているんじゃないか思ったんですね。

で、ターミナルを起動させると、

-bash: 1: command not found
-bash: w: command not found

とエラーが表示されます。

コマンドが見つからないってどうゆう事?

OnyXやMagicanでHDをクリーニングした時、間違って消したのか?とも思ったんですが、とりあえずbashのPATHがおかしくなっていないかの確認です。

ターミナルで

echo $PATH

を実行させると、PATHはなぜかandroid-sdkに通ってます。

? ……………. !!

よく考えてみたら、このMacに一時Androidの開発環境を移した時、

.bash_profile

で、一部コマンドパスの設定を変えたところがあったんですわ。

Androidの開発環境はubuntuに戻しているので、Macからは外せます。そうなると事は簡単。.bash_profileを消してしまえばいいんですね。そうですね。

cd

でhomeに移動し、

rm .bash_profile

で.bash_profileを削除します。

そしてターミナルを再起動させたら、

すっきりエラーメッセージは無くなりました。

作業環境の記録を残す様にはしてるんですが、徹底できずにいて、設定変更の事を忘れていたのが間違いの元。さらに言うなら、基本的な設定を変えなくていい様に、ジャンルの違う開発環境は、別のPCに作った方が間違いが起き難いって事ですね。

何事も、すっきりとわかり易い整理ってもんが大切なんですねえ。

ところで、MAMPのMySQLサーバの方は、プロセスとは関係なく、MySQLサーバのバージョンアップで、データベースのテーブルのバージョンと合わなくなっていた事が原因でしたか。

WAF使っちゃうと、XMLパーサで外部ファイルが解析できなくなるのね。

世界中でCMSサイトのハッキングが頻発している昨今。WordPressサイトへのブルート・フォース・アタックによる侵入が問題になってますね(ユーザー名「admin」のWordPressサイトが狙われている!←詳細はこちら)。

私の管理しているサイトでも、WordPressではなくjoomla!のものですが、ちょっと前に不正侵入がされました。

joomla!が最新バージョンじゃなかったんですね。で、セキュリティーホールから侵入されてしまったんです。調べると.htaccessがいじられていたので、慌ててサイト全体を消去し、不正侵入されたと思われる時期以前のバックアップデーからサイトを作り直しましたわ。

新サイトに移行し、消す予定だった古いサイトなので大きな被害は出なかったんですが、簡単に侵入されたもんで、今まで以上にセキュリティーに気を使う様になりました。

そこで今日の本題、「WAF」なんですね。

WAF」とは何か?と言えば、Webアプリケーションのぜい弱性を突く攻撃に対からサイトを防御するための仕組みで、Web Application Firewallの略です。

悪意ある攻撃者からサイトを守る仕組みとしては、「ファイアーウォール(Firewall)」とか「IDS/IPS」などが広く使われているんですが、これらでは、最近のCMSサイトへの攻撃には対処出来ないんですよね。

最近のWebサイトへの攻撃は、SQLインジェクション(サイトへのリクエストにデータベースへの命令をくっつけて送り、データベースを不正操作するやつ)やクロスサイトスクリプティング(フォームや検索から不正なスクリプトをサイトに挿入し、なりすましメールを送ったりも出来るやつ)といった、サイトのWebアプリの脆弱性を突いたものが多くなっているんですね。

ちょっとややこしくなるんですが、ネットワークの基本でよく言われるOSI参照モデルの、サイトを置いているサーバのコンピュータ部分のみ切り出して、外部のネットワークから攻撃を受けた時、どの層でどう防ぐのかを図にしてみました。

OSI参照モデルで見てみると

OSI参照モデルでファイアーウォールとIDS/IPS、WAFを見てみる

ファイアーウォール(Firewall)」の場合、送られてきた通信データパケットの、ネットワーク層とトランスポート層をチェックします。送信元IPアドレスや宛先のIPアドレス、(使うmailサーバやhttpサーバの)ポート番号をチェックし、許可されていない通信データは遮断する事で、不正アクセスから保護します。

IDS/IPS」は、パケットのネットワーク層からアプリケーション層までチェックするんですが、攻撃の特徴などをデータベース化したものをを元に検知(IDS)して、管理者へ通知し、通信の遮断やパケットの破棄を行い、攻撃を防御(IPS)します。

SQLインジェクションクロスサイトスクリプティングなどは、通信としては普通のアクセスと同じですから、これらの防御方法ではチェックできず、すり抜けてサイトへアクセスされてしまいます。

WAF(Wab Application Firewall)」はこれらとは違い、Webアプリケーションとクライアントが行うやり取りを監視します。Webアプリケーションに送られてくる入力内容などを直接チェックし、不正な要求を遮断してしまう仕組みになっています。

ですから、SQLインジェクションやクロスサイトスクリプティングなどにも対処できるんですね。

(詳しい情報はこちら→ Wab Application Firewall読本 – 独立行政法人 情報処理推進機構

これは、サーバーを管理・運営しているものにとって、とても助かる安心機能です。

私の管理しているサイトは、ロリポップ!hetemlヘテムル)を使っているものが多いんですが、昨年後半位から順次、WAFが無料で装備される様になりました。

もちろん、喜んで、すぐに使い始めました。

設定も簡単に出来、不正アクセスが有った場合、簡単なログチェックもできます。

ロリポップ!の場合、「ユーザー専用ページ」に入り、左の項目一覧から「Webツール」をクリックし、現れた項目から「WAF設定」をクリックすると設定ページに進めます。

ロリポップのWAF設定ページ

ロリポップのWAF設定ページ

ログチェックは、「WAF設定」ページに表示された各ドメインの「ログ参照」ボタンをクリックします。

ロリポップのWAFのログ

ロリポップのWAFのログ

hetemlヘテムル)の場合、「コントロールパネル」に入り、右の項目一覧の「ウェブ関連」>「WAF設定」をクリックします。

hetemlコントロールパネル

hetemlコントロールパネル

サーバに設定している「ヘテムルドメイン」「独自ドメイン」の一覧が表示されますから、目的のドメインの「詳細をみる」ボタンをクリックします。

heteml サーバに設定しているドメイン一覧

heteml サーバに設定しているドメイン一覧

「サブドメイン」の一覧が表示されます。
各サブドメインの「WAF設定」ボタンをクリックすると、「WAF設定」の「ON」「OFF」ができます。
各サブドメインの「ログ参照」をクリックすると、「WAF検知ログ」を確認できます。

heteml サブドメイン一覧

heteml サブドメイン一覧

hetemlヘテムル)の「WAF検知ログ」はロリポップ!のものより詳細で、「URL-Path」や「拒否理由」も表示されます。

heteml WAF検知ログ

heteml WAF検知ログ

しかし、喜んび、すぐに使い始めたのはいいんですが、ここでまた困った事が起きたんですね。

XMLパーサを使い、外部ファイルを解析して表示させていたものが、使えなくなったんですよ。

WordPressにplugin化してインストールしていたんですが、何も表示しなくなったんです。

エラーメッセージを表示させると、「403」。

英語で”Forbidden” 日本語で「禁止」って事ですか。

XMLパーサを使い、外部ファイルを解析して表示するのが、「WAF」に不正アクセスと判断されたんですね。

WAF」にホワイトリスト(これは安全だからチェックしなくてよしとするリスト)が使えたらいいんですけど、そこまで出来ないのが残念です。

せっかく「WAF」が使える様になったので、ちょっと面倒な方法ですが、外部ファイルの解析は別の方法に切り替えました。