.bash_profile を source してくるやり方を試してみたところ、gem が入らなくなりました。
==> default: Error: Could not find command 'bundle'
==> default: Error: /Stage[main]/Main/Exec[install gem]/returns: change from notrun to 0 failed: Could not find command 'bundle'
==> default: Info: Creating state file /var/lib/puppet/state/state.yaml今回logが少ない。。
capybaraのバージョンについてのお知らせ？ でもこれは特にbundle install 失敗には繋がらないみたい。
It was installed into ./vendor/bundle
Post-install message from capybara:
IMPORTANT! Some of the defaults have changed in Capybara 2.1. If you're experiencing failures,
please revert to the old behaviour by setting:
Capybara.configure do |config|
config.match = :one
config.exact_options = true
config.ignore_hidden_elements = true
config.visible_text_only = true
end
If you're migrating from Capybara 1.x, try:
Capybara.configure do |config|
config.match = :prefer_exact
config.ignore_hidden_elements = false
end
Details here: http://www.elabs.se/blog/60-introducing-capybara-2-1
Post-install message from rdoc:
Depending on your version of ruby, you may need to install ruby rdoc/ri data:
<= 1.8.6 : unsupported
= 1.8.7 : gem install rdoc-data; rdoc-data --install
= 1.9.1 : gem install rdoc-data; rdoc-data --install
>= 1.9.2 : nothing to do! Yay!- .bash_profileの中に記述されていた rbenv init - が実行されていないことにより
bundleについてpathが通っていなかったことが原因でした。 - .bash_profileの中身を一つ一つ実際に叩いて、env のpathを確認することで、中でどんなことをやっているのかが分かりました。
Could not find command系のエラーは大体pathが通っていないので、which や env で path を確かめると良いぞ！
$ which bundle
~/.rbenv/shims/bundle- 解決策としては、この .rbenv/shims の path をデフォルト値に追加してあげることにしました。
path に .rbenv/shims をを追加すると、今度はgem install bundler ができなくなりました！
==> default: Notice: /Stage[main]/Main/Exec[install bundler]/returns: ERROR: While executing gem ... (Gem::FilePermissionError)
==> default: Notice: /Stage[main]/Main/Exec[install bundler]/returns: You don't have write permissions into the /usr/lib/ruby/gems/1.8 directory.
==> default: Error: gem install bundler returned 1 instead of one of [0]
==> default: Error: /Stage[main]/Main/Exec[install bundler]/returns: change from notrun to 0 failed: gem install bundler returned 1 instead of one of [0]
==> default: Notice: /Stage[main]/Main/Exec[install gem]: Dependency Exec[install bundler] has failures: true
==> default: Warning: /Stage[main]/Main/Exec[install gem]: Skipping because of failed dependencies
==> default: Info: Creating state file /var/lib/puppet/state/state.yamlどうやら、/usr/lib/ruby/gems/1.8 のディレクトリの permission が通らないらしい。。
そのディレクトリにいってみると、確かにpermissionがrootになってました。
でもなんでここにあるgemをみているのでしょう。。。
このディレクトリのgemの中には、edit_json.rb prettify_json.rbが入っていました。
ううむ。
which gem をしてみると以下のような感じ。。
$ which gem
~/.rbenv/shims/gemむむ？このpathはさっき通したばかり。pathは良さそう。 問題は、なぜ usr/lib/ruby/gem/1.8 のディレクトリなんてみているかのかということ。
pathの優先順位は先頭から順に低くなっていく。にも関わらず、gemやbundleのpathをシステム系のものよりも後に書いていたため、システム系のgemのpathを優先させてしまったことが原因。 そのため、今まで引っ掛かったことのないpermissionエラーになってしまったようです。
sshでvm上にログインした後にenvで表示されるpathは、優先順位が環境構築する上で最適なものになっていたので、ここは問題ないと決めつけていました。もともとこのpathは、.bash_profile を source してできたpathであって、今回のリソースとは無関係なのでした。puppetってそういうものだった。
sshでログインした後のenv
PATH=/home/vagrant/.rbenv/shims:/home/vagrant/.rbenv/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/sbin:/usr/sbin:/home/vagrant/bin解決策としては、pathを最適な順番に並び替えること。
テスト通りました！おk！
notify も require も依存関係をつくるけど、どうちがうのだろう？ と思って調べてみたら、require はインストールを基準にした依存関係作る君だということが分かった。
- a subscribe b
- AはBが書き換わったら更新する
- b notify a
- Bが書き換わったらAを更新する
- B require A
- AのインストールにはBが必要
出典：http://takuya-1st.hatenablog.jp/entry/20120125/1327467007
入門puppetには、notify と subscribe は結果はどちらも同じなので、分かりやすい方を使うといいよと書いてあるのですが、今回はどっちの方が分かりやすいのだろう。。
==> default: Error: Could not start Service[restart iptables]: Execution of '/sbin/service restart iptables start' returned 1: restart iptables: unrecognized service
==> default: Wrapped exception:
==> default: Execution of '/sbin/service restart iptables start' returned 1: restart iptables: unrecognized service
==> default: Error: /Stage[main]/Main/Service[restart iptables]/ensure: change from stopped to running failed: Could not start Service[restart iptables]: Execution of '/sbin/service restart iptables start' returned 1: restart iptables: unrecognized serviceservice リソースでは、リソースタイプの名前？の部分を、指定したいサービス名にしなくてはいけないのでした。
service { 'restart iptables': からservice { 'iptables':に変更したところ、エラーが消えました。
レビューの取り込みが一通りできました。この内容でマージしてもよろしいでしょうか？