KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

PHP7 7.0.14
WordPress 4.7

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGI バージョンアップ情報 8.0.2-1

KUSANAGI バージョンアップ情報 8.0.2-1

KUSANAGI 8.0.1-2 にバグフィクスを行った、KUSANAGI 8.0.2-1 をリリースします。
また、WP-CLI の1.0.0 へのバージョンアップを行い、併せてリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、kusanagi-8.0.2-1 および kusanagi-wp-cli-1.0.0-1 へのアップデートが可能となります。

# yum update

KUSANAGI 8.0.2-1 でのバグフィクス

8.0.2-1 は、以下の問題を解決します。

  1. rootkit check tool での誤検知対応

1. rootkit check tool での誤検知対応

chkrootkitrkhunterなどのrootkit検出ツールで、kusanagi-wp-cli に含まれるファイル、/usr/bin/wp が 「RH-Sharpe’s Rootkit」の一部であると検出される問題が発生しました。
内容を確認したところ、以下の点から誤検知と判断しています。

  1. chkrootkitおよびrkhunter での「RH-Sharpe’s Rootkit」のチェックは、指定ファイルが存在するかどうかのみチェックし、内容のチェックは行っていない
  2. 弊社で作成した RPMに含まれる、/usr/bin/wp と配置された /usr/bin/wp の checksum が同一である
  3. kusanagi-wp-cli に含まれる /usr/bin/wp をVirus Check tool(VirusTotal)で確認したところ、Virus は検出されない

この誤検知は今後も発生すること、「RH-Sharpe’s Rootkit」は古くからあるrootkitで、複数あるrootkit検出ツール開発元に誤検知であること通知するのは非現実的なことから、今回 wp のパスを /usr/local/bin/wp に変更いたしました。
今回の変更後、chkrootkitおよびrkhunterで、rootkit が検出されないことは確認済みです。

アップデート後、以下の点ご注意ください。

  1. root ユーザで wpコマンドを使用する場合、.bashrc で設定する wp コマンドの alias を変更して /usr/local/bin/wp を使用するようになっております。yum update を実施後は再ログインし、新しい wp コマンドの alias が有効になるようにしてください。
  2. kusanagi ユーザで wp コマンドを使用する場合、/usr/local/bin を 環境変数PATHに含めるようにしてください

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

NGINX 1.11.6

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

PHP7 7.0.13

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

WP CLI 0.25.0

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGI バージョンアップ情報 8.0.1-2

KUSANAGI バージョンアップ情報 8.0.1-2

KUSANAGI 8.0.1-1 にバグフィクスを行った、KUSANAGI 8.0.1-2 をリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、8.0.1-2 へのアップデートが可能となります。

# yum update

KUSANAGI 8.0.1-2 でのバグフィクス

8.0.1-2 は、以下のバグフィクスを含みます。

  1. kusanagi provision/setting で、www.付きのFQDNを指定されたときのApache設定
  2. kusanagi パッケージアップデート時の問題

1. kusanagi provision/setting で、www.付きのFQDNを指定されたときのApache設定

kusanagi provision/settingで --FQDN にwww.example.com と example.com のどちらかを FQDN に指定すると、www.example.com と example.com の両方を VirtualHost として設定しますが、Apache の設定で2つ目のFQDNをServerAliasではなくServerNameとして定義していました。
kusanagi-8.0.1-2 では、この場合に正しくServerAliasとして2つ目のFQDNを設定するように修正しました。

2. kusanagi パッケージアップデート時の問題

kusanagi パッケージアップデート時に、yum updateがフリーズする問題がありました。kusanagi-8.0.1-2 では、この問題はすべて解消されています。

KUSANAGI バージョンアップ情報 8.0.1-1

KUSANAGI バージョンアップ情報 8.0.1-1

KUSANAGI 8.0.0 に機能追加およびバグフィクスを行った、KUSANAGI 8.0.1 をリリースします。
以前のバージョンをお使いいただいている場合は、root権限にて以下のコマンドを実行することで、8.0.1-1 へのアップデートが可能となります。

# yum update

KUSANAGI 8.0.1-1 での機能追加

8.0.1-1は、以下の機能追加を含みます。

  1. SSL証明書の透明性に対応(NGINXのみ)
  2. Apache2 の SSL設定にDH設定を追加
  3. certbot-auto renew の採用

1. SSL証明書の透明性に対応(NGINXのみ)

SSL証明書の透明性(Certificate Transparency。以下CT)とは、Google社が提唱している SSL/TLSの信頼性を高めるための新たな技術です。
現在はRFC6962としてRFC化され、証明書の誤発行を防ぐ新たな技術として注目されています。
kusanagi-nginx では以前よりCTに対応していましたが、kusanagi ssl コマンドのオプションで有効・無効を切り替えることができます。

kusanagi ssl --ct [on|off]

kusanagi ssl --ct on を実行すると、設定ファイル上の SSL証明書から Signed Certificate Timestamp(以下 SCT) を作成し、証明書とともにGoogleのサイトに登録し、NGINXの設定でCTを有効にします。
また、kusanagi provision/ssl --email で、Let’s EncryptのSSL証明書を取得するときは、自動的にCTがonになります。

2. Apache2 の SSL設定にDH設定を追加

NGINXでは以前から設定していたDH(Diffie-Hellman)鍵交換の設定を、Apache2 でも設定するようになりました。
これにより、暗号鍵の交換をよりセキュアに行えるようになります。

3. certbot-auto renew の採用

Let’s Encrypt で取得したSSL証明書の更新は、プロファイルごとにcrontab に登録し、2ヶ月に1度実行していました。
その為、何らかの理由でSSL証明書の更新に失敗したときに、SSL証明書の期限が切れてしまうという問題がありました。
Let’s Encrypt のクライアントである certbot-auto の renew オプションは、Let’s Encrypt から取得したすべてのSSL証明書について、有効期限が近い証明書を自動的に更新します。
kusanagi ssl --auto on では、1週間に1度 certbot-auto renew を実施するように変更し、--auto [on|off] でプロファイルの指定は無視されるようになりました。

KUSANAGI 8.0.1-1 でのバグフィクス

8.0.1-1は、以下のバグフィクスを含みます。kusanagi-8.0.1-1 では、以下の問題はすべて解消されています。

  1. ssl設定時にApache設定ファイルへの記述に問題がある
  2. hsts を有効にしたときに、httpレスポンスヘッダが不正になる(NGINXのみ)
  3. Drupal8 最新版の誤検知
  4. kusanagi provision/ssl --email 指定時に、autorenewal に失敗する
  5. KUSANAGI PluginとWP Site Managerの競合
  6. kusanagi init時にphp指定が無視される
  7. 日本語メッセージ不正

1. ssl設定時にApache設定ファイルへの記述に問題がある

kusanagi provision/ssl --email オプション指定時に、Apache2の設定ファイルへの追記に問題がありました。

2. hsts を有効にしたときに、httpレスポンスヘッダが不正になる(NGINXのみ)

kusanagi ssl --hsts でoff 以外を指定したとき、httpレスポンスヘッダに追記しているキャッシュ関連のヘッダが表示されない問題がありました。

3. Drupal8 最新版の誤検知

kusanagi provision --durupal8 でDrupal8のデプロイ時に、開発版やベータ版がインストールされる場合がありました。

4. kusanagi provision/ssl --email 指定時に、autorenewal に失敗する

kusanagi provision/ssl --email でLet’s Encrypt のSSL証明書を取得時、SSL証明書自動更新のcron設定に失敗する問題がありました。

5. KUSANAGI PluginとWP Site Managerの競合

KUSANAGIで標準でインストールされる KUSANAGI Pluginと、弊社で開発している WP Site Manager Pluginを同時にインストールする場合は、WP Site Managerが優先され、KUSANAGIの bcache機能は使用できなくなります。しかし、WP Site Manager Plugin をインストールして、設定でWP Site Managerを向こうにしているときも、bcache機能が使用できなくなるという問題がありました。
今回、KUSANAGI Plugin を更新したため、既存のKUSANAGI環境で以下のコマンドを実行し、KUSANAGI Pluginを更新してください。

# kusanagi target profile
 # kusanagi update plugin

6. kusanagi init時にphp指定が無視される

kusanagi init を対話式に実行するとき、php5を選択しても php-fpmサービスが有効にならない問題がありました。
この問題は、kusanagi init の --php5 オプション指定時には発生しません。

7. 日本語メッセージ不正

OS環境を日本語にした時、kusanagi コマンドのメッセージの一部に不具合がありました。

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

PHP7 7.0.12

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update

KUSANAGIモジュール更新情報

KUSANAGI を構成している各モジュールのアップデートを行いました。
アップデートにより適用される各モジュールのバージョンは、以下のとおりとなります。

NGINX 1.11.5

モジュールのアップデートについては、以下のコマンドで適用可能です。

# yum update