2026/06/06(土)Anubisを雑に設置したが、結果微妙だったので撤去した話

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

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で実行している。

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

導入方法

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

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

項目 役割
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に渡してくれるのだと思う

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

2026/06/05(金)先日の自宅サーバー移転に対し追加対応をした

昨日、さくらのレンタルサーバでホスティングしていたサイトの大部分を自宅サーバーに移行したが改善点が幾つか見えたので、その追加対応をしたログ。

adiaryをApacheからNginx * FastCGIへ移行

こちらについては構築記事をUbuntuのadiaryをlibfcgi-perlで動かす方法に、パフォーマンス計測記事をサイト環境を移転したのでadiaryのパフォーマンス計測をやってみたに書いている。

ECO-WikiをApacheからNginx * PHP-FPMへ移行

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

FluentBitにApacheのパーサーを追加

/etc/fluent-bit/parsers.confに以下のパーサーを追加した。

[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

FluentBitでApacheのログをとれるようにした

/etc/fluent-bit/fluent-bit.confに対し、以下のような設定を追加。

[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]

上記の設定にあるポート番号は他の記事と整合するように書いているつもりだが、ひょっとしたらずれているかもしれない。ちなみにうちのサーバーでは上記と別のポートを使っている。

Apacheのバーチャルホスト設定からログ設定を削除し、グローバル設定に集約

こうすることでログファイルを統一でき、管理が楽になる。

  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>
    
  2. /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になるように書き直した。

2026/06/05(金)Ubuntuのadiaryをlibfcgi-perlで動かす方法

サイト環境を移転したので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がインストール済

手順

  1. libfcgi-perlをインストールする
    sudo apt install libfcgi-perl
    
  2. /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
    
  3. サービスを有効化する
    sudo systemctl enable adiary.service
    sudo systemctl start adiary.service
    
  4. 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        /;
       }
    }
    
  5. nginxを再起動する
    sudo systemctl restart nginx
    

あとがき

adiary.httpd.plがオススメらしいのは見たが、HTTPサーバーは脆弱になりやすいことや、ログの使い勝手がどうなのか確認するのが面倒なこと、IPv6対応させるのが面倒だったことがあり採用しなかった。

2026/06/05(金)サイト環境を移転したのでadiaryのパフォーマンス計測をやってみた

CDNやキャッシュなどは挟まず直にCGIを実行した結果を書いている。

計測にはhttps://blog.lycolia.infoを利用している。今回の計測時はトップに画像多めの長大記事が多数ぶら下がっていたので計測の都合がよかった。

計測に使ったadiaryのバージョン

adiary Version 3.52dev / Extends Version 0.25.0

PageSpeed Insightsのスコア

まずは各環境ごとにPageSpeed Insightsで計測した。

携帯電話

環境 FCP LCP SpeedIndex パフォーマンス
さくらのレンタルサーバ 4.1 4.4 5.4 61.0
自鯖Apache CGI 11.0 11.5 11.0 30.0
自鯖nginx libfcgi-perl 3.9 4.2 5.1 64.0

デスクトップ

環境 FCP LCP SpeedIndex パフォーマンス
さくらのレンタルサーバ 0.6 2.8 1.3 54.0
自鯖Apache CGI 0.6 2.2 1.4 57.0
自鯖nginx libfcgi-perl 0.8 2.6 1.3 56.0

※ 自鯖Apache CGIは自宅サーバーのnginx→apache2環境のCGI実行、自鯖nginx libfcgi-perlは自宅サーバーのnginx→libfcgi-perlのFastCGI実行。

curlで10回叩いたスコア

curlを投げて出てきたtime_totalを書いている。

環境 10回合計 さくらのレンタルサーバとの差
さくらのレンタルサーバ 0.407181秒 0.000000秒
自鯖Apache CGI 0.403104秒 -0.004077秒
自鯖nginx libfcgi-perl 0.247276秒 -0.159905秒

あとがき

adiaryマニュアルにある通りlibfcgi-perlを使うと劇的に早くなることが分かった。

さくらのレンタルサーバではロードに一秒以上かかっていたこともあったため、それと比べるとかなり早くなるのではないだろうか?

関連記事

2026/06/04(木)さくらのレンタルサーバでホスティングしていたサイトの大部分を自宅サーバーに移行した

今日は遂に運営サイトの大半をさくらのレンタルサーバーから自宅サーバーへ移行することに成功した。

自宅サーバーでの個人サイト運営は中学時代からの夢だったので、悲願が叶ったようでちょっと嬉しい。

移行したサイトなど

次のサイトやサービスを移行した。

  • lycolia.info - lycolia.info
    • エントランスページ、LPみたいなもん
  • Lycolog - blog.lycolia.info
    • このブログ。このブログは2019年より前のログがないが、実はこのサイトは元からブログとして発祥している。当時はブログという概念はなく、日記サイトだった
  • Webツール置き場 - tool.lycolia.info
    • 適当に作った便利ツールを置いている
  • ECO-Wiki (lycolia) - eco.lycolia.info
    • 最近一言BBSへの書き込みがないのが気がかりなWiki。実はアクセスは落ちてない
  • アクセス解析 Matomo
  • TinyTinyRSS

やったこと

さくらのレンタルサーバから自宅サーバーへファイルを移設し、権限を設定

# サイト単位にtarballに固める
tar -cf hoge.tar hoge
# Windows上のRLoginを使って、NASとしてマウントしている自宅サーバーに転送
cp hoge.tar <ホスティングファイル置き場>
tar -xf hoge.tar hoge
# Apacheから見えるように
chown -R www-data:www-data <ホスティングファイル置き場>/hoge
# www-dataに属するユーザーがいじれるように
chmod -R g+rxw <ホスティングファイル置き場>/hoge

cgi-binフォルダを使っているスクリプトの対策

詳細はトラブルシューティングの該当項目参照

ヘッダーモジュールの有効化

使ってるやつがいたので有効化。

sudo a2enmod headers

さくらのレンタルサーバのMySQLからDBをダンプし、自宅サーバーのMariaDBに取り込み

sudo mysql -u <ユーザー名>
CREATE DATABASE <DB名>;
exit
# 照合順序をMariaDB方式に変換
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' ~/hoge.sql
sudo mysql <DB名> < ~/hoge.sql

nginxとApache2の設定を追加

nginx -> Apache2の構成にしているので、これの設定。基本的にレンサバでホスティングしていたものはApacheの上にのせておくと色々と楽だ。.htaccessは神だし、静的ファイルやCGIのホスティングをする場合、Apacheは取り回しがとても良い。

  1. /etc/nginx/conf.d/にサイトごとのリバプロの設定を置く。一例としてはこんな感じ

    server {
        listen 443 ssl;
        listen [::]:443 ssl;
        server_name  eco.lycolia.info;
    
        client_max_body_size 100M;
    
        ssl_certificate     /etc/letsencrypt/live/lycolia.info/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/lycolia.info/privkey.pem;
    
        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;
        }
    }
    
  2. /etc/apache2/sites-enabled/にもサイトごとの設定を書く。一例としてはこんな感じ

    <VirtualHost *:8080>
            ServerName eco.lycolia.info
    
            ServerAdmin webmaster@localhost
            DocumentRoot /var/www/path/to
    
            # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
            # error, crit, alert, emerg.
            # It is also possible to configure the loglevel for particular
            # modules, e.g.
            #LogLevel info ssl:warn
    
            ErrorLog ${APACHE_LOG_DIR}/eco-error.log
            CustomLog ${APACHE_LOG_DIR}/eco-access.log combined
    </VirtualHost>
    

このリバプロの設定の意味合いについては過去に書いたnginxからApache2のバーチャルホストにいい感じにリバプロする方法nginxからApache2へセキュアにリバプロしたときに真のクライアントIPを取得できるようにするを参照。

perlとphpのパスにエイリアスを作る

これをしてないと実行時エラーになる。

sudo ln -s /usr/bin/perl /usr/local/bin/perl
sudo ln -s /usr/bin/php /usr/local/bin/php

SSIの有効化

今時SSIを使ってる人なんてまずいないと思うが、令和最新版ということで…。

やり方

  1. SSIモジュールを有効化する
    sudo a2enmod include
    
  2. /etc/apache2/apache2.confを開き、全域でSSIを有効化。ついでにDirectoryIndexにも入れとく。SSIの設定はDirectoryディレクティブの中でないと効かない
    <Directory /var/www/>
            AllowOverride All
            DirectoryIndex index.php index.cgi index.shtml index.html index.txt
            # Optionsに+Includesの部分を追加する
            Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch +Includes
            AddHandler cgi-script .cgi
            Require all granted
    </Directory>
    

.shtmlの場合にSSIを許可するように管理しているのは恐らく/etc/apache2/mods-enabled/mime.confだと思われる。ここでMIME-TYPEも付与していると思われる。

バーチャルホストやんいやパス単位にしたい場合は適当なDirectoryディレクティブにOptions +Includesを書けば機能する。

余談だがSSIはエントランスページの更新日時を出すのに使っていて、過去に記事のネタにしたこともある。

アプリケーションのDBの向き先を変更

移設したMatomoとTTRSSは共にMySQLを使っていたためMySQLの接続情報を書き換えた。

DBの接続先はlocalhostでなく、127.0.0.1でないと上手くいかなかった。::1も通らなかったため、恐らくIPv6でListenしていないのだと思う。

Matomoの設定

  1. 無限リダイレクト抑制のためconfig/config.ini.phpのeneralセクションにassume_secure_protocol = 1を追加する。詳細はトラブルシューティングの該当項目参照
  2. gd2以上を入れろと言われるので使っているPHPのバージョンにあったものを入れる
    sudo apt install php8.3-gd
    
  3. MySQLのmax_allowed_packetが少なすぎると言われるので/etc/mysql/my.cnfを開きmysqldセクションに設定を足す
    [mysqld]
    + max_allowed_packet=64MB
    

CRONの移行

ttrssとmatomoのCRONを移行。

0 * * * * /usr/local/bin/php /path/to/ttrss/update.php --feeds --quiet 1> /dev/null
0 * * * * /usr/local/bin/php /path/to/analytics/console core:archive --url=https://analytics.lycolia.info/ 1> /dev/null

ドメインの切り替え

  1. Value-DomainのDNS管理画面を開き、移設したドメインを全て自宅サーバーに向けた
  2. 移設前はAレコードとMXレコードのIPが同一だが、今回からAレコードとMXレコードのIPが変わるので分離した。これで合っているのか怪しいが一応メールが届くことは確認している
    +mx mx.lycolia.info. 10
    +a mx 133.167.8.98
    +aaaa mx 2403:3a00:101:13:133:167:8:98
     mx lycolia.info. 10
    -a 133.167.8.98
    -aaaa 2403:3a00:101:13:133:167:8:98
    +aaaa @ 2400:4153:8f01:c800:c14b:3f7a:2b54:353a
    +a @ 133.167.8.98
    
  3. 今回移設したドメインを対象にvalue-domain-dns-utilvd-ddns-v4.plでDDNSを行う設定を追加

トラブルシューティング

cgi-binを含むパスが/usr/lib/にマップされた

例えば/var/www/html/hoge/cgi-bin/mgcount/mgcount.cgiを実行すると/usr/lib/cgi-bin/mgcountを叩こうとしてコケる問題と出会った。

実際に出たログの一例としては以下のような状態だった(IPはマスクしているが他はそのまま)

[Wed Jun 03 21:02:12.751027 2026] [cgid:error] [pid 865047] [client xxxx:xxxx:xxxx:xxxx:xx:xxxx:x:x:x] AH01264: script not found or unable to stat: /usr/lib/cgi-bin/mgcount, referer: https://lycolia.info/index.shtml

これはどうも規定ではcgi-binが入ったパスを/usr/lib/cgi-bin/にバインドする振る舞いがあるらしく、sites-enabled/の設定に次の記述をすることで正しいパスを呼び出すことができるようになった。

<VirtualHost *:8080>
        ServerName hoge.lycolia.info

        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html/hoge

        # Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
        # error, crit, alert, emerg.
        # It is also possible to configure the loglevel for particular
        # modules, e.g.
        #LogLevel info ssl:warn

        ErrorLog ${APACHE_LOG_DIR}/hoge-error.log
        CustomLog ${APACHE_LOG_DIR}/hoge-access.log combined

        # ScriptAliasで既存のバインドを上書きする
        ScriptAlias /cgi-bin/ /var/www/html/hoge/cgi-bin/
</VirtualHost>

ダンプ取り込み時にERROR 1273 (HY000) at line 30: Unknown collation: 'utf8mb4_0900_ai_ciが出る

MySQLとMariaDBで照合順序の名前が違うらしいのでダンプファイルをMariaDB流で置換する。

sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_general_ci/g' ~/hoge.sql

MySQLを叩くCGI実行時にException while creating PDO object:SQLSTATE[HY000] [2002] Connection refusedが出る

DBに繋がっていないのが原因。ポート番号やIDPWなどに間違いがなく、ローカルDBに繋ぐ場合、DBの接続先をlocalhostでなく、127.0.0.1にすれば直る。

CGI実行時にEnd of script output before headers: hoge.cgi,が出る

これはHeaderを吐く前にエラーが標準出力されているので出るエラーと思われる。昔PHPやってた人にはお馴染みのやつ。

Shebangに書かれているパスにPerlがないのが原因なのでShebangのパスを見てそこにシンボリックリンクを張っておく。

sudo ln -s /usr/bin/perl /usr/local/bin/perl

.htaccess: Invalid command 'Header', perhaps misspelled or defined by a module not included in the server configuration

ヘッダーモジュールを有効化する。

sudo a2enmod headers

nginx -> Apache2のリバプロ環境でMatomoが無限リダイレクトしたり、エラーログを吐きまくる

一般的に内部リバプロはhttpで送るが、これが原因。

Matomoはhttpリクエストをhttpsにリダイレクトするが、リバプロがhttpでリクエストしてくるため無限ループになって発生する。MatomoのGitHubリポジトリのIssueに山ほどある問題

解消法としては以下の様にconfig/config.ini.phpGeneralセクションでassume_secure_protocol = 1を設定すればよい。

 [General]
+assume_secure_protocol = 1

504エラーが出たり、やたらめったら凄く重い

アクセスが集中してるときにMatomoがDBエラーを吐いてるとAMD Ryzen 5 8500Gでメモリ32GBのNVMe SSDを積んだマシンですら504が出る程度には重かった。

エラーを潰したら平和になった。

ビジットの外観のミニグラフが出ない

GD2以降が必要なのでPHPのバージョンにあったものを入れる。

sudo apt install php8.3-gd

あとがき

2017年から自宅サーバーをマイペースに運用しており、初期はSSHDを立てただけの簡易NASやシンクラ環境として使っていたが、去年からMastodonの運用をはじめ、中学のころの夢だった鯖缶になることができた。そして更に今回、死活監視用に確保しているサイト(未構築)を除き、全てのサイトを自鯖に移行できたので、まさに中学生のころに夢見た、Webサイトを運用する鯖缶になることができ、感激もひとしおだ。

移設作業中は通信トラフィックやディスクI/Oが一気に跳ね上がったりだとか、CPUやメモリも結構頑張っていて、運用しているMastodonがやたら重くなったのが印象的だった。

何せこのブログだけでファイル数15,197の容量13GBもあるのだから無理もない。

あと移設作業中にadiaryのOGPが出なくてなんでだ?と思ったら、HTTPSの判定処理に漏れがあり、HTTPでURLが出ていたので、リバプロのヘッダもみるように改修した。実装上、リバプロしていない場合に子のヘッダが送られてきてもHTTPSになってしまうが、困るのはそんな不正な要求を送った本人なので、特に問題ないだろう。

さて、ここまで来たら次は以前も話に出した、Anubisを導入してWAFを掛けたり、現在日々増強中の監視体制の強化を続けていくなどして、自作サーバーライフを楽しんでいきたいところだ。

振り返ってみたら2025/08/21から今日までの間になんと三回も言及しており、これで四回目らしい。草。

特に意味はないが、過去にあったAnubisへの言及を以下にまとめてみた。

なんと言うか一年くらい塩漬けにしていたプロジェクトが最近はじわじわ進んでいる気がしていて、非常に清々しい。

そういえばadiaryをサーバーモードで動かすと早いという話があるので、そっちも試してみたいところだ。これは最近記事の増加に伴い中々重くなってきているのを感じているからだ。

やりたい事がたくさん湧いてくるのは充実していてとても良い。