中小規模のWordPressサイトはe2-microで十分

ブログのサーバーをGoogle Compute Enginenに移して10日が経った。現在は最低構成のe2-microで運営している。おそらくアメリカなど特定のマシンを選んで入ればほぼ無料で導入できたはずだが、なぜかモントリオールを選んでしまいちょっと失敗したなあと思っている。

無料枠についてはGoogleが公式サイトで説明している。

サイトのレスポンスなどを考えると距離が近いアジアのほうがいいという話もある。

ところが、当初このサイトは「過度な負担がかかっている」という警告が出ていた。やはりサーバーのスペックを上げざるを得ないのかなどと考えた。

最初は何を対処していいかわからず放置しておいたのだがxml-rpcというサービスが問題であるということがわかった。このサービスは今ではほとんど使われていないのだが古いシステムとの間の整合性のためにサービスとしては生きていてDDoS攻撃などの対象になってしまうらしい。

試しにこのサービスを切るプラグインを導入して1日置いてみた。1日に一度程度あった急激なネットワーク負荷がなくなりCPUの負担も上がらなくなった。やはり攻撃の対象になっていたのだった。

ml-rpcが攻撃されるたびに内部では何らかの処理が行われていたのだろう。ついでに高負荷のエラーが消えた。

つまり、中小規模のWordpressサイトはe2-microで十分だがxml-rpc対策をしないとGoogleのシステムから「過負荷がかかっていますよ」という警告が出るということになるということになりそうだ。

「無料」というと良さそうだが代わりにサーバーの管理は自分でしなければならない。一応コミュニティは存在するがあまり当てにならないようだ。一方で、共用サーバーは自分の事情ではないところでサーバー処理速度が落ちたというようなことがある。共用サーバーと同じくらいの料金で専用サーバーが持てるのはいいことなのかもしれない。

どちらを選択するかはその人次第と言えるだろう。

このカテゴリーの記事の全文はこちらから読めます。

WordPressがDDoS攻撃を受けているようだ

VMのCPU使用量がときどき「ぐわっ」と上がることがあります。原因がわからず「サーバーの設定が悪いのかもしれない」などと思いつつ放置していました。ですがついに200%を超えてしまうことがあり「これは調査をした方がいいのでは?」と思い直しました。

アクセスログを見ると特定の時期に特定のIPアドレスからxmlrpc.phpにアクセスが集中しています。xmlrpc.phpってなんだろうと思い調べて見るとピンバックなどの通信に利用する機能だそうです。

ある記事によるとこれが脆弱性のもとになっていてここから侵入してシステムを盗む試み(ブルートフォースアタック)に使われるとのことでした。また単純にここにアクセスを集中させるとサーバーをダウンさせることもできるのだといいます。これが話に聞いたことがあるDDoS攻撃です。

xmlrpc.phpにアクセスすると「XML-RPC server accepts POST requests only.」という表示が出るのですが、一応推奨されているというプラグインが出ているので導入して見ることにしました。

2つ入れたのですが、今の所「XML-RPC server accepts POST requests only.」と表示され続けていて効果が出ているのかがよくわかりません。

バリデータというものがありこちらを使ったところ405が返されてプラグインが効いていることがわかりました。

おそらくこれまでのレンタルサーバーでも同じような攻撃は受けていたんだろうなあと思いましたが、サーバー管理などしたことがなかったので気がつかなかったのだろうと思いました。知らないって怖いですね。

この記事の全文はこちらから読めます。

WordPressを管理するログインユーザーに広告が出ないように設定を変更する方法

WordPressで記事を書いていて表示を確認するときに広告が表示されているとつい踏みそうになってしまう。今は自分で踏んでも違反に問われることはないようだが、かつてはアカウント停止の対象になっていたのであまり気持ちの良いものではない。

設定を調べていたらAdSenseの設定ではなくWordpress側で制御する方法が見つかった。Google Site Kitを利用する。早く教えてよと思ったので備忘録的にやり方を書いておく。

ただし手作業で入れたコードは制御の対象にならない。つまりウィジェット経由で入れたコードや「再利用可能」ボックスから設置したコードは今まで通りに表示される。

  1. Site Kitの設定にアクセスする
  2. AdSenseに移動し[Edit]を押下する。
  3. AdSenseのタグをSiteKitから挿入する。テンプレートに直接自動広告コードを入れていたりウィジェットに自動広告コードを入れている人はそれを取り除く。SiteKitの広告除外はSiteKitが埋め込んだコードしか制御できないようだ。なぜか英語と日本語が入り混じっていて「Let Site Kit place AdSense code on your site(SiteKitがAdSenseコードを入れるようにする)」となっている場合があった。
  4. Exclude from Ads(広告を除外する)のAll logged-in usersのスライドをオンにする。

これで設定は完了だ。

ウィジェットから入れた広告が表示されなくなるのも不安なのでMacを二台立ち上げてログインしていない場合には広告が表示されるがログインしている場合には広告が表示されないことを確認できた。

このカテゴリーの記事の全文はこちらから読めます。

MediawikiにAdSenseを貼り付ける最も簡単な方法

別記事で書いたように長年放置されていたMediawikiがスパムの温床になっていた。「このまま消してしまおうか」とも思ったのだが癪にさわるので逆に広告をつけてやろうと考えた。一応失敗も踏まえて試行錯誤した結果を書いておこうと思う。

まず絶対にやって置くべきこと

ドヤ顔で「絶対やったほうがいいですよ」と書くわけだがこれはどちらかというと自分の失敗を踏まえてのものだ。かなりトラフィックが食われるので下手したらこれでサーバーのリソースが食われかねない。

  • まず、新規のユーザー登録ができないように設定を変えておく。
  • 次に、ユーザー登録しない人がページを作れないように設定を変える。
  • さらにGoogle Analytics Extensionを導入して新規ページに誰かがアクセスしてきたらわかるようにする。ユーザー登録しているログインユーザーは記録から外されてしまうのだが登録していない第三者がページを踏んだ時にわかるので、仮に何らかの手段で破られても対策ができる。

ここまで済んだらようやくAdSenseコードを貼ることができる。
いろいろ検索して見たのだがやり方はいくつあるようだ。

  1. スキンを改良してコードを貼り付ける。このやり方を試そうとしたがスキンは単純なPHPではないのでどこを見ていいかわからなかった。おそらくこのやり方であれば自動広告が使えるはずである。
  2. 一応AdSenseのプラグインもあるにはあるのだがうまく使えなかった。テンプレートのどこに広告を置いていいのかがわからなかった。
  3. 告知ができるエクステンションがありHTMLコードをスキンのヘッダーに追加できる。javascriptも安心して追加できるのだという。エクステンションの名前はhtmletsという。今回はこれを使った。形式としてはなんでも使えるはずだが「サイトを自動的に分析して広告の置き場所を決める」コードは使えなかった。だがレスポンシブ広告やインラインブロック広告などは使えるようだ。あくまでも本来の目的は告知なのでページトップに広告がつく。だが設置方法はこちらの方が簡単だった。

htmletsのやり方は次の通りだ。

  1. htmletsエクステンションをダウンロードして設置する。
  2. htmletsが参照するhtml置き場のディレクトリを設置する。

新しく作ったディレクトリの中にhtmlファイルを置く。内容はJavascriptが入っているだけのものになる。

これで無事に広告の表示ができるようになった。

このカテゴリの記事の全文はこちらから読めます。

中途半端な状態で設置してあったMediawikiがスパム被害を受ける

Google Compute Engineとは全く関係がない話なのですがMediawikiがスパム被害を受けました。旧サーバーを整理し「そもそも何が帯域を食っていたんだろうか?」ということを調べたところ、mediawikiがかなりアクセスされているようだということがわかりました。

このMediawikiは何かの事情で編集ができなくなりローカルに移行した記憶があります。内容は過去の読書記録でした。ふと「もういっかい最初から入れて見たら入るのではないか」と思い立ち、PHPのバージョンが上がっていることを確認、データベースを最初から作り直したところあっさりと更新に成功します。その日はそれで「よかった」と思いました。

次の日にローカルにあった内容を復元しようとして「誰でも編集ができる」ことを思い出しました。間抜けな話ですがすっかり忘れていたんですよね……wikiがどんなものかを。

で、全てのユーザーを見て見たところ100アカウントぐらいのスパムアカウントと膨大な数の新規ページができていました。Mediawikiはアカウントの削除とページの削減が難しく、最終的には手作業で潰して行くことになりました。

誰にも設置を告知していないわけですから前からおそらく狙われていたんだろうなあと思いました。利用帯域量からみて膨大なページができていた可能性もあります。

ですが古いデータベースを削除しているわけですからどんな恐ろしいことが起きていたのかは今となってはわかりません。

知らないって……恐ろしいです。

慌ててGoogle Analyticsのプラグインを入れました。ログインユーザーは感知できないんですが、誰かがサイトを踏んだら検知できるようにするためです。

あと設定も変えました。知っている人から見ると「何をドヤ顔で書いているんだ」と思われるかもしれませんが……

$wgGroupPermissions[‘‘][‘edit’] = false; //ユーザー以外のページ編集不可 $wgGroupPermissions[‘‘][‘createaccount’] = false; //アカウント新規作成の禁止

ですね。

これだけはやっておいたほうがいいです。

ということで中途半端に設置してしまうと大変痛い目を見るんだなあということをしみじみと感じました。

設置者自身がログインできない状態だったわけで表示も崩れていたんですがまさか新規の参加者が自由にページが作れるとは……全く盲点だったわけです。

このカテゴリの記事の全文はこちらから読めます。

最後にAnalyticsの設定をやって終わりです

Googleのサーバーを選んで良かったと思うのは所有の認定などが簡単に終わるところです。最近Wordpress用にSiteKitというプラグインができたのでボタンを押してゆくだけで連結が終わります。


一応、今回気が付いたことのまとめを……

  • サーバー管理が勉強できる上に最新技術にも触れられる(無料で使えるものが非常に多いです)Google Cloudはいいサービスだと思いました。
  • しかしながら書き物だけに専念したい人には向かないサービスです。自分でバックアップを取ったりパッチを当てたりSSLの証明書をメンテナンスする必要があります。また最悪自分でサーバーを飛ばしてしまってもなんら保証がありません。
  • サーバー管理代行・コンサルみたいなサービスもあるようです。つまり一見さんが無料情報を探してもあまり大した情報が得られません。ただ企業向けのサービスだとセキュリティ対策なんかもあるでしょうからあながちそういう業者を責められないですよね。
  • UNIXの基本的なコマンドがわからないと途中で詰みます。私が最初にコンピュータをやった時代はMS-DOSだったのでコマンドラインにはそれほど違和感を感じないのですが「ターミナルが苦手」という人は使わない方がいいです。

この記事の全文はこちらから読めます。

サイト移転に伴うAdSense対策

サーチエンジン対策が終わって次の対策はAdSense対応でした。実はルートサーバーをGoogle Cloud側に変えてしまったためにads.txtが失われてしまっていました。ここで警告が出たので慌ててルートサーバーの設定をしてドメインも追加しました。実はこの時にHTTPとHTTPSの両方からアクセスができなければならないという規定があるそうです。

一応新しいサブドメインで処理することにしたのですがここで古いホスティングを放棄するという選択肢がなくなりました。いつでもルートを元に戻せるように古い設定は取っておくつもりです。古いホスティングではルートとwwwが同一になっています。警告は1日で消えますが「収益に重大な……」などと脅されるので結構ドキドキします。

この際に広告設定を見直しました。サイト内を遷移するときに強制的に全面広告を見せる設定になっているのです、これってどうなんでしょうかね。デフォルトではパソコンやタブレットの画面でも全面広告を出す設定がオンになります。ただ、これを変えようとすると「収益が減るから90日テストをやらせてください」とAdSenseがテストを提案して来ます。AIにセールスマネージャーをやらせているわけですね。

あと関連記事の表示が一時とまりました。AdSense側の設定を変えると表示が再開されたのですが検索すると「表示されない」とか「そもそも設置が許可されていない」などという記事がたくさん出て来ます。みなさん非常に苦労されているようです。

このとき「一つのサーバーに全てを詰め込むのは危険だ」と感じました。今回は旧サーバーの小さなブログ(このGadgetMacブログもその一つです)は残せたのでこちらを携帯ユーザー向けに改変しました。

最新のテーマに変えてAMP対応にしました。PCから見ると「文字ばかり」に見えますがスマホだとこちらの方が読みやすいんでしょうね。

この記事の全文はこちらから読めます。

乗りかかった船に完全乗船する

このあたりで古いサーバーが回復したので記事をエクスポートして新しいサーバーに全て移行しました。Wordpressってすごいなあと思ったのはメディアファイルを全部転送してくれるところです。FileZillaでファイルが全て移行されていることを確認し一安心しました。

次に検索エンジン対策ってどうするんだっけ?と思い始めました。Google Search Consoleに新しいサブドメインを登録し古いサブドメインのトップに.htaccessファイルを設置するだけでした。

やり方は「301リダイレクト」で検索するといくらでもでてきます。ですが、この時点までに確認できることは全て確認しないと以降のアクセスができなくなります。自動的に転送されてしまうために管理画面にさえアクセスできなくなるからです。

一応ネットには「管理画面だけは除外する」というやり方を書いている記事もあるので面倒でもちゃんと設定したほうがいいです。
つまり、あとあとめちゃくちゃ後悔しました。設定は一瞬ですが解除がなかなかできないので面倒になって「まあいいや」などと思ってしまいます。

あと、一旦URL移行を始めてしまうと元に戻れなくなります。ここが「引き返せない」というPoint of No Returnになってます。検索エンジンランキングなどは無事に引き継がれたようで「検索を開始しました」というお知らせがGoogle Search Consoleにあとからやって来ました。

サーチエンジン対策は終わりアクセス数は減らなかったのですが、そもそもアクセスが増える原因になったまとめサイトからの流入は失われてしまったようです。「これじゃ意味ないじゃん」と思ったのですが、もう引き返せないところまで来ていたわけですね。

このまとめサイトは素性がよくわからなかったのでどういう人が流入していたのかがよくわかりません。トラフィックばかり増えて収益が上がらないでは意味がないですし、拒否もできないですから大変悩ましいなあと思います。

この記事の全文はこちらから読めます。

VMにMacからFTPSできるようにする

次の「難関」はFTPSです。MacだとFileZillaを使った事例が出てきます。

  • MacでSSHの公開鍵を作り
  • Google CloudのVM側に貼り付け
  • FileZillaに鍵の入ったファイルの場所を渡す

ことで手続きが完了します。

この時点でほぼ気持ちは折れていました。apacheのhtml領域の所有者はrootになっているのにrootではFTP接続させてくれません。ですからディレクトリを作ったら所有権を変えてやるなり誰でも書き込めるように設定を変えなければならないわけです。

つまり、lsとかchmodとかmkdirとかそういうUNIXの「おまじない」がわからない人はここで詰むはずです。

この記事の全文はこちらから読めます。

IPアドレスを取得してSSLの設定をする

次にやることはIPアドレスの取得です。最初は臨時のIPアドレスがつくだけなので、これを「予約」して継続的に使えるIPアドレスを作らないことにはその後のDNS設定ができません。VPCネットワークのセクションでIPアドレスを取得します。

次にネットの記事を参考にCloud DNSで「ゾーン」を設定するのですが、これは実は必要ありませんでした。

Googleではないところがレジストラになっている場合全てのIPアドレスはレジストラ側で管理されています。私はENOMというところが管理しています。

しかしこれがよくわかっていませんでした。AレコードとMXレコードの違いくらいはわかりますが、ネームサーバーとエリアスの区別がついていないというくらいの状態だったんですよね。

Cloud DNSのAPIを解放してこれをGoogle Cloudに預託するためにはENOM側のネームサーバーをGoogleに変えるという手続きをします。しかしこれが実は有料なんですよね。さらに、いったんGoogle側に移してしまうと今までの設定を全てCloud DNSに引き継ぐ必要があります。

次にSSLの設定をします。最近はHTTPだけではアクセスしてもらえないのでこんな面倒なことをしなければいけません。Googleが証明書を管理しているのですがロードバランサーに設定してグループを組んでVMインスタンスを割り当てるという作業をしないと使えないようです。Certbotという無料のサービスを使っている人が多いようです。

Certbotの設定は非常に簡単です。ただし英語ができればですが。ただこの設定でEl Capitanからのアクセスができなくなりました。

設定自体は簡単なのですが90日ごとに手動で証明書を更新するかスクリプトを組んで更新を自動化しなければなりません。「単に記事を送ることができるプラットフォームが作れればいいだけ」なのにサーバーのお守りをやる羽目になるとは……思いました。

ふと「今いるサーバーに金さえ払えばこういう面倒なことは全てやってくれるんだよなあ」と感じます。

ただ、結構遅いサーバーでMySQLのバージョンも低いので警告が出ています。サーバー側がなかなか対応してくれないとイライラするのと自分でなんとかするのとどっちがいいんだろうか?と思いましたが……実際にはどうなんでしょうか?

この記事の全文はこちらから読めます。