2019年7月27日（土）、大田区産業プラザPiOで開催された「技術書同人誌博覧会」（以降、「技書博」）に参加してきました。技書博を簡単にいうと、（少なくとも現時点では）技術書典の規模を小さくしたようなイベントです。
ただし、参加内容は、当日のボランティアスタッフ、としての参加です。
この手の活動は初めてだったので、簡単に振り返って記録しておきます。
続きを読む
nerves_bootstrap1.6.0ではElixir1.9を要求される
※本記事は、2019.07.15時点の情報で記述しています。
備忘。
「mix local.nerves」コマンドを実行してnerves_bootstrap のバージョンを上げてしまい、「mix nerves.new」コマンドが実施できなくなった。
バージョンアップしたnerves_bootstrapが利用できるElixirのバージョンにするか、現在のElixirで利用できるバージョンのnerves_bootstrapに戻す必要があります。今回は前者で対応しました。
続きを読むホストに対してコンテナからsnmpを投げても応答しなかった
気づくに小一時間かかったので、備忘の意味で記述。
概要
オチ：
「 /etc/hosts.allow 」にsnmpdのアクセス制限を設定していたため。
dockerに割り当てられていたIPアドレス（今回の場合、172.17.0.0/16）を「/etc/hosts.allow」に追記したら、あっさりと応答してくれた。
snmpd: 172.17.0.0/255.255.0.0
詳細
dockerコンテナ中にsnmpマネージャを構築。dockerコンテナのホストはCentOS7。
試しに、コンテナのホストに対してsnmpwalkコマンドでsnmpを投げてみるも、応答が戻って来ずにTimeoutが発生。
なお、「172.17.0.1」がコンテナ（snmpマネージャ）側から見たホストのIPアドレス。（いわゆるDockerにおける仮装ブリッジdocker0のIPアドレスである。）
# snmpwalk -v 2c -c public 172.17.0.1 .1.3.6.1.2.1.1 Timeout: No Response from 172.17.0.1
snmpwalkの宛先をホストサーバ自身が持つ別のIPアドレスで実施しても結果は同じ。
なお、ホストサーバ自体にはsnmpdを設定しているし、コンテナ外からホストにsnmpすると応答が返ってくるのは確認済み。
また、コンテナからホスト向けに発行したpingの応答は返ってくる。
このことから、「コンテナからホストへのsnmpリクエスト」か「ホストからコンテナへのsnmpレスポンス」のどちらかで通信できていないと仮定。
順に確認していく。
まず、「コンテナからホストへのリクエスト」の確認。
コンテナのイメージも自分で作成していたので、まずはDockerfileの定義から確認。
snmpは通常「ポート161」を「UDP」で利用する。そのため、「161/udp」の穴あけが必要。
Dockerfile には「 EXPOSE 161/udp 」を設定していたので、大丈夫そう。
次に、docker run時には「 -p 10161:161/udp 」も付与して実行し、コンテナでポート161が通信できるように設定済みであった。
懸念点としては、ホスト側のポートを10161としている所。だが、snmpdを動作させている関係でホスト側のポート161をバインドできなかったための処置である。
少し怪しい部分が出てきたので、ホスト側でtcpdumpを実行することにした。
ホスト側のインタフェース「docker0」に対してtcpdumpを実行すると、dockerからのsnmpリクエストの通信ログは出ていたが、snmpレスポンスの通信ログは発生していなかった。
このため、「ホストからコンテナへのsnmpレスポンス」の通信が怪しそう。
念の為、snmpd側のログをみる。
すると
Jul 2 14:04:49 snmp-dev snmpd[10333]: Connection from UDP: [172.17.0.3]:34564->[172.17.0.1]:161 REFUSED
となっていた。
REFUSED（拒否）なので、dockerコンテナ（正確には、ホストの仮装ブリッジdocker0に割り当てられた）のIPアドレスからのアクセスが拒否されていると推定。
ただし、snmpdではアクセス制限をかけていなかった。
通信関係なら「 firewalld 」かとも思い確認してみるが、ポート161に対して「172.0.0.0/8」レベルでアクセス許可の設定を投入していた。
他に何か要因があるかと考えていると、snmpdなので「/etc/hosts.allow」や「/etc/hosts.deny」でアクセス制限できることを思い出す。
というわけで、両ファイルの確認。
「 /etc/hosts.deny 」を確認するも記述なし。
次に、「 /etc/hosts.allow 」を確認したところビンゴ。
プライベートIPアドレスのクラスC（192.168.x.x）とクラスA(10.x.x.x)でアクセス制限をかけていた。
ここに、Dockerの仮想ネットワークで利用しているIPアドレスの範囲（今回の場合、172.17.0.0/16）を許可する設定を追記。
無事、アクセスできるようになった。
まとめ：
dockerコンテナを利用していため、コンテナ側やコンテナ-ホスト間の通信に原因があると思い込んでしまった。
しかし、実際にはコンテナは直接は関係しない原因（IPアドレスによるアクセス制限）であった。
思い込みは捨て、一つ一つ原因を絞り込んでいく大切さを改めて思い出した。
redmine.tokyo 第16回東京Redmine勉強会に参加してきました。
2019年5月18日、redmie.tokyoの第16回目の勉強会に参加してきました。
なお、今回が初参加です。
参加のきっかけは2点あって、「Redmineの4.0が既にリリースされていること」と「主催の @akipii 氏とお会いしてみたい」というものでした。
前者は、Redmineを普段使っている割には、あまり設定側は触っていないなぁと言うのもあり、「なるほどわからん」を味わいに行くかと言う感じでした。
後者は完全にミーハーなのですが、かつてakipii氏の書かれているブログ「プログラマの思索」でチケット駆動やRedmineの勉強をさせてもらった身としては、お会いできた際にお礼を言うことができれば嬉しいな、と思った次第です。
続きを読む
Moment.jsのaddメソッドの実行では元の値も変わる
Moment.jsを利用して、現在日時を基準にして連続した日時データを取得しようとした際に確認した事象です。
const m = moment() for (let i = 0; i < 30; i++) { let cur_date1 = m.add(i ,"minutes").format('YYYY-MM-DD HH:mm') //以下略 }
上のコードの期待としては「1分ずつ値が増えていく」でした。
しかし、実際には1回目こそ想定の値であるが、2回目は1分、3回目は3分、4回目は6分、5回目は10分、6回目は15分…と回を重ねるごとに、想定値とかけ離れていく。
理由としては、momentはミュータブルであり、addやsubtractのManipulate系メソッドの実行では元の値も変更されるため。
当然ながら、ドキュメントには書いてありました。
Note: It should be noted that moments are mutable. Calling any of the manipulation methods will change the original moment.
If you want to create a copy and manipulate it, you should use moment#clone before manipulating the moment.
訳：momentsはミュータブルな点に注意すべきです。操作メソッドが呼び出されると元のmoment（の値）は変わります。もし、コピーを作成して操作をしたければ、操作前のmomentで「 moment#clone 」を使うべきです。
この記述に習い、基準となる日時のコピーを都度作成してそのコピーに対して追加を行う方式へ変更。
const m = moment() for (let i = 0; i < 30; i++) { let cur_date1 = m.clone().add(i ,"minutes").format('YYYY-MM-DD HH:mm') //以下略 }
希望通り、1分ずつ加算される結果となりました。
実際に動作確認ページも作ってみました。
「add」を押すたびに、moment#clone していないもの（上）としているもの（下）の値の動きに違いが出てくるのがわかります。
https://rykawamu.github.io/js_code_sample/public/moment_add_sample.html
