2018年09月08日(土) - 22:56 | カテゴリ:
Linux
先日、シングル構成にしていたHDDが1台吹っ飛んだ。
仮想サーバのマスタイメージなど、無くなるとマズイデータはRAID1で冗長化しつつ、
別媒体にコピーもしているのだが、今回は重要度低めなのでシングルだった。
という事で、随分前にアキバでIYHしてきたジャンクPCにLinuxMintをインストールし、
ddした後にファイルシステムの復旧コマンドを叩いている状況。
データ復旧作業なんて久しくやっていなかったので、果たして上手くいくやら…
時間があったら後ほど手順を紹介しようと思う ﾍ(ﾟ∀ﾟﾍ)
2018年08月26日(日) - 20:22 | カテゴリ:
Linux
先日、さくらインターネットからこんなメールが届いた。
ぶっちゃけ記憶の彼方だったのだが全文読んだ辺りで…
( ﾟдﾟ) ﾊｯ! 思い出した！
ず～～っと前に「さくらのVPSでIPv6の逆引きを自由に設定したい」とフィードバックを送った事があり、
ついにIPv6逆引き機能を実装したという連絡。
さくらのVPSは多機能なので大きな不満は無かったのだが、
その中でも微妙に困っていたのがIPv6の逆引きだった。
ns-lab BBは権威DNS・メール鯖などを(ほぼ)全て自前で構築して運用している。
また、Internetコンテンツ系のサーバは自宅サーバとVPSのハイブリット構成を取っており、
DR用途と比較・検証を兼ねてVPS事業者をあえて分けて使っている。
なので、事業者毎に実装されている機能に違いがあり、結果としてフル機能を使えない事が少しあった。
その中の代表的な問題がIPv6逆引き設定であり、メール鯖にも影響が出るのでどうした物かと思っていた。
そんな中、今回はさくらのVPSがIPv6逆引き設定自由化に対応してくれたので、
今まで出来なかったサーバ構成にトライ出来るようになった。ありがたやー
という事で、今回は権威DNS・メール鯖の兼用サーバにIPv6逆引きを好きに設定しつつ、
メールのDMARCもIPv6に正式対応させてみた。
メールサーバ(MTA)のIPv6対応はググれば色々出てくるので割愛。
件のns-lab BBメール鯖はデュアルスタック方式で割り当てた。
ずっとテコ入れしたかったSPFも、今回のサーバ構成の微変更に伴いレコードを作り直した。
ns-lab BBのメールSPFレコードはIPv4のみを適当に直書きしていたのだが、
今回からIPv6も含める事となったのでレコード構成を本気で見直した。
実際に色々なメールサーバのSPF登録例を読みつつ、SPF仕様にも沿う形で下記の様に登録した。
具体的には、IPv4/IPv6でタイプが分かれる事を活用しincludeを使って外部参照する形にした。
こうする事でサブドメイン全体のメールSPFレコード(アスタリスクSPFレコード)にも噛ませたり、
管理用でIPを追加せざるを得なくなった場合にも、include・redirectで組み替えられる様になった。
SPFは10回のDNSクエリ(include)以内に参照を完結させる決まりがあるが、
上記ならば3クエリになるので無事に納まった。
include構成はYahooメール・Gmailなどの大手フリーメールでも採用している鉄板構成だったりする。
ちなみに、10回のDNSクエリ制限はRFC7208-4.6.4で策定されている。
………
SPF検証・DKIMシグネチャ付与・DMARCポリシーの設定は既存の物を流用しつつ、
IPv6対応のついでにサブドメインメールの認証も追加した。と言いつつ、DMARCはsp=noneですが
その後、実際にGmailからメールサーバに対してメールを送ったり、
外部のDMARCテストサイトを使って検証した所、全て設計通りに署名・検証が完了した。
想定通りReceivedはIPv6アドレスが記録され、受信のメール配送はIPv6経由で問題無く完了した。
流石にGoogleだけあって、メールもちゃんとIPv6に対応していた。
………
DMARCの検証には自鯖からGmailへメールを送ったり、外部の検証サイト(なりすまし対策ポータル)を活用。
検証サイトでテストした所、こちらも設計通りに「mail.ns-lab.org」発のメールが「PASS」になった。
ぶっちゃけ、自鯖でここまでメールセキュリティを上げている人は一握りの逸般人だと思うが、
何でも出来る自宅サーバだからこそ、色んな技術を積極的に導入していきたい所。
セキュリティ技術やIPv6は普及が進んでない事もあり幾らでも掘り下げられるので、
今後も自鯖インフラを活用しつつトライしてみようと思う。
« 続きを隠す
2018年08月19日(日) - 23:16 | カテゴリ:
Linux
Linuxド素人な一般人が解析した結果なので、
原因究明・解析とは違うかもしれませんがご了承ください。
………
題名の通り _(:3」∠)_
実はコレが起きたのは1ヶ月程前の自宅鯖なのだが、
当時はコミケ前だった事もあり凄く忙しかったので切り戻して復旧させた。
また、それよりも前にはゲストサーバのCentOS6をkernel 4.17.0に更新すると、
GRUBでkernelを選択した後に強制再起動がかかり、
再度GRUB起動の上また再起動する無限ループ化するのも大きな問題だった。
そして、先日ふとコレの事を思い出したので夏休みを数日使ってデバッグしてみた。
最終的に原因は判らなかったが、LKML.ORGを見たりqemuのサポート情報を見た感じだと、
kernelに追加されたKPTIとホストサーバ・ゲストサーバのミスマッチっぽかった。
ちなみに、未だに解決はしていないのでどなたか詳細知っている方いたらおしえて下さい (´；ω；｀)
当初、ゲスト鯖のkernelが不具合を持っているのか、ホスト鯖の方が悪いのか判らなかった。
という事で、バージョンを変えながらkernelビルドを繰り替える事20回。
ゲストサーバのkernelを4.17.0に上げると再起動ループになる事が判明。
この再起動もKVMの機能で電源が落ちた後に自動復旧しているのか、
本当に再起動しているのか不明だった為、ゲスト鯖のlibvirt XMLを下記の様に変えながらテスト。
結果、on_rebootをdestroyすると再起動しなくなる事からゲスト側で本当に再起動していないと判明。
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
|
ぶっちゃけ、コレにたどり着くのに2日かかった _(:3」∠)_
………
最初からlibvirtdのログ出力は [log_level=1] にしていた事もあり、
QEMUのプロセスにstraceをかけてみた。
結果、再起動が発生する直前から「futex() error」が大量発生している事が判明。
状況からしてメモリマッピングが何か変なのかと推測。
kernel 4.17.0が出た頃と言えば、巷がCPUのmeltdown/spectre問題で賑わっていた時なので、
『何か実装ミスっているのかな…』と仮説を立てつつ、MLを漁ってみた。
………
最初に書いた通り明確な原因はわからなかったが、ARM64を使った場合に似た状態になる記述を発見。
状況が似ているので「KVM guest infinite reboot loop」の様に検索したら色々引っかかった。
それらを総合的に評価すると冒頭の通りとなった。
………
『色々とやった… が、ダメだったよパトラ○シュ』
qemuのリビルド＆アップグレード、libvirtdのトレースON(ログは出なかった)などなど。
Step1にも書いた通り、ゲストOS以下の物理寄りは普通に動いているわけなのでエラーが無かった。
今回、色々とやった訳なのだが目的であったエラーの解決は出来なかったが、
ヒントになりそうな所までは来れたので時間がある時に再チャレンジしようと思う。
解決は出来なかったが調査の副産物として、
今までなんとなく使っていたlibvirtd/qemuの挙動やら設定やらに詳しくなれたので、
まぁ良しとする事にしよう (´・ω・｀)
« 続きを隠す
