2026/06/09(火)TTRSSの最新版が使えなかったのでFreshRSSを試してみたけどイマイチだったログ
さくらのレンタルサーバーにTiny Tiny RSSを建てるでも紹介したTTRSSだが、現在の最新版だとレンタルサーバーでの利用は恐らくできなくなっている。
そこで代わりとなるフィードリーダーを探したところ、FreshRSSが軽量でよさそうだったので、今回自宅サーバーに導入してみたログを書く。
※さくらのレンタルサーバーへの導入もできると思うが、試していない。
確認環境
nginxからApache2へリバプロしている構成。
| Env | Ver |
|---|---|
| OS | Ubuntu 24.04.4 LTS |
| nginx | 1.26.1 |
| Apache2 | 2.4.58 |
| PHP | 8.3.31 |
導入手順
私のサーバーでの導入ログなので一般化しづらい内容だが、要点が理解できればさくらのレンタルサーバーにも設置できるはずだ。
- 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 - ユーザーと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 - nginxにリバプロ追加、apacheにvhost設定追加、ddnsスクリプト追加、DNS反映
https://freshrss.example.com/など、設置したURLにアクセスする- 非常に親切なウィザードが出てくるので、一般的なPHPスクリプトのインストールと同様に進める


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

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

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

- 最後に定期的にフィードを読ませるために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を建てるにはコミットハッシュを書いていたので、おそらくこれをそのまま使い続けているのだと思う。
2026/06/08(月)FluentBitでSystemdのログをLokiに送ってGrafanaで見れるようにし、ついでに設定をYAMLにした
投稿日:
本記事は自宅サーバーに雑に監視を入れた時にやったこと、先日の自宅サーバー移転に対し追加対応をしたの続きである。
今回はSystemdのログをFluentBitで拾ってLokiに送ってGrafanaで見れるようにしたログ。
AWSやDockerなどを使った情報は散見したが、バイナリをネイティブ環境で動かしている情報や、複数のデーモンのログを収集する方法が見当たらなかったのでちょっと苦労した。GPT-5.5も正確なことを言わないので真面目にリファレンスを読んだりググったりして何とかした。LLM頼みも限度があるね。
確認環境
| Env | Ver |
|---|---|
| OS | Ubuntu 24.04.4 LTS |
| Fluent Bit | 5.0.6 |
| Loki | 3.5.9 |
| Grafana | 12.1.1 |
設定内容
今回は前回までのconfig設定をYAML設定に全面移行した。基本的にはデフォルトのconfigファイル+私が使っているI/Oの移植である。Lokiの待ち受けポートが9100であると仮定して進める。
各設定については公式マニュアルを参照のこと。
service→ Service | Fluent Bit: Official Manualstorage→ Storage configuration | Service | Fluent Bit: Official Manual- serviceに元々あったが別キーに分離している。但しドキュメントのページは同じ。わかりづらい
systemd→ Systemd | Fluent Bit: Official Manualsystemd_filterを複数設定する方法は記載がないが、配列にすればよい
service:
flush: 1
log_level: 'info'
parsers_file: 'parsers.conf'
plugins_file: 'plugins.conf'
storage:
metrics: 'on'
pipeline:
inputs:
- name: 'systemd'
tag: 'systemd'
db: '/var/lib/fluent-bit/systemd.db'
systemd_filter:
- '_SYSTEMD_UNIT=adiary.service'
- '_SYSTEMD_UNIT=mastodon-web.service'
- '_SYSTEMD_UNIT=mastodon-sidekiq.service'
- '_SYSTEMD_UNIT=mastodon-streaming@5001.service'
- name: 'tail'
tag: 'nginx.access'
path: '/var/log/nginx/access.log'
parser: 'json'
db: '/var/lib/fluent-bit/nginx-access.db'
refresh_interval: 5
- name: 'tail'
tag: 'nginx.error'
path: '/var/log/nginx/error.log'
db: '/var/lib/fluent-bit/nginx-error.db'
refresh_interval: 5
- name: 'tail'
tag: 'apache.access'
path: '/var/log/apache2/access.log'
parser: 'apache2_vhost'
db: '/var/lib/fluent-bit/apache_access.db'
refresh_interval: 5
- name: 'tail'
tag: 'apache.error'
path: '/var/log/apache2/error.log'
db: '/var/lib/fluent-bit/apache_error.db'
refresh_interval: 5
outputs:
- name: 'loki'
match: 'systemd'
host: '::1'
port: 9100
labels: 'job=systemd'
- name: 'loki'
match: 'nginx.*'
host: '::1'
port: 9100
labels: 'job=nginx, log_type=$TAG[1]'
- name: 'loki'
match: 'apache.*'
host: '::1'
port: 9100
labels: 'job=apache, log_type=$TAG[1]'
PARSER: apache2_vhost
前回の記事で作った以下のパーサーを利用している。
[PARSER]
Name apache2_vhost
Format regex
^(?<host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*)(?: "(?<referer>[^\"]*)" "(?<agent>[^\"]*)")?$
Regex ^(?<vhost>[^:]+):(?<port>\d+) (?<remote_host>[^ ]*) [^ ]* (?<user>[^ ]*) \[(?<time>[^\]]*)\] "(?<method>\S+)(?: +(?<path>[^\"]*?)(?: +\S*)?)?" (?<code>[^ ]*) (?<size>[^ ]*) "(?<referer>[^\"]*)" "(?<agent>[^\"]*)"$
Time_Key time
Time_Format %d/%b/%Y:%H:%M:%S %z
Time_Keep On
また前回の記事で作成したapache_errorというパーサーについては役に立たなかったので使わなくなった。標準で付いてるapache_errorも使えないし、apache2もイマイチ使えないので公式のパーサーは当てにしないほうがいいのかもしれない。
なおパーサーは旧config形式で記述している。これはとてもじゃないが書き換えてられないボリュームだったのとYAMLに対応させようとするとエスケープがだるそうだったからだ。config形式は今年でサポート外になるようだが、既存の設定のプリセットはすべてconfig形式でしか存在しないため、何とも先行きが心配だ。
サービスの修正
設定を.confで読んでいるので、ここを.yamlに変えてやる。
[Unit]
Description=Fluent Bit
Documentation=https://docs.fluentbit.io/manual/
Requires=network.target
After=network.target
[Service]
Type=simple
EnvironmentFile=-/etc/sysconfig/fluent-bit
EnvironmentFile=-/etc/default/fluent-bit
+ExecStart=/opt/fluent-bit/bin/fluent-bit -c /etc/fluent-bit/fluent-bit.yaml
-ExecStart=/opt/fluent-bit/bin/fluent-bit -c //etc/fluent-bit/fluent-bit.conf
Restart=always
[Install]
WantedBy=multi-user.target
インストールした当時は何故YAMLで書いても読んでくれないのか悩んでいたが、こんなところで指定されていた。しかも何故かパスが二重スラッシュになっていたので、そこも直しておいた。
FluentBitが上手く動いてなさそうなときのデバッグ方法
以下のコマンドを流すと動いているかどうかが分かる。なんかログが取れてなさそうだったり、Lokiに届いてなさそうなときに使える。
/opt/fluent-bit/bin/fluent-bit -i systemd \
-p systemd_filter=_SYSTEMD_UNIT=mastodon-web.service \
-p tag='host.*' \
-o stdout
あとがき
なんか最近のソフトウェアのマニュアルって論理的に書かれすぎてて具体的にどう設定したらいいのかよくわからなくて困る。もう少し具体的な設定例とか書いてくれてもいいと思うんだ。
YAML configuration files are the standard configuration format as of Fluent Bit v3.2. They use the .yaml file extension.
Classic configuration files will be deprecated at the end of 2026. They use the .conf file extension.
しかしconfigは今年末でサポート外になるという話があるのにGitHubのリポジトリの設定ファイルは全部configで、果たしてこんなので大丈夫なのか…とIssueを眺めていたら、そもそも開発側もYAMLの仕様を余り解ってないような空気を感じたので、これは今年中は厳しいのではないか?という感じがした。
- YAML configuration should be idiomatic
- Create a JSON Schema for YAML Config and publish to SchemaStore
ひとまず私はキー名がkebab-caseからcamelCaseになってもすぐ対応できるようにメインの設定だけYAMLにしておいたが、Parserを直すのはエスケープが面倒などもあると思うので、なかなか大変だと思う。
あと個人的に不思議に思った部分としてoutputsのlabelsが配列ではなく、文字列だというところだ。
pipeline:
outputs:
- name: loki
match: '*'
labels: job=fluentbit, mystream=$sub['stream']
何でここは配列にしなかったのだろうか?
実際に以下の記述でラベルが機能しているので、おそらくこの構文がFluentBitのDSLとして機能していて、真面目に配列すると改修が大変とか、そういうのがあるのかもしれないなとは思った。
- name: loki
match: 'apache.*'
host: '::1'
port: 9100
labels: 'job=apache, log_type=$TAG[1]'
ちなみに一番ハマったのはブログ執筆用に作っていたLokiのポートを書き換えたメモを基に作業していて、未来永劫FluentBitがLokiに疎通しなかったことである。
2026/06/08(月)駄文同盟の最初から現在までの登録状況を軽く調べてみた
投稿日:
本記事は古のサイト探究~駄文同盟のID上位100サイトを巡り、今までのネット人生や自サイトの過去を振り返ってみるの続きの様なものだ。
今回は駄文同盟登録にしている全サイトを機械的に調査した結果を出していく。前回は全手動だったのできめ細やかな結果を出せたが、今回は機械集計なので大まかな傾向を書いてゆく。
調査方法としては以下のコマンドでスクレイピングしたものを正規表現で成形し、エクセルで集計している。
for i in $(seq 1 20457)
do
dates=$(curl "http://www.dabun-doumei.com/data/${i}.html" | iconv -f SJIS -t UTF-8 | grep -e "登録日:" -e "更新日:")
echo "No.${i} $dates" | tee -a "dabun-doumei-dates.txt"
done
年毎の登録件数
このグラフはその年ごとの駄文同盟への登録件数をグラフにしたものだ。
その年に初めて見つかった登録サイトと、その年最後の登録サイトの件数をカウントしているため、駄文同盟の登録を解除したサイトも件数に含まれている。
逆に年と年の継ぎ目に登録解除したサイトがあると、そこは空白になってしまう。結果として55件の空白サイトがあった。
基本的に2004~2008年あたりがピークといった感じで、2009年からは登録件数が大きく減っている。2004年も少ないのだが、2004/10/20がID:1の登録日であるため、開設直後かつ、年末まで二ヶ月半しかなかったことを考えるとこれは仕方ないだろう。
2010年からは割合にして7.19%と、前年の10.18%から一気に減少し、2014年まで減少が続く。2015年は前年比0.74ポイント増えていて、何があったのかちょっと気になる。
2017年に入ると登録数が200を切り、低位に推移していくものの、横ばいが続く。しかし2022年から減少傾向に転じ、2024年には3桁を割り込み、遂に80件にまで落ち込んでしまう。
駄文同盟自体の知名度が落ちていることや、既にメンテナスもされていないことも多分にあると思うが、駄文同盟の登録件数ベースで見るとも何とも悲しい数字だ。しかし今年は既に25件あるため、もう少し横ばいで推移する可能性もある。
とはいえ、この時代に個人サイトを新規に起こしたとして、従来のように駄文同盟や、それに類するサイトに登録する人も多くはないだろうから、時代の流れとして致し方ない部分もあるのだとは思う。
登録状況
このグラフは現在の駄文同盟の登録状況をグラフにしたもので、内訳としては以下の通り。
- 更新あり=現在有効な登録があり、最低でも一度は登録を更新している(登録日時と更新日時に差異がある)
- 登録解除=登録が解除されている(IDが消滅している)
- 更新なし=現在有効な登録があるが、一度も登録更新されていない
つまり実に過半数のサイトが登録を解除しており、残ったサイトは全体の44.66%しかないことが分かる。その中で駄文同盟の登録後に一度でもサイト情報を更新したサイトの割合は76.97%だ。77%に丸めて考えると大半のサイトは何かしら一度は更新していることになる。
直近で更新があった時期
これは直近五年間で駄文同盟の登録情報を更新したサイトの件数を出している。
駄文同盟では一回も更新しなくても登録日=更新日であるため、5年以内に登録したサイトが必然的に含まれており、そこは除外していない。
頭のパーセンテージはIDの最大値に対して出しているため、あまり意味がないものになっているが、意外と更新しているサイトが多いことが伺えた。
集計データ
今回も前回同様、Google Spreadsheetに集計データをまとめている。また同様に以下に表も貼ろうと思ったが二万行以上あるため、今回は断念した。
2026/06/08(月)3年ぶりにChatGPTに帰ってきた
Chat GPT3.5が出た当初、私は狂ったようにChatGPTを利用していた。レートリミットを無視するために最大13アカウントを並列で運用していたほどだ。
しかしChat GPT-4辺りから雲行きが怪しくなり、GPT-4oで遂にERPが封じられた。そしてそのタイミングでちょうど出てきたのがClaudeだった。
ClaudeはERPができるだけでなく、GPTより性能が良かった。それゆえに私はそれからClaude Opus 4.7に至るまでClaudeを使い続けた。AnthropicにBANされようと、なお使い続けた。
しかしそれに転機が訪れたのがClaude Opus 4.8だった。Opus 4.8でもERPは出来なくはないのだが、よくある同人誌にありがちな奴ができなくなった。いわゆる非実在未成年モノというやつだ。
そして私はClaudeに対して最近良い感情があまりなかった。Claude Codeは余計なことをよく行い、指示を守らない、逸脱するというのが往々にしてあった。私はClaudeに対するコーディング面での信頼を4.7のころから失い始めており、4.8で決定的になった。
この辺りに関しては私より草片きのぽ氏のほうがよく言語化できているので勝手に紹介させていただく。この辺りの感覚は私も共感できる部分がかなりあった。
そこで、ふと思ったのだ。GPTならどうか?私はOpenAIにはBANされてない。ERPしないならGPTでもいいのでは?というところで、一昨日くらいからGPT-5.5がいい感じなので、OpenAIに戻ってくることにした。
Poe経由でClaudeを使うと非常にお金がかかるが、OpenAIに月額課金する場合はそこまでお金はかからない。ERPももう飽きてきたところだったし丁度よかった。
かつて作っていたアカウントの多くは不正利用を恐れて閉鎖しており、同じメールアドレスでアカウントを作れないので困っていたが、かろうじて一匹生きているアカウントを発見したら、なんと三年ぶりの課金であることが判明した。
今のところGPTは支持に従うし、GPT-5の時の様なそっけなさというかイマイチ使えない感じもなくなり、ずいぶんよくなったと思う。ClaudeのようにAI臭さのある文章を出してこないのも個人的に好印象だ。
というわけで、長らく続いたClaude生活から、またGPT生活に戻っていきそうだ。節約にもなるし、これはいいかもしれない。
ところで請求の単位がUSDからJPYになってるのが地味に面白いと思った。
2026/06/07(日)シェルの設定にRPS1を入れると微妙だったのでやめた話
投稿日:
私はzshをシェルとして使っており、かれこれ5年ほどプロンプトにPROMPTとRPS1を設定していたのだが、使っていてRPS1が非常に邪魔だったのでPROMPTに統一することにした。
邪魔だったもの
これまで私は画像のようにRPS1に日時と異常終了コードを出すようにしていたのだが、複数行選択したときに必然的に巻き込んでしまう問題があった。
これはコマンドの実行ログをブログに書く時や、複数コマンドをコピペするときにRPS1の部分を除去する必要があり、手間だった。
そこでRPS1を使うのをやめてPROMPTに統一することにした。行は増えたが、こっちのほうが視線移動もなくコピペ時の巻き込み問題も減るので楽になった気がする。
他にもRPS1はターミナルの幅が狭くなったり、一部のターミナルから開くと崩れやすかったので、今回の対応でそういったこともまとめて解消されてよかった。
これは余談だがPS1でなくPROMPTを使っている理由はPS1だとRPS1を使っているときに表示が崩れる環境があったが、PROMPTだとこれが起きなかったからだ。何故かはよくわかってない。







