Lyndbaum v4.42アップデート

adiary置き換え計画始動から連なる、Lyndbaum v4.40アップデートの続き。

バージョンが0.2上がり、今回は主に個人的な困りごとを大きく改善した。ちゃんとやることが減っているためアップデート速度は落ちている。

文字数が過大になるとChromiumでMS-IMEがまともに動かなくなる問題の修正

Chromiumで<textarea>に8万字くらい入れた状態で、そのもっとも下の行で変換を行おうとした場合、MS-IMEがまともに動かなくなる問題があった。これを改善し、まともな速度になるようにした。

変更前 変更後

この問題はFirefoxでは起きないことを確認していたが、私はMS Edgeをブラウザにしているため対応した。対応としてはCodeMirror 6を入れることで対応した。40万字入れても安定しており、全文コピペも行える。CodeMirror 6は表示された領域以外をレンダリングから外しているらしく重くならないらしい。Opus 5.5からの受け売りなので本当かどうかは知らないが、軽くなったのは間違いがない。

これによって旅行記などの記事にある長大記事を一々VSCodeで書いて移植しなくてよくなったので、移植ミスが減ることが期待できる。

このこととは関係ないがChromium系はIMEに関する挙動が全般的におかしいと思っているのでどうにかなってほしい思いがある。例えばVSCodeで適当な文字列を選択した状態で何か入力すると既存の入力が崩壊する。これはGoogle IMEでも確か起きる。

エディタ上での構文強調に対応

上の問題解決にCodeMirror 6を使ったので、そのついでに対応した。CodeMirror 6はObsidianやTyporaなどに採用されているとされている、構文表示と構文強調を両立するためのライブラリなので、ついでに構文の強調もできるようにした。

変更前 変更後
変更前は素の表示 変更後は一部の構文が強調表示されるようになった

最低限の対応しかしてないのでそこまでリッチではないが、少し見栄えが良くなった。Lyndbaumで利用しているSatsuki記法もハイライトされるようにしてある。

WYISIWYGにすることも考えたのだが、これはやめることにした。理由は考えることがあまりにも多すぎるからだ。

例えば出来のいいNotionでさえバレットリストを数値リストに変換するには面倒なメニュー操作が必要だし、MilkDownでは表や画像を一括選択して消すなどの操作がそのままではやりづらく、選択範囲もわかりづらい。Altテキストやファイル名だけ差し替えるのも困難だ。

WYSIWYGを保ったままテキストのように扱うというのは、かなり困難なので今回は見送ることにした。複雑であるより単純であるほうが使い勝手はいいだろうという判断だ。ギークはNotionが好きだと思うが、一般人はまず使いこなせないのも、そういうことだと思っている。

検索ウィジェットに検索タイプを非表示にするオプションを追加

デザイナのウィジェット設定に検索タイプの非表示設定を追加した

デザイナで検索タイプの選択を非表示にできるようにした。

表示してる場合 非表示の場合
検索タイプのラジオがある ラジオがなく検索バーのみ

検索字はワードを叩いてエンターしたいので、ここでわざわざラジオを選択したくなかった。

選択は検索結果の画面で可能なので、そっちでするように倒したが、ここもLyndbaumテーマでは手入れして選択の手間を減らしている。

変更前 変更後
変更前はプルダウンメニューを開いて選択する必要があった 変更後はトグルボタンを選択するだけでひと手間減っている

変更前はプルダウンメニューを開いて選択する必要があったが、変更後はトグルボタンを選択するだけでワンアクション減っている。UX向上!

検索画面のファセット検索で親タグだけ出すようにした

変更前 変更後
変更前はすべてのタグが羅列されていて探すのが大変だった 変更後は親タグから選ぶのでマシになった

変更前はすべてのタグが羅列されていて探すのが大変だったが、変更後は親タグから選ぶのでマシになった。タグのインクリメンタルサーチもあると便利な気はするのだがUIをどうすればいいかが思いつかなかったので、一旦はこの形で止めている。

そもそもタグが無数にあるこのサイトが悪いと言われたら、それはそうな気はする。でも、adiaryの使い方としては理にかなっているというか、個人的にはてなダイアリーはPukiwikiの親戚だと思ってるので、あるべき姿なきはしている。

セキュリティ対応

  • 検索時のクエリパラメーターのc(ctype)の値をエスケープせずに画面に出していたのを直した
  • タグの無害化で、実体参照で書いたjavascript:が機能してしまう不具合の修正
  • メール送信のエラーを画面に出さず、エラーログに書くようにした
  • DBの行と設定のファイルを、書き終えてから置き換えるようにした
    • ファイルに出してる途中でOSが落ちたりするとファイルが壊れるため

あとがき

Lyndbaumの目標をどうするかを定めておらず、開発にブレができる懸念があったので一旦何をするためにやっているのかを考えることにした。

adiaryは「The "adiary" is high performance CMS」だったが、Lyndbaumは「The ultimate personal use lightweight self-hosted CMS for Japanese」にしようと思った。長いな。

端的に言うと日本語向けの軽量セルフホスト型CMSという感じ。Markdownと10万字オーダーの長文に対応し、ファセット検索や全文検索、バックリンクに対応し記事を探しやすく、高速に動作し、レンタルサーバーでも動く個人用のCMSみたいなところを目指したい。強欲だ。

旅行記や小説のような長大文章を書くに不自由せず、Wikiのような使い方もできる。将来的にはギャラリーサイトやWebサイトの作成(WordPressのように文字通りのCMS)ができるようにしたいところだが、風呂敷をどこまで広げるかはまだ考え切れていないが、まぁあくまで自分用で、使いたい人がいれば使ってね的なスタンスでぼちぼちやっていければと思っている。

そういえばバージョンの桁を増やしてMajor.Minor.Patch-Brach形式にしようと考えたのだが、バージョンを考えるコストが面倒なのと打つのが面倒なので、これは辞めることにした。桁が足りなくなったらx.yyのyyをyyyにすれば回避できるだろうということで、もし問題になったらその時に考えることにした。

Lokiのデータを永続化した

FluentBitでSystemdのログをLokiに送ってGrafanaで見れるようにし、ついでに設定をYAMLにしたでLokiのセットアップについて書いたが、Lokiのデータを/tmpに置いていたため、再起動などで揮発してログが見れなくなる問題があった。

そこで取り急ぎ永続化することにしたので、やったときのログを雑に残す。

確認環境

Env Ver
Ubuntu 26.04.1 LTS
Loki 3.5.9

前提

やったこと

  1. Lokiユーザーの作成と、永続化の保存先の作成
    sudo groupadd --system loki
    sudo usermod -g loki loki
    sudo chown -R loki:loki /var/lib/loki
    
  2. 現在のデータを永続化ストレージに移動
    sudo cp -a /tmp/loki/. /var/lib/loki/
    sudo chown -R loki:loki /var/lib/loki
    sudo du -sh /tmp/loki /var/lib/loki
    
  3. 保存先を永続化ストレージに変更
     common:
    -  path_prefix: /tmp/loki/
    +  path_prefix: /var/lib/loki/
    
  4. Lokiの再起動
    sudo systemctl restart loki
    

あとがき

以前バックリンク対応を入れたおかげで、こういう断片記事を書いても元記事からたどれるようになるので、今後は気軽にこういう断片をかけるようになると思うと便利だ。これまでは断片同士を探すのが地味に大変で、繋ぎ合わせるのに苦労していたが、それが少しは楽になると思っている。

しかし増えすぎるとノイズになるし、そのうちはやりWikiを作ったほうが良いようにも思える。幸いadiaryは元々Wikiとして使うことも想定されており、Lyndbaumでは差分や履歴管理にバックリンクまで入れているため、個人用Wikiとして使うには十分な機能を持ち合わせているので、実用性はあると思っている。

TODO管理にMantisBTを使うのをやめた

これまでチケット管理にMantisBTを使っていたがこれをやめた。

最大の理由は見ないからだ。プロジェクトを分けチケットを管理していようと、MantisBTのタブをひらっきぱなしにしていようと、私はMantisBTを滅多に見なかった。偶に思い出したように見て稀にタスクを消しこんでいたが、ほとんど役に立っていなかった。

そのためチケットについてはセルフホストを諦め、GitHubに移設した。そしてこれも恐らくあまり見ないと思う。何故なら見ないから。見なくても長期的に何かを残しておきたい用途では使えることが分かったので備忘録程度には使って行こうと思う。

個人的にタスク管理、TODO管理で最も役に立っているのはGoogleカレンダーで、Googleカレンダーにやることを書き、達成出来たら消し、できなかったら順延、どうにもならなかったら消すという運用が比較的よく回っている。これは時間を切ってアラームが出るようにすることで、存在に気が付くことができるためだ。

また昨今行っているLyndbaumの開発においてはテキストベースのTODOリストが元も活躍した。テキストにやりたいことを書き、やったら消す。これはチケットを作る手間も、開く手間も、面倒な管理画面を一覧する手間も何もなく管理がとても楽だった。短所としては何故作り、どう消化し、なぜ取りやめたかの履歴が残らないことだが、そんなことより物事が進むことのほうが何倍も重要だったため割り切ることにした。

情報を管理できるが何も進まないチケット管理より、情報を管理できないが物事を進められるTODO管理のほうがずっといい。最近はGitHub Issueも使っているが、コミットとIssue消化を結びつけるのが手間なので、正直イマイチに思っている。テキストベースならコミットを打ったら消せばいい。それに長期的に見た時にGitHubを手放すことを考えるとIssueに情報を残しても仕方がないのもある。

コミットに- resolved #123とか書いたところでGitHubを捨てたら何のことやらもうわかりはしないのである。なので私はそれはしないことにしていて、結果Issueとコミットが連動していない。よってPRを作ったときにIssueとコミットを突き合わせて消し込む作業が必要になり、手間だ。最近はこれを避けるために先にPRを作り、Issueを消化したらPRにメンションして閉じていて、この仕組みは上手く回っているが、やはり手間である。テキストファイルに追記したり消したりするほうが、ウンと楽だ。

Issue管理の利点は草が増やせることと、後で経緯を多少振り返りやすくなることくらいしかない。そもそもPRに経緯を書いているため、ほぼ役に立っていない。精々リジェクトしたときにリジェクトしたことが分かる程度だ。何故ならPRにはやったことは書いているが、やらなかったことは書いていないからだ。なぜやらなかったかはIssueに残せる。但し振り返る保証はないし、役に立つのかは今のところ不明である。

ひとまずMantisBTを消したことでPHPの世話が一点減ったのはありがたかった。うちは他にttrssをホストしていて、各テナントの仮想化をしていないため同一のDBMSや言語ランタイムを使うものが複数いると、これらのバージョンにまつわる競合が面倒だった。ttrssもどうにかしたいのだが、ここまで出来のいいRSSリーダーが他に見当たらないため一旦放置している。Pukiwikiもホストしているが、こいつが問題を起こすことはまずないと思うので深く気にしてはいない。

私は一応PHPerの端くれを名乗っているが、実のところPHPのことが特に好きなわけではなく、最近は忌むべく存在になりつつあるので、可能な範囲でPHPは排除したいと考えている。PHPは実行権限なくても動いてしまうのが厄介だし、ランタイム本体が汚染されとか、その利用者の多さゆえに攻撃の対象になりやすいのも懸念事項だし、後方互換性良く切り捨てるので私はあまり気に入っていない。

Lyndbaum v4.40アップデート

adiary置き換え計画始動から連なる、Lyndbaum v4.39アップデートの続き。

今回は管理機能周りの改善。このバージョンはさくらのレンタルサーバーに設置して新規にブログを作成できるところまで確認している。

ブログの初期セットアップの画面を作り、セットアップ前はほかの画面を開けなくした

ブログをセットアップする画面

Lyndbaumを使う人間が私以外にいるかという問題はさておき、以前マルチサイトやマルチユーザー機能を削除したためブログのセットアップ画面も作り直した。

元々は静的なindex.htmlを起点とする仕様だったが、それをやめて普通にCGI側に全部持たせ、ブログが未作成の状態では一切他の画面を開けないようにした。また従来はroot*という特権ユーザーが存在したが、偶に裏口を叩きに来る人がいるため、これは削除した。

当たり前ではあるがnoindex,nofllowにしてある。

メンテナンス画面の見た目を整えた

変更前 変更後
変更前のメンテナンス画面は殺風景で、閲覧者にログイン導線が分かりやすかったうえ、閲覧者にとって解りづらかった 変更後はある程度見た目を整え、ログインリンクを一目でわかりづらい場所に再配置した

変更前のメンテナンス画面は殺風景で、閲覧者にログイン導線が分かりやすかったうえ、閲覧者にとってどういう状態なのかわかりづらいように思ったので、多少わかりやすくし、ログインリンクに誤って入られないよう、一目見た時に解りづらい場所に移動させた。

当たり前ではあるがnoindex,nofllowにしてある。

システムチェックを、より意味があるものに変更した

変更前 変更後
変更前は意味がない情報や、出ていないものがあるなど活用しづらかった 変更後はバグ報告に活用できる情報のみにし、サーバーに対して攻撃可能な情報は削除した

変更前はバグ報告に添付されても意味がない情報や、動作確認の役に立つのか怪しい情報があった。そこで変更後は本質的に必要な情報だけに絞り、動作チェックもわかりやすくした。また実行パスなど表に出すと問題がある情報は項目から削除した。

あとがき

本体周りの改善は大分キリがいいところまで達成できたように思う。まだ管理画面の設定項目が妙なところにあって分かりづらいとかはあるものの、取り敢えずデータの引継ぎがなければ使える段階までは来たと思う。

データの引継ぎ周りはまだ検討できてないが、一旦ユーザーマニュアルなどを整備すれば他の人が最低限使うことができる状態にできたと思う。バージョンのキリもいいため、本体更新は一旦このあたりで蹴りをつけ、次はマニュアル周りの整備を進めていきたいと思う。

今回の修正をするにあたり、今まで理解を避けてきたスケルトン記法についても少しわかってきたので、これは収穫だった。一言でいうとスケルトン記法はPHP並みに凄い機能が盛られた概念で、第三者が作ったテーマの作りによっては任脆弱性を作りこめてしまうなど、DSLと呼ぶには大きすぎるものだった。しかしここは特に手を入れることはしない予定だ。

参考までに今回のPRも置いておく。

9月末辺りから今日に至るまでほとんど毎日更新している関係でGitHubの草が多く、また頻度の多さから色濃くなっている

しかしまぁ、我ながらよくもまぁこう毎日更新できるものだと感心する。GitHubの草はこれまでにない連続性と密度で生え散らかしているが、そろそろ落ち着いてくるのではないかと思っている。Claude Max x5の契約もそろそろ切れ、Proに戻る予定なので、物理的に勢いを保てなくのもある。

あとがきのあとがき

久々に出たあとがきのあとがき。

Lyndbaumの開発をしていて、ふと頭をよぎったのが静的サイトジェネレーターにしないのかというところだ。静的サイトジェネレーターならサプライチェーン攻撃以外は気にしなくてよくなるかもしれない。

これに対して明確な答えは今のところない。しかしCGIの利点としてSPAなどクライアントベースと比べた時にファーストビューが早い利点はあると思っている。例えば検索用のJSONを持つ必要がないし、Lyndbaumのように記事に対して真の全文検索[1]をする場合、クライアントサイドだけやるには記事全文をクライアントに渡す必要がある。これは非常に無駄だ。

このブログは現状15MB程度のテキストデータがあるがgzip圧縮したとしてもPageSpeed Insightsのスコアは下がるだろうし、遅延読み込みとか、なんかそういう面倒なことはとにかく考えたくないのだ。

また今の方式の利点として、良くも悪くも全部が見つけ都合になっているため、クライアントとサーバーサイドで世話を分けるとか、そういうことをしなくていいことや、全部が繋がっているので考えることが少なくて済むのは利点だと思う。半面でてがろぐに直近であった脆弱性対応を考えると、マイナーCMSでもそのあたりは考えないといけないと考えさせられるが、それはNode.jsで動いてるやつでもサプライチェーンマネジメントとして必要になってくることだとは思うし、なんというか考えていて疲れてきたので考えることは一旦やめることにした。

ひとまず壊れていない物を直すなということもあるし、今の執筆環境は非常に快適なので、これを保つという意味では十分いいことだと思う。ブログの管理もやりやすい。adiaryは非常によくできており、私はそこの中にあるちょっとした個人的不満を解消したかったのだ、そう思うことにした。

まぁ動的な作りなら将来的にユーザー管理機能を復活させてペイウォールを実装するなどの余地もあると思うので、そういう場合の備えとして考えることもできると思う。

最後にサプライチェーン攻撃について書いておくと、Lyndbaumは依存ライブラリの数が極端に少なく、Image:MagickとNet::SSLeay、FCGI以外はPerlの組み込み機能で動いているため、ほとんど心配は不要だと考えている。jQueryも化石級のまま放置されておりセルフホスト前提のため、サプライチェーンがどうなろうと関係がない。また組み込み外のライブラリについてもディストリが供給してくれるため、node_modulesやComposerのライブラリより遥かに信頼性が高いと考えており、基本的に心配はしていない。

基本的にLinuxなどのディストリビューションではメンテナンスチームによる検証が行われてからリリースされているはず[2]なので、作者が気軽にPushしたり、作者に反感を持ったコントリビューターから攻撃されるなどカジュアルに破壊されるようなケースは少ないと考えている。そもそも最新版を要求しないので、どうでもいい側面もある。


  1. 検索用の辞書や索引などを用いず、無作為にgrep的な検索をすること ↩
  2. aptなどのパッケージマネージャーで落ちてくる標準がやたら古いのはこのため。膨大なパッケージを抱えているので全てを常に最新に保つことはできない ↩

Lyndbaum v4.39アップデート

adiary置き換え計画始動から連なる、Lyndbaum v4.37アップデートの続き。

バージョンが0.2増えた。今回は機能追加と機能改善。

PukiWikiの差分に相当する機能を追加

PukiWikiには前回更新時のスナップショットを持っておき、前回の状態と比較できる機能がある。これを追加した。

これにより更新したけど、やっぱ戻したいとか、前何書いたっけ?を確認したい時に対応できる。

PukiWikiの差分に相当する機能。差分を見たり、この時の状態に記事を戻せたりする

画面はこんな感じ。

リンクカードの更新を抑制

v4.36で導入したリンクカード記法には記事更新やブログ再構築時に毎回再取得が走る問題があり、相手サーバーの負荷になるうえ、単純に更新が重い問題があった。

これを解消するために再構築ではリンクカードの更新をオプションにし、記事更新時にはリンクカードを作らないようにした。どうしても作り直す場合は作り直したいカードを消して更新し、もう一度書き直すことで実現できる。

この方式はMastodonの作りを参考にしている。Mastodonでは一度投稿を消し適当なハッシュリンク付きで投稿し、削除し、ハッシュリンクなしのURLで再投稿することでリンクカードを無理やり更新できる裏技がある。この恐らくMastodonの開発者が想定しているとは思えない振る舞いを参考にし仕様を作った。システムでどうこうすると大変なので運用でカバー。

((注釈))記法の一覧を注釈を書いた見出しセクション内に展開するようにした

元々は大見出しごとに分かれていたが、((注釈))を書いた見出しの中に収めるようにした。こうしないと脚注と大きな差がなく、注釈としてあまり意味がないため。

画面表示に利用していたリポジトリURLが古かったのを修正

フッターに出ていたリポジトリURLがLyndbaum4のままだったので無印に改定した。参考までに過去のLyndbaumはLyndbaum0になっている。

あとがき

今回の対応によりIssueはだいぶ片付き、残りといえば直しても直さなくてもどうでもいいレベルの内容や、他の人が使えるようにする対応のようなものが中心になっている。

特に何もなければ昨今起きているLyndbaumアップデート記事の連打は今後減っていく、と思いたい。

そういえばリリースの版数でブランチバージョンを除いたバージョンを数えていたら64件になっていた。キリがいい。


現時点でのリリース一覧(v0.22.dev-1はブランチに見えるが、v0.22.0相当なので含んでいる)

リンク先はリリースページでなくPRかコミットハッシュにしている。

v4.39 / v4.38 / v4.37 / v4.36 / v4.35 / v4.34 / v4.33 / v4.32 / v4.31 / v4.30 / v4.29 / v4.28 / v4.27 / v4.26 / v4.25 / v4.24 / v4.23 / v4.22 / v4.21 / v4.20 / v4.19 / v4.18 / v4.17 / v4.16 / v4.15 / v4.14 / v4.13 / v4.12 / v4.11 / v4.10 / v4.09 / v4.08 / v4.7 / v4.6 / v4.5.1 / v4.5 / v4.4 / v0.43 / v0.42.0 / v0.41.0 / v0.40.0 / v0.30.0 / v0.29.0 / v0.28.0 / v0.27.0 / v0.26.0 / v0.25.0 / v0.24.0 / v0.23.0 / v0.22.dev-1 / v0.21.0 / v0.16.0 / v0.15.0 / v0.13.0 / v0.9.2 / v0.9.0 / v0.8.0 / v0.7.0 / v0.6.2 / v0.6.0 / v0.5.0 / v0.4.1 / v0.3.0 / v0.2.0 / v0.1.0


しかしadiaryを地味に改修している話からずいぶん遠いところまで来た感じがある…。