いつの間にかFreeBSDのportsからdatabases/db6が消えていた

全てはOracleのせい。BerkeleyDBを買収した後、今年の6月くらいにはver.6は登録しないとダウロードできなくなった模様。結果としてportsから更新できず。

databases/db5を使えと。

いやまぁ仕方ないのは分かるんだけど、ports/UPDATEのログにも一切記述が無くてさっぱり分からねぇよ…。

portsのsubversionログ追っかけてやっと分かったんだけど。

BerkeleyDBに依存してるオープンソースソフトウェア、そのうち軒並み死亡するかBerkeleyDB外しが進むのか…。

結局、Oracleの買収っていつもオープンソース(競合)潰しだよなぁ。

SSLの証明書で嵌まった話

管理しているFreeBSDマシンのいくつかで、weekly.localがロックしたまま延々終わらないと言うことが発生。

調べてみると、portsdb -FuがSSLの以下のエラーでリトライが終わらなくなっている模様。(エラー吐いてる実体はfetchコマンド)

Certificate verification failed for /C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3

あーなんかLet’s Encryptのルート証明書が変わるとかなんとかどっかで聞いたな…と思いつつ、定番のca_root_nssを更新して見るも状況に変化なし。はて?

結論としては、/usr/local/etc/ssl/cert.pemファイルを削除して解決。

FreeBSDシステムには証明書は以下の3つがあり、ca_root_nssをインストールすると一つ目はシンボリックリンク張ってくれるけれど、二つ目・三つ目はcert.pem.sampleの名前でしかシンボリックリンク作ってくれない。

/etc/ssl/cert.pem
/usr/local/etc/ssl/cert.pem
/usr/local/openssl/cert.pem

で、どういうわけか、比較的古いバージョンからアップデートしてきたマシンだと、下二つのcert.pemファイルの中身が空っぽ。

いやいや空っぽってどういうこと?!比較的新しい日付なんで、どうも最近消されたっぽい感じ。

そして、問題なくアップデート出来ている割と新しめのバージョンから使ってるマシンでは、シンボリックリンクではなく比較的新しい証明書の実体が入っている。何でやねん…。

まぁ、ca_root_nssインストール時に、

You may need to manually remove /usr/local/etc/ssl/cert.pem if it is no longer needed.
You may need to manually remove /usr/local/openssl/cert.pem if it is no longer needed.

って出てるので、ちゃんと読まなかった方も悪いんですが。

とりあえず解決したものの、同じバージョンのOSでもcert.pemの中身が違ったり、システムがportsのca_root_nssに証明書を全依存してるのってセキュリティ的にどうなの?とかモヤモヤするところです。

FreeBSDって古いバージョンからアップデートで使い続けてると、こういうわかりにくいトラブルが割と起こります。そのあたりどのOSでも似たようなもんですかね。

Gmailからfetchmailで引っ張るにはimapを使おう

何も考えず、Gmail側にメールを残す設定POPで引っ張ってたら詰んだというお話。

とある事情でGmail使い出したんですが、自前のスプールにfetchmailでGmailからPOPで引っ張るようにしたのは良いけど、ある日突然配送がピタッと止まりました。

cronで動かしていたfetchmailを手動でコマンド打ってみたら、未読無し…と。その時に表示される件数が480件くらい。

Gmail側をブラウザで開いてみたら、500件以上ある。はて?

詳しくは見てないけれど、どうもGmail側のメールが480件あたりを超えるとfetchmail/POPでうまく引っ張れなくなる模様。
※uidlのオプション付けてたせいかもしれない

Thunderbirdから繋いで、imapで接続し、INBOXから他のフォルダに移動させてみたけれども結果変わらず。それどころか、Webブラウザから見える「受信トレイ」の件数に変化が無い。

どうにも、GmailのI/Fが見せている「受信トレイ」はimapのINBOXとは違う物を見せてる模様で、POPも同じみたい。

fetchmailが使うプロトコルをimapに変更して、サクッと解決。


高機能な新しい物が出てくる度、知識を駆使してlegacyなやりかたに囓り付いてる…。

歳食ったなぁ…。

zvolのvolblocksize

netatalkでの共有を止めて、zvol+iSCSIへ移行したわけですが、どうにもディスク消費量が大きすぎるのが気になってました。

zfs create -sVにて疎ボリュームで作成したんで、使用したら使用した分だけディスク消費するようにしてました。

すると、実容量に対し管理領域なんかで数%ふえるのはあり得る話しだけども、2TBのファイル置くだけで2.6TBも消費していて明らかにおかしい…。

そんなわけで、volblocksizeを疑ってテストしてみました。

用意した1GBiの書込みファイル。
dd if=/dev/random of=test.data bs=1048576 count=1024

今回は-sオプション使わず、普通にzfs create -V 2Gで確保しました。

blocksizeUSEDREFER
8kB2.06G1.35G
16kB2.03G1.01G
32kB2.02G1.00G
64kB2.01G1.00G
128kB2.01G1.00G
iSCSI経由APFSでmacOSから1GBi書込み後のzfs listの値

FreeBSDでzvolを作成すると、デフォルトではblocksizeは8kBに設定されます。

しかし結果を見てみると、8kBだけ明らかにREFERの上昇が激しいです。

REFERは実際に消費されているサイズというより「書込みで使用済みとなったサイズ」なので、CoW的な動きされると「書込んだけど今は使ってない」領域が存在し、それらがカウントされているのかと思います。

それでも8kBだけこれだけ差があると、ちょっと気持ち悪い…。

blocksizeによる実際のディスク消費量の違いは、USEDの値を見るのが妥当なところかな。それでも8kBだと約3%と、ちょい多い。

パフォーマンスについては、下記のサイトで検証されていて、あんまり影響は無い模様。

っていうか、FreeNASでは16kBがデフォルトなんですね。

ディスクケチりたいので128kBにしたいところですが、なんとなくビビって64kBに設定してzvol作り直しましたとさ。

APFS自体がCoWっぽい振舞するので、zfsの疎ボリューム機能使っても無駄にしかならないので、ギリギリサイズで確保して都度、volサイズを拡張することにしました。

おまけ:zvol/iSCSI/APFS運用でのvolサイズ拡張について

ディスク容量が手狭なんで、必要最低限のzvol確保しておいて、足りなくなったらちょっとづつ拡張していく作戦。

試しに# zfs set volsize=2T hddvol/scsivolみたいな感じで拡張してみましたところ、dmesgにこんな感じのログが。

GEOM_PART: zvol/hddvol/scsivol was automatically resized.
  Use `gpart commit zvol/hddvol/scsivol` to save changes or `gpart undo zvol/hddvol/scsivol` to revert them.

GEOM_PARTがサイズの変更を感知して、GPTを修正するかどうか?って聞いてるっぽい。因みに無視して進めようとすると、zvolが使用中とかでアクセス出来ません。

gpart commit zvol/hddvol/scsivolって実行すると、良きに計らってくれるようで。

追記:2020/12/16

容量拡張時には、FreeBSD側でgpart commitしておかないと、Mac側でのボリューム拡張に失敗する模様。

パーティションテーブルもMacの管理下だろう…と、volmode=devとかしてFreeBSD側からのgeom通したパーティション操作禁止したら嵌まった…。