本家のお世話-#90。(Opcacheを使う)

 先の一昨日,自鯖上で, 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 のキャッシュの効果は,多分,大したもんなんだろう。

Details
Details
Files
Files

 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 で問い合わせが見当たらないといわれたときには驚いた。それに,私の英文の書き方が言葉足らずで,マルチポストをやった形になってしまった(^_^;)。彼らからもらったヒントが役に立ったわけだから,許してもらおう(汗)。

  1. Jeremy Herve が, define( 'JETPACK_CLIENT__HTTPS', 'NEVER' ); を使うといいかもしれないと教えてくれたが,うまくいかなかった。
  2. Richard Archambault が SSL が関係しているかもしれないので, SITE_URL を調べてみるように言ったので,チェックしたが, http://o6asan.com になっていた。これなら問題ないはず。
  3. naokomc が, WordPress.com とうまく連携できていない場合,自分のサイトでも所有権がないように見えるのだと教えてくれたので, Richard が言っていた SSL のことをもう一度考慮してみることにした。
  4. で, 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。

我が庭に,雪が降る (^o^)。

 ブログではなくて,この冬2度目の雪が降ったので,撮ってみた。今日もすぐに止んだけど。出来栄えは,ウーム……???

本家のお世話-#89。(MariaDB5.5に移行)

投稿アップデート情報  追記(12/21)  追記2(12/25)  追記3(2014/6/6)

MaintenanceNotice 昨日は,一生懸命取り組んでいた。何にって,くりくりさんとの話にも出ていた 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 をアンインストールする。

  1. すべての WordPress プラグインを無効にする。
  2. さっきやったサーバのバックアップとは別に,すべてのデータベースを sql ファイルとしてバックアップする。
  3. ダッシュボードのツールから WordPress のすべての記事・コメントをエクスポートする。この時点では,可能なら WordPress Importer を使おうと思っていた。後述の理由で,結局あきらめたが。
  4. サービスを停止する。
    コントロールパネル >> 管理ツール >> サービス
    MySQL のサービスを選んで,停止。
  5. サービスを削除する。
    cmd.exe を管理者として実行。
    > sc delete MySql
  6. フォルダ MySQL と MyDATA を削除(<--- これらには,自鯖の MySQL 関係のものがはいっている)。

ステップ2 MariaDB をインストールする。

  1. mariadb-5.5.34-win32.zipMariaDB からダウンロードする。
  2. Installing MariaDB Windows ZIP packages にざっと目を通してから, mysql_install_db.exe について を読んだ。
  3. Zip を展開する。 MariaDB と MyDB というフォルダをサーバウェア用のパーティション Drive_SV に作り,展開でできたものを MariaDB フォルダにコピーする。

    cmd.exe を管理者として実行。
    > cd Drive_SV:\MariaDB\bin
    > mysql_install_db.exe –datadir=Drive_SV:\MyDB –service=MyDB –password=secret

    これにより,root のパスワードが設定され, MyDB の中には my.ini が作られる。

  4. コントロールパネル >> 管理ツール >> サービス
    MySQL のサービスを選んで,開始。
    もし,「スタートアップの種類」が「自動」になっていない場合は,自動になおしておく。

ステップ3 phpMyAdmin で MariaDB にアクセスする。

  1. phpMyAdmin から root として,MariaDB にアクセスする。
    バックアップしていた phpmyadmin データベースをインポートする。
  2. WordPress 用ユーザを作り, WordPress データベース用に Grant 以外のすべての privileges を付与し Global privileges は一定与えないこと。パスワードも設定する。 WordPress 用のデータベースを作成する。 collation は utf8_general_ci にする。
    ログアウト。

WordPress Importer でインポートしたが,結局止めてしまった理由。

 新しく WordPress をインストールした後, WordPress Importer でコンテンツをインポートした。間の悪いことに作業がほぼ終わってから,このプラグインが <object> などのある種のタグを移してくれないことに気づいた。 html 関係のどんなタグが対象になるのか調べるのも鬱陶しくて,この方法はやめることにした。これに結構時間かかってたんだけどね。

ステップ4 phpMyAdmin ですべてのWordPress のデータを復元する。

  1. InnoDB を使いたいので,バックアップファイル上の ‘ENGINE=MyISAM’ を ‘ENGINE=InnoDB’ に置き換えた。
  2. phpMyAdmin に WordPress ユーザとしてログインし,データベースにアクセス。
    WordPress のデータベース上の現データをエクスポート。
    現在の WordPress のデータベース上のテーブルをすべて削除。ところで,バックアップした sql ファイルには,全部が含まれていて大きいが,これを編集するのも面倒なので, php.ini のアップロードの制限を作業中だけちょっと変更した。
  3. バックアップをインポートしたら,エラーが出た。アララ。
         #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追記)

  4. もっ一回,全テーブル削除。

    書き換えたファイルをインポートしたら,あらまたエラーが……
         #1064 – You have an error in your SQL syntax;

    これは,えっと,私のミスであった。 FULLTEXT indexes を消したときに “,” の消し忘れ。
         KEY `post_author` (`post_author`),   <<--------この ',' が残っていたのヨ。      ) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=xxxx ; で, ',' を削除。

  5. 全テーブル削除。

    3度目の正直。ナンチャッテ。インポート。おっ,通った。

ステップ5 通常営業に戻る。

  1. WordPess にログイン。
    全プラグインを有効化して,挙動をチェック。

    .htaccess を元に戻して,メンテ終了。

  2. 実のところ,作業後, 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 のページの示唆通り,元に戻したほうが賢明だ。

  1. phpMyAdmin にログイン。
  2. WordPress 用のデータベースを選択。
  3. wp_posts テーブルを選択。
  4. 上のナビバーから ‘操作’ を選択。
  5. ストレージエンジンを Innodb から MyISAM に変更。
  6. テーブルオプションの ‘実行’ をクリック。
  7. phpMyAdmin をログアウト。

 ところが,この変更を YARPP が認識してくれない。こういう操作のための機能も用意されているのだが,うまく働かない。解決策を探しに, YARPP サポートフォーラムに行ったら, MyISAM Override check doesn’t work というのがあった。 hussong の方法をやってみた。

  1. まず, YARPP を無効にする。
  2. phpMyAdmin にログイン。
  3. WordPress 用のデータベースを選択。
  4. wp_options テーブルを選択。
  5. 上のナビバーから ‘SQL’ を選択。
  6. SELECT * FROM `wp_options` WHERE option_name LIKE "yarpp%" をやる。
  7. 見つかったのをすべて削除。 yarpp_fulltext_disabled = 1 というのがあるはずなので,これを yarpp_fulltext_disabled = 0 に変更する。
  8. phpMyAdmin をログアウト。
  9. YARPP を有効にする。
  10. 元の設定はすべて消えてしまうので, YARPP の設定をやり直す。

 これで,タイトルと内容の検討オプションが使える。ヤレヤレ。

追記2(12/25):
 「Jetpack の不具合について。」というのを書いた。

追記3(2014/6/22):
 WordPressでの「SSL3_READ_BYTES:sslv3 alert handshake failure」を解決というのを書いた。

本家のお世話-#88。(WordPress3.8へアップグレード)

投稿アップデート情報  追記(2014/6/22)

 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」を解決というのを書いた。

本家のお世話-#87。(PHP5.5.7へアップデート)

 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。」を参考にしてください。

本家のお世話-#86。(phpMyAdmin 4.1.0へアップデート)

 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’;

 再ログイン。アラートは消えた。ミッション完了。

KeyPasoに手持ちのVista Businessを入れてみた。

投稿アップデート情報  追記(3/19)  追記2(2014/10/16)

 KeyPaso に手持ちの Windows Vista Business を入れてみた。 KeyPaso は昔クイックサンで買ったもので紹介では Elite II と書いてあった記憶があるのだが,今回調べてみたら, Elite 4 みたいだ。

 KeyPaso は茶の間の PC として使っていたのだが,動画を見るときにフリーズばかりで使用に堪えないので,お払い箱にした。しかし,まだ動く。これを自分用の動画見 PC にしようと思って,弄ってみた。 Windows XP は 2014/Apr/8 UTC まででサポートが終わるので, OS は手持ちの Windows Vista Business に変えた。 VIDEO & GRAPHICS については, Built-in にしても RADEON 9200 SE PCI にしても力のなさは否めないが, RADEON には TV-Out があり, Built-in にはないので,ディスプレイの関係で入れ替えるというか, Built-in を無効にして, RADEON のほうを使うことにした。

 スペックはこんなものである。
 

 
インストールされた OS Windows XP Professional SP3 Windows Vista Business SP2
CPU Intel(R) Celeron(R) 2.40GHz (Northwood-128) Socket 478 mPGA
メインボード SiS-650
メモリ 2GB (1GBx2) PC2700 DDR SDRAM(166 MHz)
システム BIOS Phoenix Technologies LTD ver. 6.00 PG 2003/04/04
VIDEO & GRAPHICS Built-in SiS651 RADEON 9200 SE PCI
ネットワーク SiS900 NIC
オーディオ SiS 7012 Audio Device
USB 2.0 SUPPORT USB 2.0 ポート 4個
iLINK IEEE-1394 1394 ポート 2個

 クリーンインストール後にデバイスマネージャにあった黄色の「!」マークは SiS 7012 Audio Device についての1個だったが,これ用の新しいドライバは存在しないようだった。最終的に Windows XP (x86) 用の a12112d.zip で使えることがわかった。インストール後も,互換性ナンチャラのメッセージが出るけど,無視。

 電源オプションは「高」,お約束の Aero は off ,なにしろエクスペリエンス インデックスのグラフィックスの値が 1.9 なんだもの。解像度は,茶の間の 50インチモニタとは違うので最低の 800×600 を選択。状況は,かなり改善したが,まだ,フリーズする。結局, RADEON 9200 SE PCI のドライバをあきらめて標準 VGA グラフィックアダプタのドライバにしたら,どうにか落ち着いた。書き忘れるところだったが,インストール前に,ファンやCPUの掃除はした。

 というわけで, KeyPaso は,今,寝室にある。まあ,満足。

追記(3/19):
 VL-17VS2 を使おうと,努力した話を書いたので,興味があれば,そちらもどうぞ。「富士通 30 ピン ディスプレイ コネクタ —>> DVI-D。

追記2(2014/10/16):

 昨日の Windows Update 後,突然音跳びするようになった。ドライバは,昨日までは a12112d.zip 由来のものを使っていた。最終的には,どこで手に入れたか忘れた,すごく古い Avance AC’97 Drivers for SiS を入れたらよくなった。どこで手に入れたかはっきり覚えてないが,古さから考えると, KeyPaso についてたドライバ CD のものじゃないかと思う。