ここしばらくGitHubに思うところがありすぎて、GitHubを使い続けることに悩ましさを感じていたが、折角自宅サーバーの運用が軌道に乗ってきたのだし、それならGitHubもセルフホストしちゃおう！というのでやってみたログ。
あとがきに熱が入りすぎて異様な長さになってしまったので、この記事はあとがきが本体な可能性がある。
| Env | Ver |
|---|---|
| Forgejo | 11.0.15+gitea-1.22.0 |
基本は公式のインストールガイドの通り。
バイナリの配置～デーモンの配置を行う
# Forgejoバイナリの入手
wget https://codeberg.org/forgejo/forgejo/releases/download/v11.0.15/forgejo-11.0.15-linux-amd64
# Forgejoバイナリの配置
sudo cp forgejo-11.0.15-linux-amd64 /usr/local/bin/forgejo
sudo chmod 755 /usr/local/bin/forgejo
rm forgejo-11.0.15-linux-amd64
# gitとgit-lfsのインストール（gitは既に普通あると思うが）
sudo apt update
sudo apt install git git-lfs
# Git操作用ユーザーの追加
sudo adduser --system --shell /bin/bash --gecos 'Git Version Control' \
--group --disabled-password --home /home/git git
# Forgejoディレクトリの作成
sudo mkdir /var/lib/forgejo
sudo chown git:git /var/lib/forgejo && sudo chmod 750 /var/lib/forgejo
sudo mkdir /etc/forgejo
sudo chown root:git /etc/forgejo && sudo chmod 750 /etc/forgejo
# Systemdの入手と配置
sudo wget -O /etc/systemd/system/forgejo.service https://codeberg.org/forgejo/forgejo/raw/branch/forgejo/contrib/systemd/forgejo.service
# デーモンの開始（設定ファイルとかを作らせるためにしている）
sudo systemctl daemon-reload
sudo systemctl enable forgejo.service
sudo systemctl start forgejo.service
# 設定ファイルのパーミッションを変える
sudo chmod 640 /etc/forgejo/app.ini
/etc/systemd/system/forgejo.serviceを開き[service]セクションに以下を追記する
RuntimeDirectory=forgejo
RuntimeDirectoryMode=0755
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
nginxからリバプロする
server {
listen [::]:443 ssl;
server_name git.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://unix:/run/forgejo/forgejo.sock;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
/etc/forgejo/app.iniを開き、適当に設定を書く。設定系はConfiguration Cheat Sheetに全部書いてある。
# Webページのタイトルの一部が変わる
APP_NAME = Forgejo
# Webページのタイトルの一部が変わる
APP_SLOGAN = Beyond coding. We Forge.
# 実行ユーザー
RUN_USER = git
# 本番
RUN_MODE = prod
# 実行パス
WORK_PATH = /var/lib/forgejo
[server]
# unixsocketを使う
PROTOCOL = http+unix
# Forgejoを置いているドメイン
DOMAIN = git.example.com
# unixsocketのパス
HTTP_ADDR = /run/forgejo/forgejo.sock
# unixsocketのパーミッション
# www-dataがアクセスできるように666にしているがwww-dataをgitグループに入れてもいいかも？
UNIX_SOCKET_PERMISSION = 666
# 組み込みSSHを起動する
START_SSH_SERVER = true
# IPv6でListenさせる
SSH_LISTEN_HOST = ::
[repository]
# リポジトリを格納するルートパス
ROOT = /var/lib/forgejo/data/forgejo-repositories
# アップロード制限、とりあえず公式のコピペ
[repository.upload]
; ; max size for files to the repo via web interface, in MB,
; ; defaults to 3 (this sets a limit of about 4GB)
FILE_MAX_SIZE = 4095
; ; by default 5 files can be uploaded at once, increase to 20
MAX_FILES = 20
# Gitのタイムアウト制限、とりあえず公式のコピペ
[git.timeout]
; Git operations default timeout seconds
DEFAULT = 3600
; Migrate external repositories timeout seconds
MIGRATE = 6000
; Mirror external repositories timeout seconds
MIRROR = 3000
; Git clone from internal repositories timeout seconds
CLONE = 3000
; Git pull from internal repositories timeout seconds
PULL = 3000
; Git repository GC timeout seconds
GC = 600
sudo systemctl restart forgejo.service
https://git.example.comにアクセスし適当に設定する
基本的に初期設定そのままで大きな問題がないものばかりだった気がする
SSH鍵を作成し、Forgejoで自分のアカウント設定ページを開き、公開鍵を登録する
クライアントになる環境にSSHに繋ぐための設定(~/.ssh/config)を書く
Host git.example.com
HostName git.example.com
IdentityFile /path/to/forgejo.sec
ssh -T git@git.example.com
GITHUB2FORGEJOを使うとできる。
以下は移行のコマンド例。マニュアルが親切なのでマニュアルを読めばわかる。
一個でも外すとこのオプションどうする？と聞かれるが、何も指定しなければウィザードを流してくれるので、環境変数を指定せずに叩いても動く。
以下のコマンドではGitHubと決別し、完全にForgejoに移行する前提の設定としている。
wget https://github.com/PatNei/GITHUB2FORGEJO/archive/refs/heads/main.zip
unzip main.zip
rm main.zip
cd GITHUB2FORGEJO-main
GITHUB_USER=YourGitHubUserName \
GITHUB_TOKEN=ghp_XXXXXXXXXXXXX \
FORGEJO_URL=https://git.example.com/ \
FORGEJO_USER=YourForgejoUserName \
FORGEJO_TOKEN=XXXXXXXXXXXXXXXXX \
STRATEGY=clone \
MIRROR_DIRECTION=pull \
PUSH_MIRROR_INTERVAL=8h \
PUSH_MIRROR_SYNC_ON_COMMIT=no \
MIGRATE_ARCHIVE_STATUS=yes \
MIGRATE_FORKS=no \
VISIBILITY=both \
SORT=pushed \
SORT_DIRECTION=desc \
FORCE_SYNC=no \
DRY_RUN=no \
./github-forgejo-migrate.sh
どうやらリポジトリ本体は持ってこれるもののIssueやWikiは持ってこれないようだ。
forgejo dump-repoというGitHub系サービスの中身をダンプするコマンドがあったので試してみたが、こちらは引っ張ってはこれるっぽいもののForgejoのDBやディレクトリ構造と合わないようで、移行用途では使えなかった。
gh repo list Lycolia --limit 1000 --json name --jq '.[].name' \
| while read url; do
echo sudo -u git forgejo dump-repo --git_service github --auth_token XXXXXXXXXXXXXXXXXX--clone_addr https://github.com/Lycolia/$url --config /etc/forgejo/app.ini --repo_dir /var/lib/forgejo/data/forgejo-repositories/lycolia/$url
done
GitHubのアカウントエクスポートも試してみたが、中身が省略されているように見える.gitディレクトリの山がパッケージされており、ググった感じGitHub間のアカウント移行に使う物らしかったので、諦めた。
../ssh/ssh_graceful.go:25:listen() [F] Failed to start SSH server: listen tcp 0.0.0.0:22: bind: permission deniedというエラーが出る/etc/systemd/system/forgejo.serviceを開き[service]セクションに以下を追記して再起動すれば治る。
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
動作確認時にデーモンの上げ下げしてジャーナル見るのが面倒なので、パッとやりたいときに便利なコマンド
sudo -u git /usr/local/bin/forgejo web --config /etc/forgejo/app.ini
あとがきが長すぎて、実はこっちが記事の本体という可能性が…ｗ
SSHの穴をあけるのは危険か？と思ったが組み込みのSSHであればgitユーザーが出来ること以外できないだろうし、任意のコマンドが実行されたところで、精々リポジトリの全消し以上のリスクはなさそうなので開けることにした。理由としてはHTTPはパフォーマンスが悪いらしいからだ。
構築していて思ったがForgejoのマニュアルは親切で比較的解り易く、構築が楽だったのが良かった。
積極的に使い始めたのはUbuntuのadiaryをlibfcgi-perlで動かす方法が初めてだが、unixsocketはTCP通信をしないのでポート管理が不要になるのが利点なのと、TCPのオーバーヘッドがない分処理が速いというのをどっかで見たので、使うことにした。
内部通信のポートが被らないように管理するのは地味に大変なのでアプリケーション間の通信は極力unixsocketに倒したいなと思った。
最大の理由は、ここ数年でGitHubやnpm周辺のサプライチェーンリスクを強く意識せざるを得なくなったからだ。
例えばSecrets漏れなどの事故はここ数年で非常に聞くようになったし、npmjsからGitHubのToken奪取などの問題もあったと思う。
そしてその関係でセキュリティが面倒なことになり、GitHub Actionsからnpm publish出来なくなってたのを対応したみたいなことをする羽目になったこともあり、非常に煩わしさを感じていた。
Value-DomainでcertbotのDNS Challengeをやるスクリプトを書き直した理由の一つも、npmjsから手を引きたい思いが実はあり、そもそも別にリポジトリから拾えばいいじゃんと思い、パッケージ化しなかったというのもある。だって別にPerlでもnpmレジストリに入れることはできるからね。
そして昨日npmjsのアカウントを消そうと思い立ちログインしようとしたらロックアウトされてしまった。私はホビープログラマとしてやっているだけなので、こういった変化についていくのに疲れてしまった。
例えば最近GitHub離れが進んでいることも理由の一つだ。
理由にはいろいろあると思う、例えばここ最近GitHubは不安定で、GitHub Actionsが失敗する、Webページが開けない、APIがダウンしているのは最早日常といってもいいだろう。少なくとも私はそう思っている。
他にもCopilotなどのAI化の推進や、UXの悪いPR、行儀の悪いソフトウェアの排除もある。
CopilotなどのAI化の推進についてはGitHubのWebページ上でコミットを打つと解るのだが、LLMによって勝手にコミットメッセージが補完される。あのメッセージに意図などなく、変更内容を文字列にしただけだ。これを避けるためにはAIが書き切るより早く書き起こしてコミットするか、或いは書き終わるのを待って上書きするか、何も考えず即座にコミットボタンを押しUpdate hoge.mdのようなメッセージにするかしかない。個人的にはこれが非常に煩わしく、避けたいと思っている。
そして、もしこれを回避する設定があるとしてもGitHubの設定は既に増えすぎており、もう探す気も起きない。
UXの悪いPRについては、PRを作ったときにベースリポジトリに更新が走ると更新するボタンが出てくるが、これを押すと中身のない空のマージコミットが作られることや、GitHubのバグとしか思えないよく解らない差分が出ることがあるのも挙げられる。こうやってやらなくていいことを増やすだけのシステムはUXが悪いと思う。
そして行儀の悪いソフトウェアの排除だ。行儀の悪いソフトウェアとは何かというと、もっぱら権利侵害を目的に利用されているのではないかと疑われているようなものである。
かつてGitHubでホスティングされていたyoutube-dlというソフトウェアがDMCA侵害でGitHubから消されることがあり、当時は結構騒がれた話だったと思う。その後、紆余曲折ありyoutube-dlは現在は再公開されているが、最近はほとんど更新されていない。恐らくフォークであるyt-dlpに開発が移ったと思われる。
そして今年に入ってからFAKKU, LLCが大規模なDMCAを通告した。これによりGitHubから多くのダウンローダー系ツールが削除されて祭りとなった。
この対応を受け、gallery-dlはCodebergへの移行を決めた。
個人的にはTwitterの画像を落とすのにHitomi-Downloaderをよく使っていたのだが、これもDMCAに含まれており削除の憂い目にあった。Hitomi-DownloaderはTwitterがXになり、APIが有料化してからもTwitterのメディアをバルクで落とせるので重宝していた人が多くいたと思う。なおHitomi-Downloaderについては移転したとかはなく、単に消えてそうだ。バイナリはググれば出てくるが、APIが変わってるので、もう動かないと思う。余談だが、現在Twitterの画像をバルクで落とせる無料のソフトウェアはgallery-dlくらいだと思う。
また前述したGitHubの不安定さや、AIの存在を理由にGitHubを離れたものとしてプログラミング言語のZigがある。ZigはGitHubの現状に失望し、痛手を負ってでもCodebergに移行した。現在のGitHubは更新されておらず、移行のメッセージが残されている。
また玄人向けのLinuxディストリとして知られるGentoo LinuxもGitHubのLLM方針に反発し、Codebergへの移行を発表している。
Gentooの2025年振り返りでは、「Goodbye Github, welcome Codeberg」という言葉も見られ、Planet Gentooでは開発者からLLMに対する鬱憤ともいえる批判が多く寄せられている。
個人的に強く共感したものには次のものがある。
They start using LLMs because they don’t want to maintain their code anymore. Software turns into slop, which burns out even more people.
(ja: 彼らは、もうコードのメンテナンスをしたくないという理由で、LLMを使い始める。その結果、ソフトウェアはずさんなものとなり、さらに多くの人々が燃え尽きてしまう。)
LLMを使う理由はコードを書きたくないから、メンテしたくないから、動いている風に見えればよいからだというのは私も思う。バイブコーディングで出てきたものがまともに動く保証はない。
公私ともにLLMを使ってコーディングしているが、本当にそう思うし、仕事ではLLMに毒されすぎたのか判断能力を失ってしまった人も見かける。
Gentoo aims to be made by humans
We banned LLM contributions two years ago, and never regretted it. We didn’t “wait and see”, we took decisive action, and if we got left behind, it’s only for the better. I can’t give you a 100% guarantee that no tainted code slipped through, but we’re doing our best to stay vigilant. In the end, it’s all about trust, and trusting one another is what builds our community.
(ja: 私たちは2年前にLLMによる投稿を禁止しましたが、その決断を後悔したことは一度もありません。「様子を見る」のではなく、断固たる措置を講じました。もし他者に遅れをとったとしても、それはむしろ良いことなのです。不適切なコードが混入していないことを100％保証することはできませんが、私たちは警戒を怠らないよう最善を尽くしています。結局のところ、すべては信頼にかかっており、互いを信頼し合うことこそが、私たちのコミュニティを築き上げるのです。)
この人間らしさには非常に共感した。特に「もし他者に遅れをとったとしても、それはむしろ良いことなのです。」の部分だ。誰かより早くある必要はない、誰かと比べて遅れていても問題ではない。何故なら競技ではないし、そもそもベクトルが違うと私は思う。
他にもAutodesk Fusion 360 for Linuxも同様の理由でCodebergへの移行を行い、GitHubは既にアーカイブされている。
lycolia.info、つまりサイトトップを触っていて思ったのだが、自分が作ったソフトウェアを見てもらうのに外部サイトにアクセスしないといけないというのが癪だと思った。
ソフトウェアの配布なら最悪自分のサイト上でzip配布でもすりゃあいいじゃんという話だ。
ただまぁ事はそう単純でもなく、リポジトリをWebサイトに置いておくと、出先からスマホでちょろっといじりたいとか、テキストとして転がして置き、一々ダウンロードせずコピペしたいみたいな絶妙な需要を満たせるので、セルフホストでかつ、GitHubの様な機能を満たせるものというところでForgejoを採用したのである。
勿論、先述したようなGitHubへの信頼性問題もあるが、私がDMCAでどうにかなる可能性は今のところないので、まぁ宗教みたいな話ではある。
そういえば以前WSL2のUbuntu 20.04にGiteaを生やすという記事を書いたし、Giteaにはコントリビュートしたこともあるが、GiteaのフォークであるForgejoでこんなことを始めるとは夢にも思わなかったので、めぐりあわせだなぁと思うのであった。
業務用と個人用でGitHubの無料アカウントを分けるは、このブログで二番目にアクセスの多い記事だが、Forgejoに完全に移行すれば、こういったことも解消できる。
なお現状ではGitHubのアカウントそのものはOSSのコントリに使うことが稀にあるため保持しておくつもりだが、いつ消し去っても良いくらいの温度感では持っておきたい所存である。
Forgejoは、その構造上、各ホスト上でアカウントを作らないとコントリビューションができないと思うので、特定のプラットフォームからの支配や思想を回避できるのが利点だが、同時に欠点だとも感じている。
端的に言うとそれぞれのForgejoサーバーには何ら繋がりがない。あるForgejoサーバーでアカウントを作ったとしても、別のForgejoサーバーでは使えない。これはForgejoサーバーが増えれば増えるほど難しくなっていく問題かもしれない。私の様なサーバーでは問題にならないので別にいいが…。
但しFediverseにあるActivityPubのようにオープンプロトコルを作り連合を作る計画はあるようで、将来的には各ホスト同士での疎通が実現するかもしれない。
とはいえ、連合は連合で問題である。Fediverseも連合制をとっていて様々なサーバーが連合しているがMastodonとMisskeyには互換性の問題があるし、連合は数が増えれば増えるほど負荷が大きくなる問題もある。例えばA Forgejoサーバーの変更が10の連合先に伝播し、そこから更に各サーバーの先にある10に連合…となれば伝播する時間もリソースも無駄になってくる。
設計次第ではあるものの相互に繋がった数千のサーバーがやり取りを始めたらDoS攻撃に匹敵する負荷が発生するかもしれないし、様々な分散サーバーに同一の情報が保存されるのはストレージの無駄である。
この辺りはMisskeyの開発者であるsyuiloさんや、.ioの運営者である村上さんも話しているし、連合のコストについてはfedibird管理人ののえるさんも話している。
分散型はプラットフォーマの支配を受けず、独自性を出しやすい代償に、スケールしづらいのだ。ただ、DMCAの通報がされるようなソフトウェアにとってはそっちの方が都合がいいかもしれない。とはいえ、GitHubにBANされなくとも、次はAWSやVPSからBANされたり、ドメインが差し押さえられたり、自宅サーバーであってもISPから契約解除されるなどのリスクはあるので、程度問題ではある。
そういえば、この手の話をまさにしているスレッドがRedditにあったので、記録に残しておく。
エクスプローラー - LycoGit: Lycolia's Git Hostingで公開リポジトリの一覧が見れる。
ドメイン直下にアクセスすると「自分で立てる、超簡単 Git サービス」という強めのおもしろアピールが出てくる。
今のところはGitHubのリポジトリを丸ごと移しただけなので、中身的には同じものである。
PowerShellはWSL2の中から叩けるため、WSL2の中から通知を出したいときに使える。
PowerShellなのでホスト側のWindowsからも使える。
PowerShell 7では動かないので注意。
| Env | Ver |
|---|---|
| OS | Windows 11 Pro 25H2 (OSビルド 26200.8655) |
| PowerShell | 5.1.26100.8655 |
この内容をtoast.ps1など適当な名前で保存する。文字コードはUTF-8 BOM, 改行コードはLFにしておく
param (
[String]$subject = "WSL Notice",
[String]$title = "たいとるですー",
[String]$message = "お知らせでーす",
[String]$icon = "C:/env/1e1b9fdf82a6a544.png",
[switch]$keep
)
[Windows.UI.Notifications.ToastNotificationManager, Windows.UI.Notifications, ContentType = WindowsRuntime] > $null
$template = [Windows.UI.Notifications.ToastNotificationManager]::GetTemplateContent([Windows.UI.Notifications.ToastTemplateType]::ToastImageAndText04)
$xml = New-Object Windows.Data.Xml.Dom.XmlDocument
$xml.LoadXml($template.GetXml())
$toastTextElements = $xml.GetElementsByTagName("text")
$toastTextElements.Item(0).AppendChild($xml.CreateTextNode($title)) > $null
$toastTextElements.Item(1).AppendChild($xml.CreateTextNode($message)) > $null
$toastImageElements = $xml.GetElementsByTagName("image")
$toastImageElements.Item(0).SetAttribute("src", $icon) > $null
if ($keep) {
$xml.DocumentElement.SetAttribute("scenario", "reminder") > $null
$actions = $xml.CreateElement("actions")
$action = $xml.CreateElement("action")
$action.SetAttribute("content", "閉じる") > $null
$action.SetAttribute("arguments", "dismiss") > $null
$action.SetAttribute("activationType", "background") > $null
$actions.AppendChild($action) > $null
$xml.DocumentElement.AppendChild($actions) > $null
}
$toast = [Windows.UI.Notifications.ToastNotification]::new($xml)
$appId = $subject
$notifier = [Windows.UI.Notifications.ToastNotificationManager]::CreateToastNotifier($appId)
$notifier.Show($toast)
powershell.exe -File 'C:/path/to/toast.ps1' -subject hoge -title fuga -message piyo -icon C:/path/to/icon.png -keep
| オプション | 役割 |
|---|---|
-subject |
通知の表題。ここを変えると別の通知として扱われる |
-title |
通知のタイトル |
-message |
メッセージ本文。一行のみ |
-icon |
アイコン。Windowsホストの絶対パスで指定 |
-keep |
このフラグを立てると通知が消えなくなる |
-subjectを変えると別の通知扱いになるため、通知を別々に貯めることができるようになる。
powershell 'C:/path/to/toast.ps1' -subject hoge -title fuga -message piyo -icon C:/path/to/icon.png -keep
Windows側から叩く場合、-Fileは省略できる。
Claude Codeの確認と終了のイベントで通知が出ると便利かなと思って作ってみたが、まだ試せていない。
取りあえずWSL2の中と、Windowsホスト側から叩いたときに通知が出ることは確認している。
PowerShell 7で動かそうと思ったらエラーまみれで動かず、PowerShell 7の場合、NuGetパッケージを取得するか、DLLのパスを直に指定するか、サードパーティの通知ライブラリを使うかということで、諦めた。
前回の対処ではMicrosoft Edge rounded cornersを設定して回避していたが、これが潰されたので回避方法を残す。
--enable-features=msForceNoRoundedCornerAndMarginを付け足す
端的に言うとこのコマンドで起動すれば消える。
"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --enable-features=msForceNoRoundedCornerAndMargin
レスポンシブシミュレーションの画面でも角丸が出るためWeb開発にも支障が出ると思うが、マイクロソフトはなぜこんな変更をしたのだろうか…。
余談だが、Bring back the "Microsoft Edge rounded corners" optionにフィードバックを送ると改善する可能性があるので直してほしい人は送るといいかも？私は送った。
現時点で625の投票と205個のフィードバックがついている。6月8日に見たときは391票と130コメントだったので、だいぶ増えている。
昨日時点だと縦軸にがたつきが出ているが、これを修正した。深いことを考えずやっているので表示が崩れるパターンもありそうだが、気にしないでおく。
| 昨日時点 | 本日の修正後 |
|---|---|
 |
 |
地味だがこっちのがUXはよい。
他にも地味だが、外枠が黒なのは強調が強すぎると思ったので、ついでに枠の色を薄くしたほか、枠と中身のpaddingに当たり判定がなかったので、全体に当たり判定が出るように埋めた。
画像バナーだとこんな感じ。
テキストバナーだとこんな感じ。
lycolia.info配下はすべてPerl CGIで実装しているが、ヒアドキュメントにシンタックスハイライトが効かずtypoに気づきづらい問題があった。
しかしヒアドキュメントの文字をHTMLにするとハイライトが効くことに気づいたので直した。
HTMLでも'HTML'でもどちらでも効くのがありがたい。しかし'HTML1'とかにするとダメになるのがイマイチだ。HTML1はいけるのに…。
試してみたところ、このテクニックはPHPでも有効だった。
どうでもいいが、この画像の実装はPerl CGIにする前のものなので今は使っていない。
前々からadiaryに情報バナーがないのが不満だったので、これを実装することにした。
切っ掛けとしてはLatitude 7350のCPUクーラーマウンタ用のネジ穴とラズパイクーラーのネジ穴メモの記事を書くときに使いたかったのがある。
実はこの手の表示自体は過去記事にも存在するのだが、記事ごとにHTMLを手書きしていてよくなかった。手書きだと毎回スタイルが変わってしまうし、一元的な変更もできないからだ。
adiaryには記法タグという、記法を拡張できる機能があるのを知っていたため、これを使うことにした。
そこでまずadiary本家の記法タグを定義するを真面目に読むことにした。実はこのページは過去に何度か読んでいるのだが、意味が理解できていなかった。
まず記法タグの定義の基本はこれだが、これは忘れていい。
google = Google検索, UTF-8, http://www.google.co.jp/search?lr=lang_ja&ie=utf-8&oe=utf-8&q=
keyword = はてなキーワード, EUC-JP, http://d.hatena.ne.jp/keyword/
意味的にはこんな感じである。
TAG = 説明文, 文字コード, URL
今回使うのはこっちだ。
mtex = mimeTeX, ASCII, 1, <img src="$0mimetex/mimetex.cgi?$1" alt="$1" class="tex">
test = block-tag-sample, ASCII, 2, block:
<table>
<tr><th>#1</th><td>#2</td></tr>
</table>
こちらの意味はこんな感じである。
TAG = 説明文, 文字コード, 引数の数, URL | HTML | block:
TAGは記法に使うタグの名前だ。例えばhogeとした場合、[hoge:]となる[hoge:aaa]なら1、[hoge:aaa:bbb]なら2になるURL | HTML | block:は置換に使う文字列なのだが、<で始まればHTML置換として、そうでなければURL置換としてアンカータグを出力するっぽい？
block:を指定した場合は複数行書くことができる。但しこれは可読性のためであって、実際のHTML出力は一行になるようだというので、以下の記法を定義してバナーを出せるようにした。
info = 情報バナー, UTF-8, 1, block:
<div class="notice_banner info">
<div><svg width="25" viewBox="0 0 24 24" aria-label="fontSize small"><path d="M11 7h2v2h-2zm0 4h2v6h-2zm1-9C6.48 2 2 6.48 2 12s4.48 10 10 10 10-4.48 10-10S17.52 2 12 2m0 18c-4.41 0-8-3.59-8-8s3.59-8 8-8 8 3.59 8 8-3.59 8-8 8"></path></svg></div>
<div class="message">#1</div>
</div>
warn = 警告バナー, UTF-8, 1, block:
<div class="notice_banner warn">
<div><svg width="25" viewBox="0 0 24 24" aria-label="fontSize small"><path d="M12 5.99 19.53 19H4.47zM12 2 1 21h22zm1 14h-2v2h2zm0-6h-2v4h2z"></path></svg></div>
<div class="message">#1</div>
</div>
error = エラーバナー, UTF-8, 1, block:
<div class="notice_banner error">
<div><svg width="25" viewBox="0 0 24 24"><path d="M12 2C6.47 2 2 6.47 2 12s4.47 10 10 10 10-4.47 10-10S17.53 2 12 2m0 18c-4.41 0-8-3.59-8-8s3.59-8 8-8 8 3.59 8 8-3.59 8-8 8m3.59-13L12 10.59 8.41 7 7 8.41 10.59 12 7 15.59 8.41 17 12 13.41 15.59 17 17 15.59 13.41 12 17 8.41z"></path></svg></div>
<div class="message">#1</div>
</div>
出てくるバナーはこんな感じ。
で、標準であった方が便利だろうというので私以外誰も使っていないであろうadiary-extendsの標準機能として取り込んだ。
なお、この時すでにwarnが記法として組み込まれていたため削除している。
今日は他所事に手が伸びてしまい、これまでのように大きな対応は出来なかったが、締め切りがあるわけでもなければ、一応最低限は見れるので、改築はのんびりやっていこうと思う。
あとadiary-extendsは結構手を入れていて、個人的には本家より便利になっていると思う。
特にコピペで画像をアップロード可能にしたり、Markdownの脚注書式に対応したり、アップロードを許可する拡張子にapngとwebpを追加を追加したりしているので、これだけでもだいぶ使いやすくなっているはずだ。他にも個人的に欲しいと思った機能をそこそこ入れてるので便利になっていると思う。詳細はGitHubにあるadiary-extendsの主な変更点にも書いてあるが、現状の対応は以下のような感じである。
[text](<https://example.com/hoge_()>)が機能するようにした|_hoge________|のようになる（現時点でのadiaryの都合で半角スペース連続がトリムされたためアンダースコアで半角スペース表現を代替している）が、この後ろにあるスペースが全部HTMLのtdに出てきて、文字列を選択するときに不便だったため->が含まれているときにパースが壊れる問題の対応[info:これはお知らせです。]
[warn:これは警告です。]
[error:これはエラーです。]
warn記法の削除。↑の記法と衝突していたため
しかし今月は記事を出す勢いが激しすぎて、まだ6月11日だというのに、この記事を含め23記事も書いてしまっている。一日二記事を超えるペースだ。
この調子で行くと月間執筆数過去最高の2025年3月の35記事を超えてしまいそうである。
この設定を入れただけ。
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を前段の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を手書きして、置換ではなく手作業で移設を行ったので移設するだけで時間が溶けてしまったので、今日はこんなところといった感じだ。