Lycolog

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

本記事は自宅サーバーに雑に監視を入れた時にやったこと、先日の自宅サーバー移転に対し追加対応をしたの続きである。

今回はSystemdのログをFluentBitで拾ってLokiに送ってGrafanaで見れるようにしたログ。

AWSやDockerなどを使った情報は散見したが、バイナリをネイティブ環境で動かしている情報や、複数のデーモンのログを収集する方法が見当たらなかったのでちょっと苦労した。GPT-5.5も正確なことを言わないので真面目にリファレンスを読んだりググったりして何とかした。LLM頼みも限度があるね。

確認環境

設定内容

今回は前回までのconfig設定をYAML設定に全面移行した。基本的にはデフォルトのconfigファイル＋私が使っているI/Oの移植である。Lokiの待ち受けポートが9100であると仮定して進める。

各設定については公式マニュアルを参照のこと。

• service → Service | Fluent Bit: Official Manual
• storage → Storage configuration | Service | Fluent Bit: Official Manual
  • serviceに元々あったが別キーに分離している。但しドキュメントのページは同じ。わかりづらい
• 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: 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に疎通しなかったことである。

本記事は古のサイト探究～駄文同盟の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に集計データをまとめている。また同様に以下に表も貼ろうと思ったが二万行以上あるため、今回は断念した。

本日ピクリエ^[1]で開催されており、当サイトも参加している個人サイトWebオンリー めぐる市を見てきた感想。

このイベントでは参加サークルが一次創作、二次創作、その他に分類されているが、この記事ではその他ジャンルについての語りになる。

また本記事で行った調査は私が目で見た限りなので、漏れや誤りがある可能性もある。あくまで個人の感想であって、何かを批判したりするものではないことを先に断っておく。

トップページへの流入が凄く増えた

トップページというのはlycolia.infoのことだが、ここへのアクセスが爆発的に増えた。

ただピクリエはリファラを吐かないようで、実際にどの程度がピクリエなのかはわからない。さっきUTMパラメータ付きのURLを用意したが、開場が10時だったのに、書き換えたのが20時ごろの話なので、時すでにお寿司という感じはしている。

出オチした

Anubisを雑に設置したが、結果微妙だったので撤去した話でも少し触れているが、私はこの日このイベントがあることを知っており、サイトを生かしておかないとならないはずだったのに、会期中にAnubisの画面が出したいがために8時くらいからAnubisの導入試験を行っており、結果的に10時～13時半までサイトが断続的にダウンしていた。

一番アクセスが集中する時間にサーバーダウンを伴うメンテナンスをするとは愚の骨頂で、本末転倒である。

自分が想像していた「その他」サイトはそこまで多くなかった

サークル分類が一次創作、二次創作、その他とある以上、個人的には「その他」には日記や技術、DIY、写真などいわゆるサブカル系ではないものを期待していたが、その期待にそぐうのは半数の22サークル中11サークルだと感じた。個人的な感覚としては、小説や同人誌の頒布が中心のサイトは「創作寄り」に見えたため、自分が期待していた「その他」とは少し違って見えた感じだ。

とはいえ、ジャンル分けには各サークルなりの事情や判断があると思うので、外から見ただけであれこれ言うものでもない。

サイト制作の手段が変わってきている

上の図は今回その他ジャンルで公開されていた22サークルで使われていた技術を調べたものだ。1サイトに複数技術が入っているところもあるため、合計は22にならない。

やはりWordPressが最多で、根強い人気を感じる。またWordPressについてはSangoテーマを使っているサイトがないのも驚いた。

Sangoテーマは国産のWordPressテーマで、有償だが、その完成度ゆえに結構人気が高いテーマだと思っているので、これは意外だった。流行りすぎてて独自性を出しづらいのもあるかもしれないし、特に収益性を重視したブログとの親和性がいいため、非営利のサイトだと相性があまりよくないかもしれないなと思った。

しかし驚いたのは次点以降だ。てがろぐが次点に入ってきていて、Astroも勢いがある。まさかこの令和の世に個人開発のCGIがここまで流行るとは思わなかったし、Astroのような今どきの静的サイト生成系ツールが、こういった界隈でも普通に使われているのはかなり意外だった。

それとDokuWikiを使って創作サイトをやっている人がいるのも驚いた。見た目はどっからどう見ても良くできた小説サイトの体裁で、どこをどう見てもWikiに見えなかったからだ。

HTML手書きと思われるサイトも結構あり、こちらも未だに根強い人気がありそうだと感じた。シンプルイズベストというか、HTML手書きはCMSのように画一的な表現から解き放たれ、自由自在な構成が作れるのが魅力だと思う。

流石にadiaryは私のサイトしかなかった。知ってた。

最後になるが外部ホストというのはレンタルブログやWix、Notionなどの外部サービスを使ったものの事だ。これも手軽なことから一定数見られた。こちらはサービス側の制約も手伝ってか、レイアウトの独自性が高いものは少なかったように思う。

個人サイト制作勢にX(旧Twitter)やMisskey.ioは不人気？

この図は各サイトやピクリエ上の紹介リンクにあったSNSのうち、マイクロブログに入るものを集めたものだが、トップはBlueskyで、X(旧Twitter)は次点だった。Misskeyもあったものの、Misskey.ioを使っているところはなかった。またMastodonは一番少なかった。なおFedibirdはMastodonとして集計している。

それでもFediverseとしてカウントすれば7件になるわけで、個人サイト勢の中ではXからの離脱、或いはそもそもXをやらなかった人が多かったのかもしれない。

Misskey.ioがいなかったのは、今回の「その他」ジャンルの個人サイト勢とは、利用者層が重ならなかったのではないかと思っている。というのも、あそこは男性向け成人イラスト周りの要素が強く、今回の参加者層に一致する要素が少なかったのではないかと思っている。

SNSらしきリンクが見当たらない管理人さんも3名ほどいらっしゃったので、SNSより自分のサイトに注力したいとか、そういうのもあるかもしれない。

あとがき

全体的にみると驚きが多く、Astroのようなテックなものが目立ったり、WordPressに押されて一時は影が薄くなっていた国産CMS文化が、てがろぐによって、また存在感を取り戻しつつあるように見えたところは非常に興味深く感じた。

AstroはCMSではないものの、サイト構築手段として見た場合に、Koibumi Astro Blogという日本語由来の名前を持つテーマが結構使われているようで、これも面白いなと思った。ただし国産とまでは言い切れなさそうなので、Koibumiという名前の響きと、テーマそのもののデザインの両方が評価されて使われているのかもしれないと感じた。

WordPressが主流になる前はtDiaryやSerene Bach（旧Sb）、Blogn、BlognPlusといった国産CMSが結構流行っていた記憶があるので、こういう景色を見ていると、その当時を彷彿とさせるものがあった。というか、tDiaryもSerene Bachも開発が続いているし、Serene Bachについては見た感じかなりモダンな感じになっているようなので、過去形にしたのはちょっと失礼な物言いだった。

しかしまぁ、うちのような何をやっているのかちっともわからないところはなかったので、どこもテーマがちゃんとあって凄いなぁと思うのであった。多分このサイトにテーマが生まれることは一生ないだろうが、まぁそれはそれでいいと思っている。

このサイトにテーマがないことなんて24年前からずっとそうで、一時期は何かコンテンツを置こうとしたし、MMOをプレイしていた時はそれが中心だったが、もうプレイしてないし、核がないのでどうしようもない。

結局のところ私は、過去あの時どうしていたかを書き留めたり、便利なWebツールを作ったりして、それが偶然誰かの役に立てさえすればいいと思っているのだ。

何故なら私自身がネットで検索した時に出会った記事やツールに助けられたことが多くあり、どんな事であろうと誰かの役に立つかもしれないと思っているからだ。例えば地方の豆腐屋のパッケージ写真が置いてあるだけの記事でさえ、複数のサイトに別の時系列で存在していれば、その豆腐の原材料やパッケージのマイナーチェンジが読み解けたりする。そんな誰のためになるかも分からない、需要があるかどうかも謎なものを、私は公開しているのである。

勿論、公開していればネットがある限り記事を見れるため、出先で「その話なら過去にこういうのを書きました」とか紹介したり、或いは調べ物をするときに自分の経験をベースに調べたりできて便利なのもある。

つまるところ、私のサイトははなから他人に向けて発信していないということだ。それでも読んでくれている人がいるのは嬉しい。ただ嬉しさのためにやっている訳ではないので、今後も他人のための記事を書くつもりはないし、私は私による私のための私のサイト作りをこれからもしていくのだろう。

でもそれでいいのだ。何故ならここは私の個人サイトだからね。

この記事の話は仮運用環境の構築なので、本番向きではない。また必要であろうDBのセットアップは今回していない。

• Anubisとは？
• 今回構築した構成
• 確認環境
• 導入方法
  • 1. インストール
  • 2. Anubisの設定
  • 3. TLS終端となるnginxの設定
  • 4. virtual host側のnginxの設定
  • 5. Prometheus側の設定
• ハマったところ
  • Pukiwikiに対して流すとHTTP通信になり、nginx側のポート番号が露出した
  • Matomoでリファラが取れなくなった
• 撤去
• あとがき

Anubisとは？

端的に言うと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で実行している。

導入方法

1. インストール

1. GitHubのリリース一覧から最新のバイナリのURLを控える
   • 糞長いのでAMD64は項目を展開しないと出てこない
2. インストールする
   ```bash
   curl -OL https://github.com/TecharoHQ/anubis/releases/download/v1.25.0/anubis_1.25.0_amd64.deb
   sudo apt install ./anubis_1.25.0_amd64.deb
   ```

2. Anubisの設定

まずは/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

今回設定した項目について

3. TLS終端となるnginxの設定

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;
  }
}

4. virtual host側のnginxの設定

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/;
}

5. Prometheus側の設定

scrape_configs:に以下をぶら下げれば取れる。メトリクス名はanubis始まり。

  - job_name: 'anubis'
    static_configs:
      - targets: ['[::1]:9110']

ハマったところ

Pukiwikiに対して流すとHTTP通信になり、nginx側のポート番号が露出した

https://eco.lycolia.info/wikiにアクセスするとhttp://eco.lycolia.info:8081/wikiとなり、HTTP通信になったうえ、ポート番号が露出する問題が発生した。この問題はケツにスラッシュをつけてると起きなかった。

これはnginxに次の設定をしていたため、これを消すことで解消した。削除してもAnubisがいい感じに繋いでくれるようでhttps://eco.lycolia.info/wikiで問題なくアクセスできた。

location = /hoge {
  return 301 /hoge/;
}

Matomoでリファラが取れなくなった

取れないなぁ…と思ってググったら、GitHubにIssueが出ていたので取れないっぽい。

この時点で導入を断念した。

撤去

1. nginxの設定を戻す
2. Anubisを消す

   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
   

3. PrometheusからAnubisの設定を消して再起動
4. 各ドメインにアクセスできるか確認
5. おわり

あとがき

BOT弾きついでにAnubisの可愛い画面を出せるようにと導入を検討していたが、結果として断念した。Matomoでリファラが取れないのが深刻すぎたからだ。

リファラが取れるようになったら、また試すかもしれないし、試さないかもしれない。或いはそういう風に改造するか。でもこの手の奴はセキュリティリスクが高いので、あまり自分では触りたくない気持ちもある。

しかし個人サイトWebオンリー めぐる市の会期中にサーバーの上げ下げをしながらメンテを連発していたので、何ともアレである。まぁうちのサイトは管理人である私が好き放題やる実験場なので仕方がないね。