シングスブログ

中小企業のマーケティングやブランディングのコンサルティング。事業運営、組織運営のPDCA改善やホームページの制作、ウェブサイト改善などITネット活用を中心にサービスを提供しています。

メニュー

WordPressをサーバH2Oで動かす (WordPressアプリケーションサーバとしてのH2O)

常時SSL とプロトコル HTTP/2 に対応するため、サーバ環境を新しくしてウェブサイトを移行しました。 新しい試みとしてサーバ構成を CentOS7 + PHP7 + MariaDB + H2O + WordPress にしてみました。

次世代の HTTPサーバ H2O を中心に速い WordPress を目指してサーバを構築。

今回 WordPress を HTTPサーバ H2O でどのように動かせばいいのか見てみたいと思います。

HTTPサーバ H2O とは

H2O は、プロトコル HTTP/2 に最適化されたウェブサーバです。

ここ数年でセキュリティ面で SSL が必須になりつつあり、ネット環境も新しい通信規約 (プロトコル) が求められている時代に最適なウェブサーバのひとつになっていくのだろうと注目していました。

H2O の開発は、2014年から元DNAの @kazuho さんが中心にオープンソースとして進められています。Perl を使っている方はウェブアプリを作るときに Server::Starter でお世話になっているのでは。ボクもいつもお世話になっています。 Server::Starter は、H2O のバックグラウンドにも使われていて start_server が動いているのが見て取れます。こういうところにも使われているのかとほんと感心しますね。

HTTP/2 時代を見据えているだけあってサーバの性能もベンチマークを見るとレスポンスが Apache や Nginx より速い。 他にも H2O の技術要素に注目したいものがたくさんあるのですが、詳しく知りたい方は、公式サイトやスライドも上がっているのでそちらを見ていただければと思います。

WordPress をサーバ H2O で動かす

2015年6月に FastCGI機能を実装したバージョン 1.3.0 がリリースされて、PHP が動くようになりました。 サーバ H2O で WordPress を動かすには、2 つの方法があります。

ひとつめは、WordPress を PHP-FPM や HHVM で管理。Nginx で従来やっている馴染みのあるやり方をそのまま踏襲。H2O も fastcgi.connect でホストに繋げてレスポンスを返してくれる。

今回採用したもう一個の方は、H2O 自体で管理する方法。 fastcgi.spawn で起動してH2Oの下で PHP のプロセスを管理してくれます。 PHP-FPM や HHVM をインストールしてコンフィグの設定起動、運用の手間がなくなります。

今回の試みとして思っていたことで、 WordPress とかPHPアプリを動かすアプリケーションサーバとしてH2Oは、最適なんじゃないかなぁと。

実際 H2O の下に php-cgi が動いているのが見て取れます。

WordPress を動かすサーバ設定 (/etc/h2o/h2o.conf) もYAML書式でシンプルに書けます。

以下これだけでWordPressが動きます。

paths:
  "/":
    file.dir: /path/to/wordpress
    redirect:
      url: /index.php/
      internal: YES
      status: 307
    file.custom-handler:
      extension: .php
      fastcgi.spawn: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"

実にシンプル。YAMLでわかりやすいのがいいですね。(本番運用には、自動更新やダッシュボードへのアクセスのところでもう少し手を入れる必要があるのですが。)

で今回の試したサーバ設定は、

  • 常時SSL
  • www にURL正規化
  • http から https にリダイレクト
  • WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス
  • WordPressの自動更新ができるように
  • FastCGI のスループットチューニング
  • 他もろもろ

で以下のような本番運用サーバ設定 (/etc/h2o/h2o.conf) になりました。

user: nobody
 
listen:
  port: 80
listen:
  port: 443
  ssl:
    certificate-file: /path/to/fullchain.pem
    key-file: /path/to/privkey.pem
 
hosts:
  "localhost":
    paths:
      "/":
      redirect:
        status: 301
        url: https://www.example.com/
 
  "www.example.com:80":
    paths:
    "/":
      redirect: https://www.example.com/
  "www.example.com:443":
    paths:
      "/":
        file.dir: /var/www/wordpress
        redirect:
          url: /index.php/
          internal: YES
          status: 307
 
file.index: [ 'index.php', 'index.html' ]
 
file.custom-handler:
  extension: .php
  fastcgi.spawn:
    command: "PHP_FCGI_CHILDREN=10 exec /usr/bin/php-cgi"
    user: example
  fastcgi.timeout.keepalive: 10000
 
access-log: "| exec sudo rotatelogs /var/log/h2o/access.log.%Y%m%d 86400"
error-log:  "| exec sudo rotatelogs /var/log/h2o/error.log.%Y%m%d 86400"
 
pid-file: /var/run/h2o/h2o.pid
http1-upgrade-to-http2: ON
http2-reprioritize-blocking-assets: ON

WordPressを動かすH2Oサーバ設定のポイント

WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセス

通常の設定では、WordPress ツールバーからダッシュボード (www.example.com/wp-admin/) へアクセスは、トップページを返してしまいます。

ダッシュボードにアクセスできるように file.index で index.php を追加して www.example.com/wp-admin/ で www.example.com/wp-admin/index.php にアクセスするようにしました。

WordPressの自動更新ができるように

H2O はデフォルトで nobody の下で動きます。 H2Oの管理下にある PHP も nobody で動きます。 WordPressの自動更新は、WordPressのファイル所有者の下でPHPが動かないと自動更新が働きません。 fastcgi.spawn には、どのユーザ user で動かすか指定できるので、WordPressのファイル所有者を指定して動かします。

FastCGI のスループットチューニング

fastcgi.spawn での PHP への接続は、デフォルトでは1回限りの接続です。これだとWordPressが動くたびにコネクションが発生します。 fastcgi.timeout.keepalive で Keep-Aliveを 10 秒に指定。一定時間 FastCGI の接続を継続させてスループットを改善してみました。

まだまだキャッシュ周りやいろいろチューニングができそうなので、運営しつつ試してみたいと思います。

参考サイト

sudo「コマンドが見つかりません」PATHが初期化されているときの対処法

sudo でコマンドを実行すると、「command not found」とエラーに。環境変数 PATH が通っていないと思って設定しても変わらず。実は sudoers の設定でセキュリティ上環境変数が初期化されている。そのときの対処備忘メモ。

現象

  1. sudo でコマンドを実行
  2. 「command not found」 (コマンドが見つかりません) とエラーに
  3. .bash_profile にパスを設定してみる
    vi ~/.bash_profile
    
    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin
    

    から

    PATH=$PATH:$HOME/bin:/sbin:/usr/sbin:/usr/local/bin
    

    に変更。

  4. sudo でコマンドを実行
  5. 再び「command not found」 (コマンドが見つかりません) とエラーでパスが通っていない

さらに突き詰めると、

sudoers の env_reset オプションが有効になっている

原因

sudoers の env_reset オプションが有効になっている場合、セキュリティ上環境変数が初期化されて secure_path に設定しているパスが使われるので、環境変数 PATH が通らない。

解決

3つの方法でパスを通す

sudoers はデフォルトでは env_reset オプションが有効になっている。無効化するか、環境変数を引き継ぐか、または secure_path にパスを設定することで環境変数 PATH を通す。

sudoers は visudo コマンドで編集できる。設定が間違っていたらエラーチェックもしてくれるので、直接ファイルを編集することは控える。

1. 無効化する場合

コメントアウトして env_reset オプションを無効化。

#Defaults env_reset

2. 環境変数を引き継ぐ場合

以下を追記

Defaults env_keep += "PATH"

そして以下をコメントアウト

#Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

.bash_profile に設定したパスが通ります。

3. パスを設定する場合

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin

から

Defaults    secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin

に変更してパスを追加

sudo でコマンドを実行して確認。 complete!!

教訓

環境変数 PATH の設定の他、env_reset が有効化されているかどうかも確認しよう。

関連サイト

「#!/usr/bin/perl –」はFTP転送モードの問題? 実はFTPサーバ設定の問題

Perl のパス 「#!/usr/bin/perl -w」では正常に動くのに、「#!/usr/bin/perl」では「Internal Server Error」に。

cgiスクリプトの記述や設定が正しくなかったり、サーバ内部でエラーが発生した場合に返されるのが「Internal Server Error (HTTPステータスコード500)」。エラーがあるのは分かるが、原因がわからない、Webエンジニアにとって頭を悩ます「Internal Server Error」。

その原因も様々。原因が明らかにできなければ対策も解決もできない。Perl パスの問題かと思いきや、FTPの転送モードの問題?、実はFTP サーバ設定の問題というちょっと複雑。そんな問題に直面した備忘メモ。

現象

  1. FTP を使ってアスキーモードでファイルをアップロード
  2. Perl のパス 「#!/usr/bin/perl」 では cgi が 「Internal Server Error (HTTPステータスコード500)」に
  3. Perl のパス 「#!/usr/bin/perl -w」 または 「#!/usr/bin/perl --」 では正常に動作する
  4. 改行コードが問題と思ってファイルの改行コードを「LF」に変換
  5. 再度、FTP を使ってアスキーモードでファイルをアップロードしても同じ現象に
  6. 「あれれ」無限ループにはまる。

さらに突き詰めると、

シェル上でスクリプトを走らせると、

/usr/bin/perl^M: bad interpreter: No such file or directory

とエラーに

さらに突き詰めると、

FTP サーバに vsftpd を使っている

原因

FTP サーバ vsftpd では、ファイルの改行コードが変換されないこと。

解決

改行コードを「LF」に変換するだけという、単純なものではありません。

実際は、ファイルをアスキーモードでFTPアップロードしても、改行コード「LF」に変換されません。

それは、FTP サーバ vsftpd ではアスキーモードでのダウンロード・アップロードのデフォルト設定が無効になっているから。

ということで vsftpd の設定をしてみる。

1. vsftpd の設定をする

シェル上で vsftpd.conf を編集。

vi /etc/vsftpd/vsftpd.conf

設定内容を

ascii_download_enable=NO
ascii_upload_enable=NO

から

ascii_download_enable=YES
ascii_upload_enable=YES

に変更して有効に

2. vsftpdを再起動

service vsftpd restart

3. ファイルを再度アップロードする

4. 確認。Perl のパス「#!/usr/bin/perl」でうまく表示できた。

complete!!

教訓

FTPの転送間違えの他、視野を広げてFTP サーバの設定も診てみよう。

関連サイト

専用サーバ運営では必須の不正アクセス対策 SSHのポート番号変更

サーバを運営していると、SSH経由でユーザ名とパスワートの総当たりで不正な接続を試みる攻撃 (ブルートフォースアタック) を受けることが多い。ログ監視ツール Logwatch から毎日送られてくるレポートでも多数確認できる。root には数千件の数で試みられているのが見受けられることも。

対策は、ssh のポート番号を変更すること。デフォルトのポート番号 22 での接続を避ける。

デフォルトのポート番号 22 から別の番号に変更することで断続的な不正アクセスを無くして、サーバの負荷軽減にもなる。

ということで、sshのポート番号を変更。

設定ファイルを編集。

$ vi /etc/ssh/sshd_config

デフォルトではコメントアウトでポート番号 22 が使われているので、任意のポート番号 **** に変更。ポート番号は、使用されていない 0~1023 (ウェルノウンポート) 以外のポート番号に変更しましょう。

#Port 22
Port ****

SSHを再起動。

$ /etc/init.d/sshd restart

iptablesの設定

iptables でファイアウォールの設定をしている場合、変更したポートを通す必要があります。設定せずに ssh の接続を切ってしまうと、ssh に接続できなくなるので要注意。

$ vi /etc/sysconfig/iptables
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT

から

-A INPUT -p tcp -m tcp --dport 任意のポート番号 -j ACCEPT

に変更。

iptablesを再起動して、設定を再読み込み。

$ /etc/rc.d/init.d/iptables restart
iptables: Setting chains to policy ACCEPT: filter [  OK  ]
iptables: Flushing firewall rules: [  OK  ]
iptables: Unloading modules: [  OK  ]
iptables: Applying firewall rules: [  OK  ]

接続確認

接続確認は、念のため元のターミナルでの接続を保ちつつ、新規ウインドウでターミナルを立ち上げて接続を確認することをおすすめします。

まずはポート番号 22 で接続。

$ ssh ユーザID@ホスト名
$ ssh: connect to host **.**.**.** port 22: Connection refused

ポート番号 22 では接続が拒否される。

変更したポート番号で接続。

$ ssh -p ポート番号 ユーザID@ホスト名

接続できれば完了。

analogのログフォーマット (turn debugging on or try different LOGFORMAT)

Cron からアラートメールが返ってくる。

/etc/cron.daily/logrotate:
/usr/bin/analog: analog version 5.32/Unix
/usr/bin/analog: Warning L: Large number of corrupt lines in logfile stdin:
turn debugging on or try different LOGFORMAT
(For help on all errors and warnings, see docs/errors.html)
Current logfile format:
%v %S %j %u [%d/%M/%Y:%h:%n:%j] "%j%w%r%wHTTP%j" %c %b "%f" "%B"\n
%S %j %u [%d/%M/%Y:%h:%n:%j] "%j%w%r%wHTTP%j" %c %b "%f" "%B"\n
%S %j %u [%d/%M/%Y:%h:%n:%j] "%j%w%r" %c %b "%f" "%B"\n
%S %j %u [%d/%M/%Y:%h:%n:%j] "%r" %c %b "%f" "%B"\n

analog のログフォーマットが違うみたいだ。Apache のログ形式は combined なので、analogの LOGFORMAT ( /etc/analog.cfg ) を確認。なかったので末尾に以下を追記。

LOGFORMAT COMBINED

Apache のログ形式を変更したときには見直すことを忘れずに。