2022/03/31(木)postgresql にて、任意の select 文を csv 出力する

自分メモその2。ざっくりと、こんな感じ。
# psql -h サーバFQDN DB名 -U ユーザ名 -c "《任意のselect 文》;" -A -F , > output.csv
サーバFQDN は、ホスト名のほか、IPアドレスでも可能です。自ホストの場合は localhost と指定します。
DB名・ユーザ名は、そのままですね。
任意のselect文は、全体をダブルクォーテーションで括ります。終端には必ずセミコロン「;」を付けます。
select 文中に括弧やダブルクォーテーションが入る場合、エスケープが必要かもしれません。

 -A は、「桁揃えなしのテーブル出力」で、これを指定しないと、CSV 出力の際に余計なスペース等が入ってしまいます。
 -F は、「桁揃えなし出力時のフィールド区切り文字」で、デフォルトの区切り文字は "|" なので、CSV 出力の場合は、必ずカンマ「,」を指定します。

あとは、リダイレクトで出力ファイル名の指定。
文字コードは、DBの文字コードが適用されます。

2022/03/31(木)FreeBSD12/FreeBSD13 にて Let's Encrypt を使う(manual 編)

2022/03/31 2:18 サーバ運営・管理
いつもの自分メモ。地味にいつも嵌るので、、
FreeBSD Ports においては、 securiry/py-certbot をインストールするのは、従来と同じです。

Webサーバ自体が Firewall 内部で、ルータのIPマスカレードや、NATで外部から直接アクセスできない(Firewall の内と外でIPアドレスが違うと Let's Encrypt のツールでは自動取得・自動更新は難しいと思う)ネットワーク構成の場合、--manual オプションで使うのが当方の環境では最も確実です。
但し、アクセス制限をかけたり、リダイレクトしている場合は、それらを全て一旦全て解除し、出来る限りフリーアクセスの状態にしないと、HTTPステータスが 401 になったり、 301 になったりで上手くいかない。

他に、もっと効率的な手法があればいいのですが、、
# certbot certonly --manual --preferred-challenges http-01 -d host.example.com
のように入力すると、
Saving debug log to /var/log/letsencrypt/letsencrypt.log
Requesting a certificate for host.example.com

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Create a file containing just this data:

yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU.xGBBOehwohStkrITKI6h3ng8cYkGYXMtZXQnLK8SHUA

And make it available on your web server at this URL:

http://host.example.com/.well-known/acme-challenge/yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Press Enter to Continue
のように表示されます。

外部から、
http://host.example.com/.well-known/acme-challenge/yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU

でアクセス出来るよう、ファイルの中身が
yPcvsXmaN4k_2rk-ZxFKmbp0EwgrmlgLflIPa5EsYtU.xGBBOehwohStkrITKI6h3ng8cYkGYXMtZXQnLK8SHUA

であるコンテンツをサーバ上に設置するように。。 という意味のメッセージの模様:

上手くいくと、
Successfully received certificate.
Certificate is saved at: /usr/local/etc/letsencrypt/live/host.example.com/fullchain.pem
Key is saved at: /usr/local/etc/letsencrypt/live/host.example.com/privkey.pem
This certificate expires on 2022-06-28.
These files will be updated when the certificate renews.

NEXT STEPS:
- This certificate will not be renewed automatically. Autorenewal of --manual certificates requires the use of an authentication hook script (--manual-auth-hook) but one was not provided. To renew this certificate, repeat this same certbot command before the certificate's expiry date.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
If you like Certbot, please consider supporting our work by:
* Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate
* Donating to EFF: https://eff.org/donate-le
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
のようなメッセ―ジが表示されます。
得られた公開鍵・秘密鍵を実際に運用するサーバに適切にセットアップすることで、公開鍵・秘密鍵のアップデート、新規登録が共に可能です。

尚、有効期間は 90日だが、一度同じホスト(FQDN)名で、Let's Encrypt のサーバ証明書を作ると、デフォルトでは、前回の有効期限から90日となる模様。

2022/02/10(木)Windows 11 にしてみた

一度、インストール失敗したこともあり、半日かかりました。
アップデートの際は、必ずアンチウィルスの動作を無効にしましょう。これがアップデートのときに問題を引き起こします。(下図参照)
20220210.png

これは、当方で有償ライセンスで使用している Avast! の例です。
ハッキリ言って表現が悪いのですが「永久に」というよりは、「再度有効にするまで無効にする」という意味です。

結論から言うと、「今、慌ててやる必要はない」です。
20220210.jpg


GUI インタフェースはハッキリ言うと「改悪」そのものと言って良い。

改悪の極みはエクスプローラで、
Windows 10 のエクスプローラーだと、右クリックで選択出来たものが、
Windows 11 のエクスプローラでは、「その他の機能」に殆どが移行し、例えば「名前の変更」なんかは、
右クリック1回、「その他の機能」の左クリック1回、ここで始めて「名前の変更」の左クリック。
で、合計3回させられます。

タスクトレイに日時が表示されるのは変わらないですが、勘違いなセキュリティ対策なのか、
タスクトレイの改造が外部ソフトウェアで出来なくなった上に、秒の表示が出来ません。
更に、文字の大きさが小さい。
こうするなら、タスクトレイ改造相当のカスタマイズ機能を標準でサポートするべきです。

唯一の改善点(?)は、同じディスプレイ上で明確に仮想画面を持てるようになったことくらいでしょうか。
「デスクトップ1」「デスクトップ2」というのがそれ。追加できるみたいです。

これ見て思ったのは、「MacOS のパクリ?」というところ。
でも、これは便利です。
まぁ BSD系Unix とかでは昔から普通にあった機能ですけどね。CUI環境でも8画面程度の仮想画面を持っています。

2021/12/15(水)Apache Log4j 使っていません。

2021/12/15 5:53 サーバ運営・管理
ちまたでは、大騒ぎになっていますが・・・
弊社では、このソフトウェアは使用していません。

問題となった機能を、デフォルトで無効・削除したバージョン 2.16.0 が昨日公開されたようです。

[2021/12/21 追記]
さらに、脆弱性対策漏れがあったとして、バージョン 2.17.0 が 12/17 に公開されたようです。

2021/11/26(金)clamAV は 0.104 から構築方法が変わっている模様・・・

2021/11/26 6:51 サーバ運営・管理
いつものように、ソースコードからの構築を行うべく、
# ./configure --enable-experimental --with-iconv --enable-milter
とか、やって構築しようとしたらエラーを吐くので、ちょっと見て見たら単純に configure スクリプトが無い。
更に調べたら、cmake を使う構築方法に変わったとのこと。

今まで、機会が無くやったことが無いので面食らいました。。。
clamAV 0.104 以降で cmake で構築する場合、先ず、
# cd clamav-0.104.1
# mkdir build
# cd build
# cmake .. -D ENABLE_EXPERIMENTAL=NO -D ENABLE_JSON_SHAREDOFF
とか実行して、まさに configure と同じ役割で構築環境を作り出すのですが、依存するモジュールやライブラリが結構あって、存在しないと、 cmake がエラーを吐いて終了します。最初は、これに面食らいます。

不足があるかもしれませんが、事前に下記の依存モジュールやライブラリが必須のようです:
 ・pcre-8.45   (Ports から カテゴリ:devel)
 ・pcre2-10.39  (Ports から カテゴリ:devel)
 ・autoconf-2.69_3(Ports から カテゴリ:devel)
 ・cmake-3.21.4_1 (Ports から カテゴリ:devel)
 ・libltdl-2.4.6 (Ports から カテゴリ:devel)
 ・libtool-2.4.6_1(Ports から カテゴリ:devel)
 ・libxml2-2.9.12 (Ports から カテゴリ:textproc)
 ・db5-5.3.28_7  (Ports から カテゴリ:databases)  ※ これは BerkeleyDB 5.3.28 です
 ・curl-7.80.0  (Ports から カテゴリ:ftp)
 ・json-c-0.15_1 (Ports から カテゴリ:devel)
 ・jsoncpp-1.9.5 (Ports から カテゴリ:devel)
 ・check-0.15.2  (Ports から カテゴリ:devel)
 ・ncurses-6.3  (Ports から カテゴリ:devel)
上手くいったら、
# cmake --build .
# cmake --build . --target install
とやると、ソースコードからインストールできるようです。
(ドットを省略しないことに注意を)

2021/08/28(土)FreeBSD13 からのソースコードによるOS更新は、gitup が最も手軽

2021/08/28 5:00 サーバ運営・管理
先日、FreeBSD のソースコード管理が subversion から git に変更になった旨を『厄介だ』と紹介したのですが・・・
その厄介さを払拭するメンテナンスツールが既に用意されていたのでした。

この手の情報が数えるほどしかなく、日本語による情報を当方が見つけたのはここだけです → KNCN weblog /usr/src を gitup で取得する
#見落としの可能性もあるのでご容赦を・・

これは、OSの標準コマンドではないので、出来る限り最新のports から、
# cd /usr/ports/net/gitup
# make install
# make clean
# rehash
とかやって、インストールします。インストール後、 /usr/local/etc/gitup.conf を以下のように適宜編集します:
(一部抜粋)
# $FreeBSD$
#
# Default configuration options for gitup.conf.
{
        "defaults" : {
                "host"           : "git.freebsd.org",
                "port"           : 443,
#               "proxy_host"     : "",
#               "proxy_port"     : 0,
#               "proxy_username" : "",
#               "proxy_password" : "",
#               "source_address" : "",
                "low_memory"     : false,
                "display_depth"  : 0,
                "verbosity"      : 1,
                "work_directory" : "/var/db/gitup",
        },

        "ports" : {
                "repository_path"  : "/ports.git",
                "branch"           : "main",
                "target_directory" : "/usr/ports",
                "ignores"          : [
                        "distfiles",
                        "packages",
                ],
        },

        "release" : {
                "repository_path"  : "/src.git",
                "branch"           : "releng/13.0",
                "target_directory" : "/usr/src",
                "ignores"          : [
                        "sys/amd64/conf",
                        "sys/arm64/conf",
                        "sys/i386/conf",
                        "sys/pc98/conf",
                        "sys/powerpc/conf",
                        "sys/riscv/conf",
                        "sys/sparc64/conf",
                ]
        },

        "stable" : {
                "repository_path"  : "/src.git",
                "branch"           : "stable/13",
                "target_directory" : "/usr/src",
                "ignores"          : [
                        "sys/amd64/conf",
                        "sys/arm64/conf",
                        "sys/i386/conf",
                        "sys/pc98/conf",
                        "sys/powerpc/conf",
                        "sys/riscv/conf",
                        "sys/sparc64/conf",
                ]
        },
見ての通り、JSON 形式な設定ファイル。
初めてだと JSON 形式に面食らうんですが、割と直感的に変更できます。
gitup.conf を編集後、
# gitup release
とやれば、今まで同様の /usr/src 配下へのソースコード取得、
今後は、ports ツリーもgit 管理になるらしいので、そうなった際は、
# gitup ports
で、従来のように /usr/ports 配下への取得が出来るようです。
ただ、ports ツリーの取得は、前処理・後処理があるので、portsnap のほうが使い勝手は良いです。
〔参考〕portsnap が更新しない場合の対処法

尚、新規取得時も更新時も同じコマンドラインで出来ます。

2021/08/21(土)OpenLDAP 2.5系の導入はまだ駄目っぽい・・・

2021/08/21 2:46 サーバ運営・管理
10年以上の永らくの期間、OpenLDAP は 2.4 の時代でしたが、今年(2021)年の4月末に OpenLDAP 2.5 系がリリースされています。
2.5.4 からリリースされ、現在の最新バージョンは 2.5.7 です。
FreeBSD もサポートプラットフォームになっています。
最近は開発コアメンバーがどうもアンチBSDっぽいんですが、元々はBSD系で開発が進められていた記憶があります。
※2023/02/26 追記
当方では、2022年9月中旬に OpenLDAP 2.6.3 にて、OpenLDAP 2.4系からの移行が正常に機能するようになったことを確認しました。
運用を考慮すると、OpenLDAP 2.5 系を採用した方がよいかもしれませんが、動作確認を OpenLDAP 2.6系にて、作業の合間でやっとのことで確認したため、そのまま OpenLDAP 2.6系を使っています。
恐らく、OpenLDAP 2.5系は、同時期リリースの 2.5.13 ~ なら使えそうですが、当方では OpenLDAP 2.5系の検証は、そのような時間が取れず、行うことができません。
当方で 2.5 系にすべく、アップデートを試みたですが、結局『まだ使い物にならない』が結論です。
データを登録しても、
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 fd=13 ACCEPT from IP=[::1]:37442 (IP=[::]:389)
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=0 BIND dn="cn=admin,dc=isp" method=128
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=0 BIND dn="cn=admin,dc=isp" mech=SIMPLE bind_ssf=0 ssf=0
Aug 20 04:30:34 www0 slapd[21837]: mdb_opinfo_get: err Bad file descriptor(9)
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=0 RESULT tag=97 err=0 qtime=0.000012 etime=0.000111 text=
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=1 SRCH base="dc=isp" scope=2 deref=0 filter="(objectClass=*)"
Aug 20 04:30:34 www0 slapd[21837]: mdb_opinfo_get: err Bad file descriptor(9)
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=1 SEARCH RESULT tag=101 err=80 qtime=0.000006 etime=0.000046 nentries=0 text=internal error
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 op=2 UNBIND
Aug 20 04:30:34 www0 slapd[21837]: conn=1005 fd=13 closed
のように、mdb_opinfo_get: err Bad file descriptor(9) という内部処理エラーが発生し、情報が取得できません。
OpenLDAP のエラーも 80(Internal Error) が返り、どうにも出来ません。
何故か、付属のテストプログラムは普通に機能するみたいなんですけどね。。。

少しデバッグをしてみましたが、どうも結果を出力する際に、何故か Read 処理をしようとしているようで、これが「Bad file descriptor」の原因を作っているみたいです。根深そうなので、バグ潰しに時間を割けない当方は、当面は、従来通り OpenLDAP 2.4系を使い続けることにしています。

その他にも、テストプログラムに不具合があります。うち2つは、BSD系 sed と、GNU 系 sed の仕様が異なるからのような感が。。。

先ず、構築の際の configure オプションは、
./configure --enable-crypt=yes --enable-rlookups --enable-ldap=yes --enable-mdb=yes --enable-perl=yes --with-fetch --with-tls --enable-overlays=yes --without-cyrus-sasl --disable-dynlist --with-pic
これで、幾つかの Warning が出るが、コンパイルは正常終了します。但し、FreeBSD の BSD系Make コマンドだと、
Entering subdirectory liblber
make[2]: "/usr/local/src/openldap-2.5.7/libraries/liblber/Makefile" line 302: Need an operator
make[2]: "/usr/local/src/openldap-2.5.7/libraries/liblber/Makefile" line 304: Need an operator
make[2]: Fatal errors encountered -- cannot continue
make[2]: stopped in /usr/local/src/openldap-2.5.7/libraries/liblber
*** Error code 1
のようなエラーとなってしまうため、代わりに gmake (GNU系make) を使用します。

OpenLDAP 2.4系のように、コンパイルに先立ち、FreeBSD 10系以降で生じる configure の問題(FreeBSD 1.x系と誤認する問題)回避のためのスクリプト修正は不要です。
gmake depend
gmake
のあと、
gmake test
で、テストするのですが、 test022-ppolicy・test079-proxy-timeout・test082-remoteauth は、FreeBSD ではそのままでは動作しません。
<<<<< Starting test022-ppolicy for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
Using ldapsearch to check that slapd is running...
Testing redundant ppolicy instance...
Using ldapadd to populate the database...
Testing account lockout...
sed: 1: "s/.*seconds_before_unlo ...": RE error: trailing backslash (\)
Waiting seconds for lockout to reset...
usage: sleep seconds
ldapsearch failed (49)!
<<<<< test022-ppolicy failed for mdb after 8 seconds
(exit 49)
gmake[2]: *** [Makefile:301: mdb-yes] エラー 49
gmake[2]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake[1]: *** [Makefile:287: test] エラー 2
gmake[1]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake: *** [Makefile:299: test] エラー 2
これは、tests/scripts/test022-ppolicy を以下のように修正します:
106    DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
107  -     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*seconds_before_unlock=\(\d*\)/\1/p'`
107  +     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*seconds_before_unlock=\([0-9]*\)/\1/p'`


122    DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
123  -     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\(\d*\)/\1/p'`
123  +     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\([0-9]*\)/\1/p'`


492    DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
493  -     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\(\d*\)/\1/p'`
493  +     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\([0-9]*\)/\1/p'`


737    DELAY=`$LDAPSEARCH -D "$MANAGERDN" -H $URI1 -w $PASSWD \
738  -     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\(\d*\)/\1/p'`
738  +     -b "$USER" -E accountUsability 1.1 | sed -n -e 's/.*expire=\([0-9]*\)/\1/p'`
<<<<< Starting test082-remoteauth for mdb...
running defines.sh
Running slapadd to build slapd database... DB tweaks...
Starting slapd on TCP/IP port 9011 for configuration...
Loading test remoteauth configuration...
Preparing second server on ldap://localhost:9012/ and ldaps://127.0.0.1:9013/... loading data... tweaking DB contents... starting up...
Waiting 7 seconds for slapd to start...
Saving generated config before server restart...
Checking bind handling... 1 2 3 ok
Stopping slapd on TCP/IP port 9011...
Starting slapd on TCP/IP port 9011...
Saving generated config after server restart...
Checking bind handling... 1 2 3 ok
Stopping slapd on TCP/IP port 9011...
Testing slapd.conf support...
sed: 1: "s,database\s*monitor, ...": RE error: trailing backslash (\)
Starting slapd on TCP/IP port 9011...
Saving generated config from a slapd.conf sourced server...
ldapsearch failed (32)!
<<<<< test082-remoteauth failed for mdb after 13 seconds
(exit 32)
gmake[2]: *** [Makefile:301: mdb-yes] エラー 32
gmake[2]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake[1]: *** [Makefile:287: test] エラー 2
gmake[1]: ディレクトリ '/usr/local/src/openldap-2.5.7/tests' から出ます
gmake: *** [Makefile:299: test] エラー 2
tests/scripts/test082-remoteauth を以下のように修正します:
312    echo "Testing slapd.conf support..."
313 -  sed -e "s,database\\s*monitor,\\
313 +  sed -e "s,database[ \f\n\r\t]*monitor,\\
あと、test079-proxy-timeout も何か変なのですが、下記の修正でテストは成功します。
tests/scripts/test079-proxy-timeout を以下のように修正します:
119   RC=$?
120 - if test $RC != 0 ; then
120 + if test $RC = 0 ; then
121           echo "ldapsearch failed for base: dc=idle-timeout,$BASEDN ($RC)!"
test079-proxy-timeoutの修正は、ちょっと自信がありません・・・

英語でのコミュニケーションが出来ない故、誰か代わりに報告してくれないか、と他力本願モードです。。 orz

2021/06/07(月)CAや証明書に問題無いのに「不正な証明書」となる・・・

2021/06/07 7:04 サーバ運営・管理
どうも、Thuderbird を使っていると、この現象に悩まされる模様……
厄介なのは、普通の受信操作ではこのメッセージは出ず、電子メールアカウントを指定して受信を試みることや、電子メールの送信操作で初めて表示されるというところ。
こんな感じです:
20210607_1.png


Thuderbird 単体でもこのメッセージが表示され、対処方法は、
https://www.atmarkit.co.jp/ait/articles/1702/09/news032.html 〔ThunderbirdでプライベートCA発行の証明書がエラーになる場合の対策方法(Windows)@IT〕 あたりで示されてはいます。

しかしながら、これをやっても現象が解消しないことがあります。
何故なら、アンチウィルスソフトウェアでTLS/SSL な通信を監視しており、「大手企業以外のCAをプライベートCA」と定義し、それ自体を「不正」と見做すことが多々あるため。
当方の環境も ThunderBird + Avast! な環境で問題の解消は出来ませんでした。

このモーダルウィンドウは、ThunderBird が表示しているのですが、大手企業ではないところで生成したCAは一律に「不正」という暴挙な扱いを Avast! でしているため、元凶は Avast! なのです。
一応、回避方法は示されていますが、(https://support.avast.com/ja-jp/article/Troubleshoot-invalid-email-certificate/

これをやっても当方の環境では、どうにも上手く解消せず、結局
20210607_2.png

のようにして「セキュリティ例外を承認」という策で回避しました。
CAや証明書自体には全く問題が無いからです。

2021/04/18(日)なんと! FreeBSD 13 から、ソースコード管理が subversion から git へ・・・

2021/04/18 5:47 サーバ運営・管理
2021/04/13 付けで、FreeBSD 13 が公開されました。
今回から、aarch64(arm64) と称されるアーキテクチャが amd64 と同等の Tier 1 に、
最初のTier 1 サポートになった i386 が Tier 2 に変更となっています。時代の変化です。
aarch64 は Raspberry pi に代表される小型のボードが主な対応機器になります。

Tier 1 は、フルサポートが保証されるプラットフォームで amd64 と aarch64 が該当、
Tier 2 は、実使用出来るものの、新機能追加やセキュリティサポートが積極的に行われないバージョンで、最も多くのプラットフォームがこれです。

FreeBSD の Tier ランクは4つあり、Tier 3 が実験的アーキテクチャ(FreeBSD 13 では該当なし)、
Tier 4 は「サポート終了宣言」のアーキテクチャで、現在は、pc98(NEC系の古いパソコン) と sparc64(20年近く前にかなり普及していた、サンマイクロシステムズのワークステーション) が主に該当します。

前置きが長くなりましたが、今回から変更になったものがもう一つ。ソースコードの管理です。。
リリースが近くなってから話には聞いていたものの、『実に厄介だ』というのが第一印象。

いつものように、メンテナンスのためにソースコードからアップデートかけようと、
ソースコード取得を下記のように試みるが・・・
20210418.png

このように「そんなものは無い」と拒絶されます。

今まではOSバージョンアップデート時には、/usr/src と /usr/obj 配下をまっさらにしてから、
# svnlite checkout https://svn.freebsd.org/base/releng/xx.x/ /usr/src
パッチアップデート時には、
# svnlite update
みたいな形で、と直感的なものがあったが、今回からはそれぞれ、
# cd /usr
# git clone -b releng/xx.x ssh://anongit@git.freebsd.org/src.git
# cd /usr/src
# cd /usr
# git pull
# cd /usr/src
とする必要がある。
-b に続く文字列は FreeBSD のリリースブランチ(タグ名とも称す)を示し、
FreeBSD 12.2 だと releng/12.2 FreeBSD 13.0 だと releng/13.0 FreeBSD 13-stable だと stable/13 のようになります。

慣れの問題なのでしょうが、git の第一印象は悪い(当方と同世代なエンジニアは概ね同じ印象を持っている人が案外多い)のもあり、抵抗感がややあります。

git ツールはデフォルトではインストールされていないので、
portsツリーを最新版にしてから、
# cd /usr/ports/devel/git
# make install
# rehash
みたいなコマンドを実行して、git をインストールすることが必要なのです。
ただ、ソースコード取得は subversion よりは高速なようです。

また、今回から、make buildworld , make buildkernel にかかった所要時間が秒数で表示されるようになったようです。
コンパイルにかかる所要時間は、FreeBSD 12 より若干高速になったようです。