2018年09月15日(土) - 23:02 | カテゴリ:
Linux
前回軽く書いていたHDDのクラッシュ修復。
色々と頑張ったが、待避させた時には手遅れだったのか救出不可能だった。
という事で、何をやったがダメだったのか備忘録。
ちなみに、今回お亡くなりになったのはコチラのHDD。
本来はデスクトップ用な物を自鯖で24h/365d稼働させていた事もあり、
約3年でクラッシュした。
- データコピー
定説通り、適当な余りHDDにddやらddrescueでデータコピーを実行。
…しようとしたら、そもそもコピーする段階でエラーが発生して読込み出来なかった。
流石に、ハードウェアコピーする機械は所持していないので、
今回は仕方なくデータ救えなくなる事を覚悟で元HDDでデータ救出を実行。
- fsckでFS修復
定説通りにfsckを実行。
今回のHDDはext4だったので、途中まで普通に走ったが、
ddでエラー出た辺りのブロックでエラー再発したので停止。
- 復旧天使の実行
物は試しと復旧天使を実行してみた所、一部のデータは0バイト状態で見えた。
ただ、0バイトなのでファイルの残骸しか残っておらず断念。
- 再度、fsck実行
ここまで来たら復旧は諦めて、fsckをエラー吐かせつつ全領域実行してみた。
2TBを実行するのに丸3日掛かったが、最終的には完走。
ただ、やはりファイルは復元出来なかった。
………
最終的には復旧出来なかったが、それなりに技術調査しながらやっていたので楽しかった。
まず、復旧させる時は真っ先にread-onlyでマウントするのが定石だが、
ハードウェアレベルで故障している場合は、そもそもマウント自体がアウトだった。
あと、先にfsckを実行したが真っ先に修復アプリに頼るのも一つの手かもしれない。
今回はext4だったが、xfsだとまた変わるのかもしれない。
xfsはfsckの代わりにxfs_repairコマンドになったが、
ダーティログを持つFSを修復出来なかったりするが、
天下のredhat様が色々とドキュメントを公開しているので、ある程度までは対応出来る。
そもそも、バックアップ取得しておくのが最良だが、
稀に復旧チャレンジする場面があるので、憶えておこうと思う。
« 続きを隠す
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は普及が進んでない事もあり幾らでも掘り下げられるので、
今後も自鯖インフラを活用しつつトライしてみようと思う。
« 続きを隠す
