qpstudyに参加してエンシェントな焼酎をふるまってきました
初心者にもやさしい(頃もあった)勉強会、qpstudyに初参加してきました。
www.zusaar.com
今回のテーマは監視＆運用＋自動化。
本編
最初は @koemu さんによる「ITインフラ監視の今後を考える」。
惰性的に行われてきた面もある監視を根本から見直してみようという意欲的な問題提起でした。
経営や事業評価の視点も交えて誰にどういう価値を提供するか、という観点もあり非常に刺激的でした。
speakerdeck.com
後半挙げられた３つの課題が印象的だったので整理。
- 1.PaaSをどう監視するか
監視させてくれない/見えない部分が多い、検知しても対応は事業者任せでできることが無い
監視も事業者提供ツール頼み？ cf. http://www.stackdriver.com/
SaaSはコストが明瞭、その分高く見える場合も
DIYの場合の構築コスト/運用コスト/提供価値のトータルで比較してみる必要がある
- 3.監視の細かさ
対応の必要なものを確実に通知
通知内容の優先度
- 障害でなければ通知は要らない？
- HDD容量など予防的通知は？
- 冗長したWEbのうち1台落ちたときは？
- ステークホルダーと合意は取れているか？
続いて前佛さんの「Re:運用に自動化を求めるのは間違っているだろうか？」
当初予定の時間枠では半分強しか話せずw懇親会で延長戦も行われました。
冒頭のスライドの通り、ポイントは３＋１つ。
- 運用における自動化範囲の整理・分類
- 自動化で運用はこんなにも楽しくなる
- トラブルシューティング自動化は未解決課題
- 本来あるべき状態から逆算して運用業務を楽しくしよう
運用における自動化範囲の整理・分類
ツールや手法で改善可能になった部分もある
-設計＆構築 <- 構成管理ツール、Dockerfileからの起動
-監視設定 <- オートディスカバリー、テンプレートエージェント
会場からQ. 環境構築の自動化でDockerが構成管理ツールよりも優れている点は？
前佛さんA. ツールは一長一短あるのでどちらでも
Dockerは間違いなく同じ環境を作ることができます
会場からQ. システムのライフサイクルを考えて維持管理や変更にDockerは耐えうるか
前佛さんA. Dockerだからどう、という問題点ではないと思います
会場からQ. コンテナ作成のタイミングというか依存ライブラリのバージョンが変わってしまう場合の対策は？
前佛さんA. 現で点ではローカルのResistryServerに作成したDockerイメージを置いてください
トラブルシューティング自動化
使えそうなツールはいくつか出てきた
-時系列メトリクスを何台分も並べて見ることができるもの(Elasticとか)
-クラスタ制御ツール(serf, consulとか)
よくある「サーバー重いんだけどちょっと見て」という状況に、コンテナ化されるインフラでどう対応するか。
-ツールによって"当たりをつける"ことの支援は可能
-問題の特定や支援はまだちょっと先？
他の業界で確立している手法に学んでみようシリーズ
-大事故,大規模災害時のトリアージ -> 障害の深刻度や対応復旧の優先度
-管制とレーダー -> オートディスカバリーでのクラスタ状態(の変化)の把握と各インベントリ,メトリクスの取得
(この辺で時間切れ)
グループディスカッション
それぞれ自分の業種の立場から、監視業務の価値を見直してより良い今後を考えよう、という内容で
3-4名 -> 各テーブル(8名程度) -> 全体 の三段階でのブレスト形式
自分のグループではクラウド化なんてできていないオンプレなメンバーが結構いたので
レガシーなところにも付与可能な価値、ということで一覧性の話をしたり、
DIY(オンプレ)な監視基盤の監視のためにSaaS系を用いる話、
cronやサービスウインドウを調整して日中など障害が起きるとしても対応しやすい時間に起こるようにする話、をしました。
なおテーブル班での議論を発表する際、「レガシー」という単語をど忘れして
「エンシェントなシステム」と言ってしまったのがちょっとハネたので結果オーライです。
他のチームでは経営層に響くレポートの話や、内製で引き継ぎが無いとかそもそも独りとかのツラい話が今なお心を掴んでいたりととても多様な意見とそれでも共通したある種の危機感があって面白かったです。
懇親会＆LT
自動化というトピックでちょうど良いかな、と思ってStackStormの紹介をLTしました。
単発作業の自動化/マクロ化はできていることが多いと思いますが、ノード間やクラスタ間をまたいだ自動化は急にハードルが高くなりがちなので役に立つかもしれません。
iftttとかplagerを想起させるツールなので、前佛さん資料の"ピタゴラ装置的な仕組み"を作る基盤になれるものだと思います。
StackStorm.pdf - Zoho Docs
以前、SoftwareDesign誌で"運用現場で役立ち開発力"という特集があったり昨今DevOpsというキーワードがあったりしますが、個人的にはインフラエンジニアが作るシェルスクリプトの品質という問題意識があります。会社の中でも開発部門にはコーディング規約があったりしてもインフラ運用部門は触れたこともないし出荷検品のプロセスも無いような状況というのがあるんじゃないかと思います。
ChefだとかこのStackStormのようなツールを利用することで、エラー処理や正規表現など書式のハンドリングといった部分を個別に書かずに済むフレームワーク的なメリットも得られ、テストやレビューも行いやすくなる点もあると思うので、何かしらツールを使ってみるという現状改善のアプローチもあると思います。
Software Design 2009年4月号｜技術評論社
Enterprise版のお値段の質問がありましたが、やはり非公開になっていました。月額$500以下ぐらいで12ヶ月契約と書かれています。
Pricing - StackStorm
ただし現時点ではほとんどの機能がGitHubから落とせるOSS版で利用できます。Enterprise版のみの機能は、デモでお見せしたWorkflowのGUIエディタとLDAP連携、ロールベースアクセス制御の部分のみです。
stackstorm.com
監視におけるフルリゾルバのキャッシュ by ttkzwさん
DNSやドメイン情報に起因する障害が発生している場合に監視基盤がリゾルバのキャッシュを使っていて検知できない、というようなケースをどう回避するかという課題設定。
理想的にはキャッシュDNS上のTTLをすべて監視間隔に合わせて、都度新しい情報で監視することを示され、例としてunboundでのcache-max-ttl設定をご紹介されました。(bindは省略というか足切りされましたが、max-cache-ttl/max-ncache-ttlで設定が可能です)
この問題ってFWのポリシーを名前ベースで設定する時にもからんできたりしますね。あと監視基盤がWindowsだとスタブリゾルバでもキャッシュしそうな気がします。
クラウドポリシーチェックリスト --間違えてました-> Wall-Architected フレームワーク by yktkoさん
冒頭に好きなAWSサービスはaws-cliとの言があって、そこ？と思いましたw
興味深かったので終わったあとに「Trusted Advisorと統合されないんですか？」と訊いてみましたが、汎用的にできていて「バックアップちゃんと採っていますか」といった項目もあるのでチェックリストにはなるけどすべてが機械診断に反映できるものではない旨言われ、納得でした。
こういうのはベストプラクティス的にそれぞれで経験されたものが集約されていって欲しいですね。
AWS Certificate Manager by mnakajima18さん
いろいろ理想値にすれば導入も更新も30分＋アルファ＋アルファ＋アルファくらいでできた実績のお話。
Tokyoリージョンに無いのと、Let's Encryptという競合および既存大手との争いも気になりますね。Let's Encryptは更新のcronジョブの時に80/443がサービスリスタートよりも長い時間、多分1分弱くらい停止する点が気になっています。ACMはどういう動作をするんでしょうか。
MongoDB on EC2 by kuwa_twさん
「ログを入れるなって言ってるだろう」....すみません、StackStormでもMongoDBはログやauditの置き場です....
WiredTigerストレージエンジンなら改善されるか負荷テストしてみた、という結果グラフでしたが負荷がキツすぎて結果が正直すぎて良さが伝わりにくいというか....I/O waitが80%から60%に改善されたってterribly slowがvery slowになったとしか感じないのですが。とは言えwiredTigerへの期待およびMySQLでのFalconのように今後StorageEngineの開発がいろいろ進む先陣になることへの期待があります。
4/26お昼時のBlackBeltがMongoDB on AWSとのことです。
[Black Belt Online Seminar] AWSで使うMongoDB
あと、私が熊本生まれ宮崎育ちということで熊本の焼酎を差し入れしました。
www.fusanotsuyu.jp
35度とちょっと強めでしたが30年古酒にしたこともあって飲みやすいと好評で売り切れて良かったです。お気に召した方は、是非熊本や大分のお酒を入手してみてください。
日本酒ならば阿蘇の一所懸命とかメッセージ感もあっていかがでしょうか。
吟醸焼酎 一所懸命720ml | 商品のご購入はこちらから | 熊本の阿蘇にある酒屋【阿蘇・岡本】のオリジナルのお酒・リキュールやお土産にも喜ばれる地サイダーの通販サイト
感想・考察・補足情報
ただ監視するだけではなく、運用の改善やメタに役立つことを実装することもできるという面でZabbixに高い評価と期待が感じられた一方、導入の障壁(をDockerで緩和)や導入を後押しするメリットが欲しいという話も多く聞かれた気がします。
まずは仮想アプライアンスとかでPC上のVirtualBoxで起動してみるのもいかがでしょうか？
http://www.zabbix.com/jp/download.php#appliance
ただ問題意識も経験的比較対象もなく試しても判断しにくいと思うので、メールソフトやテキストエディタをいくつか試したことがあるならばその感じで試してみても良いと思います。
「最初に触るのがZabbixという若手にメリットを理解してもらいたい」という話に前佛さんが「Zabbix無しで同じものを得る環境を作らせてみては」ということをおっしゃっていたので「BigBrotherでやらせてみては？」と野次ってみました。
BBは極論として、解は一つではないと思うので私の好きなOSS監視ソフトも挙げておきます。どちらも仮想アプライアンスやLiveCDがあります。
PandoraFMS http://pandorafms.org/ja/features/download
ichinga2 https://www.icinga.org/download/
IaaS Casual Talks #1におじゃましました
Casual Talksだけどカシュっと聞こえなくてちょっと緊張。
全員発表形式で、それ自体はためになってとても良かったんですが
時間が大幅超過したのが平日夜はツライかもでした。
(かといって次回を沖縄(Janog流れ)という案もツライのですが)
お話はオフレコ気味なものも多かったのでぼやかしてざっと感想
・ESXiでサービス基盤を構築している事業者さんが結構多い
・おぷすたのコードに手をいれるかどうかの戦い/世界線
・IaaS人材 ~= フルスタックエンジニア ~= いない
私は咳き込みながら発表でもコメントでも
ツールをいろいろ紹介していたので、挙げたツールを以下整理
NW作業の自動化
rancid
このジャンルでは超古参ツール。expectベース
www.shrubbery.net
OpenNetAdmin
メインはIPAM機能ですが、NW機器のconf diffとかも可能。開発停滞？
opennetadmin.com
サーバーのConfig as Code
holo-cm
chefがツラい人向けの機能的にはdeployerに近いツール。
Holo - Minimalistic Configuration Management
holo-buildも併せて使うとシンプル,簡単,気持ちいい
github.com
複数マシン/クラスタをまたぐ運用自動化
StackStorm(略称st2)
この翌日にBrocadeによる買収が発表されましたが..
StackStormについてはどこかで個別にLTしようと思います
Webで言うiftttの運用版、を名乗っています。
stackstorm.com
Badlock関連の情報雑メモ
かねてより予告のあったSMB関連の脆弱性、Badlockの情報が公開されました。
ひとまず見て回った情報を雑メモしておきます。
Badlock Bug
CVSSスコアはBase7.1です。
(追記: CERTはBase 7.9でした http://www.kb.cert.org/vuls/id/813296)
それぞれ、SambaパッケージのアップデートやWindows update、
NASストレージのファームウェア更新など環境に応じた対応を行いましょう。
Samba3.Xとかはそもそもちょっと古い環境への互換性を持つ面もあるので
トレードオフかもしれませんが、平文や弱い認証形式をやめていくべきという
このところTLS周りで起きている事と似ている感じもあります。
Samba周りはネット上の情報も古いままのものが多いので、
ssl.confみたいにsmb.confの模範情報が欲しいですね。
影響のあるSambaバージョン
3.6.x,
4.0.x,
4.1.x,
4.2.0-4.2.9,
4.3.0-4.3.6,
4.4.0
3.6より古いバージョンは未確認とのことです(Earlier versions have not been assessed)。
RHEL5系は3.0.Xで未確認....
RHEL6系は当初3.5だったようですが最新では3.6系や4系なので対象確定となります。
Ubuntuは14.04LTSでも4.1系ですね。
(追記: RHEL5もバックポート提供されました
3.0.33 https://rhn.redhat.com/errata/RHSA-2016-0621.html
3.6.23 https://rhn.redhat.com/errata/RHSA-2016-0613.html
さらに追記同じく3.0.33でRHEL4 延長サポート向けも提供されました
https://rhn.redhat.com/errata/RHSA-2016-0625.html
またGlusterFSもアップデートが出ています)
被る攻撃内容
1. MITM
2. リモートからのDoS
ワークアラウンド
1.のMITM向け対策
以下に相当する設定を適用することが挙げられています。
smb signing = required
ntlm auth = no
副作用は、signingはその分負荷が上がります。
(Windows 2008 R2では最大15%程度負荷上昇との記述があります。
https://technet.microsoft.com/ja-jp/library/cc731957.aspx)
NTLMの無効化はNTLMv1クライアントに影響します、がv1はそもそも今時ダメではないかと
(https://support.microsoft.com/ja-jp/kb/2793313)
2.のDoS向け対策
Firewallなどでアクセスをきちんと制御することが挙げられています。
(追記 適用時の影響)
RedHatのサイトのFAQによればアップデート適用時にサービスリスタートも行われるとのことです。
( I have updated my Samba servers and clients, do I need to restart anything?
->No, when the update is applied on your system, the smb service will be restarted automatically.)
$ rpm -qp --scripts samba4-4.2.10-6.el6_7.x86_64.rpm
postinstall scriptlet (using /bin/sh):
/sbin/chkconfig --add smb
/sbin/chkconfig --add nmb
if [ "$1" -ge "1" ]; then
/sbin/service smb condrestart >/dev/null 2>&1 || :
/sbin/service nmb condrestart >/dev/null 2>&1 || :
fi
exit 0 (preuninstallは略)
補記
今回リリースされたSamba4.4.2,4.3.8,4.2.11はデフォルト値の変更なども含まれるので
一気にバージョンアップする場合はBadlock関連以外の機能でも挙動変化もあり得そうです。
https://www.samba.org/samba/latest_news.html#4.4.2
また、2016/3/22にSamba4.4.0がリリースされたのに伴い
4.1.X系はサポート対象外となりましたので今回もアップデートは提供されません。
SMB signing関係のリンク
(SMB2では必須。SMB1の場合設定やバージョンによります)
Microsoft / 2008 R2
https://technet.microsoft.com/ja-jp/library/cc731957.aspx
NetApp
https://library.netapp.com/ecmdocs/ECMP1401220/html/GUID-0C291FD0-68D3-4DAE-A493-9958EA4C70DC.html
Isilon
https://community.emc.com/thread/178414?start=0&tstart=0
RedHat導入ガイドのSamba部分
(RHEL6)
第18章 ファイルとプリントサーバー
Mageiaのアップデートリリース
Mageia Advisory: MGASA-2016-0151 - Updated samba packages fix security vulnerabilities
(追記 今回の対象CVE)
CVE-2016-2118
CVE-2016-0128 / MS16-047
CVE-2015-5370
CVE-2016-2110
CVE-2016-2111
CVE-2016-2112
CVE-2016-2113
CVE-2016-2114
CVE-2016-2115
ちなみに間に挟まれている
CVE-2016-2116 はJasPer(jpeg)
CVE-2016-2117 はkernel
で別物でした。何か関連事項が隠されている、とかではありませんでした。
ふと思い出した20年前
攻撃のデモで、「ここはどこ、私は誰?」はよくやりますね $ pwd; whoami
— 徳丸 浩 (@ockeghem) 2016年3月3日
私がITというか計算機管理に関わるようになったきっかけは20年前。
当時計算機を苦手としていた私は、大学の講義課題をやる中であるトラブルを起こす。
計算機のことを分かってなさ過ぎた故にありえない操作を行ってしまい、
ローカル権限昇格のバグ？セキュリティホール？を突いてしまったのである。
当時の状況
私「え！課題で作ったファイルが全部消えた～！」
実際には権限昇格したため/roor/に移動していたのである。
真に、引用のpwdやwhoamiという知識があれば活かされたであろうシーンである。
嘆いてたところ、計算機管理を担っていた先輩が見てくれて、状況把握した上で
先輩「君面白いね。計算機管理やってみない？」
と誘いつつ、直してくれた。(今思えばexitしただけかも)
数年後にこの先輩から聞いたのだが、
先輩「今の君なら分かるかもしれないけど、あれローカルの権限昇格してたんだよ。
そんな危ないことする奴、放置してられないから『教えてやるよ』って言って
飼い慣らした方が安心できるだろ」
という事だったらしい。
先輩たちからは様々な知識や技を頂いて、おかげでいまもいっぱしのエンジニアとしてやっていけてる。
だが、そもそも計算機の世界に引き込まれたことが良かったのかどうかは答えに自信が無い。
expectのおさらい
この投稿はNetOpsCoding Advent Calendar 2015 - Qiita19日目分です。
(なお、特に新しい知見は含んでいない10年前の内容であるかもしれません。)
昨日はcodeoutさんの netconf / restconf 時代にもxlogin 使いまくってる話 - LGTM
という素晴らしい記事でした。
xloginを提供するrancidは2.3.1が2004年、2.3.8p4が2013年にリリースされるなど枯れて安定しているものの、3.0が2014年にリリースされるなど今も開発・改善が継続されている素敵ツールです。
expectがカバーできること
ネットワーク機器の作業を自動化/コード化/CI&CD化するにはいくつか段階があります。
expectは最初の段階にあたる、手作業と同じ内容をマクロ的に実行することに特化した、スクリプト言語tclの拡張実装です。
expectの良いところ
サーバーとネットワークの技術者が別れている場合、例えばInfrastracture as Codeなどの潮流にさらされているサーバー技術者と、プログラムは書いたこと無いというネットワーク技術者の間に暗くて深い川が流れている場合もあります。
しかし作業の自動化コード化の恩恵はネットワーク技術者にもあるはずです。
以下にネットワーク技術者がexpectに触れるメリット/甘言を挙げてみます。
- 使い始めるまでの学習コストがきわめて小さい
expectスクリプトの例を見てみましょう。
#!/usr/bin/expect
set timeout 60 spawn telnet rauter.example.com expect "Password:" send "ExpectExample101\n" expect ">"
send "exit\n"
コマンドプロンプトの応答をexpect、入力するコマンドをsendで送る、という大まかな流れなので分かりやすいかと思います。
また、expectは古くからある枯れた実装なので、参考書籍も1994年刊のオライリー本がほぼ唯一なので迷うこともありません。
JavaScriptのような変化の激しい処理系に比べると、多少腰を据えて学習しても陳腐化することは無いというのは作業を楽にしたいだけのエンジニアにとってはメリットになるでしょう。
それでもプログラムやDSLを書くのはイヤだ、という方にはautoexpectというツールがあります。
こちらはLinuxであればexpectパッケージに含まれる便利コマンドで、MS OfficeやTeraterm、RLoginのマクロ記録 - マクロ実行と同じような感覚で、コマンドラインの作業をexpectスクリプトに記録して再実行可能にするものです。
$ autoexpect
～～作業を行う～～
$exit
作業内容をexpectスクリプトにしたscript.expというファイルが生成されます。
もう一度同じ作業を行う場合は、./script.expと生成されたファイルを実行するだけでOKです。簡単ですね！
- ネットワーク機器作業に特化したラッパーrancidの存在
詳細は先述した昨日のcodeoutさんのエントリの通りですが、rancidは主要ベンダー製品への自動ログイン機構を備えており、configのバージョン管理や定期取得、差分検知などの基本的かつ広く共通したニーズが満たされるます。
まだこれらが実現できていないという環境には、とっかかりとして良いのではないでしょうか。
- tclはネットワーク機器ファームでもサポートされていたりする
私もNetworkers 2006のIOSセッションで知ったのですが(もう9年前。NMS-301のセッションで、Kronもこの時に知りました)、例えばCisco社のファームウェアにはtcl/tclshが実装されていて、ルータ上でtclスクリプトを動かすことができます。
ルータの一機能だと思えば抵抗感も少なくなるのではないでしょうか。
一方、expectの注意すべきところ
記録＆再生マクロのように気軽に使える分、極めて狭いスコープを対象とした特定の作業のみを行う、似て非なるスクリプトが量産されてしまう事態に陥りやすいです。
これを避けつつスケールさせていくためには、ある程度スクリプト作成に慣れたところで
共通部分のテンプレート化と変数の抜き出し
直接expectスクリプトを作るのではなく置換などでexpectスクリプトを生成するようなメタスクリプトの作成
といったことを視野に入れる必要があります。
テンプレート化とメタスクリプティング、面倒だなー、誰か作ってないかなー、記述にDSL使えそうだなー、AnsibleとかFabricとか使えそうだなー、あれexpect要らなくね？
....おや、こんなところに大勢の足跡が
明日はバラ色の主日、早いですねえ。
参考リンク：
expect本家サイト http://expect.sourceforge.net/
rancid http://www.shrubbery.net/rancid/
OpenNetAdmin (rancid同様の管理＆自動化機能を持つツール。2013年以降開発停滞気味？) http://opennetadmin.com/
(IOS) http://www.cisco.com/cisco/web/support/JP/docs/CIAN/IOS/IOS15_1M_T/CG/009/nm_script_tcl.html?bid=0900e4b18252971b
(IOS-XE) http://www.cisco.com/cisco/web/support/JP/docs/SEC/IdentityMGMT/SecureAccessCntrlServer4W/IG/002/nm_script_tcl_xe.html?bid=0900e4b1825ae544
