弊社でも Linuxを野放しにしていたため、
パスワードが各サーバーでパスワードが違って、面倒なことになって来ました。
遅ればせながら、今回は Kerberosを使って、パスワードの管理を
Windowsドメイン ActiveDirectory側にまとめてみましたので、設定の仕方を記録しておきます。

対象としたのは、Debian(etch)ですが、
他のディストリビューションでも設定にはかわりはないと思います。

まず、設定に必要なパッケージをインストールします。

pam-krb5 インストール途中で入力が要求されるものは、DCの名前です。適当に答えておきます。
ただし、ドメイン名は大文字で書かなくてはいけませんので注意します。

インストールが終了したら Kerberos クライアントが使用する設定ファイルを確認しておきます。
# vi /etc/krb5.conf（確認が必要な個所だけ抜粋）

うまく設定できたか、Kerberosクライアント側のコマンドを使って確認します。

うまく認証できれば何のメッセージもなくプロンプトに戻りますが
エラーの場合は以下のようになります。

いくつかの例では、Windowsの DC側のセキュリティログにイベントが残り、
Windows側にパスワードの間違いでロックがかかるようなグループポリシーを設定している場合は、
Linux側のパスワード間違いも対象になるはずです。

さて、Kerberosの設定が正しいことを確認したら、次はログイン等の認証方法を設定している pam関係のファイルを修正します。
/etc/pam.d/login等の特定のコマンド用のファイルを直すよりは、
それらが includeで使用している共通の common-** のファイルを修正します。

# vi /etc/pam.d/common-auth

# vi /etc/pam.d/common-session

以上です。何かのプロセスを再起動したりする必要はありません。

ついでに Windowsドメインと同じ名前ですでに Linux側にパスワードを持ったアカウントがあれば、
/etc/shadow を編集したりしてLinux側のパスワードを消去しておきます。
パスワードを保持したままだと Windowsドメインのパスワード／Linuxのパスワードどちらでもログインできてしまいます。

以降の運用は
アカウント追加時
１．Windows側でアカウントを作成。
２．Linux側でアカウントを作成。
　useradd newUser （←これだけで可）

アカウント無効時
１．Windows側でアカウントを無効化。
２．（Linux側でもログインできなくなる）

これで複数のパスワードを覚えておく必要はなく、Windowsドメインのパスワードを修正するだけで Linuxへのログインパスワードも変わります。
Linux側でユーザーを管理するための UIDや GIDを付番するために、
アカウント自体は Linux側にも作成する必要があるものの、パスワードの管理は Windows側に集約できます。
Linuxへのログインが一切必要ないアカウントは作成しなくてよく、
またLinuxにしかログインしないアカウントは従来通り Linux側にだけ作成することができます。

さらにアカウントまで Windowsドメイン側に統合したければ Winbindや LDAPを使ったりすることになるようですが、それはまた別の機会に。

ハマった原因はというとSolarisに標準で入っているtarで、tarとは圧縮・解凍を行うコマンドです。
Linuxなどに入っている標準のtarはいわゆるGNU tarと呼ばれるものですが、
Solarisに標準で入っているtarはGNU tarとは異なります。

Solaris標準のtarとGNU tarで違うところがいくつかあるのですが、その中の一つとして、
Solaris標準のtarは長いファイル名や深いディレクトリ階層には対応していないことです。

例えば、これがどのように影響するかということですが、
TomcatをSolaris標準のtarで解凍したときに正しく解凍してくれません。
したがって、そのまま作業を進めるとTomcatが起動できないということになります。
私は、解凍で失敗するとは考えてなかったので、Tomcatが起動できずにハマっていました。

では、どのようにするのがよいかということですが、
Solarisの場合でもGNU tar を使うようにしましょう。
Companion CDがインストールされていれば、/usr/sfw/bin/配下にgtarがあります。
インストールしていなければ、GNU tarをダウンロードしてきてインストールしましょう。

何も知らずにSolaris標準のtarコマンドを使ってると思わぬところに落とし穴があります。
Solaris標準のtarには注意です！

抽象クラスであるjava.util.Calenderクラスの具象クラス（java.util.GregorianCalenderクラス）及び、
その派生クラスにて閏年の12月31日を扱った際に、エラーが発生する場合があります。

■発生条件
　以下の全て条件を満たす時、java.lang.IllegalArgumentExceptionが発生することがある。

1)JDKまたはJREの1.2.0、1.2.1、1.2.2、1.3.0、1.3.1を使用する。（パッチレベルは省略）
2)java.util.GregorianCalendarクラス、または、java.util.GregorianCalenderクラスを継承したクラス、
　または、java.util.CalenderクラスのgetInstance()メソッドにて取得したクラスを使用している。
3)setLenient(false)を実行する。
4)以下のいずれかの方法で、閏年の12月31日の日付を設定する。

4-1)システム日付が、閏年の12月31日の時、java.lang.Calendar.getInstance()または、
　　new java.util.GregorianCalendar()を実行する。

4-2)set()メソッドで閏年の12月31日の値を設定する。
　　かつ、getTime(),add(),roll(), get(),computeTime(),getTimeInMillis(),complete(), computeFields()
　　のいずれかのメソッドを実行する。

4-3)setTime()メソッド、setTimeInMillis()メソッドで閏年の12月31日の値を設定する。

4-4) add()メソッドによる計算により、閏年の12月31日の値を設定する。

5)同じオブジェクトに対し引き続き、set()メソッドで、閏年以外の値を設定する。
6)getTime(), equals(), before(), after(), add(), roll(), get()
computeTime(), getTimeInMillis(), complete()のいずれかのメソッドを実行した場合。

■回避例
1)別の日付を設定する直前に(発生条件5)の直前に、Calendar.clear()を呼ぶ。
2)別の日付を設定する際は、新たにインスタンス化したオブジェクトを使用する。

今回は、昔のことをすっかり忘れていた為、嵌ってしまいました。
昔、社内でも報告した記憶があるのですが。。。

フリーソフトで配布しているBugZeroはPHPで動作しているのですが、
今回WindowsWebServer2008に変更した際にアップロードしたファイルが、
アップロードした人以外には参照できないという問題が発生しました。

原因は、
PHPがファイルのアップロードを行う際にファイルを一時的に別のフォルダに保存し、
アップロード完了後にアップロード先に指定されているフォルダに移動しているため、
一時保存のフォルダのセキュリティでIISの匿名認証のユーザが設定されていない場合、
そのフォルダのセキュリティ設定をファイルが継承してしまいます。
このため実際に保存されるフォルダで匿名認証のユーザが設定されていても、
その設定を引き継がないという状態でした。

解決方法は、
１．PHPの設定ファイルのphp.iniの設定項目にある「upload_tmp_dir」に、
　　フォルダを指定する記述を行う。
２．upload_tmp_dirに指定したフォルダに匿名認証のユーザの権限（読み取り権限）を設定する。
３．設定を反映するためにIISを再起動する。

以上で、アップロードしたファイルに匿名認証のユーザの権限が設定されます。

ローカルのネットワークについて、接続を緩めに許可していると、
その時点でいったいどれだけの機器をつないでいるのか、時々把握しきれなかったりしませんでしょうか？

Windowsマシンだけであれば、Microsoft Windows Networkで一覧できたりしますが、
Windows以外の OSや UPnPに対応していない機器を使っていたりすると、
いちいちいろんなアドレスに Pingを打って、使われているのかいないのかを確かめたりしなくてはならず、とても面倒です。

そんな時、わざわざ別だててネットワーク調査用のアプリケーションをインストールしなくても、
標準コマンドだけで簡易的にネットワーク機器を調べられます。
それが、「ネットワークブロードキャストアドレスに ping」です。

例えば、社内のネットワークが 192.168.1.0/24 であった場合、
　ping 192.168.1.255 (Windowsの場合)
とか
　ping -b 192.168.1.255 (Linuxの場合)
します。この ping の結果は、大半の環境では timed out になったりしますが、
その後
　arp -a (Windowsの場合)
とか
　arp -n (Linuxの場合)
をすると、ローカルブロードキャストネットワーク機器の
IPアドレスと MACアドレスがのきなみ arpリストに入っているのです。

FireWall等で制限のかかっている機器は対象とならない場合もありますが、
取り急ぎ確認してみるには使える機能ではないでしょうか？

実際には改行コードを変換するのではなく、
変換するファイルを読み込んで別のファイルを作成するというもの。
その際に、改行コードを設定します。

下記は改行コードを「CRLF」から「LF」に変換します。

'書き込みモード、読み込みモードをコンストで保持
Const ForReading = 1, ForWriting = 2

'変換するファイルの名前を設定
filename = "ファイルの名前"

'新しく作成するファイルの名前
'最後に名前を変換元の名称に変換するので何でもいいです
tmpfilename = "一時ファイルの名前"

Set obj = CreateObject("Scripting.FileSystemObject")

'変換するファイルを読み込みモードで開く
Set file = obj.OpenTextFile(filename, ForReading)

'作成するファイルを書き込みモードで開く
Set tmpfile = obj.OpenTextFile(tmpfilename, ForWriting, True)

'ファイルの終わりに達するまでは繰り返す
do while not file.AtEndOfStream

'変換元のファイルから一行読み込む
buf = file.ReadLine

'書き込む際に改行コードをつける
tmpfile.Write buf & vbLf
loop

'各ファイルの
file.Close
tmpfile.Close

'作成元のファイルを削除
obj.DeleteFile filename

'作成元のファイルに移動
obj.MoveFile tmpfilename, filename

MsgBox "終了"

変換するデータや環境にもよるのですが、
ただ単純に一行読み込んで、一行出力するだけなので、
10万件でも５～１０秒程度で変換出来ると思います。

※1レコード400バイトのデータ10万件で実行したところ、5秒程度で変換できました。

簡単な構成ですと、１つの実行ファイル(exe)で、
app.configも１つとなり、何も問題ないのですが、
複数の実行ファイルで、共通のコンフィグファイルを
読み込みたい場合があります。

その場合、app.configに記述するのではなく、
共通の外部ファイルを作成し、
"configSource"属性で指定すると良いでしょう。

  <!-- 接続文字列はCommon_connectionStrings.configで管理します-->

  <connectionStrings configSource="Common_connectionStrings.config" />

  <!-- 設定情報はCommon_appSettings.configで管理します-->

  <appSettings configSource="Common_appSettings.config" />

こうすることによって、外部ファイルを共通の設定ファイルとして扱えます。
データベースの接続文字列を変えたい場合は、一つのファイル変更で済むことになります。

なお、注意点ですが、
複数の実行ファイル(exe)に分割する場合は、
それぞれのビルド出力パスを同じにすると良いです。
（プロジェクトのプロパティで設定）
その上で、同一フォルダにコンフィグファイルを配置しておくと、
管理しやすいです。
そうしておけば、コンフィグ内容に相対パスを指定しても問題ないことになります。
ただし、セットアップファイルを作成する際は、
パスが狂わないように、「プライマリ出力」のパスに気を付けてください。

この時に社内のネットワーク ActiveDirectoryの グループポリシーを使ってそれを実現している場合、
・Windows2003までのドメインでは、パスワードのポリシーに関しては、ドメイン全体に対して１種類のポリシー(Default Domain Policy)しか設定できない。
・パスワードのポリシーはコンピュータの構成で設定するものなので、コンピュータがドメインに参加してさえいればローカルのアカウントに対してもその設定が適用される。
・Windows Server 2008のローカルの Administratorはデフォルトで『パスワードを無期限にする』のチェックが入っていない。
という理由から、放って置くとマシンローカルのアカウントのパスワードが有効期限切れになります。
あまりパスワードの有効期限について意識しないで Windows Server 2008をインストールすると、
インストール直後は良くても数ヶ月過ぎるといきなり何かが正しく動かなかったりする可能性があるということです。

そうならないためには、
・意図して Windows Server 2008のローカルの Administratorの『パスワードを無期限にする』のチェックを付ける。
もしくは
・ちゃんと定期的に Administratorのパスワードを変更する。
といった作業が必要です。

なお、Windows 2008のドメインにすれば、パスワードのポリシーを複数設定できるため、ポリシーの適用除外が指定できるようですが、
もともとセキュリティ向上のために Local Administratorのパスワードはデフォルトでは無期限になっていないのですから、よく考えて行うべきでしょうね。

実は、コマンドプロンプトでもファイルの内容の違いを
調べることが可能なのです。

ではどうすればコマンドプロンプトで、ファイルの違いを確認できるのか
といいますと、それには【 fc 】コマンドを使用します。

C:\>fc hikaku1.txt hikaku2.txt

ファイルの内容に違いがなければ以下のように
表示されます。

ファイルの内容に違いがあれば以下のように
表示されます。

このままだと違いがあるのが分かっても、ではどこに違いがあるのかが
すぐには分かりません。
そんなときは、オプションに【 /n 】をつけると行番号も表示されるため
異なる箇所がすぐに分かります。

C:\>fc hikaku1.txt hikaku2.txt /n

エディタで比較するのに飽きたら、コマンドプロンプトでたまには比較してみてください。

VirtualServer の仮想HDファイル *.VHD の中身をゲストマシン以外（ホストマシン等）でも見たい場合があります。
仮想マシンを起動していてネットワークが使える状態であれば、フォルダを共有したりすればよいのですが、
大量にファイルを移動させたい場合にわざわざ（仮想）ネットワーク経由になるのがいやだとか、
仮想マシンそのものを起動していない（メモリ不足で起動できない等）場合には
VirtualServerをインストールしたフォルダ \Program Files\Microsoft Virtual Server\ 中にある \Vhdmount\vhdmount.exe というコマンドでホストマシンのディスクとして見ることができます。
例：コマンドプロンプトで
　vhdmount /p <VHDファイル名>　　　仮想ファイルをドライブとして認識させる。
　vhdmount /u /d All　　　変更を破棄して全ての仮想ディスクを取り外す。

残念ながら VirtualPC には vhdmount.exe は付いておらず、このコマンドはコピーしただけでは動作しないので、最低限 VirtualServerをカスタムでインストールする必要があります。

ついでに、Windows Server 2008の Hyper-V にも vhdmount.exe が付いていませんが、
Hyper-Vの場合には自分で“プログラムを書く！”という方法が主に紹介（推奨？）されていて、
最も端折って書けば、以下です。

VhdMount.vbs

他にも、C#.net や VBScript(WSH)での正しい？記述が以下にあります。
(MSDN) Mount Method of the Msvm_ImageManagementService Class

（ Msvm_ImageManagementService を使ったプログラムは Hyper-Vの環境でしか使用できないようです）

※VirtualServer/VirtualPC と Hyper-Vの *.VHD には基本的には互換性があるようです。
ただし、ベースとなる仮想マシンが異なるため、一部ハードウェアの認識をしなおす必要がある場合があるのと、
Virtual～用の 追加機能と Hyper-Vの追加機能には互換性がないので、追加機能を入れなおす必要があります。
その際、Virtual～用の 追加機能のバージョンが 13.813以上でないと Hyper-Vの環境からはアンインストールできないようなので、
それ以下のバージョンの場合は、予めに Virtual～ の環境でアンインストール（もしくはアップグレード）しておく必要があります。

VirtualServer/VirtualPC のゲストマシン（中の仮想マシン）でローカルディスクのファイルに対して読み書き繰り返していると、
ホストマシン（外の実態マシン）で見える仮想HDファイル *.VHD の容量は実質的に使用している容量よりもどんどん大きくなっていきます。
ホストマシンの Virtual～ には、仮想ディスクの最適化（圧縮）のメニューがありますが、
通常はこれだけを実行しても期待通りにはファイルサイズは小さくなりません。

仮想ディスクを整理するには手順があって、
１．ゲストマシンで、全てのドライブに対してデフラグを行う。
２．ホストマシンの Virtual～ をインストールしたフォルダ \Program Files\Microsoft Virtual～\ 中の
　\Virtual Machine Additions\ に、Precompact.iso もしくは ～Precompactor.iso というCDのイメージがあるので、
　ゲストマシンの CDで見られるようにする。
３．ゲストマシンで、CDの中にある Precompact.exeを実行する（通常は自動起動するかも）
４．precompactが終了したらゲストマシンをシャットダウン。
５．ホストマシンでディスクの最適化を行う。
の順に実行しないと、思うような最適化がされません。
（何かのタイミングでゲストマシンを停止してファイルを整理する必要があるということです）

ついでに、少々注意。
Ａ．ゲストマシンに Linuxを使った場合には、precompact に相当する明示的なコマンドはどうも存在しないようです。
　precompactが行っていることは「未使用のディスク領域を nullを書き込んでいる（0で埋め尽くしている）だけ」とのことなので、
　cp /dev/zero hogehoge で DiskFullになるまで放置した後 rm hogehoge してみましたが、思うようには縮まりませんでした。
Ｂ．Windows Server 2008の Hyper-V には precompact.exe が付いていません。
　ドキュメントには precompactしなくても仮想ディスクは最適化できるらしいように書いてあるのですが、
　実際にやってみると思わしくなく、Virtual～ を入れたマシンから precompact.exe を持ってきて実行した方が良く最適化されるようです。

試しに、自分のクライアント Office2003がインストールされている環境で確認してみたところ。
次のようなコードで使うことができた。

OCRTest.vbs(WSH)

試しに ILOVEXのホームページにあるバナーアイコンを幾つか読み込ませてみると、

　　⇒　「novex システム開発専用サイトテム開発を一括で請負いまち」
　　⇒　「- x 遡 et 例 ect 二 ― 11 日報型ブ口ジェ外管理到」
　　⇒　「Windows7 オルダーアクセス権限確肥ツール Ik Au - Folder」
　　⇒　「Movable Type を使った WEB サイト構築」

（デザインされたバナーを読み込ませること自体に無理がありました。すいません）

ある程度 精度に目をつぶれば、お手軽 OCRに使えるかもしれないですね。

今回はEXCEL：VBAによる入力規制のやり方をご紹介します。

関数
<<<<<
入力規制をする範囲.Validation.Add(Type, AlertStyle, Operator, Formula1, Formula2)

・Type 必ず指定します。入力規則の種類を指定します。
　　xlValidateInputOnly：すべての値
　　xlValidateWholeNumber：整数
　　xlValidateDecimal：小数点
　　xlValidateTextLength：文字列（長さ指定）
　　xlValidateList：リスト
　　xlValidateDate：日付
　　xlValidateTime：時刻
　　xlValidateCuestcm：ユーザー設定

・AlertStyle 省略可能です。入力規則でのエラーのスタイルを指定します。
　　xlValidAlertStop：停止
　　xlValidAlertWarning： 注意
　　xlValidAlertInformation：情報

・Operator 省略可能です。入力規則での演算子を指定します。
　　xlBetween：Formula1とFormula2の間
　　xlEqual：Formula1と等しい
　　xlGreater：Formula1より大きい
　　xlGreaterEqual：Formula1以上
　　xlLess：Formula1より小さい
　　xlLessEqual：Formula1以下
　　xlNotBetween：Formula1とFormula2の間以外
　　xlNotEqual：Formula1と異なる

・Formula1 省略可能です。データの入力規則での条件式の最初の部分を指定します。

・Formula2 省略可能です。データの入力規則での条件式の 2 番目の部分を指定します。
引数OperatorがxlBetweenまたはxlNotBetweenの場合、この引数は無視されます。
>>>>>

以下が例となります。
Add以外にも色々と入力規制に関する関数があるので少し紹介します。

例）
With Range("B:B").Validation

　　既存規則削除
　　.Delete

　　規制を追加
　　.Add Type:=xlValidateWholeNumber, _
　　AlertStyle:=xlValidAlertInformation, _
　　Formula1:="1", Formula2:="99"
　　
　　IMEモードの指定も可能
　 .IMEMode = xlIMEModeAlpha
　
　　エラー時のダイアログの設定
　　.ErrorTitle = "整数のみ入力可"
　　.ErrorMessage = "入力できるのは、1から 99 までの値です"
　　
End With

まず、DBから取得するバイナリデータは画像がそのまま格納されているので
特に何も処理せず、取得したデータをPHPで画面へ出力します。

>> 以下ソース

$data = 画像データ;
header("Content-type: image/jpeg");
echo $data;

<< ここまでソース

簡単に書くとこのような処理になります。このプログラムがimage_output.phpという名前とすると
画面上のHTMLタグは以下のように記述していました。
<img src="http://hoge.com/image_output.php?imgid=9238291">

処理の流れとしては、
１）ユーザーがブラウザ経由でHTMLにアクセス
２）HTMLのimgタグに埋め込まれているPHP(image_output.php)が呼び出され
　　画像IDが9238291の画像をDBから取得して表示する。
　　すでにApacheでPHPの処理結果がキャッシュされていれば、
　　Apacheのモジュールでキャッシュ側のデータを表示する。
　　
といった、2段階の処理が行われます。

これで何も問題ないと私は思い込んでいました。
しかし様々なブラウザでテストすると、IEとFirefoxでは画像が表示されましたが
Operaではバイナリデータが表示されてしまいました。
携帯電話の場合は、DocomoとSoftbankは画像として表示されましたが
AUでは表示されませんでした。
Apacheのキャッシュが保存されるディレクトリは、どんなファイルでもMime-Typeをimage/jpegにするような
設定を試みましたが解決せず、結局自前でキャッシュ機能を作成することとなりました。

Apacheのキャッシュ機能では、ファイルがどんなファイルであってもMime-Typeは無視され、
デフォルトの設定ではプレーンテキストとして扱われてしまうようです。
ブラウザによっては、imgタグであれば画像として表示するような動きをするものもあれば、
Mime-Typeの情報をしっかり見るブラウザがあるようです。

画像を動的に出力するようなシステムを作る際は気をつけてください。

ちなみにAUの端末は拡張子がjpgであれば、
Mime-Typeに関係なく画像として表示する動きをするようです。

各機能の利用方法については、いろいろなサイトに載っていますのでそちらを見ていただくとして、
ここではOracle10gから使用可能であるDBMS_CRYPTOパッケージとTDEの機能について、
私なりに使ってみた感想を書きます。

■DBMS_CRYPTOパッケージ
DBMS_CRYPTOパッケージは、SQLの中で指定する関数となります。
暗号化したい列に対して、アプリケーション側で明示的に暗号化ロジックを組み込んでいくことになります。
この方法で実装した場合、CPU負荷が高くなる場合があり、パフォーマンスへの影響もそれなりに考えられます。
暗号化したときの暗号鍵も、知られないように管理しておく必要があります。

では、暗号化した列のテーブルを参照したときはどのような挙動になるかといいますと、
DBMS_CRYPTOでの暗号化に関しては通常のテーブルと同じようにSELECTでデータを参照することができます。
とはいえ、暗号化した文字列でテーブルに格納されているため、SELECTでテーブルを参照しても
すぐには生のパスワードを知られることがないという利点があります。

■TDE(Transparent Data Encryption)
TDEは、データベースのほうで設定を行います。
設定を行っておけば自動的に暗号化・複合化を行ってくれるため、
アプリケーション側ではとくに意識することなく実装することができます。
CPU負荷もそれほど見られないため、パフォーマンスへの影響は少ないといえます。
また、暗号鍵はOracle Walletという別のソフトウェアで一括管理されます。

では、TDEを利用した場合のテーブル参照についてどのようになるかといいますと、
暗号鍵がクローズされている場合、暗号化した列はSELECT文で参照できずにエラーが返ってきます。
暗号化した列を含むSELECT文を発行しても同様にエラーが返ってきます。
つまり、"SELECT * FROM ～" というような書き方はできなくなります。
暗号鍵をオープンすることで、SELECTでエラーにならずにデータを参照することができます。
しかし、ここで注意しなければならないのが、暗号鍵をオープンしてテーブルを参照することで
生のパスワードが見えてしまうことです。
したがって、先の説明ではアプリケーション側では意識しなくてよいと書きましたが、
その代りに暗号鍵のオープン／クローズは意識する必要がでてくるのではないかと思います。

上記の内容をそれぞれまとめると、以下のようになります。

Oracleが提供している資料などを見るとDBMS_CRYPTOパッケージよりもTDEのほうが良さそうな気はしますが、
TDEを使っても結局のところアプリケーション側で意識する必要は出てくるのではないかと思います。
そう考えるとTDEのほうは、SELECTで何も表示されないのならまだしも、
エラーが返ってくるというのが非常にマイナス点だと感じました。
（パフォーマンスがどの程度影響出てくるのか気になるところではありますが・・）
使う場面によりけりですが、TDEよりもDBMS_CRYPTOパッケージのほうが使い勝手は良いという印象です。

私が使用した時の感想なので主観的な意見が多々あるかと思いますが、
ここは違うぞ、という部分がありましたら指摘いただければと思います。