Opne Media Vault5 はちょっと面倒だった
ラズパイでデジタルミュージックプレーヤー その16
我が家の楽曲ファイルを置いてあるサーバーは、NanoPiNEO2に入れたOpenMediaVault（以下OMV）です。
OMVのSMBでmacから楽曲とカバーアートファイルを格納するとともにMPDに楽曲ファイルを渡し、プラグインのNginx（webサーバー）でMPCにカバーアートを渡しています。
当初はメーカーのFreandlyElecが提供しているOMV3がインプリされたNASキット用Bootイメージを使っていましたが、いまいちレスポンスが良くない（時々音が途切れる）こともあり、解決方法を探っていたらOMVのサイトにNanoPi用のOMV4がインプリされたイメージがあったので、改善することを期待してそちらに乗り換えました。
結果、実はレスポンスが悪いのはOMVのせいではなく、OS（ArmbianというかDebian）のUAS（usb attached scsi）ドライバーの動作が良くなく、Abortが発生してたせいで、ドライバーをUASではなく通常のUSB-storageにする（UASの対象から外す）ことで解消していました。
その後、OMVのアップデート管理で最新状態に維持しながら使い続けていたのですが、ある日を境にアップデートがない状態が続き、しばらく経ってからアップデートが提供されたかと思ったら量が少ない。
「これはもしや」と思い、久しぶりにOMVのサイトに行ってみたら案の定。OMV4の提供が終了しており、OMV5になっていました。
（要はStretchのメインストリームが終わってBusterになっただけ？）
しかも、OMV5からはシングルボード用のOS込みのイメージ提供がなく、OSを入れてから個別にOMVをインストールする必要があるとな。
これは面倒。
家の中で特定用途でしか使っていないので、アップデートしないからといってこれといった不都合はなく、そのまま使っていましたが、ふとArmbianをStretchからBusterにしたら何かが（良い方向に）変わるかも。と思い立ち、チャレンジしてみることにしました。
とはいっても、OMV4とは別のブート用MicroSDを用意したらあとはインストールと設定だけではありますが、実際には何日か悩むことになります。
例によってLinuxのHowToなブログではないので、細かいところは端折っていきます。
これまでのとは別に用意したMicroSDに入れたArmbian Busterを起動して基本的な設定をしたら、Armbian ConfigからOMVをインストール、アップデートをします。
ブラウザでOMVにアクセスしてマシンの基本的な設定をしたらmacからSMBアクセスを確認します。
MPDからアクセスするユーザ名とパスワードで楽曲ファイルが見えるし、ファイルも置けるし消せるのでまずはOK。
そしてプラグインのNginxを。。。。。。。。
あれ？
プラグインにNginxが出てこないし、OMV4になかったDockerなんていうタブがある。
なるほど、本体と重複するような機能はプラグインではなくDockerコンテナにして相互に影響出ないようにしたのね。
まずはDockerとGUIコンテナ管理ツールのPortainerを入れますが、Portainerのデフォルトのエージェントポートが8000となっていて私が使いたいポートとバッティングしているので8800に変更してインストールします。
インストールしたらPortainerにアクセスしてAppTemplatesからNginxを選択して、インストール条件、起動条件、入出力条件を指定しますが、プラグインとはあまりに違いすぎてDockerをある程度理解してないとなんでこんな設定がいるのか分かりにくいですね。
Dockerコンテナは仮想マシンのようなものなのでここではコンテナとNginxの環境設定で、Nginx自体の設定は起動したコンテナ内で行わなければなりません。
ここでは、（OMV4ではwebの待受を8000番ポートで行っていたのを引き継ぐため）ホスト8000→コンテナ80でNginxにリクエストが渡るように設定。
さらにホスト側の楽曲ファイルがあるディレクトリをコンテナのNginxドキュメントルートにバインドマウントの設定をしてデプロイ実行。
コンテナが起動したらrootでコンソールに入ってドキュメントルート配下を見ると、ちゃんとホスト側のファイルが見えます。
んでブラウザからポート8000にアクセスしたら、なんと403（アクセス権限なし）ですと。。
結論から書いちゃうと、この事象はLinux版のDocker特有のようで、ホストからバインドマウントするディレクトリ/ファイルのオーナー/グループのUID、GIDがそのまま渡されるので、コンテナ側に該当のユーザー、グループがなかったり、Nginxユーザがそのグループに属していなかったりすると発生します。（mac版のDockerはコンテナ側ユーザーのグループによろしく変換してくれるのでこの事象は起きない）
解決策としてはいくつかあって、開発環境で使うコンテナなどの場合は、ホストの/etc/passwdや/etc/groupなんかもバインドしちゃうことでコンテナ側をホストと合わせちゃうことをするようですが（ちなみにこの方法はmac版ではmacに/etc/passwdがないので失敗します）、今回は構成済み（吊るし）のNginxコンテナを使うのと、ホスト側にNginxユーザがいないためこの方法ではNginxユーザがどっかに行っちゃうので、ホスト側とコンテナ側にGIDも共通で存在するグループusersを使うことにして、ホスト側のディレクトリ/ファイルのグループをusersに変更、コンテナ側Nginxユーザにusersグループを追加することで共通の権限を設定します。
あと、MPCからカバーアートが取れるようにインデックス表示を許可するため、コンテナのnginx.confに”autoindex on;”を追記します。
これで無事ファイルが見えるようになりました。
ちなみに、今回入れたNginxコンテナですが、nanoどころかviも入っていないので、コンテナにインストールしてNginx設定ファイルを編集するか、docker cpコマンドで該当ファイルをホストに持ってきて編集して戻すか、読み書き可能な設定でバインドマウントしたディレクトリに持ってきてホスト側から編集して戻すかなどの工夫が必要です。
今回は、滅多に使わないツールをインストールしてコンテナイメージのサイズを大きくする意味もないし、今回バインドマウントしたディレクトリは読み出しのみの設定なので、docker cpコマンドのお世話になりました。
なお、ここまでたどり着くのに試行錯誤含めてDockerのインストールし直し1回、Portainer2回、Nginxのコンテナは3個作りましたが、ホスト側はそのままで何回でも試せるのがDockerのいいところですね。
特にコンテナは（リソースが許す限り）何個でも作れて切り替えできるので、条件変えて試したりするのに非常に便利ですし、不具合が出たらそのコンテナをコピーして確認や試験ができるのも魅力的です。
これでNASのマシンとSSDはそのまま、MPD、MPCの設定もそのままで、起動用のMicroSDを差し替えるだけでOMV4とOMV5を切り替えて使えるようになりました。
ところが、この状態でしばらく使ってたら音の途切れが発生。
ディスクのアクセスランプがチカチカし続けるのでSyslogをみたらUASでAbortが出てました。
（ああ、この不具合はBusterでも直ってないのね。。。）
こちらは前回同様、UASドライバーを使わないように設定して事象発生を回避しました。
OMV4と比べてOMV5は起動、シャットダウンがはやいのはいいのですが、アップデートやリスタート、シャットダウン前にDockerコンテナを止めておかないと起動時にうまく上がってこなかったり、最悪ホスト側を巻き込んでおかしなことになったりするので「性能はいいけど神経質で手間がかかる」的なイメージがあります。