yohgaki's blog

追記：会場が変更されました。旧：66会議室、新：61会議室。参加者が予想より多いため大きな会議室になりました。

毎年四国で行っているオープンソース（特にPostgreSQL）とコンピュータ関連の話題をテーマに無料セミナーを行っています。今年も6/28(土曜)に高松市にて行います。

本年度でJPUG四国支部 担当理事を山下さんに交代したので、次のオープンセミナーからは山下さんが取りまとめ役を行います。

JPUGサイトのセミナーの告知文
http://www.postgresql.jp/branch/shikoku/300c30aa30fc30f330bb30df30ca30fc2008-56db56fd300d958b50ac306e304a77e53089305b

セミナー告知用のテンプレートです。興味がある方、ML等にお知らせ頂けると助かります。

○○@□□です。

「オープンセミナー2008@四国」開催のご案内をさせて頂きます。

2008年6月28日（土）にサンポート高松（香川県高松市）にて開催します。
参加費無料です。是非ご参加頂きますようお願い致します。

このメールは転送自由です。ご興味があると思われる方、メールリストに転送
頂ければ幸いです。

---------------------------------------------------------------

　　　　　　　「オープンセミナー2008@四国」　開催のお知らせ

　　　　　　　　　　　　　　　　　　　　　　　主催：
　　　　　　　　　　　　　　　　　　　　　　　NPO法人 日本PostgreSQLユーザ会
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　瀬戸内Linuxユーザ会
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　四国BSDユーザ会
　　　　　　　　　　　　　　　　　　　　　　　協力：
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　日本UNIXユーザ会

「オープンセミナー2008@四国」は毎年技術者向けにオープンソースとインターネットを
テーマとして開催している無料セミナーです。昨年は「オープンセミナー2007@四国」、
「オープンセミナー2007@徳島」としてそれぞれ7月と11月に開催されました。2008年
もオープンソースとインターネットをテーマに香川県高松市にて無料セミナーを開催致し
ます。事前登録は必要ございません。プログラミング、セキュリティ、オープンソースや
インターネットに興味をお持ちの技術者、管理者、学生の皆様をお待ちしています。

セミナーに使用する会議室の定員は30名です。定員を超える可能性もあります。定員を超
えた場合、立ち見となる場合がございます。お早めにお越し下さい。

当日夜に高松駅近辺にて懇親会も予定しています。予約を行うため懇親会の参加には申し
込みが必要です。懇親会に参加をご希望の方は問合せ先にEメールでご連絡下さい。
（メール末尾を参照）

　　　　　　　　　　　　　　　　　　記

オープンセミナー2008@四国 − 四国で学べるオープンソースとインターネットの世界

主催：　　日本PostgreSQLユーザ会（JPUG)
　　　　　瀬戸内Linuxユーザ会（STLUG）
　　　　　四国BSDユーザ会（S*BUG）
協力：　　日本UNIXユーザ会 (JUS)
開催日： 2008年6月28日 13:00 〜 18:00 (12:50受付開始)
開催場所：サンポート香川ホール棟6F 61会議室
http://www.sunport-hall.jp/shisetu/kaigi.htm
アクセス： JR高松駅より徒歩1分
懇親会： JR高松駅近辺

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
13:00 - 13:10 開会のご挨拶

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
13:10 - 14:00 KOFの過去、今、これから
講師：中野秀男 大阪市立大学 学術情報総合センター 所長・教授/
　　　　　　　 大学院創造都市研究科 教授、KOF実行委員長
　　 法林浩之 日本UNIXユーザ会 副会長、KOF実行委員

近年ソフトウェアコミュニティの活動が各地でさかんになっていますが、関西では
「オープンソースならびにコミュニティが元気に交流できる場を、関西でも作ろう」
という目的の下に集った有志により、「関西オープンソース＋関西コミュニティ大決戦」
(通称KOF)を2002年から開催しています。

本講演では、今年7年目を迎えるKOFの活動について、これまでの経緯、活動の経験
から得たもの、今年の予定、そして今後はどういう方向に向かっていくのかをお話し
します。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
14:10 - 15:00 PG Cluster
講師：三谷 篤 株式会社SRA西日本/日本PostgreSQLユーザ会

PostgreSQLは本格的なオープンソースRDBMSと広く利用されています。PostgreSQL 8.3
では更なる高速化など大規模システムに欠かせない機能が追加されています。対規模DBに
はクラスタリングソリューションが欠かせませんが、PostgreSQL本体にクラスタリング
機能は組み込まれていません。

本講演では、PostgreSQLのクラスタリングソリューションとして実績を積んでいるPG
Clusterの技術と最新動向を紹介します。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
15:10 - 16:00 最新セキュリティ事情
講師：片山 昌樹 有限会社マギシステム

各地で発生している様々なインシデントについて、最新の情報を交えつつ紹介します。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
16:05 - 16:35 ライトニングトーク

1人5分程度でユーザ会や技術動向などを紹介するコーナーです。
ライトニングトーク講師を募集中です。コンピュータやインターネットに関連する
事であればテーマは自由です。応募される方は yohgaki@ohgaki.net までご連絡く
ださい。お待ちしております。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
16:40 - 17:30 Rails 2.1
講師：吉田 和弘 日本Rubyの会, 株式会社ミッタシステム 取締役

RailsはWeb開発の現場でも広く利用されるようになりました。Rails 2.1では新機能が
数多く盛り込まれています。特にO/Rマッパ(ActiveRecord)の新機能についてご紹介し
ます。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
17:40 - 18:30 JavaScriptで書かれたPIC-BASICエミュレータ
講師：白石 啓一 詫間電波工業高等専門学校

PIC基板を持ってなくともPIC-BASICプログラミングを楽しめる環境を作るため，Web
ブラウザに実装されたJavaScriptでPIC-BASICエミュレータを実装しました。本エミュ
レータの設計や実装方法を紹介します。

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
18:30 閉会のご挨拶

----
日本PostgreSQLユーザ会 http://www.postgresql.jp/
瀬戸内Linuxユーザ会 http://www.stlug.org/
四国BSDユーザ会 http://www.bbsbrain.ne.jp/~sbug/
日本UNIXユーザ会 http://www.jus.orjp/

問い合わせ先：
日本PostgreSQLユーザ会 四国支部 （株式会社Result内）
四国支部長： 山下 武志　TEL: 087-832-5527
メール：tyama@mbp.ocn.ne.jp
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

懇親会費は約4000円を予定しています。会場から徒歩で移動可能な居酒屋などを
予定しています。懇親会参加をご希望の方は以下のメールをお送りください。
.....................................................................
To: tyama@mbp.ocn.ne.jp
Subject: [オープンセミナー2008@四国 懇親会 参加申込]
--------------------
※ 氏名(ふりがな)： ( )
　所属：
　連絡先郵便番号:
　連絡先住所：
　Tel:
　Fax:
※ E-Mail:

注1 先頭に"※"がある項目は必須項目です。他はオプショナル項目です。
.....................................................................

PostgreSQLカンファレンス2008が今週金曜日(6/6)に開催されます。

http://www.postgresql.jp/events/postgresql-conference-2008

例年通り参加費が必要ですが懇親会費込みです。

参加費：
カンファレンス ならび に懇親会 4,000 円
チュートリアルも含むカンファレンス ならびに 懇親会 10,000 円

今回のカンファレンスの目玉は色々ありますが、その一つはチュートリアルセッションです。まだ、空席が残っているようなのでライセンスもBSDでMySQLよりも使いやすいPostgreSQLを始めてみたい方には良いチャンスだと思います。新人研修の一環としても良いと思います。

* MySQLユーザのためのPostgreSQL入門
（リナックスアカデミー 学校長 濱野 賢一朗 氏）

興味がある方は是非カンファレンスにお越し下さい。

PostgreSQL 8.3.0から、ユーザから提供されている追加機能（contrib）として利用できた全文検索機能（TSearch2）が本体に取り込まれました。

本体に取り込まれたため、PostgreSQL 8.3.0以降ではソースから構築する場合に

./configure
make
make install


と実行するだけで全文検索機能が利用できるようになりました。

Read more »

2月16日に札幌で行われたJPUG北海道 RUBY札幌 合同セミナーの資料です。

http://blog.ohgaki.net/media/users/yohgaki/PostgreSQL-Performance.pdf

セミナーの際には風邪の為、声がでず、非常に聞き辛かったと思います。聞きにお越しいただいた方には申し訳ないです。

fsync=falseなのでかなり速い事は理解していただけたと思います。（かなりのスピートダウンですがfsync=trueでも速いです）セッションをデータベースで管理した場合などにfsync=falseで運用しても問題ないでしょう。しかし、絶対にデータベース上のデータの不整合は困る場合にはfsync=trueに設定しなければなりません。

とは言ってもfsync=falseの速さは捨てがたいと言う方はUPSを利用すると良いでしょう。UPSを付ければリスクはかなり低減できるので、リスクとメリットのトレードオフで選択すれば良いと思います。

UPSを使っても防げないデータの不整合

• カーネルがクラッシュした場合
• HDDのケーブルが抜けたなど、物理的問題の場合
• 電源が壊れた場合（これも物理的な問題ですが、2重化すればかなりリスク低減可能）
• HDDの冗長化を行っていない場合（RAID組まずにデータ保護の為にUPS使っても....ですが念のため）

等が考えられます。

HDDの冗長化を行っていないサイトのデータベースであれば、fsync=falseが困る訳も無いでしょう。このような場合はfsync=falseでどんどん使ってよいでしょう。

fsync=falseはデータベースサーバ全体の設定なので結局は「ショッピングサイトなどでどんな場合でも受注済みデータが無くなると困る」のような要求があるとfsync=falseで運用できないのでは、とご意見も頂きました。このような場合でもログを別の方法で残す、例えば、メールで送信してしまう、別ディスクにジャーナルとして書き込む、など方法でデータ保存の方法を冗長化していればfsync=falseでも困らないサイトは少なくないと思います。そうは言っても、困る物は困る場合はfsync=trueで利用すると良いでしょう。

データベースに拘らずデータの冗長化を考えると、fsync=falseは強力な武器になります。

# PostgreSQL 8.3ならsynchronous_commit=offに設定してリスク
# を軽減する事も可能です。ところで、別ディスクにジャーナル
# として保存する場合はDBよりも先にジャーナルファイルに書き
# 込み、fsyncを忘れない様に注意してください。
# メール送信する場合はリモートのメールサーバが受け取った後
# にDBに書き込むように注意してください。つまりローカルのメー
# ルキューにいれるのみだとジャーナルのように使えない場合が
# あります。qmailならinjectが正常に終了すればOKだとは思い
# ますがメールシステムによっては高い信頼性を期待できない場合
# もあります。

2月16日(土)に、日本PostgreSQLユーザ会(JPUG)北海道支部とRuby札幌の合同セミナーが開催されます。

日本PostgreSQLユーザ会北海道支部 / Ruby札幌　合同セミナーのお知らせ

私も講師の一人として参加させて頂きます。PostgreSQLとMySQLのベンチマークについて話す予定です。ご都合がよい方はお越しください。

有料と聞いていないので無料セミナーだと思います。アナウンス文には無料と記載されていないので主催者に問い合わせてみます。

追記：
現在は無料であることがアナウンス文に追加されています。

PHPのSQLインジェクションを実体験
http://www.thinkit.co.jp/free/article/0801/5/2/
を書かせて頂きました。この文字エンコーディングを利用した攻撃は古い脆弱性です。知っている方なら2年以上前からよくご存知とは思います。

記事のタイトル通り、文字エンコーディングを利用したSQLインジェクションを実体験できます。ご興味のある方、まだご存知でない方はぜひご覧ください。

万が一、文字エンコーディングベースの攻撃に未対策で攻撃される可能性のある方はできるだけ早く対策することをお勧めします。

http://people.freebsd.org/~kris/scaling/7.0%20Preview.pdf

にFreeBSD7上でのPostgreSQLとMySQLのベンチマークが載っています。

PostgreSQL 8.2.4 - 11ページ

ピーク性能でおよそ5400transactions/secほど。

MySQL 5.0.45 - 15ページ

ピーク性能でおよそ3800transactions/secほど。

Kernelの主要な部分すべてがパラレルに動作するようになったため、かなり高速（数値にして数倍）になったようです。

グラフからもPostgreSQLの方がかなり良い性能であることが分かりますが、PDFファイル（16ページ）によると

On this benchmark PostgreSQL is 35% - 45% faster thanMySQL at all loads

とPostgreSQLの方が全般的に良い性能だったそうです。PostgreSQL 8.3は確実に8.2よりもさらに良い性能を期待できると思います。MySQLも5.1や6.0を利用した方が良い性能が期待できるのかも知れません。

このPDFのベンチマークはデータベースの性能を計る為のベンチマークではなく、OSの性能を計る為のベンチマークです。データベースサーバ設定、SQL文やテーブル構成などが不明なのでデータベースの性能のベンチマークとしては参考値くらいでしかありません。MySQLのテストではMyISAMを使っていると思われますが、MyISAMならこれくらいの性能差は普通です。

http://www.securiteam.com/unixfocus/6N00D0AKKM.html

に解説されている脆弱性は基本中の基本です。

Most database query in WordPress uses escape() method to sanitize SQL string, which is essentially filtering input via addslashes() function. However addslashes() fails to consider character set used in SQL string, and blindly inserts backslash before any single quote, regardless of whether such backslashes will form another valid character or not.

addslashes()によるエスケープは行ってはならない、とよく言っていますがWordPressでさえaddslashes()を使っていたのですね。WordPressはUTF-8だけでなくGIB5とか使えるのですね。WordPressをSJISを使っている方は同じ脆弱性があるので要注意です。

本質的には私のブログでも指摘している脆弱性と同じ種類の問題です。

追記
CVEが出てます。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6318

(1) Big5, (2) GBK, or possibly other character set encodings that support a "\" in a multibyte character.

BIG5, GBKエンコーディングが影響を受け他の文字に¥が現れる文字エンコーディングにも影響があると思われる、と書いてあります。つまりSJISが該当します。

対策を書いておきます。

• データベースを正しい文字エンコーディングで作成する
• アプリケーションからデータベースやクライアント文字エンコーディングを変更する場合、データベースのAPI(pg_client_encoding, mysql_set_charsetなど)を利用する(SQL文で変更しない)
• 文字列をデータベースクエリ用にエスケープする場合はデータベースAPIを利用する(pg_escape_string, mysql_real_escape_stringなど)

別の対策として、プリペアードクエリを利用する方法もあります。

壊れた文字エンコーディングの文字列を無理矢理扱えるようにする方法があります。しかし、壊れた文字エンコーディングを扱えるようにするとアプリケーションや環境に存在する未知の脆弱性により攻撃可能になるかもしれないリスクがあります。壊れた文字エンコーディングを扱えるようにするのではなく、既にあるデータは綺麗にして、新しい文字データは全て正しい文字エンコーディングであるように入力時にバリデーションすべきです。

最近のPostgreSQL, MySQL, SQLiteのパフォーマンスはどうかな?と言うことで非常に簡単なベンチマークをしてみました。

デフォルト状態のデータベースに郵便番号データ（12万件とちょっと）をINSERTしてみました。フラグを除く全てのフィールドをテキスト型として定義し、全てのフィールドを挿入しました。旧番号と現行番号にインデックスを付けています。スクリプトはPHPで記述し、DBが動作しているPC上からPHP 5.2.4で実行しました。1レコードが分割されている場合などは無視して挿入しているので12万2000レコードになりました。

PC

CPU: PentiumD 2.8GHz
Memory: 3GB
HDD: PATA

DBMS

MySQL: 5.0.45
PostgreSQL: 8.2.4
SQLite: 3.4.0 (PDO)

実行結果(12万行INSERTの実行時間）

InnoDb: 130.70663690567
MyISAM: 131.24672317505
Postgres: 159.47350597382
SQLite: 676.43534302711

MySQLもPostgreSQLもチューニングは一切無しで実行しています。

非同期クエリを利用するとPostgreSQLもInnoDb, MyISAMと同じくらいの速度になりました。

どのDBもペンチマーク中はディスク待ちの状態でCPU時間はあまり使っていませんでした。

MySQLとPostgresは概ね予想通りの結果でしたが、SQLiteが異常に遅いのでPDOを使わないで計測してみましたがあまり変わりませんでした。トランザクションかな？と思いBEGIN, COMMITを付けてみましたが変わりませんでした。

INSERTしたレコードをランダムにSELECTしてみました。番号はmt_rand関数で生成したのでほとんどがINDEXにヒットしないので、インデックスを利用した検索の最悪のケースのテストになります。単純にテーブルから検索をするだけです。永続的接続を利用しています。

Webサーバ：Apache 2.2.6
クライアント: ab -n 10000 -c 10　（別PCから実行。Athlon64 3500+/3GBメモリ）

パフォーマンス：リクエスト/秒

Postgres: 947.58
SQLite: 1096.00
MySQL(MyISAM): 1190.35
MySQL(InnoDb): 1245.85

概ね予想通りの結果ですが、SQLiteが思っていたより遅いです。PostgreSQLは接続のネゴシエーション処理が重いので非永続的接続を利用するとかなりパフォーマンスが落ちます。システム全体でDBへの接続数を上手に制御できていない場合はpgpoolを利用するとパフォーマンス（システム全体のスループット）が改善することがこの事からも分かります。

「Postgresでこんな数字でないよ」という方、pg_pconnectで試してみましょう。コネクションプーリングが無いと話になりません。

MySQLには文字エンコーディングを変更する「SET NAMES」SQL文が用意されています。（PostgreSQLも同様のSQL文、SET CLIENT_ENCODINGがあります）この機能はSQLコンソールからは使ってよい機能ですが、アプリケーションからは使ってはならない機能です。SQLインジェクションに脆弱になる場合があります。

Ruby on Railsの本を読んでいて、ActiveRecordを説明している部分にMySQLの文字エンコーディングを変更する場合の例としてSET NAMESが利用されていました。アプリケーションからはSET NAMESは使ってはならない事を周知させるのは結構時間が必要かなと思いました。

PHPも5.2の途中からMySQLモジュールにlibmysqlの文字エンコーディング設定APIのラッパー関数が追加されていたりするので、たまたま最近読んだRoRの本だけでなく、多くの開発向け情報ソースにSET NAMESを利用した例が載っていると思います。

ストアドプロシージャだけ使っていれば安全ですが、アプリケーションからDBMSの文字エンコーディングを設定する場合、SQL文ではなく必ず文字エンコーディング設定APIを利用するよう紹介しなければならないです。MySQL4はストアドプロシージャが使えないので、フレームワークなどではエミュレートしています。ストアドプロシージャだけ使って防御している「つもり」で防御になっていない場合もあります。これもフレームワークを使っていてもアプリケーションが脆弱になる良い例ですね。

脆弱性の説明は面倒ですが注意事項は簡単です。「DBMSをアプリケーションから利用する場合、文字エンコーディング設定は必ずAPIを利用する」つまり「SET NAMES（SET CLIENT_ENCODING等も)は禁止」です。