ただのにっき

■ 猫が床の上にじかに寝るようになると夏到来

なんでも観測史上もっとも暑い5月だったそうで、じっさい今日は暑かった。この週末は粗大ごみを出したり掃除したりとけっこうアクティブだったんだけど、これ以上暑くなるのは勘弁してくれって感じ。

で、とうぜん猫たちも夏モードになるわけで、ドーラはベランダのてすりでだらーんとしてるし、グスタフも柔らかいクッションの上とかでなく床の上にじかに寝る。というか、歩いているとあちこちに猫が寝そべっているので足元に注意しなくてはいけない季節。

とはいえ朝晩はまだ涼しいので、グスタフはまだ夜になると布団に入ってきて寄り添って寝たがるのだが。猫の快適気温は人間より高めだそうなので、向こうは暑くないけどこっちは暑いという。うへぇ*1。

■ Picasa APIの認証をパスワードからOAuthに変更した

massrの写真投稿機能では主にPicasaプラグインを使っているのだけど、昨日あたりから急にうまく動かなくなり、エラーメッセージをみてみると「パスワード認証使えなくなったぜ」みたいなページに飛ばされた。なるほど、もうずいぶん前からOAuthに移行しろって言ってたもんね、見てみぬふりしてたけど、ついにそのときが来たか。

奇しくも開催中のGoogle I/OではGoogle+から写真ライブラリ機能を分離したGoogle Photosが容量無制限を謳って華々しくデビュー。Picasaも吸収されちゃうんだろうと思うけど、Google PhotosはまだAPIを公開していないっぽいので、PicasaのAPIはまだしばらく現役だろう。

というわけで、Googleが提供するOAuth2.0への移行を始めたのだが、これがなかなか、うまくいかない。ちなみにこれまでパスワード認証で使っていたpicasa gemがOAuthに対応していることはドキュメントで確認済み。問題はこれに指定するアクセストークンの取得方法だ。Using OAuth 2.0 to Access Google APIsを読むと、今回のようにユーザとのインタラクションなしにAPIを使いたい場合はservice accountを使うようなのだけど、これで生成したアクセストークンを使ってもパーミッションがないと言われるのである。同じことをしている記事も見つからないしなー。

うんうん悩んでいたところ救世主が降臨。ようするにservice accountを使うのが間違いで、普通にWeb server applicationsのアカウントを作って、いったんブラウザで対話式に認証を済ましてから、そこで得られたrefresh tokenを使ってアクセストークンを得る、という流れ。ちょっと複雑になったが、ようするにOAuth1.0と同じようなステップを踏むのが正解ということか。やれやれ。

refresh token取得の流れはgoogleapi - Google API OAuth2.0のアクセストークン&リフレッシュトークン取得手順メモ - Qiitaが参考になる。Picasaの場合はこんな感じ:

1. 以下にブラウザからアクセス:(redirect urlは実在しなくても良い)

   https://accounts.google.com/o/oauth2/auth?client_id=【client id】&redirect_uri=【redirect url】&scope=https://picasaweb.google.com/data/&response_type=code&approval_prompt=force&access_type=offline

2. ブラウザに表示された最終的なURLのうち、「code=」以下の部分をコピペしておく
3. 以下のURLに対して:

   https://accounts.google.com/o/oauth2/token

   下記のデータをPOSTする。先のリンク先ではcurlを使う例がある:

   client_id=【client id】&client_secret=【client secret】&redirect_uri=【redirect url】&grant_type=authorization_code&code=【上で取得したcode】

4. 返ってきたjsonに「refresh_token」がある

という感じで、なんとかPicasaへのアクセスを取り戻した。問題は、これがPhotosへのつなぎとして短命に終わるのか、終わるとすればいつか、来るべきPhotosのAPIで同等のことができるかだよなぁ。なにせいまですらGoogleのAPI一覧に名前がないんだから……。

■ PuppetからAnsibleへ

(といっても「乗り換えノウハウ」みたいな有用な情報はない)

開発環境をさくっと作るために用意していたPuppet manifestsが、Debian Jessieのインストール時に動かなくて、読み返しても何やってるのか理解できない(笑)。やっぱりPuppetのDSLはメンテナンス性低いなぁと思い、かねてからAnsibleへの乗り換えを画策していたので実行することにした。AnsibleならWindows対応もあるので仕事でも有用だろう。

最初に(タイトルに惹かれて)「Ansibleを使い出す前に押さえておきたかったディレクトリ構成のベストプラクティス - 双六工場日誌」を読んだのは間違いで、ディレクトリ構成を考えるのはチュートリアルくらい済ましてからね。というか、これを読むとAnsibleにも暗部というか歪みがけっこうあって、Ansibleならきれいに書けてメンテナンス性が高いなんて思い込みは早くも崩れる。あと「Ansible チュートリアル | Ansible Tutorial in Japanese」はメンテされてないのでざっと参考にするくらい。

けっきょく公式ドキュメントがちゃんとしていて良いという各所にあるアドバイスのとおりだった。英語だけど。ドキュメントがしっかりしているのはPythonカルチャーかな。だいたい書き方がわかったら「All Modules — Ansible Documentation」をリファレンスしながら自分のPlaybooksを書けばよい。基本的にshellモジュールでざっくり手順を書いてから、冪等性を確保するように手を入れるというのがスムーズで良さそう。

こんへんで「role」はいわゆるホストの役割というよりはパッケージ単位に分割すべきだわかってきて、冒頭にあったような標準的なディレクトリ構成を作りはじめるんだけど、ベストプラクティスとされる構造はかなり大規模で複数人でメンテするような場合が対象なので、個人で使うにはオーバースペックだ。変数だってhostsファイルかトップレベルのPlaybookに書いちゃえばいい。というわけで、各ロールの下にはtasksとhandles、filesがある程度に。

あと、変数が定義されてることを前提に書かれているtaskが、変数定義がない場合に失敗するようにしたいなぁと思ってやり方を探すも、なんだかスマートな手法が見つからず悩んでいたら、error_on_undefined_varsという変数をTrueにしておくと勝手にチェックしてくれると教えてもらう。試してみたらちゃんと失敗してくれるのでこれでいいやと安心していたら、そもそもerror_on_undefined_varsはデフォルトでTrueだとわかってずっこけた。つまり最初に失敗するテストを書けってことですよ、とほほ。