Lycolog

仕事を終えて自分のサイトを見ると一部がダウンしておりGrafanaを見てみたらディスク使用率が100%になっていた。Mastodonがダウン、Grafanaも不安定な状態だった。

Prometheusのsyslog集めが強すぎてストレージパンクしたかな？と思ってPrometheusを止めてみたが効果はなかった。

ディスク占有しているやつを探す

ひとまずディスクを占有している主を突き止めるため、ディレクトリ単位の容量を出して突き止めることにした。犯人はForgejoだった。

犯人探しに使った軌跡

sudo du -xh --max-depth=1 /
sudo du -xh --max-depth=1 /var
sudo du -xh --max-depth=1 /var/lib
sudo du -xh --max-depth=1 /var/lib/forgejo
sudo du -xh --max-depth=1 /var/lib/forgejo/data
sudo du -xh --max-depth=1 /var/lib/forgejo/data/repo-archive

一次対応としてForgejoへの外部アクセスを遮断

取り敢えずForgejoが攻撃されてると面倒だなと思い、nginxの設定を書き換えてForgejoへの外部接続を拒否した。

次にrepo-archiveはキャッシュらしいのでForgejoの管理画面から消すことにした。すると即座にディスクは空き、全てが元に戻った。

犯人捜し

一旦サーバーは安定状態になったので犯人を捜すことにした。

まずはForgejoのログを見たのだが役に立たなかったので、次に私はGrafanaのLokiからnginxのログを引くことにした。

そしてLokiからnginxのログを見たらすぐに分かった。meta-externalagent、つまり悪名高いFacebookのクローラーだった。過去にこのブログにやってくる海外IPのBOTの挙動を軽く調べたでも出したが、こいつはやたらアクセスしてくる。

しかし何故Facebookのクローラーがなぜ…？と思ったがURLを見てすぐわかった。アーカイブにアクセスしているのだ。

もしかしたらForgejoはアーカイブURLにアクセスされるとその都度.zipや.tar.gzを生成しているのかもしれないと思って調べたらその通りだった。そんなクソみたいな仕様ある…？と思ったが、アーカイブを作るなら他に方法はない。

ForgejoはGitHubと違ってパス単位に作れるため、パスが多いリポジトリほど大量に作れるし、過去のバージョンを参照されたら事実上ほとんど無限に生成できる。そりゃパンクする。

Forgejoはどう思っているのか？

こんなのほとんど脆弱性である。しかもディスククォーターを設定したところでどうにもならない。ダウンロードできなくなって詰むだけだ。定期的にクリアしてもいいがSSDの寿命が縮んでしまう。

そこでForgejoの人たちはどう思っているのか調べてみたら案の定課題が起票されていた。最後の奴に至ってはメインコントリビューターの一人と思われるGusted氏の起票である。

• bug: Forgejo is spam-creating repository archives, and cannot create requested archives
• feat: add quota for repo-archive
• problem: no traffic policing that keeps Forgejo available

結局どうすることにしたか

リポジトリの中身をzipで落としたい需要というのはどうしても出てくるし、それは仕方がない。しかし世代ごとパスごとに作ってしまうとなると、その数は無数になりすぎてしまう。

そしてダウンロードさせる以上どこかにデータを置く必要はある。仮に定期的に消すとしてもストレージの消耗は避けられない。

結論としてForgejoは撤去し、成果物は配布ページを作ってそこでzip配信するのが無難だなと思った。

簡単なコードについてはゴミ箱みたいな場所を作ってそこに転がしておくのもいいだろう。

明らかに利用者がいるValueDomainの奴とかもあるので、ひとまず土曜日にページを作って配信しようと思った。

meta-externalagentのアクセス推移

全部で何アクセス化までは見れていないが万単位でアクセスされてそうなので無茶苦茶だなと思った。

metaは最早攻撃者にも近いと思う。

経緯とか

18時頃にメトリクスが切れているのは多分書き込めなくて一時的に死んだからと思われる。再開できた理由は不明。この時点でネットワークトラフィックも死んでおりまともにアクセスできない状態だったと思われる。

19時半頃に手当を開始したが、FacebookのクローラーはForgejoを遮断するまでダウンロード不能（statできずにエラーを吐いていた）になったURLにひたすらアクセスしていた。

あとがき

今回の障害はいい勉強になった。

ディスク容量の急増という障害があることと、単にログとメトリクスを集めているだけでも解ることがあることが知れた。

勿論、閾値を設定した上での発報や、毎回クエリを叩かなくていいダッシュボードがあればよりよいと思うが、単に監視装置を置いているだけでもこうやって知ることができるのだなというので、いい経験になった。

Forgejo v11のエディタがスマホから扱いづらいのでv15に上げて扱いやすくするのが目的。

この作業で解決する問題

Forgejo v11ではAndroid Edgeでエディタ上をロングタップするとJSでカスタマイズされたメニューが出てしまい、全選択や全選択→切り取りみたいなコンボができない問題があった。

Forgejo v15に上げることで、ブラウザ標準のコンテキストメニューが表示されるようになった。但し全選択→切り取りは上手くいかず、ファイル先頭を選択しそこから末尾までドラッグした上で切り取る必要があった。とはいえ、ほとんど全く操作できなかったところから操作できるようになっただけでも十分だ。

個人的にスマホでコードを触る場合、ほとんどは小規模な編集なので、いったんはこれでも事足りる。

参考までに、この変更はForgejo v14で行われていた。

前提条件

• DBはSQLite
• Forgejo 11.0.15+gitea-1.22.0から15.0.3へのアップグレード

手順

基本的にはアップグレードガイドを読みながらやる。

# v15の取得
wget https://codeberg.org/forgejo/forgejo/releases/download/v15.0.3/forgejo-15.0.3-linux-amd64

# バックアップの作成
sudo -u git /usr/local/bin/forgejo \
 --config /etc/forgejo/app.ini \
 dump --file /home/git/forgejo.zip

# ジョブキューを吐き出す
sudo -u git /usr/local/bin/forgejo \
 --config /etc/forgejo/app.ini \
 manager flush-queues

# サービスを止める
sudo systemctl stop forgejo.service
# バイナリを上書き
sudo cp forgejo-11.0.15-linux-amd64 /usr/local/bin/forgejo
sudo chmod 755 /usr/local/bin/forgejo
# サービスを再開
sudo systemctl start forgejo

あとがき

特に何事もなく移行でき、バックアップファイルも使うことがなかったので良かった。

UI全体としてもブラッシュアップされ、いい感じになっていると思った。

昨日の今日でv11がv15を上げた感じだが、そもそもなんでv11を入れたんだっけ…？と思ったが、多分リリースページの真ん中にv11がいて、v15は画面の上の方にあったので、前回のインストール作業時に見えていなかったのだと思う。

前回の記事でForgejoのIssueを立てるための検証をしたときに最新がv16だったので、やけにバージョンがすっ飛んでるな、WinampやPHP方式か？と思ったら、単に私が見落としていただけだったか…という感じだ。

あと全然関係ないのだが、Forgejoのコントリビューターはオタクっぽい人が多いなと思ったのと、Forgejo同様にFOSSを使っていてCodebergでも採用されているAnubisの開発者もなかなかのオタクに見えるので、この二つのFOSSに何かの縁を感じたりもした。

ここしばらくGitHubに思うところがありすぎて、GitHubを使い続けることに悩ましさを感じていたが、折角自宅サーバーの運用が軌道に乗ってきたのだし、それならGitHubもセルフホストしちゃおう！というのでやってみたログ。

あとがきに熱が入りすぎて異様な長さになってしまったので、この記事はあとがきが本体な可能性がある。

• 構築条件
• 確認環境
• やり方
• GitHubのリポジトリを一括でForgejoに移行する方法
• トラブルシュート
  • ../ssh/ssh_graceful.go:25:listen() [F] Failed to start SSH server: listen tcp 0.0.0.0:22: bind: permission deniedというエラーが出る
  • 動作確認で起動と起動時のログ確認を同時にやりたい
• 関連記事
• あとがき
  • 構築していて思ったこと
  • unixsocketの利用について
  • Forgejoを使おうと思った理由
    • GitHub周辺のセキュリティ事情の変化と、それに伴う対応
    • GitHub離れの加速
    • GitHubでホストする意味がなかった
    • GitHubの個人用アカウントと業務用アカウントがどうのこうのを解決する糸口として
  • Forgejoに対する思い
    • 分散型という諸刃の剣
  • 今回設置した物体が見れる場所

構築条件

• Dockerを使わずバイナリ直運用
• nginxからのリバースプロキシ
• 内部か外部かを問わずIPv6を使用する
• unixsocketを利用する
• GitのSSH操作にForgejo組み込みのSSHを利用する

確認環境

やり方

基本は公式のインストールガイドの通り。

1. バイナリの配置～デーモンの配置を行う

   # Forgejoバイナリの入手
   wget https://codeberg.org/forgejo/forgejo/releases/download/v11.0.15/forgejo-11.0.15-linux-amd64
   # Forgejoバイナリの配置
   sudo cp forgejo-11.0.15-linux-amd64 /usr/local/bin/forgejo
   sudo chmod 755 /usr/local/bin/forgejo
   rm forgejo-11.0.15-linux-amd64
   # gitとgit-lfsのインストール（gitは既に普通あると思うが）
   sudo apt update
   sudo apt install git git-lfs
   # Git操作用ユーザーの追加
   sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
     --group --disabled-password --home /home/git git
   # Forgejoディレクトリの作成
   sudo mkdir /var/lib/forgejo
   sudo chown git:git /var/lib/forgejo && sudo chmod 750 /var/lib/forgejo
   sudo mkdir /etc/forgejo
   sudo chown root:git /etc/forgejo && sudo chmod 750 /etc/forgejo
   # Systemdの入手と配置
   sudo wget -O /etc/systemd/system/forgejo.service https://codeberg.org/forgejo/forgejo/raw/branch/forgejo/contrib/systemd/forgejo.service
   # デーモンの開始（設定ファイルとかを作らせるためにしている）
   sudo systemctl daemon-reload
   sudo systemctl enable forgejo.service
   sudo systemctl start forgejo.service
   # 設定ファイルのパーミッションを変える
   sudo chmod 640 /etc/forgejo/app.ini
   

2. /etc/systemd/system/forgejo.serviceを開き[service]セクションに以下を追記する

   RuntimeDirectory=forgejo
   RuntimeDirectoryMode=0755
   AmbientCapabilities=CAP_NET_BIND_SERVICE
   CapabilityBoundingSet=CAP_NET_BIND_SERVICE
   

   下二行はケイパビリティの設定で、これをしておくと22番ポートが使えるようになる

3. nginxからリバプロする

   server {
     listen [::]:443 ssl;
     server_name  git.example.com;
   
     ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
     ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
   
     client_max_body_size 100M;
   
     location / {
       proxy_pass http://unix:/run/forgejo/forgejo.sock;
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-Proto $scheme;
     }
   }
   

4. /etc/forgejo/app.iniを開き、適当に設定を書く。設定系はConfiguration Cheat Sheetに全部書いてある。

   # Webページのタイトルの一部が変わる
   APP_NAME = Forgejo
   # Webページのタイトルの一部が変わる
   APP_SLOGAN = Beyond coding. We Forge.
   # 実行ユーザー
   RUN_USER = git
   # 本番
   RUN_MODE = prod
   # 実行パス
   WORK_PATH = /var/lib/forgejo
   
   [server]
   # unixsocketを使う
   PROTOCOL = http+unix
   # Forgejoを置いているドメイン
   DOMAIN = git.example.com
   # unixsocketのパス
   HTTP_ADDR = /run/forgejo/forgejo.sock
   # unixsocketのパーミッション
   # www-dataがアクセスできるように666にしているがwww-dataをgitグループに入れてもいいかも？
   UNIX_SOCKET_PERMISSION = 666
   # 組み込みSSHを起動する
   START_SSH_SERVER = true
   # IPv6でListenさせる
   SSH_LISTEN_HOST = ::
   
   [repository]
   # リポジトリを格納するルートパス
   ROOT = /var/lib/forgejo/data/forgejo-repositories
   
   # アップロード制限、とりあえず公式のコピペ
   [repository.upload]
   ; ; max size for files to the repo via web interface, in MB,
   ; ; defaults to 3 (this sets a limit of about 4GB)
   FILE_MAX_SIZE = 4095
   ; ; by default 5 files can be uploaded at once, increase to 20
   MAX_FILES = 20
   
   # Gitのタイムアウト制限、とりあえず公式のコピペ
   [git.timeout]
   ; Git operations default timeout seconds
   DEFAULT = 3600
   ; Migrate external repositories timeout seconds
   MIGRATE = 6000
   ; Mirror external repositories timeout seconds
   MIRROR = 3000
   ; Git clone from internal repositories timeout seconds
   CLONE = 3000
   ; Git pull from internal repositories timeout seconds
   PULL = 3000
   ; Git repository GC timeout seconds
   GC = 600
   

5. デーモンの再起動

   sudo systemctl restart forgejo.service
   

6. https://git.example.comにアクセスし適当に設定する
   基本的に初期設定そのままで大きな問題がないものばかりだった気がする
   

   

7. SSH鍵を作成し、Forgejoで自分のアカウント設定ページを開き、公開鍵を登録する

8. クライアントになる環境にSSHに繋ぐための設定(~/.ssh/config)を書く

   Host git.example.com
     HostName git.example.com
     IdentityFile /path/to/forgejo.sec
   

9. 疎通確認。WindowsでもLinuxでも同じ

   ssh -T git@git.example.com
   

GitHubのリポジトリを一括でForgejoに移行する方法

GITHUB2FORGEJOを使うとできる。

以下は移行のコマンド例。マニュアルが親切なのでマニュアルを読めばわかる。

一個でも外すとこのオプションどうする？と聞かれるが、何も指定しなければウィザードを流してくれるので、環境変数を指定せずに叩いても動く。

以下のコマンドではGitHubと決別し、完全にForgejoに移行する前提の設定としている。

wget https://github.com/PatNei/GITHUB2FORGEJO/archive/refs/heads/main.zip
unzip main.zip
rm main.zip
cd GITHUB2FORGEJO-main
GITHUB_USER=YourGitHubUserName \
    GITHUB_TOKEN=ghp_XXXXXXXXXXXXX \
    FORGEJO_URL=https://git.example.com/ \
    FORGEJO_USER=YourForgejoUserName \
    FORGEJO_TOKEN=XXXXXXXXXXXXXXXXX \
    STRATEGY=clone \
    MIRROR_DIRECTION=pull \
    PUSH_MIRROR_INTERVAL=8h \
    PUSH_MIRROR_SYNC_ON_COMMIT=no \
    MIGRATE_ARCHIVE_STATUS=yes \
    MIGRATE_FORKS=no \
    VISIBILITY=both \
    SORT=pushed \
    SORT_DIRECTION=desc \
    FORCE_SYNC=no \
    DRY_RUN=no \
    ./github-forgejo-migrate.sh

どうやらリポジトリ本体は持ってこれるもののIssueやWikiは持ってこれないようだ。

forgejo dump-repoというGitHub系サービスの中身をダンプするコマンドがあったので試してみたが、こちらは引っ張ってはこれるっぽいもののForgejoのDBやディレクトリ構造と合わないようで、移行用途では使えなかった。

gh repo list Lycolia --limit 1000 --json name --jq '.[].name' \
    | while read url; do
        echo sudo -u git forgejo dump-repo --git_service github --auth_token XXXXXXXXXXXXXXXXXX--clone_addr https://github.com/Lycolia/$url --config /etc/forgejo/app.ini --repo_dir /var/lib/forgejo/data/forgejo-repositories/lycolia/$url
    done

GitHubのアカウントエクスポートも試してみたが、中身が省略されているように見える.gitディレクトリの山がパッケージされており、ググった感じGitHub間のアカウント移行に使う物らしかったので、諦めた。

トラブルシュート

../ssh/ssh_graceful.go:25:listen() [F] Failed to start SSH server: listen tcp 0.0.0.0:22: bind: permission deniedというエラーが出る

/etc/systemd/system/forgejo.serviceを開き[service]セクションに以下を追記して再起動すれば治る。

AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE

動作確認で起動と起動時のログ確認を同時にやりたい

動作確認時にデーモンの上げ下げしてジャーナル見るのが面倒なので、パッとやりたいときに便利なコマンド

sudo -u git /usr/local/bin/forgejo web --config /etc/forgejo/app.ini

関連記事

• ForgejoでWebUIから触ったときにコミットに署名させる

あとがき

あとがきが長すぎて、実はこっちが記事の本体という可能性が…ｗ

構築していて思ったこと

SSHの穴をあけるのは危険か？と思ったが組み込みのSSHであればgitユーザーが出来ること以外できないだろうし、任意のコマンドが実行されたところで、精々リポジトリの全消し以上のリスクはなさそうなので開けることにした。理由としてはHTTPはパフォーマンスが悪いらしいからだ。

構築していて思ったがForgejoのマニュアルは親切で比較的解り易く、構築が楽だったのが良かった。

unixsocketの利用について

積極的に使い始めたのはUbuntuのadiaryをlibfcgi-perlで動かす方法が初めてだが、unixsocketはTCP通信をしないのでポート管理が不要になるのが利点なのと、TCPのオーバーヘッドがない分処理が速いというのをどっかで見たので、使うことにした。

内部通信のポートが被らないように管理するのは地味に大変なのでアプリケーション間の通信は極力unixsocketに倒したいなと思った。

Forgejoを使おうと思った理由

GitHub周辺のセキュリティ事情の変化と、それに伴う対応

最大の理由は、ここ数年でGitHubやnpm周辺のサプライチェーンリスクを強く意識せざるを得なくなったからだ。

例えばSecrets漏れなどの事故はここ数年で非常に聞くようになったし、npmjsからGitHubのToken奪取などの問題もあったと思う。

そしてその関係でセキュリティが面倒なことになり、GitHub Actionsからnpm publish出来なくなってたのを対応したみたいなことをする羽目になったこともあり、非常に煩わしさを感じていた。

Value-DomainでcertbotのDNS Challengeをやるスクリプトを書き直した理由の一つも、npmjsから手を引きたい思いが実はあり、そもそも別にリポジトリから拾えばいいじゃんと思い、パッケージ化しなかったというのもある。だって別にPerlでもnpmレジストリに入れることはできるからね。

そして昨日npmjsのアカウントを消そうと思い立ちログインしようとしたらロックアウトされてしまった。私はホビープログラマとしてやっているだけなので、こういった変化についていくのに疲れてしまった。

GitHub離れの加速

例えば最近GitHub離れが進んでいることも理由の一つだ。

理由にはいろいろあると思う、例えばここ最近GitHubは不安定で、GitHub Actionsが失敗する、Webページが開けない、APIがダウンしているのは最早日常といってもいいだろう。少なくとも私はそう思っている。

他にもCopilotなどのAI化の推進や、UXの悪いPR、行儀の悪いソフトウェアの排除もある。

CopilotなどのAI化の推進についてはGitHubのWebページ上でコミットを打つと解るのだが、LLMによって勝手にコミットメッセージが補完される。あのメッセージに意図などなく、変更内容を文字列にしただけだ。これを避けるためにはAIが書き切るより早く書き起こしてコミットするか、或いは書き終わるのを待って上書きするか、何も考えず即座にコミットボタンを押しUpdate hoge.mdのようなメッセージにするかしかない。個人的にはこれが非常に煩わしく、避けたいと思っている。

そして、もしこれを回避する設定があるとしてもGitHubの設定は既に増えすぎており、もう探す気も起きない。

UXの悪いPRについては、PRを作ったときにベースリポジトリに更新が走ると更新するボタンが出てくるが、これを押すと中身のない空のマージコミットが作られることや、GitHubのバグとしか思えないよく解らない差分が出ることがあるのも挙げられる。こうやってやらなくていいことを増やすだけのシステムはUXが悪いと思う。

そして行儀の悪いソフトウェアの排除だ。行儀の悪いソフトウェアとは何かというと、もっぱら権利侵害を目的に利用されているのではないかと疑われているようなものである。

かつてGitHubでホスティングされていたyoutube-dlというソフトウェアがDMCA侵害でGitHubから消されることがあり、当時は結構騒がれた話だったと思う。その後、紆余曲折ありyoutube-dlは現在は再公開されているが、最近はほとんど更新されていない。恐らくフォークであるyt-dlpに開発が移ったと思われる。

そして今年に入ってからFAKKU, LLCが大規模なDMCAを通告した。これによりGitHubから多くのダウンローダー系ツールが削除されて祭りとなった。

この対応を受け、gallery-dlはCodebergへの移行を決めた。

個人的にはTwitterの画像を落とすのにHitomi-Downloaderをよく使っていたのだが、これもDMCAに含まれており削除の憂い目にあった。Hitomi-DownloaderはTwitterがXになり、APIが有料化してからもTwitterのメディアをバルクで落とせるので重宝していた人が多くいたと思う。なおHitomi-Downloaderについては移転したとかはなく、単に消えてそうだ。バイナリはググれば出てくるが、APIが変わってるので、もう動かないと思う。余談だが、現在Twitterの画像をバルクで落とせる無料のソフトウェアはgallery-dlくらいだと思う。

また前述したGitHubの不安定さや、AIの存在を理由にGitHubを離れたものとしてプログラミング言語のZigがある。ZigはGitHubの現状に失望し、痛手を負ってでもCodebergに移行した。現在のGitHubは更新されておらず、移行のメッセージが残されている。

また玄人向けのLinuxディストリとして知られるGentoo LinuxもGitHubのLLM方針に反発し、Codebergへの移行を発表している。

Gentooの2025年振り返りでは、「Goodbye Github, welcome Codeberg」という言葉も見られ、Planet Gentooでは開発者からLLMに対する鬱憤ともいえる批判が多く寄せられている。

個人的に強く共感したものには次のものがある。

They start using LLMs because they don’t want to maintain their code anymore. Software turns into slop, which burns out even more people.
(ja: 彼らは、もうコードのメンテナンスをしたくないという理由で、LLMを使い始める。その結果、ソフトウェアはずさんなものとなり、さらに多くの人々が燃え尽きてしまう。)

LLMを使う理由はコードを書きたくないから、メンテしたくないから、動いている風に見えればよいからだというのは私も思う。バイブコーディングで出てきたものがまともに動く保証はない。

公私ともにLLMを使ってコーディングしているが、本当にそう思うし、仕事ではLLMに毒されすぎたのか判断能力を失ってしまった人も見かける。

Gentoo aims to be made by humans

We banned LLM contributions two years ago, and never regretted it. We didn’t “wait and see”, we took decisive action, and if we got left behind, it’s only for the better. I can’t give you a 100% guarantee that no tainted code slipped through, but we’re doing our best to stay vigilant. In the end, it’s all about trust, and trusting one another is what builds our community.
(ja: 私たちは2年前にLLMによる投稿を禁止しましたが、その決断を後悔したことは一度もありません。「様子を見る」のではなく、断固たる措置を講じました。もし他者に遅れをとったとしても、それはむしろ良いことなのです。不適切なコードが混入していないことを100％保証することはできませんが、私たちは警戒を怠らないよう最善を尽くしています。結局のところ、すべては信頼にかかっており、互いを信頼し合うことこそが、私たちのコミュニティを築き上げるのです。)

この人間らしさには非常に共感した。特に「もし他者に遅れをとったとしても、それはむしろ良いことなのです。」の部分だ。誰かより早くある必要はない、誰かと比べて遅れていても問題ではない。何故なら競技ではないし、そもそもベクトルが違うと私は思う。

他にもAutodesk Fusion 360 for Linuxも同様の理由でCodebergへの移行を行い、GitHubは既にアーカイブされている。

GitHubでホストする意味がなかった

lycolia.info、つまりサイトトップを触っていて思ったのだが、自分が作ったソフトウェアを見てもらうのに外部サイトにアクセスしないといけないというのが癪だと思った。

ソフトウェアの配布なら最悪自分のサイト上でzip配布でもすりゃあいいじゃんという話だ。

ただまぁ事はそう単純でもなく、リポジトリをWebサイトに置いておくと、出先からスマホでちょろっといじりたいとか、テキストとして転がして置き、一々ダウンロードせずコピペしたいみたいな絶妙な需要を満たせるので、セルフホストでかつ、GitHubの様な機能を満たせるものというところでForgejoを採用したのである。

勿論、先述したようなGitHubへの信頼性問題もあるが、私がDMCAでどうにかなる可能性は今のところないので、まぁ宗教みたいな話ではある。

そういえば以前WSL2のUbuntu 20.04にGiteaを生やすという記事を書いたし、Giteaにはコントリビュートしたこともあるが、GiteaのフォークであるForgejoでこんなことを始めるとは夢にも思わなかったので、めぐりあわせだなぁと思うのであった。

GitHubの個人用アカウントと業務用アカウントがどうのこうのを解決する糸口として

業務用と個人用でGitHubの無料アカウントを分けるは、このブログで二番目にアクセスの多い記事だが、Forgejoに完全に移行すれば、こういったことも解消できる。

なお現状ではGitHubのアカウントそのものはOSSのコントリに使うことが稀にあるため保持しておくつもりだが、いつ消し去っても良いくらいの温度感では持っておきたい所存である。

Forgejoに対する思い

分散型という諸刃の剣

Forgejoは、その構造上、各ホスト上でアカウントを作らないとコントリビューションができないと思うので、特定のプラットフォームからの支配や思想を回避できるのが利点だが、同時に欠点だとも感じている。

端的に言うとそれぞれのForgejoサーバーには何ら繋がりがない。あるForgejoサーバーでアカウントを作ったとしても、別のForgejoサーバーでは使えない。これはForgejoサーバーが増えれば増えるほど難しくなっていく問題かもしれない。私の様なサーバーでは問題にならないので別にいいが…。

但しFediverseにあるActivityPubのようにオープンプロトコルを作り連合を作る計画はあるようで、将来的には各ホスト同士での疎通が実現するかもしれない。

とはいえ、連合は連合で問題である。Fediverseも連合制をとっていて様々なサーバーが連合しているがMastodonとMisskeyには互換性の問題があるし、連合は数が増えれば増えるほど負荷が大きくなる問題もある。例えばA Forgejoサーバーの変更が10の連合先に伝播し、そこから更に各サーバーの先にある10に連合…となれば伝播する時間もリソースも無駄になってくる。

設計次第ではあるものの相互に繋がった数千のサーバーがやり取りを始めたらDoS攻撃に匹敵する負荷が発生するかもしれないし、様々な分散サーバーに同一の情報が保存されるのはストレージの無駄である。

この辺りはMisskeyの開発者であるsyuiloさんや、.ioの運営者である村上さんも話しているし、連合のコストについてはfedibird管理人ののえるさんも話している。

分散型はプラットフォーマの支配を受けず、独自性を出しやすい代償に、スケールしづらいのだ。ただ、DMCAの通報がされるようなソフトウェアにとってはそっちの方が都合がいいかもしれない。とはいえ、GitHubにBANされなくとも、次はAWSやVPSからBANされたり、ドメインが差し押さえられたり、自宅サーバーであってもISPから契約解除されるなどのリスクはあるので、程度問題ではある。

そういえば、この手の話をまさにしているスレッドがRedditにあったので、記録に残しておく。

今回設置した物体が見れる場所

エクスプローラー - LycoGit: Lycolia's Git Hostingで公開リポジトリの一覧が見れる。

ドメイン直下にアクセスすると「自分で立てる、超簡単 Git サービス」という強めのおもしろアピールが出てくる。

今のところはGitHubのリポジトリを丸ごと移しただけなので、中身的には同じものである。

今日のサーバー整備

nginxの共通設定にgzipの設定を入れて転送量を削減した。

この設定を入れただけ。

    gzip on;
    gzip_types
        text/plain
        text/css
        text/javascript
        text/xml
        application/javascript
        application/json
        application/xml
        application/rss+xml
        application/atom+xml
        application/font-woff
        application/octet-stream
        image/gif
        image/png
        image/jpeg
        image/gif
        image/webp
        image/svg+xml;

nginxとApacheのリバースプロキシについて色々確かめた。

nginxからApacheにリバースプロキシしてる時、nginxを前段のTLS終端、Apacheを後段にしているときにApacheの中でリダイレクトが走るとhttpsが壊れることがある現象を確認した。

これはディレクトリに対しhttps://example.com/hogeのようにアクセスするとhttp://example.com/hoge/に301リダイレクトがかかるのだが、どうもこの時にスキーマが引き継がれずHTTPになってしまうようだ。初めからhttp://example.com/hoge/としてアクセスすれば問題ない。

またこの現象が起きると証明書があるのにエラー表示になることも確認しているが、サブ機やスマホでは起きないようにも見えるので、この端末の証明書が何かしら変になっている可能性がある。キャッシュクリアしてもhttp降格が起きると再発するので、原因はよくわかっていない。GPT-5.5に聞いたもののハルシネーションしか得られず、ググってもnginx→Apacheの情報はほとんど得られなかった。多分ニッチな構成なのだろう。

さくらのレンタルサーバーもnginxからApacheに繋いでいるので、これをどうやっているかが知れれば改善の手掛かりになりそうだが、知る術がないので何ともだ。まさか聞くわけにもいかないし…。

そういえばさくらのレンタルサーバーではSNI SSL^[1]が使われていると聞くので、これを使えば上手くいくのかもしれない。

SSL/TLS接続のはじめに、クライアントはSSL/TLSのサーバから（サーバとCAの）証明書を受け取り、証明書の改ざんされていないことなどを確認する。サーバ証明書にはホスト名が書かれており、それが今接続しようとしているホスト名と一致することをクライアントは確認する。そうでない場合、なりすましや中間者攻撃の恐れがあるため、クライアントはユーザに警告をする。ユーザの責任で証明書を信用し、警告を迂回することができるアプリケーションも存在する。

というかWikipediaに上記の記述があったので、これのせいかもしれない。問題が起きているドメインはlycolia.infoで、元々さくら側で証明書を設定していたのでHTTPに落ちたときにその証明書が引っかかってエラーになっているとかはあるのかも？

さくらのドメインであるsakura.ne.jpを踏むとhttpでもhttpsに転送されるのと、ひょっとしたら類似の現象が起きているのかも…？いや、わからないが…。

サイト構成の変更をし始めた

このサイトの構成がイケてないなという思いが強くなったのでやることにした。

まずlycolia.infoが単なるLPに成り下がっていることが勿体なかったので、このドメインの傘下にコンテンツを増やすことにした。

一つ目はtool.lycolia.infoのドメインを廃止して、lycolia.info/tool/にぶら下げた。これはそもそもドメインを分割してやるようなサイトではなかったし、コンテンツの一部でいいと思ったからだ。

二つ目はこのブログにあったリンク集をlycolia.info/link/にぶら下げた。そもそも、本質的にサイトトップではない、このブログにリンク集があることに長らく違和感があったので丁度よかった。また移設に伴い紹介コメントも多少変更しているほか、元々のリンクが間違っていたなどもあったので、そのあたりも修正している。

そして今後は自己紹介などもブログから剝がして移動したいと思っている。ただ今のところすべてサーバー内からのHTML手打ちで、厳しさを感じるので、将来的にはCMSにしたいとも思った。

少なくとも今今は自宅サーバーである以上、家の中にいれば直にファイルをいじれるので問題はない。出先で書き換えたくなった時に困るくらいだ（一応頑張れば出先からもいじれなくはないが…）

サイト構成の変遷

本日リアルタイムでサイトを書き換えていて本番Hot Module Replacementみたいなことになっていた風景の一部を残しておく。

これが元々の状態。

改築途中の状態、なんか色々アレなことに…。

そして一旦本日の作業が終わった状態。また明日以降ちょいちょい直していくと思う。

移設したリンク集

移設前	移設後

見た目的には大きく変わり映えしないどころか、まともにスタイルを当ててないので殺風景だが、その辺りは追々どうにかしていこうと思う。

これでも一応レスポンシブデザイン、しかもモバイルファーストで作っているのでスマホで見たときの見やすさは向上している。

何せフルスクラッチでHTMLを手書きして、置換ではなく手作業で移設を行ったので移設するだけで時間が溶けてしまったので、今日はこんなところといった感じだ。

さくらのレンタルサーバーにTiny Tiny RSSを建てるでも紹介したTTRSSだが、現在の最新版だとレンタルサーバーでの利用は恐らくできなくなっている。

そこで代わりとなるフィードリーダーを探したところ、FreshRSSが軽量でよさそうだったので、今回自宅サーバーに導入してみたログを書く。

※さくらのレンタルサーバーへの導入もできると思うが、試していない。

確認環境

nginxからApache2へリバプロしている構成。

導入手順

私のサーバーでの導入ログなので一般化しづらい内容だが、要点が理解できればさくらのレンタルサーバーにも設置できるはずだ。

1. FreshRSS本体の入手と設置

   cd /var/www/path/to
   wget https://github.com/FreshRSS/FreshRSS/archive/refs/tags/1.29.1.zip
   unzip 1.29.1.zip
   mv FreshRSS-1.29.1 feed_reader
   sudo chown -R www-data:www-data feed_reader/
   sudo mysql -u root
   

2. ユーザーとDBの作成

   CREATE USER 'freshrss'@'localhost' IDENTIFIED BY 'パスワード';
   CREATE DATABASE freshrss CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
   GRANT ALL PRIVILEGES ON freshrss.* TO 'freshrss'@'localhost';
   exit
   

3. nginxにリバプロ追加、apacheにvhost設定追加、ddnsスクリプト追加、DNS反映
4. https://freshrss.example.com/など、設置したURLにアクセスする
5. 非常に親切なウィザードが出てくるので、一般的なPHPスクリプトのインストールと同様に進める
   

   

   

6. インストールが完了するとログイン画面に遷移するのでログインする
   • 遷移しなかった場合何かが間違っているので最初から全部やり直したほうがいい
7. ログインするとメイン画面が表示されるので、左上の「購読フィードの管理」からフィードを登録する。TTRSSから乗り換える場合は事前にOPMLをエクスポートしておくと移行がスムーズだ
   

   

8. フィードを登録し終えたら「フィードを更新」を押すとフィードが更新される。TTRSSではコマンドを蹴る必要があるのでこれは便利だ
   

   

9. これでフィードが出てくればOK
   

   

10. 最後に定期的にフィードを読ませるためにCRONを設定する

    10 * * * * www-data php -f /var/www/path/to/FreshRSS/app/actualize_script.php > /tmp/FreshRSS.log > /dev/null
    

FreshRSSを使ってみての感想

TTRSSと比べるとかなりシンプルというのが一つ目の感想だ。フィードリーダーとしての機能しかなく、GoogleReaderのクローンとして作られたTTRSSと比べると非常にシンプルだと思った。

正規表現によるフィルタといった高度な機能はなく、画面も今どきのスタイリッシュな感じに見えた。悪く言えばスカスカというか。

結論としてはTTRSSの方が好みだったので、私は古いTTRSSを使い続けることにした。

あとがき

TTRSSのGitHubを見た感じ、去年の10月9日にはLAMPスタック、いわゆるCGIとしての動作を打ち切っていたようだ。今使えている場合は問題ないと思う。

しかし、Androidアプリも2025-11-01でサポートが終わり、既にAPKの配布すらされていないため、Androidアプリは時期に使えなくなるかもしれない。

自宅サーバーに入れるにもDockerベースの運用が基本になり、直接起動は厄介そうな気配を感じた。軽い気持ちでチャレンジしたらサーバーのメモリを食いつぶし、まともに操作できなくなった。しかしこんな状態でもPrometheusとNode Exporterは仕事をしてて偉いなぁと思うのだった。

個人的にTTRSSはレンタルサーバーで動く軽量さがありつつも、正規表現によるフィルタでアフィリエイト記事を弾いたり、便利なAndroidアプリがあったり、UIも使いやすかったり、中々重宝していたが、同時に以前からAndroidアプリが優勝から無償になったり、配布場所が変わったり、更新が放置されたり、本体にも破壊的変更が入ったりで、非常に変革の多い体制を危ぶんでいた。

そして今回の出来事を見るに、個人的にレンタルサーバーで使っていた人や、Dockerが嫌な人にとっては厳しい状況になったと思った。とはいえ、今すぐに使えなくなるわけではないので、今運用している人はそのままでいいと思った。

私は結果としてFreshRSSでは満足できなかったのでTTRSSに戻ることにした。なおバージョンを確認しようとしたら「Tiny Tiny RSS vUNKNOWN (Unsupported) © 2005-2026 Andrew Dolgov」とあったので、どうも私が使っているもののバージョンは不明だった。

さくらのレンタルサーバーにTiny Tiny RSSを建てるにはコミットハッシュを書いていたので、おそらくこれをそのまま使い続けているのだと思う。