ブログ」カテゴリーアーカイブ

2014年8月の当ブログへのアクセス状況

今月も順調に伸びました

右肩上がり。中旬の不正アクセス対策でアクセス数が減りましたが、それでも純増でした。

右肩上がり。中旬の不正アクセス対策でアクセス数が減りましたが、それでも純増でした。

前月比で、訪問者数で3割増、訪問数とページビューで2割増でした。

コツはわかりません。(笑) 自分のペースで記事を書き続けているだけです。時々サボります。

8月中旬頃に、不正アクセス対策としてchaina unicomのIPアドレスをブロックした結果、アクセス数が3割は減ったのですが、それでもトータルで純増でした。

 

ところで、8/10と11に特異的にピークが現れています。

この日は、台風襲来で日本の多くの地域で風が強かった日です。

アクセスが増えたのは、当ブログの特定ページへのアクセスばかりでした。このページです。

みなさん、お困りだったようですね。^^

 

対策を打った不正アクセス

毎月このページばかり異様にアクセスが集中していて、ブログ内でのアクセス数トップでした。どのアクセスも、滞在時間は30秒以下。

大量のスパムコメント書き込みも、このページに集中していました。

スパムコメントのIPアドレスを調べ上げたところ、ほとんどが

36.248.*.*~36.251.*.*

の範囲でした。whoisで調べたところオーナーはChina Unicomでした。

他のページへのこのアドレス帯からのアクセスはほとんど無かったので、思い切ってこのアドレスからのアクセスを遮断したところ、そのページへのアクセスとスパムコメントがぴたりと止まりました。

実はもともと、google analyticsでは、このページへの異様なアクセスが記録されて折らず、手元のログと乖離がありました。この対策でこの乖離幅がグッと縮まりました。

 

対策に使ったのはWordPressプラグインの、

All In One WP Security

です。こいつの「Blacklist Manager」を利用しました。

ついでに、不正なログインを監視したり、様々な対策も同時に打つことができました。これはお勧めです。

 

webサーバがapacheの場合、httpd.conf内で

AllowOverride All

としておかないと、うまく動きません。

私のサーバではAllowOverride Noneとしていたため、プラグイン設定適用後にwebサーバが止まってしまい、めちゃめちゃ焦ってしまいました。

ご注意を。

2014年7月の当ブログへのアクセス状況

右肩上がりです

先月、平成26年(2014年)7月のアクセス状況です。

201407

おかげさまで、7月はアクセス数が大幅増でした。

過去も波打ちながらも右肩上がりです。ほんとに、こんな風に増えてくるとブログを続けてよかったなと思います。
(3,4ヶ月サボった時期もありましたが)

自宅サーバに仕掛けているアクセス解析ソフトAwstatsによると、
ブログを開始した昨年9月は、1ヶ月の訪問者数が235人。先月7月は7462人でした。11ヶ月で30倍となりました。

GoogleAnalyticsではそれぞれ、26人、3529人です。スパム的アクセスにフィルタが掛かっているっぽいです。(GoogleAnalyticsは複雑すぎて全部を理解できていません)

検索キーワードによってはgoogle検索結果の1位、2位に上がる記事もチラホラ出始めました。

当時は、ここまで読んでくださる方が増えるとは思っていませんでした。

なんというか、ますますブログを続ける意欲が沸いてきます。

というわけで、以上、不定期のアクセス状況報告でした。

最近(2014年5月)の当ブログのアクセス傾向

2014年5月の1ヶ月間で15839ページビュー

昨年2013年9月8日にこのブログを開始してから9ヶ月半が経過しました。

この間、ホントにマイペースで記事を更新してきました。こんなんでどれくらいの人が読んでくれるのかと自問自答しながら。

本業で頭がいっぱいで、何ヶ月かサボっていた時期もありました。

ですが、このブログを読んでくださる方は着実に増えてきておりました。
いままでお越しいただいたみなさん、ありがとうございます。嬉しいです。

過去のアクセス数推移の数値を一部ご紹介します。

画面は、フリーのアクセス解析ソフト「Awstats」です。

201405_awstats

2014年1月以降のアクセス数推移。 右肩上がりです。6月は横ばいになりそうですが。

201312_awstats

2013年中のアクセス数推移。2014年と比べて、グラフスケールが小さい(虫眼鏡で拡大しているようなもの)ですのでご注意を。

前回のアクセス数報告記事

ロボットのアクセス、LAN内からのアクセスは除いています。

ご覧の通り、

  • 2013年中は3ヶ月ほど横ばい
  • 2014年中は右肩上がり
  • 2014年3月から増加が加速
  • といっても、まだまだ絶対量が少ない

こんな傾向です。

3月、4月ころに、どの記事にアクセスがあったかを見てみたところ、「v6プラス」というインターネットプロバイダの特殊なサービスを紹介した記事へのアクセスが急増していました。

「v6プラス」は、普通にインターネットを使うだけの人にとってみれば、かなりマイナーかつマニアックなサービスです。こんな記事読む人そんなにいないだろうなー、と思いつつも、ネット上に情報が少なく私も苦労したので、知り得た情報を意識して少し多めに記事に上げていました。

今年の4月に、BIGLOBEが同サービスに対応することがプレスリリースされ、それ以降、この記事へのアクセス数がグンと増えたようです。

こういう、ネット上の情報が少ないネタの記事を上げておくと、突然アクセス数が増えるってことがあるんですね。

GoogleAdsenseの収益も、ほんの少しだけ増えています。といってもトータルで1000円少々ですが。(笑)

また最近は嬉しいことに、結構このブログが検索上位に上がって出てくるケースが増えてきました。最初の3ヶ月は全くほとんど鳴かず飛ばずでしたが・・・

ブログって、継続することが大事なのかも知れませんね。

アフィリエイト(Google Adsense)を導入してみました

ブログと言えばアフィリエイト

large_743970494ブログを始めた目的の一つに、アフィリエイトによる収入がどの程度のものか、検証することもありました。

ここ数年、ブログで食べている人が急激に増えているようで、本当に世の中変わったと思います。人が生きるための選択肢が増えるというのは、単純によいことだと思います。

また、サラリーマン一本人生に先行きの明るさを感じなくなってきていた私としても、非常に興味を持っていました。

ブログの収入というものがどんなものなのか、「実感として」知りたかったのです。

 

このブログを立ち上げたのが先月末。記事数はこの記事で20件目です。

アクセス数は30ページビュー/日くらいです。
テーマも絞れていないし、記事の蓄積が少ないし、積極的に呼び込みをしていないのでこんなもんかな、という感じですが、寂しいもんではあります。

それでも、googleさんさえ許可してくれれば、アフィリエイトを設置することはできるので、とりあえず、google adsenseをやってみることにしました。

 

申込みから広告開始まで

google adsenseは、ブログのhtmlにgoogleが指定するタグを埋め込むことで、googleが推薦する広告を出します。クリックすれば設置サイトの収入になります。

これの申請方法、設置方法などは、世の中に死ぬほど溢れているようですので、ここでは省略します。

2回の審査を経て、アフィリエイトが使えるようになります。
大まかな経過は以下。

  1. 10/27 20時ころ google adsenseを申し込む
  2. 10/27 23時  一次審査通過のメールあり
  3. すぐに広告タグを作って、ブログに貼り付ける→そのまま二次審査へ突入
  4. 10/29 01時 二次審査通過のメールあり
  5. 広告が表示され、課金開始

google adsenseを導入した他の方のブログも拝見しましたが、思ったよりもスムーズに行きました。

 

アフィリエイト設置から一晩経過したら・・・

そして、アフィリエイト開始後、日中時間帯を経過した今(10/29 21時)、アフィリエイトの状況を確認した結果が↓

アフィリエイト開始から19時間経過後のアフィリエイトの状況。 35円の売り上げ!!なんか、超ウレシイ!

アフィリエイト開始から19時間経過後のアフィリエイトの状況。
35円の売り上げ!!なんか、超ウレシイ!

なんと、既に35円の収益が上がっていました(見積ですが)。

たった35円。年間換算でもたった、12775円。

たったそれだけの、ごくごく、ささやかな売り上げなんですが・・・・

ものっすごく ウレシイ!!

子どもの頃から文章の読み書きが苦手だった私が、自分が書いた文章で、収入を得た瞬間! すごく不思議な気分です!

たった35円で、大きな感動を得ました。こんな感覚、本当にひさしぶりです。

 

今日は、ほんとうに気持ちのいい一日になりました。

 

アフィリエイト設置後の当ブログ画面を、記念コピペ。

アフィリ設置後の当ブログ。記念写真。w

アフィリ設置後の当ブログ。記念写真。w

 

ちなみに、ブログへのアクセス状況。寂しいもんですよ~。

20131029awstats

2013年9月のアクセス数推移

9月8日にブログを立ち上げ。9月のアクセス件数は927。

このブログ、9/8にブログを立ち上げましたが、このコンテンツでそれほどアクセスが伸びるとも思っていませんでした。

9/20を過ぎてポツポツとアクセスが記録されるようになりました。日別の推移はこんな感じ。

9/22以前のログはないけども、限りなく0でした。 ほんとに、これだけアクセスがあったことが信じられません。

9/22以前のログはないけども、限りなくゼロでした。
ほんとに、これだけアクセスがあったことが信じられません。

9/22に、apacheのログ設定をcommonからconbinedに変更しまし、より多くの情報を記録するよう変更しました。

commonでは情報が不足しており、一部ログ解析ソフトが対応していなかったため、9/22より前のcommonのログは解析対象から外しています。

当然ながら、LAN内のアクセスも除外しています。

アクセスしていただいた皆さま、ありがとうございました。

アクセス数が上がったこと自体、驚きではありますが、少ないことには変わりなく、まだまだ、ビジュアルも手直ししていきますし、揃えるべきコンテンツももう少し考えて変えていこうと思っています。

しばらくは、何をどうしたら、反応がどう変わるか、いろいろと試してみたいと思っています。

visitorsのツリーも置いときます。サイト内をどんな経路で移動されたかの記録です。

visitorsのツリー。 ほとんどのアクセスが検索サイトを経由していません。

visitorsのツリー。
ほとんどのアクセスが検索サイトを経由していません。

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などを用いてバックアップからの復旧ができるか、確認をしておいた方がよいと思います。

参照サイト

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

 

自宅サーバにblogのしくみ(WordPress)を導入

origin_5036291025昨日、このブログを開始したところですが、そもそもはどこかのブログサイト(Amebaのような)ではじめようかと考えていました。

自宅サーバを運用してはいるものの、回線はNTTフレッツ回線(フレッツ光ネクスト・マンション・光配線方式)で家庭・個人向けの品目ですし、サーバだって停電すれば止まってしまうようなシロモノだから、外部向けサービスなど考えてもいなかったからです。

とはいえ、所詮は個人用ですしそんなにアクセスが増えるとも思えず、当面は問題ないだろうし、問題が起こったらそのとき考えるということで自宅サーバに構築することとしました。ブログの仕組みの理解にも役立つと思いますしね。

自宅サーバのスペックは以下のとおり。

自宅サーバ外観。地震対策が大げさ(笑)

自宅サーバ外観。クランプは地震対策です。大げさ(笑)

  • OS : Vine Linux 6.1
  • CPU : Phenom2 x6 1065T
  • メモリ : 16GB
  • HD : 3TB x 1, 2TB x 1 , 1TB x1

 

これも年々、OSのバージョンを上げ、ハードも更新して今の姿です。

たしか初代はVine Linux 1.1、CPUはi486DX2 くらいのスペックだったと思います。VINEにはずっとお世話になってます。

無停止・連続運用というわけではないですが、もう10年以上生き続けています。

臓器移植で内蔵、肉体、脳みそを交換し、脳みその中の記憶までコピーして生き続けているという感じです。

テーマと関係ないですが、人間の思考や記憶が数値化して読み取れるとして、それをコピーした新しい個体は同一人物になってしまうのか、といろいろと考えてしまいます。社会的には区別がつかないんでしょうね。

ブログのwebアプリがどのようなものがあるか、かんたんにググって調べてみたところ、

  • WordPress
  • MovableType

あたりが出てきました。あまり選定に時間をかけるつもりはなかったので、検索結果が比較的多く、公式日本語サイトも充実していそうなWordPressを選びました。
(このブログを書いている最中に2つを比較した記事を見つけました。こちら。)

WordPress日本語ローカルサイトを訪れると、初期立ち上げまでの情報が一通り揃っていました。

インストールの手順は大まかに以下の通り。公式サイトからのリンク先にわかりやすくまとめてあります。ここをみながらインストールしました。


中段あたりに「5分間インストール」の文字が!

このサイトに記してあるとおりですが、大まかに以下の手順でのインストール作業となります。

  1. ダウンロード
  2. サーバ上で解凍
  3. MySQLのユーザとDB作成
  4. 設定ファイルの修正
  5. apacheのコンテンツ用ディレクトリに移動
  6. ブラウザでアクセスして初期設定
  7. 公開

30分程度で導入完了しました。普通に自宅サーバを構築・運用されている方なら、上記の公式サイト情報でかんたんに導入できると思います。

初期設定でユーザ登録すると、すぐにいきなりこんな、きれいな画面ができてしまいます。
ちょっとびっくり。ワクワク感が増します。

wordpress ダッシュボード

導入してみての感想ですが、動きも軽く、非常に使いやすい感じです。使い込めば不満な点も出てきて、結局HTMLソースを直接いじる、なんてことにもなるかもしれませんが、記録を残す目的では十分です。

また、プラグインが充実していて、スパム対策や、画像キャプチャの取り込みが楽になるツールなど、これらを使いこなすことで便利に使えそうです。

ブログを書く時間を最小にしたい、ものぐさな私にはよい仕組みと言えます。

動作が軽快だと言えば、それこそ10年ほど前に、PHPで動くwebmailを導入したことがありました。動くには動いたんですが、ブラウザでアクセスしてみると、表示が非常に遅く、ボタンをおしても反応や描画に数秒を要するという状態で、使い物にならなかった印象があります。

当時と比べればPCの処理能力が、CPUもメモリ速度もディスクアクセス速度も数百倍~千倍くらいの進化ですから、当たり前といえば当たり前なんですが、隔世の感です。

この記事を書く間にも、画像キャプチャの張り込みやパラグラフ、リストの成形などでいろいろと苦労しました。

楽にする方法を検索していましたが、やはりみなさん、同じようなところで苦労されているんですね。まだ、決定版、という方法が確立しているわけでは無さそうですし、細やかな加工をしようと思えば、HTMLソースをいじれるスキルは必須といった感じです。

有名ブロガーさんのページなどみていると非常に参考になりますね。これから勉強という感じです。
少し楽しみが増えた感じです。