さくらのVPS-経過-

現在、当サイトをさくらのレンタルサーバからVPSへ移動中です。

一応、VPSでサイトを立ち上げることができましたが、まだまだ詳細な部分がしっくりきていません。

さくらのレンタルサーバからVPSへの移行に関して、嵌った事項などについて簡単に紹介します。
 

OSの選択

最初に迷ったのがOSの選択です。
基盤になるためどのOSを選択するのかは非常に重要に思いました。
VPSの場合、契約時には標準OSしか選択できませんので、カスタムOSを選択する場合は専用のコントロールパネルから行うことになります。
※カスタムOS以外にISOイメージからのインストールも可能です。
VPSコントロールパネル

とりあえず、標準OSではパーティション変更ができないようだったので、自宅サーバを公開していたときに使っていたDebian GNU Linux、さくらのレンタルサーバと同じFreeBSD、ビジネスで使用されているRedHat Enterprise Linuxと互換性のあるCentOSの中から決めることにしました。
Linuxのパッケージ管理がきちんとしていないと芋づる式であれやこれやとインストールしていくことになり、そのうち、バージョンの整合性で結局導入できないといった経験を過去にしたことがあり、そのときはDebianで落ち着いたのですが、最近は、そういうことがないようなのでどれを選択しても問題はなさそうです。
 

アクセス制限

これは注意点になります。
OSを起動した状態では、rootユーザでしかリモートログインできません。
このことを利用して、SSHによりrootユーザでのログイン試行が頻繁に行われています。
ファイアーウォールの機能としてはiptablesが有効にはなっていますが、すべて許可の設定ですので無意味です。

このiptablesの設定を「/etc/sysconfig/iptables」ファイルを作成して編集した場合、「system-config-firewall-tui」でファイアーウォール設定を行うと、先ほど作成したiptablesファイルが削除されたり別の内容に書き換わってしまいますので注意が必要です。

ipはデフォルトでipv4とipv6の両方が有効になっていますので、iptablesもipv4用とipv6用が必要になります。
仮にipv6は使用しない場合、ipv6を無効にできる設定方法がいくつかありますが、本当に無効化できているのか?
という疑問があります。
無効化の設定をしたはずが、netstatで確認するとipv6でlisttenしていていたり、ifconfigでインターフェースを確認するとipv6の記述があったりなどなどあります。
確実に無効にできているかが不安だったので、ipv6を有効にしたまま、ip6tablesを作成してパケットをフィルターするほうが確実に思えました。
「system-config-firewall-tui」でファイアーウォールを有効にして、カスタムで許可するサービスを選択すればiptablesとip6tablesを作成してくれますので、これを雛形に利用しました。
ただ、設定が反映されてしまいますので、誤った設定をすると最悪はリモート接続できなくなる可能性もあり、注意が必要です。

あとは、メールサーバなどの設定でipv6を無効にできるものはそうするように意識して設定するようにしています。

SSHは使用するポートを変更し、rootでのログインは拒否するように設定してあります。
ただし、この設定をする前にリモート接続用のユーザを作成し、そのユーザでrootにスイッチユーザできる設定をしておかないと、接続できないまたは接続してもrootになれないといった事態になってしまいます。

※VPSのコントロールパネルにある「リモートコンソール」であれば設定に関係なくrootでログインが可能ですので、設定ミスをした際はこちらからログインして修正すればなんとかなります。
 

DNS(Aレコード)の変更タイミング

レンタルサーバでは、独自ドメインのAレコードは、共有サーバ(レンタルサーバ)のIPアドレスに設定しています。
移管しているドメインがある場合は、「会員メニュー」→「契約情報」ページの左側にある「ドメインメニュー」→「ドメインリスト」からゾーン編集が行えます。
※VPSコントロールパネルの「ネームサーバ登録」からも可能です。
さくらのDNSを使用するので、DNSを立ち上げる必要性はありません。

Aレコードに登録してあるIPアドレスをVPSのIPアドレスに変更すれば、そのドメイン名でアクセスした場合には、VPS側にアクセスします。
インターネット全体への反映には時間がかかりますので、反映されたかどうかは自分のPCから直接nslookpコマンドで確認すればよいと思います。
※このときVPSやレンタルサーバ上から確認しても、さくらのDNSに反映されたかどうかだけのことなので、あまり意味がありません。

メールサーバやWEBサーバの動作確認には、実際のドメイン名を使わないとできないので、利用中のドメインの場合は、VPS側の設定がうまくいっていないとインターネットからはサービスが利用できない状態になってしまうので面倒です。

独自ドメインを2つ取得したのは妻用と自分用となので、まずは自分用で試して問題なければ妻用を移動させればよいかと思っています。
現在は、自分用の独自ドメインは変更が反映された状態ですのでVPS側を利用しています。
 

メールサーバの設置

レンタルサーバでは「さくらのメールボックス」といわれるメールサービスが提供されていました。
メールユーザは無制限に追加でき、レンタルサーバ用の初期ドメイン(sakura.ne.jpのサブドメイン)、独自ドメイン、さくらのサブドメイン(2個まで無料)のすべてのドメインでメールユーザ名(@マークの前)共通でメールの送受信が可能でした。
※メールユーザを1つ作成すれば5ドメインのメールアドレスでメールの送受信が可能

その代替としては、VPSでメールサーバを構築するか、「さくらのメールボックス」(有料)を別途申し込むか、それともそのメールアドレスの使用をやめるかの3択になるかと思います。

自前で「さくらのメールボックス」相当のメールサーバを構築するとなると、SMTPサーバ、POPまたはIMAPサーバが必須になります。
また、クライアントからそれぞれに接続するためのユーザの作成、パスワードの管理、認証方式、暗号化方式、不正中継対策、転送設定、ウィルス対策、スパム対策などなどを考えると、もう頭がパニック状態です。

10年以上前にはこれらサーバを構築した経験がありますが、そのころとはスタンダードが代わっている様でどの組み合わせで何ができるのか全くわからずでした。
検索でヒットしたサイトを参考にするのが近道に思えますが、思い通りの動作をしない場合は原因究明に時間がかかり、最初からドキュメントを読んだほうが確実で早いと思いました。

Postfix+Dovecotでとりあえず構築してみました。
一応、バーチャルドメインとメールユーザなどのマップはPostfixAdminでMySQLサーバに登録しそれを参照するように構成しました。

いきなりマップをデータベースで管理するように設定したため、うまく動作しなかったときに何がどこでだめなのかが全くわからず嵌りました。
最初は、マップ情報はファイルを編集、データベースファイルを作成して、それを使って構成すれば原因究明も楽だったと思いました。

postmap -q hoge@example.com mysql:/etc/postfix/mysql-virtual_domain_maps.cf

とすれば、データベースを参照した戻り値を確認できます。

メール関連ではスパム対策とウィルス対策が今後の課題です。
さくらのサブドメインで受信したメールをどうするかがまだ手付かずです。
 

WEBサーバの設定

レンタルサーバで公開していたサイトは、独自ドメインで2ドメインになります。
そのうち、ひとつがDrupal、もう一方がMovableTypeです。
さらにレンタルサーバでは初期ドメイン(sakura.ne.jpのサブドメイン)が付与され、追加でさくらのサブドメインを無料で2つ取得できますので、すべてをあわせると5ドメインありました。
それ以外にレンタルサーバでは「さくらのブログ」というブログサービスが付与されており、すぐに利用できるブログもあって、ブログ用途では6ドメイン分使える状態にありました。

レンタルサーバのときには、初期ドメインとその他追加のドメインで、rewriteルールの設定で嵌りました。
初期ドメインを使う予定がなかったので、当初は初期ドメインでアクセスした場合を考慮しておらず、さくらのレンタルサーバでは「Options Indexes」が設定されているために、初期ドメインでアクセスするとディレクトリの一覧が表示されてしまっていました。
root権限がないので.htaccessで対応するしかありませんでした。

VPSにするとroot権限でなんとでもできるので、初期ドメイン(sakura.ne.jpのサブドメイン)でアクセスできないようにもできます。

apacheの場合、conf.d/*.confをインクルードするように設定されているため、conf.dにそれぞれバーチャルホスト(ホストネームベース)の設定を作成していました。
しかし、この場合、apacheを起動するとすべての設定が読み込まれるため、どのドメイン名でアクセスしても、管理用途で導入した、たとえばwebminやPostfixAdminやphpmyadminのページにアクセスできてしまっていました。

あまりよろしくないなぁということで、初期ドメインとIPアドレスでのアクセスの場合のみwebminやPostfixAdminやphpmyadminのページにアクセスできるようにバーチャルホスト(IPアドレスベース)を構成しました。
 

IPアドレスによるアクセス制限の問題

日本国内で使用されているIPアドレス以外からのアクセスを拒否しています。
※クローラは海外のIPアドレスを使用している場合がほとんどなので追加で許可しています。
このアクセス制限をレンタルサーバではドキュメントルートに設置していましたが、バーチャルホストごとにドキュメントルートを変更しているため、サーバ設定ファイルに記述していました。
サーバ設定ファイルに記述するにはディレクトリの場所を指定しなければなりませんので、「<Directory />」内に記述していました。
せっかくroot権限が使えるわけなのでわざわざ.htaccessを使うのもどうかと思った次第ですが、挙動がおかしかったようで、一時、海外からのアクセスが可能だった時期があり、Drupalにユーザ登録された件数が20件以上になっていました。
登録はできるようにはしているのでそれ自体は問題ないのですが、日本語で伝わらない方とはコミュニケーションが困難なので海外からのアクセスは制限していました。
※ユーザ登録はできますが、コメントすることくらいしかできません。
また、MovableTypeのサイトのほうへはコメントスパムが大量にあり、一応、コメントスパム対策はしてありますがイタチゴッコなのでIPアドレスで制限するようにしました。

従来どおり.htaccessで設置しようとしましたが、何箇所にも配置するとメンテナンスが面倒です。
バーチャルホストのドキュメントルートを見直せば一箇所に設置するだけで済みそうです。
 

Drupalのパーミッション問題

次に嵌った(正確には進行形です)のが、Apacheの実行ユーザ/グループとDrupalのファイルのパーミッションの問題です。
レンタルサーバでは、「ユーザホームディレクトリ」/www/drupalが、Drupalの導入ディレクトリでした。
ファイルのオーナーは「ユーザ名:ユーザグループ」でディレクトリは755、ファイルは705などユーザ以外には書き込み権限がない状態にしていました。
それでもまれに「Internal Server Error 500」が発生していたので、rewriteルールの影響かパーミッションの影響だろうと推測していましたが、何かの機能が使えないということはありませんでした。

VPSでは、レンタルサーバのdrupalディレクトリをそのまま、ファイル転送し、データベースはエクスポート/インポートして、うまく動作しているようでした。
しかし、Drupal管理ページの「サイトの状態」(admin/reports/status)で確認すると、次の2点の問題がありました。
 

書き込み権の問題

ファイルシステム(デフォルト:sites/files)、CTools CSS Cache、XML sitemap cache directoryの書き込み権限なし
※すべてファイルシステムの書き込み権の影響によるものです。

Drupalディレクトリのオーナー(ユーザ/グループ)とApacheの実行ユーザ/グループとで、アクセス権が不一致なため発生しています。
http://drupal.org/node/244924を参考に、Drupalディレクトリ内のファイルおよびディレクトリのパーミッションを変更、さらにはApache実行ユーザをDrupalディレクトリのユーザグループに追加して対処しました。
 

Mime type detectionの要件不十分

「Mime Detection」モジュールでは、Fileinfoを取得するためにmagicファイルを使用していますが、そのファイルがロードできていないため発生しています。
Apache起動時にロードしていたはずなのになんでだろう?と思いましたが、phpモジュールで使うのでphp.iniもしくはsettings.phpで設定しないといけなかったようです。
以下の3行をsettings.phpに追加しました。

$conf = array(
    'mimedetect_magic' => '/usr/share/file/magic',
    );

上記2件は対処できたものの、実際にDrupalでファイルアップロードなどの作業をしてみないと気づかないものとして拡張モジュールのアップデートの問題があります。
 

update managerの問題

Drupal 7.xからだと思いますが、「update manager」により、モジュール更新ページから、モジュールのダウンロードから更新まで一連の作業を管理画面上(GUI)で行えます。
しかし、このアップデート時にFTP接続画面が表示されるようになってしまいました。
update manager
FTP接続による方法も「update manager」に含まれる機能ではありますが、レンタルサーバのころとは明らかに異なるため、不便さを感じました。
FTP以外に、SSH、SFTPでの接続が可能ですが、プルダウンリストに表示されるのは条件を満たしているものだけリストされます。

「update manager」をユーザインターフェースをスルーする方法(レンタルサーバのときと同じ方法)にするには、http://drupal.org/documentation/modules/update&に記載がある通り、DrupalディレクトリをApache実行ユーザ/グループに変更してやれば解決はします。
しかし、モジュールのアップデート処理で削除できないファイルが存在しているためアップデートが正常に終了しませんでした。
Drupalでは、Drupalディレクトリ以外にファイルアップロード時に使用するテンポラリをファイルシステム(admin/config/media/file-system)で設定してありますので、そのディレクトリのパーミッションが影響しているのかもしれません。

Apacheの実行ユーザ/グループに変えてしまうと、FTPでサーバへアップロードする際に面倒になるような気がしたので別の方法で回避したいところです。

すべてはバーチャルホストごとにApacheの実行ユーザ/グループを変更できれば解決するのかと思いますが、Apache 2.X系ではUserディレクティブとGroupディレクティブがバーチャルホストコンテキストでは使えないようです。
MPMのperchildであればできそうかなぁとも思いましたが安定性云々で不安がありますし、ほかの方法でPHPをわざわざCGIで動作させる変更作業も面倒でデチューンな気がしてしまいます。
mod_process_securityというモジュール(mod_securityではありません)を試してみましたが、管理画面のいくつかにアクセスできなくなったので使用をやめました。
「SuexecUserGroup」ディレクティブであればバーチャルホストコンテキストで使用できるのですが、CGIのみこのユーザ/グループで実行するのみですので効果はありません。

MovableTypeを使っているサイトは、CGIを使用しているので、この際、バーチャルホストをsuexecにあわせたディレクトリで構成して、ユーザ/グループをApache実行ユーザ/グループにするのがベストな方法なのかもしれません。

とりあえずは、暫定策として「update manager」は使わずにDrupal6.xのころと同じ方法でアップデートすれば済むことなので、そうしようと思います。
 

 

ToDo

  • クライアントからメール送信不可(SMTP AUTHのエラー)の対応
  • ローカルユーザからバーチャルユーザへのメール転送
  • SPAMの学習機能の正常化
  • Drupalのupdate managerの正常化
  • Drupalのパーミッション問題への対応
  • バーチャルホストごとにApache実行ユーザ/グループを変更する方法の調査

 

コメント

ToDoにある項目はとりあえず完了しました。

ToDoにある項目はとりあえず完了しました。 Update Managerの問題は、パーミッション関連をクリアにしても、「..」(親ディレクトリ)を削除できなくてエラーになるため、「includes/filetransfer/filetransfer.inc」にパッチをあてないとだめなようです。 ちなみにDrupal 7.22でバグFixしている模様です。 以下はDrupal 7.22のリリースノートからの抜粋です。 Fixed a bug which prevented Drupal's file transfer functionality from working on some PHP 5.4 systems.