また余計なことを… セキュア・ブート

日本に設置するために構築中のテレビジョン録画サーバのカーネルを 3.16.7 にアップデートし、放送キャプチュアカードのドライバを再コンパイルしてロードしようとしたらエラーになった。

root@h-rn312:~# insmod pt3_drv.ko insmod: ERROR: could not insert module hello-1.ko: Required key not available

このドライバはクロス環境でビルドしているので、カーネルのバージョンを再確認して作り直してもダメ。

ぐぐってみたら、「Secure Boot」と言う機能で、要するにWindowsでマルウェアのドライバをインストールさせないために、Microsoftが「Windows 8 互換」を称するための必要条件としてBIOSで実現するように要求しているらしい。以前の 3.16.6 のカーネルではこの現象は見られなかったから、3.16.7から実装されたようだ。

マザーボード（ASUS）のBIOS 画面に行き、「Advanced」から「Secure Boot」を「Windows 8」から「それ以外のOS」に変更して回復した。

Secure Linux と言い、大多数のユーザには何の恩恵もない代わりに無用の混乱を引き起こすセキュア機能を黙ってデフォルト仕様にするのは如何なものだろうか？

GPT・EFI・RAID1 にHDDを追加

GPT

最近のPC用オペーレーティングシステムでは、大容量HDDに対応してGPT（GUID Partition Table）と言うパーティション方式が使われている。それまでのMBR（Master Boot Record）は1980年代のDOSの時代に設計されたもので、元々CHS（シリンダ、ヘッド、セクタ）というHDDの物理パラメタを使っていたが、のちにLBA（論理ブロックアドレス）を使うようになったものの、アドレスが32ビットなので2TiB（512バイト/セクタ×2^32セクタ）までしかディスク上の場所を記述できない（2TiBより大きいディスクにも使えるが、2TiBを超える部分はパーティションテーブルに記述できない）。また、MBRは元来4個のパーティションしか想定していなかったので、5個目以降のパーティションは「物理パーティション」の一つを更に複数の「論理パーティション」に分割するなどのつぎはぎで対応してきた。

GPTはMBRの制限を克服して、より柔軟性・拡張性のある新設計のパーティションシステムで、それぞれに誤り検出を備えた二重のパーティションテーブルをディスクの先頭と最後尾に記録して堅牢性を高め、事実上無制限のパーティション数（Widowsは128個に制限）、最大8ZiB（＝2^73≒8×10＾21）まで記述できるなど優れたパーティション方式である。

更に、GPTはMBRしか理解できない旧来のユーティリティによる事故を防ぐため、ディスクは依然としてMBRのパーティションデータを維持しており、MBRとして見るとGPT全体が一つのMBRパーティションに見えるなどの下方互換性も考慮してある。

EFI

EFI（UEFI、Unified Extensible Firmware Interface）はGPTと関連があり、PCの黎明期の資源（記憶容量）の節約が再重要課題であったMBRの時代に発案された先頭の512バイトセクタにブートローダを収めると言う現代の肥大したソフトウェアには完全に時代遅れとなったブートローダの格納方式を改め、GPTの最初のパーティション（FAT）にブートローダのファイルシステムを格納する方法である。512バイトのブートローダ笑ってはいけない。小生が最初扱ったCP/Mでは当時の単密度FDの先頭の128バイトセクタがブートローダだったから、それよりも4倍も大きかったのだ!

当然のことながら、EFIのブートシステムを使うためには、ハードウェア側のファームウェア・ブートローダがEFIブートローダを認識できなければならない。今日売られているPCのマザーボードはほぼ全てそのような仕様になっていると思われるが、MBRしか理解できないBIOSでも、MBRにもブートローダかかれており、このMBRブートローダがEFIのブートローダに引き継ぐようになっているので心配はない。

システム管理側から見ると、 ブートローダがファイルシステムとしてOSから見える空間にあることには大きな意味がある。ここで構築するRAIDシステムでも、その見通しのよさは利点となっている。

UUID

UUID（Universaly Unique IDentifier）またはGUID（Globally -）は、世界中で唯一絶対無二（と見做せる）のラベルであり、通常は計算機で発生された他数桁（代表的には16桁）の疑似乱数である。特定のオブジェクトを指定する方法として広い用途に使われており、例えばGITのバージョンなどにも使われるが、ここで関心があるのはディスクのUUID、特にパーティションのUUID。

パーティションには通常少なくとも二つのUUIDがつけられる。下は、今回のプロジェクトで生成したディスクとパーティションのUUID。

root@dvr3:~# blkid /dev/sd[ab]* /dev/sda: PTUUID="32e9ab11-f4f9-429f-ba2a-2152b1e0c6de" PTTYPE="gpt" /dev/sda1: SEC_TYPE="msdos" LABEL="BOOT_EFI" UUID="E6C8-88B4" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="9fa9a19d-edfa-4547-acdd-28a447847b8b" /dev/sda2: UUID="e895041e-5b45-28e3-48f9-f6b95a9a7c1c" UUID_SUB="d37916fe-8ff6-ab8e-be2e-2be61513ce77" LABEL="dvr3:swap" TYPE="linux_raid_member" PARTUUID="f76213c2-06fa-4cce-8389-0dfd330cfb7c" /dev/sda3: UUID="1e1befdc-8c1c-0df3-e6ff-fae3365c40dd" UUID_SUB="397fd84b-884d-ff9b-39a2-dee11c305fca" LABEL="dvr3:boot00" TYPE="linux_raid_member" PARTUUID="d574fbe7-7536-4f95-9192-d9383c682221" /dev/sda4: UUID="ce81f465-4304-e57f-3ca5-cdc9e894e5b3" UUID_SUB="f65ff449-2a51-ac83-0a51-8bd871d01c2b" LABEL="dvr3:pv00" TYPE="linux_raid_member" PARTUUID="4ea40149-9100-41d5-98e5-ba7fa5a98512" /dev/sdb: PTUUID="c4f133d4-4ae2-4fb7-bce5-f6eb9256887a" PTTYPE="gpt" /dev/sdb1: SEC_TYPE="msdos" LABEL="BOOT_EFI" UUID="0085-40A4" TYPE="vfat" PARTLABEL="EFI System Partition" PARTUUID="93c20ab9-d77b-4ca8-8f58-f0127f7e0e82" /dev/sdb2: UUID="e895041e-5b45-28e3-48f9-f6b95a9a7c1c" UUID_SUB="1ccd67c3-326c-2a42-8353-136e119fa651" LABEL="dvr3:swap" TYPE="linux_raid_member" PARTUUID="0df80d4a-86ad-49db-bc41-e79e5f546704" /dev/sdb3: UUID="1e1befdc-8c1c-0df3-e6ff-fae3365c40dd" UUID_SUB="f54b5a8f-fd50-f281-0e13-5f2e76a8dc8c" LABEL="dvr3:boot00" TYPE="linux_raid_member" PARTUUID="44a25a01-c4a1-4b2b-a242-d7d93c949418" /dev/sdb4: UUID="ce81f465-4304-e57f-3ca5-cdc9e894e5b3" UUID_SUB="47e97367-2f77-1d04-8402-91eb001271a2" LABEL="dvr3:pv00" TYPE="linux_raid_member" PARTUUID="b6842bbf-6018-430b-9177-fce9c1af7f94"

まず、各パーティションにはそのパーティションの内容に係わらず唯一絶対無二の「パーティションUUID」がつけられる。パーティションシステムはこのUUIDしか問題にしない。

/dev/sda1と/dev/sdb1は問題のEFIパーティションだが、これらのパーティションにはmkfsでフォーマット・ファイシステムを作成したときに生成された、ファイルシステムごとのUUID（4バイト）が付けられている。4バイトという短さはFATのディスク構造の制限であり、ext[2-4]やBTRFSなどの近代的なファイルシステムは16バイトのUUIDがつけられる。

/dev/sda2と/dev/sdb2は同じUUIDを持ち「唯一絶対無二」ではないが、これはこれらのパーティションが同じRAIDのメンバーであることを意味している。メンバー間の「個体認識」は異なるUUID＿SUBで区別される。

実際には、上記の/dev/sda2と/dev/sdb2からなるRAIDの上にLVMのUUIDがあり、その中の各ボリュームは固有のUUIDを持ち、更に各ボリューム上のファイルシステムのUUID、とそれぞれの階層でUUIDが付けられるが、ここでの関心はパーティションレベルまで。

OSのインスタレーション

FC20のインストーラAnacondaは、以前の版（FC5、FC13など）に比べて使いにくい。最近のこの手のソフトウェアの傾向として、Windowsを真似るだけでなく、「ソフトウェアはそれを使うユーザ自身より賢く、ユーザが究極的に何をしたいかをユーザ自身よりもよく知っている」という誤った思い込みで作られており、操作・結果の詳細をできるだけユーザに操作させない、あるいは少なくともユーザに見せないようになっており、ユーザの実行したいことがソフトウェアが想定するモデルに従わない場合は最悪の場合必要な操作が実行できない。FC20版のAnacondaもずいぶん困惑させられた。

加えて、AnacondaとEFIはRAIDと相性があまりよくない。後日、試行錯誤の末、気がついた点を述べる。

php.ini にタイムゾーンを設定する

PHPスクリプトの中で date() などの日時に関連した関数を使うと

It is not safe to rely on the system's timezone settings.
Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function.
In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier.
We selected 'UTC' for now.

のような小うるさい警告がでる。

幾つかのサイトで /etc/php.ini にタイムゾーンを設定するように書かれている。

[Date]
; Defines the default timezone used by the date functions
date.timezone = Asia/Tokyo

しかしこれは上手く行かなかった。 で、上手く行ったのはこれ。

[Date]
; Defines the default timezone used by the date functions
date.timezone = Japan

PHPのサイトのサポートされているタイムゾーンのリストの中に「Japan」はあるが、「Asia/Tokyo」はなかった。 ごちゃごちゃ言わずに、走行しているホストの現在のタイムゾーン（/etc/localtime）をデフォルトにすればよいのにと思う。

ちなみにPHPのバージョンは 5.5.16。

今度はUSBドングルが熱にやられた。

7年前に会社からもらったラップトップの延命策として802.11nのUSBドングルを挿したら目に見えて速くなった。

で、気をよくしていたら、どうもこのドングル経由のWiFiが不安定である。長くても数時間、短いときは10分程度で接続が切れてしまい、大抵の場合、デバイスをリセットしないと元に戻らない。

大変困っていた。Windowsのドライバが壊れているのかとか、ドングルが不良かと思い、 802.11acに買い換えることまで考えた。


で、ある時閃いた。それまで何となく気になっていた、ドングルを触ったときの熱さ。このラップトップはボディに左右にUSBポートがついていて、左側のポートにドングルを入れていたのだが、そのすぐ隣に電源コネクタがあり、従って多分中には電源回路があり、ここら辺がやたら熱くなるのだ。

右側のUSBポートにドングルを差し直したら、何日も安定して動作するようになった。また熱にやられた。

詰まらない間違い。でも重要な影響だった。

ロックされているPDF文書にテキストを書き込む

無料のAdobe Readerを使ってPDF文書にテキストや署名を書き込むことができる。「書き込む」と言うのは正確ではないかもしれない。「描き込む」と言った方がよいかもしれない。PDFの所定の用紙に住所氏名などを電子的に記入できるので重宝する。

ところが、セキュリティとして書き込み禁止になっているPDFには描き込めない。

これを回避するのは比較的簡単。件のPDF文書を一度PDFファイルを生成する仮想プリンタで「印刷する」とできあがった新しいPDFファイルはセキュリティロックが解除されている。PDF出力プリンタも一応「法的に問題ないだろうな？」と確認してくることもある。

小生はWindows用PDF出力プリンタとして「Bullzip Printer」をずっと使っている。

ファイアウォールサーバがまた死にかけた

仕事場から家のLANをVPN経由でアクセスしているが、突然遮断された。仕事場のインターネットが全面的あるいは部分的に使えなくなることはそう珍しいことではないので静観していたら、約30分後に復旧した。ただし、LAN上のほとんどのホストの状態をPINGで監視しているメインサーバの報告によれば、少なくとも10分以上応答がなかったので電源再投入でリブートしたらしい。

サーバのフリーズはそう頻繁にあることではないが、全くない訳ではないから「数年に」一度の事故と考えたが、その後がよろしくない。約2時間後にまた同じ現象が起きた。今度も約30分後に生き返る。明らかに何かがおかしくなっているが、もうリモートで分かることはない。多分ハードウェアの異常だろうという推測は3回目の遮断ではっきりした。

このサーバは、その先代がやはりハードウェアの異常でフリーズを繰り返すようになった後、約1年前に新調したCeleronベースの比較的軽いもの。1年でまた壊れるとは納得が行かないが、ファイアウォールなのでこれがないと我が家のインターネット接続がすべて使えない。新しいものにリプレースするとして、症状から言ってCPUの不良は考えにくくマザーボードの可能性が高いからマザーボードだけ交換するか。しかしこのマザーボードはIntel 1155なのでだんだん入手し辛くなってきている。1150にするとCPUごと替えなければならない。Amazonからメイルオーダで買ったり実験を繰り返す時間的余裕はないから、即交換するとして余った部品をどこで再利用するか、などと考えながら帰宅を急ぐ。

帰宅途中にふと思いついたのは、電源故障もおおいに可能性があるというより、マザーボードの新しさから考えてそちらの可能性が高い。

帰宅してみると4回目の自動リブートでサーバは動作している。とりあえず自動リブートを禁止して様子を見る。

インターネットへのアクセスが遮断された。二階のサーバルームに行ってみる。サーバの電源が落ちている。決まった。電源ユニットに異常がある。

別のPCの構築作業中だったので、早速そちらから正常に動作することが確認されている電源ユニットを外して付け替える。復旧した！

取り外した件の電源をテストしてみる。ACを繋ぎ、得意の24（20）ピンATX電源コネクタの緑・黒ショートで電源を入れると、内部で電源の入るプスっと言う音が聞こえるものの、ファンが回らない。ファンを触ってみると非常に固くて回らない。ファンのベアリングがダメになっているようだ。

幸いなことに部品ストックに同じサイズのファンがあったので交換すると、動いた。件のサーバも順調に動作している。修理した電源ユニットを作業中の別のPCに装着しても平然と動作している。

結局、電源その物は生きていたが、ファンが死んでいたために数十分動作すると内部が温度上昇して保護回路が動作して電源を遮断し、その後我が家の監視システムが異常を検出して電源再投入するも内部が十分冷えるまでは再動作しなかったものと結論された。

教訓というほどではないが、トラブルシュートはセオリーどおりまず大元から疑うべし。そしてスペアの電源ユニットは必ず手元にいつも備蓄しておくべし、となった。

NFSトラブル Fedora 13/14 nobody:nobody

Fedora 13（FC13）上のVMPlayerで走らせているFedora 14（FC14）がブートしなくなった。原因は不明。ブーとの最中にカーネルがパニックを起こす。

 幸いなことにすべてのバックアップが揃っているので、FC14のイメージをVMPayerで再インストールし、バックアップから必要なファイルを回復させる。わけの分からないVMPlayerのイメージファイルと格闘するよりずっと手っ取り早いという判断。もともとこのFC14はFC14をターゲットにしたプロジェクトのビルドだけを目的として、その他の汎用性はまったく求めていないのでカスタマイズした部分もわずかだ。

エディタやバックアップなどのファイル管理は、すべてセントラルサーバであるFC13に任せ、FC14はプロジェクトの開発ディレクトリのみをNFSマウントして、ビルド作業だけを実行する。以前は/home をまるごとマウントしていたが、ホームディレクトリのしたの種々の設定ファイルがぶつかるとあまりおもしろくないので、プロジェクトの開発ディレクトリだけをマウントすることにした。

ところが通常どおり/etc/fstab にNFSのマウントを記述するとマウントはするが、マウントポイント以下のファイルの所有者がすべて nobody:nobody になってしまう。 このマウントされるサーバのディレクトリは他のマシンにもマウントされているが、そちらは正常なファイルの所有者になっている。このままでは用をなさない。

条件をまとめてみる。

• FC13がNFSサーバ
  /home/h/project をエfc14にクスポート（rw,wdelay,no_root_squash,no_subtree_check）
• FC14がNFSクライアント
  mount -t nfs4 fc13:/home/h/projects /home/h/projects
• FC13とFC14のユーザ「h」は同じID（501）
• マウントは成功するが、FC14上でマウントしたディレクトリを見るとファイル所有者が nobody:nobody になっている

調査の結果、こちらからの情報が役に立った。

クライアント（FC14）の /etc/idmapd.conf を編集して

#Domain = localdomain.edu

の部分を

Domain = mydomain.edu

のように本物のドメイン（でなければならないのかどうかは不明）に書き換え、

# service rpcidmapd restart

を実行し、マウントをし直す。これでマウントされたディレクトリとその下のファイルが正しいファイル所有者になった。

今回はマウントするファイルの所有者がただ一人だったから、FC14側の ユーザIDをFC13側のIDと一致するように手で書き換えたが、複数のユーザIDが存在するならNISを使うのがよいと思う。