HTTP TRACE / TRACK Methodsの無効化を確認する方法

先日Apacheの脆弱性チェックで指摘された設定を無効化した際に、設定変更が本当に適用されているのか確認する方法が分からなかったので調べました。 なんか、まぁ、今更なヤツですがここにもメモしておこうと思います。

TRACE TRACKメソッドの無効化

まず設定変更ですが vi などのテキストエディタでApacheの設定ファイル（例：/etc/httpd/conf/httpd.conf ）を編集して下記の設定（TraceEnable）を無効（off）にします。有効（on）の場合は無効（off）に、設定が存在しない場合は、設定ファイルに下記を追記します。

TraceEnable off

次にApacheを再起動して設定変更を反映します。

> service httpd restart 

これで設定が反映されました。

ここまでは手順書に書いてあったんだけどね…^^;

無効化の確認方法

さて、ここからが今回の本題。

以下の手順でTRACE TRACKメソッドが無効化したことを確認します。

まず必要に応じてtelnetをインストールします。（※未インストールの場合のみ）

> yum -y install telnet

以下のコマンドで設定変更したApacheへ接続して無効化を確認します。

> telnet localhost 80

-------------------------------

Trying 127.0.0.1...

Connected to localhost.

Escape character is '^]'.

-------------------------------

ここで入力待ち状態になるので以下のように入力します。

-------------------------------

OPTIONS / HTTP/1.1(Enterキー)

host: localhost(Enterキー)

(Enterキー)

-------------------------------

※各行を入力したら(Enterキー)を押して改行することに注意してください！

私はこの無知により15分くらいハマりました。

続いて下記のように表示されます。

-------------------------------

HTTP/1.1 200 OK

Date: Mon, 22 Aug 2016 18:48:12 GMT

Allow: GET, HEAD, POST, PUT, DELETE, OPTIONS　← ココに TRACE がない！

Content-Length: 0

Connection: close

Content-Type: text/plain; charset=UTF-8

Connection closed by foreign host.

-------------------------------

上記の許可メソッド一覧（Allow:の部分）に TRACE メソッドが表示されません。

これで設定変更が適用されたことが確認できました。

＜参考URL＞

http://www.rem-system.com/apache-security01/#http_TRACE

http://www.tohoho-web.com/lng/199909/99090233.htm

http://d.hatena.ne.jp/end0tknr/20131127/1385518307

[2016/7/20(水)］『駅すぱあと』のヴァル研究所さんへ大人の社会見学へ行って来ました

夏風邪でダウンしていたので少し時間が経ってしまいましたが『駅すぱあと』のヴァル研究所さんの現場を社会見学させてもらいました。ちなみに大人の社会見学…というタイトルには深い（やらしい）意味はありませんｗ

入口ではペッパーくんがお出迎えしてくれました。

アナログボードと付箋で情報共有

まず驚いたのは、とにかく社内にボードが沢山あるということでした。自立式のホワイトボードはもとより、壁の空きスペースにホワイトボードシートを貼り付けて巨大なホワイトボードにしたり、巨大な（１畳くらい？）ダンボールやベニヤ板を置いてホワイトボードにしたりと、使えるものは何でも使っているという感じでした。

手書きした付箋をボードに貼りつけてチームで情報共有を行う「タスクかんばん」は私の現場の開発チームでも使っていますが、現状はあくまでも開発チーム内の情報を共有し見える化、見せる化するにとどまっています。

ヴァル研さんの社内ではざっくり下記のような粒度でアナログボードを使い分けているという印象を受けました。

• ボード（大）：複数チームの半年分のざっくり計画と進捗を共有（リリーストレイン時刻表）
• ボード（中）：チームのタスクと進捗を管理（チーム毎にユニーク。複数使い分けるチームも）
• ボード（小）：個人のタスクと進捗を管理（人によってあったりなかったり）

これはウチの現場にも大変参考になります。各チーム間の細かいことまで全部ひとつのボードで管理しようとするとすぐに破綻するし、Redmineのような電子化されたチケットにしてしまうと開発者以外があまり見なかったりして埋もれてしまうことが多々ありましたが、こんなふうに粒度ごとにボードをつくれば共有できるようになるかも…という気付きをいただきました。

開発チームだけでなく、総務や営業もカンバン

次に驚いたのは、開発チームだけでなく、総務や営業といった部署まで前述のアナログボードを使用した情報共有を行っていることでした。それぞれのチームが使っているボードも部署やチームごとに実に多様でした。例えば総務では、年間を通して時期によって定期的な作業があったりするので、定期作業と不定期作業を分けてタスク管理したり、改良したニコニコカレンダーでエモーショナルな領域も含めた問題になるべく早く気付けるよう配慮していました。また、営業では売上や達成率など数値化されたものが多くボードや柱に貼られていました。 社内のカンバンの様子はこちら（↓）で詳しく紹介されています。 

speakerdeck.com

全部門にカンバンが導入された１０の理由と活用事例 「駅すぱあと」はカンバンと秘伝のソースでできて... // Speaker Deck

 「カンバン」や「タスクかんばん」というと「TODOーDOINGーDONE」のオーソドックスなものを思い浮かべますが、それだけでは足りなかったり、業務やメンバーに向いていなかったりすることもあると思います。無理に同じやり方をするのではなく、ふりかえりながら自分達が働きやすいやり方を自分達自身で探していくことが大切なんだ…ということに、改めて気付かされた気がしました。

最後に

この日、一緒に見学したメンバーは社内の同じ受託開発チームのメンバーだけでなく、自社サービス開発チーム、普段は客先に常駐して作業している組込系の開発チームからも興味を持って参加してくれたのがとても良かったです。参加してくれたメンバーに感謝です。

また、それ以上に、社会見学をこころよく受け入れてくださったヴァル研究所さんに感謝です。Webサービス監視にベイダー卿のXFD（eXtreme Feedback Device）を使用するなど、遊びゴコロ（↓）も大変参考になりました。本当にどうもありがとうございました。

こちら（↓）に当日の様子をアップしていただきました。

本日も社内見学に来ていただきました。 2時間近く、熱心に色々興味を持っていただきましたー! | Facebook

＜追伸＞

当日参加した自社サービス開発チームのメンバーがヴァル研さんの現場をヒントに、さっそく独自のカンバン的な何かをおっ始めました。やはり何か感じるものがあったようです(^^) これが越境Powerってやつですね。

社会見学当日に残念ながら業務の都合で来られなかったメンバーやエンジニア以外の人（総務や営業や広報など）を募って、もう一度見学を企画したいな…と思いつつ、自分の現場も社会見学で人が呼べるような会社にしたいな…と感じたのでした。

SEのための契約知識【超】入門

諸事情により少しだけ勉強する機会があったので

知ってそうで意外と知らないIT系システム開発の契約に

関しての基礎的な知識（の一部）をスライドにまとめてみました。

★SEのための契約知識【超】入門(#1)

SEのための契約知識【超】入門 // Speaker Deck

★SEのための契約知識【超】入門(#2)

SEのための契約知識【超】入門（#2） // Speaker Deck

【超】がついているだけあってホントに基本のキだけですが…

社内勉強会用の資料ですが何かのお役にたてば幸いです。

今年の個人的な流行語は「Git」と「プルリクエスト」※今更ではあるが…

2015年も今日が最終日。

今年は（も？）自分なりの目標を立てて挑んだ一年。

技術のみならず、チームとかマインドセットとかモヤモヤしたものに挑んだ一年でもありました。

モヤモヤの部分を語るには、ここは適切で無いかもしれないので、それはまた別の機会に譲るとして、今年そのモヤモヤの部分に大きく影響を与えたツール「Git」について少し書いてみようと思います。

SVN期

今年の始めは、バージョン管理はSVNで行っていいました。

既に社内にGitの環境はあったのですが、社外の現場と連携したソースコードの共有を行う必要があったことからクラウドベースで運用していたSVNを選択しました。並行してチームメンバーで作業を見える化するためにタスクボードは先ずは下記のようなスタンダードなカタチから始まりました。

チケットの粒度が大きくて、作業が完了しないまま次の作業が始まるケースが多発して、価値を産まない仕掛中のタスクが多発する傾向にあったのでWIPを設定しました。

さらに、個人作業がメインで完了の定義があいまいだったタスクを、他の人がチェックするようにしました。

これにより個人任せだった完了定義と品質が少しずつ改善されていきました。

Git（bucket）期

社外メンバーとの連携の制約が解かれて、晴れて（？）社内のGitbucketでのバージョン管理が始まりました。最初は、ひたすらmasterブランチへPUSHするSVNのような運用を行っていましたが、プルリクエストを前提とした運用を始めました。これにより、動作的な確認だけでなくコードベースのレビューが自然の流れで可能になりました。当初はSVNの時の運用と違って、いちいちブランチを切るのが面倒くさく感じたのですが、プルリクエストの恩恵に気付いてからは、その手間はあまり気にならなくなりました。加えて、フィーチャーブランチを切る時に悩まないよう、ブランチの命名規則をルール化（案件を示す英字一文字_ISSUE番号）したことで、さらに気にならなくなりました。

が、チームメンバーが増えるに従ってどれを誰がやっているのかが分かりにくくなるという新たな問題も発生しました。

そこで、現在（今年の最後）は、タスクボードは上記のようなカタチになりました。新たにレビュー待ち、レビュー中という状態のレーンも設けることで、以前と比較して【実装】→【レビュー】→【完了】までの流れと状態がかなり分かりやすくなりました。また、この流れはプルリクエストを出してからレビューしてマージするまでの流れと非常に非常に非常に…自然な流れでシンクロしています。

プルリクエストの文化を徹底するため、ふりかえりなどで運用のしかたを相談して、masterブランチ、developブランチには直接PUSHできないよう、フックスクリプトを設定して事故を未然に防ぐような運用にしました。

あとは、ブランチ戦略としては

nvie.com

 を参考に、先ずは下記のようなシンプルなルールで運用をし始めました。実際は、下記をベースにテスト用のブランチやドキュメント用のブランチをケース・バイ・ケースで切るなどの試行錯誤や工夫はしていますが、現在でも大枠は下記の戦略です。

 

これによって、何が変わったか？

ですが、下記のような目に見えた恩恵がありました。

• レビューをする文化の定着
• 責任の分担（ソースコードの共同所有）
• ソフトウェア品質の向上
• 開発スピードの大幅UP（※メンバーにもよるけど半端ないくらいUPした）
• 柔軟なリリース（プルリクブランチのマージを選択することで可能）
• 人のソースコードを見る習慣から自然と学びがある

ハッキリ言って本当にいいコトずくめで、考えてみてもデメリットは思いつかないくらいです。

良い文化というものは、ツールの力を借りはするものの、それはメインのパワーとはならないと思っていたのですが、Gitとプルリクエストは、上記のような恩恵をもたらす文化を醸造するのにものすごい力を発揮してくれました。

モチロン結局は運用するのは人なので、このような機能を良くも悪くも使えるとは思いますが、個人的にはこれを使わない手はないと思っています。（※だって只だし）また、メンバーが必要を感じて段階的にカイゼンしていけたことも（今思えば）結構大事なことだったんじゃないかなと思います。押し付けて一方的にやらせていたらまた違った結果になっていたんじゃないかなぁ…

使ってる人にとっては今更イマサラですが、巷ではなんかGitが流行っているなぁ…と思ってから随分と時間が経って（気付けば数年？）しまいましたが、その恩恵を感じた一年でした。

個人的に今年は燃えプロ（※炎上プロジェクト）もあって、イロイロと大変なこともありましたが、チームメンバーと同じかそれ以上にGitとプルリクエストに助けられた年でもありました。たぶんSVNとかTFSを今までどおりの感覚で使ってたらもっと炎上していたんじゃないかなぁ…（※これらのツールがダメという訳ではないです。ちゃんと使えばいいだけだとは思います）

今、いっぱい飲んで年末を堪能しながらいい気持ちでこの記事を書いています。

きっと誤字もたくさんあることでしょうが、ご容赦ください。

それでは、今年も残すことろあと２時間…

良いお年をお迎えください。

初めてのATTでCSMになれた話

この記事は TOCfE Advent Calendar 2015 の14日目の記事になります。

昨日はメイド長こと大和さんの「未来福音」のおハナシでした。

まずは自己紹介。Twitterアカウントと同じくorinbouというHNでBlog書いてます。派遣や受託でソフトウェア開発を行うの小さな所謂SI屋で働いています。プログラム書いたりマネージメントしたりしながらそこそこデベロッパな生活を送っています。時々、IT系のコミュニティに参加したりTOCfE Boot Campに姿をあらわします。

TOCfE歴は、TOCfE Boot Campで、考えるための3つの道具「ブランチ、クラウド、アンビシャス・ターゲット・ツリー」をひととおり学びました。そういえば、今回TOCfE Boot Campに参加するキッカケもメイド長だったような…ｗ その人からのバトンを引き継ぐことになるとは、何やら不思議な縁を感じますね。

今回は、一年前に参加した

で 「アンビシャス・ターゲット・ツリー」を初めて学んだ時のお話をしたいと思います。

アンビシャス・ターゲット・ツリー（長いので以降はATTと略しますね）は、「目標を実現したいけど、どーやったらいいんか分からない…」という時に、今ある情報を基に達成計画を立てるツールです。ATTについては「目的と目標について｜Eijiのブログ」でもEijiさんが解説してくれているのでそちらもご覧ください。

ATTをつくる流れはこんな（↓）感じです。

1. アンビシャスターゲット(AT)を決める
2. ATに対する障害やリスクを洗い出す
3. 障害を乗り越えたといえる中間目標を出す
4. 中間目標を前提条件順に並べる
5. 中間目標に実際の行動を加える

この日は折角の機会だったので、私が普段から抱えているリアルな目標（AT）を達成するためにワークショップを活用させてもらいました。私のATは「認定スクラムマスター研修（通称CSM研修）に参加して認定資格を得る」というものでした。資格を得る事自体が本質的な目標というわけではなく、IT系コミュニティなどで仕入れた様々な知見やツール、マインドセットなどを自分の現場や社内に展開するにあたり、分かり易い資格というカタチとして持っておくことが、それを加速するひとつの武器になると考えたからです。人事考課の面談や折をみては１年くくらい上長に訴え続けていたのですが、なかなか行かせてもらえず半ば諦めモードな感じでした。

そんな状態で先ずは個人作業で自分なりに障害やリスクとなることを洗い出してみてATTを作ってみましたが、手詰まりの連続でした。直列的なツリーとなり、とても目標を達成できそうもない木になってしまいました。ATTというツールを初めて使うということもあったと思いますが、自分なりにやることはやってきた…という変な先入観というか自尊心みたいなものが邪魔をしていたいように思います。

ワークショップが進行していき、各自が自分なりに作ったATTを３人一組のグループ内で共有する時間になりました。その時、同じグループのお二方から様々な指摘やツッコミ、問いかけをしていただき、自分なりに手は尽くした…と勝手に思い込んでいたカチカチ頭の自分に気付けました。ありがたいことです。

さらに、私があまりにも切実そうだったためか、お二方とも自分のATTを差し置いて、後半のグループワークの殆どの時間を、私のATTを完成させることに費やしてくれました。自分だけで考えることももちろん大事ですが、前提として思い込みがあるような場合は、他者から質問されたり、声に出して読んでみて自分自身の耳から情報を入力してみたりすることは、自分の置かれた状況を客観的に捉えるための手段として、とても有効なのだと改めて感じました。

その日、完成したATTがコチラ（↓）になります。

• 濃黄色：アンビシャス・ターゲット（１年以内にCSMの資格を取る）
• 薄黄色：中間目標
• オレンジ色：行動

玄人の方からすると、まだまだ十分な完成度とはいえないツリーかもしれませんが、自分なりにしっくりきていたので、翌日からこのツリーに沿って下から順番にやっていくことにしました。徹夜でCSMアピールスライド作ったり、社長室へ乗り込んで説明したりとか。ツリーに沿って進めていく中で新たに分かること、状況の変化などに応じて微妙に修正を加えはしましたが、基本的には、この日決めた方向へ殆ど迷うことなく進んでいくことができました。アンビシャス・ターゲットに期限をつけたのが良かったのかもしれませんし、また、一緒に考えてくれた人達の顔（プレッシャー？ｗ）が後押ししてくれたようにも思います。

そんな訳で、今年の3月めでたくCSM研修に参加して資格を習得することができました。

その時の様子は

の記事に書きました。単にATTだけの力ではないかもしれませんが、この日この会に参加していなかったら、間違いなくこのようなアプローチはしていないかったと思います。TOCfEのATTというツール、また、TOCfE Boot Campという場、また、そこで出会えた人達には、ただただ感謝の言葉しかありません。本当にありがとうございます。

TOCfEに興味がある人、また、学びたい人にとって、TOCfE Boot Campは費用もそれ程かかりませんし、初心者でも気兼ねなく参加できる場になっていますので、少しでもご興味ある方は、一度参加されてみては如何でしょうか？もしかしたら素敵な "アハ体験" ができるかもしれませんよ。

最後に告知です。TOCfE Boot Campの直近のイベントは

になります。年内最後のイベントになるのかな？

ご興味ある方は是非ともご参加ください。

明日は15日目、Kunikazu Fujita さんです。どんな話が聞けるのか楽しみです。CLRかな？クラウドかな？そんな訳で、まだまだ TOCFEアドベントカレンダー2015のバトンは続くのです。それでは、よろしくおねがいします。

認定スクラムマスター（CSM）を取得しました

先月の話になりますが念願の認定スクラムマスター研修を受けてきました。

講師：ジム・コプリエン - James O. Coplien(Jim Coplien)

日時：2015年03/02（月）〜03/03（火）

場所：渋谷 VOYAGE GROUP 会議室 パンゲア

この日も、日本人だけでなく、アメリカ、バングラデシュ、中国といった多国籍の参加者がいました。なんちゃってアジャイラーの自分にまず最初に刺さったのは、朝会の３つの質問に足りないもの（「チームのゴールに貢献するために…」を常に意識して話をすること！）という指摘と、朝会で毎日スクラムボードを見なおしなさい…という点でした。やってたつもりだったけど、改めて、そこまで意識的にはやってなかった…でも、そういう小さい意識が結果として大きな違いを生み出すんだろうな、と

ノッてきたのかいつもなのか、Copeも裸足になって熱く語ってくれました。

２日目後半は、楽天の川口さんも駆けつけてくれてスクラム流の挨拶を教えてくれました。

得るもの、気付き、出会いなどなどイロイロとあった訳ですが、実践の場（私の現場）で活かしたいと思います。なんせ赤いピルを飲んだ（飲まされた？）訳ですから。

セミナー終了後、1週間くらいで、ScrumALLIANCEから認定試験の案内が来ます。メールの案内に記載されているオンライン試験にパスすれば、すぐに認定スクラムマスター（Certified Scrum Master、略称CSM）の認定証が発行されます。ちなみにこういうの（↓）です。

いつ頃からかは不明ですが、今では日本語で受験できるので英語が苦手な人でも問題ありません。日本語、英語の他にも中国語などのかなりの言語で受験できるようになっていたので、スクラムの認知度が世界的に高いことを間接的に感じました。

そして、これはゴールでなく、始まりです。

終わりなき旅が始まります（もう始まってますが…）

いざ

RTMP接続を自前で死活監視する方法

新年あけましておめでとうございます。

年末年始の休暇で、執筆やプログラミングなど色々とやろうと思っていたのですが一家で病に伏していたためでコレしかできませんでした。ほぼ自分用の技メモです。

一般的なサーバの死活監視あれこれ

pingレベルのサーバ死活監視やWebサービスやURL死活監視については、無償／有償のサービスが世の中には沢山あります。例えば監視サービスだと「Site Alert(サイトアラート)」とか「Site Care FREE Ⅱ」とかありますし、最近だとやっぱりHatenaさんの「Mackerel」とかですかね。自前で監視サーバを建てるんなら「Hinemos」なんかもあります。

RTMP接続の死活監視サービスはないの？

現在ストリーミング配信サービスの開発に関わっているのですが、今回やりたかったのがストリーミングサーバの死活監視なので、監視対象のプロトコルはrtmpやrtmpeやrtmptなどです。これらはもともとAdobe社が開発したTCPベースの通信プロトコルで、現在では仕様が「Real-Time Messaging Protocol (RTMP) specification | Adobe Developer Connection」として公開されています。一般的な死活監視サービスでは、この特殊な接続の死活監視をすることができません。

と思ってRTMPの死活監視サービスを探したら、「おっ！」ありました！！

こんなビンゴなの（↓）を発見しました。

Webサイト監視サービスで初！ストリーミング配信の監視が可能に！ 『AEROALIVE（エアロアライブ）』に、RTMP監視機能を追加 | AEROALIVE | プレスリリースを無償で投稿・閲覧・配信：AEROPRES（エアロプレス）

が、情報が2年前から更新されておらず新規ユーザ登録もできなくなっていました…orz

う～ん、残念。。やはり自力でやるか…

自前でRTMP接続の死活監視するには？

仕方ないので「rtmpdump コマンド一覧と使い方 : ニコニコ動画研究所」を参考に自力で死活監視する方法を考えてみました。

まず下記のツールを入手します。

Linux版とWindows版があります。

今回はWindows版（EXE形式）をダウンロードしました。

RTMPDump 2.4 122213

次にダウンロードした実行ファイル一式を任意の場所に配置します。

パスを通す必要もなく、コピーのみでOKなのでとても簡単でした。

Jenkinsで監視するプロトコル毎に下記コマンドを定期実行させるJobを作成します。ありがたいことにRTMPDumpはコマンドラインで実行でき、かつ、実行結果をEXIT STATUS（成功：0、失敗：1 or 2）として返してくれるので、実行（死活監視）に失敗した場合のみJenkinsでビルド失敗メールを簡単に飛ばせます。

• RTMP

         rtmpdump.exe -r rtmp://localhost/vod/mp4:sample1_500kbps.f4v -o rtmp.f4v

• RTMPE

         rtmpdump.exe -r rtmpe://localhost/vod/mp4:sample1_500kbps.f4v -o rtmpe.f4v

• RTMPT（※必ず失敗してしまうので監視対象外としました。Win版だからかな？）

         rtmpdump.exe -r rtmpt://localhost/vod/mp4:sample1_500kbps.f4v -o rtmpt.f4v

念のためRTMPdumpの監視接続時に接続数が増えることも管理コンソールで確認しました。とりあえず、これでOKですね。

そんな訳で、マニアックな記事で始まった2015年となりましたが、本年もどうぞよろしくお願いします。