Vine Linux」カテゴリーアーカイブ

自宅サーバ メール配送遅延・不達問題(後に解決)

システム用のHDDにトラブルが出て対処中にもかかわらず、新たなトラブルが出ました。

ある日突然、自宅サーバからいくつかのドメインに、メールを配送できなくなりました。

心当たり不明。スパム対策(S25Rなど)も行っているので、なぜそんなことに・・・

 #2013/10/23追記:

大変初歩的なミスが原因とわかりました。メールサーバはドメインのマスターのネームサーバも兼ねているのですが、ネームサーバのIPアドレスが変わったにもかかわらず、レジストラのネームサーバIPアドレスを変更し忘れていました。

タイミングによっては、違うIPアドレスでありながら、勝手にマスターサーバを名乗って詐称していたことになっていたわけです。そんなサーバからの接続、拒否されても当然です。

固定IPアドレスをそれほど頻繁に変えるわけではないために、その作業をすることを忘れていました・・・

レジストラの登録情報を変更したあと、メールを拒否される事象は発生していません。

 

とりあえず、ブラックリストに登録されていないか調べてみた

Blacklistalert.org

自宅のメールサーバはブラックリストには登録されて無さそう

自宅のメールサーバはブラックリストには登録されて無さそう

見たところ、ブラックリストの線はシロのようです。

他に、rbl.jpでも検索しましたが、シロでした。

キューが溜まってないか見てみた

mailqでメールの配送待ちがないか見てみたところ(mailq)、通常、溜まっているメールなんてないのに、「9通も!」溜まっていました。

溜まっている原因はどれも、

  • conversation timed out
  • lost connection while EHLO handshake
  • refused to talk to me

のどれかでした。相手サーバから「拒否」されたか、「シカト」されたってことのようです。

postfix flush

で、溜まったキューの強制配送をしてログを監視していましたが、案の定、2通は上記3つのメッセージのオンパレードでした。
2通は受け付けてくれて送れたみたいです。

 

拒否されている相手は、携帯3社(docomo.ne.jp,softbank.jp,ezweb.ne.jp)、複数のプロバイダのドメインのメールサーバでした。

同時に拒否されるってことは、これらプロバイダや携帯キャリアが共通に参照しているDBがあって、そこに登録されてしまった可能性が高いと思いますが・・・それがなんなのか、見つけられませんでした。

結局、グローバルIPアドレスを変更した。回復した。

結局、最後の策としてあまりやりたくありませんでしたが、自宅サーバに割り当てられているグローバルIPアドレスを変更してみることにしました。

現在利用しているプロバイダと(固定IPを安価に提供していて、申込み即日接続可)、追加の接続契約を結んで、新たなIPアドレスの払い出しを受けることにしました。並行運用期間を終えたら、現在の契約は解除することになります。1ヶ月程度の二重課金を覚悟しての対策です。

申込みはすんなり完了し、フレッツPPPoE用の新接続IDとともに、新IPアドレスが届きました。

HGWに新セッション情報を登録し、自宅サーバが新セッションからインターネットに出るよう設定し、新セッションと旧セッション両方からの通信が受信できるようIPマスカレードの設定を行いました。

 

この状態まで持って行ったところで、メールキューを強制配信(postfix flush)をしたところ、全部一気に配信が完了しました。便○解消!って感じ。

やっぱり、何かのきっかけでスパムサーバ扱いされていたのだと思います。
IPアドレスを変更しただけで回復したことから、スパム登録の対象はIPアドレスのみで、ドメイン名は拒否対象ではなかったようです。

結局なぜこんなことになったのか、理由はよくわかりませんが、この後メールサーバのスパム対策を強化(taRgrey)しました。結構いい感じになりましたが、これはまた後日。

自宅サーバのシステムHDDセクタ異常発生につき、交換! 2TB→3TB LVM使用 fdisk→parted その3

前回の続き。

結果的にはシステムドライブは移行成功(MBR→GPT)

Linuxの自宅サーバの、システムとして使っているHDDがセクタ異常を出し始めたため、応急処置の上、HDDを交換することにしました。

ところが、旧HDDは2TBのMBR形式(fdisk)、新HDDは3TBのGPT形式に変更しなければならず、BIOSからGPTディスクを起動するという私にとっては未知の領域に挑戦することになってしまいました。

新HDDを2TBディスクとしてMBR形式で使えば、悩む必要も無いのですが、そういう野暮な使い方は私の感性が許しませんでした。

BIOSからGPTディスクのLinuxを起動する方法が、「なんとなくできそう」というところまではわかったものの、なぜうまく起動できるのか理屈が理解できておらず、今ひとつ確信が持てませんでした。

以上が前回までの経緯。

 

その後も調査を続けましたが、いつまで経っても核心持てる情報にたどり着かないので、強行しちゃいました。

結論から言うと、うまいことHDDを旧→新、移行できましたが、grubまわりで手間取り、1時間ほどサーバを停止してしまいました。

応急処置で、197 Current_Pending_Sectorが、1→0になっていましたが、
移行作業完了後、3に増えていました。やっぱり早めの対処が必須です。恐ろしい・・・(汗)

作業概要

大まかに、以下の手順で作業を進めました。

  1. 新HDDのパーティションを切る、pvを作る
    • bios_grubパーティションを作成
    • bootパーティションを作成
    • 残りをlvm用として、50GB~100GB単位で切りまくる
    • lvm用のパーティションに対してpvcreate
  2. lvmを利用してドライブのデータを新HDDに移動する
    • vgextend でVGに新HDDのPVを追加
    • pvmove で旧HDDのPVから新HDDのPVにデータを逃がす
    • vgreduce で旧HDDのPVをVGから除外する
    • 以上を旧HDDのPVの数だけ繰り返し。
  3. 新HDDにgrubをインストール
  4. 新HDDのmenu.lst、fstabを調整する
  5. シャットダウンし、HDDのケーブルをつなぎ替え(新旧入れ替え)、電源投入
    • 旧HDDのケーブルを抜く
    • 新HDDに旧HDDにささっていたケーブルを挿す

すんなり書いていますが、実は、4をやらずに5をやったため、Linuxが起動せずかなり焦りました。

前提の環境

作業に当たっての前提条件は以下。

  • 自宅サーバのスペック:
    • OS : Vine Linux 6.1
    • CPU : Phenom2 x6 1065T
    • メモリ : 16GB
    • HD : 3TB x1 , 2TB x1 , 1TB x1 (システムドライブは2TB)
    • マザー:Giga-byte GA-880GA-UD3H Rev.2.2 (U-EFI非搭載)
  • 旧HDDの状態
    • デバイス名:/dev/sda
    • 容量:2TB
    • 領域確保の方式:MBR(fdisk)
      • /dev/sda1 :boot領域
      • /dev/sda2~15 :lvmで使用。root領域もlvm内。
  • 新HDDの状態
    • デバイス名:/dev/sdd
    • 容量:3TB
    • 領域確保の方式:GPT(parted)
      • /dev/sdd1 :bios_grub領域
      • /dev/sdd2 :boot領域
      • /dev/sdd3~34 :lvmで使用。旧HDDのVGを移行する。

といったところ。

コマンド等含めた作業詳細は次回。(書く時間がなかなかとれない・・・)

自宅サーバのシステムHDDセクタ異常発生につき、交換! 2TB→3TB LVM使用 fdisk→parted その2

前回、システムドライブがセクタエラーを吐いたため、ドライブを交換することになり、交換用ドライブが届いた件の続きです。

3TBの容量を活かすには、MBR(fdisk)ではダメ。GPTです。

今回、何も考えずに購入した交換用HDD(Seagate ST3000DM001/N)は3TBの容量です。交換前の現システムドライブは2TB。

KURODACHI」で2TB→3TBにハードコピーして、あとから領域拡張して終わることを目論んでいましたが、そうは問屋が卸さなかった。

2TBの現HDDで使っている、MBR形式(正しくは、MBR領域の情報でパーティション管理する形式)では2TB以上の容量を確保できず、捨てることになります。すっかり忘れていました。
データ用3TBドライブを既に所有していて、GPTで領域を切って運用しているというのに!(歳には勝てん)

2TBを越えるHDDを、無駄なく使用するには通常のfdiskでのMBR形式ではなく、より新しいGPT形式を使う必要があります。私のVineLinuxでは、コマンドラインの管理ツールはparted。

MBRからGPTに移行する必要があるため、「KURODACHI」は使えません

データディスクとして使う分にはpartedの使い方を調べて、領域確保してmkfsすれば普通通りに使えるのですが、今回はブートドライブとして使うため、私としては知識不足。調査が必要でした。

 MBRとGPTでは扱える容量も違うが、ブート方法も違う

マシンが起動する最初の最初は、電源投入後にマザーボード搭載のBIOSが起動し、HDDのMBR(先頭セクタ)を読み出しにいき、起動が始まります。PCはすべて、そのルールの下に作られています。

PCのHDDは、1セクタの長さは512byteと決まっています。MBR領域はHDDの先頭1セクタです。要は、たった、512byteしか容量がありません。

今時の大容量かつ複雑なHDDの起動に必要な情報すべてを、ここに入れ込むことはできないため、MBRを読んだ後、特定の別の領域にジャンプして続きの情報をゲットさせるなど、つぎはぎだらけの拡張で何とかやってきました。

fdiskでプライマリパーティションが4つ、拡張しても15個しか作れないのは、この領域の狭さに起因しています。
また、最大利用できるディスク領域も2TBまでに制限されます。MBR形式ではディスクのセクタ数を32bitで扱っていることによる制限です。

 

GPTは、この仕組みを見直すもので、セクタを取り扱うアドレスも64bitとするなど、MBR形式の弱点を克服しています。また、起動時にMBR領域を使用しません。当然、MBR領域から起動することを想定して作られているBIOSでは、GPTディスクを素直に起動することはできず、U-EFIという仕組みで起動するようにしているのだそうです。

取り扱える領域は8ZB(ゼタバイト)、128個のプライマリパーティションを扱えます。私が生きている間は十分持ちそうです。

Windows系ではBIOS+GPTの組み合わせでは起動できず、U-EFIが搭載されたマザーボードでないと起動しないようです。

Linuxではどうやら、少しの工夫を加えることで、U-EFIを搭載していないBIOSのみのマザーボードでもGPTディスクから起動できる方法がありそうな感じです。

パーティションを切るときは、AFTも要考慮

また、この新HDDはパーティションを切るときに、AFTを考慮する必要があります。

AFTはAdvanced Format Technology。最近発売のHDDはほとんどこれに対応しているようです。

AFTは、HDD内部で1(物理)セクタ長を4096バイトと、従来(512バイト)の8倍の長さにしており、その分読み書きのオーバーヘッドが少なくなり、速度が上がることになります。また、HDDの外(PC本体)に対しては、従来通りの1セクタ512バイトのフリ(論理セクタ)をして命令やデータのやりとりをしています。HDDの物理セクタ長を大きくしながらも、それに対応しないPCにも合わせてあげることができます。

 

一方OSは、1セクタ512バイトとしてHDDを読み書きしながらも、効率化のため、ブロックやクラスタという単位で、複数の連続するセクタをひとまとめにして処理して効率化しています。Linuxならその単位はブロック(だいたい1ブロック=8セクタ=4096バイト)です。Windowsならクラスタ。

Linuxは、パーティションの開始(論理)セクタを起点にして、8(論理)セクタずつをブロックとするため、パーティションの開始位置が8セクタの倍数でないと、ブロックとHDD内部の物理セクタが互い違いになって、読み書きパフォーマンスが落ちることになります。

つまり、パーティションの開始セクタは必ず8の倍数セクタの位置にするよう、注意する必要があります。

自宅サーバはU-EFI非搭載。BIOSからGPTドライブを起動する特殊な方法が必要

拙宅の自宅サーバのスペックは以下。自宅サーバ外観。

  • OS : Vine Linux 6.1
  • CPU : Phenom2 x6 1065T
  • メモリ : 16GB
  • HD : 3TB x1 , 2TB x1 , 1TB x1 (システムドライブは2TB)
  • マザー:Giga-byte GA-880GA-UD3H Rev.2.2 (U-EFI非搭載)

BIOSでGPTディスクからLinuxを起動しなければならなくなります。 調べてみたところ、

ドライブの先頭から2TBの範囲内に、”bios-grub”フラグを付けた、1MB程度のパーティションを作れば、そこを介して起動できるようです。

ですが、もう少し調べてみないと、作業にかかれません。

次回へ続きます。

自宅サーバのシステムHDDセクタ異常発生につき、交換! 2TB→3TB LVM使用 fdisk→parted その1

先日の記事で報告したとおりまだ記事にはしていませんが、自宅サーバのシステムが入っているメインHDDがセクタエラーを出したため、念のためHDDを交換することにしました。

応急対処でエラーは出ていないんですが、この異常が出た後には同様の異常が頻発することが多いらしく、リスク回避をすることにしました。

#2013/10/11 朝10時 追記。
応急処置で、197 Current_Pending_Sectorが、1→0になっていましたが、

その後のHDD移行完了直後、3に増えていました
やっぱり197あたりが出始めたら、早めの対処が必須です。恐ろしい・・・(汗)

#2013/10/11 20時 追記。
197 Current_Pending_Sectorはその後、

  • 18時 に47個
  • 20時 で131個

に激増しています。まさに、「加速度的」。(大汗)
origin_4492113186

今回のHDD交換のポイント

  1. 2TBのMBRから、3TBのGPTへの移行交換。
  2. 旧ドライブに導入済みLVMを有効利用し、最大限のオンライン移行を試みる。
    物理的なHDD交換時以外はサーバを止めないことを目指す。

特に、2.に関しては、このブログを運用しているサーバでもあるので、できる限りオンラインで移行することを目指します。

ブログへのアクセスは大した数じゃないんですよ。ええ。
止まったからといって、影響は知れてますよ。はい。
大事なのは、気持ちですから。はい。
(ちなみに、10月に入ってからのアクセスは、50ページ/日くらいです。ロボット除く。)

交換用HDDが届いた

届いた新HDD。3TBです。 Seagate ST3000DM001/N。

届いた新HDD。3TBです。
Seagate ST3000DM001/N。

昨夜amazonに注文した、交換用の新HDDがさきほど届きました。

Seagate ST3000DM001/N です。10,781円。

  • 容量 : 3.0TB
  • インターフェース : SerialATA6.0Gbps
  • 回転数 : 7,200rpm
  • キャッシュ : 64MB

特にスペックにこだわりがあるわけでは無いんですが、お約束ということで。

もう2年間も売れ筋として名前と在庫が並ぶ

余談ですが、amazonの注文履歴を見てびっくり。この型番のHDD、今回で3台目の購入でした。それほど頻繁に買うものじゃないので、たいてい買うたびに新しいモデルが出ています。同じものを3台も買っていた印象がありませんでした。

  • 2012/3/25 14,780円
  • 2013/2/26 11,772円
  • 2013/10/9 10,781円

価格.comを見ると、発売が2011年11月です。既に発売から丸2年が経過しようとしているのに、売れ筋ランキング9位という高順位です。

現在のハイエンドクラスは4TBくらいで価格も高く、この容量は2番手ですが最もこなれた価格帯です。
以前と比べて、HDDの進化は鈍化したんでしょうかね。

3TBでも使い切れない量であることには変わりないんですが。

 

早速サーバをシャットダウン(1回目)し、HDDをサーバにセットし、念のため起動後以下のテストを実施。

smartctl -t long /dev/sdd

badblocks -vs -o sddbadblock /dev/sdd

どちらも異常セクタ、異常ブロック無しでした。

既に時間も遅くなったので、今日はここまでとします。

次の記事

WordPressブログ立ち上げ半月のアクセス状況

WordPressを立ち上げて半月。アクセスが・・・あった!

origin_5036291025ヨソさまからのアクセスなど、まっっっっっったく期待していなかったのですが、9/22ころからサイトへのアクセスが、ポツ・・・・ポツ・・・、と上がるようになってきました。

まだ、サイトの体裁が整っていないし、記事の内容・書き方も定まっていないので、正直恥ずかしいんですがね。

アクセス解析は3つの仕組みを導入しています。いろいろ比較して使い試す予定です。

  • Google Analytics
  • Visitors
  • Awstats

この3つです。

私にとってまだアクセス解析は必要ない(アクセスが無い!)のですが、後から経緯を分析するためにも、早めに導入だけしておこうという意図です。

世の中はGoogle Analytics花盛りですが、Analyticsがどの程度のものかもわからないので、Google以外の確認手段も自前で確保しておくことは今の私には意味あることと思っています。

で、期待せずに画面を見ていると、数日前からアクセスが増え始めています。と、いっても、1日2桁ですが。以下、Awstatsの画面キャプチャ。

9/8ブログ開始。ここ数日、アクセスの存在する日が続いている。 おお!

9/8ブログ開始。ここ数日、アクセスの存在する日が続いている。
おお!

 

滞在時間など、ほとんど無いようです。でも、

「来てくれてありがとう」

という気持ちになります。以上、足跡。

 

WordPressのテーマをカスタマイスしようと・・・HTML+CSSから勉強を始めてしまった

余談ではありますが、このブログ、WordPressで構築しました。最初は適当なテーマテンプレートを持ってきて、チョロチョロッとカスタマイズして済まそうと思っていました。

が、なかなか気に入るものがみつかりません。

今は暫定テーマで動かしています。

 

いろいろとテーマカスタマイズの方法を調べているうちに、お手軽に、見た目にそこそこのテーマに仕上げることは多分できる、という感触は持てました。

が、やはり、自分の気に入ったものにしようと思うと、細かいところに手を施せるスキルが不可避のように感じました。テーマのカスタマイズを初心者向けに解説するサイトや本も多いのですが、書いてあることすべてを理解できない自分がいることにも気づきます。

 

んで、せっかくなので、基礎から理解するアプローチを取ることにしました。

webの世界のすべての基礎である、HTML+CSSの基礎から、コツコツとやってみます。

私がHTMLのことを少しカジッたのは’90年代、MOSAICがあった頃でした。テキストエディタの文書のみでは表現力いまいちなのだけど、テキストファイル以上にいろんなデコレーションができて、しかもテキストエディタで作れてしまう、HTMLの出現に感動したものでした。

仕様を世界の皆が尊重し、HTMLコンテンツを作り、はたまたブラウザを作り、それがまた新たな可能性を生、このサイクルに感動したものでした。

とはいえ、HTMLの基本は理解したものの、いちいちタグを埋め込む面倒くささと、読む人の少なさから、それ以上は深入りしませんでした。

今でこそ、webは社会の要素として不可欠ですが、当時は社会的影響は「ゼロ」です。「インターネットって何?」の世界でしたから。今のように、センスのいいキレイなサイトなども、ほとんどありませんでした。

今、20年の月日を超え、HTMLを基礎から勉強し直している自分がいます。

こういうのって、けっこう楽しいですね。ワクワクします。

以上、読者のためではない、自分のための足跡日記でした。

 

WordPressのフォルダを、Windows Explorerで開けるようにする

ブログの執筆・投稿に集中できる環境を作りたい

origin_5036291025ブログを立ち上げてはや7日、ブログを書くことよりも、文書の整形に手間取ったり、ファイルを加工したりアップロードする作業に時間がかかったりで、効率的なブログ作成環境にはほど遠いです。

早く定型化して、楽にして、記事の内容を考えることにより多く時間を割きたいと思っています。

とはいえ、せっかくなので、効率化の作業そのものも記事にしていきます。

 

WordPressのコンテンツフォルダをWindowsのexplorerで直接操作したい(samba利用)

WordPressの作成環境を整えるにあたって、時々、WordPressをインストールしたフォルダを直接いじりたくなることがあります。(wp-config.phpが置いてあるディレクトリです)

PhotoPinで出てきた「samba」のイメージ。ちょっと違うな・・・

PhotoPinで出てきた「samba」のイメージ。まぁ、いいか・・・

wp-config.php を編集したり、favicon.icoファイルを配置してみたり、robots.txtを編集してみたり。

WindowsPCで調べ物をしていて、すぐにサーバで試してみたいことがあるときに、一々teratermを立ち上げてunixにログインし、ファイルをいじる、というのが面倒なので、explorerでアクセスできれば楽ちんです。

目的別にプラグインを探してダッシュボード経由で操作する方法もあるかと思いますが、いじれる手段を複数用意しても、損になるわけではありません。いろいろと可能性を追求していきます。

今回は、expolorerからsamba経由でファイルやディレクトリを直接操作し、ファイルの権限やユーザなどに矛盾を来さない環境構築を考えてみます。

下手するとファイルを消してしまうリスクは上がりますので、運用は慎重にしていくことになります。

自宅サーバ環境(前提)

  • OSはVine Linux 6.1
  • webサーバはapache
  • コンテンツフォルダ内ファイルの権限設定は原則700か600
  • sambaのセキュリティ設定は”user”
  • sambaサーバにはunixアカウントと同名のアカウント名を登録済み
  • webサーバのunixアカウント名はwebuser
  • ログインに用いるunixアカウント名はhoge

コンテンツフォルダでlsすると、こんな状態。

[root@localhost]# ls -al
drwx——  5 webuser webuser  4096  9月 15 12:00 ./
drwxr-xr-x 11 root   root    4096  9月  7 23:27 ../
-rw——-  1 webuser webuser  2924  9月 15 11:59 favicon.ico
-rw——-  1 webuser webuser    53  9月 14 23:48 googlexxxxxxxxxxxxxxxx.html
-rw——-  1 webuser webuser    53  9月 14 22:41 googleyyyyyyyyyyyyyyyy.html
-rw——-  1 webuser webuser   395  9月 14 14:57 index.php
-rw——-  1 webuser webuser 19929  9月 14 14:57 license.txt
-rw——-  1 webuser webuser  3081  9月 14 14:57 readme-ja.html
-rw——-  1 webuser webuser 10101  9月 14 14:57 readme.html
-rw——-  1 webuser webuser   717  9月 14 22:30 robots.txt

smb.confを一部示すと、こんな状態。

[global]
security = user
passdb backend = tdbsam
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = * %n\n * %n\n *
dos charset = cp932
unix charset = utf-8
display charset = utf-8
[homes]
・・・・

sambaに設定を追加(smb.conf)

通常利用するユーザ名hogeでログインし、コンテンツフォルダへの読み書きはwebuser名で行うように設定します。また、ログインできるunixユーザも、限定します。

smb.confに以下を追記。

[WordPress]
comment = WordPress
path = /wordpressコンテンツのパス
valid users = hoge     #wordpressフォルダにアクセスできるユーザを制限
read only = No     #書き込みOK
hosts allow = 192.168.1.0/24     #アクセス可能な端末をLAN内に限定。適宜。
force user = webuser     #コンテンツフォルダに書き込むときは、このユーザ名になる
force group = webuser     #コンテンツフォルダに書き込むときは、このユーザ名になる
create mask = 0600     #ファイル作成時は権限設定600強制
directory mask = 0700     #ディレクトリ作成時は権限設定700強制

で、できあがったsamba経由のフォルダの様子はこんな感じ↓

samba経由でwordpressコンテンツフォルダを表示

samba経由でwordpressコンテンツフォルダを表示

始めに接続するときは、ユーザhogeの認証を求められるかも知れません。

 

動作を確認する

試しに、samba経由のWordPressコンテンツフォルダに、ファイルを新規に作成してみます。

explorerでファイルを新規に作成

explorerでファイルを新規に作成

上のように、味も素っ気もないテキストファイルを作成しました。

自宅サーバにログインして、コマンドラインでlsで確認すると、以下の通り。

[root@localhost]# ls -al
drwx——  5 webuser webuser  4096  9月 15 13:10 ./
drwxr-xr-x 11 root   root    4096  9月  7 23:27 ../
-rw——-  1 webuser webuser  2924  9月 15 11:59 favicon.ico
中略
-rw——-  1 webuser webuser     0  9月 15 13:10 新しいテキスト ドキュメント.txt
[root@localhost]#

きちんと、正しいユーザ名(webuser)、権限(600)でファイルができたことが確認できました。

 

テキストエディタを選ぶ(おまけ)

テキストファイルは、windows系とunix系で、改行コードが違います。windowsのテキストエディタでunixのテキストファイルを編集すると、改行コードが変わってしまい、サーバの挙動が変わることがあります。

ご存知の方がほとんどだと思いますが、念のため。

  • Windows系の改行コード: CR+LF 2文字使ってます。
  • UNIX系の改行コード: LF
  • Macの改行コード: CR 持ってませんが、そうらしいです。

シェアウェアの秀丸エディタは、ファイルの中身を見てどちらの改行コードか判断して、設定を変えてくれます。

つまり、sambaの環境と秀丸エディタを使えば、explorerで開いたフォルダにあるテキストファイルを、何も考えずに開いて編集し、保存することができるようになります。

そういうテキストエディタは、今時探せばたくさん出てきそうですが、とりあえず私の知る一例として紹介しました。

large_928806031

WordPressの管理画面アクセスにSSL接続を強制する

origin_2985330439

 

サラリーマンである私は土日は基本的に仕事がお休みです。
先週このサイトを立ち上げたものの、平日はなかなか手を出せません。
その間、休日になったらやってみたい、ということがたくさん浮かんでいました。

これもその一つです。

 

WordPress管理画面のみへのSSL接続

WordPressの管理画面(wp-admin)には、自宅LAN内だけでなく、スマホや会社PCからもアクセスできるのですが、通常のHTTPアクセスで、ID、Passwordを送るのに抵抗を感じていました。
※会社PCからアクセス「できる」だけで、アクセス「している」わけではありません。念のため^^;

また、管理画面そのものも、基本的には自分だけしか見ることができない、本来非公開のものですので、暗号化無しのHTTP通信でやりとりするのは気持ちのよいものではありませんでした。

会社PCの場合、会社のFWで通信内容を記録していますので、何やってるかモロバレです。
※あくまで、会社PCからアクセスしたとしたら、です。

とはいえ、サイト全体をSSL化すると、通常のブログ閲覧でもSSL通信に対応することになり、サーバへの負荷が上がってしまいます。
※今は負荷を心配するような、大量なアクセスはありません。はい。念のため。

管理画面のみ、SSLアクセスを強制化するような設定が望ましいわけです。

 

管理画面SSL接続の設定方法は、WordPress公式サイトにありました

なんということでしょう。
ドンピシャ情報が公式サイトにありました。すばらしい。ここ。

2つのケースが紹介されていました。

  • SSLログインのみを強制する方法
  • SSLログイン・管理画面アクセスを強制する方法

私のニーズから、後者を選びます。

設定後の挙動を見るに、この設定によって「http://~」で管理画面にアクセスしてきたら、強制的に「https://~」に転送するというもののようです。

WordPress自身がSSLの証明書を作って、SSL通信を行うわけではなく、それはあくまでwebサーバの役割です。(当たり前ですが)

ですので、webサーバには、「https://~」で「wp-admin」ディレクトリにアクセスできるよう、VirtualHostなどを用いて、適切に設定されている必要があります。

SSLの証明書は、通称「オレオレ証明書」を使います。SSL接続するのは自分だけで、一般の閲覧者にはむしろSSL接続して欲しくないので、接続時に「この証明書は怪しい!」と警告が出た方がよいのです。

 

設定の流れ

設定の大まかな手順はこんな感じ。

  • wp-config.php へ、SSL強制の設定を追記
  • webサーバSSL設定、ファイヤーウォールへの設定(必要なら)
  • webサーバ再起動

基本的に上のwp-config.phpへの設定追記のみで、SSL接続強制されます。
webサーバには、HTTPからHTTPSへの転送する、Rewriteの設定は不要です。

ただし、webサーバではあらかじめ、https://~ のアクセスを受け付けられるように設定されていなければなりません。

 wp-config.phpへ追記

WordPressコンテンツのディレクトリトップにある、「wp-config.php」に以下の行を追加します。

define(‘FORCE_SSL_ADMIN‘, true);

管理画面はHTTP、ログインのみをSSL強制とする場合は次の一行となります。

define(‘FORCE_SSL_LOGIN‘, true);

ただしいずれも、wp-config.php内の、次の記述より上に書かなければなりません。

require_once(ABSPATH . ‘wp-settings.php’);

 

webサーバ(apache)のSSL設定

ブログサイトのディレクトリには、httpアクセスの設定しかしていませんでした。sslでもアクセスできるよう、設定を追加します。

—http.conf—一部抜粋

通常アクセス用の設定。変更無し。

<VirtualHost *:80>
ServerAdmin yyy@xxx.com
DocumentRoot /wordpressのコンテンツパス/
ServerName xxx.com:80
ErrorLog logs/wordpress-error_log ログファイル名、なんでもOK
TransferLog logs/wordpress-access_log ログファイル名、なんでもOK
<Directory />
AllowOverride None
</Directory>
</VirtualHost>

今回追加。同じディレクトリにSSL経由でアクセスさせる設定。

<VirtualHost *:443>
ServerAdmin yyy@xxx.com
DocumentRoot /wordpressのコンテンツパス/
ServerName xxx.com:443
ErrorLog logs/wordpress-admin-error_log ログファイル名、なんでもOK
TransferLog logs/wordpress-admin-access_log ログファイル名、なんでもOK

SSLEngine on
SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL
SSLCertificateFile /証明書配置パス/ssl.crt
SSLCertificateKeyFile /証明書配置パス/ssl.key
CustomLog logs/wordpress-admin-request_log \
“%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \”%r\” %b”
<Directory />
AllowOverride None
</Directory>
</VirtualHost>

—以上、httpd.conf抜粋—

 

SSL証明書の準備

httpd.confの設定にあった、

SSLCertificateFile /証明書配置パス/ssl.crt
SSLCertificateKeyFile /証明書配置パス/ssl.key

の2つの証明書を準備しなければなりません。

認証機関に認証してもらう証明書を利用すると、SSLアクセス時の警告が出なくなりますが、有料です。

オレオレ証明書を使ったときの警告。InternetExplorer画面。

オレオレ証明書を使ったときの警告。InternetExplorer画面。

希に無料の証明書を発行しているところもあります。参考までに。→StartCOMの無料証明書。
やり方はググったらたくさん出てきます。

冒頭にも書きましたが、今回はSSL利用者が自分のみであるため、また、一般の閲覧者にはむしろSSL接続して欲しくないので、「オレオレ証明書」を使います。

オレオレ証明書作成手順

オレオレ証明書は、第三者の認証のない、自分が自分を認証する証明書です。自分が利用するだけなら、これほど信頼のおける証明書はありません。:P

cd /証明書配置パス

$ openssl genrsa 2048 > ssl.key
Generating RSA private key, 2048 bit long modulus
………………………………………..+++
………..+++
e is 65537 (0x10001)

$ openssl req -new -key ssl.key > ssl.csr
いろいろと運営者の情報を聞いてくるので、適当に設定。

$ openssl x509 -days 3650 -req -signkey ssl.key < ssl.csr > ssl.crt
Signature ok
subject=/C=JP/ST=xxxx/L=xxxx/O=xxxx/OU=xxxx/CN=xxxx/emailAddress=yyy@xxx.com
Getting Private key

証明書有効期限は3650日(10年)です。

以上で、カレントパスに次の3ファイルができているはずです。

  • ssl.key
  • ssl.csr
  • ssl.crt

ssl.keyとssl.crtを、前段で設定したVirtualHostが参照します。

おわりに

webサーバの再起動と、ファイアーウォールやルータのtcp:443番を空けておくことをお忘れなく。

以上で設定完了です。
WordPress管理画面にアクセスしようとすると、自動的にHTTPSのSSL経由の通信に変更します。

これで安心して会社PCから外出先スマホからアクセスできます。

 

WordPressのバックアップの設定(MySQLのバックアップ)

WordPressの更新通知が来た

一昨日あたりかな? WordPressのダッシュボードにログインすると、更新通知が。

ダッシュボードにWordPressの更新通知が

ダッシュボードにWordPressの更新通知が

さっそく、アップデートしようとしたところ、


重要:
アップグレードの前に データベースとファイルをバックアップしてください。アップグレードについてヘルプが必要な際はWordPress のアップグレード Codex ページをご覧ください。

と警告が。ま、おっしゃるとおりです。
ブログのバックアップを取る仕組みを入れていませんでした。これから記事をため込んでいこうとしているのに、これは大事なことです。

更新時だけとはいわず、定期バックアップの仕組みを作り込もうと思います。
想像するにバックアップ復旧が必要なシーンを考えると、

  • サーバを再インストールするとき
  • ブログを移設するとき
  • ブログをうっかりミスで消してしまったとき
  • HDDが壊れてしまったとき

でしょうか。
HDDの回転音が異常になったり、bad sectorができたり、まったく読めなくなったり、というのは経験上、割と発生します。
1~3点目は、どこにバックアップを残しておこうが問題になりませんが、4点目を考慮すると、DBが入っているのとは物理的に別のHDDにバックアップを取っておいた方がよいと言えます。

また、ブログの更新頻度は多くても一日一回程度ですので、バックアップ頻度も一日一回程度とします。

他にも、遠隔サーバにバックアップしたり、ミラーサイトを作ったり、いろいろと方法はあるかと思いますが、今回は自宅サーバ内の別ディスクに、一日一回、バックアップを残すことを目指します。

さっそく公式サイトのlinkをたどった。

 

WordPressのバックアップの方法。

webアプリは使わずより低レベルなcronでやっとこう。

WordPressはMySQLにブログ記事を含めたサイトのデータを格納していますので、DBレベルのバックアップが必要です。(ファイル丸ごとコピーでは、DB壊れるかもしれません)

バックアップ対象はDB以外にもあります。phpの設定ファイルなどは、ファイルレベルのバックアップが必要です。私の環境ではすでに全ファイル日時バックアップを組み込んでいるのでそのまま利用します

ファイルのバックアップについては詳しくは書きませんが、バックアップはcron rsync の組み合わせでやっています。サーバ筐体内に物理的に別のHDDを追加し、一日一回、rsyncで丸ごとバックアップをとっています。

公式サイトのバックアップの説明サイトのリンクをたどったところ・・・

wordpressのバックアップ

公式サイトのwordpressのバックアップの説明

phpMyAdminというwebアプリ経由でのバックアップの説明がありました。

これ、インストールしていないです。また、これを使うとバックアップしたり、復旧したりするときに、このwebアプリが必要になると考えた方がよいのでしょう。(そうでない方法もあるかも知れませんが)

バックアップの復旧は低レベルの操作でできるに越したことはないし、何でもできる自宅サーバですので、cronで直接DBをバックアップする方法を取りたいと思います。

 

採用したMySQLのバックアップ方法と自動化設定

MySQLのバックアップをするためのコマンドは、mysqldumpです。これを使います。

以下の手順でバックアップを設定しました。

  • MySQL バックアップ専用ユーザ作成、権限設定
  • バックアップコマンドと動作確認
  • シェルスクリプト作成
  • cronへの組み込み

以下、手順詳細。

バックアップ専用ユーザ作成 (ユーザ名 backup)
[root@]# mysql -u root -p
mysql> grant select,file,lock tables,show view,event on *.* to backup@’localhost’ IDENTIFIED BY ‘パスワード’;
Query OK, 0 rows affected (0.00 sec)
mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
※SQLは大文字で書くらしいです。上は混ざっています。

コマンドラインでDBバックアップしてみる。(バックアップ先はmysql-all-db.sql)

[root@]# mysqldump -u backup -pパスワード –all-database –events > ./mysql-all-db.sql

スクリプト作成

バックアップ先のパス:/Backup/mysql_backup/
バックアップファイル名:mysql-all-db.tar.gz
としています。

バックアップ先(/Backup)は物理的に別のディスクをマウントしています。/Backupの権限は700。
lvmも使っていません。lvmを使っていると復旧が大変になる場合があります。

mysqldumpでバックアップを作成した後、tarで圧縮をかけて保存するようにしています。

—mysql_backup.sh—

#!/bin/sh
USER=”backup”
BPATH=”/Backup/mysql_backup/”
BFILE=”mysql-all-db.tar.gz”
PW=”パスワード”
mysqldump -u $USER -p$PW –all-database –events> $BPATHmysql.sql
mkdir -p $BPATH
tar cvzfP $BPATH$BFILE $BPATHmysql.sql >/var/log/mysql_backup.log
rm $BPATHmysql.sql
chmod 600 /var/log/mysql_backup.log

—mysql_backup.sh—

crontab登録

[root@]#crontab -e
30 12 * * * /パス/mysql_backup.sh
毎日12:30に起動します。

おわりに

これで、一日一回、別の物理ドライブにSQLのDBすべてをバックアップする環境が整いました。

実際には、テストDBなどを用いてバックアップからの復旧ができるか、確認をしておいた方がよいと思います。

参照サイト

参考にさせていただきました。ありがとうございます!