現象

サーバ側Exchange Server 2010 (SP1)、クライアント側Outlook 2003 (SP3)の環境で、Outlook側で[送受信]ボタンをクリックするなどしてサーバと同期すると、メールの受信等は行えるものの、エラーが発生する。同期ログには「Microsoft Exchange オフライン アドレス帳 0X8004010F」のエラーメッセージが残されている。

対処法

　まず前提として、Exchange Server 2010 のセットアップ中に「組織内に Outlook 2003 または Entourage を実行するクライアント コンピュータはありますか?」との問いに[はい]と答えておく。[いいえ]と答えてしまったときは、セットアップ完了後、Exchange Serverヘルプの「パブリック フォルダーについて」と「パブリック フォルダー データベースの作成」を参照して別途パブリックデータベースを作っておく。もっとも、これをしないとOutlook起動時に「Exchange サーバー管理者が、使用しているバージョンの Outlook をブロックしています。」と出てそもそもまったく接続できないのだが。
　そのうえで、サーバ側のExchange Management Console(EMC)にて次のように設定。

1. ツリーで[組織の設定]-[メールボックス]をクリック。
2. 右ペインの[データベースの管理]タブをクリック。
3. 上ペインの[Mailbox Database …]の行を右クリックして[プロパティ]をクリック。
4. [クライアントの設定]タブをクリックし、[オフライン アドレス帳]の[参照]をクリックして[既定のオフライン アドレス帳]を選択して[OK]をクリック。[OK]をクリックして[Mailbox Database … のプロパティ]を閉じる。
5. 右ペインの[オフライン アドレス帳]タブをクリック。
6. [既定のオフライン アドレス帳]行を右クリックして[プロパティ]をクリック。
7. [配布]タブをクリックして次のものにチェックを入れ、[OK]をクリックする。
   • [Outlook 2003 SP2 またはそれ以降 (Version 4)]
   • [Web ベースの配布を有効にする]
   • [パブリック フォルダーの配布を有効にする]
8. [既定のオフライン アドレス帳]行を右クリックして[更新]をクリック。表示されたダイアログボックスで[はい]をクリック。

　最後にOutlookを再起動して試してみる。

所感

　KB905813に、「この資料は以下の製品について記述したものです」に入っているにもかかわらずExchange Server 2010向けの手順が載っていないのはいかにも不親切。いや、そもそも別の問題なのだろうか。なんだかよくわからない。

(NHK BSPにて放送)
　著作権失効対策ではあろうけれど、それにしてもこれは見直す価値のある高画質。ノイズが皆無とは言わないまでも相当除去され、画面のブレもない。また、HDらしい高解像度でピントが誰の顔に合っているかがはっきりわかる。映画館で見るよりよほどよく見えるのでは。音質もよく背景の音効がよく聞こえる。
　中身は従来通り素晴らしいのだけど、何度目かの再鑑賞で、やはり若干ペースが遅いように感じられたのは致し方ないところか。大阪の息子はこの話に必要だったか今でも確信が持てない。
　何度見ても杉村春子の演技は頭抜けている。
　名作の影に名映画音楽あり。あまり言われないけれど、この作品も音楽がいい。最近の邦画はまず音楽が安っぽくてダメだね。

　この話は、「老いた父が、ひとたび巣離れした子供はもはや当てにすべきでないと気付かされる話」である。

95点/100点満点

メモ
製造所固有記号「P13」は群馬県前橋市の工場。(ほか、A66が福島県酪農業協同組合 郡山工場としたページあり。また、こちらのページからするとA11およびA50は沖縄産か。追記: こちらのページはある程度まとまっている)
使用水は、基本的に工場の地下水を浄水器に通した純水で水道水は不使用。ほか高知県沖の海洋深層水も入っているが使用割合は非公表。
賞味期限は製造日の1年後の日付。

参考: 群馬県の放射線量など。水道水の測定結果は18日からの分しかない。また、地下水への放射性物質の浸透速度等は不明。

現象

Windows UpdateにてWindows Internal Database Service Pack 4 for x64 Edition (KB2463332)のインストールが失敗する。エラーコードは643。

原因

(同じKB2463332でもMicrosoft SQL Server 2005 Service Pack 4となっているものには通常当てはまらない。)
%SystemRoot%\SYSMSI以下にあるWindows Internal DatabaseのディレクトリがNTFS圧縮されているとService Packのインストーラがインストールを拒否するため。

対処法

%SystemRoot%\SYSMSI以下のNTFS圧縮を解除する。
(追記)……とだけ書いておいたところ、この記事を見た直後に「%SystemRoot%\SYSMSI以下のNTFS圧縮を解除する」という検索語で検索する人が続出。これはおそらくこの文の意味がわからなかったということではないかと思われ。
　具体的な手順としては、エクスプローラ等で通常C:\Windows\Sysmsiフォルダ(Windowsをインストールしたドライブが違うときはC:をその別のドライブに置き換えて読むこと)のプロパティを開き、[詳細設定]をクリックして出てくる画面の[内容を圧縮してディスク容量を節約する]チェックボックスを外して[OK]をクリックする。それでもし[属性変更の確認]画面が出てきたときは[変更をこのフォルダー、サブフォルダーおよびファイルに適用する]を選択して[OK]。

所感

　Windows Internal Databaseは実質SQL Serverです。で、SQL Serverのデータファイルは圧縮しないほうがパフォーマンスがいいので、SQL ServerのService PackはSQL Serverのディレクトリが圧縮されていると、その旨のエラーを出して終了する仕様になっています。Windows Internal DatabaseのService Packも実質SQL ServerのService Packと同等の内容で、そのためにこのような現象が起こるのだと思われます。Windows Updateでは一切のメッセージが抑止された状態でインストールが進むので、エラーの中身がわかりづらいわけですね。
　システムドライブは容量がひっ迫しがちであって、圧縮されている状況は一般的ですから、Windows Internal Database向けService Packとしては、本来、圧縮されていてもエラーにならないように仕様変更したものをリリースすべきでした。システムドライブが圧縮されている状況でテストしなかったのでしょうね。
　もっとも、そもそもディレクトリが圧縮されていたらエラーにするというSQL Server Service Packのインストーラの仕様自体やりすぎなのだと思われます。パフォーマンスは悪いながらも動くには動くのであって、ユーザがそれを承知で動かしているならインストーラが文句を言う筋合いのものではないのですから。
　しかもさらに問題なのは、この仕様がドキュメント化されていない(!)ということ。だから同じMicrosoftの社員であろうところのWindows Internal Database Service Packの担当者(たぶんSQLSPの担当者とは違う)すらこの仕様を把握できなかったわけです。Microsoftはこの手のドロナワ式仕様追加が昔からやたらと多い会社で、もうこれはこの会社の体質なんでしょうねえ。

追記

　同様の原因によりWindows Update エラー 6d9eで失敗するケースもあるらしいことが記事として掲載されているようなんですが、うちではそういうエラー番号ではありませんでした。まあ、この記事で説明されているのはWindows Internal Database扱いのService Packではないし、SP3ですからね。
　リンクをたどると、圧縮されているとエラーになるという問題について説明したサポートエンジニアのMSDNのブログ記事がありますが、こんなところに書き散らさないできちんとknowledge base(サポートオンライン)に登録すべきではないでしょうか。MSはどこまでだらしなくなるのでしょう。ドキュメントに対する態度は年々ひどくなってます。

　かの手塚治虫氏はマンガの本質を風刺だと喝破しておりましたが……
　まあ結局ですね、ドラマというものの二大分類について言えば、観客から見て、風刺されているのが自分自身だと感じるようならシリアスドラマ、他人が風刺されていると感じるようならコメディなんですよ。そして誰も風刺されてないようなものはドラマではない。
　風刺というのは、描写(再現・ミーメーシス)を用いた遠まわしな批判です。

おお神よ、カメラを揺らす撮影監督に速やかなる死を与え給え。

65点/100点満点

　SUAには標準ではbashがない。
　古～いバージョンならバイナリも配布されていたらしいものの、それはちょっと……ということで、ソースから最新版をビルドしたいわけだったのだが、bash 4.1のときはあれこれ苦労したあげく、64bit環境であることがよくないのか、なぜか$(…)形式の展開だけsyntax errorになる(`……`形式は動くのに)という不可解な動作をするバイナリしか作れなかった。しかし最近出たbash 4.2ではあっさりと動くようになっていた。
　わずかにひっかかるのは次の２点。

1. 相変わらずconfigureでシステム名を認識せず、「configure: error: cannot guess build type; you must specify one」と言われるので、support/config.guessとsupport/config.subを最新版(config.guess/config.sub)に入れ替える。
2. ログインシェルとして使うとき、そのままだとlessなどがWARNING: terminal is not fully functionalと警告を出してマトモに動こうとしない状態になる。bash起動時、環境変数のTERMに空文字列が設定されなければならないところがdumbという文字列が設定されてしまうために/etc/profileのTERMを設定する部分がうまく動いていないのが原因で、ワークアラウンドとしては、起動時のコマンドラインをC:\Windows\posix.exe /u /c /bin/bash -c "TERM= /bin/bash --login -i"のようにする。TERM= と/bin/bashの間にスペースが入っているのに注意。

　まだmake testsで少しエラーは出るのだが、4.1のときの惨憺たる結果に比べれば上出来。

　これで使い慣れたUNIX環境に一歩近づいたわけだが、ただSUAそのものは、全体的に動作がもっさりしている上に、時々ひっかかるように十秒くらい動作を停止するようなときもあり、まだUNIX環境として実用レベルと言いがたいところがある。

　opensslのライブラリ(libcrypto)にはlibdes互換機能がついていたが、openssl-0.9.7からそれがdes_old.hによる置換マクロのみの対応となり、libdes互換のためのシンボルは存在しなくなった。このため、libcryptoを共有ライブラリ(libcrypto.so)の形で動的リンクしてlibdes互換機能を利用していたプログラムの場合、openssl-0.9.6からopenssl-0.9.7以降に更新するとバイナリ互換性が失われ、des_cbc_encryptなどいくつかのシンボルが見つからないというエラーが発生するようになった。
　当方の場合、opensslをアップデートしたところ、OS(古いRedHat)にバイナリでインストールされているcyrus-saslパッケージに入っているlibdigestmd5.soが参照しているdes_cbc_encryptなどがundefined symbolとなってしまった。これを使っているpostfixのsmtpdがdlopenするときに、/var/log/messagesに「unable to dlopen /usr/lib/sasl2/libdigestmd5.so.2: libcrypto.so.2: cannot open shared object file: No such file or directory」というエラーを吐く。
　LD_PRELOADで逃げる手も試したがdlopenには効かないようであった。opensslには深刻な脆弱性が見つかっているので、0.9.6のまま使い続けるというわけにもいかないし、そうかといって、再コンパイルしようとすると依存しているバイナリやライブラリを芋づる式にコンパイルしていかなければならなくなりそうで手がつけられない。
　メジャーバージョンアップでもないのにまったくとんでもない仕様変更をしてくれたものだが、変わってしまっているものは仕方がないので、以下のようにしてなんとか強引に対処した。

openssl-0.9.8r:
% ./config shared -DOPENSSL_DES_LIBDES_COMPATIBILITY
% make
% make test
# make install
# cd /lib
# ln -s /usr/local/ssl/lib/libcrypto.so.0.9.8
# ln -s /usr/local/ssl/lib/libssl.so.0.9.8

libdes-4.04b:
% patch < des.Makefile.diff # libdes.so.3を作りたいときのみ。
% make

適当なディレクトリで:
% gcc -shared -Wl,-soname,libcrypto.so.2 -o libcrypto.so.2 -Wl,--whole-archive libdes.aへのパス libcrypto.aへのパス -Wl,--no-whole-archive -ldl -Wl,-noinhibit-exec
# cp libcrypto.so.2 /usr/lib/sasl2
# cp smtpd.libdes /usr/libexec/postfix
# chown root.root /usr/libexec/postfix/smtpd.libdes
# chmod 755 /usr/libexec/postfix/smtpd.libdes
# vi /etc/postfix/master.cf

smtp inet n – n – – smtpd
とある行(chrootの列は標準ではyだけど)を
smtp inet n – n – – smtpd.libdes
に変更。

# /sbin/service postfix restart

　若干の間違いはあるかもしれないが、大体こんな感じ。
　要するにlibdes.aとlibcrypto.aをくっつけて一つの共有ライブラリを作っているのだけど、シンボルが重複してエラーになるのを-noinhibit-execで無理やり無視させたりして、かなり強引。なんとなく動いているように見えるだけで、実は中の動作はめちゃくちゃかも。
　こんな怪しいライブラリを標準のライブラリのサーチパスに入れておくのは危険なので、上記の通り、smtpdだけに適用するsmtpd.libdesというスクリプトを作った。

注: この記事は個人的なメモです。真似するのは自由ですが無保証です。

　ハリウッドの世界だともうシナリオは三幕構成というのが金科玉条のごとく守られているようなイメージがあります。で、シド・フィールドあたりのハリウッド系のシナリオテキストを見ると、しばしばこの三幕構成はアリストテレスも主張してることだみたいなことが書かれていたりします。
　しかしこれは本当でしょうか。確かにアリストテレスは悲劇は「始め」「中間」「終わり」の３要素を持ってないとダメだという趣旨のことを述べてはいるのですけれど、これらがそれぞれ幕を構成するなどとは言っていません。

　すでにわたしたちは、悲劇とは、一定の大きさをそなえ完結した一つの全体としての行為の再現である、と定義した。
(中略)
　全体とは、初めと中間と終わりをもつものである。初めとは、それ自身は必ず他のもののあとにあるものではないが、そのあとには本来他のものがあったり生じたりするところのものである。反対に、終わりとは、本来それ自身は必ず、あるいはたいてい、他のもののあとにあるものだが、そのあとには何もほかにないところのものである。また中間とは、本来それ自身も他のもののあとにあり、それのあとにも他のものがあるところのものである。
　それゆえ、巧みに組み立てられた筋は、勝手なところからはじまることも、勝手なところで終わることも許されず、いまあげた形式(初め、中間、終わり)を守らなければならない。
(アリストテレス著『詩学』(松本仁助・岡道男訳)7章)

　これが原文です。アリストテレスの著書の例に漏れずなにか禅問答のようでもありますが、「幕」もしくはそれと同等の言葉はまったく出てきていません。ではこれらは何を意味しているのかというと、私見によれば今日にいうところの「原因」「因果関係」「結果」のことを言っているのだと思われます(ご興味のある方は、アリストテレスのこうした言葉遣いについて『形而上学』の2巻2章もご覧ください)。
　なお、これは有名な「三単一の法則」のうちもっとも本質的とされる「行為の単一」の元になった記述でもあります(もっとも、この後の8章の方でも大きく取り扱われていますが)。

　ところで実はアリストテレスは別のところで悲劇の構成について触れているのです。

すべての悲劇には、出来事の結び合わせの部分と、解決(解きほぐし)の部分がある。劇の外におかれていることがらと、多くの場合、劇のなかで起こることがらの若干のものが、結び合わせの部分であり、残りは解決の部分である。わたしのいう結び合わせとは、始まりから運がよいほうへ、または悪いほうへ転じる直前のところまでのことであり、解決とは、この変転の始まったところから結末までのことである。
(前掲書18章)

　これを読めば、実際にはアリストテレスは２部構成を主張していたことがわかるでしょう。

　Windowsのシステムドライブの容量が苦しくなってくると、%systemroot%\installer(典型的にはC:\Windows\installer)のサイズがバカみたいに大きいのが気になって、別のドライブに移したくなる人も多いだろう。そして、Windowsに慣れている人ならば、その手段としてlinkd.exeを使えばいいんじゃないかと思いつく人もいるだろう。実際、軽く検索してみるとそれを実行してうまくいったというレポートもある。ところが、さらに詳しく調べると、実はこれがとんでもない罠らしいのだ。
　別ドライブにディリクトリを移動してlinkd.exeで%systemroot%\Installerにジャンクションを作った直後はうまく動いているように見える。ところが、新しくアプリケーションをインストールすると、Windows Installerがそのディレクトリの中身を全部削除して空っぽにした上でジャンクションを解除し、普通のディレクトリとして作りなおすらしい。こうなると、当然既にインストールされているアプリケーションのアンインストールは一切できなくなるとのこと。
　なんでマイクロソフトはこんないやがらせみたいな仕様にしたんだろう?