Supermicroのマザーボードでファンの回転数をIPMI経由で制御するには、以下のコマンドを投げつければよい。

# 制御モードをFullにする
ipmitool raw 0x30 0x45 0x01 0x01

# "system"ゾーンの回転数を37.5%にする
ipmitool raw 0x30 0x70 0x66 0x01 0x00 0x24

# "peripheral"ゾーンの回転数を25%にする
ipmitool raw 0x30 0x70 0x66 0x01 0x01 0x16

まず、ファンの制御モードを“Full”にする必要がある。他のモード（Optimalとか）だと、その設定の方が優先されるとのこと。その後、ゾーン毎に回転数を設定してやる。

2～3つ目のipmitoolで送っているバイト列のうち、最後がファンのデューティー比、後ろから2番目がゾーン番号を表す。ゾーンのsystemとperipheralは、マザボのFAN用コネクタFan1系列とFanA系列に対応していると思われるが確認したわけではないので間違ってるかも。

デューティー比は0x00～0x64の64ステップとされている。でも、16進数なんだから0～100なんじゃないの？という気が…ま、ともかく0x00が最小で0x64がフル回転だそうなので、こまけぇこたぁいいんだよ！

実際のところ、Optimalで割とイイ感じに制御してくれるんだけど、ファンによってはデューティー比低すぎて止まっちゃうことがあるんですよね。で、ファン停止エラーが検出される→フル運転→エラーが止まる→デューティー比下がる→ファンが止まる→…の無限ループになるという。

この場合ipmitool sensor threshで最低回転数のスレッショルドを調整するのが定石。うちでは設定値が悪いのか、上手く動いた試しがない。

ファン制御やスレッショルドを弄ってにっちもさっちも行かなくなったら、ipmitool mc reset coldでBMCをリセットしてやればおｋ。

• ファン制御
  • Reference Material - Supermicro X9/X10/X11 Fan Speed Control | ServeTheHome Forums
  • FAQ Entry 18025 - I want to change the FAN settings of IPMI by RAW commands on my X9 motherboard. Can you give me the correct command?
  • Script to control fan speed in response to hard drive temperatures | TrueNAS Community
  • PID fan controller Perl script | Page 5 | TrueNAS Community
  • GitHub - khorton/nas_fan_control: collection of scripts to control fan speed on NAS boxes
• スレッショルド変更
  • How To: Change IPMI Sensor Thresholds using ipmitool | TrueNAS Community
  • Decrease Supermicro IPMI Fan Threshold – Calvin Bui
  • set fan thresholds on my Super Micro H11DSi-NT | pcfe's blog

SSL証明書の期限が切れた状態でcertbot renewを行うと、ApacheプロセスのCPU利用率が100%となりハング状態になるっぽい。apachectlで止めようとしても（弊鯖はご存じのとおりFreeBSDなのでservice apache24 stopだが）、応答が返ってこずkillせざるを得ないという状況。環境は以下のとおり。

• FreeBSD 13.0-RELEASE-p4
• Apache 2.4.51
• certbot 1.21.0
• certbot-apache 1.21.0
• Python 3.8.12
• webrootモードで運用

weekly_certbot_enableでもって週次で証明書の確認＆更新が行われるはずなのに、なんで切れてるの？そもそも期限切れになったからと言って、なんでhttpdがハング状態になるの？と疑問は尽きないのだが、ひとまず脇に置いといて、この状況に陥ったらcertbot certonlyを使って手動で証明書を更新してやる。

# certbot certonly --webroot -w /path/to/document_root -d example.com

証明書更新後、certbot renewでhttpdが暴走しないことを確認する（renewが正常に終われば暴走はしてない。）

それにしても原因は何なんだろうなー。以前、同様の状況が発生した時は、apacheやモジュールの更新を行っていたのでバイナリ間の何らかの不整合くらいで流したが、たぶん今回と同じ原因だったんだろう。さらにその以前は正しく動いていたような気がしなくもない（結構期限切れをやらかしていたので確証が持てない）ので、よくわかりません。

詳しい方教えてください。

(2021-12-24 追記)

確証はないけど、証明書更新後にapache reloadをしておらず、新しい証明書がapacheに認識されてないのが原因な気がする。

FreeBSDフォーラムの投稿のように、証明書更新後のフックスクリプトでリロードしてやれば解決しそうな気がする。

/usr/local/etc/letsencrypt/renewal-hooks/deploy/reload_apache24.sh

#!/bin/sh
service `echo $0|sed -e 's/.*\/\(.*\)_\(.*\).sh/\2 \1/'`

パッと見「なんじゃこりゃ？」ってシェルスクだが、自身のファイル名をsedで切り出しservice apache24 reloadを実行するという、実に巧妙な仕組みだ。引用元のフォーラムでは、同様にdovecotやpostfixの証明書更新も行っていた。中身同じでファイル名を変えればいいだけとは、よく思いつくものだ。

• Apache Running at 100% - Certbot Unable To Renew Certificate - Help - Let's Encrypt Community Support
• "Could not find ssl_module; not disabling session tickets." · Issue #7998 · certbot/certbot · GitHub

不注意でProxmox VEのZFSプールを使い切り、空き容量がゼロという状態になってしまった。すべてのデータセットのAVAILが0という本物のゼロである。VMのディスクがthinで図らずもオーバーコミット状態となっており、VM内で物理容量以上のファイルコピーを行ってしまったのが原因。当然ながらVMは固まるわ、PVEもWebコンソールから何もできないわで超焦った…。

幸い物理コンソールは生きていたので、不要なZVOLを消して事なきを得たと思いきや、ファイル操作をするとInput/output errorが起きるようになってしまった。

root@myserver:/etc/pve/nodes/myserver/qemu-server# touch test
touch: cannot touch 'test': Input/output error

ファイル/ディレクトリの作成、削除がダメ。既存ファイルの読み込みは問題なさそうで、書き込み系がダメっぽい。それもすべての場所でダメというわけではなく、ルートディレクトリ直下は大丈夫だったりする。同じデータセットなのに。

もちろんzpool scrubでエラーが出ないことは確認済み。というわけで実に厄介というかヤバい状況なのであーる。どうすんのこれ…

関係しそうなバグチケ報告もあるにはある。

• silent corruption gives input/output error but cannot be detected with scrub, experienced on 0.7.5 and 0.8.3 versions · Issue #10697 · openzfs/zfs · GitHub
• silent corruption for thousands files gives input/output error but cannot be detected with scrub - at least for openzfs 2.0.0 · Issue #11443 · openzfs/zfs · GitHub

が、ほとんど関係ない気がしなくもない。うちはサイレントじゃないし。実は静かに壊れてて今回ので発現した可能性もあるが、ほんの数日前にVM追加してるしちょっと考えにくい。FreeBSDの方では何だかんだ10年ほどZFSを使っているが、データが壊れたのはそれなりに原因が分かっている2回しかない（1回目、2回目）。

容量ゼロをトリガーにLinux側とZFS側で何らかの齟齬が発生し、容量の回復がLinux側に伝わってないとかが原因なら再起動で直りそうなものの、シャットダウンしたが最後、完全に壊れてPVEが立ち上がらなくなる可能性もありそうで恐ろしい。この記事も書いているメイン環境は、そのPVE上で動いているのでPVEの死＝メイン環境の死なので慎重にならざるを得ない。

(2021-11-24 追記)

意を決してPVEマシンを再起動してみたら、Input/output errorは出なくなった。何事もなかったようにVMも動いている。

ZFSではCoWの関係上、一般的に空き容量がプール容量の10～20%¹⁾を切ると危険水域とされている。予めプール全体にquotaをかけておけば、今回のようなヤベェ自体は予防できるだろう。

家鯖のFreeBSDのnet/samba413をビルドしようとすると、configureでncursesが見つからんと言われてコケるようになっていた。

ncurses not available, cannot build regedit
ncurses not available, but --with-regedit was specified

ncursesってbaseに含まれてたような…なんでエラーになんの？と思いつつ、念のためdevel/ncursesを入れても効果なし。Sambaの依存パッケージじゃないし、そりゃそうだ。

portsのバグを疑いしばらく放置＆再試行してみたものの、一向に直る気配がない。そもそもエラーでググってもそれらしい結果が出てこないので、自分の環境の問題なのだろう。

では、どうやってシステムのncursesを直すか？

base.txzあたりでシステムを上書きすれば良さそうではあるものの、ncursesがどのtarballに含まれているのかが分からない。かといって、なんも考えずにtxz一式を展開した結果、設定ファイルなどがデフォルトに戻るのは避けたい。

そんな感じでモニョってたんだけど、たまたま目にしたFreeBSD-SA-00:68.ncursesに解決策があった。/usr/src/lib/libncursesでmake installするだけで良かったのだ。

# cd /usr/src/lib/libncurses
# make && make install

そしてSamba 4.13が無事ビルドできて一件落着。

# portmaster net/samba413

システムを飛ばしたときの復旧が不十分だったんだろうなぁ、たぶん。近いうちにbuildworldしとくか…

消費電力削減のためメインPCと家鯖を仮想化で統合してから半年、当初の目論見ほどには電気代が安くなっていない今日この頃、皆さんいかがお過ごしでしょうか。

消費電力が下がらないことに業を煮やした私は、更なる節電のためにX10DRiとデュアルXeon E5-2673v3の組み合わせから、X10SRL-FとシングルXeon E5-2680v4に変更するという暴挙に出ました。CPU1個分のベース電力が削減できるだろう、Broadwell-EPのHWP (Hardware P-states)でv3より省エネだろうという皮算用をもとに…。

X10DRiにE5 v4を1つだけ載せればいいのでは？と思われるかもしれないが、PCIeスロット数の関係で叶わぬ願いだったのさ。X10世代のデュアルソケットマザーにはPCIeスロットが6本載っているものの、ソケット毎に3本ずつという割り当てで、しかもCPU1側はPCIe x16が1本のうえGPUを差すと直下のPCIe x8が隠れて実質2本しか使えない極悪配置なのである。

どうせマザボも変えるならWindows 11を見据えてSkylake-SPにしてしまうのも手だったけど、多コアのやつはまだちょーっち高いなぁって。

そういうわけで、メインマシン兼鯖の構成と消費電力は下表のようになった。

25W程度の削減となったが、100W切りは達成ならず。瞬間値なら98W程度を確認するも、まぁ殆どの場合100～105Wをうろうろしてる感じ。

DDR4メモリの消費電力は8GBあたり3W程度ということで、DDR4 RDIMM 32GB×2枚を取り外して24Wの節約だぜ！？と試してみたら、せいぜい5W程度しか変わらなかった…。それも明確に下がったわけではなく、なんとなーく下振れしてるかなー？という程度。10W削れるならともかく、これならメモリ+64GBの恩恵を受けた方がいいかなと。

これ以上の消費電力削減は無理な予感だなー。CPUやメモリの電圧弄れば違うだろうけど、お堅いM/Bなので設定できるはずもなく。HDDが5W/台で6台載ってるのが最大のネックなんだよなー。

X10SRL-FのPCIe x16スロットは、マニュアル上はx8動作ということになっているが、BIOSの設定でx16動作に変更することができた。この場合、同じPCIeリンクを共有するPCIe x8スロットは当然だけど使えなくなる。PCIeバイファケーションの設定が全パターン（x16, x8x8, x8x4x4, x4x4x8, x4x4x4x4）選べるのは、さすがSupermicroといった感じ。