ブログをAstro+TinaCMSからWordPressに移行した話

 この度、本ブログをAstro+TinaCMSからWordPressに移行しました。

 本記事では、WordPressの選定理由及び、移行手法について紹介します。

旧ブログの環境と問題点

 旧ブログは下記の環境で構成されていました。GitHubにMarkdownの記事データを載せるか、TinaCMSを使って記事を書くことで、Cloudflare Pagesのデプロイが自動で走り、静的サイトとして提供されるようになります。また、画像ファイルは/publicディレクトリに保存します。

  • Astro 7.1
  • TinaCMS 3.11
  • Cloudflare Pages

 本環境での問題は2点ありました。

 一つ目は画像のアップロードが少し手間であったことです。画像は/publicに保存されますから、事前に画像を圧縮しておく必要があります。また、TinaCMSは画像のアップロードを行う度にコミットを行う為、Cloudflare Pagesのビルド数制限を圧迫します。

 二つ目は下書きの問題です。私は技術系の記事を書く際、検証を行いながら、同時に本文を記述します。この場合、数日にまたがる検証や、そもそも数ヶ月掛けて気が向いたら検証を進める系の記事では、Gitにコミットできず、そのまま機材の初期化等で失われる記事が出てきます。Astroの設計でDraft記事を受け付けるようにすれば良い話ではあるのですが、プッシュしてしまうとCloudflare Pagesのビルドが走る問題もあり、あまり下書きに向いていない運用でした。

 これらの問題があったため、これらが解決できそうなWordPressを導入することにしました。

WordPressの選定理由

 真っ先に考えた移行としては、TinaCMS以外のDraftを扱えるソリューションへの移行と、Cloudinary等の画像配信サービスの導入です。

 しかし、TinaCMSはめんどくさい記事のアトリビュートを持っているこのブログにとても良くフィットしていましたし、実際に他のソリューションを入れてみたところ、あまりうまく動いてくれませんでした。

 また、このブログはアクセス数が少ないですが、それでも従量課金要素のあるCloudinary等の導入はあまり気乗りしませんでした。

 そこで、静的サイトを諦め、CMSを導入することにしました。CMSはあまり詳しくなく、とりあえず有名で、元々使ってみたいと思っていたWordPressに白羽の矢が立った訳です。実際に手元で簡単な検証を行ったところ、うまく移行出来たため、WordPressが移行先の第一候補となりました。

 OSS WordPress以外のソリューションとして、SaaSに移行するというアイデアもありました。具体的には、はてなブログやWordPress.com等です。しかし、これらのサービスはカスタムドメインが有償であり、なおかつこれまでのURLを引き継げるかの確認も取れず、丁度レンタルサーバを別用途で借りていたのもあって、自動更新などを行ってくれるOSSのWordPress運用することに決めました。

 また、AstroのバックエンドでWordPressをヘッドレスCMSのように使う選択肢もありましたが、こちらは純粋に設定の手間を考え、直接WordPressを公開することにしました。

移行手順

 逆はよくあるのでしょうが、AstroからWordPressへの移行はあまり記事がなかったように思います。今回は思い立ったのが丁度お盆休み中で、幸い記事数も少なく検証作業も簡単だったため、ChatGPTにMarkdownベースの記事一覧をWordPressのXMLエクスポートに変換するプログラムを書かせました。

 このスクリプトがかなりうまく動き、一部のMarkdownを除いてまともに読めるレベルの移行が行われていた上、問題のあるMarkdownも頑張れば読める状態であったため、このエクスポートファイルをそのまま本番の移行に使うことにしました。

 WordPressのエクスポートファイルには画像データ等が存在せず、これらのデータはサーバから落としてくる仕様の為、同一ホスト名で移行する際には問題が発生します。今回はCloudflare Pagesの.pages.devドメインが生きていたため、ここから画像ファイルを落としてくるように設定しました。

 特にコメントなども存在しなかったため、記事データの移行はこれだけで完了しました。

最後に

 WordPressへの移行は主にLLMのおかげでかなりうまくいきました。今後はカテゴリ機能等をうまく使いこなして行きたいと考えています。

 また、WordPressといえばセキュリティ問題です。一応簡単にセキュリティが上がりそうな設定は投入していますし、レンタルサーバ側も簡易的なWAFを導入してくれているようなので、これらに期待したいと考えています。現状利用しているテーマはWordPress公式の物ですし、プラグインも有名どころと思われるもの一個しか入れていないため、そこら辺の問題は少ないと思いたいところです。

 現状気になる点は、編集画面の背景が真っ白でDarkReaderも効かないため、肝心の執筆を行っていると目が痛くなることくらいでしょうか。記事ページはDarkReaderに対応しているので、おそらく本記事をご覧の方は問題無いはずです。

 今後より良いソリューションを見つけた場合、また移行を行うかもしれませんが、しばらくはWordPressの高級すぎるエディタを使って記事を書いていければと思っています。

HardwareVisualizerを起動時にUAC無しで立ち上がるようにする

最近、HardwareVisualizerというソフトウェアに出会いました。プログラム実行中は裏で常にGPU温度やプロセスの状態を記録しておき、後からそれらの情報を取得できるNetDataのようなソリューションです。

自作PCの冷却に不安を抱えていたり、ゲーム中のリソースの過不足が気になっていたりと、バックグラウンドかつ時系列での測定ソリューションが欲しいと思っており、適当にAIに愚痴ってたらこのソフトを教えてもらったため、利用するようになりました。

しかし、このソフトウェア単体ではCPU温度をまともに取得することができず、PawnIOをインストールすることでなんとかCPU温度を確認出来るようになるのですが、管理者権限が要求されます。

管理者権限が要求されるということはUACが表示されるということで、毎回起動時にUACが表示されるのは少し気になります。特にスタートアップにすさまじい量のアプリケーションを登録している関係で、タイミングが悪いとブラウジング中にUACが出ることもあります。

そこで、本記事ではUAC無しでスタートアップを行う手法について扱います。HardwareVisualizerを対象としていますが、ロジック的にはWindows標準のタスクスケジューラを利用するため、他の管理者権限を要求するアプリケーションの自動実行でも使えるはずです。

環境

  • Windows 11 Pro (25H2, 26200.9168)
  • HardwareVisualizer 1.9.2

現在GitHubのデフォルトブランチに存在するHardwareVisualizerはかなりUIが変わっているので、もしかしたら次の大幅なアップデートで手順が変わるかもしれません。

HardwareVisualizerの事前設定

事前にHardwareVisualizerの設定画面にて、下記の設定を投入します。

  1. Automatic startup on OS startupを無効に(タスクスケジューラによる自動起動と競合するため)
  2. Run as administrator on startupを有効に
  3. (オプション)Close to tray instead of quittingを有効に

タスクスケジューラによる自動起動設定

タスクスケジューラを開き、Task Scheduler Libraryもしくはお好みのフォルダを開き、そのフォルダ内でアクションメニューのCreate Taskをクリックします。

Generalでは、Nameを適当にHardwareVisualizer等と設定し、ユーザアカウントが自ユーザになっていることを確認した後、Run only when user is logged inを選択し、Run with highest priviledgesを有効にします。

同時に、Configure forをWindows 10もしくは最も新しいOSに設定します。

Triggersタブでは、新たにAt log onトリガーを作成します。ユーザは自ユーザがログインした際に制限し、それ以外の設定はデフォルトのままにします。

最後に、Actionsタブで新たなアクションを作成します。アクションはStart a programで、Program/scriptは標準では"C:\Program Files\HardwareVisualizer\hardware-visualizer.exe"となるはずです(ダブルクオーテーションは保持してください)。

もし、別のディレクトリなどにインストールした場合は、そちらに合わせて設定してください。

これらの設定を行った後、OKを押して保存します。

最後に、実際にPCを再起動したり、ログオフしたりして動作の確認を行ってください。

おまけ: CPU温度取得設定

Hardware Visualizerでは一部のセンサー情報の取得にPawnIOを要求します。Intel CPUの温度情報の取得等を行いたい場合は、PawnIOのインストールが必要です。

PawnIOはかなり強い権限を自由すぎる機能を持つドライバーです。ゲームのアンチチートツールに引っかかりそうな気もしますが、現状Strinova, NTE, 鳴潮では特に問題は起きていません。

下記にPawnIOの簡単なインストール手順を記述します。詳細は公式ドキュメントも参考にしてください。

  1. PawnIO公式サイトからインストーラーをダウンロードし、インストールします。Macintosh向けインストールDMGのように、インストール後もインストーラーを呼び出すウィンドウが残りますが、正常ですので、各自で終了させてください。
  2. PawnIO.Modulesのリリースから最新のモジュールを落としてきます。
  3. ダウンロードしたモジュール(大量の.binファイル等)をC:\Program Files\PawnIOに保存します。必要なモジュールのみを入れることもできます。

以上で設定は終了です。次回HardwareVisualizerを管理者権限で起動した際に、CPU温度がCPU Package (PawnIO Intel DTS)のような名前で表示されるはずです。

CoreServer v2でCloudflare Origin CAを使う

近年は証明書を発行すると、Certificate Transparency Log に残り、内部用サイトのドメインが流出したり、公開直後から/wp-admin等への攻撃が始まったりします。

この問題を解決する最も簡単な方法はワイルドカード証明書を発行することですが、Let’s Encrypt 等では TXT レコードの追加が求められ、CoreServer の自動発行・更新では対応できず、証明書の有効期限が年々短くなっていく昨今、手動更新もあまり現実的ではありません。

そこで、Cloudflare の発行する最長 15 年の証明書を使った Cloudflare と CoreServer 間の TLS 通信を行うことで、Certificate Transparency Log に残す証明書を Cloudflare の自動発行するワイルドカードの Edge Certificate のみにしようという試みです。

もちろん、この手法を使うには Cloudflare にプロキシさせることが条件となります。一応 Cloudflare の CA を各デバイスに配り、信用するように設定することも可能ですが、あまり良い方法とは言えないでしょう。

また、本手法では CoreServer V2 のサブドメイン登録機能を使うことで、サブドメインで提供されるサイトすべての証明書の設定を一括で終わらせられるようにしています。Cloudflare にプロキシさせたくないサイトは、サブドメインとして登録するのでは無く、ドメイン登録画面から設定し、個別に Let’s Encrypt 等の証明書を渡す必要があります。

CloudflareでOrigin CAを発行する

Cloudflare は頻繁に UI が変わるので、Cloudflare origin CA · Cloudflare SSL/TLS docs あたりを直接確認していただければと思います。

CoreServer V2 から ECC に対応していますので、Private key type は ECC にすると良いでしょう。

Hostnames に関しては APEX を使う場合、ワイルドカードに加え、APEX も登録すると良いでしょう。また、後から証明書を区別しやすいように、note--for-coreserver等のサブドメインも登録すると便利です。

また、事前にドキュメントの「Cloudflare Origin CA root certificate」セクションから、ECC の CA をダウンロードしてください。

CoreServerでドメインの設定とSSLの設定を行う

管理画面の「ドメイン」->「ドメイン管理」で、利用したいドメインを追加します。Cloudflare の無料プランの場合、登録ドメイン直下しか使えませんので、例えば「example.com」を Cloudflare に登録されている場合、CoreServer に登録するドメインは同じく「example.com」となります。

登録後、「SSL証明書設定」を開き、画面右上のドメイン名を設定したいドメインに変更します。その後、「事前に生成された証明書とキーを貼り付け」を選択し、画面の右上に現れた「SSL CA証明書」をクリックし、事前にダウンロードした Origin CA のルート証明書を貼り付け、「Use a CA Cert」にチェックを入れて保存します。

その後、1 画面戻り、鍵と証明書に Cloudflare のダッシュボードに表示された証明書を貼り付けます。

ECC を利用している場合、鍵のBEGIN PRIVATE KEY及びEND PRIVATE KEYをそれぞれ、BEGIN EC PRIVATE KEYEND EC PRIVATE KEYに変更してください。

公開するサブドメインを追加する

CoreServer の設定で、「ウェブ」->「サブドメイン管理」と進み、画面右上のドメイン名を設定したいドメインに変更します。その後、サブドメインを追加からお好みのサブドメインを登録します。

その後、Cloudflare の DNS 管理画面に当該ドメインと CoreServer の A/AAAA もしくは CNAME レコードを追加し、プロキシ設定をオンにします。

Apple containerを使ってみた

現在私の使っているMacintoshはM1 MacBook Airの8GBモデルという、なんとも言えない性能のマシンです。Apple siliconの初めてのマシンで、macOS上で動くソフトウェアはよほど無理をしない限り、8GBであることを忘れる程快適に動作してくれますが、Asahi Linuxはもちろん、macOS上であってもDockerを動かすとメモリとバッテリーをかなり消費します。

本記事では、8GB macOSにおいて、Apple containerがDockerの代わりにまともに動き、開発環境として使えるのかを検証したいと考えています。

環境

  • MacBook Air A2337 (M1, 8GB RAM, 256GB SSD)
  • container 1.0.0

使ってみる

下記に試したコマンド及び結果を記述します。

# 独自のPHPIpam Dockerイメージのビルド
# Src: https://github.com/mkaraki/phpipam-frankenphp-docker/tree/897f4c2f121d8e7c991c23c984e1bb6897b6931d
# container-runtime-linux用のVMサービスが2.13GB程度のメモリ消費
# arm64である影響で最後まで実行できず
container build -t phpipam:latest .

# さすがに動く
container run -it --rm ubuntu:noble

# 簡単なDockerfileのビルド
container build -t ipdb:latest .

# ポート待ち受けを行うApache2 PHPアプリのテスト
container run --rm -it -p 8080:80 ipdb:latest

# Volumeマウントを伴うFrankenPHPアプリケーション
container run --rm -it -p 8080:8080 -v $(pwd)/books:/books:ro cbz-viewer:latest

軽く試したところ、Containerを使い始めると、Virtual Machine Serviceが立ち上がり、メモリを2.13GB程消費し始めます。これにより、Activity Monitor上でのMemory Usedが7GB前後をうろうろするようになり、一応JetBrains IDEとMS Edgeを追加で立ち上げてもきちんと動いてはいるものの、かなり不安感はあります。この状態でCompressedが2.97GB、Swapは8.35GBです。

使っているターミナルがWarpだったり、裏でTeamsやEvernoteなどが動いていたりと、Container以外にもメモリ使用率を上げている要因はありますが、とはいえ8GBのMacBookではプログラマーになる夢を見るには少し厳しいかもしれません。

また、WSL containerと同様に、こちらもDocker Compose相当の機能を実装されていないようです。しかし、apple/container #1736にパッチが上がっているので、もしかしたら近いうちに動かせるようになるかもしれません。

Cloudflare One Clientとの相性問題

VMが53をBINDする為、mDNSResponder関係のエラーが出る場合があるとのこと。一度container system stopを行ってから、再接続しよう。Cloudflareのドキュメントによれば、再接続後に再度Container Systemを起動すれば動かせるらしいが、こちらは未検証。

Ref

WSL containerを触ってみた

環境

  • Windows 11 Pro 25H2 (OS Build 26200.8655)
  • Windows Subsystem for Linux 2.9.3
  • Git for Windows (git version 2.54.0.windows.1)

インストール

特に再起動などは要求されず、下記のコマンドを打ち、後は指示にしたがうだけで終わりました。

ただし、Docker Desktop on Windowsとの相性は悪いらしく、WSL needs updatingの画面が表示されました。現在使っているのが、Docker Desktop on Windows 4.75.0 (227598) と少し古いのが影響しているのかもしれません。

wsl --update --pre-release

使ってみる

基本は docker コマンドの代わりに wslc コマンドを叩くだけで使えます。検証するにあたり、Docker Composeが移植できるか試したかったのですが、どうやらそちらは非対応のよう。

Clystian氏 がパッチを作っているらしく、そちらはある程度試せる状態の用です。詳細は clystian/WSLのPR #1 をご参照ください。

また、公式リポジトリの Discussion #40836 及び Issue #40948 はあまり活発ではなさそうです。WSL Container自体が最近の発表かつ、Public Preview入りしたばかりですから、これはばかりはしょうがないです。

下記に実際に打ってみたコマンドを貼ります。最低限コンテナで遊ぶ分には問題なく動いてくれます。

# Ubuntuのシェルをお試し
> wslc run --rm -it ubuntu:noble

# ps等の有名なショートカットは普通に動く
> wslc ps
CONTAINER ID   NAME            IMAGE         CREATED          STATUS                 PORTS
AADC7244B1FB   noble_beartooth ubuntu:noble  16 minutes ago   running 16 minutes ago

# 独自のPHPIpam Dockerイメージのビルド
# Src: https://github.com/mkaraki/phpipam-frankenphp-docker/tree/897f4c2f121d8e7c991c23c984e1bb6897b6931d
# デフォルトだと動かない為、後述する修正を実施。
> wslc build -t phpipam:latest .

# 簡単に http://localhost:8080 で接続できることを確認
> wslc run --rm -it -p 8080:80 phpipam:latest

# マウントテスト
# 先頭に`/mnt/`を付けたりもしたが、ダメそうである。
> wslc run --rm -it -p 8080:80 -v /d/projects/phpipam-frankenphp-docker/Dockerfile:/test phpipam:latest
> wslc exec -it 1da35be50090 sh
$ cat /test
cat: /test: Is a directory

Docker Buildのお試し

前セクションで wslc build コマンドを叩きましたが、これはうまく動きませんでした。表示されたWARNING、ERRORは下記の通り。

WARNING: current commit information was not captured by the build: git was not found in the system: exec: "git": executable file not found in $PATH
ERROR: failed to solve: dockerfile parse error on line 19: unknown flag: exclude

まず、本環境にはGit for Windowsがインストールされていますが、これは認識されないようです。

そして根本的なエラーとしては、COPY 命令における --exclude オプションを認識していない。本問題の解決は容易で、ファイル先頭に # syntax=docker/dockerfile:1.25.0 とDockerfileのシンタックスバージョンを指定することで解決しました。

標準で使われているSyntaxバージョンについては調査して居ませんが、これからはSyntaxバージョンを指定するようにした方が安全かもしれません。

全体的な感想

compose コマンドや cp コマンドが無いなど、Docker Desktop on Windowsの代替として使うにはあまりにも頼りないですが、簡単なデータベースを検証用途で動かす等の用途ではある程度使えそうです。

Network系のコマンドや、Volume系のコマンドは検証から外しましたが、Docker Compose実装パッチのスクリーンショットを見る限り、こちらもうまく動いてくれそうです。

Ref

NTE上の釣りにおける高価な材料で作られた釣り餌の有効性調査

NTEの「高価な材料で作られた釣り餌」は最も安価な釣り餌の14.4倍の金額となっている。本釣り餌について、その高価さに見合う性能があるのかを簡易的に調査した。

本調査は暇つぶしで行われた、あくまでも簡易的ものであり、信頼できる品質の結果を取得することを目的としていない。

検証環境

本検証は、2026年6月3日にリリースされたNTE バージョン1.1の新釣り場である、「ヒナタ島釣場」にて行った。検証は2026年6月6日に一回のみ行われた。ランチャーの提示するバージョンは1.1.4であった。

検証では、72魚鱗コインで販売されている「幽蘭の餌」を11点購入し、これらの餌及び「上級者の釣り竿」を利用して釣れた魚に、販促文に記載されている、「ゴールデンカマス」及び「海中の栗」の出現回数を調査した。

また、同時に5魚鱗コインで購入できる「万能釣り餌」についても同様の検証を行い、取得できる経験値量及び魚鱗コインを比較する。

検証結果

最終的に、逃げられることなく11匹の魚を釣ることができた。しかし、販促文に記載されている、ゴールデンカマス及び海中の栗に関しては観測できず、釣り経験値にして合計421 Expの取得と、202魚鱗コインの取得にとどまった。取得できた経験値の中央値は25で、平均値は38であった。

実際に釣れた魚の内訳を、下記の表に示す。

Attempt # 魚種別 Exp
1 クロマグロ 24
2 ヒトデ 109
3 クロマグロ 24
4 アオノメハタ 24
5 ユカタハタ 38
6 シャインシイラ 22
7 クロマグロ 25
8 クロマグロ 25
9 藍鱗の旗 43
10 サバ 48
11 金サバ 39

万能釣り餌でも同様に、逃げられることなく11匹の魚を釣ることができた。釣り経験値は385 Exp取得し、184魚鱗コインの取得にとどまった。取得できた経験値の中央値は38で、平均値は35であった。

万能釣り餌にて釣れた魚の内訳を、下記の表に示す。

Attempt # 魚種別 Exp
1 シャインシイラ 18
2 赤鱗の旗 48
3 サバ 59
4 緑鱗の旗 38
5 クロマグロ 19
6 マンボウ 19
7 マンボウ 20
8 エンペラーエンゼル 42
9 赤鱗の旗 51
10 キリンミノカサゴ 21
11 金サバ 50

取得経験値の中央値が幽蘭の餌に比べ高いにもかかわらず、平均値及び合計値は幽蘭の餌が上回った結果となった。

t検定による検証

幽蘭の餌による経験値量及び万能釣り餌による経験値量を非等分散と仮定し、有意水準5%にて両側検定を行ったが、この2点の経験値量の平均値に有意的な差は見られなかった。

議論

本調査では、NTEでの釣りにおける高価な釣り餌の有用性について、簡易的に調査を行った結果、少なくとも11回程度の試行回数では、合計で202魚鱗コイン程度の売り上げにしかならず、釣り餌の金額である792魚鱗コインの元を取ることができなかった。

取得経験値の平均値及び合計値は幽蘭の餌が上回った結果となった原因として、幽蘭の餌において検証を行った際に、経験値量の高い、「ヒトデ」が釣れたためであると考える。ヒトデは本釣り餌の販促文に記述されていないため、偶然このような結果になったと考えられる。

本検証では、サンプル数が11件と極めて低く、外れ値と考えられるレアリティの高い魚による影響を否定できない。今後の検証では複数の釣場の利用や、試行回数を増やす必要性があると考える。

上伊那ぼたん 6話 中国語(台湾)

TinaCMSを導入したので、テスト記事の代わりに簡単にまとめてみた。中国語は全く勉強したことが無いので、内容の信憑性は皆無。

タイムスタンプはAbema TVのVOD基準。ある程度調べた後に原作2巻にすべて載っているという事実を知った。途中からはそちらの情報も含めている。

  • 7:11: 剉冰 (ツア ピン): 従来式の氷を砕くかき氷のことらしい。氷に味が付いている奴は雪花冰というらしい。
  • 8:55: 有意思 (作中ではウー イー スー、Google Translate曰くヨー イー スー): この文脈だと、「興味深い」もしくは「おもしろい」だろうか。他にも「おかしい」「意義がある」等の意味もあるらしい。食べてみたい。
  • 14:40: 同上か?: 文脈としてはあってなさそうであるため、聞き違えの可能性が高そう
  • 15:05: 我想喝水: 聞き取れなかったので原作を確認した。水をほしがっているっぽい。
    • 我: 主語
    • 想: ○○したい
    • 喝: 「飲む」という動詞
    • 水: そのまま「水」という意味

References

ソフトウェアRAIDの削除方法

Ubuntu Server 24.04等で利用されている新しいインストーラでは、/dev/md*が存在し、
ディスクがRAIDで利用されている場合、RAID無しで設定しようとするとインストール時にコケる。

元々RAID環境で使われていたストレージを利用しようとすると、
元々使っていたRAID環境が復元されるようで、
これを無効化しなければインストールに失敗する。

環境

  • Express5800 T110i
  • RAIDカード無し, AHCIモード
  • Ubuntu Server 24.04.3

手順

画面上のHelpからシェルを開き、下記コマンドでRAIDの設定状況とデバイス名を取得します。

cat /proc/mdstat

RAIDを停止し、RAIDの構成デバイスからスーパーブロックを削除します。
コントローラの仕様によっては、/dev/sda1のようにパーティションがRAIDメンバーになっているかもしれません。

mdadm --stop /dev/md126
mdadm --zero-superblock /dev/sda

昔はパーティションテーブルが残っているとインストールにコケたため、
念のためにディスクのパーティションテーブルあたりを削除しておきます。

dd if=/dev/zero of=/dev/sda bs=512M count=2

最期に再起動をすることで、RAIDブロックに起因するエラーは改善されます。

Debian 12 (x86)にATOK for Linux (atokx2)をインストールする

大昔にジャストシステムから発売されたATOK for Linux (atokx2等とも呼ばれている)をDebian 12にインストールします。

この手順でインストールしたATOKは、少なくとも環境設定が開けないという重大な問題がある。
解決策が見つかり次第、追記する。

トライアンドエラーを繰り返しまくった為、
もしかしたら必要の無い手順が入っているかもしれない。

また、DebianのIIIMFをインストールすれば改善するかもしれないが、
今回は付属のHTTとXIMで動かす。

環境及び検証内容

下記の環境をセットアップしています。
基本的にはDebianのインストーラで最小構成 + System Utilityをインストールした後、
xinitopenboxをインストールした形です。

  • Debian 12.9 i386
  • openbox 3.6.1-10
  • xinit 1.4.0-1
  • 日本語設定
    • LANG=ja_JP.UTF-8
    • XKBMODEL=pc105
    • XKBLAYOUT=jp
    • fonts-noto-cjk

下記のソフトウェアにて日本語入力を検証しました。

  • vim-gtk3 2:9.0.1378-2+deb12u2(成功)
  • xterm 379-1(成功)

既知の問題

現状、下記の問題が起きており、解決方法は不明です。

  • 環境設定等の一部ウィンドウが開かない
    • 開こうとするとXごとフリーズする
    • パレットや変換候補ウィンドウ、辞書ツール等は出る
    • 文字パレットは問題無く出る
    • BasicAux, DicUTAux, PropertyAuxが動かないでよさそう
  • (アップデート後) 上記ウィンドウを開いた後、しばらくするとXがフリーズする
    • 素早く設定してkillall xinitするしかなさそう
    • 検証が甘いので、別の原因がある気もする
  • 入力時に極端に不安定な挙動を取ることがある
    • 日本語入力仕様と思ったらフリーズするような挙動も
    • アプデで改善せず。

公式tgzパッケージの展開

doc/ATOK/readme_for_tar.htmlの通りに、下記のファイルを展開し、/にコピーする。
今回は、GTK2.4を利用する。

/bin/IIIMF/iiimf-client-lib-trunk_r2059-js1.i386.tar.gz
/bin/IIIMF/iiimf-csconv-trunk_r2059-js1.i386.tar.gz
/bin/IIIMF/iiimf-protocol-lib-trunk_r2059-js1.i386.tar.gz
/bin/IIIMF/iiimf-rc-trunk_r2059-js1.i386.tar.gz
/bin/IIIMF/iiimf-server-trunk_r2059-js1.i386.tar.gz
/bin/IIIMF/iiimf-x-trunk_r2059-js1.i386.tar.gz
/bin/IIIMF/iiimf-gtk24-trunk_r2059-js1.i386.tar.gz
/bin/ATOK/atokx-17.0-2.0.i386.tar.gz

アップデートの適用

上記のトラブルの元になる可能性があるため、必要に応じて入れる形を推奨。

公式からATOK for Linux アップデートモジュールをダウンロードし、
tar.gz内の下記のファイルを展開し、/に上書きコピーする。

bin/ATOK/atokx-17.0-2.1.i386.patch.tar.gz
iiimf-gtk24-trunk_r2059-js2.i386.tar.gz

前提パッケージのインストール

aptに存在するパッケージを入れる。

apt install libstdc++5 libgtk2.0-0

libpangox-1.0のインストール

aptに存在しなくなってしまったlibpangoxをインストールする。
Bullseye版のdebファイルをダウンロードするか、
Debian Snapshotから適当なバージョンなりソースをダウンロードする。

Systemdサービスの定義

今回はinitスクリプトは使わず、完全にSystemdから取り扱う。

/etc/systemd/system/atokx2.serviceは下記の通り。

[Unit]
Description=ATOK X2 Daemon
After=network.target

[Service]
ExecStart=/opt/atokx2/sbin/atokx2mngdaemon
Type=forking
Restart=on-failure

[Install]
WantedBy=multi-user.target

/etc/systemd/system/iiim.serviceは下記の通り。
atokx2を前提条件にしている。

[Unit]
Description=iiim (htt)

After=network.target atokx2.service
Wants=network.target atokx2.service

[Service]
ExecStart=/usr/lib/im/htt
Type=simple
Restart=on-failure

[Install]
WantedBy=multi-user.target

最期に自動起動を有効にし、同時に初回起動もしてしまう。

systemctl daemon-reload
systemctl enable --now atokx2 iiim

xinitrcを書く

~/.xinitrcに下記の内容を記述する。

#!/bin/bash
export XMODIFIERS=@im=htt
export XIM="htt"

export XIM_PROGRAM=/bin/true

export GTK_IM_MODULE=xim
export QT_IM_MODULE=xim

. /opt/atokx2/bin/atokx2_client.sh

exec /etc/X11/xinit/xinitrc

これで次にstartxした際にATOKが立ち上がる。

Debian 12 (x86)にATOK X for Linuxをインストールする

大昔にジャストシステムから発売されたATOK X for LinuxをDebian 12にインストールします。

この手順でインストールしたATOK Xは極めて不安定かつ、低速で、
変換ウィンドウやメニューすら表示されない有様ですが、
ある程度の動作確認は取れた為、現在の知識で出来る最善を記録する目的で記事にします。

トライアンドエラーを繰り返しまくった為、
もしかしたら必要の無い手順が入っているかもしれない。

また、DebianのIIIMFをインストールすれば改善するかもしれないが、
今回は付属のHTTとXIMで動かす。

環境及び検証内容

下記の環境をセットアップしています。
基本的にはDebianのインストーラで最小構成 + System Utilityをインストールした後、
xinitopenboxをインストールした形です。

  • Debian 12.9 i386
  • openbox 3.6.1-10
  • xinit 1.4.0-1
  • 日本語設定
    • LANG=ja_JP.UTF-8
    • XKBMODEL=pc105
    • XKBLAYOUT=jp
    • fonts-noto-cjk

下記のソフトウェアにて日本語入力を検証しました。

  • vim-gtk3 2:9.0.1378-2+deb12u2(成功)
  • xterm 379-1(成功)
  • kwrite(失敗, 反応せず)
  • kate(失敗, 反応せず)

既知の問題

現状、下記の問題が起きており、解決方法は不明です。

  • IMEのオンオフ切り替えが極めて遅い
    • gvim等はつられてInsertモードへの切り替えなども遅くなる
  • 変換の切り替えが遅くなる
    • 候補の二つ目くらいまでは軽量に動くが、それ以降を呼ぼうとするとかなり遅くなる
  • 変換候補ウィンドウやATOKパレットなどが表示されない
    • 入力文字種表示のみが出てくる状態
  • X全体がフリーズして操作を受け付けなくなる場合がある
    • X全体ではなくアプリケーション単位でhtt (XIM)を読ませると影響を小さく出来る
  • AtokPaletteAux, SystemLineAux, LookupAuxが継続的にセグフォする
    • segfault at 35 ip ... sp ... error 4 in libglib-1.2.so.0.0.10[...]らしい
    • 読み込ませるlibglibを書き直したら直りそうだけど、さすがに知識が足りなさすぎる

公式tgzパッケージの展開

適当なディレクトリに、CD内のatokx-1.0-1.i386.tgziiimf.tgzをコピーし、
tar xf filename.tgzで展開する。

その後、cp -R ./{etc,usr,var} /でシステムにインストールする。

init.d/functionsのインストール

CentOSのinitscriptsのソースパッケージに含まれている、rc.d/init.d/functions/etc/rc.d/init.d/functionsに保存する。

今回は、initscripts-9.03.31-2.el6.centos.src.rpmから展開した。
Wayback Machineのリンク

consoletypeのビルド

Gentooプロジェクトのgentoo-functionsから、consoletype.cをもらってくる。
コンパイルはただgcc consoletype.cすればよい。

先のinitscriptsにあるconsoletype.cをビルドしても良さそうであるが、こちらは未検証。

コンパイルしたファイルは、/sbin/consoletypeに設置する。

libxtのインストール

普通にaptで入る。
一応libc6libx11も明示的に入れておくが、
多分最初から入っていると思う。

apt install libc6 libx11-6 libxt-dev

atokx及びIIimサービスのSystemdへの登録と実行

本来はinit.dファイルをSystemd向けに書き直すべきであろうが、
めんどくさいので、そのままSystemdから呼び出す形にする。

まず、/usr/lib/systemd/system/atokx.serviceは下記のようになる。
IIimの後に起動するようにしているが、特に要らない気もする。

[Unit]
Description=ATOK X Server
After=IIim.service

[Service]
Type=forking
ExecStart=/etc/rc.d/init.d/atokx start
ExecStop=/etc/rc.d/init.d/atokx stop

[Install]
WantedBy=default.target

/usr/lib/systemd/system/IIim.serviceは下記の通り。
こちらはsimpleで直接実行した方がエラー時の復旧的にもよいと思う。

[Unit]
Description=IIim

[Service]
Type=forking
ExecStart=/etc/rc.d/init.d/IIim start
ExecStop=/etc/rc.d/init.d/IIim stop

[Install]
WantedBy=default.target

2つとも設置できたら、下記のコマンドで起動してしまう。

systemctl daemon-reload
systemctl enable --now atokx IIim

xrdbの配置

aptでx11-xserver-utilsをインストールした後、
下記のコマンドで/usr/X11R6/binの中にxrdbのシンボリックリンクを置く。

mkdir -p /usr/X11R6/bin
ln -s /usr/bin/xrdb /usr/X11R6/bin/xrdb

GTK1.2のインストール

aptにはもう存在しないため、
GNOMEプロジェクトからglib-1.2.10.tar.gzgtk+-1.2.10.tar.gzをダウンロードしてくる。

glibのインストール

ダウンロードしてきたglibのパッケージを展開し、
gstrfuncs.cを修正する。

おそらくこの修正は間違ったアプローチであるが、
現状これしか解決策が思い浮かばないので、
そのまま編集してしまう。

下記にpatchファイルを貼る。
適当にファイルに保存し、
patch < saved-patch-file.patchすれば適用されるはず。

--- gstrfuncs.c    2025-09-08 20:32:11.237763156 +0900
+++ gstrfuncs.c.patched 2025-09-08 16:31:52.089892394 +0900
@@ -867,8 +867,8 @@
                   /* beware of positional parameters
                    */
                 case '$':
-                  g_warning (G_GNUC_PRETTY_FUNCTION
-                             "(): unable to handle positional parameters (%%n$)");
+                  g_warning (G_GNUC_PRETTY_FUNCTION);
+                             /* "(): unable to handle positional parameters (%%n$)"); */
                   len += 1024; /* try adding some safety padding */
                   break;

@@ -1034,8 +1034,8 @@
                   /*          n   .   dddddddddddddddddddddddd   E   +-  eeee */
                   conv_len += 1 + 1 + MAX (24, spec.precision) + 1 + 1 + 4;
                   if (spec.mod_extra_long)
-                    g_warning (G_GNUC_PRETTY_FUNCTION
-                               "(): unable to handle long double, collecting double only");
+                    g_warning (G_GNUC_PRETTY_FUNCTION);
+                               /* "(): unable to handle long double, collecting double only"); */
 #ifdef HAVE_LONG_DOUBLE
 #error need to implement special handling for long double
 #endif
@@ -1077,8 +1077,8 @@
                   conv_done = TRUE;
                   if (spec.mod_long)
                     {
-                      g_warning (G_GNUC_PRETTY_FUNCTION
-                                 "(): unable to handle wide char strings");
+                      g_warning (G_GNUC_PRETTY_FUNCTION);
+                                 /* "(): unable to handle wide char strings"); */
                       len += 1024; /* try adding some safety padding */
                     }
                   break;
@@ -1108,9 +1108,9 @@
                   conv_len += format - spec_start;
                   break;
                 default:
-                  g_warning (G_GNUC_PRETTY_FUNCTION
-                             "(): unable to handle `%c' while parsing format",
-                             c);
+                  g_warning (G_GNUC_PRETTY_FUNCTION);
+                             /* "(): unable to handle `%c' while parsing format",
+                             c); */
                   break;
                 }
               conv_done |= conv_len > 0;

パッチの適用が終わったら、Configureとmake、make installを行う。
今回はインストール先を変更したいため、prefixを設定する。
また、コンパイルエラーをなくすために、いくつかのむちゃくちゃなオプションも指定する。

CFLAGS='-fcommon -D__const__=__volatile__' ./configure --prefix=/usr/local/gtk-1.2
make
make install

もしシステム全体にインストールしたい場合は、
prefixを明示的に/にする。
設定したprefixgtk+のインストールでも同じ値を設定する。

gtk+のインストール

こちらも展開し、下記のコマンドでconfigureとmake、make installを行う。
パッチの適用は特に必要無い。

LD_LIBRARY_PATH=/usr/local/gtk-1.2/lib:$LD_LIBRARY_PATH GLIB_CONFIG=/usr/local/gtk-1.2/bin/glib-config CFLAGS='-fcommon' ./configure --prefix=/usr/local/gtk-1.2
make
make install

もし、先ほどのセクションでシステム全体にglibをインストールした場合は、configureコマンドを下記の要に変更する。

CFLAGS='-fcommon' ./configure --prefix=/

EUC-JPのロケール生成

/etc/locale.genja_JP.EUC-JPの行をコメントを外し、
locale-genコマンドを実行して適用する。

システム全体のロケールを変更する必要は、
Fefora Core 1がUTF-8であることを考えるとなさそう。

libXi.soのインストール

aptでlibxi-devをインストールする。

Fedora Core 1向けのインストール手順を踏襲する為の手順のため、
もしかしたら飛ばせるかもしれない。

飛ばす場合は、atokx_clientスクリプトのLD_PRELOADも設定しないように。

atokx_clientスクリプトの編集

/usr/lib/im/locale/ja/atokserver/atokx_clientを編集する。

/usr/lib/im/httx -if atok12 -lc_basiclocale ja_JP -xim htt_xbe &

と書いてある行を、下記のように変更する。
LD_LIBRARY_PATHはGTK1.2をシステム全体に入れた場合は要らない。

LD_PRELOAD=/usr/lib/i386-linux-gnu/libXi.so LD_LIBRARY_PATH=/usr/local/gtk-1.2/lib:$LD_LIBRARY_PATH LANG=ja_JP.eucJP /usr/lib/im/httx -if atok12 -lc_basiclocale ja_JP -xim htt_xbe &

自動起動スクリプトを書く

httxがそれなりの頻度で落ちるため、
自動で再起動するスクリプトを用意する。

本資料では、これを~/.htt_helper.shに置く。
chmod +xを忘れないように。

#!/bin/bash

while true; do
    htt_proc=`ps x | grep "/usr/lib/im/httx" | wc -l`

    if [ $htt_proc -lt 2 ]; then
        logger -is -p user.info -t htt_helper "httx might crashed or not booted. Restarting."
        . /usr/lib/im/locale/ja/atokserver/atokx_client
    fi
done

xinitrcを書く

~/.xinitrcに下記の内容を記述する。

上記の自動再起動スクリプトを使わない場合は、~/.htt_helper.shの行をコメントアウトし、
1行上にある純正のローダを呼び出す行のコメントを外す。

#!/bin/bash
export XMODIFIERS=@im=htt
export XIM="htt"

export XIM_PROGRAM=/bin/true

export GTK_IM_MODULE=xim
export QT_IM_MODULE=xim

#. /usr/lib/im/locale/ja/atokserver/atokx_client
~/.htt_helper.sh &

exec /etc/X11/xinit/xinitrc

参考資料