nkjmkzk.net

powered by Kazuki Nakajima

Archive for 12月, 2008

LinuxでiSCSIを利用する

LinuxでiSCSIのストレージを利用するにはカーネルでiSCSIのドライバが有効になっていて、iSCSIイニシエータのソフトウェアがインストールされている必要があります。ドライバはディストリビューション付属のカーネルであれば大抵有効になっていると思いますので、iSCSIイニシエータのセットアップから開始します。Redhatであればiscsi-initiator-utilsとしてRPMが用意されていますのでこれをインストールします。

# yum install iscsi-initiator-utils

次にiscsiデーモンを起動します。

# service iscsi start

ここからイニシエータの設定を行っていきます。イニシエータの情報はデータベース管理されており、iscsiadmコマンドを用いてこのデータベースを参照、更新できます。
最初にターゲットの情報を取得してデータベースに登録します。

# iscsiadm -m discovery -t sendtargets -p 192.168.12.146
192.168.12.146:3260,1 iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000
192.168.12.143:3260,1 iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.0a000

-pオプションで指定したストレージのコントローラで接続可能なターゲットの情報一覧が表示されます。同時にデータベースへの登録も行われています。

次に接続したいターゲットを指定してログインします。

# iscsiadm -m node -T iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000 -p 192.168.12.146 --login

dmesgをみるとストレージが/dev/sdaとして認識されたことが確認できます。

# dmesg
scsi0 : iSCSI Initiator over TCP/IP
Vendor: HITACHI Model: DF600F Rev: 0000
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sda: 503316480 512-byte hdwr sectors (257698 MB)
sda: Write Protect is off
sda: Mode Sense: 77 00 00 08
SCSI device sda: drive cache: write through
SCSI device sda: 503316480 512-byte hdwr sectors (257698 MB)
sda: Write Protect is off
sda: Mode Sense: 77 00 00 08
SCSI device sda: drive cache: write through
sda: unknown partition table
sd 0:0:0:0: Attached scsi disk sda

この後は通常どおりのブロックデバイスの操作です。
普通にパーティションを作成するにはfdisk等を用います。

# fdisk /dev/sda

あるいはLVMを使用しているのであればpvcreateで物理ボリュームとして登録します。

# pvcreate /dev/sda

基本的なセットアップは完了です。
ターゲットについての設定情報を参照するには以下のようにします。

# iscsiadm -m node -T iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000 -p 192.168.12.146
node.name = iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000
node.transport_name = tcp
node.tpgt = 1
node.active_conn = 1
node.startup = automatic
node.session.initial_cmdsn = 0
node.session.auth.authmethod = None
node.session.auth.username = 
node.session.auth.password = 
node.session.auth.username_in = 
node.session.auth.password_in = 
node.session.timeo.replacement_timeout = 120
node.session.err_timeo.abort_timeout = 10
node.session.err_timeo.reset_timeout = 30
node.session.iscsi.InitialR2T = No
node.session.iscsi.ImmediateData = Yes
node.session.iscsi.FirstBurstLength = 262144
node.session.iscsi.MaxBurstLength = 16776192
node.session.iscsi.DefaultTime2Retain = 0
node.session.iscsi.DefaultTime2Wait = 0
node.session.iscsi.MaxConnections = 1
node.session.iscsi.MaxOutstandingR2T = 1
node.session.iscsi.ERL = 0
node.conn[0].address = 192.168.12.146
node.conn[0].port = 3260
node.conn[0].startup = manual
node.conn[0].tcp.window_size = 524288
node.conn[0].tcp.type_of_service = 0
node.conn[0].timeo.logout_timeout = 15
node.conn[0].timeo.login_timeout = 15
node.conn[0].timeo.auth_timeout = 45
node.conn[0].timeo.active_timeout = 5
node.conn[0].timeo.idle_timeout = 60
node.conn[0].timeo.ping_timeout = 5
node.conn[0].timeo.noop_out_interval = 10
node.conn[0].timeo.noop_out_timeout = 15
node.conn[0].iscsi.MaxRecvDataSegmentLength = 65536
node.conn[0].iscsi.HeaderDigest = None,CRC32C
node.conn[0].iscsi.DataDigest = None
node.conn[0].iscsi.IFMarker = No
node.conn[0].iscsi.OFMarker = No

これらの設定情報を編集するには同じくiscsiadmコマンドをアップデートモード実行します。

# iscsiadm -m node -T iqn.1994-04.jp.co.hitachi:rsd.d7h.t.11799.1a000 -p 192.168.12.146 -o update -n node.startup -v manual

* -o update : 操作モードをアップデートモードに指定
* -n : 設定項目を指定
* -v : 設定項目の値を指定

with one comment

Written by 中嶋 一樹

12月 6th, 2008 at 7:07 pm

Posted in Uncategorized

Tagged with ,

CentOS 5で仮想化システムを構築する(ゲストOSのセットアップ)

ゲストOSを作成するにあたりまずその仮想化のモードについて決めておかなければなりません。Xenには準仮想化と完全仮想化の2種類のモードがあります。それぞれのモードについての詳細な説明は割愛させていただきますが、Xenでは特に準仮想化モードを採用した場合に性能面に大きなアドバンテージがあります。今回はこの準仮想化に絞って話を進めていきます。

仮想化のモードに加えて、ゲストOSはその実体データの保存形式をパーティションベースのものとファイルベースのものから選択することができます。パーティションベースの方はホストOSで認識しているブロックデバイスのパーティションをそのままゲストOSに貸出し、その上にゲストOSをインストールします。このパーティションにはローカルマシン上のハードディスクや、iSCSIまたはFC接続のSANも利用可能です。
ファイルベースの方はパーティションは必要とせず、ファイルを作成してその上にゲストOSをインストールします。ファイルはホストOSからアクセスできるところにあればローカルマシン上のハードディスクにあってもリモートのNFSサーバ上にあっても構いません。
一般的にパーティションベースのゲストOSはディスクI/O性能がファイルベースのもの比べて優れていると言われており、一方ファイルベースのゲストOSはファイルとしてOSを取り扱えるという感覚から移動やバックアップ等が容易であると言われています。さらにファイルベースの場合、Sparseファイルという形式を用いることで実際に消費するディスク容量を大幅に削減することが可能です。このあたりのパフォーマンスや利便性の実際については後に詳しく検証を行いたいと思います。

それではゲストOSの作成方法を見ていきましょう。
CentOS 5ではゲストOS作成支援ツールとしてvirt-managerとvirt-installを提供しています。virt-managerではGUIを利用したウィザードでゲストOSの作成を進めることができます。virt-installは CUIでの操作になります。今回はX Windowが使えない環境でも利用できるvirt-installでの手順をご紹介します。

ゲストOSをパーティションベースで保存する場合はあらかじめパーティションを作成しておく必要があります。fdisk等のツールでゲストOS用に確保したい領域を「/dev/sda5」等として切り出しておきます。LVMの論理ボリュームも指定可能です。この時点でパーティションをフォーマットする必要はありません。ファイルベースで保存する場合はvirt-installで自動作成することができますので事前の準備は不要です。十分なディスクスペースがあることだけを確認しておいて下さい。

次にvirt-installコマンドにてゲストOSのインストールを開始します。virt-installは引数なしで実行すると対話形式でゲストOSに最低限必要なパラメータ入力を順に行うことができます。あるいは引数を与えることでパラメータを一括して指定することもできます。以下は引数を与えて実行する例です。

# virt-install \
--paravirt \
--name=vm01 \
--vcpus=1 \
--ram=512 \
--file=/srv/vm01 \
--file-size=5 \
--location=http://ftp.riken.go.jp/Linux/centos/5/os/x86_64 \
--nographics \
--nonsparse

以下、各オプションの説明です。
–paravirt : 仮想化モードに準仮想化を指定します。
–name : ゲストOSの識別名を指定します。
–vcpus : ゲストOSへの仮想CPU割り当て個数を指定します。
–ram : ゲストOSへのメモリ割り当て量(メガバイト単位)を指定します。
–file : ゲストOSを保存するファイル、またはパーティションを指定します。
–file-size : ゲストOSを保存するファイルのサイズ、つまりゲストOSに割り当てるディスクサイズ(ギガバイト単位)を指定します。
–location : OSのリポジトリを指定します。
*ちなみにlocationに上記の用にインターネット上のミラーサーバを指定するとインストールが開始されるまでに異様に時間がかかる現象がありました。僕の検証用のノートPCのネットワークカードの調子が悪いのが原因かもしれません。同じ現象に遭遇された方はLAN上にレポジトリを立ててやると回避できると思います。面倒ですが。
–nographics : CUIでのインストールを指定します。これを指定しない場合VNC接続でのインストールとなります。
–nonsparse : ゲストOSを保存するファイルにSparseファイルでない通常のファイル形式を指定します。

ファイルの作成が完了するとOSのインストールウィザードが表示されます。

あとはウィザードにしたがってインストールを進めて下さい。通常のOSのインストールと同じ手順となります。インストールが完了するとリブートを促されます。「OK」としてリブートを行うとゲストOSが再起動し、初回起動時のみいくつかの設定項目が表示された後でログインプロンプトが表示されます。Ctrl+]キーを入力するとゲストOSの端末からデタッチしてホストOSのコマンドプロンプトに戻ります。ゲストOSのコンソールに再びアタッチする場合は以下のようにコマンドを実行します。

# xm console vm01

vm01のところには起動中のゲストOSの識別名を指定します。ゲストOSの起動・停止は同様にxmコマンドにて行うことができます。
・起動

# xm create -c /etc/xen/vm01

・停止

# xm shutdown vm01

なお、xm createの際はゲストOSの識別名ではなく、ゲストOSの設定ファイルを指定することに注意して下さい。virt-installで作成したゲストOSの設定ファイルはデフォルトで/etc/xen/以下に保存されています。

ここまででゲストOSを稼働させるまでの基本的な流れと手順を確認しました。
以降では実際に「サーバ集約」という目的におてい仮想化システム構築をシミュレーションし、そのプロセスをひとつづつ解説していきます。

次回は仮想化システム構築の際に最初のハードルとなるサイジングについて焦点を当て、

・ゲストOSのパフォーマンスはどうなのか?
・一台の物理マシンにゲストOSは何台くらい稼働させられるのか?
・ハードウェアはどのように構成すればよいのか?

というところを中心に解説したいと思います。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:06 pm

Posted in Uncategorized

Tagged with ,

CentOS 5で仮想化システムを構築する(ホストOSのセットアップ)

CentOSでXenを用いて仮想化環境を構築する際のハウツーをまとめておきます。ちなみにRHEL5でも同様です。

まずXenのコンポーネントをインストールします。これは非常に簡単で、OSからインストールする場合にはインストール時のシステム構成選択で「仮想化」にチェックをいれてインストールするだけです。これでハイパーバイザーとXen用のカーネル、その他管理ツールやライブラリがインストールされます。すでにOSがインストールされている場合は「ソフトウェアの追加と削除」から「仮想化」を適用すれば同様にインストールできます。Xensource社のサイトから別途ソースをダウンロードして独自ビルドも可能ですが、環境によっては依存関係の問題で一筋縄ではいかないことがありますので今回は安定性を重視してディストリビューションに付属しているパッケージを採用することにします。

Xenについてパッケージをそのまま使うということはあらかじめビルドされたカーネルを使用するということになりますが、これは後々に不都合が発生する場合があります。例えばドライバを追加したい場合です。僕のいつも使っているThinkpad T60にはAtheros Communications社の無線LANが内蔵されていますが、このデバイスは現在正規のカーネルではサポートされていません(ドライバが含まれていません)。なのでこのネットワークインターフェースを使いたい場合には別途madwifiのドライバをインストール必要があります。カーネルモジュールとしてドライバを新たにインストールする場合、現在使っているカーネルのソースツリーが必要になりますが、自分でカーネルをコンパイルしていない限りカーネルのソースツリーはファイルシステム上には存在しません。したがって追加のドライバをインストールするにはカーネルソースツリーを手に入れる必要があります。CentOSや他の一般的なディストリビューションではバイナリ配布しているパッケージのソースをSRPMとして公開しています。今回はカーネルのSRPMをダウンロードしてそれらを適切に展開してファイルシステム上にカーネルソースツリーを構築します。

まずCentOSのミラーサイトより現在稼働しているカーネルに合致するSRPMをダウンロードして保存します。

# ls
kernel-2.6.18-8.1.10.el5.src.rpm

次にこのSRPMをインストールします。

# rpm -ivh kernel-2.6.18-8.1.10.el5.src.rpm

すると/usr/src/redhat/SOURCESにカーネルソース、パッチ、スクリプトが展開されます。
次に/usr/src/redhat/SPECSに移動して「kernel-2.6.spec」というファイルがあることを確認します。

# cd /usr/src/redhat/SPECS
# ls
kernel-2.6.spec

ファイルが確認できたらrpmbuildコマンドによってSOURCESディレクトリ以下のファイル群をマージしてソースツリーを構築します。

rpmbuild -bp kernel-2.6.spec

/usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64以下にカーネルソースが構築されます。
*僕の環境が64bitなので.x86_64になっていますが32bitだとi386とかなると思います。

これでカーネルソースの構築が完了です。ちなみにこの状態でmadwifiのmakeを試みると失敗します。madwifiはカーネルバージョンを判断するためにutsrelease.h等をチェックしにいきますが、カーネルソースがビルドされていないとこのファイルがまだ生成されておらず、カーネルバージョンの確認ができないためです。ということもあり、折角なのでこのディストリビューション純正のソースを使ってカーネルをビルドしてしまいます。
まずカーネルソースの直下に移動し、その後configsディレクトリの中からkernel-2.6.18-x86_64-xen.configを.configとして現在のディレクトリにコピーします。

# cd /usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64 # cp configs/kernel-2.6.18-x86_64-xen.config ./.config

このファイルはXen用のカーネルをビルドする際に使われるカーネルビルドオプションが記述されたファイルです。通常のカーネルにはないCONFIG_XEN=y等のオプションが追加設定されています。カーネルをいくらかカスタムしたい場合はそのままmake menuconfig等を実行してコンフィギュレーションを詰めます。その後通常通りにカーネルをビルド、インストールしていきます。

# make
# make modules_install
# make install

残念ながらmake installだけではinirdを自動で生成してくれないので手動で作成します。

# mkinitrd -v -f initrd-2.6.18-prep.img 2.6.18-prep

ちなみに2.6.18-prepは今回ビルドするカーネルの識別名になります。デフォルトだとコレになりますが、makeする前にMakefileのEXTRAVERSIONの値を書き換えれば指定も可能です。
これで現在のディレクトリにinitrdが作成されましたのでこれを/bootにコピーしてインストールします。

# cp initrd-2.6.18-prep.img /boot

あとgrubの設定ファイル(/boot/grub/menu.lst)も追記してあげる必要があります。以下のようなカンジです。

default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title CentOS (2.6.18-prep)
  root (hd0,0)
  kernel /xen.gz-2.6.18-8.1.10.el5
  module /vmlinuz-2.6 ro root=/dev/VG00/LV_root rhgb quiet
  module /initrd-2.6.18-prep.img
title CentOS (2.6.18-8.1.10.el5xen)
  root (hd0,0)
  kernel /xen.gz-2.6.18-8.1.10.el5
  module /vmlinuz-2.6.18-8.1.10.el5xen ro root=/dev/VG00/LV_root rhgb quiet
  module /initrd-2.6.18-8.1.10.el5xen.img

2.6.18-prepの方が今回追加したエントリになります。
これでめでたくカーネルソースツリーの構築とカスタムカーネルのビルドが完了しました。再起動して今作成したカーネルで無事ブートできればOKです。

ちなみにmadwifiをインストールするには以下のようにします。

# tar xvfz madwifi-0.9.3.2.tar.gz
# cd madwifi-0.9.3.2/
# make KERNELPATH=/usr/src/redhat/BUILD/kernel-2.6.18/linux-2.6.18.x86_64
# make install

ここまででインストールは完了。あとは以下のようにmodprobeを実行してドライバモジュールをロードしてデバイスを認識させます。

# modprobe ath_pci

ここまでで仮想化環境を構築するための土台であるハイバーバイザとDom0カーネルのビルドが完了しました。
次回はゲストOS(DomU)インストールについて説明します。

with 2 comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:05 pm

Posted in Uncategorized

Tagged with ,

マルチプロセッサー環境でKernelをビルドする

最近Linuxカーネルに傾倒しています。
いろいろ調べているうちにカーネルを何通りかでビルドしてテストすることになりました。カーネルのビルドは一度やってしまえばなんてことはない作業なのですが、調べていると何かと知らなかったことがわんさか出てきます。今回は手短に最近のマルチプロセッサ環境でのカーネルビルドHow Toをまとめてみます。

・カーネルソースをダウンロードする。
当然kernel.orgにあるわけですが、我々日本人は国際回線の帯域幅節約に貢献すべく日本国内のミラーサイトから手に入れるのがよいでしょう。僕はいつも理研さんに御世話になっています。
理研のミラーサイト

・展開

# tar xvfj linux-2.6.22.tar.bz2
# cd linux-2.6.22

・設定
ここはカーネルのバイナリを自分の環境に最適化させる上でもっとも重要な手順です。とはいえここに懲りだすと日が暮れるので今回はデフォルト設定を適用します。
カーネルビルドの設定は展開したトップディレクトリに.configとして用意します。当然自分でガリガリ書くのではなく、用意されている便利なツールを利用します。デフォルト設定の設定ファイル(.config)は以下のようにして作成します。

# make defconfig

ちなみにこの設定はLinusのメイン開発マシンとほぼ同じ設定だそうです。ほんまかな。

・ビルド
さて、カーネルをコンパイルしていきます。通常は以下のようにmakeを実行するだけでOKです。

# make

ここで実はなかなかに便利、というかマルチプロセッサー・オーナーにはもはや必須なオプションがあります。

# make -j2

この-jオプションはコンパイルのスレッド数を指定できるもので、例えばCore 2 Quadが搭載されているマシンであれば、-j4と指定するとマッハでコンパイルできるのではないかと思います。

実際にCore 2 Duoのプロセッサーが搭載されているThinkpad T60でビルド時間を計測してみました。

[-jオプションなし]

real 5m22.791s
user 4m56.123s
sys 0m23.153s

[-j2]

real 3m24.712s
user 5m0.723s
sys 0m24.834s

[-j4]

real 3m20.628s
user 5m3.811s
sys 0m25.606s

-jオプション有と無しでは1.7倍程度の差が出ました。もう-jオプション無しではビルドできません。ちなみにとある書物には「プロセッサ数 x 2」の値を-jオプションに与えるのがよいとされていましたが今回は-j2と-j4ではそれほど差異はありませんでした。

・インストール
あとは以下のようにすれば新しいカーネルのインストールは完了です。

# make modules_install
# make install

上記手順でインストールを行うにはmkinitrdが必要です。最近のディストリビューションにはほぼインストールされていると思います。上記コマンドを実行するとビルドしたカーネルを/bootにコピーし、grubのmenu.lstの追記やinitrdの作成も同時に行ってくれます。何て便利な世の中なのでしょうか。ただ、menu.lstの設定でデフォルトのカーネルにはなっていないと思いますので、menu.lstの「default」の値を編集するか、起動時にメニュー画面で今作成したカーネルを指定して下さい。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:04 pm

Posted in Uncategorized

Tagged with ,

IMAPを使う3の理由

せっかくなので何故にIMAPがいいのか語っておきます。

1. どのPCからでも同じメールにアクセスできる。
これが一番基本的なメリットだと思いますが、IMAPはメールのデータをサーバ上に保存するため個々のPCに依存しません。「あ、メールにあの情報があった気がするけど今PCもってない・・orz」のような状況はIMAPだと起こりません。 ただ、この点はWebメールには若干劣ります。 Webメールが実にブラウザとID/Passwordしか必要としないのに比べて、IMAPは一旦メールクライアントを設定する必要があるためです。 なのでネットカフェや友達のPCをちょっと借りてメールを、、という用途には向きません。

2. メールを簡単にサーバへアップロードできる
例えばpopのアカウント:nkjm-pop@gmail.comとIMAPのアカウント:nkjm-imap@nnd.jpがThunderbirdに設定してあったとします。するとユーザはnkjm-pop@gmail.comに届いたメールをnkjm-imap@nnd.jpにドラッグ・アンド・ドロップで簡単に移動できます。これはユーザエクスペリエンス的にはただフォルダ間をメールが移動しているだけですが、バックグラウンドではローカルPC上のメールデータがIMAPサーバへとアップロードされています。これが何故いいかというと、IMAPの特性であるメールの一元化の能力をさらに強力にするからです。
IMAPのメールをどのPCからでも見れるのは先に述べた通りですが、このアップロード機能を併用するとIMAPでないPOPのメールもあわせてひとつのサーバに集約することができます。複数メールアカウントを所持しており、その中にPOPしか提供してくれないメールサーバがあったとしてもIMAPサーバがひとつあればそこに全メールをまとめることができるわけです。 しかもこれがドラッグ・アンド・ドロップでできちゃうというのがスゴい。

3. Webメールより使いやすい
このGooglizeされた現代でこれを言うのは少しばかり勇気がいるのですが、非難を恐れずに言えば実はGmailってあんまり使い易いと思ったことがないのです。 以下、僕がGmailを使わない3の理由です。

1. フォルダ階層が作れない。
Web2.0の重要な要素のひとつにラベリングがあるのは周知の事実でGmailもそれを踏襲してると言えます。情報の合理的かつ共有を前提とした分類方法としてはたしかにFolksonomyは優れていると思いますが、僕はFolksonomyは個人の頭の中を整理するのには向かないと思います。メールの分類はユーザ個人が必要なメールがどこにあったか直感的に判断できることが重要です。フォルダ階層でそれを行うには計画的な階層設計が必要ですが、良く設計されたフォルダ階層はメールを分類するには非常に有用であると経験上感じます。

2. チェックボックスやプルダウンをつかった操作は面倒。
Gmailではメールを選択するのにチェックボックス、アクションを指定するのにプルダウンメニューを使用しますが、このようなチェックボックスやプルダウンを使った操作はドラッグ・アンド・ドロップに比べて一手以上多い手順を必要とします。特にビジネスにおいてメールは時間あたりに相当な量を受信します。繰り返し行う作業で手順がひとつでも増えるとそれは大きなストレスになります。

3. ロードが重い。
Gmailはログインしてトップページが表示されるまでにサーバと相当な処理が走ります。これはブロードバンド環境ではあまり気にならないのですが、PHS等低速回線を利用していると顕著になります。新幹線の車中でPHSを使うと当然コネクションの質はめちゃくちゃ悪くなるのでGmailを開くにはかなりの忍耐を必要としますが、POPやIMAPといった純粋なメールのプロトコルであればこの劣悪な環境でもなんとかサバイバルできます。

*ちなみに誇張してGmailを使わないと書いてますが実際は使いまくってます。

Ajaxという技術はたしかにスゴく、最初にGoogle Mapをみたときは唖然としました。しかしそれから世間のAjax熱は過熱感があると思っていて、今までローカルアプリで動かしていたものをなんでもかんでもAjax化してWeb上に持っていこうとしている気がします。 Ajaxは今までブラウザでできるとおもわれていなかったことを覆すという離れワザを実現した素晴らしい技術だと思います。 USのYahoo Mail Betaはこれまた凄まじいユーザインターフェースを提供しており、使い勝手はかなりローカルアプリに近くなっています。

ただし今のところまだ「メールをさばく」という一日に数え切れない程のオペレーションを要するところではThunderbirdのようなPCベースのアプリケーションが操作性、応答性において優れていると感じます。

したがって、このような操作性を誇るローカルのアプリケーションとIMAPのデータ集約性、アクセシビリティを組合せた形が快適なメール生活を送る上で僕にとっては理想的だと思った次第です。これからGmailは一回POPしてそれをIMAPで自分のサーバにアップしよっかなと思っています。

というわけで今日はIMAPで一日終わりそうです。お疲れさまでした。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:03 pm

Posted in Uncategorized

Tagged with ,

dovecot + MySQLでIMAPサーバ(over SSL)を構築する

その昔はIMAPサーバにはCourierIMAP + OpenLDAPを使用していましたが、このサーバの設定には中々苦労した思い出があります。 最近はdovecot + OpenLDAPという構成でやってきましたが、DBをMySQLやらPostgreSQLやらOpenLDAPやらといろいろ動かしているとメンテナンスや移設のときに結構しんどいので、現在VPSで新たに環境を構築する上ではDBは基本的にMySQLに集約することにしました。 (そもそも当初はいろんなサーバの構築ができるようにと勉強目的で複数種のDBを動かしていましたが、もういいや、ということで。)

環境はdovecot-1.0.3, MySQL-5.0.41, CentOS-5.0です。前提としてMySQLはすでに/srv/mysqlとしてインストールされているものとします。dovecotと連携させる上でMySQLを特段追加のオプションを付けてビルドしなければならないといったことはありません。MySQL側では認証用のDBとテーブルを用意するだけでOKです。

ちなみに僕はソースからビルドしたアプリケーションはすべて/srv/以下に置くことにしているのでdovecotのインストールパスもそれにしたがいます。

手順は以下のようなステップとなります。
・dovecotのインストール
・Unixユーザの追加
・メールボックスの作成
・設定ファイルの編集
・データベースの作成

では上記のステップを順を追って見ていきます。
まずdovecotをソースからビルドしていきます。まずconfigureを適切に行う必要があります。

# tar xvfz dovecot-1.0.3.tar.gz
# cd dovecot-1.0.3
# CFLAGS="-I/srv/mysql/include/mysql" LDFLAGS="-L./srv/mysql/lib/mysql" ./configure --prefix=/srv/dovecot --with-mysql

MySQLと連携させるためにはMySQLのヘッダファイルとライブラリファイルへのパスを認識させる必要があります。 今回の環境の場合ではMySQLが/srv/mysqlと通常のパス設定では認識できないところにあるのでこれをconfigure時に認識できるようにCFLAGSとLDFLAGSを設定してあげる必要があります。

configureの結果をみて以下の用に「Building with SQL drivers」のところにmysqlと表示されていればOKです。

Install prefix ...................... : /srv/dovecot
File offsets ........................ : 64bit
I/O loop method ..................... : poll
File change notification method ..... : dnotify
Building with SSL support ........... : yes (OpenSSL)
Building with IPv6 support .......... : yes
Building with pop3 server ........... : yes
Building with mail delivery agent .. : yes
Building with GSSAPI support ........ : no
Building with user database modules . : static prefetch passwd passwd-file checkpassword sql (modules)
Building with password lookup modules : passwd passwd-file shadow pam checkpassword sql (modules)
Building with SQL drivers ............: mysql

なお、今回はIMAPサーバへの接続をIMAP over SSLにするので「Building with SSL support」の結果も同時に確認しておく必要があります。 もしyesとなっていなければOpenSSLのライブラリが正しく認識できていないので、CFLAGS, LDFLAGSにOpenSSLのヘッダファイル、ライブラリファイルへのパスも含める必要があります。(OpenSSLが既にインストールされている前提)

あとは通常通りコンパイル、インストールを行います。

# make 
# make install

次に必要なUnixユーザを作成します。

# useradd -s /bin/false dovecot
# useradd -s /bin/false -u 501 vmail

dovecotはサーバ起動用のユーザ、vmailは実際にメールボックスを操作するユーザです。
後に作成するメールボックスのディレクトリツリーはこのユーザに所有される必要があります。なお、dovecotのデフォルトの設定上、vmailのユーザIDは500以上としておいた方がよいでしょう。これらのユーザにはシェルは必要ないのでログインシェルには/bin/false等を指定して無効化しておきます。

メールボックスのルートとなるディレクトリを作成します。

# mkdir /var/spool/vmail
# chown -R vmail:vmail /var/spool/vmail

これはどこでも構いませんが、先に作成したvmailユーザによって書き込めるようにパーミッションを設定しておく必要があります。

メインの設定ファイルを作成します。/srv/dovecot/etc/dovecot-example.confというテンプレートが用意されていますのでこれをベースに編集していきます。

# cd /srv/dovecot/etc # cp dovecot-example.conf dovecot.conf # vi dovecot.conf

ポイントとなる箇所を抜粋して記載します。特に重要なパラメータのみコメントしています。

protocols = imaps
disable_plaintext_auth = no
log_path = /var/log/dovecot.log
ssl_cert_file = /srv/dovecot/etc/ssl.crt
ssl_key_file = /srv/dovecot/etc/ssl.key

# メールボックスの形式にMaildirを指定し、その場所を指定します。後にデータベースで設定するメールアカウントには「home」というフィールドがあり、mail_locationを「~/」と設定することでこのhomeフィールドの値がそのまま各ユーザのメールボックスへのパスになります。

mail_location = maildir:~/

mail_debug = yes
protocol imas {
 ssl_listen = *:993
 login_executable = /srv/dovecot/libexec/dovecot/imap-login
 mail_executable = /srv/dovecot/libexec/dovecot/imap
}
auth_executable = /srv/dovecot/libexec/dovecot/dovecot-auth
auth_default {
 mechanisms = plain
 #passdb pam {
 #}

#認証用のデータベースにSQLを指定しています。dovecotでは既定でパスワード情報を取得するためのSQLクエリとユーザ情報を取得するためのクエリの2クエリを発行しますが、userdb prefetchを設定することによってこれらのクエリを1クエリにまとめることができます。

 passdb sql {
  args = args = /srv/dovecot/etc/dovecot-sql.conf
 }
 userdb sql {
  args = args = /srv/dovecot/etc/dovecot-sql.conf
 }
 userdb prefetch {
 }
}

SSL接続のためのRSA秘密鍵と証明書は既に作成してある前提ですが、もしまだ作成していなければ以下のように作成しておきます。

# openssl keygen 1024 > /srv/dovecot/etc/ssl.key
# openssl req -new -x509 -days 365 -key /srv/dovecot/etc/ssl.key -out /srv/dovecot/etc/ssl.crt

次にSQLの設定ファイルを作成します。

# cd /srv/dovecot/etc
# cp dovecot-sql-example.conf dovecot-sql.conf
# vi dovecot-sql.conf

以下が設定ファイルの中身です。

driver = mysql
connect = host=/tmp/mysql.sock dbname=mail user=root
default_pass_scheme = PLAIN
password_query = SELECT userid as user, password, home as userdb_home, uid as userdb_uid, gid as userdb_gid FROM users WHERE userid = '%u'
user_query = SELECT home, uid, gid FROM users WHERE userid = '%u'

僕の環境ではMySQLは同一サーバ上にあるのでアクセス制御を容易にするためにconnect=にhost=/tmp/mysql.sockとUNIX SOCKETを指定していますが、TCP/IPでMySQLに接続する場合はここにホスト名(またはIPアドレス)を指定します。user=にはrootを指定してうるぅあ!って感じで接続することになっていますが、適宜適切な権限のユーザを指定したりパスワードをpassword=パラメータで追加したりして下さい。
password_queryとuser_queryは後に作成するデータベースのテーブルスキーマに合わせて設定しています。

次に認証用のデータベースを作成します。

# mysql -u root
> CREATE DATABASE mail;
> USE mail
> CREATE TABLE users (
  userid VARCHAR(128) PRIMARY KEY NOT NULL,
  domain VARCHAR(128) NOT NULL,
  password VARCHAR(64) NOT NULL,
  home VARCHAR(255) NOT NULL,
  uid INTEGER NOT NULL,
  gid INTEGER NOT NULL
);
> INSERT INTO users VALUES ('nkjm','nkjmkzk.net','nkjm_passwd','/var/spool/vmail/test', 501,501);
> q

ここではまず「mail」データベースを作成し、実際にメールアカウントを格納するテーブル「users」を作成しています。このテーブルの中のdomainフィールドは今回特に気にする必要はありません。useridとpasswordがユーザがメールクライアントのアカウント設定でログインidとパスワードに指定するものになります。homeはこのユーザのメールデータが格納されるディレクトリになります。このディレクトリは初回ユーザがログインした際に自動的にdovecotが作成してくれます。なんて便利なんでしょう! uidとgidには先に作成したvmailユーザのuidとgidを指定します。最後にテストアカウントとして’nkjm’を作成しています。

これで構築は完了です。
/srv/dovecot/sbin/dovecotを実行してサーバを起動し、メールクライアントから接続できます。クライアントのアカウント設定では接続方式にSSLを指定して宛先ポートを993に指定することをお忘れなく。うまくいかないときは/var/log/dovecot.logのメッセージがシューティングに役立つと思います。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:02 pm

Posted in Uncategorized

Tagged with , ,

最近のRedhat系OSのrc.dをみておく

Linuxは起動時にinittabで指定されたランレベルnに応じて/etc/rc.d/rc[n].dの中のスクリプトを順次実行してサービスを開始していきます。

しなしながらこの中には各ユーザ環境によっては不要なものも含まれており、このようなサービスを全て起動させておくのはシステム資源の無駄であると同時に意図しないネットワークポートが開くこととなり、セキュリティ上も潜在的な穴が増えます。

さらに不要なサービスをそのままにしておくと起動にえらく時間がかかります。
Linuxの起動は以下の3つのステップで行われます。

1.Biosブート
2.カーネルブート
3.システムinit

このなかで「3.システムinit」は相当な時間を占めており、つまりはここを圧縮すればシステムの起動時間全体の圧縮に大きく寄与します。 あとは「1.Biosブート」でのメモリ検査等のシステム診断プロセスも相当な時間を要します。なのでH/W不良がこわくないヤンキーな人はこのあたりもオフってしまうのも手です。

というわけで前置きが長いわけですが、自分が基本的にRedhat系Linuxを使用するときにいるもの、いらないものを整理しておこうと思います。 僕は大体いつもサーバOSをインストールするとデフォルトのランレベルを4に切替えて、rc4.dのみをいじるようにしています。
rc.d内のスクリプトは全て/etc/rc.d/init.dへのシンボリックリンクになています。
直接このリンクを消したりしても目的は達成できますが、あとでまたサービスを復活させたいときに面倒なのでchkconfigコマンドを使って以下のようにするのが本道でしょう。

chkconfig --level [ランレベル] [サービス名] off

さて、本題のいらないサービスを網羅していきます。
いるいらいないの基準は僕の勝手によりXen環境を運用する上で最小限のもの、ということにします。

ーー仕事中なので続きはまた今度ーー

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 7:00 pm

Posted in Uncategorized

Tagged with

タイムゾーンの直し方

タイムゾーンがうっかりアメリカ時間になってました。

% mv /etc/localtime /etc/localtime.org
% ln -s /usr/share/zoneinfo/Japan /etc/localtime

としておきました。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 6:59 pm

Posted in Uncategorized

Tagged with

最近のホスティング事情

現在までかれこれ6年程自宅サーバでWebサイトやメールシステム等を運用してきましたが、この度外部のホスティングサーバを契約してそちらにサービスを移すことにしました。 理由は以下の通りです。

・現在自宅サーバはシングル構成で最近バックアップをまったくとっていないのでHDDが壊れちゃったらデータが全部吹っ飛んでしマウス。

・来年3月に引越しする予定だが引越し先ではそう簡単にグローバルIPをゲットできない。

・なんとなく外部のサーバを契約するっていうのも初めてなのでわくわくする。

というわけで先週末の土曜日に一日かけてホスティング業者の選定を行いました。
ホスティングの種類は大きく以下の3つがあります。

・Dedicated Server
・VPS (Virtual Private Server) / VDS (Virtual Dedicated Server)
・Shared Server

Dedicated Serverはその名の通り専用・占有サーバで、物理的なサーバ機をまるごと我が物として占有できるサービスで、マシンのリソースをフルに使える分パフォーマンス、自由度ともに最強ですが価格も3種類の中で最も高価になります。価格はおおよそ月額10000円以上ですが、安価なサービスでは10000円を切るものもあるようです。例えばこのThe Planetとか。しかも評判もそこそこ良い様子。

VPS/VDSは物理的なサーバに何らかの仮想環境構築技術を用いて複数の完全に独立したOS環境をユーザに提供するものです。仮想環境構築技術(ソフトウェア)にはVM Ware, Virtuozzo, Xen, UML等があります。 自由度はほぼDedicatedサーバと遜色なく、リブート、アプリケーションのインストール、設定等すべて自由に行うことができます。 パフォーマンスについてはやはりひとつの物理サーバに多くの仮想環境が稼働している程に劣化します。 しかし仮想環境構築ソフトウェアによって特定の仮想環境に割り当てる最低限のリソースを保証することができます。 例えば仮想環境AはCPUは最低600MHz, メモリは256Mbyte, HDDは10Gbyte、といった具合です。 VPS/VDSについてはこの最低保証リソースによってサービスレベルをわけているようです。価格レンジは日本円で月額2000円位から8000円位というところでしょうか。

最後がShared Serverで、これはひとつの物理サーバ上のひとつのOSを複数のユーザで共有するもので、一般的にはOSをユーザの都合によってリブートしたりアプリケーションを独自にインストール、カスタマイズすることはできません。自由度が最も低い分、価格は最も安価で、日本円で月額1000円以下でも契約することが可能です。アプリケーション設定に深く依存しない一般的なBlog等のWebサービスを展開するのであればこのレベルのサービスがリーズナブルということになると思います。

今回僕が検討したのはVPS/VDSのタイプ。何故かというと、やはり今まで自宅サーバで運用していると単にコンテンツをもっていけば稼働するというシステムばかりではなく、アプリケーションの設定に紐付いて稼働しているものが存在するからです。その他にもやはりいろんなアプリケーションやプログラムの検証をかねて動かしていた部分もあるので、インターネットにWebコンテンツを公開できればOK!というわけではなく、自分でOSを完全にコントロールできないと厳しい(楽しめない?)というのがあります。

というわけでVPS/VDSのサービスをいろいろみてみましたがやはり海外の方が圧倒的にサービスが豊富。 価格も国内のものとくらべて同レベルのサービスだと総じて安価であると思います。 ただしこのホスティングってやつはなかなかクサイ商売のようで、各社営業がかなり激しいです。 ただWebを閲覧しているだけでも「担当者とChatしませんか?」みたいなポップアップがでてきたり(そして実際してみた)、オーダーフォームがかなり作り込まれていて、Submitボタンを押さなくてもテキストボックスにメールアドレスをいれただけもJavascriptで自動的にPOSTされているようで、後に「Don’t Go! I miss you. Here is the special coupon only for you.」みたいなメールが来てびっくりしました。 

そんなこんなで海外のホスティングに関するフォーラムを数時間読みふけっていろいろ情報収集し、以下の3つにしぼりました。

ServInt
ProVPS
ZONE.NET

ServIntは老舗です。価格は決して高くはありませんがクオリティには定評がある模様。ここが候補になったのはこんなところで紹介されていたりと、評判がかなりよさげなので。 Terms of Serviceをみても、「無料試用サービスやキャッシュバック保証はなし。 なぜならこのようなサービスや保証は悪用されるケースが多く、我々はWebで謳っている内容を確実に提供する自信があるから。」等とあり、老舗ならではのクリーンさとクオリティの高さを感じとれます。 低スペックの激安サービスのラインナップはなく、最安のサービスでも49$/month、メモリ256Mbyte、HDD10Gbyte、IP4つという感じ。

一方ProVPSとZONE.NETは比較的新しい業者です。特にZONE.NETの方は市場と比較してサービス内容はしっかりしている上に低価格のラインナップが用意されています。 ServIntだと最低49$/month〜ですが、ProVPSは19.5$/month〜、ZONE.NETは25$/month〜という設定。
同じくらいのサービスレベル(メモリ256MB)でProVPSとZONE.NETを比較すると、ServIntは49$/month、ProVPSは39$/monthでZONE.NETは25$/monthという感じ。細かいところでは一長一短あるのですが、ZONE.NETはこの最安のサービスでもIP2つくれちゃったりとなかなかツボをついています。

結局のところProVPSとZONE.NETをとりあえず両方一ヶ月間使ってみて良い方で継続することにし、両方契約しました。 仮想化の技術もProVPSの方がXen, ZONE.NETがVirtuozzoということで長い契約になるので一度両方みてみた方がいいだろう、ということで。

とりあえず両方で同じようにLAMP構成を構築してみましたが、どちらも使い勝手はかなり良いです。しかしProVPSの方で、多分メモリが192MBなのが原因だと思うのですがSennaのコンパイルができませんでした。(コンパイラがnfkcのところでKillされたので多分メモリ関連でしょう。)なのでSennaについては手元のマシンでビルドしてバイナリをもっていきました。 ZONE.NETの方は特に問題なく全て同一サーバ上でビルドできました。

現在は手始めとして最もコンテンツがポータブルなこのサイト:nkjmkzk.netをZONE.NETに移行しました。 若干レスポンスが悪くなりましたが問題ないようです。 やはり自宅サーバと比べるとSSHの反応もやや鈍くなりますがまぁ仕方のないところかなと思います。

以下、現在のProVPSとZONE.NETの比較情報をまとめておきます。特にZONE.NETの方はあまり事例やレビューが国内にはないので。

ProVPS:
・サーバはDual Core Xeon。”cat /proc/cpuinfo”すると2.8GHz。2次キャッシュは2Mbyte。
・仮想化はXen。
・契約関係、特に解約がちょっと厄介(Service Cancellation Request Formなるものを送ったりしなきゃいけないらしい)。
・管理画面はオリジナル。
・パーティションの設定ができたり複数のOSをインストールできたりとかなり柔軟。

ZONE.NET
・サーバはQuad Core Xeon。”cat /proc/cpuinfo”すると2.3GHz。2次キャッシュは4Mbyte
*体感的にはProVPSより速い
・仮想化はVirtuozzo。
・管理画面はVirtuozzo Power Pannel。日本語にローカライズされている。
・ファイアーウォールが管理画面で設定可能。便利。

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 6:58 pm

Posted in Uncategorized

Tagged with

ZFSっていいんじゃないの

以前からちらほらと名前は聞いていたZFSですが、少し調べてみたところ相当良いのではと思いました。 ZFSはオープンソースとしてSun Microsystemsが開発しているファイルシステムで、もともとは将来のSolaris用に開発していたのを現在ではSolarisとは切り離して単独のオープンソースプロジェクトとして開発が進められている、というものです。

MacOS Xの次期バージョンでもオプショナルで採用予定とのことなのでこれを期に一気に認知度があがるんじゃないかなと思います。

さてこのZFS、何がいいのかというとまとめるとこんな感じ。

バックアップ、リストア関連
・フィアルシステムのスナップショット
・お気軽ロールバック

耐障害性関連
・同一Disk上でのデータ冗長化

柔軟性
・論理ドライブ、パーティションとかはもうナシ ひとつのストレージプールで表現

この中で特に僕がフムフムと思ったので柔軟性。
最近VA Linuxの高橋さんから「パーティションとかホントいらないよね」という話を聞いてなるほどーーっと思っていたところなのでこれは「おぉ、」と思いました。

要はパーティションでディスクを区切っちゃうと、シリンダの最後のパーティションなら容量を拡張することはなんとか可能ですが、真ん中くらいにあるパーティションの容量が足りなくなったりすると単純にそのパーティションを伸長することはできません。

これを「パーティションなんてもうナシよ。 ディスクはストレージプールで一括して抽象的に表現します」っていうのがZFS。 こうすることで、「オイオイ、予想外に/home足りねぇーぞ。 /home/nkjm使いすぎじゃね? /var死ぬ程余ってんのに。」ということがなくなります。

以下、www.opensolaris.orgより。

ZFS presents a pooled storage model that completely eliminates the concept of volumes and the associated problems of partitions, provisioning, wasted bandwidth and stranded storage. Thousands of filesystems can draw from a common storage pool, each one consuming only as much space as it actually needs. The combined I/O bandwidth of all devices in the pool is available to all filesystems at all times.

あとスナップショットによる高速インクリメンタルバックアップやロールバックとかも相当イイ! 来週は仕事してるフリしてZFSの検証でもしよっかなーー。 でも残念なことに今のとこLinuxにはportされてない模様。 検証するならopensolarisかFreeBSD上なのかな。 一応Linux向けには現在ZFS for FUSE/Linuxってのがあるみたい。

参考:

without comments

Written by 中嶋 一樹

12月 6th, 2008 at 6:56 pm

Posted in Uncategorized

Tagged with , ,