subsonic のDBを調べる
定期的にsubsonicのDBが壊れる。
具体的には実際のファイル数よりも明らかに少ないファイルしかスキャンされず、しかも何度スキャンしても状況が変わらない。
そのたびに直近のバックアップをrestoreしているのだが、proxmoxだから手軽に出来ているのであって、いつまでもこんなやり方ではまずい。
なので、出来ればDB(HSQL)の中で何が起こっているのか調べておきたい。
http://hsqldb.org/doc/guide/ch08.html
を参考に。
というわけで先ずは接続。
予めsubsonic の dbディレクトリを適当な場所にコピーしておく。subsonicをstopしてからやったほうがいいだろう。
java -jar /var/subsonic/jetty/[DIR]/webapp/WEB-INF/lib/hsqldb-1.8.0.7.jar --inlineRc URL=jdbc:hsqldb:file:[DB_PATH]/subsonic,user=sa,charset=UTF-8
subsonicの使っているHSQLのjarを使って、予めコピーしておいた subsonic の dbディレクトリを指定して、standaloneで接続して中身を見る、という事をやっている。dbのファイルは subsonic.* という名前なので、接続する時はファイル名を直接指定せずにsubsonicまでで止めること。
passwordは空っぽで良い。
sql> \dt TABLE_SCHEM TABLE_NAME ----------- ------------------- PUBLIC ALBUM PUBLIC ARTIST PUBLIC BOOKMARK PUBLIC CUSTOM_AVATAR PUBLIC GENRE PUBLIC INTERNET_RADIO PUBLIC MEDIA_FILE PUBLIC MUSIC_FILE_INFO PUBLIC MUSIC_FOLDER PUBLIC MUSIC_FOLDER_USER PUBLIC PLAYER PUBLIC PLAYER_TRANSCODING PUBLIC PLAYER_TRANSCODING2 PUBLIC PLAYLIST PUBLIC PLAYLIST_FILE PUBLIC PLAYLIST_USER PUBLIC PLAY_QUEUE PUBLIC PLAY_QUEUE_FILE PUBLIC PODCAST_CHANNEL PUBLIC PODCAST_EPISODE PUBLIC ROLE PUBLIC SHARE PUBLIC SHARE_FILE PUBLIC STARRED_ALBUM PUBLIC STARRED_ARTIST PUBLIC STARRED_MEDIA_FILE PUBLIC SYSTEM_AVATAR PUBLIC TRANSCODING PUBLIC TRANSCODING2 PUBLIC USER PUBLIC USER_RATING PUBLIC USER_ROLE PUBLIC USER_SETTINGS PUBLIC VERSION PUBLIC VIDEO_CONVERSION
で、テーブルの一覧を見れる。\d TABLE でテーブルの定義が見れる。
sql> \d MEDIA_FILE name datatype width no-nulls --------------------- --------- ----- -------- ID INTEGER 11 * PATH VARCHAR 32766 * FOLDER VARCHAR 32766 TYPE VARCHAR 32766 * FORMAT VARCHAR 32766 TITLE VARCHAR 32766 ALBUM VARCHAR 32766 ARTIST VARCHAR 32766 ALBUM_ARTIST VARCHAR 32766 DISC_NUMBER INTEGER 11 TRACK_NUMBER INTEGER 11 YEAR INTEGER 11 GENRE VARCHAR 32766 BIT_RATE INTEGER 11 VARIABLE_BIT_RATE BOOLEAN 5 * DURATION_SECONDS INTEGER 11 FILE_SIZE BIGINT 20 WIDTH INTEGER 11 HEIGHT INTEGER 11 COVER_ART_PATH VARCHAR 32766 PARENT_PATH VARCHAR 32766 PLAY_COUNT INTEGER 11 * LAST_PLAYED TIMESTAMP 6 COMMENT VARCHAR 32766 CREATED TIMESTAMP 6 * CHANGED TIMESTAMP 6 * LAST_SCANNED TIMESTAMP 6 * CHILDREN_LAST_UPDATED TIMESTAMP 6 * PRESENT BOOLEAN 5 * VERSION INTEGER 11 *
readlineなんて気の利いたものは無いので、操作はかなりストレスが溜まる。
あくまで予想、なのだが LAST_SCANNED や CHANGED 辺りがおかしくなっているのではと思い、幾つか調べてみる。
select top 10 * from media_file where artist = '[artist]' and type = 'MUSIC'; : 2013-02-12 01:49:48.0 2013-02-12 01:49:48.0 2016-12-22 00:09:44.479 1970-01-01 09:00:00.0 true 4
これは、CREATED以降のcolumnを調べてみたもの。壊れた時に調べてみればいいか。
parent_path には、ファイルのあるディレクトリが入っていた。
ちなみに、LIMITを使おうとしたら何故かエラーになった。しょうがなくTOPというもので代用している。マニュアルにLIMITはあるのだが。謎だ。
Switch について考えるフリ
Nintendo Switch の第一報が発表されました。
色々と予想や妄想が捗る感じの含みのある発表でしたが、伝えたいことは「着脱可能な本体とデバイスで、遊ぶ場や遊び方を Switch(切り替え)する」ということでしょう。そこに定番のIPゲームの新作/マイナーチェンジ版を織り交ぜ、更に今まで任天堂ハードとは縁の薄かったサードパーティ(ベセスダ)の超有名作を含めるというソフトウェア選択はなかなかに強力です。
しかし、逆に「語られなかったこと」も多くあったと思います。ここで、それらの不明な点に関して予想・妄想を行い、自分の目利きがどのくらいへっぽこなのか、そしてもしかすると意外と鋭いかもという一縷の望みも含めて、誰からも求められていない自分に対する試験を行ってみます。
・タッチパネルの有無
今回の発表では本体の画面を触るシーンは一度もありませんし、触れるような操作画面を出すことは一度もありませんでした。操作に関するガイド的な表示も隠されています。このような構成にした意図としていくつか考えてみましょう。
「タッチパネルでは無いから」
あり得る話です。というか本命にも思えてきます。Switch本体を触って操作する必要性は、「敢えて作らなければ存在しない」からです。昨今のタブレット型デバイスにタッチパネルが存在するのは操作デバイスがそれしか存在しないからであり、Switchには2本のアナログスティック(クリッカブルかどうかは不問)と12個+1〜4個のボタンが存在します。ユーザーはそれらのデバイスを手に収める形になるため、タッチパネルを使用するには一旦それらのデバイスから手を離す必要があります。その際には本体を片手で持つことにもなり、レバー/ボタン操作とタッチ操作を頻繁に切り替えるやり方は、本体のサイズも考えるとあまり合理的ではありません。何より、本体をドックに収めて外部ディスプレイで遊ぶ場合には、そもそも本体の画面に触ることが出来ません。つまり、タッチ操作をゲーム操作に含めてしまうと、遊ぶ場をSwitchする=操作方法をSwitchすることになってしまいます。もちろん、補助的な操作として使うことは考えられると思いますし、本体をゲーム専用機ではなく既存のタブレット機器と同じような用途にも使えるようにするならタッチ操作は利便性を向上させるでしょう。つまり、Switch が多用途を志向するか否かが鍵になります。
「まだ決まっていない」
流石にスケジュール的に厳しいとは思います。発売まで5ヶ月ほど。ハードウェアは何とかなってもソフトウェア側は厳しいでしょう。延期前提ならわかりませんが、他社のソフトの都合もあります。
「タッチパネルだが今回伝えたいことには含まれていない」
こちらも本命でしょう。伝えたいことは前述の通りなので、タッチパネルであるかどうかは問題ではない、ということです。しかし、発表のソフトの中にタッチ操作がそれなりに意味を持つソフトが一つだけあります。「Splatoon」です。しかし主に使われているのはエリア効果の武器だけですし、加えて本ソフトは2画面であることを活かす形で制作されているため、1画面になることでそもそも操作形態がリフレッシュされる事が宿命と成るソフトでもあります。なので、色々変わるけど人気IPだから使った、だけなのかもしれません。
「ただのタッチパネルではない」
こちらも同様に本命に見えます。本命が多すぎて推定になってませんが気にしない。つまり Switch にはまだ秘密があるが、今回は語らない、という方針ということです。
で、結局どうなるのか? 悩みどころですが今のところは「タッチパネルだが今回伝えたいことには含まれていない」にしておきます。「ただのタッチパネルではない」も似ていますが、まずコストの面で既にかなりきつい状態であることが推測できることが反論材料となります。更に、独自の遊び方を提案しすぎてサードパーティを苦しませてしまったWiiUの同じ轍は踏めないだろう、というのもあります。コストの面で云うと「タッチパネル無し」がもちろん最有力になりますし、正直、かなり悩みどころです。51:49くらいの僅差なので、明日には考えが変わっている可能性があります。タッチパネルが無いことによるマイナスをどれくらいに評価するか、ということが判断材料なのですが、本質的には「不要」なのでマイナスはありません。本質的ではない、つまりゲームとは直接関係の無い部分でマイナスが現れます。まずはタッチパネルがないことによる反射的な失望、です。あの形のデバイスでタッチパネルが無いことを想像する人は、今日ではあまり居ないでしょう。当然のように「有る」と思っていたことにより単純にがっかりしてしまうというわけです。ゲームでは使わないのに。このことをマイナスと取るかどうか。任天堂はどちらかというとマイナスに取らない側の会社に思えます(完全に主観的なイメージですが)。となると話は戻り、多用途に使うかどうか、ちょっとずるい言葉に置き換えると「将来性」という意味では明らかにマイナスです。また、「MARIO MAKER」というIPを Switch で展開するならばタッチパネルは有力な選択肢です。ここで初めてタッチパネルが本質論の俎上に上がってきます。ステージ作成の時だけタッチパネルが使えるならば、前述の「操作方法のSwitch」的な混乱は無く、「使い分け」の範囲内に収まりそうです。纏めると、「既存のIPにタッチ操作を前提とするものが多い」と考え、タッチパネルが無いことで生じるマイナスを多めに評価する、というのが今日の気分です。後は共同開発でもあるNVIDIA的には(多用途性も)欲しいんじゃね?みたいな胡乱な考えも少し。
・スペックは?
まず、Switchには元となる機器が存在します。NVIDIA SHIELD の Portable と Tablet です。直近では Tablet の方になり、これは Tegra K1 32bit を使用しています。FLOPSで見ると、周波数次第ですが360GFLOPSほど。PS3とXBOX360のGPUだけのFLOPSは250GFLOPSほどで、WiiUは不明ながらそれ以上(しかし2画面)となっており、WiiUとマルチするタイトルが有る以上は 360GFLOPSは一つのベースラインとなりそうです。そして Tegra K1 は Tegraの最新世代の2つ前(最新のTegra P?は出荷前)です。K1→X1→P となりますが、X1 と P 世代のGPUはそれほど差はありません。X1はMaxwell世代で、K1(Kepler)と比べると消費電力比の性能が向上しています。SHIELD Tablet と形状的には近い Switch は時期的にMaxwell世代以降になるのは必然なので、性能も少しは上積みされるでしょう。といっても 512GFLOPSくらいが上限かなと考えます。ちなみに PS4/XBOX one世代は 1.2TFLOPSから1.8TFLOPSを理論値としています。1.5TFLOPSクラス、としましょう。ここまでを纏めると、GPUだけを見ると、PS3/XBOX360世代の倍、PS4/XBOX one世代の1/3となります。しかしこれはあくまで理論値です。ちなみに512GFLOPSは2008-2009くらいのハイエンドGPUと同じくらいになります。今時のデスクトップ向けで2万円クラスのGPUは2TFLOPSクラスです。現代的なゲームを作る上で、GPUがPS3の倍のFLOPSを持っていれば、まあ及第点な感じはします。CPU側ですが、これは意外にそれほど差はなく、Switch が X1と同等の Cortex-A57 4コアであれば、80GFLOPSクラス。PS4/XBOX oneのJaguarは拡張命令を考慮しなければ100GFLOPSクラスっぽいです。とは言え消費電力的には Switch側はタブレットクラス、PS4/XBOX one側はノートPCクラスのCPUなので、理論値以上の差はあるでしょう。補足ですが、XBOX360のCPUも100GFLOPSクラスであり、単純にFLOPSでは比較できない差があるか、ゲーム用のCPUはこのくらいの性能で充分と判断されている(更に言えばGPGPUをミドルウェアが活用している)かどちらかなのでしょう。更に補足すれば、発表の中で出てきたSkyrimの推奨環境は500GFLOPSクラスのGPUとなります。GTA5になると必要環境が500GFLOPSクラス、推奨が3TFLOPSクラスになっています。まあ、GTA5はPS3/XBOX360版もあるので正直FLOPSだけで語るのも限界はあります。
比較対象になる SHIELD Tablet は ANDROIDを採用していますが、Switchは独自OSです。また、専用にNVIDIAが作成したNVNというミドルウェアが用意されています。このNVNがどのレベルをカバーするものかは良くわかりません。ゲーミングAPIという呼称が使われている事から、Unrealなどのゲームエンジンのようなものを想像しますが、今時そのようなものを独自で作るメリットがあるとも思えません。OSの上に被せてハードウェアを使いやすくまたは差異を吸収するためのものかも知れません。さて、独自のOSを作る意味というのはハードウェアを叩くためのAPI層を薄くするため、というのが大きいでしょう。まあ、独自と行ってもLinux系やBSD系などのOSS系のOSをベースにしている可能性もあります。(実際、PlayStationはその方向です)ともあれ、このようにハードウェアに最適化されたミドルウェア層を作ることで、同様のハードのAndroidベースのハードよりも高いパフォーマンスを得られるように設計されているのでしょう。また、タブレットとしての使用の際には画面の解像度に合わせて解像度を落として必要パフォーマンスを調整したり、逆に据え置き時にはタブレット専用のものよりも高い周波数での動作が可能なようにして最大性能を上積みしたり、専用のハードウェアであることを活かした調整を行ってくるでしょう。
・ちょっとした過去のまとめ
3D世代以降の据え置きゲーム機のCPU/GPU。ベンダー名は現在の当時のものではなく今のものにしてある。SONY系は全てSONY表記。細かいところは適当。
| 任天堂 | CPU | GPU | SONY | CPU | GPU | MS | CPU | GPU | SEGA | CPU | GPU |
|---|---|---|---|---|---|---|---|---|---|---|---|
| N64 | MIPS(SGI/任天堂) | MIPS(SGI/任天堂) | PS | MIPS(SONY) | 独自 | - | - | - | Saturn | SH(日立) | 独自 |
| GC | PowerPC(IBM) | 独自(AMD) | PS2 | MIPS(SONY/東芝) | 独自 | Xbox | IA(Intel) | カスタム(NVIDIA) | DC | SH(日立) | PowerVR(Imagination/NEC) |
| Wii | PowerPC(IBM/任天堂) | 独自(AMD) | PS3 | PowerPC(SONY/IBM/東芝) | カスタム(NVIDIA/SONY) | XB360 | PowerPC(IBM) | カスタム(AMD) | - | - | - |
| WiiU | PowerPC(IBM/任天堂) | カスタム(AMD) | PS4 | IA(AMD) | カスタム(AMD) | XB One | IA(AMD) | カスタム(AMD) | - | - | - |
| Switch | ARM(NVIDIA) | カスタム(NVIDIA) | - | - | - | - | - | - | - | - | - |
ARM系のCPUは据え置きのメインストリームでは初めて。NVIDIAはAMD独占を崩そうと積極的に売り込んだ可能性高し。Tegraの戦略が紆余曲折した結果、いい感じで任天堂の要求と合致したのかも知れない。
TegraはGPU専業からの脱却を狙うNVIDIAの戦略から生まれたものと思われる。過去にはnForceというチップセットによって、GPUだけでなくPCにおけるCPU以外のベース部分までマーケットを広げようとした。一定の成果はあったものの、徐々に縮小し撤退。GPGPUは成果を収めたが一般的なコンシューマのマーケットではない。TegraはARMベースのCPUの採用により、CPU/GPUを含めたSoCとして開発された。ほぼ自社製のプラットフォームというのに同社の強い執着を感じる。鳴り物入りで市場に出たものの、最もフォーカスしていたスマートフォンの市場はTegra3の世代でほぼ手放したと言って良い。性能偏重による発熱問題で悪いイメージが付いてしまったことと、モデムがSoCに含まれていなかったことが、同業他社に遅れを取った。これはIntelでさえも同様だった。Tegra4でようやくモデムを内蔵したものの、スマートフォンには殆ど採用されずに、主な搭載機種はタブレットになってしまった。運良くタブレットの市場が立ち上がって何とか次に繋がるかと思われたが、高機能タブレットはWindowsタブレットという競合に食われ、更にタブレット市場がそれほど広がらなかったことから、その道も途絶えた。そこで、Androidベースのゲーム機に活路を見出す。Tegra3がOUYAに使われた事もきっかけだったのかもしれない。Tegra4で、独自のAndroidベースのゲーム機SHIELDを立ち上げる。問題は、NVIDIAはゲーム開発において1stパーティではなかったこと。AndroidベースのAAAクラスのゲームなどは少なく、携帯ゲーム機然としたハードウェアを活かす事は出来なかった。そこで実績のあるGPGPUとしての能力を活かすべく、TegraをCUDAコアベースにしたのがTegra K1以降になる。その計算能力を活かして自動運転の車載システムやDeepLearningなどの用途も視野に入れつつ、SHIELDなどの高性能ポータブルマシンの道を模索することになる。そして、CUDAコアベースにした事はゲーム用のGPUとしての市場性も高めた。SwitchはSHIELDで成し得なかったコンシューマゲーム機のメインストリームの道を切り開く、まさしく捲土重来の機会と言える。AMDのAPUというPCの方ではいまいち乗りきれなかったシステムがコンシューマゲーム機によって成果を得たのに近い形かも。
・プレーシェアは?
NVIDIA ShadowPlay を SHIELD Tablet で採用しているので、可能性はあります。用途が謎のボタンが左側にあるのでそこなのかもしれません。
・ジャイロ系は搭載する?
おそらく搭載するのでしょうが、本体側(つまりタブレット側)に搭載するのは一見効率が悪そうなので Joy-Con側になるでしょう。問題はJoy-Conが非常に小さく、更にプレゼン動画ではワイヤレスでの使用も提示されていたため、「ワイヤレス」「バッテリー」に加えて詰め込める余地がどれほどあるのか、という不安につながります。ワイヤレスで使わない場合は有線接続となり必要ならバッテリーの充電も行うことになるとは思うのですが、ますますワイヤレスで使用する際の負担が大きくなりそうです。つまりワイヤレスの使用をあくまでおまけ的に考えて(絶対に必要に成るのは複数人同時プレーの時だけですし)、バッテリーの保ちをそれほど重視せずに最低限のバッテリーで済ませる(最大でも本体のバッテリー持続時間だけ保てばいいわけですし)、あるいはBluetoothではなくZigbeeを使用するなど別の手段でバッテリーの負担を軽減する、更にあるいはJoy-Conに複数のタイプを設けて高機能版をオプションにする、などなど、様々な予想が可能です。
さて、それらをクリアしてまでジャイロをつける価値はあるのか? 現状では「価値はある」という答えになってしまうでしょう。ジャイロを活用したモーションコントローラを推進してきたのは他ならぬ任天堂ですし(携帯ハードのカートリッジに内蔵してまで!)、Joy-Conという小型コントローラの可能性を広げるにはもってこいの装置です。2人同時プレーを本体だけで可能なのはプレゼン動画を見てもわかりますが、これはライトゲーム向きの機能であり、ライトゲームにはジャイロが活躍する場面が多くあるでしょう。あれ、2人同時? ...そうです。ジャイロが2セット必要なのです。正直コスト的にはかなり厳しいハードウェアだなと思ってしまいます。余談ですが、このようなサイズのジャイロ内蔵ワイヤレスコントローラとして現存するものはなんでしょうか?すぐに思いつくのはAppleTVのSiri Remoteです。こちらは IRとBluetoothのハイブリッドになっています。電池の保ちも充分で「なんだ、可能じゃん」と思えなくもないですがお値段10000円弱。もちろん、タッチパッドやマイクなどの不要な機能もあるので比較対象にはならないですし、ジャイロを搭載しても問題なし、という証明にはなるのですが。
最後に、これは後に分かったことですが振動ユニットにも特殊なものが搭載される可能性がある、らしいです。リークなので眉唾ですが。正直、外野(ユーザ)はあのちっこいJoy-Conにどれだけ夢を詰め込むつもりだ、と思わなくもないですが。こちらの話が正しければ、ジャイロをタブレット本体とコントローラのドックだけに搭載してJoy-Con単体には付けない(これでもジャイロの数は2個なので同じ)、というのもアリだと思えてきます。しかし、本体はまだしもコントローラドックにデバイスを組み込むのは綺麗な発想だとは思えません。あれはただJoy-Conにフレームを与え充電のためのインターフェイスを与えるもの、つまりdumbなデバイスであってこそのものだと思います。余計に装置を分散させるのはあらゆる意味で賢くない選択です。
見ての通り揺れまくりでブレブレの想像ですが、Joy-Conは全部入りのちっちゃくて高性能なデバイス、というのが願望にも近い最終的な考えです。
・値段は?
これに関しては、任天堂だから高くても(下位モデル限定かもしれないが)30000円を切る、という分析もへったくれもない考察が可能です。しかし、本製品には逆ザヤは無いと明言されているのでもうちょっと考えてみましょう。SHIELD Tabletは現時点で199ドルです。それなりに高性能とはいえ、モデムのないタブレット端末としては(利益をそれなりに削れば)このくらいにはなる、ということです(逆ザヤじゃなければ、ですが)。ここからまずカメラとモーションセンサを省きます。そしてJoy-Conを2つとドックの値段を足します。コントローラドックに関しては、下位モデルでは省かれるかも?なんて思っていますが、これはちょっと悲観的すぎるかもしれません。Joy-Conを30ドル、ドックを30ドル、コントローラドックを15ドルと妄想(希望的観測)すると本体+105ドルが値段になります。で、本体をそのまま199ドルとすると304ドル。なんだか、30000を切るのが現実味を帯びてきます。しかし正直にいうと、SHIELD Tabletはほぼ利益度外視の値段になっていると思われるので、どれだけSHIELD Tabletをシェイプアップ出来たが肝かなと思います。ディスプレイは8インチよりも小さくなるのではないかと思いますし、前述のカメラやセンサを外したり、SoCのカスタマイズでコストも下がるでしょう。具体的にはTegraの省電力側のCPUを省略する、という方法がありえます。それらのコストダウンで、GPUのコストアップを相殺しつつ、スケールメリットも含めていけば..下位モデル28000円くらいには、なるのかなあと、なって、ほしいなあと。
さて、無駄な考察を続けてきましたが、こうして分かることは「コントローラ周りの悩みは任天堂史上最大なのでは?」ということです。もちろん、任天堂自身は特に悩まずに粛々と必要なものを搭載し不要なものを搭載しないだけなのかも知れませんが、プレゼンの時点でオプションを除いた操作形態が(1)コントローラドック使用 (2)Joy-Conタブレット装着 (3)Joy-Con 分離 1人使用 (4)Joy-Con分離 2人使用 と4パターンも存在しているため、どこになんの機能が搭載されているかで、形態毎に何が使用できるか(あるいは使用できないか)が変化する可能性が出てきます。正直、このようなことをユーザに考えさせるのはメーカの本意では無いと思いますので、なるべく「変化しない」ようにするとは思うのですが、そうなるとコストやバッテリー、搭載スペースなどの悩みが噴出することでしょう。小型で多機能なワイヤレスデバイスを標準で2個付けなければならないわけですから。そう、Switchは一見、据置機と携帯機の垣根を無くすハードであり、そこに知恵が絞られているように思えますが、実は過程で生まれたJoy-Conというハードウェアをどのように形にするのかというのが任天堂に与えられた大きな課題で、形に出来たからこそSwitchを発表できた、のかもしれません。
Subsonic の SSL化(続)
色々と試したり調べたところ、port の変更は出来ない模様。 --http-01-port で変更できるかもと思ったが test 実装と書いてあり、思ったようには動作してくれなかった。まあ、443は外部公開していなかったので一時的に開ける。
./certbot-auto certonly --standalone --standalone-supported-challenges tls-sni-01 -w /var/www/html -d DOMAIN
で一応うまくいった。
次は nginxの設定。
listen 54040 ssl default_server;
listen [::]:54040 ssl default_server;
server_name DOMAIN;
proxy_set_header Host $http_host;
location / {
proxy_pass http://SUBSONIC;
proxy_redirect http:// https://;
}で、取り敢えず接続できた。色々と詰めなければいけないところもあるが。
で、今度は renew の為に色々と試してみたのだが、webroot を使った cert がうまく動かなかった(これも portが443じゃないせいなのかも)ので、standaloneを使うことでひとまず回避することに。
で、nginxがそのportを使ってないのをいいことに、nginxは止めずに更新後 restartするようにした。restart が必須かどうかは調べていないが、まあ問題はないだろう。
サーバについて色々
Subsonic を Let's encryptとnginxで、ちゃんとしたhttpsにしたわけだが、他にもそうしたいサーバはある。しかし、現状では Subsonicのサーバでnginxを動かしており、普通のやり方ではこれ以上は証明書を発行できないだろう。
で、案としてはnginxのreverse proxyを別サーバにして、そこから各種サーバに対してproxyするというやり方。port別にproxyを振り分けることが出来ればurlなどは変化させなくて済みそうだし、証明書も一つですむ。現状で、httpのリクエストをhttpsにredirectすることがうまく行ってないので、それを解決できれば良さそう。
今後の課題。
Subsonic の SSL化(案)
Subsonic 6.0にしたあと快調に動作していて不満はないものの、5.x + OSX の時から定期的に発生していた、オレオレ証明書であることを理由にブラウザ(Chrome)に弾かれているのに、警告画面が出ないために無視する選択肢が出ずに、表示が出来なくなる。暫く放置すると警告画面が出る、という謎の現象は治らず。そろそろ、ちゃんと証明書を作ろうと決意。
証明書はLet's Encryptのものを使うことにする。現状の案としては、nginxをreverse proxyとして SSL関連を処理。Subsonic標準の https機能は無効に。ちょっと調べて、Subsonic側の証明書を変更する方法もあったのだが、証明書をcatしてjarにする必要があるようで、ちょっと面倒だし、問題の切り分けがしにくそう。nginxとLet's Encryptの運用は情報が多いし、証明書更新の自動化も楽そうだ。
apacheを使わないのは、reverse proxy専門ならnginxでしょという短絡的な考えから。
とりあえず、nginxとgitをinstall。
最近、Let's Encrypt の client は、certbot という名前になったらしい。
$ git clone https://github.com/certbot/certbot $ cd certbot $ ./certbot-auto certonly --webroot -w /var/www/html -d DOMAIN
で、色々とパッケージがinstallされ..って、40個以上入るのか。それなりに大掛かりというか..
ちなみに、Ubuntu16.04で用意されている client を使うのも良かったのだが(というか、本家サイトのチュートリアルはそっち)名前がletsencryptのままだし、せっかくだから最新を。
で、実際に certbot-auto を動かしたところ、port forward 設定が正しくなかったためにエラーが。
続く。
Subsonic 6.0の準備
少し前にSubsonicが6.0になりOSSでは無くなった。
理由は HTML5への移行により、再生環境構築のためプロプライエタリなライブラリを使用しているからだという認識。かなり動作が変わる上にOSSであることを放棄したためにコミュニティでもそれなりに反発や動揺はあるようで、自分も少し前に移行を試したもののあまり気のりはしなかった。
が、OSX(macOS)からの移行をすすめるにあたり、flashへの依存もなるべく減らしておきたいのも事実。というわけで再度試すことにする。
そのためのメモ。
今回、Ubuntu 14.04から16.04への移行も同時に行う。
Javaのインストール
Java7以降が必要。16.04のopenjdkは8以上なので、
apt install openjdk-8-jre
フォントの設定
何も考えず、以前から使っていた Takaoフォントを使用する。
apt install fonts-takao
javaから使用する設定。この辺も以前のものをそのまま。
mkdir -p /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/fonts/fallback cd /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/fonts/fallback ln -s /usr/share/fonts/truetype/takao-*/Takao* ./
proxmox の bindmount
まあ、これは自分の環境に依存するものだが、/etc/pve/lxc/xxx.conf に追記。
locale apt install language-pack-ja
で、locale -a に ja_JP.UTF-8 がなかったら
locale-gen ja_JP.UTF-8
で作成。
update-locale LANG=ja_JP.UTF-8
で設定。これに関してはとにかく動いたからよし。
timezone timedatectl set-timezone Asia/Tokyo subsonic install dpkg -i subsonic-x.x.deb
あとは db を入れ替えたり。
subsonic.properties も一緒にコピー。ライセンス情報も一緒にmigareteしてくれるはず..?
で、今のところ random が出ないくらいで特に問題はなし。おそらくrandomはdbを更新すれば出るんじゃないかと予想。使ってないし、別にいいか。
暫く、試用してみる。
OSXからの移行作戦4
Thunderbird のメモリ消費量の件は取り敢えず落ち着いた模様。
前回の対応が効いたかどうかはわからないが1Gを超えるような有様にはなっていない。
ちなみにキーボードは logicool k380。bluetooth で、特に問題なく使えている。機能的にも複数のペアリング切り替えに対応していたり、値段の割には気が利いている。ちなみにこれにした理由はMacboook で使っていた apple の bluetoothキーボードと配置が似ていたから。特にボリュームなどがコンビネーション無しに使えるところ。とにかく、以前の環境をなるべく変えない、と云うのが当面のジャスティス。
細かな問題として、drag&dropの挙動が浮上。ダブルクリックや「開く」などのメニューを使う分には問題ないのだが、d&dだとsmb経由でのファイルのurlが smb:/ になってしまう。このようなスキーマ付きのurlを一部のアプリケーションは使えない。VLCはsmbプロトコルのプラグインらしきものがあり、そこにユーザ名やパスワードを入力しておけば開けるのだが、かなり例外的。まあ、d&dをあまり使わなければいいのだが。
Skypeの前に google Hangout を使ってみる。カメラが非常に暗かったので guvcview をinstall して調整してみた。まあ、この調整が反映されるかは試してないのだが。
Empathy を自動起動に。
cp /usr/share/applications/empathy.desktop ~/.config/autostart/
みたいな感じ。
