MacBook Pro（13-inch, Late 2013）を使い続けて8年半。 論理的には驚くほど健在なのでこの2年くらいずっと買い替えを迷っていたのだけれど、Montereyでついにサポートから外れてしまったし、バッテリーがわずかに膨張してネジ山が一箇所死んでしまったので、ようやく買い換える決意をした。
MacBook Airと少し悩んだ末に、今回はMac miniにすることにした。 上海から直送らしく、現在納品待ち。 ちなみにコスト面から現行MacBook Proは選択肢になく、最近出てきたMac Studioは眼中にすらなかった。
ここ数年で脱macOSというか、iOSデバイスでもできることを増やす取り組みをしてきたこともあって、自分の生活の中でコンピュータが必要なシーンは（ゼロになることはないけれど）着実に減っている。 そんな状況なので、各種アダプタの取り回しやバッテリーの経年劣化といったモバイルコンピュータ特有の煩わしさに耐え忍んでまで、携帯性を確保することに意味があるとは思えなかった。
PostgreSQLの14がstableになったようで、@worldをupdateしたら自動的に14が降ってきた。
勝手に13を置き換えてくれるのかと思ったらそうではなく、二つのバージョンが同時にインストールされた状態になるので、マイグレーションは自分でやる必要がある。
Portageのメッセージに導かれてWikiを辿ると、マイグレーションの手順を用意してくれている。 基本的にこの内容に従えば、特に苦もなくマイグレーションできる。
補足としていくつか。
localがtrustでないので、pg_upgradeの前にpg_hba.confの調整が必要なにはともあれ、Portageからのメッセージを見逃さないことが大事。
時流に乗って（乗れてないけど）、手元のGitリポジトリの master ブランチを改名することにした。
ただざっと調べたところでは（GitHubとかでなく）独自のリモートリポジトリを使っているケースの情報が見当たらなかったので、せっかくなのでまとめておく。
ちなみに、このテキストを改名後の main ブランチにpushすることでpublishされるので、何かミスってたらこのテキストは世に出ないことになる。
ローカルの master ブランチを main に改名する。
$ git checkout master
$ git branch -m master main
改名した main をリモートにpushし、同時にupstreamを設定する。
$ git push --set-upstream origin main
次にリモートの master を削除する。
が、リモートの HEAD が master を向いたままだと削除できないので main に向け直す。
GitHubで言うところの「デフォルトブランチの変更」に相当する。
ここだけはリモートリポジトリを直接触る必要がある。
remote$ git symbolic-ref HEAD refs/heads/main
リモートの master を削除する。
$ git push origin --delete master
remotes/origin/HEAD が消えてしまうので再設定する。
$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
ローカルの master ブランチを main に改名する。
$ git checkout master
$ git branch -m master main
fetchしてupstreamを再設定する。
$ git fetch
$ git branch --unset-upstream
$ git branch --set-upstream-to=origin/main
remotes/origin/HEAD が origin/master を向いたままなので、再設定する。
$ git symbolic-ref refs/remotes/origin/HEAD refs/remotes/origin/main
残っているリモートトラッキングブランチ origin/master を削除する。
$ git branch --remotes --delete origin/master
次にリポジトリを新規作成する場合に備えて、デフォルトブランチの名前を変えておく。
$ git config --global init.defaultBranch main
CPUが貧弱でGentooの日々のメンテがしんどいので、 試しにCcacheを使いはじめた。
実利的な面は、それなりに長期間運用してみないとわからない。
Gentoo WikiのCcacheのページにかなり網羅的な情報が載っていて、 ここを参考にすればPortageの設定までカバーできてしまう。
ただし Using ccache globally is not recommended
らしいので、そこは各自の判断で。
Gentoo Wikiのgenkernelのページに さらっと書いてある 程度で、情報が少ない。
最終的に /etc/genkernel.conf の設定は、要点だけ抜粋すると以下のようにした。
CCACHE_DIR="/path/to/ccache-cache"; export CCACHE_DIR
KERNEL_CC="/usr/lib/ccache/bin/gcc"
UTILS_CC="/usr/lib/ccache/bin/gcc"
UTILS_CXX="/usr/lib/ccache/bin/g++"
当初は KERNEL_CC="ccache -d /path/to/ccache-cache gcc" といった設定を試してみたものの、
Ccacheが Invalid option というエラーを吐いた。
おそらくビルドプロセスのどこかでコマンドライン文字列の扱いに難があるせいだが、深くは追っていない。
とにかく、キャッシュディレクトリのパスを環境変数で渡すしかないので無理矢理exportしている
（Bashスクリプトなのでexportできてしまう）。
さらに、これだけではinitramfsのコンパイルの段階で ACCESS VIOLATION という見慣れないエラーが発生する。 これはinitramfsのコンパイルがSandbox環境で行なわれ、 許可されていないディレクトリへの書き込みがブロックされるためで、 以下のいずれかの設定を入れる必要がある。
/etc/genkernel.conf で SANDBOX="no" を設定/etc/sandbox.conf に SANDBOX_WRITE="/path/to/ccache-cache" を追加個人的には後者のほうが筋は良いと思う。
ただ、ドキュメントを読む限り /etc/sandbox.d/ に設定ファイルを作成しても効きそうなものだが、
/etc/sandbox.conf に追記しないと想定した挙動にならなかった。
これも裏は取っていない。
ここ、88171.netのDNSをHidden Primary化した。
と、したり顔で言ってはみたものの、Hidden Primaryという名前で呼ばれていることは後から知った。
Hidden Primaryとは、ドメインのNSレコードに含まれず意図的に存在を隠されたプライマリサーバを指す。 リゾルバからの名前解決要求は必然的にセカンダリサーバでのみ受け付けることになる。 ゾーン情報の管理の観点では、プライマリ・セカンダリの関係は一般的な構成と変わらない。
前出の記事ではそれぞれHidden Primaryのメリットについて触れられているけれども、 決して普遍的なものではないし、必ずしもこのドメインに当てはまるものでもない。
なぜ、このドメインのプライマリを隠したのかといえば、以前に書いた記事に関係する。
独自ドメインにDNSサーバを置いている場合も、 上位サーバのグルーレコードにIPアドレスが残ったままになるので同様のリスクがあるし、 ゾーンのコントロールを奪われ得るのでより悪いとも言える。
つまり、（ここの場合）たかだか1年間の有期契約で借りているプライマリサーバのIPアドレスを上位サーバに登録することは、 将来なんらかの理由で管理が立ち行かなくなった場合にセキュリティリスクとなるので、それを避けたかった。 リスクとはいっても現実となる可能性は無視できるくらい低いものの、 このドメインの場合は特に大きなデメリットが見当たらないこともあって、念のためやっておくことにした。
隠したとはいうものの、SOA.MNAMEには変わらずプライマリのホスト名を載せているし、
プライマリにクエリが飛んでくれば誰にでも普通に返事をする。
存在を公言しなくなった、という表現の方が実情に近い。
いっそのこと、さくらにプライマリを任せてしまえば面倒がないのでは？という説はある。 実際に数年前まではそうしていたのだけど、ゾーンをファイルで管理できるのはやっぱり楽なので、なかなか戻りづらい。
ちなみに、さくらのネームサーバのような共用DNSサーバを使うこと自体がリスクを孕んでいるので、そこは追って検討する。 一つ言えるのは、一個人の立場では選択肢はとても限られている。