Tag Archives: MySQL

バージョン違いMySQLの同居

同じバージョンのMySQLを2台同じサーバーに入れたりというのは開発環境でやったことがあるのですが、双方とも自動起動してバージョン違いかつ文字コード違いという環境は初めて入れた。結論としては自動起動スクリプトがまるで複数導入を想定していないというのが分かったくらいかな。

やってみた構成はこんな感じ。
  • rpm版同士での複数インストール
    これは普通に競合するのでNG
  • 既存のMySQLクライアントとPHP-MySQLコネクタを残して、MySQL公式サイトのrpm最新版(Serverのみ)をインストール
    これも競合。MySQL公式サイトのものはServerとClientで2つに分けているが、RedHat公式のMySQLはServerとClientとその両方で使う無印パッケージの3つ分かれ、無印とMySQL公式のパッケージで競合を起こす。
  • 既存はrpm版で別途ソース版を入れる
    これは問題なし、自動起動スクリプトは改造が必要
  • 既存がソース版で別途インストールもソース版
    問題は無いがソース版同士なので全ての設定を別に分ける必要が出てくる。自動起動スクリプトは改造が必要。
自動起動スクリプトの改造が必要なのは、configureの設定内容を無視しているのでそのまま使えばデフォルトの構造でmy.cnfやpidファイル、sockファイルを探しに行くという恐ろしいワナがある。結局自動起動スクリプト上のmysql_safeコマンドの行に–defaults-file=[my.cnfのパス]で設定が必要。ちなみにこのオプションは最初に記述しないとエラーになります。他にはDBの初期化(mysql_install_db)をするときに既存のDBを破壊しないように念のためバックアップを取った上でオプションでdatadirやdefaults-fileを設定し回避すること。これは理由がわからないのですがスレーブ用に構築する予定のDBで初期化するときに最初からmy.cnfよりbin-logを抜いていたらエラーになった。これは初期化にはバイナリログが必要だったのか、中途半端なコメントがまずかったのかは不明。別に初期化の時にバイナリログが出されてもたいしたこと無いので別に良いのですけどね。
参考
またレプリケーションも本格的に負荷分散しようとしたら参照系で不要なDBやテーブルを持ってきたくないという事がありました。こちらの設定はスレーブ側のmy.cnfの[mysqld]内に
replicate-do-table=dbname.table
replicate-do-db=dbname
といった感じで追記するだけ。
また文字コードの設定で[mysqld]内に
default-character-set = utf8
だけでなく
skip-character-set-client-handshake
を設定するとPHPから接続したときにいちいち「SET NAMES」を設定しなくても良くなるし、他のセクションにdefault-character-setを入れなくても文字コードが統一される(status;やshow variablesで確認)。
[MySQL] 特定データベース、特定テーブルを指定したレプリケーション設定 | 半袖野郎 blog.hansode.org
あと大きなバッチを使うときに気になるのがメモリ使用量なのですが、折角1行ずつ取り出すのに一斉に配列に入れようとするのはセンス無さ過ぎで見つけ次第指導するレベルなのですが、また全件必要でないのにどうせ詮索スピード変わらないからという理由でLIMITを使わないのもメモリの事を考えてない証拠なのでこれもダメ、でもまさかmysql_query関数の結果が一旦全部メモリにキャッシュされるとは思わなかった。PHP上ではどう見てもメモリが溜まるような処理を書いてないのにメモリ不足になるのはこれのせいだった。そのときはmysql_unbuffered_queryを使いましょう。mysql_unbuffered_queryの制約としてはmysql_data_seekが使えないことや全ての行をフェッチする必要があるという事なので件数の絞込みはしっかりLIMITで設定しましょう。スピードは多分遅くなると思いますがバッチ等では消費メモリの上限を抑えられない方が問題なので。
PHP:SQLクエリのメモリ消費量を抑える:mysql_unbuffered_query

Cookieを使ったSQLインジェクション

最近Cookieを使ったSQLインジェクションが発見されたということでその手法の詳細記事がありました。前置きが長すぎてもっと簡潔にして欲しかったのですが問題点は以下のようになります。

  • メジャーな侵入検知システムはPOST/GETの検査を行うがCookieを見逃していた。
  • スクリプト側でPOST/GET等メソッドを明示的に区別してデータ取得していない。
  • スクリプト側で入力データの検査が出来ていない。

元記事には

ここまで聞くと、「うちのサイトではクッキーにデータベースに関連するような情報は格納していないから関係ない」と、早合点する人もいるかもしれない。それは間違いなので、もう少しお付き合いいただきたい。

なんて書いてるからよくよく読んでみましたがCookie使う以前の問題で仕事でウェブプログラミングしているならその会社のスキルを疑って良いレベルです。PGのスキル不足は常にあると仮定してもレビューせずに素通りかPLが無能。PMが放置主義って言ってる様なもので会社でレベルで恥かいてるぞ。私ならこんな杜撰なコード組む会社に2度目の外注はしない。

まずコードの品質を上げる前に侵入検知システム等に頼るのは気が進まないし費用のムダ。これの方法の恐いのは侵入検知システム自体に穴がある場合だけでなく、サーバー移設等環境が変わった場合にミスが起きやすい。ニュースで「サーバーの設定ミスで情報漏えい」というケースがこれ。

次にデータ取得においてメソッドを区別していないのはCookie以前の問題でGETしか想定していないスクリプトでPOSTで渡されてもスクリプトのみでは同じ問題が起きるので注意すること。昔Perlで外部ライブラリなしでコーディングしているときは非常に面倒だと思いつつもどうやってデータがウェブサーバに送られてくるのか勉強になりました。今時よく利用されるASPやPHPはその辺の面倒な処理を自動的にやってくれて組込関数グローバル変数から読み込めますがRequest系の実装は気持ち悪くて使えない。未だにRequestについてGET/POSTを気にせずどっちでも使えるから便利とか発言するPGを見かけるが変数名が重複したときの対処方法を考えていないのが大半。セキュリティはともかくバグの元になる事を想定できていない。そういう人に限ってデバッガ未経験だったりする。

あとニュース記事には書かれていませんがPHPの場合、Requestでなくても$_POSTや$_GETのみで変数を上書きできるから注意ですね。通常リスト構造のデータを受け取るときは配列型にしたほうが便利ですが、それをせず同じ変数名で並べて送ってくるフォームがありそれにも$_POSTや$_GETは対応できないのでPerlの時のように素の入力データから抽出しています。それと同じ方法で本来の変数を上書きされても発見できない場合がありますので注意です。

最後に入力されたデータを検査していないのは論外、今回のセキュリティホールもPOST/GETを想定した変数だとしてもスクリプト側で検査していれば問題になっていない。メソッドを明示していればCookie経由で上書きしようとした変数はその場でイジェクトできるし、Request受けていてもそのデータを検査できていれば良いのである。とは言っても現実はApacheエラーログを見ずに組む人が多い、サニタイズどころかValidateやisset検査すらせずにエラーログを汚しまくる奴もいる。指摘するとErrorじゃなくてWarningだから大丈夫だろうとか言葉を理解できていない人やErrorじゃ無いんだからサーバー側でログ出力止めろよ!と逆ギレする民度の低いPGも少なからず存在する。そういうのに限ってこれまたPHPはPerlと違ってセッション実装できているから凄いとか内部処理を知らずに自慢(それもPHP作った本人じゃないのに)していたことがあって呆れたこともあります。

以上で愚痴込みのまとめは終わりますが、元記事を見てハッと気付いた脅威が一つありました。
最低限の作業として送られてくるデータは特定して検査するように書いているつもりですが、セッション変数はサーバーに保存されているデータなのでそこまでは強制的に検査していませんでした。(ヒマがあればするけれど他人にまで強制していない)

これの何が原因かというと、一度送られたフォームデータ(特にショッピングカート等)は途中ページでの改ざんを防ぐ為にセッション変数として保持することがありますが、保存したセッション変数からデータを再取得するときに検査をしていない場合がありました。近年はCookieに値セットして使うことが無いので完全な見逃しですが、Cookieを改ざんされた時に$_SESSIONが自動的に汚染されないか確認したことが無かった・・・。これは週明け直ぐにでもチェックしてみます。

他にDBとの入出力に対しての検査も、最初はそこまでする必要あるのかな?と思っていましたが仕事で使う内に必須だと思うようになりました。セキュリティ的には外部と接触する部分で一斉検査すれば大体良いのですが、開発途中でDBのデータがいい加減に入力されているとか仕様外の構成になっていたりするとが多く、というかほぼ100%でデバッグの障害になってたりもします。これでPGとDBエンジニアが鶏が先か卵が先かみたいなケンカもします。そこでスクリプト側としてはDBとの入出力にも開発効率を上げるために検査を入れておいたほうが良いと思います。あとApache管理者の意見として、大量のUndefined indexでログを汚すなというのもあります。

またまた進化したSQLインジェクションの脅威 クッキーを悪用 セキュリティー-最新ニュース:IT-PLUS
http://it.nikkei.co.jp/security/news/index.aspx?n=MMIT2g000028102008&cp=1

PHPにPDOを実装

最近PHPの開発でDB接続にPDOを使用する機会が増えてきました。PDOとはPHP5.1以降に登場したPHP Extensionで従来のmysql等の代わりに使えるライブラリらしいです。ということは従来のmysql関数群は無くても良いということかな?それは余ったサーバでも捜して試してみるかな。またPEAR::DBのようなスクリプトのラッパーではなくネイティブコードなのでパフォーマンスの低下も少ないというメリットもあるそうです。その他既存のデータベース関数と比較すると抽象化しているのでなんたら…とPDOの中身はまだ勉強してませんがw

ソースからのインストール方法は./configureで–with-pdo-mysql=/usr/local/mysqlという風に追加すれば大丈夫のようです。 ググっても–with-pdoは省略されているので無くて大丈夫っぽい。

因みに、既存環境でPDOを追加インストールするのは過去にやってエントリー書いてますのでそちらを参照ください。

PHPにモジュールを追加 (ここでPDOを追加インストールしています)

そういえばmbstringやmysqlもExtensionでしたね。そうすると全くExtensionなしのPHP関数の一覧ってどんなものなんだろう?今後は使う関数がどのライブラリに属しているか気にしたほうがよさげですね。PHPリファレンスもライブラリを調査して明記してくれると大変ありがたい。PHPがdisられているときに関数の銘々規則がめちゃくちゃなんて書かれていましたがExtensionの開発者のクセがそのまま乗っかってるとかそんな気がしてきた…。

参考:PDOでサクサクDB開発:CodeZine
http://codezine.jp/a/article/aid/433.aspx

参考:PHP 5.1インストール
http://w-d-l.net/memo/vinelinux_ppc/12_php/

Apache,MySQL用top

apachetopとmytopというApache用、MySQL用のtopのようなものを見つけたのでインストールして試してみました。

mytopのインストール

mytop – a top clone for MySQL
http://jeremy.zawodny.com/mysql/mytop/

入手したtarボールを展開
# mv mytop-1.6.tar.gz /usr/local/src/
# cd /usr/local/src/
# tar zxf mytop-1.6.tar.gz
# cd mytop-1.6

Makefileの作成
# perl Makefile.PL
Checking if your kit is complete…
Looks good
Warning: prerequisite Term::ReadKey 2.1 not found.
Writing Makefile for mytop

コンパイル
# make
cp mytop blib/script/mytop
/usr/bin/perl “-MExtUtils::MY” -e “MY->fixin(shift)” blib/script/mytop
Manifying blib/man1/mytop.1

テスト
# make test
PERL_DL_NONLAZY=1 /usr/bin/perl “-Iblib/lib” “-Iblib/arch” test.pl
1..1
ok 1

インストール
# make install
Installing /usr/local/man/man1/mytop.1
Installing /usr/local/bin/mytop
Writing /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd/auto/mytop/.packlist
Appending installation info to /usr/local/lib/perl5/5.8.7/i386-freebsd/perllocal.pod

試しに実行
# mytop
Can’t locate Term/ReadKey.pm in @INC (@INC contains: /usr/local/lib/perl5/5.8.7/i386-freebsd /usr/local/lib/perl5/5.8.7 /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl .) at /usr/local/bin/mytop line 175.

実行にはReadKey.pmが必要ということで失敗したのでReadKeyを追加します。

ReadKeyをCPANから入手して展開

Jonathan Stowe – TermReadKey-2.30 – search.cpan.org
http://search.cpan.org/~jstowe/TermReadKey-2.30/

# mv TermReadKey-2.30.tar.gz /usr/local/src/
# cd /usr/local/src/
# tar zxf TermReadKey-2.30.tar.gz
# cd TermReadKey-2.30

Makefileの作成
# perl Makefile.PL
Checking if your kit is complete…
Looks good
Writing Makefile for Term::ReadKey

コンパイル
# make
cp ReadKey.pm blib/lib/Term/ReadKey.pm
AutoSplitting blib/lib/Term/ReadKey.pm (blib/lib/auto/Term/ReadKey)
/usr/bin/perl -I/usr/local/lib/perl5/5.8.7 genchars.pl

インストール
# make install
Installing /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd/auto/Term/ReadKey/ReadKey.so
Installing /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd/auto/Term/ReadKey/ReadKey.bs
Files found in blib/arch: installing files in blib/lib into architecture dependent library tree
Installing /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd/Term/ReadKey.pm
Installing /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd/auto/Term/ReadKey/autosplit.ix
Installing /usr/local/man/man3/Term::ReadKey.3
Writing /usr/local/lib/perl5/site_perl/5.8.7/i386-freebsd/auto/Term/ReadKey/.packlist
Appending installation info to /usr/local/lib/perl5/5.8.7/i386-freebsd/perllocal.pod

mytopの再実行
# mytop -uhoge -phogehoge
オプションの内容は-u[ユーザ名] -p[パスワード]です。
これでMySQLの負荷を簡単に確認できるようになりました。

次にapachetopを試します。

apachetopを入手して展開

ApacheTop – Trac
http://www.webta.org/projects/apachetop/

# mv apachetop-0.12.6.tar.gz /usr/local/src/
# cd /usr/local/src/
# tar zxf apachetop-0.12.6.tar.gz
# cd apachetop-0.12.6

設計
# ./configure

コンパイル
# make

インストール
# make install
Making install in man
/bin/sh ../config/mkinstalldirs /usr/local/man/man1
/usr/bin/install -c -m 644 ./apachetop.1 /usr/local/man/man1/apachetop.1
Making install in src
/bin/sh ../config/mkinstalldirs /usr/local/bin
/usr/bin/install -c apachetop /usr/local/bin/apachetop
Making install in config

実行
/usr/local/bin/apachetop -f ログファイル名
apachetopはログファイルのリアルタイム監視を行います。私の環境ではログファイル名を常に変える形のローテーションなので日付変更と同時に中断して新しいログファイル名でコマンドを打ちます。rpm版Apacheのようにデフォルトがシステムでローテーションさせてる場合はどうなるんでしょうね?そこまで気長に放置しませんがw

DBD-mysqlのインストール

昨日のMT4BETAのインストールですっかりPerlにMySQLコネクタをインストールし忘れていたので今度BETA4を入れる前までに用意します。

# mv DBD-mysql-4.005.tar.gz /usr/local/src/
# cd /usr/local/src
# tar zxf DBD-mysql-4.005.tar.gz
# cd DBD-mysql-4.005

ここまではいつも通りの前準備

まずPerlコマンドを利用してMakefileを作成します。
# perl Makefile.PL

Can’t exec “mysql_config”: No such file or directory at Makefile.PL line 76.

Cannot find the file ‘mysql_config’! Your execution PATH doesn’t seem
not contain the path to mysql_config. Resorting to guessed values!
Can’t exec “mysql_config”: No such file or directory at Makefile.PL line 466.
Can’t exec “mysql_config”: No such file or directory at Makefile.PL line 466.
Can’t exec “mysql_config”: No such file or directory at Makefile.PL line 466.
Can’t exec “mysql_config”: No such file or directory at Makefile.PL line 466.
Can’t exec “mysql_config”: No such file or directory at Makefile.PL line 466.
Can’t exec “mysql_config”: No such file or directory at Makefile.PL line 466.
Failed to determine directory of mysql.h. Use

perl Makefile.PL –cflags=-I<dir>

to set this directory. For details see the INSTALL.html file,
section “C Compiler flags” or type

perl Makefile.PL –help

…う、mysql_configへパスを通してなかったorz。

# find / -name mysql_config
/usr/local/src/mysql-5.0.18/scripts/mysql_config
/usr/local/mysql/bin/mysql_config

.cshrcを確認
set path=(/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin $HOME/bin)

以上より一時的に/usr/local/mysql/binをPATHに追加

set path=(/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin /usr/X11R6/bin $HOME/bin /usr/local/mysql/bin)

後はmakeとmake installで完了です。
# make
# make install

MySQLにCSVでインポート

これはver3のころよくやっていた方法ですがここ数年ずっと使用してなくて思い出すように検索してました。一応健忘録。

以下は全フィールドでのインポート・エクスポートに難がある場合に使用します。
※主キーが内容に特別意味を持たないauto_incrementの場合等、インポート時にキー重複でエラーになると困るもの。

CSVにおいてもエクスポート・インポート共にフィールド指定。

【エクスポート】
mysql> select text,cre_date into outfile ‘/tmp/db.tsv’ lines terminated
by ‘n’ from csvtest;
Query OK, 24 rows affected (0.00 sec)

【インポート】
mysql> load data infile ‘/tmp/db.tsv’ into table csvtest lines
terminated by ‘n’ (text,cre_date);
Query OK, 24 rows affected (0.00 sec)
Records: 24 Deleted: 0 Skipped: 0 Warnings: 0

但しtimestampのフィールドは00000000000000になったので無視できないですね。

16進ダンプでも心配なMySQL

さすがに16進なら大丈夫だろうと思っていたら、他のサーバへデータを移動する為にインポートしようとしたら

ERROR 1054 at line 98603: Unknown column ‘0x’ in ‘field list’

このようにエラーを吐いて処理が止まった。
結局どんな吐き出し方をしたのだろうと確認すると、元のDBでは空文字(NULLでは無い)状態になっている文字列フィールドでダンプ時に0xのみ出力されていました。

NULLであれば
VALUES(NULL,NULL,NULL);
という感じになるところが空文字だと
VALUES(0x,0x,0x);
となっていました。終端文字を吐き出さない仕様だからこうなるのでしょうが、同じバージョンのMySQLならインポートも対応しろよって思いました。

結局空文字はNULLでも良かったのでテキストエディタで置換してインポート終了しました。どうしても空文字で入れたいのであれば0xを”に置換してもいいですね。

使用したバージョン:4.0.26

phpMyAdmin で Parse error

PHP Parse error: syntax error, unexpected T_STRING, expecting ‘)’ in /usr/local/apache/htdocs/phpMyAdmin/lang/japanese-euc.inc.php on line 19

phpをインストールするときに–enable-zend-multibyteオプションをつけていると上記のようなエラーが発生する。今まで気が付かなかったが既存サーバに導入しても真っ白で表示されないから調べたらこんな始末でした。。。

参考:
PHP5.1.1
phpMyAdmin2.8.0.2
MySQL4.0.26

MySQLの文字を16進数でダンプ

以前から、BINARY属性のついた文字列をダンプすると得体の知れない化け文字になって他のバージョンにインポートできないなど苦労したので16進数でダンプしてくれるオプションを見つけました。

–hex-blob

です。何故かコマンドヘルプにも出てこないので探すのに苦労した…。

MySQLでテーブル定義だけエクスポート

SHOWやDESCでは見づらいのでSQL文で定義を見たい、でもデータは不要…と、phpMyAdminがあればそんなことは任せればよいのだが実環境では用意されていないことのほうが多い。そこでどうやって定義を抽出しているのか調べたら、phpMyAdminのインポート・エクスポートはmysqldumpをラッピングしているという情報を得た。ということはmysqldumpを使えば良いと言う事。結局それか…と思いデータを出力しないオプションを探す。

> mysqldump -h[ホスト] -u[ユーザ名] -p[パスワード] -d [データベース名] [テーブル名]

でOKだった。