|
あけましておめでとうございます。 皆様,本年もよろしくお願いいたします。 午年ですねえ。現実の馬は見るのも乗るのも好きです,残念ながら,ここ10年ばかりそのチャンスは全くありませんが,そのうちにも一回乗って,海辺なんかをうろうろしてみたいなあ。 皆様にとって,今年がよい年でありますように。 |
![]() |
投稿者: o6asan
先の一昨日,自鯖上で, Opcache を有効化した。
インストール以来,種々のトラブルをもたらした「BulletProof Security」だが,結構,有用な情報もくれた。例えば,これの System Information のページで見たことから,セキュリティ強化のために, php.ini の以下の値を変更した。
| デフォルト | カスタム |
| output_buffering = 4096 | output_buffering = Off |
| expose_php = On | expose_php = Off |
| mysql.allow_persistent = On | mysql.allow_persistent = Off |
また,同じページで,「Opcode Cache」というのを見て,そういえば, OPcache が PHP5.5 にバンドル とか書いてあったなと,思い出した。で,やってみたわけ。
php.ini の変更点は,以下の通り。
「zend_extension=php_opcache.dll」という行を Windows Extensions の最後に加える。以下の6行はアンコメントし, ここのページの指示 にしたがって値を変更する。のちのち自鯖用にもっといい値を見つけられるかもしれないが,今のところは,指示どおりが無難だろう。
| デフォルト | カスタム |
| ;opcache.enable=0 | opcache.enable=1 |
| ;opcache.memory_consumption=64 | opcache.memory_consumption=128 |
| ;opcache.interned_strings_buffer=4 | opcache.interned_strings_buffer=8 |
| ;opcache.max_accelerated_files=2000 | opcache.max_accelerated_files=4000 |
| ;opcache.revalidate_freq=2 | opcache.revalidate_freq=60 |
| ;opcache.fast_shutdown=0 | opcache.fast_shutdown=1 |
うちの場合, CLI 版 PHP は使わないので,「;opcache.enable_cli=0」はこのまま。
ビフォア&アフタで Apache のベンチマークを採ってみた。 ApacheBench
ベンチマークでも,若干良くなっているように見えるが,自 LAN 内での体感は,もっと良かった。うちのサイトは WordPress で動いてるから, PHP のキャッシュの効果は,多分,大したもんなんだろう。

APC Control Panel ってのがあるらしいので, Opcache にもあるのかなと思って探してみたら, Opcache Control Panel (実体は ocp.php だけ) というのがあって,ブラウザから Opcache を操作出来て便利。なんだけど, phpinfo 関数を有効にしないと動かないので,アクセス制限はかけておかないといけないよ。
くりくりさんが,「APC / OPcacheについて」というページを教えてくれた。こういう比較サイトはほかにもいろいろあるから,やってみる前にググって見るといいと思う。
Jetpack の不具合について。
MariaDB に移行した後, Jetpack が突然 エラーを吐くようになった。親サイトのダッシュボードから WordPress.com のスタッツにアクセスできなくなってしまったのだ。どうしても解決できなかったので, Jetpack Support Forum に行き,「Jetpack: site_inaccessible」をたてた。3日後,今度は WordPress.com 日本語フォーラムで,「ルートサイトと昔のテストサイトのコンフリクト。」というのをたてた。両方に顔出ししたのは,2つが全く別物だと思っていたからだが, Jetpack Support Forum で問い合わせが見当たらないといわれたときには驚いた。それに,私の英文の書き方が言葉足らずで,マルチポストをやった形になってしまった(^_^;)。彼らからもらったヒントが役に立ったわけだから,許してもらおう(汗)。
- Jeremy Herve が,
define( 'JETPACK_CLIENT__HTTPS', 'NEVER' );を使うといいかもしれないと教えてくれたが,うまくいかなかった。 - Richard Archambault が SSL が関係しているかもしれないので, SITE_URL を調べてみるように言ったので,チェックしたが, http://o6asan.com になっていた。これなら問題ないはず。
- naokomc が, WordPress.com とうまく連携できていない場合,自分のサイトでも所有権がないように見えるのだと教えてくれたので, Richard が言っていた SSL のことをもう一度考慮してみることにした。
- で,
define( 'FORCE_SSL_ADMIN', true );をコメントアウトしてやってみた。わぉ!! なんと,あっさり行ったよ。
結局のところ,一番初めの authorization のときは,環境によっては, define( 'FORCE_SSL_ADMIN', true ); のままだとうまくいかないことがあるということだ。WordPress.com との連携完了後, define( 'FORCE_SSL_ADMIN', true ); を元に戻したが,無問題だった。
というわけで,不具合は解消した。しかし,分からないのは,なんでこれが起こったかなんだよね。それについては,いまだに納得がいっていない。
こんなことがあっていいのか。
今月20日に, Reuters が “Exclusive: Secret contract tied NSA and security industry pioneer” というすっぱ抜きをやった。 23 日には,ミッコ・ヒッポネン が “EMCおよびRSAのトップ達への公開書簡” を書いた。
こんな話を信じたくはないが,ミッコがこんなものを書くということは,あらかた真実なんだろうと思わざるを得ない。 NSA にとっては,ある意味正規の仕事をやったにすぎないと言えないこともないが, RSA のほうからいうと恥を知ないにもほどがあるということになる。もちろん,片方の側の記事を読むだけでなく,反対側の記事,例えば NSAとの関係に関するメディアの主張に対するRSAの対応 (魚拓です)なんかも読まなければいけない。
しかし,一番悲しいことは, RSA への信頼が損なわれたということである。
コメント見落とし。
本日,シバケンさんのコメントにお返事を書くときに,たまたま,気づいたコメントがあった。「あれっ,これ読んでいないぞ」ということで,見に行ったら,やはり,お返事もしていなかった。
くりくりさんが,「CentOS6の練習-#10(Apacheのrpmを作る)。」につけられたコメントだった。
なんでだろうと思ったのだが,そういえば yahoo.de のアカウントのパスワードリセットが来たころだと思い当たった。 yahoo.de のアカウントはブログの連絡用に使っているものだが,なんか日頃と違った動きをすると,すぐパスワードリセットのお願いが来る。で,リセットするまで,アカウントはロックされている。だから,パスワードリセットをして,WP Mail SMTP の設定を直すまでは, WordPress からコメントのお知らせメールが来ないということになる。
今回も,対処後,トップの最近のコメントの一覧は確認したのだが,「停電???」の話で珍しくコメントの多かったときなので,見落としてしまったらしい。元記事が少し古いものだったので,その後も,気づかなかったらしい。やはり,こういうときは,ログインして,コメントの管理ページを見ないといけないと,改めて反省。
くりくりさん,ご覧になってますか。お返事が遅くなって,すみませんでした m(_”_)m。
| ブログではなくて,この冬2度目の雪が降ったので,撮ってみた。今日もすぐに止んだけど。出来栄えは,ウーム……??? |
昨日は,一生懸命取り組んでいた。何にって,くりくりさんとの話にも出ていた Windows7HP+SP1(x86) 上での MySQL から MariaDB 移行に(汗)。
まずは,全サーバデータのバックアップ。
次に,右図の表示をする maintenance.html を作り,作業のために,以下の行をドキュメントルートの .htaccess の頭に追記した。(参考: mod_rewrite,<IfModule>,Webサイトのメンテナンス中画面を出す正しい作法と.htaccessの書き方)
ErrorDocument 503 /maintenance.html
RewriteEngine On
RewriteCond %{REQUEST_URI} !=/maintenance.html
RewriteCond %{REMOTE_ADDR} !=IP address for Admin
RewriteRule ^.*$ – [R=503,L]
Header set Retry-After “Wed, 18 Dec 2013 01:00:00 GMT”
ここに,「特定のモジュールの存在に関わらず動作する 設定ファイルの原本が必要なときにのみこのセクションを使用してください。 通常の動作では、ディレクティブを <IfModule> セクションの中に 入れる必要はありません。」と書いてあったので, <IfModule> はいらないかなと思いはずした。
さて,さっき作った maintenance.html をサイト上に表示するようにして, MariaDB5.5 への移行に取り掛かった。
MariaDB をクリーンインストールする。今回,エンジンは MyISAM から InnoDB に変えてみたい。 MySQL を使い始めたときにすべてのテーブルを MyISAM で作った。最近, InnoDB のメリットをよく聞くのでやってみたくて仕方なかった。もっとも,そうしたって,よくわかっていないから,生かしきれないと思うけど(爆)。それに,移行で泥沼にはまっている話もちょくちょく見かけたので,二の足を踏んでいた。だって,何か起きたら対処しきれないじゃないヨ,もともと,よくわかってないんだから-Haha。
MariaDB はデフォルトで InnoDB らしい。この機会に,テーブルを作り変えてもいいや。
ステップ1 MySQL をアンインストールする。
- すべての WordPress プラグインを無効にする。
- さっきやったサーバのバックアップとは別に,すべてのデータベースを sql ファイルとしてバックアップする。
- ダッシュボードのツールから WordPress のすべての記事・コメントをエクスポートする。この時点では,可能なら WordPress Importer を使おうと思っていた。後述の理由で,結局あきらめたが。
- サービスを停止する。
コントロールパネル >> 管理ツール >> サービス
MySQL のサービスを選んで,停止。 - サービスを削除する。
cmd.exe を管理者として実行。
> sc delete MySql - フォルダ MySQL と MyDATA を削除(<--- これらには,自鯖の MySQL 関係のものがはいっている)。
ステップ2 MariaDB をインストールする。
- mariadb-5.5.34-win32.zip を MariaDB からダウンロードする。
- Installing MariaDB Windows ZIP packages にざっと目を通してから, mysql_install_db.exe について を読んだ。
- Zip を展開する。 MariaDB と MyDB というフォルダをサーバウェア用のパーティション Drive_SV に作り,展開でできたものを MariaDB フォルダにコピーする。
cmd.exe を管理者として実行。
> cd Drive_SV:MariaDBbin
> mysql_install_db.exe –datadir=Drive_SV:MyDB –service=MyDB –password=secretこれにより,root のパスワードが設定され, MyDB の中には my.ini が作られる。
- コントロールパネル >> 管理ツール >> サービス
MySQL のサービスを選んで,開始。
もし,「スタートアップの種類」が「自動」になっていない場合は,自動になおしておく。
ステップ3 phpMyAdmin で MariaDB にアクセスする。
- phpMyAdmin から root として,MariaDB にアクセスする。
バックアップしていた phpmyadmin データベースをインポートする。 - WordPress 用ユーザを作り, WordPress データベース用に Grant 以外のすべての privileges を付与し Global privileges は一定与えないこと。パスワードも設定する。 WordPress 用のデータベースを作成する。 collation は utf8_general_ci にする。
ログアウト。
WordPress Importer でインポートしたが,結局止めてしまった理由。
新しく WordPress をインストールした後, WordPress Importer でコンテンツをインポートした。間の悪いことに作業がほぼ終わってから,このプラグインが <object> などのある種のタグを移してくれないことに気づいた。 html 関係のどんなタグが対象になるのか調べるのも鬱陶しくて,この方法はやめることにした。これに結構時間かかってたんだけどね。
ステップ4 phpMyAdmin ですべてのWordPress のデータを復元する。
- InnoDB を使いたいので,バックアップファイル上の ‘ENGINE=MyISAM’ を ‘ENGINE=InnoDB’ に置き換えた。
- phpMyAdmin に WordPress ユーザとしてログインし,データベースにアクセス。
WordPress のデータベース上の現データをエクスポート。
現在の WordPress のデータベース上のテーブルをすべて削除。ところで,バックアップした sql ファイルには,全部が含まれていて大きいが,これを編集するのも面倒なので, php.ini のアップロードの制限を作業中だけちょっと変更した。 - バックアップをインポートしたら,エラーが出た。アララ。
#1214 – The used table type doesn’t support FULLTEXT indexesもともと, MyISAM だったので, FULLTEXT indexes が使われていたみたい。調べてみたら, YARPP が post_title と post_content のキーとして使っていた。ウーム。 しかし,フォーラムに, we can use YARPP on the InnoDB というのがあったので読んでみたら,性能は落ちるけど, InnoDB でも使えんことはないよと,プラグインの作者が言っていたので,「エイヤッ」と全 FULLTEXT indexes 関連行を削除した。(そういえば, MySQL5.6 は InnoDBでも FULLTEXT に対応したよね。–12/25追記)
- もっ一回,全テーブル削除。
書き換えたファイルをインポートしたら,あらまたエラーが……
#1064 – You have an error in your SQL syntax;これは,えっと,私のミスであった。 FULLTEXT indexes を消したときに “,” の消し忘れ。
KEY `post_author` (`post_author`), <<--------この ',' が残っていたのヨ。 ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=xxxx ; で, ',' を削除。 - 全テーブル削除。
3度目の正直。ナンチャッテ。インポート。おっ,通った。
ステップ5 通常営業に戻る。
- WordPess にログイン。
全プラグインを有効化して,挙動をチェック。.htaccess を元に戻して,メンテ終了。
- 実のところ,作業後, Jetpack が親サイトでエラーを吐いている。
Your website needs to be publicly accessible to use Jetpack: site_inaccessible
Error Details: The Jetpack server was unable to communicate with your site https://MySITE
[IXR -32300: transport error: http_request_failed SSL certificate problem: self signed
certificate in certificate chain]でも,調べてみたところ,メンテのせいではないようだ。そんなわけで, Jetpack フォーラム での情報待ちです。
MariaDBについては,移行完了ってところ。拍手×2。
追記(12/21):
MyISAM から InnoDB に変更して以来, YARPP プラグインの性能低下がはなはだしい。予想以上のひどさである。 YARPP のページの示唆通り,元に戻したほうが賢明だ。
- phpMyAdmin にログイン。
- WordPress 用のデータベースを選択。
- wp_posts テーブルを選択。
- 上のナビバーから ‘操作’ を選択。
- ストレージエンジンを Innodb から MyISAM に変更。
- テーブルオプションの ‘実行’ をクリック。
- phpMyAdmin をログアウト。
ところが,この変更を YARPP が認識してくれない。こういう操作のための機能も用意されているのだが,うまく働かない。解決策を探しに, YARPP サポートフォーラムに行ったら, MyISAM Override check doesn’t work というのがあった。 hussong の方法をやってみた。
- まず, YARPP を無効にする。
- phpMyAdmin にログイン。
- WordPress 用のデータベースを選択。
- wp_options テーブルを選択。
- 上のナビバーから ‘SQL’ を選択。
SELECT * FROM `wp_options` WHERE option_name LIKE "yarpp%"をやる。見つかったのをすべて削除。yarpp_fulltext_disabled = 1というのがあるはずなので,これをyarpp_fulltext_disabled = 0に変更する。- phpMyAdmin をログアウト。
- YARPP を有効にする。
元の設定はすべて消えてしまうので, YARPP の設定をやり直す。
これで,タイトルと内容の検討オプションが使える。ヤレヤレ。
追記2(12/25):
「Jetpack の不具合について。」というのを書いた。
追記3(2014/6/22):
WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。
WordPress 3.8 “Parker” の本家版が 12 月 12 日に出たので,日本語版を待っていたのだが,先ほど出た。コアな部分の変更もあるが,ダッシュボードのデザインがかなり変わっている。詳しいことは, WordPress Codex 日本語版 Version 3.8 を見てほしい。
いつものことだが,マルチサイトの親の言語のせいか日本語版のアップデート情報が表示されない。 wordpress-3.7-ja.zip をマニュアルダウンロードして,アップグレード。
今回もまた, 3.7 と同様, ca-bundle.crt 関連で下記の注意が出た。
注意: https://MySiteName の更新の際、問題が発生しました。サーバーがサイトに接続できない
かもしれません。エラーメッセージ: SSL certificate problem: self signed certificate in certificate chain
この機会に, Oiram の回避策 PDF版をやることにした。これで,この件済み。
xrea の s370 と @pages の www39 でもアップグレードした。両方とも,全く問題なし。
追記(2014/6/22):
WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。
Dec-12 01:43:06UTC に PHP5.5.7 が出た。
ChangeLog によれば,バグフィックスに, CVE-2013-6420 についてのものが含まれているようだ。
いつもどおり,我が家用 (Windows7HP+SP1(x86)) として,VC11 x86 Thread Safe 版の php-5.5.7-Win32-VC11-x86.zip を落としアップデート。 VC11 がいるので,インストールがまだの場合は PHP のコンフィグの前に vcredist_x__.exe を入れておく必要がある。
php.ini-production には何も変更はなかった。
php5apache2_4.dll はオフィシャルバイナリに含まれているので,新旧のファイルを入れ替えて php.ini を放り込み, Apache をrestartするだけ。
新規に導入する方は,必要なら「Windows7上にWamp系WebServerを建てる-#2。」を参考にしてください。
phpMyAdmin 4.1.0 が出た。 「このバージョンから,最低でも PHP は version 5.3, MySQL は version 5.5 が必要です」ということで, ChangeLog もてんこ盛り。アップデートした。
phpMyAdmin-4.1.0-english.zip をダウンロード,ファイルを展開,旧の config.inc.php を展開でできた phpmyadmin フォルダにコピーし,すべてをアップロード。(詳しい話は「Windows7上にWamp系WebServerを建てる-#3。」を見てください。)
ところで,新しい config.sample.inc.php では次の行が増えていた。
/* User used to manipulate with storage */ のところに
// $cfg[‘Servers’][$i][‘controlport’] = ”;
/* Storage database and tables */ のところに
// $cfg[‘Servers’][$i][‘users’] = ‘pma__users’;
// $cfg[‘Servers’][$i][‘usergroups’] = ‘pma__usergroups’;
// $cfg[‘Servers’][$i][‘navigationhiding’] = ‘pma__navigationhiding’;
最後の部分の the doc/ folder の話のすぐ上に
/**
* Should error reporting be enabled for JavaScript errors
*
* default = ‘ask’
*/
//$cfg[‘SendErrorReports’] = ‘ask’;
そんなわけで,アップロード後最初のログインで,下のほうに「phpMyAdmin 環境保管領域が完全に設定されていないため、いくつかの拡張機能が無効になっています。理由についてはこちらをご覧ください。」というメッセージが出る。
クリックして見に行くと,3つ警告が出ていた。
$cfg[‘Servers’][$i][‘users’] … not OK [ Documentation ]
$cfg[‘Servers’][$i][‘usergroups’] … not OK [ Documentation ]
Configurable menus: Disabled
$cfg[‘Servers’][$i][‘navigationhiding’] … not OK [ Documentation ]
Hide/show navigation items: Disabled
同時に,どうすればいいかという方法についても下記のように書いてある。
Quick steps to setup advanced features:
Create the needed tables with the examples/create_tables.sql.
Create a pma user and give access to these tables.
Enable advanced features in configuration file (config.inc.php), for example by starting from
config.sample.inc.php.
Re-login to phpMyAdmin to load the updated configuration file.
examples/create_tables.sql を使ってテーブルを作るか,手動で作るかは,環境によりけりだと思うが,私の場合は,前からのものがあるので,手動で行った。(より詳しい話が必要な場合は,「Configuration storage」と「phpMyAdmin configuration storagephpMyAdmin 環境保管領域」を見てください。)
それあと,自分の config.inc.php に今回増えた行を付け加え,さらに,付け加えた行のうち3行を下のようにアンコメントした。
$cfg[‘Servers’][$i][‘users’] = ‘pma__users’;
$cfg[‘Servers’][$i][‘usergroups’] = ‘pma__usergroups’;
$cfg[‘Servers’][$i][‘navigationhiding’] = ‘pma__navigationhiding’;
再ログイン。アラートは消えた。ミッション完了。
