Virtual Host

Debian で Xen 4.1 を

パッケージで入れられてしめしめとか思ってたら、何か依存関係でも壊したのか、起動しないゲストがあったでござる。ということで、バニラな方法で入れ直す。元ネタは昨日と同じでこちら → Xen 4.1 from source with Debian Squeeze 2.6.32-5-xen-amd64 dom0 (test) Xen.org からソースを取ってきます。現時点での最新版は、4.1.2。 wget http://bits.xensource.com/oss-xen/release/4.1.2/xen-4.1.2.tar.gz ビルドに必要なパッケージをインストールします。/etc/apt/source.list に以下の行を追加して、 deb-src http://ftp.jp.debian.org/debian/ sid main</code> 以下を実行。 apt-get build-dep xen apt-get build-dep xen-utils-common build-dep で入らないパッケージを追加で入れます。 apt-get install libx11-dev libssl-dev python2.6-dev で、おもむろにビルド make xen make tools make stubdom エラーがなければインストール。 make install-xen make install-tools PYTHON_PREFIX_ARG= make install-stubdom Domain 0 に必要なサービスデーモンの起動設定を忘れずに。 update-rc.d xencommons defaults update-rc.d xendomains defaults 4.0 までと互換性のある、xm ツールセットを使う場合は、xend も起動するようにしておきます。 update-rc.d xend defaults ひとまず以上で、Xen が起動するはずです。再起動して確認しましょう。 xl list 次のように、Domain-0 がリストされない場合、たいていは GRUB の設定ミスです。 Name ID Mem VCPUs State Time(s)
Read more

Debian Squeeze に Xen 4.1 を入れる

XenServer 6.0 の基盤になってたり、他のディストリがこぞって採用してるのが、Xen 4.1 なのですが、時期の関係で、Squeeze には、4.0 が収録されています。何か中途半端。sid にはパッケージがありますので、そっからソースを取ってきて(さすがにバイナリは持ってきても動かないので)、ビルドする方法を見つけましたので、備忘録がてら。 元ネタはこちら → Xen 4.1 from source with Debian Squeeze 2.6.32-5-xen-amd64 dom0 (test) まずは、source.list に1行追加。 deb-src http://ftp.jp.debian.org/debian/ sid main squeeze や wheezy の行があれば、コメントアウトしておきます。 で、おもむろに、ビルド…する前に、パッケージをひとつ追加しておきます。ないとコンパイルがエラーになるので。 apt-get install ipxe-qemu PXEブートに使うファームのQEMU用ROMイメージなんですが、なぜか Xen をインストールしても、build-dep しても入りません。 まずはビルド環境を整えます。 apt-get update apt-get build-dep xen apt-get build-dep xen-utils-common Xen のソースと Debian パッチの取り寄せ、ビルドも apt-get で済むのが便利なところ。 cd /usr/src/ apt-get source xen -b apt-get source xen-utils-common -b エラーがなければパッケージができているので、dpkg でインストールすればおしまい。 dpkg -i *xen*deb

VPS ショートレビュー (1/2)

鯖の乗り換えでいくつか VPS を借りてみたので、その雑感などを。 Linode 評価: ☆☆☆☆☆ 2ch の VPS スレ や WebHostingTalk では鉄板とされています。契約からサーバーの設定、オプションの購入、OSのインストール、設定まですべてWeb管理画面から行うことができ、非常に簡単にサーバーを立てることができます。サーバー自体も非常に安定しています。落ちたとか、繋がらないなどということは噂すらありません。単にウェブサーバーやメールサーバーを立てるだけなら、さくらで専用サーバーを借りるよりここを借りた方が遙かに良いのではないでしょうか。 ここの特長は安定性と応答性の良さ以外にも、1. ディスクのパーティションをユーザが自由に配置できる。2. メモリも購入した範囲内であれば、増減可能。3. VPS のディスクイメージを他の VPS へ簡単にコピーすることが可能。と、他のプロバイダにはない点が挙げられます。 データセンターは、フレモント (アメリカ、カリフォルニア州) の他にアメリカ国内に三カ所、ロンドンに一カ所と合計五カ所あり、申し込んだ後に選択できます。今どこのデータセンターのどんなプランが空いてるのかは、Datacenter Availability ページで予めわかります。フレモントは大人気 (多分、アジアからの申し込みが集まるからだと思います) で、空きが出てもすぐ埋まってしまうのが悩ましいところですが。 私はここにウェブサイト (このブログも含みます) とメールサーバーを置いています。日本にサーバーを置いていた時と比べても特に気になる遅延はありません。SSH でのログインも快適です。 ロケーション レモント (アメリカ、カリフォルニア州)、ダラス (アメリカ、テキサス州)、アトランタ (アメリカ、ジョージア州)、ニューアーク (アメリカ、ニュージャージー州)、ロンドン (イギリス)。 仮想環境 Xen (HVM) コントロール パネル Linode 独自 Web コントロールパネル 対応OS Arch Linux 2009 02 (32/64), CentOS 5.3 (32/64), Debian 4.
Read more

SSLでネームベースのバーチャルホスト

某所にある Apache WebサーバのSSLモジュールを OpenSSL から、GnuTLSへ変更しました。何のためにそんなことをしたかというと、タイトル通り、SSLでNamed Virtual Hostを有効にするためです。 そんなことできんの? SSLってIP1個につき、1ホストじゃないとできないんじゃないの? と思ったあなた、そんなことはありません。知ってるよ。ワイルドカード証明書でしょ? でもあれ高いんだよね−。と思ったあなた。違います。ワイルドカード証明書のことではありません。IPアドレス1個で、全く関係のないドメインがバーチャルホストできるんです。え? 知ってる? おまえが遅れてるだけ? すいません。最近、サーバ関係は手を抜いてるもんで。^^; そもそも私がこれを知るきっかけになったのは、Postfix メーリングリストにドメイン名の変更に当たり、二つのドメインを同時にSSLで受け付けられないかという質問が投げられたことにありました。で、その回答中に、複数のドメインをひとつの証明書にいれてもらう = subjectAltName を使用するというのがあったんです。 subjectAltName? そんな属性がSSLにあるんかいな、とググったところ、SSL・サーバ証明書の発行と認証 CSPSSLというページを発見。おおーっ。確かにある。で、さらにググったところ、まっちゃ139というサイトで勉強会に使用したというプレゼンページを発見。凄いわかりやすくて勉強になりました。ありがとうございます。まっちゃ139さん 詳しくはそちらをご覧頂くとして、SSLでもNamed Virtual Host が可能。ちゃんとRFCにもなってて、ワイルドカード証明書よりスジがいいってこともわかりました。そういえば、GoDaddy でも、Multiple Domains SSL売ってたなぁ、あれもこれ使ってるんだとか思ったり。:P ですが、subjectAltName では、それ用のSSL証明書が当然のことながら必要です。これが悩ましい。というのも、実は私、SSL証明書を四通持ってるんです。うち、二通はしまいっぱなし。いや、以前は使ってたんですが、IPアドレスをいくつも持ってるのが経済的に厳しくなって、サーバを解約しちゃったものですから、余ってたんですね。もったいない。そこへIP増やさなくてもSSLで使えるかもってんですから飛びついたんです。でもまあsubjectAltNameはそういうものでした。しかし! 天は我を見放さなかったのです! (大袈裟) SNI (Server Name Indication) であれば、証明書を無駄にせずにすむ! IE6は対応してないみたいだけど、今時そんなブラウザ使ってるやつぁ無視! マイナーどころのブラウザについては、RFC追っかけてちゃんと作ってれば動く! 動かないのは使ってるやつの運が悪いだけ! (笑) というわけで、この方法でいってみようと決心したわけです。  ところがどうも、Apache 標準の mod_ssl は、パッチを当てないといかんらしい。ディストリビューションに取り込まれてないパッチはちょっと当てたくないなぁと思い、その必要がない、GnuTLS + mod_gnutls でいくことに決めたわけです。mod_gnutls は、セキュリティホールが去年報告されたようなのですが、最新版ではちゃんと対応されてるので、問題なしと判定。ビルドしてインストールしました。サンプルについてた設定ファイルのキーワードが間違ってて、小一時間悩みましたけど、無事起動。そして、手持ちのSSL証明書を全部インストールして、Apache を再起動。おそるおそるそれぞれにアクセスしてみると… やったよ! うまくいったよ! (当たり前) Safai対応してるって書いてるサイト、あんまりなかったけど、普通に見えるよ! ということで、どうやったかを書くと tips として役に立つと思うんですが、なんせセキュリティがらみなもんで、具体例はちょっと…インストールの手順はまた後日ってことで。