予想していた訳ではありませんが、そう決着しそうですね。

以前の記事です。↓
http://softonhouse.jp/nori-sdc~5164

土下座まではしなかったものの、県民を騒がせた事については、きちんと謝罪はしたようで評価できます。

県外に分散移設するに越したことはないのでしょうが、それはキャンプシュワブへ移転し、普天間基地の負担を軽減した後、時間をかけて実現するしかないでしょう。

それを受けて私が望むのは、V型滑走路ではなく、環境アセスメントが許すのであれば平行滑走路であった欲しいという事です。

V字型滑走路は、米軍が撤退した後に民間滑走路として利用するにも、または公園緑地や施設用地として転用するにも、空から見て非常に異質に見えるという事です。

特に埋め立てという事であれば、今までにない海岸線を形成することは間違いなく、できるだけ潮流に逆らわず、かつ、見た目に違和感のない形状であるほうが、１０年後、２０年後にはしっかり環境が形成されるでしょう。

沖縄に残留してしまう事は残念ですが、本当の意味での海外移転に向けて、政権が変わろうとも引き続き努力して欲しいものです。

と、思ったら XFER の有効期限が１日の設定だったそうで。。。。

なんと馬鹿げた設定でしょう。

今はなき H氏 の置き土産でした。

H氏 の罠はいたるところに仕掛けられていて、今まで何度も踏みました。
都度罠を外してきたのですが、まだあったとは･･･。

それにしても期限が 24H なんて何故そんな設定に？

まあ･･･その置き土産もこれで最後でしょう。
罠が仕掛けられていそうな機器はこれで終わりです。
近々DNSも新型へ交換されるのでもう心配はありません。

そんな訳でご迷惑をおかけしました。

申し訳ありませんでした。

まあ・・・進歩ないのですが。

今年に入ってから(正確には昨年後半から)、PCと向き合う時間が長いため、どうしても目が疲れやすく、その分調子は良くありませんでした。

ジョッキビールなど飲もうものなら、後悔することになります。

ようは水分を取りすぎた状態がいけないのですよね。
ですから、乾杯後にはすぐに日本酒にするようにしています。

好物の GUNESS がたらふく飲めないのが悲しい。。。

まあ、今のところ高めですが・・・なんとか許容値なので、頑張ってお目めを大切にしたいと思っています。

･････そう言えば、最近考えられない事が起こりました。

メンテでお客様のマスタのDNSサーバーを落としたのですが、外部に委託しているセカンダリDNSサーバーも落ちてしまい、しばらく名前解決が不通になってしまったという事が起きました。

けっこう有名なインフラ業者なのにどうしたと言うのでしょう。

DNS が落ちるなんて、そうそうあり得ることではありませんので、すっかり油断していました。反省しかりです。

理由が不明なのですが、まさか「マスタが落ちたのでセカンダリも落としました」とか、「マスタから XFER できなくなったので自動的に落ちました」なんて言い訳をするのではないかと不安です。

何のためのセカンダリだよ・・・・。

最近、様々な業者やエンジニアと一緒に仕事をする機会もありますが、何か基本的なことが抜けているような気がして仕方ありません。

基本を忘れずにいたいものですね。

私は基本をすっとばすのが得意技ですが・・・。

何気にお客様が運用しています。

いや、性能は悪くないんです。

でも、愚痴らせてください。

Java を使っているようで、ヒープサイズとかプロセス数とかの設定があり、何かと Windows 版ではトラブルが多くて困っています。

一度 Java 系トラブルがあると、再インストールしないと正常に動かないケースが多く、何度もインストールしています。

まあ、インストールはあっという間ですが、その後の設定がとにかく大変で、忍耐が必要です。

まず、設定画面が Web のフレームを使っているのですが、大きさ固定であるため、とにかく狭くて使いづらい。
例外URLの設定なんて、いやがらせかと思うほど使いづらい。

構成のバックアップがあるのに、再インストールしたら使えない。(何のための構成バックアップなんだろう)

複数台を NTLM のシングルサインオンで使用する場合は、アレイ構成ができないので、全台に同じ設定をしなければならない。

このNTLMなんですが、機能要件には書いていないんですよね。
ところが管理者ガイドには書いてあるのですよ。
なんて書いてあるかと言いますと・・・P124に一言。
しかも見出しとして。

NTLM 認証 (スタンドアロン版のみ)

本当にできないのか試しにやってみたい気もしますが、もし出来なかったときにまた何台も構成設定をするかと思うと･･･。
嫌ではないですよ･･･。
でも、ものすごーーーーく、モチベーションが下がります。

せめて再インストールしても構成バックアップの復元ができるようにしてもらわないとものすごーーーく 不便 です。

あーすきっりした。

自分メモのようなものです。

Windows Server には Hyper-V というものがあり、NICを仮想化して動作させています。

Hyper-V はレガシィNICも利用できますが、多くの方は仮想化NICにてゲストOSをインストールしているかと思います。

Windows 2000 から、NICに通信の一部をまかせ、CPU の負担をかけず通信をする機能 TaskOffload という機能が実装されています。

この機能を「ハードウエアオフロード」と呼び、機能的には「TCP/IP と IPSec のハードウエア・アクセラレータ」と呼んでいます。

ですが、時にこれが正常な通信の邪魔をする事があります。

たとえば Windows Update で通信ができないとか、Windows のライセンス認証とか、エラーコードが 0x80072EE2 と出る場合があります。

私の勝手な想像ですが、この現象は Windows Server 2008 R2 で発生することが多く、原因は TCP Chimney Offload にあるのではないかと思います。

TCP Chimney Offload は TaskOffload の完全版で、従来の機能に加え、TCP ACK番号など新たな機能を NIC で行うようになっています。

この機能は Windows 2008 R2 からデフォルトで「自動」になっており、マルチコアCPU で Hyper-V の仮想化 NIC を利用する場合に邪魔になっているような気がします。

この機能を無効にするには、コマンドプロンプトから、
netsh int ip set chimney disabled

と打ち込めばよいのですが、上記エラーがこれによって解決できるかは確認しておりません。

実装されている NIC がそれらをサポートしているかどうかなどのステータス情報は以下のコマンドで確認することができます。

netsh int tcp show chimneystats

とりあえず私は Windows 2000 から実装されているレジストリキーを操作する事により、IPSec のアクセラレータも含めて機能を停止し、問題を解決しています。

以下にその方法を記述します。

TCP/IP と IPSec のハードウェア アクセラレータを無効にする。

レジストリを変更して TCP/IP と IPSec の両方のハードウェア アクセラレータを無効にするには、次の操作を行います。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DisableTaskOffload の DWORD レジストリ設定を "1" に設定します。

IPSec のハードウェア アクセラレータのみを無効にする。

レジストリを変更して TCP/IP のハードウェア アクセラレータのみを無効にするには、次の操作を行います。

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IPSEC\EnableOffload の DWORD レジストリ設定を "0" に設定します。

設定が終了したら「再起動」してください。
また、レジストリ等の修正に関しては「自己責任」で行ってください。

以上です。