前回の記事でWordPressに対する改ざん攻撃への対処を行いましたが、その後さらにプラグイン「IP Geo Block」を導入しました。

不正アクセスとファイル改ざん被害との戦い

筆者のサイトが海外からの不正なアクセスにより、ファイルの改ざんや不正ファイルの設置を行われ、SPAM送信の踏み台にされる被害に遭いました。

前回の記事でこれに対する対策を行い、以後被害はなくなりました。

前回行った対策

手動では状況把握が不完全で、いたちごっこになるため処理も追いつかず、セキュリティ系プラグインに頼りました。

1. 被害内容の把握
2. ユーザー名を非表示にする
3. 不正ログイン対策
4. 改ざんされたファイルのスキャンと修正
5. 不正に設置されたファイルの削除
6. .htaccessによる海外IPアドレスのアクセス拒否（ここで完全解決）
7. SPAM送信をしてしまったPostfixの対策処理

今回の記事ではさらに一歩進め、上記対策で太字になっている部分をさらに強化することにします。

また、もやもやしていた.htaccessでのアクセス拒否について問題が見つかりましたので、これも同時に解決します。

IP Geo Blockの導入

非常に高機能かつ日本語化されていて設定も簡単なプラグイン、IP Geo Blockを導入します。

こちらのメイン機能は「国コードによるホワイトリストまたはブラックリスト型のアクセス制限を行う」というものです。

まさに前回.htaccessによって力技でやっていた内容ですが、異なる点がいくつかあります。

• 海外からのアクセスを遮断できる
• 国コードで判別の設定を行うため手動でIPアドレスを制限するよりも間違いがなく高効率
• アクセス制限を行う対象を選択可能
• ゼロデイ攻撃も防御できる
• 高速で動作し、かつ機能の重複する他の重いプラグインを無効化できる（例：Akismet）

こちらも、太字の部分が重要となっています。各項目の詳細については後述します。

インストール

まずはWordPress管理画面の「プラグイン」→「新規追加」からインストールして有効化します。

インストール直後は外部からデータベースをバックグラウンドで読み込むため、しばらく待つよう指示されます。

設定する

管理画面の「設定」→「IP Geo Block」で、挙動の設定を行います。

なお以下の設定内容は、すでに改ざん被害に遭った筆者の環境ですので、予防として導入する場合はもう少しライトな設定でも構わないと思います。

検証ルールの設定

ここで、基本となるルールを決めておきます。ここで決めたルールを、この後でどこにどう使うか指定するイメージです。

マッチング規則

「ホワイトリスト」とします。ブラックリストとの違いは以下の通りです。

• ホワイトリスト：基本すべて拒否、指定された国コードのみ許可
• ブラックリスト：基本すべて許可、指定された国コードのみ拒否

りゅう

前回の記事で紹介した.htaccessファイルはホワイトリスト型です。すべて拒否した後で、botと国内IPアドレスを許可しています。それでも4千行を越えてしまいましたが。

国コードのホワイトリスト

JP（日本）とします。必要であればカンマ区切りで他の国コードを加えることもできます。

悪意のあるシグネチャ

管理領域、テーマ領域、プラグイン領域に対して悪意があるとみなすシグネチャを指定します。

改行またはカンマ区切りで複数指定することができます1。

デフォルトのシグネチャ

../,/wp-config.php,/passwd

追記後のシグネチャ

../,/wp-config.php,/passwd
curl,wget,eval,base64

りゅう

筆者の受けた改ざん被害でも、PHPのevalやbase64が用いられていました。

IPアドレス当たりのログイン試行可能回数

同一のIPアドレスからのログインを許可する回数で、ここでは5としました。

検証のタイミング

ここは、IP Geo Blockプラグインがどのタイミングで上記のような検証を行うのかを設定します。

デフォルトのタイミング

"init" アクション・フック

変更後のタイミング

"mu-plugins" (ip-geo-block-mu.php)

デフォルトでは標準的なプラグインの実行タイミングとなります。その前にWordPressによる様々な前処理が行われることになります。

mu-pluginsに変更すると、他のプラグインより早いタイミングで実行されるため、後にアクセスを拒否することになる接続先に対して、無駄なサーバ資源の消費を避けることができます。高速化も期待できます。

注意点として、以下に記述されているような制限事項が生じます。

http://www.ipgeoblock.com/codex/validation-timing.html

英語ですし、なんだか難しく書いてあります。

• テーマ内functions.phpのカスタムフィルターフックが動作しない
• 人間に優しいエラーページが無効になる

カスタムフィルターフックについては、テーマ表示より前のタイミングで実行される以上は仕方のないところです。解決策も書かれていますので、問題の発生する環境では試してみると良いでしょう。

次にエラーページの件ですが、上記と同様にテーマ表示の処理を行う前にIP Geo Blockが動作しますので、テーマを処理する前だという理由で404.phpのようなユーザーフレンドリーなエラーページを表示できません。こちらも解決策が書かれています。エラーページを静的HTMLファイルとして保存すれば良いようです。

筆者の環境ではどちらも対策していませんが、どのみち拒否するユーザーに見せるものなので気にしないことにしました。

バックエンドの設定

IP Geo Blockプラグインで「どこを」「どう」防御するのかを決める部分であり、とても重要な設定です。

コメント投稿

国コードで遮断

コメントを海外から投稿できないようにしています。思い切った設定ではありますが、実はこれでSPAMコメントがほとんどなくなります。

ということは、重いことで有名なSPAM対策プラグイン、Akismetを停止することできますね（後述）。

XML-RPC

国コードで遮断

筆者はXML-RPCを悪用した攻撃をひっきりなしに受けていました。攻撃手段となり得る機能を野放しにしておくのはよろしくないので対策したいのですが、無効にするのも抵抗があります。IP Geo Blockでは海外勢のみ遮断することができます。便利！

ログイン・フォーム

国コードで遮断

ログイン試行の回数を設定する部分がありましたが、ここではそもそもログイン試行を行う対象を国内IPアドレスに絞ることができます。海外からのログイン試行はひっきりなしに行われていますので、こちらも国コードで遮断しておきます。

管理領域

国コードで遮断
ゼロデイ攻撃を遮断

管理領域（/wp-adminディレクトリ）内に対するアクセスを国コードで遮断します。通常であれば、管理者である自分以外はアクセスしない部分です。

また「ゼロデイ攻撃を遮断」が登場しました。ゼロデイ攻撃とは、脆弱性が発見されてから対策された日（ワンデイ）までの間にあたる脆い期間（ゼロデイ）に行われる攻撃のことです。これは非常に心強い機能で、未対策の攻撃を検知して遮断することができます。

管理領域ajax/post

国コードで遮断
ゼロデイ攻撃を遮断

管理領域内にあるadmin-ajax.phpとadmin-post.phpに対するアクセスを上記と同様に遮断します。

プラグイン領域

ゼロデイ攻撃を遮断
WPコアの読み込みを強制

改ざんや不正ファイル配置は、プラグイン領域に対してよく行われます。ここでは管理領域と同じように、ゼロデイ攻撃を遮断します。国コードで遮断するよりも強固になります。

テーマ領域

ゼロデイ攻撃を遮断
WPコアの読み込みを強制

テーマ領域に対しても、改ざんや不正ファイル配置はよく行われます。ここも管理領域と同じように、ゼロデイ攻撃を遮断します。国コードで遮断するよりも強固になります。

なお上記2つで「WPコアの読み込みを強制」をチェックしてありますが、これはWordPressのコア（本体）を読み込まずに実行されるPHPファイルがあった場合への対策となります。

フロントエンドの設定

通常の投稿やページを表示、つまり制作者が意図しているURLでのアクセスに対する設定です。

ここへの直接攻撃はちょっと考えにくいですし、テーマファイルへの攻撃なら前項の設定で防御できます。そこでここは遮断しないよう設定します。

フロントエンドの遮断を設定すると、外部からの正常なアクセスを検証、遮断しますので、ただ普通にサイトを見に来たユーザーやクローラーが対象になります。筆者は前回の対策ではクローラー関係で苦労することになりました。この項目を設定しなくても攻撃されることはなくなり、かつクローラーのエラーもなくなっています。

位置情報APIの設定

IP Geo Blockプラグインでは、外部の位置情報データベースをAPI経由で取得して利用しています。そのための設定ですが、このままで問題ありません。

ローカル・データベースの設定

上記APIでローカルに取得されたデータベースの状態です。

「自動更新（月1回）」をチェックするのみで、他には特にすべきことはありません。プラグイン導入直後にバックグラウンドでデータベースの取得が開始されますが、うまく働いていない、または取得に失敗しているようであれば「今すぐダウンロード」ボタンをクリックしてください。

統計とログの設定

このようなプラグインでは、「動作しているか」「期待通りに動作しているか」「どのような状況か」「何をいつどうしたか」といったログを見たいものです。

ここで検証とログを有効にしておきましょう。

検証のログを記録

遮断時または遮断対象国の通過時に記録

筆者が既に攻撃を受けて被害も被っているため、見られる情報はなるべく見たいということでこの設定にしてあります。

通常は「遮断時に記録」だけでも良いかも知れません。

IPアドレスのキャッシュ設定

キャッシングに関する設定です。特に変更すべき部分はありません。

投稿時の設定

コメント欄の上下に一言何かを表示する機能のようです。本プラグインで設定を行う必要はないでしょう。

プラグインの設定

便利な設定のエクスポート、インポートがあります。プラグインのアンインストール時に全設定を削除する設定もありますが、このあたりはお好みで。

その下部に「変更を保存」ボタンがありますので、ここまでの設定が済んだらクリックしておきます。

不要となるプラグインや設定

以下のプラグインが有効である場合、これらは停止もしくは削除することができます。

機能が完全に被っているか、または部分的にせよ重要な部分をIP Geo Blockで代替できるためです。

特にありがたいのがSPAM対策プラグインのAkismetで、これは大変重いことで有名です。IP Geo Blockに任せましょう。

Wordfenceについては、筆者は残してあります。理由は、ノートン先生やウィルスバスターなどに似たスキャン機能があり、改ざん被害を発見・通知することができるためです。

改ざん被害に遭っていない方は、今からIP Geo Blockで防御すれば、それも未然に防げる可能性があります。

まとめ

前回行った.htaccessによる海外からのアクセス制限では、何もかも問答無用で弾いてしまうため、強力ですが困ることもありました。

りゅう

具体的には、Googleなどのようなメジャーどころではないbotの扱いで困りました。

目的が「日本人以外を弾きたい」のではなく「攻撃は全て海外からなのでそれを弾きたい」なので、IP Geo Blockによるゼロデイ防御の方が適しています。

国コードという概念とゼロデイ防御という手法でセキュリティを向上できるIP Geo Block、個人的に2018年のベストプラグイン賞決定です。

WordPressがマルウェアに感染したり、ファイル等の改ざん被害を受けた際の対策をまとめました。

WordPressは狙われやすい

WordPressは、世界で最も多く利用されているオープンソースのCMSです。

しかし利用者が多いということは、ITリテラシーやセキュリティ意識の低いユーザーが多い可能性も高くなります。

りゅう

つまり悪意あるユーザーにとっては格好の標的となります。

ということで今に始まったわけではありませんが、WordPressは悪意あるユーザーに「常に狙われている」状態にあるとまず考えましょう。

名の売れたサイトが狙われやすいのは当然ですが、「自分のところはアクセス数が少ないから対策しなくても大丈夫だろう」と高をくくるのは危険です。

悪意あるユーザーが求めているのは、まさにそのようなセキュリティ意識の低いサイトです。

被害に遭ってから対策するのはかなり骨の折れる作業になりますので、事前にできる限りの予防をしておきましょう。

乗っ取り被害のチェック

WordPressの管理画面にログインし、左メニューの「ユーザー」を確認します。

もし自分以外のユーザーが不正に登録されていたら、即座に削除しましょう。

さらに自分自身のパスワードも、長く難解なものに変更します。WordPress側で自動生成することもできます。

adminユーザーに注意

WordPressでは、デフォルトの管理ユーザーがadminになっています。

これをこのまま放置するのはセキュリティ上好ましくありませんので、管理権限を持つ別ユーザーを作成して、adminは削除することをおすすめします。

ログインユーザー名が表示されるのを防ぐ

http://******.***/?author=1のように、自サイトのURLに/?author=1を追記してブラウザで表示してみてください。

管理者権限を持つユーザー名が表示される場合、これは危険な状態です。

WordPressの認証は基本的にユーザー名とパスワードの2要素で行いますので、そのうち1つがバレるというのはリスクが高いと考えてください。

手動でなんとかする方法

テーマディレクトリ内のauthor.php（無ければ作成）の内容を、以下の通りにします。

<?php
    wp_redirect(home_url());
    exit();

これで、authorのユーザー名を表示することなくトップページに強制転送します。若干無理やり感がありますが。

プラグインを使用する方法

Edit Author Slugというプラグインで対策できます。

ユーザーアーカイブのスラッグを変更することができますので、/?author=1のようにアクセスしても設定したスラッグのURLに転送され、ユーザー名が露呈することはありません。

りゅう

テーマによっては、ユーザー名の表示を無効化する機能を持っている場合もあります。

ログイン保護と不正アクセス対策

不正アクセスを防ぐためには様々な方法がありますが、まとめて行ってくれるプラグインがあります。

SiteGuard WP Plugin

りゅう

既に改ざんや乗っ取り被害の跡が見られる場合は、WordPressの管理画面ではなくFTPなどでアップロードする方法をおすすめします。

SiteGuardは国産のセキュリティプラグインで、ログインページの保護と不正アクセス対策に特化しています。

上の画像のように、ログイン履歴を見ることもできます。

注目すべきは右端の「タイプ」で、ログインページではなくXMLRPCからのログイン試行（失敗）が並んでいる点です。私がそのような操作を行ったことはありませんので、これは不正アクセスの試行を受けていることを意味しています。

りゅう

XMLRPCとは外部からWordPressを操作する仕組みと考えてください。外部連携には便利な機能ですが、悪用されやすいというデメリットがあります。

SiteGuardでは、このXMLRPCを無効にする設定も可能です。

いくつかの機能がありますが、私は以下のように設定しました。

日本語で項目ごとに説明が記述されているので迷うことは少ないでしょう。

「ログインページ変更」では、/wp-admin/と決まっている管理画面のURLを変更することができます。想像できる通り、ログインページからの不正ログイン試行の多くを防ぐことができます。

「画像認証」は、ひらがなによる画像認証を追加することができます。コメントにも仕掛けられますが、筆者はログインページだけにしておきました。

「XMLRPC防御」では、XMLRPCそのものを無効にしました。具体的には.htaccessにxmlrpc.phpへのアクセスを禁止する記述が追加されます。

これでひとまず、不正ログインに関してはかなりセキュリティを強化することができます。

改ざんと不正ファイルのチェック

これらの被害に遭っているかどうかを手動で調査するのは、大変骨の折れる作業となります。

ここでは、セキュリティリスクをスキャンできるプラグインを使用して、被害に遭っているかどうかを確認します。

Wordfence Security – Firewall & Malware Scan

Wordfenceは、WordPress本体のファイル改ざんや、不正なファイルが作成されていないかをスキャンすることができます。

また、古すぎたり更新が停止しているプラグインはスキャン結果で警告されますので、代替となるプラグインを探すことをおすすめします。

Wordfenceは英語のプラグインですが、使用するのは一部機能のみで設定も特に要らないため問題になることはないでしょう。

何はともあれ、まずは上記プラグインをインストール、有効化します。

りゅう

既に改ざんや乗っ取り被害の形跡が見られる場合は、WordPressの管理画面ではなくFTPなどでアップロードする方法をおすすめします。

管理画面の左メニューに"Wordfence"が追加されますので、そこから"Scan"を選択します。

"START NEW SCAN"ボタンをクリックすれば、WordPressインストールディレクトリ以下の全ファイルを調査してくれます。

この画像では左下部の"Results Found"が空になっていますが、これは改ざんや不正なファイルが見つからなかったことを示しています。

りゅう

日本語版WordPressではwp-config-sample.phpとreadme.htmlが「内容がオリジナルと異なる」と表示されますが、多くの場合正常です。
前者はPHPスクリプトなので、一応おかしなコードが埋め込まれていないか確認（後述）し、問題がなければどちらもIgnore（無効）にしてしまってOKです。

もし"Results Found"に改ざんされたファイルや不正に作成されたファイルが表示された場合、対策が必要です。

具体的には、以下のように対応します。

• 改ざんされたファイル：対象ファイルをエディタで開き、後述のようなコードが埋め込まれていれば該当部分を削除する。
• 不正に作成されたファイル：対象ファイルを削除する。

このスキャン作業は、たまに行って確認するようにしましょう。日々の作業が増えますが、被害に遭ってから対応するよりよほど楽です。

Live Trafficが便利

Wordfenceには、他にも様々な機能がありますが、主に使用するのは上記のスキャンと、"Live Traffic"です。

アクセスログをほぼリアルタイムに閲覧できる機能ですが、国名を見られたり、怪しいか問題のあったアクセスを色分けして表示してくれたりするので大変便利です。

この機能だけを持つプラグインもありますが、このように1本にまとめられているのは嬉しい限りです。

また、上の画像がまさにそうなのですが、不正なアクセスを行ったIPアドレスをブロックリストに入れることもできます。

りゅう

ただし攻撃者は自らのPCではなく様々な国にある複数の踏み台を操って不正アクセスを試みますので、多くの場合IPアドレスは一定ではありません。
したがって単一のIPアドレスをブロックすることには（無意味とは言いませんが）あまりメリットはありません。

改ざんされたファイルの修正

Wordfenceのスキャンで改ざんされたファイルが見つかったら、エディタで開いてみます。

おそらくファイルの先頭に以下のようなコードが不正に埋め込まれています。

<?php $xxxx = Array(/* 無意味に見える大量の英数字 */);
eval(xxxx_function($base64_data, $xxxx)); ?>

「無意味に見える大量の英数字」の部分をbase64でデコードすると、PHPのコードであることがわかります。

私は何度もいたちごっこを繰り返しましたが、改ざんされるファイルは毎回index.php, wp-config.php, wp-settings.phpあたりでした。

これらのファイルはWordPressが毎回必ず読み込むファイルであるため、悪意あるコードを埋め込むにはうってつけというわけです。

上記のようなコードを発見したら、エディタで不正コード部分の<?phpから?>までを削除してください。

りゅう

完全な原因究明と抜本的な対策が行われない限り、繰り返し改ざんが行われる場合があります。私もそうでした。

不正に作成されたファイルの削除

Wordfenceの"Live Traffic"の部分で紹介した画像のように、いかにもランダムで付けたファイル名である場合が多いですが、たまに意味ありげなファイル名になっていることもあります。拡張子は.phpです。

作成されるディレクトリはまちまちで、wp-admin/やwp-includes/の中であったり、wp-content/uploads/の中であったり、プラグインやテーマのディレクトリ内であったりします。深い階層内に作成されることもあります。

該当ファイルをエディタで開くと、コードは概ね以下のように難読化されています。

最後の方でeval関数によって文字列がPHPコードとして評価されます。

りゅう

実行されるコードは様々でしょうが、筆者の場合はSPAMを送信するコードになっていました。

攻撃者はこの不正に作成したPHPファイルにPOSTメソッドでアクセスし、実行してきます。これはアクセスログやWordfenceの"Live Traffic"で確認することができます。

この不正ファイルを放置するのは大変危険ですので、見つけ次第 問答無用で削除してください。

海外のIPアドレスを拒否する

いささか乱暴ではありますが、攻撃はほぼすべて海外のIPアドレスから行われますので、サイトの公開対象が国内のみであれば、海外からのアクセスをすべて遮断してしまう方法があります。

これは大変効果的で、攻撃者とのいたちごっこを繰り返していた私が最終的に問題を解決するに至った手法です。

遮断する方法はいくつかありますが、ここでは最も修正が手軽な.htaccessによるアクセス制限を紹介します。

以下は、私が採用している.htaccessです。内容は、以下のような流れになっています。

1. すべてのアクセスを拒否
2. Googleやfacebook, Twitterなどbotからのアクセスを例外として許可
3. 日本国内で使用されるIPアドレスを例外として許可（4千行以上）

Apacheのバージョンによってアクセス制限の書式が異なる点に注意してください。

▼Apache 2.2系を使用している場合

https://gist.github.com/ryu-blacknd/3625090cd46b2b60d7ce3700ae7d6b78

▼Apache 2.4系を使用している場合

https://gist.github.com/ryu-blacknd/59dc7f1dbf5c82a3be507a9acb0146d9

多くの場合、既に何かが書かれた.htaccessファイルが存在すると思いますので、その部分は残して上記コードを追記してください。

貼り付ける場所に悩んだら、# BEGIN WordPressの直前にしておけばOKです。

SPAM送信の踏み台にされた場合の対処

私が実際に被害に遭ったサーバの環境は、OSがCentOS 7で、MTA（メールサーバ）はPostfixです。

ここではPostfixであった場合、かつrootによる作業が可能な場合の対処方法を紹介します。

まずは現在溜まっているキューを確認します。

$ postqueue -p

送信した覚えのないメールがズラッと表示された場合、既にSPAM送信が実行されています。

この場合は以下のコマンドでまずキューを削除します。

$ postsuper -d ALL

上記対応によって問題が解決している場合は、このままPostfixの運用を続けて構いません。

まだ対策が完了していない場合はさらにキューが増加しますので、不本意ながらPostfixを停止しておきます。

$ systemctl stop postfix

当然ですが、Postfixを停止している間はメールの送受信が機能しません。なるべく早期に対策を終え、再度Postfixを起動します。

$ systemctl start postfix

一度SPAMの踏み台になってしまった以上、以後しばらくはキューの確認を行うことをおすすめします。

まとめ

既に書きましたが、最も効果的な対策は海外のIPアドレスを排除することです。

すべての対策を行っても解決しない場合、最終手段は再セットアップということになります。WordPressのファイル群をすべて削除し、素のWordPressから再度環境を構築をすることで、クリーンな状態に戻せます。

ただし事前にバックアップを取ることはもちろんですが、バックアップしたファイルをそのまま書き戻さないこともまた重要です。
プラグインやテーマは改めて新規インストールし、手動で以前の設定を復元するべきです。

この作業は困難かつ時間がかかりますので、できることならここで紹介した方法で解決したいものです。

最後になりましたが、WordPress本体やプラグイン、テーマのアップデートは無視せず実行してください。

りゅう

公開されたばかりのバージョンであっても脆弱性が発見されることがしばしばありますので、常に目を光らせておいてください。

CentOS 7にLAMP環境を構築。GitBucketとJenkinsを動かし、自動ビルドや自動デプロイまでやってみます。

なぜGitBucketか

GitBucketはGitHubクローンで、似たものに有名なGitLabがあります。 GitLabも最近はrpmコマンド一発でインストールできるほど簡単になっていますが、今回はより簡単 (.warファイルを置くだけ) で、見た目や使い勝手もGtiHubに近いGitBucketを選びました。

概要

• ソースからのビルドは行わず、yumパッケージや.warファイルを使用
• Apacheのmod_proxy_ajpを使い、Tomcatへはポート8080ではなく80でアクセス
• GitBucketでリポジトリにpushがあったらJenkinsで自動ビルド
• Jenkinsのビルドでは、rsyscでApacheの公開ディレクトリに自動デプロイ
• 自動デプロイ時のユーザーはtomcatではなくapacheで行う

動作環境

CentOS 7のミラーサイト一覧で、日本のミラーから最新版をダウンロードしてください。 Vagrantで起ち上げた仮想マシンやDockerのコンテナでも構いませんが、一部読み替えたり、ポートマッピング等の追加設定が必要になります。

リポジトリの準備

デフォルトではパッケージが少なかったり古かったりするので、EPELとremiのリポジトリを追加します。

EPELリポジトリの追加

yum install -y epel-release

remiリポジトリの追加

rpm -ivh http://rpms.famillecollet.com/enterprise/remi-release-7.rpm

パッケージのインストールと起動設定

とりあえずは最新の状態にしておきます。

yum -y update

必須パッケージに加え、普段よく使うパッケージも入れておきます。

yum --enablerepo=epel,remi install -y sudo vim-enhanced syslog httpd httpd-devel php php-devel php-pear php-mysql php-gd php-mbstring php-pecl-imagick mariadb-server phpmyadmin wget git java-1.7.0-openjdk-devel tomcat

各種サービスを起動し、さらに再起動時にもサービスが有効になるように設定します。

CentOS 6まではservice(または/etc/rc.d/init.d/のスクリプト)とchkconfigコマンドを使用しましたが、CentOS 7ではsystemctlに変更されています。

systemctl enable --now httpd
systemctl enable --now tomcat
systemctl enable --now mariadb

サービスの状況は以下のコマンドで確認できます。

systemctl list-unit-files

GitBucketをインストール

先述の通り、.warファイルを置くだけの簡単インストールです。

https://github.com/gitbucket/gitbucket

releaseから最新版のgitbucket.warをダウンロードして、実行用のディレクトリにコピーします。

cp gitbucket.war /var/lib/tomcat/webapps/

Jenkinsをインストール

こちらも.warファイルを置くだけです。

りゅう

簡単でいいですね！

https://jenkins.io/

最新版のJava Web Archive (.war)をダウンロードして、以下のディレクトリにコピーします。

cp jenkins.war /var/lib/tomcat/webapps/

ここでTomcatを再起動しておきます。

systemctl restart tomcat

ファイアウォールの設定

CentOS 6まではiptablesを使用しましたが、CentOS 7ではfirewalldに変更されています。

firewall-cmd --add-port=80/tcp --permanent

Apacheのプロキシ設定

AJPというプロトコルによって、ApacheとTomcatの相互通信を行い、外部への配信はApacheが担当するようにします。

TomcatのAJP通信は、ポート8080ではなく8009を用います。

以下のファイルを作成します。

/etc/httpd/conf.d/gitbucket.conf

<Location /gitbucket>
    ProxyPass ajp://localhost:8009/gitbucket
</Location>

/etc/httpd/conf.d/jenkins.conf

<Location /jenkins>
    ProxyPass ajp://localhost:8009/jenkins
</Location>

ファイルを作成したら、Apacheを再起動しておきます。

systemctl restart httpd

アクセスしてみる

まずはGitBucketにアクセスしてみます。

http://[hostname]/gitbucket

• ユーザー名：root
• パスワード：root

ログイン後はrootのパスワードを変更し、新規ユーザーを作成しておきます。

次にJenkinsにアクセスしてみます。

http://[hostname]/jenkins

正常に起動し、アクセスできました。

Jenkinsにプラグインをインストールする

「Jenkinsの管理」→「プラグインの管理」→「利用可能」へと進みます。

フィルタに「git」と入力して、以下のプラグインを選択して「再起動後にインストール」します。

• Git Plugin
• GitBucket Plugin

必要なプラグインがインストールされますので、「インストール完了後、ジョブがなければJenkinsを再起動する」にチェックを入れて待ちましょう。

長時間インストールが終わらない場合、実は既に終っているのに表示に変化がないだけということもあります。

GitBucketとJenkinsの連携設定

GitBucketのリポジトリを作成し、pushがあった際にJenkinsで自動デプロイを行うよう設定します。

GitBucket の設定

画面右上のレンチ型アイコンから設定画面へ進み、「System Settings」を選択します。

GitBucketでリポジトリを作成する

「new repository」からリポジトリ名を入力、「Initialize this repository with a README」にチェックを入れて新規リポジトリを作成します。

これで、リポジトリのトップページに表示されるREADME.mdのみがInitial commitされた状態になります。

次にリポジトリの「Settings」→「Service Hooks」と進み、「WebHook URLs」を入力します。

http://[hostname]/jenkins/gitbucket-webhook/

GitBucket側での設定は、このWebHookのみです。

apacheユーザーでデプロイするための設定

普通にデプロイの設定をすると、ファイル群はtomcatユーザーのままデプロイされます。
これだとApache的に都合が悪い場合もあるため、デプロイをapacheユーザーで行うようにします。

そのためには、Jenkinsを動かしているtomcatユーザーが、sudo -u apacheできるようにしなければなりません。

visudo

▼ 変更前

Defaults    requiretty

▼ 変更後（コメントアウトする）

$ Defaults    requiretty

さらにtomcatユーザーがパスワード無しでsudoできるよう設定します。

以下の行を追加

tomcat  ALL=(ALL)       NOPASSWD: ALL

そして、デフォルトでは/var/www/htmlの所有者がrootになっており、このために自動デプロイが失敗するので、権限を変更しておきます。

chown -R apache. /var/www/html

Jenkinsの自動デプロイ用ジョブを作成

新規ジョブ作成から、ジョブ名を入力 (例：project01)、「フリースタイル・プロジェクトのビルド」を選択してOKをクリックします。

りゅう

GitBucketのリポジトリページからコピペできる項目が多いです。

最後に「ビルド手順の追加」から「シェルの実行」を選択し、下記シェルスクリプトを記入します。割とここが目玉です。

sudo -u apache rsync -vr --delete --exclude ".git/" /usr/share/tomcat/.jenkins/jobs/project01/workspace/ /var/www/html/project01/

動作確認

gitコマンド、またはお使いのGitクライアントから、ファイルに適当な修正を加えてコミット → プッシュしてみてください。

※尋ねられるアカウントは、GitBucketのユーザーアカウントです。

GitBucketでは、GitHub同様にコミット履歴が加わっていれば成功です。こちらはまず大丈夫でしょう。

Jenkinsでは、リポジトリに対応するジョブが実行されて、/var/www/html以下に自動デプロイが行われたことを確認できればOKです。

CentOS 6で構築する場合

CentOS 6でも同様に、まずyumのリポジトリとしてEPELとremiをインストールします。

Tomcat 7もインストールできるため、一部CentOS 7独特の部分 (systemctlやファイアウォール等) 以外はそのまま進められます。

しかしJenkinsのGit Pluginがエラーを吐きます。

りゅう

これはCentOS 6にyumでインストールしたGitのバージョンが、1.7.1等の古いバージョンだからです。

解決するためには、最新のソースからGitをインストールすることです。

古いGitを削除

yum remove -y git

必要になるパッケージをあらかじめインストール

yum install -y curl-devel expat-devel gettext-devel openssl-devel zlib-devel

新しいGitのソースファイルをダウンロード

wget https://git-core.googlecode.com/files/git-1.9.0.tar.gz

解凍してインストール

tar zxf git-1.9.0.tar.gz
cd git-1.9.0
./configure --prefix=/usr/local/
make
make install

もし/usr/local/binにPATHが通っていなければ、下記のように.bash_profileに追加しておいてください。

.bash_profile

PATH=$PATH:/usr/local/bin

export PATH

そして上記変更を適用します。

source ~/.bash_profile

一応Gitのバージョンを確認しておきましょう。

git --version

これでJenkinsもエラーを吐くこと無く動作するはずです。

CentOS 7で採用されたApache 2.4の設定は従来とかなり変わっており、そのせいで戸惑うこともあるかと思いますので、馴染めない方は、少々面倒ですが上記の方法でCentOS 6上で構築してみるのも良いかと思います。

人気テーマOriginでフォント指定する方法を紹介します。フォントサイズについてもまとめてみました。

Origin最新版はこちら

フォントを変更できない理由

フォントの変更は、通常であればテーマファイル群のstyle.cssで指定すればOKです。

しかしこのOriginというテーマは、そこに至るまでに少々手間がかかるというだけです。

素直にstyle.cssでフォントを変更できない理由は以下のとおりです。

1. テーマのカスタマイズで指定するのが基本になっている
2. 優先して読み込まれるstyle.min.cssが存在する

まず1はさほど問題ではありません。style.css側でどうにでもやり方があります。

問題の2は、読み込みを少しでも早くするためですが、そもそもstyle.cssがそれほど大きくないため、圧縮する必要性を感じられません。

style.min.cssを削除する

元のstyle.cssが残っている以上、カスタマイズをするうえで邪魔な存在でしかありません。

削除しても問題ないファイルですので、削除してしまいましょう。

これでstyle.cssの記述を生かせるようになりました。

!importantに頼る

スタイルシートをいじる人にはお馴染みの手法です。
!importantを最後に付けることにより、他の場所で異なる指定がされていても、こちらの記述が優先ですよ、という宣言になります。

さっそく変更してみる

フォント名に日本語表記を使うのであれば、まずはこれが必須です。一番上のコメントブロック直下にでも記述しましょう。

@charset 'UTF-8';

記述後は、忘れずにテキストエディタの機能を使い、文字コードをUTF-8(BOM無)で保存しなおしておきましょう。

次は全体のフォントを変更してみます。

テーマのバージョンにもよりますが、だいたい33行目あたりに以下の部分があると重います。

font: 0.8125em/1.692307em 'Bitter', Georgia, 'Times New Roman', Times, serif;   /* 13 / 16 = 0.8125;  22 / 13 = 1.692307 */

このfont行がフォントの指定をしいている部分です。font-size, line-height, font-familyを1行で指定しています。

これを以下のように変更してみます。

font: 1em/1.65 'Helvetica Neue', Arial, 'Hiragino Kaku Gothic ProN', Meiryo, sans-serif !important; /* 13 / 16 = 0.8125;  22 / 13 = 1.692307 */

フォントサイズの指定

まず初めの1emは、フォントサイズの指定です。

元は0.8125emとなっていますが、これは行末のコメントにある通り、サイト全体のデフォルトを16pxとした際に、フォントサイズを13pxにするために割り算をした結果の数値です。

次の1.65は、所謂なんちゃって黄金比な数値です。この計算式も行末のコメントに記述してあります。

フォントファミリーの指定

次の記述が、font-familyに該当する部分です。

フォント名は先に書いてある方が優先順位が高く、欧文は「Helvetica NeueがなければArial」、日本語は「ヒラギノ角ゴシックProNがなければメイリオ」、「どれもなければシステムのゴシック体フォント」という指定になっています。

すでにあるフォント指定の上書き

重要なのが、最後の!importantです。

これを記述した行は、CSS内の他の部分で「被る」指定があったとしても優先（上書き）されます。

りゅう

!importantをさらに上書きする方法もありますが、ここでは説明を省きます。

Originテーマではstyle.cssとは別の部分でフォントを指定しており、それは管理画面の「外観」→「カスタマイズ」→「CUSTOM CSS」で変更することを前提としています。

しかしstyle.cssでスタイルのすべてを制御したいと思うのはデザイナーの性です。ていうかわかりにくいですし。

ここで紹介した方法なら、style.cssでフォントを含めすべてを制御できます。

WordPress 3.7で待望の自動アップデート機能が搭載されました。設定についても紹介します。

自動アップデートされるのは一部だけ

すべてが自動アップデートされるわけではありません。

りゅう

アップデートによる不具合が心配という向きにとっては当然の措置なのですが、ライト層のユーザーにとっては「全部やっといてくれよ！」というところでしょう。

デフォルトで自動アップデートされるファイル

• コア(マイナーバージョンアップ)
• ローカライズ

デフォルトで自動アップデートされないファイル

• コア(メジャーバージョンアップ)
• プラグイン
• テーマ

自動アップデートの設定を変更して有効にする

これらを自動アップデートするか否かは、WordPressのルートディレクトリにある設定ファイルwp-config.phpで指定することができます。

以下を追記すると、自動アップデートされるファイルを指定することができます。記述しない場合、これらは自動アップデートの対象外です。

コアファイル(メジャーアップデート)：有効

add_filter( 'allow_major_auto_core_updates', '__return_true' );

プラグインファイル：有効

add_filter( 'auto_update_plugin', '__return_true' );

テーマファイル：有効

add_filter( 'auto_update_theme', '__return_true' );

自動アップデートを無効にするには

逆に、自動アップデートされては困るファイルを指定することで、手動アップデートにすることもできます。

コアファイル(マイナーアップデート)：無効

add_filter( 'allow_minor_auto_core_updates', '__return_false' );

ローカライズファイル：無効

add_filter( 'auto_update_translation', '__return_false' );

まとめ

企業で利用している場合はコアやプラグインを下手にいじってほしくないケースもありますし、個人でも子テーマやまるごとコピーを使わずにテーマファイルをいじっている方はいると思いますので、きちんと使い分けしてトラブルのない自動アップデート生活を楽しみましょう！

統合開発環境にNetBeansを、テスト環境にXAMPPを導入する方法を紹介します。

XAMPP for Windows

XAMPPは、いわゆるLAMP環境（Linux, Apache, MySQL/MariaDB, PHP/Perl）をWindows上に構築するソフトウェアです。

りゅう

VirtualBox等の仮想マシンやDockerのコンテナでLinuxを起動して、LAMP環境を構築する方法もあります。

XAMPPには、大きく分けるとインストーラ版と手動インストール版の2種類があります。ここでは後者のZIP版をダウンロードすることにします。

https://www.apachefriends.org/jp/

大きいファイルですので、ダウンロードには少々時間がかかります。

XAMPPの解凍とインストール

ダウンロードが完了したら、C:ドライブ直下に解凍しましょう。xamppというフォルダの中にゴチャゴチャとファイルができていればOKです。

このフォルダ構成は「標準的な構成」であり、これでインストールは完了です。

もし上記以外のフォルダ構成にした場合は、解凍したファイルにあるsetup_xampp.batを実行しておきましょう。これでXAMPPの構成設定が更新されます。

XAMPPの設定変更

このままでも既にXAMPPは実行可能な状態なのですが、ここではNetBeansでPHPアプリケーションの開発を行うという前提で、必要となる設定をしていきます。

PHPのモジュールを設定する

当然のように使用するモジュールが使えなかったりするので、php.iniをテキストエディタで開いて編集します。

エクスプローラから直接エディタを起動しても良いですし、xampp-control.exeを実行してApacheの「Config」ボタンをクリックしても設定ファイルを開くことができます。というか後者のほうがラクでしょう。

右側にある「Config」から、使用するエディタの設定もできたりします。

いずれかの方法でphp.iniを編集できる状態になったら、990行目あたり以降のextension=php_*.dllが羅列してある部分を変更します。

;extension=php_openssl.dll

↓ コメントを外す

extension=php_openssl.dll

これでSSLモジュールが使用できるようになりました。PHPのComposerが動かない！といった場合はコレが悪さをしている可能性大です。なぜ無効にしてあるのかは不明です。

他に、せっかくXAMPPにはMercuryという聞きなれないメールサーバも付属していますので、imapモジュールも有効にしておきたいところです。

;extension=php_imap.dll

↓ コメントを外す

extension=php_imap.dll

PHPのXdebugを有効にする

これも、主に開発環境の一部として使われるXAMPPでなぜ無効にしてあるのかわかりませんが、デバッグを行うためのXdebugが無効になっているので有効にします。

;zend_extension = "C:¥xampp¥php¥ext¥php_xdebug.dll"

↓ コメントを外す

zend_extension = "C:¥xampp¥php¥ext¥php_xdebug.dll"

そして設定値が色々ありますが、面倒なので以下をコピペして最終行に追記しておきましょう。

xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9000
xdebug.remote_handler="dbgp"
xdebug.profiler_enable=1
xdebug.profiler_output_dir="C:¥xampp¥tmp"

MySQLの設定を変更する

同じようにして、MySQLの設定ファイルであるmy.iniを編集します。Linux等では/etc/my.cnfだったりするアレです。

デフォルトで使用する文字コードをUTF-8にする設定です。

まずは[mysqld]の下に以下の行を追記します。

character-set-server = utf8

そして[mysql]と[mysqldump]それぞれの下に以下の行を追記します。

default-character-set = utf8

XAMPPの実行と自動実行の設定

ここまでで、大抵の本番環境と似た状態になったと思います。

早速XAMPPを起動してみましょう。起動するのはxamppフォルダにあるxampp-control.exeです。

デスクトップなどにショートカットを作っておくと便利です。

起動したら、まず右端にある「Config」ボタンをクリックしましょう。そして、今後のXAMPP起動時に自動実行したい項目を選択しておきます。

ここではApache, MySQL, Mercuryを自動実行するよう設定しておきました。よく見るとテキストエディタも変更してあります。

ほかに、起動時に最小化してくれる「Start Control Panel Minimized」も地味に便利です。

「Save」したら再起動しても良いですし、このままApacheなどの「Start」ボタンをクリックしてもOKです。

NetBeansの設定

NetBeansで、XAMPPを使用するための設定をしておきます。

まずは「ツール」→「オプション」と進み、オプションダイアログの上部アイコン「PHP」をクリックします。

そして「一般」タブにある「PHP 5インタプリタ」の項目に、インストールしたXAMPPのphp.exeを指定します。

次に「デバッグ」タブを開き、不要だと思われる「最初の行で停止」のチェックを外しておきます。

まとめ

これで、NetBeansとXAMPPを使ったWebアプリケーション開発とデバッグができるようになりました。

NetBeansでは、さらにPHPUnitによるユニットテストや、各種PHPフレームワークのプラグインなども豊富に揃っていますので、公式サイトやGoogle先生を参考に色々調べてみてください。

りゅう

大手のSymfonyやZend Frameworkだけでなく、CakePHPやFuelPHP等のプラグインもあります。

CentOS 6の開発環境を一発で構築するスクリプトを公開しました。NetBeansやRedmineも紹介します。

GitHubのリポジトリ

https://github.com/ryu-blacknd/bootstrap

りゅう

気が向いた時に更新するかもしれません。

想定している開発フロー

1. Redmineでプロジェクト管理
2. NetBeansで開発
3. ローカルのGitリポジトリでコミット
4. リモートのベアリポジトリへプッシュ(Redmineが参照するのはココ)
5. 本番環境リポジトリ(/var/www/html以下)で自動プル

スクリプトの概要

• セキュリティ関係の設定(ローカル開発環境なので甘々に設定)
• yumのリポジトリを追加(epel, remi)
• yum updateと、必要なパッケージのインストール
• 不要なサービスの停止
• LAMP環境のインストールと最低限の設定
• RubyとPassenger周りのインストール
• Gitユーザーの作成と関連する設定
• phpMyAdminのインストール
• Redmine本体、テーマ、プラグインをインストール
• おまけ：ベアリポジトリ用フックスクリプトの雛形

詳細は、シェルスクリプトを読んでみてください。たいしてトリッキーなことはしていません。

動作環境

• LAN内のサーバPC、またはVirtualBox等の仮想マシン(Vagrant可)
• CentOS6 x86/64 minimal isoイメージでのインストール直後であること

インストール

rootでログインし、gitをインストール後、取得したbootstrap.shを実行するだけです。

yum -y install git
cd
git clone https://github.com/ryu-blacknd/bootstrap.git
chmod +x bootstrap/bootstrap.sh
bootstrap/bootstrap.sh

ほぼノンストップで進みますが、Passengerのインストール時のみ画面に表示される通りEnterを押して進んでください。

※2013.10.16 追記：Passengerインストール時にEnterを自動入力することで、ノンストップになりました。

インストール後はシステムを再起動します。

reboot

開発に関する情報

*1 NetBeansでのプッシュ先リポジトリ = Redmineでの参照リポジトリ

*2 開発ユーザー毎にSSH公開鍵を作成し、このファイルに追記していく(後述)

初回の開発フロー

初回のみGit絡みで面倒ですが、以下のフローが済めば、以降は自動化され楽になります。

1. [サーバ] ユーザーgituserでSSHログイン
2. [サーバ] /var/repos/[プロジェクト名]を作成し、ディレクトリ内でgit init --bare
3. [ローカル] NetBeansでローカルのリポジトリにファーストコミット
4. [ローカル] NetBeansから先ほど作成したベアリポジトリにプッシュ
5. [ローカル] Redmineで新規プロジェクトを作成、リポジトリを設定、ユーザー割り当て
6. [サーバ] cd /var/www/htmlしてgit clone /var/repos/[プロジェクト名]
7. [サーバ] /var/repos/[プロジェクト名]/.git/hooks/にpost-updateをコピーして編集

post-updateファイルはユーザーrootのホームディレクトリにあるため、gituserはアクセスできません。

chown gituser. post-update

としておき、gituserのホームディレクトリにでもコピーしておくとよいでしょう。

post-updateのコピーと編集

フックスクリプトpost-updateは、プロジェクトを作成する毎に手動でコピー、****の部分を編集します。

#!/bin/sh
/usr/bin/wget -q -O /dev/null http://localhost/redmine/sys/fetch_changesets?key=****
(cd /var/www/html/**** && git --git-dir=.git pull)

2行目は、Redmineの 管理 → 設定 → リポジトリ で生成したAPIキーを記述します。

3行目は、上記手順のプロジェクト名(=リポジトリのディレクトリ名)を記述します。

これで冒頭に書いたようなフローの準備が整いました。

以後はNetBeansで、ローカルコミットとベアリポジトリへのプッシュを繰り返して開発を進めます。

コミット・メッセージでチケットの状態を更新する

NetBeansからのコミット時は、コミット・メッセージの文末にrefs #1 @1.5h等を付与すると、Redmineのチケットと連携することができます。

このとき、作成者とコミッタをRedmineのユーザー名に合わせるようにしてください。

上記ユーザー名がRedmine側と一致しない場合は、チケット連携が正常に行われません。その場合はプロジェクト毎の 設定 → リポジトリ から、ユーザーの関連付けを行ってください。

※詳しくはこちらを参照してください。

http://blog.redmine.jp/articles/new-feature-1_1/automatic-spent-time-logging/

リポジトリへのアクセスにSSH鍵認証を利用する

ユーザー毎のSSH公開鍵をユーザーgituserのauthorized_keysに追記していきます。

以下の手順でSSH公開鍵と秘密鍵のペアを生成します。

ssh-keygen -C user@example.com

なお、この鍵ペアを外部サーバへの接続用途に使わないのであれば、パスフレーズは無視して構いません。

これでユーザーのホームディレクトリに2つの鍵ファイルが作成されます。

この公開鍵をサーバ管理者に渡し、管理者はgituserユーザーで~/.ssh/authorized_keysに追記します。

cd ~/.ssh
cat id_rsa.pub >> authorized_keys

次にNetBeans側で、「秘密鍵ファイル」に上記の秘密鍵ファイルを指定すれば、リポジトリにアクセスすることができるようになります。