Browse Month: September 2008

rubygems その三

rubygems のローカルミラーを gem mirror コマンドで構築したら、実際にローカルミラーを使う方法をまとめておく。

まず、.gemmirrorrc で指定した to のディレクトリを HTTP 経由で公開する必要がある。Apache なら、次のように設定しておけばよい。

 


AliasMatch ^/rubygems(.*)?$ "/var/www/rubygems$1"
<Directory "/var/www/rubygems">
    Options Indexes FollowSymLinks
    Order allow,deny
    Allow from all
</Directory>

 

この設定だと、http://example.com/rubygems で rubygems のローカルミラーが公開されていることになる。

 

あとは、このローカルミラーを使いたいサーバの root のホームディレクトリに .gemrc に次のように設定しておけばよい。もちろん、gem install コマンドを実行するときに指定しても問題ないが、毎回指定するのはめんどくさいので、この設定がおすすめ。


gem: --no-rdoc --no-ri --no-update-sources --backtrace --source http://example.com/rubygems

他のオプションは、サーバに rubygems をインストールするとき rdoc などは不要なので、ruby-enterprise のインストーラープログラムを参考にして設定した。

 

もちろん、この設定も puppet module にしたので公開しようっと。

エンジニアのための時間管理術を読んだ

かなり勉強になったと思う。何度か読み返して、すこしずつ改善していこう。

以下、メモ。

  • タイムマネジメントに関するものをすべて一ヶ所にまとめる
  • オーガナイザーとして iPhone or 紙を使う
  • 作業リスト、カレンダー、人生の目標を保存する
  • Emacs howm を試してみる
  • スケジュールなどは覚えきれないので、かならずオーガナイザーにまとめる
  • 毎日、必ず読書の時間を作るようにしよう
  • 今取り組んでいることに頭を使い、それ以外のことには外部ストレージを使用する
  • 日常生活の細かいところまで意識しない、洋服とか食物とか
  • いかにして、今の頭の中で気にしていることを外部ストレージに移すことができるかどうかが勝負
  • 定期的に行うことに対してルーチンを決める
  • 日常生活をなるべくルーチンにして、無意識でルーチンをやれるようにする
  • 習慣やモットーを身につけることにより、事前に判断を下す
  • プロジェクトタイムでは集中力を維持する
  • デスクトップからアイコンを削除して、壁紙をなくす
  • なかなか作業がはかどらないときは、すべてのウィンドウを閉じてから深呼吸してもっとも優先度の高い作業を一つ選ぶ
  • 必ず、ウィンドウの位置を固定にしておく
  • 1時間早く出社して、電子メールを確認するのではなく、優先度の高い作業をやる
  • 最初に、nagios の画面をみてシステムに問題が発生していないか確認する習慣をつける、nagios でアラートが発生したら緊急事態なので通知してくれるクライアントアプリケーションが必要
  • とくにかくやる気がでないときでも、作業に着手してみよう
  • 会議に時間を気にしないようにするため、アラームをセットする
  • これらのツールを仕事以外の時間管にも応用し、日常生活を改善する

OSC Tokyo 2008

今日、知ったが OSC Toyo 2008 第一日目に参加することにした。一番の楽しみは、もちろん OpenBSD、LVS なんか目ではないという噂の relayd の話を聞けるのが楽しみ。そして、BSDなひとときは久しぶりの開催なのであわせて楽しみ。

10:15-11:00 : 仮想化環境におけるベンチマーク結果報告
11:15-12:00 : Networking OSとしてのOpenBSD
13:00-13:45 : Silverlight 2とは何なのか
14:00-14:45 : やってみようシリーズ第2弾 高可用性を持ったiSCSIターゲットをOSSで作る!
15:00-15:45 : BSDなひととき
16:00-16:45 : Geeklog1.5日本語版正式公開! Geeklog1.5で何ができるか
10:15-11:00
11:15-12:00
13:00-13:45
14:00-14:45
15:00-15:45

rubygems のミラーサイトを作る方法 – 其ノ二

前のエントリで、gem コマンドを使うとミラーサイトが作れる方法を紹介したけれど、今日 rubygems 1.1.1 で試したら、次のようなエラーがでてしまった。


$ gem mirror
fetching: http://gems.rubyforge.org/Marshal.4.8.Z
ERROR: While executing gem ... (TypeError)
invalid Gem::Specification format ["1.2.0", 3, "flow", #, Sat Aug 09 07:00:00 +0900 2008, "A Web Server", #=", #]], @version=nil>, #=", #]], @version=nil>, "ruby", [#=", #]], @version=nil>, @name="rev", @type=:runtime>], "flow", "ry at tiny clouds dot org", ["ry dahl"], "A Web Server", "http://flow.rubyforge.org", false, "ruby"]

これは困ったというわけで、RubyForge Mirrors にある rsync による方法で取得することにした。月間 300GB 帯域に制限されているので、 –bwlimit で帯域を制限しないといけない

とは、いっても rubygems のミラーサイトを作るには、yaml と gem を http で公開しないといけないらしいので、実際に gem mirror でどうやっているか、/usr/lib/ruby/site_ruby/1.8/rubygems/commands/mirror_command.rb のソースコードを読んでみたら、gem を gems というディレクトリに入ればいいみたい。

ここで、もしかして rubygems 1.2.0 ならなおっているのかなとリリースノートを読んでみたら、”Marshal Gem::Specification objects from the future can now be loaded.” というバグフィックスがされている!

ということで、rubygems 1.1.1 では gem mirror を使えないので、1.2.0 にアップデートしてから gem mirror を実行すれば問題ないということで…。

ただし、gem mirror を実行すると、途中で gem がないらしきエラーがでるものがあるけどちゃんと実行できた。容量は、2.7GB 程度使っている。

ディスク使用量の警告通知スクリプト

さくらのレンタルサーバを使っていると、どうしてもディスク使用量が気になる。さっきメーリングリストの設定で管理者のメールアドレスを警告を気にせずにメーリングリストのメールアドレスにしたら、fml のログがいっきに 800MB くらいできて驚いた。

そういうこともあるので、800MB くらいディスクを使っていたら、メールで通知するシェルスクリプトを作ってみた。これをさくらのレンタルサーバの管理画面から cron で 1 日に一回登録しておいた。

本来なら、Nagios の NRPE を使いたいところだけれど、レンタルサーバでは無理っぽい。

さくらのレンタルサーバ FreeBSD 4.1 で動作確認済み。


#!/bin/sh

MAILTO='通知先のメールアドレス'
TOTAL_DISK_SPACE=`du -cm $HOME | grep total | cut -f 1`

 

if [ $TOTAL_DISK_SPACE -le 800 ]; then
  echo "disk usage is $TOTAL_DISK_SPACE MB" | mail -s "[alert] disk usage" $MAILTO
fi

あと、業務として使うのなら、HTTP と SMTP の nagios で監視した方がいいと思ったので、あわせて監視設定した。もちろん、nagios は別のサーバ。

GNU screen で起動時にウィンドウ幅がリサイズされるのを防ぐ

GNU screen を使っていると、よく起動時にウィンドウ幅が 80 文字程度に強制的にリサイズされてしまうので、画面サイズが大きい環境で使っているとターミナル画面が小さくなっているので、不便だった。調べてみると、「GNU Screenの起動時やアタッチ時にターミナルをリサイズさせない方法」で回避策が紹介されていた。この記事では、FreeBSD のときとあるが OSX でも同様だった。

僕は、xterm ではなくて、xterm-256color なので、次のように .screenrc に追加した。

  termcapinfo  xterm-256color hs@:is=\E[r\E[m\E[2J\E[H\E[?7h\E[?1;4;6l

 

この文字列の意味がまったく不明だが、これで回避することができたので、しばらくこのままで使ってみる。

オープンソーステクノロジー勉強会

オープンソース勉強会に行ってきた。今回は、いつもとてもお世話になっている SAKURA インターネットさんからデータセンターについての講演でした。データセンターは、最近初めて仕事でも使っているので、タイムリーな話題。資料は、もう公開されています。

  • 都市型のデータセンターの重要が多い
  • 床下空調のときは、小さいものから下にマウントしたほうがいい(実際、大きいものを一番下にマウントしてしまった、、、もちろんスイッチは一番上)
  • 6U 5台のフレームシャーシは、はてなと似ているサーバだった
  • アイルキャッピングは、商標登録で申請中らしい
  • アイルキャッピングは、作業環境としては悪いらしい、ラックの扉をメッシュタイプにする必要があるので中が丸見えになる
  • 1U クォーターシャーシサーバはすごい、密集率
ということで、おもにラックまわりのお話で勉強になりました。あと、VMware や Xen のような仮想化技術の話もしてほしかった。個人的には、VMware がやっている iDC 自体を仮想化する技術というのがよく分からないので週末に調査してみる。

Zmanda Recovery Manager を試してみた

今まで、MySQL のバックアップは自作の cron スクリプトでバックアップをしていたが、ZRM(Zmanda Recovery Manager) という便利そうなツールを知ったので、試してみた。

その前に、現在の MySQL のバックアップ状況を説明しておく。普通の MySQL レプリケーションを組んだシステムで、Master と Slave 1台に、それぞれに自作の cron を使ってバックアップしている。

  • Master 側: flush logs したあと、リレーログを rsync バックアップして一カ月以上の前のリレーログを削除している
  • Slave 側: レプリケーションを停止して、flush tables したあと /var/lib/mysql ディレクトリ以下をまとめて rsnyc バックアップ

今は Master 側と Slave 側のバックアップ時間はほぼ同じなっていることが、さっき問題だと気がついたが、この状態で Master がクラッシュした場合 Slave 側でバックアップしている /var/lib/mysql を使ってから Master 側のリレーログで流し込めば復旧する手はずにした。

しかし、昨日リカバリを試してみたところ、なぜか InnoDB が壊れていてすぐにリカバリをすることができなかった。ここにあるとおり強制的に InnoDB を復旧させるとリカバリされたっぽいが、どうも不安。

というわけで、自作のシェルスクリプトを修正しようと、インターネットを調べていたら ZRM を知ったというのが経過。

ZRM を試してみて問題がなければ、Slave 側のバックアップを ZRM に置き換えたい。

ZRM について日本語の情報はほとんどないが、ZRM の特徴は次のとおり。

  • MySQL のデータをスケジュールしてフルバックアップすることが可能(スケジューラは、ZRM に含まれている)
  • スナップショット経由でのバックアップツール(無料の Community Edition では Linux の LVM のみサポート、有償版では Windows VSS, Solaris ZFS, Veritas VxFS をサポートしている)、mysqldump を使ってのバックアップもできる
  • バックアップできる MySQL のストレージエンジンの制限はない
  • ファイアーウォール越し(プラグインを使って SSH 経由とか)でもバックアップすることが可能
  • MySQL 4.1.x と 5.x に対応している
  • encrypt-plugin を使うと、データを暗号化してバックアップすることができる
  • perl で書かれている

ということで、今導入してようとしているサーバにぴったり。LVM にしていてよかったと思った。

特徴をざっとみたところで、さっそくインストールしてみる。

  • ZRM は、RPM がちゃんと用意されているので RPM をダウンロードする
  • RPM は、フル版とクライアント版があるが、フル版をインストールする
  • 今日の時点での安定最新版は、2.0.1
  • ZRM をインストールするとき、 perl-XML-Parser が必要なので事前に yum でさくっとインストールしておく

RPM で提供されていると、ビルドする手間がないので、とてもありがたい。先日の bacula は、ビルドにとても苦労したので、本当に助かる。頭の中では、FreeBSD だと port で一発なんだけれどもふと思うけれど、Linux なので仕方がない。

環境は、OS は CentOS 5.2 final x86_64 + MySQL 5.0.51b。Slave は、ちゃんとレプリケーションができている状態。

ZRM のマニュアルは、Zmanba Recovery Manager for MySQL Users Manual に詳しくまとまっているので、参考にしながら設定してみる。

ZRM は、MySQL のバックアップツールなので、すべてのコマンドは mysql ユーザで実行する。

  1. /etc/my.cnf に client セクションを追加して、バックアップするユーザアカウントを設定する
  1. ZRM の共通設定ファイルは、/etc/mysql-zrm/mysql-zrm.conf にあるが、変更したパラメータは次のとおり。
    • compress(gzip で圧縮する設定)を 1 にする
  2. ZRM は、「バックアップセット」というバックアップする単位セットを定義できるようになっていて、その設定ファイルを /etc/mysql-zrm/バックアップセット名/mysql-zrm.conf で定義できるので、次のパラメータを追加した、バックアップセットは hoge としておく
    • backup-mode(バックアップするときのモード、raw or logical、logical のときはバイナリログが必要)を raw に設定する
    • host(バックアップ先のホスト)は、もちろん localhost
    • user(バックアップするときに使用するユーザ名)を root にする(localhost でバックアップするためと LOCK TABLES, SELECT, FILE, RELOAD, SUPER 権限が必要なので、バックアップ専用ユーザを作ってもいいと思う)
    • password を設定する
    • database(バックアップ対象のデータベース)をバックアップしたいデータベースに設定する
    • replication(slave でバックアップするときは必須の設定)を 1 に変更
    • retention-policy(バックアップデータのローテーション間隔)を 1M(一カ月)に変更
    • destination(バックアップ先)を変更できるが、デフォルトの /var/lib/mysql-zrm のままにした
    • lvm snapshot でとりたいので、snapshot プラグインと snapshot size を指定した
    • snapshot-plugin=”/usr/share/mysql-zrm/plugins/lvm-snapshot.pl”
      snapshot-size=30G
  3. lvm snapshot のときは、mysql ユーザで lvdisplay とかのコマンドをパスワード入力なしで実行しないと自動的に実行できないので、/etc/sudoers に次の内容を追加する
    • mysql           ALL = NOPASSWD:/bin/mount, NOPASSWD:/bin/umount, NOPASSWD:/bin/d
      f, NOPASSWD:/usr/sbin/lvdisplay, NOPASSWD:/usr/sbin/lvcreate, NOPASSWD:/usr/sbin
      /lvremove

設定ファイルを変更したら、設定ミスがないかどうかチェックする

  • sudo -u mysql mysql-zrm –action check –backup-set hoge

次のように表示されれば問題なし。

check:INFO: ZRM for MySQL Community Edition – version 2.0
neoad:check:WARNING: Binary logging is off.
neoad:check:INFO: Configuration check successful

さっそく、すぐにバックアップしてみる。backup-level というのは、バックアップするレベルで 0 がフルバックアップ、1 がインクリメンタルバックアップになる。インクリメンタルバックアップには、バイナリログが必要。

$ sudo -u mysql mysql-zrm-scheduler –now –backup-set hoge –backup-level 0
schedule:INFO: ZRM for MySQL Community Edition – version 2.0
Logging to /var/log/mysql-zrm/mysql-zrm-scheduler.log
backup:INFO: ZRM for MySQL Community Edition – version 2.0
hoge:backup:INFO: START OF BACKUP
hoge:backup:INFO: PHASE START: Initialization
hoge:backup:WARNING: Binary logging is off.
hoge:backup:INFO: backup-set=hoge


ERROR: /usr/bin/mysql-zrm did not finish successfully

バックアップに失敗した。どうやら、snaoshot を作成できないらしい。

form にあったとおり、手動で lvcreate してみた。

$  sudo /usr/sbin/lvcreate -L30G -s -n zrmS3LYb7LAEu /dev/vg00/lvol1  Insufficient free extents (0) in volume group vg00: 960 required

ああそうか、空き領域がないのか、これはインストールしたときに全部割り当てしまったからだ。。。

うーむ、今から本番稼働しているサーバの lvm 設定を変更するのは、とてもリスクが大きい。

lvm のスナップショットを使ったことがないので、調べてみたところどうやらローカルのバックアップとして使えないらしい。そうすると、当初の目的を達成することができない。

ZRM には、replication という設定があって、slave でのバックアップオプションがあるけれどバックアップするときのポジションなどの情報を取得するためにバイナリログが必要とのこと。stop slave したあと、show slave status で解析すれば分かるけれど perl なのでなおすには時間がかかりそう。。。

ということで、slave 側はシェルスクリプトで slave を止めたあと、mysqldump してバックアップすることにした。

Master 側だとバイナリログは出力しているので、Master 側のバックアップは ZRM を使うといいかもしれない、しかしすでに稼働しているサーバで導入するのはやめておこう。現行のシェルスクリプトで充分だし。

で、それぞれのバックアップ用のシェルスクリプトを bacula と連携できるように頑張ってみよう。

私はこうして受付からCEOになった

カーリーさんの「私はこうして受付からCEOになった」を読んだ。大企業の CEO の本を久しぶりに読んだけれど、とても面白くて食いついて読みました。

この本でいくか、心に残った言葉を残しておく。

  • P.17「私の人生は、私のもの。やりたいことをやらなければ。」
  • P.38「信念があれば、そのうちきっと誰かに通じること。ベストを尽くせばチャンスの扉は開かれること。」
  • P.116 「酒席の付き合いは人と親しくなるよい方法だと、いまでは私は考えている。…郷に入っては郷に従う。相手の習慣になじむことは、共通の理解を深める大きな一歩である。」
  • P.130「つまりリーダーは医師のようなものだ。対処療法をするのではなく、病気の根本原因を見つける。」
  • P.165「ねえ、もしかしたらあなた、いつかヒューレット・パッカードのCEOになるかもしれないわね」なぜ母はそんなことを言ったのだろう。二人の話題に上がったことすらなかった。私は笑い飛ばした。
  • 急進的なアイディア、奇想天外なアイディアは、悪いアイディアではない
カーリーさんの常にその場でベストを尽くすという姿勢はとてもすばらしいことだと思うし、僕もそうでありたい。
そして、何よりも大事なのは自分のやりたいことをする。さらには、愛する人たちと幸せな生活を送ることが、人生の幸せなのかもしれないとふと感じた。

symfony で独自のタスクを作ってみた

最近というかいつの間にか、なぜか仕事で symfony を使って開発をしていますが、symfony の propel-init-admin タスクで自動生成させる action のスケルトンをカスタマイズしていくうちに、標準の propel-init-admin タスクだと、モデル変数名を展開してくれなくて、不便になってきた。

{$sf_symfony_data}/tasks/sfPakePropelAdminGenerator.php をみてみると、次の変数しか展開してくれない。


$constants = array(
'PROJECT_NAME' => $task->get_property('name', 'symfony'),
'APP_NAME' => $app,
'MODULE_NAME' => $module,
'MODEL_CLASS' => $model_class,
'AUTHOR_NAME' => $author_name,
'THEME' => $theme,
);

そこで、次のように追加して、propel-init-admin-plus という独自のタスクを定義してみた。変更したのは、次のところだけ。sfInflector というクラスの存在を調べるのが、すこし大変だった。


$constants = array(
'PROJECT_NAME' => $task->get_property('name', 'symfony'),
'APP_NAME' => $app,
'MODULE_NAME' => $module,
'MODEL_NAME' => sfInflector::underscore($model_class),
'MODEL_CLASS' => $model_class,
'AUTHOR_NAME' => $author_name,
'THEME' => $theme,
);

こうすることで、##MODEL_NAME## となっている部分を自動的に展開してくれて、updated タスクなどを定義できるようになって、かなり便利になった。具体的な、action クラスのスケルトンは、次のような感じにしています。


/**
* ##MODULE_NAME## actions.
*
* @package ##PROJECT_NAME##
* @subpackage ##MODULE_NAME##
* @author ##AUTHOR_NAME##
* @version SVN: $Id: actions.class.php 2288 2006-10-02 15:22:13Z fabien $
*/
class ##MODULE_NAME##Actions extends auto##MODULE_NAME##Actions
{
protected function save##MODEL_CLASS##($##MODEL_NAME##)
{
parent::save##MODEL_CLASS##($##MODEL_NAME##);
}

protected function delete##MODEL_CLASS##($##MODEL_NAME##)
{
parent::delete##MODEL_CLASS##($##MODEL_NAME##);
}

protected function update##MODEL_CLASS##FromRequest()
{
parent::update##MODEL_CLASS##FromRequest();
}

 

protected function get##MODEL_CLASS##OrCreate($id = 'id')
{
return parent::get##MODEL_CLASS##OrCreate($id);
}

 

この独自のタスクは、symfony のプロジェクトディレクトリの data/tasks ディレクトリを作成して、その中に入れるだけで使うことができるので、かなり便利になった。

ソースコードは、coderepos に置いたので自由に使ってください。

symfony を使っていて分からないことがあったら、ぐぐるよりも symfony のソースコードを探検したほうが比較的楽に調べるということが分かってきた。

  • 1
  • 2