8月 072019
 

最近の FreeBSD は BIOS では PC の機能が使えなくなってきているものがちらほら出てきて、いよいよ UEFI に変えるべきかと思えてきた。
僕の持っているちょっと古いが、今でも現役の ThinkPad E145 を BIOS で利用するのは FreeBSD/amd64 10.1-RELEASE が一番良かった。その後 10.3-R -> 11.2-R にしてみると LCD の明るさが変えられなくなったりとか。
最近 11.3-R にしたら suspend して resume すると /dev/psm0 が『もう使えないよ。』みたいなエラーを吐きやがる。

psm0: failed to get status (doinitialize).
psm0: failed to enable the device (doopen).
psm0: failed to enable the device (reinitialize).

 
こんな感じ。 resume 後はもう USB なマウスを使うしか手がない。 /dev/psm0 だけでなく /dev/sysmouse (こっちはタッチパッド) も使えない状態。 moused も hald も悲しい状態。

/dev/psm0 みたいなのは BIOS べったりなので OS 的に UEFI 対応が進む FreeBSD ではいよいよ使えなくなってきているのだろうなぁ。などと、思い、それじゃ。と、いうことで UEFI で起動してみるかぁ。と、なったのであります。

 
以前、このブログでは ThinkPad E145 を BIOS+MBR の組み合わせで Windows8 と FreeBSD のマルチブートについてエントリを書いているのですが、今回はいよいよ UEFI+GPT でのブートになります。
当時 (上記 URL の記事は 2013 年 09 月に書いていますね) は、マルチブートに関する前例が中々見当たらず、インターネット上にもそれらしい記事がなかったのですが、最近は探せばちらほらと見つかるようになってきましたね。それは非常に良いことです。

と、いうことで僕もトライ。今回は、自分の今後のことも兼ねて、メモ的にその手順について書き留めておきます。まぁ、作業はほとんどが Windows10 上で行うんですけどね。

おおまかな手順は以下です。

0. Windows の回復 USB メモリの作成
1. Windows10 をまずインストール。もしくはパーティションを分割
2. FreeBSD 用 EFI パーティションを作成
3. FreeBSD/amd64 12.0-RELEASE をインストール
4. bcdedit でマルチブート設定
5. EFI パーティションにファイル設置
6. 電源投入で FreeBSD 起動

だいたいこんな感じでしょうか。では、はじまりです。

一応、断っておきますが、0 番目の「回復 USB メモリ」はもしものためにちゃんと作成しておきましょう。僕は Windows10 環境を何回もぶっ飛ばしていたりしますが、もし、そうなっても僕は責任持てません:-|。

 
1. Windows10 のインストール
新しい PC を買ってきたときや、今使っている PC には Windows10 が最初から入っていると思われます。
コントロールパネル -> コンピュータの管理 -> ディスクの管理 で、Windows10 に割り当てられているパーティションをちっこくしてあげる。詳細は書きませんけども。
新規に Windows10 をインストールする場合は C:\ を好きなサイズにして FreeBSD をインストールするスペースを残しておきます。
まず最初に Windows10 をインストールする。もしくは Windows10 がインストールされている状態。と、いうのが重要です。

 
新規に Windows10 をインストールする場合、ブート用の USB メモリを作成するところから始める人がいるかもしれませんが、僕の場合、今回は Windows のアプリで rufus と、いうのを利用しました。

バージョンにもよるかもしれませんが、 Windows10 の ISO ファイルは rufus に食わせると USB の起動イメージを BIOS+MBR で作るか UEFI+GPT で作るか指定できます。もしこの時に UEFI+GPT で作成した場合には NotePC の BIOS 設定は UEFI モードにしないとイントールできません。
Widowos10 の USB の起動イメージを BIOS+MBR で作ると、インストールした Windows10 は BIOS+MBR になってしまいます。今回は UEFI+GPT で USB 起動イメージを作成することになります。

作成した USB 起動イメージに合わせるために BIOS の設定を確認しましょう。 BIOS の設定については以前書いています。そちらを参考にしてください。

さてと。これで Windows10 のインストールが無事に完了しました。

 
2. FreeBSD 用 EFI 領域の確保
FreeBSD を ISO イメージから起動してメニューの [install] を選択して進めていくと、 Windows10 がインストールされているにも関わらず FreeBSD しかブートしない NotePC になってしまいます。 bsdinstall を利用して (それはつまりは FreeBSD をフツーにインストールする。と、いうことです) FreeBSD をインストールすると既に存在する Windows10 の EFI パーティションを上書きしてしまうからなんですね。

フツーの人 (それは takawata さん みたいにマニアではない人のこと;-) は FreeBSD はフツーにインストールすると思います。

しかし、フツーにインストールすると既にある EFI パーティションを上書きして潰してしまうので、新規に 100MB 程 EFI パーティションを作成してあげます。

Windows10 は既に起動しているはずなので、以下のコマンドを管理者権限の DOS プロンプトから実行します。

c:\ diskpart
DISKPART> list disk
DISKPART> select disk 0
DISKPART> list part
DISKPART> 
DISKPART> create partition efi size=100
DISKPART> format quick fs=fat32 label="FreeBSD-EFI"
DISKPART> assign letter="S"
DISKPART> 
DISKPART> list vol
DISKPART> list part
DISKPART> exit

 
簡単にコマンドイメージだけ書きました。

1). diskpart.exe を管理者権限で実行
2). 対象とするディスク番号を選択
3). ディスクのパーティション状況を確認
4). いよいよ create partition で EFI パーティションを 100MB で作成
5). fat32 でフォーマットして、ラベルは FreeBSD-EFI とする (お好きな文字列をどうぞ)
6). assign letter=”S” でおまじない;-)

 
これで FreeBSD の bsdinstall がアクセスする EFI パーティションが作成できました。 FreeBSD を何回インストールしても、インストール後に NotePC を再起動すると Windows10 が起動する状態になります。

上記 takawata さん の URL ではこの工程がないので Windows 側の EFI パーティションを守るために bsdinstall を利用しないで make buildworld しているんですね。あ。 takawata さんは『マニア』なのかもしれないですが、 make buildworld が好きな人なのですね。きっと;-)。

それにしても bsdinstall が既存の EFI パーティションを上書きしてしまうのが問題なんですね。メニューで上書きするかしないか選択できるようにすれば良いのに・・。

と、いうことで次は FreeBSD のインストールです。

 
3. FreeBSD のインストール
今回は FreeBSD-12.0-RELEASE-amd64-bootonly.iso をチョイスしました。もう、面倒なので Windows10 上で、やはり rufus を使い USB 起動イメージを作成しました。
FreeBSD の場合は、今度は BIOS+MBR でしか作成できません。なので、FreeBSD インストール時には今度は BIOS の設定を Legacy モードにする必要があります。

あとはフツーにインストール。パーティション分割のところで GPT を選択し、更に [Manual] を選択してHDD (最近は SSD か;-) の空き領域にインストールします。

インストールが完了してリブートします。 2. のところで書いた通り、先に FreeBSD 用 EFI パーティションを作成していると bsdinstall を利用しても Windows10 側の EFI パーティションはつぶれてないので、この時点で再起動後は Widnows10 が起動するはずです。
もし FreeBSD が起動してしまった場合は Windows10 がつぶれてしまった。と、いうことです。回復 USB メモリなどから Windows10 を復旧しましょう。

 
4. bcdedit でマルチブート設定
FreeBSD インストール後に再起動したら Windows10 が起動しましたが、インストールした FreeBSD はしっかり残っております。起動させるために Windows10 側で bcdedit を利用してエントリを作成してあげます。

以前、このブログでも BIOS+MBR 環境のときに bcdedit を利用して、Windows Boot Manager から Windows と FreeBSD をブートしていましたが、 UEFI+GPT の場合は Windows Boot Manager が利用できません。 UEFI+GPT でのマルチブート環境は Firmware Windows Boot Manager を利用してブートすることになります。

そもそも「Firmware Windows Boot Manager」とはなんぞや?と、なるのですが、簡単に言うと BIOS(UEFI) のブートセレクタです。
例えば HDD からブートするとか、CD や USB メモリからブートするとか、選択する画面は Fn キーを押してメニューを出しますが、それをどうやら「Firmware Windows Boot Manager」というようです。
CD や USB・HDD からブートするのと同じレベルのメニューに “FreeBSD” や “Windows Boot Manager” メニューが存在している状態になります。

ThunkPad の場合 (Lenovo の PC の場合) は電源投入時に F12 キーを押すとブートセレクタが現れます。メーカによっては F2 キーだったり F8 キーだったりするかもしれません。

これから、このブートセレクタに bcdedit でメニューを登録していきます。

 
まず、管理者権限の DOS プロンプトでフツーに bcdedit と叩くと「Windows Boot Manager」のメニュー画面の情報が出力されます。僕の知っていた bcdedit はこの、オプションなし状態の出力でした。

「Firmware Windows Boot Manager」の項目を表示するには以下のコマンドを打ちます。

C:\Windows\system32> bcdedit
C:\Windows\system32> 
C:\Windows\system32> bcdedit /enum firmware
C:\Windows\system32> bcdedit /enum all

 
/enum オプションをつけて、そのあとに firmware とすると「Firmware Windows Boot Manager」の項目を表示します。 all と打つと「Firmware Windows Boot Manager」と「Windows Boot Manager」の全ての項目を表示します。ここ、重要ですからね;-)。

まず、「Firmware Windows Boot Manager」に FreeBSD のメニューを追加します。

C:\Windows\system32> bcdedit /copy "{bootmgr}" /d "FreeBSD"
*** ここで UUID が表示される ***
C:\Windows\system32> bcdedit /set {UUID} device partition=\Device\HarddiskVolume2
C:\Windows\system32> bcdedit /set {UUID} path \EFI\FreeBSD\Boot\bootx64.efi
C:\Windows\system32> bcdedit /set fwbootmgr displayorder {UUID} /addfirst

 
以下のような雰囲気です。

1). /copy で “FreeBSD” というエントリを作成。このときに FreeBSD の UUID が割り当てられる
2). エントリ中に device を設定 (省略可)
3). エントリ中に path を設定
4). エントリ中の順番を設定

最後の 4). のエントリについて先に説明します。 /addlast で最後に追加することもできます。その場合 F12 キーを押さない場合は Windows10 が起動します。 /addfirst を指定すると先頭に追加され、 F12 キーを押さない場合は FreeBSD がブートするようになります。お好みで;-)。

上記コマンドを投入したあと、再度 bcdedit /enum firmware を叩いてみましょう。以下は抜粋です。

C:\Windows\system32> bcdedit /enum firmware

ファームウェアのブート マネージャー
--------------------------------
identifier              {fwbootmgr}
displayorder            {bootmgr}
                        {dd655fef-3160-11e9-8f42-a6c75caf7b54} <- 先頭に追加
                        {dd655fe9-3160-11e9-8f42-a6c75caf7b54}
                        {dd655fea-3160-11e9-8f42-a6c75caf7b54}
timeout                 2
<--- 略 --->
Windows ブート マネージャー                                       <- 今回追加
--------------------------------
identifier              {dd655fef-3160-11e9-8f42-a6c75caf7b54}
device                  partition=\Device\HarddiskVolume2
path                    \EFI\FreeBSD\Boot\bootx64.efi
description             FreeBSD
locale                  ja-JP
inherit                 {globalsettings}
badmemoryaccess         Yes
default                 {current}
resumeobject            {dd655fed-3160-11e9-8f42-a6c75caf7b54}
displayorder            {current}
toolsdisplayorder       {memdiag}
timeout                 30
<--- 略 --->

 
このあとに説明しますが、UEFI+GPT の場合、OS をブートさせるためには EFI パーティションにファイルを一個置いてあげる必要があります。FreeBSD の場合は、インストールされている FreeBSD の /boot/boot1.efi を上記エントリの device と path に指定したところに正しく置いてあげる必要があります。

記載内容を間違えると「Firmware Windows Boot Manager」で “FreeBSD” を選択しても何もアクションが起きません。

そして、この内容が、BIOS+MBR の頃のように

device                  partition=c:\
path                    \bootx64.efi

 
などと記載していると「Windows Boot Manager」側で認識して、ブートすると 0x000007d みたいなエラーが出力されます。

記載した内容と設置した場所を正しく一致させましょう。

 
ちなみに作成したエントリを消す bcdedit は以下になります。書いては消して、また書いて、ブートしないのでまた書いて・・。などと、いうとき用です;-)。

C:\Windows\system32> bcdedit /delete {UUID} /f
C:\Windows\system32> bcdedit /set {fwbootmgr} displayorder {UUID} /remove

 
一行目は bcdedit /copy “{bootmgr}” で作成したエントリ全てを消すコマンドです。このコマンドを実行すると「ファームウェアのブートマネージャー」からも削除されます。
二行目のコマンドは「ファームウェアのブートマネージャー」から削除するときのみ利用するコマンドです。例えば /addlast で一番最後に登録したけど、やっぱり /addfirst で先頭に登録したい。などとうとき、二行目のコマンドを実行したあとに再度 bcdedit /set fwbootmgr displayorder を叩く。と、いうときに利用します。

bcdedit で「Firmware Windows Boot Manager」に登録するコマンドはこんな感じでしょうか。

 
5. EFI パーティションにファイル設置
さてと。あと少しで環境が整います。 EFI パーティションに FreeBSD がブートするための boot1.efi を書き込んで上げます。他の PC 上で動作している FreeBSD から /boot/boot1.efi を持ってきて Windows10 側に保存して上げましょう。

まず、diskpart.exe でボリュームの確認です。

c:\ diskpart
DISKPART> list disk
DISKPART> select disk 0
DISKPART> list vol
  Volume ###  Ltr Label        Fs    Type        Size     Status     Info
  ----------  --- -----------  ----  ----------  -------  ---------  --------
  Volume 0         回復           NTFS   Partition    499 MB  正常
  Volume 1     C                NTFS   Partition    213 GB  正常         ブート
  Volume 2                      NTFS   Partition    574 MB  正常
  Volume 3                      FAT32  Partition    100 MB  正常         システム
  Volume 4         FREEBSD-EFI  FAT32  Partition    100 MB  正常         非表示
DISKPART>

 
EFI バーティションは Windows10 が作成したもの (Volume3) と FreeBSD インストール時に作成したもの (Volume4) と二つありますが、どっちを利用しても問題ありません。

Windows10 で EFI パーティションをマウントするためには以下のコマンドを利用します。

C:\Windows\system32> mountvol
C:\Windows\system32> mountvol z: /S
C:\Windows\system32> mountvol z: /D
C:\Windows\system32> mountvol z: \\?\Volume{874c2b19-1ada-4089-9a27-de7f61f38177}\
C:\Windows\system32> mountvol z: /D

 
mountvol.exe コマンドですが、オプションなしで実行するとヘルプと、下のほうにボリュームの一覧が表示されます。
Windows10 が作成した EFI パーティションを z:\ に mount する場合には二行目のコマンドを打ちます。
FreeBSD のインストール時に作成した EFI パーティションをマウントするには四行目のコマンドを利用します。 mountvol のオプションなしで実行した場合に下のほうに「現在のマウント ポイントとボリューム名の考えられる値:」で表示されたマウントポイントの *どれか* を指定します。
diskpart.exe の list vol や list part と見比べてじっくりと判断してください;-)。

ちなみに mountvol z: /D はumount するオプションです。

 
今回は FreeBSD インストール時に作成した EFI パーティションは利用せず、Widnows10 側の EFI パーティションを利用します。

C:\Windows\system32> mountvol
C:\Windows\system32> mountvol z: /S
C:\Windows\system32> z:\
z:\> mkdir EFI\FreeBSD\Boot 
z:\> cd EFI\FreeBSD\Boot 
z:\> copy c:\boot1.efi ./bootx64.efi
z:\> dir
z:\> c:\
C:\Windows\system32> exit

 
mountvol で Widnows10 の EFI パーティションを z: に mount します。 z:\ に行くと既に EFI というディレクトリが掘られています。そこに FreeBSD 用のディレクトリを作成し、c:\ に置いた boot1.efi という FreeBSD から引っこ抜いてきたファイルを bootx64.efi として保存します。
途中、ls ではなく dir コマンドで色々確認しつつ作業を行ってください。 設置場所は bcdedit コマンドで指定した device と path の各オプションと一致していることが重要です。

ちなみに mountvol で EFI パーティションをマウントしていると bcdedit /enum firmware で確認した場合の device パラメータの表示が変わってきます。 mountvol で mount している状態のほうが確認しやすいです。

 
さてと。これで全ての準備が整いました。Windows10 側でリブートしましょう。 /addfirst を指定した場合は NotePC 再起動後にスルスルっと FreeBSD が起動するようになります。

やったっ!!

もし FreeBSD が起動しなかった場合は bootx64.efi の設置場所が bcdedit で指定したものと合っているかじっくりと確認してください。

僕の場合ですが、大失敗・・。 copy c:\boot1.efi ./bootx64efi とやっていました・・。orz
これじゃ起動しません。rename bootx64efi bootx64.efi として事なきを得、無事に FreeBSD が起動したのでありました。ふぅ。そして、パチパチパチ。

 
6. 電源投入で FreeBSD 起動
さてと。僕の場合 ThinkPad E145 は FreeBSD メインで利用し、時々 Windows10 を利用する形態なので bcdedit /set fwbootmgr displayorder {UUID} /addfirsst で登録しました。これだと電源投入後はサクっと FreeBSD が起動します。

Windows10 を起動したいときには NotePC の電源投入後に F12 キーを押してブートセレクタを表示して「Windows Boot Manager」を選択すると Windows10 が起動するようになります。

 
さてと。最後に FreeBSD 12.0-RELEASE についてちょっと書いておきます。

今まで僕はずっと BIOS+MBR な FreeBSD しか使ったことがなかったのですが、今回初めて UEFI+GPT な FreeBSD を使うことになります。
一番上で書いた /dev/psm0 が resume 後に psm0: failed to get status となって使えなくなった事象は解決しました。やっぱり FreeBSD の ACPI 周りはどんどん UEFI に傾倒して行っているのね。と、再確認できました。

あと、ThunkPad E145 など AMD のグラフィックスチップ使っている PC 限定かもしれませんが、グラフィックスチップは graphics/drm-fbsd12.0-kmod で認識しています。今までは radeonkms.ko を指定していましたが、これを利用するとカーネルパニック頻発です。 amdgpu にしたら安定しました。 UEFI ブートとは相性が良くないみたいですね。 pkg-message にも書かれています。

しかし、 UEFI にしても acpi_video.ko が使えない状態なのは変わらず。なので、ディスプレーの明るさは変えられません。 AMD グラフィックスチップの悲劇か・・。

 
とまぁ、ツラツラと書いてみましたが UEFI+GPT にした PC において Windows と FreeBSD のマルチブートについて書いてみましたが、大きな点としては

1). bsdinstall は Windows 側の EFI パーティションを潰してしまう
2). 「Windows Boot Manager」ではなく「Firmware Windows Boot Manager」でマルチブートを実現

でしょうかね。

1). のほうは僕も過去に実はずいぶんとハマりました。どうして Windows10 が起動しないのだっ!!?? みたいな・・。知っている人はちらほらいるみたいですが、僕は Slack のとあるコミュニティで FreeBSD のエラい人に教えてもらいました。 FreeBSD のインストールのために EFI パーティションを一個作成する。ってことがミソですね。

ちなみにですが、/boot/boot1.efifat が、ここで書いてきた FreeBSD インストール前に作成した EFI パーティションの中身です。
bsdinstall が Windows10 側の EFI パーティションを boot1.efifat で上書きしています。 FreeBSD インストール前に EFI パーティションを作成すると bsdinstall は FreeBSD インストール前に作成した EFI パーティションに対して /boot/boot1.efifat が書き込まれ Windows10 側の EFI パーティションは無傷です。

mountvol z: \?\hoge\ で FreeBSD 側 EFI パーティションも mount できるので確認してみるのも良いかも。

2). のほうはある意味目ウロコですね。 Windows Boot Manager を捨ててその一個前のフェーズで FreeBSD をブートしてしまう。 grub とか、他のブートマネージャは不要で bcdedit でなんとかしてしまう。ってことになりますね。

FreeBSD インストール前に EFI パーティションを一個作って、 bcdedit /enum firmware のコマンド群で制御。

この二つが今回は大きな収穫でした。これで UEFI な PC でもマルチブートは大丈夫っ!! 新しい NotePC 買おうかなー;-)。

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 でも作るかなぁ;-)。

3月 152019
 

このサイトはさくらのレンタルサーバ上にあるので自分の力で apache の設定を変えられはしないので、さくらの VPS 上で運用している icmpv6.orgmotsuyaki.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(^^;;。

12月 282018
 

ノッチのあるスマートフォンというのはどんな感じだ? などと思い、 Apple の iPhone は高くて手が出ないので、中国産の Android スマートフォンを購入しました。今回チョイスしたのは UMIDIGI というブランドの Z2 Updated Edition というモデルです。

色々調べてみると UMIDIGI Z2 というのは初代・スペシャル・アップデートと三種類あるらしいですが、僕が購入したのはタイトルにもある通り UMIDIGI Z2 Updated Edition です。

この端末、技適を通していないので、日本国外で使うのはちと無理です。正月に海外で過ごすときなど、成田空港の外側で利用するよあにしましょう。

 
スペックや、使用感などは既に他のブログなどあちこちで掲載されているのでここでは一切書きません。触ってみて、僕が『ん?』と思った部分のみ掲載してみます。

 
最初に断っておきますが、僕は google がキライです。なので、初期にインストールされている google 謹製のアプリはほとんど無効にしています。

カレンダー・ドライブ・GMail・Chrome・フォト・Play music/Movie などは google 謹製を利用していません。

 
1.メーラソフト無い?
GMail を無効にするとメーラアプリがなくなるんですね。 SONY Xperia Z5 Compact を購入したときは別にメーラアプリがあったので安心していたのですが・・。
しょーがないので、 TypeApp というメーラをインストールしました。

他にカレンダーも無くなったので OneCarender というのをインストールしました。このカレンダーアプリは CalDAV に対応しているので自宅に構築した DAViCal サーバのカレンダー情報を読み込むことができます。どちらも広告無しの秀悦なアプリです;-)。

 
2.カメラは GPS ポイントを書き込んでくれない
このスマートフォンで撮った写真は、特定のアプリでは地図上に写真を配置してくれる。それはつまりは EXIf に現在地情報を書き込んでくれるのですが、これを macOS の『写真』アプリに持っていくと位置情報無し。と、いうことになります。

と、いうことで純正のカメラアプリも無効化します。そして、google フォトも無効化しているので、それぞれに対応したアプリを探します。

カメラアプリは OpenCamera をインストールしました。こいつはしっかりと GPS ポイントを Exif に書き込んでくれます。また、このスマートフォンのカメラの機能も一応引き継いでくれているような気がします。まだ、被写体深度の深い写真はあまり撮ってないんですけどね。

写真管理のアプリはギャラリーをインストールしました。別に google に写真はバックアップしないので、これで全然問題はありません。逆に google に写真預けたくない;-)。

 
3. CPU 遅いよ・・
このスマートフォンは Helio P23 という CPU を利用していますが、こいつが遅い・・。orz
今まで利用していた SONY Xperia Z2 compact よりも遅いと感じるので実質的に、僕個人的なスマートフォン環境としてはデグレードしている感満載です・・。orz

ポケモン GO の起動も遅いし、フツーのタイミングで待たされることがある感じです。
アプリを終了してランチャーに戻るとき、重いランチャーだと、アプリアイコンが表示するまでに 3 秒くらい待たされる場合があったり、結構うんざりします。ランチャーアプリは軽いのをインストールするのがおすすめです・・。

素直に UMIDIGI F1 待ったほうが良かったかなぁ。などと思ったりもしていますが・・。

 
4. テザリングしくしく
やはりテザリングはボトルネックですねぇ。僕はトヨタのカローラフィールダーに乗っているのですが、カーナビはトヨタ純正でテザリングすると Android アプリの MyTOYOTA for T-Connect と同期してくれて走行距離とか取ってきてくれたり T-Connect カーナビアプリは『G メモリ』に登録した行き先情報をカーナビからアクセスできたりと、連携してくれるのですが・・。

カーナビが要求してくる Wi-Fi AP の仕様は 2.4GHz の 1-13ch なのにこの UMIDIGI Z2 は基本的に 2.4GHz の場合 14ch で待ち受けます。なので、カーナビはデザリングできないんですね。

この写真はカーナビ側のアクセスポイントの詳細情報を表示しています。チャンネルが 14 なので、接続できない。見えるんだけど、パスワードを何回も聞いてくる状態なんですね。あれま・・。

 
しかし、時々は接続できる場合があるので、その場合 UMIDIGI Z2 側は 10ch になっていたりするので、テザリング時に 14ch 固定ということは無さそうです。

例えば USB のバスパワーで動作する Wi-Fi AP を 13ch に設定して車の中で電波を出したあとに UMIDIGI Z2 のテザリングをオンにすると、14ch に近い 13ch が使われていると認識して、もっと下のチャンネルを利用するタイミングがあります。

もっと言うと、駐車場の周りにある建物の Wi-Fi AP が外へ漏れている場合、その影響を受けて 14ch ではないチャンネルでテザリング待ち受けする場合があるのでトライしてみるのも良いかもしれないです。

 
ちなみに僕は USB バスパワーで 2.4GHz 帯でチャンネルを任意のチャンネルに指定できる Wi-Fi AP として WRH-583GN2-S を利用しています。

 
とまぁ、つらつらと書いてみましたが、機能的には DSDV 使えたり(まだ使ってないけど)、こまめに OS のバージョンアップ(バグ修正)してくれたりするので良い感じかな? とは思ってますが、今は Andorid8.1 で、多分 Android9 にはならないと思います。 Android9 が欲しいなら新しいの買ってね。安いんだし。って雰囲気出ています;-)。

 
なお、上にも書いていますが、ベンダはこまめにバグフィックスしてくれているようで、過去にリリースされた OS イメージは以下のサイトでダウンロード可能になっています。その点はありがたいですね。

https://community.umidigi.com/forum.php?mod=forumdisplay&fid=202

もう少し使い込んでみて、あまりに遅いようだと次のを購入するか、と、いう感じですが、 au の ガラホ SIM で DSDV を試してみたい。と、いうのはちょっと思いますねぇ。

 
この話、続きのエントリが書かれることがあるかな?

12月 012018
 

一個前のエントリで Mac mini を購入した件を書きましたが、今まで利用していた MacBook 2009 も一応健在です。OS は Sierra でしたが、インストールできる最新の Hight Sierra にしたいモノですが、中々バージョンアップが行えない。

あ。 MacBook 2009 は Mojave は非対応な機種となりました。しかし、 Aplle は Sirra も Hight Sierra もまだサポート対象 OS としているので一応、安心して利用可能です。

 
今まで利用していた環境は MacBook 2009 に Sierra をインストールしていましたが、自分で交換した 128GByte の内蔵 SSD は容量不足になりつつあったので、これを機会に 256GByte に容量を増やし、そのタイミングでなんとか Sierra -> Hight Sierra にバージョンアップしようとの目論見です。

既に多くのウェブサイトに記載されていますが Sierra -> Hight Sierra へのバージョンアップは非常に厄介です。ファイルシステムが HFS+ から APFS に変更になったため容易にはインストールできません。

そして、自分で個別に、僕のように初期の HDD から SSD に変更した人は更に高い壁が立ちはだかりインストールができません。
MacBook系 の HDD を SSD に変更した人がはまる道。


https://applech2.com/archives/20171002-high-sierra-upgrade-issue-due-to-third-party-ssd.html

純正の HDD もしくは SSD を自分で、別の SSD に換装した場合にファームウェアの更新ができなくて Hight Sierra にアップデートできない。と、言うんですね。

僕もこの壁にぶち当たりましたが、なんとか回避しました。その手順を書いておきます。

1. 今の状態
MacBook 2009 は HDD であったが、遅いで 128GB の SSD に換装したのは今から 2,3 年前。
macOS Sierra までは順当にアップデートができたが Hight Sierra にアップデートしようとしたらちっともアップデートできないのでそのままにしていた。
ちっともアップデートできないとき、以下のメッセージが表示されていた。

「macOSをこのコンピュータにはインストールできません。ファームウェアの検証でエラーが発生しました」

Hight Sierra を USB メモリでインストールできるようにインストールイメージを USB メモリ上に作成。
作成についてはあちこちのサイトに記載されているのでそちらを参考にしてください;-)。

USB メモリでのインストールも何回か試みるも上記メッセージが表示されちっともアップデートできない。

 
2. 128GB の SSD を 256GB の SSD に換装
ちょうど良いタイミングで 128GB の SSD の容量が足りなくなってきたので 256GB の SSD に換装し、 Hight Sierra をクリーンインストールすることにする。
タイムマシンでバックアップし、 128GB の HDD はもしものためにきっちりとキープしておく。

Hight Sierra のインストールイメージが入っている USB メモリからブートし、クリーンインストールを試みるも上記メッセージが出てやはりインストールできず。

おやおや・・。orz

このときに NVRAM のリセットを試みる。option+command+P+R の同時押しの電源投入で、二回『ちゃらーん』(音が違うか。これは笑点だ;-)と聞こえたら NVRAM の初期化完了。

その後、再度 USB メモリからクリーンインストールに挑戦するもやはりダメ。

 
3. 256GB の SSD に Sierra をインストール
USB メモリから Hight Sierra をインストールするのを断念し、以前利用していた 128GB の SSD を USB 接続してから MacBook を起動し、復旧バーティションから Sierra をインストールします。これは無事にインストール完了。
新しい 256GB の SSD には今まで利用していた OS と同じ macOS Sierra がインストールされました。

この状態で、 macOS Sierra のアップデートをドドドと適用します。クリーンインストールなのでマッサラな状態です。

で、何個かのアップデートを適用していくのですが、2018-005 だけが適用できないのであります。
で、 2018-005 は何をしているのか? と、いうと、上記のようにエラーとなるファームウェアのアップデートなんですね。 2018-005 が適用できないと、いつまで経っても Hight Sierra がインストールできません。
裏を返すと 2018-005 が適用できると Hight Sierra のインストールが可能になるわけです。

僕は、 2018-005 未適用な状態、 2018-004 まで適用した状態で再度 NVRAM のリセットを試みました。そして再起動後にアップデートを実行すると、あぁら不思議。 2018-005 が適用できて最新 Sierra は最新の状態になりました。

そして、半分嬉しさを噛み締めつつ『この状態だと Hight Sierra にバージョンアップできんじゃね?!』などと思い、 App Store から Hight Sierra をダウンロードしアップデートインストールを試みたのであります。

 
4. 来たゼッ!! Hight Sierra
新しい 256GB の SSD に macOS Sierra をインストールし、サラの状態で Hight Sierra にアップデートするので特にゴミなど無いであろう。と、思われるのであります。

アップデートの途中で失敗することもなくインストーラは最後まで完走し、無事に Hight Sierra にアップデート完了ですっ!!

いやぁ。長かった。無事にアップデートできて良かった。

 
以上が macOS Sierra から Hight Sierra へのアップデートの道のりです。アップデートに失敗した人は僕も含めて色々な探しモノをするのですが、『ファームウェア初期化でインストールできた。』と、いう人がいるのですが、 NVRAM のリセットをいつ行ったら良いか?と、いうのが中々つかめない。

僕の場合都合二回ほど NVRAM のリセットを行うタイミングがあり、そのうちのどちらかがバシっと効果的に効いて、 2018-005 が適用できたのでしょうなぁ。

Mac の SSD 換装による Hight Sierra へのアップデートができない人は多分 2018-005 も適用できていないと思います。 まずは Sierra の 2018-005 のアップデートを適用するために NVRAM のリセットを行う。と、いう手もあるのではないかと思われます。

 
まぁ、ここに書いたのは『僕の MacBook 2009 の場合。』のお話かもしれませんが、同一機種で問題が発生している人の参考になれば嬉しく思います。

11月 222018
 

久しぶりに Apple の PC を購入しました。今まで使っていたのが MacBook 2009 なので約 8,9 年ぶりくらいですかね。

MacBook 2009 は macOS Sierra で、 Hight Sierra にバージョンアップできなくて困っていたのですが、それについては別途エントリを書く予定なので置いといて、 macOS mojave には対応しなくなるので、いよいよ新製品を購入。と、なったのであります。

それにしても MacBook は遅かった。 Core2Duo 2Core で mdworker が動き出すと CPU 食われまくり。新しい、絶大なパワーを持った Mac mini を買おうとしていたら Apple から 4 年ぶりに発売されたそれのパワーは絶大ですかさず飛び付いた。と、言う感じですね。

 
今回購入したのは intel i7 とメモリ 16GB で SSD は 256GB にしました。これで、消費税込み 19 万 yen コースです。高いなぁ。とは思うのですが、有り余るパワーの Mac が持てて非常に満足です;-)。

 
Mac mini に直接的に購入したのは USB-C の USB HUB 二個ですね。 USB ポートが少ないので USB-C の口にゾロゾロと色々接続するために購入しました。

その他、 Mac mini を利用するときに気付いた点を少々。

 
o. T2 チップ内蔵でスリープ状態が解らない
これはあちこちで書かれていますね。本体がスリープしてもフロントの LED が点灯しっぱなしでスリープしているのか解らない。
ディスプレーが省電力モードに移行していると『あ。寝ているね。』と、判断するしかないですかね。

 
o. Siri 起動
『へい。しり。』って言っても macOS は Siri が起動してくれない。コマンドキー+スペースキー長押しで起動しますが、そもそも Mac mini にはマイクが付いてないので意味ないじゃーん。と、いうことになるのですが、僕の場合、以前 PC 用に購入した USB サウンドカードがあったのでそれを接続し、その昔 Pod Cast やろうとして購入した SONY のステレオマイクがあったのでそれを接続しました。
これで Siri に対して色々聞くことができるようになりました。

しかし、上の項目にもマッチするのですが、 USB サウンドカードは電源が供給されていると LED が点灯するんですね。なので、 Mac mini がスリープしたか起きているかは USB サウンドカードを見るとこで確認できるようになり、一石二鳥なのであります。

こんなのを利用しています。

 
o. CPU パワーすげー。
僕は Mac のリソース確認のために MenuMeters と、いうのを利用しているのですが、 CPU コアが 6 個、 HTT 対応で計 12 Core に見えるのは圧巻です。今までに利用した PC は AMD の FX-6100 が 6 Core で最高だったのですが、Mac mini が一番コア数の多い PC になりました。

おかげでサクサク、コンパイルもサクサク、上にも書いた通り mdworker どんと来やがれ状態です;-)。

 
o. epkg も動いているよ
以前、このブログにも書いていますが、epkg を /usr/local/ 配下にインストールして動作できる環境を整えています。

なので、FreeBSD の ports 的に、自分で必要なものは自分で make && make install して利用しています。もし良ければ使ってみてください。

https://icmpv6.org/EPKG/

epkg を作成する上で、今回一番困ったのが、最近の macOS から ftp コマンドが消えている。と、いう点です。しかも wget がないのでどうやってファイルを取ってくるのだ?と、なるのであります。

epkg-mojave-20181203.tgz には epkg で作成した wget のバイナリも入れておいたので epkg install すれば良いと思います。
自分で Makefile を書いてコンパイルしてバイナリを作成したのですが、一応 OpenSSL も enable しています。 なので上記 URL からも色々取って来られると思います。

自分でソースからコンパイルすると、やっぱり楽しいですねぇ。 epkg の Makefile には make -j 12 と書かれたモノが何個かあるかもしれないです;-)。
cmake とか emacs などは make していて気持ちが良い;-)。

 
新しい Mac mini はこんな感じてでしょうか。コンパイルメインに利用しているなんて、いかにも間違った使い方かもしれませんが、他の人とは違う使い方を書いているのでまぁ、ヨシとしておきましょう;-)。

 
さてと。今回は Mac mini の他にディスプレーも買い替えてしまいました。今まではフルハイビジョンの 21.5 インチのディスプレーを約 10 年くらい利用していたのですが、そろそろ買い替えどきかと思い 4K にするか、悩んだのですが、2K で表示する 23.8 インチのものにました。

Mac mini から 2k (2560×1440) サイズは利用可能でず。ただ、MacBook 系とは違い文字サイズの変更ができません。

「システム環境設定」から「ディスプレイ」を選択し、[解像度]を[変更]しても文字サイズを変更するメニューが出ないのであります。なので、 2k サイズで利用する場合にはちっこい文字での表示となります。

あ。今回購入したディスプレーは IO-DATA の EX-LDQ241DB です。 NTT-X で購入したのですが、僕の場合はタイミングが良くクーポン券が付いていて 19,980yen で購入できました。ずいぶんお得で助かりました。

 
とまぁ、こんな感じで macOS を利用する環境が新たに整ったので、今後はガシガシ使い込んで行きたいと思います。

何か気付いた点が、今後出てきたらまた何か書きたいと思います;-)。

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 を再起動すると設定画面が日本語化されます。

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

9月 172018
 

KDE の 4 や 5 を使っていると ps -ax とか打つと気が滅入るときがあります。『どうしてこんなにakonadi が起動しているのだっ!?』と。まぁ、 akonadi は kdepim 系のユーザ情報管理や各種サービスへのアクセスを一手に引き受けているのでさまざまなプロセスが動くのはしょーがいなのではありますが・・。

akonadi はバックエンドにデータベースを利用していて、必要な情報はそこに格納します。選べるのは全部で三つ。 MySQL・PostgreSQL・SQLite3 ですね。 KDE4 の頃は複数のプロセスからアクセスするとデータベースがぶっ壊れるから MySQL を使え。と、いうお達しが出ていて、『まじかよー。デスクトップのバックエンドに mysqld 動かすんかよぉ・・。orz』などと思っていたのですが、 KDE5 からはいよいよ純粋に上記三つのデータベースが選択可能になったようです。

と、いうことで ports の databases/akonadi をインストールする場合は以下のようにオプションを選択すると良いでしょう。

今回は非常に負荷の軽い SQLite3 をチョイスしました。この状態で akonadi をコンパイルすると関連性により databases/qt5-sqldrivers-sqlite3 がインストールされます。 akonadi が利用するデータベースドライバですね。
ちなみに MySQL を選択すると databases/qt5-sqldrivers-mysql がインストールされます。

これで今日は akonadi は SQLite3 を利用するようになる。わーいっ!! などと喜んではいけません。 akonadi は今でも default で MySQL を利用するようになっているので、設定を変更して上げる必要があります。

設定変更するファイルは ${HOME}/.config/akonadi/akonadiserverrc になります。 akonadi を一回起動(しようと)すると生成されます。

[Debug]
Tracer=null

[%General]
Driver=QSQLITE3

[QSQLITE3]
Name=/home/USERNAME/.local/share/akonadi/akonadi.db

 
起動直後は [%General] では Driver=QMYSQL と書かれていると思いまずが、これを上記のように変更し、更に [QSQLITE3] を書いてデータベースを指定してあげます。

設定ファイルが完成したら akonadictl restart するか、一回ログアウトしてから再度ログインし直すと良いでしょうか。再度ログインすると mysqld が起動していないのに akonadi が動作しているのが嬉しいですね;-)。

これで mysqld が起動しない分 PC の負荷が多少は軽くったでしょうか? もしかしたら気分的な問題かぁ?

 
では、そもそも akonadi 自体を起動したくない場合はどうするか?

一番簡単なのはコンパイルのオプションで SQLite3 を指定して、設定フアイルである akonadiserverrc には MySQL を利用する設定を記載することです。

databases/qt5-sqldrivers-sqlite3 や databases/qt5-sqldrivers-mysql などがデータベースドライバになるのですが、設定ファイルで選択したデータベースのドライバが無い場合には akonadi が起動しません。

それとは別に [QSQLITE3] や [QMYSQL] の中に StartServer=false と掛けば akonadi が起動しない。と、いう話のようですが、実際に記載した設定ファイルを用意しても akonadi は起動してしまいました。残念。

[Debug]
Tracer=null

[%General]
#Driver=QSQLITE3
Driver=QMYSQL

[QSQLITE3]
Name=/home/USERNAME/.local/share/akonadi/akonadi.db
StartServer=false

[QMYSQL]
Host=
Name=akonadi
Options="UNIX_SOCKET=/tmp/akonadi-USERNAME.73cx0k/mysql.socket"
ServerPath=/usr/local/libexec/mysqld
StartServer=false

 
と、いうことで akonadi のコンパイル時に SQLite3 を指定して、上記のように設定ファイルを記載すると、起動しなくなります。

起動したい場合には [[%General] で Driver=QSQLITE3 を有効にして Driver=QMYSQL をコメントアウトすれば OK です。

これで akonadi がずいぶんと楽しいものになったかな? ;-)。

9月 092018
 

僕が利用している ThinkPad E145 はカーネルがずっと 10.1-RELEASE のままで、ユーザランドが 10.4-RELEASE だったりしていました。これは以前にも書いていますが suspend/resume が動作しなくなる。resume 後にバックライトの調整ができなくなるため、しかた無く。の対応だったんですね。

あと、ThinkPad E145 はグラフィックスカードに Radeon HD 8330 を利用していて、このチップは radeonkms.ko では未対応で Xorg のドライバでは VESA を利用していたんですね。

そして、 KDE5 は 10.4-RELEASE でコンパイルしたものは、コンパイルしたバージョンとは違う 10.1-RELEASE 上では動作しない。と、いうことになり、そろそろ新しい NotePC を買うことを考えていたところに drm-next-kmod がバリバリと動作する。 Radeon HD 8330 も radeonkms.ko で動作するようだ。と、いうので 10.1-RELEASE から 11.2-RELEASE にいっきに上げてみることにしました。

と、ここまでが前振りです(^^;;。
freebsd-update でいっきに 11.2-RELEASE にして pkg delete -a で古い packages を削除したあとに 11.2-RELEASE でコンパイルした KDE5 一式をドドドとインストール。その他 NotePC に必要なモノをインストールします。

そして、今回はそこに graphics/drm-next-kmod をインストールします。 /usr/ports/graphics/ の下を見ると、全部で以下があるようです。

・drm-devel-kmod/
・drm-legacy-kmod/
・drm-next-kmod/
・drm-stable-kmod/

まぁ、見て、雰囲気が大体解ると思われますが;-)。

graphics/drm-next-kmod をインストールすると /boot/modules/ の中がずいぶんとにぎやかになります。

この中から radeonkms.ko を見つけ出してブート時に kldload するように、/etc/rc.conf に設定します。

# --- kernel module load --- #
kld_list="/boot/modules/radeonkms.ko"

 
radeonkms.ko は今回 graphics/drm-next-kmod でインストールしたモノと別にシステム標準の /boot/kernel/radeonkms.ko があります。 /boot/loader.conf に radeonkms_load=”YES” と書くとシステム標準のカーネルモジュールがロードされてしまうため、上記のように記載します。

インストールが完了したあとは /etc/X11/Xorg.conf を編集してあげます。最近は /usr/local/etc/X11/xorg.conf.d/ 内にドライバ・キーボード・マウスなど、個別のファイルを用意して /etc/X11/Xorg.conf は書かない。ってのが流行みたいですねぇ。まぁ、どっちにしろ Section “Device” の項を書き換えます。

Section "Device"
        Option      "TwinView" "true"
        Option      "TwinViewOrientation" "LeftOf"
#       Option      "RegistryDwords" "EnableBrightnessControl=1"
        Identifier  "Card0"
#       Driver      "radeon"
#       Driver      "vesa"
        Driver      "modesetting"
        BusID       "PCI:0:1:0"
EndSection

 
Driver radeon は動作しないので、しょーがない。今までは Driver vesa で使っていたのですが、今回 graphics/drm-next-kmod にしたので Driver modesetting にしました。最近の Xorg は賢くなって色々なモノを自動認識するようになり、デバイスにあったカーネルモジュールをロードしてくれるようです。

と、いうことで上記の設定ができたらリブートしましょう。
リブート後、僕の ThinkPad E145 では以下のカーネルモジュールがロードされるようになりました。 linuxkpi.ko が今回のカナメでしょうかねぇ。

--- <上略> ---
23    1 0xffffffff82421000 15d6d9   radeonkms.ko
24    1 0xffffffff8257f000 74b70    drm.ko
25    4 0xffffffff825f4000 edc8     linuxkpi.ko
26    3 0xffffffff82603000 114b8    linuxkpi_gplv2.ko
27    2 0xffffffff82615000 6b8      debugfs.ko
28    1 0xffffffff82616000 23f8     radeon_kabini_pfp_bin.ko
29    1 0xffffffff82619000 23f8     radeon_kabini_me_bin.ko
30    1 0xffffffff8261c000 23f8     radeon_kabini_ce_bin.ko
31    1 0xffffffff8261f000 43f8     radeon_kabini_mec_bin.ko
32    1 0xffffffff82624000 2a78     radeon_kabini_rlc_bin.ko
33    1 0xffffffff82627000 12e8     radeon_kabini_sdma_bin.ko
34    1 0xffffffff82629000 38eb0    radeon_bonaire_uvd_bin.ko
35    1 0xffffffff82662000 13328    radeon_BONAIRE_vce_bin.ko
36    1 0xffffffff82676000 37528    linux.ko
37    2 0xffffffff826ae000 2d28     linux_common.ko
38    1 0xffffffff826b1000 31e50    linux64.ko
--- <以下略> ---

 
Xorg を起動し、ログインマネージャの x11/sddm を起動し KDE5 にログインします。そして、 「KDE システム設定」から[ディスプレイとモニタ]->[Compositor]ときて、[レンダリングバックエンド]を確認します。VESA ドライバを利用していたときは選択できるのは xdandr のみだったのですが、今は OpenGL2.0 や 3.1 が指定できます。おぉっ!! これで 「ゆれるウインド」とか「魔法のランプ」などが利用できるようになるっ!!

ってんで、 graphics/drm-next-kmod の恩恵が受けられるのでありました。

 
で、次のステップですが、 まだ、以下の二点が残っております。

・suspend/resume はちゃんと動くの?
・バックライトの明るさ調整はできるの?

まず、suspend/resume についてですが、最初の 1,2 回はフタを閉じた段階でシステムごとフリーズしていたので『むむむ。 graphics/drm-next-kmod は suspend/resume に対応してないのか?』などと思ったのですが、ロードするカーネルモジュールとかその他設定を見直すことで無事に suspend/redume が動作するようになりました。

ThinkPad E145 では acpi_video.ko はまともに動作してないので利用していません。 acpi_ibm.ko はバックライト調整はできないけどボリューム調整はできるのでロードしています。

 
次にバックライト問題ですが、これは、本家でも wiki の掲載があるほどなので、ことは一大事なのでしょうなぁ。

https://wiki.freebsd.org/Graphics/Brightness

ここに書いているのは一通り試しました。上にも書いた通り ThinkPad E145 は Radeon HD 8330 なので intel_backlight (ports 的には graphics/intel-backlight) を使うと Device not found. です。あら。つべたい。

accessibility/sct はオプションの数値を変えると色が変わるので、 LCD brightness とはちょっと違う。

で、結局、僕は xrandr を使うことにしました。xrandr は VESA ドライバを利用している頃はまともに動作しなかった (Can’t open display と表示される) のですが、 graphics/drm-next-kmod を使うと無事に動作するようになりました。

まず、以下のコマンドを打ってディスプレー名を取得します。

$ xrandr --listmonitors
Monitors: 1
 0: +*LVDS-1 1366/256x768/144+0+0  LVDS-1

 
最後の LVDS-1 が重要で VESA ドライバを利用していた頃はこの値が表示されず xrandr で明るさの調整ができなかったんですね。今回 graphics/drm-next-kmod を利用することによりちゃんと動作するようになりました。ここまで来ればラクショーです。あとは以下のようにコマンドを打って画面の明るさ調整をすれば良いだけ。

$ xrandr --output LVDS-1 --brightness 0.8

 
今動作している明るさが 1 で、それよりも暗くしたい場合は 1 以下の数値を小数点で指定し、更に明るくしたい場合は 1.2 とか指定すれば良いです。

雰囲気的には機械的にバックライトを調整するのではなく、画面の色をグレーにすることで暗くなったように見える。と、いう機能ですね。ハードウェア的にバックライトを暗くしてないのでバッテリー運用のときは要注意って感じでしょうか。

 
と、いうことで CPU/GPU 共に AMD な NotePC である ThinkPad E145 ですが、

・11.2-RELEASE にした
・graphics/drm-next-kmod で Radeon HD 8330 を認識してくれる
・KDE5 が使えるぞぉ (これは当たり前;-)
・suspend/resume ができる
・バックライト調整も一応できる

と、いう状態になり、ほぼほぼ満足な結果です。細かく言うと

・キーボードが 101 のままだぁ
・マウスの動作があやすぃー
・音の出るところ調整(スピーカーかイヤホンか)

など、ありますが、それらは Xorg の設定で調整するもヨシ。KDE5 側で設定するもヨシ。と、いう状態なので、道は色々あります。それらを一応全て解決できたので、僕の ThinkPad E145 は壊れなければあと 4,5 年は持つような気がしてきました;-)。

5月 202018
 

最近の ports-current を追いかけていると、統合デスクトップ環境 (懐かしい響きだ;-) に KDE4 を利用している人にとっては、関連性からインストールする packages が xxx-kde4 へと、名前が順次変わっていたので『むむむ。そろそろ KDE5 が降ってくるのか?』などと思っていたら、果たしてその通りで x11/kde5 と、いうのができました。

デスクトップが更新されたのはずいぶんと久しぶりだなぁ。以前のこのブログのエントリに「FreeBSD に KDE4.1 がやってきた。」と、いうのを書いているのですが、それが 2008 年 08 月ですね。約 10 年ほど KDE4 を使い続けた。と、いうことですが、このたび KDE5 に移行しました。今回のネタは FreeBSD で利用する KDE5 について、少々書いてみたいと思います。

 
それにしても 10 年も経つと色々なことが変わりつつあります。そもそも、今でもデスクトップ環境として FreeBSD+xorg を利用している人は何人くらいいるのでしょうか? このエントリを書いて、ちゃんと読んでくれて、設定を方法を見てくれる人がどれくらいいるのでしょうか? 不安です・・f(^^;;。

が、まぁ、しかし、初めてみましょう。

 
1). インストール
まぁ、簡単で ports の x11/kde5 を make install すれば良いだけです。make config で好きなモノを設定していけば良いでしょう。
ただし、KDE4 からのアップグレードの場合、KDE4 に関連する packages は全て削除しましょう。 KDE4 と KDE5 の ports/packages では confrict が発生し、 make install が途中で止まったりします。

インストールは qt5- ・ kf5- ・ plasma5- で始まるモノがドドドとインストールされます。 akonadi はまだ動かないようですね。なので korganizer やkmail などは動きませんし、インストールされません。 okular は QT4 ライブラリがくっ付いているのでインストールする気にもなれません。これらは 18.04.1 のバージョンで多分解決するのではないかな。と思われます。
オフィスアプリは calligra-3.1.0 よりも libreoffice のほうが良いでしょう。

あと、KDE5 や Qt5 では日本語言語パックがなくなりました。フツーにインストールすると i18n 対応です。一応、 devel/kf5-ki18n がインストールされているかだけ、確認しておきましょう。

ports から make すると PC の性能にもよりますが 40 時間程度でインストールされると思います;-)。

 
あと、ウィンドマネージャとしての kdm がなくなりました。変わりに sddm というのを利用します。 kde5 インストール時に関連性でインストールされないので、後から x11/sddm と deskutils/plasma5-sddm-kcm をインストールしましょう。

起動については kdm4 と一緒です。 /etc/rc.conf に以下のように記載すれば OK です。

sddm_enable="YES"
sddm_lang="ja_JP"

 
sddm は一回起動すると /usr/local/share/sddm/scripts/Xsession というログイン時のスクリプトを生成します。自分好みの起動にしたい場合はこのファイルを直接直しちゃいましょう;-)。

インストールについてはだいたいこんな感じでしょうかねぇ。

 
2). 環境構築。
sddm から左上の「セッション」から “plasma” を選択すると上記 sddm の Xsession から startkde が実行され、デスクトップが表示されます。
“User Session” を選択すると ${HOME}/.xsession が動き出します。

起動後についでてすが、 KDE4 を利用していた場合は ${HOME}/.kde4/ に設定ファイルが置かれていましたが、 KDE5 では ${HOME}/.config/ にバラけて入るようになりました。
僕の場合は、ややこすぃーのがイヤなので KDE4 の設定は引き継がず、新たに KDE5 の設定ファイルが新規に生成されるようにしました。しかし、KDE5 になっても ${HOME}/.kde/ に設定ファイルを置くプログラムが何個があるようですね。

KDE5 のデスクトップ環境は「KDE システム設定」 (systemsettings5) で様々な設定をします。

僕は「KDE システム設定」->「起動と終了」->「自動起動」から「スクリプトファイル」で以下を実行するようにしました。環境変数と X のキーボード周り、あと、言語設定などですね。

#!/bin/sh
# XmodMap Sesource Setup
Xkeybord=$HOME/.xmodmaprc
if [ -f $Xkeybord ]; then
        /usr/local/bin/xmodmap $Xkeybord > /dev/null
fi
UsrResource=$HOME/.Xresources
if [ -f $UsrResource ]; then
        /usr/local/bin/xrdb -load $UsrResource
fi

# Start some clients
xset s 300 300 &
xset s noblank &

export LC_TIME=C
export LANG=ja_JP.UTF-8
export LC_CTYPE=ja_JP.UTF-8

export TZ=JST-9

export TERM=xterm
export UNICODEMAP_JP=cp932

# Session Type Select
export KDE_UTF8_FILENAMES=true
export KDE_LANG=ja_JP.UTF-8
export QT_XFT=true
export GDK_USE_XFT=true

## IME Start
#export QT_IM_MODULE=xim        # Qt4 用設定
export QT_IM_MODULE=fcitx       # Qt5 用設定
export GTK_IM_MODULE=xim
export XMODIFIERS=@im=fcitx

exec /usr/local/bin/mozc start
exec /usr/local/bin/fcitx

# Other Wakeup Programs
# gkrellm
Gkrellm="/usr/local/bin/gkrellm"
if [ -f $Gkrellm ]; then
    exec $Gkrellm &
fi
# Emulate3Button
Xkb2mb2="/usr/local/bin/kb2mb2"
if [ -f $Xkb2mb2 ]; then
    exec $Xkb2mb2 -c 117 &
fi

 
日本語入力は fxitx+mozc を利用しています。 fcitx は Qt5 用に textproc/fcitx-qt5 をインストールする必要があります。そして、環境変数の設定方法も変わっています。

fcitx 自体は今でも GUI 部分に Qt4 ライブラリを利用しています。うーむ。早いところ Qt5 に移行してほしいなぁ。 fcitx5 というのがリリースされているので、早いところ FreeBSD の ports になってほしいモノです。
ちなみに japanese/mozc-tool は Qt5 に移行しています。

文字をベコベコ打っていると、キーボードが 101 形式であることがわかります。 106 キーボードに変更する人は「KDEシステム設定」->「入力デバイス」->「キーボード」から設定します。一番最初に表示される [ハードウェア] タブにのキーボードモデルには 106 キーボードが無いんですね。その横にある [レイアウト] タブの「レイアウトを設定」にチェックを入れて JP 日本語キーボードを新規に登録する必要があります。

以下、キャプチャです。

こんな感じでキーボードを登録すると KDE5 側でも 106 キーボードが利用可能です。 X の twm などでは 106 キーボードが使えるのに KDE5 を起動すると 101 キーボードになってしまうので困ってしまうですねぇ。

 
もっと困ったのがマウスでした。僕の場合 Apple が推奨する Natural Scroll 、それは俗にいうホイールの逆回転ですね。これが動かない。
「KDEシステム設定」->「入力デバイス」->「マウス」に『スクロール方向を逆にする』という項目があり、チェックを入れても逆になりません。あららぁ・・。

色々調べてみると KDE5 からは libinput というのがマウスを管理しているようです。ports 的には x11-drivers/xf86-input-libinput です。 xorg.conf の設定で以下のような感じで用意してあげれば動くようなのですが、 Linux のドキュメントはたくさんある。しかし、 FreeBSD のドキュメントは全く無いっ!!

FreeBSD のフツーの X の使い方では xf86-input-libinput は利用されません。

Section "InputClass"
        Identifier "libinput pointer catchall"
        MatchIsPointer "on"
#        MatchDevicePath "/dev/sysmouse"
        Driver "libinput"
        Option "NaturalScrolling" "true"
EndSection

 
詳細についてはインターネット上にある libinput のドキュメントを読んでください。Linux の場合は /dev/input/event* なるデバイスができるようですが、 FreeBSD の場合はそれができない。デバイスではなく MatchHoge でも装置を認識するようです。装置名などにマッチさせることもできるパラメータで何種類かのマッチ要素があるようです。装置を確認するには xinput list で特定するらしいです。

が、そもそも、現在の FreeBSD (少なくとも僕の環境) では libinput は Xorg で利用されないため必要ないようです。なので、この設定自体は無視してかまいません。

では、どうやってマウスのホイールを逆回転するか? いやはや。古典的な設定で実現しました。

 
o.回避策そのいち (xorg.conf)

Section "InputDevice"
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/sysmouse"
#   Option         "ZAxisMapping" "4 5 6 7"
    Option         "ZAxisMapping" "5 4 6 7"
EndSection

 
o.回避策そのに (${HOME}/.xmodmaprc)

pointer = 1 2 3 5 4 6 7 8 9 10 11 12

 
マウスのスクロールボタンは 4,5 なので、その値をひっくり返すことにより対応しました。 KDE5 の設定でなんとかしようとせずに X の設定で対応した。と、いう感じでしょうか。これで、マウスの設定も完了です。ふぅ。

 
僕的にはこれで KDE5 を楽しむことができるようになりました。

 
3). 使ってみる。
KDE4 から KDE Plasma5 になり、画面の雰囲気がガラっと変わり、全体的に明るくなりました。ベースのワークスペースのテーマは Breeze というのになりました。そのおかげでちょっと明るめの気配かな。使用感は KDE4 と遜色ないです。

 
気がついた問題点を少々。

 
o.ディスク IO 負荷が高い
ログインしてしばらくすると /usr/local/bin/baloo_file_extractor が動き出します。これはデスクトップのフル検索のための情報収集プログラムだと思われます。 macOS で言うところの mdworker のようなモノですね。こいつが動いていると KDE5 がやたらと重いのでプロセスを kill してかつ、「KDEシステム設定」->「検索」から「Enable File Search」のチェックをはずすとフツーの速さに戻ります。

 
o.今まであったアプリがない
上にも書いた通り、FreeBSD だけかもしれませんが、まだ akonadi が無いためにオフィス系アプリはほとんどありません。別途インストールする必要があります。もしくは 05/19 以降の ports-current を利用するのが良いかと思われます。

あと、このエントリ書くためにスクリーンキャプチャ (スクリーンショット) を撮ろうとしたんだけど、グラフィックスのメニューの中もずいぶん静かで、ありませんでした。
で、調べてみると、なんとっ!! PrtScr ボタンを押すと起動するんですね。 Windows みたいだ。で、実態はというと /usr/local/bin/spectacle が起動するので、メニューに登録してあげると良いでしょう。 (よくよくメニューを眺めてみると「ユーティリティ」の中にありました)

 
o.konqueror は相変わらずか?
レンダリングエンジンが KHTML から Webengine に変わっていますが、firefox に比べて軽いブラウザなので嬉しいです。が、SSL なサイトは相変わらず閲覧できないのは KDE の証明書ライブラリが相変わらずぶっ壊れているからか?

 
とまぁ、ダラダラと書いてみましたが、一番最初にも書いた通り、約 10 年ぶりのデスクトップ環境のアップデートです。嬉しいですねぇ。途中 KDE4 が重くて xfce4 をインストールしたこともありましたが、やはり KDE は良いですねぇ。

Gtk2/3 の角ばった雰囲気よりも Qt4/5 の丸っこいアウトラインが好きだし、そー考えると GNOME はもう 8 年くらい触ってないし。

などと、書いていますが、皆さんも是非 KDE Plasma5 をお試しください;-)。