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
の調整が必要
サービスの自動起動設定は忘れずにケアする
旧バージョンは依存関係が切れているのでdepcleanすれば消えるが、データと設定は残してくれるので好きなように
なにはともあれ、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
他のcloneで追いかける
ローカルの 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 を使いはじめた。
実利的な面は、それなりに長期間運用してみないとわからない。
Portage
Gentoo WikiのCcacheのページ にかなり網羅的な情報が載っていて、
ここを参考にすればPortageの設定までカバーできてしまう。
ただし Using ccache globally is not recommended らしいので、そこは各自の判断で。
genkernel
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 環境で行なわれ、
許可されていないディレクトリへの書き込みがブロックされるためで、
以下のいずれかの設定を入れる必要がある。
そもそもSandboxを使わないようにする
/etc/genkernel.conf
で SANDBOX="no"
を設定
Sandbox内でもキャッシュディレクトリへの書き込みを許可する
/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アドレスが残ったままになるので同様のリスクがあるし、
ゾーンのコントロールを奪われ得るのでより悪いとも言える。
遺されたシステム - 88171.net
つまり、(ここの場合)たかだか1年間の有期契約で借りているプライマリサーバのIPアドレスを上位サーバに登録することは、
将来なんらかの理由で管理が立ち行かなくなった場合にセキュリティリスクとなるので、それを避けたかった。
リスクとはいっても現実となる可能性は無視できるくらい低いものの、
このドメインの場合は特に大きなデメリットが見当たらないこともあって、念のためやっておくことにした。
隠した とはいうものの、SOA.MNAME
には変わらずプライマリのホスト名を載せているし、
プライマリにクエリが飛んでくれば誰にでも普通に返事をする。
存在を公言しなくなった、という表現の方が実情に近い。
いっそのこと、さくらにプライマリを任せてしまえば面倒がないのでは?という説はある。
実際に数年前まではそうしていたのだけど、ゾーンをファイルで管理できるのはやっぱり楽なので、なかなか戻りづらい。
ちなみに、さくらのネームサーバのような共用DNSサーバを使うこと自体がリスクを孕んでいるので、そこは追って検討する。
一つ言えるのは、一個人の立場では選択肢はとても限られている。
older entries