日頃からお世話になっているレンタル・サーバーがあります。 今回、ｓ２２と呼ばれるコアサーバーで稼働中のメインのWordPressが閲覧できない障害が発生しましたので、ｓ２２コアサーバーのWordPressをハッキング(以後ハックと称す)(wiki)_して、記事ミラーリング運用中の他国サーバーと無料XREA国内サーバーに自動的に振り分ける緊急対策を記録します。
○障害発生日時：2019/10/28 04:15～ の詳細はここ_。



アイ・キャッチ動画（英語版WordPress:featured image）参照元を見る。利用に感謝！ 今回はフリッカーの動画ダイレクト・リンクを利用しており、リンク切れなどをテスト中です。

まず、正常動作中のWordPressを用意する

不断の努力で海外の無料サーバー上で稼動する英語版WordPressと、無料サーバーXREAで稼動する日本語版WordPressを運用する。 わたしが用意したWordPressのURLは以下の通り。

  • 英語版ワードプレス： ujikioo000webhostcom.000webhostapp.com
  • 日本語版ワードプレス： wordpress.fs4y.com
今回感じたのは、同じビル(？)、同じフロアー(？)に設置されたレンタルサーバーは、一度にダメージを喰らう可能性があるということ。 特にスプリンクラーが誤作動すると、同じフロアーに設置されたサーバー群は、全てが惨事発生状態となり、メンテナンス要員はパニックに陥る。 雑居ビルで同じフロアーに別の企業がテナントに入り、そこから火災警報装置が作動する。 フロアー全てを借りないと問題を残す。 下の階や上の階で火災警報が作動しても同じでスプリンクラーが自動的に作動するビルもあるだろう。 惨事発生対応を急ぐあまり、マニュアルを無視すると、バックアップを省いてしまう。 問い合わせの洪水を、そのままバケツで被ると、「直ぐにリカバリーするから（適当に）電話を切って！」と言いながら失敗を重ねてしまう。 よって、ユーザーは不断の努力で、遠く離れた米国や露西亜の無料サーバーでのミラーリング投稿を忘れない。 投稿記事に対するセキュリティーが心配なら、記事内容を全て JavaScriptファイル化し、別のサーバーから提供すれば良い。 いつでも JavaScriptファイルの配信をデーターサーバー側で拒否すれば良い。 HTMLタグが含まれる長文文章をJavaScriptファイル化するマクロは、既に公開しました。 マウスの右クリックだけで、YUICOMPRESSORで一次ダイエット圧縮を行って、Gzipで二次データー圧縮したファイルを生成する機能も公開しました。 それら３つのJavaScriptファイルセットをDNSラウンドロビン化したミラー・サーバーにWinSCPでミラーリング・アップロードを行って、JavaScriptファイルを配信すれば、WordPressを扱うサーバー１つ１つが低容量であっても、容量オーバーすることが近々の問題とはならない。 つまりデーターベース（以後DBと称す）内の記事情報がJavaScriptファイルの呼び出しだけになるので、DBデーターが肥大化しないし、 JavaScript呼び出しとは、画像の呼び出しと同じで、ブラウザーがキャッシュするので、再接続による通信を抑止し、接続アタックを受けても、DBの少ないデーターに対してサーバーのメモリーだけで、スムースにWordPress自身が解放に向かい易い。

参考：
アフィリエイトのリンクを貼り付けると近い将来「接続が終わらないブログ」に成長してしまうから貼り付ける時に改造を忘れない！_
参考：
JSとCSSとHTACCESSを連動させ世界最高速を夢見よう！_

サーバアクセス障害を起こしているメインのワードプレス

motpresse.fs4y.com
あらゆるハックを先行している WordPressです。

サーバアクセス障害の状況

  1. http://motpresse.fs4y.com
    接続すると、何と、 wp-admin / install.php を起動してしまう。 このファイル折角なので編集しました。 WordPressを知るクラッカー達は、喜んで言語を選択しますかね？（笑）
    1. FORMタグが、２箇所あるのでPOSTからGETに書き換える。
      何を送っているのかを明確にするためです。
    2. 同じく、action=を今回は被災していない可能な限り遠方となる別企業(?)の海外(?)の無料サーバー上のWordPressのURLに書き換える。
    WordPress本体の自動更新を受けると元の状態に初期化されるかも知れません。
  2. 障害を起こしているサーバーのWordPressのディレクトリーにはWordPress自身が用意した .htaccess が存在しますが、以下のコードを追加しました。
    米国のWordPressへは、日本語記事の全てをミラー投稿していないので、投稿記事数の多いwordpress.fs4y.comに転送させています。
http://motpresse.fs4y.com が復旧した後も、上記のハックは放置できると思います。
もちろん正常に .htaccess の ErrorDocument が処理されていることを確認する思いで、転送先の http://wordpress.fs4y.com/ の .htaccess にも、第三番目のWordPressに接続する ErrorDocument を定義しました。

ここで注意するべきは、 ErrorDocument の指定で、決してループさせないことです！ 同じサーバー、同じWordPressを指定することもご法度ですよね。 エラーを起こしているのに、自分自身に接続するのは、永久ループを起こしませんか？！ それと ErrorDocument で外部のサーバーのWordPressを指定するのですけど、その先の ErrorDocument で移動させる第三、第四のサーバーの行き着く先はループさせないことです！ 今回、ｓ２２で作成したメインのWordPressが閲覧不能となり、 ErrorDocument でwordpress.fs4y.comに向かいますが、wordpress.fs4y.comで指定した ErrorDocument で向かう先は海外のサーバーのWordPressで、そこでエラー処理は終点です。 永久ループさせない！（笑）

海外の無料サーバーのWordPressのテーマをハックする

WordPressのテーマの header.php の、 <!DOCTYPE html> の直下に以下のPHPスクリプトを追加しました。 問題を起こしているWordPressの wp-admin / install.php からの接続に特化した改造です。

GETで指定されたlanguageが無ければ何もしません！言語指定が日本語なら、日本語版WordPressに接続し、日本語意外ならサーバーもWordPressも英語版オリジナル生粋のWordPressに接続し直します。
あなたの選択肢で、テーマの更新を受けると初期化されるでしょう。

ErrorDocument の終点である海外の無料サーバーのWordPressですけど、海外の無料サーバーのWordPressがダウンしてしまうと当然のこととして機能しません。 wp-admin / install.php から飛ばされた接続は海外の無料サーバーのWordPressで破綻します。 仮にwordpress.fs4y.comが破綻すれば、接続不能となるか、 ErrorDocument によって、海外の無料サーバーのWordPressに接続を試みますが、ループはしないですよね。サーバーの異状による暴走列車の向かう先は、海外の無料サーバーのWordPressが終着駅です。（笑）

BASENAME:

わたしは、統べてのWordPressを、「設定 / パーマリンク設定 / 共通設定 / ・投稿名」に必ず設定しています。 つまり、WordPress内でユニークな記事固有のスラッグを、記事のURLとして利用することに統一化します！ WordPressの初期値では無いのですよ！ 「今さら変更できない！」と悲観する必要は無いですよ。 先ずはGoogle検索エンジンなどにＵＲＬの更新を通知するには、WordPressプラグインの「Google XML Sitemaps」(作成者：Arne Brachhold)を導入し、設定メニューから、「Notify Search Engines about your sitemap or your main sitemap and all sub-sitemaps now.」を実行すれば、 XML Sitemap がGoogleなどに対して更新されますよね？ 精神が「いらち」な、あなたは必ず異状終了します！（爆笑） 後は、旧パーマリンク設定アドレスから新パーマリンク設定アドレスに変換する、WordPress内でのリダイレクトを考えましょう！

わたしは、WordPressだけでなくて、MovableTypeだけでなくて、日本国内の無料のブログにも同時に投稿しています。いちいち新規投稿画面で投稿なんてしません！！ 単体記事用の雛形のMovableTypeのインポート書式テキストファイルを編集し、MovableType形式でのインポート処理を行います。 たったの一記事のインポートですから処理は短時間で終了します。

良いブログと利用できないブログを確認する！
MTインポートをサポートするブログをDISQUSやSNSで是非教えてください！
この記事のMT書式のインポートファイルを紹介しましょう！（笑）

URLは改竄しています。（微笑）

MovableType形式でのインポート処理時に重要なのは、 BASENAME: ですし、 KEYWORDS: などです。 少なくとも、ミラーリングしているWordPressもMovableTypeも、記事に対する BASENAME: が同じです。 これが、 .htaccess 内で登録した、例えば、 ErrorDocument 500 http://wordpress.fs4y.com%{REQUEST_URI} の%{REQUEST_URI}で間違いなく、誘導できました。 世の中の解説では、「ErrorDocumentで指定できるアドレスは同じサーバー内でしか指定できない」とありますので、動作が異なるのかも知れません。 あなたが利用中のレンタルサーバーのApacheなどのバージョンであったり、レンタルサーバーのシステム管理者が行うチューニング次第で異なるんでしょう。
どの番号のエラーだったかを知るには、アンカーを付加しますか？ 例えば:

それでも、リダイレクト出来ない記事はある

例えば、記事「motpresse.fs4y.com/khajiit/ Rigmor of Bruma 冒頭カジートの停止不具合を回避しよう！ _」でエラーでリダイレクトされるアドレスは、 http://wordpress.fs4y.com/khajiit/ ですが、記事のスラッグ値が違うので、%{REQUEST_URI}での便利な誘導が出来ません。 固定ページに「移動しました」記事を作成し、対応します。
老人の消えゆく神経細胞の記憶の底を掻き混ぜて思い返せば、わざわざ記事のスラッグをスマートなkhajiitに、手動で変更した記事が、あったような、無かったような。 折角の BASENAME: 制御なのに、手動で変えてしまっては、救われません！

想定外はどこでも起きる？

日本人がWordPressを開発したのなら、日本語で質問できるのでしょう。 WordPressの開発者と話すのに、「日本語版のWordPressでは・・・・・」などと英語で語っても、相手は理解に及びません。 だから、英語オリジナルのWordPressが欲しかったのです。 サーバー自身も、日本語環境に一切改造されていない英語そのままのサーバーが必要でした。 そこで、迷わず、米国内(?)の無料レンタルサーバーを入手し、こつこつと、日本語MovableTypeインポート用のファイルを喰わせては、公開する前に、コピーし、タイトルやキーワードや概要やタグ、そしてカテゴリーを機械翻訳してから、インポートさせて公開を重ねました。 今回のコアサーバーの惨事を経験し、ビルやフロアーから遠く離れたWordPressの存在は必須だなと思えました。

本当にサーバーが死んでしまったら・・・・・

Domain Name System_(以後DNSと称す)を編集し、適当なサーバーに、同じディレクトリーを作成し、 .htaccess を利用して転送処理を行わせる。 ディレクトリーの下には、何もファイルを作成しなければ、 ErrorDocument 処理で飛びますよね・・・・・

SNS

応援よろしくお願い致します！

s22の現状

2019/11/08 18:41

Error establishing a database connection と表示されるようになりました。 phpMyAdmin でＤＢを開けません。 WordPress のファイル群は、ハックを先行したmotpresse.fs4y.com_と、正常稼働中のwordpress.fs4y.com_にもujikioo000webhostcom.000webhostapp.com_にもアップロードしていますので、プラグイン群やテーマの暴走でＤＢが破壊されたとも思えません。 ｓ２２の管理者側のご努力を急がせることなく、以下の対応を実施しました。

  1. ｓ２２のpublic_html/ motpresse.fs4y.comディレクトリーをリネームしました。
  2. ｓ２２にpublic_html/ motpresse.fs4y.comディレクトリーを新規作成しました。
    この段階でディレクトリー下には何もありません。
  3. ｓ２２にpublic_html/ motpresse.fs4y.com/ .htaccessファイルを新規作成しました。
    ErrorDocument だけを定義しました。
一部サーバーで発生しました共有ストレージ障害の対応状況につきまして | お知らせ一覧 | レンタルサーバー CORESERVER（コアサーバー）_
2019/11/10(日) 21:00 ～ 2019/11/11(月)　09:00にメンテナンスが実施され、一度、リネームしたディレクトリーを元に戻して見ましょう！

2019/11/09 07:30

とうとう、プロセスで埋め尽くされたのか、ｓ２２が応答しなくなりました。

  1. ＤＮＳを編集_し、ｓ２２に向かわせていたＩＰアドレスを、問題を起こしていると公開レポートされているサーバー以外の、無料のXREAサーバーのＩＰアドレスに変更しました。
    nslookup motpresse.fs4y.com 8.8.8.8
  2. ｓ２２を含めて、問題を起こしていると公開レポートされているサーバー以外の、無料のXREAサーバーに、 public_html/ motpresse.fs4y.com 新規作成しました。
  3. public_html/ motpresse.fs4y.com/ .htaccess 新規作成し、 ErrorDocument だけを定義しました。
一部サーバーで発生しました共有ストレージ障害の対応状況につきまして | お知らせ一覧 | レンタルサーバー CORESERVER（コアサーバー）_
2019/11/10(日) 21:00 ～ 2019/11/11(月)　09:00にメンテナンスが実施され、一度、ｓ２２でリネームしたディレクトリーを元に戻して、ＤＮＳのＩＰアドレスも元のｓ２２に戻してみましょう！

2019/12/08 15:00

ｓ２２の応答が異様に遅くなる時があります。

  1. WordPressを別のコアサーバー_にコピーしました
    1. public_html/ motpresse.fs4y.com WinSCPを利用して、アップロード・ミラーリングしました。
    2. MySQLに最新SQLデーターをアップロードしました。
    3. ＤＮＳを変更_しました。
    快適になりました。
  2. ｓ２２を破棄することはしません！
    新たなサーバーのMySQLを無人自動バックアップします。 記事「特別なMySQLバックアップを自動的に実行する_」で話題にしました、ｂａｓｈスクリプトを新たなサーバーで運営し、毎日、MySQLデーターのバックアップを行います。 そのバックアップを、ｓ２２のphpMyAdminでインポートを重ね、いつでもｓ２２を復帰させることを可能とします。
  3. 記事「特別なMySQLバックアップを自動的に実行する_」で話題にしました、ｂａｓｈスクリプトは、ｓ２２で稼動を続けます。
    どこからも接続されないｓ２２のWordPressですから、毎日、SQLバックアップを自動的に行いますが、自動的にMD5が同じ古いバックアップは削除されます。バックアップファイルで埋め尽くされることはありません！
  4. 記事「特別なMySQLバックアップを自動的に実行する_」で話題にしました、ｂａｓｈスクリプトは、DNSの調整で公開接続されているWordPressのMySQLを、毎日、自動でバックアップを行って、DNSの調整で接続しなくなったｓ２２のMySQLには、phpMyAdminでインポートさせています。
    Version: 3.3 から、圧縮はZIPで行っていますし、拡張子は.sqlに変更していますので、phpMyAdminでのインポートも解凍することなく、迅速に完了しています。 これで、いつでもサーバーにトラブルが起きても、先ずはDNSの変更だけで、WordPressをスイッチできます。

特別なハックを追加

改訂日時： 2019/11/26 08:00

様々な想定を考慮して、 ErrorDocument の定義を行って、ある程度のエラー発生状況を把握できるようになった今だからこそ？ この際だからと、新しいリダイレクト構文４行を、メインWordPressの.htaccessに追加しました！ ｇｚｉｐ圧縮通信を許可しない環境の場合に、海外のサーバーのWordPressに接続をリダイレクトさせる制御です。 効能は、プロキシー・サーバー経由であるとか、古過ぎるブラウザーとか、ファイルの拡張子である.gzを読もうとしない接続者の場合に、接続を強制的にシャットアウトします。 メインのWordPressの応答が遅くなる接続を排除します。 想定されるデメリットは、世の中の良性のボッド接続を排斥する可能性があります。 悪性のボッド接続を排他するのは良いのですけど、良性のボッド接続であるGoogle検索エンジンを排斥するかも知れません。 悪性ボッド接続を特定出来れば、WordPressにリダイレクトしないで、どこか海外のサーバーの画像ＵＲＬにリダイレクトしても良いですよね。

Google検索に影響は無い模様です。

2019/11/18 00:00 So-netプロバイダ キャンセル So-netブログ 転出 - Google 検索_の結果で折角のトップページのトップに表示されていた検索結果が、今回のｓ２２トラブルで、何と、ミラーリング投稿していたXREA無料サーバー上の特異なサブ・ドメイン名のWordPressに置換されており、それはそれで流石にGoogle検索の対応は素晴らしいと感じておりましたが、ｓ２２トラブルが解消された今、元のｓ２２ 移転先のコアサーバー_の元のサブ・ドメイン名のWordPressのURLに戻っています！ 素晴らしいGoogle検索システムですね。

次の機器のブラウザーでは、正常にリダイレクトされました：

gzip (.gz) をサポートしないブラウザーを利用している(古い?)機器だと判明します。
PHP:
JS :
あなたのwindow.navigator.userAgent:
  • SONY PlayStation 3
    Mozilla/5.0 (PLAYSTATION 3 4.85) AppleWebKit/531.22.8 (KHTML, like Gecko)
参考：
JSとCSSとHTACCESSを連動させ世界最高速を夢見よう！
RewriteCond %{HTTP:Accept-Encoding} !gzip_
参考：
JSとCSSとHTACCESSを連動させ世界最高速を夢見よう！
管理者は別格なんです_

記事の改訂について

DISQUSコメントで案内します。

DISQUSコメントにログインし、DISQUSコメント枠の一番下段の左端のメール・シンボルをクリックすれば、DISQUSコメントがあれば自動的にメールで知らせてくれます。記事末尾のDISQUSコメントの表示が小さくてスレッドのデザインが狭過ぎると思うなら、DISQUSコメント本尊に接続_してみてください。


サポートが必要ですか？


Support AIt's free and fastSupport BIt's free and fastSupport CIt's free and fast

「無料サポート」に興味があれば
上の丸ボタンをクリック願います。
サーバーから9kbを受信しますのでお待ち願います。

※ 記事本文は別サーバーから JavaScriptファイルとして配信しており、配信元のサーバーにおける JavaScriptファイル(YUICOMPRESSOR済み)も、実際にあなたのブログが受信する gzip圧縮済みの JavaScriptファイルも、３０日間のキャッシュ流用を定義していますので、特にご質問の前にブラウザーのキャッシュを削除してから、再度のご訪問と閲覧をお願い致します。
※ DISQUSについては別管理ですので、毎回、最新のDISQUSを表示できています。 但し、ご自分のDISQUSコメントを編集した直後に編集後の内容に至らない場合がありますが、DISQUS表示の上部にある「あなたの言語でDISQUSメニューを再表示する！」をクリックしますと最新の状況を表示致します。 宜しくご理解願います。
※ どれだけ待ってもDISQUSが表示されない場合は「広告ブロック」機能を切ってみて下さい。
Google Translator.

良いブログと利用できないブログ


  • CLICK!