機能 #380
完了Subversion サーバを立てる
100%
説明
mod を含む状態でのゲームの管理などに有用。
Gitea とオブジェクトストレージを利用した Git LFS を試したこともあったが、100 GB を超えるくらいになると Gitea のバックエンドの git コマンドがタイムアウトしてしまい、まともに使えなくなった。
NO nop_thread さんが12ヶ月前に更新
実験的に SMB & local FS repo による subversion 運用を試しており、とりあえず動くには動いている。
ただしコミット速度はかな〜り遅いため、これを常套手段としたくはない。
しかし一度サーバを立てようとしてみたものの (https://mastodon.cardina1.red/@lo48576/113182879299743981) 満足いく構成にするのはまあまあ面倒そうなことが発覚したため、もう少し下調べと構想が必要かもしれない。
(Windows で SSH は基本的にダルい！)
NO nop_thread さんが12ヶ月前に更新
- 優先度 を 通常 から 低め に変更
- 前回確認日 を 2024/05/29 から 2024/10/15 に変更
NO nop_thread さんが12ヶ月前に更新
- 関連している 機能 #426: NAS 全般のハードウェアと運用を再考する を追加
NO nop_thread さんが2ヶ月前に更新
- 前回確認日 を 2024/10/15 から 2025/07/25 に変更
最悪の場合は自己署名証明証も許容すべきかもしれないが……うーん。 local FS over SMB とどちらがマシかは何ともいえない。
NO nop_thread さんが2ヶ月前に更新
- 関連している 行動傾向 #791: [meta] 2025夏休みに手を出したいこと を追加
NO nop_thread さんが2ヶ月前に更新
https://mastodon.cardina1.red/@lo48576/113183826265831060:
443 以外のポートで全自動でオレオレルート認証局から証明書を自動発行してくるのダルすぎる
これがどうにかできればどうにかなる。
NO nop_thread さんが2ヶ月前に更新
いろいろ考えているうちに混乱していたようだ。
選択肢はそんなに多くない:
- Subversion サーバ (svn プロトコル) を用意し、 svn+ssh プロトコルでアクセスする。または、
- Subversion サーバ (HTTP) を用意し、リバースプロキシ (ヘッダを書き換える) を設定する。または、
- Subversion サーバ (HTTPS) を用意し、証明書の更新を自動化する。
1はメインのクライアントとなる Windows だと SSH を使うのが面倒なので避けたい。
2は選択肢としてはアリだが、サーバ側に余計な設定が必要になる。
3は実質的に (svnserve 等でなく) Apache2 の mod_svn を使う必要がありそうなのと、他のサーバで使っている Caddy 組込の証明書更新ではなく Apache2 の certbot 連携を使う必要があるという欠点がある。
ヘッダ書き換えについては、調べた限りでは mod_svn がリクエストを受け取るとき Destination header を確認しているというだけのようで、リクエストを書き換えさえすればよさそうなのでおそらくそこまで難しくはない。
NO nop_thread さんが2ヶ月前に更新
どうせ自分専用なのでそんなに負荷とか考える必要はないし、 Caddy の WebDAV 系の挙動がどうなのか確認するのも面倒なので、全部 Apache2 に任せる方向でやってみるか。
NO nop_thread さんが2ヶ月前に更新
- ステータス を 新規 から 進行中 に変更
- 前回確認日 を 2025/07/25 から 2025/07/29 に変更
NO nop_thread さんが2ヶ月前に更新
ドメインまるごと subversion 用に提供しようとして以下のように Location / へ Dav svn してはいけない。
<VirtualHost *:80>
<Location />
Dav svn # ←これがマズい
SvnParentPath ...
</Location>
# ...
一度 Dav svn してしまうと、その子孫の location に対して Dav Off による無効化はできない。
つまり /.well-known/acme-challenge 以下についても mod_dav_svn が奪ってしまい、 certbot による証明書発行ができなくなる。
試していないが renew も同様にできなくなるはずだ。
仕方ないので <Location /svn> とか <Location /repos> のように /.well-known を含まない location を使うしかない。
リバースプロキシを立てるとか certbot を standalone モードで使うなら話は別だが、 Apache に完全に任せたいので今回は / を諦める。
NO nop_thread さんが2ヶ月前に更新
- 進捗率 を 0 から 50 に変更
svnadmin dump /PATH_TO_OLD_REPO | svnadmin load /PATH_TO_NEW_REPO でリポジトリを移動しようとしているが、移動先が CIFS マウントされたディレクトリだと svnadmin: warning: W200029: Couldn't open rep-cache database '/PATH_TO_NEW_REPO/db/rep-cache.db' のような警告が出る。
どうも rep-cache.db が SQLite3 のファイルだが、これがリモートのファイルシステム上にあるとよろしくないらしい？
とりあえず warning でしかないので様子を見てみる。
NO nop_thread さんが2ヶ月前に更新
- ステータス を 進行中 から 終了 に変更
- 開始日 を 2025/07/29 にセット
- 進捗率 を 50 から 100 に変更
- 前回確認日 を 2025/07/29 から 2025/07/30 に変更
移行完了。
relocate (Relocating a working copy) もできたし、たぶん成功しているだろう。
何かおかしそうだったらバグとして起票する。
NO nop_thread さんが2ヶ月前に更新 · 編集済み
- 前回確認日 を 2025/07/30 から 2025/07/31 に変更
svn クライアントから HTTPS 経由でリポジトリのログを見ようとしても、 apache2 のプロセスの CPU 利用率が100%付近に貼り付いて一向に結果が返ってこない。
メモリは全然使っていない (プロセスあたり 20 MiB 程度？) が、30分放置してもプロセスが鎮まる気配がない。
ログにも碌な情報が出てこない。
これは駄目かもしれない。
キャッシュが生成されればマシになるなどの可能性もあるにはあるので、とりあえず待つだけ待ってみようと思う。
NO nop_thread さんが2ヶ月前に更新
落ち着いてからもう一度リポジトリのログを見ようとしたが改善しなかった。
救いはないらしい。
諦めてクライアントから SMB 経由で直接使う方式で行こうと思う。
小さなリポジトリであれば動く可能性もあるが、その程度のことなら Git LFS でも十分なので、何にせよ今回経てた subversion サーバは無益ということになる。