屑籠というかゴミ箱

主に家のサーバーの遍歴と使った製品のレビュー

Paperless-ngxを追加

経緯

最近自宅のサーバのスペックが上がってCPUとかメモリとかかなり遊んでいるので自宅ホストのサービスを増やしちゃお、ってことでこれまでドキュメントスキャナでPDF化だけしてHDDに眠っていた書類たちをPaperless-ngxにまとめてみることにした。
Paperless-ngx使えなさそうでもHDD管理に戻るだけなのでひとまず試してみるということで構築

構成

今回もRHEL10のサーバを使ってPodman ＆ docker-composeをsystemdで管理する構成で。
wallabagも同様だったので同じ仮想マシンで動かす構成。

外部公開はいつも通りCloudflare Tunnel＆Access

追加設定

基本的には標準のcompose.ymlファイル構成で、追加の設定として

  • NASをマウントしてmediaディレクトリとして使用する場合Sambaだと難しそう（Podmanのrootlessの運用と相性が悪い感じ）
    NFSであれば問題ないのでNFSで
  • environmentに"PAPERLESS_CONSUMER_POLLING: 10"、"PAPERLESS_DATE_ORDER: YMD"あたりは設定しておく必要がありそう
    PAPERLESS_DATE_ORDERは指定しないと日付の推測をdd/mm/yyyyでやってしまうので日本語と相性が相当に悪い
  • ログイン失敗のログを出力しようとすると"PAPERLESS_LOGGING"で色々設定しないとダメそう

という感じ。

Cloudflare Tunnelの設定注意点

アプリでServiceTokenで認可させようとする場合/api/*以下をServiceTokenで、/をIdPで認証させようとした場合色々うまくいかない。（/api/以下をwebアクセス時も使っているみたい）
なので、api用にサブドメインでアクセスできるようにしてWebアクセス用とAPIアクセス用でアクセスする名前を変えてWebアクセス用の名前のAccess設定をIdP、APIアクセス用の名前をServiceTokenで設定する。

Wallabagを使えるように

Wallabag

Wallabagはいわゆるブックマーク系のサービス。
セルフホスト化出来るので試してみた。
どこまで有効か？は試してみる。正直、あとから読むのも全部Notionに入れておけば？と思わなくもない

課題

これまでセルフホストはCloudflare AccessでSWGというか認証認可を任せていたんだけど、Wallabagの場合Web経由なら問題ないんだけどChromeのアドオンだったりスマホのアプリだったりを使おうとすると/apiや/oauthを公開しておかないとうまくいかないのでそこだけが課題
Cloudflare Access経由での障壁があるので大分内部は適当にやっていたんだけど、そこを公開するならちゃんとしようとして

  • Podmanでrootlessで実行する
  • SELinuxで権限取られても他に被害が出ないようにする

を基本想定としてRHEL10のVMを立てて設定。
Podmanは初だったんだけど色々勉強になった。docker-composeは使うようにしたんだけど、systemdとの連係が必要だとかユーザーでのsystemdの扱いだとか色々。

メモ

詳細は別途まとめるとして、現時点で課題にしているところ

  • Androidアプリで初回の接続設定をするときだけはアプリのルートパスをAccessをバイパスして接続出来るようにしないと先に進まない ※ 初回の接続確認後は停めてOK。/apiと/oauthがバイパスされていればOK

Navidromeの構築メモ

段階的に構築進める想定なのでちょっとずつメモ増やしていく予定

Navidrome

www.navidrome.org

SubsonicAPI対応の音楽ストリーミングサーバ。
同種のソフトを比較しているところでサーバのリソース消費がかなり少ないという評価だったので選択。

yamanekovillage.com

最初のファイルスキャン中は結構激しく動いている感じだったけどその後はおとなしいので、録画サーバからほぼ単純NASになってリソースがあまり気味のサーバで動かすことにした。

スマホのストレージを節約しつつ大量の音楽を聴けるようにしようとするとSpotifyとか使うかセフルホストのミュージックサーバ立てるかなんだけど、セルフホストのミュージックサーバてててみることにした。
ブラウザから再生するときもリプレイゲインを有効に出来るので良い。
リプレイゲインが有効なプレーヤーが必須なので個人的にはこの機能がかなり大きい。

スマホからの再生に関してはこれまでPowerAmpを使っていたんだけど、そのままでは連係に使えなさそうなのでクライアントはSymphoniumあたりを検討中。

外からの接続に関してはCloudflare Tunnel経由を想定しているけどうまく連係出来るかな？

last.fmとの連係

last.fmやListenBrainzとの連係も可能。
last.fmと連携する場合はAPIキーを発行して有効にする必要がある。

www.navidrome.org

dockerで立てる場合は

  • ND_LASTFM_ENABLED
  • ND_LASTFM_APIKEY
  • ND_LASTFM_SECRET

を指定する必要がある。
APIKEYとSECRETはlast.fmで登録したら発行される。
指定してNavidromeの管理者から個人設定で「Last.fmへscrobbleする」が有効になっているので、これをONにしてlast.fmの接続確認が出るのでOKすれば完了。
last.fmの設定→Applicationsに登録した名称のアプリケーションがConnected Applicationsに登録されていればOK

各種Configはここを確認

www.navidrome.org

last.fmのAPI Keyの詳細、あとから見たい場合はここから見られるみたい
https://www.last.fm/api/accounts

外部アクセス

家の外からのアクセスについてはCloudflare Tunnel経由でAccess認証通してつながるようにしたい。
ということでサクッとnavidrome.ドメイン名という感じのサブドメイン定義してAccess設定をして、Tunnelに先程のサブドメインとローカルのNavidromeアドレスを割り当てて公開。
前やってしまったけど、Access設定する前にTunnelで割り当ててしまうとAccess設定するまでアクセスし放題になるので要注意。

※ Cloudflare Tunnel経由でSymphoniumでアクセスしようとするとうまくいかない 　どうもバグっぽいことがフォーラムに記載があるけどどうなんだろ

SymphoniumのCloudflare Tunnelとの連係について

Symphoniumのメディアプロバイダ設定でSubsonicのプロキシ認証設定にカスタムヘッダのCF-Access-Client-Id、CF-Access-Client-Secretを設定する必要がある。
これはCloudflare Zero Trust、というかCloudflare Accessでサービストークンを発行して、そのクライアントID、クライアントシークレットを設定する形になる。
設定順としては

  • サービストークンの発行（サービス資格情報からサービストークンを作成）
  • Accessのアプリケーション設定でアクセスポリシーの先頭に新規ポリシーを追加（Service Auth設定でポリシーを作成して、先程作ったService Tokenをルールに設定）

これを行ったうえで、symphoniumのプロキシ認証でカスタムヘッダにCF-Access-Client-Id、CF-Access-Client-Secretを指定。値はCloudflare Accessでトークン発行したときの値を設定
こんな感じ

カスタムヘッダーの設定

これで外からSymphoniumでアクセス出来た。
課題としては屋内からでもTunnel経由になってしまうのでLAN内で完結しなくなること。
そろそろちゃんと家庭内DNS整備してフォールバックするような環境が必要か？
→ 「優先する接続」をローカルのIPアドレスに、予備の接続をパブリックなドメイン接続に設定しておけば良さそうなのでスマホはそういう設定にしようかと思っている。今のところ家の中のタブレットだけ設定しているから影響がわからん

なろうのタイトル長傾向確認2025年結果

経緯

2024年版はこちら teandt.hatenablog.com

小説家になろうにおけるタイトル長がどんどん長くなっているという記事を見て、感覚と実態が一致しているか確認したくて調べた結果。
2024年は上位陣のタイトル長は短くなる傾向がでていたが今年はどうだ？というところと、連載と短編の比率が再び逆転しそうな傾向があったので今年はどうなるか？というのを確認する。

コードは前年ものをそのまま使用しています。
生成AIとのコーディングで多少メンテナンスはしたけどAPI的には特に変更なくそのまま使用しています。

ツール

数年間使っていましたが、多少使い勝手をマシにして昨年公開しました。
基本的にはここに書いてあるとおり実行して結果をまとめているだけです。
github.com

結果

以下、各結果。
昨年同様過去データは一致しない可能性が高く、今年もデータをAPIで取り直しているので過去データが削除されていると取得できないはず。
全体的な傾向を掴むくらいで考えてください。

上位100位

2025年上位100位

上位500位

2025年上位500位

上位1000位

2025年上位1000位

上位2000位

2025年上位2000位

上位10000位

2025年上位10000位

補足（データ：平均タイトル長）

注意：2024年までは昨年の結果のコピペです

TOP100 TOP500 TOP1000 TOP2000 TOP10000
2004 6.83 7.341727 7.341727 7.341727 7.341727
2005 8.59 8.106000 7.874000 7.986947 7.986947
2006 10.20 9.632000 9.134000 8.450000 8.272634
2007 9.89 9.680000 9.540000 9.028000 8.392640
2008 10.33 10.584000 10.157000 9.701500 8.790788
2009 10.83 10.034000 10.392000 9.932000 9.022700
2010 10.11 10.198000 10.041000 10.203500 9.467900
2011 10.72 10.868000 10.817000 11.025000 10.382900
2012 13.10 12.752000 12.079000 11.715000 11.168500
2013 14.12 13.978000 13.978000 13.431000 12.047700
2014 16.95 16.678000 16.373000 15.677500 14.003500
2015 17.65 17.660000 17.306000 16.996500 15.471900
2016 23.10 20.192000 18.933000 18.438000 16.744100
2017 23.65 22.906000 21.825000 21.224500 18.418900
2018 28.66 28.098000 26.477000 24.726500 21.339200
2019 30.23 29.898000 27.899000 26.223000 23.803200
2020 48.42 40.210000 36.817000 32.918500 29.356800
2021 45.61 38.684000 35.746000 34.112500 33.554800
2022 44.37 39.312000 36.955000 35.876000 32.397900
2023 41.44 37.212000 34.949000 33.912500 31.674200
2024 37.47 30.172000 28.876000 27.983000 28.277200
2025 32.39 29.250000 27.323000 26.825500 28.350900

連載と短編の比率

今回も連載比率についても継続して調べてみた。青が連載、オレンジが短編。
今回の結果で一番予想外だったのがこの結果で、これまで2016年頃から10年ほど投稿作品数が停滞している感じだったのが突然急増している。
原因は調べてみないとわからないけど短編だけではなく長編というか連載も増えているので何かしら変化があったはず。
候補としては生成AI活用の執筆速度向上による影響、完全生成AIによる大量の投稿が発生した、収益化により影響、これらの複合要因といったあたりだろうか？

青：連載／オレンジ：短編

補足：タイトル長ヒストグラム

上位100位のタイトル長分布。
2024年と比較すると50文字以内に抑える作品が大半になっているように見える。
75%までを見ても顕著で、2025年が42文字、2024年が52文字。
ただし、50%までだと2025年が30文字、2024年が34文字で大差が無い。
ということで全体的に20～40文字くらいの範囲が標準的になっていることがうかがえる。
※相変わらずギリギリを攻める作品も健在

2025年上位100位のタイトル長分布

count 100.000000
mean 32.390000
std 16.831845
min 8.000000
25% 21.750000
50% 30.000000
75% 42.000000
max 99.000000

Proxmox Backup Serverの導入

経緯

NAS代わりに使っているMicroserverGen8のHDD 8TB2本を24TB1本に集約したことでHDDスロットとHDDそのものが余ったのでこれまで放置してきたサーバ本体側のバックアップ用にしようということでいくつか設定。

rsnapshotの導入

雑多にDLしたファイルをSSDに入れて定期的に整理していたんだけど、整理する前に消えたら困るなと思ってrsnapshotで一時的にバックアップするようにした。
Geminiと相談してcron + バッチファイルでやろうとしたけど、絶対これOSSで存在するでしょと聞いたらほぼrsnapshotだったので一部気になる部分はあるけど実用上問題ないのでそのまま使うことにした。

github.com

設定ファイルがスペース認識せずにTabで余白入れないとエラーになるとかクセは強いけど一回設定すればそんなに問題は無いのでいいかな。
自分でcrontab設定するのも久しぶりな気がする

Proxmox Backup Serverの導入

本題。
ProxmoxのVM周りのバックアップをしておこうと思って自動バックアップ出来るようにBackup Serverを入れてみた。
これもProxmoxのVMで構築。 2コア＋4GBメモリでお試し中

Proxmox Backup Serverのフリーリポジトリへの変更

Proxmox Backup Serverを入れたところエンタープライズリポジトリが標準になっていてそのままだとapt updateで失敗する。

Err:4 https://enterprise.proxmox.com/debian/pbs trixie InRelease 401 Unauthorized [IP: 51.79.228.122 443] Error: Failed to fetch https://enterprise.proxmox.com/debian/pbs/dists/trixie/InRelease 401 Unauthorized [IP: 51.79.228.122 443] Error: The repository 'https://enterprise.proxmox.com/debian/pbs trixie InRelease' is not signed.

変更についてはこちらを参考に www.nuface.tw

編集するファイルは

/etc/apt/sources.list.d/pbs-enterprise.sources

内容は

Types: deb
URIs: http://download.proxmox.com/debian/pbs
Suites: trixie
Components: pbs-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg

データストアをCIFS連係する場合の注意点

データストアをCIFS連携する場合はマウント時のUID/GIDの指定に注意が必要。
実行ユーザーを

  • uid=34
  • gid=34

に設定する必要がある。 ここを設定していないと

Permission denied (os error 13)

と出る。

PX-MLT5PEを購入した

経緯

PX-Q1UDが最近駄目駄目すぎるので全体的に家の録画サーバ環境を見直すことに。
そんなわけでMS-A2にしてPT3を入れられるようにしたんだけど、やっぱり外付けで利用できるチューナーも確保しておこうと思って色々調べていたらPX-MLT5PEを外付け出来るケース＋基盤を作成している人がいたのでこれを機会に購入。

thun.booth.pm

チューナーの価格に対してちょっと高い気もするけど、色々試すくらいなら良いかと思って購入。
正直予想以上に質感良かったです。ケースは再販ないようなので欲しい人は早めに購入したほうが良いです。（すでにケースのみは売り切れ）

セットアップ

PX-MLT5PEも同時に購入してProxmoxVEのVMでテストするぞ！とdocker-mirakurun-EPGStationで起動したらエラーでEPG取れないの。
Mirakurunが標準だとdvbドライバ用ってことでdvbドライバ以外だとrecpt1とかのコマンドを使えるようにしておく必要がある。
今後色々面倒になりそうだったのでチューナー設定とかチャンネルスキャンあたりを出来るようにテスト環境作ってみた。

github.com

px4_drvいれたPX-MLT5PE環境用に直接記載しているけど、devicesあたりを編集すれば他機でも使えると思うけど試してないので不明。
使い方としてはISDBScannerをdockerでインストール、実行してチューナー設定とチャンネル設定をMirakurun用にコピーしてMirakurunにrecpt1を追加するよう公式に記載されているスクリプトを追加しただけの環境だけど、これで動作確認してからdocker-mirakurun-EPGStation用のdocker-compose.ymlファイルの差し替えをすればそれっぽく動く。

今後、チューナーを1つにまとめるか2つのVMで分けて動かすかはちょっと検討中。
カードリーダーを一つにまとめるほうが楽でいいんだけどどうするかな