カテゴリー: オープンソース

Hudson と Mercurial を利用した Maven 成果物のリリース管理

/ Kaz Nishimura / コメントする

たまには何か書かないと PV が増えないので、今回は Hudson と Mercurial を利用した Maven 成果物 (artifact) のリリース管理について書いてみたいと思います。

ご存じの方もいるかと思いますが、私は OSSRH を利用して Maven Central Respository に Java 系成果物を公開しています。一例としては Google Login Plugin for Hudson とかですね。

ところで、Maven にはバージョンの末尾に -SNAPSHOT が付くと、リリース前のスナップショットとして扱われるという慣例があります。例えばバージョン X.Y-SNAPSHOT はバージョン X.Y より前のスナップショットという意味になり、Maven のリポジトリーでも別枠となります。

さてここまでを前置きとして、今回紹介するのは Hudson と Mercurial を利用して、成果物のリリースを半自動化してしまう手法です。

Hudson の使い方については別途調べてもらうとして、Hudson を使うことで Maven 成果物のデプロイ (deploy) までは自動化可能です。スナップショットの段階なら Hudson が新しいリビジョンを見つけるたびに自動デプロイしても何ら問題はありませんが、正式のリリースとなるとそうも言っていられません。

一応 OSSRH にステージング機能があるので、デプロイしてもいきなりリリースされることはないのですが、リリースしないものは破棄しなければなりませんので、リリース バージョンの自動デプロイは極力減らしたいところです。

そこで活用するのが Mercurial のブックマークです。例えばブックマーク release-candidate をリリース用のブランチに作成して、Hudson ではこのブックマークを追跡して自動デプロイするようにジョブを作っておきます。こうすると release-candidate の移動に伴ってリリース候補が OSSRH のステージング領域に自動デプロイされることになりますので、リリース OK となったら最後のリリース候補をリリースして残りを破棄すればリリース完了という流れです。

注意点としては、一旦リリースしたら次のリリースまでブックマークを移動しない (つまり自動デプロイしない) ようにすることでしょうか。Git でもブランチの移動を工夫すれば同様のことは可能だと思いますので、ぜひ試してみてください。

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

/ Kaz Nishimura / コメントする

ヤマハの 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 でも同様にできると予想しますが、そこは自己責任でお願いします。

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

/ Kaz Nishimura / コメントする

以前にも書いたかもしれませんが、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

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

/ Kaz Nishimura / コメントする

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

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

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

Hudson と Jenkins を両方使ってみて分かった両者の違い

/ Kaz Nishimura / コメントする

かねてより書いているとおり、当工房では Hudson と Jenkins をともに運用しているわけで、これまでに分かった両者の違いをまとめてみます。

  1. Jenkins の方がコミュニティに活気があり、プラグインも多い。
  2. Hudson は同梱されているプラグインが少なく、最初の起動時にダウンロードするようになっている。
  3. Hudson では Jenkins にもある Maven プロジェクトがレガシー扱いになっていて、自由形式プロジェクトで扱えるように変更されている。
  4. Hudson ではマスター ノードの構成が Jenkins のようには独立していない。
  5. Hudson にはカスケーディング ジョブがあり、ジョブの継承やテンプレート的な利用が標準機能だけで可能になっている。
  6. Jenkins は ${user.home}/.jenkins と ${user.home}/.hudson がどちらもあると後者を優先して利用する。システム プロパティで JENKINS_HOME を設定しない限り、同一アカウントでは共存できない。

最後のは違いではないですが、どちらも使ってみたい方には参考になるのではないかと思います。

 

Hudson のカスケーディング ジョブを使ってみました。

/ Kaz Nishimura / コメントする

Hudson のバージョン 2.2.0 以降 (執筆時の最新はバージョン 3.2.1) で利用可能になったカスケーディング ジョブ (英語では Cascading Job ですが日本語の訳語が未確定のため暫定的にカタカナで表記します) を初めて使ってみました。これは基本的にジョブ構成の継承機能で、これを使うことであるジョブの構成を一部だけ変更した派生ジョブを簡単に作れてしまいます。

使い道としては、SCM の別ブランチをビルドするジョブを作成するというのが挙げられていますが、他にも活用はできそうですね。これだけのために Hudson を使うというのもありかもしれません。

最近のオープンソース活動 (Hudson 編)

/ Kaz Nishimura / コメントする

Hudson のプラグイン チームに参加することになったというのは既報のとおりですが、最近のオープンソース関係の活動を一つ紹介しておきます。

今回紹介するのは、Hudson で SSH スレーブを起動したときに新規ディレクトリのアクセス許可が変な設定になる不具合の修正です。

POSIX のアクセス許可は、本来 8 進数で表記するべきところを 10 進数で書いていたため、結果的におかしくなっていたというだけなのですが、バージョン 3.2.1 まで出しておいて今まで誰も気が付かなかったのかと言うような話で、Jenkins と分かれてしまった Hudson 側の人材不足はかなり深刻みたいですね。