Lycolog

検索条件

日付で絞り込み 2019年(8) 2020年(6) 2021年(4) 2022年(10) 2023年(50) 2024年(79) 2025年(107) 2026年(76)

全340件 (3/68ページ) 一覧表示に切り替え記事本文を表示

2026/06/06(土)個人サイトWebオンリーめぐる市を見てきて

更新日：2026/06/10
投稿日：2026/06/06

ジャンル::インターネット

本日ピクリエ^[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ツールを作ったりして、それが偶然誰かの役に立てさえすればいいと思っているのだ。

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

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

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

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

オンライン同人イベントプラットフォーム ↩

コメント（0件）

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

投稿日：2026/06/06

ジャンル::自宅サーバージャンル::サイト運営

この記事の話は仮運用環境の構築なので、本番向きではない。また必要であろう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. インストール

GitHubのリリース一覧から最新のバイナリのURLを控える
- 糞長いのでAMD64は項目を展開しないと出てこない
インストールする
```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が出ていたので取れないっぽい。

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

撤去

nginxの設定を戻す

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

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

あとがき

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

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

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

コメント（0件）

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

更新日：2026/06/08
投稿日：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に以下のパーサーを追加した。(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

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

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

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

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

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

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

コメント（0件）

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

投稿日：2026/06/05

ソフトウェア::CMS::adiaryジャンル::自宅サーバーOS::Linux::Ubuntu

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

手順

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