プログラマーのメモ書き

伊勢在住のプログラマーが気になることを気ままにメモったブログです

ファームウェアアップデート

以前ブレッドボード版の IchigoJam を作ったのですが、伊勢ギークフェア向けに何か作るのに使えないかと考え、手始めにファームウェのアップデートをすることにしました。

その理由なんですが、元々、作ったままのIchigoJamでは画像に結構ノイズが乗って見づらく思っていたら、クリスタルを追加すると映像が改善することがあるとの情報を見つけて、これはいいと思っていたら、クリスタルを追加すると、ファームウェアをクリスタル対応版にする必要があるとのことがわかったためです(ファームウェア1.0.2からは自動検出になるようです)。

で、ファームウェアアップデートをするときは、PCとも接続しないといけないので、それも併せて試しました。

ということで、このあたりの一連の作業を忘れないようにメモしておきます(ハードウェア系の作業なんてホント忘れてしまいそうです)。

IchigoJamをPCに接続する

必要なもの

  • USBシリアル変換
  • オス-メスのジャンパーケーブル3本

いきなりファームウェアのアップデートも怖いので、まず最初は、IchigoJam をPCに接続してみます。作業は、『イチゴジャムレシピ』にある『パソコンと接続』ページを参考に行いました。

接続するために必要なものとしては

  • USBシリアルモジュール
  • オス-メスのジャンパーケーブル3本

になります。今回は、安さにつられてamazonに出ていた海外発送の商品を購入しました(買ったときは400円!)。不良品もあるので、2個同時に注文するとかの情報も見かけましたが、そんなこと気にせず1個だけ注文しました。ちなみに、写真にジャンパーケーブルが写っていたので、買わなくていいやと思っていたら、これはメスーメスのタイプなので、ブレッドボードのIchigoJamと接続するのには使えませんでした。あとから、追加注文する羽目になりました。

機材の準備ができれば、早速IchigoJamにつなげてみます。

今回購入したやつは、モジュール上の端子がTXC、RXCとなっており、『イチゴジャムレシピ』にある『パソコンと接続』ページでクロスではなく、ストレートで結線しないといけないと注意されているタイプでした。

f:id:junichim:20160825154815j:plain

早速つなげてみます。USBシリアルモジュール側に指したジャンパーケーブルの色(緑:GND、赤:TXC、青:RXC)に対して、

f:id:junichim:20160825154810j:plain

ブレッドボード側は、赤:TXD、青:RXD、緑:GNDになります。

f:id:junichim:20160825154812j:plain

(クリスタル設置後の写真です。USBシリアルモジュールの接続の様子がわかればと思います)

結線ができたので、PCにターミナルソフトをインストールしておきます。今回は、イチゴジャムレシピのページでも紹介されているIJKBを使いました(facebokグループもあります)。

で、喜び勇んで、USBシリアルモジュールをPCにつないで見ると、モジュール上のランプが点灯してます!おぉ、これで問題ないなと思っていたら、なんかCOMポートがうまく選択できず、もちろん、接続できませんでした。

答えを先にいうと、このチップ用のドライバをインストールする必要があります。 (ドライバのことは、下記のサイトの記事を眼にして知りました。ありがたいことです。)

ドライバは、こちらの『CP210x USB - UART ブリッジ VCP ドライバ』の手順に従ってダウンロードとインストールを行ってください。PC側が、Windows7(64bit版)でしたので、それに見合ったものを入れました。

ドライバのインストールが終わってから、USBシリアルモジュールをPCにつないで見て、IJKBを起動すると、COMポートの選択肢が増えている!早速これを選んでつないで見ると、おぉ!繋がった。PC側で、

LED 1

とかコマンドを送ると、ちゃんとLEDが光りました。

ちょっとドライバ周りで手間取りましたが、これで問題なく接続できたようです。

ファームウェアのアップデート

さて、次は本番のファームウェアのアップデートです。IchigoJamの場合、クリスタルの有無で利用するファームウェアが変わるようです。

安全策をとるならば、

  1. クリスタルを設置
  2. 今のバージョン(0.9.7)のクリスタル対応版へファームウェア書き換え
  3. 最新版(1.0.1)へアップデート

とするとか、

  1. 最新版(1.0.1)へアップデート
  2. クリスタルを設置
  3. 最新版のクリスタル対応版へファームウェア書き換え

と、2回書き換えを行うことになると思います。

でも、まあ、なんとなく面倒になってきたのと、『イチゴジャムレシピのファームウェアの更新』ページの下のほうの注意書きに、クリスタル対応版のファームを入れてクリスタルがない場合はLEDが点灯する、という記述を見つけて、多分壊れることは無くあとからクリスタルをつければ動作するのだろうと思ったので、1回で済ますことにしました。

というわけで、作業手順です。まあ、こちらの『IchigoJamのファームを書き換える』を参考にそのまま作業しただけですが・・・

進め方としては、

  1. 1.0.1(クリスタル対応版)へアップデート
  2. クリスタルを接続
  3. 無事に起動

という目論見です。

まず、作業PCにFlashMagicをダウンロードして、インストールしておきます。

次に、IchigoJamのファームウェアを公式サイトからダウンロードして、解凍しておきます。今回使うのは、1.0.1のクリスタル対応版です。

IchigoJamはPCからはずし、電源を切ります。次に、IcigoJamのICのISP端子とGNDを接続します(RESETは接続しなくてよいようです)。

この状態で、IchigoJamの電源をいれると、LEDが点灯した状態になります(こんな感じです)。

f:id:junichim:20160825154804j:plain

ここで、USBシリアルモジュールをPCに接続します。

Flashmagickを起動します。

CPUとして、LPC1114/102を選択します。COMポートとして、IchigoJamのものを選択します(ここではCOM6でした)。Baud Rate は115200を選択します。

その他として、『Erase blocks used by Hex File』と『Verify after programming』にチェックを入れておきます。

f:id:junichim:20160825154803p:plain

Step3のところで、ダウンロードして解凍したIchigoJamのファームウェアを選択します。

Step5のStartボタンを押せば、ファームウェアの書き換えが行われます。問題がなければ、下側のステータスメッセージに、Finishedが表示されます。

ここで、一旦IchigoJamの電源を切り、ISPとGNDを接続していたジャンパーケーブルを抜きます。

再度IchigoJamの電源を入れると、前述のように、LEDがちゃんと光ってます。

ここから、クリスタルの設置になります。

クリスタルは、『イチゴジャムレシピの周辺機器』のページにあるように12MHzのものを用意します。毎度のごとく、amazonで購入しました。1個しか使わないのに、10個入りでしか売ってないのがつらいですね。でも、たまにしか買わないのなら、amazonの送料無料というのは魅力的なんですよね。

設置は全然難しくなく、CPU上の IchigoJam の端子と @taisukef の端子をつなぐように接続します。ブレッドボードなんで、CPUに対して斜めにして押し込んで完了です。

さて、これで作業完了(のはず)です。 電源を入れると、無事に表示されました!

f:id:junichim:20160825154808j:plain

ちょっと文字がボケてるのは、カメラの腕のせいで、IchigoJamのせいではないので、悪しからず。

ローカルサーバーにsshで接続する

misocaのブログngrokの紹介が載っていて、あ、面白そうなサービス、と思っていたところ、NATの内側にあるローカルサーバーに外部からSSHで接続する必要が生じたので、早速試してみました。

インストール

インストールはなにも難しくありません。

mor@LaptopDev:~/bin$ wget https://dl.ngrok.com/ngrok_2.0.19_linux_386.zip
mor@LaptopDev:~/bin$ unzip ngrok_2.0.19_linux_386.zip

ダウンロードする際は、32bit版/64bit版がわかれているので、そこだけ注意してください(32bit版は、More Platforms を開くとでてきました)。

早速動かしてみます。

mor@LaptopDev:~/bin$ ./ngrok tcp 22
Tunnel session failed: Non http-protocols are only available after you signup at https://ngrok.com/signup
mor@LaptopDev:~/bin$ 

おっと、SSHの場合は、サインアップが必要だそうです。なので、 https://ngrok.com/ からサインアップします(GitHubアカウントがあったのですぐでした)。

サインアップした時点では、freeプランなので、お金もかかりません。

サインアップ後、ngrokサイトのダッシュボード画面で表示されるauthtokenを指定してやります。

mor@LaptopDev:~/bin$ ./ngrok authtoken xxxxxxxxxxxxxxxxxxx

設定ファイルが、~/.ngrok2/ngrok.yml に作成されます。

これで、

mor@LaptopDev:~/bin$ ./ngrok tcp 22

とすると、見事にポートフォワーディングをしてくれました。

設定ファイルの作成

これでも十分使えるのですが、今回の場合対象のサーバーがリモートにあるので、OS起動後に自動的に ngrok の設定ができていると嬉しいです。

~/.ngrok2/ngrok.yml の内容を追記します。設定ファイルの内容はngrokのDocumentationに詳しく載ってます。

authtoken: xxxxxxxxxxxxxxxxxxxxxxxx
log_level: info
log_format: logfmt
log: /var/log/ngrok.log
tunnels:
  ssh:
    proto: tcp
    addr: xxx

addr でポート番号を指定します。ssh のポート番号を変える場合は、/etc/ssh/sshd_config 側の設定も確認してください。 これを呼び出すには、

mor@LaptopDev:~/bin$ ./ngrok start --config=~/.ngrok2/ngrok.yml ssh

のように呼び出します。コマンドライン上のsshは、設定ファイル中のssh(トンネル名?というのかな)に対応しています。この名前はユーザーが任意につけられるようです。 今回は、簡単に確認するため、cronで起動時に、これを呼び出すようにしてみます。

mor@LaptopDev:/etc/cron.d$ cat ngrok 
# /etc/cron.d/ngrok: crontab entries for ngrok

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

@reboot  root    /opt/ngrok/bin/ngrok start --config=/opt/ngrok/ngrok2/ngrok.yml ssh >> /var/log/ngrok.log 2>&1
mor@LaptopDev:/etc/cron.d$ 

設定ファイル等はrootの持ち物にして、それっぽい場所におきました。設定後、再起動してから、ngrok.comのダッシュボードを見ると

f:id:junichim:20160825154802p:plain

のように接続用のURLが登録されていることがわかります。もし、接続用のURLやポート番号を固定にしたい場合は、有料プランに変更すればよいようです。

ここまで、無料でつかえるなんて、ngrokさんありがたすぎです。

ディスク使用量を監視する

もともと、redmineを運用していたサーバーのディスク空き容量が厳しかったので、ディスク使用量を監視しようと思ってました(まあ、その設定をしようとサーバーをみたら、『[Ubuntu] unattended-upgrade 実行失敗と復旧』で書いたように痛い目にあってしまいましたので、なおさら必然性がでてしまったのですが・・・)。

で、『[Ubuntu] unattended-upgrade の通知設定』で書いたように既にメール設定を導入したので、自分でディスク使用量の監視スクリプトとcronを書けば事足りるのですが、CloudWatch を使いたいというのがあったので、今回はこちらで実現しました。

EC2だと、CloudWatch を使えば、いくつかの指標(メトリックス)に関しては、デフォルトかつ無料(5分単位の監視の場合)で利用可能なのですが、デフォルトで提供されているものには、ディスク使用量は含まれていません。

ちょっと調べてみると、Amazon CloudWatch Monitoring Scripts for Linux を使えば簡単にディスク使用量の監視をカスタムメトリックスとして CloudWatch に追加できるようです。

以下の作業はこちらの記事を参考にさせていただきました。

CloudWatchでEC2のディスク容量のチェックをおこなう

準備

説明ページあるように、必要なパッケージをインストールしておきます。

bitnami@ip-10-132-190-144:~$ sudo apt-get install libwww-perl libdatetime-perl

 問題なくインストールできれば、準備完了です。

CloudWatchの設定

インストールはスクリプトファイルをダウンロードして、設置すれば終わりです。

bitnami@ip-10-132-190-144:~$ wget http://aws-cloudwatch.s3.amazonaws.com/downloads/CloudWatchMonitoringScripts-1.2.1.zip
bitnami@ip-10-132-190-144:~$ cd /usr/local/bin
bitnami@ip-10-132-190-144:/usr/local/bin$ sudo unzip /home/bitnami/CloudWatchMonitoringScripts-1.2.1.zip 
bitnami@ip-10-132-190-144:/usr/local/bin$ 

試してみます。ここで、認証情報は、AWS_ACCESS_KEYとAWS_SECRET_KEYに入っているとしています。

--verifyオプションをつけると、実際にメトリックスを送信することなく、認証を含めて指定の値がとれるか確認します。これで、問題なければ、下記のように表示がされます。

bitnami@ip-10-132-190-144:/usr/local/bin/aws-scripts-mon$ ./mon-put-instance-data.pl --disk-space-avail --disk-path=/ --verify --verbose --aws-access-key=${AWS_ACCESS_KEY} --aws-secret-key=${AWS_SECRET_KEY}   
DiskSpaceAvailable [/]: 4.74913787841797 (Gigabytes)
Endpoint: https://monitoring.ap-northeast-1.amazonaws.com
Payload: {"MetricData":[{"Timestamp":1442134385,"Dimensions":[{"Value":"/dev/xvda1","Name":"Filesystem"},{"Value":"xxxxxxxxxx","Name":"InstanceId"},{"Value":"/","Name":"MountPath"}],"Value":4.74913787841797,"Unit":"Gigabytes","MetricName":"DiskSpaceAvailable"}],"Namespace":"System/Linux","__type":"com.amazonaws.cloudwatch.v2010_08_01#PutMetricDataInput"}

Verification completed successfully. No actual metrics sent to CloudWatch.

bitnami@ip-10-132-190-144:/usr/local/bin/aws-scripts-mon$ 

問題無いようですね。

ちなみに、ここで使用した認証情報に対応する、IAMユーザーは、AmazonEC2FullAccess をポリシーとして持っています。このポリシーの詳細を表示してみると、

f:id:junichim:20160825154800p:plain

のようになっているので、デフォルト状態で、CloudWatchの権限があることがわかります。

それでは、cronから呼び出すようにします。cron から呼び出す場合は、--from-cron オプションを設定してください。

bitnami@ip-10-132-190-144:/etc/cron.d$ cat ec2_monitor_cloudwatch 
# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

# m h dom mon dow user  command
*/5 * * * * root /etc/ec2/ec2-cloudwatch.sh
bitnami@ip-10-132-190-144:/etc/cron.d$ 

さきほどコマンドラインから実行した内容は、ec2-cloudwatch.sh にまとめています。

bitnami@ip-10-132-190-144:/etc/ec2$ cat ec2-cloudwatch.sh 
#!/bin/bash
#
# monitor some metrics and push to CloudWatch
#
# writen by Junichi MORI, 2015/9/13

EC2_ENV=/etc/ec2/bash_ec2env

. ${EC2_ENV}

MON_DIR=/usr/local/bin/aws-scripts-mon
MON_SCRIPT=mon-put-instance-data.pl

${MON_DIR}/${MON_SCRIPT} --disk-space-avail --disk-path=/ --aws-access-key=${AWS_ACCESS_KEY} --aws-secret-key=${AWS_SECRET_KEY} --from-cron
bitnami@ip-10-132-190-144:/etc/ec2$ 

認証情報は、EC2_ENV で指定しているファイルで設定しています。

確認

しばらくすると(5分以上)待って、AWSコンソールからCloudWatchを開くと、『メトリックス』に『Linuxシステム』というのが追加されています。

アラームの設定

CloudWatchでカスタムメメトリックスを設定したので、せっかくなので、アラームも設定してみましょう。

『AWSコンソール』から『CloudWatch』を開いて、ダッシュボード中の『アラームの作成』ボタンを押します。下記のようなアラームの設定画面が表示されるので、画面に従って、必要事項を入力していきます。

f:id:junichim:20160825154744p:plain

最初はアラームを設定するメトリックスを選択します。メトリックスを選択すると、アラーム定義画面に移ります。

f:id:junichim:20160825154745p:plain

始めに、アラームの名称・説明を入力し、次に、アラームの閾値を設定します。

f:id:junichim:20160825154748p:plain

この例の場合は、ディスクの残り領域が、4.7GB以下が1回連続した場合にアラームを発行するという基準にしています。

次に、アラームの閾値に対して、どのような行動を取るかを指定します。

『アラームが次の時』の意味は、対象となるメトリックスがアラーム閾値の条件を満たし場合が『警告』、満たさない場合が『OK』になります。『不足』はメトリックスが取得できていないなどの状態です。

『警告』を選択すると、アラームが閾値を満たした場合(上記の場合だと、ディスクの残り容量が4.7GBを切ったとき)に通知が飛びます。同じ閾値に対して『OK』を選択すると、ディスクの残り容量が4.7GBより大きい場合に通知が発行されます。

f:id:junichim:20160825154749p:plain

『通知の送信先』には、アラーム基準を満たした場合の通知先を入力します。ただし、この欄は、Amazon SNS のトピックとして入力する必要があります。

まだ、SNSを設定していない場合は、『新しいリスト』を選択します。すると、

f:id:junichim:20160825154751p:plain

のように、『メールリスト』欄が現れます。

この『メールリスト』欄に、送信先のメールアドレスを入力します。さらに、『通知の送信先』にSNSのトピック名を入力します。今回は新規での作成になるため、トピック名としては(使える文字・記号と文字列の長さは守る必要がありますが)任意の文字列を指定すればよいと思います。

メールアドレスだけ指定すればいいと勝手に思い込んでいたもんで、実は、ここで結構はまりました。『通知の送信先』が空欄だと、『アラームの作成』ボタンを押しても、エラーとなり、そのエラーメッセージも文字種別の不正、のような内容のため、メールアドレスが間違っているのかと勘違いしてました。

問題なく入力できていると、入力したメールアドレス宛に、すぐに確認メールが送られます。こんな感じです。

f:id:junichim:20160825154752p:plain

メールに記載されているリンクをクリックすることで、メールアドレスが登録されます。画面もすぐに下記のように変わります。

f:id:junichim:20160825154754p:plain

問題なく設定できると、CloudWatchの画面で

f:id:junichim:20160825154756p:plain

こんな感じで、アラームが設定されたことがわかります。

なお、CloudWatchのアラームの作成については、こちらのリファレンスなどをご参考にしてください。ちゃんと読むとSNS設定のことなども載ってますね。

確認

では、実際にアラームを発生させてみます。

監視対象のサーバーにログインして、適当なファイルをコピーして、ディスクの空き容量を4.7GB以下にします。

すると、そのうち、

f:id:junichim:20160825154758p:plain

のように、設定したアラームがアラーム状態に変化します(紛らわしい・・・)。 メールも送られているはずなので、確認してみると、

You are receiving this email because your Amazon CloudWatch Alarm "LowFreeDiskSpace" in the APAC - Tokyo region has entered the ALARM state, because "Threshold Crossed: 1 datapoint (4.4244499206543) was less than or equal to the threshold (4.7)." at "Sunday 13 September, 2015 10:56:13 UTC".

View this alarm in the AWS Management Console:
https://console.aws.amazon.com/cloudwatch/home?region=ap-northeast-1#s=Alarms&alarm=LowFreeDiskSpace

Alarm Details:
- Name:                       LowFreeDiskSpace
- Description:                Low free disk space
- State Change:               OK -> ALARM
- Reason for State Change:    Threshold Crossed: 1 datapoint (4.4244499206543) was less than or equal to the threshold (4.7).
- Timestamp:                  Sunday 13 September, 2015 10:56:13 UTC
- AWS Account:                xxxxxxxxxxxx

Threshold:
- The alarm is in the ALARM state when the metric is LessThanOrEqualToThreshold 4.7 for 300 seconds. 

Monitored Metric:
- MetricNamespace:            System/Linux
- MetricName:                 DiskSpaceAvailable
- Dimensions:                 [Filesystem = /dev/xvda1] [InstanceId = xxxxxxxxxx] [MountPath = /]
- Period:                     300 seconds
- Statistic:                  Average
- Unit:                       not specified

State Change Actions:
- OK: 
- ALARM: [arn:aws:sns:ap-northeast-1:xxxxxxxxxxxx:ec2administrator]
- INSUFFICIENT_DATA: 

こんな感じのメールが送られていました。無事に監視できているようです。

その他

カスタムメトリックを利用するとCloudWatch の料金が発生しますが、CloudWatchの料金の説明を読むと、

新規および既存のお客様は、10 メトリックス(Amazon EC2 インスタンスまたはカスタムメトリックス、または CloudWatch Logs* の詳細モニタリングに適用)、10 アラーム、および 100 万の API リクエストを追加料金なしでご利用いただけます。

とあるので、10メトリックスまでなら無料で使えそうです。

また、SNS も料金の説明を読むと無料利用枠があるので、数個のアラームに使う分には追加料金も不要のようです。ありがたいことです。

あと、CloudWatch を少し触ってみた印象としては、サーバーの状態の中でも数値が刻々と変化していく指標に使うのが良さそうです。グラフィカルに変化を見ることができるので、これを利用しない手はないという印象です。もちろん、エラーの有無などをメトリックスにしてアラームを設定することも可能ですが、わざわざCloudWatchを使わなくても良さそうです。気になる指標が出てきたら、いろいろ追加して使ってみようと思います。