ポルカの日記 | CSSベースのHTMLレイアウト入門講座

4年目に突入した我がiMac27。
パフォーマンスは、いまだぜんぜん充分。
この調子だと、あと1回はOSのメジャーアップデートを越せるだろう。

ただ、毎年暑い。




くぼみみたいな場所で作業しているので
空気の流れが悪く、熱が溜まっていくようだ。
50cm位離して使っているデカいモニタの前には熱の壁がある。

快不快はヒラメキや作業の粘りに影響するので
なんとか解決したいと思って何もせず、
CPUが50℃後半になったらエアコンをつけるようにしてきた、が、
ここにきて小さいUSB扇風機を導入。


ミニサボテンの鉢植え位の大きさだ。
http://goo.gl/LtXPMe


朝9時13分頃、モニタ付近の室温28℃、FanControlのベース速度2500rpm
iMacCPUヒートシンクは45℃でキープ。
背中から約1.2Mのところで通常の扇風機を首振り弱でまわす。

モニタからの熱は相変わらずで、
これはLEDモニタにでもしない限りは難しいのかな、と思うが
ひとまずこれでしばらく様子を見ることにする。

静音タイプらしいけど、独特な羽音と回転音が僅かに聞こえる。
我慢できないほどではないけど、今まで静かだったので慣れが要りそう。
とりあえず2台買わなくて良かったかな、とは思う。

お世話させて頂いているお客様のサイトに
不正アクセスがあり、勝手にメールを送信するファイルを作られているので
SpamCopなる、国際的なスパム摘発組織？から連絡が入っているとのこと。

「phpinfo.php」とか、本当にあってもおかしくないようなファイルが業していたのだけれど、
他にも、いくつかのPHPファイルに改ざんされていたようだ。
（改ざん内容は詳しくはわからないけれど、
そのファイルが動作すると強制的にどこかのサイトへ転送させるような感じだった）




そのまま放置すると、どうやらサーバがブラック認定されてしまうらしく、
レンタルサーバ会社から、即時の対処を求められた。
また再度、迷惑がかかっている連絡が入ったら、
それこそ即時にアカウントを停止するとも。



つまり、次のような事態になる。
１）サイトが見られなくなる。
２）他社サーバに引越するにしても手続きに時間がかかりそう。（空白期間ができてしまう）

うーむ、想像したくない。。。




この不正アクセスは約1ヶ月の間に2回発生していて、
なんと2回目の復旧作業の2日後に3回目が発生していたらしい。
（どうやら2回目の作業で、取りこぼしがあった感じ。）

結局、サーバ会社の要請通り、サーバにあるファイルを全て削除してから、
サイトを最初から構築しなおすことに。

5、6年位運用されていることもあって、
1GB近いファイルで構成されており、復旧に正味で丸一日要した。




以上は騒動の顛末ですが、
ここから、サイト制作・運営に関わる業者としてのお願いです。

更新できるホームページとして
WordPressの他、CMSを使っているサイトが増えているのですけれど、
便利な反面、不正利用するための入口が付いている状態でもあるので、
運用されている方は注意してください。

サイト規模にもよるけれど、復旧は厄介です。

サーバごとにクセみたいなのがあって、それを読みつつ、
CMSのクセとサイトの構成を見ながら対処を行うので、難度の高い作業になります。

CMSの自動インストールとかの便利機能をサーバが用意していることも多いけれど、
（それでWordPressの普及が早まったのだろうと思うけれど）
「自動」でできることはトラブルが起こったときには、対処が難しいです。
（本来必要となるファイルのアップロードや記述を自動でしてくれるので便利だけれど、
ブラックボックスの中で作業されるので、「ある/ない」「要/不要」がわからない状態になっているため）

自動的につながるはずのことも、つながらない可能性を見越して、
アナログ的にコピペでCMSの登録した記事をエクセルに移したり、
設定項目を記録したりと工数はかなり多いです。

できれば、保守やメンテサービスを利用されることをオススメします。

SOY1.4.1aしか使えない状況の中、
（今の最新は1.8.6）
不正アクセスがあったことで、SOY本体とSOYのルートフォルダの入替を余儀なくされ、
削除＆新規インストールした後に、

sqlite版での簡易的なバックアップからの復元方法をとり、
SOY本体とSOYのルートフォルダ内のDBをバックアップから戻したものの、

SOYページ（テンプレート）を更新すると、
トップページ以外にサイト全ページが真っ白になってしまう事象が発生。



●rewiteがうまくいっていない？
●パーミッションの設定不備？
●必要ファイルの不足？
●新規インストールしたSOYとDBファイルの整合性？

ちょっと特殊な事情として、
いつものSOY　sqlite版インストールのように
必要なフォルダをガバっとアップロードすると、
設定方法が悪いのか、正しく動かないサーバで、
サーバの管理画面からインストールする必要があることだ。

このことから、
●インストール後にDBファイルを追加すると、おかしなことになるのかも？

などと、いろいろ考えるも今は原因不明。
現在対処中。




最終手段はSOY内の設定（ページや記事など）を
アナログ的にバックアップして、
ほんとうの意味でのサイトを再構築するしかないが、、、

ロールオーバーをさせているときに、
Firefoxだけ、ぴょこっと不用意に動いてしまうのを抑えるスタイルシートがこれ。
box-shadow: #000 0em 0em 0em;

そのときはjQueryでボタンをfadeIn, fadeOutさせていたときに発生。

どなたかのブログで紹介されていて、
助かったのだけれど、URLを控えるのを忘れた。。。

クライアントのサイトにおいて、
●SOY CMS 1.8.3
●SOY INQUIRY 1.1.16
●PHP 5.3.3
の組み合わせで複数のサーバエラーが発生。
今は改善して、まもなく接続制限の解除申請を行うところまで来た。
（2015/01/09　既に解除済み）




●使っているサーバ、
●PHPのバージョン、
●PHPの初期設定、
●SOY CMSのバージョン、
●SOY CMSでの設定、
●稼動させているプラグイン、
●その組み合わせの相性、
などなど、
複数の要因が絡むので、特殊なケースかも知れないが、
整理も兼ねての覚え書き。




最初の問題発生は、以下の2点。
１）ページの表示が激遅になっていることと。
２）タイムアウト？による500エラーが頻発すること。




トップページの表示速度が約12秒と遅くなっている原因は
「SOY CMSを導入したこと」だと最初は思ったので、
クライアントと相談の上で、以下の高速化手法を立て続けにとる。

●CloudFlare（CDN）
●FirstCGI
●mod_pagespeed
●Etag設定
●mod_expires（キャッシュ設定）
●gZip圧縮

ちなみにサーバはXserverで、PHPのバージョンは5.3.3。

このころ「過剰負荷により接続制限をかけている」との連絡が
Xserverから来たと連絡が入る。
つまり、激遅だったのは、この制限によるものだった。
ここから、エラー解消に向けたバトルが始まる。




Xserver管理画面からエラーログを参照すると、
以下の2つのサーバエラーが発生していた。

SystemException in API_Linux.cpp:172:
（↑　アクセス集中したときに起きるエラーのよう）
Premature end of script headers:
（↑　原因がわからなけれど、とりあえず問題が起きていることを示すエラーのよう）

ネットで「SystemException in API_Linux.cpp:172: 」を調べると
4、5ページほど同じエラーについて書かれたページに当たった。

ある方が、WordPressそのものを入れ替えてエラーが出なくなった、
と書かれていたけれど、今回のケースでは稼動中のECサイトでのことなので、
最終手段にしか使えない手と考え、他の方法を模索することにした。





各エラーの参照先は
同じディレクトリをいったりきたりしてできたような
実際には存在しない長いURLになっていて、
この「いったりきたり」が負荷過剰になった原因かもと予想。

もしかすると、SOY CMSが使う転送の仕組み（.htaccessのRewrite）と、
うまくかみあっていないのかも、と予想はするものの原因は特定できず。




SOY CMSのバージョンを1.8.3→1.8.6にアップデート
するも
管理画面が真っ白になって表示されず、いそぎ1.8.5に戻す。

一旦、問題解決のために、それまで施した高速化手法を全て外した後、
他の方がブログで紹介されているSOYルートサイトの.htaccessの記述で
Rewriteを「/」から始まるルートパスに置き換える。
＜参考ブログ＞
http://blog.netandfield.com/shar/2012/10/soy-cms-ocn.html

【旧】
RewriteRule ^(.*)$ index.php?pathinfo=$1&%{QUERY_STRING} [L]
↓
【新】
RewriteRule ^(.*)$ /index.php?pathinfo=$1&%{QUERY_STRING} [L]

※「SOYでのルートサイト」以外の「SOYでのサイト」に上記を施すと
表画面がブラウザで表示されなくなった。




ここで、あらためてSOY CMSを1.8.6にアップデートする。
今度は管理画面が表示された。

ここまでの作業で、
エラーは「フォームのあるページ（SOY INQUIRY連動ページ）」に集中した。




そこで、
SOY CMS内に登録しているフォームページを削除し、新しく作りかえた。
このことで、データベースに残っていたかも知れない誤った記述がリセットされることを期待。

それと、SOY INQUIRYを
1.1.16→1.1.17へアップデートを行う。

すると、エラーが発生しなくなった。




そこから24時間後時点でもエラーがでていないことを確認し、
高速化手法を再度戻していく。

●CloudFlare（CDN）
●FirstCGI
の2つは使えた。が、

●mod_pagespeed
●Etag設定
●mod_expires（キャッシュ設定）
●gZip圧縮
を使うと、わけのわからない長いURLがでるエラーが復活してしまったので、
使わないこととする。




解消まで1週間ほどかかった。
年末年始を挟んでのことで、サイトへのアクセスが少ない時だったのが、
何よりの幸いだった。




あくまでも、今回のケースでではあるが、
まとめると、以下の4つの対処によりエラーは解消された。

１）SOYルートサイトの.htaccessの記述を一部変更（ルートパスに変更）
２）SOY CMSおよびSOY APPをアップデート
３）エラーが集中しているのSOYページを削除し、作り直す（登録し直す）。
４）高速化に使うのはCloudFlare、FirstCGIのみ。



特定箇所の問題、というよりは、
複合的な原因だったのかも。

厄介だったのは、一旦エラーが出だすと、
エラー前の状態に.htaccessを戻しても、
連鎖するようにエラーが出続けたことだ。

もしかするとCloudFlareの影響かでキャッシュが残り、
その古い情報とバッティングして
エラーが解消しにくい状況になっていたかもしれない、とか、

.htaccessの保存時か、
アップロード時の事故だったのか、とか、

さまざまに想像するが、
エラー連鎖が発生した時の効果的な対処はいまだにわからない。




今は収まっているので、様子を見ながら、
一旦取り下げた高速化にチャレンジする予定。