投稿者「Yuaiho」のアーカイブ

ACPD245C4G-BKの文字だけ雑レビュー

OwltechのACPD245C4G-BK(Owltech社商品紹介サイト)を買って運用しています。文字だけレビューです。写真は面倒なので一切ありません。

私はSatechi 165W GaN Chargerの後継候補として買っているので、それとの比較で語ってるところが多いです。Satechi 165W GaN Chargerをお持ちでない方はそこはご容赦ください。

概要

OwltechのACPD245C4G-BKはPDに対応したUSB Type-Cを4ポートを備えている最大出力245[W]のUSB充電器です。単ポートの最大出力が100[W]で、100[W]出力が最大2ポートで使用可能です。またワーストパターンでも1ポートあたり45[W]までの出力が担保されています。

200[W]超のPD対応のマルチポート充電器で5ポート以上出力可能な製品は、実用的な性能で使えるのは概ね4ポート程度で、残ったポートは20[W]しか出ないとか、ポート数や値段の割に微妙な仕上がりの製品が多く見られます。しかしこの製品は245[W]もある割にポート数は4つと無闇にポートを増やさず、ポートあたりの出力W数を重視した製品になっています。

まぁ4ポートが100[W]+45[W]x3というのはいささか微妙で個人的には60[W]x4の方が嬉しいのですが、世の中には「100[W]/140[W]出力可能なポートが無いのはゴミ」みたいな方もいるのでそういう組み合わせの方が喜ばれるのでしょう。

Amazon Japanで取り扱いがなくなったSatech 165W GaN Charger(以下Satech 165W)の後継機として買ったものです。普段はAmazonで15k〜16k円ぐらいで売られていますが、タイムセールやプライムデーの時は1万を切ります。急いでいないならセールを狙って買うのがおすすめです。

寸法・重量

Owltech公式の商品紹介サイトよりキャプチャ
Owltech, “WEBショップ限定 最大PD100W出力/合計最大245W出力 USB Type-C×4 AC充電器 OEC-ACPD245C4G-BK | 製品情報 | 株式会社オウルテック”, 株式会社オウルテック, 2025年7月29日 1:02:12 JST更新, 2025.07.29閲覧

まず寸法ですが、これは実寸でも記載のとおりです。JIS規格の明記がない怪しいデジタルノギスで測っても公式に記載の通りです。まぁ誤差があったとしてもせいぜい1mm前後だと思います。

突起物は?と思うかもしれませんが本機に突起物はありません。つまり脚のようなものはありません。もし設置面に生身で置くのが気になるゴム足でも買ってください。私は3Mの「CS-04」を買って貼り付けています。ちなみにどっちが上かなんですが、電源インレットのある面に仕様が印刷されていて、この仕様に書かれた文字が正方向になるように置くのが正しい置き方みたいです。縦置きするな、とは注意に書かれていませんが縦置き用のスタンドはありません。

電源コードの長さはWebサイトには記載がありませんが雑に測ってみるとコンセントのブレード部分の除いた長さが凡そ100cmです。ちなみに電源コードの電気的な仕様としては0.75sqのVCTFKです。コネクタはIEC C6(メガネケーブル)で差し込み部やコネクタ部は7A/125V品です。私が買ったものはこれというだけでロット差や個体差がある可能性はあります。とりあえず100cmは正直短いので私はIEC C6のケーブルだけ社外品を買って使っています。

重量の表記は謎です。電源コードなしの本体のみで実測520+1[g]です。2個体をそれぞれキッチンスケール2個つかって測ってみましたが、いずれも実測520+1[g]です。どう頑張っても商品紹介ページ記載の454gにはなりません。Amazonのレビューにある写真も520[g]近傍ですので単なる記載ミスか、スケールが不良品だったか、我々の暮らしている一般的な重力場とは異なる世界線で測定したのどれかだと思います。

単位質量あたりの出力ですが、本機は0.470[W/g]となります。Satech 165Wは348[g]で165Wなので0.476[W/g]です。質量あたりの性能は若干劣後しますが、Satech 165Wもこっちはこっちでダメな部分があるので、まぁ負けるとも劣らないと言って良い水準と思います。少なくとも同じGaNトランジスタ搭載を謳うUGREEN Nexode PD 100Wの0.352[W/g]やAnker 547 Chargerの0.300[W/g](どちらも2023年購入)や、2016年ぐらいに買った某社の5V/50Wの6ポート充電器の0.251[W/g]よりは全然マシです。技術の向上を感じます。数値は大きいほど高性能です。有効数字3桁の四捨五入です。

まぁ520[g]が重いか軽いかは体格や感覚にもよるでしょうが、私はSatech 165Wの348[g]でも普通に重い部類だと思ってます。あと、W数分純粋に嵩張ります。旅先で是が非でもタップを使わずに45Wx4をPDで供給する必要があるんだ、と言う稀有な例を除けば旅行・出張用の唯一無二の選択肢とは思えません。

PD出力部

eMarker付きのケーブルが出払っているので3Aの測定になるのですが、電圧は全セットあり、5V/9V/12V/15V/20Vでちゃんと12Vにも対応します。仕様通りDC3.3〜21V/3.0Aの範囲でPPSのPDO持っています。ただ、QuickChargeはどうも12Vまでの対応みたいですね。

負荷テストは電子負荷出すのが面倒なのと、電子負荷用のType-Cポートを作るのが面倒なのでやりません。この辺は一旦オウルテックを信用することにするので、どなたか追試希望です。

瞬断はあります。ただ必ず瞬断するわけではなく、ざっと挙動をみた雰囲気では、充電器全体の最大出力が切り替わる際に発生するようです。例えば2ポートの使用時の場合、総出力のパターン(後述)は100[W]x2=200[W]のパターンと100[W]+65[W]=165[W]のパターンの2種類がありますが、このパターンは内部で最後の組み合わせを覚えているようで、これを跨ぐような接続替を行うとその時に接続されているポートで瞬断するようです。

PD出力パターン

本機の出力パターンの複雑さはAnker 547 Chagerに負けていない気はしますが、細かいことを考えない運用なら至ってシンプルです。ちなみにポートは正しい位置で置いた場合、向かって正面左からC4, C3, 2C, C1です。左に電源ランプがあるのがC4で、囲いがあるのがC1です。

Owltech公式の商品紹介サイトよりキャプチャ
Owltech, “WEBショップ限定 最大PD100W出力/合計最大245W出力 USB Type-C×4 AC充電器 OEC-ACPD245C4G-BK | 製品情報 | 株式会社オウルテック”, 株式会社オウルテック, 2025年7月29日 1:02:12 JST更新, 2025.07.29閲覧

上記はオウルテック公式のUSB出力パターンです。まぁこれ覚えられる人は覚えていただいて差し支えありませんが、実は割とシンプルなので下記のように覚えると記憶すべきものを圧縮できます。

1ポート使用時

1ポート使用時はどこに挿しても100Wです。

後に挿す機器のことを考えないならどこに挿してもOKです。可能ならC4かC1に挿しておくと2個目3個目がが来た時も100W確保できます。C1なら常に100W確保できます。

2ポート使用時

隣同士さえ避ければ必ず100[W]です。おすすめはC1&C4です。C2とC3は注意が必要です。

本機が一番ややこしいのは2ポート時ですが、結論としては2ポートで使う場合はC1&C4、C1&C3、C2&C4みたいな感じで未使用ポートを1つ挟んで接続してください。これで2つとも100[W]出力が保証されます。

おすすめはC1&C4です。この組み合わせなら間に3ポート目を挿されてもC1/C4の2ポートは100[W]になります。

細かい説明するとC1とC4は相手によらず100[W]出力可能です。しかしC2とC3は相手によって最大出力が変わります。C3は最弱で、C3は隣(C2 or C4)が接続されると必ず65[W]になります。C2はC3が隣だと強くて、C3と隣同士(C3&C2)の時のC2は100[W]ですが、C1と隣同士(C2&C1)の時のC2は65[W]になります。

2ポート使用時はこんな感じで最大200[W]出力と最大165[W]出力の2パターンがあります。前述のようにどうも電源を入れてる間は最後のパターンを覚えているようで、充電器全体の最大出力のパターンが切り替わるような接続替えを行うと瞬断します。

3ポート使用時

どのパターンも両端が100W。挟まれたポートが45W。

3ポートはa.■■■□とb.■■□■とc.■□■■とd.□■■■の4パターンがありますが、いずれもパターンも外側の■が100[W]で、挟まれた間のポートが45[W]です。例えばb.の■■□■のパターンは100[W]/45[W]/空き/100[W]になります。d.の□■■■のパターンなら空き/100[W]/45[W]/100[W]ですね。

絶対では無い気がしますが3ポート使用時に差し替えすると総出力が変わるからか瞬断します。b.■■□■とc.■□■■でもC1やC4が瞬断することがあります。”することがあります”という残念な表現はiPhoneの充電のOn/Offの切り替わりという雑な方法で見ていてそこまで詰めていないためです。

ちなみにこの製品の最大245[W]出力は3ポート使用時の理論値です。

4ポート使用時

C1だけ100[W]。それ以外は45[W]。以上。

ちなみに4ポート出力の時は235[W]です。3ポートの245[W]もそうですが、このプラ筐体で放熱間に合うのかは疑問です。そして使用可能な雰囲気温度の記載は一切ありません。

Satech 165W GaN Charger比較での長所・短所

本機の長所

  • 出力W数が高い。
  • LEDが大人しめ
  • 基本横置きで重いので安定性が高い。
  • Amazonでは安い。
  • 入手性もいい。

LEDに減光シートを貼らなくて良い点は楽でいいです。

本機の短所

  • 梱包が雑。本体ぐらい袋に入れて欲しい。
  • 出力分順当に重い。体積も大きい。
  • 横置きなので設置面積が大きい。
  • 電源コードが短い

プラスチック使用料削減のつもりだか知りませんが、せめて本体ぐらいは袋に入れて欲しいですね。若干擦れたような跡があります。

Satechi 165Wの長所

  • 出力分順当にコンパクトで軽量
  • 縦置きできるので設置面積が小さい。
  • 付属コードが必要十分な長さ。
  • 出力が割とシンプル(160or165[W]になるように最大化してくる)

設置面積は結構大きな長所だと思います。

Satechi 165Wの短所

  • LEDがやんちゃ(無駄に眩しい)なので減光処理が怠い。
  • 出力パネルが脆い。
  • セールでも高い。
  • ディスコン?

出力パネルというのはType-Cポートがある面のフェースプレートです。これは爪で止まってるわけではなく、接着剤だけで止まっているだけなので経年でフェイスプレートが外れて基盤が剥き出しになることがあります。

総合

目新しい要素はないものの据え置き用としては堅実な進化。Satechi 165Wの後継として有用。

Satechi 165Wがリリースされた当時のマルチポートPD充電器市場は、各社が総出力が100[W]とか120[W]の微妙な総出力か、200[W]あっても微妙な出力組み合わせのマルチポートPD充電器を出していた時代でした。Satechi 165Wはそこに165[W]という高出力を4ポートでかつ実用的な出力配分を実現したある意味エポックメイキング的な充電器でした。

まぁエポックメイキングと言っても消費者目線で言うとSatechi 165Wぐらいが及第点といえるレベルで、それ以前のは「代わりがないから買う」みたいレベルでナチュラルに褒められる要素なんてありませんでしたけどね。あとこれの姉妹品の200[W]版は直感的にも微妙な感じがして、スペック見ると「やっぱり無いなー」と確定して商品ページをそっ閉じするぐらいには微妙な仕上がりです。

ACPD245C4Gはこの実用性重視の血筋を引いていて、かつSatechi 165Wの欠点を克服し、純然たる上位互換品と言っても良い印象を受けます。ただ、技術的な目新しさはなく、W数が増加した分だけ順当に重く、大きくなった感じのする製品です。

電源入力は240Vまで対応しますが、海外赴任ならともかく旅行には不向きだと思います。フルサービスキャリア(↔︎LCC)の国際線の預け入れ手荷物は大体23kg〜ですが、この充電器は23kg枠の2.2%を占める重さです。この充電器でなければいけない理由がないなら過剰、重すぎると思います。100Wが不要ならAnker Nano IIの65Wを4つ持つ方が軽くて総出力も高いです。

出力は若干ややこしいですが、パターン自体は少ないので覚えやすい方だと思います。少なくともAnker 547 Chargerよりは全然マシです。

あとは永く壊れなければ今のところ特に文句はないという感じだと思います。

HPを開設した理由

ハンドル名に続き、ウェブサイト開設25周年記念として、25年前にHPを開設した理由や経緯について話します。これもハンドル名同様記憶を頼りにしていて、何か正確な記録が文章であるわけではないのでなんか不正確だったり前回と整合性がない部分はご容赦ください。

HPを作った直接的な理由は自己紹介にもある通りで、当時契約していたプロバイダが容量をくれたからです。これ自体は別に嘘も偽りもない事実です。というかきっかけ…トリガー…直接的な理由はそれなので正しいです。ただ、自己紹介では当時の背景を結構色々端折って雑に書いてるので、今日はそれを補足します。

この容量というのは10MBでした。現在では下手すると画像1枚すら入るか怪しい容量ですが、2000年当時のWEBサイトやメールボックスの容量としてはよくある容量で、100MBは「大容量」と言っても過言でも誇大広告でもなんでもない時代でした。

ちなみに、どうでもいいんですが、そのプロバイダというのはエンドレスネットというプロバイダで、ルミーズの前身です。また、容量をくれた当時は「エンドレスアドバンス インターネット事業部」という名前で、どうもエンドレスアドバンスの事業の一つという感じでした。これはいつの間にか株式会社エンドレスネットに変わっていました。

また、今は変わってしまいましたが、まだエンドレスネット株式会社があった時代のエンドレスネット株式会社のウェブサイトのドメイン(www.endless.ne.jp)のAレコードと、エンドレスアドバンス株式会社の(www.endless-sport.co.jp)のドメインのAレコードは第3オクテットまでは全く同じで、第四オクテットの末尾の桁の数が1つだか2つ違うだけでした。

というか今調べたら今でも第2オクテットまでは同じで、同一のホスティング業者使ってますね。ただ、現在の両者の関係は特に調べていないので謎です。

<digの結果>
www.endless-sport.co.jp. 86283	IN	A	119.245.185.4
remise.jp.		300	IN	A	119.245.147.223
※理由はわかりませんがTTLが結構違いますね。。。

<Whoisの当該アドレスの結果>
inetnum:        119.245.185.0 - 119.245.185.255
netname:        RENTALSV-NET
descr:          Server Hosting Service                         (NTTPCCommunications,Inc.)

inetnum:        119.245.147.0 - 119.245.147.255
netname:        RENTALSV-NET
descr:          Server Hosting Service (NTTPCCommunications,Inc.)
※/24で切られてますが119.245.0.0/16全体が同じ持ち主で、持ち主はInfoSphere(NTT PC)。

ホームページ作成計画

おっと、話が逸れましたね・・・元に戻します。このサイトは2000年05月15日開設ですが、Webサイトを作る計画は1998年末頃には既にありました。これは2号機の紹介やハンドル名の紹介のところでも触れています。

このWebサイトを作る計画は2つの要素がありました。それは
1つめは「Yuaiho名義で【Yuaiho Softwareと言う名前のHP】を作る
2つめは開設したHPで【自作のソフトウェア(HyperCardスタック)を公開】する
というものでした。

こちらのハンドルの由来でも触れたようにこの計画の2つの要素のうち、2番目の要素である【自作のソフトウェア(HyperCardスタック)を公開】の部分はポシャりました。まぁ、前述の通り、絵心も技術力もアイディアも碌に無いのにスタックが完成するわけがありません。残当です。

そして、というか、しかし、というか”HP容量を貰えた”といのをきっかけにして残った1番目の【Yuaiho Softwareと言う名前のHP】を作るの部分だけを無理矢理実行に移してHPを開設しました。これが今の「Yuaiho17」です。開設当時は「YuaihoのHome Page」と称していました。これが、「HP容量を貰えたから作った」と言う理由の裏にある理由です。

つまりどういうことか?

つまり、ホームページ/ウェブサイトを作って公開する本来の目的が消えたのにも関わらず、なんとかHPだけそれっぽく作って公開し(ちゃっ)たということです。「見切り発車」「無計画」「向こう見ず」「やっつけ」という感じですね。三つ子の魂100までと言いますが、少なくとも25年程度ではあまり変わらないようです。

まぁ上では格好よく「計画」とか言っちゃってますが、実際は単に目標とか構想に近い物で、当然の如く計画書やWBS・線表のようなものはありませんでした。

この目標とか構想に近い計画のような何かを実行に移すと決めたのは2000年の4月頃だったと思います。実行に移すと決めた時点ではサイト名も未定ですし、公開できるHTMLファイルはたったの1ファイルたりともありませんでした。というか決まっていたのはURLとトップページの背景色だけです。まぁ、URLはISPと契約した時点で決まっていたので別に私が決めたわけではないですね。

もう一つだけ決めていた背景色ですが、これはYuaiho Softwareの構想時点で「トップページの背景色はピンク色にする」ということだけは何故か決めていました。理由は不明ですが、まぁたぶん単なる好みでしょうね。今のトップページの背景色(#ffe1fc)はこの構想を実行に移したもので、開設以来全く同じ背景色を延々と使い続けてます。WayBackMachine見るとわかりますが、どの年も背景色だけは同じです背景色だけでなくホームに並んでるコンテンツも20年以上変わり映えしませんけどね。

この背景色、永らく使ってますが決め方は結構いーかげんで、Color Picker(Macのシステムで標準的に実装されているカラーパレット)からピンクっぽい色を適当(雑)に選んだものです。たぶん誰も気にしていないと思うのですが、ホーム以外は背景色は2020年以降に作成したコンテンツでもほぼすべてがWebセーフカラーなのに、ホームだけが頑なにWebセーフカラーではないのはこれが理由です。まぁ、当時は四半世紀後も存続するなんて思ってないのでこの辺りは適当(=いーげん、雑)です。

今見るとピンクというより赤紫っぽく見えると思いますが、これは当時使っていたCRTモニタの色温度が9300Kだったせいだと思います。9300Kだと青みが強いので薄い紫〜ピンクになります。今はsRGBにしてるので見え方変わっちゃってますね。

ほとんど見えないこのブログのピンクっぽい背景色も実はこの色です。

見切り発車だったので開設当初はネタがあるはずはなく必死でネタ探しして作って公開してました。初期のコンテンツが取って付けたかのようにいまいち短くて雑なのはそう言う背景です。まぁ、あれでも一応オリジナルコンテンツですし、短く見えるののは今基準だからであって、当時のウィンドウサイズ(SVGA=800×600)基準としては十分な長さに見えたんですけどね。

公開当初はYuaihoのHome Pageというサイト名でしたが、リンクしていただいた時に字面がダサいと思ったので1年ぐらいでYuaiho17に変更しました。

こんな感じで今から25年前の2000年5月15日(月)にYuaihoのHome Pageというサイト名でひっそりと開設して今に至ります。ひっそりとか言いつつ当時はQ&A掲示板の署名欄で広報してましたけどね。5/15という日付や特に意味はありません。強いて言えばこの日にやっと公開できる形になった、というところでしょうか。

まとめ

まとめるとこんな感じです。

今なきHYPERCARD PARKで活躍されているスタック作家さんみ見た若きYuaihoは、こんな計画を立てました。【Yuaiho名義で「1. (Yuaiho Softwareと言う名前の)HPを作って」「2. そこで自作のソフトウェア(スタック)を公開する」】と。

しかし諸々の残念な理由で2番目の要素は実現困難になり、計画の目的(公開するもの)は消失。

でも、HPを持ちたくて仕方なかったYuaihoは、ISPに容量を貰えたこときっかけに、手段を目的化してなんとかそれ以外のコンテンツで2000年05月15日にHPデビュー。見切り発車だったので最初はネタに苦労しました。
 
まとめるとかなり酷い内容ですね。

その後、HyperCardスタックは完成しませんでしたが、結局はHP公開の3年後の2003年から習作レベルですが自作プログラムの公開を始めました。2003年までHP作る機運やキッカケがなかったらこのサイトはちゃんとYuaiho Softwareになっていたかも知れません。

今後

最近はレンタルサーバの維持費よりもドメイン維持費の方が高いのですが、とりあえず私が死ぬか、ドメイン周りにトラブルが出るか、ドメイン更新忘れるorなんらかの理由で出来なくなるまではWebサイト自体は存続すると思います。

Xを見てると私どころかこのサイトよりも若い方がいて、そういう方々を見るとこのサイトも永くやってるなーという気分になります。

ジオシティーズ、Infoseek、So-net、IIJ4Uと言った大手のHP公開サービスの終了で 20世紀から存続するサイトは大量絶滅してしまいました。また、いち個人が公開するコンテンツもSNSやnote.comやqiita等の台頭でこのサイトのような(非営利・趣味の)個人サイトは絶滅危惧種とまで言われています。

実際、前世紀から運営している個人サイトを探すのは有名どころ以外は結構難しいですし、前世紀と言わずとも2000年代初頭であっても普通にレアなレベルです。というか、まぁ、あるはあるんですが、ラーダ・ニーヴァの如く原型保ってるサイトは結構希少だったりしますし、古い話で困った時に頼れる最後の砦が個人サイトだったりしますので、コンテンツは充実させつつもあまり雰囲気を変えずに残せたらなと思ってます。

ハンドル名の由来 Yuaihoの友愛は粛清!?由来を徹底解説します!

中身の薄い動画やブログみたいなタイトルを付けましたが、Yuaiho17は今日(2025年05月15日)でサイト開設25年になります。25周年記念としてハンドル名などの解説をしていきたいと思います。

私のプロフィールはここです。

雑が感じが否めない自己紹介ですが、開設時からあまり変わっていないのと、2000年ぐらいの(所謂)個人サイトはどこもこんなテイストでした。気合い入ってる人は「<作者のハンドル>に100の質問」みたいな内容が公開していました。懐かしいですね。あれはちょっと作ろうかなと思いましたが、私は非公開にしてる内容が多いのと、30個目ぐらいで面倒になってやりませんでした。

ハンドル名

名前は通常表記がYuaihoで、正式にはAikinsetsu Yuaiho(※)/愛金雪 遊愛宝(友愛宝)/あいきんせつ ゆうあいほうです。フルネームとしては「Aikinsetsu Yuaiho」なんですが、Twitter以外ではほぼYuaihoの部分のみを使ってます。ちなみにWikipediaだけはAikinsetsuです。愛金雪の方が日本で言うところの姓で、遊愛宝が名部分部分に相当します。

元は命名当時にNINTENDO 64用のソフトであるファミスタ64(Wikipeida)で使ってたプレイヤー名をそのまんまハンドル名にしました。漢字3文字なのはファミスタ64の名前の文字数制限が姓名それぞれ3文字までだったことに由来します。つまり、そのあたりの時期に作ったハンドルというわけです。

英語表記は「Aikinsetsu Yuaiho」なので英語でも姓・名順表記です。2025年現在では公用文章でも採用されている英語の姓名表記ですが、命名した90年代末では結構マイナーな表記方法でした。一応理由はあります(後述)が、まぁそう決めたという感じが強いです。

Yuaiho(名前部分/通称)の意味

ハンドル名としてメインで使用している名の部分のYuaiho/遊愛宝は「ゆうあいほう」と読みます。Yuaihoをそのまま読むとゆあいほですが、読みは「ゆうあいほう」です。とうきょうをTokyoと書くのと同じような感じです。

当て字感のあるが漢字表記ですが、実際には前述のようにYuaihoの当て字ではなく漢字の「遊愛宝」方が先に作ってあって、それを読んだものをローマ字っぽく書いただけのものです。

意味はほぼ漢字そのまんまです。自堕落な感じですね。この辺りは今でも変わっていません。漢字表記は遊愛宝と友愛宝の2通りあって、一応前者を正式なものと定義しています。ただ作者自身があまりこだわってないのでサイト内でも揺れてます。実は遊の漢字は暫く間違えて覚えていて、当初は辶に族でした。

Ainkinsetsu(姓部分)の意味

姓部分のAikinsetsu/愛金雪は「あいきんせつ」と読みます。

これも名の部分同様に漢字の方が先にあって、それをローマ字っぽく書いただけ名前です。上述のファミスタ64では姓部分が必要だったので雑に付与したのがが由来です。

雑というのは愛金雪は遊愛宝と異なり、読みにも漢字にも特に意味がありません。あいうえお順で先頭(出席番号1番)を狙えて、漢字3文字で、独特かつそこまで非現実的でもない(と当時思った)名前を選んでいます。英語表記でも姓名順表記なのは、名簿で先頭が視野に入るからそう決めたという感じです。まぁ今考えると「愛金雪なんてDQNな姓なんて日本人にいねーよ」とは思いますけどね。

Aikinsetsuの方は単独ではほとんど使っていません。Wikipediaでは使っていますが記事がありませんが。

名前を考えたのは正確な記録はありませんが、姓名どちらも1998年頃に考えた名前です。(私の方が先に使い始めているので)友愛に粛清の意味はありませんし、20世紀少年(の民友党)も無関係です。

ただ、独自性は結構気にして作ったのは事実です。これは命名当時(1998年)にやっていたNHK連続テレビ小説の天うららの主人公の名前である「川嶋うらら(演・須藤理彩氏)」の影響を多分に受けています。

Yuaihoの命名の雑な歴史

このハンドル名はサイトの開設と密接に絡んでます。

サイト開設の話は次にしますが、ざっと説明するとハンドル名を策定した当時、HYPERCARD PARKというサイトがありました。このサイトは現存しませんがアーカイブを残されてる方がいます。

HyperCardがなんたるかの説明はWikipedia先生に譲るとして、そのHYPERCARD PARKにはスタック作家と呼ばれる方々がいっぱい居て、そこに自作のプログラム(スタック)を公開していました。本筋とはずれますし、そのHYPERCARD PARKには居なかったと思いますがsta氏こと、妹尾泰隆氏も所謂スタック作家さんの一人でしたね(当時はやすりん名義)。

私も当時そのHYPERCARD PARKやそのリンクからスタックをダウンロードして、HyperTalkがプログラミングのイロハのイの文字のてっぺん辺り触れているうちに、自分も何かHYPERCARDで公開できるものを作って公開したいと思うようになりました。

もし、スタック自作して、それを公開した時に使う予定として計画してたハンドル名こそが今も使ってるYuaihoです。ちなみに、サイト名は当初はYuaiho Softwareになる予定でした。

高いような低いような志を持ったところまではいいのですが、絵心も技術力もアイディアも碌に無いのに、公開できるソフトウェアなんて当然出来るはずもありません。そのため勿論計画は頓挫しました。まぁ、残当です。というか残念すぎる絵心・技術力・アイディアで無理やり計画を走らせたら黒歴史になっただけだと思います。

そんな感じでプログラム書いてプログラマ(スタック作家)になってHPを公開してという計画的で無計画な計画は頓挫しましたが、そのために用意した「Yuaiho」と言うハンドル名と、ハンドル名に一緒に使う予定だった「Aikinsetsu」というなんか残骸みたいなものを25年以上も運用をしているのが、今も使っているAikinsetsu Yuaihoというハンドルです。

YuaihoまたはAikinsetsu、Aikinsetsu Yuaiho名義の活動の場は、2025年現在では本サイトとTwitterのみです。スプラトゥーン3をやってること自体は公言していますが、名義はYuaihoではありませんので、もし居たらどれも私ではありません(名義は非公開です)。

次回はWebサイトを開設した理由でも書こうと思います。

Dovecot 2.3.21 → 2.4.1への移行

先日Dovecot 2.4.1が出たので、Dovecot 2.3系から2.4.1を移行の検証?を渋々やりました。

Dovecot CE版のマニュアルは親切とは言い難く、どこをどう変えれば良いのかがわかりにくいです。私も結局はConfig変える度にservice dovecot restartで怒られたところをマニュアルやdovecotが配布しているsampleを見て直して修正するという、TAS作るようなやり方で移行しました。サンデーオペレータの私には割と苦痛な作業でした。

記事公開したのは、同じような環境で使っている方に、私が踏んだクソをもう一度回踏んでほしくは無いと思ったので私の例を紹介したいと思います。

環境

私の環境は下記のような感じです。

  • マシン: 38号機 (N100DC-ITX, DDR4 32GB, SATA SSDx2)
  • OS: FreeBSD 14.2-RELEASE-p2 (amd64)
  • コンパイラ: llvm19-19.1.7_1 (pkg版)
  • MTA: Postfix 3.9.1
  • MDA: Dovecot 2.3.21 → 2.4.1-4
  • DB/認証バックエンド: MySQL 8.0 / Cyrus SASL

MTAはPostfixでVirtual Domainを運用していて、バックエンドはMySQL (≠MariaDB)です。MTAもMDAもソースからのコンパイルです。

DovecotはMRA(Mail Retrieval Agent)としてのみ使っています。PostfixはSubmissionポートをListenしていますが、PostfixのSubmissionの認証バックエンドはCyrus SASL+MySQLで、Dovecotの認証機能は使っていません。そのためDovecotでSubmissionの認証をしている方は書き換えるべき設定がもっと増えると思います。

コンパイルオプション

コンパイルオプションは私の場合下記です。

zlib関係(ZLIB_CFLGS, ZLIB_LIBS)

前述のように私はバックエンドにMySQLを使っているので、--with-mysqlを入れています。

2.3.21の頃は--with-mysqlのみでconfigureが通ったのですがが、私の環境の2.4.1は後ろにZLIBのパラメータを入れないと下のような文句を言ってきて./configureが正しく終わらなかったため渋々入れました。

libbsd

--with-libbsd は証明書周りの挙動が不審(SNI別の設定を消すとSegmentation Faultする)だったので入れたらよくわかりませんがあ動くようになりました。まぁ現場猫クオリティで入れたので、もしかしたら--with-libbsd は付与しなくても大丈夫かもしれません。

configureが終わったらmake allでコンパイルします。

make install前にやること→旧バージョンのmake uninstall

コンパイルしたらインストール前に設定移行作業をすると思いますが、とりあえずここでは一旦これからインストールするという前提で話をすすめます。

このセクションは2.3系以前のDovecotが動いている方のみ該当します。

2.3系以前のDovecotが動いている場合、コンパイルが終了後、2.4系のインストール前にserviceコマンドでdovecotを停止し、今使っているバージョンのディレクトリでmake uninstallして既存のDovecotをアンインストールしてください。

私は雑にmake installで新バージョンを上書きしたのですが、下記のようなエラーログが出てIMAPSがまともに動きませんでした。

旧バージョンをmake uninstallしてから新バージョンを入れたら上記は出なくなったので2.3系以前のDovecotは一旦消すことをお勧めします。

make install後にやること→imap-hibernateのコピー

これはFreeBSDで、インストールは完了してて次はserviceコマンドでDovecot起動しようかなという状態での話です。

make installでインストールが終わったらcd src/imap-hibernateに移動して引数なしのmakeコマンドでimap-hibernateをコンパイルしてください。
コンパイルが通ったら出来上がったimap-hibernateをcp -pi でlibexec/dovecot(※)にコピーしてください。

※Dovecotは特にインストールディレクトリを指定しなければ/usr/localに入るので先述の「libexec/dovecot」は「/usr/local/libexec/dovecot」になるはずです。

この工程を省くと、dovecot起動時にimap-hibernateがねーぞ、ボケ、と怒られます。

これ、dovecotが上がらないので渋々入れたんですがなぜ起動時にimap-hibernateを求めるのかは謎です。そもそもIMAP Hibernate は 下図のようにFreeBSD(のようなkqueueベースのシステム)ではサポートしない。と明記されています。

Dovecotのマニュアルより引用
IMAP | Dovecot CE, https://doc.dovecot.org/2.4.0/core/config/imap.html , 2025.04.05閲覧

確かにimap-hibernateはFreeBSDではmake allではコンパイルされませんし、予めmakeでコンパイルしておいてもmake install時にインストールしてくれません。それなのに何故か起動時には存在していないとmasterプロセスが上がってこない不思議仕様なのでこのような対応を入れています。

正直意味不明なんですが、まぁDovecot CEにとってはFreeBSDはベストエフォート対応らしいので諦めです。

dovecot.conf

※新旧の設定は同一の筈です。

ここから先は設定関連です。私は2024年に25号機から38号機に移行した際にdovecotは25号機と2024年当時の最新のデフォルトの設定ファイルを比較して新しいファイルに設定を書き込んだので元設定はそんなに古くないと思います。

OX Dovecotでは「Example Configuration」で設定例を配布しているので、dovecot.confに限らず書き方に悩んだらこのファイルを参照すると良いと思います。まぁ後で出てくるんですがコメントが正しいとは限らないトラップがあったりしてそれでも面倒ですけどね。

ちなみにdovecot.confも含め、私が引っかかった部分しか書いていません。私より設定がもっと複雑な方はもっと書き換える部分が多いと思います。

設定ファイルのVersion定義

まずはdovecot.confです。以下、青緑が差分です。

2.3.x2.4.x
# --sysconfdir=/etc --localstatedir=/var
# Protocols we want to be serving.
# protocols = imap pop3 lmtp submission
protocols = imap


# --sysconfdir=/etc --localstatedir=/var
# Config header
dovecot_config_version = 2.4.0
dovecot_storage_version = 2.4.0

# Protocols we want to be serving.
# protocols = imap pop3 lmtp submission
protocols = imap

dovecot_config_versionとdovecot_storage_versionは2.4から新たに導入された設定値で、Dovecotの一連の設定はこの定義から始まらないと起動時に怒られます。設定ファイルの先頭にある必要まではありませんが、dovecotの設定はこの2つのパラメータから開始する必要があります。

私の場合2.3系の設定はprotocols = imapから始まっていたので、そこより上なら別にどこでもよかったのでテキトーにprotocls = imapの真上に入れました。

dictディレクティブ

2.3.x2.4.x
dict {
#quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
}
#dict {
#quota = mysql:/etc/dovecot/dovecot-dict-sql.conf.ext
#}

dictサービスは無くなったのですべてコメントアウトしました。

conf.d配下

次移行はconf.d配下です。conf.dは複数のファイルがありますが、ここで挙げてないファイルは私は/usr/local/etc/dovecot/conf.dに入れていません。

10-auth.conf

※新旧の設定は同一だと思います。

2.3.x2.4.x
# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
# matches the local IP (ie. you're connecting from the same computer), the
# connection is considered secure and plaintext authentication is allowed.
# See also ssl=required setting.
# disable_plaintext_auth = yes
disable_plaintext_auth = no
# Disable LOGIN command and all other plaintext authentications unless
# SSL/TLS is used (LOGINDISABLED capability). Note that if the remote IP
# matches the local IP (ie. you're connecting from the same computer), the
# connection is considered secure and plaintext authentication is allowed.
# See also ssl=required setting.
# disable_plaintext_auth = yes
auth_allow_cleartext = yes

disable_plaintext_authは設定名が変わりました。設定名だけでなく設定の意味も変更され、2.3系以前は「無効をNo」でプレーンテキスト認証が有効でしたが、2.4系は「許容をYes」でプレーンテキスト認証が有効となりますので上記は設定としては同一です。

私はインターネット向けはIMAP over TLSしかLISTENしておらず、プレーンテキスト以外の認証は設定が面倒臭いのでプレーンテキストOKにしています。

10-logging.conf

※新旧の設定は同一ではない可能性があります。

2.3.x2.4.x
# mail_log plugin provides more event logging for mail processes.
plugin {
# Events to log. Also available: flag_change append
#mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
# Available fields: uid, box, msgid, from, subject, size, vsize, flags
# size and vsize are available only for expunge and copy events.
#mail_log_fields = uid box msgid size
}
# mail_log plugin provides more event logging for mail processes.
mail_plugins {
# Events to log. Also available: flag_change append
#mail_log_events = delete undelete expunge copy mailbox_delete mailbox_rename
# Available fields: uid, box, msgid, from, subject, size, vsize, flags
# size and vsize are available only for expunge and copy events.
#mail_log_fields = uid box msgid size
}

pluginブロックの設定名が変更になりました。私はプラグインは特に使っておらず、こう変えたら動いたという感じなので設定としては新旧同一ではない可能性があります。

その他ログ関係

実運用の設定は上記のみなんですが、検証やトラブルシュート等でログを詳細(verbose)にしたい場合、下記のようにVerboseの指定方法が変更になっています。2.3系以前のno相当の設定はなさそうで、無効化する場合はコメントアウトです。(まぁ2.3.xもnoを入れずにコメントアウトで無効化していましたけど)

2.3.x2.4.x
auth_verbose = yes
auth_debug = yes
mail_debug = yes
verbose_ssl =
yes
log_debug=category=auth
log_debug=category=mail

log_debug=category=ssl

ログ系の細かい内容はマニュアルのLogging Verbosityのところにあります。

10-mail.conf

※新旧の設定はたぶん同等です。

Virtual DomainでMaildirを利用している場合の設定になります。

2.3.x2.4.x

# mail_location =
mail_location = maildir:/path/to/vmailbox/%d/%n

# mail_location =
# mail_location = maildir:/path/to/vmailbox/%d/%n
mail_driver = maildir
mail_path = /path/to/vmailbox/%{user | domain }/%{user | username }

mail_locationはなくなり、mail_driver / mail_path / mail_inbox_pathの3つに分割されました。また、プレースホルダ(%dとか%n)も変更になりました。

設定としてはmail_driverでMaildirの使用を明示したのち、mail_locationと同等の設定をmail_pathに書きます。

マニュアルには.INBOXを指定するmail_inbox_pathの例がありますが、mail_inbox_pathは省略するとmail_pathと同一になります。私はmail_inbox_pathは省略しています。

こうしている理由ですが、2.3系のmail_locationは、ここで指定されたパスを.INBOXとみなして、.INBOXに格納されるべきcurやnewをmail_locationで指定したディレクトリに散らかす構造になっています。本当は.INBOXは.INBOXディレクトリに入れたいのですが、mail_inbox_pathを明示すると今までmail_locationに散らかされた内容が見えなくなると怖いのでこのようにしました。

プレースホルダの末尾のスペースはマニュアルにそう書かれているのでコピペしました。

「/path/to/vmailbox」の部分はVitual Domainのメールボックスのルートとなるディレクトリで、MTAがPostfixの場合、virtual_mailbox_baseの設定と一致させる必要があります。

面倒なので検証していませんが、マニュアルによると(非Virtual Domainのように)どうもhomeディレクトリ配下にMaildirを設ける場合は下記のような書き方が必要っぽいです。

    home=/path/to/user/home/
mail_path=/path/to/user/home/Maildir/

10-ssl.conf

※新旧の設定は同一ではないかもしれませんが同等の筈です。
※SNI明示(local_name)のSSL証明書設定はFreeBSDのバイナリpkg版のcertbotで取得したLet’s Encryptの例です。ただしドメインは架空です。

2.3.x2.4.x

ssl_cert = </etc/ssl/certs/dovecot.pem
ssl_key = </etc/ssl/private/dovecot.pem
ssl_dh = </usr/local/etc/dovecot/dh.pem
local_name mail.yuaiho.net {

ssl_cert = </usr/local/etc/letsencrypt/live/mail.yuaiho.net/fullchain.pem
ssl_key = </usr/local/etc/letsencrypt/live/mail.yuaiho.net/privkey.pem
}

ssl_server_cert_file = /etc/ssl/certs/dovecot.pem
ssl_server_key_file = /etc/ssl/private/dovecot.pem
ssl_server_dh_file = /usr/local/etc/dovecot/dh.pem
local_name mail.yuaiho.net {
protocol imap {
ssl_server_cert_file = /usr/local/etc/letsencrypt/live/mail.yuaiho.net/fullchain.pem
ssl_server_key_file = /usr/local/etc/letsencrypt/live/mail.yuaiho.net/privkey.pem
}
}

SSL証明書、鍵、DHパラメータの名前・指定方法が変わりました。名前だけでなく値の書き方も変更されて、内容もパスの指定のみでよくなりました。旧の方は「</path/to/ssl.pem」で中身を食わせていますが、新はパスのみの指定になっています。

ちなみに、食わせるという書き方自体は2.4系でも有効っぽいので単に%s/ssl_/ssl_server_/で置換するとリロード時に食うは食いますが、2.4系のssl_server_*_fileはファイルパスを文字列で設定する値であって、pemファイルの中身を食わせる設定ではありません。そのため雑に設定名だけ変えて不等号マークを残したままdovecotリスタートするとdovecotがバグります。というか、バグらせました。

あと、クライアントが送信するSNI(Server Name Indication)毎に、サーバが送信するサーバ証明書を変更する設定はlocal_nameのままです。ただ、直下にSSL証明書関係のファイルパスを直接指定することは出来ず、プロトコル指定が必要になったようです。直接書くとdovecotの起動時にCoreを吐いてSegmentation Faultで落ちます。

私の環境ではSegmentation Fault出たら真っ先に疑うのがこの部分です。

10-master.conf

このファイルは2.3時代には設置しておらず、2.4でチューニングが必要なことがわかったため、新規で「Example Configuration」から丸コピして(渋々)作りました。変更箇所は下記です。

service imap-login {
inet_listener imap {
#port = 143
}
inet_listener imaps {
#port = 993
#ssl = yes
}

# Number of connections to handle before starting a new process. Typically
# the only useful values are 0 (unlimited) or 1. 1 is more secure, but 0
# is faster. <doc/wiki/LoginProcess.txt>
#service_restart_request_count = 1
service_restart_request_count = unlimited

# Number of processes to always keep waiting for more connections.
#process_min_avail = 0

# If you set service_restart_request_count=0, you probably need to grow this.
#vsz_limit = 256M # default
}

service_restart_request_countの設定を1から変更しています。それ以外はサンプルのままです。

1がどうもデフォルト値っぽくて最高のセキュリティらしいので1にしたいところですが、1のまんまだとdovecotのログに「anvil: Warning: conn unix:anvil (uid=0): Handshake with duplicate service=imap-login pid=-1 – replacing the old connection」が結構な量記録されて鬱陶しいです。

マニュアルには100や1000が良いだろうみたいなことが書かれています。確かに100にすると上記のログは減るは減るのですが、私一人しか使っていないような環境でも抑制しきれていないので渋々unlimitedにしました。

ちなみに、「Typically the only useful values are 0 (unlimited) or 1.」と書かれていますが、1は指定できても0は指定できません。0を指定すると下記のように起動時に0を超えた値にしろボケ、と怒られます。ただ、0と同じ意味らしいunlimitedは指定できます。

Starting dovecot ...
doveconf: Fatal: Error in configuration file /usr/local/etc/dovecot/dovecot.conf: service(imap-login): restart_request_count must be higher than 0 (did you mean "unlimited"?)

15-mailboxes.conf

このファイルは2.3のデフォルトのままなんです。特に変更しなくても動いています。

auth-sql.conf.ext/dovecot-sql.conf.ext

※同等だと思うけどdovecot-sql.conf.extの設定の一部は移植しておらず。

2.3.x2.4.x
passdb {
driver = sql
# Path for SQL configuration file, see example-config/dovecot-sql.conf.ext
#args = /etc/dovecot/dovecot-sql.conf.ext
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
}


userdb {
driver = sql
#args = /etc/dovecot/dovecot-sql.conf.ext
args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
}

mysql 127.0.0.1 {
user = DBのユーザ名
password = DBのパスワード
dbname = DB名
}


sql_driver = mysql


passdb sql {
#driver = sql
# Path for SQL configuration file, see example-config/dovecot-sql.conf.ext
#args = /etc/dovecot/dovecot-sql.conf.ext
query = dovecot-sql.conf.extのpassword_queryの値を入れる。
}


userdb sql {
#driver = sql
#args = /etc/dovecot/dovecot-sql.conf.ext

#args = /usr/local/etc/dovecot/dovecot-sql.conf.ext
query = dovecot-sql.conf.extのuser_queryの値を入れる。
}

このファイルですが、SQLの設定の外出しができなくなり直書きが必要になりました。そのため「dovecot-sql.conf.ext」は不要になった・・・と思います。

mysqlディレクティブ

2.3系以前ではSQLの設定はdovecot-sql.conf.extとかいうファイルを作って、そこにconnect = host=/tmp/mysql.sock dbname=DB名とかでSQLの設定を書き、auth-sql.conf.ext側ではargsでdovecot-sql.conf.extのファイルパスを指定すればよかったのですが、この方法はNGになったっぽいです。

そのため2.4系でMySQLバックエンドを使用するには本ファイルのmysql <接続先>ディレクティブでDBの接続先定義と、sql_driverでSQLエンジンを選択します。代わりに、passdb/userdbからはdriverを消します。ただ、passdb/userdbからdriverは消さなくても文句は言ってこないです。

127.0.0.1はドメインソケット接続ではなくTCPで接続している可能性があります。が、これは個人的にはどっちでもいいので未検証です。

passdb/userdb

passdbとuserdbは名前を定義する必要があります。この部分の名前はテキトーではダメらしく、SQLの場合は「sql」で固定なようです。mainとかhogeとかのテキトーな名前だと、dovecot起動時に「中にqueryとか意味わからん設定があるんだけど?」と怒られます。passdbやuserdbが複数ある場合はsqlN(Nは数字)が許容されるっぽいです(未検証)。

argsは無くなりました。代わりにqueryにSQLを直書きします。

queryに書くSQLはargsで指定していたファイル(dovecot-sql.conf.ext)をプレースホルダだけ気をつけてそれ以外はそのまま移植すれば大丈夫です。移植元はuserdbディレクティブのqueryは「user_query」の設定値を、passdbディレクティブの場合は「password_query」の設定値を移植します。

これ、dovecot-sql.conf.extにあった「iterate_query」をどこにも移植していない気がしなくも無いんですが、とりあえず動いているっぽいので今回は見なかったことにします。

前述の通り、driver = sqlは消しても消さなくても動きます。謎です。

所感

2.4系への移行は、DovecotからのアナウンスではMigration Guideを見て注意深くやれ(Please carefully review before https://doc.dovecot.org/main/installation/upgrade/2.3-to-2.4.html installing new packages.)のようなことが書かれていますが、まともに検証しないで導入するいい加減なサンデーオペレーターの私の環境ですら上記の如くトラップだらけです。

そのためガイドを熟読するよりも、通り一遍見て、service dovecot startで文句言ってきたところを一つづつ潰していくのが実務としては効率的ではないかなと思います。まぁ、要するにゴリ押しなんですが、そう言っても2.4系は設定によっては起動時にログを出すこともなくSegmentation Faildで簡単に死んじゃうので、この戦法も確実では無いのが非常に面倒なところです。

まぁCoreダンプ読める人なら関係ないんでしょうけど私には無理です。

28号機の更改(3期構成→4期構成+各パーツ修繕)

先日…といってもこれもまた結構前なんですが、28号機の更改を終わらせました。28号機は去年の暮れあたりに、Gemini Lake RefreshでJ4125-ITXでASRockJ4105-ITXの置き換え(マザーボード入れ替え)を行い、28号機4期構成となりました。この時はマザーボードのみを取り替えるいつもの手抜き更改をしました。

ただ、ファンと電源は新造時(2015年)から同じものをずっと使っていました。SSDも2期構成からずっと同じです。OSもCentOS7で、建造当時の2015年時点では最新ですが、2024年ではEoSL寸前です。色々と見過ごせないレベルで古いパーツやソフトウェアが跋扈してる状態だったので、これらも全部入れ替えてリフレッシュしました。

28号機の用途は先日書いた39号機の対向側にいるOpenVPNサーバ(L3VPNルータ)です。

マザーボード

28号機4機構成のマザーボードはJ4125-ITXです。

28号機3期ではASRock J4105-ITXでした。ASRock J4105-ITXは16号機3期構成にも搭載されていました。この16号機側のJ4105-ITXは元を辿ると13号機(4期構成)のお下がりなんですが、2022年ごろからHDD LEDの挙動が怪しく、点灯しっぱなしだったり正しい動作したりと非常に気持ち悪く、交換したい気持ち満々でした。

ただ、2023年にもなってJ4105-ITXを新品で買ってくるのはさすがにバカバカしいです(売ってはいました)。そこで、修理したい16号機と同じASRock 4105-ITXを積んでいる28号機3期を更改して、余ったマザボでJ4105-ITXを修理しようとしてできたのがこの28号機4期構成です。

13号機や21号機はJ5040-ITXを積んでるので、28号機もJ4125-ITXの上位版であるJ5040-ITXを入れたかったです。ただ、J5040-ITXは2023年秋の時点では正規販売がなくなっていたので、妥協してJ4125-ITXにしました。

マザーボードだけ入れ替えは2023年の秋にやったのですがその時は、それ以外はそのままでした。

メモリ

メモリはCFD PanramのDDR4 SO-DIMM 8GBx2枚で16GBにしました。3期では4GBx2枚の8GBで、マザーボードを入れ替えて4期構成にした時点ではこれを使い回しましたが、ファンやSSD、電源交換に合わせてメモリも交換して16GB化にしました。

まぁ、ぶっちゃけるまでもなくこのマシンの用途に対して16GBは過剰なんですが、2021年ごろからメモリは最低16GB積むことにしたので16GBです。まぁOSの名前以外はほぼ同じ構成で同じ用途の39号機は32GBなのでそれに比べれば全然控えめです。

CFD Panramなのはまともブランドで安い製品を選んだらこれでした。まぁ個人的にはCFDと言う会社はあんまり好きでは無いのですが、CFD ElixerやCFD Crucial、CFD Panramあたりのメモリに関しては安い割に不良が殆ど無いので楽です。信頼できるんじゃないかなと思います。

ストレージ(SSD)

ストレージはCrucial MX500 120GBから、HP(Hewlett Packard)のS600シリーズのSATA 240GBに置換しました。4期構成にした時はMX500を続投したのですが、ファンや電源、メモリ交換に合わせてSSDも交換しました。3期構成も4期構成も1台構成です。

PCメーカー製(HP)という珍しいSSDです。まぁ、どうせ中身はどっかのOEMでしょうけど、中華製ではないまともなメーカーで、コントローラがSiliconMotion製(SMxxxx)ではなく、TBWが100GB以上ある250GBのSATA SSDで最も安いのはHP S600の240GBでした。

Crucial MX500 120GB自体はまだ全然使えたのですが、中身がCentOS7でアップグレード先が無く、後継で使う予定のAlma LinuxがOpenVPNルータの用途に耐えるかは1ミリも検証してませんでした。さすがにそのまま上書きして入れる勇気は無く、SSDは入れ替えてCentOS7の環境は保持することにしました。

ファン

28号機は実家に置いてあって、夏は50℃近くまで上がる過酷な環境です。そのため、実家に配備しているすべてのマシンに強制空冷ファンが付いて居ます。28号機も同様に強制空冷ファンがついています。

28号機の元のファンは新造時に一緒に買って付けたもので、オウルテック扱いの山洋電気 SF8-S1を2発です。SST-ML06Bは80mmファンが2基と120mmファンが1機付く構成ですが、ファンはすべてオプションで付属品はありません。そのためこの山洋電気のファンも私が新造時に一緒に買ってきて入れました。当初は吸気ファンだったんですが、2期目にしたあたりで天板にフィルタをつけたので、裏返して排気ファンに入れ替えています。

ファンは2発とも内側にグリル(フィンガーガード)をつけています。ケーブル巻き込み防止のためですね。グリルとファンはM4x35mmの皿小頭ビス(黒)とセレート付きフランジナットで固定しています。筐体色と同じでビスが筐体とツライチになるようにしてビスが目立たないようにしてあります。こだわり部分です。ちなみにM4x35mmの皿小頭ビス(黒)はモノタロウで買いました。モノタロウの注文コードは41691377です。ちなみにこの注文コードは普通にモノタロウに出てるので、これを指名買いで買っても私には一銭も一報も入りません。

セレート付きフランジナットは締めると緩みにくくワッシャーも不要で、共回りしにくいため把持用の工具なしでビスを回せるので、ファンを貫通ボルトで止める際のナットとして便利です。

話を戻すと、元のファンはさすが山洋電気製だけあって、温度差の激しい実家で9年近く過ごしても壊れてはいません。ただ、異音は出ていました。交換品を探したところ、新造時に買ったSF8-S1が2024年でもディスコンになっておらず、当時ほぼ同じ値段で買えたので、同一型番の新品で置換しました。

SF8-S1はPWM制御ができない3pinファンなので電圧制御しています。ファンがPMWに対応したところで、どのみちJ4125-ITXのマザーボード側コネクタは3pinなのでどのみち電圧制御でしか運用はできません。

SF8-S1の定格速度は800rpmですか、マザーボード側のファンコンで調整して凡そ400〜500rpmで回してます。ちなみにMBのケースファン側の制御を最低レベルにしたら交換前は回ってたのに交換後のファンは回りませんでした。まぁ、山洋電気のファンは11.4V未満の動作保証は無いのでこれは個体ですね。

28号機はフルパワーでもせいぜい20W程度で、筐体もファンも発熱量に対してはかなり余裕があります。そのため8cmファンをゆるゆる回していれば余裕で排熱出来ます。というか、不必要に高速で回すと埃が早く溜まるので、出来る限り回転速度を落としています。

電源

電源は13/21/33号機と同じに構成にしました。Mini-box picoPSU-120-WI-25 と Meanwell GST90A19-P1Mの構成です。

28号機のSST-ML06BはSFX電源が入るケースで、記憶が怪しいのですが昔はたしか電源付きで売られていました(と思います)。もとの電源はその付属品(たぶん)で、SST-SF300というSilverstone製の80PLUS BronzeのSFX電源(300W)でした。この電源は新造以来一度も交換しておらず、最も故障を懸念していたパーツでした。まぁ懸念しつつも2022年ぐらいから交換の検討してて、19号機同様にFSPあたりのフルプラグインにしたいと思っていました。28号機のようなシンプルな構成で直付けだと使わない電源コード・コネクタが多くて邪魔です。次ぐらいに写真があると思いますが、実際に使わないケーブルは無理やり押し込んでいました。

下の写真はSST-ML06の電源とストレージエリアなんですが、このケースはこの部分の設計がクソで、プラグイン電源は(入る気はしますが)ちょっと収まる自信がありません。写真の電源はSFXの規格サイズ(奥行き100mm)なので特に大型のものを搭載しているわけでは有りません。

28号機の電源・ストレージエリア

28号機は前々からACアダプタ電源化したかったのですが、SFX用DCジャックのホールがあるパネルが2019ぐらいを堺にオリオスペックから取扱いが無くなったので困っていました。仕方ないので、34号機の引退を機に、34号機にから剥がして持って来て、34号機は中国の某有名通販サイトから買った怪しいSFXのアルミグリルのパネルをつけることにしました。

picoPSU-120-WI-25 をSST-ML06B + J4125-ITXにつけると、基板とコネクタ部の屈曲が気にならなくはないですが、まぁそれなりに無難に取付できました。ただ、SST-ML06のSFXパネルとJ4125-ITXのATX24pinコネクタは若干遠いので線はそこそこピン張りになります。J4125-ITXのATX電源コネクタは24pinですが、picoPSU-120-WI-25 はのコネクタは20pinです。しかし、変換せずATX24ピンのコネクタに20ピンだけさしてに挿して使っています。これは13/21/33号機も同じです。なのでマザーボード側のATX24ピンは4ピン分空いています。まぁこの4ピンはPCI/PCIeの電源強化らしいので、何も刺してないに近しい28号機なら問題はありません。

ACアダプタは私の中で採用実績豊かなMeanwell GST90A19-P1Mです。50℃雰囲気での寿命や60W出力を担保できて、最も安いのがこの機種です。DELTAも選択肢にはありましたが、同様の性能で1.5倍ぐらい高い割に温度デグレードが大きいのでMeanwell GST90A19-P1M一択です。

電源を交換したら16W前後食っていたのが14W程度になりました。構成の割には大食いな気もしますが、PCIeの増設カードを積んでるという要素もあるため致し方ないという感じです。

OS

OSは元がCentOS7だったので、Alma Linux 9.4を入れています。インストールはMinimum Installです。ここにEPELリポジトリを追加してOpenVPNをインストールしています。このOpenVPNは先日の39号機同様のディレクトリ分けがあります。

このAlmalinuxはSELinuxを有効にしています。SELinuxはMinimum Installでも有効なんですが、Rocky Linux 9.4ではデフォルトでインストールされるsemanageが、何故かAlmalinuxではデフォルトでインストールされません。まぁ、dnfで普通に入れられますが手間かかって面倒ですね。

39号機的な説明をすると、28号機は21号機のOpenVPNサーバの部分だけ切り出したマシンです。なのでブランチ元の21号機のOSに倣うならUbuntu Server LTSです。実際、28号機は導入当初は本当にUbuntuだったんですが、Intel C1 State Bugを対応している過程でCentOSに入れ替えたのでそのままRHELの流れを汲む方向になりました。

NIC

39号機と同一機種のにtp-linkのNIC(ギガ蟹)が積んであります。tp-linkのNICは新造時からあったものではなく、新造時IntelのNIC(Intel Gigabit CT Desktop Adapter)を積んでいました。しかし、対向側にいる34号機を新造した時に増設NICをtp-linkにしたので、28号機も合わせる形でIntelからtp-linkに交換しました。

Intelからtp-linkにしたのは基板面積や消費電力がIntelより小さかったからです。というか、以前のIntelのNICは2009年ごろに17号機に搭載するつもりで買って6年ほど放置していた余剰品です。2000年代のGbEのNICは今ほど省電力化も進んでいなくて、基板が大きかったです。28号機建造当時は金がなかったのでNICは余り物を入れてましたが、物理サイズと電力消費が嫌で省電力なtp-link(Realtek)にしました。消費電力も若干下がってたと思います。

ちなみにこのIntel Gigabit CT Desktop Adapterは正規流通品を買ったわけではないので偽物かもしれませんが、現物を捨ててしまったので謎です。

コメント

9年近く稼働してて不安要素が多々あった28号機でしたが、ケース以外を総取り替えしたおかげでで不安要素はなくなりました。ただ、所詮はSST-ML06なのでこの役目(OpenVPN)が精々かなって感じですね。まぁ安いケースなので仕方ないんですけどね。

39号機稼働開始(34号機更改リプレース)

24、25号機に続き、34号機も更改しました。39号機となりました。

34号機は紹介のページにもありますが、先代の34号機は元々建造計画がなく、障害対応として急造したマシンです。予算も無かったので暫定構成と割り切り、ケース以外は寄せ集めのパーツで建造しました。暫定と言う割にはどこぞの某元暫定CEO(故人)の如く3年以上運用していましたが、建造当初から更改なりリプレースなりの時期だけは決めていたマシンです。

39号機は37、38号機の異母兄弟機みたいな構成で、ケースとSSDは異なりますが、マザーボード、メモリは同一という構成です。

ケース・電源

ケースはSilverstoneのSST-SG13Bです。

先代の34号機のLian-Li PC-Q21のフォルムは結構気に入っていたのですが、PC-Q21は耐タンパ性がゼロなのが課題でした。色々考えましたが、買い換えたほうが安いのでSST-SG13Bにしました。

SST-SG13Bが高耐タンパかと言うと微妙ですが、ロックされたSST-SG13Bは、ノーガードに近くてツールレスでSSDを持っていけるPC-Q21に比べれば面倒です。

曲がりなりにもケースをロック出来て、PCI/PCIeカードが付けられる小型ケースは少なく、(19号機で採用している)SST-SG05BとSST-SG13Bとその後継機しかありませんでした。19号機と全く同じケースを約15年も経ってまた買うのも芸がありませんし、SST-SG16などは交流電源専用みたいな構成で、ACアダプタ運用がしにくいと感じたので、SST-SG13Bとなりました。

SST-SG13BはATX電源ですが、搭載しているN100DC-ITXはACアダプタ直結なのでそのままだと電源部が開口します。それはまずいのでM8のDCジャックが入るホールが付いた、アルミ製のグリルパネルを入れてあります。この手のDCジャックを取り付けできるパネルは、昔ならOliospecで買えたのですが、今はOliospecでは売ってないので海外から通販で買いました。

電源は37・38号機と同じGST90A19-P1Mです。

先代の34号機は秋月で売ってたGo Forward (GF)社製のGF65I-US1934という19V 3.4Aの65W電源を使っていました。秋月のGF社製の電源はまぁまぁ静かで可もなく不可もなくという感じですが、秋月のDC電源のバレルプラグは殆どが2.1/5.5mmなのでそのままでは2.5mm/5.5mmのバレルジャックでは挿さりません。なので変換アダプタを咬ませていましたが、この変換アダプタが地味に鬱陶しいので37号機や38号機と構成を合わせる形にしました。

ケースは異なりますが37号機、38号機同様ゼロスピンドルのファンレス機です。

マザーボード・メモリ

マザーボードとメモリは37、38号機と全く同じです。N100DC-ITXにCFD Crucialの32GBが入ってます。32GBは用途的には過剰ですが、メモリとしては予算内だったで37号機や38号機と合わせてあります。

CFD Crucialの32GBは37号機や38号機と同じもので、2枚セットの片割れを使っているのも同じです。39号機のもう片割れは予備のマザーボードに実装しています。

SSD

SSDはTeam CX2 256GBの1台構成です。

39号機はデータ(所謂ユーザデータ)をほとんど持っていません。そのため耐久性はあまり考慮せず安価なSSDを採用しています。37号機や38号機はシステム用とデータ用(/home用)の2台のSSDを積んでますが、39号機はシステム用とデータ用のSSDを分けていないので1台構成です。

39号機は元を辿るとCentOS5で運用していた14号機から派生したマシンで、その派生機・後継機である29-30-34号機ではCentOS7が入ってました。そのためその後継の39号機でもRed Hat Enterprise Linux(RHEL)系統のOSであるRocky Linuxを入れています。

RHEL系はOSのメジャーアップグレードが難しく、メジャーアップグレードは事実上SSDを入れ替えて新規インストールでしか対応できません。そのため交換を見据えてSSDは安いものにしました。また、39号機はVPNルータ専用機で他の用途を兼任させるつもりが無いので250GBもあれば必要十分です。先代の34号機も2020年新造ですが、SSDは当時にしてすでに8年落ちの2012年製のIntel 320 シリーズのSSD入れてましたしね。どうでもいいですが、このIntel 320シリーズは160GB、300GB、600GBという今にしてみれば結構珍しいラインナップです(参考リンク)。

OS

OSは前述の通り、Rocky Linux 9.4です。最近はRHELでも個人用途なら16本ぐらいならタダで使用可能です。そのためRHELも少し考えましたが、ライセンス管理が面倒なのでやめました。まぁ正確に言うと管理が面倒というより、管理するものをあまり増やしたく無いのでフリーのRocky Linuxにしました。Alma Linuxと悩みましたが、Alma Linuxは実家の28号機に入れることにしました。

このマシンはOpenVPNとNTPしか動かさないので最小インストールにして、EPELリポジトリからdnfでOpenVPNを入れました。

RHEL8系は知りませんが、RHEL9系のEPELのOpenVPNの設定は/etc配下がserver(/etc/openvpn/server)とclient(/etc/openvpn/client)に分かれています。systemctlで呼ばれるUnit名で、設定ファイルを探すディレクトリが変わります。

openvpn-server@hogehoge.serviceでサービス起動すると、/server(/etc/openvpn/server)の設定ファイル(ここではhogehoge.conf)が読まれ、openvpn-server@hugafuga.clientでサービス起動すると、client(/etc/openvpn/client)側の設定ファイル(ここではfugafuga.conf)が読まれます。

例えば、systemctl openvpn.server@y17でOpenVPNを起動すると、/etc/openvpn/server/y17.confを探しに行くようになってます。同様にsystemctl openvpn-client@y17でOpenVPNを起動すると、/etc/openvpn/client/y17.confを探します。

まぁ、openvpn-server@.serviceで起動しても、openvpn-client@.serviceで起動してても、どちらもUnitファイル内のExecStartでは(引数は若干違うものの)同じ /usr/sbin/openvpn が呼ばれています。なので、実際のOpenVPNの動作(クライアント動作かサーバ動作か)に関わらずをどっちにどっちを入れても動くは動きます。実際、39号機は28号機に繋ぎにいくクライアントモード(tcp-client)で動作していますが、設定ファイルは/etc/openvpn/server/に放り込んであります。

と、言うか、サーバとして動作する設定を/etc/openvpn/server/に入れてopenvpn-serverで起動したからといって、firewallやsemanageをいい感じにやってくれたりすることは一切ありません。なので、個人用なら好きな方に入れてくださいって感じがします。

ちなみに、Alma Linux 9.4のEPELでも同じように分かれています。

NIC

このマシンはPCIeスロットにNICを増設しています。増設NICを刺すために37号機や38号機とは異なったケースを採用しています。

NICはtp-linkのREALTEKチップのやつです。所謂蟹チップです。ギガ蟹です。このNICでNTTのNGN(IPoE)のIPv6網に接続して、実家とLayer 3 VPNを組んでいます。

ギガ蟹使ってるのは消費電力・発熱の問題もありますが、正直蟹でも十分なので蟹にしています。まぁ、蟹がいいと言うより、(私の場合は)Intelに値段なりの価値を見出せなかったというのが正しいです。Intelは良いかもしれませんが、(自宅のブロバン環境がクソなのもあって)私はRealtekで特に困っていません。

蟹NICは上級者には割と不評なんですが、最近のギガ蟹なら殊更に不安定や遅いとかはまずありません。ただ、Realtekのドライバはハズレも有り、ハズレ具合によっては速度以前に動作が不安定だったりします。今時のRealtekのドライバはOSで標準で添付されてたりしますが、特にFreeBSD添付のものはクソでしたね。

あと、RTL8111系やRTL8168系のチップはRHEL7系とかだと何故かRTL8169系のドライバが入ることがあります(参考リンク)。何故かRTL8169系でも8111や8168がそれっぽく動くんですが気持ち悪いです。またドライバが良くても各種オフロード系(gsoやgro等)を正しいチューニングしないとまともに速度出ないことがあります。難しいと言えば難しいチップです。

この辺を勘案すると、上級者に不評な蟹NICですが、運用は自体は上級者向けですね。値段は素人さん向けなんですが、素人さんはポン付けでもまぁまぁ動くIntel製を買われた方が(個人的には)無難だと思います。まぁそういってもIntel製のNICは量販店とかになかなか売ってないんですけどね。

ちなみに、M.2 E Key (iCNV Wi-Fi用のM.2はEキー)から有線Ethernetを生やす怪しいNICを買ったのですが、MACからして怪しかったので使うのをやめました。

チューニング

37号機や38号機同様、電力設定はチューニングしています。チューニングは37号機と同じでPL1=10W, PL2=25W Autoから、PL1=6W, PL2=10W 10sにしています。この状態で44℃前後です。

39号機はファンレスですがケースがスカスカでガバガバなためデフォルトでも実は大きな問題はありません。デフォルトでも温度的には全然問題ないのですが、N100DC-ITXはコイル鳴きが結構喧しく、スカスカガバガバなケースではコイル鳴きの音が結構よく通ります。

コイル鳴きは電流変動が小さい方が音を小さくできるので、発熱よりもコイル鳴き対策で電力設定をチューニングしています。性能的にはもっと制限を厳しくしても大丈夫なんですが、設定値を管理(記憶)したくなので37号機や38号機と同じ設定を入れています。

そのため、ケースは触っても動いていることがわからないぐらいの温度になっています。

建造所感

39号機はOpenVPNを積んだルータ相当のサーバですが、正直OpenVPNを動かすだけなら今や独立したx86のPCである必要を感じないのも事実です。OpenWrtを積んだBBルータやNanoPiなどのSmall Board Computer(SBC)などでも充足出来ると思ってます。

ユニットコスト面でもx86で新造すると200USD前後(30k円)かかるのに対してSBCなら大体170USDぐらいでなので、x86で作るメリットってなんだろうと思わなくはありません。まぁ、もう組んでしまいましたけど。

38号機稼働開始(25号機更改リプレース)

先日(と言いつつ結構経ちますが)、24号機に続き、25号機の後継として38号機の稼働を開始しました。購入後約11年弱、運用自体は2016年からですが、トラブルはありつつも8年近い運用にピリオドを打ちました。

38号機の主な構成

Silverstone SST-ML10のケースにASRock N100DC-ITXを組み込んだものです。メモリはCFD Crucial DDR4-3200の32GBx1です。これにMeanwellのGST90A19-P1Mという19V 90WのACアダプタで電力供給しています。

先日稼働した37号機とはSSDとOSを除き全く同じ構成です。というか、37号機と38号機でハードウェア的に違うのはSSDだけです。それ以外はブザーやSATAケーブル、後から付けた縦置用のゴム脚に至るまで同一構成です。

置き換え元となる25号機(と24号機と34号機)はすべてゼロスピンドル機で、静粛性と耐衝撃性の向上、並びに通常運用中のメンテナスフリー化を志向したマシンです。38号機もこの志向を引き継ぎいでゼロスピンドル機としました。Twitterでは120mmファンを搭載しようかと呟いていたのはこの38号機のことなんですが、メンテナンスフリー化は捨てがたいのでゼロスピンドルで組みました。

ケース・電源

ケースは前述の通りSilverstone SST-ML10です。前述の通り37号機と全く同じです。シリアル番号までほぼ同じで、最後の桁以外は全く同じです。37号機と同じ構成ですが、37号機側が流用で38号機側オリジナルです。

プラットフォームはMini-ITXを採用し、電源もボードタイプやpicoPSUいずれでも行けるように配慮した構成にしてあります。これは、故障が頻発してマザーボードの予備をすべて失っても最悪その時に売ってるMini-ITXのマザーボードを使えるようにしてあります。また、2.5インチSSDを2台搭載出来る構成にしてあります。

電源は実家で稼働実績にあったMeanwell社のGST90A19-P1Mです。37号機と同一機種で、37号機同様にDigikeyで買いました。Efficiency Level VI対応です。

カタログスペック上の効率は90%です。Efficiency Level VIが嘘でないなら、90Wクラスの電源であれば少なくとも87%はある筈です。最近流行りのGaNトランジスタを使用しているかは不明です。GaNトランジスタの採用を謳ってる機種と比べると90Wという容量の割に嵩張ります。ただ、表面積が大きい方が放熱、つまり寿命面では有利です。まぁ、とは言え、13W程度の消費電力でも電源が入っていることがわかる程度には発熱します。

GST90A19-P1Mはファンレスですが本体に青色LEDの通電ランプがあり、これがなかなかの光量で光ります。夜中は目に刺さるのでLightDimの減光用のシールを2枚重ねで貼っています。

マザーボード・メモリ

マザーボードはN100DC-ITXです。マザーボードも37号機とは製造番号が一つ違いのものを使用しています。ちなみに製造番号は隣り合ってましたが、MACアドレスは第5 WORDは同一だったものの、第6 WORDは隣り合っていませんでした。

37号機でも買いた通り、マザボはデスクトップ用のDDR4-DIMMを1枚だけしか搭載出来ないので、CFD Crucialの2枚セット品を買ってそのうちの片割れを使っています。もう片割れは37号機で使っています。

SSD

SSDは2台構成なのは37号機と同一ですが、2台とも37号機とは異なるモデルを搭載しています。

38号機のSSDはTranscendのSSD470K (以下、SSD470K)というシリーズの1TBと250GBを採用しました。これは産業用で、書き込み寿命が250GBモデルは591TBW (推定)、1TBモデルでは2,365TBW (推定)ある製品です。(DPDW2.16@3年から計算)。

コンシューマー用のTBWは250GBのSSDで100〜200TBW程度、1TBだと400〜600TBW程度で、DPDW@3年の値は大体0.7前後ぐらいが相場なのでコンシューマ用と比べると2.5倍以上の書き込み耐性があります(2024年現在)。

Transcendの産業用のSATA SSDには他にSSD422Kというのがあり、こちらも検討はしました。比較は下記です。SSD422KはDPDWが2.6とちょっと高いぐらいですが、アクティブ時の消費電力が470Kの約1.5倍、値段が470Kのざっくり2〜2.5倍と色々コストが高いので470Kの方を買うことにしました。ちなみにSSD470Kは112層の3D-NAND構成ですが、SSD422Kは2D-MLC NAND構成みたいです。その所為か定かではありませんがカタログ上のIOPSはSSD422Kの方が低いです。

Transcend SSD470Kの消費電力、TBW
https://jp.transcend-info.com/embedded/product/embedded-ssd-solutions/ssd470k-ssd470k-i (2024.06.09閲覧)
Transcend SSD422の消費電力、TBW
※2D-MLCとTBWの多さが絶対的正義ではないならSSD470Kの方がお買い得。
https://us.transcend-info.com/embedded/product/embedded-ssd-solutions/ssd422k (2024.06.09閲覧)

SSD470KもSSD422Kも産業用ですが、普通にAmazon上でAmazon販売で売ってるので買えます。ただ、レビュー見るとサポートソフトウェアとかを手に入れるには大口クライアントにならないとダメみたいなことが書かれています。

SSD470Kのアイドル消費電力1.35Wは、昨今のSSDとしては大食いです。昨今のコンシューマー用SSDのアイドル時の消費電力は数百mW、製品によっては100mWを切ってます。そんな中470Kはカタログで1.3Wあり、実機でもPD+20VトリガーケーブルをAVHzYのCT-3経由で見た感じ、だいたいカタログ値通りの電力を消費しています。

正直なところ、このSSD470Kは過剰スペックだと思ってます。欲しかったのはSamsung 860 ProぐらいのスペックのTBW(250GBで300TB前後)なので、250GBで600TBWに迫るTBWは明らかに過剰です。

ただ、860/870系統のSamsungのPro版SATA SSDは検討時には既にディスコンのようで、Amazonでの価格が異様に高く(50K超)、2台で10年間都合1.3W×2=2.6W分の電気代を垂れ流してもまだSSD470Kの方が安いのでSSD470Kにしました。購入費用は2台で約35k円でした。

ちなみに、先代の25号機のSSDは2台で8万円近くしました(※)。そのため2013年の導入当初は更改時も使い回す気満々でした。ただ、25号機に更改するとき、UEFI+GPTにしたつもりが後からBIOS+GPTでOSが入ってたらしいことに気づいたのと、25号機で採用したSSDであるCFD HG6dもIntel 335もTBWが不明(非開示)で残余寿命がわからないので続投しないことにしました。

容量は25号機の頃は512GB+240GBでしたが、38号機では13号機と構成を合わせる形で1TB+250GBにしました。

OS

OSは、先先代(15号機)、先代(25号機)に続きOSはFreeBSD(amd64)です。今回の更改はこのFreeBSDのインストール・運用がなかなか安定せず難航しました。

Intel N100はEコアだけ積まれてる12世代プロセッサですが、どうもFreeBSD14はEコアしか無いのは想定外なのか、デフォルトで起動するとファイルシステム(UFS)操作でクラッシュします。mysql80-serverを/var/db/mysqlを削除してクリーンスタートすると割と簡単に再現します。

なかなか原因と対策が突き止められなくて、IOが怪しいところまではわかったんですがそこからCPU不良を疑ってマザボ変えてみたり、SSD変えてみたり、M.2 PCIeをSATAに変換する基板入れてみたりしても再現してました。

クラッシュする瞬間をiPhoneでスロー撮影したりして色々調べていたら、FreeBSDのMLで/boot/loader.confに「vm.pmap.pcid_enabled=0」を入れると直るかも的な記事をここ(https://www.mail-archive.com/users-jp@freebsd.org/msg00203.html)で見つけました。それで実際に/boot/loader.confに「vm.pmap.pcid_enabled=0」を入れたら嘘のように安定したので、やっと移行作業が出来るようになりました。

このN100DC-ITXはNICにRealtek RTL8111Eが搭載されています。FreeBSD標準添付のドライバがクソなのかなんなのかわかりませんが、SCPするだけでもNICがよくこけるのでRealtekの公式ドライバらしいrealtek-re-kmodのpkgを入れてあります。

移行

移行は15号機や25号機でもやってきたように、新しいマシンを傍らに置いて、ルータでNAPTを止めての移行作業です。1発勝負です。終わった時に脳汁(ドーパミン)が最も出るやり方です。まぁ失敗して戻したことは無いのですが、どのマシンの移行でもトラブルが無かったことも皆無という残念な方法です。

移行で面倒なのは設定ファイルのレビューですね。実はOSやソフトウェアは安定版ではありますが最新版を追ってて、リリース用ML等で新バージョンのアナウンスが出ると速攻で入れてます。しかし、バイナリとは対照的に設定ファイルはインストールしたときからほとんど変わっていません。

現に動いている設定ファイルなので、次のマシンに持っていても動きます(たまに動きませんが…)。ただ、長年使った設定ファイルと最新の設定ファイルを比較すると、今設定していない値に値が定義されていたり、わざわざ定義している値のデフォルト値等が変わって定義が不要になったり、定義している値が非推奨な値になっていることがちょくちょくあります。

このため、更改時には旧設定と新設定を見比べて、古い設定ファイルから新しい設定ファイルに適切に設定を移行する必要があるのですが、これがなかなか面倒な作業でした。ちなみに、今回の一番設定が違ってたのがmysql.cnfでした。FreeBSD10.0で入れたMySQL5.6の設定ファイルでもMySQL8.0でも動くのかーとは思いましたが、結構Deprecatedな設定があったのでそのまま持っていくのは流石にやめて、サンプルConfigから作り直しました。

チューニング

37号機同様、電力設定をチューニングしています。チューニングは37号機と同じでPL1=10W, PL2=25W Autoから、PL1=6W, PL2=10W 10sにしています。38号機はPL2=15W 20sぐらいは欲しいなぁと言うのが正直なところです。ただ、37号機と比べるとSSDの発熱が大きく、安定的に性能を出せる電力はこの辺りかなーって感じで37号機と同じPL1=6W, PL2=10W 10sにしています。

逆に言うと、37号機は38号機よりSSDの発熱が低いのに38号機と同じ設定なので、もっと上げられると言えます。ただ、面倒なので合わせています。

この設定でFreeBSD 14.0で、常温下に縦置きで概ね63〜67℃程度を推移しています。SSDの発熱のせいか37号機よりも10℃ほど高い温度になっています。ただ、先代の25号機もこんな感じの温度だったので、マザーボードなどでハズレ個体引いていなければそうそう壊れることも無いと思っています。

37号機稼働開始(24号機更改リプレース)

先日、24号機(Shuttle XS35V3L)の後継として、37号機の稼働を開始し、24号機の運用を停止しました。24号機は購入後10年、2016年から7年以上運用していましたが、その歴史にピリオドを打ちました。

主要な構成

37号機の主要構成はこちらです。

SilverStone SST-ML10のケースにASRock N100DC-ITXを組み込んだものです。メモリはCFD Crucial DDR4-3200 32GBx1です。N100DC-ITXはSO-DIMM対応ではないので、普通のDDR4メモリです。これにMeanwell社のGST90A19-P1MというACアダプタを繋いでいるのが主要部分となります。

この主要な構成は25号機の後継となる38号機(予定)も全く同じですし、34号機の後継となる39号機(予定)もケース・SSD以外は同じです。

置き換え元の24号機(と25号機と34号機)はすべてゼロスピンドル機です。ゼロスピンドルによる高い静粛性、機器清掃作業の排除(メンテナンスフリー化)、地震等による転倒・落下に対する耐衝撃性の向上を志向したマシンです。

37号機もこの志向を引き継ぎいでゼロスピンドル機としました。Twitterでは120mmファンを搭載しようかと呟いてましたが、メンテナンスフリー化はやはり捨てがたいでゼロスピンドルで組みました。

ケース・電源

ケースは前述の通りSilverstone SST-ML10です。近年のITXケースは、拡張スロット(PCI/PCIe)使用が前提となっています。そのため、ミニタワーみたいな近いケースか、ShuttleやSST-SGシリーズのようなキューブ型、小型化を追求したものであればThin-ITXかDeskminiのようなMini-STXだったりが主流になっています。そのためSilverstone SST-ML10のようなMini-ITXで、かつMorexの血を引く基盤型電源を使用可能なケースは、現代においては希少です。

ファンは50mm x3と、120mm or 140mm x1のファンを設置できますが、前述のようにゼロスピンドルにしたかったため結局は設置しませんでした。そもそもゼロスピンドルでなくても50mmは入手性の問題、120mmはSSDを積むとクリアランスの問題が厳しいので搭載は難しかったです。

電源は実家で稼働実績にあったMeanwell社のGST90A19-P1Mです。Digikeyで買いました。実家で動いているものは1USD≒100JPY前後の時代だったので3,500円程度で買えましたが、昨今の円安で5,500円しました。

この電源、一般的なACアダプタと比較すると安くはないです。しかし、50℃以上の雰囲気でも稼働できて、PSEが付いてて、稼働温度範囲が広く、最高雰囲気温度下(70℃)でも60W出力を担保できる電源がそれなりの値段で1個から買える。ということを考えれば十分に安いとも言えるな選択です。ちなみにMeanwellは台湾の企業ですが、電源本体は中国製です。

マザーボード/メモリ

マザボはN100DC-ITXで、SATAが2ポートあるモデルにしました。m.2のNVMeにしたい気持ちはあるのですが、障害時にデータを抜くのはSATAの方が楽なので今回もSATAです。

N100DC-ITXがJ5040などの従来のASRock製のSoC ITXマザーと大きく異なるのは電源・CPUと、メモリがSO-DIMMでないこと、メモリスロットが1つしかないこと、SATAが2ポートしかない(ASmediaのSATAコントローラがないこと)があげられます。

あと、実用上は問題ないのですが、N100DC-ITXはBoot Beep(起動時のピッの音)音がやたらと汚いです。また、SATA電源はマザボから供給されるのですが、この供給される電圧は12Vと5Vレールのみで3.3Vレールはありません。まぁ、今時SATA3.3V使うストレージはレアですが、ストレージ以外の電源として使う場合は注意が必要です。

このマザボはデスクトップ用のDDR4-DIMMを1枚だけしか搭載出来ません。そのためCFD CrucialのDDR4-2400の32GB/枚のモジュールを買ってきて積みました。N100はIntel ArkではMax 16GBと書かれてますが、ASrock N100DC-ITXの仕様上は32GBと書かれていますし、書いてある通り、32GBモジュールを認識します。

ただ、N100DC-ITXのメモリスロットは1つしかないので(※)、メモリーインターリーブアクセスの機構(≒デュアルチャンネル)は物理的にありません。従って、メモリ不足でないなら無駄に増やしてもパフォーマンス向上は見込めません。私はDDR4はオワコン寸前で、今後は今ほどは安く買えなくなると思ったのでほぼ使わないであろう32GBにしました。私はメモリ積みたがり星人なので大量に詰んでますが、過剰かと言えば一般的には過剰だと思います。

※メモリスロットが1つ: そもそもN100自体のメモリチャネルが1chしかありません。

メモリはマシン4台分を安価に調達するため、CFD Crucialの2枚セット品を買ってそのうちの片割れを使っています。

CFD Crucialは安価ですが、ロウハンマー耐性はちゃんとありました。

SSD

SSDは先代の24号機からそのまま載せ替えました。先代の24号機の導入当初はCentOS6を入れて使っていました。このCentOS6が2020年11月にEoSLを迎えた際、24号機の更改機を新造した暁には新造機ににそのまま載せ替える前提で、24号機のSSDは新しいSSDに交換して、OSをUbuntu LTSに切り替えました。こう言った経緯があったので(だいぶ期間は空きましたが)SSDは載せ替えとしました。

まぁ、これはCentOS6からCentOS7への所謂上書きインストールが結構手間で難しい上に、頑張っても約3年半でCentOS7のEoSLが来るからと言うのもあるんですが、CFDのHG5dというTBW不明のSSDで(すでにGPT+UEFIの時代に)GPT+MBR+BIOSブートしてたのも大きい理由です。

SSD載せ替え後はNICの名前がenpからensに変わりましたが、/etc/netplanの設定ファイルのインターフェース名の名前の一部をenpからensに変えたらIPをそのまま引き継いで普通に動作しました。ついでに、netplanのgatewayキーワードは2020年時点は問題ありませんでしたが、2023年ではdepricateらしいので、routeに直しておきました。

チューニング

電力設定はチューニングしていて、PL1=10W, PL2=25W Autoから、PL1=6W, PL2=10W 10sにしています。デフォルトでもシャットダウンするとかはありませんが、更改前でも性能不足はなく、そんなに熱くしても寿命に響くだけなので下げてあります。

この設定でUbuntu 22.04 LTSで常温下で概ね50〜55℃程度を推移しています。

37号機はハズレのマザーボードを引いていなければそれなりの寿命が期待できると踏んでいます。

ASRock N100DC-ITX

023年の12月の暮れにAlderlake NのSoCオンボードマザーのASRock N100DC-ITX (ASRock公式サイト)を買いました。24、25、34号機の更改のためです。予備含め4枚買いました。

買った理由ですが、2019年頃に立てたJasper/Elkhartlake更改という計画を実行に移すためです。計画名と買ってるマザーボードが若干違う気がしますが、前述の通りCeaderView/Braswell機である24、25、34号機を更改(リプレース)するための計画です。

元々は名前の通りの計画で、自宅に跋扈しているCeaderViewやBraswell等の老朽機をJasper lakeかElkhart Lakeで一掃する計画でした。2020年頃には予算・資金も確保し、準備万端となりました。しかし予算は付いたもののパーツ調達フェーズで3年ぐらい計画が止まっていました。計画の要となるコンシューマー向けの Jasperlake や Elkhartlake を搭載したMiniITXマザーボードが一向に出て来ない状態が延々と続いてました。

出ないものは仕方ないのですし、Gemini Lakeはありましたが、Gemini Lake系統は実家で使ってて、できればGemini Lake一色には染めるのは避けたかったので、自宅ではD2550とかN3050という2010年代前半の古い機材で運用を続けていました。D2550の方はShuttleのベアボーン機で予備機を持っていたのですが、2020年に25号機が壊れてしまい、予備機の在庫がなくなったためまさに薄氷を踏むような運用でした。

そんな中、2023年中頃にようやくAlderlake-NでITX SoCが出ました。これがASRockのN100DC-ITXです。そして、更改のために購入したのがこのAlderlake Nのマザーボードです。

マザーボードの要件は下記の通りで、若干妥協はありますが、N100DC-ITXは概ね要件を満たしていため購入することにしました。

  • Mini-ITXであること。
  • ファンレスであること。
  • SATAが2本あること。
  • PCI EXpressスロットがあること。
  • ATX20ピン、または24ピンで給電されること。

要件1: Mini-ITXであること。

更改対象の24号機と25号機はShuttleの超小型ベアボーンどと言うプロプライエタリなプラットフォーム(以下、プロプラPF)でした。プロプラPFのベアボーンは電源とマザーボードと筐体が一式でセットになっています。

このお陰でMiniITXより小型化出来るのですが、調達も一式単位になるので予備機材が高く付きます。しかもマザーボードだけ入れ替えて更改みたいな芸当ができないので、壊れると一式交換となります。一式交換しかできないのでプロプラPFはメーカで一式がディスコンになると立ち行かなくなるデメリットがあります。

と言うか、実際に立ち行かなくなったので、オープンプラットフォーム(以下、オープンPF)であるMiniITXで建造することにしました。Mini-ITXの規格自体は(提唱したメーカは消えそうな勢いですが)、Intel/AMDも支持はしているのでここ10年ぐらいでは消えないかと思います。なので最悪はその辺のIntelなりAMDのデスクトップマザーを入れれば運用できます。

ここまでがプロプラPFからオープンPFに移った理由で、Mini-ITXにしたのは単純に置き場や運用の問題です。更改対象機はどれも専用機で、構成もシンプルで、運用期間中に増設も無ければ、高いエアフローが求められるマシンでもありません。

そして、私の家は狭く、大型マシンがメンテしやすい環境ではありません。そういう状況で大型機を買っても無駄で、邪魔で、メンテナンスがしにくいだけです。そう言う理由でMini-ITXにしました。

要件2: ファンレスであること。

ファンレスが実は超重要でした。

2010年以降の機材で、運用予定寿命が10年未満なら、埃の溜まる期間orファンの寿命<運用寿命です。一方、ファン以外のパーツは概ね、パーツの寿命>運用寿命です。つまり、ファンレスにすればマシンの運用寿命が来るまでほぼメンテフリーになり、PCの物理メンテナンスから解放されるのが大きな理由です。

強制空冷はどうしても埃が入ってきます。そして埃は最も通気しやすい部位の、抵抗の大きいに溜まってやがて詰まり、次に通気しやすい部分の抵抗の大きい部分に溜まってどんどん詰まっていきます。つまり、定期的に清掃が必要になります。吸排気を調整しても、セミファンレスでない限り大体3年ぐらいで詰まってきて内部温度が上がり、騒音レベルも上がってきます。

運用寿命が10年なら3年に1回は運用断を伴う掃除が必要です。私は台数が多いのでメンテそのものが面倒ですし、清掃期間の管理も面倒です。清掃せずに済むならやりたくないです。

そして、電動ファンはPCパーツの中では寿命が短いパーツで、これもまた、正しく動いているかの定期的な確認と、NGの際はサーバを停止して交換が必要になる面倒なパーツです。加えて電動ファンは小型のもの(〜60mm)は同一シリーズでもカタログスペックの時点で大型のもの(120mm〜)より寿命が短く、体感的にも故障しやすい傾向があります。

こんな感じで、24、25、34号機はファンレスにしたので更改後もファンレスにすることにしました。

要件3: SATAが2本あること。

SATAは結構重要で、OSが起動しない状況でデータを引き抜いたり移す際はNVMeよりSATAの方が色々便利なのでSATAにしています。

SATAよりNVMe m.2のが断然高速なんですが、SATA以外の部分が同じなら、その性能差が如実に出るような使い方をしない限り、スペック差ほど使用感に差は無いです。阿部寛のホームページを1Mbpsでも見てめ10Gbpsの回線で見ても1万倍の差を感じないのと同じです。

実際、私のマシンだと32号機のMacや36号機のhpのノートPCのSSDはNVMe/PCIeで、最も使う23号機はSATAなんですが、速度差を実感する用途は殆ど無く、いつの間にかSATAに変わっていてもしばらく気づかないと思います。。

要件4: PCI Express (PCIe)スロットがあること。

PCIeスロットはVPNルータの34号機の更改でNIC増設をするためPCIeスロットは必須です。

まぁ、PCIeスロット無くてもPCIeが生えてるM Key のM.2やE Key M.2のiCNVioからEthernetを生やす怪しい基板はあるにはあります。まぁ実際に買ってみたんですが、怪しいMACで、積んでる蟹チップすら正規品か怪しいぐらいです。

まぁ、怪しい云々の前にPCIeのEthernetカードを買う方が普通に安いですし、iCNVioもE Key M.2用の怪しいEthernetもなんていつまであるかわからないので、普通のPCI Expressスロットにしました。

ちなみにNICは蟹(Realtek)にしました。Realtekは Checksum オフロード関係がダメダメだったりしますが、ethtoolでOFFにしてしまえば終わりですし、初期コストも消費電力も低いです。また、N3050すら持て余しているマシンでやっていたことを、Skylakeクラスの性能が出るという謳い文句のCPU詰んだ専用機にやらせるのでCPU負荷が少々高くても特に気にならないので蟹で妥協です。

というか、対向にある実家の28号機なんてIntelから蟹で置き換えてますしね。

要件5: ATX電源

これは妥協しました。

最後のATX電源だけは待ってても出るアテもなく、妥協しても(4台ぐらいまとめ買いした)picoPSUの出番がなくなるだけで、それ以外はデメリットが無いので妥協としました。

ACアダプタはどうせ買いますし、picoPSUは次の更改で必要になれば使えばいいですからね。

これらを使って更改をしていきます。まぁ書いてる時点ではほぼ終わってるんですけどね。

33号機2期構成 ASRock J4125-ITX @ Morex Cubid 2799

先日、33号機の更改作業を行ってきました。2期構成となりました。作業としては新造時に入れたGemini LakeのマザボであるASUS J4005I-Cを、Gemini Lake Refreshの積んだASRock J4125-ITXへと置き換えました。

33号機はコロナの初期にあたる2020年6月に新造したマシンです。当時はGemini LakeのASRock J4105-ITXが家の中で跋扈していたので、一応製造元分散としてASUS J4005I-Cで自作したものです。

33号機のケースはMorex社のCubid 2977というケースを使っています。Morexのケースはここ10年ぐらいは日本ではまともに取扱が無いようで、2000年ぐらい以降生まれの方には馴染みのないメーカーだと思います。今でこそMiniITXはメジャーな自作プラットフォームですが、2000年代初頭のMiniITXは全然マイナーな規格で、VIA Technologiesというx86互換CPUメーカー(※)の独自規格みたいな時代がありました。

※VIA Technologies自体は2024年現在でも存続してますが、x86互換CPUメーカーとしてのVIAは今の兆芯がそれに該当します。

そんなマイナーな時代のMiniITXのケース事情はMorexのケース以外はほぼ選択肢がありません、みたいな状態で、初期のITXプラットフォームではITXといえばMorexみたいなポジションに近いケースメーカーでした。と言っても、MiniITX自体はMicroATXケースと互換性がありましたし、MiniITXはケースとセットでベアボーンとして売られていたことが多かったような気がするので、当時でもMorexが有名かというと疑問ですが。

しかし、このMorexのケースでよく採用されていた12VからATXを生成する電源基板は、基板サイズとビス位置がACアダプタ用の電源基板のデファンクトスタンダードみたいになってて、SST-ML10の電源基板もこれに準じた大きさやビス位置になっています。(ただ、Morexが主導したのかは存じません)

なお、正しくはMorex Information社で、コネクタハウジングの名門であるMolex社とは別の会社です。

33号機と13号機21号機の上にスタック(平積み)して置いています。下に置いている13/21号機も古いMorex のケースで、これらの上にスタックしたいがためにわざわざ在庫のあるEU圏から輸入してきました。2020年当時でも売っていること自体ある意味奇跡だと思いました。

このCubid 26xx/27xxシリーズ、個人的には好きなんですが、PCのケースとしては前時代的な設計です。フロントパネルは今だにUSB2.0のみで、IEEE1394(FireWire)がフロンパネルにあったり、ライザーは(Expressではない)PCIしか無いなど、20年間から何一つ進化していない感が見て取れます。フロントパネルオーディオにAC97のコネクタが残っているのも時代を感じますね(HD Audioのコネクタもちゃんとあります)。理由がない限り、今時このケースで新造するのはお勧めできません。

電源はACアダプタも付属していて、2000年代によくあった12VのACアダプタ+電源ボード式です。付属の電源は60Wです。ただ、電源基板は瞬間に取り外し、新造時から13号機や21号機と同じMeanwell GST90A19-P1M + Mini-Box picoPSU-120-WI-25の構成にしています。これは2期構成でも続投です。

と、まぁ、こんな感じで自作したまではいいんですが、構成がよく似ている13号機、21号機と比べると消費電力がどうチューニングしても4W程度高い状態が続いていて、正直初期構成で使い続けるのも微妙だなーと思っていたのが更改理由です。

今回置き換えに使用したJ4125というAtomの血を引くGemini Lake RefreshコアのCPUで、J5040の廉価版です。置き換え元のJ4005はJ5005の廉価版ポジションにあたりますが、J4005のJ5005に対する見劣り具合はJ4125のJ5040に対するものよりよりだいぶ大きいのも気になってました。

J4125はJ5040とCPU部分を比べるとコア数やスレッド数、ベースクロックは同じで、Turboboostのシングルコアの吹き上がり方が違う程度でした。が、J4005はコア数まで違います。この差は結構気になるところでした。

実作業は私が度々やってマザボ一式(マザボ+CPU+メモリ一式)を置き換えてそれ以外のパーツは続投のやり方です。このやり方はSSDをそのまま引き継ぐのでOS回りの作業が少なくて楽なんですが、更改した時の感動は薄いですね。ドーパミンが出ません。。

このケース、PCIeにブラケットを付けるとブラケットの先端がマザーボードのオーディオコネクタにつっかえてマザーボードを引き出せないので、地味に面倒です。PCIeは何も実装してません(※)が、40mmファンを無理やり付けてて、エアフロー確保のためにグリルタイプのスカスカのスロットカバーをつけています。ちなみにケース、PCI用のライザーカードは付属しますが、PCIe用は無いのでPCIeカードの実装はあまり現実的ではありません。

ファンは40mmが2つ、60mmが1つついてて、いずれも10mm厚です。すべてアイネックス社のOMEGA TYPHOONシリーズを使ってます。劣化傾向が見られないので続投にしました。Duroベアリングを採用するアイネックスのGlobe fanは60mm以下に限って言うと耐久性と静粛性を高いバランスで備えていると思います。まぁSanyoやNoctuaと比較すると劣るのかも知れませんが、少なくとも同一価格帯のファンの中では頭ひとつ飛び抜けた耐久性があると思います。

まぁ、これはアイネックスでもGlobe FanのCFZ-4010とかCFZ-6010とかに言えることで、同社が出してるCFY-40SAなんかは全然持ちませんでしたね。CFY-40SAは値段の割に2BB軸受ということで、耐久性に期待を込めて13号機に付いてたことがあったんですが、スリーブと見紛うぐらい勢いでそそくさと逝き、私の予備品在庫から消えて行きました。CFY-40SAの方が100円ぐらい安いですが、お値段以上に寿命の差があるので、耐久性が欲しい場合は手を出してはダメです。

電源も前述のとおり続投です。MeanwellのMTBF 38万9000時間は最強です。まぁこれ、25℃雰囲気下でのスペックなので、アレニウス則下だと55℃なら48,000時間程度なんですけどね。まぁ、実家の断熱は無いのと同義で、5℃とかも時も普通にあるので、実質プラマイゼロで普通に20年程度は期待できるのではないかなと思ってます。

SSDはSamsung 840 EVOとTranscendのSSD370です。このTranscend 370はググっても370Sばっかりヒットするんですが、370と370Sとは別物で、370はdevsleep非対応でTBWも370Sと比べると若干少なめです。まぁ、devsleep非対応なこともTBWが若干少なめもS.M.A.R.Tの稼働時間が再起動のたびにリセットされることに比べれば実に些細なことです。Transcendの稼働時間は起動からの時間だ、と思いたいところですが、これ、同じTranscend 370ですらファームが違うと普通に総稼働時間だったりするのでマジで意味不明です。早く置き換えたいです。

J4005I-CもJ4125-ITXもEthernetはRealtekのものなので、デバイスシンボルは/dev/re0から変更がありませんでした。よって、FreeBSD14では何も設定することなくIP/Default Gatewayなどを引き継いて運用を再開することができました。

何年運用するかはわかりませんが、次の更改か、運用終了時に電源を切るまでまで問題なく動いて欲しいものです。