本当にどうでもいいメモなどをたまに書く程度。

2020年ブラックフライデー VPS

日付:
タグ:

あとで追記する。自分で契約したものばかり。

まだ契約できそうなもの

  • Ethernet Servers
    • https://www.ethernetservers.com/clients/store/ssd-linux-vps-special-offers
    • クーポンコード BLACKFRIDAY-VPS で 25% off。recurring なので翌年以降も 25% off。↓の金額はクーポン適用後。
    • 場所 Los Angeles / New Jersey
    • OpenVZ
    • 30 GB SSD / 1 TB BW / 1 GB RAM / 1 IP / 1 CPU
      • 9 USD / year
    • 60 GB SSD / 2 TB BW / 2 GB RAM / 1 IP / 1 CPU
      • 15 USD / year
    • 70 GB SSD / 3 TB BW / 2.5 GB RAM / 1 IP / 1 CPU
      • 18.75 USD / year
    • $15 の LA を契約したが快適。私が LA を契約した時は IPv4 アドレスが2個ついていたが、29日夜現在は1個になっている。クーポンコードはまだ有効なようだ。
    • 29日夜に $9 の NJ も契約した。
  • Gullo’s Hosting
    • https://hosting.gullo.me/black-friday/
    • RAM 512MB のシンガポール VPS が 8 USD / year。UK LittleVZ とあるが、オーダー画面でイギリスかシンガポールか選べる。
    • 上記ページからのオーダーリンクでクーポンコードはあらかじめ入力されているのだが、適用されていない場合がある。Use a coupon code をクリックするとコードが入力されているので Redeem する。ここでカートが空になる場合があり、その場合はもう一度上記ページからリンクを開く。
    • サポートなし、返金なしが強調されているので不安に思う人もいるだろうが、この業者 (といってもたぶん個人) は LET や LES などのフォーラムでアクティブに活動しているので、サーバーダウン等は速やかに解決されると思われる。私は3年半ほど彼のサービスを利用していて、これまでトラブルはない。
    • シンガポールは日本から近いだけあって低レイテンシで、操作性は素晴らしい。
  • HostHatch
    • https://www.lowendtalk.com/discussion/168301
    • 15 USD / year
    • KVM
    • 1 CPU (12.5% dedicated, burstable up to 100%)
    • RAM 2GB
    • NVMe SSD 20GB
    • BW 2TB
    • 場所 アムステルダム / ストックホルム / ロサンゼルス / チューリッヒ / オスロ / ウィーン / ワルシャワ / ロンドン / シカゴ / ニューヨーク / シドニー / 香港 / マドリード / ミラノ
    • 場所の選択肢がとても多い。香港・マドリード・ミラノは即開通ではなく12月中開通のプレオーダー。
    • 私はマドリードをプレオーダーした。
    • 契約方法の早い話 : 業者のサイトでユーザー登録してデポジットを払い、サポートチケットを開く。

それ以外

  • ViridWeb
    • 6 USD / year
    • KVM
    • 1 vCPU
    • RAM 1GB
    • SSD 25GB
    • BW 1TB
    • 場所 オランダ
    • IP アドレスは IPv4 と IPv6 が1個ずつ
    • LET のフラッシュセールで契約。ところがこの業者、クーポンコードの有効数設定を盛大に間違えて大量の注文を受け入れてしまい、返金処理をしているようだ。私のは開通して現在使えているが、後からキャンセル返金となるかも知れない。
  • RackNerd
    • 8.57 USD / year
      • KVM
      • 1 vCPU
      • RAM 768MB
      • SSD 20GB
      • BW 3TB
      • 場所 シアトル
    • 8.79 USD / year
      • KVM
      • 1 vCPU
      • RAM 1.2GB
      • SSD 16GB
      • BW 4TB
      • 場所 ロサンゼルス
    • LET のフラッシュセールで2台契約。ここは PayPal 支払いが FastSpring 経由で、FastSpring が消費税を上乗せしてくる (↑の金額は上乗せ済み)。が、それでもかなりのお買い得。
  • HostSolutions.ro
    • 8.88 EUR / year
    • 1 vCPU
    • RAM 2GB
    • SSD 50GB
    • BW 10TB
    • 場所 ブカレスト
    • ルーマニアの業者。LET のフラッシュセールで契約。5日以内に開通とのことで、まだ開通していない。

ベンチマーク

スクリプトはこれ

Ethernet Servers ロサンゼルス

Processor:    Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
CPU cores:    1
Frequency:    2399.926 MHz
RAM:          2.0Gi
Swap:         256Mi
Kernel:       Linux 4.19.0 x86_64

Disks:
ploop*****     60G  HDD

CPU: SHA256-hashing 500 MB
    5.598 seconds
CPU: bzip2-compressing 500 MB
    7.690 seconds
CPU: AES-encrypting 500 MB
    2.319 seconds

ioping: seek rate
    min/avg/max/mdev = 135.2 us / 366.8 us / 130.2 ms / 1.73 ms
ioping: sequential read speed
    generated 6.65 k requests in 5.00 s, 1.62 GiB, 1.33 k iops, 332.3 MiB/s

dd: sequential write speed
    1st run:    467.30 MiB/s
    2nd run:    487.33 MiB/s
    3rd run:    445.37 MiB/s
    average:    466.66 MiB/s

IPv4 speedtests
    your IPv4:    ***.***.***.***

    Cachefly CDN:         63.82 MiB/s
    Leaseweb (NL):        5.74 MiB/s
    Softlayer DAL (US):   20.06 MiB/s
    Online.net (FR):      4.88 MiB/s
    OVH BHS (CA):         10.57 MiB/s

IPv6 speedtests
    your IPv6:    ****:****:****:****

    Leaseweb (NL):        2.48 MiB/s
    Softlayer DAL (US):   6.29 MiB/s
    Online.net (FR):      1.68 MiB/s
    OVH BHS (CA):         6.92 MiB/s

SSD は高速だが、ネットワークは微妙かな?

Ethernet Servers ニュージャージー

OS を入れ直したら起動しなくなったのだが、サポートチケットを開いたら17分で解決の返事が来た。

Processor:    Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz
CPU cores:    1
Frequency:    2399.926 MHz
RAM:          1.0Gi
Swap:         256Mi
Kernel:       Linux 4.19.0 x86_64

Disks:
ploop*****     30G  HDD

CPU: SHA256-hashing 500 MB
    5.447 seconds
CPU: bzip2-compressing 500 MB
    7.106 seconds
CPU: AES-encrypting 500 MB
    2.241 seconds

ioping: seek rate
    min/avg/max/mdev = 49.9 us / 230.4 us / 12.8 ms / 414.2 us
ioping: sequential read speed
    generated 6.18 k requests in 5.00 s, 1.51 GiB, 1.24 k iops, 309.1 MiB/s

dd: sequential write speed
    1st run:    577.93 MiB/s
    2nd run:    527.38 MiB/s
    3rd run:    653.27 MiB/s
    average:    586.19 MiB/s

IPv4 speedtests
    your IPv4:    ***.***.***.***

    Cachefly CDN:         86.58 MiB/s
    Leaseweb (NL):        9.12 MiB/s
    Softlayer DAL (US):   34.57 MiB/s
    Online.net (FR):      4.69 MiB/s
    OVH BHS (CA):         43.86 MiB/s

IPv6 speedtests
    your IPv6:    ****:****:****:****

    Leaseweb (NL):        13.79 MiB/s
    Softlayer DAL (US):   30.17 MiB/s
    Online.net (FR):      10.69 MiB/s
    OVH BHS (CA):         48.66 MiB/s

SSD は速い。

アメリカ東海岸なのでヨーロッパやカナダからの転送がロサンゼルスより速いのは理解できるが、ダラスも速い。

日本からの経路はニューヨーク (NYC) 経由。データセンターは Internap (INAP) のニュージャージーということなので、マンハッタンからハドソン川を渡って西に数 km の Secaucus らしい。まさにニューヨーク都市圏の VPS だと言える。

安 VPS 界隈でよく業者が利用する ColoCrossing がニューヨーク州バッファローにデータセンターを構えているため、NY と書いてあってもバッファローという安 VPS がかなり多いのだが、これは州境こそまたぐもののよっぽど NYC に近い。

Gullo’s Hosting シンガポール

Processor:    Intel(R) Xeon(R) CPU E3-1270 v6 @ 3.80GHz
CPU cores:    1
Frequency:    889.465 MHz
RAM:          512Mi
Swap:         -
Kernel:       Linux 4.19.0 x86_64

Disks:
ploop*****     10G  HDD

CPU: SHA256-hashing 500 MB
    6.025 seconds
CPU: bzip2-compressing 500 MB
    10.402 seconds
CPU: AES-encrypting 500 MB
    2.406 seconds

ioping: seek rate
    min/avg/max/mdev = 140.4 us / 291.9 us / 73.7 ms / 1.00 ms
ioping: sequential read speed
    generated 1.04 k requests in 5.00 s, 259.8 MiB, 207 iops, 51.9 MiB/s

dd: sequential write speed
    1st run:    38.05 MiB/s
    2nd run:    38.24 MiB/s
    3rd run:    38.34 MiB/s
    average:    38.21 MiB/s

IPv4 speedtests
    your IPv4:    ***.***.***.***

    Cachefly CDN:         110.25 MiB/s
    Leaseweb (NL):        13.51 MiB/s
    Softlayer DAL (US):   3.37 MiB/s
    Online.net (FR):      15.65 MiB/s
    OVH BHS (CA):         7.29 MiB/s

IPv6 speedtests
    your IPv6:    ****:****:****:****

    Leaseweb (NL):        15.24 MiB/s
    Softlayer DAL (US):   2.86 MiB/s
    Online.net (FR):      14.89 MiB/s
    OVH BHS (CA):         5.19 MiB/s

見た目上 CPU はかなり絞ってあるようだ (889.465 MHz) が、ベンチマーク所要時間はそう悪くない。ストレージは SSD ではなく HDD と思われる。

ファイルサーバーの HDD 交換

日付:
タグ:

2014年に Q1900-ITX でファイルサーバーをリプレイスしたのだが、常時稼働5年半を超え、RAID1 を構成する HDD 2台のうち片方でバッドセクターが生じた。
ちょうど特別定額給付金が入ったので、HDD を交換した。


これまで HDD は基本的に Western Digital を選んでいて、メイン PC の SSD すら WD 製品を使うほど WD 信者と言っても良さそうな私なわけだが……よりによって NAS 向けである WD Red HDD で SMR を採用という大ポカをやらかしたので私の忠誠心は急落。

10TB あたりで考えていたのだが、ちょうど最新モデルから WD Red の 10TB はヘリウム充填ではなくなり、結構うるさいというレビューが散見された。
12TB を見てみたら、東芝が一番安くてヘリウム充填なのでこれに決定 (MN07ACA12T)。

この東芝 12TB HDD、普段は静かなのだが、書き込み時は昔の HDD のようなゴリゴリ音なので気になる人は多いかも知れない。


ついでにシステムとデータの分離を図る。

手元で余っていた Crucial の 64GB SSD (RealSSD C300 CTFDDAC064MAG) にシステムを入れ、ファイルサーバーとして使うデータ部分を切り離すことで、今後の HDD 交換時もデータのみコピーすれば済むようにした。

どうせログぐらいしか書き込まれないのだから SSD でもいけるだろう……という考え。

Wyse 3030 N03D シンクライアント (3290)

日付:

ヤフオクに2台で1000円という超特価で大量出品されていたもの。
メモリなし、ストレージなし、AC アダプターなしでの出品であるせいか、特価なのに入札者が少なかった。まだ大量に出ている。

  • Wyse 3030 N03D
  • CPU : Intel Celeron N2807 1.6GHz (2コア)
  • メモリ : DDR3L SO-DIMM 1スロット (元は 4GB らしい)
  • ストレージ : mSATA (half) (元は 16GB らしい)

AC アダプターは 12V 5.5/2.5mm。電流容量は 1A で足りるはずだが、2A ぐらいが安心かな。手元に転がってるという人も多そうだ。
我が家には (他機付属のものを除いて) 4台あった。
持っていなくても、AliExpress でも200円以下で買える (到着まで日数はかかるが)。

メモリは DDR3L SO-DIMM で上限は 4GB (Celeron N2807 の上限)。出荷時にすでに最大量を搭載しているわけだ。
私は中古でメモリなしだったので、とりあえず 2GB をつけた。

ストレージは mSATA (half) SSD。miniPCIe ハーフサイズと同じ縦横の mSATA SSD で、普通の (フルサイズ) mSATA は長さ方向でヒートシンクに干渉するため装着できない。
これの調達が本機活用にあたって最大のネックになると思われる。
AliExpress の最安値は Goldendisk の 8GB (1700円強) だが、あと400円弱出せば KingSpec の 64GB (2100円弱) になるので実に悩ましい。
とりあえず注文して現在到着待ち。

ストレージ到着待ちなので Memtest86+ ぐらいしかしていないが、動作中で 6~7W。AC アダプターをあやしい中華 AC アダプターに交換すると動作中で最大 8W (ワットチェッカー実測)。1W の差は AC アダプターの発熱と思われる。中華の方が熱い。


内部へのアクセスは、背面のネジ3個をはずして、製品情報タグが入っていない側の側面パネルを開ける。
前面側がヒンジで背面側が開くようなイメージで、背面側を手前にして本を開くように左右に開くと言えばいいか。結構固いので不安になるかも知れないが、思い切って開ける。勢いがつきすぎるとスピーカーのケーブルが抜けるが、挿し直せばいい。

閉める時はまず前面側を深めに入れて、背面側を押し込んでいく。
こうしないと側面パネルの前面側が浮く。
実際に私が購入したものは、2台とも側面パネルの前面側が浮いた状態で到着した。

iCop EBOX-3310MX-AP

日付:

EBOX-3310A-JSK に続いての Vortex86 シリーズ搭載機。

  • iCop EBOX-3310MX-AP
  • CPU : DM&P Vortex86MX+ 933MHz
  • メモリ : DDR2 1GB オンボード
  • ストレージ : なし

EBOX-3310MX シリーズはバリエーション豊富だが、リセットボタンがないものを「『Auto Power On』機能があるもの」と位置づけているようだ。
リセットボタンがあるものは、電源スイッチを ON にしてもリセットボタンを押すまでは起動しない。


Vortex86MX+ は Vortex86DX 同様 586 互換の CPU で、686 互換ではない。
そのため Debian は jessie までの対応となる。

Vortex86DX3 は 686 互換のデュアルコアらしいので、いつか入手してみたいものだ。


ストレージは含まれないが、SD カードスロットがあるのと、2.5インチ SATA HDD/SSD を内蔵できる (どちらも IDE HDD/SSD として認識される)。
9.5mm 厚の SSD だと内部の配線がかなり圧迫されるが、なんとか収まった。実際には 7mm 厚の方が良いだろう。

また、USB ポートは外部の3個 (前面2個、背面1個) だけでなく、内部にも1個あるので、内部のポートに USB メモリを挿してもいい。


Debian jessie でベンチマークをとってみた。VPS でよく使っている nench.sh

CPU: SHA256-hashing 500 MB
    41.209 seconds
CPU: bzip2-compressing 500 MB
    130.406 seconds
CPU: AES-encrypting 500 MB
    92.153 seconds

やはり遅いが…… Vortex86DX 1GHz と比べると動作クロックがやや低い 933MHz であるにもかかわらず、所要時間は下がっている。
Vortex86 シリーズも進化しているようだ。


Linux ではカーネル fb と相性が良くないようで、vga=normal をつけないと画面が右にずれる。

Vortex86DX はグラフィック機能がなく、EBOX-3310A シリーズは Volari Z9s を搭載していた。
Vortex86MX+ はグラフィック機能を内蔵しているため、違いが出ているものと思われる。

FreeBSD では問題なく表示できるし、X も動作する。
しかしウィンドウの上でマウスカーソルをぐりぐり動かすだけで Xorg が CPU を 80% も食うので、GUI 利用は現実的ではなさそうだ。

Nexterm RT-500 シンクライアント

日付:

Debian stretch から、686 クラス以上の CPU が要求されるようになっている
DM&P Vortex86DX などはまさにこれに引っかかって Debian jessie までしか動かないのだが、サポート外れリストには MediaGX が載っているものの、Geode の名前はない。

ならば Geode では stretch どころか buster だって動くのではないか?
というわけで検証すべく Nexterm RT-500 なるシンクライアントを入手してみた。
(2016年あたりに秋葉原で500円で投げ売りされていたらしい)

  • Nexterm RT-500
  • CPU : AMD Geode LX 800 (500 MHz)
  • メモリ : 512MB
  • ストレージ : CompactFlash スロット

さて Debian buster の動作だが、ぶっちゃけ USB ブートの癖 (後述) さえなんとかできればすんなりインストーラーが動くので、全く問題ない。
AMD Geode は stretch の CPU サポート外れリストにない。実際にその通り、buster も動作することが確認できた。

要するに CMOV 命令の実装こそが問題で、物理アドレス拡張 (PAE) の問題ではないようだ。Geode LX 800 には CMOV があって PAE はない。
実際 stretch 以降ではカーネルのメタパッケージ linux-image-686 があって、これは linux-image-686-pae と違って non-PAE で動く。

Vortex86DX には CMOV がない (そもそも i586 互換で、i686 互換をうたっていない) ので、stretch 以降は動作しない。


USB ブートには癖があって、USB メモリを挿入したまま電源投入では USB メモリを認識しない (複数の USB メモリ、複数の USB CD-ROM で同様だった)。
電源が入っている状態で BIOS あたりに行き、USB メモリを挿入して Ctrl-Alt-Del という手順でいけた。

(2020/03/20 訂正)
USB 機器との相性があるようだ。認識するものは挿入のまま電源投入でも認識するし、不安定なものは不安定。


消費電力が小さい。ワットチェッカーの表示で、アイドル 6W、CPU 負荷状態 8W。
(ただしシャットダウンしても待機電力が 3W なのはいただけない)


VPS でよく使っているベンチマーク nench によると、CPU ベンチマークはこんな感じ。

CPU: SHA256-hashing 500 MB
    77.901 seconds
CPU: bzip2-compressing 500 MB
    143.812 seconds
CPU: AES-encrypting 500 MB
    136.239 seconds

かなりの低性能。しかし消費電力と発売時期を考えると、かなり善戦していると言えるのではないか。なんといっても 500MHz だし、CPU に負荷をかけていても 8W 止まりだ。


「Nexterm RT-500」でググると色々間違った情報が書かれているので、実際に確認したことを書く。

  • BIOS に入れない。
    → 電源投入して F1 叩けば入れる。なお F1 が押されたままという認識になる場合があり、その際は USB キーボードを抜いて同じポートに挿し直す。
  • 起動順序が選べない。
    → BIOS で設定できる。
  • CompactFlash が入っていると USB ブートできない。
    → BIOS で起動順序を設定できる。
  • カバーを開けても CompactFlash の挿抜以外、内部にアクセスできない。
    → 背面の VGA とシリアルポートの左右にある六角が内蓋を挟むように固定しているので、六角をゆるめる。

PDNS Manager の API でダイナミック DNS

日付:

前回の記事で PowerDNS のレコードを編集するのに PDNS Manager を導入した。 PDNS Manager は API も備えており API を叩くことでレコードの変更が可能だ。
つまり、ダイナミック DNS を運用可能だ。


詳細はドキュメントの通りだが、要するに

  • パスワードを使った HTTP GET メソッド
  • 公開鍵認証を使った HTTP POST メソッド

と、2種類のやり方がある。

以下、次の想定で書いていく。

  • PowerDNS はマスター master.example.com、スレーブ slave.example.com で動作している。
  • PDNS Manager は https://pdns.example.com/ で動作している。
  • home.example.com をダイナミック DNS として使う。
  • home.exmaple.com のレコード ID は11。

共通部分

  1. PDNS Manager にログイン。
  2. example.com ドメインを選択。
  3. 下部 Add で home.example.com を作る。TTL は標準で86400秒 (24時間) になっているので、600秒程度に短くしておく。
  4. home.example.com のレコード ID を記憶しつつ (本記事中では前述通り11と想定)、右側に3個並んだアイコンの右側、鍵アイコンをクリック。

GET メソッド

  1. Add credential | Key | Password の Password をクリック、右側に入力欄が出るので入力して Save。
  2. https://pdns.example.com/api/v1/remote/ip にアクセスすると自分の IP アドレスが (JSON で) 表示される。
  3. https://pdns.example.com/api/v1/remote/updatepw?record=11&password=(パスワード)&content=(IP アドレス) にアクセスすると home.example.com のレコードが更新される。

cron に登録するシェルスクリプトはこんなところかな。

wget を使う場合:

#!/bin/sh
ARECORD=`dig @master.example.com home.example.com a +short`
CURRENT=`wget -q -O - https://pdns.example.com/api/v1/remote/ip | jq -r .ip`
if [ $ARECORD = $CURRENT ]; then
	echo "The A record does not need to be updated."
else
	echo "Updating the A record..."
	wget -q -O - "https://pdns.example.com/api/v1/remote/updatepw?record=11&password=パスワード&content=${CURRENT}"
fi

curl を使う場合:

#!/bin/sh
ARECORD=`dig @master.example.com home.example.com a +short`
CURRENT=`curl -s https://pdns.example.com/api/v1/remote/ip | jq -r .ip`
if [ $ARECORD = $CURRENT ]; then
	echo "The A record does not need to be updated."
else
	echo "Updating the A record..."
	curl -s "https://pdns.example.com/api/v1/remote/updatepw?record=11&password=パスワード&content=${CURRENT}"
fi

jq 入れたくない人は CURRENT= の行を以下のように変更。
API は {“ip”:“203.0.113.9”} といった形式でデータを返すので、awk でセパレーターをダブルクォーテーションにすれば4番目のフィールドが IP アドレス。

CURRENT=`wget -q -O - https://pdns.example.com/api/v1/remote/ip | awk -F \" '{print $4}'`
CURRENT=`curl -s https://pdns.example.com/api/v1/remote/ip | awk -F \" '{print $4}'`

あるいは以下のような、単純に IP アドレスのみを返してくれるところを wget なり curl なりする。

ただ、せっかく API で更新するんだから、同じ API で IP アドレスを取得した方が正しいとは思う。


POST メソッド

PDNS Manager 作者の GitHub にある PDNS Manager Client を使うことになる。
作者の説明では git clone しろとあるが、pdns-client と pdns-keygen という2個の bash スクリプトを配置するだけなので手動でやってもいいと思う。
鍵ファイルなどは内蔵しないので、/usr/local/bin/ に入れてパーミッション 755 で問題ない。

  1. pdns-keygen を実行。pdns.private.pem、pdns.public.pem が生成される。
  2. Add credential | Key | Password の Key をクリック、右側に入力欄が出るので pdns.public.pem の内容を貼り付けて Save。
  3. pdns-client -s https://pdns.example.com/ -i 11 -c (IPアドレス) を実行。

cron に登録するシェルスクリプトはこんなところ。
pdns-client 内で curl、jq を使っているので、その流儀に合わせた。

#!/bin/sh
ARECORD=`dig @master.example.com home.example.com a +short`
CURRENT=`curl -s https://pdns.example.com/api/v1/remote/ip | jq -r .ip`
if [ $ARECORD = $CURRENT ]; then
	echo "The A record does not need to be update."
else
	echo "Updating the A record..."
	pdns-client -s https://pdns.example.com/ -i 11 -c ${CURRENT}
fi

Basic 認証を使っている場合

私がまさに該当する。
Basic 認証と PDNS Manager で二重の認証を必要とすることで、より侵入しにくくする、という考え方。

GET メソッドの場合、さほど悩む必要はない。

  • wget なら –user=ユーザー –password=パスワード をつければいいだけ。
  • curl なら –basic –user ユーザー:パスワード をつければいいだけ。

問題は POST メソッドで、pdns-client が実行する curl にパラメーターを渡す必要があるわけだが、pdns-client 内に認証情報をハードコードしたくない。
というわけで pdns-client を改造した。
GitHub で fork して改造したのを公開しているので、そちらをどうぞ。

使い方はこんな感じ。
「-b ID:パスワード」で認証情報を渡す。

pdns-client -s https://pdns.example.com/ -i 11 -c 203.0.113.9 -b ID:パスワード

PowerDNS で DNS コンテンツサーバー構築。バックエンドは MariaDB でレプリケーション

日付:

ぶっちゃけ「ALIAS レコードが使いたい」というだけの理由で、PowerDNS に乗り換えた。
だが本気で乗り換えてみれば、PDNS Manager でレコード編集は楽だし、バックエンドを MariaDB にしてレプリケーションさせればゾーンの増減時にスレーブでの作業が不要になってさらに楽。
ただし構築は NSD と比べて手間がかかる。


マスターが master.example.com (192.0.2.1)、スレーブが slave.example.com (198.51.100.1) という構成を想定して書いていく。
DNS 的なゾーン転送 (AXFR) をするわけではないのだが、一応。

マスターはメモリ 2GB で nginx 等も動作しており、スレーブはメモリ 512MB で DNS のみを担当という想定。想定というか実際そうなのだけれども。

ALIAS レコードを使うので、127.0.0.1:53 に PowerDNS Recursor を動かす。

手順は Debian でも Ubuntu でもほぼ同じ。実際に私のスレーブのうち1台は Ubuntu である。
(ただし /etc/mysql/my.cnf だけなぜか Ubuntu だとないので、Debian からコピーした)


MariaDB、PowerDNS の導入

マスター、スレーブで共通の作業。

MariaDB は Debian 収録物ではなく MariaDB Repositories で導入する。
ただ add-apt-repository は好みじゃないので手順を少し変更。

sudo apt install dirmngr
sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 0xF1656F24C74CD1D8
echo 'deb http://ftp.yz.yamagata-u.ac.jp/pub/dbms/mariadb/repo/10.3/debian stretch main' | sudo tee /etc/apt/sources.list.d/mariadb.list
sudo apt update
sudo apt install mariadb-server

PowerDNS も Debian 収録物ではなく PowerDNS repositories で導入する。

wget https://repo.powerdns.com/FD380FBB-pub.asc -O - | sudo apt-key add -
echo 'deb http://repo.powerdns.com/debian stretch-rec-41 main' | sudo tee /etc/apt/sources.list.d/pdns.list
echo 'deb http://repo.powerdns.com/debian stretch-auth-41 main' | sudo tee -a /etc/apt/sources.list.d/pdns.list
sudo apt update
sudo apt install pdns-recursor pdns-server pdns-backend-mysql

pdns-server が起動失敗するが、この時点ではそれで問題ない。
標準では pdns-server が *:53 を listen するのだが、127.0.0.1:53 を先に pdns-recursor が listen しているため、pdns-server が listen できないのだ。


MariaDB のインスタンスを分ける

マスターでは DNS 以外の仕事も担当しており、MariaDB は PowerDNS のみを収容しているわけではない。
しかし MariaDB の REPLICATION SLAVE 権限は特定のデータベースのみを対象とする権限ではなくグローバル権限なので、スレーブがマスターのデータベースすべてをレプリケーションする権限を持ってしまう (権限を持った上で、スレーブ側の設定でレプリケーションするデータベースを絞る、という形になる)。
これはセキュリティ上好ましくないので、PowerDNS 専用の MariaDB インスタンスを別に立ち上げる。

MariaDB を複数インスタンス起動する手段として、ちょっと古い記事だと mysqld_multi を使う説明が多いのだが、mariadb.service の代わりに mariadb@.service を使うという手段がある。
systemctl start mariadb@HOGE すると、mysqld –defaults-file=/etc/mysql/conf.d/myHOGE.cnf が実行される仕組み。この場合 /etc/mysql/my.cnf は読み込まれない。
なので /etc/mysql/my.cnf から末尾の !include-dir を除去したものを /etc/mysql/conf.d/mymariadb.cnf に置く。!include-dir /etc/mysql/conf.d なので除去しないと無限ループ。
!include の方は残してもいいが、PowerDNS 専用インスタンスはすべて mypdns.cnf に記述するので、!include も除去して mymariadb.cnf だけで済ませる方が統一感があるように思われる。

PowerDNS 専用インスタンスは次の設定とする。

  • ソケット /var/run/mysql/mysqld_pdns.sock
  • PID /var/run/mysql/mysqld_pdns.pid
  • ポート 3307
  • データディレクトリ /var/lib/mysql_pdns
  • バイナリログ /var/log/mysql/mariadb_pdns_bin
  • server-id 1
sudo systemctl stop mariadb
sudo systemctl disable mariadb
sed -e '/^!include/d' /etc/mysql/my.cnf | sudo tee /etc/mysql/conf.d/mymariadb.cnf
sed -e '/^!include/d' -e 's/\/var\/lib\/mysql/\/var\/lib\/mysql_pdns/g' -e 's/mysqld.\(sock\|pid\)/mysqld_pdns.\1/g' -e 's/3306/3307/g' 's/#\(server-id\)/\1/' -e 's/mariadb-bin/mariadb_pdns_bin/g' /etc/mysql/my.cnf | sudo tee /etc/mysql/conf.d/mypdns.cnf
sudo mysql_install_db --datadir=/var/lib/mysql_pdns
sudo systemctl enable mariadb@mariadb mariadb@pdns
sudo systemctl start mariadb@mariadb mariadb@pdns

PDNS Manager を使うので、空のデータベース pdns を作っておく。
同時にユーザー pdns@localhost、レプリケーション用ユーザー pdnsrepl@localhost も作る。

root のパスワードが空なので、これもパスワードを設定しておく。
mariadb を導入した時点で root のパスワードをつけたじゃないかって? それは mariadb@mariadb における root のパスワードで、mariadb@pdns における root のパスワードではない。

PowerDNS 慣れしている人はここでテーブルを作りそうになると思うが、PDNS Manager がテーブルを作るので、空のまま。

sudo mysql -P 3307 -h 127.0.0.1
CREATE DATABASE pdns;
GRANT USAGE ON *.* TO pdns@localhost IDENTIFIED BY 'パスワード';
GRANT ALL ON pdns.* TO pdns@localhost;
GRANT REPLICATION SLAVE ON *.* TO pdnsrepl@localhost IDENTIFIED BY 'パスワード';
UPDATE mysql.user SET password=PASSWORD('パスワード') WHERE user='root';
FLUSH PRIVILEGES;
\q

スレーブでもデータベース pdns、ユーザー pdns@localhost を作っておく。

sudo mysql -p
CREATE DATABASE pdns;
GRANT USAGE ON *.* TO pdns@localhost IDENTIFIED BY 'パスワード';
GRANT ALL ON pdns.* TO pdns@localhost;
\q

PDNS Manager の導入

マスターでの作業。

PDNS Manager を入れる。
公式サイトの説明が今時珍しく Apache での説明しか書かれていないので、nginx での設定を書いておく (PHP は php-fpm を使っている)。

server {
	server_name pdns.example.com;

	root /var/www/html/backend/public;
	index index.html index.php;

	location / {
		root /var/www/html/frontend;
		try_files $uri $uri/ /index.html;
	}

	location /api {
		try_files $uri $uri/ /index.php;
	}

	location ~ [^/]\.php(/|$) {
		if ($request_uri ~* "/api(.*)") {
			set $req $1;
		}
		fastcgi_pass unix:/run/php/php7.3-fpm.sock;
		fastcgi_split_path_info ^(/api)(/.*)$;
		fastcgi_index index.php;
		fastcgi_param SCRIPT_FILENAME $request_filename;
		fastcgi_param PATH_INFO $fastcgi_path_info;
		fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
		fastcgi_param REQUEST_URI $req;
	}
}

https://pdns.example.com/setup をブラウザーで開き、初期設定を行う。
基本的に Getting Started の通りだし、ぶっちゃけ画面見ればどこに何を入力すべきか一目瞭然だが、注意点が一つ。

Database の Host は localhost ではなく 127.0.0.1 とする

127.0.0.1 を指定しないと mariadb@pdns ではなく標準の方 (mariadb@mariadb) につながってしまうため。
コマンドラインで mysql -P 3307 -h 127.0.0.1 としていたのも同じ理由による。

ドメインの追加は、Add domain | MASTER | NATIVE | SLAVE とある中で、NATIVE で行う。
PowerDNS でゾーン転送 (AXFR) するのではなく、バックエンドである MariaDB を使って同期するためだ。


ssh port forwarding の設定

MariaDB は標準の設定ファイルでは localhost しか listen しないし、これを開放するのはセキュリティ上好ましくない。
なので、スレーブからマスターに ssh port forwarding で接続できるよう設定する。
レプリケーション用のシステムアカウントを作り、autossh で接続を維持する。

マスター、スレーブで共通の作業:

sudo useradd -r -s /usr/sbin/nologin -d /etc/powerdns/pdnsrepl pdnsrepl
sudo mkdir /etc/powerdns/pdnsrepl
sudo chown pdnsrepl:pdnsrepl /etc/powerdns/pdnsrepl
sudo chmod 700 /etc/powerdns/pdnsrepl
sudo -u pdnsrepl mkdir /etc/powerdns/pdnsrepl/.ssh
sudo -u pdnsrepl chmod 700 /etc/powerdns/pdnsrepl/.ssh

スレーブでの作業:

sudo -u pdnsrepl ssh-keygen -t ed25519
sudo apt install autossh

スレーブの /etc/powerdns/pdnsrepl/.ssh/id_25519.pub の内容を、マスターの /etc/powerdns/pdnsrepl/.ssh/authorized_keys に貼り付け。
もちろん authorized_keys は 600 にする。

スレーブで /etc/systemd/system/autossh-pdnsrepl.service を作成。

[Unit]
Description=AutoSSH port forwarding for PowerDNS DB replication

[Service]
ExecStart=/usr/bin/sudo -u pdnsrepl /usr/bin/autossh -f -M 0 -N -L 3307:127.0.0.1:3307 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" pdnsrepl@master.example.com
ExecStop=/usr/bin/killall -KILL autossh
Type=forking

[Install]
WantedBy=multi-user.target

スレーブでの作業:

sudo -u pdnsrepl ssh pdnsrepl@master.example.com
sudo systemctl enable autossh-pdnsrepl
sudo systemctl start autossh-pdnsrepl

これで、スレーブで 127.0.0.1:3307 に接続するとマスターの 127.0.0.1:3307 につながるようになった。


レプリケーションの設定

マスターでの作業:

sudo mysql -P 3307 -h 127.0.0.1 -p
FLUSH TABLES WITH READ LOCK;
\q
sudo mysqldump  -P 3307 -h 127.0.0.1 -p pdns --lock-all-tables > pdns.db
sudo mysql -P 3307 -h 127.0.0.1 -p
UNLOCK TABLES;
SHOW MASTER STATUS;
\q

SHOW MASTER STATUS; で表示されたファイル名とポジションをメモりつつ、できた pdns.db をスレーブにコピーする。

スレーブでの作業:

sudo mysql pdns -p < pdns.db
sudo systemctl stop mariadb

/etc/mysql/mariadb.conf.d/slave.cnf を作成。
マスターでは my.cnf をベースに編集したファイルを mariadb@.service で直接読み込ませていたが、スレーブでは MariaDB インスタンスを分けず mariadb.service で起動するため、最小限の追加で済ませる。

[mysqld]
server_id = 2
read_only
replicate_do_db = pdns

スレーブでの作業:

sudo systemctl start mariadb
sudo mysql -p
CHANGE MASTER TO MASTER_HOST='127.0.0.1', MASTER_PORT=3307, MASTER_USER='pdnsrepl', MASTER_PASSWORD='(マスターで pdnsrepl@localhost につけたパスワード)', MASTER_LOG_FILE='(マスターの SHOW MASTER STATUS; で表示されたファイル名)', MASTER_LOG_POS=(マスターの SHOW MASTER STATUS; で表示されたポジションの数字);
START SLAVE;
\q

PowerDNS の設定

/etc/powerdns/pdns.d/mysql.conf を作成。

マスター:

launch+=gmysql
gmysql-dbname=pdns
gmysql-user=pdns
gmysql-password=パスワード
gmysql-socket=/var/run/mysqld/mysqld_pdns.sock

スレーブ:

launch+=gmysql
gmysql-dbname=pdns
gmysql-user=pdns
gmysql-password=パスワード
gmysql-socket=/var/run/mysqld/mysqld.sock

/etc/powerdns/pdns.conf を編集。
変更点は以下の通り。

  • expand-alias=yes
  • local-address は外側 IP アドレス (本記事の想定ではマスター 192.0.2.1、スレーブ 198.51.100.1) に設定する。
  • IPv6 がない場合、local-ipv6= にする。
  • resolver=127.0.0.1

pdns-server を起動。

sudo systemctl start pdns

完了。

NURO の詐欺みたいなタイトルのチラシ

日付:
タグ:

NURO の詐欺みたいなタイトルのチラシが入っていた。

ご不在連絡書

ご不在連絡書
何か自分にとって重要なものかと思って見るよね。
で、結局ただの spam なわけだ。

こういう詐欺みたいなタイトルは So-net 公認なのか?
少なくとも私の NURO に対する印象はかなり悪くなったぞ。
So-net はクソみたいな代理店をきっちり教育しなさい。

ちなみにこれが入ってた日、私は不在じゃなかった。
リアルアーツ株式会社、嘘ばっかじゃん。


先日 NHK が来たので「地デジもワンセグも映る機器がない」と言ったら「ご購入されましたらご連絡をお願いします」と帰ったくせに不在票入れてきたり、最近この手の嘘が流行ってるんだろうか。

アットウィキの anti-adblock を uBlock Origin で対策

日付:

uBlock Origin を使っているのだが、たまたま見たアットウィキ (atwiki、@wiki) の anti-adblock が全面モーダル表示であんまりなので対策。

uBlock Origin の My フィルターに、このどちらかを入れる。

atwiki.jp##div:has(#modal-window)
atwiki.jp##div:matches-css(position: fixed)

Adblock Plus を使っている場合はこうかな? ただし私は使っていないのでこれでいけるか不明。

atwiki.jp##div:-abp-has(#modal-window)
atwiki.jp##div:-abp-properties(position: fixed)

Togetter のまとめでは div の ID がランダムになったので対策不可能とされている。

しかし、そのランダムな ID を持つ div の子要素に #modal-window (「広告が表示されていません」ダイアログ) があるので、子要素で引っかければ良い。
それが :has() だ。

あるいは、全面モーダル表示は基本的に position: fixed を使うので、そこで引っかける。
:matches-css() だ。

私は :matches-css() を使っている。もし ID が変更されても、position: fixed は変わらないと思われるので。

手間いらず株式会社からの Apple を騙るフィッシング spam

日付:
タグ:

もう2回目なので晒し者にしておく。

手間いらず株式会社 (東証マザーズ2477) から Apple を騙るフィッシング spam が届いている。

Received: from earth.temanasi.jp (www.temanasi.jp. [211.125.61.96])
        by mx.google.com with ESMTP id p203si1134417ywg.170.2019.01.17.04.22.39
        for <musashi@araki.jp>;
        Thu, 17 Jan 2019 04:22:39 -0800 (PST)
Received-SPF: pass (google.com: domain of apache@temanasi.jp designates 211.125.61.96 as permitted sender) client-ip=211.125.61.96;
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of apache@temanasi.jp designates 211.125.61.96 as permitted sender) smtp.mailfrom=apache@temanasi.jp
Received: by earth.temanasi.jp (Postfix, from userid 48) id 6895BE9800D; Thu, 17 Jan 2019 21:22:38 +0900 (JST)
To: musashi@araki.jp
Subject: [情報] Apple IDがロックされています。あなたの最近のアクセスアカウントにいくつか問題がありました。
X-PHP-Originating-Script: 48:s-box.php
MIME-Version: 1.0
Content-type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
Mailer: Mailer
Message-ID: <1547727748-7e1400de641e46f3bba097170b5ece37-9197ec103d780b6779cb78eec6afce31-zkhl@www.temanasi.jp>
From: "ブラウザ上のApple Phone" <n0replay.supportliveOXXX2DEECDDVHJ80support@www.temanasi.jp>
Date: Thu, 17 Jan 2019 21:22:38 +0900 (JST)

以前も SpamCop で上流の abuse@web.ad.jp に通報したと記憶しているのだが、再発しているので HN506JP と ST11510JP も通報先に追加しておいた。


(2019/03/04 追記)

コメント欄としてつけている Disqus に本日このようなコメントが投稿された。

投稿者: ゆー

本文:
手間いらず株式会社のドメインはtemairazu.comですが、そのメールヘッダはtemanasi.jpになってますよ?完全に誤認情報では?

コメント返信でも反論しているが、記事中でもまとめておく。

まず、temanasi.jp の登録者名である「比較.com株式会社」 (JPRS WHOIS) は、手間いらず株式会社の2017年10月以前の商号である。
これは手間いらず株式会社の沿革ページに明記されている。

2017年10月 「比較.com株式会社」を「手間いらず株式会社」に商号変更

次に IP アドレスの話。

  • temairazu.com の IP アドレスは 211.125.61.95 である。
  • temanasi.jp の IP アドレスは 211.125.61.96 である。

両 IP アドレスが属する CIDR ブロック 211.125.61.64/26 は「比較.com株式会社」名義である (JPNIC Whois Gateway)。

以上から誤認ではなく、手間いらず株式会社から送信されたものであることは間違いないと考えている。
さすがにこの程度のことは調べた上でないと、他社を名指しで批判できない。まして相手は上場企業なのだから、ろくに確認もせず言いがかりをつけたとあっては「風説の流布」などで私の手が後ろに回る。

また、211.125.61.64/26 の管理者連絡窓口、技術連絡担当者に指定されている SK14915JP (JPNIC Whois Gateway) の電話番号は、手間いらず株式会社の会社概要ページに大代表として記載されている電話番号と一致している (これは Jun11 氏のコメントで気づいた。御礼申し上げる)。


手間いらず株式会社から送信された Apple を騙るフィッシング spam については、他の方のブログで2018年12月14日送信分2018年12月18日送信分が紹介されている。 私が本記事に掲載したものから約1ヶ月前のものだ。

私は「手間いらず株式会社が主体的に Apple を騙るフィッシング spam をばらまいた」とまでは考えていない。踏み台にされただけだろう。
しかし、これは ASP 事業者たる手間いらず株式会社が spam の踏み台にされる状況を1ヶ月以上も放置していた、ということを意味する。
仮にもプロが何やってんの? という感想しか持てない。