無気力生活 (ノ ´ω｀)ノ ~゜

脱力系エンジニア。てきとーに生きてます。

Vagrant1.9.4で発生するエラーとその解消法

vagrant

結論

vagrant plugin install vagrant-share --plugin-version 1.1.8実行してgem更新してやればOK

vagrant --help displays a rubygems error · Issue #8519 · mitchellh/vagrant · GitHub

背景

いま時点の最新版である1.9.4に更新した際に、vagrantを実行するとこんなエラーが発生します。

なお、環境はWindows10Proの10.0.15063ですが、ubuntuやmacosでも発生している報告があるのでおそらく全環境で発生する模様。

HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require': cannot load such file -- vagrant-share/helper/api (LoadError)
        from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-share-1.1.7/lib/vagrant-share/activate.rb:244:in `<encoded>'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-share-1.1.7/lib/vagrant-share/activate.rb:16:in `RGLoader_load'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-share-1.1.7/lib/vagrant-share/activate.rb:16:in `<top (required)>'
        from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/rubygems/core_ext/kernel_require.rb:54:in `require'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-share-1.1.7/lib/vagrant-share.rb:23:in `block in <class:Plugin>'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/cli.rb:75:in `call'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/cli.rb:75:in `block (2 levels) in help'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/registry.rb:49:in `block in each'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/registry.rb:48:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/registry.rb:48:in `each'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/cli.rb:69:in `block in help'
        from C:/HashiCorp/Vagrant/embedded/lib/ruby/2.2.0/optparse.rb:917:in `initialize'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/cli.rb:57:in `new'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/cli.rb:57:in `help'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/cli.rb:32:in `execute'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/lib/vagrant/environment.rb:308:in `cli'
        from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-1.9.4/bin/vagrant:127:in `<main>']

ここで気になるポイントはここ

from C:/HashiCorp/Vagrant/embedded/gems/gems/vagrant-share-1.1.7/lib/vagrant-share/activate.rb:244:in `<encoded>'

問題が発生している1.9.4の差分見た限り、特にこの辺に影響ありそうな修正はなさそうでした。

https://github.com/mitchellh/vagrant/compare/v1.9.3…v1.9.4

となるとgemが悪さしているっぽそうですね。対応方法から察するに、1.9.4が参照すべきgem指定が更新されないままリリースされた匂いがします。

このvagrant-shareのgemは公開されていません。hashicorpのサイトのみでホスティングされているようです。

# curl https://gems.hashicorp.com/
<!DOCTYPE HTML>
<html lang="en-US">
    <head>
        <meta charset="UTF-8">
        <meta http-equiv="refresh" content="0; url=https://www.hashicorp.com">
        <script type="text/javascript">
            window.location.href = "https://www.hashicorp.com"
        </script>
        <title>HashiCorp</title>
    </head>
    <body>
        If you are not redirected automatically, follow this <a href="https://www.hashicorp.com">link</a>.
    </body>
</html>

なので詳細はわからず(´・ω・`)

minecraft1.7.10用のIC2 classicは2種類ある。安定している方と安定していない方だ

minecraft

GCPで動かし始めたMinecraftサーバー。IC2 classicを導入して遊んでいたんですが、時折クラッシュすることがありました

// Would you like a cupcake?

Time: 4/22/17 7:16 AM
Description: Ticking block entity

java.lang.IllegalArgumentException: Energy source ic2classic.core.block.wiring.TileEntityElectricBatBox@28fa649b is not added to the enet.
        at ic2classic.core.EnergyNet.emitEnergyFrom(EnergyNet.java:140)
        at ic2classic.core.EnergyNet$EventHandler.onEnergyTileSource(EnergyNet.java:553)
        at cpw.mods.fml.common.eventhandler.ASMEventHandler_30_EventHandler_onEnergyTileSource_EnergyTileSourceEvent.invoke(.dynamic)
        at cpw.mods.fml.common.eventhandler.ASMEventHandler.invoke(ASMEventHandler.java:54)
        at cpw.mods.fml.common.eventhandler.EventBus.post(EventBus.java:140)
        at ic2classic.core.block.wiring.TileEntityElectricBlock.func_145845_h(TileEntityElectricBlock.java:139)
        at net.minecraft.world.World.func_72939_s(World.java:1939)
        at net.minecraft.world.WorldServer.func_72939_s(WorldServer.java:489)
        at net.minecraft.server.MinecraftServer.func_71190_q(MinecraftServer.java:636)
        at net.minecraft.server.dedicated.DedicatedServer.func_71190_q(DedicatedServer.java:334)
        at net.minecraft.server.MinecraftServer.func_71217_p(MinecraftServer.java:547)
        at net.minecraft.server.MinecraftServer.run(MinecraftServer.java:427)
        at net.minecraft.server.MinecraftServer$2.run(MinecraftServer.java:685)

色々調べてみたところ、Eneregy関連のロジックに問題があるらしく、Batboxといった電力をプールする系のブロックの電力が空になると発生する模様。遠出して拠点に戻る際、Batboxがあるところに近づくと確実に発生するので、チャンクロードのタイミングで発生しているっぽい。

この現象が発生した後、インする度にサーバーが即死するという困った状況に見舞われるわけです(´・ω・`)

結論としては、1.7.10に対応したIC2 classicは2種類あり、今回問題が発生したimmbis版ではなく、もう一つのSpeiger版を使うことで回避できました。

ただし入れ替えすると、ワールドに設置していたimmbis版のマシンはごそっと消滅します。 機能的にはほぼ同一ですがMod自体が異なるので、まーしょーがないですね。

fiddlerでiosの通信を解析するためにやったこと

雑記

単純にプロキシ機能使っただけです、はい。

最近のMacbook Proの迷走に付き合いきれず、最近Windowsに戻りました。 Macのときはcharlesで通信見てたんですが、Windowsでどうやるんじゃい？ということで昔Fiddlerを使っていたことを思い出したわけです。

手持ちのIOSの通信を覗き見するためにやったことが以下になります。

手順

  1. Fiddlerのダウンロード
  2. [tool]-[telerik fiddler options]-[connections]-{Allow remote computers to connect}=ONでPC外からのリクエストを受け付けるようにする
  3. HTTPSの通信を取りたい場合、このままだと中身の解析ができないので、CAの認証をする。[tool]-[telerik fiddler options]-[HTTPS]の設定を変更
  4. {Capture HTTPS CONNECTS}=ON
  5. {Decrypt HTTPS traffic}=ON
    通知出るがNOで問題なし。この設定をすることでIOS側にCA証明書の導入が可能になる。
  6. IOSで、プロキシ設定を有効にする。 デフォルトだと、{host:8888}に設定すればOK
  7. 設定したら、safariを開き、” http://ipv4.fiddler:8888 ”へアクセスすると、PC側のFiddlerからCA証明書を取得できるので、それをインストールする

参考資料

http://qiita.com/rch850/items/6d550d01d4c76c692d89

embulkでBigqueryにテキストデータ流し込めなかった話

雑記

ユーザーメッセージを分析するようにBigqueryに流し込んでたんですが、とある日Slackに失敗通知が飛んでいることに気づく

Error: org.jruby.exceptions.RaiseException: (Error) failed during waiting a Load job, get_job(to_aru_server, embulk_load_job_000f1d44
-0935-4cf7-84a9-e00aac16995e), errors:[{:reason=>"invalid", :message=>"Too many errors encountered."}, {:reason=>"invalid", :message=>"CSV
table references column position 2, but line starting at position:147 contains only 2 columns.", :location=>"file-00000000"}]
2017-03-09 06:00:38 +0900 [ERROR] (0017@+fetch_table+fetch_yesterday^sub+for-table=messages) io.digdag.core.agent.OperatorManager: Task failed with unexpected error: Command failed with code 1
java.lang.RuntimeException: Command failed with code 1

なんぞこれ。設定周りに不備があると思って色々調べたんですが、原因が特定できず。 弊社のBigquery師範から、流し込んでるデータに問題あるんじゃないかの指摘を受け、調べてみたら改行を含んだユーザーコメントがいるわけでして(ヽ´ω`)

改行を含んだカラムを扱うときは、--allow-quoted-newlinesが必要とのことなので、liquidにオプション追加すると解消できました

in:
{% include 'common_in' %}
  query: |
    SELECT
      id,
      text,
      created_at
    FROM messages
    WHERE id > 1 
      AND created_at >= "{{ env.TARGET_DATE }}"
      AND created_at < DATE_ADD("{{ env.TARGET_DATE }}", INTERVAL 1 DAY)
out:
{% include 'common_out' %}
  table: messages{{ env.TARGET_DATE | date: "%Y%m%d" }}
  schema_file: embulk/messages.json
  path_prefix: /tmp/messages
  allow_quoted_newlines: 1 # <--------これ
  formatter:
    type: csv
    charset: UTF-8
    delimiter: ','
    header_line: false
    column_options:
      created_at: { format: "%Y-%m-%d %H:%M:%S" }

munin-node再起動して正常に動作するまで少し時間かかるらしい

雑記

利用しているIaaSからFailoverをくらい、そのままサービスは動作していたので放置していたんですが、ふとmuninを見ると該当サーバーがモニタできていないことに気づく。

おそらくchkconfigされなかった系だと思われますが、munin-nodeのプロセスがお亡くなりになっていたので、おもむろに service munin-node startするわけですよ。

…5分間隔でモニタしているんだが、一向に描画されねぇ(ヽ´ω`)

とか思ってたら10分くらいしてからモニタされ始めました。 少し時間かかるみたいですね。

provisiningのテスト環境を作ってる

Ruby Itamae

最近、借りてるVPSのスペック変えたんですよ。 ただ、変える課程でサーバー環境まるっと消されたんですよ。

これまで手作業でサーバー構築してたんですが、さすがにつどやるのが面倒になってきたのでコード化したい。 そのへん困ったこと出てきたら、まとめるシリーズになります。

ちなみにこんなものを使おうとしてます

今日書くのはitamaeが動かない問題について
使ってるrubyバージョンは2.3
ruby 2.3.0p0 (2015-12-25 revision 53290) [x86_64-darwin14]

この状態でitamaeを使う最低限のGemfile作っていれます。

source "https://rubygems.org"$
gem "itamae"$

bundle installして、おもむろにitamae help
この時特にバージョン指定してないので、itamae-1.9.10がインストールされます。

# itamae help
/Users/shinoyu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/itamae-1.9.10/lib/itamae/cli.rb:15:in `initialize': undefined method `upcase' for nil:NilClass (NoMethodError)
    from /Users/shinoyu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor.rb:365:in `new'
    from /Users/shinoyu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor.rb:365:in `dispatch'
    from /Users/shinoyu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/thor-0.19.4/lib/thor/base.rb:444:in `start'
    from /Users/shinoyu/.rbenv/versions/2.3.0/lib/ruby/gems/2.3.0/gems/itamae-1.9.10/bin/itamae:4:in `<top (required)>'
    from /Users/shinoyu/.rbenv/versions/2.3.0/bin/itamae:23:in `load'
    from /Users/shinoyu/.rbenv/versions/2.3.0/bin/itamae:23:in `<main>'

おや…?

類似の報告ないか調べてたら、http://kawakubox.hatenablog.com/entry/2016/12/13/014011 にそのままのことが書かれてました。すごくタイムリー。
itamaeのこのバージョンが依存しているthorのバージョンが良くないらしく、これを0.19.1にすれば解決するとのこと。

Gemfileをこんな感じにして入れ直すと正常に実行いけました。

source "https://rubygems.org"
gem "thor", '0.19.1' #明示的にバージョン固定した版を先にいれとく
gem "itamae"
# itamae help
Commands:
  itamae destroy [cookbook|role] [NAME]   # Undo role or cookbook (short-cut alias: "d")
  ....

OKそう

Next.jsがおもしろそう

github.com

Reactアプリケーションをより簡単に作れるものらしい。 チュートリアルしか触ってないので全貌は量れないが、a small framework for server-rendered universal JavaScript webappsと謳われており、素のHTMLの記法でそのままReactアプリケーション作れるところが良さそう。

ぱっと見た限り、riot.jsに思想が近いと思った。

riotjs.com

試して数分でデフォルトポート変えたくなったので調べてみたら、

この辺らしい

https://github.com/zeit/next.js/blob/master/bin/next-start#L7-L16

$(npm bin)/next -p 3001
> Ready on http://localhost:3001

OKそう

いろいろなWebフロントフレームワークが出てきて、何を使えばいいか右往左往してます(´・ω・｀) mithril→riotと有力視していたけど、nextが一番素直に見える。 触ってみよう。