この本は、達人プログラマーという本があったが、その本のコンセプトに近い、プログラマーが幸せに生きるためのヒントが合計 53 の項目に書かれてまとめられている本です。

個人的にぐっときた項目を紹介したいと思います。

5. 自分の知性に投資しよう (Invest in Your Intelligence)

自分がこれから学ぶべきテクノロジーをどうやって選択するのか、そのヒントが書かれています。これから主流になりそうなテクノロジーを学ぶことが重要だけれど、そうでなくあえて主流でないテクノロジーを学ぶことで自分自身を高めることができるという発想は個人的にはなかった。もちろんその主流でないテクノロジーの達人になるのではなく、他のプログラミン言語との特徴や違いをつかむことが重要とのこと。

個人的には、まったく関数型言語を使ったことがないので、これから挑戦してみようと思います。

15 一に練習、二に練習 (Practice, Practice, Practice)

本番で練習するという考え方はもう捨てること。自分の技術にちゃんと時間を投資して練習し続けることの大切が書かれています。たくさん練習することで、自分の技術は磨かれる。当たり前と言ってしまうと、確かにそうですが、なかなか実務に忙しいときは練習量が減ってしまうことも多々あるかと思います。なので、練習するという意識はもち続けることが大切なのだと思います。

28. 8時間燃焼 (Eight-Hour burn)

毎日、職場についたら8時間！やって、やって、やるしかない！という気持ちで業務に取りかかって、終了の時刻を自分に厳しく課して生産性を向上あげようというもの。けっこう僕の場合、最初はだらだらしがちになってしまうことが多いので、この8時間燃焼という考え方は実践してみたいと思います。

午前4時間、お昼休憩1時間、午後4時間、そのサイクルでくたくたになるまで集中して取り組む。もちろん、Twitter やメッセなどは全部切って集中する。終わったら、帰宅してくつろいで好きなことをする。

そして、最後の項目。

53 独立する (Go Independent)

個人的に今年の４月からフリーランスとしての独立をしてしまったので、感情深いエッセイとして読んでしまった。僕も、この項目に書かれている内容を決意して独立をしました。何事も分かりやすいのが、一番なので。

この他にも、53の項目以外にも、コラムがあってその中には GitHub の誕生秘話などもあって、かなり面白いのでプログラマー・エンジニアの方は読んでみるのをおすすめします。

環境は、次のとおりです。

• OS: CentOS 5.x x86_64
• ロードバランサー: LVS + keepalived
• ウェブサーバ: Apache + Passenger + Rails

サービスをメンテナンス状態にしたいとき、次の方法が考えらます。

1. ロードバランサー側の iptables を使って、ロードバランサー側でメンテナンス表示画面を返す
2. ウェブサーバ側で、メンテナンス表示画面を返す

1 だと、メンテナンスへの切り替えが面倒なので、僕は 2 の方法で行っています。

ウェブサーバ側で、次のようなルールを記述しておきます。

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteCond %{SCRIPT_FILENAME} !maintenance.html
RewriteRule ^(.*)$ /$1 [R=503,L]

DocumentRoot 以下に maintenance.html というファイルがあるとき、そのファイルを返すというシンプルなルールです。

メンテナンス表示に切り替えるには、maintenance.html を置くだけなので、プログラムのデプロイにも使っている capistrano の ::deploy::web の disable / enable を、次のように定義します。

namespace :web do
task :disable do
on_rollback {
run “rm #{current_path}/public/maintenance.html”
}

run “cp #{current_path}/templates/maintenance.html #{current_path}/public/”
end

task :enable do
run “rm #{current_path}/public/maintenance.html”
end
end

あとは、このタスクを使って、次のコマンド一発でメンテナンスへの切り替えをすることができます。

$ cap deploy:web:disable

メンテナンス状態を解除する場合には、次のコマンド一発です。

$ cap deploy:web:enable

また、メンテナンス表示のとき、画像を返さないといけない場合は、mod_asis を使って、次ようなルールを定義しています。

AddHandler send-as-is asis

RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}/maintenance.html -f
RewriteRule ^(.*)$ /images/transparent.gif.asis [NC,L]

transparent.gif.asis は、1×1 の白い、次のヘッダーがついた gif です。

Status: 200 OK
Content-Type: image/gif
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Pragma: no-store
Cache-Control: no-store

その理由は、次のとおりです。

• 最近のサーバには、かなりの大量のメモリが搭載できる
• CPU の処理速度もマルチコア化がかなり進んでいて上がっている
• 仮想化技術が当たり前のようになっていてサーバのリソースをまんべんなく使えるようになっている
• 最初のボトルネックになりがちだったディスクも SSD や Fusion I/O を搭載できる
• ラックの最大許容電力の問題

具体的な例をあげてみましょう。いつもこのブログでは DELL サーバを例にとっているので、今回は HP のサーバを例にとってみます。

例えば、HP の ProLiant DL360 G7 では、最大次のような仕様になっています。

• サイズ: 1U
• CPU: Xeon 5500/5600番台 x 2
• Memory: 192GB (DDR3、18 スロット)
• Disk: 2.5 SAS/SATA x 8
• NIC: 4ポート
• PCI Express: 2 スロット

このサーバを、次のスペックで見積もってみると、約67万円くらいでした。

• CPU: Xeon L5520 x 2
• Memory: 48GB
• Disk: 120GB 2.5 inch x 2

いっけん高いようにみえますが、比較するべきは、次のようなスペックのマシンを２台購入したときとのコストの比較になると思います。

• CPU: Xeon L5520 x 1
• Memory: 24GB
• Disk: 120GB 2.5inch x 1

もちろん、マシンは機械である以上故障はするので、故障のリスクも考えないといけませんが、できる限りマシンは減らした方がサーバの運営管理コストは下がるので、量と質の問題を考えなければいけません。

さらに、4U の ProLiant GL580 G7 というサーバには、メモリをなんと最大 1TB まで搭載できます。コストは相当なかかると思いますが、コストはイニシャルコストとランニングコストのバランスの問題になってくるはずです。

すこし前までは、メモリが足りない、ディスクが遅い、などの理由で、多数の 1U サーバを並べる傾向が強かったような気がしています。

さらにクラウドでも、同じような傾向があります。クラウド大手の Amazon EC2 をみてみると、High Memory Instance として次の 3 種類が提供されています。

• High-Memory Extra Large Instance 17.1 GB memory, 6.5 ECU (2 virtual cores with 3.25 EC2 Compute Units each), 420 GB of local instance storage, 64-bit platform
• High-Memory Double Extra Large Instance 34.2 GB of memory, 13 EC2 Compute Units (4 virtual cores with 3.25 EC2 Compute Units each), 850 GB of local instance storage, 64-bit platform
• High-Memory Quadruple Extra Large Instance 68.4 GB of memory, 26 EC2 Compute Units (8 virtual cores with 3.25 EC2 Compute Units each), 1690 GB of local instance storage, 64-bit platform

Quadruple Extra Large を選択すると、なんと 68.4GB メモリが搭載されています。

価格は、現時点で次のとおりです。(US – N.California, Linux の場合)

• Extra Large: $0.57 per hour
• Double Extra Large: $1.34 per hour
• Quadruple Extra Large: $2.68 per hour

Extra Large と Quadruple Extra Large の価格差は約 4.7 倍程度で、おおよそ実際のスペックと同じ比率になっています（若干すこし高めの設定ですが）。

この価格なら、例えば Extra Large を 5 台並べるか、Quadruple Extra Large を 1 台にするか、どちらがいいのか考える必要があるでしょう。

もちろん、サーバが少ないときのデメリットも、サーバが１台ダウンしたときの影響が大きいが考えられます。

すこし前まではサーバの多く並べる傾向が強かったと思います。

ただ、これからの時代はどちらかというと、サーバをたくさん並べるよりも、処理能力の高いサーバを少なく並べる傾向が強くなってくると思います。

つまり、僕はできる限り多くの同時リクエストを１台のサーバでさばく、そんな時代になってくると思うので、その流れにあった技術を身につけるのが重要になるのではないかと思います。

このとき OS を再起動して、BIOS から変更すれば IPMI の IP アドレスを変更することが可能ですが、データセンターの現地にいって一台ずつ再起動するのが面倒です。

Linux 上からだと、IPMI のサービスを起動することによって、IPMI の IP アドレスを変更することができます。仮想化をしている場合には、物理サーバ上から変更することができます。

まず、IPMI のサービス、imptool をインストールします。

$ sudo yum install OpenIPMI ipmitool

次に IPMI のサービスを起動します。

$ sudo service ipmi start

Starting ipmi drivers:                                     [  OK  ]

IPMI サービスを起動すると、ipmi のデバイスが見えます。

$ dmesg | grep ipmi

ipmi message handler version 39.1
ipmi_si: Trying SMBIOS-specified kcs state machine at i/o address 0xca2, slave address 0×0, irq 0
ipmi: Found new BMC (man_id: 0x00XXXX,  prod_id: 0xXXXX, dev_id: 0xXX)
ipmi device interface

この状態で、ipmitool を使って IP アドレスとサブネットマスクを変更します。

$ sudo ipmitool lan set 1 ipaddr X.X.X.X

$ sudo ipmitool lan set 1 netmask 255.255.0.0

この変更にはすこし時間がかかることもあるので、プロンプトが返ってくるまで待ちます。

変更したら、正しく変更されているか確認します。

$   ipmitool -I lanplus -H X.X.X.X -U ＜ユーザ名＞ -P ＜パスワード＞ lan print

IPMI の IP アドレスなどの変更ツールは、IA サーバのメーカー製のツールがあってそのツールからも変更できますが、ipmitool を使うことによって同じ方法で変更できるので便利です。

Puppet Labs に、そのときの動画をスライドがすべて公開されています。

動画はあとでチェックすることにして、スライドだけチェックしてみました。講演のタイトルは、次のとおりです。

• Portable infrastructure with Puppet – Luke Kanies (Slides|Video)
• Embedded Puppet – Alban Peignier (Slides|Video)
• Deploying datacenters with Puppet – A user’s perspective – Rafael Brito (Slides|Video)
• Puppet modules and module standards – Alessandro Franceschi (Slides|Video)
• Auditing change management policies with Puppet and Splunk – Jeff McCune (Slides|Video)
• Puppet in complex, real-time environments – Rick van der Zwet (Video)

まずは、Puppet の中心人物である Luke さんの発表。この発表では、おもに Puppet の現在の状況と、これからの展望について発表がありました。以下、メモです。

• Puppet は、安定している（現在のリリースバージョンは、0.25.5）
• Puppet は、さまざまな面で日々高速に進化している
• Puppet は、さまざまな分野で使われている（Google、DELL、Disney、J.P.Morgan など）
• Puppet キャンプ 2009 では、次のことを約束した

バージョン 1.0 のリリース … 1.0 / 2.0 はスキップして、現在 2.6 で開発中で、いくつか大きな機能を盛り込んでいる、Pure Ruby DSL(*1)、クラスパラメータ(*2)、REST への移行がすべて完了する、puppet のプログラム一つに移行する（例えば、puppetmastered -> puppet master となる）、レポートにさらに詳細な情報が含まれるようになる、新しい関連を示すシンタックスが追加される(*3)、ハッシュ(*4)

Web GUI アプリケーション … Puppet Dashboard としてリリースした

モジュール … モジュールを共有できる場所として Puppet Forge をリリースした

(*1) Pure Ruby DSL

Puppet 2.6 では、Ruby で DSL として、次のような感じで記述することができる。ついにこの機能が登場しそうです。Ruby で記述できれば、特殊な Puppet DSL を学習することができなくて済みますね（大きな概念は変わらないと思いますが）。おそらく、これはユーザの声をきいた結果だと個人的に思います。

hostclass “foo” do

package :foo, :ensure => :present

service :foo, :ensure => :running

end

node “hoge.example.com” do

acquire “ssh”

end

(*2) クラスにパラメータを与えることができる

class foo($hoge = “bar”) {

…

}

class { foo: hoge => “bar” }

(*3) 次のようなシンタックスが追加される、個人的にはちょっと複雑な文法なので使いこなせなさそうです

notify { b: } -> notify { a: } -> notify { c: }

Notify[b] ~> Notify[a] ~-> Notify[c]

(*4) ハッシュ、Ruby のハッシュっぽく記述することができる、これは重宝しそうです

class foo {

$data = {}

$data[one] = 1

$data[one] = 2

file { “/tmp/hoge”: content => template(“foo/tmp/hoge”), }

Puppet Forge については、改めて別の機会に紹介したいと思います。

次の話は、Puppet を組み込む方法について。これは省略します。

その次の話は、Puppet を使って複数のデータセンターを構築する方法の話。OS は、RHEL でしたが、その中で kickstart の pre セクションで、MAC アドレスを登録する次のスクリプトは、なるほどと思いました。

%pre
SERVER=`grep ‘url address’ /tmp/anaconda.log | awk ‘{print $6}’`
cd /tmp && wget -q http://${SERVER}/pub/dmidecode
chmod +x /tmp/dmidecode
SN=`dmidecode | grep “Serial Number” | head -1 | awk ‘{print $3}’`
MAC=`ifconfig | grep HWaddr | awk ‘{print $5}’`
wget -q http://${SERVER}/cgi-bin/register.pl?mac=$MAC\&sn=$SN
reboot

上のスクリプトでは、MAC アドレスと dmidecode をしたマシンのシリアル番号を register.pl へ送っています。

僕は、いままでマシンの BIOS などで MAC アドレスを確認していましたが、この方法を応用すれば自動化できる可能性が出てきました、さっそく挑戦してみたいと思います！

その次の話では、Puppet モジュールの標準的な書き方について、いくつか参考になる話があったのでまとめておきます。

include するときのポイント。次のように使い分けると分かりやすい。

• include postfix – Postfix サービスをインストールして実行する
• include postfix::disable – Postfix をインストールするがサービスは実行しない
• include samba::server – Samba サーバをインストールする
• include samba::client – Samba クライアントをインストールする

import と include の違いは、Puppet の中で重要なので押さえておきたいところです。次のような違いがあります。

• import autofs – $modulepath/autofs/manifests/init.pp を読み込む
• include autofs::server – $modulepath/autofs/manifests/server.pp を読み込む

puppetdoc コマンドを使うと、コメントが含まれているマニフェストからドキュメントを生成することができる。例えば、次のようなマニフェストを書く。

# Class: apache
#
# このモジュールは Apache を管理します
#
# Parameters:
#
# Actions:
#
# Requires:
#
# Sample Usage:
#
# [注意: コメントとクラス定義の間には空行を入れないこと]
class apache {
	...
}

最後の二つの講演は、特に参考になる情報はありませんでしたが、Puppet キャンプ楽しそうです！

とても分かりやすく「独自/ミラー yum リポジトリ」を作る方法がまとまっている素晴らしいエントリです。

アシアルさんのブログでは、rsync や createrepo などを手動で使っていますが、これを cobbler というツールを使うともっと簡単に「独自/ミラー yum リポジトリ」を作成することができます。

まず、CentOS 5.x のミラーを作成する方法を紹介します。

EPEL を設定してから、cobbler をインストールします。

$ sudo yum install cobbler

CentOS ミラーサイト一覧から、自分がいる国にいる近いサイトの rsync 可能なミラーサイトを選びます。ミラーサイトを選んだら、次のコマンドでミラーします。

$ sudo cobbler import –path=rsync://your_centos_mirror_site/centos –name=centos –arch=x86_64

rsync し終わったら、httpd を起動してから、/etc/yum.repos.d に次のような yum リポジトリを追加します。

cobbler をインストールすると、自動的に必要な yum リポジトリの公開設定が /etc/httpd/conf.d/cobbler.conf にされています。

[centos]
name=centos
baseurl=http://localhost/cobbler/repo_mirror/centos
enabled=1
gpgcheck=0
priority=1

ミラーを更新したい場合は、次のような cron を root ユーザの cron で設定します。

/usr/bin/cobbler reposync –tries=3 –no-fail > /dev/null 2>&1

独自の yum リポジトリを作成した場合は、RPM が入っているディレクトリ (例えば /home/naoya/rpms) を用意して、次のコマンドを実行するだけです。

$ sudo cobbler repo add –name=”local” –mirror=”/home/naoya/rpms”

独自の yum リポジトリを更新する場合も、上の cobbler reposync コマンド一発で同期させることができます。

独自の yum リポジトリの設定は、次のようなになります。

[local]
name=local
baseurl=http://localhost/cobbler/repo_mirror/local
enabled=1
gpgcheck=0
priority=1

いかがでしょうか？

cobbler を使うと、とても簡単に yum リポジトリを構築することができます。

ぜひ、試してみてください！

まず、kumofs には、次のものが必要です（以下の情報は公式ドキュメントを参照しました）。

• linux >= 2.6.18
• g++ >= 4.1
• ruby >= 1.8.6
• Tokyo Cabinet >= 1.4.10
• MessagePack for C++ >= 0.3.1
• MessagePack for Ruby >= 0.3.1
• libcrypto (openssl)
• zlib

Linux と g++ と libcrypto と zlib は、CentOS 5.5 x86_64 の標準パッケージに含まれているので標準パッケージをインストールすれば問題ありません。

Ruby は、以前紹介した方法で作成したバージョン 1.8.7 系を RPM でインストールします。

TokyoCabinet は、自分で作成した SPEC ファイルから RPM を作成しました。

MessagePack for C++ も、自分で作成した SPEC ファイルから RPM を作成しました。

MessagePack for Ruby は、RPM を作成してもいいですが gem コマンド一発でインストールすることができるので RPM は作成しませんでした。次のコマンドでインストールします。

$ sudo gem install msgpack

肝心の kumofs ですが、kumofs は分散環境下で使われていることを前提しているので、kumo-manager、kumo-server、kumo-gateway、は別々のサーバであることが普通の環境だと思います。

そこで、kumofs というコアのプログラムが含まれている RPM、manager、server、gateway、をそれぞれ別々の RPM として作成してみました。あわせて、manager、server、gateway、それぞれの redhat 系の起動スクリプト、設定ファイル、logrotate スクリプト、daemontools 用のサンプルスクリプト、を作成して RPM に同梱しました。これからのスクリプトは、まとめて github に置きました。また、作成した RPM も github に置きました（バージョンが少し古いので注意してください）。

sysinit のスクリプトを使うと、kumofs の実行ユーザが root にになります。通常ユーザで実行したい場合は、daemontools などを使うといいと思います。daemontools 用のサンプルスクリプトは、github においてある kumofs-XXX-run.sample と kumofs-XXX-log-run.sample です。daemontools を使う場合は、logrotate のスクリプトを削除するのを忘れないでください。

kumo-gateway のプログラムにも libtokyocabinet がリンクされているのはちょっと気になるところですが、特に弊害はないので気にしないことにします。

ここで作成した RPM で、それぞれのインストール方法を説明します。

まず、manager から、manager にはコアの RPM もインストールします。manager の設定は、/etc/sysconfig/kumo-manager を編集します。daemontools 用のスクリプトも同じ設定ファイルを読み込んでいます。

$ sudo yum install kumofs kumofs-manager

次に server。設定ファイルは、/etc/sysconfig/kumo-server です。

$ sudo yum install kumofs-server

そして、gateway。設定ファイルは、/etc/sysconfig/kumo-gateway です。

$ sudo yum install kumofs-gateway

server と gateway には、kumoctl などの管理系のコマンドはインストールされないので注意してください。server と gateway にはそれぞれに必要な最低限のプログラムをインストールしています。kumofs の管理系のコマンドを使う場合は、manager のサーバ上から使います。

また、kumofs とは関係ありませんが、個人的には rpmforge を本番環境のサーバでは使わない方がいいと思います。過去に、rpmforge を使っていてパッケージまわりでトラブったことがあります。自分で RPM を作成する手間を削減できるので EPEL の方はちゃんとしているので使うのをおすすめします。

今回作成した kumofs の RPM も、EPEL に入れることができるのか提案してみる予定です。

今回の RPM を作るにあたって、次のページを参考にしました。貴重な情報ありがとうございました！

• eugene-k.net » Blog Archive » CentOS 5.4用のkumofsのrpmをビルドする(改訂版)
• ほぼまっさらなCentOS5.4にkumofsをインストール – DenkiYagi

（おまけ）

OSX を使っている人向けに MacPorts でも kumofs をインストールすることができます。

$ sudo port selfupdate

$ sudo port install kumofs

$ sudo port info kumofs
kumofs @0.4.7 (net)
Variants:             universal

Description:          kumofs is a scalable and highly available distributed
key-value store. You can use a memcached client library to
set, get, CAS or delete values from/into kumofs. Backend
storage is Tokyo Cabinet and it will give you great
performance.
Homepage:            http://kumofs.sourceforge.net/

Library Dependencies: msgpack, rb-msgpack, tokyocabinet, openssl, zlib
Platforms:              darwin
License:                  unknown
Maintainers:          < my email address >

しかし、新しい世代の MacBook Pro になってから、OSX のバージョンアップの影響からなのか、昨年紹介した方法が使えなくなってしまいました。

ずっと不便だなと思っていたのですが、今日偶然こんな映像「Set Up External Monitor/TV to Macbook Pro – Video」を見つけました。この映像によると、次の手順で外付けディスプレイのみを使うことができるようです。

1. MacBook Pro の LCD を閉じる
2. スリープ状態になるまで待つ
3. 適当な外付けキーボードを接続する
4. MacBook Pro と外部ディスプレイを接続する
5. 外付けキーボードから、スペースキーを押して復帰させる

この方法をとると、MacBook Pro LCD の解像度ではなく、外付けディスプレイの解像度として切り替えることができるようです。

なるほどと思って、僕もさっそく試してみると上の方法で確かにできました！

ただ、毎回外付けキーボードを接続するのは面倒くさいです。無線 LAN 経由で、スリープ状態から起こすことができるか調べてみるとなんとできるではありませんか！（参考：無線LAN経由で眠っているMacBookを起こす方法 – ザリガニが見ていた…。）

ということで、次の方法で MacBook Pro を外付けディスプレイのみで使うことに成功しました。これで、大きいディスプレイがある環境では、マルチディスプレイにするより作業効率が上がります。

1. MacBook Pro を、同一ネットワーク上からインターネットに接続する
2. 別のホストコンピュータから、WakeOnLan などのソフトウェアを起動して MacBook Pro を認識させておく
3. MacBook Pro の LCD を閉じて、スリープ状態にする
4. 外付けディスプレイに接続する
5. 手順 2 の WakeOnLan などのソフトウェアから、対象の MacBook Pro を起こす
6. 対象の MacBook Pro が起きると、外付けディスプレイのみに出力先が切り替わる

あとは、teleport や Synergy なりで、ホストコンピュータから MacBook Pro を操作することができます。

これで、個人的には自宅や出先での作業効率がいくぶんか上がるはずです。

# 2010/06/10: 追記

@htaira さんから、すばらしいアドバイスをいただきました。なんと、次の方法でもできました！

1. MacBook Pro LCD を閉じる
2. 外部ディスプレイを接続する
3. MacBook Pro がスリープ状態になったら、素早く LCD を開いて、すぐに閉じる

これなら、簡単ですね！

RVM を使うと、簡単に Ruby のバージョンを使い分けることができます。

インストールは、いたってシンプルで gem からインストールします。

$ sudo gem install rvm

rvm をインストールしたら、rvm-install コマンドでホームディレクトリにインストールします。

$ rvm-install

すると、$HOME/.rvm というディレクトリが作れらます。

次に、.zshrc などに、次の設定を追加して反映させます。反映されると、rvm というコマンドが使えるようになります。

if [[ -s /Users/n0ts/.rvm/scripts/rvm ]] ; then source /Users/n0ts/.rvm/scripts/rvm ; fi

あとは、ここに使いたい Ruby をインストールするだけです。RVM で対応している Ruby 一覧を見るには、次のコマンドを実行します。

$ rvm list known

…

(ruby-)1.8.6(-p399)
(ruby-)1.8.6-head
(ruby-)1.8.7(-p249)
(ruby-)1.8.7-head
(ruby-)1.9.1(-p243)
(ruby-)1.9.1(-p376)
(ruby-)1.9.1-head
(ruby-)1.9.2-preview1

…

REE や JRuby や IronRuby などにも対応しています。

さっそく複数の Ruby をインストールしてみましょう。

最初に、Ruby バージョン 1.8.7 をインストールします。

$ rvm install 1.8.7

Ruby をコンパイルしてインストールするので、対象時間がかかります。

次に、Ruby バージョン 1.9.1 をインストールします。

$ rvm install 1.9.1

そして、肝心の Ruby を切り替える方法ですが、バージョン 1.8.7 に切り替えたいときは、次のコマンドを実行します。

$ rvm use 1.8.7
Using ruby 1.8.7 p249

$ ruby –version
ruby 1.8.7 (2010-01-10 patchlevel 249) [i686-darwin10.3.0]

$ which ruby
/Users/naoya/.rvm/rubies/ruby-1.8.7-p249/bin/ruby

仕組みは単純で PATH 環境変数を書き換えているだけです。

次にバージョンを 1.9.1 に切り替えてみます。

$ rvm use 1.9.1
Using ruby 1.9.1 p378

$ ruby –version
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.3.0]

$ which ruby
/Users/n0ts/.rvm/rubies/ruby-1.9.1-p378/bin/ruby

ちゃんと切り替わっていますね。

また、RVM でインストールした Ruby に対して一括実行することもできます。

$ rvm ruby -v
ruby-1.9.1-p378: ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.3.0]
ruby 1.9.1p378 (2010-01-10 revision 26273) [i386-darwin10.3.0]

$ rvm gem install rails

まとめて Rails をインストールすることができます。

Passenger も同様にインストールできますが、Passenger の Apache / Nginx モジュールを作成するときには、次のようにします。

$ rvm install
$ rvm 1.8.7 –passenger
$ rvm 1.8.7
$ gem install passenger
Building native extensions. This could take a while…
…
$ rvmsudo passenger-install-nginx-module
…
Phusion Passenger is a trademark of Hongli Lai & Ninh Bui.

あとは、PassengerRoot を、/Users/naoya/.rvm/gems/ruby-1.8.7-p249/gems/passenger-2.2.11/ に設定します。Ruby バージョン 1.9.0 のときも同様の方法でインストールすることができます。

RVM を使うと、手軽に Ruby を切り替えることができるので、便利です。

まず、Fedora になる Ruby 1.8.6 の RPM をダウンロードします。

$ wget http://ftp.jaist.ac.jp/pub/Linux/Fedora/development/source/SRPMS/ruby-1.8.6.399-1.fc14.src.rpm

SRPM をインストールします、なぜか MD5 があわないので無視します。

$ rpm -i –nomd5 ruby-1.8.6.399-1.fc14.src.rpm

ruby.spec ファイルを書き換えます、現時点での Ruby バージョン 1.8.7 のパッチレベルは 249 なので、ダウンロードします。

$ cd rpmbuild/SOURCES

$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p249.tar.bz2

次に ruby.spec ファイルを、修正します。基本的に適応できないパッチをあてないのと、x86_64 の場合は lib ディレクトリのパスが変わるので変更します。lib ディレクトリのパスは、i386 でも問題がないように %{_lib} を利用しました。

ruby.spec ファイルの差分は、次のような感じです。

あとは、rpmbuild するだけですが、依存しているパッケージがけっこう多いので拙作の auto-rpmbuild.sh を使うと便利です。

$ auto-rpmbuild.sh -ba ~/rpmbuild/SPECS/ruby.spec

最後に、既存の Ruby を上書きしてアップグレード完了です。

$ sudo rpm -Uvh rpmbuild/RPMS/x86_64/ruby-*

$ ruby –version

ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]

上書きしたあと、なぜか ruby-libs の古いバージョンが残っているので念のため削除しておきました。

$ sudo rpm -e ruby-libs-1.8.5-5.el5_4.8

作成した Ruby の RPM は、github へアップロードしておきました（ついでに Rubygems バージョン 1.3.7 の RPM を作ってアップロードしておきました）。

今回の RPM の作り方は、次のページを参考にしました。

• Haru’s blog: CentOS でRuby 1.8.7のrpmを作る

# CentOS は、パッケージが枯れすぎていてパッケージを作るのがとてもとても面倒だけれど、安定して動いてくれているので重宝しています。

例えば、CentOS の Subversion は 1.4.2 で試してみます。

まずは、通常の全体バックアップを行います。

$ svndump /var/svn/repository > svn_repository.dump

全体バックアップをとる直前のリビジョンを svn info file:///var/svn/repository で保存しておきます。

あとは、次の日などに前にリビジョンに +1 してリビジョンから、HEAD まで dump することで差分バックアップをすることができます。次の例は、前日がリビジョン 1 までのバックアップだと想定しています。

$ svnadmin dump –incremental -r 2:HEAD

前にとある開発サーバで、SVN リポジトリのバックアップを毎朝全体で行っていましたが、バックアップ量が多すぎてハードディスクがパンクしたことが何度がありました。差分バックアップを使えば、バックアップ量も少なくて済むので便利だと思います。

SNI は、とても簡単に設定することができます。以下、設定方法をまとめておきます。

• mod_ssl をインストールしたときにインストールされる SSL の設定ファイルは読み込まない
• あとは、通常の SSL の設定と VirtualHost の設定をする

まずは、443 ポートを Listen する設定などを行います。

Listen 443
SSLStrictSNIVHostCheck off

あとは、VirtualHost を定義するだけです。

<VirtualHost *>
ServerName hoge.example.com
DocumentRoot /var/www/html/hoge
</VirtualHost>
<VirtualHost *:443>
ServerName hoge.example.com
DocumentRoot /var/www/html/hoge
SSLEngine On
SSLCertificateFile /etc/httpd/conf/server.crt
SSLCertificateKeyFile /etc/httpd/conf/server.key
<VirtualHost>

上のような VirtualHost を定義しておけば、一つの IP アドレスで複数の SSL 対応のウェブサイトを設定することができます、もちろん証明書も切り替えて。

ちなみに、Apache バージョン 2.2.11 以前は、次のような 80 ポートと 443 ポートの組み合わせの VirtualHost ができていますが、2.2.12 以降はできなくなっていますので注意しましょう。

<VirtualHost * *:443>
ServerName hoge.example.com
</VirtualHost>

参考資料

• Apacheの設定を変更し、単一IPアドレス上で複数のSSLサイトを運用する – builder by ZDNet Japan

2009年5月18日の認証局変更により、中間 CA 証明書を更新する必要があるので、2009年5月18日以降で日本ベリサインから SSL 証明書を取得した人は注意しましょう。Firefox 3.x 系だけで発生する問題なので、気がつかない可能性があります。
更新された中間 CA 証明書は、次のページに公開されています。

• 2009年5月18日の認証局変更

ちょっと自分で直してみようかなと考えてみましたが、OSX プログラミングは経験がないので github にあるかもと思って検索してみると、修正されている MacFusion2 がありました。MacFusion2 の Dowload から「Macfusion-2.0.4-SL.zip」というファイルをダウンロードして上書きインストールするだけで問題なく動作します。github 素晴らしすぎります。感覚的に github は、Google からの検索にヒットしないことがある印象をうけるので、github のサイトから検索した方が便利です。今回の該当のコミット内容は、ここから確認することができます。

また、Amazon S3 にも対応した商用版の ExpandDrive というソフトウェアもあります。価格は、$39.95。ExpandDrive は試用することができますが、最新版の 2.0.6 で 10.6.3 上で正しく動作していました。ExpandDrive の方は、メニューバーからアクセスすることができるので便利な印象をうけました。

振り返ってみれば、約３年半ちょっととこのウェブ業界ではかなり長いかもしれませんが、初めてウェブ業界に入って特にインフラまわりの仕事を中心に行っていました。その業務の中で、公開できる情報に関しては、このブログで一生懸命アウトプットを行ってきました。

僕がどうしていわゆるインフラエンジニアになったのかについては、過去のエントリを参考にしてください。

過去をあまり振り返えると、話が長くなりそうなので、まずは素晴らしい会社に最高のタイミングで入社できたと思っています。そこで、かなり個性的で優秀なエンジニアと出会い、一緒に仕事をできたことは最高に幸せでした。この素晴らしい会社を起業してくれた社長には感謝をしています。そして、一緒に仕事してくれたエンジニアの皆さん、その他の社員の皆さんには、かなりたくさんの失敗をしてご迷惑をおかけしたと思いますが、感謝をしています。ありがとうございました。あわせて、これかも懲りずに交流していただければとても幸せです。

会社を退職した理由はいくつかありますが、一番大きいのはちょっと一人でやってみたいという気持ちが強くなったことです。絶対成功するとか、起業するときか、そういうことは今のところ考えていませんが、組織に属しているときに見えるもの、組織に属せずに見えるもの、とがあるような気がしています。今ままでずっと、大きな休みはなしに組織にずっと属していたので、そろそろ後者の視点から物事を見てみたい、ちょうどよいタイミングだと思ったことが大きいです。

そして、このブログもかなり多くの人に読まれているようで、最近エントリをするプレッシャーも感じつつありますが、プレッシャー感じてしまうとブログを更新する機会も減ってしまいますので、これからもできる限りインフラ系の話題を中心にエントリをしていきたいと思います。情報をアウトプットすると、自分も勉強になることがかなり多いと思います。

インターネットの歴史は、振り返ってみると約十年ちょっとでしょうか？とても早い動きで動いているインターネット。この世界を支えるのは、無数のコンピュータであり、そのコンピュータを支えるのはインフラエンジニアだと思っています。その上で、地球上のたくさんの人たちが自由にインターネットを使って人生を楽しんでいますし、インフラエンジニア以外にもたくさんのエンジニアの皆さんが毎日インターネット上でさまざまなサービスを開発しています。

最近は、あまりインフラエンジニアという肩書きもいけていないかもしれませんが、これからますます増えるであろうインターネット上の膨大なトラフィックを、いかにして低コストでかつ省力で運用していくていくのか、今の僕の興味はそこにあります。そのために、必要な技術を身につけて、さらに自分である問題を解決するためのものを作っていきたいと思います。

最後に、フリーランスで生きていこうと決心したきっかけになった一つの動画を貼り付けておきます。

Web 2.0 Expo NY: Gary Vaynerchuk (Wine Library), Building Personal Brand Within the Social Media Landscape

これからも、このブログと私をよろしくお願いします。

CentOS の場合、pbzip2 バージョン 1.0.5（最新版は 1.1.0） が EPEL から提供されているので、yum 一発でインストールすることができます。pbzip2 は、SRPM があるので、手軽に最新版も試すこともできます。

$ sudo yum install -y pbzip2

圧縮時間の測定のために 50MB ほどのアクセスログを bzip2 と pbzip2、それぞれで圧縮してみました。

この測定したサーバは、Xeon L5530 で HT 有効のサーバです。

まずは、bzip2 から。

$ time bzip2 -kv –best access_log

6.144:1,  1.302 bits/byte, 83.72% saved, 56862316 in, 9255173 out.
bzip2 -kv –best access_log  16.29s user 0.08s system 99% cpu 16.370 total

次に、pbzip2。

$ pbzip2 -kv -p8 access_log

pbzip2 -kv -p8 access_log  19.31s user 0.15s system 772% cpu 2.521 total

処理時間と比較すると、次のような結果でした。ついでに、16 コアでも試してみました。

• bzip2: 約 16 秒
• pbzip2(-p8): 約 2.5 秒
• pbzip2(-p16): 約 2.1 秒

圧縮後のサイトは、どちらも 8.9MB とほぼ同じでしたが、バイト数は次のような結果でした。

• bzip2: 9,255,173
• pbzip2: 9,262,212

pbzip2 の方は仕組み上、多少圧縮サイズが小さいという結果になりましたが、圧縮時間が大幅に減少しました。圧縮サイズはそれほど変わらないので、複数コアのあるサーバでアクセスログを圧縮する場合は pbzip2 を使っていくことにしました。

なお、解凍は bzip2 形式なので、pbzip2 で圧縮したファイルも bzip2 -dc で解凍することができます（当たり前ですが…）。

ウェブサーバ上の過去のアクセスログは、ディスクを圧迫するためウェブサーバ上で圧縮するのが普通だと思いますが、複数コアの CPU があるサーバなら pbzip2 を使うことで圧縮時間を大幅に短縮できます。短縮できた CPU 時間をウェブサーバ本来の処理にまわすことができるはずなので、ウェブサーバのリソースを有効に扱うことに結びつくと思います。

さらに詳しい pbzip2 のベンチマーク結果は、本家サイトに情報があるので、興味のある人は参考にするといいと思います。

• Mac mini: 家での作業用 PC、音楽を聞いたり、写真を見たり、映画を見たり、個人プロジェクトの開発用
• 小型サーバ: VMWare ESXi で、FreeBSD と CentOS と Windows XP が動いている、FreeBSD はメールサーバや wiki など、CentOS と Windows XP は技術的な実験用

で、音楽や写真データなどは、今までずっとバックアップをとっていなかったけれども、だんだんとデータ容量も増えてきてバックアップをとることにしました。

家庭用 NAS を導入するとものが増えるので躊躇っていたけれども、データが消えたときのことを考えると不安だったので、思い切って家庭用 NAS を導入することにした。Mac mini だけなら、Time Capsule でもよかったけれども FreeBSD にも大切なデータが入っているので、他の家庭用の NAS を検討してみました。具体的には、ハードディスク|HD-HTGL/R5シリーズなどを考えたけれど、かなり大きくて僕が求めているのはもっとコンパクトなものがほしいと思っていました。

そこで、偶然立ち読みした DOS/V POWER REPORT マガジンにThecus Technologyというおもに NAS を開発している会社を知りました。この会社のホームページをみてみると、N2200 という非常にコンパクトな家庭用 NAS を見つけました。N2200 のおもな特徴は、次のとおりです。さらに詳しい特徴は、UAC 株式会社にも情報があります。

• ハードディスク x 2、RAID 0/1、JBOD 対応
• ハードディスクレスのタイプなので、ハードディスクは自由に選択可能
• サポートするハードディスク容量は、2TB x 2 まで対応している
• 内部が Linux なので、SMB、CIFS、HTTP、HTTPS、FTP、NFS V3、AFP 3 をサポート
• ブラウザから、NAS の設定を変更することが可能

購入は、Amazon からもできるけれど、UAC ダイレクトから購入してみました。ハードディスクは、2TB のハードディスクの価格がかなり下がっていたので、WESTERN DIGITAL のものと、HGST のものを一台ずつ購入しました。なんとなく、同じハードディスクだと何かあったときにめんどうなので、わざと別々のメーカーのもにしました。実際に購入してみると、予想どおりかなりコンパクトでいい感じです。

セットアップ方法は、ハードディスクをトレイに接続して、Windows の専用クライアントから IP アドレスやディスクのフォーマットをするだけと、とてもセットアップは簡単でした。IP アドレスさえ設定してしまえば、あとはブラウザから操作できるので、Mac からも操作することができます。ブラウザの管理画面は、次のような感じです。ファームウェアの更新もブラウザからできるので、とても便利です。

実際に使っていた感想は、次のとおりです。

• セットアップが非常に簡単
• RAID1 で使っているけれど、片側のハードディスクをはずしても動き続けて、ハードディスクを再度取り付けると自動ビルドが始まる（ハードディスクがはずれると、かなり大きいビーという音がする）
• とても静か、ハードディスクにコピーしているときだけハードディスクの音が聞こえるけれど、ファンの音はまったく気にならないほど静音設計になっている
• 内部のファイルシステムは、XFS になっている

実際のバックアップ方法は、それぞれ次のような感じで行っています。

Mac mini からは、このあたりの情報から調査した結果、最終的には TimeMachine でバックアップしています。ただし、公式にはサードパーティ静の NAS に対応していないので、iTimeMachine というアプリケーションで設定しています。もちろん、Terminal から設定できるので、次のコマンドを入力してもいいと思います。

$ defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1

そして、ここを参考にして NAS 上に TimeMachine のバックアップをとれるように設定しています。

FreeBSD からは amd 経由で NFS でマウントして rsync でバックアップしています。将来的には、ZFS にファイルシステムを変更して、さらに手軽にバックアップする予定です。

気になる価格の方は、N2200 と 2TB のハードディスクを 2 台あわせて約 5 万円弱くらいです。価格的には、Time Capsule 2 TB モデルと同じくらいです。ただし、RAID1 なので Time Capsule よりはコストパフォーマンスがよいといえるかもしれません。そのかわり、セットアップはめんどうですが。

これでようやく、音楽や写真などの大事なデータをバックアップして生活することができるようになりました。

Thecus 2ベイ NASキット DLNA対応 N2200

posted with amazlet at 10.03.27

Thecus (2009-10-09)
売り上げランキング: 62581

Amazon.co.jp で詳細を見る

例えば、次のような設定を書いたとする。

<VirtualHost * *:443>
ServerName test.localhost
DocumentRoot /var/www/html

<Directory /var/www/html>
Allow from All
</Directory>

<Location />
AuthType Basic
AuthName “test”
AuthUserFile /var/www/.htpasswd
Require valid-user
</Location>

<Location /test>
Order allow,deny
Allow from all
Satisfy Any
</Location>
</VirtualHost>

このような VirtualHost を設定しておくと、http://test.localhost 以下の /test 以外は Basic 認証がかかった状態になる。たまに、こういった設定も必要なときがあるので、これは便利。

参考資料

• Apacheのベーシック認証の応用

最初は、スイッチやネットワーク系統の問題だと思っていたのですが、どうやら内部にたてている DNS で逆引き設定を忘れていて、その上位の DNS サーバで急に逆引きができなくなったことが起因していました。

お恥ずかしい限りですが、内部の DNS で逆引き設定を忘れていました。

SSH で逆引きしないように設定するには、FAQ に書かれているとおり sshd_config に UseDNS no と設定すれば 逆引きしない設定することができます。

同様に MySQL で逆引きしないように設定するには、mysqld の起動オプションに --skip-name-resolve とつけて起動すれば設定することができます。

どちらもこの設定をしてしまうと、接続設定にホスト名を指定することができなくなってしまうため、不便です。

てっとりばやく解決するには、それぞれのサーバに /etc/hosts を記述すれば可能なのですが、すべてのサーバを /etc/hosts を puppet  で管理するのはなかなかめんどうです。puppet には host リソースがあって、手軽に /etc/hosts を扱えるのですが、前に s[1-255].server.example.jp という設定をマニフェストに記述してみたら、s1 から順番に並んでいないとても汚くなってしまったので微妙です。それに各サーバごとの役割は、現実的にかなり頻繁に変わるので、そのたびにすべてのサーバの /etc/hosts を変更するのは管理コストがかなりかかります。個人的には、かなり非現実的です。

やはり、内部 DNS で逆引き設定をするのが一番いいと思います。今のところ、内部 DNS には bind を使っています。bind には、GENERATE という独自の構文があって、これを使うと次のように簡単に逆引き設定をすることができます。

$TTL    86400
@               IN SOA  @       root (
                                       123             ; serial (d. adams)
                                       3H              ; refresh
                                       15M             ; retry
                                       1W              ; expiry
                                       1D )            ; minimum
               IN NS           ns1.example.jp.
$GENERATE   1-256   $.0.0.10.in-addr.arpa.  PTR     s$.example.jp.

あとは、/etc/named.conf に、次のように zone 設定を記述すれば逆引き設定をすることが可能です。

zone "0.0.10.in-addr.arpa" IN {
               type master;
               file "0.0.10.in-addr.arpa";
               allow-update { none; };
               notify no;
};

設定したら、正しく逆引きができるこを、次のような感じで確認します。

$ dig @localhost -x 10.0.0.1

今回は、どうやら回線プロバイダから提供されている上位の DNS で逆引き設定ができなくなったようですが、なぜこの時間に起きたのか詳しい原因はよく分かっていません。

内部 DNS をたてている場合、逆引きの設定は忘れやすいので注意したいです。

今のところ、内部 DNS には bind を使っていますが、Unbound か PowerDNS に置き換える予定です。

rsyslog 4.6.1 の前のバージョンであるバージョン 4.5.6 では、僕がパッチを送ったデータを圧縮したときのメモリリークが修正されています。おそらく rsyslog を使っている人で圧縮を有効にしている人は少ないと思いますが、もし使っている人は激しくメモリリークするので、最新版の 4.6.1 にアップグレードしましょう。

bugfix: memory leak when sending messages in zip-compressed format
Thanks to Naoya Nakazawa for analyzing this issue and providing a patch.

こんな感じで rsyslog の CHANGELOG に自分の名前が掲載されているなんて感無量です。

現在、rsyslog バージョン 4.4.2 を本番サーバで使っているのバージョンアップする予定です。

あと、rsyslog を使っていますが、たとえばかなりの容量の Apache のアクセスログを rsyslog へ送っているとき、まれに rsyslog が落ちてしまう問題が一回発生したのですが、再現していません。再現したら、解析して、またパッチを送ってみようと思います。

rsyslog は、現在でもかなり活発に開発が進められているので、今後も進化を続けると思います。

# 今後は、rsyslog バージョン 5.x 系の開発に注力するようです。

• コンパイルにかなりの時間がかかる
• コンパイル後の、テストが必ず失敗する(SSL まわりのエラーなので、テストは必ずしないように変更していた)
• なぜか、InnoDB plugin が無効になってしまって、InnoDB plugin を普通に試せない

ということで、QA もちゃんとされている MySQL の公式 RPM に切替えてみることにしました。

まず、現在の MySQL 5.1 の最新バージョンは 5.1.44 です。MySQL の公式サイトでは RHEL5 用の x86_64 の RPM が用意されています。
RHEL5 x86_64 用の RPM は、次のものをダウンロードすることができます。

• MySQL-client-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-community-5.1.44-1.rhel5.src.rpm
• MySQL-community-debuginfo-5.1.44-1.rhel5.x86_64.rpm
• MySQL-devel-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-embedded-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-server-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-shared-community-5.1.44-1.rhel5.x86_64.rpm
• MySQL-shared-compat-5.1.44-1.rhel5.x86_64.rpm
• MySQL-test-community-5.1.44-1.rhel5.x86_64.rpm

次のそれぞれの RPM に、どんなものが含まれているか調査してみました。

MySQL-client-community-5.1.44-1.rhel5.x86_64.rpm
/usr/bin/mysql など、MySQL クライアントようのコマンドが含まれています。

MySQL-community-5.1.44-1.rhel5.src.rpm
SRPM です。mysql-5.1.44.rhel5.spec と mysql-5.1.44.tar.gz が含まれています。

MySQL-community-debuginfo-5.1.44-1.rhel5.x86_64.rpm
MySQL のデバッグシンボル情報です。

MySQL-devel-community-5.1.44-1.rhel5.x86_64.rpm
mysql_config コマンドと MySQL のヘッダーファイルが含まれています。

MySQL-embedded-community-5.1.44-1.rhel5.x86_64.rpm
MySQL の組み込む用途に使われる /usr/lib64/mysql/libmysqld.a が含まれています。

MySQL-server-community-5.1.44-1.rhel5.x86_64.rpm
mysql の sysinit スクリプト、my.cnf 設定ファイルなど MySQL サーバに必要なプログラムが含まれています。

MySQL-shared-community-5.1.44-1.rhel5.x86_64.rpm
/usr/lib64/libmysqlclient.so と libmysqlclient_r.so が含まれています。

MySQL-shared-compat-5.1.44-1.rhel5.x86_64.rpm
MySQL-shared-community の複数のバージョンが含まれています。

MySQL-test-community-5.1.44-1.rhel5.x86_64.rpm
mysql_client_test コマンドが含まれています。

次に、CentOS で提供されているパッケージ名と MySQL 公式のパッケージ名の対応は、次のとおりになります。さらに詳しい RPM の説明は、MySQL 公式サイトを参照しましょう。

mysql:               MySQL-client-community + MySQL-shared-community
mysql-bench:   該当なし
mysql-devel:    MySQL-devel-community
mysql-server:  MySQL-server-community
mysql-test:      MySQL-test-community

MySQL 公式の RPM を使うには、既存の CentOS から提供されているパッケージを上書きするようなダミーパッケージを作成したほうが便利だろうと考えました。なぜなら、既存の MySQL 以外のパッケージで、mysql や mysql-devel のパッケージ依存関係が設定されているときにやっかいだからです。具体的には、このような現象が想定されるからです。

一度ダミーパッケージを作って、公式の RPM もローカルの yum リポジトリに入れてインストールとすると、どうも不思議な感じになってしまいました。具体的には、mysql パッケージをインストールすると、なぜか MySQL-server-community パッケージがインストールされてしまいました。

公式の RPM をよく見てみると、なんと Provides が設定されているじゃありませんか!
公式の RPM では、次のようにちゃんと Provides が設定されています。

MySQL-client: mysql-client MySQL-client
MySQL-server-community: msqlormysql mysql-server mysql MySQL MySQL-server
MySQL-test-community: mysql-test MySQL-test
MySQL-devel-community: mysql-devel MySQL-devel
MySQL-shared-community: mysql-shared MySQL-shared
MySQL-embedded-community:  mysql-embedded MySQL-embedded
MySQL-test-community: mysql-test MySQL-test

なので、mysql パッケージ名を指定すると MySQL-server-community パッケージがインストールされるんですね。。。ということで、小文字のパッケージ名でもちゃんとインストールできます。。。ダミーパッケージを作成したのが無駄になってしまいました、お恥ずかしい。。。

一点だけ注意点があって、mysql というパッケージ名は MySQL-server-community で Provides されているので、MySQL サーバが入ってしまうということです。もし、あるパッケージに mysql というパッケージの依存関係があると MySQL-server-community パッケージがインストールされてしまうので注意しましょう。

まとめると、ダミーパッケージは必要なく、MySQL の公式パッケージだけで、次のコマンドで MySQL の最新バージョンを手軽に使うことができます。

$ sudo yum install mysql-client mysql-shared mysql-server

上のコマンドで MySQL をインストールする場合、MySQL の公式 RPM の方がバージョンが新しいので必ず MySQL 5.1.44 がインストールされるはずです。

ですが、正しくバージョンを指定して、MySQL のバージョンをインストールした場合は、次のようにします。

$ sudo yum install mysql-client-5.1.44 mysql-shared-5.1.44 mysql-server-5.1.44

ただし、RPM に登録されるパッケージ名は、MySQL-*** となるので注意しましょう。mysql* という小文字のパッケージでは登録されていないので気をつけてください。

また、mysql の設定ファイル(/etc/my.cnf と /etc/mysqlmanager.passwd)は、インストールされていないので自分で設置しましょう。
デフォルトの /etc/my.cnf は、このあたりの情報をもとにして設定を追加するといいと思います。

ちなみに MySQL の公式 RPM は、cobbler でローカルの yum リポジトリにミラーしていますが、こんな感じで設定してあります。

$ sudo cobbler repo report –name=mysql-MySQL-5.1

repo: mysql-MySQL-5.1
arch: x86_64
breed: rsync
comment:
created: Tue Feb  9 22:34:22 2010
createrepo_flags: -c cache -d
environment: {}
keep updated: True
mirror: rsync://ftp.jaist.ac.jp/pub/mysql/Downloads/MySQL-5.1/
mirror locally: True
modified : Tue Feb  9 22:34:22 2010
owners: ['admin']
priority: 99
rpm list:
yum options: {}

こうしておけば、MySQL 5.1 系の最新バージョンがでたとき、cobbler reposync すればすぐに最新版の RPM をローカルの yum リポジトリにミラーできるので、とても便利です。

さて、これで MySQL をメジャーアップグレードする準備が整いました。

オープンソースカンファレンス2010 Tokyo/Spring – イベント案内 | 2010-02-27 (土): LinuxからBSDへ – reallyenglishのインフラとネットワーク

以下、講演内容のメモです。

• reallyenglish のサービス紹介、おもに BtoB 向けの英語学習サービスを提供
• データセンターは、日本と香港に二つ借りている
• サーバ台数 50 台、30 台の L2/L3 スイッチ、10 の IPsec-VPN くらいの規模、L2/L3 レベルですべて冗長化されている
• OS は、ルータにはすべて OpenBSD、サーバには FreeBSD 7.x を使っている
• nagios の監視レベルで、100 個のホスト死活監視、400 のサービス監視
• サーバは、PXE 経由でインストールしている、VLAN を設定してあって、管理コンソールは HP の iLO2 を使っている(つまり HP 製のサーバだということ)
• 香港のデータセンターは、有料で OS のセットアップまで行ってくれるが、自分たちでなるべくやっている
• smokeping を使って、ネットワークのレイテンシーをみている
• ローカルネットワークにパッケージのビルドサーバ、パッケージリポジトリをもっていて、port ツリーを一部カスタマイズしたりしている
• freebsd-update もローカルのサーバ経由で行っている
• Marcuscom Tinderbox を使って、パッケージのビルドなどを管理している(かなり便利とのこと)
• Jail を多用している、雑用系のサーバには 10 くらいの Jail が起動していた、他の仮想化技術と違って仮想化によるオーバーヘッドがほとんどないとのこと、Jail から ZFS も扱えるとのこと
• Jail の設定はかなりめんどうだったが、ezjail – Jail administration framework というツールでかなり簡単に設定できるようになった
• LDAP を使っている
• ZFS を本番環境で使っている

Version 13 が RELENG_8 に入っている

ほぼ本番環境でも使えるクオリティに仕上っている

ZFS の運用では、パーティションやスライスを切らないのが普通とのこと

ルートパーティションは、UFS2 にして USB メモリに入れてブートしている

ハードディスクは、すべて ZFS に割り当てている

SSD 上で ZFS L2ARC : Brendan Gregg にある L2ARC(read), ZIL(write) という仕組みを使うと SSD をキャッシュとして使うことができる

Dedup という実装が進んでいる(詳細は調べてみたが分からず)

• HAST – FreeBSD Wiki という Linux でいうところの DRBD のようなものが開発が進められている
• HAST + ZFS + iSCSI という夢の組合せができるかもしれないとのこと
• nagios version 3.0.6 を使って監視しているが、Template Engine を使ってテンプレートで生成している(mixi と同じ方式だと理解しました)
• reallyenglish では、現在開発エンジニアとインフラエンジニアを絶賛募集中とのこと

その他、貴重な本番の nagios の監視画面や smokeping の画面やネットワーク構成図も見ることができました。

BSD 系のインフラの話は、あまり話を聞く機会がなかったのでかなり参考になりました。

まずは、自分個人の FreeBSD サーバで ZFS や Jail を使ってみたいと思います。

今回の講演のスライドは、おそらく公開されるのではないかと思いますが、今回の hbstudy #8 ではツール以前にインフラエンジニアとしてどんなところを目指すか、どのような姿勢でインフラを管理するかといった精神論的な考えというか思想が、とても勉強になりました。

まず、インフラにかかわらず、何言にも共通する思想は、

楽をすること

につきると思います。楽をするための苦労は惜しまずに、楽をするためのツールを自作したり、オープンソースのツールを使ったり、楽をするにはいろいろな方法があります。まず考えることは、楽をするために何をすることなのかなぁと思います。楽をするというと、なんだか怠け者のような印象をもたれることもあると思いますが、楽をするために新しい手法を取り入れていることは大事だと思います。

その次は、インフラエンジニアとしての大切だったと思った思想は、次のとおりです。

• インフラに導入するツールは、なるべくシンプルなものにする
• 自作ツールの場合、なるべく同じ技術を使ったツールで統一する
• ある程度、基本知識がある人なら、自分が管理しているインフラを管理することができるようにする

まず、前提となる知識を習得するのが困難だったり、使い方は複雑なツールは使わないということです。やはり、とても便利なツールでも複雑なツールを導入してしまうと、自分はいいのですが他の人に引き継ぐことになったときなどに説明する手間がかなりかかると思います。また、決してオープンソースのツールだけに選択肢をおかずに機会損失や管理コストなどを総合的に比較して商用ツールも検討するといったこともあるかと必要な場面があると思います。

その次ですが、kazuho さんが基本的にとてもシンプルな自作ツールでインフラを管理しているという話の中で登場してきたツールはほとんど perl で書かれていました。自作ツールでも、シェルスクリプトだったり、C++ だったり、ruby だったり、と実装している技術はバラバラだと、すべての知識が必要になってきます。こうした自作ツールは、perl など１つの実装にまとめることで perl さえ分かれば自作ツールのメンテナンスや改良もできます。最近の Linux の場合、Linux Standard Base (LSB) | The Linux Foundation という規格があるこの規格によると perl や python は最初からインストールされています。残念ながら、ruby や PHP は入っていないので、ruby や PHP で作るときにはパッケージのインストールが必要になります。最近のサーバは、とても早いのでわざわざ C++ などで作成するよりも LL で十分なことも多くなってきていると思います。個人的には、ruby を愛用していますが、python にしたほうが標準インストールされているという観点でみるとありかなと思っています。

最後に、自作ツールでもあまりオレオレ仕様的なツールは作らずに、他のツールの思想や考えたにのとった自作ツール、定番といえるオープンソース、だけをできるだけ組み合わせて、かつシンプルに形でインフラを管理しておくということです。シンプルにしておけば、日常業務の中でも毎日やることが単純になったり、業務レベルで他の担当者と共有することも比較的容易なのでないかと思います。

今回の hbstudy では、このような考え方というか思想が大事なのではないかと感じました。僕が管理しているインフラも、この思想に基づいていけるように日々改善を重ねいたいと思いました。

このバージョンでは、CHANGELOG をみて分かるようにバグフィックスの他にいくか機能拡張がされています。

その中で、個人的に大きいのは httpd のサービスチェックのときに HOST ヘッダーを指定できるようになったことです。例えば、次のようなに HOST ヘッダーを指定して httpd サービスの監視をすることができます。

if failed host localhost port 80 protocol http and request ‘/ testing’ hostheader ‘example.com’ with timeout 20 seconds for 2 cycles then restart

hostheader という識別子で手軽に指定することができます。

さっそく試そうと RPM を作ってみることにしました。monit には、RPM を作成するための SPEC ファイルが同梱されているので、次のコマンドでさくっと RPM を作成することができます。

$ rpmbuild -ta monit-5.1.tar.gz

しかし、いくつか不用なファイルの設定が原因で RPM をビルドできないので SPEC ファイルを、次のように修正しました。この修正は、本家に連絡してすでにコミットしてもらってあります。

— monit.spec-org      2010-02-18 10:48:56.000000000 +0900
+++ monit.spec  2010-02-18 10:49:09.000000000 +0900
@@ -51,7 +51,7 @@

%files
%defattr(-,root,root)
-%doc CHANGES.txt CONTRIBUTORS COPYING FAQ.txt LICENSE README README.SSL
+%doc CHANGES.txt COPYING LICENSE README README.SSL
%config /etc/monitrc
%config /etc/init.d/%{name}
%{_bindir}/%{name}

RPM を作成して、さっそく monit をアップグレードして、次のような設定で試してみます。

check process httpd with pidfile /var/run/httpd/httpd.pid
start program = “/etc/init.d/httpd start”
stop program = “/etc/init.d/httpd stop”
if failed port 80 protocol http
and request “/” hostheader “example.com”
with timeout 2 seconds for 2 cycles
then restart

動作確認するために、sudo monit -Iv してみると、hostheader の syntax エラーになります。ソースコードをみてみると、不具合っぽいのでさっそく連絡してみると、作者の Martin さんから、次のようなパッチが送られてきました。

Index: p.y
===================================================================
— p.y (revision 128)
+++ p.y (working copy)
@@ -1077,7 +1077,7 @@
;

hostheader      : /* EMPTY */
-                | hostheader STRING {
+                | HOSTHEADER STRING {
portset.request_hostheader = $2;
}
;

monit バージョン 5.1 の不具合のようです。さっそく、上のパッチとあわせて本家に掲載されている FTP のパッチをあわせて RPM を作成しました。パッチをあてて作成した RPM は、ここに置いておきます。

パッチをあてた monit でさっそく動作確認してみると、hostheader 識別子をちゃんと認識して問題なく動作しました。

これからの修正は、CHANGELOG をみてみると、おそらく近いうちに monit バージョン 5.1.1 でリリースされるのでないかと思います。hostheader のバグレポートを報告したので、CHANGELOG になんと僕の名前が掲載されています。こんな小さな報告でも CHANGELOG に追加されるんですね。

Fix the HTTP protocol test’s hostheader option which was added in 5.1.
Thanks to Naoya Nakazawa for report.

httpd のサービスチェックで HOST ヘッダーを指定できると、かなり便利になるので、monit を愛用している人はバージョン 5.1.1 を待つか、パッチをあてたバージョンにアップグレードするといいと思います。

monit は、なんといっても設定ファイルが書きやすい、メーリングリストで質問やバグレポートをすると翌日にはすぐに返信があるのでかなり活発なプロジェクトなので、使っていない人はぜひ使ってみるといいと思います。

# 2010.02.25: 追記

monit バージョン 5.1.1 がリリースされました。バグフィックスのみのリリースです。

Release checksums
=================
md5:    4bbd3845ae1cbab13ec211824e0486dc
sha256: bf789e0660410e8c63f4b3dc2eeab9889347e6494a6dc1c0e764343cae0dc1ba

Release information:
====================
Bug fixes
* Fixed FTP protocol test. Thanks to Axel Reinhold for report.
* Fixed the hostheader option in the HTTP protocol test, which was
added in Monit 5.1. Thanks to Naoya Nakazawa for report.
* Removed an erroneous warning message about missing system service check.
* Improved manual page formatting. Thanks to Stefan Alfredsson for report.

僕の名前があって、ちょっとうれしいです(笑)。

iptstate は、netfilter の接続をトラックキングしているテーブルの情報を top のように表示してくれるコマンドです。

CentOS の場合は、すでに iptstate バージョン 1.4.1 が提供されていて、普通にインストールすると iptstate パッケージがインストールされています。

さっそく、試してみます。iptstate は、netfilter つまり iptables の接続トラックキングテーブルの情報を表示してくれるので、iptables が動作している必要があります。

$ sudo /usr/sbin/iptstate

IPTables – State Top
Version: 1.4          Sort: SrcIP           s to change sorting
Source                  Destination             Proto   State        TTL
127.0.0.1:33005         127.0.0.1:8020          tcp     ESTABLISHED  119:59:58
127.0.0.1:52326         127.0.0.1:8021          tcp     ESTABLISHED  119:59:56
192.168.161.1:60730     192.168.161.125:22      tcp     ESTABLISHED  119:59:12
192.168.161.1:54619     192.168.161.125:22      tcp     ESTABLISHED  119:59:55
192.168.161.1:17500     192.168.161.255:17500   udp                    0:00:09

な感じで、接続元の IP アドレス、経路情報、プロトコル、状態、TTL、を表示してくれます。

もちろん、top のように並び替えもできます。iptstate では、次の並び替えのキーが定義されています。

d   カラムのサイズを動的に変更して、古いデフォルトのサイズを使用する

f   loopback でフィルタリングする

l   IPアドレスの中で DNS を探している順にする

m   ホスト名を切り取った形でフィルタリングする

n   DNS に関連した表示にする

q   終了する

r   逆順に並び替える

space   表示をすぐに更新する

昔から存在するコマンドですが、どこから接続があるので、どのポートに接続しているのか、などがすぐに分かるので、とても便利なコマンドです。

Puppet Dashboard とは、ノード管理とレポートツールを提供してくれる Puppet のウェブアプリケーションです。ノード情報はYAML 形式でエクスポートすることができて、ダッシュボードから外部ノードツールとして使うこともできるようです。

まず、最初にPuppet Dashboard を動作させるために、次のものが必要です。

• ruby >= 1.8.1
• rake >= 0.8.4
• mysql
• puppet
• rubygems >= 1.3.2
• rails >= 2.3.4

さっそくインストールしてみましょう。

$ git clone git://github.com/reductivelabs/puppet-dashboard.git

$ cd puppet-dashboard

$ rake install

rake install すると、dashboard_development というデータベースが作成されてテーブルがいくつか作成されるので、localhost に mysql が起動している必要があります。

Rails アプリケーションなので、さっそく起動します。

$ ./script/server

http://localhost:3000 にアクセスすると、次のような Puppet Dashboard トップ画面が表示されます。

ノードの例として、「sample node」が定義されています。さっそく、ユーザ登録してみます。ユーザ登録は、ユーザ名とパスワードを入力するだけのシンプルな形です。

ユーザ登録できたところで、実際のノードを追加してみます。Nodes タブをクリックして、ノードを追加します。

この他にも、ノードクラス、ノードグループ、レポート、の機能があります。

まず、レポートの機能は、現在の puppet レポートの実行結果が /var/puppet/lib/reports にある場合は、次のコマンドで Puppet Dashbaord へインポートできます。

$ rake reports:import

また、puppet レポートの実行結果が、他の場所にある場合は、次のコマンドで Puppet Dashboard へインポートすることができます。REPORT_DIR という環境変数に Puppet レポートの実行結果を格納してあるディレクトリを指定するだけです。

$ rake reports:import REPORT_DIR /path/to/your/reports

Importing 1 report from /path/to/your/reports
Importing:     100% |##########################################| Time: 00:00:00
1 of 1 report imported

試しに1件レポートデータをインポートした画面は、次のようになっています。

毎回、レポートをインポートするのが面倒なので、Puppet サーバと連携する方法も用意されています。Puppet サーバと連携するには、puppetmasterd に、次のように –reports オプションを指定するだけです。

–reports <puppet_bashboardのサーバ名>

ただし、Puppet Dashboard は、localhost:3000 で動作するようにハードコーディングされています。これを変更するには、lib/puppet/puppet_dashboard.rb を変更する必要があります。

次に Puppet Dashboard には、Puppet 互換の外部ノード情報と連携することができます。Puppet 互換の外部ノード情報は、YAML 形式で出力しますが、Puppet Dashboard に付属している bin/external_node プログラムを使います。このプログラムも、localhost:3000 でハードコーディングされているので、環境に応じて変更するとよいでしょう。

今のところ、僕が Puppet を投入している本番環境ではレポート機能をオフにして、エラーログのみチェックしていますが、比較的少ない台数で運用している場合は、Puppet Dashboard 管理画面からレポートの実行結果をチェックすることができるので、便利なツールと言えそうです。

将来的には、次の機能が実装予定とのことです。

• LDAP と ActiveDirectory 認証
• 管理者の権限によるアクセス制御
• データをよりよく可視化して、情報にアクセスしやすくする
• さらに多くのノード状態情報(オフライン状態、通信エラー、など)
• リソースの変更を報告して、トラックキングする
• Puppet の実行スケジューリング
• その他のコミュニティからのリクエスト機能

まだ、Puppet Dashboard は登場したばかりなので、これから期待できるツールにもなりますね。

さっそく、CentOS で試してみると、iptables の libipt_statistic モジュールがないというエラーになってしまった。次に RedHat のページを調べていると、Bug 215361 – iptables is missing /lib/iptables/libipt_statistic.so というまさにぴったりな情報が見つかった。その情報では、iptables バージョン 1.3.6 から追加されたとあったので、さっそく netfilter iptables バージョン 1.3.6 のページの変更点を調べてみると、たしかに次のような記載があった。

- Add support for statistic match (needs kernel >= 2.6.18)
  [ Patrick McHardy ]

CentOS 5.3 x86_64 の iptables のバージョンは、iptables-1.3.5-4.el5 なので一つバージョンが古いのが原因のようだ。Linux カーネル 2.6.18 が必須とのことなので、CentOS でもおそらく使えるそうだ。

さっそく、iptables バージョン 1.3.6 を導入するために、RPM を作成にとりかかった。

まず、iptables-1.3.5-4.el5 の SRPM をダウンロードして、このバージョンの iptables.spec ファイルをパッチなどはすべて正しくあてるように、かつ libipt_statistic をビルドして組み込むように RPM を作成した。

libipt_statistic は、iptables バージョン 1.4.0 以降から標準で組み込まれるようになっているが、バージョン 1.3.6 では標準では組み込まれない。ちょうど、該当のコミットログがあったので、コミットログを参照しながら RPM を作成した。

作成した RPM は、ここにアップロードしてある。あわせて、SRPM もアップロードした。他に作った人がいないかも調べてみたが、見つからなかった。

iptables を現時点での最新版であるバージョン 1.4.6 ではなく、バージョン 1.3.6 にしようとした理由は RPM のおそらくメジャーアップグレードになるので RPM の作成が大変であること、安定性の面で経験がまったくないのでなるべる標準にインストールされるバージョンに近いものにしたいと思ったからだ。

作成した RPM で、CentOS にインストールされている既存の iptables をバージョンアップして、さっそく試してみた。

まず、外側のネットワークのデバイスに IP エイリアスを設定する。次の例は、ifconfig eth0 の出力結果だが、不要な情報は省いてある。

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.125  Bcast:192.168.161.255  Mask:255.255.255.0

eth0:0    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.124  Bcast:192.168.161.255  Mask:255.255.255.0

eth0:1    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.123  Bcast:192.168.161.255  Mask:255.255.255.0

eth0:2    Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx
inet addr:192.168.161.122  Bcast:192.168.161.255  Mask:255.255.255.0

次の iptables の設定で NAT チェインを、次のように設定する。(スマイルアイコン対策のため、PREGROUTING と POSTROUTING の前のセミコロンは省いてある)

*nat
PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.125
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.124
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.123
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.122
COMMIT

iptables を再起動して、さっそく接続先のサーバに Apache HTTPD を起動して、アクセスログを確認してみると、次のような結果になった。

192.168.161.125 – - [11/Feb/2010:23:17:07 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:17:08 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:17:09 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.122 – - [11/Feb/2010:23:17:09 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:10 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:11 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:17:12 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:13 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:17:14 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:17:14 +0900] “GET / HTTP/1.1″ 200 44

完全にはラウンドロビンにはなっていないが、リクエストごとにアクセス元の IP アドレスが毎回変更されている。

最後に libipt_statistic のモジュールとはどんなモジュールかソースコードを読んでみた。libipt_statistic モジュールとは、ある状態になっているかを調べることができるモジュールのようである。

設定内容は、次のような設定が可能。

–mode mode: マッチモード (random あるいは nth)

–probability p: 確立

–everyn: n 番目のパケットに毎回マッチする

–packet p: 初期値のカウント値(p は、0 以上 p – 1 以下)、デフォルトは 0

どうやらこのモジュールは、ある状態ごとに iptables の設定を変更できるモジュールのようだ。

いろいろと試した結果、完全なラウンドロビンにするには、次のような設定でいけるようだ。(スマイルアイコン対策のため、PREGROUTING と POSTROUTING の前のセミコロンは省いてある)

*nat
PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 4 -j SNAT –to-source 192.168.161.125
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 3 -j SNAT –to-source 192.168.161.124
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 2 -j SNAT –to-source 192.168.161.123
-A POSTROUTING -o eth0 -p tcp –dport 80 -m statistic –mode nth –every 1 -j SNAT –to-source 192.168.161.122
COMMIT

上の設定のときの Apache アクセスログは、次のようになった。

192.168.161.122 – - [11/Feb/2010:23:27:29 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:27:30 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:27:31 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:27:32 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.122 – - [11/Feb/2010:23:27:32 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:27:33 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.124 – - [11/Feb/2010:23:27:34 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.123 – - [11/Feb/2010:23:27:34 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.122 – - [11/Feb/2010:23:27:35 +0900] “GET / HTTP/1.1″ 200 44
192.168.161.125 – - [11/Feb/2010:23:27:36 +0900] “GET / HTTP/1.1″ 200 44

どうして、この設定だと、完全にラウンドロビンになるのか、よく分かっていない。。。

iptables には、こんなこともできるのかと感動した。

# 2010.04.01: 追記

iptables の設定ファイルの例は、ここに置いた。

以下、動画からのメモです。

• CPU の高い使用率が問題になっていた
• 10,000 台のウェブサーバ
• それぞれのリクエストに 800 ミリ秒かかっている
• コードベースが巨大になるにつれて、さらに遅くなる
• ハードウェアは、フリーではない
• 言語ごとのベンチマークした結果の CPU の使用率
• CPU の使用率が低い順 No1: C++, No2: Java, No3: C#, No4: Erlang, No5: Python, No6: Perl,  No7: PHP
• PHP と Perl は同等、C++ や Java に比べると10 倍くらい遅いという結果
• 高いメモリ使用率が問題
• - 150M
  for ($i = 0; $i < 1000000; $i++) {
  $a[] = $i;
  }
• - 750MB
  for ($i = 0; $i < 5000000; $i++) {
  $a[] = $i
  }
• HipHop for PHP では、次の問題点を解消するために作った
• 高い CPU の使用率を解消するため
• 多くのメモリの使用率を解消するため
• 他のシステムで既存の PHP のロジックを再利用するため
• 拡張は、ほとんどの PHP 開発者には書くことが難しい作業
• HipHop for PHP は、2年間の成果で、ソースコードの最適化された C++ コード(g++ を使う)の変換機
• 効果は、ウェブサーバは 50% 以下に下がった、API は 2 倍のトラフィックに対して 30% 以下に下がった(APC を使った PHP コードベースと比べた結果)
• 7つのステップを通して、コードを変換する
• 本番環境でのデプロイは、通常の PHP コードでのデプロイとは異なっている
• 複数のスレッドで一つのプロセスを起動している
• 再起動している間のダウンタイムがない(port takeover… ポートを乗っ取り?)
• 巨大なバイナリを置く
• HipHop は、現在とてもシンプルなウェブサーバ上で使っている
• これからのロードマップ
• 現在、PHP 5.2 をサポートしているが、5.3 もサポートしたい
• ウェブサーバのオプションとして Apache をサポートしたい
• Facebook では、Apache 1.3 Prefrok で使っているとのこと
• 同時にデータベースのコネクションも減っている
• PHP の拡張はスレッドセーフでない問題は解決できていないとのこと

まだ、ちゃんと試していないのでよく分かりませんが、PHP なウェブサービスで PHP が CPU ボトルネックになっている場合には、物理サーバを減らすための有効なソリューションの一つになるかもしれないイメージをうけました。ただし、Facebook では、まだとても単純なウェブサーバ上でしか使っていないそうので、実際のサービスに使うにまだまだ時間がかかりそうです。

あと、個人的には Java は C++ と同様のベンチマーク結果だということも注目です。

なお、HipHop for PHP のソースコードは、github でもうすぐ公開予定とのことです。

sudo コマンドはなくてはならないコマンドですが、同時に危険なコマンドでもあります。

今まで、ずっとデフォルトの sudo の設定で使っていたのですが、改めて設定を見直してみました。

sudo の公式ページをみてみると、頻繁にバージョンアップされているのがよく分かります。/etc/sudoers の設定方法も詳しいドキュメントがあっていい感じです。

次の2点ほど設定を見直しました。

• デフォルトのパスワードのキャッシュ時間を 0 にする
• パスワードプロンプトにホスト名を表示する

まず、最初の設定はデフォルトだと 5 分間、パスワードがキャッシュされます。そうすると、連続で sudo コマンドを実行するとき、パスワードを聞かれないためオペミスを起こしてしまう可能性が高まります。そこで、キャッシュ時間を 0 にすることにより、必ず毎回パスワードを聞くように設定します。この設定は、visudo コマンドを使って、次の行を追加します。

Defaults timestamp_timeout = 0

次にパスワードを聞かれるときのプロンプトにホスト名を表示して、念のためどのホストで sudo を実行しようとしているのか表示します。次の行を追加します。

Defaults passprompt = “%u@%h Password: “

この設定をすると、例えば hoge というユーザ名で、s1 というホスト名の場合、次のようなパスワードプロンプトになります。

hoge@s1 Password:

デフォルトのパスワードプロンプトに比べると、かなり分かりやすい表示になりました。

最新版の sudo バージョン 1.7.1 以降からは、次のような構文で別の設定ファイルも読み込めるようになっています。

これを使えば、ホストごとに異なった設定も管理しやすくなります。ただし、CentOS の場合、バージョン 1.6.8 なので対応していません。すこしはまってしまいました。。。

#includedir /etc/sudoers.d/hoge

最新版の sudo に入れ替えようと思いましたが、今のところそれほど困っていないので最新版は使っていません。

普段何気なく使っている sudo。もちろん、なるべく本番サーバ上では使わないのが賢明ですが、メンテナンスのときなど使う機会があるので、なるべくオペミスのリスクを減らしたいものです。

さらに、僕は sudo をコマンド補完履歴に追加しないようにしています。

# 2/5 追記

ちなみに、sudo のパスワードキャッシュをクリアするときは sudo -k あるいは -K オプションで行います。