2016年2月28日日曜日

EdgeRouter LITEのファームを上げてみた

購入してから一度もファームを上げていなかったので、今回ファームを上げてみました。

まず、ファームはここから入手します。

シリアルコンソールからのファームのアップデート方法は不明だったので、今回Webインターフェースから上げます。

まず、EdgeRouterに適当なIPを割り当ててログインします。


ログインしますと、今風な画面が出ます。自分は購入時点のVer1.2です。



少々見にくいのですが、下のほうにちょこっとsystemというタブがありますので、そこをクリックします。



右のほうにUpgradeSystemImageというのがあるので、Upload Fileという赤いボタンを押し、
ダウンロードしたファームウエアをアップロードします。

再起動するよ。というダイアログが出ます。



再起動します。シリアルコンソールでつないでいると、再起動時の様子が見えます。
あ、コケていますね。(汗



とりあえず起動はしたようなので、Webインターフェースにログインします。
一応ファームは上がったようです。



さて、こけた原因なんですが、OpenVPN周りの設定が綺麗に消し飛んでいます。



Vyattaの時もそうだったのですが、EdgeOSもそうか・・・
市販のルータと違い、Vyattaはファームアップグレード時、以前のConfが読めなくなることがあります。
その際、以前のConfをリネームしてくれたりとかはしてくれず、読めないものはこのように消えたりします。
基本的にはConfのバックアップなりから再度設定を流しなおすなりすればいいのですが。

(補足:EdgeOSのバージョンアップで、基になるdebianのバージョンが上がることがあります。その際、リポジトリを追加していたりした場合、リポジトリを変更する必要があります。)


どうもConfを読み込みperlなどをつかって、iptablesなど各種設定を行うのですが、これが時々順番が前後するのか失敗することがあります。
そうなると、成功した設定だけを反映した中途半端な状態で起動してしまいます。
しかもConfも中途半端な状態になるし・・・


あと、バージョンが上がって、OpenVPNの証明書を作成するeasy-rsaコマンドが無くなったようです。
別のマシンで作成してアップロードするしかないかな。

2016年2月21日日曜日

メモ:nginxで80 failed (97: Address family not supported by protocol)が出る。

nginxを使っていて、80 failed (97: Address family not supported by protocol)とでて起動しないことがあります。
その場合、/etc/nginx/nginx.confにある

    server {
        listen       80 default_server;
#        listen       [::]:80 default_server;

のように、IPv6のところをコメントアウトすると起動するようになります。



2016年2月13日土曜日

AWS SDK for RubyでELBの作成や証明書の更新をするスクリプトを作成してみた。

クラウドを使う醍醐味はAPIでインフラを制御できる征服感だとおもっています。

というわけで、自動化、省力化をぼちぼち進めているのですが、前回S3+CloudFrontをやったので、
今度はELBに挑戦です。
といっても本業ではまだ実は使ったことがなかったりしますが・・・

今回もAWS SDK for Ruby V2をつかっています。
ELBの証明書更新作業は、早くAWS Certificate Managerが東京リージョンに来てくれれば開放されるのですが・・・

ELBの証明書更新スクリプトはここにあります。


また、ELBの作成スクリプトはここです。

EC2の作成スクリプトは既につくってあるので、これと組み合わせればちょっとしたオーケストレーションツールが作成できます。
あとはオートスケールとAnsibleスクリプトを組み合わせれば、ほぼ自動化できます。パチパチ~








ま、効率上げても首絞まるだけなんだけどね(ボソッ・・・


2016年2月11日木曜日

Aitendoで売っているDCDCを直してみた。

以前東京へ行ったときにお土産?にかったAitendoのジャンクDCDCを直してみました。
これは店頭しか売っていなくて、通販では入手できないもののようです。
ちなみに100円でした。安い!!流石中華パワーw

購入後、配線間違い品らしく、そのまま通電するのは危険。というのは調べていたので、
まずは回路を調査しました。

・・が、まぁ既に先人の方によって解析済みで、修理方法も確立しているようですので、今回、
ここを参考に修理してみました。
(一応回路図を起こしては見ましたが、同一だったので清書はしていません)
自分は手元に合ったジャンク基板より、1Kオームと0.1uF程度のチップ部品を剥ぎ取って修理しました。

まずは、基板の裏側にある、出力へ伸びているパターンをカットします。
また、ボリュームの端のベタGNDの箇所に抵抗をつけるためパターンを露出させます。
某リンゴな基板よろしく黒いレジストで非常に見にくいです。表面をフラックス洗浄剤やアルコールで綺麗にすると多少は見やすくはなりますが・・・


ボリュームの2番、3番をショート。1番2番の間にコンデンサを、1番と削ったGNDの間に1Kの抵抗を半田付けします。


以上で修理完了です。

一応異常発信などしていないかを確認しました。
せっかく買ったけど使い方がいまいち良く分からなくて余り出番のないDSO-nano君です。



怖くて耐久試験はしませんでしたが(笑)、電圧は変わることを確認。


色々ごちゃごちゃしていますが、23.4Vを3.3Vに降圧できています。

なお、出力を自作アンプの電源にしてみましたが、結構ノイズが載っているようでしたので、そういう用途に使うのがよさそうです。
気持ち的には入出力にコンデンサ足したいな。



2016年2月7日日曜日

AWS SDK for Rubyを用いて、S3+CloudFrontでCache Distributionパターンを構築するスクリプトを作成してみた。

相変わらず慢性的なアレやコレやで、無駄に忙しいのですが(ぉぉ
そんな中、忙しければ省力化、自動化だろ。ということでS3+CloudFrontでCache Distributionパターンを構築するスクリプトを作成しました。

CloudFrontって、設定箇所がかなり多く、またS3との連携設定もあり、どうしても手数が多くなり、
手順書を作成してもなかなか大変です。
しかも、設定変更したら反映されるまで数十分待つ羽目になりますしね。

こんな所は自動化するに限ります。
インフラ構築を自動化するツールは俗にオーケストレーションツールと呼ばれ、
AWS純正のCloudFormationとか、Terraformとかがあります。
Terraformは昔試してみたことがあるのですが、バグが酷かったり、メッセージが謎だったりと。ちょっと実用に耐えれないな。という印象があるので、以前から興味があったCloudFormationを試してみました。
・・・・が、一般人の私には山のようなJSONをインデントを見失わず手打ちするのは無理がありすぎました。
RubyっぽくかけるDSLも有るみたいなのですが。

なので、早々にあきらめて、API叩くことにします。
ですが、AWS SDK for RubyのVer2は正直使いづらい使い方がリファレンスを見ても良く分からないし、
ましてCloudFrontの設定パラメタの多いこと!
おまけにマネコンでの設定名称とパラメタの名称が違っていたりするし(汗
というわけで、CloudFormationの付属のツール(?)である、cloudformerを使いました。

このCloudFormerというのは、構築済みのAWS環境を解析し、CloudFormationで使用するJSON形式で出力するツールです。
ただし、ツールといってもEC2インスタンス内で動くアプライアンスみたいなもので、t2.mediumインスタンスだったりするので地味に課金が怖かったり(ぉ

使い方はクラスメソッドさんのブログを参考にしていただければいいのですが、1点。
AWSではデフォルトのVPCが存在します。
このVPCを削除して自前でVPCの設定をした場合、CloudFormerは起動に失敗します。

対処法は簡単で、バージニアなど別リージョンで起動させる。です。
CloudFormerはWebからアクセスするアプリなので、実はリージョン依存ではありません。

S3+CloudFrontの環境をAWS上にマネコンでぽちぽち作成後、CloudFormerでJSON化すると、
こんな感じになります。
まぁマネコンもCloudFormationも裏ではAPIを叩いているでしょうから、内容がほぼAPIと対応します。

これで、必要なパラメタとその内容が分かりました。あとはAPIリファレンスを参照しながらコーディングするだけです。

というわけで、作成したスクリプトはこちらになります。

最後に、かかった課金のほうですが、現時点で0.14$となっています。
CloudFormerは削除すると関連するリソースを全て削除してくれるのですが、デバックのためS3やCloudFrontを消したり追加したりした結果地味にカウントされます。

このあたり、さくらのクラウドみたいにAPI試すようサンドボックス環境が欲しくなります。
あと、AWSさん。マネコンで作成したら、その操作をJSONなりでダウンロード出来る機能つけてくれませんかねぇ。
CloudFormerでは全部が解析できるわけではなさそうで、それであれば、ウイザードの段階からJSONなりを作成してくれればいいのにな。