謎のサブタイトルの由来はアニメ「ゆるゆり」
生徒会長の名台詞、「罰金バッキンガムよ！」に由来する
今回取り扱うソフトがchinachuだからだ。
このソフトの名前の由来がアニメ「ゆるゆり」の吉川ちなつ。
（私はchinachuの研究の一環でわざわざ「ゆるゆり」を
1期2期通して見たw）
前回記事でおパンツは鑑賞も録画もできるようになったのに
今更なぜchinachu？というとひとつは番組表だ。
いちいち番組表をどこぞのHPで確認して
録画開始時刻までの残り時間を秒or分で計算するのは面倒だ。
おパンツの開始時刻と終了時刻から録画時間を秒or分で
計算するのも面倒だ。
chinachuなら番組表が見られる事に加えて
右クリックで特定のおパンツを録画指定ができる
放送時間の変更にも対応している。
毎日or毎週同じおパンツを継続録画もできる。
確かに番組表のプログラムは過去にも複数存在した。
しかしそれらの中には既に開発終了したものもあり
古くなったせいで脆弱性を抱えるという説もある。
参考リンク
epgrecは日経Linux2009年8月号掲載用に作られたが
2011年時点で開発が停止していて現在は脆弱性あり云々
参考リンク
「またepgrecを狙った攻撃がありました」
というタイトルのブログ記事
日本のおパンツサーバーが狙われる理由のひとつは
日本のアニメその他を見たいという需要があるかららしい。
参考リンク
勿論これはWOWWOWのタダ見的な需要でもある。
（そもそも無料のテレビを"タダ見"とは矛盾だが
海外の人間目線で考えるなら日本のおパンツは放送されない、
イコール見たければDVD買え、イコール有料という事になる）
またepegrec自体にもアクセス権的に甘い面がある云々。
参考リンク
ここではepegrecのどこが脆弱性なのか
具体的にプログラミング的に多少解説している。
参考リンク
ここではパソコンを乗っ取られる的な被害の内容について
多少書いてある。
一方chinachuは現在進行形で開発中。
そういう諸々の理由でchinachuを入れる。
さて、公式のインストール方法はこのへん（リンク）
まずはmirakurunのインストールから行う事になる。
動作環境はこのへん（リンク）
一応centosも動作環境に入ってはいる。
しかしこのchinachu 実は推奨のOSがdebianである。
たとえばここ（リンク）ではdebianだけ太字にされている。
とりあえずはNode.jsが必要。ここのページでは
Node.js ^6.5.x || ~8
という微妙な書き方をしている。
一瞬何の事かわからないがこれはNode.jsの文法に基づく表記。
参考リンク1 参考リンク2
ここのHPでは多少マシな書き方をしている。
Node.js >=6.5.0 <7.0.0 or >=8.0.0 <9.0.0 needed.
つまりNode.jsが必要だがバージョンに条件がある。
具体的には「6.5.0以上7.0.0未満」または
「8.0.0以上9.0.0未満」
しかし厳密には、この2つのバージョンの記載方法は
中身が矛盾している。
最初の^6.5.x || ~8 これは6の左にキャレット(^)が付いている。
これは「最新版」を意味するので
単に「6.5.0以上」としか書いていない2つめの条件とは食い違う。
またバージョン8は不安定だと主張するHPもある（リンク）
しかし本連載では基本的に最新版のソフトを入れてきた。
だから今回も受けに回ってはダメだ。徹底的に攻めで行く。
ばっちこーいw
そこでNode.jsは8系を入れてみる。node.js本家参照。$ curl --silent --location https://rpm.nodesource.com/setup_8.x | sudo bash -
//これは本家の記載
# curl --silent --location https://rpm.nodesource.com/setup_8.x | bash -
// そこで私はこう（↑）してみた
# yum install nodejs
# node -v
v8.9.4
# npm install pm2 -g
# npm install mirakurun -g --unsafe --production
// この辺から赤字でerrorが出たりして不穏な空気になるw
// おい、8系入れようとか言った奴誰だ！ ^o^ わたしです
# pm2 status
// mirakurun-serverがonlineなら成功
# EDITOR=nano mirakurun config server
// 設定に入るが、ここは何も設定しなくてもよい
// せいぜい最後のポート番号変えるぐらい
# EDITOR=nano mirakurun config tuners
// 設定に入る。初期状態では全チューナーisDisabled:trueで
// 無効化されているからそれを解除する
// 使うチューナー全てに関してtrueをfalseに直す
# EDITOR=nano mirakurun config channels
// ここではチャンネル名とチャンネル番号修正必須
# mirakurun restart
// mirakurun再起動
# npm install rivarun -g
// rivarunインストール recpt1みたいなもの
# npm install arib-b25-stream-test -g --unsafe
// 復号処理に必要なもの
$ rivarun --list | sed 's/},/},\n/g'
// 動作確認1
$ rivarun --list | sed 's/},/},\n/g' | grep -v serviceId
// 動作確認2
$ rivarun --b25 --ch GR/666 777 destfile.ts
// 動作確認3
よしよし動いてる動いてるいいなあーワクワクするなー
と真希波マリばりに喜んでいたのも束の間
PCを再起動後はmirakurunが起動しない事案発生（爆w
（某マリー＝アントワネット）
# mirakurun restart
// これで手動で正常動作確認
// この時mirakurun-serverがonlineになる
// しかしPCを再起動するとやはり動かない。
// だからと言って毎回毎回手作業をするのは面倒
# pm2 start mirakurun
// 再起動後にこれを打ってみるとmirakurun-serverではなく
// mirakurunがonlineになる そしておパンツ鑑賞不可
# mirakurun restart
// 続けてこれ（↑）を打つと mirakurunはerrorになる
// しかし mirakurun-serverはonlineになる そして動作おｋ
# pm2 start mirakurun-server
// 再起動後にこれを打つと
// [PM2][ERROR] script not found と出た。
// もちろんおパンツ鑑賞不可
一体悪いのはどこだろうか？
そもそも"mirakurun"と"mirakurun-server"の
2つが存在するのは正しい状態なのか？
ここ等を見るとそもそもmirakurun-serverしか無いのが
正解のような気がする。
もしもmirakurunが壊れていたら
# mirakurun restartを打った程度で正常動作はしないはず。
よってmirakurunそのものは生きている可能性が高い。
問題があるとしたら起動方法？OS側の設定？
もしくはdebian推奨のソフトをcentos7で動かしているから？
（これは作者が動作環境にcentos7を入れているのが
ウソでしたという可能性すら込みでの話になる）
PC起動後に# mirakurun restartで動くのだから
まずはこの作業さえ自動化されればいいのでは？と考えた。
mirakurunは起動にはsystemdを使っている。
そこでsystemdについて調べた。その結果、ここ発見。
記載内容に基づき /etc/systemd/system/ を見てみた。
その結果、pm2-asahinamikuru.service発見
名前から推測してこれが設定ファイルに違いない。
開くと
ExecStart=/usr/lib/node_modules/pm2/bin/pm2 resurrect
と書いてあった。
要はこの1行がPC起動時に実行されればいいはず。
一旦PCを再起動して、手動でpm2 resurrectを打つと
正常に動作する。
手作業でできる事がなぜ自動処理できない？
もう一度PC再起動して
# systemctl start pm2-asahinamikuru.service
こう打ってみた所、以下のエラーが発生
Job for pm2-asahinamikuru.service failed because the control process exited with error code. See "systemctl status pm2-asahinamikuru.service" and "journalctl -xe" for details.
# systemctl status pm2-asahinamikuru.service
# journalctl -xe
をそれぞれ実行すると、どちらの場合も赤字で
Failed to start PM2 process manager.
と出てきた。
このメッセージでぐぐるとこれ発見
Startup for systemd fails if user is not root
...管理者権限の問題なのだろうか？
根拠1 ここ（リンク）でもやたらとsudoが出てくる
根拠2 ここ（リンク）で
>mirakurunの非rootユーザでの実行を許可してほしい。
という一文あり。
作者はその提案にかなり否定的な態度で返答をしている。
つまり、やはりroot権限を使っている。
根拠3 ここ（リンク）
>なにかMirakurunが仕事しない時（中略）
>recpt1がsudoで使えない（rootでパスが通ってない）
>状態でした。通常ユーザーだと使えるので気づきにくい。
つまり通常ユーザーでやれば済む事すら
root権限を取得してから作業している。
そこでpm2-asahinamikuru.serviceを編集してみた
User=asahinamikuru
これ（↑）を、こう（↓）書き換えた。
User=root
この結果、正常動作確認 PC再起動してもおｋ (ﾟдﾟ)ｳﾏｰ
ちなみに最初からsudoが使える設定でOSを入れなおしてみたが
mirakurunはやはり# mirakurun restartが必要だったので
sudoの多用が原因ではないらしい。
だとしたらchinachuはrootで動きたがる行儀の悪いソフトだ
という事になる。
作者自身は利便性と安全性のバランスを考慮したらこうなる
と謎の主張をしている。（リンク）
特権が必要な作業とは今後実装される予定の
「負荷状況に応じたプロセス制御や自動アップデータ対応」
を想定しての話だという主張だ。
（つまり、現状は必要も無いのにroot権限を要求していると
認めた事になる？）
挙句の果てには
「現実的なセキュリティ対策を講じる事が本質であって
rootかどうかは主題ではない」と謎の主張で案件終了w
...？？ 何が言いたいんだかよく分からない。
rootであれば他の一般ユーザーにかけられた制限を取っ払う事ができる。
それは見られないものも見られるようになる、
消せないものも消せるようになる、
書けないものも書けるようになる、
実行できないものも実行できるようになる、という事に他ならず
まさにセキュリティの話題だと思うのだが違ったのか？
「負荷状況に応じたプロセス制御」とは何だろう？
日本のおパンツ放送はBCASだの何だの
ゴミみたいなシステムのせいで暗号化、復号化の
二度手間な無駄が多い。
そういう無駄を飛ばして本来の生データそのものを
記録するのなら、tsファイルの録画など
atomでも十分間に合うレベルの低負荷でしかない。
元から低いのに今更負荷状況もヘッタクレも無いと思うのだが
仮に高負荷があるとしたらエンコードかリアルタイム視聴か。
「プロセス制御」の具体的内容が不明だが
仮にCPUの処理が追いつかない場合に優先順位を
上げるor下げるとかそういう話だと仮定をするなら
リアルタイム視聴は優先順位を下げられては困る。
音や映像が切れ切れになる可能性があるからだ。
逆に上げるのも無理。CPU使用率100%であっぷあっぷの
ゴミCPUのケツを叩いた所で
オーバークロックできる訳ではなかろう。
CPUの処理能力が追いつかないのならもっといいHW買えとか
そういう話になる。管理云々の話ではない。
一方、エンコードなら優先順位を下げられるのかもしれない。
しかし現状ではchinachuはffmpegはインストールしているのに
別途グローバルでもインストールしろとか謎の主張をしている。
・・・また出た。謎の二度手間だ。
ffmpeg使う気なんか本当にあるのか胡散臭い状態だ。
...。一体何をどう管理したいんだろう？
この作者が一体どういうつもりかわからないので
githubを見ていると、ここの左の方にここへのリンクがある。
開くと、「れいさ」なる人物（？）のリンクがある
worksにchinachuやmirakurunが並んでいるので
ここが作者のHPで間違いないようだ
れいさ / re1s ( 菅祐貴 / Yuki KAN)
...誰？ これが本名？
Microsoft MVP for Microsoft Azureだそうなので
リンク先を見ると顔写真が出ている（本人？）
同じページにはLanguage Japanese, English, Korean
とも書いてある。なぜKorean？
名前が菅なのはもしかして在日だったのか？
私はkanreisaと名乗って作者がいろいろ書いているのは
管理者＝kanrishaをネットスラング的に文字っているのかと
今まで考えてきた。まさかカン＝レイサが本名？韓国人？
（今更在日ごときでビビる私ではないが）
同じプロフページからリンクを辿ると
ここにはCEOで菅祐貴と出ている。やはりこれが本名？
べつに本名だろうが偽名だろうがどうでもいい話ではある。
この作者の考えが私の考えとはだいぶ違うというそういう話だ。
自動アップデータなんか究極これはネットワーク経由の
リモート操作すら許しかねない話題だと思うのだが
（あくまでも"究極"）
究極なんて言うのなら私自身が番組表データの取得や表示を
プログラミングすればいいという話にもなる。
それはchinachuを捨てる事にもつながる。
いや、何なら今すぐにでもchinachuを捨てられなくはない。
番組表ぐらい、どこぞのHPを見てしまえばいい。
コマンドラインでパチパチと手打ちでrecpt1使ってもいいし
現在時刻から録画開始時刻までの秒数を計算して
自動的に待機時間を考慮したコマンドに変換する...
その程度のプログラムなら今すぐにだって書ける。
とりあえずはmirakurun, rivarunと入ったので
chinachu gammaインストール開始
ここには書いていないが、ここには
以下のソフトをインストールしろと書いてある
# yum install wget curl yasm
多分バージョンが上がる過程で必要が無くなったのだろうか？
ちなみにyasmはepelに存在する。
何も知らずにコピペだけで設定しようとすると躓く所だ。
相変わらずcentosに冷たい作者であったw
これに限らず、この公式HPは記載が不十分な内容がある。
私が過去に試した時は以下のソフトも入れる必要があった。
これはffmpegを入れる時の依存関係と酷似している。
しかしベータ時代とガンマ時代で違いが出てきているので
これはあくまでも参考
# yum install cmake freetype-devel gcc-c++ libtool mercurial nasm zlib-devel gcc make automake autoconf git pkgconfig
ではいよいよchinachuインストール開始
$ git clone git://github.com/kanreisa/Chinachu.git \
~/chinachu
$ cd ~/chinachu/
$./chinachu installer
// ここはAutoを選択する。ベータ時代に試してみた所、
// 2のfastはchinachuの便利機能が何ひとつ入らないので
// 番組表閲覧すら不可 無い無いづくしで使い物にならない
// 6のepgdumpを入れれば番組表閲覧・予約録画までは可能。
// しかしリアルタイム視聴が不可
// 適当にコーデックを入れたりffmpegをコメントアウトしたら
// インストール終了はするがリアルタイム視聴不可になる
// （画面は黒いままでログにはエラーも無い）
// 面倒臭いから結局フルで入れるのが速い
$ cp config.sample.json config.json
// 設定開始
$ nano config.json
// 以下公式HPより設定の説明
"uid" には通常1000または"実行ユーザー名"を指定
"vaapiEnabled"をtrueにするとストリーミング再生時に
HW支援を使用します。
別途ffmpegをビルドしてグローバルに
インストールする必要があります。
Chinachuが内部ビルドしたffmpegは削除してください！
(./usr/bin/ffmpeg) （以下略w
なるほど。いまだにffmpegを「内部ビルド」している訳だ。
なぜ「内部ビルド」なんてしておきながら
別途グローバルにインストールしろと言い出すんだろう？
「内部ビルドは削除してください！」なら
初めからそんなものインストールしなければいいのでは？
相変わらずよく分からない人だ。
この辺を疑問に思ったので、私はffmpegをインストールせずに
先にchinachuを入れてみた。
その結果、vaapiEnabledがfalseであるにもかかわらず
リアルタイム視聴時に画面にエラーが出た。
コンテナ形式やコーデックを変えてみてもエラーが変わるだけで
音も映像も出なかった。
それがffmpegインストール後は解決した。
やっぱりよく分からない人だ...。 とりあえず設定の続き。
$ echo [] > rules.json
// 空のルール設定ファイルを作成
$ ./chinachu service wui execute
// 問題なく起動できたらCtrl+\で終了
$ ./chinachu update
//EPG取得テスト
この後ベータ時代とガンマ時代で
設定方法が違ってきている
【ガンマの場合】
sudo pm2 start processes.json
sudo pm2 save
再起動して正常に起動できるか確認する
...問題なのは再起動しようが正常に起動なんかしない件だ。
相変わらずよくわからない人だ...。
作者に質問でもしてやろうか？とは思った。
しかしここではmirakurunの問題を質問してきた人に
英語で質問を書きなおせと答えている。しかも最後の最後は
「PM2の事は俺に聞くな。PM2の作者に聞け」で終了w
まあ、私なら最初から英語で質問してもいいけど。
debianを推奨している人だから
あまり相手にしてくれない可能性もある。
一人で試行錯誤していると、ガンマの設定の後に、更に続けて
ベータ時代の設定の後半を行うとchinachuが動くと気づいた。
【ベータ時代の設定の後半とは下記】
./chinachu service operator initscript > /tmp/chinachu-operator
./chinachu service wui initscript > /tmp/chinachu-wui
sudo chown root:root /tmp/chinachu-operator /tmp/chinachu-wui
sudo chmod +x /tmp/chinachu-operator /tmp/chinachu-wui
sudo mv /tmp/chinachu-operator /tmp/chinachu-wui /etc/init.d/
sudo insserv chinachu-operator
sudo insserv chinachu-wui
sudo service chinachu-operator start
sudo service chinachu-wui start
...しかもこれは完全にdebian系の書き方である。
centosではこの設定は不可能である。
単にsudoがどうとかそういう話ではない。
sudoぐらいcentosでも使おうと思えば使える。
まず、このベータ時代の設定で問題になるのは
insservはdebian系のコマンドであってredhat系には存在しない
という点だ。redhat系はchkconfigを使う。
しかし今回はcentos7だ。
centos7ではchkconfigがsystemctlに変わった
ではsystemctl enable ...と思ったらそう単純ではない。
これはエラーが出る。native serviceではない云々。
で、結局insservの2行の所は...
# chkconfig chinachu-operator on
# chkconfig chinachu-wui on
...こう書くのが正解
あとはベータ時代の設定方法そのままで動く。
ただ、動くのはいいがWUIにアクセスの時に
127.0.0.1が使えないのはなぜなんだろうか？
ローカルIPを使う必要がある。
例えばhttp://192.168.1.2:20772
相変わらずよくわからない人だ...
しかも未だにOS再起動後は
$ sudo mirakurun restart
これが必要なんだが。この問題はまた検証予定。
最後はお約束のひと言をオナシャス
「黒幕はキリスト教徒！」
0 件のコメント:
コメントを投稿