ススメ」が掲載されました。今回は犯人探しのお話です。社のサポートが受けられる標準機能なので気軽に試せるかと思います。熊猫はコーヒーブレークの内容にはノータッチなのですが、今回のコーヒーブレークの内容には突っ込みを入れておこうと思います。問題を解決するのに必要な情報が提供されない理由のひとつに、「サポート技術者が何をもとに調査や解析を行うかがあまり知られていない」ことにあるという点は同意します。問題が起きたときに、「どんな問題が起きているのか判らない」「どこに必要な情報が保存されているのか判らない」「どうすれば必要な情報を取得できるのか判らない」「トラブルの発生後に情報取得のツールやコマンドを提示されても、すぐに使いこなせるとは限らない」など、「製品別に調査に必要な情報の一覧を作っておくだけでは対処できない」部分も多いと思うのです。OSSであってもシステムの安定稼働とセキュリティが年々重要視されてきている中で、お客様がトラブルに遭遇したときに自力で情報収集や一次切り分けができるスキルをどうやって共有/継承していくのかという「教育」の問題でもあり、問題解決のお手伝いをする組織としてどう対処していくのかを考え続けなければいけない課題でもあると思うのです。熊猫が安心して年次有給休暇を取得できるようになるためにも、ね。ススメ」が掲載されました。今回は誰かの行動を一つ残らず追いかけるという話です。知世ちゃんのことを思い出したので、「歓びのキャロル」を聞きながらこちらの補足記事を書いています。普通に使われていると思うので、特別な内容は無いです。ログを頼りに問題事象の解析を行う調査担当者の立場としては、「事象の再現手順を確立する」「事象の発生時刻が判るようにする」という基本事項の繰り返しです。今年もいろいろなバグや脆弱性に振り回され続けてきました。(18年前!)から存在している(と考えられる)脆弱性」により引き起こされる様々な問題事象に関して、脆弱性の修正方法を議論して修正内容がバックポートされるまでの間ずっと無防備になることを避けるために、いくつかの問題事象を先に修正してもらえるよう試行錯誤していました。してしまう事象に関して、脆弱性を使わずに事象を再現させるプログラムを作成して投稿したところ、関係者からのコメントを頂くことができ、衝撃の事実が明らかになりました。乗り換えを真剣に検討し始めるだろう」という冗談が飛び出すような、とんでもない相違が存在していたのです。これじゃあ、システムがロックアップしてしまうのも不思議ではないですねぇ。やって修正するのか、これから延々と議論が続くことになりそうです。セカンドシーズン、素敵なアニメでした。第10回「ソースコード閲覧ノススメ」が掲載されました。今回はディストリビューションに同梱されているプログラムのソースコードの確認手順の話です。ユーザ向けの手順にしてあります。何か問題が発生した時に、ちょっとソースコードを確認すれば、どこで問題が起きているのか/起こりそうかが判明することが少なからずあります。解析ツールを使用することで原因を突き止めやすくなります。商用のウイルス対策ソフトや死活監視プログラムのように、ディストリビューションに同梱されていないプログラムを使用している環境では、普段遭遇しないようなエラーコードが返却されたり、フリーズしたり再起動したりするトラブル事例が多いと感じています。残念ながらソースコードを確認できないため、原因不明のまま諦めざるを得ません。各種ウイルス対策ソフトが使っている(リアルタイム検索のための)カーネルモジュール部分のソースコードを閲覧できるようになっていれば、だいぶ状況は良くなりそうなのになぁ・・・。第9回「アップデートノススメ」が掲載されました。おけるソフトウェアの管理の話です。ススメ」となる予定でした。今年も大型脆弱性が続々と発見されているのに、相変わらず「アップデートしないで済む根拠」を確認するための問合せが目立っており、どうも「アップデートすることを必要以上に恐れすぎているのではないか」と思えるのです。「リグレッションに遭遇して動かなくなるのが怖い」のか「個々のプログラムや設定がどこでどのように影響しあっているかを知らないから怖い」のかは判りません。前者なら変更履歴とソースコードとの照合を行うとか、後者なら自分が管理しているシステムについて理解しようと努力するとか、塩漬けにする以外に何かできることはあると思います。オープンソースを使ったシステムがブラックボックスのままだなんて、モッタイナイ。第8回「カーネルパラメーターチューニングノススメ」が掲載されました。今回はカーネルパラメータチューニングです。予期せぬ再起動や系切り替えが発生する前に何とかして手がかりを得ようと試行錯誤を続けた結果として「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」という資料ができました。役に立つかもしれないということに気が付きました。あろうと、システムを再起動するための関数呼び出しが発生したらカーネルパニックを発生させます。取得して解析することができる筈ですから。仕掛けられないケースもあります。熊猫自身は問題事象の発生する環境を持ち合わせていないため、どれくらい効果があるのかは不明です。ススメ」が掲載されました。システム構成の把握/ログの確認/リソース使用状況の確認のために取得していただいている訳ですが、いろいろと落とし穴があります。勝手にカーネルモジュールをロードしてしまうとか、大量のCPU時間を消費したりとかディスクI/Oを発生させたりとかの話は本文を参照していただくとして、ここでは調査担当者としての苦労話を書こうかと思います。なく商用の運用監視ツールを使っているために、計算式がどうなっているのかとかグラフをどう見ればよいのかとかが不明というケースがあります。センタから当該製品のサポート窓口に照会する術を持ち合わせていないため、ログやリソース使用状況の確認ができませんので、お客様のほうから当該製品のサポート窓口に照会していただくことになります。そうそう、計算式といえば、回収可能なメモリを加味した空きメモリの計算方法というのは長年の課題なんですよね。書き込むことで表示されるようになります。この項目があると、空きメモリの監視が格段に楽になるのではないかと思います。取得していただいたのに、リソース使用状況を確認できないというケースもあります。使用有無やログの保存場所がどこに設定されているのかは不明な訳です。お客様のサーバにログインして構成を調査をすることはできませんので、お客様のサーバ向けにカスタマイズしたログの取得手順を提示することもできない訳です。含まれていない必要なログファイルを一緒に取得していただけると有難いなぁと思っている訳です。ススメ」が掲載されました。ここでは、「再現手順を確立することの重要さ」の例として、熊猫が先月対応していた不具合事例について紹介したいと思います。この不具合は以下のような経緯により原因が特定され、修正されました。カーネルにバックポートされるのを待っている状態です。社に照会を行い、上記の不具合情報の存在について把握した。センタにも照会を行い、再現手順を確立できないと先に進めないことを理解した。使用していると発生頻度が高くなることを突き止め、問題事象を再現できる手順を確立した。用いた調査を提案した。用いた情報取得を行い、カーネルパニックに至るシグナルを受信するよりも前に矛盾点が発生していることを突きとめることができた。含まれるスレッドセーフでは無い処理が問題事象の発生原因であることを突きとめることができた。情報から追うことができないケースという特殊さが組み合わさって、不明瞭なカーネルパニックを引き起こしてきたようです。センタでも問題事象を再現させることができず、お客様自身が問題事象の再現手順を確立する以外に先に進めないという状況にありました。関係各位の連携プレーにより、見事解決することができました。問題解決までの流れを知っておくと、サポートを利用する側としてどのようなことができるかを考えることができるようになります。スムーズな問題解決のために、ご協力をお願いいたします。宛に投げても反応が無いので、ここで説明することにします。中の人から反応がありました。スパムキューの中に埋もれていて気付いていなかったそうです。追加するように記述が修正されました。サービスに適用する手順が紹介されています。環境変数を設定しても、効果はありません。効果が無いことを確認する手順を以下に説明します。C言語で作成されたCGIプログラムを使って確かめてみましょう。----------このCGIを叩いてみましょう。いう行は表示されないことが確認できます。プロセスから起動されるCGIプログラムには継承されていないことを意味しています。呼び出す可能性のあるCGIプログラムを保護することはできません。作成できてしまう訳です。環境変数による回避策を使おうとするのは危険です。)の影響範囲の調査方法について」が掲載されました。脆弱性とか御嶽山噴火とかで騒ぎ出しました。社のサポート対象外な機能であるため、商用サポートを必要とするお客様に紹介することができず、焦りと残念さが募っています。連載をしているところですので、思い切って緊急コラムとして掲載しちゃいました。(即日で作成したので詳細までは準備できませんでした。質問などがありましたら遠慮なくどうぞ。)熊猫がセキュリティキャンプに参加するようになってから今年で4回目になる訳ですが、年々技術的なトピックから離れてきているのを感じています。それは、OSレベルのアクセス制御に興味を持ってくれる人が少ないからという理由もあります。「プログラムのアイデア出しから保守まで全部を自分で行う」側から「他人が作成したプログラムの不具合調査を行う」側になったことで、「誰かが面倒を見てくれている筈だから、自分は考えなくてよい」という「隅々から全体までを通して見ようとしない」姿勢こそが問題の根底にあるのではないかと思うようになったからという理由もあります。「自分に関係しないことは気にしない」では済まされない。システムのトラブル/セキュリティの脅威は、助け合いなしでは対処できない。すぎたため、公開したら怒られそうな内容になってしまいましたが、まさに今回の脆弱性のような「事件」への対応姿勢がそれを問うているように思えます。ススメ」が掲載されました。以下のような利点があります。以下のような利点があります。取得するというのが好ましいと考えます。両方の利点を得ることができます。ススメ」が掲載されました。出力メッセージを受信させたり、ローカルディスクへの書き込みが遅延する恐れがある場合に数秒間隔で取得している性能データを他のホスト上に保存させたりするという使い方もできます。「ローカルディスクへの書き込みが遅れるなんてことあるんかいな?」と思われるかもしれませんが、実際に遅延した事例があります。記録が大幅に遅延して、死活監視のタイムアウトエラーが発生してしまいました。設定を変更して対処しました。「ヤマノススメ」は風景描写が丁寧ですねぇ。「ARIA」を思い出します。いえば、アニメで口笛シーンが登場するのは珍しいことかも。ススメ」が掲載されました。活躍してくれることを期待しています。難しいのは、送信側よりも受信側なのかもしれません。あるようにそのままでは使い物にならない。使えばとりあえず受信はできるものの、送信元やタイムスタンプの情報も一緒に記録してくれないと不便。同時に指定すると、必要以上にログファイルを肥大化させてしまうし、余分な送信元やタイムスタンプを除去してからでないと読めないというのも面倒。インスタンスを起動した方が良いと思います。送信されたカーネルメッセージに含まれている文字列をホスト名だと勘違いして手当たり次第DNS問合せをしてしまいますのでご注意を。セカンドシーズン」という現在放送中のアニメに倣っています。「夏色プレゼント」というのは、そのアニメのオープニング曲です。前回の記事で「侵略!イカ娘」じゃないよと熊猫が書いたことに対して正解を示唆してくれているものと思われます。今年もセキュリティキャンプ2014が開催された訳ですが、2014年度の第1Qには「ふんわり」系のアニメがたくさん放送されていたのを反映してか、いろいろなアニメネタが登場しました。「ごちうさ」の「ぴょんぴょん」とか(由来は知らないけれど)「ておくれポイント」とかが健闘しましたが、最も猛威を振るったのは「進捗どうですか?」かと思われます。流行はしなかったけれども大爆笑したのは、「一週間フレンズ。」を捩った「進捗フレンズ。2014年度の第2Qは、あまり「ふんわり」系のアニメが見当たらず、ちょっと寂しいです。そんな中、「ヤマノススメ」はゆるふわキャラクターによる山登りの話だと思っていたのに、なぜか温泉の話、スカートの話、水着の話と山じゃない話が続いていてドキドキ。(笑)いや、ゆるふわでも真面目なアニメなので問題描写は登場しない筈。第2話「シリアルコンソールノススメ」が掲載されました。設定済みのサーバは増えてきたようですが、シリアルコンソールを設定したサーバはまだ多くはないようです。同一のサーバで複数回の予期せぬリブートを経験して初めてシリアルコンソールの設定を検討するようになるという状況ですので、予期せぬリブートの原因についての問合せでは初回の事象発生時に何も手掛かりを見つけられず、残念な思いをすることが多いです。再発するまでに何ヶ月も待たされることが多く、調査する側としては何だか落ち着かない状況が続きます。この記事が、初回発生時に手掛かりを見つけるのに役に立てばいいなぁ。現在放送中の某アニメに倣って「○○ノススメ」を予定しています。いう部分を読んで何のアニメなのかを検索したらしく、「侵略!イカ娘」ですかと訊かれてしまいました。え〜?そっちは知らないにゃ〜。安らかな夜を迎えるために」を始めました。安らかな夜を迎えるために」を開始しました。本業にいつ余裕ができるかを全く予測できないという性質上、原稿を書く時間を定期的に割けることを約束できないため、不定期連載という形になります。各話のタイトルは、現在放送中の某アニメに倣って「○○ノススメ」を予定しています。「セキュリティ・キャンプ全国大会2014」参加者募集が始まりました。撮影されないようにカメラから逃げ回っている熊猫が、何故かクラス紹介の動画で喋るはめになってしまいました。(汗)昨年度は「セキュリティの見える化を考えるゼミ」という名前で募集し、「利用者を置いてけぼりにしないセキュリティを考えてみよう」というテーマには8名もの応募がありました。セキュリティについて利用者が置いてけぼりにされているというモヤモヤ感を持った人が予想以上に多く存在していると感じました。セキュリティという得体のしれないものを相手にするのは学生には難しいとも感じました。そのため、今年はOSのセキュリティを考える前段階である「OSの見える化を考えるゼミ」という名前で募集します。発表で使用する「エンタープライズ向けサーバのトラブル対応のための情報取得方法について」を紹介しておきます。メッセージ受信用プログラムを作りました。確認しても原因が判らないものです。技術的にはカーネルメッセージをシリアルコンソールに出力することができるのですが、運用としてシリアルコンソールを導入することが困難なサーバが多く、もどかしい思いをしていました。コメントおよびディストリビューション向けパッケージのメンテナになっていただける方を募集しています。絡みの不具合が話題になりました。days?https://access.redhat.com/site/solutions/68466しかし、上記の不具合を修正したカーネルには落とし穴があったようです。書き換えにより連続稼働をエミュレートするという方法で再現試験を行った限りでは、この不具合の再現率は100%のように見受けられます。業務用サーバとして広く使われていると思いますので、油断していると襲われますよ〜。変化の兆しが出てきました。利用者を悩ませてきたLSMですが、変化の時が近づきつつあるようです。ワールド満開(嘘)なプレゼン資料も貼っておきます。アクセス制御に興味のある方に読んでほしいなぁ。ネットワークインストーラは、環境によっては「次へ」ボタンが表示されないことがあるようです。インストールしようとした時の画面です。キーを使ってフォーカスを移動してください。インストールしようとした時の画面です。版を使う方が正解かと思います。定数の値が変更されています。以降では期待通りに動かなくなります。バックポートされています。この修正は他のいくつかのディストリビューションにもバックポートされることが予想されます。定数を使用するように修正されているかどうか確認するようにしてください。ハードコードされた整数を指定していたため、バグ報告が出ています。