MYCOMジャーナルで紹介されていた Execute Query を試してみる。
これは便利! MySQL/PostgreSQLにも対応 - RDBMS操作ツール"Execute Query"
http://journal.mycom.co.jp/articles/2006/09/22/executequery/
このツールのダウンロードは
http://executequery.org/download.jsp
から行なえる。今回も Debian(sid)にインストールしてみる。ここでは
eqsetupj-v3.0final.jar (Java installer - any OS)
とやらを選択。Java 1.5系じゃないと動かないらしいので
$ export JAVA_HOME=/usr/lib/j2sdk1.5-sun/
$ sudo /usr/lib/j2sdk1.5-sun/bin/java -jar eqsetupj-v3.0final.jar
としてインストーラーを起動。普通にインストールすると
/usr/local/share/executequery
にインストールされる。起動用のシェルスクリプトが用意されているので
$ /usr/local/share/executequery/eq.sh
で実行する。ただ、default のJAVA_HOMEが Java 1.5 に向いてないので、以下のように書き換え。
#!/bin/sh
# Java heap size, in megabytes
JAVA_HEAP_SIZE=128
# default java location
# change this to point to the local java installation
DEFAULT_JAVA_HOME="/usr/lib/j2sdk1.5-sun"
if [ "$JAVA_HOME" = "" ]; then
JAVA_HOME="$DEFAULT_JAVA_HOME"
fi
exec "$JAVA_HOME/bin/java" -mx${JAVA_HEAP_SIZE}m -jar "eq.jar" &
これで JAVA_HOMEが設定されていなくても、上記のスクリプトだけで起動できる(もちろん、/usr/lib/j2sdk1.5-sun に Java-1.5 が事前に導入されている必要はある)
$ /usr/local/share/executequery/eq.sh
Unable to access jarfile eq.jar
だめだった orz
うーん、/usr/local/executequery に移動して起動することが前提になってるのか……さらに
#!/bin/sh
# Java heap size, in megabytes
JAVA_HEAP_SIZE=128
# default java location
# change this to point to the local java installation
DEFAULT_JAVA_HOME="/usr/lib/j2sdk1.5-sun"
if [ "$JAVA_HOME" = "" ]; then
JAVA_HOME="$DEFAULT_JAVA_HOME"
fi
cd /usr/local/share/executequery
exec "$JAVA_HOME/bin/java" -mx${JAVA_HEAP_SIZE}m -jar "eq.jar" &
に書き換えた。
動いた :-)
これだけだと実はだめで、ちゃんとドライバも用意してやる必要がある。PostgreSQL ならこんな感じ
# apt-get install libpg-java
これで、一番左の
Drivers を選択して、JDBC Driversの一覧を表示させ「ODBC Driver」のところで右クリックか
をクリックして、「New Driver」を追加し、以下のような感じで設定。
この状態で、「Connections」に戻って、普通に User/Pass, 接続先, DB名などを指定してやると繋がる。
既存のDBからER図も生成できて面白いね :-)
ただ、やっぱりMYCOMジャーナルの記事でもあったように、ドライバの設定が億劫かなぁ? Javaの知識がある程度ないと使えないのは辛い(^_^;
PostgreSQLでパラレル・クエリを可能にするpgpool-II,無償公開
http://itpro.nikkeibp.co.jp/article/NEWS/20060908/247609/
最近は MySQL を扱う案件が多いとはいえ、ちゃんと見とかないとね。
PostgreSQL に関する MIB を返してくれる SNMPエージェント
まだ試してないけど、よさげ :-)
PostgreSQL のログを解析してくれるツール。
http://pgfouine.projects.postgresql.org/
Query とかが記録されたログを食わせると、html のレポートを出力してくれる。
http://www.postgresql.org/docs/techdocs.50
via http://lwn.net/Articles/184760/rss
via http://traiss.tabesugi.net.nyud.net:8090/lwn.html
今日はこれで半日は潰れた……どうも単純なアップデートだと、アプリケーションによっては痛い目を見る気がします。
取るべき対策は
1. PostgreSQLサーバのアップデート
2. クライアント側のドライバのアップデート
3. いくつかのアプリでは、改修も必要
こんな感じでしょうか?
目を通しておくべきドキュメントは
http://www.postgresql.org/docs/techdocs.52
からリンクのある
FAQ
User's Guide
Technical Information on the Security Hole
の3つ。
このアップデートで、PostgreSQLサーバには
1. UTF-8, SJIS などマルチバイトなエンコードで、不正な文字コードをきちんとチェックするようになった。
2. default で、文字コードが SJIS, BIG5, GBK, GB1803, UHC の場合、エスケープ文字として "\" が使えなくした。
の2つの変更が加えられています。特に後者が曲者で、SJIS を使っており、なおかつエスケープ文字として "\" を利用しているようなアプリを書いてると、該当部分の書き直しが必要になるようです(あってるよね?)
ちなみに、このエスケープ文字の挙動に関しては
* backslash_quote = on : Allow \' always (old behavior; INSECURE
* backslash_quote = off : Reject \' always
* backslash_quote = safe_encoding : Allow \' if client_encoding is safe
こんな感じで、以前の挙動に戻せたりするらしい。ちなみに前記したように、default の挙動は
backslash_quote = safe_encoding
だそうです。
アプリが動かなくなった!とか、クライアント側のドライバのアップデートが抜けてた! とかありそうな話だ……
ちなみになぜマルチバイトエンコードを利用して、SQL Injection が可能となるのか? それについては、上でも挙げた
Technical Information on the Security Hole
に、非常に詳しく書いてあるので、ご一読をお奨めします。そっか表か……
http://www2b.biglobe.ne.jp/~caco/pgpage/jisx0213.html
PostgreSQLでは(8.1現在),JIS X 0213はサポートされていません.このページでは, PostgreSQLでJIS X 0213をサポートする際の問題点などを検討します.
via http://ogawa.s18.xrea.com/tdiary/20060331.html#p03
http://www2b.biglobe.ne.jp/~caco/pgpage/index.html
WEB+DB PRESSの連載記事のPDFを公開しました
とのこと。PostgreSQL研究所の記事がすべて PDF で公開されていますね。
ありがたや :-)
via reddit