FreeBSD 13.1-R ではフツーに NTFS が使えている。

11月 102022
 

僕が持っている色々な PC は WindowsOS と FreeBSD でマルチブートしています。デスクトップ PC の場合は M2.SSD の他に SATA 2.5 インチ SSD と、更に USB HDD を接続して、全てのストレージは NTFS と UFS (ZFS ではない;-) に分割して、どちらの OS でも高速アクセスと、ビッグデータ蓄積領域を確保している状態です。

普段は FreeBSD を利用しているのだけど、たまに Windows11 を起動してアプリを利用したり、蓄積していたデータをファイルサーバにアップして、再度 FreeBSD を起動してファイルサーバから取ってくる。とかしていましたが、今後はそーいう動作は必要なくなります。

FreeBSD 13.1-RELEASE (正確には 13.0-R 辺りからかな？) では NTFS 領域がマウントできて、かつ FreeBSD から rw アクセスが可能となりました。 sysctl で vfs.usermount=1 などとすると、一般ユーザ権限でマウントして、かつ、設定によっては自動的にマウントできたりします。

そして KDE5 などを使っていると dolphin (KDE5 のファイルマネージャ) から簡単にアクセスできるようになります。

設定方法について、順番に見ていきましょう。

 
1. ports からインストール
まずは ports から sysutils/fusefs-ntfs をインストールします。そして /boot/loader.conf に以下の行を書きます。

fusefs_load=”YES”

 
これで完了です。

 
2. 実際にマウント
僕のデスクトップ PC の場合、 FreeBSD の起動時に以下の SSD と HDD が認識されています。

$ dmesg | grep nvd
nvd0:  NVMe namespace
nvd0: 488386MB (1000215216 512 byte sectors)
Trying to mount root from ufs:/dev/nvd0p5 [rw]...
$
$ dmesg | grep da0
ada0 at ahcich1 bus 0 scbus1 target 0 lun 0
ada0:  ACS-4 ATA SATA 3.x device
ada0: Serial Number S5RRNF1R566155H
ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes)
ada0: Command Queueing enabled
ada0: 953869MB (1953525168 512 byte sectors)
da0 at umass-sim0 bus 0 scbus6 target 0 lun 0
da0:  Fixed Direct Access SPC-3 SCSI device
da0: Serial Number DCC77FFFFFFF
da0: 40.000MB/s transfers
da0: 3815447MB (7814037168 512 byte sectors)
da0: quirks=0x2
$
$ gpart show /dev/nvd0
=>        34  1000215149  nvd0  GPT  (477G)
          34        2014        - free -  (1.0M)
        2048      532480     1  efi  (260M)
      534528       32768     2  ms-reserved  (16M)
      567296   629467136     3  ms-basic-data  (300G)
   630034432    20971520     5  freebsd-ufs  (10G)
   651005952   167772160     6  freebsd-ufs  (80G)
   818778112   125829120     7  freebsd-ufs  (60G)
   944607232    41943040     8  freebsd-ufs  (20G)
   986550272    12124160     9  freebsd-swap  (5.8G)
   998674432     1529856     4  ms-recovery  (747M)
  1000204288       10895        - free -  (5.3M)
$
$ gpart show /dev/ada0
=>        34  1953525101  ada0  GPT  (932G)
          34       32734     1  ms-reserved  (16M)
       32768   819200000     2  ms-basic-data  (391G)
   819232768  1134292367     3  freebsd-ufs  (541G)
$
$ gpart show /dev/da0
=>        34  7814037101  da0  GPT  (3.6T)
          34       32734    1  ms-reserved  (16M)
       32768  4096000000    2  ms-basic-data  (1.9T)
  4096032768  3718004360    3  freebsd-ufs  (1.7T)
  7814037128           7       - free -  (3.5K)

 
nvd0 が M2.SSD で / パーティション他がある、メインの SSD です。
ada0 は SATA SSD で da0 は USB HDD です。全て WindowsOS と FreeBSD で半分ずつ (NTFS と UFS で半分ずつ) 利用しています。

 

実際に NTFS をマウントしてみるには以下のコマンドを利用します。

# ntfs-3g -o rw /dev/ada0p2 /mnt/
#  ls -l /mnt/
total 0
drwxrwxrwx  1 root  wheel  0 Nov 18  2021 $RECYCLE.BIN/
drwxrwxrwx  1 root  wheel  0 Nov 24  2021 Hyper-V/
drwxrwxrwx  1 root  wheel  0 Apr  3  2022 Data/
drwxrwxrwx  1 root  wheel  0 Nov 23  2021 Recovery/
drwxrwxrwx  1 root  wheel  0 Nov 18  2021 System Volume Information/
#
# umount /mnt

 
ports から sysutils/fusefs-ntfs をインストールすると ntfs-3g というコマンドがインストールされ、そのオプションに -o rw を指定しているので FreeBSD から書き込みもできるようになります。

これで NTFS の中のデータを取り出すために WindowsOS を起動することがなくなりました;-)。

 
3. automount しちゃうよ
KDE5 を利用している場合、 sddm からログインすると、ログインした段階で色々なファイルシステムを一般ユーザ権限でマウントしてくれる機能があります。

一般ユーザのアカウント takachan でログインすると、自動マウントさせたい場合には上にも書いた通り /etc/sysctl.conf に以下の設定をします。

vfs.usermount=1

 
この他に「KDE システム設定」でちょっと設定します。

「KDE システム設定」を起動して「起動と終了」→「Background Services」をチョイスすると、その中に [Removable Device Automounter] という項目があるのでこれにチェックを入れて更に再生ボタンを押してステータスを『実行中』にします。

次に同じく「KDE システム設定」の「リムーバブルストレージ」→「Removable Devices」をチョイスして、一番下にある [Automatically mount removable media that have never been mounted before] にチェックを入れて [適用]ボタンを押します。

これで、一旦ログアウトして再度ログインするか、service sddm restart してからログインしてみます。

と、いうか、sddm を再起動したあと、リモートから ssh でログインして df -k とかたたいて確認して、そのあとで sddm から一般ユーザでログインするとログイン後に様々なファイルシステムがマウントできることが確認できます。

僕のデスクトップ PC の場合はこんな感じになります。

$ df -k
Filesystem    1024-blocks      Used      Avail Capacity  Mounted on
*** 一部略 ***
/dev/ada0p3     549341012 187462520  317931212    37%    /opt
*** 一部略 ***
/dev/fuse       409599996  44718652  364881344    11%    /media/Samsung_SSD_870_QVO_1TB_S5RRNF1R566155H_p2
/dev/fuse      2047999996 534627440 1513372556    26%    /media/WDC_WD40_EZRZ-00GXCB0_DCC77FFFFFFF_p2
/dev/da0p3     1800630836 892226780  764353592    54%    /media/WDC_WD40_EZRZ-00GXCB0_DCC77FFFFFFF_p3
/dev/fuse       314733564  69794920  244938644    22%    /media/WDC_PC_SN730_SDBPNTY-512G-1006_213240808600_p3
/dev/fuse          764924    604264     160660    79%    /media/WDC_PC_SN730_SDBPNTY-512G-1006_213240808600_p4

 
/media/ ディレクトリのは以下にデバイス名付きで自動的に、一般ユーザ権限でマウントされます。デバイス名の後ろは p2,p3 とありますがパーティション名ですね。
Windows11 の C:\ や リカバリ領域なども自動マウントします。あと、UFS なファイルシステムも自動マウントしてしまいます。

Filesystem が /dev/fuse の場合は NTFS か FAT で /dev/da0p3 と表示されている場合は UFS ですね。 /media/Samsung_SSD_870_QVO_1TB_S5RRNF1R566155H_p3 は UFS ですが、これは /dev/ada0p3 で既に /opt にマウントしているので自動マウントされません。

 
KDE5 を利用した場合は opendesktop.org 由来の UDisks2 が利用されます。 FreeBSD 的かつ ports 的には sysutils/bsdisks が動作して plasmashell から dbus を経由して自動マウントしてくれるようです。
NTFS ファイルシステムを自動マウントしたくない場合は kldload fusefs.ko をやめれば良いです(あとで別件で説明します)。 UFS はもう完全に自動マウントしてしまうので止められない。自動マウント自体を停止したい場合は「KDE システム設定」の [Removable Device Automounter] を停止するしか手はないです。

 
KDE5 を利用している場合には KDE5 側で自動マウントしてくれますが、KDE5 を利用していな場合、 sysutils/dsbmd をイントールして /etc/rc.conf に dsbmd_enable=YES を書く必要があるかもしれません。

詳細については以下の URL を参照してください。

https://github.com/mrclksr/DSBMD

上記の dsbmd は ports のコンパイル時の make onfig で様々なファイルシステムを検知、自動マウントしてくれるようです。裏を返すとそれだけ色々な fusefs をインストールする。と、いうことになると思いますが。 ext4 とか HFS+ とかすげーな。みたいな・・。

一般ユーザ権限で色々なファイルシステムを自動マウント。遊んでみてください;-)。

 
4. 注意制限事項
注意点は二つ。

  • Bitlocker で保護されている NTFS はマウントできない
  • USB HDD の場合、スピンドルが止まっている場合がある

 
順番に見ていきましょうか。

Lenovo の ThunkPad X13 は Windows11 と FreeBSD のマルチブートですが、 Windows11 の NTFS は Bitlocker で保護されているので ntfs-3g ではマウントできません。以下のようになります。

# ntfs-3g -o rw /dev/nvd0p3 /mnt/
NTFS signature is missing.
Failed to mount '/dev/nvd0p3': 無効な引数です
The device '/dev/nvd0p3' doesn't seem to have a valid NTFS.
Maybe the wrong device is used? Or the whole disk instead of a
partition (e.g. /dev/sda, not /dev/sda1)? Or the other way around?

 
上記のようなエラーが出た場合は WindowsOS 側で「コンピュータの管理」→「ディスクの管理」を開いて当該パーティションが『Bitlocker で保護されてます。』と、いう表示があるか確認してみましょう。
この場合 kldload fusefs.ko していても意味ないです。リカバリ領域が見えても意味ないし・・。

 
次の USB HDD の場合ですが、SSD と違い外付け USB HDD の場合、ケースの機能によっては HDD の回転を停止するものがあります。自動マウントしている状態で HDD のスピンドルが停止していた場合、 cd /media/USB-HDD/ とか ls /media/USB-HDD/ すると、そこから HDD のスピンドルが回り始めます。この場合、ほぼほぼ CAM status: SCSI Status Error が出ます。そして、マウントしている状態だけど ls しても表示してくれない・・。 orz

外付け HDD の場合は cd とか ls でアクセスする前に以下のコマンドを打つ必要があります。

$ sudo camcontrol start /dev/da0

 
上記コマンドを打った段階で停止していた HDD (/dev/da0) のスピンドルが回り始めます。そのあとで cd とか ls でアクセスするようにしましょう。

 
以上、FreeBSD で NTFS に対するアクセスと、ファイルシステムの一般ユーザ権限での自動マウントについて書いてみました。

マルチブートしている PC の場合、もう一方の OS の中へアクセスしたい。と、いうことは多々あるのですが、今回は FreeBSD 側から WindowsOS の NTFS に対して簡単にアクセスする方法を書いてみました。

皆さんの環境でも是非、導入してみてください;-)。自動マウントはらくちんですよ。

AMD Ryzen7 環境の VirtualBox は動かない？

8月 282022
 

去年の 11 月にデスクトップ PC を新調しました。 CPU は AMD Ryzen7 PRO 4750G です。この環境において FreeBSD を起動 (当時は 13.0-RELEASE でしたが、今は 13.1-RELEASE が動作しています) しています。

素晴らしい CPUをチョイスしたので 8 Core/16 スレッドです。ports を make するとメモリが足りなくなって大変。みたいな・・。
この強力な CPU パワーを使い切るのは ports のコンパイル時しかないんかい?! になるのも悲しいので VirtualBox でもインストールして利用するべ。などと思っても、ちぃとも動作しない・・。

エラーとしてはこんな感じ。

文字列的には・・。

仮想マシン"WindowsServer2012_01"のセッションを開けませんでした。

VirtualBox can't enable the AMD-V extension. Please close all other virtualization programs. (VERR_SVM_IN_USE).

終了コード : NS_ERROR_FAILURE (0x80004005)
コンポーネント: ConsoleWrap
インターフェース: IConsole {872da645-4a9b-1727-bee2-5585105b9eed}

 
まぁ、OS は Windows Server でなくとも良いんですが、 Windows11 だったり FreeBSD なども上記エラーメッセージが出力されて起動しない・・。 orz
せっかくの 8 Core/16 スレッドな CPU なのに・・。

たまに VirtualBox を起動して『あ。やっぱり動かないね。』になるのよねぇ・・。
BIOS (UEFI) で AMD-V (AMD SVM) が有効になっていることは何回も確認している。

上記メッセージは日本語的には

「VirtualBox は AMD-V 拡張機能を有効にできません。 他のすべての仮想化プログラムを閉じてください。 (VERR_SVM_IN_USE)。」

らしいんですな。 Linux 方面では kvm と VirtualBox がケンカしていて仮想化資源を取り合っているんだそうで、VirtualBox を起動する際は kvm のカーネルモジュールを rmmod すれば良いらしい。

 
では、 FreeBSD は何が仮想化資源を掴んでいるのだぁ!? と、なるのですが、原因が全くわかりません・・。

cat /var/log/messages してみると・・。

vboxdrv: XXXXXXXXXXXXXXXX VMMR0.r0
vboxdrv: XXXXXXXXXXXXXXXX VBoxDDR0.r0
VMMR0InitVM: eflags=40246 fKernelFeatures=0x2 (SUPKERNELFEATURES_SMAP=1)

 
んー。見覚えのある文字列がありますが、これはなんなんざんしょ(?_?) と、いう状態です・・。

でもって、閃いた。試しに vmm.ko を kldunload してみた。

$ sudo kldunload vmm.ko
ivhd0: detached
amdiommu0: detached
pci0:  at device 0.2 (no driver attached)

 
man vmm してみると以下のように表示されますな。

NAME
vmm.ko – bhyve virtual machine monitor

DESCRIPTION
vmm.ko provides the kernel portion of the bhyve(4) hypervisor.

An Intel CPU with VT-x/EPT or AMD CPU with SVM support is required.

PCI device passthrough to a virtual machine requires hardware with VT-d support.

なるほどねぇ・・。こいつと競合していたのねぇ・・。と、いうことで、以降はすんなりと VirtualBox の仮想マシンが無事に起動したのでありました。

 
と、いうことで、VirtualBox が仮想化資源をつかめない。上記のようなメッセージが出力されている場合は、競合が発生しているので、とりあえず vmm.ko がロードされていないか確認すると良いと思います。

僕は AMD の CPU しか使ったことないけど、 Intel 系の CPU も vmm.ko は kldload できるのかな？

HP ProDesk 405 G6 SFF/CT 購入。

11月 202021
 

新しくデスクトップ PC を購入しました。『AMD FX おじさん』ではないですが、今まで利用していた PRIMERGY MX130 S2 は 2012 年に購入したのですなぁ。約 10 年使っていた。と、いうことか・・。速度的に『遅いっ!!』とは思ってなかったのでずっと使い続けていましたが・・。

今は半導体不足なときで、PC も決して安くはない。 AMD Ryzen7 PRO 4750G / Memory 16GB / 512GB SSD で 85,000yen 程度。納期は約一週間でした。

写真的には外側よりも内部のほうが嬉しいですよね。多分;-)。

HP ProDesk 405 G6 SFF/CT を買う前に一旦 Lenovo の ThinkCentre M75t Tower Gen2 を注文したんだけど、納期が約半年先、来年の 3 月になる。とのことだったので、待ってられないのでキャンセルした。ということがあるのであります。
HP は昔の日本 DEC の工場を持っているので納期が早いのねぇ。と、いう感じがします。

default の OS は Windows10 home でした。まだ Windows11 にはしていません。それよりも先に、すかさず FreeBSD のインストールを開始するのであります。

 
がっ!!驚きーっ!!よく調べずに今回の PC を買ったのですが、なんとっ!! FreeBSD/amd64 13.0-RELEASE がインストールできないのです。インストール用 USB メモリを Rufus で書き込みブートさせるのですが —<<BOOT>>— が出る前でフリーズしてしまうのでありました。『あらら？ もしかしてハズレな PC 買ってしまったか？』 などと調べ始めると・・。

ほおほお。 HP の デスクトップ PC や NotePC では 13.0-RELEASE 以前のバージョンではブートできないパターンがあるのねぇ。

https://forums.freebsd.org/threads/freebsd-on-hp-prodesk-g6.79252/

こちらのスレッドがまさしくビンゴ。 HP の PC は本当に悩みモノらしい。下まで読み進むと 14-CURRENT ではブートするようになったみたいなので、試してみたら確かにブートしてインストールできた。ホっ。
で、更に追加で 13.0-STABLE でも試してみたらこちらも無事にブートしたのでありました。ふぅ。

上記 URL のネタは 6 月には CURRENT 用の修正版が出たみたいだし STABLE に降りてくるのにはそんなに時間がかからないと思うので、今の 11 月辺りでは 13.0-STABLE でも OK 。と、いう感じなのでしょうねぇ。
と、いうことで今回インストールしたのは FreeBSD-13.0-STABLE-amd64-20211111-7647baa1e8f-248036-bootonly.iso になります。 2021/11/11 分の STABLE ですね。

一個前のエントリで書いていますが 13.0-RELEASE と同様に Windows の EFI パーティションをつぶすこともなく、インストールが完了しました。
Lenovo の PC と違い BitLocker を気にする必要がなく、素直にセキュアブートをオフにするだけでインストールすることができたのであります。

 
デバイス的なことを書きましょう。手元に Intel AX200 の代わりに購入した Intel Wireless-AC 9260 があったので、それを設置しました。 NotePC 用に買ったのでアンテナが無かったのですが Amazon で 760yen で追加購入。ただのケーブルが二本だけど、Wi-Fi モジュールに接続できる必要があるので、しっかりと選択する必要があります。長さはだいたい 30cm ほどかなぁ。ケース内にケーブルを這わせたあと、 FreeBSD で利用すると 20Mbps 程度、Windows で利用すると 200Mbps 程度出ます(自宅で可動しているスピード計測サイトでの計測;-)。

他に S-ATA 接続の Samsung SSD 870 QVO 1TB SVQ01B6Q も設置。 M2.2280 な SSD と合わせて 1.5GByte の容量を確保できました。

 
FreeBSD の pciconf -lv で特筆すべきデバイスをちょっと並べてみます。

none0@pci0:4:0:0:       class=0xff0000 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816e subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'Realtek RealManage BMC'
re0@pci0:4:0:1: class=0x020000 rev=0x29 hdr=0x00 vendor=0x10ec device=0x8168 subvendor=0x103c subdevice=0x872d
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller'
    class      = network
    subclass   = ethernet
none1@pci0:4:0:2:       class=0x070002 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816a subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111xP UART'
    class      = simple comms
    subclass   = UART
none2@pci0:4:0:7:       class=0x0c0701 rev=0x1a hdr=0x00 vendor=0x10ec device=0x816c subvendor=0x10ec subdevice=0x8168
    vendor     = 'Realtek Semiconductor Co., Ltd.'
    device     = 'RTL8111xP IPMI interface'
    class      = serial bus
    subclass   = IPMI
iwm0@pci0:5:0:0:        class=0x028000 rev=0x29 hdr=0x00 vendor=0x8086 device=0x2526 subvendor=0x8086 subdevice=0x0014
    vendor     = 'Intel Corporation'
    device     = 'Wireless-AC 9260'
    class      = network

 
HP の法人向け PC なので Intel でいうことろの vPro みたいなのを積んでいるようですが、 AMD の CPU 搭載なので Intel チップはちと無理か。そのかわりに Realtek のリモート管理系チップが搭載されているようです。俗に『AMD DASH』と呼ばれているヤツかな？ BIOS (UEFI) の設定メニューにオン/オフのオプションがありました。

が、当然 FreeBSD では認識されません。

iwm0 はあとから自分が取り付けたモノになります。 BIOS (UEFI) 的にもフツーに認識されているし Bluetooth も BIOS で認識しているので問題ないですね。
下の写真では、一番上の真ん中にあるある出っ張ったパーツです。アンテナが伸びているのは一枚目の写真でも解るでしょうか？

せっかく 13.0-STABLE にしたし Intel Wireless-AC 9260 もついたので、Iwlwifi を試してみるかねぇ。みたいな状態で https://wiki.freebsd.org/WiFi/Iwlwifi を試してみましたが・・。
https://people.freebsd.org/~bz/wireless/apply-wireless-latest.sh これはもうコードが古くてコンパイルも通らないですね・・。orz 20210904 のカーネルソースコードだと linuxkpi のコードにもずいぶんと改修が進んでいるだろうに・・。
と、いうことで FreeBSD での 802.11ac はまだ待ちの状態です。

 
Realtek の NIC は re0 で認識されてはいますが /boot/kernel/if_re.ko では認識できないチップです。最新のチップかな？ 最初『え゛。Realtek のチップ認識しないの？』と、驚いたのですが、今の世の中 ports からインストールするとか。 ports の net/realtek-re-kmod/ をインストールすると /boot/modules/if_re.ko が入ります。これを利用すると re0 で認識できます。
/boot/loader.conf はこんな感じで。

if_re_load="YES"
if_re_name="/boot/modules/if_re.ko"
hw.re.max_rx_mbuf_sz="2048"

 
あと、今回の PC は CPU が AMD Ryzen7 PRO 4750G なので GPU は Renoir です。これは ThinkPad X13 と一緒。 ports の graphics/drm-devel-kmod/ では X が起動しませんでした。
せっかく 13.0-STABLE を利用しているので linuxkpi 系は最新のソースコードがはいっているはず。と、いうことで GitHub から drm-kmod-master の最新版を取ってきました。今だと drm-kmod-5.7 になります。これをインストールしたらあーたっ!!

X はバリバリ動作する。

$ xrandr 
Screen 0: minimum 320 x 200, current 2560 x 1440, maximum 16384 x 16384
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)
DisplayPort-2 connected primary 2560x1440+0+0 (normal left inverted right x axis y axis) 527mm x 296mm
   2560x1440     59.95*+  60.00  
   2048x1152     60.00  
   1920x1200     59.88  
   1920x1080     60.00    60.00    59.94    30.00    24.00    29.97    23.98  
   1600x1200     59.95  
   1680x1050     59.95  
   1600x900      60.00  
   1280x1024     60.02  
   1440x900      59.95  
   1280x800      59.95  
   1280x720      60.00    59.94  
   1024x768      60.00  
   800x600       60.32  
   720x480       60.00    59.94  
   640x480       60.00    59.94

 
スゲースゲー。 ThinkPad X13 では 13.0-RELEASE と drm-kmod-5.5-wip でやっとこさ X を動かしたんだけど、 AC アダプタ抜くとカーネルパニックとかしていてまだまだだなぁ。と思っていたんだけどそんなこともなく。

あと、デスクトップ PC で 13.0-STABLE + drm-kmod-master (5.7) を利用すると suspend/resume できますっ!! デスクトップ PC で suspend/resume っ!! resume 後に X が死ぬ。と、いうこともなく本当に無事に、 WindowsOS のようにフツーに動作します。かなり感動的っ!!

 
今回、HP ProDesk 405 G6 SFF/CT にイントールしたあと、すかさず ThinkPad X13 も同じ構成にしてみたんだけど、上にも書いた通り AC アダプタ抜いてもカーネルパニックせず、 X は無事に動作するし suspend/resume も完璧に動作する。嬉しいっ!!

 
PC の技術はどんどん進化しているんだけど UEFI+CSM 時代は 10.1-RELEASE が一番良いと思っていた (suspend/resume していた)。そして、 UEFI 時代の FreeBSD は今度でる 13.1-RELEASE が最適なバージョンになるでしょうなぁ。今回利用した 13.0-STABLE の出来の良さに驚いたのでありました。

もし、手元に UEFI のみで動作するバリバリ最新の PC があるのであれば、是非とも FreeBSD をインストールしてみて頂きたいものであります。

いやぁ。今回は「イバラの道」というのは 13.0-RELEASE インストールでフリーズする以外、13.0-STABLE をチョイスして drm-kmod-master をインストールしたらスルっと、なんの苦労もなく動作したので、幸せな日々が送れて嬉しいのであります;-)。

このネタ、もう完結してしまって、続きませんf(^^;。

Let’s Note CF-SZ5 のタッチパッドクルクル OK。

7月 292021
 

前回のエントリでは Let’s Note CF-SZ5 の中古を購入して FreeBSD/amd64 13.0-RELEASE をインストールしました。そして、無事に動作して、なんちゃってな suspend/resume が動作しているところまで書いています。

 
さて、suspend/resume ですが、ports-CURRENT を追いかけていると、以下をインストールした辺りで正常に suspend/resume が動作するようになります。

  • drm-fbsd13-kmod-5.4.92.g20210720_1
  • mesa-dri-21.1.5
  • mesa-libs-21.1.5

もう、 /etc/rc.resume の中に色々書く必要ないです。

/etc/sysctl.conf に、以下の設定を記載すると、フタの開け閉めで suspend/resume ができるようになります。

# suspend/resume
#hw.acpi.lid_switch_state=NONE
hw.acpi.lid_switch_state=S3
hw.pci.do_power_suspend=0
hw.acpi.lid_switch_state=S3
hw.acpi.power_button_state=S5

 
すごいことですねぇ。 NotePC でバリバリ利用可能な FreeBSD の完成です;-)。

 
と、いうことで、ここからが本題。

以前のエントリでは Let’s Note のクルクル回すタッチパットでスクロールできない。と、書いていましたが、こちらも問題解決できたので、追加でエントリ書いてみたいと思います。

 
インターネット上で色々探してみると古い FreeBSD のバージョンでは特に気にすることなく動作していたみたいですが、12 系リリースの辺りからクルクルホイールさせるためには色々とワザが必要なって来たようです。

まず、カーネルがブートしたときの psm の状況を見てみましょう。
あ、このとき、/boot/loader.conf には以下のように設定してあります。

# psm/sysmouse
hw.psm.synaptics_support=1
hw.psm.trackpoint_support=1
#hw.psm.elantech_support=1

 
hw.psm.synaptics_support=1 が記載してあります。

それでもブート時には以下のように表示されます。

$ dmesg | grep psm
psm0:  flags 0x1000 irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0.
psm0: model Generic PS/2 mouse, device ID 0

 
このようになっていた場合、どう xorg の synaptics 設定を書いてもクルクルホイールできません。ただのタッチパッドの動作になります。この状態では、とあるおまじないをする必要があります。

おまじないが有効化されるとこのようになります。

$ dmesg | grep psm
psm0:  flags 0x6000 irq 12 on atkbdc0
psm0: [GIANT-LOCKED]
WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 14.0.
psm0: model Synaptics Touchpad, device ID 0

 
一番最後が model Generic PS/2 mouse か model Synaptics Touchpad の違いです。

ではどのようにすると model Synaptics Touchpad になるのか？

ソースコードをいじる必要があるんですねぇ・・。
いやぁ、ようやっと、ネタを見つけた。と、いうか・・。

https://github.com/wulf7/iichid/issues/53

pciconf -lv したときに ichsmb0 があると良いのですが・・。 kldstat で ichsmb.ko がロードされているか確認してみてください。

さて、上記 URL を確認してみると、タッチパッドが SMBus 経由で動作するかもしれん。と、いうことで /usr/src/sys/dev/atkbdc/psm.c を書き換えてみてください。と記載されています。

--- psm.c.orig  2021-04-13 10:02:53.550143000 +0900
+++ psm.c       2021-07-28 10:23:34.503022000 +0900
@@ -6315,7 +6315,7 @@
                    active_ports_count);
 
        /* psm has a special support for GenMouse + SynTouchpad combination */
-       if (active_ports_count >= 2) {
+       if (active_ports_count >= 1) {
                for (port = 0; port < KBDC_AUX_MUX_NUM_PORTS; port++) {
                        if ((active_ports_mask & 1 << port) == 0)
                                continue;

 
(active_ports_count >= 2) の部分を 1 に書き換えたあと、カーネルを作り直して再起動してると・・。
おやまぁっ!! psm0 が model Generic PS/2 mouse から model Synaptics Touchpad になったではありませんかっ!!

最近の Let’s Note のタッチパットでクルクルを有効化させるためにはコードを修正する必要がある。と、いう感じでしょうか。

 
あとは xorg の設定をしていきます。僕の場合、/usr/local/etc/X11/xorg.conf.d/70-synaptics.conf を用意しました。

Section "InputClass"
    Identifier          "touchpad catchall"
    Driver              "synaptics"
    MatchIsTouchpad     "on"
    MatchDevicePath     "/dev/input/event*"
    Option              "CircularScrolling"     "1"
    Option              "CircularScrollTrigger" "0"
EndSection

 
/dev/input/event は何番になっているか？ とかは libinput list-devices コマンドが良い感じかも。

あと、他の設定はどこに書いたら良いのか・・。僕の設定は /etc/sysctl.conf に書いていました。色々やったけど、動かなかったので /etc/sysctl.conf に書いていた。と、いう状態でしょうか・・。

# synaptics mouse 
hw.psm.synaptics.vscroll_hor_area=1300
hw.psm.synaptics.min_pressure: 16
hw.psm.synaptics.max_pressure: 220
hw.psm.synaptics.max_width: 10

 
こんな設定が入っていましたf(^^;;。これが効いているのかは sysctl で確認。と、いう感じです。
あと、KDE5 を利用している場合「KDE システム設定」の「入力デバイス」→「タッチパッド」で GUI 的に色々設定できるのでそっちで細かい設定をしたほうが直感的かも。

それにしてもようやっと、ホイールが動作してタッチパッドが動作するようになりました。嬉しいかぎかぎカギリですです。

ホイールクルクル回す他に、二本指で上から下に、もしくはその逆になぞるとスクロールもしてくれます。動作的には ThuinkPad X13 AMD みたいな感じかな。

 
さてと。これで Let’s Note CF-SZ5 はほぼぼカンペキな FreeBSD マシンになりました。 ThinkPad X13 AMD の Renoir が今でもまともに動作しないので、どうしてもこの NotePC が FreeBSD のメイン機として活躍していきそうな気配です。

 
あと、この NotePC は vPro が動くみたい(さすがはビジネス向けっ!!)みたいですが、 FreeBSD はそもそも vPro が動作しないようです。

ThinkPad X13 AMD で利用する FreeBSD 13.0-RELEASE。

4月 142021
 

以前のエントリで「ThinkPad X13 AMD で利用する FreeBSD。」と、いうのを書きました。このときに利用した FreeBSD のバージョンは FreeBSD/amd64 12.1-RELEASE でした。その後 FreeBSD/amd64 12.2-RELEASE が出たときに試しましたが、やはり Renoir は認識せず、 xf86-video-scfb を使い続けていた状態なのでありました。

 
途中 13-CURRENT も試したりしましたが、カーネルと drm-kmod 辺りの相性が悪く、カーネルパニックになったりしてそこはかとなく悲惨な状態だったので利用を断念して RELEASE バージョンに戻した。と、いう雰囲気だったのであります。

さて、「ThinkPad X13 AMD のタッチパッド。」のエントリに書いていますが、drm-v5.0-fbsd12.1.zip を github から拾ってきて、自分でコンパイルして試したりしていますが、2021/04/14 にリリースされた FreeBSD/amd64 13.0-RELEASE は drm-kmod がバージョン 5 になっているのできっと動くだろうと思い早速トライしたのであります。

 
結果としては、見事に玉砕。最新の ports CURRENT でもカーネルパニックが発生しました・・。orz
ThinkPad X13 AMD はコツコツと BIOS (と、いうか UEFI) のバージョンアップがあるのでその影響が出たのかな? と、いう感じがします。

あ。FreeBSD の ports CURRENT を持ってこようとして svn update しようとしても、2021/04/02 で SVN サーバ上の更新が止まっていますね。しょうがないので git 経由 /usr/ports を更新することにしましょう。と、言いつつ、ウェブで色々探したのですが、一発目のコマンドイメージがどこにも書いてないですね・・。 /usr/src を持ってくる方法はあるのですが・・。と、いうことで、一発目に実行するコマンドイメージを探すのにずいぶんと苦労しました。
以下のコマンドを一回だけたたきます。

# cd /usr
# mv ports ports.svn
# git clone --depth 1 https://git.freebsd.org/ports.git /usr/ports
<以下略>

 
二回目以降は

# cd /usr/ports
# git pull
<以下略>

 
これで良いです。
問題なのは、一回目に実行する git clone がどこにも書かれていない。と、いうことですかねぇ・・。

 
と、いうことで最新の ports CURRENT が手に入りました。これで Renoir に必要な ports を各種インストールすることにします。
だいたいこの辺りをインストールすると良いのではないかと思われます。僕の場合は kde5 を利用しているので、関連する ports もドドドと、当然インストールされますが。

  • drm-fbsd13-kmod-5.4.92.g20210202
  • gpu-firmware-kmod-g20210224
  • xf86-video-amdgpu-19.1.0_1
  • mesa-dri-20.2.3_1
  • mesa-libs-20.2.3

 
続いて、各種設定です。

 
1. /etc/rc.conf

kld_list="amdgpu.ko"

 
amdgpu.ko をロードする設定を記載します。

 
2. /boot/loader.conf

hw.amdgpu.exp_hw_support="1"

hw.psm.elantech_support="1"
hw.psm.trackpoint_support="1"

hw.vmm.amdvi.enable=1

vmm_load="YES"
cpp_load="YES"

ntb_hw_amd_load="YES"
amdpm_load="YES"
amdsmb_load="YES"
amdtemp_load="YES"
amdsbwd_load="YES"

smbus_load="YES"
smb_load="YES"
intpm_load="YES"
ichsmb_load="YES"
imcsmb_load="YES"

iichid_load="YES"
iicsmb_load="YES"
iic_load="YES"
ig4_load="YES"

 
hw.amdgpu.exp_hw_support=1 を記載すると amdgpu が使えるようになります。他、デバイスドライバを認識させるカーネルモジュールも書いておきました;-)。

 
3. /usr/local/etc/X11/xorg.conf.d/06-driver.conf

Section "Device"
    Option      "DRI" "3"
    Option      "AccelMethod" "exa"
    Option      "MigrationHeuristic" "greedy
    Option      "TearFree" "On"
    Driver      "amdgpu"
    BusID       "PCI:5:0:0"
EndSection

 
Driver に amdgpu を指定します。 BusID は pciconf -lv | grep vga を叩いたときに表示される番号を指定します。
準備ができたので、再起動して動作を確認して root で startx だぁーーっ!!

が、カーネルパニック・・。 orz
シューリョー・・。 orz

 
そんなばかなぁ・・。とか、思いつつ色々悪あがきで設定を見直してみましたが、ダメでした・・。引き続き /usr/local/etc/X11/xorg.conf.d/06-driver.conf の Driver は scfb の利用を継続・・。

 
と、いうことで、問題は ports の graphics/drm-fbsd13-kmod であることは多分明白です。これは 13-CURRENT をインストールしていたときに確認しています。 drm-fbsd13-kmod が 5.4 なので、もっと新しいバージョンはないのか?

 
https://github.com/freebsd/drm-kmod/tree/5.5-wip

 
こちらです。 5.5 です。他に drm-kmod-5.5-wip-amd と drm-kmod-5.5-wip-amd-pr がありましたが、これらは make が通りませんでした。
drm-kmod-5.5-wip.zip をダウンロードしてきて make && make install します。そのとき、ports からインストールした graphics/drm-fbsd13-kmod がインストールされていても問題ありません。 drm-kmod-5.5-wip を make install して上書きします。

 
これで、準備ができました。上の設定を全て有効にして再起動します。起動したらすかさず startx を叩きます。

ちょっと長いですが、dmesg を貼り付けます。

amdgpu: [powerplay] smu driver if version = 0x0000000a, smu fw if version = 0x0000000e, smu fw version = 0x00374700 (55.71.0)
amdgpu: [powerplay] SMU driver if version not matched
amdgpu: [powerplay] dpm has been disabled
amdgpu: [powerplay] SMU is initialized successfully!
[drm] Display Core initialized with v3.2.56!
[drm] Connector eDP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.eDP-1
[drm]   - kern.vt.fb.default_mode
[drm ERROR :dm_helpers_parse_edid_caps] Couldn't read SADs: -2
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector DP-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-2
[drm]   - kern.vt.fb.default_mode
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] VCN decode and encode initialized successfully(under DPG Mode).
[drm] fb mappable at 0x460BC7000
[drm] vram apper at 0x460000000
[drm] size 8294400
[drm] fb depth is 24
[drm]    pitch is 7680
WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 14.0.
VT: Replacing driver "efifb" with new "fb".
start FB_INFO:
type=11 height=1080 width=1920 depth=32
cmsize=16 size=8294400
pbase=0x460bc7000 vbase=0xfffffe010c9c7000
name=drmn0 flags=0x0 stride=7680 bpp=32
cmap[0]=0 cmap[1]=7f0000 cmap[2]=7f00 cmap[3]=c4a000
end FB_INFO
drmn0: fb0: amdgpudrmfb frame buffer device
drmn0: ring gfx uses VM inv eng 0 on hub 0
drmn0: ring comp_1.0.0 uses VM inv eng 1 on hub 0
drmn0: ring comp_1.1.0 uses VM inv eng 4 on hub 0
drmn0: ring comp_1.2.0 uses VM inv eng 5 on hub 0
drmn0: ring comp_1.3.0 uses VM inv eng 6 on hub 0
drmn0: ring comp_1.0.1 uses VM inv eng 7 on hub 0
drmn0: ring comp_1.1.1 uses VM inv eng 8 on hub 0
drmn0: ring comp_1.2.1 uses VM inv eng 9 on hub 0
drmn0: ring comp_1.3.1 uses VM inv eng 10 on hub 0
drmn0: ring kiq_2.1.0 uses VM inv eng 11 on hub 0
drmn0: ring sdma0 uses VM inv eng 0 on hub 1
drmn0: ring vcn_dec uses VM inv eng 1 on hub 1
drmn0: ring vcn_enc0 uses VM inv eng 4 on hub 1
drmn0: ring vcn_enc1 uses VM inv eng 5 on hub 1
drmn0: ring vcn_jpeg uses VM inv eng 6 on hub 1
[drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0
WARNING !(mask != 0) failed at /usr/local/src/drm-kmod-5.5-wip/drivers/gpu/drm/amd/display/dc/dc_helper.c:53
#0 0xffffffff80e3f803 at linux_dump_stack+0x23
#1 0xffffffff83604b0b at set_reg_field_values+0x4b
#2 0xffffffff83604a83 at generic_reg_update_ex+0x53
#3 0xffffffff8353932c at dp_disable_link_phy+0x5c
#4 0xffffffff8353d176 at core_link_disable_stream+0x416
#5 0xffffffff835a2aac at dcn20_reset_hw_ctx_wrap+0x15c
#6 0xffffffff8355f46b at dce110_apply_ctx_to_hw+0x2b
#7 0xffffffff835469de at dc_commit_state+0x51e
#8 0xffffffff8351a23f at amdgpu_dm_atomic_commit_tail+0x4bf
#9 0xffffffff83302f86 at commit_tail+0x46
#10 0xffffffff83302366 at drm_atomic_helper_commit+0x1e6
#11 0xffffffff833059e9 at drm_atomic_connector_commit_dpms+0xd9
#12 0xffffffff83333e3e at drm_mode_obj_set_property_ioctl+0x15e
#13 0xffffffff8330de6b at drm_connector_property_set_ioctl+0x2b
#14 0xffffffff8332cab2 at drm_ioctl_kernel+0x72
#15 0xffffffff8332ce18 at drm_ioctl+0x2c8
#16 0xffffffff80e3d053 at linux_file_ioctl+0x2e3
#17 0xffffffff80c76ced at kern_ioctl+0x26d

 
一応、認識しました。やったーっ!!
ただし、下のほうの # で始まる行は定期的にログが出力されます。まぁ、しょうがないか・・。

 $ xrandr
Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384
eDP connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 293mm x 165mm
   1024x768      60.03 +
   1920x1080     60.03*+
   1680x1050     60.03  
   1280x1024     60.03  
   1440x900      60.03  
   1280x800      60.03  
   1280x720      60.03  
   800x600       60.03  
   640x480       60.03  
HDMI-A-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-0 disconnected (normal left inverted right x axis y axis)
DisplayPort-1 disconnected (normal left inverted right x axis y axis)

 
ディスプレイが eDP として認識されました。と、いうことは xrandr –output eDP –brightness 0.5 も使えて、画面の明るさも変えられるようになりました。

FreeBSD 13.0-RELEASE になって /boot/kernel/backlight.ko というのができて、こいつが画面の明るさを管理しているみたいですが、kldload backlight.ko すると「dmesg 見てみろ。」とか言われいまいち動作していないようです。が、コマンド的に /usr/bin/backlight 30 とかすると画面の明るさが変わります;-)。

 
と、いうことで、Renoir (それはつまりは Vega10 のことですね;-) が無事に動作するようになり、ホッと一安心。そして、画面設定やコンポジタの設定は KDE5 の 「KDE システム設定」から色々できます。嬉しいことです。

 
最後にですが、FreeBSD/amd64 13.0-RELEASE になって、 ThinkPad X13 AMD で Renoir の他に動くようになったモノ、まだ動かないモノなどについて記載しておきます。

  • Realtek のカードリーダ (RTS522A) が rtsx0 で認識して動くようになりました。
  • 音はスピーカーからもヘッドホン端子からも出ます。
  • CPU の温度が拾えるようになりました。
  • Intel Wi-Fi 6 AX200 はまだ動きません。
  • Suspend して Resume で起きても動きません。電源ボタン押すと shutdown はしてくれるようですが、ネットワークは利用できません。

 
こんな感じでしょうかねぇ。それにしても、再度書きますが、 Renoir (それはつまりは Vega10 のことですね;-) が動作するようになったのは嬉しいことです。
AMD Ryzen 7 PRO 4750U で Xorg を動かしたいけど、カーネルがパニックしてしまう。と、いう人は github から drm-kmod-5.5-wip.zip を取ってきてインストールして見るのも一つの手だと思います。

次は suspend/resume にトライだぁ;-)。

Nginx の HTTP/3 その後。

1月 062021
 

以前のエントリで、「Nginx + quiche パッチで HTTP/3 にチャレンジ。」と、いうのを書いています。このエントリの『続編』を書いてみたいと思います。

と、いうのも色々あったからです。

簡単に書くと、あっという間にこのエントリは終わってしまいますf(^^;;。
ネタ的なモノを箇条書きにしてみると

  • nginx + quiche パッチでは SSI は動作しません
  • nginx + quiche パッチを利用した場合 RTMP モジュールが利用できないです

の二つになります。これが解れば詳細はどうでもいー。と、いう人はここでおしまいです。
『なんで?』と思った方は読み進んでくださいf(^^;;。

 
まず、上の部分の SSI についてですが、perl による index.cgi で SSI で吐き出すことと同じ動作をするモノを作成すると、無事に動作します。

以下はサンプルです。これは index.cgi 。

#!/usr/local/bin/perl
use strict;
print "Content-type: text/html\n\n";
print "<html>\n<head>\n";
print "<META HTTP-EQUIV=\"Content-type\" CONTENT=\"text/html;charset=utf-8\">\n";
print "<TITLE>IPv6 HTTP/3 Access Web page.</TITLE>¥n";
print "</head>\n<body>\n";

print "<br><h2>Hello HTTP/3 World.</h2><hr>\n";

my $word = "";
if ($ENV{'REMOTE_ADDR'} =~ /:/) {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv6 パケットを受け取りました。";
} else {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv4 パケットを受け取りました。";
}
print "$word<br><hr>\n";;

print "===> Protocol: $ENV{'SERVER_PROTOCOL'}<br>\n<hr>";
print "===> Access Port: $ENV{'SERVER_PORT'}<br>\n<hr>";

exit;

 
似たようなのを index.shtml と access.cgi でやるとこんな感じ。

こちらは index.shtml。

<HTML>
<HEAD>
<META HTTP-EQUIV="Content-type" CONTENT="text/html;charset=utf-8">
<TITLE>IPv6 HTTP/3 Access Web page.</TITLE>
</HEAD>
<BODY>
<ht>
Hello HTTP/3 World.<br>
<hr>
<!--# include file="./access.cgi"-->
<hr>
</BODY>
</HTML>

 
こちらは access.cgi。

#!/usr/local/bin/perl
use strict;
print "Content-type: text/html\n\n";
my $word = "";
if ($ENV{'REMOTE_ADDR'} =~ /:/) {
    $word  = "===> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv6 パケットを受け取りました。";
} else {
    $word  = "---> ";
    $word .= "$ENV{'REMOTE_ADDR'} から IPv4 パケットを受け取りました。";
}
print "$word<br><hr>\n";;
print "===> プロトコル: $ENV{'SERVER_PROTOCOL'}<br>\n<hr>\n";
print "===> アクセスポート: $ENV{'SERVER_PORT'}<br>\n";
exit;

 
index.html (index.shtml) に include があると、 Nginx + quiche パッチではまともに動作しないようです。 quiche パッチを詳しく追ってはいないのですが、どうやら include 部分がそげ落ちているようです・・。 orz

まぁ、今の段階では SSI を利用しないコンテンツを用意する必要がありそうです。

 
二個目。

テレワークなどで、PC にカメラを接続する機会が多いのですが、せっかく購入したカメラ。もっと色々な用途で使ってみたい。などと思うわけです。 USB Video Class 、俗に USB な UVC カメラを FreeBSD に接続し、 webcamd や obs-studio をインストールして『ストリーミングなどしてみんべ。』などと思うわけです。
このブログでも以前に「NotePCに付いているカメラを FreeBSD で使う。」と、いうのを書いていたりしますが;-)。

更に一歩進んで obs-studio をイントールした場合、配信先に RTMP サーバが必要になります。
Nginx はモジュールとして RTMP モジュールや Stream・Stream SSL モジュールなどを利用可能ですが、HTTP/3 を有効にする quiche パッチを適用した Nginx ではこれらのもジュールは利用できません。

以下は nginx.conf の設定の抜粋です。

load_module /usr/local/libexec/nginx/ngx_stream_module.so;
load_module /usr/local/libexec/nginx/ngx_rtmp_module.so;

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        access_log /var/log/nginx/access_rtmp.log;

        application webcam {
            live on;
            record off;
            wait_video on;
        }
    }
}

 
load_module のところで早くもエラーが出ます。

# service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] dlopen() "/usr/local/libexec/nginx/ngx_stream_module.so" failed (/usr/local/libexec/nginx/ngx_stream_module.so: Undefined symbol "SSL_set_tlsext_host_name") in /usr/local/etc/nginx/nginx.conf:7
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

 
もしくは

# service nginx start
Performing sanity check on nginx configuration:
nginx: [emerg] dlopen() "/usr/local/libexec/nginx/ngx_rtmp_module.so" failed (/usr/local/libexec/nginx/ngx_rtmp_module.so: Undefined symbol "HMAC_CTX_new") in /usr/local/etc/nginx/nginx.conf:7
nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed

 
みたいな感じ。

最初、どうして、SSL 系でエラーが出るのか解らなかったのですが、ports の www/nginx/Makefile とかソースを眺めていたら解りました。以前のエントリで、Nginx + quiche パッチを適用する場合 configure オプションに –with-openssl=/usr/ports/www/nginx-http3/quiche/deps/boringssl を指定しているんですね。
RTMP や Stream モジュールを利用する場合、ベタな openssl のソースのパスを指定する必用があるのですが、 quiche パッチを適用した場合、quiche 独自の SSL のコードを参照する必用があるので、 RTMP や Steram モジュールのコンパイルが通ったとしても、いざ動作させようとすると色々とシンボル名がなかったりするのですな。

 
と、いうことで、 Nginx に quiche パッチを適用した場合は、 HTTP/3 でのアクセス可状態なサーバで、SSI を利用しないウェブサーバとして利用するみとになります。

あ。Nginx + quiche パッチを適用したウェブサーバでも HTTP/2 や HTTP/1.1 、そして HTTP/1.0 (今では w3m くらいか?) でアクセスがあった場合 (それは、つまりは TCP でアクセスがあった場合かぁ？) には SSI は動作します。あくまで HTTP/3 でアクセスがあった場合のみ SSI の記述がある index.html がまともに表示されない状態になります。

SSI 使ったり RTMP・Strerm モジュールを利用したい場合は別にコンパイルしたサラの Nginx を用意する必用があります。 quiche パッチを適用しない Nginx では SSI や RTMP のサーバとして利用できるので、仮想マシンやコンテナで別立てするのがよろしいかと思われます。

 
ちなみに、Firefox は 72 から、 macOS や iPhone は Safari 14 から HTTP/3 がサポートされるようになりました(詳細については gugu ってください;-)。 macOS や iOS から HTTP/3 でアクセスできるようになると、ウェブサーバ担当者としてもいよいよ HTTP/3 の設定をしてサーバを起動してみたくなりますなぁ;-)。 ファイアーウォールの UDP Port:443 を開けるときが、今っ!! 来ましたっ!! ;-)。

Nginx + quiche パッチで HTTP/3 にチャレンジ。

1月 092020
 

2020 年の 正月に ports を csv update したら Firefox72 が降って来ていたので、そのまま FreeBSD/amd64 12.1-RELEASE にインストール。
しかし、ハタと考えてみた。『Firefox って 72 から HTTP/3 をサポートしたんじゃなかったけっ？』
果たして about:config で確認してみると

network.http.http3.enabled

と、いうのがあるではないかっ!! これをすかさず true にして google などを確認してみる。

HTTP/3 というのは、チョー簡単に言うと UDP で SSL 通信を行うものであります。詳細についてはウェブで情報を探してください;-P。
ファイアーウォールなどで UDP の 443 ポートなんてのは中々開いているものではないので、自宅なり、オフィスなりのファイアーウォールをまず先に確認してみましょう。

 
しかし、自分でも UDP:443 で通信するサーバを構築してみたい。色々探してみると apache24 はまだ、未対応ですが、 nginx は対応パッチが出ているようです。

まずは以下の URL にアクセス。

https://blog.cloudflare.com/experiment-with-http-3-using-nginx-and-quiche/

 
ここに記載されている git からパッチを取ってきて nginx のソースにパッチを当てて make しても良いんだけど、configure のオプションがややこすぃー。せっかく FreeBSD が手元にあるので ports の nginx に quiche パッチを適用してサーバ環境を構築してみましょう。

と、いうのが今回の趣旨です。ひと足お先に HTTP/3 を体験してみましょう。

このブログでは以前に apache24 で HTTP/2+TLSv1.3 対応にするエントリを書いていますが、今回は nginx のエントリになります。

 
1). ports の準備
以下に手順を書いてみます。

# cd /usr/ports/www/
# cp -pr nginx nginx-http3
# cd nginx-http3/
# git clone --recursive https://github.com/cloudflare/quiche
# make patch

 
原本となる /usr/ports/www/nginx/ は一応残しておいて nginx-http3/ というディレクトリで作業を始めます。
git から quiche を一式持ってきて、ports 的には make patch まで走らせます。make patch 時に make config が走ると思いますがお好みの設定で、絶対に忘れてはいけないオプションが HTTP_SSL と HTTPV2 です。 default で [X] になっていると思うんですけどね。

 
2). パッチ適用

# cd work/nginx-1.16.1/
# patch -p01 < ../../quiche/extras/nginx/nginx-1.16.patch
# cd ../..

 
nginx-1.16 用の quiche パッチなので、最新の ports ツリーであれば容易に適用できます。

 
3). ports の Makefile の編集
www/nginx-http3/Makefile を編集します。上記 URL では configure オプションが記載されていますが、それを FreeBSD の ports に書いて上げます。

diff -ur Makefile.orig Makefile
--- Makefile.orig       2020-01-03 12:00:17.947717000 +0900
+++ Makefile    2020-01-03 12:01:29.885305000 +0900
@@ -53,6 +53,9 @@
 
 HAS_CONFIGURE= yes
 CONFIGURE_ARGS+=--prefix=${ETCDIR} \
+               --with-http_v3_module \
+               --with-openssl=/usr/ports/www/nginx-http3/quiche/deps/boringssl \
+               --with-quiche=/usr/ports/www/nginx-http3/quiche \
                --with-cc-opt="-I ${LOCALBASE}/include" \
                --with-ld-opt="-L ${LOCALBASE}/lib" \
                --conf-path=${ETCDIR}/nginx.conf \

 
さーっ!! 準備ができたのでいよいよ make だぁっ!! などと思っては行けません。 quiche 側のソースコードのコンパイルには rust の cargo build を実行するので、なんとっ!! ここへ来て、 rust をインストール必要があります。
Firefox を自前でコンパイルする人は既に rust はインストール済みだと思われるため簡単ですが、持っていない人は /usr/ports/lang/rust/ を make install しましょう。速いマシンでも 30 分くらいかかると思いますけど。

 
rust のインストールが終わったらいよいよ nginx を make install します。

 
以上で HTTP/3 対応 nginx のインストールが完了しました。めでたしめでたし。

 
4). nginx.conf の設定
nginx.conf の設定は抜粋のみです。

user  www;
worker_processes  4;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  16;
}

http {

    autoindex off;

    server {
        listen [::]:443 quic reuseport;
        listen [::]:443 ssl  http2;
        listen      443 quic reuseport;
        listen      443 ssl  http2;

        server_name         nx.icmpv6.org;

        access_log  /var/log/nginx/access_nx_icmpv6_org.log;

        location / {
            root   /usr/local/www/nginx;
            index  index.html index.shtml index.php;
            allow  all;
        }

        ssl_certificate     /usr/local/etc/letsencrypt/live/nx.icmpv6.org/cert_chain.pem;
        ssl_certificate_key /usr/local/etc/letsencrypt/live/nx.icmpv6.org/privkey.pem;

        ssl_protocols       TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
        ssl_session_cache   shared:SSL:1m;
        ssl_session_timeout 5m;

        ssl_ciphers  HIGH:!aNULL:!MD5;
        ssl_prefer_server_ciphers  on;

        add_header alt-svc 'h3-23=":443"; ma=86400';

        http3_max_concurrent_streams 128;
        http3_max_requests           1000;
        http3_max_header_size        16k;
    }
}

 
listen は計 4 行ありますが、HTTP/3 で接続する場合には 443 quic reuseport の行が利用されます。 HTTP/3 に対応していないブラウザでは HTTP/2 で待ち受けるので、その設定は 443 ssl http2 になります。

そして、IPv6/IPv4 のデアルスタクです。

HTTP/2 も HTTP/3 も SSL が必須なので証明書を準備しましょう。 SSL 関連の設定もお忘れなく。

 
5). 実際に起動してみる
まず、何はなくとも以下のコマンドを叩いて確認。

$ netstat -an | grep 443
tcp4       0      0 *.443                  *.*                    LISTEN     
tcp6       0      0 *.443                  *.*                    LISTEN     
udp4       0      0 *.443                  *.*                    
udp4       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*                    
udp6       0      0 *.443                  *.*
$
# tcpdump -i em0 udp port 443

 
うぉー。udp4,6 で port:443が開いているっ!!
tcpdump を起動して、UDP の port:443 でパケットが流れているか、確認ができます。
また、nginx のアクセスログで "GET / HTTP/2.0" は TCP Port:443 の接続になります。 "GET / HTTP/3" が UDP の Port:443 の接続になります。
上記の nginx の設定ではもう HTTP/2 か HTTP/3 の接続になりますな。高級なブラウザの場合は HTTP/2 か HTTP/3で、 w3m でアクセスするとようやっと "GET / HTTP/1.0" でのアクセスになります。

 
あとは nginx の root パスにドカドカコンテンツを置いていけば良いと思われます。

しかし、 netstat -an で UDP port:443 を確認して待受状態になっているにも関わらず接続できない場合があります。
サーバ側で tcpdump で確認してみると、クライアント側からアクセスがあるだけで、サーバ側からの応答がない場合が・・。しかし、とあるタイミングでは接続できるので・・。今の所 nginx を再起動してみたりと、いう運用ですかねぇ。

あと、Firefox72 は HTTP/3 で接続できなかった場合 HTTP/2 や HTTP/1.1 にフェイルオーバーしません。 HTTP/3 の応答が無くともずっと待っている状態になります。 about:config の HTTP/3 のタイムアウト設定も見当たらないし・・。

 
と、いうことで、今から遊ぶには十分に楽しい HTTP/3 です。FreeBSD では ports を利用すると Firefox72 は使えるわ、 nginx は ports にパッチを当てるだけで configure オプションに悩まなくて済むわ。比較的容易に、そして十分に楽しめること間違いなしです。

ここいらで UDP の世界にどっぷりとハマってみるのも良いのではないでしょうか;-)。

thunderbird-60.6.1 を日本語化。

4月 082019
 

FreeBSD の ports-current を追いかけていると www/firefox と mail/thunderbird は i18n な ports/packages が削除されたことが解ります。
なので、firefox や thunderbird をインストールした人は各個人で Japanese Language Pack をアドオンからインストールしてね。と、いうことになるのでありますが・・。

それにしても thunderbird のアドオンから言語パック (Japanese Language Pack のこと)をダウンロードしようにも 52 のままで新しい thunderbird-60.6.1 に対応したものが見つかりません。

困ったのぉ・・。と、いうことで、どーすんべ・・。などと悩んだのですが Linux 方面から持ってくることを思いつきました;-)。

ちょいと調べてみると ubuntu 方面のモノが使えそうです。と、いうことで以下のサイトにアクセスして ubuntu の deb パッケージをダウンロードします。

https://packages.ubuntu.com/ja/xenial/amd64/thunderbird-locale-ja/download

僕は thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb というのをダウンロードしました。

これを適当なディレクトリで展開します。 FreeBSD の tar はなんでもかんでも xvzfp で展開できるのが嬉しいですねぇ;-)。

$ mkdir deb
$ cd deb
$ wget http://security.ubuntu.com/ubuntu/pool/main/t/thunderbird/thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb
$ tar xvzfp thunderbird-locale-ja_60.6.1+build2-0ubuntu0.16.04.1_amd64.deb
$ tar xvzfp data.tar.xz
$ cd usr/lib/thunderbird-addons/extensions/
$ cp -pr langpack-ja@thunderbird.mozilla.org.xpi ~/.thunderbird/乱数.default/extensions/
$ thunderbird
$

 
以上です。

1. ubuntu の deb パッケージから Japanese Language Pack を引っこ抜きます。
2. それを自分の thunderbird の環境の extensions/ の中に入れます。
3. thunderbird を起動し Japanese Language Pack を enable して再起動します。

以上で FreeBSD の thunderbird-60.6.1 でも日本語対応することができるのであります;-)。

当分の間は、thunderbird のバージョンアップを繰り返すごとに上記を実行する必要があるかなぁ・・。

japanese/thunderbird-langpack-ja/ なんて ports 作っても、きっと却下されるんだろうなぁ。ノラ ports でも作るかなぁ;-)。

HTTP/2+TLSv1.3 対応のサーバにしました。

3月 152019
 

このサイトはさくらのレンタルサーバ上にあるので自分の力で apache の設定を変えられはしないので、さくらの VPS 上で運用している icmpv6.org と motsuyaki.org を HTTP/2+TLSv1.3 に対応させてみました。

どちらのサイトも基本的に写真掲載付きのブログ(とわ言いつつ、最近バッタリ更新が止まりましたが・・)なので、写真とかドドドとあり、一回アクセスで大体 40 個くらいファイルを持っていくんではないかなぁ。と、思います。そんな感じなので HTTP/2+TLSv1.3 は非常に効果的ではないかと思われるわけであります。

HTTP/2+TLSv1.3 に対応するためには色々と準備が必要です。ここでは FreeBSD/amd64 12.0-RELEASE 上で動作している環境を HTTP/2+TLSv1.3 にしてみたいと思います。

1. FreeBSD の準備
手間を掛けたくないのであれば FreeBSD 12.0-RELEASE を用意しましょう。なぜかと言うと、それは OpenSSL のバージョンに関係するからです。
11.2-RELEASE の openssl は以下のバージョンで HTTP/2+TLSv1.3 に対応していないんですね。

$ openssl version
OpenSSL 1.0.2o-freebsd  27 Mar 2018

 
対して 12.0-RELEASE は以下のように表示されます。

$ openssl version
OpenSSL 1.1.1a-freebsd  20 Nov 2018

 
HTTP/2+TLSv1.3 に対応するためには OpenSSL は 1.1.0 以上のバージョンが必要です。

しかし、FreeBSD/amd64 12.0-RELEASE もまだまだ問題があってサーバとしては中々利用しづらいですよねぇ・・。
12.0-RELEASE の問題点はパッと思いつくだけで、

・NTT フレッツ回線を利用、IPv6 での通信時に ssh が利用できない
・shutdown -p now で、電源が落ちない PC がある
・drm-fbsd12.0-kmod はカーネルパニックするときがある(割と頻繁)

僕が直接的に感じたのはこれくらいでしょうか。まぁ、最後のは X が必要なのでサーバにはあまり関係ないですが・・。

 
FreeBSD 11.2-RELEASE を利用する場合には個別に OpenSSL をバージョンアップする必要があります。 ports に security/openssl111/ があるのでそれをインストールするのが良いかも知れませんが、僕は試していません。

 
2. apache24 の環境
FreeBSD の準備が整ったのでいよいよ apache24 の設定を見ていきます。

ports で www/apache24/ をインストールしますが、make config のときに [X] HTTP/2 と [X] SSL は当然として、さらにもう一個設定してあげる必要があります。

「Build enabled SESSION modules」のところで (*) MPM_EVENT を指定してあげる必要があります。

MPM_EVENT を指定すると httpd はマルチスレッドで動作することになるので WordPress などを利用している場合、php (僕は lang/php73/ を利用している) は [X] ZTS 付きでコンパイルし直す必要があります。

以上で準備 apache24 のが整いました。

 
3. apache24 の設定
HTTP/2+TLSv1.3 の設定をします。あちこちにファイルが散りばめられておりますな。

o. /usr/local/etc/apache24/httpd.conf

LoadModule ssl_module libexec/apache24/mod_ssl.so
LoadModule http2_module libexec/apache24/mod_http2.so
LoadModule mpm_event_module libexec/apache24/mod_mpm_event.so

 
上記モジュールの設定が必要です。他に SSL を有効にするとか色々あるのですが、その辺りは割愛します。

あと、既に ports から www/apache24/ をインストールしていて httpd.conf を編集している状態の場合、MPM_EVENT を有効にして make && make deinstall && make reinstall した場合は mpm_event_module の設定が httpd.conf に現れません。
『あれ？ MPM の設定はどこでしているのだ？』となるのですが、そのときは /usr/local/etc/apache24/modules.d/ の下の 000_mpm_prefork_fallback.conf を見ましょう。ここで mpm_prefork_module をロードしているので、その部分を mpm_event_module に書き換えてあげる必要があります。

o. /usr/local/etc/apache24/modules.d/000_mpm_prefork_fallback.conf

#LoadModule mpm_prefork_module libexec/apache24/mod_mpm_prefork.so
LoadModule mpm_event_module libexec/apache24/mod_mpm_event.so

 
ports からインストールし直した apache24 の設定の場合、これで大丈夫;-)。

o. /usr/local/etc/apache24/extra/httpd-ssl.conf

  :
その他の SSL の設定は略
  :
SSLProtocol -ALL +TLSv1.2 +TLSv1.3

<VirtualHost *:443>
      :
    その他の SSL の設定は略
      :
    SSLEngine on
    SSLCertificateFile    "/usr/local/etc/apache24/SSL/CRT.crt"
    SSLCertificateKeyFile "/usr/local/etc/apache24/SSL/KEY.key"

    ErrorLog  "/var/log/ssl_error.log"
    CustomLog "/var/log/ssl_access.log" common
    CustomLog "/var/log/ssl_request.log" "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"

    Protocols h2 http/1.1
</VirtualHost>

 
HTTP/2+TLSv1.3 にするので SSLProtocol で +TLSv1.3 してあげるのは当然でしょうかね。あとは VirtualHost ディレクティブの中で、最後に書いてある Protocols h2 http/1.1 を記述します。

これで良いのですが、SSL でアクセスがあったときに本当に TLSv1.3 でアクセスしているのかログを残したいためエラーログ・アクセスログの他に ssl_request.log というのを出力するように設定しました。
自分のブラウザからアクセスして TLSv1.3 でアクセスできているか、確認することができます。

 
とまぁ、設定はだいたいこんな感じでしょうか。 SSLCipherSuite をより強固にしてみる。なんてチューニングも良いかもですね。僕の場合は以下のように設定しています。あ、設定する場合は改行なしで一行で書いてください。

SSLCipherSuite \
ECDHE-RSA-AES128-GCM-SHA256:\
ECDHE-RSA-AES128-GCM-SHA:\
ECDHE-RSA-AES128-SHA256:\
ECDHE-RSA-AES128-SHA:\
ECDHE-ECDSA-AES256-GCM-SHA384:\
ECDHE-ECDSA-AES256-GCM-SHA:\
!LOW:!MD5:!aNULL:!eNULL:!3DES:!EXP:!PSK:!SRP:!DSS:!ADH:!DH

 

 
と、まぁ、こんな感じで準備が整いました。あとは apache24 を restart してアクセスしてみて ssl_request.log を覗いてみると TLSv1.3 で、どの暗号スイートを利用していて HTTP/2 でアクセスしている。と、いう情報が確認できるかと思います。

それにしても、ウェブページの表示は速くなったのか？ と、聞かれると、実測はしてないですが、感覚的に『多少速くなったかな？』みたいな雰囲気ではありますf(^^;;。

KDE5 で latte-dock を使ってみる。

9月 232018
 

KDE5 をインストールして、最近色々遊んでいるところです。デスクトップにも NotePC にもインストールしたので利用頻度はグググと上がりました。

そんなこんなで色々遊びつつ・調べつつしていたら latte-dock というのを発見しました。 KDE5 のパネルの代わりになるシロモノです。 FreeBSD の ports 的には deskutils/latte-dock になります。

まずはキャプチャを;-)。

レイアウトは My Layout・Plasma・Unity の、全部で三種類から選べます。 My LayOut は macOS 風、 Plasma は KDE5 の default のパネル風、 Unity というのは NextStep のランチャー風で、macOS の上にあるステータスバーみたいなのも表示されます。上記キャプチャはMﾝ Layout でドックの設定で配置してみました。

KDE5 のウィジェットはガシガシ登録できるし、プログラムのショートカットも登録可能です。 KDE5 の標準のパネルが macOS 風になった。と、いういう認識で問題ないかと思われます。と、いうのも macOS と一緒でマウスオーバーするとアイコンがズズズと大きくなります。おぉっ!!

そして、ドックの上で右クリックすると設定画面が現れてことこまかに色々と設定することができます。設定画面ではドックとして利用したときのアイコンサイズのだとか、ウィンドの下に隠れるとか、 3D や影を付けたり、現在利用中のアプリのアイコンを光らせたりとか。

フツーの KDE5 のパネルではつまらないと思う人は是非とも体験してみてください;-)。

ただ、一部動作が多少怪しいと思う点が、使い込むほど出てきているので、今使っているパネルは小さいままデスクトップ上に置いといたほうが良いかもです。バージョン 1 が出たときには安定してくれていると嬉しい;-)。

 
それにしても KDE3 の頃だったか？ パネルのアイコンが OS X (当時) 風に、普段は小さいのにマウスオーバーで大きくなったりする機能を持っていたんだけど Apple からクレームが入りその機能がなくなって、マウスオーバーしてもアイコンサイズが変わらなくなってしまった。と、記憶しています。 KDE 本体から分離したプロジェクトとして用意された latte-dock ではその機能が復活している。と、いうのはなんだか感慨深い;-P。

 
さてと。話が横道にそれましたが、設定画面のキャプチャを掲載しましょうかね。

僕の設定は日本語表示されています;-)。 この latte-dock というのは gettext で po ファイル化されているので独自に翻訳してみました。もうちょっと精査したあと kde-jp@kde.org に送る予定なので、次のバージョン辺りから最初から日本語化対応になっているのではないかと思われます。

あ。このブログでは何回か書いていますが僕は JKUG のメンバでもあるので、 KDE 自体の翻訳は特に気にはならずに Opendesktop.org に協力している次第です。

それにしても先行して日本語 po/mo フアイルが欲しい方は以下の URL に置きましたので持って行ってください。

https://icmpv6.org/Prog/ja.po/latte-dock-0.8.1-po-ja.tgz

deskutils/latte-dock を ports からインストールしたあと、ダウンロードした tgz を展開して、その中にある mo ファイルを /usr/local/share/locale/ja/LC_MESSAGES/ にほーりこんで latte-dock を再起動すると設定画面が日本語化されます。

日本語化されていたほうが設定しやすいとは思うのですが、一部へんちくりんな日本語や機能的に間違っている部分があるかと思われますが、随時更新して行きたいと思います。

 以前のエントリー