すごくわかりやすいし面白い。
などなど。デジタル署名あたりまで読み終えたけど、SSL/TLSはまだまだこれから。
素数をもとにしたRSAが解けるかどうかは素因数分解を高速に解けるかどうかにかかっていて、P≠NP問題が暗号につながるのはこれかーとか。楕円曲線暗号ってなんだろうなーとか。AESはオープンなコンペ方式で専門家が穴をつつきまくった結果負けなかったアルゴリズムであるとか。
やあ、楽しいですね。
$HOME/.guardrcもしくはGuardfileと同じディレクトリの.guardrcに次のように追記する。
Pry.commands.delete(/^$/)
全プラグインを実行するにはaやallを入力すればよい。
ポリシージェネレータをいじったり手でいじったりして、特定のタグを持つインスタンスの起動、停止ができるカスタムポリシーを作った。
// ※ 実際はJSONなのでコメントは記入できません { "Version": "2012-10-17", "Statement": [ // EC2のインスタンスに対する状態の取得を許可する // これも↓のAllowStopStartのように対象をタグで絞り込もうとしたら動いてくれなかったので、全サーバに対して許可した { "Sid": "AllowDescribe", "Effect": "Allow", "Action": [ "ec2:Describe*" ], "Resource": [ "*" ] }, // key=Foo,value=Barタグを持つインスタンスに対して起動と停止を許可する { "Sid": "AllowStopStart", "Effect": "Allow", "Action": [ "ec2:StartInstances", "ec2:StopInstances" ], "Condition": { "StringEquals": { "ec2:ResourceTag/Foo": "Bar" } }, "Resource": [ "arn:aws:ec2:*" ] } ] }
実際にはAllowStartStop部分だけでいいんだろうけど、decribe系のAPIも使いたかったのでAllowDescribeとして混ぜた。注釈でも触れているとおり、describe系の対象もタグで絞り込もうとしたら動かなかったので、全インスタンスを対象にした。ちなみにSidは自由に設定できる。
ポリシーは生成してからもあとから編集できるんだけど、反映されるまでに少し時間がかかった。それと、ポリシー名をあとから変えたらポリシー自体が設定していたユーザの画面から消えた…。
カスタムポリシーを使えばFull Accessのような過大な権限を与えた結果関係ない部分に対して誤操作をしてしまうこともないし、適切なポリシー名をつければそのユーザがグループの用途やできることがわかりやすくなる。
mirakui/ec2sshの2.x系ではHostの末尾がregionだったのに対して、3.x系ではAZに変わっていた。
# 2.x Host tag-name.ap-northeast-1 HostName ec2-54-NNN-NNN-NNN.ap-northeast-1.compute.amazonaws.com # 3.x Host tag-name.ap-northeast-1a HostName ec2-54-NNN-NNN-NNN.ap-northeast-1.compute.amazonaws.com
knife-soloのJSONファイルがこのHostと一致させる必要があったのでなかなか移行できずずっと見送っていたのだけれど、よく考えたら出力するときにAZ末尾のaやcを削ってしまえばいいことに気がついた。
というわけで3.x系での~/.ec2sshのhost_line部分を少し書き換えたところ、2.xと同じように出力されるようになった。
host_line <<EOS Host <%= tags['Name'] %>.<%= availability_zone %> HostName <%= dns_name || private_ip_address %> EOS
↓
host_line <<EOS Host <%= tags['Name'] %>.<%= availability_zone.sub(/[abc]$/, "") %> HostName <%= dns_name || private_ip_address %> EOS
めでたしめでたし。
以前Open3.popen3で外部コマンドの出力を随時受け取って表示するということをやったけど、それでは不便な場面が出てきた。
というのも、例えばgrepでマッチした部分を色付けしたものを得ようとしてもOpen3.popen3で受け取ることはできない。これはgrepが出力先がttyのときだけ色付けするようになっているのに対して、Open3.popen3のやりとりにttyが使われていないことが原因らしい。((出力先のIOがttyかどうかはrubyだとIO#tty?で調べられる。))
正直ttyってなんなのかわからないけど、とりあえずPTY.spawnを使うと擬似ttyをruby上に作ったうえで外部コマンドとやりとりできるとのことがわかったのでやってみた。
require "pty" PTY.spawn("long-long-command") do |r, w, pid| # rはコマンドの出力IO。標準出力と標準エラーの両方が同じところから出てくる # wはコマンドへの書き込みIO w.close_write r.sync = true begin r.each do |line| next if line.nil? || line.empty? puts line rescue Errno::EIO ensure ::Process.wait pid end end
ちなみにknife-soloでの変更点などの出力の色付けは出力先がttyでないと行われないんだけど、それを裏で叩いているpaknifeではOpen3.popen3を使っているため色付けされない。
なので色付けされた出力を得ようとPTY.spawnを使うようにしてみたんだけど、一部分だけが色づくだけで変更箇所などは色付けされないので、どこが原因かまだ探っているところだ。
--json-attributes <json>もしくは-j <json>オプションを使えばnodes/*.jsonを作らなくても走らせることができた。
$ knife solo cook myserver.01 -j '{"hostname":"myserver.01"}'
みたいな感じ。
さすがにJSONを長々と書くのは不便なので、基本となるロールをroles/*.rbに定義して、ノードごとに異なる値をJSONで渡す形式にしてやるとよさそう。
ロールは--override-runlist 'role[<role>]'もしくは-o 'role[<role>]'で指定できる。カンマ区切りで複数指定も可。
$ knife solo cook myserver.01 -o 'role[app]' -j '{"hostname":"myserver.01"}'
みたいな感じ。
