ESXi用のパッチがリリースされています。
Updated VMware Hosted products and patches for ESX and ESXi resolve a
critical security vulnerability.
でしたので週末に実施しましたが、
今日のFX、オンライン証券のサイトで計測している各社のオンラインサイトに関するログイン状況の詳細用 バックアップサイトの運用を失敗してしまいました。
今日のFX、オンライン証券ではCactiで計測結果を記録しているのですが、前回のバックアップサイトを運用した後に本番サーバーに追加した内容が反映し切れておらず、
トレイダーズおよび
マネーパートナーズの計測が記録できておりませんでした。
本番サーバーからバックアップサイトのサーバーにデータを記録しているファイルを転送したところまでは良かったのですが、そのファイルの所有者が誤っており2社分のデータについて記録が漏れてしまいました。
バックアップサイトのファイル更新には細心の注意だということと、日頃のバックアップサイトでの運用が常に行えるように検討していきたいと思います。
サーバーにアクセスできないという最悪のメンテナンス方法を選択されています。
詳しくは
今日のトレイダーズ証券の詳細グラフから御覧いただけます。
昔、インターネット上の銀行でも同様のメンテナンス方法を採用している銀行があり、アグリゲーションサービスを提供しているソフトの対応に苦労しました。
そのサーバーでデイトレードできますか?のWordPressを2.7.1にバージョンアップしました。
K2を利用しているせいか、表示レイアウトが影響を受けました。
単純にバージョンアップをした結果ですが、CSSを見直さなければいけない様です。
最近、iMacで作業をしている時間が多いのでとは言い訳できません。
今日のFX、オンライン証券としてサーバーの監視状況を公開しているのですが.....
グラフの説明がIEで表示できないという情けない失敗をしておりました。
それも単純なタグの閉め忘れでした。
手でHTMLを書く時は要注意です。
今日も電話がかかってきても取る事が出来ない状況が発生しました。
電話野呼び出しが終わるまでリセットせずに我慢して画面に何が表示されているかを確認しました。
結果は.....
mopera Uのパスワード入力でした。
困りました。
これからmopera Uの設定を削除して再設定する予定です。
この様な現象で苦しんでいるのは私だけなのでしょうか？
昔利用していた機械で発生した各種の障害に付いてメーカーの方に調査していただく事がいろいろとあったのですが、「世界中でこの様な事象の報告はありません。」と担当に方によく言われた事がありました。
誰もあきらめて(報告すると追跡調査されるので)報告していないだけなのでは無いかと思っていました......
この話題は別の機会にゆっくりと書いてみたいと思います。
こちらのサイトがIEで見えていませんでした。
真っ白になってしまい、途方に暮れましたが、結局はtagの閉め忘れでした。手で書くのは難しいです。
修行します。
ルーターをリセットし後は計測は安定しています。
原因はルーターの問題なのか、インターネットの回線の問題だったのかは不明ですが、障害記録のラベルをつけておきます。
詳しくは
こちらからどうぞ
RTX1200 2008/11/18 09:58:59 99% 18% 32℃
何かが暴れ回っている様です。
Time Machieのバックアップを疑いましたが、Time Machineのバックアップが終了(エラー)してもCPUの利用率は下がりません。
他に影響が出るとつらいので、ルーターを再起動します。
記録として、こちらも記録しておきます。
不正アクセス検知の情報
日時 攻撃の名称 攻撃元アドレス 攻撃先アドレス
2008/11/20 01:47:24 TCP SYN and FIN 89.114.114.254 aaa.bbb.ccc.ddd
DHCPでIPアドレスがずれてしまうと時刻同期のデーモンであるntpdが悲鳴を上げるそうです。
IPアドレスを固定して再起度しましたが、タイミングが悪かったかもしれません。
とりあえず、片側のインタフェースについてDHCPを外して様子を見る事にします。
再起動を行いました。
linux上で利用しているDHCPクライアントの設定が不足しておりました。
結果としてRTX1200をDHCPサーバーで運用するとIPアドレスが固定できない状況になっておりました。
/etc/sysconfig/network-scripts/ifcfg-eth0/ifcfg-eth0
の中身である
[network-scripts]$ cat ifcfg-eth0
DEVICE=eth0
BOOTPROTO=dhcp
HWADDR=XX:XX:XX:XX:XX:XX
ONBOOT=yes
TYPE=Ethernet
[network-scripts]$
のうちの、HWADDRが実際インタフェースとずれておりました。
この結果、RTX1200は正しく動いており、毎回異なった新しいIPアドレスを割り当ててくれた様です。
言い訳ですが、仮想環境を複写した時に、こちらもあわせて変更しなくてはいけなかったのですが、以前利用していたルータでは同じアドレスを割り当ててくれていました。
今週はルーターの交換による計測停止時間の方が長く、お恥ずかしい限りです。
こちらの方針も早めに決める必要があります。
こんな大事な日に測定が安定していなかったのは非常に残念です。
概要は
こちらに記述されています。
昔の事を思い出します。
告知の履歴が
こちらに列挙されています。
気になるのは
作業漏れなどはないか?
今晩、対応が必要なものはないか?
その次は
昨晩は特別なバッチまたは作業を行ったのか?
バッチが遅かったのか?
バッチが異常終了したのか?
リカバリー処理は適切だったか?
バッチエラーが発覚してから再開時間を告知するまでの間に何を行ったか?
適切に担当者が招集できたか?
対処した担当者は適切だったか?
対処方法での誤りはなかったか?
もっとよい対象方法はなかったか?
DBの領域などの要領管理は出来ていたか?
バッチのスタート時間、処理時間を記録していたか?
事前に兆候はなかったか?
ですが、
とにかく、正確に発生した事象を記録していただき次回は発生しない様にしていただきたいです。
今晩も担当者は眠れない一晩になると思うのですが無理せず がんばってください。
計測に影響が出てしまいました。
文章を書いています。
RTX1200にとりあえず置き換えただけです。
キチンとRTX1200の機能を使いこなしたいです。
設定さえ出来てしまえば、いったん設定さえ出来てしまえば
以前のルーターよりもRTX1200が安定している事を期待します。
文章を書いています。
久々のYamahaのルーターで苦戦しましたが、第一段階は終了しました。
中途半端に元に戻れるように準備した、以前のルーターにも足を引っ張られました。
設定をして切り替えてみましたが、見事に失敗しました。
PPPoEの接続は出来ている様なのですが、久々のYAMAHAのルーターは手強いです。
フィルターをかけすぎたのでしょうか？
グラフもかけてしまいました。
本番運用なら切腹ものです。
きり戻しての運用となりました。
来週は計測できない可能性が大です。
どちらの問題かはわかりませんが、記録しておきます。
特にイベントはなかったと思うのですが.....
