見た。見た!!!!!!!
パンフレットは買い忘れてしまったのでまた買いに行く。というかもう一回見に行く。小説版はすばやく Kindle で買って読みました(スピンオフの方も)。
ネタバレを含む感想を書く場所が社内チャットの #kiminona チャンネルくらいしかなくてそこに書いていたのだけど、どうせならオープンインターネットに書き散らしておく。ということでネタバレを気にせずに書きます。嫌な人はブラウザ閉じてください。
続きを読む過去記事とかは記事一覧で見れます
Vagrant 1.8.6 で無事直っていたようだった。
ちょっと遊びに、と思って手元に Vagrant を新しくセットアップして bento/centos6.7 の box をセットアップしたところ、vagrant up
がAuthentication failure で止まってしまう症状に遭遇した。
この環境は特にプロビジョニングがなかったのだけど、もしかしたらこの後後続のvagrant provision
が動かないというパターンもありえそう。
==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key default: default: Vagrant insecure key detected. Vagrant will automatically replace default: this with a newly generated keypair for better security. default: default: Inserting generated public key within guest... default: Removing insecure key from the guest if it's present... default: Key inserted! Disconnecting and reconnecting using new SSH key... default: Warning: Authentication failure. Retrying... default: Warning: Authentication failure. Retrying... default: Warning: Authentication failure. Retrying... ... default: Warning: Authentication failure. Retrying... Timed out while waiting for the machine to boot. This means that Vagrant was unable to communicate with the guest machine within the configured ("config.vm.boot_timeout" value) time period. If you look above, you should be able to see the error(s) that Vagrant had when attempting to connect to the machine. These errors are usually good hints as to what may be wrong. If you're using a custom box, make sure that networking is properly working and you're able to connect to the machine. It is a common problem that networking isn't setup properly in these boxes. Verify that authentication configurations are also setup properly, as well. If the box appears to be booting properly, you may want to increase the timeout ("config.vm.boot_timeout") value.
この状態で vagrant ssh
するとパスワード認証(vagrant/vagrant)で入れる。なんだろうなと思って検索したところ、 Vagrant 1.8.5 のバグのようだった。
確かめてないけど、デフォルトの umask
に依存するので RedHat 系では発生するが Debian 系では発生しない、とも書いてある。
I believe the difference between the linux distros is the default value of umask. Debian has 0022, resulting in 0644 on authorized_keys, which is acceptable to ssh, but RedHat has 0002, resulting in 0664, causing ssh to refuse to honor the authorized_keys file.
https://github.com/mitchellh/vagrant/issues/7610#issuecomment-233807963
よくみると上のログにも出ているのだけれど、最近の vagrant (1.7 以降?) は insecure な ssh 鍵を見つけると差し替えるという格好いいことをしてくれる。
なのだけど、この時に ~/ssh/authorized_keys のパーミッションがおかしくなってしまうことがあり、その場合にこのようなエラーが出るとのことだった。
上の qiita のエントリにあったようにこの差し替え機能自体を Vagrantfile で無効にする、という選択肢もあるけど:
config.ssh.insert_key = false
既に途中まで作られてしまった vm の状態を直したい場合は、ssh で入って permission を直せば良い。
$ vagrant ssh [vagrant@localhost ~]$ cd .ssh [vagrant@localhost .ssh]$ ls -la 合計 12 drwx------. 2 vagrant root 4096 9月 14 15:15 2016 . drwx------. 3 vagrant vagrant 4096 9月 14 15:22 2016 .. -rw-rw-r--. 1 vagrant vagrant 389 9月 14 15:15 2016 authorized_keys [vagrant@localhost .ssh]$ chmod 600 authorized_keys [vagrant@localhost .ssh]$ exit
これで vagrant reload
すると今度はきちんと完走するようになるし、vagrant ssh
が公開鍵認証(=パスワード入力なし)で入れるようになる。最初の公開鍵書き換えで公開鍵の中身は secure になっているので、この後さらに vagrant reload
しても再度 permission がおかしくなることはなさそう。
issue によると 1.8.6 では直るとのことなので、それまでは辛抱という感じですね。
シンデレラ4thライブが始まったということで、まずは9/3と9/4にあった神戸公演に行ってきた。神戸の2公演がスターライトステージ(デレステ)メインの Starlight Castle 、SSA の1日目がニューフェース中心の Brand new Castle 、そして2日目がアニメの中心メンバーによる 346 Castle 、ということで、そのデレステメインの Starlight Castle の回。ちょうど公演初日の 9/3 がデレステ1周年だったということもあってデレステのアニバーサリーライブ的な様相もあった二日間、デレステフィーチャーならではの演出や選曲で大変たのしいライブだった。サプライズゲストもとても良かった。
……という話をつらつらと書いていく。2日間で共通した話題が多いので長くなるのを覚悟でえいやっと1記事にまとめることにする。
個人的な感想を好き勝手に書くので、ライブについてちゃんと知りたい人はマイナビニュースなどのリポート記事を読むとよいかと思います:
news.mynavi.jp
結構間が空いてしまったけれど、イベントの振り返りと言うことで載せる。
7/30にあったシンデレラガールズのリリースイベントに行ってきた。正式なイベントのタイトルは「アイドルマスター シンデレラガールズ コロムビアCD&映像作品累計出荷300万枚突破 &THE IDOLM@STER CINDERELLA GIRLS STARLIGHT MASTERシリーズ発売記念イベント」だったのだけど、流石に長すぎてタイトル収まらなかった。。。