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は非常によくできており、私はそこの中にあるちょっとした個人的不満を解消したかったのだ、そう思うことにした。

まぁ動的な作りなら将来的にユーザー管理機能を復活させてペイウォールを実装するなどの余地もあると思うので、そういう場合の備えとして考えることもできると思う。実は太古の昔にStripeの開発者アカウントをとっているので、このアカウントが今でも生きてれば作れる機能ではある。

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

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


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