カテゴリー
everyday life

丈夫になったもんだ。

The same article in English

 昨日はひどい目にあった (^_^;)。

 4日ぐらいから,なんでこんなに眠いんだろうと思っていた。2日には年始のお客さんが来たが,3日には十分休んだし,その後,特に何もしていない。夜もよく眠っていた。4日の朝起きたとき,何となく扁桃腺がはれているような痛みがあったが,ほかの風邪の症状はなかったし,夕方までには扁桃腺の痛みも消えた。

 5日の朝も,なんか変な感じだったが,特に風邪といえる症状はなかった。夕方には,初泳ぎに行った。1週間ぶりくらいだったが,帰ってきたときには,ずいぶん気分がよくなっていた。

 ところが,夜は眠れず,仕方がないので,昨日はいつもより早起きした。出かける約束があったが,とてもいけそうにない。メールより電話がいいが,それには早すぎるので,8時になるのを待った。待っている間に,状態はどんどん悪くなっていった。

 8時になった時には,声は出ないし,頭は痛いし,電話もemailも無理になっていたので,家族に連絡をしてもらった。

 何とか,朝食を取り,解熱剤を飲んで,寝室に行った。持病では,まじめに病院の行くのだが,風邪のときなんかは,病院が大嫌いだ。家族は,仕事始めだし,出かけていった。

 ベッドに入ったが,20分もしないうちに,朝食と薬を吐いてしまった。悪寒が続いている。再度,ベッドに入り眠ろうと努力した。自分では,すごく長い時間がたった気がしたが,起きたらまだ9時だった。悪寒が治まらない。とにかく眠ろうと努力した。次に起きたら,10時だった。幸いにも悪寒は治まっていた。熱があげどまったらしい。少し吐き気があったので,脱水症状を起こしかけているなと思い,少量の水を飲んだ。水で首筋を濡らすととても気持ち良かった。飲んだ水のせいか,幸いにも,吐き気は治まっていた。茶の間から体温計を持ってきて測ったら,39.6℃だった。高すぎだろ(笑)。

 もう一回,解熱剤を飲みたかったが,さっき全部吐いたのかどうか確信がなかったので,もう一度眠って1時を待つことにした。次に起きたら,お昼だった。茶の間で時間をかけて昼ご飯を食べ,改めて解熱剤を飲んだ。寝室に戻り,また,ベッドに入った。

 起きたら,夜の8時になっていた。38.3℃。よく寝た。気分もずいぶんよくなった。

 病弱な子供だった。しかし,20歳を超えるまで,高熱の経験がない。当時のかかりつけの医者は,熱が出ないので,手掛かりが少なくて困ると言っていた。彼は,ぎりぎりまで我慢しないで早く言いなさいと言っていた。彼は,私を我慢強い子と思っていたらしい。今思うと,彼は間違っていた。私は我慢強いのではない,痛みに鈍いのだ。

 30代半ばを過ぎるまで,しばしば入院した。日常的に学校や仕事を休むということはなかったが,その羽目になったときの入院はいつもかなり長いものだった。

 昨日のことが,30代半ば前の私に起こったとしたら,絶対に病院に行かなくてはいけなかっただろう。しかし,今,この記事を書いているわけで,丈夫になったものだと,感無量である。

カテゴリー
everyday life

氏神様に初詣。

The same article in English

 夜暗いうちに,一時ごろかな,歩いて3・4分の氏神様に初詣に行ってきました。

 いつもは,誰もいない境内に,大晦日から三が日くらいだけ,人気があります。今年は,石段の両端に蝋燭が灯され(写真の分は中央ですね(滝汗),さらに下の石段においては,両端だったもので,そのほうが印象強くて — (^_^;)),なんとお神楽(踊りはなし)も聞こえていました。これは,お初。例年は,そういうものはないのですが。

 それでも,お参りはまあまあいました。これは,例年並み。

篝火
篝火
蝋燭
蝋燭
おめかし
おめかし – (^_^)
カテゴリー
everyday life

あけましておめでとうございます。

 あけましておめでとうございます。
 皆様,本年もよろしくお願いいたします。

 午年ですねえ。現実の馬は見るのも乗るのも好きです,残念ながら,ここ10年ばかりそのチャンスは全くありませんが,そのうちにも一回乗って,海辺なんかをうろうろしてみたいなあ。

 皆様にとって,今年がよい年でありますように。

おめでとう
カテゴリー
WordPress

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

The same article in English

 先の一昨日,自鯖上で, 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について」というページを教えてくれた。こういう比較サイトはほかにもいろいろあるから,やってみる前にググって見るといいと思う。

カテゴリー
WordPress

Jetpack の不具合について。

The same article in English

 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 ); を元に戻したが,無問題だった。

 というわけで,不具合は解消した。しかし,分からないのは,なんでこれが起こったかなんだよね。それについては,いまだに納得がいっていない。

カテゴリー
everyday life

こんなことがあっていいのか。

The same article in English

 今月20日に, Reuters が “Exclusive: Secret contract tied NSA and security industry pioneer” というすっぱ抜きをやった。 23 日には,ミッコ・ヒッポネン が “EMCおよびRSAのトップ達への公開書簡” を書いた。

 こんな話を信じたくはないが,ミッコがこんなものを書くということは,あらかた真実なんだろうと思わざるを得ない。 NSA にとっては,ある意味正規の仕事をやったにすぎないと言えないこともないが, RSA のほうからいうと恥を知ないにもほどがあるということになる。もちろん,片方の側の記事を読むだけでなく,反対側の記事,例えば NSAとの関係に関するメディアの主張に対するRSAの対応 (魚拓です)なんかも読まなければいけない。

 しかし,一番悲しいことは, RSA への信頼が損なわれたということである。

カテゴリー
everyday life

コメント見落とし。

 本日,シバケンさんのコメントにお返事を書くときに,たまたま,気づいたコメントがあった。「あれっ,これ読んでいないぞ」ということで,見に行ったら,やはり,お返事もしていなかった。

 くりくりさんが,「CentOS6の練習-#10(Apacheのrpmを作る)。」につけられたコメントだった。

 なんでだろうと思ったのだが,そういえば yahoo.de のアカウントのパスワードリセットが来たころだと思い当たった。 yahoo.de のアカウントはブログの連絡用に使っているものだが,なんか日頃と違った動きをすると,すぐパスワードリセットのお願いが来る。で,リセットするまで,アカウントはロックされている。だから,パスワードリセットをして,WP Mail SMTP の設定を直すまでは, WordPress からコメントのお知らせメールが来ないということになる。

 今回も,対処後,トップの最近のコメントの一覧は確認したのだが,「停電???」の話で珍しくコメントの多かったときなので,見落としてしまったらしい。元記事が少し古いものだったので,その後も,気づかなかったらしい。やはり,こういうときは,ログインして,コメントの管理ページを見ないといけないと,改めて反省。

 くりくりさん,ご覧になってますか。お返事が遅くなって,すみませんでした m(_”_)m。

カテゴリー
everyday life

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

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

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

The same article in English
投稿アップデート情報  追記(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.zip を MariaDB からダウンロードする。
  2. Installing MariaDB Windows ZIP packages にざっと目を通してから, mysql_install_db.exe について を読んだ。
  3. 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 が作られる。

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

カテゴリー
WordPress

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

The same article in English
投稿アップデート情報  追記(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」を解決というのを書いた。