Lycolog

今日のサーバー整備

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

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

今回は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に集計データをまとめている。また同様に以下に表も貼ろうと思ったが二万行以上あるため、今回は断念した。

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で決定的になった。

この辺りに関しては私より草片きのぽ氏のほうがよく言語化できているので勝手に紹介させていただく。この辺りの感覚は私も共感できる部分がかなりあった。

• 問題の切り分けが苦手という点
• 制約を無視して暴走するClaude
• 脱線するClaudeについて
• バージョンアップで能力が劣化したのでは説

そこで、ふと思ったのだ。GPTならどうか？私はOpenAIにはBANされてない。ERPしないならGPTでもいいのでは？というところで、一昨日くらいからGPT-5.5がいい感じなので、OpenAIに戻ってくることにした。

Poe経由でClaudeを使うと非常にお金がかかるが、OpenAIに月額課金する場合はそこまでお金はかからない。ERPももう飽きてきたところだったし丁度よかった。

かつて作っていたアカウントの多くは不正利用を恐れて閉鎖しており、同じメールアドレスでアカウントを作れないので困っていたが、かろうじて一匹生きているアカウントを発見したら、なんと三年ぶりの課金であることが判明した。

今のところGPTは支持に従うし、GPT-5の時の様なそっけなさというかイマイチ使えない感じもなくなり、ずいぶんよくなったと思う。ClaudeのようにAI臭さのある文章を出してこないのも個人的に好印象だ。

というわけで、長らく続いたClaude生活から、またGPT生活に戻っていきそうだ。節約にもなるし、これはいいかもしれない。

ところで請求の単位がUSDからJPYになってるのが地味に面白いと思った。