さくらのレンタルサーバーに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 |
私のサーバーでの導入ログなので一般化しづらい内容だが、要点が理解できればさくらのレンタルサーバーにも設置できるはずだ。
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
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
https://freshrss.example.com/など、設置したURLにアクセスする
10 * * * * www-data php -f /var/www/path/to/FreshRSS/app/actualize_script.php > /tmp/FreshRSS.log > /dev/null
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を建てるにはコミットハッシュを書いていたので、おそらくこれをそのまま使い続けているのだと思う。
本記事は自宅サーバーに雑に監視を入れた時にやったこと、先日の自宅サーバー移転に対し追加対応をしたの続きである。
今回は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
systemd → Systemd | Fluent Bit: Official Manual
systemd_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]
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で書いても読んでくれないのか悩んでいたが、こんなところで指定されていた。しかも何故かパスが二重スラッシュになっていたので、そこも直しておいた。
以下のコマンドを流すと動いているかどうかが分かる。なんかログが取れてなさそうだったり、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の仕様を余り解ってないような空気を感じたので、これは今年中は厳しいのではないか？という感じがした。
ひとまず私はキー名が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に疎通しなかったことである。
この記事の話は仮運用環境の構築なので、本番向きではない。また必要であろうDBのセットアップは今回していない。
端的に言うとBOTを弾くためのWAFのような奴だ。公式サイトはAnubis: Web AI Firewall Utility | Anubisだが、その名の通りLLMのクローラーを弾くことを重点にしている。
こういった感じのCloudflareにあるようなBOT認証画面が出てくるのだが、これが結構かわいい。公式サイトもかわいい。カナダのFF14プレイヤーの人が作ってるらしい。
実際の動作画面はList of known websites using Anubis | Anubis辺りから見れる。FOSSや、ザ・海外のオタクみたいなサイトが軒を連ねている。
最近BOTのアクセスが目立つし、こういう可愛いのいいなと思って導入を検討したのが事の発端だ。
ちなみにローディング画面はカスタマイズも可能なので、カスタマイズしている人もいるが、ちゃんとかわいい文化が継承されているのがいい。
またAnubisを導入しているサイトをClaude Opus 4.8に見させたところエラートラップに掛かって閲覧できなかったので機能的には問題なさそうだった。LLM越しにコンテンツを見られたくない場合には、かなりフィットしそうだ。
adiaryはFastCGI + libfcgi-perl、PukiwikiはFastCGI + PHP-FPMで実行している。
| Env | Ver |
|---|---|
| Ubuntu | 24.04.4 LTS |
| Anubis | 1.25.0 |
| nginx | 1.26.1 |
| adiary | 3.52dev / Extends 0.25.0 |
| libfcgi-perl | 0.82+ds-3build2 |
| Pukiwiki | 1.5.4 |
| PHP-FPM | 8.3.31-3+ubuntu24.04.1 |
| Prometheus | 3.5.0 |
まずは/etc/anubis/default.envに設定があるので適当に書き換える。
以下は設定例。細かいのは公式の設定ドキュメントに書いてある。
BIND=[::]:10000
DIFFICULTY=4
METRICS_BIND=[::]:9110
SERVE_ROBOTS_TXT=0
REDIRECT_DOMAINS="example.com,*.example.com"
TARGET=http://[::1]:8081
OG_PASSTHROUGH=true
あとはサービスを有効化して開始すれば動く。
sudo systemctl enable anubis@default.service
sudo systemctl start anubis@default.service
今回設定した項目について
| 項目 | 役割 |
|---|---|
BIND |
Anubis自体のListenポート |
DIFFICULTY |
チャレンジの難易度 |
METRICS_BIND |
Prometheusがポーリングしに来る時のポート |
SERVE_ROBOTS_TXT |
Anubisにrobots.txtを代理生成させるかどうか |
REDIRECT_DOMAINS |
Anubisの先にあるサイトのドメイン、無指定だと悪意のあるサイトに飛んでいく可能性がある |
TARGET |
Anubisがプロキシする先のサイト。Anubisから繋ぎこむ先を同じポート番号にしていれば一元的に飛ばせる |
OG_PASSTHROUGH |
OGをパススルーするかどうか。Anubis自身がOGを取り込んでSNSとかのOG取得BOTに渡してくれるのだと思う |
example.com, blog.example.com, tool.example.comに対してAnubisを利かせたい場合、以下のように書く。
upstream anubis {
server [::1]:10000;
}
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name example.com blog.example.com tool.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://anubis/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
listenポートをAnubisから投げるポートに変更し、TLS終端でなくなるため証明書も消し去る。ここは受け口ではないため受けるIPも片方だけあればいい。
server {
- listen 443 ssl;
- listen [::]:443 ssl;
+ listen [::]:8081;
server_name blog.example.com;
- ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
- ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
...
}
余談だが、以下のような記述がある場合、Anubisがいい感じにしてくれるので消せる、というか消さないとポート番号がむき出しになったり、無限リダイレクトし始めるので、そういうことが起きたら消したほうがいい。
location = /hoge {
return 301 /hoge/;
}
scrape_configs:に以下をぶら下げれば取れる。メトリクス名はanubis始まり。
- job_name: 'anubis'
static_configs:
- targets: ['[::1]:9110']
https://eco.lycolia.info/wikiにアクセスするとhttp://eco.lycolia.info:8081/wikiとなり、HTTP通信になったうえ、ポート番号が露出する問題が発生した。この問題はケツにスラッシュをつけてると起きなかった。
これはnginxに次の設定をしていたため、これを消すことで解消した。削除してもAnubisがいい感じに繋いでくれるようでhttps://eco.lycolia.info/wikiで問題なくアクセスできた。
location = /hoge {
return 301 /hoge/;
}
取れないなぁ…と思ってググったら、GitHubにIssueが出ていたので取れないっぽい。
この時点で導入を断念した。
sudo systemctl stop anubis@default.service
sudo systemctl disable anubis@default.service
sudo apt remove anubis
sudo rm -Rf /etc/anubis
sudo systemctl restart nginx
BOT弾きついでにAnubisの可愛い画面を出せるようにと導入を検討していたが、結果として断念した。Matomoでリファラが取れないのが深刻すぎたからだ。
リファラが取れるようになったら、また試すかもしれないし、試さないかもしれない。或いはそういう風に改造するか。でもこの手の奴はセキュリティリスクが高いので、あまり自分では触りたくない気持ちもある。
しかし個人サイトWebオンリー めぐる市の会期中にサーバーの上げ下げをしながらメンテを連発していたので、何ともアレである。まぁうちのサイトは管理人である私が好き放題やる実験場なので仕方がないね。
昨日、さくらのレンタルサーバでホスティングしていたサイトの大部分を自宅サーバーに移行したが改善点が幾つか見えたので、その追加対応をしたログ。
こちらについては構築記事をUbuntuのadiaryをlibfcgi-perlで動かす方法に、パフォーマンス計測記事をサイト環境を移転したのでadiaryのパフォーマンス計測をやってみたに書いている。
Pukiwiki本体はPHP-FPM、それ以外をApacheで動かすようにしている。キメラ構成。
将来的にドメイン直下に静的コンテンツを置いたり、サイトをレガシー技術で拡張することを念頭に置いて設計しているがKISSだし、意味があるかどうかは謎である。
server {
...前略...
root /var/www/path/to/eco;
location = /wiki {
return 301 /wiki/;
}
location /wiki/ {
try_files $uri /wiki/index.php$is_args$args;
}
location ~ ^/wiki/.+\.php$ {
fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
fastcgi_index index.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}
location / {
proxy_pass http://apache/;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
/etc/fluent-bit/parsers.confに以下のパーサーを追加した。(LLMの言った内容のコピペ)
[PARSER]
Name apache_vhost
Format regex
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
[PARSER]
Name apache_error
Format regex
Regex ^\[(?<time>[^\]]*)\] \[(?<module>[^:]*):(?<level>[^\]]*)\] \[pid (?<pid>[^\]]*)\](?: \[client (?<client>[^\]]*)\])? (?<message>.*)$
Time_Key time
Time_Format %a %b %d %H:%M:%S.%L %Y
Time_Keep On
/etc/fluent-bit/fluent-bit.confに対し、以下のような設定を追加。(LLMの言った内容のコピペ)
[INPUT]
Name tail
Path /var/log/apache2/access.log
Tag apache.access
Parser apache_vhost
DB /var/log/flb_apache.db
Mem_Buf_Limit 5MB
[INPUT]
Name tail
Path /var/log/apache2/error.log
Tag apache.error
Parser apache_error
DB /var/log/flb_apache_error.db
[OUTPUT]
name loki
match apache.*
host ::1
port 9100
labels job=apache, log_type=$TAG[1]
上記の設定にあるポート番号は他の記事と整合するように書いているつもりだが、ひょっとしたらずれているかもしれない。ちなみにうちのサーバーでは上記と別のポートを使っている。
こうすることでログファイルを統一でき、管理が楽になる。
/etc/apache2/sites-enabled/hoge.confからログ設定を削除
#LogLevel info ssl:warn
- ErrorLog ${APACHE_LOG_DIR}/eco-error.log
- CustomLog ${APACHE_LOG_DIR}/eco-access.log combined
</VirtualHost>
/etc/apache2/apache2.confのファイル末尾に共通的なログ設定を追加。vhost_combinedを指定することでログにホスト名が出るようになっている
ErrorLog ${APACHE_LOG_DIR}/error.log
LogFormat "%v:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" vhost_combined
CustomLog ${APACHE_LOG_DIR}/access.log vhost_combined
今回のサイト移転に伴い、IPv6側が優先接続されるようになったのか、アクセスカウンタが回らなくなったため、アクセスカウンタにIPv6対応を施した。
具体的にはうちで使っているアクセスカウンタはリモホを見て日本のISPならカウントしているのだが、IPv6ではリモホが取れないためカウントできない問題があった。この問題そのものは去年の8月には気づいてIssueにしていたのだが、対応せず放置していたところ、ちょっとこれは困ると思って対応した。
変更差分としては、UAによるBOT判定を強化した上で、日本のISPかIPv6ならカウントするように変更した。また、条件分岐がmutableでイケてなかったので、Immutableになるように書き直した。
サイト環境を移転したのでadiaryのパフォーマンス計測をやってみたの環境構築した時のログ。
| Env | Ver |
|---|---|
| Ubuntu | 24.04.4 LTS |
| nginx | 1.26.1 |
| adiary | 3.52dev / Extends 0.25.0 |
| libfcgi-perl | 0.82+ds-3build2 |
nginxとperlがインストール済
sudo apt install libfcgi-perl
/etc/systemd/system/adiary.serviceを次のように作成し、adiaryのFastCGIデーモンを作る
[Unit]
Description=adiary daemon
After=network.target
[Service]
Type=simple
User=www-data
Group=www-data
WorkingDirectory=/var/www/path/to
ExecStart=/usr/bin/perl /var/www/path/to/adiary.fcgi /var/www/path/to/adiary.sock 10 100
Restart=always
[Install]
WantedBy=multi-user.target
sudo systemctl enable adiary.service
sudo systemctl start adiary.service
nginxの設定を書く
server {
listen 443 ssl;
listen [::]:443 ssl;
server_name blog.example.com;
client_max_body_size 100M;
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
root /var/www/path/to/blog;
location / {
try_files $uri @adiary;
}
location /__cache { deny all; }
location /data { deny all; }
location ~ \.cgi$ { deny all; }
location @adiary {
include fastcgi_params;
fastcgi_pass unix:/var/www/path/to/adiary.sock;
fastcgi_param Basepath /;
}
}
sudo systemctl restart nginx
adiary.httpd.plがオススメらしいのは見たが、HTTPサーバーは脆弱になりやすいことや、ログの使い勝手がどうなのか確認するのが面倒なこと、IPv6対応させるのが面倒だったことがあり採用しなかった。