カテゴリー: 備忘録

CRYORIG Frostbitを導入した

kifuyu

どことなくグランド鎌クロスを彷彿とさせるそれは、CPUではなくM.2 SSD向けパッシブタイプクーラです。

 

参照先　http://www.scythe-sub.sakura.ne.jp/cooler/grand-kamacross.html

 

M.2 SSD向けのクーラの大半はヒートシンク１枚であり、取付箇所は空気の流れが悪そうなマザーボード表面であることが多いです。中にはSSD本体を立てるためのブラケットや機構がある仕様のものもあります。

今回のこれ（Frotsbitのクーラ）は立てるタイプであり、放熱フィンはヒートパイプの先に取り付いているタイプです。ファンレスですが、CPUやGPUのファンからの空気を取り込みやすいいので、直付けよりかは熱を逃がせる仕様です。
M.2タイプのSSDは熱を持つというイメージがあるので、せっかくならこれにしようとAmazonでポチりました。

冒頭写真からパッケージを開けたところ、入れ子構造になっており、正面にヒートシンクと金具が見えてきます。

 


付属品はグリスや熱伝導シート、取り付けネジでした。などが現れました。グリスはヒートパイプとSSDの間に塗るためのもので、中華製の怪しいやつではなくそこそこ使えるタイプでした。（NoctuaのCPUクーラに付属していたやつです）
…グリスはお気に入りがあるのでそれを使います。

気になるヒートパイプの外形はだいたいΦ5mmです。（肉厚0.5mmくらい？思っていたよりも小さい印象。）
ほんとうにこれ冷えるんかな…(・∀・)

肝心のSSD実装に移りますが、ここにきてミニトラブル。SSDの裏面に熱伝導シートを貼り付けても、SSD固定用のフレームに接触しない＝熱がフレームに逃げない…。あるいは内部に空気の流れができるからそれを見越しての設計？ではなぜ熱伝導シートが2枚あるの…？予備？
このフレームとSSDのコントローラの隙間が1mmなので、いい感じの金属板を取り付けたいところ。

ぽちぽちとAmazonで調べてるといい感じのプレートを発見。2枚で1000円弱だった。早速購入して取り付けてみることにした。

幅・長さ・厚みジャストフィットでした。まさかこれ使う前提で設計されてる？？これに熱伝導シートを貼り付けて実装。

後はマザーボード本体に取り付けて完成。あまりにもごちゃごちゃしてきたので、エアーフロー改善のため、後日ファンを追加しました。

温度は常用30~40℃くらいで安定。（なお、上記写真Frostbitの隣にあるものは中華製SSDヒートシンク。適当に用意したファンで強制的に冷却している）
フィン面積が大きいため、エアーフローをよくできると一層冷えてくれる感じ。ビジュアル的にもかっこいいのでこれはあり。

 

 

 

WAN/LANのインバウンドが恐ろしく低下した話

kifuyu

自宅サーバはAsus H370 F gamingにwindows server 2019をインストールしています。最近、WAN側のインバウンド経路で通信速度が7~8Mbps(平時500mbpsを平気で出す）程度に留まってしまう現象に陥りました。

思い浮かぶ原因はルータやL2スイッチ、LANケーブルやNICの物理的故障、設定的なところ、VPNやプロキシを挟んでしまうなど挙げられます。しかし、今回どれを試しても状況は変わりません。

しまいにはWAN側だけでなく、LAN側 のインバウンドも超絶速度低下してしまいました。
現像PCから写真を１枚送ったらエクスプローラがフリーズするほどです…

 

トラブルシューティングを進めるにつれて、NICに原因があることはわかりました。
ただNIC自体の物理故障に直面したことは経験になく、もしも修理になるのであれば、１年のメーカー保証が切れてしまう前につくもへ駆け込む必要がありました。（昨年7/9購入）
引っ越し以来触っていないレシート箱をひっくり返し…

ところが物理故障の確信を持つためLinuxから確認してみると、問題なく速度がでます。
そこでようやくドライバが悪さしていることに気づきました(´・ω・`)

そもそもこのマザーボード。windows serverに対応していないのです（添付ドライバCD的な意味で）
なので組立時はいろいろな所からドライバをかき集めたのでした。
特にLANのドライバはwindows server の場合、少しコツが必要で「windoows server lan 無理やり」なんてやや卑猥なワードで調べると似たような事例がぽんぽん出てきます。
私の場合はこれすら面倒で、ドライバインストール時に汎用ドライバ一覧から近そうな名前のデバイスをインストールしたのでした…（Intel I219-Vに対してI219-LMをねじ込む）

 

今回もドライバを適当に当て直してみたところ、元通りの速度が出てくれたのでした。。。
というわけで、WANやLANの速度が恐ろしく低下してしまった場合は、ドライバの再インストールをしてみる必要ありますね。
結局正規ドライバいれずにいるけど、とりあえず動いてくれてるからいっかー、という状況(´ε｀；)

i9 9900kを殻割りした

kifuyu

爆熱で有名なCore i9 9900kを殻割りして直冷化した話。

道具はROCKIT COOLの殻割り機材。それとダイ直冷のために必要なCPUフレーム。当初は銅製IHSへの改装を考えてましたが、フレームを手に入れたので結局使いませんでした。


購入先：https://rockitcool.thebase.in/items/14875553

殻割り機は3Dプリンタで出力されたものらしく、出力精度はよくわかりませんが、重量と剛性感があるためIHSを外すには十分な代物でした。

CPUを挟み込んでネジを回すとずるずるっとIHSが剥がれます。
あとは液体金属を表面に塗ってしばらく放置。液体金属がダイ表面に浸透することで、カッターの刃を使わずとも綿棒でソルダリングを除去することができます。

写真見るとわかりますが、作業時はたまにワークエリア外に綿棒が出てしまっています。念のため、養生しておくといいと思います。
あとは研磨剤で表面を磨き、いい感じにつるつるなったら完成です。

CPUソケット部の押さえを直冷用フレームに換装して作業完了です。

サーバ証明自動更新のエラー修正ほか

kifuyu

・エラー修正
サーバ証明の更新時にエラーメールが届く。
エラーは以下の通り

Attempting to renew cert (email.domain) from /etc/letsencrypt/renewal/email.domain.conf produced an unexpected error:
Problem binding to port 443: Could not bind to IPv4 or IPv6.. Skipping.
All renewal attempts failed. The following certs could not be renewed:
  /etc/letsencrypt/live/email.domain/fullchain.pem (failure)
1 renew failure(s), 0 parse failure(s)
完了しました。

letsencrypt導入時の設定が問題だった。certbot-auto renewal実行時にnginxが443ポートを使っているためエラーが生じていた。
認証方式をstandaloneからwebrootへ設定変更。/etc/letsencrypt/renewal/email.domain.confに以下を記述

#authenticator = standalone
authenticator = webroot
[[webroot_map]]
mail.domain = /usr/share/nginx/html

 

・本サイトのSSL化
諸事情で本サイトは SSL化せずにいた。wordpressのプラグイン修正で問題解決したためSSL化した。
調べればわかるが証明書発行は以下のコマンドでできる。

/usr/local/certbot/certbot-auto certonly --webroot -w /usr/share/nginx/html -d domain.name

リダイレクトの設定などはtsuchikazuさんという方のブログを参照

証明書を nginx へ設定

nginxの設定を変更してSSLを有効にしましょう。設定ファイルはこんな感じになります。

# httpはhttpsへリダイレクト
server {
  listen 80;
  server_name tsuchikazu.net;
  rewrite ^ https://$server_name$request_uri? permanent;
}
server {
    listen 443 ssl;

    server_name tsuchikazu.net;

    ssl_certificate /etc/letsencrypt/live/tsuchikazu.net/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/tsuchikazu.net/privkey.pem;
    ssl_session_timeout 1d;
    ssl_session_cache shared:SSL:50m;
    ssl_session_tickets on;
……

参照 Let’s Encryptの証明書をnginxに設定してhttps化した | tsuchikazu blog

nginxでBasic認証かけると404になる

kifuyu

kifuyu.netに非公開のページを作りたくてBasic認証を導入しました。
NginxでBasic認証を行うためにはApacheでいう.htaccessのようなファイルに書き足す必要があります。
今回はBasic認証導入後に404が連発してしまったのでその対処のメモ書きです。

▶任意のディレクトリにBasic認証をかける
▶locationの記述位置を誤ると404

・パッケージの導入

$ sudo yum install -y httpd-tools
$ sudo htpasswd -c /etc/nginx/conf.d/.htpasswd <userName>

ここまでで/etc/nginx/conf.d/.htpasswdに <userName>のパスワードが生成されてます。
htpasswdのオプションを-cから-mにするとMD5でハッシュされます。気になる人は後者の方がいいかもしれませｎ。
ところでNginxでは設定をファイルごとにincludeできるので、私はconf.dというディレクトリを作ってconfファイルを分割して格納しています。

・Nginxのconfファイルの設定を行う

$ vi /etc/nginx/conf.d/<httpの設定が書かれたconfファイル>.conf

ある任意のディレクトリ “nyan”にBasic認証をかけます

server {
location / { ....
    location /nyan/ {
            auth_basic "Auth";
            auth_basic_user_file /etc/nginx/conf.d/.htpasswd;
    } #location /naynの終
} #location / の終

注意しないといけないのはディレクトリ”nyan”のlocation設定がRoot以下のlocation設定内に書かれてないといけないことです。
リファレンス読まずlocationごとに中括弧をつけていたので404連発でした。

しっかし平文でパスワードやりとりするのは…