2014年11月25日

第9回「アップデートノススメ」が掲載されました。

今回は RHEL におけるソフトウェアの管理の話です。

この連載のタイトルは「ヤマノススメ」に倣っているので、企画段階では今回は rpm パッケージを管理するための yum コマンドの使い方を紹介する「 yum ノススメ」となる予定でした。

しかし、今年も大型脆弱性が続々と発見されているのに、相変わらず「アップデートしないで済む根拠」を確認するための問合せが目立っており、どうも「アップデートすることを必要以上に恐れすぎているのではないか」と思えるのです。「リグレッションに遭遇して動かなくなるのが怖い」のか「個々のプログラムや設定がどこでどのように影響しあっているかを知らないから怖い」のかは判りません。前者なら変更履歴とソースコードとの照合を行うとか、後者なら自分が管理しているシステムについて理解しようと努力するとか、塩漬けにする以外に何かできることはあると思います。オープンソースを使ったシステムがブラックボックスのままだなんて、モッタイナイ。

posted by 熊猫さくら at 21:15| Comment(0) | TrackBack(0) | Linux

2014年11月11日

第8回「カーネルパラメーターチューニングノススメ」が掲載されました。

今回はカーネルパラメータチューニングです。

予期せぬ再起動や系切り替えが発生する前に何とかして手がかりを得ようと試行錯誤を続けた結果として「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」という資料ができました。そして、その後も試行錯誤を続けた結果、今度は SystemTap が役に立つかもしれないということに気が付きました。

# stap -g -e '
function call_panic() %{ panic("Calling panic() due to machine restart\n"); %}
probe kernel.function("machine_emergency_restart") { call_panic(); }
probe kernel.function("machine_restart") { call_panic(); }' &

SystemTap を用いて行っていることは簡単で、 /sbin/reboot -f であろうと Watchdog のタイムアウトであろうと echo b > /proc/sysrq-trigger であろうと、システムを再起動するための関数呼び出しが発生したらカーネルパニックを発生させます。カーネルパニックを発生させることができれば、 kdump を取得して解析することができる筈ですから。
ただし、残念ながらトリプルフォールトのように SystemTap を仕掛けられないケースもあります。また、熊猫自身は問題事象の発生する環境を持ち合わせていないため、どれくらい効果があるのかは不明です。

posted by 熊猫さくら at 20:48| Comment(0) | TrackBack(0) | Linux