月: 2012年3月

これまでプライバシー・ポリシーとは団体・組織が取り扱う個人情報をどう会員や顧客に不利益を与えない形で処理するかを定めておけばよかったかもしれない。その対象は送られてくる質問、メールや電話、FAX、注文データなどの取り扱いをしっかりしておくということ。厳密に言えば当然Webのアクセス記録やメールのやりとりを記録したサーバーログもそこに入るが、しっかりと運用していれば外部に漏れることはないものだった。

しかし、インターネット上の急激な認証化の動き（具体的にはFacebookやGoogleなどが実名での登録を要求し、その登録規模がかつてないほどの大きなものになったこと）に伴って、その対応も変えざるをえなくなってきている。

たとえば、Webアクセス解析はGoogle Analyticsなどのサービスを使っていれば、誰がどのページを見ている、という情報は自社内で管理はできずに、Google上で把握されてしまう。本来、誰が見ているという情報の部分は追わないというのがあるべきプライバシー・ポリシーであったはずだが、GoogleアカウントやFacebookアカウントと結びつけられることで把握されてしまう可能性は飛躍的に高まっている。

それ以上にFacebookなどとWebサイトを結びつけると逆にこのサイトを支持する、という形で自らを晒していく動きが大きくなっている。これは自分の意志でやっていくわけであり、積極的にこうした人たちと結びついていくことで、その組織の存在が身近に感じられるという効果もあり、今後の大きなトレンドになっていくだろう。正の側面が語られることが多いが、負の側面がないかどうか、今後の議論には十分注目する必要があるだろう。

一方、Google Analyticsなどによって、本人が知らない間に閲覧記録が取られてしまうという問題は検討すべき課題として大きくなっている。

Google Analyticsは無料で提供され、その機能も高く、さまざまなガイドブックも売られているので、トレーニングの負荷も低く、多くの団体で使われている。ユーザーの側でGoogleにアクセス記録を取られないように防御する方法がないわけではないが、基本的にほぼすべての人のアクセス記録はGoogleのデータとして保存される。

これに関してはオープンソースのアクセス解析を使うことで解決することは可能だ。オープンソースのアクセス解析のPiwikは直感的にわかりやすいインターフェースで完成度も高い。しかも、訪問者のオプトアウトも確保しているなど、プライバシーに関する配慮も高い。

問題としてはGoogle Analyticsは日々システムが更新され、新しくなっていくのに対して、オープンソースのシステムは管理者がアップデートしない限り、更新されないこと。またGoogleと基本は同じなので、知っている人にとってはトレーニング不要だけど初心者向けのマニュアルがあるわけではないこと。しかし、後者の問題はPiwikのインターフェースが直感的に理解可能で、Googleのものとほぼ同様に使えるという点で、大きな問題ではない。

プライバシー概念が大きく変わっている中、あるべきプライバシー・ポリシーを確定することは容易ではない。
しかし、楽だからという理由だけでGoogleを使い続けることが許されるか一度考える必要があるだろう。

Piwikをインストールしてみたが、完成度はかなり高く感じた。アクセスがあった地域の情報は国単位ではなく、やはりもっと細かい行政単位で情報が必要だろうが、それはGeoIPのエクステンションをインストールすることで可能（なお、パフォーマンスが要求される環境ではGeoIPのApacheのモジュールをインストールすることが望ましいようだ。今回は省略。詳しくはMod_GeoIP）。

サーバーに１つインストールすれば複数の異なるサイトを解析できて、しかもユーザー権限も個別に設定できるなど、便利である。使い込んでみるともっと別の評価が出てくるかもしれないけれども。

TwitterやFacebookのように時系列にデータが並ぶメディアだと大事な情報が過去に流れてしまうので時系列ではない情報の受け皿としてMediawiki（Wikipediaのエンジンのオープンソース版）でやろうと考えた。

しかし、Wikiの文法はくせがある。それをうまく意識しなくて使えるようにしてくれるオンラインエディター(WYSWYGエディター）、FCKeditorを組み合わせればかなり使いやすくなる。

ところがもうこのFCKeditor（CKeditor）のextensionはメンテナンスされておらず、古いextensionは現在のバージョンのMediaWikiでは使えないことがわかった。PHP 5.3へのアップデートあたりの問題が絡んでいるのだろうか。FCKeditorなしのWikiだと使ってもらうのはかなり難しいと思う。

他にもオンラインエディターはあるのだけど、どうも使い物にならない感触。この状況ではMediawiki自身のオルタナティブを考えないといけないかもしれない。でもあのやさしくはないWikiで作れたWikipedia、よくみんな書いていると関心してしまう。

Wikiにこだわらず、WordPressなどのstaticページを使うのも手かもしれないし、その他に使えるものとかあるだろうか？

結局、FacebookとかTwitterしか使ったことのない人に使ってもらえるものと考えるとMediaWikiはきつい。情報オタクにはいいかもしれないけれども。
MindTouchは使いやすそう。ただ、気になるのはオープンソースとして提供されてはいるものの、企業の展開に左右されそう。将来にもオープンソースとして使い続けることができる確実性はMediaWikiの方が上か。

正直言って困っている。何かいいアイデアあったら教えてください。

サーバーのバックアップは悩むところだ。公共性の高い、保存価値の高いWebサイトの管理をしていて、もしそのデータが失われてしまったら、とてもまずい。

以前であれば異なる場所にあるサーバー間で重要なファイルを相互にバックアップさせておけばどれかのサーバーがクラッシュしても、重要なデータは失わない、という形でとりあえず十分と思っていたけれども、たとえば自分が急病や事故で動けない状態になった時にアウトになってしまう。不正侵入を防ぐために特定のIPアドレス以外からはサーバーにはログインできないように防御しているので、逆にそれが仇になってデータが取り出せなくなる危惧がある。

高価なバックアップ装置を買ったとしても火事でサーバーごと焼けたらおしまい。またバックアップできていると思って確認したらこわれていて取れていなかった、というケースも結構ある。

そのような場合、またクラウド企業の出番になってしまうのだけど他に解がないので、またもやDropboxを使う。

DropboxはLinuxサーバー上でも使えるのでLinuxサーバーにインストールする手もあるが、常に常駐させておくとメモリー使用量も大きいし、バックアップを毎時やるのでなければ常駐させておくのはエネルギー効率が悪い。

アップデートする時だけ常駐させ、アップデート終了したら終了させるシェルスクリプトを書けばいいかと思っていたら、こんなのがあった。Dropbox Uploader …curlさえ入っていれば動くBashスクリプト。Dropboxをインストールする必要すらない。

まずはバックアップの準備。

#!/bin/sh
tar -C / -czf /バックアップディレクトリ/wwwdata.tar var/www/(backuptarget)
mysqldump -u ユーザーID -pパスワード -x データベース名 | gzip >
/(backupdir)/db.mysql.dump.gz

これでバックアップ対象のHTMLファイルとデータベースがバックアップディレクトリに２つのファイルに保存される。

#!/bin/sh
TODAY=`date '+%d'`
cp /(backupdir)/wwwdata.tar /(backupdir_history)/wwwdata.$TODAY.tar
cp /(backupdir)/db.mysql.dump.gz /(backupdir_history)/db.msql.dump.$TODAY.gz

これでバックアップディレクトリ履歴のディレクトリに www.日付け.tarなどの形式で保存される。以前の状態のデータも1月は保存される（ディスクに容量がなければこの部分は省いてもいいかもしれない）。これはローカルのディスク上でだけ保存して、Dropboxには入れない（容量制限を考えて）。Dropboxには最新ファイルだけ入れる（これだと最新ファイルが壊れていたりすれば終わりなのでもう少し工夫した方がいいかもしれないが）。

#!/bin/sh
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/db.mysql.dump.gz
echo パスワード | gpg --passphrase-fd 0 --batch -c
/(backupdir)/wwwdata.tar
mv /(backupdir)/*.gpg /Dropboxに同期させるディレクトリ

これで設定したパスワードでgpgを使って暗号化される。gpgはLinux版だけでなく、Mac版やWindows版もあるので、どんな環境でもパスワードさえわかれば元のファイルに戻すことが可能。暗号化も不要という場合はこのプロセスも省略可能。

あとは、Dropboxのアカウントを作っておき、curlが入っていればdropbox_uploader.shをコピーして実行する。

シェル上で、./dropbox_uploader.sh と打つと、

This is the first time you run this script.
 Please open this URL from your Browser, and access using your account:

 -> https://www2.dropbox.com/developers/apps

 If you haven't already done, click "Create an App" and fill in the
 form with the following data:

  App name: MyUploader2*********
  Description: What do you want...
  Access level: Full Dropbox

 Now, click on the "Create" button.

 When your new App is successfully created, please insert the
 App Key and App Secret:

 # App key: 

と聞いてくる。シェルを離れて、ブラウザで https://www2.dropbox.com/developers/apps にアクセスし、”I agree with the Dropbox Developer terms and conditions.” をチェックして、Submitボタンを押すと、App name: を聞いてくるので上記のMyUploader2***….をコピーして入れて、Descriptionには自分のサーバーのバックアップだということがわかる文章を入れ、Access levelの選択をFull Dropboxの選択をする。そうすると、App key と App secretを表示するので、それをシェルに戻り、入力する。そうするとシェルの方で、
https://www2.dropbox.com/1/oauth/authorize?oauth_token=********
にアクセスしてAppをDropbox側で承認するように求められるので、ブラウザ上でこのURIを開く。承認ボタンを押せば、設定終了。

あとはとっても簡単

sh dropbox_uploader.sh upload ./Dropbox/*

これでDropboxに保存される。

上記のスクリプトを適当に作って、crontabに登録し、毎朝3時とかサーバー負荷が低いと思われる時に自動実行するように設定しておけばいい。

この方法の助かることはバックアップが無事行われているかオンラインであればどこでもチェックができる（サーバーに装着されたバックアップ装置のチェックよりもはるかに楽）。

もっともバックアップされたファイルの内容が想定している状態になっているかはファイルをダウンロードして確認することは必要だろうけれども。

あとは自分以外でサーバー管理できる人とパスワード情報を共有する必要がある。問題は共有してもサーバーを復元することのできる人がそういないことかもしれない。ただ、できる人が見つかればサイトは復元できるはず。