2016-09-22

StackStorm勉強会に参加＆発表してきました

9月13日に行われたStackStorm勉強会に参加＆発表してきました。
感想や補足について書き記しておきます。

今年の春頃はStackStormで検索しても日本語ではバンド名/芸名/アルバムなどの作品名しかヒットせずほとんど情報が無かったので、今回100人以上の方が申し込まれたというのは驚きというか感慨というか数ヶ月での変化の大きさを感じました。

私がStackStorm(以下st2と略す場合もあります)を知ったのは去年の春頃です。
今年の年明けくらいから懇親会やLTの場で何度か紹介していたのがきっかけで今回発表の機会をいただきました。
というわけで、内容はこれまでのLTの総まとめをしつつ、これからst2を触る人への
励ましと期待と地雷案内(?)といった感じにしました。

speakerdeck.com
#スライドの色もst2っぽいオレンジベースにしてみました

補足1

HA構成ガイドの図なども出したのでかなり大がかりな仕組みという印象を与えたかもしれません。まあたしかに小さくはないですが、最近のGitLab Omnibusと比べれば見通しやすいレベルだと思います。
以前qpstudyでLTした際に「MongoDBにはヒストリーログやauditが入ります」と言ったところ２つ後のLTで@kuwa_twさんが「Mongoにログ入れんなっつってんだろ」とスライドで叫んでいて大変忍びなかったです。あ、あの、いわゆるログメッセージはテキストに落ちますのでどうか..

補足2

st2はつなぎ役というか裏方的なソフトウェアなので、いろんなものと比較されがちです。発表内で紹介したように公式ブログにも比較記事が多くあります。
ということで、初めてのst2勉強会なのでst2に集中した方が良いかなとも思いましたが、これからst2を使うみなさまも言われるであろう比較論にも触れておきました。

補足3

入力->処理->出力のところで「Northbound API / Southbound API」の表現もしたかったのですが当日言いそびれた気がします。系/システムの捉え方として補足しておきます。

補足4

私の立場は「あまりスクリプト作成が得意でない運用エンジニア、またはiRuleもちょっと苦手なネットワークエンジニアのチームにおいてどうやってスクリプト化を質を保って進めていくか」という問題意識がベースにあります。
Ansible等もmoduleを使ってフレームワークとして活かすことで、シェルスクリプトで起きがちな問題(例: ヌルい正規表現によるバグ、ムラのあるエラー処理)を自然と防ぐのに役立つ素晴らしいツールだと思います。
単体タスクを超えたワークフロー的な処理ではst2が同様にフレームワークとして分岐-合流処理や変数引き渡しといった部分を整理できそう、というところで活かしたいと思っています。

....という問題意識がステ猫さんの２年前のブログにすでに整理して書かれていたりします。
d.hatena.ne.jp

補足5

以前NetOpsCodingでLTした時に、コメントツイをいただきました。

ツールの紹介でGUIが良いって意見をたまに聞くけど、それ使ってたらいつまでもコードに落ちないと思うので、無視して良いと思う。 #NetOpsCoding
— Yasuhiro Yamazaki (@sparklegate) 2016年6月27日

まったくご指摘の通りで、~~enterprise~~BWCはワークフローのIDE的なエディタとして便利ですが、操作系の標準GUIの方はまだイマイチなところもありますし、あまり標準GUIには期待せずよくできているst2コマンドで行うのが良いと思います。

感想

まだまだこれからのソフトウェアだよね、という感はありつつも多様な話題で登壇されたみなさまとcuriousなご参加のみなさまで面白い勉強会だったと思います。私がひときわ泥臭い発表内容だった感じなのがかなり心配ですが。

拡張Packが豊富なこともあり、利用シーンや重視する機能、トラブルポイントが個々に異なったりすることも予想されますが(Communty Slackでも話題論点が様々です)、st2を通して多くの人が集まってディスカッションしたり課題解決のヒントを得たりする場になると良いなと思います。
第２回が行われたら、ちゃんとした話はいったん出し切ったのでピザが届く系のネタでLTしようと思います。

そう言えばブロケードさん9月1日のOSC.Enterpriseに出展したら良かったのにとも思ったり。

番外

今回も熊本焼酎を差し入れしました。
www.tsuruya-dept.co.jp

手元にはまだおいしい焼酎がありますので、引き続き
　インフラや運用系
　&& 懇親会に焼酎持ち込み可
　&& LTでツールネタ可
というイベントやディスカッションの情報を求めています。

2016-06-28

自分用メモ：Monitorama 2016の資料リンク

Monitorama 2016 PDX

開幕したMonitoramaが期待以上の面白さです。
動画はアーカイブ公開されると思いますが、
ひとまず資料などへのリンクを随時まとめておきます。

Day1

Monitoring Challenges
http://www.slideshare.net/adriancockcroft/monitoring-challenges-monitorama-2016-monitoringless

Monitoring is Dead
https://speakerdeck.com/grepory/monitoring-is-dead
https://github.com/grepory/monitorama2016

How Metrics Shape Your Culture
http://www.slideshare.net/nicolefv/2016-metricsasculture

Creating A Culture of Observability at Stripe

healthz: Stop reverse engineering applications and start monitoring from the inside

https://github.com/kelseyhightower/monitorama

The Art of Performance Monitoring

SREConでの発表 https://www.usenix.org/conference/srecon16/program/presentation/smith

Tackling Alert Fatigue
https://speakerdeck.com/caitiem20/tackling-alert-fatigue
https://github.com/CaitieM20/Monitorama2016/blob/master/README.md

Humanscale Systems

Going for Brokerage: People Analytics at Redfin
http://www.slideshare.net/SarahLakeHagan/monitorama-2016
https://github.com/thesarahhagan/monitorama

Everything @obfuscurity taught me about Monitoring
http://www.slideshare.net/petecheslock/everything-obfuscurity-taught-me-about-monitoring

Day2

Scaling Pinterest's Monitoring
http://www.slideshare.net/BrianOverstreet1/scaling-pinterests-monitoring

What Your Javascript Does When You're Not Around

CHICKEN and WAFFLES: Identifying and Handling Malice

Fake it Til You Make It

5 Lines I Couldn't Draw
http://www.slideshare.net/librato/five-lines-i-could-not-draw

Everything is Broken

Metrics are for Chumps - Understanding and overcoming the roadblocks to implementing instrumentation

Day3

Intuition Engineering at Netflix

Prometheus
http://www.slideshare.net/brianbrazil/prometheus-monitorama-2016

Grafana Master Class

How to Teach an Old Monitoring System New Tricks
https://speakerdeck.com/kdaniels/teaching-an-old-monitoring-system-new-tricks

All of Your Network Monitoring is (probably) Wrong
http://www.slideshare.net/ice799/all-of-your-network-monitoring-is-probably-wrong
http://blog.packagecloud.io/eng/2016/06/29/monitorama-2016-all-of-your-network-monitoring-is-probably-wrong/

Building Twitter’s Next-Gen Alerting System
https://docs.google.com/presentation/d/1K4e7uB0wBzrlq5EctCvWEyok0gTOz-1Sh9Ya-o6NeRw/edit#slide=id.g150c37c97c_0_188

Monitoring and Health at Airbnb

Statistics for Engineers
http://www.slideshare.net/HeinrichHartmann/statistics-for-engineers-63589022

Monarch, Google’s Planet-Scale Monitoring Infrastructure

参加された方のメモ
https://github.com/zapman449/monitorama_2016_notes

2016-05-15

第5回ペパボテックカンファレンスに行ってきました

今回は「〜インフラエンジニア大特集〜」という副題が付いているとおりインフラ系のイベントなのですがWeb系な雰囲気満載だった第5回ペパボテックカンファレンスに行ってきました。
pepabo.connpass.com

本篇１トーク＆LT

各発表資料はアップされているので、発表部分は資料リンクとＱ＆Ａ部分の書き起こしおよびひとことコメントだけで。
発表のフォーマット感があって流れが掴みやすいのがとても印象的でした。
発表されたみなさんが大まかに以下に沿っていました。

アジェンダ - 背景経緯 - 問題設定/設計実装 - 結果/効果 - 残課題 - まとめ - 今後といった構成
イメージカラーベースの共通スライドマスター
ごせいちょうありがとうございました -> 拍手がしやすい区切り方
資料公開はSpeakerDeck

発表1 100行あったmod_rewirteを ngx_mrubyで書き換えた話 by buty4649さん

speakerdeck.com
Q&A
Q: apache/mod_rewriteの頃のテストは？
A: テスト環境に設定を入れて人手で確認

Q: Luaでも同じ事ができそうだがmrubyを選んだ理由は？またmod_rewriteよりレビューコストが上がっていないか？
A: Luaでもできるが、matsumotoryさん始め社内の知財的にruby,mrubyが強いので選んだ。元々得意な人が多いのでレビューコストもそれほどではない

Q: パフォーマンス劣化は無かったか
A: ngx_mrubyのwikiの情報ではパフォーマンスはそれほど落ちない。実際abコマンドでやってみてもそれほど劣化は見られなかった

発表2 ペパボのプライベートクラウド "Nyah" その後 / Pepabo's PrivateCloud "Nyah" After That by tnmtさん

speakerdeck.com

Q&A
Q: バックアップ構成は？
A: 現状けっこう課題
　 OpenStack上の別インスタンスやOpenStack外の基盤に採っている

Q: OpenStackのバージョンアップ後の切り戻りは？
A: 新バージョンは別途構築して移行しているので実質切り戻しはない

Q: Neutro使うとLinuxでパフォーマンス落ちないか？
A: 現状構成は組めたけどパフォーマンスは細かく見られていない

LT 高集積ホスティングにおけるセキュリティとPHP実行基盤の高速化 by tshpaperさん

speakerdeck.com

下matsumoto-rさんの内容を超高速でご紹介された勢いのある発表でした。
5年ちょっと前くらいに当時のParalellsさんの製品で物理一台に7000ドメインくらい積めるのがありましたが今のハードスペックだと万単位でやってるんですね。

ちなみに今日の発表の「高集積ホスティングにおけるセキュリティとPHP実行基盤の高速化」のより詳細な内容として参照されていた資料はこちらになります #pbtech https://t.co/t3HIuSBVto
— 松本亮介 (@matsumotory) May 14, 2016

LT インフラエンジニアもCIがしたい by alotofweさん

drone.ioのCIをnested dockerで実施するお話。CIの行き倒れゴミとか経験してるとdrone.ioの良さ嬉しいですよね。CIツールはまだまだ増えていますがインフラで使うときはテスト環境の生成と、単体ではないテストを流せるか/どう流すかがネックというか鍵になる印象です。GitHub Ent.がすでに運用の真ん中に根付いているという前提条件もうらやましくも重要なポイント。
speakerdeck.com

発表3 時代が求めたSTNSと僕〜夏の日の1986〜 by pyama86さん

AD以外のLDAPは挫折しましたすみません。deploy用の共通アカウント使うならChatからdeployすればいいかなとか(軟弱)。基本認証に対応していたり、api end pointを並べて書けば冗長できたり、使う側に便利なポイントも抑えてあったのが好印象でした。
SSH鍵管理はクッ社さんもいろいろ便利ツール作っていたり、管理の面では新たな課題ですね。
speakerdeck.com

Ｋ「実際開発の人たちはインフラに入ってきているか？」
Ｔ「Puppetの設定にcommitしたりはしている。」
Ｓ「あるRoleに対してはインフラエンジニアはコードのレビューのみになっている」
Ｋ「今まで煩雑な依頼があったのが、だいぶ良い環境になってきている。
　　数年前からDevOpsに取り組んでいるが、アプリケーション寄りの活動も、物理やネットワークにも取り組んで行きます」

以上。以下Ｑ＆Ａ

Q: 構成管理ツール、の難しさを感じる。社内への普及や教育はどうやっているか？
A: (Ｔ)一番最初はmizzyさんから直接教えてもらって、落とし込みは自分たちで議論しながら行った
　 (Ｋ)当時は良い教材が無かった。あと普及面では世の中にはまだまだ手順書があるが、これを置き換えたときに何が得なのか、逆に手順書でないとできないことは何か、とみんなで考えてはどうか
　 (Ｓ)当時「スクリプトではダメだぞお前」という空気があった
　 (Ｋ)同調圧力ではなくて、問題意識を共有してる上でのこと

Q: インフラエンジニアとアプリケーションエンジニアの責任範囲の分け方は？
A: (Ｋ)アプリケーションエンジニアのプルリクをインフラエンジニアがレビューするのでその時点で責任範囲というかコードの通り。振り返りは大事だが、責任範囲を問うことはしていない

感想や小話

全体

先のqpstudyは比較的泥臭さも感じるインフラエンジニア界隈でしたが、今日はさすがペパボさんというか技術で様々な施策を打っていて、自社サービスの環境をちゃんと把握した上での対応が行われているという感じでした。
ruby/mrubyという軸が強くあるので、環境やツール選定にも大きな理由があってすんなり行っている印象でした。自社プラットフォーム開発をされている会社さんはこれがありますね。運用系の集まりだと強い言語は無かったり個々人で違ったりするので「RubyのDSLで書けるっ」はそれほどメリットでなかったりも。個人的には「フレームワークとしてメリットを得られるものを選べば良いんじゃないでしょうか」と言うシーンが最近多かったので、明確な軸があるのはうらやましくも感じました。

構成管理

cfengine is cool, puppet is sexyというフレーズを聞いたのは10年近く前の気がしますが、古参ツールのpuppetを会得して使いこなしている感にあふれていて、ツールがちゃんと手段に収まっているのも印象的でした。構成管理ツールって最初に使った時に気持ちの良い感動があるはずなので、そのメリットが活かされたまま定着できているのが良いなあと。世には「Chefツライ」とか「YAMLプログラミング(Ansible)ツライ」とか「本当にholoで良いの？」いった話も多いですからね..ベアメタルレベルの管理のお話が聞けなかったので、そこの施策も聞いてみたいです。OpenStackで言うIronicとかUbuntuならMAASとか
tnmtさんに「ストレージ選定ネタの続きも期待してます」「StackStorm便利ですよ。どうっすか」と２つお話できたので、もしかするとOpenStack MistralのワークフローベースでStackStormを操るお姿が見られるかもしれません。StackStormは、都合がつけばHosting Casual #3でディスカッションのまな板に乗せてみたかったのですが。

ヒト

一方で4月のqpstudyや3月のIaas Casualと同じくインフラエンジニアの今後のキャリア形成やチームメイキング、採用といったヒトのお話では共通した課題や悩みが聞かれた気がします。クラウドやらコンテナやらと基盤が進化してツールも充実したことで、変化は感じていてそれに伴った危機感も感じている、といったところでしょうか。今回のpbtechと併せた3つのイベントで割と共通して聞かれたメッセージとしては「すべてできる人はいない」「コミュニケーション大事。コミュニケーションもChatOpsとか技術で改善できる部分もある」「そこはきっと楽しいところ(デマルコ風)」がありました。あと懇親会でkumanoさんからファシリテーターの活用というお話もあり、これまた実際の活用話はあまりお聞きする機会が無かったので、ファシリテーター人材という課題も有りそうですが納得感がありました。

☆

実は前日まで抽選に落ちたと勘違いしていて午前中に髪を切りに予約入れちゃったりしていたのですが、無事参加できて様々な刺激を得られて良かったです。今後もpbtechでインフラ/運用系のネタをやって欲しいし自分のチームメンバーにも参加して欲しいです。
また、懇親会のカレーが小分けで配布されたのは食べやすかったので、Zoho各位にはナンのこだわりもあると思いますが参考にしてもらえれば。

トークセッション中、後ろでは着々とカレーの準備をしています！#pbtech pic.twitter.com/JWrNUcWdHi
— ペパボ採用担当 (@pb_recruit) May 14, 2016

おまけ

Web+DB Press Vol.92の第一特集"Web開発新人研修"はまるごとペパボさんのご執筆です。
gihyo.jp

(5/16 公開資料へのリンクを追加しました)

2016-04-28

ntpの脆弱性201604公開分-雑まとめ

ひとまずRedHat情報で整理したものを。
"will not fix"でconf内容を見直せ、というものが結構あります。

CVE-2015-7973:Authentication Bypass by Capture-replay

CVSS v3 Base

アップデートパッケージ(RHEL)

なし

補足

Do not use NTP's broadcast mode by not configuring the "broadcast" directive in the ntp.conf file.

CVE-2015-7974:Improper Input Validation

CVSS

6.3

アップデート

なし

CVE-2015-7975:Improper Input Validation

CVE-2015-7704:Improper Input Validation

アップデートパッケージ(RHEL)

https://rhn.redhat.com/errata/RHSA-2015-1930.html

CVE-2015-7705:Improper Input Validation

未

補足

Do not add the "limited" configuration option to any restrict lines in the ntp.conf file.

qpstudyに参加してエンシェントな焼酎をふるまってきました

初心者にもやさしい(頃もあった)勉強会、qpstudyに初参加してきました。
www.zusaar.com
今回のテーマは監視＆運用＋自動化。

本編

最初は @koemu さんによる「ITインフラ監視の今後を考える」。
惰性的に行われてきた面もある監視を根本から見直してみようという意欲的な問題提起でした。
経営や事業評価の視点も交えて誰にどういう価値を提供するか、という観点もあり非常に刺激的でした。
speakerdeck.com

後半挙げられた３つの課題が印象的だったので整理。

1.PaaSをどう監視するか

　監視させてくれない/見えない部分が多い、検知しても対応は事業者任せでできることが無い
　監視も事業者提供ツール頼み？ cf. http://www.stackdriver.com/

2.監視システムはDIYかSaaSか

　SaaSはコストが明瞭、その分高く見える場合も
　DIYの場合の構築コスト/運用コスト/提供価値のトータルで比較してみる必要がある

3.監視の細かさ

　対応の必要なものを確実に通知
　通知内容の優先度
　　- 障害でなければ通知は要らない？
　　- HDD容量など予防的通知は？
　　- 冗長したWEbのうち1台落ちたときは？
　　- ステークホルダーと合意は取れているか？

続いて前佛さんの「Re:運用に自動化を求めるのは間違っているだろうか？」
当初予定の時間枠では半分強しか話せずw懇親会で延長戦も行われました。

Re: 運用に自動化を求めるのは間違っているだろうか from Masahito Zembutsu

www.slideshare.net

冒頭のスライドの通り、ポイントは３＋１つ。

運用における自動化範囲の整理・分類

自動化で運用はこんなにも楽しくなる

トラブルシューティング自動化は未解決課題

本来あるべき状態から逆算して運用業務を楽しくしよう

運用における自動化範囲の整理・分類

ツールや手法で改善可能になった部分もある
-設計＆構築 <- 構成管理ツール、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/

最後に

長時間のイベントでしたが参加者の意欲も旺盛で様々な意見交換ができて非常に有益でした。
人数の多いイベントをハンドリングしたスタッフのみなさまも素晴らしかったと思います。
主催・スタッフ・参加・ハッシュタグ参加されたみなさま、ありがとうございました。

余談

手元にまだ宮崎のおいしい焼酎があります。平日夜に空けるのは厳しいと思うので
　土曜日開催のインフラや運用系
　&& 懇親会に焼酎持ち込み可
　&& LTでツールネタ可
というイベントの情報を求めています。

(4/24 LTの他の方々の発表部分を追記しました。酔ってたしログ無いので薄めですが)

2016-04-13

IaaS Casual Talks #1におじゃましました

iaas-casual.connpass.com

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

2016-04-13

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系はサポート対象外となりましたので今回もアップデートは提供されません。

(追記今回の対象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
で別物でした。何か関連事項が隠されている、とかではありませんでした。

補足1

補足2

補足3

補足4

補足5

感想

番外

Day1

Day2

Day3

本篇１ トーク＆LT

発表1 100行あったmod_rewirteを ngx_mrubyで書き換えた話 by buty4649さん

発表2 ペパボのプライベートクラウド "Nyah" その後 / Pepabo's PrivateCloud "Nyah" After That by tnmtさん

LT 高集積ホスティングにおけるセキュリティとPHP実行基盤の高速化 by tshpaperさん

LT インフラエンジニアもCIがしたい by alotofweさん

発表3 時代が求めたSTNSと僕 〜夏の日の1986〜 by pyama86さん

LTベンチマークテストやろうぜ by pbmasakiさん

LT構成管理ツールを用いたインフラ開発フローの改善 by k_hanazukiさん

トークセッション「ペパボのインフラを読み解く」

☆

☆

☆

☆

☆

☆

☆

☆

感想や小話

全体

構成管理

ヒト

☆

おまけ

CVE-2015-7973:Authentication Bypass by Capture-replay

CVSS v3 Base

アップデートパッケージ(RHEL)

補足

CVE-2015-7974:Improper Input Validation

CVSS

アップデート

CVE-2015-7975:Improper Input Validation

補足

CVE-2015-7976:Improper Input Validation

アップデートパッケージ(RHEL)

補足

CVE-2015-7977:NULL Pointer Dereference

アップデート

補足

CVE-2015-7978:Uncontrolled Resource Consumption ('Resource Exhaustion')

アップデートパッケージ(RHEL)

補足

CVE-2015-7979:Incorrect Synchronization

アップデートパッケージ(RHEL)

補足

CVE-2015-8138:Improper Input Validation

CVSS v3 Base

アップデートパッケージ(RHEL)

CVE-2015-8139:Information Exposure

アップデートパッケージ(RHEL)

補足

CVE-2015-8140:Authentication Bypass by Capture-replay

アップデートパッケージ(RHEL)

補足

CVE-2015-8158:Uncontrolled Resource Consumption ('Resource Exhaustion')

アップデートパッケージ(RHEL)

CVE-2016-1547:Incorrect Synchronization

CVE-2016-1548:Authentication Bypass by Spoofing

CVE-2016-1549:Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

CVE-2016-1550:Improper Input Validation

CVE-2016-1551:Authentication Bypass by Spoofing

CVE-2016-2516,CVE-2016-2517:Improper Input Validation

CVE-2016-2518:Out-of-bounds Read

CVE-2016-2519:Improper Restriction of Operations within the Bounds of a Memory Buffer

CVE-2015-7704:Improper Input Validation

アップデートパッケージ(RHEL)

CVE-2015-7705:Improper Input Validation

補足

関連情報

本編

運用における自動化範囲の整理・分類

本篇１トーク＆LT

発表3 時代が求めたSTNSと僕〜夏の日の1986〜 by pyama86さん

(追記適用時の影響)

(追記今回の対象CVE)