最終更新日：180412 原本2018-03-06　

Airsonic のインストール

Jetty9.4を使ってAirsonicをSubsonicとほぼ同じ速度で動かす手順です。

Subsonicと同じように、AirsonicもTomcat組み込みのインストーラが配布されています。
(コミュニティではTomcatに慣れた技術者が多いので採用しているのでしょう)

ですがTomcatはAirsonicの要件的にレスポンス速度が少々遅いです。
そのためこの記事では「Jetty」を使ってAirsonicを動かす手順を扱います。
JettyはSubsonicも採用しているコンテナです。

作業項目の目次を見ていただくと、「Jettyアンインストール」というのがあると思います。
それを行うと、最初からそこまでに追加したファイルを全て消します。
(それ以降の「Airsonicインストール」で作成するデータディレクトリは削除しません)

Jettyインストール

ほとんどをrootユーザで操作します。
注意。

Jettyは、単純に動かすだけであれば1コマンドでスタンドアロンで起動が可能です。
そのしくみを使って簡単インストールをすることも、一応できます。
ただしこの方法では起動時に「非推奨だからマニュアル見てね」と警告が出ます。

サーバの長期安定稼働やバージョンアップの利便性を考慮した推奨方法がドキュメントに書いてあります。
この記事の手順はその推奨方法に則って、上から順に実行すれば動くように、またAirsonicの場合変更した方がいいような点を修正したものです。

作業のおおまかな流れは以下のようなものです。

  • インストールディレクトリに解凍
  • 起動時の環境変数設定
  • 初期化コマンドで設定ファイル生成
  • 設定ファイルを書き換えて起動

とてもポピュラーな作業内容なので、何かサーバをインストールしたことがある方であれば特に難しい内容もないと思います。
難しい設定は極力行わないようにしています。
これを基本に、何か困ったことがあれば肉付けしていけばよいと思います。

インストールディレクトリ作成

ディレクトリを作成します。
opt配下に配置する前提ですすめます。

/opt/jetty

Jettyのディストリビューションを置く場所。

/opt/jetty/run

pidやstartlogの出力場所。サーバをjetty権限で動かすので/var/runでなくここ。

/opt/jetty/temp

Service LayerでJavaに割り当てられるtemp(java.io.tmpdirに渡す)。
サーブレットの作業ディレクトリになります。
標準的な一時ディレクトリは、長時間実行されるJettyサーバに混乱を引き起こすさまざまなクリーンアップスクリプトによって管理されることが多いので隔離するとのこと。WAKARU
このディレクトリはjettyユーザのホームディレクトリとして作成するので、ユーザ追加時に作成します。

/opt/web/mybase

サーバーの設定ファイルおよび、Webアプリケーションセットを配置する場所。
今後バージョンによって変わるであろう構成は/opt/jettyに押し込み、汎用基本設定はこちらで行うというポリシー。

ユーザを追加

最小権限のユーザを追加します。

ドキュメントには以下のように記載があります。

falseはftpも禁止の、一番制限が大きいタイプです。
noshellやfalseだと動かないんじゃ、と思ったらやっぱり動かなかったので外して上の方のコマンドで。

ユーザをグループに追加、楽曲ディレクトリを作成

これはインストールとは直接関係ありませんが、この時点でユーザやグループを決めておくとよいと思います。
Airsonicをjettyユーザで動かすので、楽曲ディレクトリはjettyユーザが読み書きできる必要があります。
例えば以下のように楽曲管理用グループを作って、あとで特定ftpユーザ等もこのグループに追加する、など。

OSのディストリビューションによっては初期インストール時にmusicディレクトリが存在します。
ストリーミングサーバの目的から言ってもバッティングさせないで隔離した方が良いと思いますが、個々の事情に合わせて。
OSによっては特殊な扱いをされるディレクトリである場合もあるので、リスクを避けるなら分けた方がよいかもしれません。

当初musicDirはスキャンできればよいので750、podcastDirは書き込みを行うので770としていましたが。
よく考えると画面側にタグ編集の機能があるので、両方とも読み書きできるディレクトリである必要があります。

タグ編集しないのであれば(あるいは元の楽曲データを改変できないようにしたいのであれば)musicDir側はRで動きます。
podcastDirはAirsonicが自動でCRUDするのでRWが必要です。

ダウンロード、解凍

/opt/jetty以下にJettyディストリビューションを配置します。
ディレクトリ名はそのままです。
バージョン違いのものを入れる場合、この階層に並列します。

環境変数設定

起動スクリプト実行前に読み込まれる環境変数を設定します。

とりあえず以下のように。
VMのチューニングはここで。

JETTY_HOME
最低限JETTY_HOMEが必要です。
稼働に使用するディストリビューションのパスを記述します。
バージョン違いのものを入れる場合、ここを書き換えます。
LANG JAVA_OPTIONS

LANGとJAVA_OPTIONSはJavaのファイルシステムを日本語対応するためのものです。
ここで設定するのが楽かと思います。
エラーが見にくくなったり不要なトラブルを回避するため、普段極力不要な日本語化は行わないという方のために一応。

こういうディレクトリ・ファイルパスの楽曲ファイルも演奏できるか、というお話です。

CDから自動でリッピングしてストレージにそのまま置く、のようなお手軽管理をしている場合、ほとんどのソフトはCDDBから取得した曲名で楽曲ファイルを吐くと思います。
つまり日本語タイトルの楽曲の場合、Windowsで生成した日本語名ファイルをLinuxに持ち込むことになります。
もしこのような設定がなくAirsonicが日本語ファイル名を表示できない場合でも、スキャンはされパスはDBに格納されます。
ただし画面上では文字化けをし、演奏操作時点でファイルエントリが認識できない、という不具合の出方をします。
それを避けるためにここで設定をしておきます。
タグエンコーディングの文字化けとはまた別の話です。

JETTY_USER JETTY_RUN TMPDIR

稼働に使用するユーザ名やディレクトリです。事前に作成しているのでここに記述。

初期化処理

よくある解凍即起動のサンプルは、初期時に準備されている全部載せの設定ファイルで動かしています。
ここでは自分用の設定ファイルを作成します。
Airsonicを動かすのであれば以下のコマンドで。

このようにモジュール再構成のための初期化処理が走ります。

この時点で、/opt/web/mybase以下に稼働に必要となる設定ファイルやディレクトリが自動で追加生成されます。

そのうちのひとつ、start.iniを一ヵ所だけ修正します。

start.iniはmoduleと呼ばれるライブラリセットと、プロパティの定義ファイルです。
だいたいPOMのparentのような役割です。

moduleは自作もできます。
サーバの処理を本気でいじくりだすとなると先のJarまで見に行く必要がありますが、動かすだけであれば大抵のことはここで設定できます。

ポートの指定がコメントアウトされているので

自分の環境に合わせて修正します。
Module: httpのところにあります。

まずはこれだけ。

start.iniを保存したら、ここまで配備したファイルのオーナーをjettyに変更し、再度環境設定ファイルを開きます。

JETTY_BASEを追加します。
一応ドキュメントでも概ねこのような作業の流れになっています。

設定の確認

以下のコマンドで設定を確認できます。

基本設定ファイルとディストリビューションが分割配備されていて、起動時にちゃんと読みに行けるな、という確認をします。
何かトラブルがあったらここまで戻りましょう。

ここまで理解しておけば仕事で他人がインストールしたjettyを触るときも大丈夫そうですね。

サービス登録

最新のLinuxは少し違うと思いますがそこは読み替えましょう。

起動

起動後の確認

正しく起動したか確認します。

先ほどのstatusとほぼ同じですが、一行目にpidが表示されていると思います。

このpidを使って確認します。

rootではなくちゃんとjettyユーザで動いていればOKです。

Jettyアンインストール

一応削除方法を。
以降Airsonicをインストールするので、実行しては駄目です。
ここまでの手順をループできますよね、と確認するためのメモです。

Airsonicインストール

ここから先の作業はAirsonicのサイトにあるインストール方法と少し似ていますが、もう少し簡単だと思います。

Airsonic配備

Airsonicのデータディレクトリを作成します。

Airsonicをダウンロードします。
少し時間がかかるので気長に待ちます。

ホットデプロイを使用します。
デプロイされていればログに出力されています。

安定稼働できる確認が取れたら、デプロイは起動時に一回だけ行うよう変更もできます。
設定はstart.iniでできます。

ログイン

ここから先の作業はほとんどSubsonicと同じです。

ブラウザから 「http://サーバのアドレス:ポート番号/airsonic」 で接続します。
初期パスワードはadminです。

楽曲ディレクトリの設定

Setting > Media Foldersを開きます。

初期設定では楽曲ディレクトリに/var/musicが割り当てられています。

私はこの手順の最初の方で /var/musicDir を作成しているので、それに書き換えます。
わかりにくいという方は何か適当に作ってオーナーとパーミッションを変更してください。
もしjettyユーザが読めない場所が指定されると、この画面にエラーが出ます。

おそらく楽曲をFTPで送信することになるので、そのあたりの運用も含めてユーザとグループの使い方を決めておくとよいです。

Podcastディレクトリの設定

Setting > Podcastを開きます。

初期設定では楽曲ディレクトリに/var/music/Podcastが割り当てられています。

私はこの手順の最初の方で /var/podcastDir を作成しているので、それに書き換えます。

初期設定では楽曲ディレクトリに入れ子になっていますが、このままでは索引作成時に楽曲とPodcastが混在してしまいます。
これを避けるため、/var/musicDirと/var/podcastDirのようにツリールートを分割するとよいです。

こうするとアカウントごとフォルダアクセス権を設定することで、楽曲ディレクトリの使い分けができるようになります。
携帯アプリ接続時は用途に合わせ楽曲とPodcastのどちらも表示できるアカウント、もしくは/var/musicDirしか表示できないアカウントのどちらかを使う。
PCから使うときは楽曲ディレクトリごとに表示したり全表示したりといったUIがあるので、両方アクセスできるアカウントを使う、といったようなことができます。

Podcastを使い始めてある程度データがたまってからでは移行が面倒なので、最初に運用を決めておくとよいです。

ffmpegインストール

Setting > Playersを開きます。

この時点ではtranscoders がインストールされてないよと警告が出ます。

ぐーぐる先生にffmpegインストールを聞けばたくさん出てくると思いますが、たとえば以下のように行います。

transcodeディレクトリに実行ファイルなりリンクを置く仕組みもSubsonicと同じです。

スキャン

楽曲フォルダに楽曲ファイルを格納後、Setting > Media Foldersを開きます。
Scan media folders nowをクリックすればスキャンが開始されます。

スキャンが終わったら再生して確認したり、PlayersからプレイヤーのMax bitrateを設定しておくとよいです。

付記

ここから先は技術者向けのおまけです。

JettyとTomcatの比較

どちらが早いとは一概に言えませんが。
Subsonicのようなタイプのサービスを動かす場合Jettyの方が向いていて速いです。

一般にTomcatは大人数からの安定的に多数の接続をする場合、Jettyはテキストやバルクの単純送出速度にこだわる場合といった使い分けがなされます。
たとえばベンダー製のWebアプリケーションサーバ製品では起動時に複数のコンテナを起動し、システム連携用のSOAPやRESTの口はJettyを使用しているような場合があります。

今回の作業でベンチは取っていませんが、自分のクライアントプログラムを動かすときに、JettyとTomcatの両サーバで動作確認をしています。

クライアントが同時に要求するコネクション数に着目する場合、Webアプリは画面更新時に一本、仮にAjaxを使ってもシングルスレッドなのでせいぜい数本です。
私のデスクトップアプリは処理によってはマルチスレッドでガンガン投げます。
(実際にはクライアントのOS側で通信数に制限が入るにしても、たて続けにリクエストを送る)
どの程度まで許容するかについては、標準インストールしたSubsonic相手にタイムアウト2s以内の設定でクライアントの機能が動かせる、といったところを目安としています。

このような強引なつくりでもJettyの場合問題なく動きますが、Tomcatは元の送出が遅いので過密処理では後続の処理がタイムアウトになる場合があります。
少なくとも一人が瞬間的にガンガン要求を投げてそれを高速にさばく、といった観点では未チューニング同士ならJettyにアドバンテージがあります。

速度に定評にあるSubsonicが、DBをアップデートしたり戻したり古いJettyを採用していたりするのは根拠あってのことなんだろうと思います。

SubsonicとAirsonicの比較

この記事にある設定方法であれば、同一のサーバマシン上での比較をした場合、SubsonicとAirsonicでほぼ似たような体感速度が得られるのではないかと思います。
ただしクライアントが同じリクエストを投げていても、SubsonicとAirsonicで返すレスポンスが一部が異なる場合もあります。

Jettyのchunkサポートは4.2.9あたり。
Subsonicの標準インストールの場合組み込まれているJettyは6.1.xです。
この記事でインストールしているのはAirsonicとJetty9.4.8です。

ファイルをstreamしてみると、Subsonic(6.1.x)でもAirsonic(9.4.8)でもchunk。

streamではなくdownloadの場合、Subsonic(6.1.x)だけchunk。
クライアントの動作には影響はありません。
そのうち調べます。

How about Airsonic?
Jetty9.xのrequestHeaderSize変更

Subsonicオールインワン(Jetty6.x)と最新Jettyでデフォ値が異なる箇所の一つです。

How about Airsonic?
Subsonic/Airsonic APIのバージョン互換

Subsonic/Airsonicのバージョン互換に関する記事です。

How about Airsonic?
Airsonicの使い方について

AirsonicをSubsonicの代替サーバにしたり改造して使っていく方法に関する記事を置きます。