新潟のマリンピア日本海にきてます。 尋常じゃない暑さ！ 今日は海水浴の方が良かったかも。（汗）]]>
なんか勝手にウチの記事の単語を拾って、単語にリンクをはって、よくわからん検索エンジンにすっ飛ばすようになってました。
何かアナウンスがあったのかもしれないけど、気持ち悪いので使うのやめます。 閉鎖する直前ではあるのだけど、見てる人に変な被害が及んでも嫌なので。
まずは予告まで。
さて、最近車を買い換えまして、同時にナビも新しくなりました。 PanasonicのCN-HW890D。 やっぱりこう言うイベントがあると多少忙しくても書く気になりますね。（笑）
Strada CN-HW890D
http://panasonic.jp/car/navi/products/HX910/HW890/index.html
前の車でもパナナビだったのですが、購入先の車屋さんがナビの話をしたらデフォルトがパナだというので、そのままOKしちゃいました。 慣れてますしね。
下位モデルでも良かったのですが、折角なのでBluetooth付きにしてN82と接続させたいと思い、この機種を選びました。 車に乗り込んだらすぐにハンズフリーってやってみたかった訳で。（笑）
で、納車されてすぐ試してみたのですが、困ったトラブルが発生...
しかし自動接続しない...
厳密に言うと、自動的に接続して、その直後切断されてしまいます。 自動接続は諦めて手動で接続を試みても同じ。
一旦携帯の登録情報を削除して、再度ペアリングするとちゃんと繋がる。 って事は、使うたびに毎回ペアリング...なんてやってられませんって。
ネットで調べてみると同じ現象にでくわしている人がいました。
ハンズフリー通話 Bluetooth接続について
http://strada.mci-fan.jp/com/oshiete/viewArticle.do?roomtype=10&roomid=20&root=15401&articleid=15401
全く同じ。(^^;) 携帯は違いますが、現象はまるっきり同じです。
このページ見つけたあたりから諦めモード気味っぽくなってきたわけですが、それでもそれ以外のところでBluetooth使うつもりはなかったので、気が向くたびに無駄な抵抗をしてました。 しかし一向に解決する気配なし。
ところが今日、ふと思い立ち、「Bluetoothオーディオの自動接続をしてやればハンズフリーフォンも勘違いしてつながるかも」なんて何の根拠もない、解決できない時の末期症状なアイデアを試してみたところ、なんと...自動で繋がっちゃいました...
このまま毎回安定して自動接続されるか分からないのですが、しばらく様子見してみたいと思います。
しかし体力的に結構厳しいなぁ… 明日はゆっくりさせていただきたいところです。(^_^;)
しかしいい天気。暑いくらいだな。
]]>プログラムの中でこのテーブルに対してinsertとupdateを連続的に行う処理をさせているので、一見全くスコアがつかないように錯覚してたんですが、実はupdate後に現象が出ることに気づきました。 ものすっごく時間がかかった。
更に色々調べてみると、どうやらintegerのカラムをupdateすると現象が出るっぽい。 しかし、updateの際、他のvarcharとかtextとかtimestampとかのカラムに、「元の値とは異なるデータ」をセットして、一緒にupdateするとスコアは戻る。
結構困ってます。 ダミーとして何かセットするかしないと解決しなそう。 これってバグなんだろうか。
ここに書くのもどうかと思うが、ludia開発停滞してるっぽいし、しかしかなり作りこんでしまったので他に乗り換える事は難しいし、なにより納期がかなり迫ってるし。
むー。
ようやく問題が絞り込まれてきました。 integerだけじゃなく他の型をupdateしても現象が再現するケースもあるようです。 嘘書いてました。（汗）
現時点でわかってきたこと。
対象のテーブルには時刻型、厳密に言うとtimestamp(0)のカラムがあって、updateの際にここの値を「元の値とは違うものに置き換え」ればスコアが戻ってくるようです。 複数timestamp型カラムがある場合はそのいずれかを置き換えればよさそう。
なぜ時刻型カラムの更新がLudia配列型インデックスのスコアに影響するのかはわかりませんが、とりあえず突破口は見えてきました。 気持ち悪いけど、この性質を利用してこの問題を切り抜けようと思います。
NAVの時代から特定クライアントの更新が止まる現象というのは時折起きていたので、あぁSEPも同じか...なんて思いつつSEPMのコンソールを見てみたら、なんと全てのクライアントの更新が滞っているではないですか。
SEPM側の問題と直感的に思ったのですが、日付が12月31日というきっかり去年の末という点に直感でシステム上の問題ではないかと疑いを持ち、Symantecのサイトを漁ってみたら、ほらね、やっぱりありました。
SEP クライアントと SEPM のウイルス定義ファイルの日付が最新版に更新後も 2009/12/31 のままとなっている
http://service1.symantec.com/support/inter/entsecurityjapanesekb.nsf/jp_docid/20100105094746949?OpenDocument&dtype=corp
2009/12/31 11:59 PM より新しい日付のコンテンツが、古い定義ファイルと認識されてしまう問題が SEPM で確認されています。
（中略）
問題回避のため、シマンテックセキュリティレスポンスは SEP のセキュリティコンテンツの日付を変更せず、コンテンツのリビジョン番号のみ増やしています。シマンテックセキュリティレスポンスは、恒久対策が行われるまで、この方法を回避策として提供します。
とりあえずリビジョン番号はあげてるから問題はないという見解っぽいけど、日付が変わらないって結構問題じゃありません？ 最新版かどうかはサイト上で確認する以外ないだろうし、直感的な確認ができませんよね。
あとエンドユーザーからの問い合わせが増えるのも管理側としては面倒な話。 「定義ファイルの日付が古いままなんですけど...」「あ～それはですね...」てな会話が当面続く訳で。 彼らには日付が古くなっていたら連絡して下さいという話を常日頃しているのでそれが裏目にでちゃいます。
早く直して下さい。
雰囲気的にネットワーク周りの問題だとは思っていたけど、元々カプセル化されたものをそのまま移設しているわけだし、変わっているとしたらNICのMACくらい。 だからOpenVPNってMACに依存するの？とか悩み出してこれが深みへの入り口となりました。(^^;)
結局下のサイトさんを見つけて解決。
きのさいと - VMware/ESXi/TIPS集
http://www.masatom.in/pukiwiki/VMware/ESXi/TIPS%BD%B8/
ここにある通り、ネットワーキングのプロパティのセキュリティタブでプロミスキャスモードを許可することで解決しました。
ちなみに私の場合VMware Serverのゲストで問題なく動いていました。 その時は何もはまらず素直に動いていたのですが、ESXiにはセキュリティ設定があったんですね。 目から鱗でした。
ありがとうございました。 助かりました。m(._.)m
ESXi4だと最低2G積んでないとハイパーバイザのインストールすら拒否される。 仕方ないのでESXi3を入れることにしたんですが、インストール後起動しようとすると特定の場所で固まる問題が発生。 画面には、
Loading module ipmi_si_drv ...
と表示されている。 コンソールでAlt+F12押して起動ログを見ると、なんとなく微妙に動いているような動いていないような感じ。
ぐぐってみたら全く同じ現象に出くわしている人は多いみたい。 上の状態で１時間くらい待てばとりあえず起動はするという事だったので待ってみると、確かに１時間１０分位で起動した。 ログ見るといくつかのIPMIモジュールをロードする際に異常があるのかタイムアウトする（にしちゃ長過ぎるけど）みたいな感じ。
見た通りIPMI関係っぽいので必要ないっちゃ必要ない。 でも起動に毎回こんなに時間かかってるのではたまらない。 なのでこれを無効化してしまおうと。
適当にESXi内のファイルをあさってみたところ、/sbin/configにipmi関係のモジュールをロードする箇所を発見。 ここを編集していけばいいはず。 ちなみにESXi4の場合は/etc/vmware/init/init.d/72.ipmiみたい。
ただ単純に編集しただけだと、ホストを再起動したときに設定が初期化されてしまうので、編集したファイルをoem.tgzに放り込む必要がある。 で、以下が今回行った作業内容。
まず/sbin/configを直接じゃなく、テンポラリにコピーして編集する。 後でtarで固める時に実際の構造と同じに展開されるようにmkdirしてその中にコピーすること。
mkdir -p /tmp/oem/sbin
cd /tmp/oem/sbin
cp /sbin/config .
vi config
このファイルの中に
loadIPMI=`vsish -e get /hardware/ipmiSupport | sed 's/IPMI state: \([^ ]*\).*/\1/'`
というのがあって、これ以降数行がIPMIモジュールのロードをしている。 なので、上の行をコメントアウトして次の行でloadIPMIに0を代入する。
# loadIPMI=`vsish -e get /hardware/ipmiSupport | sed 's/IPMI state: \([^ ]*\).*/\1/'`
loadIPMI=0
これでファイルを保存したらtarして出来たファイルを/bootbankにコピーする。
cd /tmp/oem
tar cvzf oem.tgz sbin
chmod 755 oem.tgz
cp oem.tgz /bootbank/
これで起動時に/sbin/configが上書きされて、IPMIモジュールがロードされないようになる。
ESXi4でも同じ方法でいけるとおもう。 この場合72.ipmiの中をコメントアウトすればいいんではないかと。
で、これを期にという訳でもないのですが、ネットワーク環境を見直すことにしました。 回線及びプロバイダを変更します。
停止は１２月１２日の午後１時あたりから。 回復は未定ですが、恐らく半日～１日位で終わるのではないかと思います。
相変わらずバイク凄いっすね。排気ガスも物凄い。
警察が交通整理してるけど、かえってそれが渋滞の元になってる気がする。(^_^;)
]]>
って、だからなんだよみたいな。（汗）これまた全然ベトナムじゃないし。まぁたまにお買い物する店だと言うことで、思い出の１ページとさせて下さい。(^_^;)
]]>
一昨日現地人である知り合いの皆さんの協力の下、どうにかこのN82、動いてくれました。アドレスブック消失というアクシデントはありましたが…(^_^;)まぁ想定の範囲内。でもおかげで通話もネットも何不自由なくできるようになりました。有り難い事です。
只今食事にきたところです。ホーチミン1区レタントン通り、ランカスターの斜め前に構えるHCM胡蝶です。室内なのでGPSが効かず地図が出ないであろう事が残念。
一人で静かに食事したいようなお疲れモードの時は大抵ここ。店員も静かでゆっくり食事できます。
あー疲れた。さっさと食べてホテルで寝よう。
]]>