MSDE? これはMagSite1開発日誌のはずでは? と思った人もいると思いますが、間違いではありません。
実は、MagSite1を複数ユーザーの環境で使うための認証機構として、さる既存の認証ソフトを使うという案があり、現在試用しようと頑張っているところなのですが。このソフトは、各種情報の保存にSQL-Serverを使用しています。その関係の話題です。
SQL-Serverは守備範囲外 §
ここで問題が1つあります。
私は、SQL-Serverは自分の守備範囲外としています。これに限らずRDB全般が守備範囲外です。この話題は、そのうちにちゃんと書くと良いと思いつつまだ書いていませんが。要するに、データを縦横にきちんと並んだ表に押し込めないと扱えないようなシステムは、ほとんどの情報処理(つまり、多数の多品種少量不定形の情報処理を含む情報処理)には不便でありすぎるという経験的感想から、守備範囲外に置いているわけです。XMLを支持するのは、その裏返しということが言えます。
とはいえ、全くRDBを使ったことがないと言うわけではなく、人生の中で何回かそれを使う機会がありました。SQL-Serverを使ったこともあります。しかし、それは自由自在に扱うというほど大したレベルではなく、しかもだいぶ前のことなので、既にかなり忘れています。
さて、最初の問題は、うちがSQL-Serverの正規ユーザーではないということです。しかし、MSDEでも問題なく動くということなので、MSDEを使うことで解決。どうせ、大した量のデータを入れる訳でもなく、MSDEでも問題はありません。
MSDEさんこんにちは §
というわけで、MSのサイトからSQL Server 2000 Desktop Engine SP3という最新版を入手してセットアップ。しかし何も起こりません。最初のセットアップは、セットアップファイルを展開するもので、それを更にセットアップする必要があったのです。さすが、自作ソフトに組み込んで配布するモジュールです。
ところが、2度目のセットアップを起動すると、saのパスワードを指定しないとセットアップできないと言われてしまいました。ドキュメントを調べて、SAPWD=sa_passwordという指定をsetup.iniに書き込むか、コマンドライン引数に指定する必要があることが分かりました。これをsetup.iniに書き込んで、セットアップは完了しました。
しかし、セットアップは完了しましたが、これで使えるようになったわけではありません。
以前、SQL-Serverを使ったときはEnterprise Manaegrで全て管理しましたが、MSDEにそれはありません。どうも、osqlというコマンドを使うとコマンドラインで管理できるらしいと分かりましたが、何しろ使ったことがないコマンドなので、何がどうなっているか分かりません。
ともかく、osqlを起動してみようと思って、cmd.exeから起動してみると、ユーザー名を指定しろと言います。しかし、さっき指定したパスワードを使って
osql -U sa -P パスワード
というようなコマンドを打ってもエラーになって起動できません。
Windows認証もあるらしいので、ドメインやサーバのアカウントを指定してみましたが、通りません。
Access 2003で試す §
osqlなんて使い方も知らないし、もうダメかと思ったところ。
Access経由なら管理できるかも知れないと気付きました。Accessも、昔は多少使ったことがあるし、Office 2003のアップグレードパッケージも、一応Access入りのものを選んで買ってあります。
というわけで、Access 2003でチャレンジ。昔のアクセスとだいぶ使い勝手が違うので、回り道をしてしまったものの、成功。一応、データベースに接続することができました。
しかし、またまた謎が浮上しました。
データリンクプロパティで、Windows NTの統合セキュリティを使用するを選択している場合は問題なく接続できます。しかし、特定のユーザー名とパスワードを使用するを使うと、saを含むどんなユーザー名とパスワードを指定しても通りません。いったい、Windows NTの統合セキュリティを使用するでは、どんな権限で認証されているのか不思議です。
守備範囲外で分からないことだらけなので、何かセットアップ中に間違えた可能性もあり得そうです。そこで、MSDEをアンインストールしてから入れ直そう、と思いました。
再セットアップでもトラブル §
そして、もっと安易な設定、つまり、saにブランクパスワードを設定して試してみようと思ったわけです。そこで、アンインストールを行ってから、setup.iniにBLANKSAPWD=1を書き込んで、セットアップしてみると、途中でエラーになります。これは大いに焦りました。しかし、原因が分かりません。仕方がないので、setup.exeに/L*vオプションを付けてログを書かせてみることにしました。このオプションもくせ者で、動作を把握するのに時間を食われました。/L*vは省略可能なログファイル名を指定できます。そこで、ファイル名を省略して
setup.exe /L*v
としたらエラーで動作しませんでした。setup.exe /L*vのあとにファイル名を記述したら動作しました。このあたりの動作も謎です。
さて、エラーを調べるとどうも自分がインストールしたあるツールを起動しているらしいことが分かりました。そのツールを手動で起動すると、引数がおかしいというエラーになります。そこで更に調べてみると、データベースを構成するファイルは、アンインストールでは消えず、次にインストールされたときにそれが有効になっているらしいことが分かりました。古いファイルの認証情報が引き継がれて、空パスワードのsaでは認証できないようです。
というわけで、古いファイルを別の場所に移動させてインストールしたところ、上手くインストールできました。
しかし、動作させてみると、やはりosqlコマンドでエラーになります。
このマシンはずいぶんいろいろなソフトを入れたり消したりしているので、何か悪いことをする設定が残っているのかと、夏に買ったばかりのノートパソコンにも入れてみましたが症状は同じです。
そこで、今度はSECURITYMODE=SQLを指定してSQL Server認証を有効にして、もう一度インストールしてみました。すると、上手くsaでosqlコマンドを起動することに成功しました。とりあえず、起動できれば、あとはそこから様々な設定ができそうなので、これで良しとしましょう。
注: 2003年11月17日21時頃追記。念のために書いておきます。開発マシンにブランクパスワードのsaでアクセス可能なMSDEをインストールしてはいますが、侵入を試みてやろうなどと思わないように。まず、NATの内側のマシンなので、グローバルセグメントからアクセスする経路はありません。仮にあってもルータでSQL-Serverのポートは閉じています。そして、インストール成功後にすぐパスワードは設定していますので、仮にアクセスできても簡単に侵入はできません。追記終わり
お暇な人があれば §
とりあず動くようになったので、まだ調べ切れていませんが、これで調査は打ち切ります。ですが、疑問も残っているので、知識があってお暇な人があれば教えて下さい。
使用したのは、以下のMSDEです。
SQL Server 2000 Desktop Engine SP3
分からないのは以下の2点です。
疑問1 SECURITYMODE=SQLを付けない場合のsaの存在意義 §
SECURITYMODE=SQLを付けない場合、saを使うことはできないように資料から読めましたが、この認識で正しいのでしょうか? もし、それが正しいとするなら、saにパスワードを強制する意味は何でしょう?
2003年11月17日18時頃追記
チャットで以下のような反応を頂きました。
ほぼ正しいです > SECURITYMODE=SQLを付けない場合、saを使うことはできない
Windows 認証のみでインストールしても、あとから混合モードへ切り替えることができるからです。 > saにパスワードを強制する意味は何でしょう?
疑問2 SECURITYMODE=SQLを付けない場合に使えるアカウント §
SECURITYMODE=SQLを付けない場合、どのアカウントを使うと、MSDEにアクセス可能になるのでしょうか?
資料を見ると、ローカルマシンのAdministratorグループのアカウントが使えそうな気がしますが、上手く行きませんでした。ドメインのAdministratorグループも試してみましたが同じでした。saも使えませんでした。
午前4時の死闘 §
実はここに書いた手順の途中から後は、夜中の午前4時頃に目が覚めたときに気になって行った手順だったりします。リモートデスクトップ接続で仕事場のマイパソコンに接続して作業しました。途中、午前5時頃にファイルサーバに接続できないエラーに遭遇して焦りましたが、これはスケジュールされた定期リブートでした。通常は使っていないはずの時間帯にスケジュールしているのですが、今日に限っては使っていたというわけです。
ご注意 §
なお、ここで試用を試みている認証機構は、仮に使うことになったとしても、一般向けのリリースに含まれるかどうかは分かりません。基本的にはISP的に1サーバーで複数のMagSite1を運用する場合に使われるものです。