Linuxサーバ用に10GBase NICを調達した

Hackintosh 化した T5810 に 10GBase NIC を載せてちゃんと認識させることができたのは良いのだけど、対向になる機器側の準備ができていなく

使えそうだ、というのはわかったのだけど、現時点では対向側となる 10GBase 対応の機器がないので、実際に通信テストや負荷試験といったことはできてないです。

[From 10GBase対応のNICをT5810に載せてみた(ただしIntel互換品) - Soukaku's HENA-CHOKO Blog]

テストとかできない状態じゃ楽しくないよね、ということで、 10GBase NIC を追加で調達することに…。

ひとくちに、 10GBase NIC と言いましても…

新品、中古取り混ぜて、探せば色々種類があるわけですが、10GBase 対応のスイッチまでは今のところ手が出せないし、そもそもスイッチ使ってまでの 10G ネットワークを組む予定もないので、当面は 10GBase NIC を積んだ機器間を直結することとして、とりあえず NIC とケーブルを何とかすることに。

まず、 NIC 。
これは、ケーブルどうするかにもかかってくるんですが、とにかくあんまりお金かけたくなかったというのもあって、 ebay で見つけた Mellanox MCX311A-XCAT をチョイス。こいつ、 Linux であれば問題なく認識して使えるようだし、 ebay でなら送料込みで $40 台で手に入れられる(けど、届くまでに多少時間はかかる)ので、お試しで使う分には良かろう、ということで。(ちなみに、アマゾンでも 7,000円台からある模様)
Mellanox という会社自体、 NVIDIA に買収されたようで、最新のドライバは NVIDIA のサポートページからダウンロード可能。

ケーブルに関しては、 DAC ケーブルをチョイス。お試しだし、機器間もそれほど離れたところに置くわけでもないので、これも値段優先で。
ファイバーだと割と安いのがあるのだけど、 SFP+ のトランシーバが必要なのでその分高くなっちゃうし、 RJ-45 で 10G 対応しているトランシーバは更にいいお値段なのでね…。

で、届いたわけですよ

注文から 10 日かからずに MCX311A-XCAT が上海から到着〜。 DAC ケーブルの方はイスラエルからの発送らしいので、まだ届いてない。

MovableType 7でutf8mb4対応

昨日、書いたエントリ。
実は、公開するまでに、えらく時間がかかってた。文章書くところは、 MarsEdit でそれなりにサクサク書けてはいたんですが、いざ公開しようと MarsEdit から MobavleType へのエントリーのアップロードを実行すると、エラーが出る。

最初は、 DB ぶっ壊れたかな?と思っていたのだけど、 MarsEdit で採れる Network Log を見てみると、どうもアップロードしようとしているエントリのデータ自体に問題がありそうなログが出てくる。

Network reply received: 2021-05-15 18:40:25 +0000
API Endpoint URL: https://www.downtown.jp/MT6/mt-xmlrpc.cgi
Method name: metaWeblog.newPost
Status code: 200
Succeeded: NO
Networking error: --Fault Error--
Fault code: 0
Fault string: Failed to execute INSERT INTO mt_entry
(entry_allow_comments, entry_allow_pings, entry_atom_id, entry_author_id, entry_authored_on, entry_basename, entry_blog_id, entry_category_id, entry_class, entry_comment_count, entry_convert_breaks, entry_created_by, entry_created_on, entry_excerpt, entry_keywords, entry_modified_by, entry_modified_on, entry_ping_count, entry_pinged_urls, entry_status, entry_tangent_cache, entry_template_id, entry_text, entry_text_more, entry_title, entry_to_ping_urls, entry_unpublished_on, entry_week_number, entry_current_revision)
VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
with allow_comments, allow_pings, atom_id, author_id, authored_on, basename, blog_id, category_id, class, comment_count, convert_breaks, created_by, created_on, excerpt, keywords, modified_by, modified_on, ping_count, pinged_urls, status, tangent_cache, template_id, text, text_more, title, to_ping_urls, unpublished_on, week_number, current_revision: DBD::mysql::st execute failed: Incorrect string value: '\xF0\x9D\x84\x87 #...' for column `movabletype`.`mt_entry`.`entry_text` at row 1 at /var/www/MT6/extlib/Data/ObjectDriver/Driver/DBI.pm line 418.

ログに出ている "Incorrect string value: '\xF0\x9D\x84\x87 #...' for column" あたりのメッセージを手掛かりにして検索をかけてみると、MySQL/MariaDB での文字コードの扱いの問題であるらしい。
でも、エントリの内容見直してもおかしな文字使ってねぇしなぁ、といろいろ試してみたら、どうやら引用しようとしている 2 つの tweet の一方を入れないと問題が出ないことが判明。問題が出る tweet を引用しないって手もあったのだけど、いずれ似たような事態にぶち当たるだろうから、データベース側で対処することにした。

データベースで使う文字コードを変更する

この問題、界隈によっては「寿司ビール問題」として有名な話だったみたいですね。

さて、 MovableType は現在 MariaDB と組み合わせて使っているんですが、 MovableType のデータを格納しているデータベースを初期生成したのはいつだっけな?といういうぐらい前。下手すると MobavleType 5 を初期設定した状態から使い続けているんじゃないかなぁ。
MovableType 7 は、r.4607 以降で utf8mb4 に対応していて、これについては既にバージョンアップ済みだったので、データベース側を以下の順番で対応していけば良い、と。

  1. MySQL/MariaDB の設定で、デフォルトの文字コードを変更
  2. データベースそのものの文字コードを変更
  3. データベース内のテーブルの文字コード変更

まず /etc/mysql/mariadb.conf.d/50-server.cnf/etc/mysql/mariadb.conf.d/50-client.cnf で、それぞれ以下の設定を追記 or 修正して、 mariaDB を再起動。

[mysqld]
character-set-server = utf8mb4
[client]
default-character-set = utf8mb4

続いて MovableType のデータを格納しているデータベースの文字コードを、デフォルトの utf8_general_ci から utf8mb4_general_ci へ切り替え。

この操作は、コマンドラインで。

# mysql -u root -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 9281
Server version: 10.5.9-MariaDB-1 Debian buildd-unstable

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> ALTER DATABASE movabletype CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;
Query OK, 1 row affected (0.000 sec)

続いて、テーブルの方の文字コード設定をカラムも含めて変えていくわけですが、こちらは phpmyadmin を使って、一気に変更。

phpmyadmin でテーブルの照合順序を変更

これで、データベース側の準備も完了。

問題の原因となっていた tweet を入れてエントリを MarsEdit からアップロードしてみたら、成功。
🍣も🍺も問題なく使えるようになったかな?

Tunnel Broker 経由で見れない Web サイトが出てきたので、 Squid で対処してみた

おそらく、ここ 2ヶ月ぐらいのことだったと思うのだけど、 Engadget 日本語版の記事が見れなくなってた。
例えば、下の tweet 中の記事へのリンクをクリックすると

こんな画面に転送されてしまい、記事が読めないという状態。

EngadgetのGDPR警告画面

なんだかんだで、こんなヒントを貰ったので、確認してみたところ…。

さくらの VPS に建ててるサーバは、IPv6 を有効にしているので、こちらを使って curl コマンドでのアクセスを試してみると正しいコンテンツが返ってくる…。
ということで、 我が家のネットワークにおける IPv6 接続に原因があるということが判明…。

自宅内で運用してたSMTPサーバをさくらのVPSに引っ越した

自宅内のネットワーク環境の見直しの一環で、自宅内の配置していた SMTP & IMAP サーバ(セカンダリ DNS も兼務)を VPS に移動することにしたので、備忘録的なエントリーを書いておく。
移動っていっても、物理的には移動させることはできるわけがないので、既存のサーバと同じサービスを動作させたサーバを VPS 上に用意して、各種サービスは新しく用意したサーバの方を利用するという形。

自宅ネットワークの概要

これで、プロバイダと固定 IP アドレス 8 個のオプション付きで契約しているのが、オプションを外す事ができるようになるのですよ。それでも自宅内で動かしているマシンの台数は大きく減らないんですが…。

特定の条件でrspamdを通さないようにする設定をpostfixに施す

内容の怪しいメールは、相変わらず送られてくるわけですが、 rspamd を使っているおかげで 40 〜 50 通/日程度のスパムメールがブロックされているので、目にすることは少ないのですけど、それでもすり抜けてくるものが、ちらほら。

すり抜けてきたもので、明らかに「フィッシングだよな〜」というやつに関しては、フィッシング対策協議会の情報提供窓口に転送をしているわけですが、

フィッシング対策協議会では、フィッシングサイトに関する情報提供の窓口も準備していますので、怪しいメールを受け取ったら情報提供をするのも良いかもしれません。

[From フィッシングサイトへの誘導メールが届いた - Soukaku's HENA-CHOKO Blog]

その転送メールが、今度は rspamd でブロックされてしまって、情報提供できないことが過去に何度も起きてたんですよね。
すり抜けてきたタイミングでは、 rspamd がスパムとして判定するスコアの閾値を超えていなかったのに、フィッシング対策協議会へ転送しようとしたタイミングで閾値を超えるスコアになってしまう、ということが原因であるんですが、これだと情報提供できず都合が悪いということで、なんとかしたいなと思っていたわけです。

GeForce GT635搭載ビデオカード×4で、FAHClientを実行してみた

思い立っちゃったんで、買ってきましたよ。> Geforce GT635 搭載ビデオカード
前のエントリーに書いたとおりで、 2枚めの GT635 なビデオカードを追加したときにチェックしたとおり

でも、エッジフリーな PCI-E × 1 スロットが、まだ 2 本空いてるんで、もしかしたら 4 枚刺しイケたりする?

[From Folding@homeに参加してみた、ので設定とかをもう少し細かく書いておく - Soukaku's HENA-CHOKO Blog]

スロット空いてたので、試してみようと思った次第。

追加で買ってきたGT 635搭載ビデオカード

買ってきたお店は、お約束の秋葉原最終処分場さん。金曜日( 4/3 )の夕方の時点では、まだまだブツはありましたね。

CELSIUS W520 のスロット構成だけど、 PCI Express × 16 が 1 本、 × 4 が 1 本(コネクタ形状は × 16 )、 ×1 が 3 本(エッジフリーコネクタの × 1 が 2 本と × 16 コネクタ)。あと、最近では出番の殆どない PCI スロットが 2 本。

エッジフリーなPCI Express ×1スロット

上の画像でいうと、 中央の青いエッジフリーコネクタの右側が × 16 、 左側が × 16 コネクタの × 1 。 × 16 の更に右側に × 4 が並んでます。
#ホコリ、すげぇな…。今度掃除しよ…。

Folding@homeに参加してみた、ので設定とかをもう少し細かく書いておく

前回のエントリーで端折っていた

自分のところでは、 Debian sid をインストールしたマシン 2 台に FAHClient をインストール。それぞれのマシンに GeForce GT 710 、 GT635 & Quadro 600 で2枚刺しって構成になっています。 Debian には CUDA を利用するためのソフトウェア群もインストール。

[From Folding@homeに参加してみた、ので設定とかイロイロ - Soukaku's HENA-CHOKO Blog]

ハードウェア周りのこととか、 CUDA 周りのこととかを追記しておきますね。

ハードウェア周り

現時点で、自分とこで、 Folding@home に参加させているマシンは、以下の 2 台。

  • 富士通 CELSIUS W520 (以下、 W520 )
    • Xeon E3-1245 v2搭載モデルで、こちらに GeForce GT635 搭載カードを 2 枚刺し。
    • 残念なことに電源 300Wモデル 、さらに PCI-E 補助電源ケーブルも生えてないのもあってハイパワーな GPU は使えないんで、 GT 635 で妥協。
    • でも、エッジフリーな PCI-E × 1 スロットが、まだ 2 本空いてるんで、もしかしたら 4 枚刺しイケたりする?
  • HP Pro 6300 SFF (以下、 Pro 6300 )

メインマシンである Z620 にも FAHClient 入れてはみたんですが、 OpenGL/OpenCL サポートが非推奨という OS 的な制約で RX580 使った解析ができないんで、さっくりとアンインストールしちゃいました。う〜ん、残念。
その代わり、 Z620 には BOINC の方を頑張ってもらうことにする。
# RX570 版例のカードも、手元にあったりするんだけど、なんだかんだと制約があるおかげで使えないだよね…。

Folding@homeに参加してみた、ので設定とかイロイロ

長年参加してた SETI@home が、この3月末をもって休止する事になった

On March 31, the volunteer computing part of SETI@home will stop distributing work and will go into hibernation.

[From SETI@home hibernation]

ってんで、せっかくだし他の分散コンピューティング・プロジェクトでもやってみるか〜、と思っていたところに、タイミングよく Folding@home が新型コロナウイルスの解析に対応したというのをみて、いっちょやってみるかということに。

解析用クライアントである FAHClient の入手方法やインストールの手順については、探せばイロイロ出てくるので、そっち任せるとして、自分のとこで動かす上で、ちょっとハマったポイントなどを、書き残しておく。

さくらのVPS(v5)を使い始めました

ここ数ヶ月、借りてた VPS がオーバーロード気味だったので、同居させてた MariaDB を別の VPS 借りてそっちに動かしたりして、と対策はしていたのだけど、なかなか負荷が減ることがなく、「もうちょっと、メモリ割当があって、SSD も容量あって、お安めのプランが出てくれたらなぁ…」と思っていたところに、11 月の頭に流れた、この tweet 。

早速チェックしてみたら、ちょうど「あったらいいな」と思っていたプランがあるじゃないですか!さらにストレージ変更オプション使って SSD の容量、倍!!
さくらのVPS 980(その後、さくらのVPS 512 に改称された)から使い続けていたのと、MariaDB 専用にさくらのVPS 1G に追加ストレージも使っていたのが、「 これなら 1 台に纏められる上に、月々の負担も軽くできる」って思った瞬間に申し込みしてました。

で、いつもどおりに Debian を入れ直して buster から sid にアップデート。現行で使っていた VPS から設定やらユーザデータやら DB やらを移行して、DNS の設定も切り替えて、さっくりとサーバの切り替えも完了。
ほんとは、お試し期間の 2 週間を目一杯使ってから切り替えようと思ってたのだけど、予想よりもデータとかの移行がすんなりと終わったし、思っていた通りのパフォーマンスが出ているので、早々に切り替えちゃうのが吉だな、ということで契約から 3 日ほどで完全移行してしまった次第。

メッシュWi-Fi/AiMesh対応ルーター ASUS RT-AC68UとLyra miniを試す(その3)

Lyra mini に関するエントリーの第三弾。

実際に主となる方を書斎代わりの部屋に、従となるほうをキッチンに置いて使ってみているわけですが、 iPhone つないで使っている限りでは、家の中どこにいてもちゃんと繋がってくれるようになったな、というぐらいの感想しかない、というのが正直なところ。
実際、どのぐらいのパフォーマンスが出るのかは、ちゃんと測定してみたいと思います。

[From メッシュWi-Fi/AiMesh対応ルーター ASUS RT-AC68UとLyra miniを試す(その2) - Soukaku's HENA-CHOKO Blog]

前回の予告とおり、トラフィック測定してみましたので、その結果など。

測定の方法と機材について

さて、どうやってトラフィック測定しようか、と考えたときに「サイズの大きなファイルのダウンロードでいいかな?」と思いつついろいろ調べてみたところ、「Linux( Debian )動かしているノート PC もサーバもあるんだし、 iperf 使うのがいいじゃね?」ということで、iperf3 を使うことに。

iPerf3 is a tool for active measurements of the maximum achievable bandwidth on IP networks. It supports tuning of various parameters related to timing, buffers and protocols (TCP, UDP, SCTP with IPv4 and IPv6).

[From iPerf - The TCP, UDP and SCTP network bandwidth measurement tool]

Debian であれば、root 権限で

# apt install iperf3

を実行すれば、インストール完了。
測定も、サーバ側で

$ iperf3 -s

クライアント側で

$ iperf3 -c サーバのIP

と実行すれば、OK。この場合は、クライアント→サーバの測定になりますが、 -R オプションを付けると サーバ→クライアントの測定ができるので(実際の測定時には、少しオプション付きで実行してますが。)