ナチュラルキーでもいいじゃない・・・

あぁ、そういえばこんなブログ書いてたな・・・

何か、4年も前の日記に最近謎のトラックバックがあったようで、ってか、まだログインできたんだこのブログ。凄いな、はてなさん。
前の日記の時代から既に転職しちゃってますけどね。あはは、若かったなぁ僕。

ってか、続きはまた今度で終わってるなぁ。もう忘れてるけど。ひたすらレジストリを手作業消去して廻って解決しました。お礼に缶コーヒー貰いました。おいしかった筈です。ちゃんちゃん。

閑話休題

仕事でDBに関係することでちょっとやらかし・・・気になったことがあったので色々調べていたら、ナチュラルキーvsサロゲートキー論争の記事に出くわしまして。見てて面白かったので。
【用語注釈】
ナチュラルキー:
業務に直接使用されるデータ(社員ID、顧客IDなど)をテーブルの主キーとする場合の呼称

サロゲートキー
プログラム管理上で利用する、業務には直結しないデータ(連番値、ランダム値)をテーブルの主キーとする場合の呼称

【それぞれの特徴】
ナチュラルキー:
実際に使用する値を軸にテーブル関係を見ることが出来、業務とテーブルの関連が直感的に理解し易い。テーブルの親子関係を明示し易く、この場合複合キーが用いられる。但し、データの連鎖性に優れる余り、仕様変更による影響も甚大で、複合キーも多すぎるとSQL文が冗長になりがち。

サロゲートキー
業務に関係無いデータをキーとする為、業務改善等によるデータ仕様の変更に強く、単一のキーで管理される為、テーブル結合処理が楽。但し、どのテーブルがどのテーブルに事実上影響しているのかが解かりづらく、SQL文もサブクエリが多くなりがちな為、人を相手にした可読性は劣る。
【でもって、判り易い論争の現状】
ナチュラルキー派:パッと見判り易くていいじゃねーか
サロゲートキー派:仕様変更し易くていいじゃねーか


う〜んなんとなく、ネット上ではサロゲートキー派が多いかなって感じですね。ってか最近の趣向って感じ。やっぱ仕様変更はついてまわるものですからねぇ……

……でも不思議なのは「じゃあ仕様変更が発生しなかったらナチュラルキーの方がいいってことじゃん!」って声高らかに言ってる人がいないことですね。多分言ったらアホだと思われるからでしょうね。

僕はアホなので構わないですが。

ただ実際問題、システムが10年間稼動しました。その間に何度も仕様変更がありました。でも、ナチュラルキーとなる部分の仕様変更は一切ありませんでした。

・・・となった時、初回設計時にナチュラルキーという手法を選択した人に対して「お前は間違っていた!」とは断言できないと思うんですよねぇ。10年もあれば、その間に先方もこちらも担当者が変わっているわけで、この場合解かり易さのメリットの方がシステム可用性のメリットより大きかったってことにならないかなぁ。まあ「未来のことなんか解かるか!」って言われりゃそれまでだけど。

あ、でも「あの時の俺にはこの未来が見えていたんだよ!」って言い切ったらカッコいいね。カッコいいだけだけど。

まあ、どっちにも一長一短あるってのは確かなので、「俺は時と場合とシステム規模によりけりだな派」っていう、曖昧模糊としたコウモリ的な意見の人がもうちょっといてもいい気もする。

……ってか、大概の二元論って「要は一長一短」って言葉で片付く気がするんだけど……

ウィルスパニック

きっかけは、何気ない行動だったんですが。
ちょっと同僚のPCにUSBメモリスティックを挿そうとした時、
な〜んとなくいやな予感がして、ちょっとCドライブのsystemフォルダの
中を見てからにしようと思いとどまる。以前、USBメモリ経由で感染する
ウィルスに遭遇した事が有り、そのときはC:\WINDOWS\system\の中に
ぼこぼこファイルを作っていたなぁなんて記憶が蘇ったノデ。
 
取り合えず、隠しファイルを表示するようにして、さてと……
おや?Cドライブの直下に、何も隠しファイルが無い?
と思ったら、隠しファイルを表示しない設定のままになっていた。
 
な〜んだ、キャンセルでも押しちゃったかね。失敗失敗。ってことで、
もう一度隠しファイルを表示するようにして・・・表示されないねぇ。
 
隠しファイルの表示を強制的に行わないようなポリシーなんてあったっけ?
一応現象をググって見ると……あ、ウィルスでやんの。しかもUSB感染式。
kavo.exeとか、revo.exeって名前らしい。
う〜ん、我ながら感心する危険察知能力。その割りにいつも危機的状況なのは何故。
それにしても、隠しファイルを強制的に表示しないようにするとは、
以前遭遇した物よりもヒネリが効いとる。
 
取り合えず、フロア全員に、PCのLANケーブルを抜くように指示しましたが、
仕事が出来なくなるからそんな事は出来ないと抗議を受ける。
ほう、いつもは仕事が出来ていると
気持ちは解かりますが、USB以外からも感染するタイプだったら
僕の仕事が余計にめんど……被害が拡大するだけなので、
理解してもらう。
 
とりあえず、感染経路の特定は後にするとして、ウィルスの種類の特定から。
ググッた物と全く同じとは限らないしねぇ。ワクワクなんかしてませんよ。
ホントですよ。頭の中にドクターマリオのBGMなんか流れてません。

まず、感染したPC内で、先ほど調べたkavo.exeとかrevo.exeでファイル検索を
してみたけれど、特にそういったファイルは無し。レジストリの中も
調べてみたけど、結果は同じ。一応、潜伏先はsystem32フォルダらしいので、
コマンドプロンプトでフォルダ内の隠しファイル一覧を調べてみたが、それもなし。
となると、USBストレージ内のファイル名から追ってくかなあ。

全員のUSBストレージを回収して、普段使用していない生贄用PCで中を見てみると、
ああ、いるわいるわ。経験された方にはおなじみのautorun.infと、妙なexeが。
しかもその妙なexeの数、実に7〜9個。 (マニアに売れるかも・・・
 
この妙なexeファイル(yj.exeとか)は、あくまで母体を生成する為の
ファイルなので、コレだけ消しても意味は無い。ただ、この妙な
exeファイル名を元にレジストリ検索すれば、何かしらの手がかりが
あるだろうと調べたら、スタートアップのファイルを指定するレジストリ
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
にちょっと違った見慣れないexeが。
 
xvassdf.exe
ierdfgh.exe
 
一応、ググって調べたら、やはりウィルス。USB感染、隠しファイル
強制非表示等、現象が酷似です。なお、潜伏先は
"C:\Documents and Settings\[ユーザID]\Local Settings\Temp"
・・・潜伏先が、明らかに面倒な場所に変更されてるでやんの。
 
面倒な理由1:
Local Settingsは隠しフォルダなので、隠しフォルダを表示できない
この状況では、GUIではアクセスできない。
パス手入力(レジストリからコピペできるけど)の必要有り。
 
面倒な理由2:
ログインユーザごとに潜伏先が違う。
(ファイル本体は消せるけど、スタートアップのレジストリ値修正は
個別にログインする必要有り)
 
駆除作業まで含めたら何日かかる事やら……
と言う事で、続きはまた後日

wpadってなんですか・・・?続き

うーん。プロキシを通ってない原因として考えられるのは
 
1:IISにて、wpad.datの保存場所が違う
2:ブラウザがwpad.datを取得していない
3:wpad.datの中のスクリプトがおかしい
 
とりあえず、wpad.datと同じディレクトリにindex.htmlを作って、ブラウザからアクセスしてみると、ちゃんとindex.htmlの画面が表示されるので、パスの間違いではない。
じゃあブラウザがwpad.datを取得していないのかなぁ・・・と思って、パケットキャプチャしながらブラウザを起動してみると・・・お、ちゃんとwpad.datのリクエストをしてるパケットがじゃないか……って、あれ?
 
「404:File Not Found」
 
何故だ。さっきディレクトリについては間違いなかったはずでは。検証方法おかしかったか?それともwpadの設定でまだ何か見落としが有るのか?それとも、何か変なセキュリティでもかかってるのか?それともIEのバージョンで何か違うとか?それとも…(BGM:かまいたちの夜)
 
どうでもいい所で想像力がたくましいらしく、それともが10個くらいはばらばらと頭に浮かぶ。くそ、これのどこが「すぐできるよ」なんだ。上司め、図ったな。
一応、真っ先に思いついたのが特定の拡張子をはじくような設定がされている可能性(exeとか、明らかにデフォじゃダメそうな拡張子も有ることだし)だったので、ちょっと調べてみた所、

「IIS6.0では、HTTPリクエストではdatファイルを扱えないようになっているのがデフォ」

……そんなんwpadの設定手順のどこにも書いて無いし。同じIIS6.0を想定しているの手順だったのだから、注意書きくらいあっても良いと思う。それとも、常識の範囲過ぎて割愛されているのだろうか。
結局、IISMIME(マイムって読めばいいんだろか)の設定で、datファイルを登録した所、無事wpad.datの取得に成功。プロキシを経由するようになりました。あー……疲れた。知恵熱出た。早退したい。むしろ辞めたい。

と、ここで疑問。AD環境なんだし、グループポリシーでプロキシのアドレスを指定したIEの設定を作って、クライアントに配布すればいんじゃね?と。wpadはセキュリティ的に余りオススメされていないようにも見えるし。と思って上司に聞いたところ、後でwpad.dat内のスクリプトを書き換えて、複数のプロキシをランダムに使用するようにするのだとか。マニアックな。

wpadも、全部解かってみれば確かに設定は簡単だけど、割と最近の環境で実現する場合の手順が書いてある資料が無いんですね。(特に、DNSがWinServer2008で使用しているという話をとんと聞かない)
なので、追加手順として
 
1:WinServer2008をDNSにする場合、グローバル拒否リストからwpad
 エントリを外す(要コマンド)
2:IISが、IIS6.0の場合、MIMEに拡張子datを追加する。

 
が必要なようです。

wpadってなんですか・・・?

ある日ある時、上司から「wpad使ってプロキシ通すから、環境宜しく」と
言われた。

「はあ、wpad・・・ですか」
「大丈夫大丈夫。すぐできるよ」

ダブルパッドってナニ?女物の下着ですか?としか思い浮かばないカスである自分に、ググる以外の道は無し。
ここで間違っても「wpadってナンデスカ?」などと聞いてはいけない。そんなことを聞いたが最後。コンピュータペンシルを使おうとしたのび太に対するドラえもんの目で1週間は蔑まれること請け合いだ。そしてそのストレスに耐えられず会社を辞め、不況の中再就職先も見つからず、人生に絶望して堕ちる所まで堕ちて行くハメになるのだ。恐ろしい。これがパワハラか。(妄想だ)

とりあえずwpadとは、DNSDHCPを使って、ブラウザが使用するプロキシサーバのアドレスを自動配布する方式…と言うのは解かった。設定も、上司が言う通り、大したことなさそう。

                                                                                                                                            • -

[BGM:NHK今日の料理]
【必要な物】
DNSDHCPサーバ(今回はDNS
IISが稼動しているサーバ(WEBサーバ)
wpad.datというファイル名のスクリプトファイル


【手順】
1:ドメイン環境を作る(これはもうあるからおk)
2:DNSに、wpadという名前のAレコードかCNレコードを作って、
 IISが稼動しているサーバのアドレスを登録する。
3:WEBサイトから適当に拾ってきたサンプルスクリプトファイルの中の、
 プロキシのアドレスを指定する部分だけ書き換えて、IIS
 ルートフォルダに突っ込む。
4:各クライアントのIEの設定で「プロキシの設定を自動検出」にチェック
 もしくは、相当するポリシーを配布。

                                                                                                                                            • -

以上。なんだ、簡単簡単。
そう思ったんですけどねぇ・・・
一応設定を終えて、テスト稼動させてみる。普通に、インターネットにアクセスできた。よしよしと。で、WEBサーバのアクセスログを見てみると

・・・プロキシ通ってない。
というか、nslookupでwpadを引いてみたら、名前解決すらできてない模様。他のPCとかは大丈夫なんですが・・・
設定を1から見直してみても、おかしい所は見つからない。でも、そこは新人。
絶対に設定を見落としてる。だって自分新人だもん。
そう信じて、色々見直すも、やっぱり結果は変わらず。
で、ふと思った。ググって収集した手順は、どれもWinServer2003のもの。今設定しているDNSは、WinServer2008。アヤシイ。
そう思って調べてみたら・・・あ。

「WinServer2008では、wpadというネームエントリはグローバル拒否リストに
登録されているのがデフォ」

そーですか。そりゃあまともに機能しないわけだ。こりゃ、一本取られたな。いいか、その一本は果てしなく無駄な一本だ。後悔するぞマイク〇ソフト。
ともかく、wpadを拒否リストから外し、再度挑戦。
これで上手く

・・・いかない・・・ねぇ・・・。

名前解決は出来てるのに、まだプロキシは通っていない。
やめやめ。疲れた。「人生、諦めが肝心」って、人生を諦めちゃった人が言ってた。
今日はもう帰って寝る。

一応、後日解決は出来たので、そちらはまた明日にでも。