ラベル さくらのVPS の投稿を表示しています。 すべての投稿を表示
ラベル さくらのVPS の投稿を表示しています。 すべての投稿を表示

2012年6月8日金曜日

2012年5月版 「さくらのVPS」 Ubuntu Server ガイド

Code Jam やその他モロモロでおくれにおくれ、「さくらのVPS」の移行優遇策も時期的にスルーしてしまったのですが、「さくらのVPS」を、最新の Ubuntu Server 特に 12.04 LTS で使いたいという需要があるのではということで、2012年5月版と言うことで、過去に書いた記事を現在の状況に合わせて再度書いてみたいと思います。

サーバー要件の調査


何事にも計画を立てるということは大切なのですが、サーバーを構築するのでも計画を立てて、要件を詰めておく必要があります。10.04 の時の記事の再掲になりますが、
  • ホスト名
  • DNSドメイン名
  • DNS FQDN名
  • IPアドレス
  • ネットマスク
  • ルーティング情報(デフォルトゲートウェイも含む)
  • DNSサーバ指定(複数指定されていればその全て)
  • DNSサーチドメイン名
  • NTPサーバ
の各項目を調べておいてください。「VNCコンソール」については当時ベータ版扱いでしたが、今では正式なサービスとなっているので、こちらを使うとよりイメージしやすいかもしれません。

カスタムOSインストールが便利


この記事を書く段階では「カスタムOSインストール」には Ubuntu 12.04 LTS がまだ用意されていなかったのですが、さすが LTS というだけあって、6/7 には利用できるようになりました。



試しに「カスタムOSインストール」でインストールしてみましたが、パッケージの選択が「さくらのVPS」の標準OSの CentOS に準拠して、最初から OpenSSH が立ち上がっている状態となりました。深いことは考えずにこれを利用してみるのもいいかもしれません。

ただし、普通のPCと違っていきなりインターネットに接続している(VPSですからあたりまえですよね)ので、即刻 ufw や OpenSSH の設定を見なおしておくと良いと思います。

この辺のノウハウは Ubuntu Magazine Vol.07 で徹底紹介していますので、参考にしてみると良いでしょう。

Ubuntu Magazine はもうすぐ最新号の Vol.08 が出る予定ですから、もうしばらくするとバックナンバーのPDFファイルが編集部で公開される予定なのでそちらをチェックしてみても良いかと思います(言うまでもないことですが、グラビアなどの公開されない記事もあるので実物を購入するのも選択としてアリです)。

ガチで最小構成でインストールする場合には


現在は「さくらのVPS」の「カスタムOSインストール」で 12.04 LTS がインストールできるようになりましたが、『ガチで最小構成でインストール』するためには、ネットワークインストーラーを入手し、Grub から起動する形でインストールを進めます(ただしネットワーク資源的にはミラーサーバーから必要なものを適宜ダウンロードするので「カスタムOSインストール」のほうが無難かもしれません)。

 

Ubuntu 12.04 LTS amd64 のネットワークインストーラーの入手


具体的にネットワークインストーラーを入手するわけですが、 12.04 LTS のコードネームは Precise Pangolin ですので、標準OSのCentOS上で、

# mkdir /boot/ubuntu
# cd /boot/ubuntu
# wget http://jp.archive.ubuntu.com/ubuntu/dists/precise/main/
       installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux
...
# wget http://jp.archive.ubuntu.com/ubuntu/dists/precise/main/
       installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz
(URLが長いので折り返しましたが、この部分は1行で続けて書いてください)

としてダウンロードします。 標準でインストールされる CentOS 6.2 構成でカーネルや initrd などを起動時に読み出す /boot パーティションを間借りするのがコツです。

設置したネットワークインストーラーの起動


この辺は以前の記事と同様の操作で、リブートして、Grub のコマンドラインから設置したインストーラーを起動することになります。

# reboot

として再起動し、Press any key to continue と出てくるので何かキーを押し、その後 Booting CentOS と出たところでも再度何かキーを押して、Grub のメニュー画面を表示させます。さらに Grub のメニュー画面では 'c' を押してコマンドラインモードに移ります。





Grub のコマンドラインでは

grub> root (hd0,0)
grub> kernel /ubuntu/linux
grub> initrd /ubuntu/initrd.gz
grub> boot

としてネットワークインストーラーを手動起動します。


以前の記事のくり返しになりますが、キーボードは us モードになっているので、一般的な日本語キーボードでは開き丸カッコは Shift + 9 、閉じ丸カッコは入力できないので root (hd0,0 とここまで入力したところで TAB キーを押して閉じ丸カッコを補完させます。また、kernel の部分についてはVNC コンソールを使う前提であれば、特にオプションを指定する必要はありません。kernel や initrd のところでもファイル名については TAB キーによる補完が効くので、適当なところまで入力した後に TAB キーを押してとっとと補完させておくのがスマートです。

うまくいくとインストーラーが起動します。

Ubuntu のインストール


あとは画面に従ってインストールを進めていくことになります。この辺はもういつもと同じ感じということで、Ubuntu Magazine Vol.07 を参考にしましょう。

コンソール環境の整備


ネットワークインストーラーからインストールした際にもコンソール環境の設定をしておくと、VNCだけではなく「リモートコンソール」からメンテナンスができて便利かもしれません。/etc/init/ttyS0.conf や、/etc/default/grub を必要に応じて編集し反映させておくといいでしょう。なお、以前記事で書いたような、/usr/sbin/grub-mkconfig や /etc/grub.d/00_header への修正は必要なくなったので、ご安心を。

/etc/init/ttyS0.conf

# ttyS0 - getty
#
# This service maintains a getty on tty1 from the point the system is
# started until it is shut down again.
 
start on stopped rc RUNLEVEL=[2345] and (
            not-container or
            container CONTAINER=lxc or
            container CONTAINER=lxc-libvirt)
 
stop on runlevel [!2345]
 
respawn
exec /sbin/getty -8 115200 ttyS0

/etc/default/grub

# If you change this file, run 'update-grub' afterwards to update               
# /boot/grub/grub.cfg.                                                          
# For full documentation of the options in this file, see:                      
#   info -f grub -n 'Simple configuration'                                      
                                                                                
GRUB_DEFAULT=0                                                                  
# GRUB_HIDDEN_TIMEOUT=0                                                         
GRUB_HIDDEN_TIMEOUT_QUIET=false                                                 
GRUB_TIMEOUT=5                                                                  
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`                
GRUB_CMDLINE_LINUX_DEFAULT="quiet"                                              
GRUB_CMDLINE_LINUX="nosplash console=tty1 console=ttyS0,115200n8r"              
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"                                                                              
                                                                                
# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"
 
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
GRUB_TERMINAL="serial console"
 
# The resolution used on graphical terminal
(以下省略)

なお ntp や OpenSSH、 ファイヤーウォールなどの設定についてはUbuntu Magazine Vol.07や以前の記事を参考にすると良いでしょう。

2012年4月23日月曜日

東京に引っ越しました

さくらのVPSの移行ねたを書くと予告しておきながらまったく手がついていなくてゴメンナサイ。

手がつかない理由が実はあって、この4月に転職と引っ越しをして東京に住むことになり、その関連の様々な事々をこなすことに追われておりました。

この界隈では「転職したらブログを書く」という風習があるようですが、私の場合はそんな大それた仕事をしてきたような自覚は全くないので、あまり多くは語らないことにします。とはいえ、前職ではスタッフの皆さんやお客さんには非常にお世話になったことは事実で、この場を借りて御礼申し上げます。また、新しい職場の皆さんや Ubuntu , Android をはじめとしたコミュニティの皆さまにはこれからどうぞよろしくお願いします。

なぜ東京にという疑問をお持ちの方もおらっしゃるのではないかとは思いますが、より洗練されたもの、クールなもの、面白いものを追い求めるためには、やはり人が多く集まるところで仕事を含めた活動を行うのが自然な流れです。この辺の話題は 2010 年の OSC 仙台での LT で喋った内容が今でも自分の中に生きていて、色々なチャレンジをするためには東京に移住する必要があるという考えを持っていることが大きいのではないかと思っています。


このブログや Ubuntu での活動は徐々に元に戻していきたいと思いますので、これからもどうぞよろしくお願いします。

2012年4月9日月曜日

「さくらのVPS」サービスプラン全面改定

皆様お久しぶりです。長南です。Ubuntu Magazine そして Ubuntu Weekly Recipe の記事公開から地味に色々忙しくなってきておりますが、なんとか生きております。

さて、各種ニュースなどを通じてもうすでにご存じの方も多いと思いますが、「さくらのVPS」のサービスプランが全面的に改定され、お得度がさらに増しました。

このblogでも 「さくらのVPS 512」を使った Ubuntu Server 構築を話題にあげてきましたが、本気で契約を見直したいくらいの内容となっています。


 プラン名  初期費用 月額費用 メモリ  HDD CPU 
(旧)さくらのVPS 512 0円 980円 512MB 20GB 仮想2コア
(旧)さくらのVPS 1G 2,980円 1,480円 1GB 30GB 仮想2コア
(旧)さくらのVPS 1.5G 4,980円 1,980円 1.5GB 50GB 仮想2コア
(旧)さくらのVPS 4G 9,980円 3,980円 4GB 120GB 仮想4コア
(旧)さくらのVPS 8G 19,800円 7,980円 8GB 240GB 仮想4コア
(新)さくらのVPS 1G 0円 980円 1GB 100GB 仮想2コア
(新)さくらのVPS 2G 1,980円 1,480円 2GB 200GB 仮想3コア
(新)さくらのVPS 4G 5,980円 3,980円 4GB 400GB 仮想4コア
(新)さくらのVPS 8G 9,980円 7,980円 8GB 800GB 仮想6コア


さらに、現在VPSを使用しているユーザについても乗換え優遇策として
  • 新プランの利用料金を最大1か月無料
  • 年払いユーザの場合、旧プランの6月からの利用料金相当額を返金
という優遇策も実施されるということです。ただし、年払いの場合は4/20までに新プランでの申込・入金、既存プランの解約手続きが済んでいるが条件です。また解約した既存プランは5/31でサービス廃止となるので、乗換えをするなら比較的早急に引越し作業を行わないといけないことになります。

私も 「さくらのVPS 512」を年払いで使っていて、今回のサービス改定でどうしようかちょっと悩んでいたのですが、今回の優遇策に乗って新しい 2G プランに移行することにいたしました。

あまりクリティカルなサービスを提供しているわけではないのですが、サーバー引越しについても興味を持っている人は多いのではないかと思いますので、忙しいのですがまた半連載状態でヌルく書いていきたいと思います。

( Ubuntu Weekly Recipeで何か原稿やネタを出せという圧力を感じますが、ネタの神が降りてくるまでしばしお待ちください。さすがに「さくらのVPS」ネタを書いたとしたら、掲載途中で乗換え優遇策の期限が来てしまいますので... )

2011年10月17日月曜日

Ubuntu 11.10 "Oneiric Ocelot" リリース

今、最も人気があると言っていい Linux のディストリビューション Ubuntu の最新版 "Oneiric Ocelot" が先週 10/13 にリリースされました (いきなり脱線しますが、"Oneiric Ocelot" は「夢見がちなオセロット」と翻訳されることが多いですが個人的に「夢見るオセロット」を推していきたい気がします) 。また、一歩進んだ日本語環境を提供する「日本語 Remix CD」も 10/16 にリリースされました。

Ubuntu 11.10 リリース ( Ubuntu Japanese Team )

Ubuntu 11.10 日本語リリースノート ( ubuntu wiki )

Ubuntu 11.10 Desktop 日本語 Remix CD リリース ( Ubuntu Japanese Team )

リリースの大まかな雰囲気としては、リリース日に公開された Ubuntu 道場が、より突っ込んだ内容についてはリリースノートが大いに参考になると思います。特に Ubuntu Japanese Team の皆さんが言っている通り、リリースノートは必読です。リリースノート翻訳はかなり修羅場だったそうなのでそういった面も含めて是非読んでください。

行っとけ! Ubuntu道場! - 第49回 ~師範、Ubuntu 11.10について教えてください!~ ( ascii.jp )

私もこの週末に以前この blog でもとりあげた「さくらのVPS512」や自宅のマシン等にインストールやアップグレードを行ってみました。道場の記事やリリースノートを読む限りにおいては、ブラッシュアップが主な内容だということですが、/var/run が /run へ、 /var/lock が /run/lock へ移行したことによる影響がアップグレードインストールを行った際に出る場合があるようです。リリースノートには Ubuntu AppArmor と VMWare に焦点があてられていますが、これ以外にもこれらのディレクトリの移行に失敗し影響が出るケースがあるようです。実際に遭遇する現象としては、アップグレード後の起動時に
Waiting for network configuration...
Waiting up to 60 more seconds for network configuration...
という表示がなされたままログインプロンプトやログイン画面が表示されないという状況になります。これらについてはそれぞれ


incomplete migration to /run (shutdown script order has been demolished)

Boot hangs at "Booting system without full network configuration..."

Unable to connect to the system bus: Failed to connect to socket /var/run/dbus/system_bus_socket: Connection refused (oneiric)

[oneiric] Keyboard & mouse not working in X - incomplete migration to /run

で議論されているところですが、対処方法としては、[ctrl]+[alt]+[F1~F6] でコンソールを切り替えたり rescue mode などでログインし、 /var/run と /var/lock を手動で移行するという方法があるようです。Ubuntu 11.04 までの標準構成ではこれらについては tmpfs で mount されていますので、
# mv /var/run /var/run.bak
# ln -s /run /var/run
# mv /var/lock /var/lock.bak
# ln -s /run/lock /var/lock
として、/var/run や /var/lock については /run および /run/lock へのシンボリックリンクを作成する必要があるようです (もちろん問題がないことが確認できたら、 /var/run.bak や /var/lock.bak は必要ありませんので削除できます) 。 /run や /run/lock への移行が完全であればこのシンボリックリンクは必要ないように思われますが、この辺はまだまだ完全に整備されているわけではなく、シンボリックリンクがないとやはり起動しませんので注意が必要です。

また、このような移行を行ってもなお問題が解決されないケースがあり、/etc/network/interface の記述をそれぞれコメントアウトしつつトラブルシュートしたりする必要があるようです。

今回の /run および /run/lock への移行は Linux FHS ( Filesystem Hierarchy Standard ) 3.0 Draft 1 への準拠による問題なので、これは Ubuntu に限らず遅かれ早かれ多くの Linux ディストリビューションで問題になりそうな感があります。

ということで、今回の Ubuntu 11.10 へアップグレードする際には道場の記事の中でも出てきましたが
編集S:まとめると、「自信があるならバックアップ取ってからアップグレードするといいよ」「自信がなければ1ヵ月ぐらい様子を見て、問題が出尽くしたあたりでチャレンジ」かな?
ということに尽きそうな気がします。新規インストールではなくアップグレードする際には今回はいつにも増して「バックアップ推奨」したいところです。サーバ用途に使っているのであれば検証用の環境を用意してそこで練習するくらいが丁度良いと思います。

2011年9月5日月曜日

Apache の脆弱性、対策しましたか?


先月末に Web サーバ として広く使われている Apache の既存のすべてのバージョンにおいて、深刻な脆弱性をかかえていることが明らかになりました。攻撃を行うための手法はすでに広く流通しており、手元の環境でも検証することができるくらいになっています。

最悪なシチュエーションの妄想


この脆弱性を突かれると Web サーバを沈黙させることができるという状況で Web サイト運営側とすると大きな脅威となっています。最悪のシナリオを考えてみると
  1. 政治問題などで某隣国を刺激してしまう
  2. 日本国内のWebサイトを攻撃する呼びかけが広まる
  3. 自動攻撃ツールに今回の脆弱性への攻撃手法が盛り込まれる
  4. 実際に攻撃が行われ国内の多くのサイトが沈黙してしまう
ということが起こりえる状況です。少なくとも対策が一巡するまでは隣国を刺激して欲しくない(笑)のですが、この blog では「さくらのVPS」でのサーバ構築ノウハウをとりあげたことがありますので、こういった状況が発生したときに、どういった対応をとればいいのかということを書いておきたいと思います。( Web サーバについてはマニアックに lighttpd を紹介しましたが、それは聞かないお約束です)

信頼できる情報を入手し行動しよう


まず何よりも大切なのは信頼できる情報を入手するということです。「blogでヤバいって書いてあるから」 とか 「Twitter で勧められたから」という理由で行動を起こすのは非常に愚かな行為であるといえます。今回の件での情報源としてあげることができるのは JPCERT/CC の


かと思います。JPCERT/CCの注意喚起についてはアナウンス用のメーリングリストでも公表されるので、これを機会に購読しておくのも良いかと思います。実際の対策については
The Apache Software Foundation から本脆弱性を修正した Apache HTTP
Server 2.2.20 が公開されています。また、一部のディストリビュータなどか
らも修正済みプログラムが提供されています。十分なテストを実施の上、修正
済みプログラムを適用することをお勧めします。
と書かれている通り、更新された新しいバージョンのものにアップデートすれば良いということが言えると思います。

Ubuntu の場合ですと、この件について
というセキュリティ告知 ( Ubuntu Security Notice ) が出されており、それを見てみると現在サポートされているバージョンにおいて対策を講じた apache2 パッケージが公開されており、それにアップデートすれば良いようです。対策済のバージョンはそれぞれ
Ubuntu 11.04
  apache2.2-bin 2.2.17-1ubuntu1.2
Ubuntu 10.10
  apache2.2-bin 2.2.16-1ubuntu3.3
Ubuntu 10.04 LTS
  apache2.2-bin 2.2.14-5ubuntu8.6
Ubuntu 8.04 LTS
  apache2-mpm-worker 2.2.8-1ubuntu0.21
  apache2-mpm-event 2.2.8-1ubuntu0.21
  apache2-mpm-prefork 2.2.8-1ubuntu0.21
  apache2-mpm-perchild 2.2.8-1ubuntu0.21
となっており、「一般的には通常の方法でアップデートすれば必要なものがすべてアップデートされる」とも書かれています。アップデートの方法は過去にこの記事で触れたので、参考にしてもらえればと思います。

なんとか対策が終わったとして、対策が済んだのかどうかを確かめる必要があるのですが、実は Ubuntu の場合ここで小さな罠があります。例えば apache2.2-bin パッケージのバージョンを調べるのに、dpkg -l を使ってこんな風に調べると
$ dpkg -l apache2.2-bin
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  apache2.2-bin  2.2.16-1ubuntu Apache HTTP Server common binary files
$ 
と、このようにバージョン文字列の表示が途中で切れてしまってセーフなのかアウトなのか分からないもどかしい表示となってしまいます。マニュアルを読んで調べれば分かることなのですが、一例しては、dpkg-query -W を使って
$ dpkg-query -W apache2.2-bin
apache2.2-bin   2.2.17-1ubuntu1.2
$ 
とすることで、対策済かどうかが判別できるかと思います。

「部品」として使われている Apache に注意


ということで、Ubuntu を使っている場合には「一般的な環境では通常通りアップデートせよ」と結果としては非常に簡単な結論になるわけですが、その根拠をこういった感じで調べるということが非常に重要なのではないかと思います。

あとは同じようなモノについても対策を講じる必要があるわけですが、Apache そのものは非常に広い範囲で使われているため「部品」として使われることも多く、Tomcat や Rails などの Web アプリフレームワークと連携をさせている場合などに盲点になりやすいので注意が必要です。

こういった脅威に対してどれだけ迅速に対応できるのかといった点が OS のサポートの質を問うバロメータの一つと言っていいかと思いますので、その辺りにも留意しておくとよいでしょう。

また、Apache を自前でコンパイルしていたり、独自のモジュールなどを組みこんでいたりするとそういったモノについてもケアする必要があるので、そこは各自頑張っていただくよりほかないことも付け加えておきたいと思います。

2011年3月1日火曜日

「さくらの6rd(トライアル)」が提供開始されたので設定してみた(Ubuntu 10.10)

サービス提供開始以来、様々なところで話題になっている「さくらのVPS」ですが、この 3/1 から「さくらの6rd(トライアル)」と銘打ち、6rd による IPv6 接続サービス実験を開始しました( プレスリリース )。このサービスを利用できるのは、

弊社専用サーバサービス、ハウジングサービス、さくらのVPS等、サーバの管理権限(root権)を使用可能なIPv4サービスをご利用のお客様は、サーバの設定を行うだけで簡単に利用することができます(申し込み不要です)。

とある通り(さくらインターネット研究所 「さくらの6rd(トライアル)」より)、「さくらのVPS」だけではなく、専用サーバやハウジングサービスなどでも利用できるサービスで、申込なしで利用可能で、当面は 3/31 までの試験サービス(必要に応じて短縮や延長される)となっています。

IPv4 アドレスについては先日 IANA が持つ中央在庫が枯渇したというニュースもあり、ちょっとタイムリーなねたでもあるので、私が借りているさくらのVPSでもこの 6rd による IPv6 接続を試してみたいと思います。なお、今回のサービスの仕組や概要については、「6rdによるIPv6接続(概要編)」 ( さくらインターネット研究所 ) を参照してください。

とはいっても、今借りているVPS上で動かしている Ubuntu 10.10 Server での設定についてはすでに「6rd設定方法(Ubuntu10.10編)」( さくらインターネット研究所 ) にまとめられていますので、この手順をなぞる格好になります。

早速設定してみよう


「6rd設定方法(Ubuntu10.10編)」( さくらインターネット研究所 )で書かれていることの重複になってしまいますが、設定手順について簡単に説明してみると、VPS に割り振られた IPv4 アドレスが pp.qq.rr.ss だった場合、これから使う IPv6 アドレスを
$ printf "2001:e41:%02x%02x:%02x%02x::1\n" pp qq rr ss
2001:e41:PPQQ:RRSS::1
というふうに計算し、その IPv6 アドレスについて /etc/network/interfaces に
auto tun6rd
iface tun6rd inet6 v4tunnel
        address 2001:e41:PPQQ:RRSS::1
        netmask 32
        local pp.qq.rr.ss
        endpoint any
        gateway ::61.211.224.125
        ttl 64
        up ip tunnel 6rd dev tun6rd 6rd-prefix 2001:e41::/32
        up ip link set mtu 1280 dev tun6rd
という内容を追加します ( pp.qq.rr.ss および PPQQ:RRSS の部分は割り当てられた IPv4 アドレスにより変化しますので、適宜読み替えて下さい )。その後再起動して、
# ifconfig tun6rd
...
# ip tunnel show
...
# ip -6 route show | grep default
...
の各コマンドで、設定した内容が正しいと確認できれば IPv6 アドレスが使えるようになったことになります。

ICMPパケットを投げてみたけれども...


しかし、ここで例えば
# ping6 www.kame.net
とやってみると、この blog を参考にしてVPSサーバを構築した人は多分
PING www.kame.net( ...... ) 56 data bytes
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
と表示され、通信できていない状況にがっかりするのではないかと思います。

ファイヤーウォール設定の再調整


実はこの現象は Ubuntu のファイヤーウォール管理プログラム ufw の標準での振る舞いに起因するもので、 ufw のマニュアルに
IPv6 is blocked by default and only IPv6 traffic on the loopback interface is allowed. To change this behavior, set IPV6 to 'yes' in /etc/defaults/ufw and reload ufw.
と書いてあるとおりで、 IPv6 でのトラフィックについてはループバックインターフェイス上のものだけを許可する仕様となっているためです。ip6tables コマンドで確認してみても
# ip6tables -L
Chain INPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all      anywhere             anywhere

Chain FORWARD (policy DROP)
target     prot opt source               destination

Chain OUTPUT (policy DROP)
target     prot opt source               destination
ACCEPT     all      anywhere             anywhere
と、ufw による制御が行われていないことが確認できます。マニュアルの記述にもありますが、これについては /etc/default/ufw ファイルの冒頭部分を
  1 # /etc/default/ufw
  2 #
  3
  4 # Set to yes to apply rules to support IPv6 (no means only IPv6 on loopback
  5 # accepted). You will need to 'disable' and then 'enable' the firewall for
  6 # the changes to take affect.
  7 #IPV6=no
  8 IPV6=yes
  9
 10 # Set the default input policy to ACCEPT, ACCEPT_NO_TRACK, DROP, or REJECT.
いうふうに、「IPV6=yes」と変更して保存した後に
# ufw reload
Firewall reloaded
として、変更を反映することによって ufw による制御を IPv6 トラフィックにも適用させることができます。ここまで作業した上であらためて、www.kame.net に対して ping6 をかけてみると
# ping6 www.kame.net
PING www.kame.net( ...... ) 56 data bytes
64 bytes from ...... icmp_seq=1 ttl=56 time=2.39 ms
64 bytes from ...... icmp_seq=2 ttl=56 time=2.06 ms
...
といった風に、www.kame.net の IPv6 アドレスに対して通信できることが確認できると思います。

なお、ufw の設定については、IPv4 向けの設定のみが有効となっていますので、必要に応じて IPv6 向けの設定を追加する必要があります。とはいえ、以前紹介したような事例
# ufw status numbered
Status: active
 
     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     LIMIT IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
のような場合で、IPv6 での http 入力についても IPv4 同様に許可する場合には、単に ufw allow in http/tcp とすることによって
# ufw allow in http/tcp
Skipping adding existing rule
Rule added (v6)
# ufw status numbered
 
     To                         Action      From
     --                         ------      ----
[ 1] 22/tcp                     LIMIT IN    Anywhere
[ 2] 80/tcp                     ALLOW IN    Anywhere
[ 3] 80/tcp                     ALLOW IN    Anywhere (v6)
と、すでに存在する IPv4 のルールを飛ばして IPv6 の許可ルールを追加することができます。IPv4 と IPv6 で許可/拒否の区別を行う際には、IPv4/IPv6 両方について許可するルールを追加した後で、拒否したいルールを番号指定で削除することになります。上の場合で、IPv4での http 入力を拒否する場合には、対象となるのは、2番のルールですので、
# ufw delete 2
とします。なお、現在のところ IPv6 での LIMIT IN は利用できないようですので、ALLOW IN や、当面の間 IPv4 のみ LIMIT IN で許可するなどの妥協が必要になります。

実際に作業する前に...


この一連の作業はネットワーク構成を変更する作業で、作業を誤ると通信できなくなってしまう可能性もあります。そういった状況に陥ることを防ぐために、コンソール( VNC もしくは仮想シリアルのどちらでもかまいません ) での作業を行うことや事前にバックアップを取っておくといった準備を行うことをお勧めします。

一応設定はしてみたけれど...


正直現時点では VPS サーバを IPv6 化しても、いつも使うインターネット環境が IPv4 だけだという場合にはなかなか実感がわかない部分がありますが、近い将来に役に立つことがきっと来るのではないかと思います。

2011年2月9日水曜日

相次ぐセキュリティ注意喚起にご留意を

ここ2,3日の間で、JPCERTコーディネーションセンターから注意喚起が相次いで出されました。

まずは、Adobe 関連のアップデートということですが、Flash Player および Adobe Reader/Acrobat のセキュリティアップデートが出されています。

JPCERT-AT-2011-0005 Adobe Flash Player の脆弱性に関する注意喚起
JPCERT-AT-2011-0004 Adobe Reader 及び Acrobat の脆弱性に関する注意喚起

現行の Flash Player と Adobe Reader/Acrobat は全て対象になるようですのでアップデートを行う必要があります。Adobe の Flash や Acrobat は現在広く利用されているソフトウェアではありますが、脆弱性の発見とアップデートが日常的に行われています。現在のところ JPCERT/CC では攻撃が行われたという情報は持っていないということですが、アップデートしておきたいところです。気を許すとすぐにアップデートしないといけない部分もありますが、アップデートの仕組みについても Chrome や Google 日本語入力のようにとまでは言いませんがスマートにアップデートする仕組みを Adobe さんには開発してもらいたいところです。

そして、Microsoft の月例アップデートですが

JPCERT-AT-2011-0003 2011年2月 Microsoft セキュリティ情報 (緊急 3件含) に関する注意喚起

インターネットに接続する一般ユーザが使う PC などではこの辺は「自動更新」でアップデートしてしまうのが吉だと思います。業務用に使用しているところだといろいろ制限がある場合もありますが、業務に影響しない範囲ならばこの辺はきちんと追っかけておいて損はないと思います。

さて、問題は次の

JPCERT-AT-2011-0002 主に UNIX / Linux 系サーバを対象としたインターネット公開サーバのセキュリティ設定に関する注意喚起

で、この注意喚起の内容が非常につかみづらいところがあります。要は「5060/udp を scan する試みが広く行われていて、それらは踏み台にされた UNIX/Linux サーバが使われているようだから気をつけろ」ということなのですが、注意喚起文のなかに掲げられている、定点観測システムでの検出状況をみると

(上のグラフは国内、下のグラフはアジア太平洋での観測動向です )

と、昨年の 7~9月 に観測実績があがり、ここ最近では小康状態を保っているように感じられます。このような小康状態期にあえて JPCERT/CC が注意喚起するということは量的なところではなく別の要因があると考えるのが自然です。こういった注意喚起文ではナーバスなところはボカすどころかまったく言及されない性質があるのですが、もう一度読んでみると
今回、情報提供者から本事例に関する情報と攻撃者によって設置されたプログラムの提供を受けて調査した結果、攻撃の流れが判明した事に加え、インターネット定点観測システム (ISDAS/TSUBAME) で観測した送信元IPアドレスが国内に多数存在していることから、不正侵入されたサーバへのセキュリティ対策の実施や、同様の被害の未然防止を目的として、本注意喚起を発行しました。
と書いてあることに気が付きました。つまり、

  • 攻撃メカニズムが分かってきた
  • 5060/udp scan を仕掛けている送信元IPアドレスに国内のものが多数存在する
というのがキーポイントのようです。攻撃メカニズムについては注意喚起文に詳しく説明されているのでそちらを読んでいただくとして、scan 元に国内IPアドレスが多数存在するという記述はその真偽も含めて興味が出るところです。

ということで、色々なところのパケットフィルタログを掘り出してきて 5060/udp scan を仕掛けてきた国内IPアドレスについて調査をしてみました。といっても仕事で解析した部分もあるので、おおまかな傾向のみですが書いてみたいと思います。

  • 5060/udp scan をかけてくるIPアドレスの多くは中国もしくはアメリカからのものである ( 国内IPアドレスからの scan は構成比でトップになるほど多いというわけではない )
  • scan 実績があったIPアドレスの多くはホスティングサーバやVPSサーバからのものが多い。自宅サーバもないわけではないけれどもどちらかというと少数派
  • 中には色々な RBL やブラックリスト的なものに登録されているサイトもある
  • 確かに弱点がありそうな(笑)運用状態のサイトもまま見受けられる
とこういった傾向がみられました。特にここ最近低価格のホスティングサービスや VPS サービスが出てきてユーザの人気を集めていますが ( さくらのVPS についてはこのブログでも取り上げました ) せっかくお金を出してそういったサービスを利用するわけですから、ある程度のところまではがんばって構築をして最低限のセキュリティを保ってもらいたいなと思います。

イマドキの Linux ディストリビューションでは、サービスを立ち上げることだけに焦点をあてると比較的簡単に構築できるわけですが、長く使うのであればセキュリティにも注意を払い、知らず知らずのうちに加害者にならないことが肝要です。このブログのさくらのVPSシリーズでいえば、ufwによるファイヤーウォールの設定、かなりはしょって書いてしまいましたが、SSHサーバの設定といったところは非常に重要な要素になると思います。特に SSH サーバについては、パスワード認証を使わずに公開鍵認証のみに絞ることができればパスワードが破られて侵入されるといった脅威をかなりとり除くことができます。

中途半端な状況で放置するくらいなら一旦サーバを初期化してもう一度トライしてみるというのも良い経験になるかと思います。末長く運営するための手間は一見無駄なものに見えるかもしれませんが後でかならずその苦労は帰ってきますので、よくよく確認していただければと思います。

とはいえ、中には業務で使用しているものがそのような状況に陥っているところもごく一部に見受けられますが、何らかの方法できちんとマネジメントしてもらうか、それができなければ相応の報いを受けるしかないかと思います。日本には不正アクセス禁止法 ( 不正アクセス行為の禁止等に関する法律 ) という法律がありますが、法律そのものがサーバのセキュリティを守ってくれるというものではないということを知るべきなのかもしれません。

2011年1月6日木曜日

さくらのVPS 逆引きDNS変更機能実装

みなさま、あけましておめでとうございます。
本年もどうぞよろしくお願いします。

さて、すでに去年の話になってしまいましたが、さくらのVPS に「逆引きDNS変更」機能が実装され、コントロールパネルから利用可能になりました。(ホスト名のところに「変更」ボタンが追加されました)


この逆引きDNS変更機能というのは、DNS の PTR レコードについて、利用者が所持しているドメイン配下の FQDN 名(完全修飾ドメイン名)を VPSマシン に割り振ることができる機能です。


使用している方はすでにご存じかと思いますが、さくらのVPSの利用を開始すると sakura.ne.jp ドメイン下のホスト名が割り振られ、PTR レコードについても初期値が設定されますが、この機能を使うことで利用しているVPSに対してDNS正引き(DNS名からIPアドレス)とDNS逆引き(IPアドレスからDNS名)の結果を一致させることができるようになります。

この機能は正逆双方のDNS検索が一致することが要件になるサービスを運営する必要がある場合や SSL 証明書を取得して https サービスを稼働させる場合により便利になる機能ではありますが、通常のサーバとしての用途の場合、どちらかというとメンテナンス操作時の見た目や精神的なものが大きいのではないかと思います。私が利用しているVPSでは当面そういった需要は出てこないので標準設定状態で運用するつもりです。

また、逆引きDNSとは直接関係ありませんが、「VNCリモートコンソール」についてもベータ版という扱いから、正式版に格上げされて、「リモートコンソール」画面の「VNCコンソールを開く」のリンクから起動できるようになりました。

2010年11月9日火曜日

さくらのVPS に軽量 Wordpress を

皆様おひさしぶりです。プライベートな話で恐縮ですが、この秋に引越しをしてようやくちょっと落ち着いたところです。普段「自宅サーバ」ということで、あーんな機械やこーんな機械を動かしていたのですが、こういうことがないと「自宅サーバの事業仕訳」をやらないので、ある意味いい機会だったのかもしれません。

ちょっと前に連載状態で紹介していた「さくらのVPS」についても実はこの引越しの一環で、自宅で動かしていたものをVPS環境に移すことで、自宅環境で楽をしようという目的がありました。事実、引越し先のインターネットはADSL環境となるので、遅延や帯域的にも引越し前にくらべてかなり不利になってしまいます。

ということで、自宅で運営していた Web コンテンツのうち、Blog ( 今書いているこの Blog は Blogger ですが、実験的なことができる環境も欲しいですよね ) とウェブアルバムについて VPS 環境に移しました。といってもただ単に移行するのでは芸がありませんし、どうせなら旬のものにチャレンジしたいということで、「さくらのVPS + Ubuntu 10.10 Server + lighttpd + MySQL + Wordpress 」というちょっとトンがった環境を作りました。少し前に「LAMP ( Linux + Apache + MySQL + PHP )」なんて言葉がその筋でちょっとだけ流行ったことがありましたが、そんなノリでいけば「LLMP ( Linux + Lighttpd + MySQL + PHP )」ということでしょうか。

とはいっても、Ubuntu のパッケージ体系ではこの組み合わせも想定の範囲内で apt-get だけでほぼすべてのソフトウェアが揃ってしまいます。この柔軟さは兄貴分にあたる Debian 譲りの特徴といえるでしょう。インストールについては都度必要なパッケージをインストール、データベースのセットアップ等必要な事項をこなしていく格好となります。ただ今回は Web サーバに Lighttpd を使ったので、Apache と Lighttpd の相違点で問題となる箇所を修正する必要があります。

特に問題となるのは Apache の mod_rewrite の設定項目で、Lighttpd では Apache 向けの設定をそのまま使うことはできませんし、最新の WordPress のマルチサイト機能を使う場合にはこの設定が必須となるので、ここを乗り越える必要があります。今回は「サブディレクトリ」でのマルチサイト構築となりましたが、WordPress の管理ページでは「ツール」→「ネットワーク」の部分で、
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]

# uploaded files
RewriteRule ^([_0-9a-zA-Z-]+/)?files/(.+) wp-includes/ms-files.php?file=$2 [L]

# add a trailing slash to /wp-admin
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]
RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]
RewriteRule . index.php [L]
と設定するよう指示がなされます。Lighttpd 的には、URL書き換えを行うmod_rewriteを使い

url.rewrite-once = (
"regex1" => "relative-uri1",
"regex2" => "relative-uri2"
)
といったように書いていくのがセオリーなのですが、%{REQUEST_FILENAME} の部分は ModRewrite ではどうも表現できません。ここは随分悩んだところでして、いろんなサイトを調べて、mod_magnetを使い lua で rewrite ルールを記述する必要があることがわかりました。Lighttpd の設定ファイルに
server.modules += ( "mod_magnet" )
$HTTP["host"] =~ "^some\.your\.domain" {
magnet.attract-physical-path-to = ( "/some/path/to/wpmu.lua" )
}
と記述し、下記のような wpmu.lua スクリプトを書きます。
if (not lighty.stat(lighty.env["physical.path"])) then
if (string.match(lighty.env["uri.path"], "^(/?[^/]*/)files/$")) then
lighty.env["physical.rel-path"] = "index.php"
else
n, a = string.match(lighty.env["uri.path"], "^(/?[^/]*/)files/(.+)")
if a then
lighty.env["physical.rel-path"] = "wp-includes/ms-files.php"
lighty.env["uri.query"] = "file=" .. a
else
n, a = string.match(lighty.env["uri.path"], "^(/?[^/]*/)(wp-.*)")
if a then
lighty.env["physical.rel-path"] = a;
else
n, a = string.match(lighty.env["uri.path"], "^(/?[^/]*/)(.*\.php)$")
if a then
lighty.env["physical.rel-path"] = a
else
lighty.env["physical.rel-path"] = "index.php"
end
end
end
end
lighty.env["physical.path"] = lighty.env["physical.doc-root"] .. lighty.env["physical.rel-path"]
end
これで前掲の .htaccess での mod_rewrite 機能が実装できるかと思います。

ひととおり試してうまくいくようになったことが確認できたら、さらに速度を稼ぐためにこの lua スクリプトをプレコンパイルしておきます。
% luac -o wpmu.luac wpmu.lua
また、設定ファイルの magnet.attract-physical-path-to についても
    magnet.attract-physical-path-to = ( "/some/path/to/wpmu.luac" )
と書きなおした上で Lighttpd を再起動すれば完了です。

余談ですが、この wpmu.lua、ファイル名や Google 検索でご察しのとおり WordPress MU 向けのファイルとして英語圏で広く共有されているものですが、 WordPress 3 になってメディアライブラリへアップロードされたファイルへアクセスするための php スクリプトが wp-content/blogs.php から wp-includes/ms-files.php に変更になりましたので、この部分を確認しておかないとメディアライブラリにアップロードしたものが利用できないということが起きるので、注意が必要です。

2010年10月1日金曜日

さくらのVPS Ubuntu 10.04 大まかなまとめ

ちょっとした連載という形で続けてきた、さくらのVPS Ubuntu 10.04 連載でしたが、あとはそれぞれ
  1. インストールするサービス用のテスト用ファイヤーウォール設定の変更
  2. サービスのインストール
  3. サービスの設定、構築
  4. 本番用のファイヤーウォール設定の変更
という一連の流れを繰り返していくこととなります。ufw の設定の際には HTTP についても設定しましたが、ここから先は場合によっていろんな選択肢が考えられる展開となります (実際のところ HTTP についても、デファクトスタンダードになっている Apache や、速度重視の Lighttpd のどちらを選ぶのかは場合によりけりだと思います) 。

最小構成から必要なものだけをインストールしていくという手法をとることによって、フットプリントを小さく抑えることができ、かつ動作も軽く、(余計なものが入っていないので) 意図しないところからのセキュリティ脅威を未然に防ぐといったことが可能になります。
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 19G 896M 17G 5% /
none 243M 164K 243M 1% /dev
none 247M 0 247M 0% /dev/shm
none 247M 40K 247M 1% /var/run
none 247M 0 247M 0% /var/lock
none 247M 0 247M 0% /lib/init/rw
none 19G 896M 17G 5% /var/lib/ureadahead/debugfs
この状態でのディスクの消費量を見ても、1 GB 以下、 / パーティションの 5% 程度にすぎません。

私が UNIX ライクな OS を使いだしたときに比べて非常にこの辺は洗練されてきている印象があります。実際ここまでくる間でも、ソースコードを入手してコンパイルをするといった必要はありませんでしたし、ファイヤーウォールだって簡単に設定できます ( 本音を言えばソースコードからコンパイルするという作業も教育的な意味からすると重要なのですが ) 。最小の手間で必要なものだけを用意することができるということでは本当に便利に世の中になりました。

ということで、さくらの VPS ですが、サーバを借りてみたいがコスト的にはちょっとという人や、自宅サーバの運用に疲れた人にはおすすめのサービスなのではないかとおもいます。

2010年9月30日木曜日

さくらのVPS Ubuntu 10.04 SSH サーバの設定

Google Developer Day 2010 から帰ってまいりました。非常に有意義なイベントでとても刺激を受けました。

さて、今日はさくらの VPS の Ubuntu に SSH サーバをインストールしてみたいと思います。

とはいえ、インストールについては簡単で、メタパッケージ ssh を
# apt-get install ssh
としてインストールするだけです。インストールが成功すると、自動的に ssh サーバが起動しますので、一旦
# service ssh stop
として、sshサービスを停止させておきます。Ubuntu の ssh サーバではデフォルトでパスワード認証を許可する設定となっていますが、ブルートフォース攻撃をかけられたり、パスワードが何らかの経路で漏れたときにVPSサーバを危険にさらしてしまいます。ブルートフォース攻撃については前回のファイヤーウォールの設定でそれなりに障壁を作っていますが、できれば、公開鍵認証を使うことにして、設定を変えておきたいところです。ssh の設定を変更するには /etc/ssh/sshd_config を編集します。
/etc/ssh/sshd_config
49 # Change to no to disable tunnelled clear text passwords
50 #PasswordAuthentication yes
51
52 # Kerberos options
53 #KerberosAuthentication no
54 #KerberosGetAFSToken no
ここでパスワード認証の設定部分である、PasswordAuthentication の部分を no と設定します。
/etc/ssh/sshd_config
49 # Change to no to disable tunnelled clear text passwords
50 #PasswordAuthentication yes
51 PasswordAuthentication no
52
53 # Kerberos options
54 #KerberosAuthentication no
55 #KerberosGetAFSToken no
この設定をすることにより、このサーバに対してはパスワードだけでの認証について受け付けない設定となりました。

さくらのVPS にログインするためには、 ~/.ssh/authorized_keys2 に公開鍵を追記 ( 存在しなければ作成 ) します。あまり意味はありませんが、今回作った公開鍵の場合には
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys2
とします。公開鍵については何らかの方法で VPS サーバに転送する必要がありますが、あくまで公開鍵ですので、一時的に適当な Web ページにアップロードして、wget コマンドで取得するのが良いでしょう( あとでファイルを消すことができて、かつ信用のおけそうなところを使うべきではありますが... )。設定が終わったら
# service ssh start
で ssh サービスを起動しましょう。あとは ssh が使えるプラットホームであれば、Winodws なり Mac なりなんでも作業端末になります。

2010年9月24日金曜日

さくらのVPS Ubuntu 10.04 ファイヤーウォールの設定

Ubuntu 10.04 が入った、さくらのVPS ですが、今回はファイヤーウォールの設定について書いてみたいと思います。

Ubuntu をファイヤーウォールに


「ファイヤーウォール」というと、たぶん皆さんは Windows マシンにインストールするウィルス対策ソフトウェアのデスクトップファイヤーウォールを想像するのではないかと思いますが、Linux ベースの OS では多くの場合、iptables コマンドを使って制御します。ここで「詳しくは iptables のマニュアルを読んで設定してください」と書いてしまうと、話は終わってしまうのですが、実はこの iptables には色々な機能が実装されていて、なかなか手数がかかって複雑かつ面倒だという事情があります。インタフェースをたくさん持っていてたくさんのネットワーク間の通信制御を行おうとすると、もはや人力で設定するのは難しいレベルに到達したりもします。こういったファイヤーウォールの設定を本気で作ろうとすると fwbuilder などで設定を作ることも検討しなければいけないのですが、さくらのVPS を使うのにはそこまで大がかりになるのもどうかとも思いますし、実は Ubuntu には iptables の使いやすいラッパー ufw が用意されているので、これを使って設定してしきましょう。

ufw でファイヤーウォールの設定を


ufw コマンドはすでにインストールされていると思いますので、早速設定してみたいと思います。コンソール(ここ重要)でログインし、ufw を有効にします。
# ufw status
Status: inactive
# ufw enable
Firewall is active and enabled on system startup
# ufw status
Status: active
現在の ufw の状況は ufw status で見ることができるので、ufw enable したあとに本当に有効になっているのか、上記のコマンド実行例のようにして確認してください。もしかしたら読者のみなさんの中にはすでに ssh サーバをインストールして、sshでログインしている人がいるかもしれませんが( ssh についてはこの連載(?)でも後で扱いたいと思います )、そのような場合でもファイヤーウォールについての操作はコンソールで作業することをお勧めします。設定に失敗した場合に ssh ではどうにもならない事態に陥ることもままあるので、はじめからコンソールで作業するのが無難です。逆の言い方をすれば、コンソールへアクセスする手段がない状況でこの手の作業を行うのは非常にリスクが高いことだということになります。

次にファイヤーウォールの設定に合致しなかったパケットについての処理について決めておきます。さくらのVPS は文字通りサーバとして使うので、入力時に規制ルールを書き、出力時は特に制限をかけないことにしておきたいと思います。ufw default コマンドで
# ufw default deny incoming
Default incoming policy changed to 'deny'
(be sure to update your rules accordingly)
# ufw default allow outgoing
Default outgoing policy changed to 'allow'
(be sure to update your rules accordingly)
# ufw reload
Firewall reloaded
# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing)
New profiles: skip
として、デフォルトルールとして、入力については deny、出力については allow と設定してください。なお、この状態では具体的なルールを書いていませんので、入力パケットについては全て破棄されることになります。

提供(予定の)サービスについて許可ルールを追加


ここではじめて、提供(もしくは提供予定の)サービスについて、許可ルールを追加します。ここでは、ssh と http について、許可ルールを追加してみたいと思います。
# ufw limit in ssh/tcp
Rule added
# ufw allow in http/tcp
Rule added
# ufw status numbered
Status: active

To Action From
-- ------ ----
[ 1] 22/tcp LIMIT IN Anywhere
[ 2] 80/tcp ALLOW IN Anywhere

# ufw reload
Firewall reloaded
さくらのVPS にとって、入力パケットはすべてVPSサーバ自身へのパケットですので、IPアドレスを書かずに allow in や limit in という風に指定することができます。

ここで、ssh については limit in を指定しましたが、これは、ssh に対してブルートフォース攻撃( ユーザ名とパスワードを総当りで試す攻撃 )が横行している状況を受けて、同一 IP アドレスから 30 秒間に 6回以上の接続がある場合には接続を拒否するという設定です。これで ssh と http のみを受け付ける設定ができました。

ufw の優れているところは、ループバックインタフェース lo の通信や icmp 、接続が確立されている通信などについての許可ルールや、マルチキャストやブロードキャストアドレスの通信を拒否するといった設定が暗黙のうちに組み込まれているところです( 詳しくは /etc/ufw や /lib/ufw のファイルを覗いてみてください )。文献によってはこの ufw を「簡易Firewall」と書いているところもありますが、なかなかしっかりしている印象をうけました( 正直私にはこれだけの設定内容を iptables で短時間にスクラッチから書くことはできません )。iptables で実現できるすべてのことを ufw で制御できるわけではないのですが、さくらのVPS のようなサーバに対してはジャストフィットな仕組みだと思います。

次回は


ファイヤーウォールの設定もできたので、ここらで ssh サーバを立ち上げたいと思います。

2010年9月22日水曜日

さくらのVPS Ubuntu 10.04 セカンダリDNSサーバとNTPの設定

Ubuntu 10.04 をインストールしてきた、さくらのVPS ですが、OSそのものの設定についてはあとちょっとだけ残っている部分があります。

セカンダリDNSサーバを設定する


標準のCentOSの時に控えてきた情報の中で、まだ設定していない項目があります。セカンダリ(2つ目)で使用する DNS サーバと、 NTP サーバです。まずは DNS リゾルバの設定です。設定ファイルは /etc/resolv.conf ですので、このファイルを root 権限で編集します。インストールしたそのままの状態では
search (インストール時に設定したDNSサーチドメイン名)
nameserver (インストール時に設定したDNSサーバ)
という状態で、DNSサーバは1個設定されている状態だと思います。すくなくとも1個設定してあり、このDNSサーバが稼働していれば特に問題はありませんが、CentOSでの設定に合わせる形で
search (インストール時に設定したDNSサーチドメイン名)
nameserver (インストール時に設定したDNSサーバ)
nameserver (設定を控えておいたセカンダリDNSサーバ)
と1行追加しておきましょう。ファイルを変更したら一般ユーザでDNSでの名前解決ができることを確認しておきましょう。
ubuntu@foobar$ dig google.com

; <<>> DiG 9.7.0-P1 <<>> google.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22486
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;google.com. IN A

;; ANSWER SECTION:
google.com. 128 IN A 66.249.89.99
google.com. 128 IN A 66.249.89.104

;; Query time: 14 msec
;; SERVER: (ここに /etc/resolv.conf で設定した nameserver のIPアドレスが表示されます)
;; WHEN: Wed Sep 22 15:21:48 2010
;; MSG SIZE rcvd: 60
このようにIPアドレスが検索できれば大丈夫です。

Ubuntu は生き物だ ( apt-get によるアップデート)


ここまで設定して、さくらのVPS からインターネット上のリソースを利用できるようになりました( 逆に、さくらのVPSマシンはサービスをインストールしていないのでまだコンソールからしか操作できません )。 ここで、Ubuntu システムのアップデートをしておきましょう。ログインすると
Welcome to Ubuntu!
* Documentation: https://help.ubuntu.com/

(途中略)

8 packages can be updated.
8 updates are security updates.

ubuntu@foobar$
などと表示されるかと思います。ここで重要なのは最後の 2 行の部分で、この例では 8 個のパッケージがアップデート可能で、そのうち 8 個が ( この場合は全部ですね ) がセキュリティ関連のものだという意味になります。インストール時にはこういったアップデートは手動で行うように設定したので、自動的にアップデートしたり再起動したりすることはありませんが、Windows Update のように折を見て更新しておく必要があります。アップデートするためには
ubuntu@foobar$ sudo apt-get update
[sudo] password for ubuntu: (ログインパスワードを入力します)
Hit http://jp.archive.ubuntu.com lucid Release.gpg
Hit http://jp.archive.ubuntu.com lucid-updates Release.gpg

(途中略)

Hit http://security.ubuntu.com lucid-security/multiverse Sources
Reading package lists... Done
ubuntu@foobar$
として、(一応念のため) パッケージリストを最新状態にアップデートした上で、アップデート操作を行います( 以降、sudo の部分は # プロンプトで省略するので適宜読み替えてください)。
# apt-get upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be upgraded:
bzip2 dpkg ... ( ここにアップデート対象のパッケージが列挙されます )
8 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 45.8MB of archives.
After this operation, 4096B of additional disk space will be used.
Do you want to continue [Y/n]?
ここで対象パッケージを確認したうえで、質問に "Y" と答えるとアップデート作業がはじまります。アップデート対象パッケージによっては再起動が必要になる場合がある ( その旨が表示されます ) ので、念のためブートローダ周りを確認して ( コンソール設定でスクリプトの内容も変更したので注意が必要です。grub 関連パッケージがアップデートされた場合には要注意です ) 再起動します。

システム時刻を同期させる


インストール時に控えていた項目で設定を入れていないのは NTP だけとなりました。現在の状況では、NTP サービスすらインストールされていないので、インストールします。パッケージ名は "ntp" なので、これをインストールするということで apt-get コマンドを使ってインストールします。
# apt-get install ntp
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
ntp-doc
The following NEW packages will be installed:
ntp
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 559kB of archives.
After this operation, 1450kB of additional disk space will be used.
Get:1 http://jp.archive.ubuntu.com/ubuntu/ lucid/main ntp 1:4.2.4p8+dfsg-1ubuntu
2 [559kB]
Fetched 559kB in 0s (790kB/s)
Selecting previously deselected package ntp.
(Reading database ... 41610 files and directories currently installed.)
Unpacking ntp (from .../ntp_1%3a4.2.4p8+dfsg-1ubuntu2_amd64.deb) ...
Processing triggers for man-db ...
Processing triggers for ureadahead ...
ureadahead will be reprofiled on next reboot
Setting up ntp (1:4.2.4p8+dfsg-1ubuntu2) ...
* Starting NTP server ntpd [ OK ]

今回は一つのパッケージでしたが、複数のパッケージを一度にインストールしたり、他のパッケージに依存しているものは必要なパッケージをリストアップして同時にインストールしれくれます。また、 ntp パッケージをはじめ、多くのパッケージでは、自動的にサーバサービスが起動されるようになっています。とはいえ、ntpサーバは ubuntu のサーバを参照するように設定されているので、ここは変更しておきましょう。設定ファイルは /etc/ntp.conf で
 14  
15 # You do need to talk to an NTP server or two (or three).
16 # server ntp.ubuntu.com ( デフォルト設定のサーバは # でコメントアウト )
17 server ( 控えておいた ntp サーバをここに記入 )
18
というふうに書き換えます。書き変えたら、ntpサーバを再起動します。
# service ntp restart
* Stopping NTP server ntpd [ OK ]
* Starting NTP server ntpd [ OK ]
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
(設定したサーバ).GPS. 1 u 2 64 1 0.406 2.388 0.001
#
ntp サービスを再起動したところで、 ntpq -p コマンドで設定したサーバが参照されていることを確認してください。このような形でサービスを追加していくのが今後の構築の流れになります。ただ、今回はセキュリティ面を特に気にせずにサービスの導入を行いましたが、設定もれなどがあるとそこが弱点になるので、ひとつひとつ段階を踏んでサービスを増やしていくと良いでしょう。なお、 Ubuntu 10.04 の ntp サービスでは、設定ファイルで特に明示しないかぎり外部からのntpサービスへの参照を拒否する設定となっています( 本当にそうなのか設定ファイルを確認してください )。

次回は


インターネット上でサービスを公開する上ではセキュリティは避けて通れない話題ですが、そのあたりを書いてみたいと思います。

2010年9月18日土曜日

さくらのVPS Ubuntu 10.04 コンソール環境の整備

さてみなさん、さくらのVPS に Ubuntu をインストールすることはできたでしょうか? 微妙に誰も読んでない気もしないではないのですが、気にせず続けていきたいと思います。前回の作業でインストールはしたけどサービスとしては何も稼働していない、純白の花嫁のような環境ができたのですが、インストーラでは設定しきれない部分について拾っておきたいところです。なお、この「何一つサービスを公開していない」という状況は裏を返せば「攻撃を受ける要素がない」という状況なので、このまましばらく設定を続けていきたいと思います。

コンソール環境の整備しよう


さくらのVPSでは、VPSのシリアルポートをコンソール端末として使用できる「リモートコンソール」と、ディスプレイとキーボード相当に相当する「VNCコンソール」が利用できますが(現在「VNCコンソール」はベータ版扱いでまだ公式なものではありません)、このコンソール環境についても標準OSである CentOS の時と同じようにブートローダーやログインできるように整備しておくと、いざというときに役にたちそうです。

「リモートコンソール」からログインできるようにしよう


ということで、VPSのシリアルポートに相当する「リモートコンソール」でログインできるようにしてみたいと思います。UNIX や Linuxマシンでは端末を監視するのに getty という仕組みを使い、 getty は OS が起動した直後に実行される init で実行されます。Ubuntu 10.04 では init の挙動を /etc/init ディレクトリの設定ファイル群で指示する形になっています。実際に /etc/init の中をのぞいてみると、tty1.conf や tty2.conf といったファイルがあるのが確認できるかと思います。この設定ファイルにならってシリアルコンソール用の設定を作ります。最初のシリアルポートは /dev/ttyS0 ですので、/etc/init/ttyS0.conf を以下の内容で作成します。
# ttyS0 - getty
#
# This service maintains a getty on ttyS0 from the point the system is
# started until it is shut down again.

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]

respawn
exec /sbin/getty -8 115200 ttyS0
といっても、デバイスと通信速度以外は tty1.conf と一緒なので、
# cd /etc/init
# cp tty1.conf ttyS0.conf
# vi ttyS0.conf
( 速度を 115200, デバイスを ttyS0 に変更するよう内容を編集 )
というふうにすると良いでしょう。ファイルの作成が終わったらVPSを再起動すると「リモートコンソール」にも Login: プロンプトが出現し、ログインして作業できるようになります。

「リモートコンソール」でブートローダも制御できるようにしよう


これで、「リモートコンソール」でログインできるようになりましたが、VPSの電源投入時や再起動時に VNC コンソール同様にリモートコンソールブートローダの制御も行えるようになるとさらに安心できそうです。これは Ubuntu が起動するまでの部分ですので、さきほどの getty や init ではなく、ブートローダの設定を変更することになります。VPSの標準OSの CentOS では grub v1 が採用されていましたが、 Ubuntu では grub も新バージョンの grub v2 が採用されています。 grub 2 になって様々な部分が拡張され、より複雑になってしまいましたが、設定は /etc/default/grub で指定し、各種スクリプトなどを使い、/usr/sbin/update-grub コマンドでそれらを反映させる仕組みとなっています。

今回は標準の CentOS と同じように、リモートコンソールとVNCコンソールの両方で制御を行うことを目標にしますが、現行の Ubuntu 10.04 のスクリプト群では複数のデバイス ( この場合はシリアルポートとディスプレイ ) を入出力デバイスをして使うことは想定されていない状況なので、スクリプトにも手を入れる必要があります。

さしあたり、設定ファイル /etc/default/grub の冒頭の部分を
# If you change this file, run 'update-grub' afterwards to update         
# /boot/grub/grub.cfg.

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
という内容から
# If you change this file, run 'update-grub' afterwards to update         
# /boot/grub/grub.cfg.

GRUB_DEFAULT=0
# GRUB_HIDDEN_TIMEOUT=0
GRUB_HIDDEN_TIMEOUT_QUIET=false
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX="nosplash console=tty1 console=ttyS0,115200n8r"
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200 --word=8 --parity=no --stop=1"
GRUB_TERMINAL_INPUT="serial console"
GRUB_TERMINAL_OUTPUT="serial console"
と書き換えてください。ポイントは
  • GRUB_HIDDEN_TIMEOUT をコメントアウト
  • GRUB_CMDLINE_LINUX_DEFAULT と GRUB_CMDLINE_LINUX を編集 ( console= は2か所あり、tty0 ではなくて tty1 を指定してください )
  • GRUB_SERIAL_COMMAND, GRUB_TERMINAL_INPUT, GRUB_TERMINAL_OUTPUT を新規に作成
  • これ以降の部分はそのままに
というところです。また、このようにGRUB_TERMINAL_OUTPUT を指定すると /usr/sbin/grub-mkconfig スクリプトの中のチェックに引っ掛かりエラーとなるので、/usr/sbin/grub-mkconfig の 145 行目をコメントアウトします。
141       fi
142     fi
143   ;;
144   xconsole | xserial | xofconsole) ;;
145 #   *) echo "Invalid output terminal \"${GRUB_TERMINAL_OUTPUT}\"" >&2 ; exit 1;;
146 esac
147
148 # check for terminals that require fonts
149 case ${GRUB_TERMINAL_OUTPUT} in 
また、この書き方をするとシリアルポートを使用しないものとみなされ、GRUB_SERIAL_COMMAND の設定内容が無視されてしまうので、/etc/grub.d/00_header の 68 行目について
67 case ${GRUB_TERMINAL_INPUT}:${GRUB_TERMINAL_OUTPUT} in
68   *serial*:* | *:*serial*)
69     if ! test -e ${grub_prefix}/serial.mod ; then
70       echo "Serial terminal not available on this platform." >&2 ; exit 1
71     fi
72
73     if [ "x${GRUB_SERIAL_COMMAND}" = "x" ] ; then
74       grub_warn "Requested serial terminal but GRUB_SERIAL_COMMAND is unspecified. Default parameters will be used."
75       GRUB_SERIAL_COMMAND=serial
76     fi
77     echo "${GRUB_SERIAL_COMMAND}"
78   ;;
79 esac
と、serial:* | *:serial) から *serial*:* | *:*serial*) へと変更します(念のため各ファイルについてはオリジナルのものを保存して、元に戻せるようにしておきましょう)。

ここまできたら、update-grub コマンドを root 権限で実行します。
# /usr/sbin/update-grub
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.32-24-generic
Found initrd image: /boot/initrd.img-2.6.32-24-generic
Found memtest86+ image: /boot/memtest86+.bin
done
#
エラーが出ずに正常に更新されたようであれば、再起動してうまくいくかどうか確認します。うまく設定できたら、VNCコンソールの ALT + F1~F6 キーで切り替えられる仮想コンソールの設定について粛清します。tty1 と tty2 だけ残しておけば大丈夫だと思いますので、
# rm /etc/init/tty6
...
# rm /etc/init/tty3
と設定ファイルを消して資源の節約をはかっておきましょう。

今回のTips


これで標準のCentOSの時のようにコンソールが使えるようになったかと思いますが、作業についての小技を紹介しておきたいと思います。
  1. Ubuntu の標準では root ユーザのパスワードが利用できない
  2. Ubuntu の標準では root のパスワードが利用できない設定となっています。これはパスワードで特権ユーザである root ユーザの利用をするのではなく、資格のあるユーザが必要に応じて root 権限でコマンドを発行することにより事故を防ごうというものです。コマンド実行例ではその部分についてばっさり省略して、root 権限でコマンドを実行することを # プロンプトで示していますが、実際に作業を行う際には sudo コマンドを活用してください。sudo コマンドは
    $ whoami
    chonan
    $ sudo whoami
    [sudo] password for chonan: (ここでログイン時のパスワードを入力します)
    root
    $
    といったふうにroot権限でコマンドを実行するのに使います。なお、sudo コマンドの詳しい使用方法についてはマニュアルや他サイトの解説を参考にしてください。
  3. テキストエディタは何を?
  4. 今回はじめてテキストファイルを編集するシチュエーションが出てきましたが、テキストエディタについては詳しく触れませんでした。私はこういったオペレーションをよくやるので、vi や vim などの vi 系のエディタを愛用しています。vi はちょっと癖があってという人は、nano というエディタが Ubuntu の最小構成でも利用できるので、これを使うのが良いと思います。emacs 系のものは最小構成には入っていないので、nano か vi を使ってしばらくは凌いでください :)


次回予告


書きだすとどうしても分量が増えてしまいますが、次回は引き続きインストーラーでカバーされなかった内容の設定について書きたいと思います。

2010年9月17日金曜日

さくらのVPS OS入替 ( Ubuntu 10.04 amd64) まで

サーバ要件の調査


さて、思わず申し込んでみた「さくらのVPS」ですが、OSを入れ替える前にVPSサーバの要件を調べておく必要があります。これは初期状態で即使えるようにセットアップされている( もちろん「OS再インストール」を行ってもこの状態になります ) 親切設計なのですが、この状況から OS セットアップに必要な情報を収集しておかないと、いざインストールのときに困ることになるからです。仮にOSを入れ替えることを企てないような場合でも使い始めるまえにこの辺の情報は控えておいたほうが良いと思います。

とりあえずこの項目を調べてね


ということで、まずは Linux 管理の復習もかねて、VPSに設定されている以下の項目を調べておいてください。初期状態でユーザを作っていない状態でも、コントロールパネルの「リモートコンソール」や、ベータ版非公式の 「VNC コンソール」 ( https://secure.sakura.ad.jp/vpscontrol/main/vnc ) で root ユーザでログインすることができます( root ユーザの初期パスワードはメールで通知されます。また再インストールを行う際にはパスワードを指定することができます )。調べ方については詳しく触れませんが、不安な方はここで参考書などを読み復習しておきましょう。
  • ホスト名
  • DNSドメイン名
  • DNS FQDN名
  • IPアドレス
  • ネットマスク
  • ルーティング情報(デフォルトゲートウェイも含む)
  • DNSサーバ指定(複数指定されていればその全て)
  • DNSサーチドメイン名
  • NTPサーバ

なお、「VNC コンソール」については、Ubuntu 10.04 のインストールでよく使うので、ブックマークに登録しておくと良いでしょう。

Ubuntu のネットワークインストーラの入手


VPS サーバには仮想CD-ROMが接続されているようにOSから認識されていますが、「CD-ROM媒体を挿入する」という動作を行うことが現状ではできないので、ネットワークインストーラを入手し、それを起動する方向でいきたいと思います。「VNC コンソール」上にログインし、現在利用できる Ubuntu 10.04 amd64 版のカーネルとインストーラーinitrdイメージを入手します。root ユーザで
# mkdir /boot/ubuntu
# cd /boot/ubuntu
# wget http://archive.ubuntu.com/ubuntu/dists/lucid/main/
installer-amd64/current/images/netboot/ubuntu-installer/amd64/linux
...
# wget http://archive.ubuntu.com/ubuntu/dists/lucid/main/
installer-amd64/current/images/netboot/ubuntu-installer/amd64/initrd.gz
(URLが長いので折り返しましたが、この部分は1行で続けて書いてください)
としてファイルを取得します。URLが長いですが、rootの標準シェルになっている bash のヒストリ機能をつかうと2回目のコマンドの大部分の入力を楽に行うことができます。

Ubuntu のネットワークインストーラの起動


うまくファイルを取得できたら、問答無用でリブートします。他のサイトさんの Ubuntu インストールの手引きでは grub の設定ファイルを編集してますが、どうせ使い捨てになるので、ブートしたときに入力することにして、迷わず reboot です。
# reboot

VPS が再起動すると、Press any key to continue と出てくるので何かキーを押し、その後 Booting CentOS と出たところでも再度なにかキーを押すと、Grub のメニュー画面となります。

ここで中央下の部分にも書いてありますが、 'c' キーを押して、 grub コマンドラインモードに移ります。

grub のコマンドラインではこのように
grub> root (hd0,0)
grub> kernel /ubuntu/linux
grub> initrd /ubuntu/initrd.gz
grub> boot
と指定します。ここで、キーボードは us モードになっているので、一般的な日本語キーボードでは開き丸カッコは Shift + 9 、閉じ丸カッコは入力できないので root (hd0,0 とここまで入力したところで TAB キーを押して閉じ丸カッコを補完させます。また、kernel の部分についてはオプションを指定する必要が本当はありますが、VNC コンソールを使う前提であれば、こんな程度で大丈夫です。kernel や initrd のところでもファイル名については TAB キーによる補完が効くので、適当なところまで入力した後に TAB キーを押してとっとと補完させておくのがスマートだと思います。

Ubuntu のインストール


うまくいくとコンソールにメッセージが流れ、インストーラーが起動します。インストーラの質問に答えながら作業を進めていきます。
  • Choose language "C - No locale" ( 日本語もイケるけど、デフォルトの言語と設定されコンソールで日本語が表示されずに文字化けしてイヤな思いをするので、 C を推奨 )
  • - continent , country "Asia , Japan"
  • Detect keyboard layout? "No"
  • Origin of the keyboard, Keyboard layout "Japan, Japan" ( もちろんいつも使うキーボードに合わせて設定してください )
  • Charactet set to support ". Conbined - latin; Slavic Cyrillic; Hebrew; basic Arabic" ( デフォルトのままで OK )
  • DHCP "すぐにcancel" ( VPS 網に DHCP パケット飛ばしても迷惑なだけで意味はありません )
  • Network autoconfiguration failed "continue"
  • Network configuration method: "Configure network manually" ( 手動設定を選択 )
  • IP address: ( 事前に調べておいた IP アドレスを入力。よく確認して! )
  • Netmask: ( 事前に調べたネットマスクを入力。きっと 23ビットなので、きちんと確認を )
  • gateway IP address: ( 事前に調べたデフォルトゲートウェイアドレスを入力 )
  • Name server address: ( 事前に調べたネームサーバのうちいずれかを入力。インストール後に完全な設定を作ることにします )
  • Hostname: ( IPアドレスが正しく入力されていればDNS逆引きの結果得たホスト名がデフォルトの文字列になっているはずです。事前に調べたものとあってるか確認を )
  • Domain name: ( Hostname 同様確認を )
  • Choose a mirror: "Japan" ( Japan が一番有利なはず )
  • Ubuntu archive mirror: "jp.archive.ubuntu.com" ( これだけが選択可能になってるはず )
  • HTTP proxy: "" ( Proxy サーバは使用しません )
  • Time zone: "Asia/Tokyo" ( となっているはずなので確認を )
  • Partition disks: "Guided - use entire disk" ( LVM にしてもメリットなさそうなので、単にディスク全体を使用 )
  • Partition disks: ( 仮想HDD 1台のみが選択可能なはずです )
  • Write the changes to disks: "yes" ( こだわりある人はレイアウト変えるのもよいでしょうけど、所詮仮想環境なので凝っても仕方がないと思います )
  • Full name for the new user: ( 常用するユーザの本名をローマ字で )
  • Username for your account: ( 常用するユーザのアカウント名を )
  • Choose a password for the new user: ( 常用するユーザのパスワード )
  • Encrypt your home directory: "no" ( 暗号化はやめときます )
  • manage updates: "No automatic updates" ( 更新は手動でやることにします )
  • Software selection
いろいろありますが、後でから追加できるので、 Basic Ubuntu server のみを選択。
今回のようにリソースが限られている環境では、
この段階で色気を出してもロクなことにならない場合が多いので注意。
  • Install the GRUB: "yes" ( grub ブートローダもインストールします )
  • Is the system clock set to UTC? "yes" ( マルチブート環境でもありませんし、 UTC にしておいたほうが良いでしょう )
  • Installatio complete: "continue" ( インストール完了。Continue を選択すると再起動します )
と、ここまでで、インストールが完了しました。インストール中に指定したアカウント名でログインできることを確認してください。


この次は?


OSのインストールには成功しましたが、この状態では何のサービス ( ssh でさえも ) 動いていない状態です。また、シリアルポートが接続されていることになっているはずの「リモートコンソール」のほうは何の反応もない状態となっているはずです。次回はこの辺の部分の整備について書いてみたいと思います。

さくらのVPS はじめました

前回の OpenSolaris OGB 解散のエントリから少し開いてしまいましたが、その間に OpenIndiana という新たな Solaris 系のディストリビューションが発表されるなど、新たな Solaris 関連の動きもありますが、まだまだ将来が見えない状況ですが皆さんお元気でしょうか。

そのような中、さくらインターネットさんの新たな VPS サービス「さくらのVPS」がサービスインいたしました。この「さくらのVPS」はIT技術者を中心にベータテスト段階から大きな関心が寄せられ、比較的自由度の高い環境を安価( 980円/月 )で気軽に利用できるということもあり、自宅サーバで運用しているもののうちのいくつかをそちらに移してしまおうかと考え、「さくらのVPS」に申し込んでみました。余談ですが、私は自宅サーバそのものについては「フレッツISDN」の頃から運用してきましたが軌道に乗ってくると構築する要素は減り、トラブル対応などの後ろ向きな要素が増えてしまう部分があります。レンタルサーバ、自宅サーバそれぞれ醍醐味やメリット、デメリットがあるので、その時々の情勢に応じて使い分けをしたいところです。

「さくらのVPS」襲来


さて、「さくらのVPS」ですが、すでに色々なところでニュースレビューが掲載されているので、詳しい内容はそちらに譲るとして、ざっくり特徴をあげてみると
  • データセンター内の仮想サーバ環境をレンタル
  • HDD は 20GB、メモリは 512MB、固定 IPv4 アドレス 1個
  • コントロールパネル上で起動・停止・再起動・シリアルコンソール・OS再インストールができる
  • OS 環境は CentOS
  • 正式版ではないものの VNC コンソールも提供されている
といった特徴があります。他のユーザに迷惑をかけることをしてはいけないのはもちろんではあるのですが、オペレータの方に対応依頼しなくてもOSの再インストールができるので、色々と多い日でも安心です。

おおまかな目標をたてる


VPS 環境を申し込んで、いろいろ試してみた感覚での感想を書いてみると
  • ネットワーク環境はデータセンター内ということで本当に快適
  • CPUは占有できるわけではないけれども高性能 ( いつもジャンクのような機械を自宅サーバに使っているからそう感じるのかもしれません )
  • 20GB の HDD 空間は使い方に工夫すれば結構なことができそう
  • 512MB の割当メモリが目下の課題。「全部入り」でなんでも動かすようなことをしているとすぐに壁にぶちあたりそう
といった印象を受けました。余裕のサーバ構築というわけにはいきませんが、工夫すればそこそこの仕事をこなせるのではないかという印象です。とりあえずの目標として
  • OS は Ubuntu amd64 環境に入替える
  • 自宅で稼働させている bbsden.com と flky.org の Web 環境(blog)、flky.org のメール環境を移行する
といったあたりを目標にしたいところです。

OSについては標準のCentOSでも良いのですが、サーバ用途として見た場合でも標準環境でもすでにフットプリントが大きい感じがするというのと、Ubuntu の関係者の方には twitter でお世話になっている方がいらっしゃる部分もあるのでということで Ubuntu を使うことにしました ( Solaris 系の OS はメモリ割当量の関連から断念しました )。次回からは作業の様子もふくめてお伝えしたいと思います。

... と書いて、連載にするつもりなのでしょうか?