@znz blog

外部ドライブなしでTime Machineバックアップを設定する

Sun, 15 Feb 2026 14:00:00 +0000

macOS の Time Machine バックアップはネットワークストレージだとバックアップも復元も遅いという問題があったり、外部ドライブ (USB HDD) だと接続が切れることがあるので MacBook Pro を物理的に動かしにくくなったりする問題があったりして、他の手段を検討した結果、ローカルに sparse bundle を作成して使う方法があるとわかったので、設定してみました。

確認環境

MacBook Pro 14 インチ, 11月 2024
macOS Tahoe 26.3

sparse bundle 作成

Time Machine With Wasabi via a Mountable Drive and Rclone や Time Machine With Wasabi via Cyberduck を参考にしました。

まず容量と暗号化するかどうか決めて以下のように作成します。暗号化する場合の違いは後で説明します。

hdiutil create -size 500g -type SPARSEBUNDLE -fs HFS+J -volname "TimeMachineDisk" ~/TimeMachineDisk.sparsebundle 

-size 500g はマウント後の df -h で確認すると 500Gi になっています。(2026-02-22 追記: 500g は大きすぎたので sudo du -shc /Volumes/TimeMachineDisk/Backups.backupdb/knmbp24/Latest/Data/* | sort -h でバックアップ対象が 40G ぐらいなのを確認して 100g にして様子をみています。)
-type SPARSEBUNDLE は sparse bundle を明示していますが、拡張子があれば省略可能と hdiutil の manpage に書いてありました。
-fs HFS+J は hdiutil の manpage をみてもはっきりとした説明はなかったのですが、ジャーナリングの HFS+ だと思います。
-volname は /Volumes の中に出てくるディレクトリ名になったり、Finder で見える名前になったりしていました。

バックアップ設定

フルディスクアクセス権限が必要な操作があったはずなので、普段使いの端末ソフトに権限をつけたくないなら、他の端末ソフトを用意するなどの準備が必要です。

以下のようにバックアップ設定します。

tmutil addexclusion ~/TimeMachineDisk.sparsebundle hdiutil attach ~/TimeMachineDisk.sparsebundle sudo tmutil setdestination /Volumes/TimeMachineDisk tmutil destinationinfo 

/Volumes/TimeMachineDisk は自動で Time Machine バックアップから除外されますが、 TimeMachineDisk.sparsebundle 自体は除外されなさそうなので、 tmutil addexclusion で明示的に除外属性をつけておきます。

hdiutil attach でマウントした後、 sudo tmutil setdestination で Time Machine バックアップ先に設定します。 (追加する場合は tmutil setdestination -a です。)

最後に tmutil destinationinfo で確認しています。

バックアップ作成

GUI からスタートするか、コマンドで以下のような感じでバックアップ開始します。

tmutil startbackup --auto --block

バックアップ設定削除

Time Machine の設定で確認すると暗号化されていなかったので、一度削除して作りなおしました。

Time Machine のバックアップ先からは tmutil removedestination でも削除できますが、GUI から削除しました。

eject して sparse bundle も削除すれば元通りです。

hdiutil eject /Volumes/TimeMachineDisk rm -rf ~/TimeMachineDisk.sparsebundle

暗号化ありで sparse bundle 作成

まず、 Mac で Google Drive 等への暗号化バックアップを行う方法 - WebOS Goodies を参考にして暗号化用の証明書を作成しました。

まず、「キーチェーンアクセス」アプリを開きます。「パスワード」アプリとの選択肢が出てきても「キーチェーンアクセス」を開きます。メニューの「キーチェーンアクセス」の「証明書アシスタント」の「証明書を作成…」で

名前: CloudBackup
固有名のタイプ: 自己署名ルートのまま
証明書のタイプ: S/MIME のまま

で証明書を作成しました。

作成された証明書は「デフォルトキーチェーン」の「iCloud」ではなく「ログイン」の方に入っているので、「種類」が「証明書」の行をデスクトップにドラッグアンドドロップで保存します。

以下のように保存した証明書を -certificate に指定して sparse bundle を作成します。

hdiutil create -size 500g -type SPARSEBUNDLE -fs HFS+J -volname "TimeMachineDisk" -encryption AES-256 -certificate ~/Desktop/CloudBackup.cer ~/TimeMachineDisk.sparsebundle 

hdiutil の manpage によると -encryption は AES-128 か AES-256 しか指定できないので、 AES-256 にしておけば良さそうです。

証明書のバックアップ

「種類」が「証明書」の行を右クリックなどでコンテキストメニューを開いて、「”CloudBackup”を書き出す…」から「個人情報交換(.p12)」で保存します。名前は「CloudBackup」にして「CloudBackup.p12」として保存しました。そのとき、秘密鍵を保護するパスワードとその確認、キーチェーンのパスワード(ログインパスワード) を要求されました。

sparse bundle のマウントに必要になるので、「CloudBackup.p12」は別途安全な場所に保管しておきます。

旧 MacBook Pro がまだあるので、そちらに CloudBackup.p12 も持っていって sparse bundle が開けることを確認しています。 (秘密鍵の行から書き出したファイルを持っていっても sparse bundle を開けませんでした。)

再確認できていませんが、インポートはキーチェーンアクセスへのドロップではできなくて、p12 ファイルを開いて読み込みした気がします。

バックアップ設定

暗号化なしと同様にバックアップ設定します。 hdiutil attach でキーチェーンのパスワード (ログインパスワード) を要求されました。

tmutil addexclusion ~/TimeMachineDisk.sparsebundle hdiutil attach ~/TimeMachineDisk.sparsebundle sudo tmutil setdestination /Volumes/TimeMachineDisk tmutil destinationinfo 

Time Machine の設定で「空き 536.08 GB、暗号化」となっていて「暗号化」がついているのが確認できました。

除外設定

以下のように tmutil addexclusion で追加するか、 GUI で Time Machine 設定のオプションから除外設定を追加します。

tmutil addexclusion ~/.colima tmutil addexclusion ~/.config/colima tmutil addexclusion ~/.lima tmutil addexclusion ~/.pcloud 

tmutil addexclusion は拡張属性の設定なので、 GUI の設定と同期していませんが、 tmutil addexclusion -p が GUI の設定と同期しているようなので、フルディスクアクセス権限があれば -p ありの方が便利そうです。

他には Biscuitの環境を他のパソコンに移す方法で Chromium ベースのアプリ全般で cache とつくディレクトリは消しても大丈夫そうかなと思ったので、以下のように除外設定を追加しています。 (以下にない他の Chromium ベースのアプリも含めて設定しています。)

find ~/Library/Application\ Support/biscuit -iname '*cache*' -print0 -prune | xargs -0 --verbose tmutil addexclusion find ~/Library/Application\ Support/Google -iname '*cache*' -print0 -prune | xargs -0 --verbose tmutil addexclusion 

他にも du -sh .??* * | sort -h などでみつけた容量の大きいバックアップが不要そうなものは除外しました。

sparse bundle のバックアップ

マウント確認のために rsync で旧 MacBook Pro に転送してみたり、 pCloud Drive に入れて戻して実行パーミッションなどが消えても大丈夫か試してみたりしました。

大丈夫そうなので、今後は rclone か何かで定期的にバックアップするようにしようと思っています。

まとめ

ローカルのみで Time Machine バックアップを有効にできることが確認できました。

外部へバックアップしなくても、Time Machine バックアップをブラウズで履歴が見えるようになるだけでも便利そうなので、外部ディスクやクラウドストレージを用意できない環境でも試してみる価値がありそうだと思いました。

headscale+tailscaleに移行中

Sat, 14 Feb 2026 14:00:00 +0000

LILO&東海道らぐオフラインミーティング 2026-02-01 で発表したのですが、 VPN 環境を Headscale + Tailscale に移行しました。

動作確認環境

Headscale 0.27.1 から 0.28.0

イベントでの発表時点では 0.27.1 でしたが、その後 0.28.0 に上げたら状況が変わっていました。

発表資料

スライドはいつも通り Rabbit Slide Show (RubyGems), SlideShare, Speaker Deck にあげています。(ソースは github にあげています。)

Headscale + Tailscale に移行中

ユーザーとタグの扱い

0.28.0 に上げると、タグを設定しているノードは tagged-devices ユーザーに移動してしまいました。

発表中には口頭でユーザーを移動できるので、所有ユーザーは適当に設定していたと話しましたが、 https://github.com/juanfont/headscale/pull/2922 でユーザーを変える機能は消えていました。

すべてのノードに user:sakura なら tag:sakura などのようにユーザー名と同じタグもつけていたので、 ACL に大きな影響はありませんでした。

しかし、ユーザーの端末にはタグをつけないことを想定しているようで、 tag:zabbix-agent と併用できなくなってしまうので、そのあたりの ACL 設定を含めてどう移行しようか、まだ悩み中です。

まとめ

LILO&東海道らぐのイベントで発表した内容とその後の状況を紹介しました。

影響がなければ発表内容をまとめなおして記事にする予定だったのですが、状況が変わっていたので、その部分の追加の話になってしまいました。

OpenLDAPのバックエンドをhdbからmdbへ移行した

Wed, 31 Dec 2025 09:36:00 +0000

VPS で動かしている Ubuntu や Debian のバージョンアップのブロッカーになっていた OpenLDAP (slapd) のバックエンドデータベースをやっと hdb から mdb に移行しました。

対象環境

Ubuntu 20.04.6 LTS (focal)
- slapd 2.4.49+dfsg-2ubuntu1.10
Debian GNU/Linux 11 (bullseye)
- slapd 2.4.57+dfsg-3+deb11u1

移行手順の概要

まず slapcat で LDAP データベースのバックアップをとって、 hdb のデータベースは削除します。

そして https://github.com/DSI-Universite-Rennes2/openldap-migrate-backend を参考にして、 /etc/ldap/slapd.d/ の # AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify. と書いてあるファイルの内容を直接書き換えて、 CRC32 がずれるのは https://gogs.zionetrix.net/bn8/check_slapdd_crc32 で修正します。

slapadd で mdb としてデータベースを復元して動作確認ができれば終了です。

バックアップ

まず slapcat を使って適当なファイル名でバックアップをとっておきます。

0 は cn=config なので、 /etc/ldap/slapd.d を直接バックアップした方が良さそうです。 etckeeper を使っているので、そこのバックアップはしていません。

1 がメインのデータベースなので、後で使います。

2 は accesslog で使う設定にしていますが、設定がちゃんとできていなかったらしく、トップレベルの dn: cn=accesslog だけで他に何もデータが入っていませんでした。

普通は 1 だけとっておけばいいと思います。

sudo slapcat -n 0 -l slapcat.0.$(date -I).ldif sudo slapcat -n 1 -l slapcat.1.$(date -I).ldif sudo slapcat -n 2 -l slapcat.2.$(date -I).ldif sudo chmod 640 slapcat.*.ldif 

移行対象を停止

syncrepl で 2 台体制で動かしているので、1台止めて移行します。

止めても getent passwd などがちゃんと動くのを確認しておきます。

sudo systemctl stop slapd.service getent passwd

olcDbDirectory

olcDbDirectory を確認して削除して空ディレクトリを作りなおしておきます。 sudo slapadd で root 所有のファイルができるので、後でまとめて chown するので、空ディレクトリは root 所有のままにしました。

ディレクトリがないと sudo slaptest -u -F /etc/ldap/slapd.d でエラーになります。

空ディレクトリの作成は普通は sudo mkdir -p /var/lib/ldap でいいと思います。

$ cd /etc/ldap $ sudo grep -r olcDbDirectory slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcDbDirectory: /var/lib/ldap slapd.d/cn=config/olcDatabase={2}hdb.ldif:olcDbDirectory: /var/lib/ldap/accesslog $ ls -al /var/lib/ldap/ 合計 11212 drwxr-xr-x 3 openldap openldap 4096 12月 31 18:06 . drwxr-xr-x 56 root root 4096 11月 20 2024 .. -rw-r--r-- 1 openldap openldap 96 8月 2 2014 DB_CONFIG -rw------- 1 openldap openldap 532479 12月 31 18:06 __db.001 -rw------- 1 openldap openldap 139263 12月 31 18:06 __db.002 -rw------- 1 openldap openldap 286719 12月 31 18:06 __db.003 drwxr-xr-x 2 openldap openldap 4096 12月 31 18:06 accesslog -rw-r--r-- 1 openldap openldap 4096 12月 31 18:06 alock -rw------- 1 openldap openldap 28672 3月 21 2016 cn.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 displayName.bdb -rw------- 1 openldap openldap 24576 3月 21 2016 dn2id.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 entryCSN.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 entryUUID.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 gidNumber.bdb -rw------- 1 openldap openldap 16384 3月 21 2016 givenName.bdb -rw------- 1 openldap openldap 81920 3月 21 2016 id2entry.bdb -rw------- 1 openldap openldap 10485759 12月 31 17:59 log.0000000001 -rw------- 1 openldap openldap 8192 3月 21 2016 loginShell.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 member.bdb -rw------- 1 openldap openldap 16384 3月 21 2016 memberUid.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 objectClass.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 ou.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 sambaDomainName.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 sambaGroupType.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 sambaPrimaryGroupSID.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 sambaSID.bdb -rw------- 1 openldap openldap 16384 3月 21 2016 sn.bdb -rw------- 1 openldap openldap 16384 3月 21 2016 uid.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 uidNumber.bdb $ ls -al /var/lib/ldap/accesslog/ 合計 10828 drwxr-xr-x 2 openldap openldap 4096 12月 31 18:06 . drwxr-xr-x 3 openldap openldap 4096 12月 31 18:06 .. -rw-r--r-- 1 openldap openldap 96 8月 2 2014 DB_CONFIG -rw------- 1 openldap openldap 532479 12月 31 18:06 __db.001 -rw------- 1 openldap openldap 139263 12月 31 18:06 __db.002 -rw------- 1 openldap openldap 114687 12月 31 18:06 __db.003 -rw-r--r-- 1 openldap openldap 4096 12月 31 18:06 alock -rw------- 1 openldap openldap 8192 3月 21 2016 dn2id.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 entryCSN.bdb -rw------- 1 openldap openldap 32768 3月 21 2016 id2entry.bdb -rw------- 1 openldap openldap 10485759 12月 31 17:59 log.0000000001 -rw------- 1 openldap openldap 8192 3月 21 2016 objectClass.bdb -rw------- 1 openldap openldap 8192 3月 21 2016 reqStart.bdb $ sudo rm -rf /var/lib/ldap/ $ sudo mkdir -p /var/lib/ldap/accesslog 

`check_slapdd_crc32` を用意

CRC32 修正用のコマンドを用意しておきます。

$ git clone https://gogs.zionetrix.net/bn8/check_slapdd_crc32 Cloning into 'check_slapdd_crc32'... warning: redirecting to https://gitea.zionetrix.net/bn8/check_slapdd_crc32/ remote: Enumerating objects: 61, done. remote: Counting objects: 100% (61/61), done. remote: Compressing objects: 100% (51/51), done. remote: Total 61 (delta 22), reused 0 (delta 0), pack-reused 0 Receiving objects: 100% (61/61), 12.16 KiB | 47.00 KiB/s, done. Resolving deltas: 100% (22/22), done. 

書き換え

https://github.com/DSI-Universite-Rennes2/openldap-migrate-backend の手順を参考にして手で書き換えました。シェルスクリプトの内容を確認して、直接実行でも良いと思います。

$ sudo grep -ri hdb slapd.d/cn=config/olcDatabase={1}hdb.ldif:dn: olcDatabase={1}hdb slapd.d/cn=config/olcDatabase={1}hdb.ldif:objectClass: olcHdbConfig slapd.d/cn=config/olcDatabase={1}hdb.ldif:olcDatabase: {1}hdb slapd.d/cn=config/olcDatabase={1}hdb.ldif:structuralObjectClass: olcHdbConfig slapd.d/cn=config/cn=module{0}.ldif:olcModuleLoad: {0}back_hdb slapd.d/cn=config/olcBackend={0}hdb.ldif:dn: olcBackend={0}hdb slapd.d/cn=config/olcBackend={0}hdb.ldif:olcBackend: {0}hdb slapd.d/cn=config/olcDatabase={2}hdb.ldif:dn: olcDatabase={2}hdb slapd.d/cn=config/olcDatabase={2}hdb.ldif:objectClass: olcHdbConfig slapd.d/cn=config/olcDatabase={2}hdb.ldif:olcDatabase: {2}hdb slapd.d/cn=config/olcDatabase={2}hdb.ldif:structuralObjectClass: olcHdbConfig $ sudo mv -vi slapd.d/cn\=config/olcBackend\=\{0\}hdb.ldif slapd.d/cn\=config/olcBackend\=\{0\}mdb.ldif renamed 'slapd.d/cn=config/olcBackend={0}hdb.ldif' -> 'slapd.d/cn=config/olcBackend={0}mdb.ldif' $ sudo mv -vi slapd.d/cn\=config/olcDatabase\=\{1\}hdb.ldif slapd.d/cn\=config/olcDatabase\=\{1\}mdb.ldif renamed 'slapd.d/cn=config/olcDatabase={1}hdb.ldif' -> 'slapd.d/cn=config/olcDatabase={1}mdb.ldif' $ sudo mv -vi slapd.d/cn\=config/olcDatabase\=\{2\}hdb.ldif slapd.d/cn\=config/olcDatabase\=\{2\}mdb.ldif renamed 'slapd.d/cn=config/olcDatabase={2}hdb.ldif' -> 'slapd.d/cn=config/olcDatabase={2}mdb.ldif' $ sudo mv -vi slapd.d/cn\=config/olcDatabase\=\{1\}hdb slapd.d/cn\=config/olcDatabase\=\{1\}mdb renamed 'slapd.d/cn=config/olcDatabase={1}hdb' -> 'slapd.d/cn=config/olcDatabase={1}mdb' $ sudo mv -vi slapd.d/cn\=config/olcDatabase\=\{2\}hdb slapd.d/cn\=config/olcDatabase\=\{2\}mdb renamed 'slapd.d/cn=config/olcDatabase={2}hdb' -> 'slapd.d/cn=config/olcDatabase={2}mdb' $ sudo sed -i 's/back_hdb/back_mdb/' slapd.d/cn=config/cn\=module\{0\}.ldif $ sudo sed -i 's/hdb/mdb/' slapd.d/cn\=config/olcBackend\=\{0\}mdb.ldif slapd.d/cn\=config/olcDatabase\=\{1\}mdb.ldif slapd.d/cn\=config/olcDatabase\=\{2\}mdb.ldif $ sudo sed -i 's/Hdb/Mdb/' slapd.d/cn\=config/olcDatabase\=\{1\}mdb.ldif slapd.d/cn\=config/olcDatabase\=\{2\}mdb.ldif $ for attr in olcDbCacheFree olcDbCacheSize olcDbChecksum olcDbConfig olcDbCryptFile olcDbCryptKey olcDbDNcacheSize olcDbDirtyRead olcDbIDLcacheSize olcDbLinearIndex olcDbLockDetect olcDbPageSize olcDbShmKey; do sudo sed -i "/^$attr:/d" slapd.d/cn\=config/olcDatabase\=\{1\}mdb.ldif; done $ sudo sed -i '/^olcAccess: {0}/i olcDbMaxSize: 1000000000' slapd.d/cn\=config/olcDatabase\=\{1\}mdb.ldif $ sudo ~/check_slapdd_crc32/check_slapdd_crc32 --fix 2025-12-31 18:11:21,901 - check_slapdd_crc32 - WARNING - /etc/ldap/slapd.d/cn=config/olcDatabase={0}config.ldif: no CRC32 value found. Correct CRC32 value is "47dba06d". 2025-12-31 18:11:21,902 - check_slapdd_crc32 - WARNING - /etc/ldap/slapd.d/cn=config/olcBackend={0}mdb.ldif: invalid CRC32 value found (f6ccc16c != 1918d801) 2025-12-31 18:11:21,902 - check_slapdd_crc32 - WARNING - /etc/ldap/slapd.d/cn=config/cn=module{0}.ldif: invalid CRC32 value found (bc225411 != f86810e2) 2025-12-31 18:11:21,902 - check_slapdd_crc32 - WARNING - /etc/ldap/slapd.d/cn=config/olcDatabase={1}mdb.ldif: invalid CRC32 value found (4b81209f != 7623f07e) 2025-12-31 18:11:21,903 - check_slapdd_crc32 - WARNING - /etc/ldap/slapd.d/cn=config/olcDatabase={2}mdb.ldif: invalid CRC32 value found (09c73f52 != 6c208dd4) $ sudo slaptest -u -F /etc/ldap/slapd.d config file testing succeeded $ sudo slapschema -F /etc/ldap/slapd.d -b 'cn=config' $ 

DB 移行

mdb にバックアップしておいたデータベースを取り込んで、ファイルのオーナーなどを修正します。

$ sudo slapadd -n 1 -l ~/slapcat.1.2025-12-31.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... $ sudo slapadd -n 2 -l ~/slapcat.2.2025-12-31.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... $ sudo chown -R openldap:openldap /var/lib/ldap $ 

作業対象サーバーの入れ替え

同時に起動すると syncrepl で問題が起きそうなので、残っていた1台を sudo systemctl stop slapd.service で止めて、一瞬 LDAP サーバーがなくなった状態になった後、移行した方を sudo systemctl start slapd.service で起動しました。

getent passwd などで問題がないことを確認して、次のサーバーも同様に作業しました。

もう1台も移行

もう1台の方も sudo systemctl start slapd.service で起動して、 syncrepl などの状態を確認できたら移行完了です。

最後に

以前に移行作業しようとしたときは、全然具体的な情報がなくて諦めていましたが、さすがに Debian で hdb 対応が消えた bookworm が oldstable になっていたり、 Ubuntu でも hdb が消えた jammy (22.04) の次の LTS の noble (24.04) が出ていたりするので、具体的な移行方法もみつけられました。

focal も bullseye もまだ完全な EOL ではないものの、いろんなツールなどの対応が終わってきているので、 slapd の hdb が原因でまだ上げられていない人がいれば参考にしてみてください。

Dokkuを動かしているUbuntuを20.04から22.04に更新した

Sat, 27 Dec 2025 05:36:00 +0000

年末で時間がとれるようになったので、 Dokku を動かしている VPS のサーバーを Ubuntu 20.04 (focal) から Ubuntu 22.04 (jammy) に更新しました。

データベースなどのバックアップ

まず、いつもの dokku postgres:export でデータベースのバックアップをとったり、その他のバックアップをとりました。

do-release-upgrade

https://wiki.ubuntu.com/JammyJellyfish/ReleaseNotes/Ja を参照して大きな影響がなさそうなのを確認した後、 sudo do-release-upgrade で更新しました。

etc のファイル確認

前回の do-release-upgrade のときから残っているファイルが混ざっているかもしれませんが、 /etc で git clean -ndx を実行して、 etckeeper で無視されている *.dpkg-* や *.ucf-* などを確認しました。

`sshd_config`

追加変更していた設定は /etc/ssh/sshd_config.d に分割しまし。

50unattended-upgrades

3項目だけ変更して 50unattended-upgrades.ucf-dist をマージしました。

Unattended-Upgrade::Mail "root"; Unattended-Upgrade::Remove-Unused-Dependencies "true"; Unattended-Upgrade::Automatic-Reboot "true"; 

zabbix-agent2

https://www.zabbix.com/download?zabbix=7.4&os_distribution=ubuntu&os_version=22.04&components=agent_2&db=&ws= から zabbix-release_latest_7.4+ubuntu22.04_all.deb を入れて、 zabbix-agent2 を更新しました。

sudo apt update で

N: Skipping acquire of configured file 'main/binary-i386/Packages' as repository 'https://repo.zabbix.com/zabbix/7.4/stable/ubuntu jammy InRelease' doesn't support architecture 'i386' 

というメッセージが出るので、 /etc/apt/sources.list.d/zabbix.list の deb の行に [arch=amd64] を追加しました。

dokku と docker

Dokku は https://dokku.com/docs/getting-started/installation/ から bootstrap.sh をダウンロードして参照して apt の設定を更新しました。

wget -qO- https://packagecloud.io/dokku/dokku/gpgkey | sudo tee /etc/apt/trusted.gpg.d/dokku.asc 

で gpg 鍵を更新して `/etc/apt/sources.list.d/dokku.list は

deb https://packagecloud.io/dokku/dokku/ubuntu jammy main

にしました。

/etc/apt/sources.list.d/dokku.list.* や /etc/apt/sources.list.d/download_docker_com_linux_ubuntu.list* は削除しました。

https://get.docker.com/ をダウンロードして参照して apt の設定を更新しました。

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu jammy stable" | sudo tee /etc/apt/sources.list.d/docker.list 

sudo apt full-upgrade -V で更新対象を事前確認しました。

The following packages will be upgraded: containerd.io (1.7.27-1 => 2.2.1-1~ubuntu.22.04~jammy) docker-buildx-plugin (0.23.0-1~ubuntu.20.04~focal => 0.30.1-1~ubuntu.22.04~jammy) docker-ce (5:28.1.1-1~ubuntu.20.04~focal => 5:29.1.3-1~ubuntu.22.04~jammy) docker-ce-cli (5:28.1.1-1~ubuntu.20.04~focal => 5:29.1.3-1~ubuntu.22.04~jammy) docker-ce-rootless-extras (5:28.1.1-1~ubuntu.20.04~focal => 5:29.1.3-1~ubuntu.22.04~jammy) docker-compose-plugin (2.35.1-1~ubuntu.20.04~focal => 5.0.0-1~ubuntu.22.04~jammy) docker-container-healthchecker (0.14.0 => 0.14.1) docker-image-labeler (0.8.1 => 0.9.0) dokku (0.35.20 => 0.37.3) dokku-event-listener (0.17.2 => 0.18.0) dokku-update (0.9.6 => 0.9.7) gliderlabs-sigil (0.11.4 => 0.11.5) herokuish (0.11.3 => 0.11.8) lambda-builder (0.9.1 => 0.9.2) netrc (0.10.2 => 0.10.3) plugn (0.16.0 => 0.16.1) procfile-util (0.20.3 => 0.20.4) sshcommand (0.20.0 => 0.20.1) 18 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 

https://dokku.com/docs/appendices/0.36.0-migration-guide/ と https://dokku.com/docs/appendices/0.37.0-migration-guide/ を確認して、

sudo dokku-update run -s

で更新しました。

0.36.0 で Ubuntu 20.04 がサポート対象外になっていたようです。

その他のファイル

ca-certificates.conf.dpkg-old や cron.daily/bsdmainutils.dpkg-remove は単純に削除しました。他のファイルも変更をマージして削除しました。

まとめ

Dokku のドキュメントには OS の更新についての記述がないので、大丈夫なのかわからず、なかなか上げられずにいましたが、 Dokku 専用環境だからか OS 更新でひっかかるようなものはなくて、すんなり更新できました。

しばらく様子をみて、問題なさそうなら早めに 24.04 まで上げてしまうと良さそうだと思いました。

systemdのtimerの時間が重なって想定外の挙動になっていた

Sun, 30 Nov 2025 14:10:00 +0000

概要としては systemd timer でデータベースのバックアップをしていて、ディレクトリの中身のサイズの単調増加でバックアップ成功を確認していたら、古いファイルの削除は systemd-tmpfiles に任せていたのとタイミングが重なって、サイズの単調増加チェックが失敗するようになった、という話です。

バックアップ設定

バックアップ先は /srv/postgres-export というディレクトリにしています。

バックアップ用スクリプトとして /srv/postgres-export.sh に以下の内容を用意しています。最後の test でダンプが成功して容量が単調増加しているのを確認しています。

#!/bin/bash -x set -euo pipefail umask 027 DUMP_DIR="/srv/postgres-export" OLD_TOTAL_SIZE=$(du -b "$DUMP_DIR" | awk '{print $1}') if [ -z "$(dokku postgres:list)" ]; then echo "$0: No databases" exit 0 fi for db in $(dokku postgres:list | awk 'NR>=2{print $1}'); do DUMP_FILE="$DUMP_DIR/${db}_$(date +'%Y%m%d%H%M%S')".dump dokku postgres:export "${db}" </dev/null >"$DUMP_FILE" test -s "$DUMP_FILE" done NEW_TOTAL_SIZE=$(du -b "$DUMP_DIR" | awk '{print $1}') test "$OLD_TOTAL_SIZE" -lt "$NEW_TOTAL_SIZE" 

/srv/postgres-export.sh を dokku ユーザー権限で定期実行しています。バックアップ先は ExecStartPre に + をつけて root 権限で install コマンドを実行してパーミッションなどを含めて期待している状態にしています。 OnFailure で1人Slackに通知して失敗に気付けるようにしていたので、今回の失敗に気がつきました。

# /etc/systemd/system/postgres-export.service [Unit] Description=Backup dokku postgres After=docker.service Requires=docker.service OnFailure=notify-to-slack@%n.service [Service] Type=oneshot ExecStartPre=+/usr/bin/install -o dokku -g dokku -m 0750 -d /srv/postgres-export ExecStart=/srv/postgres-export.sh User=dokku 

systemd timer で3時と15時に実行しています。

# /etc/systemd/system/postgres-export.timer [Unit] Description=Backup dokku postgres [Timer] OnCalendar=*-*-* 3,15:00 Persistent=true [Install] WantedBy=timers.target 

通知設定

本筋とは関係ないですが、通知の設定もついでに公開しておきます。

こんな感じの /usr/local/bin/notify-to-slack.rb で通知しています。

#!/usr/bin/ruby # frozen_string_literal: true require 'json' require 'uri' require 'open3' require 'net/http' unless ENV.key?('SLACK_WEBHOOK_URL') abort('Set SLACK_WEBHOOK_URL into /etc/systemd/system/notify-to-slack.env') end uri = URI(ENV['SLACK_WEBHOOK_URL']) unit = ARGV.shift text, status = Open3.capture2e(*%W"systemctl status --full #{unit}") payload = { text: text } payload[:username] = ENV['SLACK_USERNAME'] if ENV.key?('SLACK_USERNAME') payload[:icon_emoji] = ENV['SLACK_ICON_EMOJI'] if ENV.key?('SLACK_ICON_EMOJI') headers = { 'content-type' => 'application/json', } http = Net::HTTP.new(uri.host, uri.port) http.use_ssl = true http.set_debug_output $stderr if $DEBUG response = http.post(uri.path, payload.to_json, headers) puts "#{response} #{response.body}" 

service unit はこんな感じです。

# /etc/systemd/system/notify-to-slack@.service [Unit] Description=Notify systemd %i unit status to slack [Service] Type=oneshot ExecStart=/usr/local/bin/notify-to-slack.rb %i User=nobody Group=systemd-journal # SLACK_WEBHOOK_URL="https://hooks.slack.com/services/..." EnvironmentFile=/etc/systemd/system/notify-to-slack.env 

EnvironmentFile の内容は以下のような感じです。置く場所は特に決まった場所がなさそうなので、 service ファイルと同じ場所に owner=root group=systemd-journal mode=0440 で置いています。

SLACK_USERNAME="hostname" SLACK_ICON_EMOJI=":red_circle:" SLACK_WEBHOOK_URL=https://hooks.slack.com/services/... 

systemd-tmpfiles

/etc/tmpfiles.d/postgres-export.conf に

d /srv/postgres-export - - - 7d

という設定をして1週間分残すようにしています。 ExecStartPre の方でパーミッションなどは設定しているので、こちらでは - にしています。

systemctl list-timers で確認すると、 systemd-tmpfiles-clean.timer が毎日 15:00:14 で動いていました。

設定は以下の通りでした。

# /lib/systemd/system/systemd-tmpfiles-clean.timer # SPDX-License-Identifier: LGPL-2.1+ # # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version.  [Unit] Description=Daily Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) [Timer] OnBootSec=15min OnUnitActiveSec=1d 

# /lib/systemd/system/systemd-tmpfiles-clean.service # SPDX-License-Identifier: LGPL-2.1+ # # This file is part of systemd. # # systemd is free software; you can redistribute it and/or modify it # under the terms of the GNU Lesser General Public License as published by # the Free Software Foundation; either version 2.1 of the License, or # (at your option) any later version.  [Unit] Description=Cleanup of Temporary Directories Documentation=man:tmpfiles.d(5) man:systemd-tmpfiles(8) DefaultDependencies=no Conflicts=shutdown.target After=local-fs.target time-set.target Before=shutdown.target [Service] Type=oneshot ExecStart=systemd-tmpfiles --clean SuccessExitStatus=DATAERR IOSchedulingClass=idle 

原因

postgres-export.timer が 15:00:00 に動いて、 systemd-tmpfiles-clean.timer が 15:00:14 に動いているため、 OLD_TOTAL_SIZE の取得後、バックアップ中に systemd-tmpfiles --clean が動いてしまって、 NEW_TOTAL_SIZE の取得のタイミングではサイズが減っているのが原因でした。

Slack 通知は 15 時だけきていて 3 時にはきていなかったので、その理由もこれで説明できます。

対応案

バックアップのサイズ制限が systemd-tmpfiles に依存しているので、 postgres-export.timer も OnBootSec と OnUnitActiveSec に変更して実行タイミングをずらすのが一番確実そうです。

個人サーバーで厳密な処理でもないので、設定はこのままで、次の再起動でタイミングがずれて解決でも、大きな問題は良さそうです。

まとめ

systemd timer のタイミングの組み合わせでたまたま些細な問題が起きたという例を紹介しました。

組み合わせが重要な timer が複数あるときは実行時刻や実行間隔の設定で問題が起きないように注意した方が良さそうです。

kube-prometheus-stackでinit-chown-dataがエラーになっていたのを対処した

Sat, 29 Nov 2025 04:00:00 +0000

kube-prometheus-stack helm chart でインストールしている grafana で init-chown-data がエラーになっていたので、対処する設定を追加しました。

確認バージョン

https://prometheus-community.github.io/helm-charts の kube-prometheus-stack 79.1.1

エラー内容

正常起動する前のログなので、k9s では確認できなかったのですが、後で loki で確認できたログによると https://github.com/grafana/helm-charts/pull/3698 と同じで、

chown: /var/lib/grafana/csv: Permission denied chown: /var/lib/grafana/png: Permission denied chown: /var/lib/grafana/pdf: Permission denied 

というエラーが出ていました。

仮対応

最初は init-chown-data が失敗しているという情報しかなく、 local-path-provisioner を使っていたので、 PV の場所を確認して、何かできることはないかと思って、とりあえず空ディレクトリの削除を

sudo rmdir -v /opt/local-path-provisioner/pvc-*_monitoring_kube-prometheus-stack-grafana/{csv,pdf,png} 

で試したら起動するようになったので、その対応を繰り返していました。

設定

https://github.com/grafana/helm-charts/pull/3698 に readOnlyRootFilesystem: true と capabilities に DAC_READ_SEARCH を追加する、という pull request があったので、その設定を追加しました。

grafana は kube-prometheus-stack の helm subchart なのでの設定方法に悩みましたが、 initChownData.securityContext が grafana.initChownData.securityContext になるようにするだけでした。

## Using default values from https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml ## grafana: # Fix init-chown-data error # pick from https://github.com/grafana/helm-charts/pull/3698 initChownData: securityContext: readOnlyRootFilesystem: true capabilities: add: - CHOWN - DAC_READ_SEARCH drop: - ALL 

別の方法

pull request がマージされない原因のコメントのように細かいセキュリティを気にするなら、 initChownData.enabled を false にして init-chown-data 自体を実行しない、という方法もあるようです。

原因

問題のディレクトリが drwx------ で owner 472 なので、 root ユーザーには chown -R をするときにパーミッションによるディレクトリの中のファイル一覧を読む許可がなくて、通常の root 権限はパーミッションを無視して読めるのも DAC_READ_SEARCH という capabilities を drop していると無理、というのが原因だったようです。

capabilities の DAC_READ_SEARCH を add してしまうと root 権限でなくてもパーミッションを無視してディレクトリの中のファイル一覧を読めてしまう、というのが pull request でセキュリティを気にする人がコメントしている内容だと思うので、 root 権限にだけ DAC_READ_SEARCH を残せれば良さそうなのですが、できるのかどうかわかりませんでした。

まとめ

kube-prometheus-stack helm chart の value.yaml に grafana.initChownData.securityContext で許可を追加するか、 grafana.initChownData.enabled を false にすればエラーは解消されそうです。

## Using default values from https://github.com/grafana/helm-charts/blob/main/charts/grafana/values.yaml ## grafana: # Fix init-chown-data error # pick from https://github.com/grafana/helm-charts/pull/3698 initChownData: securityContext: readOnlyRootFilesystem: true capabilities: add: - CHOWN - DAC_READ_SEARCH drop: - ALL 

limaでNFSサーバーを用意した

Wed, 29 Oct 2025 07:30:00 +0000

k8s からの NFS のテスト用に NFS サーバーがほしくなったので、 lima で試してみました。

動作確認バージョン

macOS Sequoia 15.7.1
limactl version 1.2.1
Ubuntu 24.04.2 LTS

最初の動作確認

最初は以下のように同じネットワークに接続して動作確認しました。

limactl start template://ubuntu-lts --name nfs-server --containerd none --vm-type vz --network=lima:user-v2 --tty=false limactl start template://ubuntu-lts --name nfs-client --containerd none --vm-type vz --network=lima:user-v2 --tty=false 

NFS サーバー側設定

最初は以下の設定で試しました。

sudo apt update sudo apt install nfs-kernel-server sudo mkdir /exports sudoedit /etc/exports 

/etc/exports には以下の設定をしました。

/exports *(rw,fsid=0,sync,no_subtree_check,no_root_squash)

NFS クライアント側

最初は以下のコマンドで試しました。

sudo apt update sudo apt install nfs-common mkdir /tmp/nfs sudo mount -t nfs -o port=2049,rw,nfsvers=4,soft lima-nfs-server.internal:/ /tmp/nfs 

実際には soft 以外のオプションはデフォルトなので不要でした。 -t nfs も明示する必要はありませんでした。

NFSv4 のみに変更

Ubuntu 22.04 に NFSv4 サーバ構築（NFSv3 無効化）を参考にして以下のように設定変更しました。

sudo systemctl mask --now rpc-statd.service rpcbind.socket rpcbind.service sudoedit /etc/nfs.conf sudo ufw allow 22/tcp sudo ufw allow 2049/tcp sudo ufw enable 

/etc/nfs.conf は vers3=y がコメントアウトされていた [nfsd] セクションに以下の設定を追加しました。 vers2= の行はありませんでしたが、一緒に追加しないとエラーになるようでした。

vers2=n vers3=n

この状態でもマウントできたので、ポートは 2049/tcp しか使われていないのが確認できました。

外部からの接続確認

minikube などの他の仮想マシンから接続するには、ホスト側の IP アドレスで接続できる必要があります。

確認用に --network=lima:user-v2 なしで VM を作りなおしました。

limactl start template://ubuntu-lts --name nfs-client --containerd none --vm-type vz limactl start template://ubuntu-lts --name nfs-server --containerd none --vm-type vz 

port forwarding の設定変更

ホスト側で nc -v localhost 2049 はつながるのに、 nc -v 192.168.253.154 2049 でつながりませんでした。 (192.168.253.154 は macOS の IP アドレス)

server 側の lima.yaml で

portForwards: - guestPort: 2049 hostIP: "0.0.0.0" 

として localhost 限定じゃなくす必要がありました。

NAT 経由の問題対応

client 側から TCP 接続がつながるようになっても、 Operation not permitted でつながりませんでした。

$ sudo mount -t nfs -o port=2049,rw,nfsvers=4,soft 192.168.253.154:/ /tmp/nfs mount.nfs: Operation not permitted for 192.168.253.154:/ on /tmp/nfs 

エラーメッセージで原因がわかりにくいですが、 VirtualBoxのNAT環境でNFSクライアントとしてマウントするに書いてあるように、 NAT 経由だと /etc/exports に

/exports *(rw,fsid=0,sync,no_subtree_check,no_root_squash,insecure)

という感じで insecure も必要でした。

分離されたネットワークにいるマシンなので insecure にしてしまいましたが、共有のネットワークにいるマシンなら他の方法の方が良いかもしれません。

まとめ

いくつかひっかかる点がありましたが、簡単な NFS サーバーを用意して、クライアントからのマウントまで試せました。

最後に設定例をまとめておきます。

サーバー側

lima.yaml に追加:

portForwards: - guestPort: 2049 hostIP: "0.0.0.0" 

設定コマンド:

sudo apt update sudo apt install nfs-kernel-server sudo mkdir /exports sudoedit /etc/exports sudo systemctl mask --now rpc-statd.service rpcbind.socket rpcbind.service sudoedit /etc/nfs.conf sudo ufw allow 22/tcp sudo ufw allow 2049/tcp sudo ufw enable 

/etc/exports に追加:

/exports *(rw,fsid=0,sync,no_subtree_check,no_root_squash,insecure)

/etc/nfs.conf の [nfsd] セクションに設定:

vers2=n vers3=n

クライアント側

sudo apt update sudo apt install nfs-common mkdir /tmp/nfs sudo mount -o soft ${NFS_SERVER}:/ /tmp/nfs 

ciliumのGateway APIをminikubeで試した

Thu, 16 Oct 2025 07:45:00 +0000

cilium の Gateway API Support を有効にして Gateway や HTTPRoute や CiliumNetworkPolicy の動作を確認したかったので、 minikube で試せる環境を作成しました。 (CiliumNetworkPolicy はこの記事の対象外です。)

動作確認環境

macOS Sequoia 15.7.1
colima 0.9.1 で動かしている docker 環境
minikube v1.37.0
vfkit 0.6.1
kubectl v1.34.1
cilium-cli v0.18.7

8080 番ポートで動作確認

privileged port は別途設定追加が必要なので、最初に 8080 番ポートで動作確認しました。

ホスト側の macOS からノードの IP アドレスに直接接続できるようにするため、 vfkit を使ったので、 brew install vfkit でインストールしておく必要があります。

minikube は --cni cilium に対応していましたが、 Gateway API CRDs を cilium より先に入れる必要があったので --cni false にしました。

gateway-api の最新は 1.4.0 になっていますが、 cilium との組み合わせが確認されている 1.3.0 にしました。

gatewayAPI.hostNetwork.enabled=true で NodePort などを使わずに直接見えるようにしました。これと vfkit の組み合わせでホスト側のブラウザーなどからも直接見えるようになります。

80番ポートは default/cilium-gateway-cilium-gateway/listener: cannot bind '0.0.0.0:80': Permission denied (cilium の pod のログで確認) で使えないので 8080 番ポートにしています。

動作確認のテスト用アプリケーションは Claude が出してくれたものを使いました。テスト用なので Gateway なども default namespace のままになっています。

起動待ちをしていないため、最後の curl で表示されなかったので別途実行して確認しました。

#!/bin/bash set -euxo pipefail # 最終的な構成 minikube start \ --driver=vfkit \ --network-plugin=cni \ --cni=false \ --extra-config=kubeadm.skip-phases=addon/kube-proxy kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml cilium install \ --set kubeProxyReplacement=true \ --set k8sServiceHost=$(minikube ip) \ --set k8sServicePort=8443 \ --set gatewayAPI.enabled=true \ --set gatewayAPI.hostNetwork.enabled=true \ --set ingressController.enabled=false cilium status --wait # Gateway (8080ポート) kubectl apply -f - <<EOF apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: cilium-gateway spec: gatewayClassName: cilium listeners: - name: http protocol: HTTP port: 8080 EOF # テスト用アプリケーション kubectl create deployment echo --image=ealen/echo-server:latest kubectl expose deployment echo --port=80 # HTTPRoute kubectl apply -f - <<EOF apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: echo-route spec: parentRefs: - name: cilium-gateway rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: echo port: 80 EOF # テスト curl http://$(minikube ip):8080 

80番ポートで確認

80番ポートを使えるようにするには https://docs.cilium.io/en/latest/network/servicemesh/gateway-api/gateway-api/ の説明にあるように envoy.securityContext.capabilities の設定も必要でした。

values.yaml に書くなら以下のようになります。

envoy: securityContext: capabilities: keepCapNetBindService: true envoy: - NET_ADMIN - SYS_ADMIN # Add NET_BIND_SERVICE to the list (keep the others!) - NET_BIND_SERVICE 

keep the others! 用の値は cilium の chart の values.yaml の以下のところから持ってきています。

 capabilities: # -- Capabilities for the `cilium-envoy` container. # Even though granted to the container, the cilium-envoy-starter wrapper drops # all capabilities after forking the actual Envoy process. # `NET_BIND_SERVICE` is the only capability that can be passed to the Envoy process by # setting `envoy.securityContext.capabilities.keepNetBindService=true` (in addition to granting the # capability to the container). # Note: In case of embedded envoy, the capability must be granted to the cilium-agent container. envoy: # Used since cilium proxy uses setting IPPROTO_IP/IP_TRANSPARENT - NET_ADMIN # We need it for now but might not need it for >= 5.11 specially # for the 'SYS_RESOURCE'. # In >= 5.8 there's already BPF and PERMON capabilities - SYS_ADMIN # Both PERFMON and BPF requires kernel 5.8, container runtime # cri-o >= v1.22.0 or containerd >= v1.5.0. # If available, SYS_ADMIN can be removed. #- PERFMON #- BPF # -- Keep capability `NET_BIND_SERVICE` for Envoy process. keepCapNetBindService: false 

最終的に動作確認用のコマンドは以下のようになりました。

#!/bin/bash set -euxo pipefail # 最終的な構成 minikube start \ --driver=vfkit \ --network-plugin=cni \ --cni=false \ --extra-config=kubeadm.skip-phases=addon/kube-proxy kubectl apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.3.0/standard-install.yaml cilium install \ --set kubeProxyReplacement=true \ --set k8sServiceHost=$(minikube ip) \ --set k8sServicePort=8443 \ --set gatewayAPI.enabled=true \ --set gatewayAPI.hostNetwork.enabled=true \ --set ingressController.enabled=false \ --set envoy.securityContext.capabilities.keepCapNetBindService=true \ --set envoy.securityContext.capabilities.envoy='{NET_ADMIN,SYS_ADMIN,NET_BIND_SERVICE}' cilium status --wait # Gateway (8080ポート) kubectl apply -f - <<EOF apiVersion: gateway.networking.k8s.io/v1 kind: Gateway metadata: name: cilium-gateway spec: gatewayClassName: cilium listeners: - name: http protocol: HTTP port: 80 EOF # テスト用アプリケーション kubectl create deployment echo --image=ealen/echo-server:latest kubectl expose deployment echo --port=80 # HTTPRoute kubectl apply -f - <<EOF apiVersion: gateway.networking.k8s.io/v1 kind: HTTPRoute metadata: name: echo-route spec: parentRefs: - name: cilium-gateway rules: - matches: - path: type: PathPrefix value: / backendRefs: - name: echo port: 80 EOF # テスト curl --head http://$(minikube ip) 

最後に

いくつかはまりどころがありましたが、やりたかったことができる環境を作成できました。

これで既存の環境を壊さずに CiliumNetworkPolicy の設定を試行錯誤できそうです。

BrowserosaurusでクリップボードにURLをコピーする

Sat, 30 Aug 2025 06:00:00 +0000

今はデフォルトブラウザーとして Browserosaurus という実際にURLを開くアプリを選べるアプリを使っていて、ブラウザーを開く変わりにクリップボードにURLを調べたことがあったので、その方法のメモです。

動作確認バージョン

Browserosaurus Version 20.11.0
Browserosaurus Version 20.12.0

この記事を書くときに https://github.com/will-stone/browserosaurus を確認したところ、

This repository was archived by the owner on Aug 3, 2025. It is now read-only.

になっていて、 The retirement of Browserosaurus — Will Stone というブログ記事へのリンクがあったので、新しく使うなら、リンク先の記事の最後の方に書いてある別のアプリを候補にした方が良さそうです。

クリップボードへのコピー

結論から先に書くと、ブラウザーを選択するメニューが出ているときに、 Command+c を押すとコピーできました。

ポップアップメニューの下のドメインが表示されている部分のクリックでもコピーできました。

Browserosaurus のポリシーとか

Browserosaurus は簡単に使えるようにするため、あらかじめソースに対応アプリ一覧が埋めこまれていて、ユーザーが自由に対応アプリなどの設定を追加はできない、という思想になっています。

そこで、機能を追加してもらうとしたらどんな感じだろうと思って、ソースをながめてみると、 Command+cでクリップボードにコピーできるようになっていました。

記事を書きながら確認しなおしていたところ、 URL barのクリックでもコピーできるようになっていたので試したところ、ポップアップメニューの下のドメインが表示されている部分のクリックでコピーできました。

まとめ

クリップボードへのコピー方法を書いたドキュメントはみつけられませんでしたが、ソースを確認することで機能が存在して使えることがわかりました。

以前に調べてから、記事を書くまで間が開いてしまって、状況が変わっていて驚きました。

まだしばらくは問題なく使えそうですが、対応アプリの追加が望めなかったり、新しい macOS で動かなくなる可能性があったりするので、そのうち別アプリへの移行を検討したいと思いました。

macOSのターミナルの「Control +V で非ASCII入力をエスケープ」の挙動を調べた

Fri, 04 Jul 2025 00:25:00 +0000

macOSのターミナル.appで「Control +V で非ASCII入力をエスケープ」を有効にしているとマルチバイト文字の入力が変になるという話を調べてみました。

経緯

Unable to type non-ASCII chars on Mac <ffffffff> ではまったという話をみて気になったので調べました。

調査

最初は雑に system("stty raw -echo") で調査したら、戻し忘れて変になったので、ちゃんと STDIN.raw を使って戻すようにして試しなおしました。

通常の「Control +V で非ASCII入力をエスケープ」が無効の状態では a でも あ でも問題なく入力できました。

% ruby -r io/console -e 'p STDIN.raw{STDIN.sysread(80)}' "a" % ruby -r io/console -e 'p STDIN.raw{STDIN.sysread(80)}' "\xE3\x81\x82" 

設定から「Control +V で非ASCII入力をエスケープ」にチェックを入れて有効にした状態では a は問題なくて、あ の各バイトに Control-V (\x16) がついていました。

% ruby -r io/console -e 'p STDIN.raw{STDIN.sysread(80)}' "a" % ruby -r io/console -e 'p STDIN.raw{STDIN.sysread(80)}' "\x16\xE3\x16\x81\x16\x82" 

zsh での Control-V

bindkey の出力から Control-V の割り当てを確認します。そして zshzle の manpage から /quoted-insert で検索しました。

% bindkey | grep V "^V" quoted-insert "^X^V" vi-cmd-mode % man zshzle

名前の通り、次の文字をそのまま入力する機能です。個人的には echo ^V^G で BEL 文字を入力して visual bell になっているか試す、というような用途に使うことがあります。

 quoted-insert vi-quoted-insert Quote the character to insert into the minibuffer. 

まとめ

zsh で Control-V は quoted-insert なので、環境によってはマルチバイトの入力に必要なことがあるのかもしれませんが、日本語環境では文字が壊れて困ることが多そうで変更しない方が良い設定だとわかりました。

@znz blog

外部ドライブなしでTime Machineバックアップを設定する

確認環境

sparse bundle 作成

バックアップ設定

バックアップ作成

バックアップ設定削除

暗号化ありで sparse bundle 作成

証明書のバックアップ

バックアップ設定

除外設定

sparse bundle のバックアップ

まとめ

headscale+tailscaleに移行中

動作確認環境

発表資料

ユーザーとタグの扱い

まとめ

OpenLDAPのバックエンドをhdbからmdbへ移行した

対象環境

移行手順の概要

バックアップ

移行対象を停止

olcDbDirectory

check_slapdd_crc32 を用意

書き換え

DB 移行

作業対象サーバーの入れ替え

もう1台も移行

最後に

Dokkuを動かしているUbuntuを20.04から22.04に更新した

データベースなどのバックアップ

do-release-upgrade

etc のファイル確認

sshd_config

50unattended-upgrades

zabbix-agent2

dokku と docker

その他のファイル

まとめ

systemdのtimerの時間が重なって想定外の挙動になっていた

バックアップ設定

通知設定

systemd-tmpfiles

原因

対応案

まとめ

kube-prometheus-stackでinit-chown-dataがエラーになっていたのを対処した

確認バージョン

エラー内容

仮対応

設定

別の方法

原因

まとめ

limaでNFSサーバーを用意した

動作確認バージョン

最初の動作確認

NFS サーバー側設定

NFS クライアント側

NFSv4 のみに変更

外部からの接続確認

port forwarding の設定変更

NAT 経由の問題対応

まとめ

サーバー側

クライアント側

ciliumのGateway APIをminikubeで試した

動作確認環境

8080 番ポートで動作確認

80番ポートで確認

最後に

BrowserosaurusでクリップボードにURLをコピーする

動作確認バージョン

クリップボードへのコピー

Browserosaurus のポリシーとか

まとめ

macOSのターミナルの「Control +V で非ASCII入力をエスケープ」の挙動を調べた

経緯

調査

`check_slapdd_crc32` を用意

`sshd_config`