RNote

hugo再再起動

先日再公開したWebサイト。

Perplexity作の扉絵

この仕組みをイラスト1枚の扉絵にして

rNote版のサイトとイメージが乖離してしまうと面倒なので記事内のHTMLをそのまま引き継ぐ形で構築したのが、リンク切れなど細かく確認チェックしたところ、実体パスが変わっていたり、エラーで変換漏れしている事がわかった。

詳しく言うと、rNoteでいうところのAnker:20171115_b_routeは、アンダーバーを使わないHugoではslug:20171115-b-routeになるらしいので、改めて「清く正しくMarkdownのお作法に従うべし」という考えに立って、今度はPerplexityでやり直し。

変換漏れは、slugの元ネタとなるAnkerが元々間違っていた(コピー元から派生した際の変更忘れ)事に起因する、slug重複による上書きと判明し、XML側のAnkerをファイル名に合わせて手動で訂正。

アンダーバー問題は内部参照リンクをスクリプトで変換する形で対応。

公開サーバにアップロードすると記事内の画像や参照リンクURLが/images/~と絶対パスになってしまう問題も復活したが、Hugoのテンプレートに清く正しくRelPermalinkやrelURLなどを盛り込む対処でOK。

Gemini版とは違うものの、Archiveを年月でドリルダウンする仕掛けもそれなりにできた。いずれにせよrNote版とは乖離しており、どっちが良いとも言い切れないのが悩みだが、レスポンシブデザインだったりユニバーサルデザインとか考えるとそのあたりに拘るのは時代的によろしくないのかもしれないなぁ、と理解。

yano@cometlake:~$ cd ~/hugo_site/
yano@cometlake:~/hugo_site$ source .venv/bin/activate
(.venv) yano@cometlake:~/hugo_site$ rsync -avu gt110b.local:~/public_html/entries/diary/* rnote_xml/; \
                                    rsync -avu gt110b.local:~/public_html/images static/;
(.venv) yano@cometlake:~/hugo_site$ python rnote2hugo.py -b "/~yano" -i rnote_xml/ -o content/post/
完了: 8667 件変換, 0 件エラー  →  content/post/
(.venv) yano@cometlake:~/hugo_site$ hugo
Start building sites …
hugo v0.161.0-98d396c16a07b51df06e7673d817a3880da6218d+extended linux/amd64 BuildDate=2026-04-28T11:46:32Z VendorInfo=gohugoio
~~
Total in 40521 ms
(.venv) yano@cometlake:~/hugo_site$ rsync -avu ./public/* vps:~/public.hugo.20260516/

前回ので10分以上かかっていた8,000件のbuild時間も40秒ほどに短縮されて、何より。

参照

The world’s fastest framework for building websites https://gohugo.io/

hugo再起動

geminiによるダッシュボード作成がうまくいったので、2008年のMTOS乗り換え検討以来の懸案にも活用してみた。

1枚の扉絵してもらった

この仕組みをイラスト1枚の扉絵にして

もう一度rNoteを立ち上げて移行する方法を相談してみたところ、やっぱりXML記事をMarkdownに変換して静的サイトジェネレーター(SSG)で構築するのが良さそうだ。というわけで2019年4月に着手したHugoに再トライ。

テーマはひとまずMainroadを選択。さらにArchive記事を年月日で絞り込めるようにレイアウト/テンプレートを補強し、大枠はいい感じになったものの、肝心の画像と参考リンクのスタイルがどうにも以前のサイトとイメージが乖離してしまうので、記事を真面目にMarkdownに変換するのは止めて、ひとまず記事内のHTMLはそのまま残す方針で再公開を優先。

公開サーバにアップロードすると記事内の画像や参照リンクURが/images/~(/~yanoが入らない絶対パス)になってしまう問題があって、hugo serverで起動してhttp://localhost:1313/で確認ケースと折り合いを付けるのに四苦八苦したのだが、どうやら「記事内のHTMLはそのまま残す」方針がHugoの仕様と相容れない結果らしい。

いずれ自家製AIに喰わせて遊ぼうと思ったら、画像や参照リンクも含めてMarkdownのお作法に従うのがいいんだろなぁ、というのもなんとなくわかったので、今回はMarkdown変換スクリプトで強制的にURLに/~yanoを入れてしまう方向で着地。

2019年4月のHugo着手から7年余りの紆余曲折を経てようやく結実。2024年9月に一時閉鎖したサイトもひとまず再開できた。

参照

The world’s fastest framework for building websites https://gohugo.io/

GitHub - Vimux/Mainroad https://github.com/Vimux/Mainroad/

Google Gemini https://gemini.google.com/

Wikipedia http://ja.wikipedia.org/wiki/

サイト一時閉鎖

Webサイト構築に使用しているrNoteにJVN#68244135: rNote におけるクロスサイトスクリプティングの脆弱性がアナウンスされています。

JVN#68244135: rNote におけるクロスサイトスクリプティングの脆弱性

JVN#68244135: rNote における…より

2021年のUbuntu 20乗り換えの流れでphp 7.4.3対応として若干手を加えたので(希望的観測で)大丈夫かな~とは思ってるんですが、2011年6月14日のリリースから10年以上放置されているソフトウェアに拘り続けるというのもあれなので、とりあえずrNoteにおける運用を停止しWebサイトを一時閉鎖します。

代替フレームワークに乗り換えできたら再開する予定ではありますが、2008年のMTOS乗り換え検討以来かれこれ15年以上右往左往し、2019年のHugo検討から5年以上は手が止まっている状態なので、どうなりますことやら。

参照

rNoteサポートページ http://rinn.e-site.jp/rnote/

Japan Vulnerability Notes https://jvn.jp/

CWE - Common Weakness Enumeration https://cwe.mitre.org/

Ubuntu20.04

2014年6月にUbuntu 14.04 (Trusty)にアップデートしたbravotouring.comのサーバ。

Hugo乗り換えを大義名分に先送りにしていたアップデートを、気の迷いで1月13日未明にうっかり実施。大胆にもdo-release-upgradeを3回繰り返し、LTS最新版のUbuntu 20.04 (Focal Fossa)という荒業にチャレンジしたメモ。

まず、spamassassinが起動に失敗。うん、CPANが追いついてないので無理だよね、というわけでひとまずuninstallして首絞め。

続いて、DKIMNSDも起動に失敗していて、メールが送受信できない事に気づいて軽く慌てはじめる。/var/log/syslog

Jan 13 03:59:56 vps nsd[2349728]: Error in SSL_CTX use_certificate_file 
    crypto error:140AB18F:SSL routines:SSL_CTX_use_certificate:**ee key too small**

というエラーに気づいた。ググってみるとOpenSSL 1.1.1/changelog[28 May 2019]で

Change the default RSA, DSA and DH size to 2048 bit instead of 1024. This changes the size when using the genpkey command when no size is given. It fixes an omission in earlier changes that changed all RSA, DSA and DH generation commands to use 2048 bits by default.