カテゴリー: サーバー管理

今回のメールサーバーの目的は、現在使っているプロバイダ系のEメールをプロバイダからPOPして保存、IMAPサーバーとしてクライアントに公開するという物で、PCとか携帯、タブレットどれからでもメールが読み書き出来るようななるというWEBメールに近い環境が実現できるという物です。家サーバーの時はfetchmailコマンドを使って、プロバイダからPOPで落として来たが、専用サーバーということで、プロバイダからメール転送をかけることにした。これによりタイムラグ無くメールを読むことが出来るようになった（fetchmailだとポーリング間隔だけタイムラグが出来てしまう）。

imap環境は家サーバーのubuntuの時と同様にpostfixとdovecotの設定のみ。旧メールフォルダを家サーバーからtarしてscpしてtarしてVPSに転送、ついでにバックアップ。こちらを参考に取得したSSL証明書などもバッチリ反映させておけばSSLでアクセス可能。

SMTPでメール送信機能を持たせるのは家サーバーではやっていなかった事なので、後回しにします（一発ぶっつけでうまく動かなかった）。

せっかくなので、Webmail機能を持たせようと、SquirrelMailを導入したが、うまく動かない。ubuntuの時は何の問題も無くあっさり動いた物だが、パスワード認証のあと「このページにアクセスするにはアカウントが必要です。」というエラーメッセージが、httpdのログには何も載っていなかったので、不思議と思いググってみた所、どうも /var/lib/php/session の書き込み権限がないとか、、、ああ、思い当たった！家サーバーの時と条件を合わせるため、apacheの実行ユーザーをデフォルトと変えていたのでした。ubuntu と CentOSでは実行ユーザーが異なるため、同じ設定ではアクセスが出来ないということ。ということで、該当ディレクトリの所有者を変更して、書き込み可能にすることで無事解決。

SMTP Authの設定は基本的にはimapの設定の時と同じページを参考に薦めればOKでした。最後の最後までうまく動かず悩ませた理由は単純なtypoでした。。。これは気をつけないといけない。

メールサーバーの機能はこれで必要な分一通り完了。メールアカウント一杯作れます。悪用禁止ｗ

サーバー移動にあたって、WEBデータの移動が大きな問題の一つでした。

家サーバーがubuntu8.10のまま長らく放置されていたのも、データベース移動がうまく行くかどうかに不安があったからだ、それに加えてPC自体の調子の悪さも相まって、「光学ドライブが動かない」「USBポートが不安定」などの理由でそのままにせざるを得なかったというのもありました。

今回の場合は、完全に引越であるので、失敗しても何度でもやり直せるということで、色々試してみた。

まず、WEBサーバーにインストールしたphpMyAdminを用いてバックアップ/リストアを行う方法。

全データを対象に行ったが、読み込みファイルサイズに制限があったので、あらかじめFTP転送しておいたバックアップファイルをリストアしようとしたが、rootですら書き込み権限が無いとかで失敗。どうもinformation_schemaというデータベースが問題であろうという所までは分かったが、放置。

mysqlのコマンドラインツールで全バックアップ/リストア

結局は上記理由で失敗。information_schemaは内部的な利用のための物で書き込むことは出来ないらしい・・・じゃなんでバックアップ/リストアの対象になっとんねん？って思ってしまうが、そういうわけで地味に最後の手段。

コマンドラインでちまちまデータベース一つずつバックアップ/リストア

結局はこれ。information_schema以外のデータベースをmysqldumpでちまちまバックアップ取って、リストア先で

mysql> create database wp-data default character set utf8

$ mysql  -u wpdata -p xxxx < backup.sql

でな感じであらかじめ（wpdata）というユーザー権限でデータベース（ここではwp-data）を作っておいて、バックアップデータである*sqlファイルを読み込みます。※ここのwpdataというユーザー名とwp-dataというデータベース名はバックアップ元に準じます。

あとは、ｈｔｍｌディレクトリを構造毎ファイル所有者に注意して複製して終わり。

ただ、この方法ではうまくいかず、ページのリンク関係がボロボロ。そりゃそうです。トップページのＵＲＬが変わったのだから、当然直リンしている所は破綻するわけで、ここを直さないといけない。幸いバックアップした*.sqlファイルはテキストなので、ここはsedを使って置き換えてしまいます。

$ sed -e ‘s/old url/new url/g’ backup.sql > backup1.sql

出来上がったデータで置き換えます（もちろんデータベースは一旦消して作り直します）。またコピーしたhtmlディレクトリの中にも旧URLを直接参照している所があるはずなので、これも出来る限り書き換えます。

grep ‘old url’ */* などして探して手動で書き換えられる程度の作業なので大したことはありませんでした。

これで、無事データ移植完了。

同じような感じで xoops も移植できました。

とりあえず、家サーバーでやっていた仕事を一通りさくらVPSにやらせることを目的にサーバー構築を進めます。

基本は公式っぽいさくらVPSマニュアルに沿って進めることにする。

• rootパスワードの変更
• yumアップデート
• 日本語環境構築　（/etc/sysconfig/i18n      =>  LANG=ja_JP.UTF-8）
• 作業用一般ユーザー作成。suグループに編入
• 鍵認証。telnetとかは危険なので、基本SSHでホストログイン。
  鍵はPuTTYでの作成が例ですが、Linuxマシンのクライアントから入る場合は
  ssh-keygen -t rsa で出来上がります。id_rsa (private key ) id_rsa.pub (public key)
• SSHポート変更 22番のままだと攻撃されちゃうので変更。
  /etc/ssh/sshd_conf
  あと必要な設定は、 PermitRootLogin no   としておくこと。
  さらに鍵持ってる人しか入れないようにするには  PasswordAuthentication no とすると完璧。
  ※ 上記設定は必ず鍵認証の確認を行ってからすること。でないと取り返しの付かないことになるかも・・・
  ※ VPSならVPSコンソールから入れば直せますがねｗ
  うちは家サーバーの頃から物騒なアクセスログを散々見ていますので、鍵付きでしか入れないようにしました。
• 次にファイアーウォール。 /etc/sysconfig/iptables  の編集と service iptables restart コマンド
  これはこの先何度も設定し直すことになるので憶えておくこと。さくらVPSのデフォルトではiptablesファイルが無いようなので、手順書にあるテンプレートファイルを導入し編集。

ここまで来ると、もう普通に使えるようになってるので、その他のhttpd、メールサーバーなどの設定に進みます。