Chap-.39 NetBSD のお試し

　BSD の3種(FreeBSD、OpenBSD、NetBSD)の中では一番マイナーと思われるＯＳです。試したのは ver 11.0 です。
最初に包括的な自分の感想を書きますが、3種の中では一番完成度が高そうに感じました。
試す前の予想は、良い方から FreeBSD、OpenBSD、NetBSD の順だと思っていました。今は NetBSD が一番の様に感じます。
予想外な結果でした。
Sec-１．インストール及び GUI 化
Sec-２．日本語環境及びメーラー
Sec-３．インストール後に最初に試すこと(unix っぽく)
Sec-４．GUI(Desktop)利用の使い心地
Sec-５．CUIサーバでの運用
Sec-６．全体としての感想
Sec-１．インストール及び GUI 化

　例によってインストール作業は省略。
GUI 化は FreeBSD、OpenBSD と類似です。xfce4、xfce4-extras を入れれば多分大丈夫、笑。
xfce4-pulseaudio-plugin はありません。入れても意味が無いです(理由は後述)。

なお、使った機器は Ryzen-3400G、A320マザボ、メモリー16GB、250GB-SSD、Geforce-gt710、内臓イーサネット(realtek) です。

最初から Geforce が使えるのはとても良かったです。自分でドライバーを入れる必要すらありません。インストール後、すぐに Xfce4 が Geforce で綺麗に動きました。
Sec-２．日本語環境及びメーラー

　日本語環境として fcitx5-anthy、fcitx5-configtool、fcitx5-gtk、ibus-anthy、ibus-gtk を入れました。半年ほど前に試したときに fcitx と ibus 系を両方入れておいた方がうまく日本語環境が動きました。今回もそれにならいました。
.bashrc .xsession には何時もの記述を書き込みました。

.xsession
# for japanese IM
export LANG="ja_JP.UTF-8"
export GTK_IM_MODULE=fcitx
export XMODIFIERS=@im=fcitx
export QT_IM_MODULE=fcitx
#

.bashrc に
export LANG="ja_JP.UTF-8"
を記入

LANG の記述が重複していますが、これは念のため。
これでリブートしたら、「session と起動」で fcitx が動くように自動的に設定されていました。
xfce4-terminal では editーpreferenceーadvanced でdefault-character-encoding は utf8 にしています。
firefox、Libreoffice 等は問題なく日本語入力出来ました。

メーラーは claws-mail を試したら問題なく動きます。証明書付きのメールなども支障なく読めます。
なお、半年ほど前に試した時は送ったメールについて、表題部が文字化けしていました。
今回、設定を少し変えて無事に文字化け無くメールが送れました。
configurationーpreferrenceーMail handling (Sending) のところを UTF-8 にしました。それで問題なしにメール送信出来ます。
なお、Linux でチェックしてみたら、普通はそこは空欄のままで Linux では文字化けせずにメール送信出来ています。Linux では UTF-8 に指定する必要がありません。

今回は evolution については、試していません。

日本語環境の設定は BSD 3種の中で NetBSD が一番やりやすく、確実に動きました。良かった・・・・笑
Sec-３．インストール後に最初に試すこと(unix っぽく)

　例によって UNIX ギーク風にやることです。NetBSD は半年ほど前に少しいじっただけ。真面目にやるのはこれが始めてです。

*** IPアドレスの設定や管理 ***
　IP アドレスは /etc/rc.conf に

auto_ifconfig=yes
ifconfig_re0="192.168.0.hoge/24"

などと書くだけです。gateway を書き込むのは /etc/mygate です。
ホストネームも /etc/rc.conf に書き込みます。

*** リゾルバーの設定 ***
　/etc/resolv.conf を書き換えるだけです。普通です。

*** rc.local ***
　最初から動くように設定されています。最初から /etc/rc.local があります。

*** パケットフィルタ ***
　NetBSD は npf です。
基本的に、調子良く動きます。後発のパケットフィルタなので速度は多分速いと思います。確認してませんが・・・・笑。
npf については良いチュートリアルがネット上に見当たりません。少し馴染むのに苦労しました。マイナーＯＳの悲哀です、笑。
イメージとしては OpenBSD の pf と Linux の nftables を突つき合わせたような印象です。正直に言いますと pf より分かり辛い。
これは良いチュートリアルが無いためでもあります。

*** デーモンコントロール ***
　/etc/rc.conf と sysrc コマンドを組み合わせるやり方です。実際の必要スクリプトは /etc/rc.d/ の中にあります。
FreeBSD っぽいやり方で、使いやすさはマアマアです。
なお、npf のログをとるためのデーモンである npfd があります。これをコントロールするスクリプト(/etc/rc.d/npfd)にはちょいと記述が不足している模様です。
このファイルの最初の辺りにテキトーに

name1="npflog0"
ifconfig $name1 create
ifconfig $name1 up

と書き足します。これを加えないとnpfのログデーモン(npfd)が起動出来ないです。これは、ログデーモンが "npflog0" という仮想イーサネットデバイスに書き込むのに、それを作るスクリプトが欠けているためです。多分 NetBSD 作ってる人達が書き忘れている、汗。

*** 各種ソフトのコンパイル ***
　ccl は BSD 系の場合は FreeBSD でしか動かせないと思います。それ以外だと、guile、chicken、ecl、nginx、postfix 等がコンパイル出来ました。sbcl はハナから最新版がパッケージにあるので、セルフコンパイルはやりませんでした。多分、簡単に自力コンパイル出来そうです。
　ただし、guile は自力ビルドするのに少しくせがあります。まずネットで拾ってきたソースから gc-8.2.12.tar.gz を入れます。
次に、入れる必要があるパッケージは pkg-config くらいです。が、それでもコンパイル出来ません。やむなく・・・

# sysctl -w security.pax.mprotect.enabled=0

とやって、一時的にコンパイル(自力ビルド)出来る様にします。OpenBSD みたいに --disable-jit はやらなくても良いです。
次に

# paxctl +m /usr/pkg/bin/guile

と入力します。これで次からは # sysctl -w security.pax.mprotect.enabled=0 と打ち込まなくても guile が無事に動きます。guile のインストール先が /usr/pkg/bin/ と仮定。
この paxctl の設定(制限解除)はＯＳリブート後もシステムの中に情報として残ります。以後、常に guile が問題なく動きます。
この paxctl の設定をやらないと guile は動きません。
　NetBSD のメモリー管理はちょっと変わっています。プロセスがメモリー中を読んだり書いたりすることに対して、一定の制限がある模様。他のＯＳよりも制限が厳しそうです。やっている事は「書き込み可能メモリーを実行可能に変えさせない」という制限の様です。
実はこれに引っかかって guile がコンパイル出来ません。configure のオプションで何とかするのは無理そうなので、やむなくこの制限を一時的に外してコンパイルします。それが上記の
# sysctl -w 以下の記述です。
これはその制限をシステム全体で一時的に止める設定です。ＯＳリブート後はもとの制限された設定に戻ります。なので、次の
# paxctl +m 以下の入力は
guile に対してだけこの制限を外すためのものです。
この paxctl の設定はＯＳリブート後も残りますが、もしも何らかの理由で guile を再インストールすると消えます。なので私は rc.local の中にこの paxctl の記述を念のために書き込んでいます。

*** シリアル回線制御 ***
　cu が使えます。最初はモードが
crw------- 1 uucp wheel 66, 0 Sep hogehoge /dev/ttyU0
だったので
crw-rw---- 1 uucp wheel 66, 0 Sep hogehoge /dev/ttyU0
に chmod しました。自分は wheel に入っています。一度変えると、そのままなのでずっと使えます。
$ cu -l /dev/ttyU0
です。

　なお、使っているのは USB-serial のケーブルです。

***　その他　***
＊プログラムの実行速度とネット通信速度については、Sec-37. FreeBSD のところに書いたとおりです。プログラムの実行速度はちょい遅め。ネット通信速度は Slackware 等の70％くらいしかスピードが出ません。かなり遅いです。
＊NetBSD は普通の ntp なので同期確認は普通に $ ntpq -p とするだけです。

このセクションは全般に調子良いです。ネット速度以外には、特に問題ありません。
Sec-４．GUI(Desktop)利用の使い心地

　いわゆる GUI での使い心地。Windows 代替的な使い心地です。
＊libreoffice、firefox、gimp、claws-mail、evolution など、一通りのパッケージソフトがあります。
＊libreoffice、firefox には無事に日本語入力出来ます。使い心地に問題はありません。
＊claws-mail はSec-2. に書いたとおりで、うまく動きます。日本語入力も普通に出来ます。もう、面倒になって evolution は試していません。

なお、usb-speaker から音を出すには

# ln　-sf　/dev/audio2　/dev/audio

とやりました。2 はたまたまうちのシステムの接続状況での話です。これで youtube が視聴出来ました。
実は、audio0、audio1、audio2 と順にやって、2で音が出ました、笑。
多分、実際にはもっとスマートに関係デバイスファイルを見つけられるはずですが・・・・笑。
こんな風なので、xfce4-pulseaudio-plugin が必要ありません。あっても使えないでしょう。

某巨大掲示板ビュアーの jdim ビルド
　NetBSD、OpenBSD、FreeBSD でコンパイルして使えます。以下に NetBSD でのコンパイル手順

入れるパッケージ
gtkmm3, p5-ExtUtils-PkgConfig, meson, ninja (cmake も必要だったかも・・)

後はネット記載のとおり
https://https://github.com/JDimproved/JDim

$ git clone -b master --depth 1 https://github.com/JDimproved/JDim.git jdim
$ cd jdim
$ meson setup builddir
$ ninja -C builddir

作業は少し前でした。入れたパッケージの記憶はやや曖昧、笑。
記憶が違っていたら meson が「hogehoge が入ってないぞ」と表示するので、その都度入れれば良いです。それで、大抵はなんとかなります。
jdim/builddir/src/jdim にバイナリーが出来上がる。これを使う
アイコンは jdim/jdim.png があるのでこれを利用

　この Sec-4. の結論として、まるっきり Windows 代替にするには無理があると思います。しかし「サーバルームの開発機がメインでたまに GUI 利用もやる」という程度なら、十分満足出来ると思います。
実は、お試し前にはそれほど期待していませんでした。GUI 利用の出来栄えは FreeBSD、OpenBSD、NetBSD の順だろうと予想していました。
試して見たところ、私の実感としては NetBSD、OpenBSD が同格ただしちょっとだけ NetBSD の方が良い。その次に FreeBSD の順でした。まったく思ってもみなかった結果です。
パッケージの出来栄えは NetBSD と OpenBSD が同等ですが、Geforce のグラボが動く分、NetBSD の方が GUI 利用に良い(便利)と思います。
FreeBSD は GUI 利用に関してちょっと残念な結果でした。
Sec-５．CUIサーバでの運用

　まだインターネットサーバで運用を始めて、一週間程度です。しばらく使い込まないと是非の判断は出来ません。
今のところは原則として順調です。安定・堅牢な印象。
OpenBSD、Linux 等でやっていたセキュリティ対策は基本的にすべて NetBSD でも出来ました。

　ただし、組み込みで動かしていたプログラムが、ごくごくごく稀に取りこぼしました。動かない時があった、汗。
原則として動いていて、ごくまれに取りこぼすのは大方タイミング調整の問題です。
なので、smtp、http のサーバにほんの少しだけ遅延をいれてタイミング調整してみました。そうしたところ、それ以降は一切取りこぼしが無くなりました、笑。
全般的に NetBSD は少し速度が遅め。なので組み込みプログラミングだとタイミング調整しないと取りこぼしが出るようです。
Linux 等ではタイミング調整が必要になった事はありません。これまでタイミング調整が必要だったのは Common Lisp の中でも特に遅い処理系の Ecl を組み込みに使った時だけでした。
このことについては、自分は
「タイミング調整さえすれば安定運用できるのだから問題ない」「ただし、タイミング調整しなくても良いなら、それに越したことは無い。NetBSD は速度改善が望まれる」
と考えます。
Sec-６．全体としての感想

　CUI でのサーバ運用は組み込みでやや注意が必要ですが、基本的に問題なく安定・堅牢な印象です。
また GUI での運用はサーバルームでの開発機やサーバーソフトの試験運用機でまれに GUI アプリを使う程度なら、十分期待に応えられると思います。最低限の GUI アプリは一通り動きます。
ただし UNIX 代替的な事は一切やらずに、まるっきり Windows 代替で使うのは向かないと思います。それなら Debian や Ubuntu の方が良い。

　BSD 三種を比較すると、CUI サーバ運転はどれも満足ですが、GUI の利用だと出来栄えは NetBSD、OpenBSD、FreeBSD の順だと感じました。ただし NetBSD と OpenBSD の差はごく僅差です。
BSD のお試しを始める前に思っていたのと、逆の順でした。

個人的好みとしてはいまのところ 3 つの中で NetBSD が一番気に入りました。世間の空気(？)とは合致しません、笑。
いまはまだ少しあやふやな印象です。しばらく(２ケ月程度)使ってみれば印象はもっと固まるでしょう。

その他、CPUの脆弱性対策について
　この事については、既に発生から9年程度経過しています。まさかセキュリティがウリの BSD で対策が出来ていないはずは無いだろう・・・なんて思っています。なぜこんなことを書くのかと言いますと、チェック方法が良く分からないからです、笑。
OpenBSD の場合は以下の

https://https://why-openbsd.rocks/fact/meltdown-spectre/

等にもはや問題なさそうな事が書かれています。
しかし NetBSD については情報を得ることが出来ません。確認が出来ません。
よもや対策がやってないなんて事はないだろう、と個人的に勝手に思っているだけです。確たる根拠はありません、笑。
　NetBSD を始めとして BSD の情報の少なさはやや困るところです。
Debian や RedHat クローンだといわゆる「UNIX OSっぽい使い方をしている人達の情報発信」が多数見られます。情報集めに困りません。
それに比較すると、本来 UNIX の最も正当派であるはずの BSD ではその手の情報がネットで少ししか集められません。特に NetBSD はその傾向が顕著です。
NetBSD はユーザがとても少なそうです。
良い出来栄えなのに、不思議かつ残念です。