RT58i と rsyslog を使って発信者番号をメール通知

ヤマハの RT58i には着信した電話の発信者番号を syslog に出力する機能があります。そして syslog デーモンの一種 rsyslog にはログをメールで送る機能があります。

そこでこれを組み合わせたら、着信した電話の発信者番号をメールで通知することができるのではないかと考えて試してみたので設定を紹介します。

前提条件

今回試した設定では以下のバージョン (リビジョン) を利用しました。

  • RT58i: ファームウェア Rev.9.01.51
  • rsyslog: バージョン 8.4.2 (Debian 8 収録のもの)

準備

RT58i でログを別ホストに送信する設定

まず RT58i でログを別ホストに送信するように設定します。以下のようにホスト名なり IP アドレスなりで rsyslog の動作するホストを指定します。

syslog host syslog.example.com

これを設定したら save を忘れずに。

rsyslog で別ホストからログを受信する設定

rsyslog.conf (Debian の場合は /etc/rsyslog.d 以下の任意の example.conf ファイルに記載するとよいでしょう。) に以下を記述して UDP 受信を有効にします (ここでは legacy configuration で記載しています。)。

$ModLoad imudp
$UDPServerRun 514

ここまで設定して service rsyslog force-reload を実行すれば、RT58i のログが rsyslog で記録されるようになるはずです。

rsyslog で着信電話の発信者番号をメール送信する設定

RT58i では電話の着信があると以下のようなログを残します。

TEL[**/*] InComing Call from 0ABCDEFGHIJ

そこでまずこれを抜き出すために以下のような正規表現を使ったフィルターを使います (まあ国内の電話番号なら必ず 0 で始まるはずなので [0-9] は余計かもしれませんが念のために入れておきました。)。

:msg,regex,"InComing Call from [0-9]" action

rsyslog の仕様なのか TEL[…] の部分は msg プロパティーには含まれないので正規表現には含めていません。

次にこのフィルターを利用して以下のように発信者番号をメール送信するように設定します。

$ModLoad ommail

$template MailSubject,"Got an incoming call"
$template MailBody,"From %msg:R,ERE,1: from ([0-9]+)--end%"

$ActionMailFrom nobody@example.com
$ActionMailTo somebody@example.com
$ActionMailSubject MailSubject

:msg,regex,"InComing Call from [0-9]"   :ommail:;MailBody

ここまで終わったらもう一度 service rsyslog force-reload を実行して新しい設定を有効にします。

最後に自分の携帯電話から発信するなり誰かに発信してもらうなりして実際にメールで発信者番号が通知されることを確認すれば作業は終わりです。

たぶん後継機種の NVR500 でも同様にできると予想しますが、そこは自己責任でお願いします。

Google Cloud Storage Nearline を使ってみました

Google Cloud Platform に Cloud Storage Nearline というサービスがあるのに気づいたので Turbo NAS のバックアップ用に使ってみることにしました。

Developers Console から、ストレージ クラス Nearline を選択して Cloud Storage にバケットを作成するだけで、後は通常の Cloud Storage を使うバックアップと同じ設定であっさり成功してしまいました。ほぼ同じ料金の Amazon Glacier と違って、バックアップした内容が Developers Console から確認できるほか、不要になったバケットやフォルダーの削除も何時間も待つことなく可能なので、使い勝手は格段に良いです。

しばらく使ってみて、料金的に問題が発生しないようなら、比較のために同時に設定してみた Glacier を使ったバックアップは取りやめにしようかと考えています。

DHCP で NetBIOS over TCP/IP を止める方法

以前にも書いたかもしれませんが、ISC DHCP サーバーを使って、DHCP で IP アドレス割り当てを受けている Windows の NetBIOS over TCP/IP (NetBT) を止める方法を紹介します。

まず、dhcpd.conf に以下の設定を追加します。MSFT.release-lease-on-shutdown の行は省略しても構いませんが、後述のように便利なこともあるので記載しておきます。

option space MSFT;
option MSFT.disable-netbios code 1 = unsigned integer 32;
option MSFT.release-lease-on-shutdown code 2 = unsigned integer 32;

次に、NetBIOS over TCP/IP を止めたいスコープに以下の設定を追加します。

class "MSFT" {
    match if option vendor-class-identifier ~= "^MSFT";
    vendor-option-space MSFT;
    option MSFT.disable-netbios 2;
}

これで DHCP で IP アドレス割り当てを受けている Windows では NetBIOS over TCP/IP が停止します。

追加で以下のオプションも含めておくと、一時的に接続される Windows ホストが多数あるネットワーク環境では、Windows のシャットダウン時に DHCP リースを解放するので IP アドレスが足りなくなるという事態の防止に貢献します。

    option MSFT.release-lease-on-shutdown 1;

参考: https://msdn.microsoft.com/ja-jp/library/cc227275.aspx

AWS Elastic Beanstalk に WildFly を載せてみました

Amazon Web ServicesElastic Beanstalk というサービスがありますので、試しに WildFly を載せてみることにしました。

まず AWS コンソールから Elastic Beanstalk で Create New Application を選択すると、いくつかの構成の中から環境  (Environment) を作成できるようになっているのですが、残念ながら WildFly の構成はないので、今回はお試しということで Docker の構成を選んで Single instance の新しい Web Server Environment を作成することにしました。アプリケーションの選択時に WildFly の Dockerfile をアップロードすることで、とりあえず WildFly 単体の稼働は確認できました。

WildFly の Dockerfile は、http://www.jboss.org/docker/ から入手可能になっていますが、これだけだと自前のアプリケーションが載せられないので、実用的には Dockerfile に何らかのカスタマイズが必要になってきますね。

Elastic Beanstalk の環境を作成した後で、AWS コンソールで EC2 を確認すると新しいインスタンスが作成されていました。また Elastic Beanstalk を使うためにはどうやら Elastic IP も必須なようです (自動的に割り当てられます)。

Microsoft Azure で仮想マシンを作成してみました

当工房では Amazon Web Services (AWS) だけでなく Microsoft Azure や Google Cloud Platform (GCP) にも対応するというスタンスなので、今回 Microsoft Azure で仮想マシンの作成を行ってみました。その中で気づいた点を、経験の少ない Amazon EC2 との比較でいくつか挙げてみたいと思います。

  1. Azure 仮想マシンでは、ユーザーが DNS ホスト名を host.cloudapp.net の形で指定します。EC2 のように勝手に決められることはありません。
  2. デフォルトでは、仮想マシンを起動するごとに IP アドレスが動的に割り当てられます。シャットダウン後も IP アドレスを保持することはできますが、課金が継続するので、そうする意味はあまりありません。しかし前項で書いたように DNS ホスト名が固定で指定できるので、ホスト名で参照する限りそれほど不便にはなりません。もちろん有料オプションで固定 IP アドレスを使うこともできます。
  3. 課金は分単位です。EC2 のように 1 時間単位に切り上げられることはありませんので、必要な時に短時間だけ起動して使いたいという場合にも無駄が発生しません。
  4. EC2 の t シリーズに相当するインスタンスはなく、Basic 層の A シリーズを使うことになります。最小構成の A0 インスタンスは RAM 768 MB なので、Windows Server を稼働させるのにはちょっと厳しいですかね。
  5. 仮想マシンの OS ディスク イメージは、EC2 での EBS のような専用領域でなく、ストレージ アカウントに BLOB として保存されます。A0 インスタンスの Windows Server 2008 R2 の構成で 127 GB が確保されていました。おそらくこの容量分は別途課金されるだろうと思います。
  6. 仮想マシンを作成すると、クラウド サービスも自動的に有効になります。クラウド サービスについてはまだ手探りなので、何か分かったら改めて記載することにします。
  7. おまけですが、Microsoft Azure には AWS Console のようなリージョン切り替えがありません。全部一つの画面で一覧できます。

とりあえず現時点で気づいた点を挙げてみました。それほど使い込んでいる訳ではないので、間違いがあれば遠慮なくご指摘ください。

更新: 現在の名称である「Microsoft Azure」に表記を訂正しました。

 

Virtual X68000 バージョン 2.0 一夜にして完成

作者にも全く不可解なのですが、基礎設計すら終わっていなかった Virtual X68000 バージョン 2.0 が、今朝気が付いたらどうした訳かコーディングが完了していました。それも当初予定していた GNU/Linux 版、Windows 版に加えて Mac OS X 版まで用意するという念の入れようで、もうこれは4月1日の奇跡とでも言うより他に言葉がありません。

完成した Virtual X68000 バージョン 2.0 のソース コードは、作者のレビューと動作確認を実施した上で、GNU GPL の基で公表する見込みです。


以上は、もちろんエープリルフールのネタです。

freetel priori2 をテスト機として調達

以前のテスト機で失敗 (メモリ不足なのかデバッグができない) したので、今回追加でテスト機を調達しました。本当は Nexus 5 辺りが良かったのですが、予算がないので freetel の priori2 です。

今回は本体メモリが 1 GB あるせいか、デバッガーがいきなりデバッグを放棄すると言うこともなく、Android SDK の USB ドライバーをインストールするだけで、adb_usb.ini の編集もなしで認識されると言う、素直な良いテスト機と言うのが最初の印象でした。

なぜか USB のソケットがトップ側にあるんですけどね。

追記: Wi-Fi は 2.4 GHz だけのようです。