ハレとケガレのweblog pid0.org支店: 2010

2010年12月15日水曜日

中高生向けのゲーム制作雑誌「がまぐ！」創刊

有志による、21世紀の現代の中高校生を対象としたゲーム制作雑誌「がまぐ!」が 12/15 に創刊され、現在配布サイトにてPDFファイルが無償でダウンロードできるようになっています。ものすごく乱暴な言い方をするならば「21世紀のマイコンBASICマガジン」ということができるオンライン雑誌です。( 直接関係ありませんが編集長の @117Florian 氏は古い知人です。 )

この企画自体については商業目的云々ということではなくて今の時代の中高校生に読んでもらうことを第一に考え、 twitter で有志を募りオンライン雑誌という形でこのような成果物ができてしまったという非常に現代的な制作過程や、紙媒体の出版が非常に難しい状況になっている昨今の状況、そしてなりより次の時代を担う中高生が気軽に手に取れるかつての「ベーマガ」のような存在が皆無であるという状況が特筆すべき背景であったのかと思います。

とはいえ、執筆陣が豪華でしかも可能なかぎり簡単な言葉で書くという編集方針が徹底して取られており、全般的に非常に丁寧な言い回しの内容に仕上がった印象があります。その一方で昨今のIT専門書にありがちな開発環境のインストールに紙面の半分を割くといったような無駄な冗長さは排し、掲載ソースコードについては読者が手を動かして実際に入力することを推奨するためにあえてコピー&ペーストができないようにしているといった「辛い」要素も兼ね備えています。創刊号はレイアウト的に若干課題が残っている部分がありますが、今後「がまぐ!」は年4〜6回の発行を予定しているということなので、経験値を積んで次の号に活かしていけば問題ない程度なのではないかと思います。

今回はゲーム制作の世界でこのようなムーブメントが起こったわけですが、同じような問題はゲームだけにとどまらず色々な分野で現在進行形で起きている事情もありますので、今安価に利用できる資源を使って伝えたいことをオンライン雑誌の形で伝えていくという手法は有効ではないのかと思います。

ともあれ、ゲーム開発に少しでも興味がある人はダウンロードして読んで損はない内容なのではないかと思います。また中高生ではなくとも多いに刺激を受ける要素が多いので是非ダウンロードして目を通してみてください。

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月13日水曜日

Project Jaris 再起動

このところずっとお葬式状態で、未来への希望を持つとしたら Illumos もしくは OpenIndiana といった状況でありましたコミュニティベース Solaris ですが、ここにきて Project Jaris がまさかの再起動、そして復活を果たしています。

Project Jaris は 2009 年 3 月に晋遊舎さんの「Linux 100%」に巻頭特集として取り上げられ話題を呼び、このblogでもその当時の騒動(?)についてこのようなエントリを掲げて話題にしたディストリビューションです。その後、色々な事情があったのか、なかなか開発が進まず、いつしかサイトからもダウンロードできなくなっていた「幻のSolaris 系ディストリビューション」でもあります。公式には「Linux 100%」から大きな動きがなかっただけに、まさに 1 年半越しの復活ということになります。その間 Oracle/Sun は EU の独禁法審査、合併承認、沈黙、OpenSolaris コミュニティの事実上の解散と Solaris をとりまく状況は大きく変わってしまいました。

また「Linux 100%」で取り上げられたということも手伝ってか、ライトユーザ層や2ちゃんねるを中心に Jaris を待望する動きが今までずっと続いてきた、他に類を見ないディストリビューションです。

現在は onnv b135 をベースに作られた、「バージョン101フルコンテンツ版 ( Jaris-1.0p ) 」が期間限定でダウンロードできるようになっていますが、ベータ版のまま沈黙してしまったという事情もあり、Jaris の全貌に近いものが初めて公開されたといってよいのかもしれません。また、onnv b135 は結局リリースされなかった OpenSolaris 2010.03 周辺で前後の developer build に比べて安定していた事情もあるので、期待できる部分もあるのではないかと思います。

といっても、通常は「ベーシック版」を公開していく状況のようですので、興味がある方は今のうちにダウンロードして試してみてはいかがでしょうか。

(2011/09/05) 追記
"Jaris" のキーワード検索でこのエントリにいらっしゃる方が少なからずいらっしゃるようですが、2011/09 の時点での雑感をこちらのエントリに書きましたのでよろしければそちらもどうぞ。

2010年10月1日金曜日

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

ちょっとした連載という形で続けてきた、さくらのVPS Ubuntu 10.04 連載でしたが、あとはそれぞれ

インストールするサービス用のテスト用ファイヤーウォール設定の変更
サービスのインストール
サービスの設定、構築
本番用のファイヤーウォール設定の変更

という一連の流れを繰り返していくこととなります。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月27日月曜日

Google Developer Day 2010 Japan に行ってまいります

明日 9/28 、Google Developer Day 2010 Japan ( 東京会場 ) に行ってまいります。このイベントは Google のテクノロジーに関する、開発者向けのイベントなのですが、参加するためには Google テクノロジーやプログラミング等についてのクイズに答え、一定のポイントを得ないと参加権がもらえないという一風変わった仕組みになっています。( Google Developer Day - DevQuiz にご参加ありがとうざいました。 )

このクイズ、開発者向けのガチンコな内容だけでなく、ソーシャル面での貢献、エッセイなどを加味したものとなっていますが、興味本位で挑戦してみたら、「Super Hackers 枠 ( 優れたプログラミング能力を持つ方に当てはまる枠 ) 」で参加できることになりました。さらに先週末になって「Super Hackers 枠」の参加者向けの交流会の招待メールなんてものまで届き、これらのおまけを含めて参加してきたいと思います。

なお予定としては、28日は東京泊、29日は移動以外の予定を入れていませんので、リアルで会いたいという奇特な方がおられましたら、twitter @chonan に連絡でもいただければと思います。

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の時のようにコンソールが使えるようになったかと思いますが、作業についての小技を紹介しておきたいと思います。

Ubuntu の標準では root ユーザのパスワードが利用できない

$ whoami
chonan
$ sudo whoami
[sudo] password for chonan: (ここでログイン時のパスワードを入力します)
root
$

テキストエディタは何を?

次回予告

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

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 はメモリ割当量の関連から断念しました )。次回からは作業の様子もふくめてお伝えしたいと思います。

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

2010年8月24日火曜日

OpenSolaris OGB 総辞職動議可決

先月の OGB 決議から 1 か月が経ち、約束の期限を迎えました。この間にも Illumos 立ち上げの発表や、Oracle の内部のリークメモの流出、そのリークメモの内容を裏打ちする、ON コードベースの更新停止と、日々混乱状態にある OpenSolaris コミュニティですが、先の決議の期限明けの OGB 会議が月曜朝 ( カルフォルニア現地時間 ) に開かれました。

この会議に先立って公開された Agenda や各方面の状況を総合すると OGB の解散は不可避な状況にあるのではないかと個人的に感じていましたが、やはりその方向に進んでしまいました。

[ogb-discuss] Motion concerning dissolution of the OGB
http://mail.opensolaris.org/pipermail/ogb-discuss/2010-August/008012.html
( 以下拙訳を掲げます )

今朝のOGBの会議で、Plocher が作成しPhipps が賛同した以下の動議が、全会一致で (悲しいことであるが) 採択された。

-John Plocher
(前) OGB 議長

OGB の解散に関する動議

(Whereas) Oracleは、OGB と共に OpenSolaris の開発とコミュニティの将来について働く連絡役を指名するという要求を無視し続けており、

(Whereas) Oracleは、 2010 年 8 月 13 日に従業員に対して、Oracle と OpenSolaris コミュニティの間の開発パートナーシップを一方的に終結させるというOracleの決定を強いる内容のメールを配布し、

(Whereas) OpenSolaris の開かれた開発に対して Oracle の継続した支持と参加がない限り、OGB と Sun/Oracle が作ったコミュニティが開かれた Solaris 開発パートナーシップを支持するということは意味をなさなく、

(Whereas) OpenSolaris コードベースの開かれた開発を続けることについての願望と熱狂は明らかにOracleの (述べてきたように、このコミュニティの) 手から離れ、他のコミュニティに渡された。

(決議文) OpenSolaris Govering Board はここに一括して辞任し、OpenSolaris 憲章 1.1 ( および規約 1.3.5 ) の規定により OGB を選任する責務が Oracle に渡ることを示す。

これにより、現在 OGB のメンバーは誰一人として存在しない状況となりました。決議文後半の部分については、 OpenSolaris 憲章や規約において、 OGB の定員が 3～7　名であり、欠員が生じたり OGB 選挙が 14 か月実施されなかったり OGB そのものへの不信任等といった事態が生じた場合には、Oracle(Sun) が一時的に補填メンバーを指名し、臨時選挙を実施する旨の条項があることを踏まえた形となっています。

今後、現在と同じ形での OGB や OpenSolaris コミュニティを維持するためには、Oracle が OGB 補填員を指名し、臨時選挙を行い新しい OGB 体制を構築する必要がありますが、現在までの経過を見る限り現在の Oracle がそういった行動をとることは想像できなく、事実上の OGB の解散・解体ということになるかと思われます。また OGB は OpenSolaris の色々なコミュニティを統括してまとめあげる位置づけの組織ですので、残念ながらこの決議は OpenSolaris コミュニティの解体をも意味するのものであると受け取らざるをえない状況となっています。

ここにきて、OpenSolaris を構成するとされている 3 つの要素について

コードベース - onnv-gate の更新が停止される ( 先のリークメモを裏打ちする内容 )
ディストリビューション- リークメモによれば OpenSolaris としてのディストリビューションは公開されない
コミュニティ - OGB 総辞職動議により事実上解体

と、プロジェクトとしての OpenSolaris は終結してしまったと言わざるをえない状況になりました。もちろん Oracle としては次期 OS である Solaris 11 の開発を進め、Nextenda をはじめとした OpenSolaris 派生ディストリビューションや、ON の代替となるであろう Illumos などがあるので、 Solaris 系の OS の譜系が完全に途絶えるわけではありませんが、このようなハードランディングと言っていい手法でプロジェクトを終結させてしまった点については将来に遺恨を残しそうです。

2010年8月4日水曜日

Illumos Project のアナウンス

Oracle による Sun 買収から混迷状態が続いている OpenSolaris コミュニティですが、日本時間の 8 月 4 日未明に Illumos Project が電話会議および Web セミナーでプロジェクトの発表を行いました。発表の内容については Illumos Project Announcement のページにてスライドと音声が利用できるようになっています。

この Illumos ですが、OpenSolaris の基本部分である OS/Net (ON) に対して、コミュニティ主体で完全オープンソースの派生プロジェクトとし、特定企業への依存を排しコミュニティとしてのアイデンティティを保ち、ディストリビューションを作るための最小構成相当のものをリリースすることを目標に掲げています。8 月 4 日の発表では vmware 環境上でのデモも披露され、環境は限定されるものの起動できる状況まで進んでいるようです。

現行の OpenSolaris ON は、確かにコードベースの大部分についてはオープンソースとしてソースコードが公開されていますが、いまなおソースが公開されていないコンポーネントが存在し、そのコンポーネントのバイナリがないと ON のビルドができない状況にあります。また、外部の開発者がコードを寄贈しようとしても権利関係の手続き ( SCA 署名 ) を行った上でバグ登録を行い、メーリングリストで議論するところまではできたものの、実際にコードベースに反映するのは旧 Sun の従業員だという事情もあり、オーナー企業の方針に左右されやすいという問題も内在していました。

また、ON についてのこういった問題は現在すでに派生プロジェクトとなっている Nexenta, BeleniX, Schillix, berliOS といった派生OSのプロジェクトメンバーにとっても重大な問題となっていたのではないかと思います。

Oracle による買収の後、OpenSolaris コミュニティへの Oracle のかかわりが非常に希薄となっている現状 ( その一つの表れが前日の OGB 決議の件だと思います ) での今回の発表ですが、Webサイトやスライドの端々にそういった状況を打開しようとする意図が読み取れ、Illumos のサイトにはロゴの隣にリンカーンよろしく "Of the Community, By the Community, For the Community" と書かれています。現状に不満を言うのは簡単なことですが、それにとどまらず何をやるべきかを考えることが重要だという強いメッセージを個人的に感じました。今後の OpenSolaris がどの方向へ進んでいくのかということを考えるにあたり、この Illumos の動向は非常に重要になってくるのではないでしょうか。

2010年7月19日月曜日

OpenSolaris の今後

ここ最近、OpenSolaris の新しいリリースをめぐる話題や、Oracle と OpenSolaris コミュニティとの間の微妙な話題が続いており、なかなかブログに書ける話題がありませんでした。しかし 7 月に入り、OGB ( OpenSolaris Governing Board ) が状況を動かしはじめました。

なぜこの 7 月に動きが出たのかというのは、リリースするであろうと予測されていた、 OpenSolaris の新版のリリース予定の変遷が大きく関係しています。

当初 OpenSolaris のリリースは 2010 年の 2 月に予定されていました ( 合併前に Sun が予定していた当初のリリーススケジュール ) が、リリースが間に合わなく 1 か月延期されました。この延期は当時の開発者向けビルドにおいても技術的な問題があることが知られており延期やむなしとみられていました。

しかし皆さんご存じのとおり、この時期に Oracle の Sun 合併が実行されリリースの雲行きがあやしくなってきました。その後、3月中に新バージョンがリリースされることはなく、 ML への投稿の一端や Oracle の役員によるロードマップなど断片的で非公式な情報から、2010 年 5 月 ( リリース 2010.05 という内部表現など )、2010 年 6 月 ( ロードマップ資料、 2010.1H という内部リリース表記など ) にリリースされるのではないかと期待されていたのですが、結局今日まで新バージョンがリリースされることはありませんでした。

リリース時期について予測できる情報がもうないことや開発者向けのビルドについても公開が止まっていることも相まって、OGB が解散ぶくみの選択肢も示しつつ決議をしたのが下記の内容です。(私が jposug ML に投稿したメールです)

[ug-jposug] [翻訳]　OpenSolarisコミュニティの状態、2010年7月
http://mail.opensolaris.org/pipermail/ug-jposug/2010-July/002181.html

正直なところ、Oracle/Sun の「外部」の貢献者として活動してきた私にはこの OGB のメッセージは共感できる部分が大きく、多くのユーザや開発者もそう感じるのではないかと思います。合併が実行される以前は Sun の皆様が陰に陽に粋な計らいをされていたこともあり、そのおかげでコミュニティもそれなりにうまく回っていたのですが、今になってみてみると実質的な合併の後のコミュニティ運営がぎくしゃくしはじめ、うまく機能していない状況に陥ってしまったのではないかとみています。

現在のコミュニティ運営が行き詰まっているというのは、OGB の中でも認識されているようで、OGB メンバーである Peter Tribble は自身の blog で記事を書いていて

Moving OpenSolaris forward - The Trouble with Tribbles... ( Peter Tribble )
http://ptribble.blogspot.com/2010/07/moving-opensolaris-forward.html

しばらくの間岩の下で暮らしていたのでもない限り、 OpenSolaris コミュニティが健康な状態ではないことは明らかです。このプロジェクトの新しいオーナーでありスポンサーである Oracle は、見事に打ちとけないでいます。Oracle が自身の障壁の陰に引っこんでしまい、残った外部のコミュニティは内紛に従事し始めたので、OGB は完全に無力化され、単なる見物人に成り下がりました。

ですから、容易な判断ではないのですが我たちは決議しました：

OGB は OpenSolaris への理解とオープンな開発を促進し、 Oracle と共にコミュニティを代表して活動したく思っているが、それとして、OGB は 2010 年 8 月 16 日までに OpenSolaris の将来および OpenSolaris コミュニティとの相互作用について話す権限を持った連絡役をOracle が指名することを必要としている。さもなければ、OGB は 8 月 23 日の会議において Oracle へコミュニティの管理を返還する OGB 憲章の条項を発動するための行動を講じる。

いまのところ、Ben には申し訳ないのですが、これは "対話を始めるか、さもなければ自分の頭を撃ち抜く" という最後通告ではありません。私たちはすでに生命維持装置につながれていますし、もし生命の兆候がなければ生命維持装置はオフにされます。

継続して、もしくは無期限に待つということは、単に嘘を永続化させます。みんな具合が悪く、そして待つということを信じていた私たちはまったくもって愚かであったのかもしれません。それをするということは、単に妄想家になるということだったのでしょう。

それは Oracle が事態を収拾するために白馬に跨ると考えている一部の人にとっては良いかもしれません。もしそれが起きたとしても、それはコミュニティの現状が本質的に OpenSolaris 憲章・憲法と互換性がなく、私たちが新しい統制手法を持った新しい組織に向かって前に進む必要があるという、現実の状況を本当に変えるものではないでしょう。それを変えていくことは（どこであっても）現在の統制を吹き飛ばすことを意味します。Oracle　は準備しなくてもいいのですが、OGB はその必要性を認識し最初のステップを取るのに充分勇敢です。私たちは Oracle と提携してそうしたいと思っていて、それゆえに公式な連絡役が利用できるように要求しているのです。

この動きは、現実直視とモーニングコールをもたらそうとするものでもあります。どれだけ悪い事態が起こったのか分かっていないことについて、誰も ( Oracle　の内部であるか外部であるかを問わず ) いいわけすべきではないのです。

OpenSolaris は岐路に立っています。多くの道筋が開かれ、そこには利用可能な選択と下すべき決断があります。単にこの場に立ち、拳を握りしめ、そして　Oracle が地図を示すのを漠然と待つという選択肢はありません。私たちをこの場所に結び付けている足かせを壊し、前進する必要があるのです。

と述べています ( 訳出は私が行ったものですので正確なところは英語オリジナルの blog 記事を参照してください )。現状で機能していない部分は認めた上で、あらためて Oracle に連絡を呼びかけた上でそれでもダメならコミュニティの再構築を行うしかないという見解です。

今回の OGB 決議は、OGB 解散ぶくみの内容が含まれているということでセンセーショナルに報じられている部分がありますが、仮に現在の OGB が解散される事態になったとしてもそれがただちに OpenSolaris の死を意味するものにはならないということを皆さんには知ってもらいたいと思います。

もちろん今後 OpenSolaris がどういった方向性を持つのか、外部開発者やコミュニティ、ディストリビューションがどうなるのかなどといった、見えない部分が非常に大きくユーザのみなさんの心配のネタがつきないのは OpenSolaris にかかわる身として心苦しい部分が大きいのですが、そういった状況だということをお酌みいただければと思います。

一言で状況を言い表すとするならば、現在は「OpenSolaris 幕末期」だといえるのではないでしょうか。

2010年5月24日月曜日

OSC2010 仙台に参加してまいりました

杜の都仙台に OSC がやってまいりました。OSC 的に仙台は私のホームでありますので、Tokyo OpenSolaris User Group 名義で先週の土曜日(2010/05/22) にオープンソース・カンファレンス 2010 in 仙台に参加してきました。セミナー、ブース、LTと大暴れしてしまいましたが、太田さんのサポートでなんとかこなすことができました。太田さん、ありがとうございました!!

せっかくフル参加したわけですから、UST 中継録画やプレゼン資料などをまとめておきたいと思います。

セミナー「OpenSolaris の新機能とトピックス」 ( → サポートページ )

Ustream 中継録画

プレゼンテーション

OSC2010 Sendai - OpenSolaris Seminar 「OpenSolarisの新機能とトピックス」

ライトニングトーク

Youtube 動画

プレゼンテーション

OSC2010 Sendai - Tokyo OpenSolaris User Group Lightning Talk 「地方在住でOSS活動をするには」

当日の模様(写真)

2010年3月2日火曜日

デブサミ 2010 そして OSC 2010 Tokyo/Spring に参加してきました

OpenSolaris のコミュニティでは、なぜか山形県在住なのに Tokyo OpenSolaris User Group の Leader の1人となっている私ですが、デブサミ2010 そして OSC 2010 Tokyo/Spring に参加してきました。デブサミ2010 のほうは特にコミュニティの代表ということで、OpenSolaris のブース入りし、ライトニングトークでもちょっと喋らさせていただきました。

また、OSC 2010 Tokyo/Spring では関係者というよりも普通の参加者としてお忍び(?)で参加してさとうさんを驚かせるというネタを仕込んだのですが、一通りネタを披露した後は OpenSolaris のブースでご紹介とOpenSolaris 2009.06 の CD 配布などを手伝わせていただきました。OSC 2010 Tokyo/Spring では、ライトニングトークだけではなく、新機能の説明セッションも開催されましたが、また例によってライトニングトークの模様をYoutube にアップロードいたしました。

この2つのイベント、IT系のイベントという共通項はありますが、雰囲気の異なるイベントでして、重厚(?)な雰囲気のデブサミに対して学園祭に近い賑やかさが魅力のOSCとそれぞれ異なった魅力がそれぞれのイベントにあったと思います。

一連のイベントで印象深かったのは、デブサミのほうに参加された、すくすくスクラムさんやDevLOVEさんのような現場改善をめざすグループの和気藹々ぶりが光ってたことです。どうしてもITなお仕事はバグ取りとか障害対応とか心が後ろ向きになりがちなイベントが多いのですが、コンピュータを作ってモノを作ることそのものの楽しさや意義を再確認させられました。

また OSC 懇親会でお話した @nanbuwks さん提唱の #hydrastyle が非常にクールで感動しました。そうだよ小池スタイルなんてヌルい、ヌルすぎだぜ。小池スタイルが登場してから漠然と持っていたモヤモヤを解消してくれたということでこれは個人的にツボでした。

OpenSolaris のコミュニティーという看板のようなものを掲げて遠征してきましたが、こういったイベントに出てくる方々はみなすばらしい人ばかりで色々な刺激を受けて帰ってきました。ひたすら hack にいそしむのも悪くはないのですが、こういったイベントに参加するというのも有意義なことなのかもしれません。

2010年2月23日火曜日

twitter 発(?)の IPS mirror ツール

ブログではご無沙汰になってしまいましたが、みなさんいかがお過ごしでしょうか。私は相変わらず OpenSolaris 使い込んでいます。

OpenSolaris では IPS というパッケージ管理システムが導入されて、このシステム経由でパッケージやシステム全体のアップデートを行うのですが、この IPS サーバは実はpythonでwebアプリとして書かれています。普通に使っている分にはあまり気にならないのですが、バリバリ開発していると手元にこの IPS レポジトリのミラーが欲しくなります。

IPS レポジトリについては根こそぎミラーする術は公式には用意されていないのですが、IPSサーバは OpenSolaris に組み込まれているので、配布されているものをうまく準備できればミラーを作ることが可能です。ミラーを作る術についてはこれまでにもいくつかのスクリプトが作られており、中でも Andrzej Szezo さんの ips-mirror.py スクリプトが有名です。

このスクリプトを使うと一応ミラーを作ることは可能なのですが、IPS サーバ側の事情なのかたまにファイルの一部が欠落してしまったり、そもそもダウンロードするファイルの数が膨大(リリース1つx86/sparc両方ダウンロードで大体 350,000ファイル程度)だったりと、なかなか大変な仕事だったりします。

折しもさとうさんがtwitterでこの辺のことをボヤいていたこともあり、ips-mirror.py を改造してみたら、まるで「ぶっこぬきツール」なものができて関係筋に受けてしまったので、fork という形で ipsget.py ということで公開してみました。

ipsget.py についてはさとうさんがイカす記事を書かれていたので、使い方の説明はそちらに任せて、ちょっとしたポイントを紹介したいと思います。

この IPS ではファイル名を自分自身の sha1sum 値にしてさらに gzip 圧縮しているのですが、ダウンロードしたファイルを検証するために sha1sum を調べる機構が必要になります。この機構、python 2.5 以降では hashlib モジュール、 python 2.4 までは sha モジュールでそれぞれ提供されています。さらに Solaris 10 では python 2.4 のみということなので、普通に考えれば hashlib バージョンと sha バージョンを用意しなければならないということになりますが、それではちょっと残念だったりします。

じゃあどうしようかということで、苦肉の策で書いてみたのがこんな感じです。

try:
       from hashlib import sha1
except ImportError:
       from sha import new as sha1

       (途中略)

       hash = sha1(gzip.GzipFile(fileobj=sf).read()).hexdigest()

なんか微妙な技を使ってしまった気がしますが、そんなこんなで OpenSolaris と Solaris 10 の両方でなんとか動くものができました。ということで、IPSをバリバリミラーしたいという方で気が向いた方がおられましたら ipsget.py おためしください。

登録: 投稿 (Atom)