AR ホームベーカリー

オイラのアウトプット用ホームベーカリー!

Vagrant up で予期せぬ box が起動に使われる

再現性は不明。

ロケ地:自分のMacbookPro@OSX El Capitan

vagrant up すると知らない環境が立ち上がる

vagrant up したら、前日まで利用していた環境が起動しない。 起動時のログを確認した所、vagrant box add したときに指定した box から、新しい VM 環境を作成している模様。

User-MacBook-Pro:rvm_vagrant user$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Importing base box 'rvm_vagrant'...

なんか Importing とか出てるんですけお! ちなみにこの様になるまえは、起動するとこのようなログが出ていた。

User-MacBook-Pro:rvm_vagrant user$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...

明らかにおかしい。

調べたら同様の症状の人は居た

elm-arata.hatenablog.com

ははぁん、なるほど。

VM の UUID を調べる

User-MacBook-Pro: $ VBoxManage list vms
"rvm_vagrant_default_1145141919893_46157" {0a5f536c-1fd5-40d5-8f7f-8c62749a9e11} <=こっちを使いたい
"centos6_mysql55_default_1145141919810_91735" {215b5e22-dffa-468f-bfee-83865f23d1c5}

UUID を修正する

本来利用したい「rvm_vagrant_default_1145141919893_46157」の UUID とは別の UUID が書き込まれているのを確認したので、書き換えてみる。

User-MacBook-Pro:vi /PATH/TO/.vagrant/machines/default/virtualbox/id
#=> 0a5f536c-1fd5-40d5-8f7f-8c62749a9e11 に書き換える

起動してみる

User-MacBook-Pro: $ vagrnt up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
...

おっやったz

default: Warning: Authentication failure. Retrying...

デデドン!

default: Warning: Authentication failure. Retrying...

とりあえず vagrant の UUID はちゃんとつけ変わったようなので、このエラーの対処をする。

qiita.com

鍵が異なっているらしい。 VM と紐付けが変わった時になんかあったのかもしれん。原因は不明。 とりあえず鍵を作成しなおす。

User-MacBook-Pro: $ cd /PATH/TO/VAGRANTFILE
User-MacBook-Pro: $ vagrant ssh-config
...
  IdentityFile /Users/hoge/key
...

IdentityFile に記載された鍵を使って ssh-keygen する。

User-MacBook-Pro: $ ssh-keygen -yf /Users/hoge/private_key > ./publickey

これをどうにかして、先程 UUID を書き換えた対象の VM へ持っていき、authorized_keys に書き込む。

今回は、VirtualBoxGUI から起動して、CLI を起動した所、ホストの Macbookpro の IP が見えたので、 MacOSX 側の SSH を許可して、SCP で取得させたのち、authorized_keys にリネームした。 (クリップボード共有が動かなかったのでこのような手段をとったが、クリップボード共有できている場合はコピペすればいい。)

編集終わったら、一応 sudo halt とかして一度 VM を止めておくといい。

※なんかこいう事もあるらしい

qiita.com

vagrant up

ここまでやったので、改めて vagrant up する。

User-MacBook-Pro: $ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Clearing any previously set forwarded ports...
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
...
==> default: Machine already provisioned. Run `vagrant provision` or use the `--provision`
==> default: flag to force provisioning. Provisioners marked to run always will still run.

やったーなおった! このあと、vagrant ssh も無事疎通を確認できた。

わかったこと

カジュアルに紐付けが壊れるらしいので、壊れたらカジュアルに修正すること。 実は今回この現象に初めて遭遇したけど「本番デプロイするかー」とおもって vagrant up したら遭遇したので、めっちゃびっくりした。

too long unix socket path

ロケ地:AWS EC2 CentOS7.2@m3.medium

passenger-status が使えない

passenger-status を呼ぶと以下のように怒られる。

ERROR: Phusion Passenger doesn't seem to be running. If you are sure that it is running, then the causes of this problem could be:

1. You customized the instance registry directory using Apache's PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir option, or Phusion Passenger Standalone's --instance-registry-dir command line argument. If so, please set the environment variable PASSENGER_INSTANCE_REGISTRY_DIR to that directory and run passenger-status again.
2. The instance directory has been removed by an operating system background service. Please set a different instance registry directory using Apache's PassengerInstanceRegistryDir option, Nginx's passenger_instance_registry_dir option, or Phusion Passenger Standalone's --instance-registry-dir command line argument.

なんか前にも調べた気がするけど以下の通りらしい。

www.pistolfly.com

[root@ip-11-4-51-4 ~]# ls -la /tmp/
..
drwx------   3 root   root      16 Nov  7 14:40 systemd-private-aaaabbbbccccddddeeeeffffgggghhhh-httpd.service-5v2rlt
..

ありました。めんどくさいので今回はコマンドに「PASSENGER_INSTANCE_REGISTRY_DIR」を指定しましょう!

[root@ip-11-4-51-4 ~]# PASSENGER_INSTANCE_REGISTRY_DIR=/tmp/systemd-private-aaaabbbbccccddddeeeeffffgggghhhh-httpd.service-5v2rlt/tmp/ passenger-status
Version : 5.0.30
Date    : 2016-11-07 20:06:10 +0900
Instance: 114514 (Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.5.34 Phusion_Passenger/5.0.30)

/usr/local/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/src/ruby_supportlib/phusion_passenger/admin_tools/instance.rb:94:in `initialize': too long unix socket path (115bytes given but 108bytes max) (ArgumentError)
    from /usr/local/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/src/ruby_supportlib/phusion_passenger/admin_tools/instance.rb:94:in `new'
    from /usr/local/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/src/ruby_supportlib/phusion_passenger/admin_tools/instance.rb:94:in `http_request'
    from /usr/local/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/bin/passenger-status:113:in `show_status'
    from /usr/local/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/bin/passenger-status:61:in `command_show_status'
    from /usr/local/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/bin/passenger-status:332:in `start'
    from /usr/local/lib/ruby/gems/2.3.0/gems/passenger-5.0.30/bin/passenger-status:335:in `<top (required)>'
    from /usr/local/bin/passenger-status:23:in `load'
    from /usr/local/bin/passenger-status:23:in `<main>'

too long unix socket path

という訳でタイトルになります。「PASSENGER_INSTANCE_REGISTRY_DIR」で指定されているディレクトリ名が流すぎるのが原因のようです。 試しにシンボリックリンクを設定してみましょう!

シンボリックリンクを作成する

[root@ip-11-4-51-4 ~]# cd /tmp/
[root@ip-11-4-51-4 ~]# ln -s /tmp/systemd-private-aaaabbbbccccddddeeeeffffgggghhhh-httpd.service-5v2rlt/tmp/ test_path

passenger-status を再度実行してみる

[root@ip-11-4-51-4 ~]# PASSENGER_INSTANCE_REGISTRY_DIR=/tmp/test_path/ passenger-status
Version : 5.0.30
Date    : 2016-11-07 20:06:10 +0900
Instance: 114514 (Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips PHP/5.5.34 Phusion_Passenger/5.0.30)

----------- General information -----------
Max pool size : 6
App groups    : 1
Processes     : 1
Requests in top-level queue : 0

----------- Application groups -----------
/var/www/test_app (production):
  App root: /var/www/test_app
  Requests in queue: 0
  * PID: 21062   Sessions: 0       Processed: 7       Uptime: 33m 31s
    CPU: 0%      Memory  : 68M     Last used: 3m 1s ago

出ましたね! これで、「PASSENGER_INSTANCE_REGISTRY_DIR=/tmp/test_path/」を指定していれば、passenger-config restart-app なども実行できます。

Go のインストール

Go なのか Golang なんかどっちなんね。

ロケ地:EC2 t2.micro ( CentOS7 )

インストール

ダウンロード

# cd /usr/local/src
# wget https://storage.googleapis.com/golang/go1.7.3.linux-amd64.tar.gz

展開

# tar -xzvf go1.7.3.linux-amd64.tar.gz
# mv ./go/ /usr/local/bin/

環境変数の登録

# mkdir ~/.go/
# vi ~/.bash_profile

環境に併せて書き換えてください。 今回 $GOPATH ( go get とかするとインストールされる先)は ~/.go/ としています。

GOPATH=$HOME/.go
GOROOT=/usr/local/bin/go
PATH=$PATH:$HOME/bin:$GOPATH/bin:$GOROOT/bin

export GOPATH
export GOROOT
export PAATH

環境変数の反映

# source
# go version
go version go1.7.3 linux/amd64

ちゃーんと go version〜〜 が出力されたらオッケーです! warning も出てないので、go get も使えるはずです!

gox インストール

せっかくなので、gox をインストールしてみます。

インストール

# go get github.com/mitchellh/gox
# which gox
/root/.go/bin/gox

わぁぃ。

AWS CLI でルートテーブルのつけかえ

c9katayama.hatenablog.com

おっできるんか!と思ってまず aws コマンドから、ルーティングの変更を試すことに。

削除

aws ec2 delete-route --route-table-id ルートテーブルID --destination-cidr-block 送信先
  • ルートテーブル ID
    • VPC ダッシュボードから確認出来るルートテーブルの ID
  • 送信先
    • IP/CIDR 形式、ルートテーブルを選択したあと、「ルート」タブから確認する

http://docs.aws.amazon.com/cli/latest/reference/ec2/delete-route.html

追加

aws ec2 create-route --route-table-id ルートテーブルID --destination-cidr-block 送信先 --network-interface-id ターゲット
  • ルートテーブル ID
    • VPC ダッシュボードから確認出来るルートテーブルの ID
  • 送信先
    • IP/CIDR 形式、ルートテーブルを選択したあと、「ルート」タブから確認する
  • ターゲット
    • eni- から始まる Elastic Network Interface
    • --gateway-id や --instance-id を指定するとそれらを対象にできるようですね

http://docs.aws.amazon.com/cli/latest/reference/ec2/create-route.html

なんで

なんで削除も return 返してくれないのか。

CPAN のダウンロード先が国外を向いてる

めっちゃダウンロード遅くてなにこれ、と思ってよくみたら「.au」とかいうドメインだった。オーストラリアやんけ!

国内なら公式のミラーリストにある「http://ftp.nara.wide.ad.jp/pub/CPAN/」を登録しておけばいいと思います!

登録されているミラー一覧

CPAN[1]> o conf urllist 

一覧から削除

CPAN[1]> o conf urllist pop URL

一覧に追加

CPAN[1]> o conf urllist push URL

作業内容を反映する

CPAN[1]> o conf commit

マルチバイトのダミーデータを作る

ダウンロードする。

なんちゃって個人情報

CSV → INSERT文に変換する。

CSV→INSERT文変換

適当な RDBMS で食べる。

UTF8 の設定忘れてて読み込めない(ここまでワンセット)。

AWSで新たなVPCを作る時

めっちゃ忘れまくってたのでメモ。

プライベートIPアドレスの帯域

  • クラスA
  • 10.0.0.0~10.255.255.255 ( 10.0.0.0/8 )
  • クラスB
  • 172.16.0.0~172.31.255.255 ( 172.16.0.0/12 )
  • クラスC
  • 192.168.0.0~192.168.255.255 ( 192.168.0.0/16 )

VPN を乗り入れたりしない場合は、特に深く考える必要はない。 が、後々そういうことが微粒子レベルでも存在してるならクラスCはなるべく使わないほうがいい、事故りやすい。

VPC ・サブネットの作成

適当に作ってもおk、名前はわかるようにしておこう。 VPC の CIDR ブロックを /23 にしておくとサブネット作成時にわかりやすい。

作成例

CIDR ブロックは 10.1.0.0/23

ap-northeast-1a

  • 10.1.0.0/24
  • サブネット名:ほんにゃかふんにゃか-1a

ap-northeast-1c

  • 10.1.1.0/24
  • サブネット名:ほげふが-1c

もちろんもっと IP アサインしたい環境の場合は増やしていい。 テナンシーは普通は専有しなくておk。

インターネットゲートウェイ・ルートテーブル作成

VPC とサブネット作ったままだと、EC2 インスタンス作成時に割当は出来るけど、ルートがなくてインターネット経由で接続できない。 インターネットゲートウェイを適当な名前で作成して、ルートテーブルの「ルート」タブから 0.0.0.0/0 を割り当てる。 デフォルトの VPC と見比べると良いと思います。

ここまでの作業だと、EC2 インスタンスにパブリック DNS が付与されない

VPC 作成後に「DNS ホスト名:いいえ」のままインスタンスを作成すると付与されない模様。 DNS ホスト名を「はい」に変更すれば利用できるようになるらしい。 どうせなので ElasticIP を割り当ててしまったほうが良いと思っている。