Posts

最近のノートPCにはRS232Cポートがついていない・・・ということで、ForCy-AVRのためにELECOMのUSBPC to SerialCable(UC-SGT)という安物を買ってきました。約3.5k。めんどくさい時代になったのぅ。

不良品は交換してもらいました。交換してくれた店員さんはいい人だった。不良品をつかまされた店員はいやな人だった。

クリスマスプレゼント物色中。自分の分も物色中。 昔はほしいものがた〜くさんあって、クリスマスとか誕生日がとても待ち遠しかったものだけれども、今はほしいものが全然ありません。物質的に十分に豊かになった・・・というわけではないと思いますし、お金があまって仕方がない・・・というわけでもありません。なんでしょうね。

またしても勉強会をやってみたけれども、スキルのばらつきがある10人以上を相手にすると、さすがにどのレベルで物をしゃべっていいのか良くわからなかったです。やっぱりこういうのは特殊な技術が必要ですね。

タナケンと二人でちょこっとだけお酒を飲んで帰ったのですが、話をする内容がいよいよサラリーマンっぽくなってきた気がします。「うちの会社は・・・」とか。 世の中がわかってきたといえるかもしれないし、つまらない大人になってきている気もする。

ForCy-AVR評価基盤を申し込んでみたところ、滑り込みセーフで送ってくれたとの連絡がありました。久しぶりに頭の体操をしようと思います。

サービスロケータ、名前解決の仕組みからADを捉える 前回は認証、名前解決の視点からADを見てみましたが、今回はサービスロケータ、名前解決の視点からADを見ていこうと思います。 ※注意事項 以下の事項に関しては、ここで述べるには複雑すぎるので詳しくは述べません。 通信に利用するプロトコル(NetBEUI、TCP/IP） インターフェース（NETBIOS、NETBIOS over TCP/IP) NETBIOS名とホスト名 WINSサーバとDNSサーバーの違い Windowsブラウジングの仕組み スタンドアロンPCの場合 スタンドアロンPCの場合には、特にサービスロケーターや名前解決の仕組みは必要ありません。 複数PCの場合 複数PCの場合には、どのPCに何が入っているかなどに関しては全て個人の記憶なりで管理します。特にPCの仕組みとしては組み込む必然性はありません。 ワークグループの場合 ネットワークが利用できる環境では、通信をするために名前解決が必要ですし、共有リソースにアクセスする必要性も出てきます。 共有リソースの場所は記憶で管理し、名前解決はブロードキャスト(同一セグメントのみ)、ローカルファイル(hostsファイル、lmhostsファイル)を利用します。 どのPCがワークグループに参加しているか、という点に関しては、ブラウズリストを利用します。このブラウズリストに関しても、ブロードキャストやローカルファイルを利用して取得します。 NTドメイン NTドメインにおいては、アカウントデータベースも共有リソースとなります。つまり、ログオンする際にはドメインコントローラーを知り、通信を行う必要があります。 では、ドメインコントローラーの場所をどのようにしてクライアントは知ることが出来るのか? これは複数の方法があり、(同一セグメントであれば)ブロードキャスト、各PCのlmhostsファイルに記述するといった方法もありますが、本命はWINSを利用する方法になります。 WINSの場所自体は、各PCに静的に設定します。 WINSによって提供されるもの WINSの役割は複数ありますが、以下のものを提供します。 -ドメインコントローラーの場所 -NETBIOS名とIPアドレスの組(名前解決) -ブラウズリストの場所 WindowsNT時代にはWINSがサービスロケーター、名前解決の手段として一般的に利用されていました。 (余談)ちなみにNetBEUIプロトコルを利用しているかぎりにおいては、このあたりは全てブロードキャストで解決します。なぜならNetBEUIにはネットワークセグメントという概念はなく、全てのPCに対してブロードキャストが届くネットワークしか想定していないからです。 WINSサーバーの問題 WINSサーバーには以下の問題がありました。 オブジェクト数、データ構造 WINSのデータベースはフラットな構造であったので、必要なレコード、つまり全てのドメインの全てのレコードを保持する必要がありました。 (余談)WINSの場合、対象サーバーが保持しているレコードは名前解決できるし、保持していないレコードは名前解決できないという動きでした。自分が保持していないレコードだった場合には保持しているはずのWINSサーバーに問い合わせて、答えを返す・・・というようには動きません。 複製の管理 WINSサーバーが複数存在する環境では、WINSサーバー同士でレコードを明示的にPushしたり、Pullしたりする必要がありました。つまりWINSの複製のトポロジを管理者が管理しなくてはならず、しかも色々と複製にまつわるトラブルが多かったそうです。 ログオンするDCのコントロール NTドメインの時代にはログオンするDCはWINSサーバーから取得していたので、ログオンするDCが名前解決に依存してしまっていました。このため、最悪の場合には、近くにあるDCを利用せずに、ネットワーク的に非常に遠いDCを利用してしまうこともあったそうです。 公開できるリソースの種類 サービスロケーターとしてWINSを捉えた際にWINSが扱えるものはDCの場所とブラウズリストの場所に関するものだけだったので、たとえば共有プリンタの場所などは扱えず、UNCパスを利用しなくてはなりませんでした。 ADでの改善 ここまで見てきたWINSの問題点を改善するために、ADでは名前解決にDNS、サービスロケーターとしてもDNS,ADを利用するように変更されています。 オブジェクト数、データ構造 DNSを採用することで、ドメインごとに管理を分散できるようになりました。 複製の管理 名前解決に関してはDNSを採用したため、WINSの構成を行う必要がなくなりました。それに加えて、ADのDNSでは「AD統合ゾーン」という仕組みを採用し、DCのレプリケーションにDNSのレコードも含められるようになっています。(通常の標準プライマリ、標準セカンダリとしても構成可能) これによって、管理者は名前解決のための複製管理とDCの複製管理を分けて考える必要がなくなりました。 ログオンするDCのコントロール ADでは「サイト」という概念が導入されて、ログオンするDCはまずはサイト内を利用する・・・というように管理者が細かく管理できるようになりました。DCの場所はDNSのSRVレコードで示されています。 公開できるリソースの種類 ADでは、ユーザー、グループ、共有フォルダ、共有プリンタなどのリソースに関しても「ADに公開」することが出来るようになりました。

なぜかマネージャーばっかりのミーティングに呼ばれました。経営戦略ミーティングっぽかったんだけど??いったい会社は何を考えているんだろう?なんて思ってたけど、あんまり考えが無いのかもしれない。 ・・・はっ。もしかしてだまされてる??

か っ こ い い バ ッ シ ュ × 1 : . c o . j p の G o o g l e 検 索 なーんてのをみて、シェルの色使いの話かと素で思ってしまった。もう立派な・・・。(;-;

土曜日の夜9時から仕事のために、金曜日に深夜2時にねて、土曜日に16時に起きて、日曜日に11時に寝て、18時に起きて。

このサーバーはメインメモリが非常に少ないのですが、リファラスパムにやられて、Out of Memory連発・・・。仕方が無いのでiptablesではじいてみたけれども・・・。

プロダクトキー検索ツールが存在することを知る。仕事で使えそう!ということで、メモメモ。 http://www.h5.dion.ne.jp/~afuruta/scankeylx/scankeylx.htm http://www.licenturion.com/xp/

フィッツジェラルド短編集 ここのところ新しい本を読まずに気楽に経済ってそういうことだったのか会議|http://www.amazon.co.jp/exec/obidos/ASIN/4532191424/ebiswebpag-22/ref=nosim/]]とか[[村上朝日堂の逆襲とか再読してました。でも、そろそろ何か新しいものが読みたいなぁということで、仕事に行く前に本屋さんにふらっと立ち寄って気になったものを適当に買ってみました。 で、買ってきたのがフィッツジェラルド短編集。深夜作業に向かう電車の中で読んでいたのですが、今日は非常に寒い！その中で氷の宮殿を読んでいたら本当に寒くなりました。ううさむいさむい。 今頃新潟も10年ぶりくらいの寒波ということで非常に寒かろうと思います。風邪とかひかないように気をつけてね＞嫁

こちらでVisual Studio 2005 Express Editionsの無償公開が始まりましたね。MSがVSを無償で公開する時代になったかぁ。時代は変わりましたね。 ダウンロードして、C#でWindowsアプリケーション作ってみたいな。

今頃ADの勉強会?という声も聞こえてきそうですが、新人はまったく別のことが専門だった人がほとんど・・・というのが今のSIerの実体で、需要は毎年あるのです。 3日かけて、AD勉強会をやりました。ものすごく疲れた・・・。 ちょっとは達成感があるけど、自分の技術的なスキル向上にはまだ全然やくにってない！人に話をする練習にはちょっとはなってるかな。 まだまだこれからだのぅ。

会社でだれにいわれたわけでもないけど、「やるぞ」ということで、ADの勉強会をしています。希望を募ったら、20人くらい集まったので、3日に分けて、まずは基本的なところから。今日は初日であんまりうまく出来なかったけれども、明日もあさってもあるから、もうちょっとうまくやろうっと。 でも、こんなことやって自分の仕事時間増やしても、特になにも得はないのです。もうちょっと何か文句でもいいからいってくれるといいんだけど・・・。

毎年のことだけれども、咳がとまりません。毎年冬になると１〜２ヶ月くらいずっと咳が出続けます。たいてい仕事をしていなければ出ないんだけれども、ことしはそろそろ子供も生まれるし・・・ということで、特に子供に悪影響を及ぼさないのか・・・というところを確認してきました。 結果、まぁ、アレルギーでしょう、季節限定の気管支炎みたいなもんですとのこと。「原因調べたってしょうがないしさ・・・」というのもどうかと思ったけれども、「子供に影響は無い」とのことなので、ひとまず安心。 薬は今まで見たことも無いようなものを二つ出されて、使うかどうか、考え中。ホクナリンテープとフルタイド200ロタディスクとのこと。怖いよー。 ちなみに病院は職場の2階にあって、お昼休みにさくっといけました。便利♪

日曜日、月曜日と、新潟に嫁の様子を見に行ってきました。 トンネルを抜けて新潟に入った瞬間からすごい雪!さすが雪国。雪が沢山積もっておりました。でも、まだまだこれからとのことで。すごいよなぁ。 いつも行かせてもらうたびに思うのだけれども、気候も、四季のイベントも、食べものも、地域社会のありかたも全然違うことを思い知ります。非常にうらやましいことが多いです。もちろん隣の芝は青く見えるのは当たり前ですが、自分の住むところを選ぶっていうのは非常に重要なことだし、その自由は常に持っていたいなあと思うのでした。 さて、自分で作った曲を聞かせてみたわけですが、おなかの中の子供に聞こえたでしょうか?生まれて言葉が話せるようになったら聞いてみようっと(笑)。

昨日、今日と2日連続で飲み会、送別会でした。 意見の相違から上司と口論したり、始発で帰ったり、よっぱらっいすぎた同僚を家で寝かしつけたり。いまとなりの部屋で女性二人男性一人が寝ているわけですが・・・。 年末になるとこの手の話が多くなるんだけど、いまだにうまい方法がわからないんだよね。 でも、色々話をしていると自分が現状にかなり不満を抱いていることがよくわかる。やれやれ。理想の共同体のあり方ってどんなんなんだろう。

仕事の話を日記に書いてみるテスト。嘘がふんだんに盛り込まれている可能性大ですので、ご注意ください。 こんなところに書いてなにかいいことがあるのか? どうでしょうね・・・。 ActiveDiretoryとは何者か?(認証、アカウント管理の視点から) ActiveDirectoryというと、色々な要素があり、なかなかとらえずらいですが、まずはひとつの見方として、認証、アカウント管理の視点からその進化の過程を見ていこうと思います。(※あくまでもひとつの見方です。) スタンドアロンPC まず、スタンドアロンPCではローカルでのユーザー管理、アクセス制御を行います。ローカルにユーザーを作成することが出来、NT系のOSではローカルにユーザーを複数つくり、それぞれプロファイルを切り替えて使うことで1台のパソコンを共有する仕組みが備わっています。 その上で他のひとに見られたくないファイルには自分だけがファイルにアクセスできるようにアクセス権を設定することが出来ます。 1台のWindowsマシン上で、マシンの共有とリソース権限の確保が実現されています。 複数のPCがあると困ること 複数のWindowsPCが存在すると、ユーザーアカウントデータベースはそれぞれのPCに個別に保持されます。アカウントとパスワードの組み合わせを複数覚える必要があるので少々不便になります。同じIDとパスワードにしてしまうことも考えられますが、ユーザーの登録作業は必須です。 また複数PC間でリソースの共有ができないので、不便です。 ワークグループでのリソース共有 リソースの共有を実現するために、WindowsPC同士をネットワークでつなぎます。具体的にはNetBEUI、TCP/IPなどのネットワークプロトコルを構成し、相互に通信可能な状態にします。そのうえで、複数のマシンがネットワークに参加します。ネットワークに参加してしまえば、共有したいリソースを「共有」し、他のPCに見せることが出来ます。 しかし、ここでアクセス制御に少々こまったことが起きます。 ワークグループでのリソース共有で困ること リモートのPCで共有されているリソースにアクセスしようとすると、IDとパスワードを聞かれてしまいます。これは他のPCにアクセスするためにはそのPCで有効なIDパスワードを入力し、そのPCのユーザーとしてアクセスする必要があるからです。 複数のパソコンで複数のIDが管理されており、パスワードも一致していないとしたら・・・かなり混乱します。 これを避けるために、全てのIDを全てのWindowsPCに登録し、パスワードもそろえてしまうという運用方法があります。これなら他のPCのリソースにいちいちID/Passwordを入力しなくてもアクセスすることが出来ます。 しかし、ある程度大きな規模でこれを実現しようとすると、1人新しく人が加わっただけで全てのPCにユーザーを登録して回らなくてはいけません。 さらにセキュリティ対策のために、定期的にパスワードを変更する必要がある・・・などとなったら面倒でやっていられません。 アカウントデータベースの一元管理(NTドメイン) そこでアカウントのデータベースを個別のWindowsPCに持つのではなくて、一括してどこかにまとめて管理してしまおうという発想が出てきます。これがWindowsドメイン(NTドメイン)ですね。 NTドメインによって、認証やネットワーク資源の一元管理を行うことが出来るようになりました。 ユーザーはドメインに登録し、コンピューターはドメインに参加することで、ドメインに管理をゆだねます。これで、どのPCにでも誰でもログオンでき、別のPCにあるリソースにアクセスする際に、一々ID,パスワードを入力する必要がなくなりました。 !!!!(余談)ローカル管理から一元管理への流れ ホスト名の解決にしても、NETBIOS名の解決にしても、データベースにしても、たいていのものはローカルでの管理から始まって、共有の方向に向かっているように思われます。 NTドメインの問題点 こうしてNTドメインにアカウント情報が共有され、クライアントPCもドメインのリソースとして登録すれば、どのPCにでもログオンできるし、リソースの管理も一元化できます。 しかし、以下の問題点が・・・。 !!!!扱えるオブジェクト数の限界 NTドメインでは単一のドメイン内で扱えるオブジェクト数がそれほど多くなく約4万が限界でした。そのため大規模な環境の場合、アカウントを登録するドメインとは別にリソースを登録するドメインを分ける・・・ということを余儀なくされることがありました。 !!!!管理者の権限 ドメイン内において管理者は全てのオブジェクトに大しての権限を持つことになります。本来であればひとつの拠点や部署などもっと小さな単位で管理権限を与えたい場合でも、不必要に強い権限を与えなくてはいけませんでした。それを避けるためには、これまたドメインを分割する必要がありました。 !!!!信頼関係の管理 上記のようにドメインを分割した場合には相互に連携するために、信頼関係を結ばなくてはいけません。この信頼関係はドメインが増えるたびに全て追加で登録の必要があったため、維持、管理に問題がありました。 !!!!シングルマスタ アカウントの管理は一元化されたものの、大規模に展開するためには、そのデータベースを複数用意し、参照できる必要があります。NTドメインではこれはPDCがマスター、BDCがバックアップといった具合に実現されています。 しかし、データベースの更新処理自体はPDCにしか行えず、PDCのデータのコピーをBDCが保持するという形態になっていたため、運用上少々不便でした。 ActiveDirectoryでの改善 ActiveDirectoyでは上記の問題点が解消されています。 !!!!扱えるオブジェクト数の限界 ActiveDirectoryでは単一のドメインで扱えるオブジェクトの数が100万オブジェクト以上となり、事実上オブジェクト数のみを問題としてドメインを分割する必要はなくなりました。 !!!!信頼関係の管理 ActiveDirectoryでは「ActiveDirectoryフォレスト」というものを形成し、自動的に推移的な信頼関係を構築するので、信頼関係の維持管理にかかるコストが減少しました。 !!!!管理者の権限 ActiveDirectoryでは単一のドメインの中にOUという管理組織を作成することができ、その中にオブジェクトを格納できます。その上でそのOUに対して管理の委任を行うことができ、「このアカウントにはこのOUの管理を任せる」ということが出来るようになりました。 !!!!シングルマスタ ActiveDirectoryではドメインコントローラーが対等な立場として存在し、そのドメインコントローラーでも情報の更新が行えるマルチマスタモデルになっています。たとえばDNSなどもADに取り込まれており、マルチマスタでの情報の更新が可能になっています。 ただし、全ての機能が対等に存在しているわけではなくて、4つの機能に関しては単一のドメインコントローラーが保持しています、これはFSMO(フィズモ)の役割などと呼ばれます。FSMOに関しては別のところで述べます。 ActiveDirectoryのいけてないところ これで終わるとあまり意味が無いので悪いところも・・・。 !!!!扱えるオブジェクト数の限界 扱えるオブジェクト数の限界は増えたものの、その分データベースにしわ寄せが来ている印象があります。データベースエンジンはMicrosoftおなじみのExtensible Storage Engine(ESE)です。(Exchangeなどでも使われているものです) それぞれのオブジェクトが消費するデータベースが結構大きく、削除済みのオブジェクトも規定で60日間、今度のR2では180日間保持されます。 なので、オブジェクトの絶対数はそれほどでもないけれども、毎日大量に削除〜作成を行うようなシステムでは容量は要チェックです。(あまりないと思いますが) !!!!信頼関係の管理 フォレスト内での信頼関係はいいのですが、その他のNTドメインや別フォレストと信頼関係を結ぼうとすると、結局以前のNTドメインの際の問題に直面します。ある意味仕方ないのかもしれませんが・・・。 ※ただし、フォレスト間の信頼関係に関してはWindowsServer2003で改善されています。 http://www.microsoft.com/japan/windowsserver2003/evaluation/demos/flash_animations/01forest.htm !!!!管理者の権限 OUを分けることで管理を委任できる・・・というところが売りなのですが、OUに対していかに効率的にリソースを移動、配置するかという点はあまりサポートされていません。 たとえば、コンピューターオブジェクトは普通にドメイン参加するとComputersコンテナに作成されるので、そこから手動でOUに移動する必要があります。 ドメイン参加の際にコンピューターオブジェクトが作成される規定の場所を変更することは可能ですが、それも別の1箇所に変更するのみであって、条件によって振り分けるようなことは出来ません たとえば、あるOU以下しか管理権限がない場合に、単純にドメイン参加すると、Computerオブジェクトが管理下にないOUに作成されてしまい、手も足も出なくなってしまいます。このような場合、先にコンピューターオブジェクトを管理下のOUにつくっておけば問題は回避できますが・・・。 OUへのオブジェクトの配置は今のところ独自にアプリケーションを開発するなどして管理してあげる必要があります。 !!!!シングルマスタ 複数のDCに書き込めることのメリットも確かに沢山あるのですが、複数に書き込めるようになった分だけその整合性を取るところでおかしなことが起きます。 書き込んだつもりの情報があとから更新された情報によって上書きされたり、削除したはずのオブジェクトを再作成しようとすると、まだ削除の情報が全てのDCに伝わっていないためにエラーではじかれてしまったり。 最悪なのはDC間の同期がおかしくなった場合です。この場合完全に全ての最新の情報を救うのは絶望的になります。DC間の同期の正常性の確保は非常に重要です！ ...