リソース監視ツールのmuninは手軽に使えて素晴らしいのだが、監視対象のサーバが増えてくると集計サーバの負荷（主にディスクI/O）が馬鹿にならなくなってくる。そこでこちらのサイトを参考にして、データファイルとHTMLファイルをtmpfs上に移動してみた。

環境

• CentOS 6
• munin-1.4.5 (EPELリポジトリからインストール）
• メモリ: 8GB

データファイルとHTMLファイルの場所は /etc/munin/munin.conf の dbdir と htmldir で変更できる…はずなのだが、プラグインの中には /var/lib/munin のパスを決め打ちにしているものがあるらしく、dbdir を変更するとうまく動かなかった。仕方がないのでHTMLファイルを /var/lib/munin 以下に移動して、tmpfs を /var/lib/munin にマウントすることにした。

まずHTMLファイルを移動する。以下の操作はroot権限で、muninの集計を停止してから行う。

muninの集計を止めるには、munin-cronの実行権限を外すか、/etc/cron.d/munin を編集してcronによる定期実行を止める。

# munin-cronの停止
chmod ugo-x /usr/bin/munin-cron
 
# 念のためmuninプロセスが動いていないか確認しておく
ps aux | grep munin

次にHTMLファイルをディレクトリごとコピー、そのパスにあわせてmuninとApacheの設定を変更する。

cp -a /var/www/html/munin/ /var/lib/munin/html
 
vim /etc/munin/munin.conf
# htmldir /var/lib/munin/html
 
vim /etc/httpd/conf.d/munin.conf
# 私の環境ではcgiディレクトリは /var/www/munin/cgi に移してあるので
# ScriptAlias /munin/cgi/ /var/www/munin/cgi/
# Alias /munin/ /var/lib/munin/html/

ここまで終えたら一旦muninの集計を再開し、正しく動くことを確認しておく。確認できたら再び集計を停止して、tmpfsの設定に移る。tmpfsに割り当てる容量だが、とりあえず参考サイトに従って1GBとした。二十数サーバを数年間監視した結果のデータ+HTMLファイルが300MB弱だったので、1GBあれば当分は大丈夫だろう。

vim /etc/fstab
#tmpfs  /var/lib/munin  tmpfs  rw,size=1024M   0 0

一旦データを退避してから /var/lib/munin にtmpfsをマウントし、退避しておいたデータを戻す。

mv /var/lib/munin /var/lib/munin.backup
mkdir /var/lib/munin
mount /var/lib/munin
cp -a /var/lib/munin.backup/* /var/lib/munin/

これでmuninが更新するファイルは全てメモリ上に置かれることになった。が、このままだとマシンが再起動されるとデータが消滅してしまうので、バックアップ策を講じる必要がある。参考サイトではcronを使って1時間ごとにバックアップを行っているが、それだと更新中の不完全なデータがバックアップされる危険性がある。そもそもmuninの集計はcronで5分ごとに実行されるのだから、次のような方針でバックアップ/リストアをすることにした。

• 30分に一回、集計の「後に」データをバックアップする
• 毎回、集計の「前に」データの有無をチェックして、なければデータをリストアする。このチェックは単純にファイルの有無を調べるだけなので、5分ごとに実行しても負担にはならない

このためにmunin-cronをラップする次のようなシェルスクリプトを書いた。

#!/bin/sh
 
rsync=/usr/bin/rsync
munin_cron=/usr/bin/munin-cron
munin_dir=/var/lib/munin
backup_dir=/home/munin/backup
lock_file=/var/tmp/munin-cron-backup.lock
 
die() {
        echo $1
        exit 1
}
 
lock() {
        test -e $lock_file && die "Backup/retore process is already runnning" 
        touch $lock_file
}
 
unlock() {
        rm -f $lock_file
}
 
backup() {
        lock || die "Failed to lock the backup process"
        $rsync -au $munin_dir/ $backup_dir/
        unlock
}
 
restore() {
        lock || die "Failed to lock the restore process"
        if [ ! "(" -e $munin_dir/datafile -a -d $munin_dir/html ")" ]; then
                $rsync -au $backup_dir/ $munin_dir/
        fi
        unlock
}
 
restore
 
test -x $munin_cron && $munin_cron
 
if [ "$1" = "backup" ]; then
        backup
fi

このスクリプトでは datafile というファイルと html ディレクトリの存在をもって、「データが存在する」と判断する。一応、同時実行を避けるための簡易的なロックも付けてみた。5分に一回しか実行されないと分かっているのだから、この程度でも多少は意味があるだろう。各種コマンドやバックアップ先などのパスは好みで変えて欲しい。私はこのシェルスクリプトやバックアップを /home/munin 以下にまとめることにした。

あとはmunin-cronの代わりに、/etc/cron.d/munin の中でこのスクリプトを実行するよう設定する。30分に一回は引数に backup を与えて実行することで、バックアップが作成される。

MAILTO=root

0,30 * * * * munin /home/munin/bin/munin-cron.sh backup
5,10,15,20,25,35,40,45,50,55 * * * * munin /home/munin/bin/munin-cron.sh

リストアは集計前に勝手に行われるので、再起動しても何もしなくていい。

最後に実施前後のCPU使用率のグラフを載せておく。確かにI/O待ちはガクンと減った（ちょっとだけ出ているのはバックアップ）。

CPU使用率の変化

それから集計に要する時間も多少は短縮されたようだ。もっともネットワーク経由でクライアントに接続する部分がボトルネックになっているようなので、あまり結果は安定していない。

munin集計時間の変化

追記（11.10用） 下記の設定を行った状態で11.10にアップデートしたら無線LANが認識されなくなった。/etc/modprobe.d/blacklist.conf で次の1行をコメントアウトして再起動したら復活した。

#blacklist rt2800pci

…

ASUSのネットブックEee PC 1015PEMを買った。標準で入っていたWindows 7 Starterを使う気はさらさらなかったので、リカバリ領域をUSBメモリにバックアップした後、HDD丸ごと使ってUbuntuをインストールした。もうすぐ11.04が出るのだが、とりあえず10.10を選択。

1015PEMには光学ドライブはないのでインストールはUSBメモリから。手順はUbuntu公式の「Netbook」のダウンロードページに書いてある。まずWindowsでUniversal USB Installerをダウンロードして、次にUbuntu Japanese Teamのサイトから10.10 Desktop 日本語Remixのisoイメージを落とし、Universal USB Installerを起動してUSBメモリに書き込んだ。

あとはUSBメモリを刺して起動時にBIOSでboot deviceを指定、画面に従ってインストールするだけ。ちなみにこのときUSBメモリから直接起動して動作をテストすることもできるが、その動作は実際にインストールしたときの動作とは必ずしも一致しないことに注意。私の場合、この方法で起動すると無線LANが全く繋がらなかったり、日本語入力が使えなかったりした。

インストール自体は30分ほどで終了。早速無線LANに繋いでソフトウェアアップデートをかけるが、どうもネットワークの速度が遅い。pingを打ってみると30%〜ほどのパケットが欠落している。有線LANに繋ぎ変えると正常なので、明らかに無線LANがおかしい。Windows 7で使ったときには正常だったから、問題は無線LANアダプタのドライバだろうと当たりをつけて調査開始。

結論から言うと、次の操作を行うことで解消した：

/etc/modprobe.d/blacklist.conf に以下の内容を追記して、マシンを再起動。

blacklist rt2800pci
blacklist rt2800lib
blacklist rt2800usb
blacklist rt2x00usb
blacklist rt2x00pci
blacklist rt2x00lib

問題を解消するにあたってはこのページが非常に役に立った。

Ubuntu 10.04 LTS でEeePC 1015PEMで無線LANを使う(Ralink RT3090) – Ubuntuスタイル

まずlspciコマンドを実行してみると、確かにRaLink社のRT3090というアダプタが搭載されているのが確認できた。そこでRaLink社のサイトを見に行ったところ、Linux用のドライバが配布されていたので、早速「RT3090」用のファイルをダウンロードした。zipファイルを展開して中を見てみると、このドライバは「RT2860STA」という名称だと判明した。

ここでインストールする前に念のため lsmod | grep rt で現在読み込まれているドライバを確認してみたところ、既にrt2860staは読み込まれている、つまりUbuntu 10.10にデフォルトで含まれていたということが分かった。もしかしたらバージョンが古いのかとも思ったが、公式で配布されているドライバの更新日時からするとそれも考えにくい。

しかしさらに注意してlsmodの結果を見てみると、rt2800pciやrt2x00pciといったRaLink社の他のドライバも読み込まれていることに気づいた。これが悪さをしているのかもしれないと思い、このページに従って前述のとおりに /etc/modprove.d/blacklist.conf を修正し再起動したところ、問題は解消した。

なお以上はすべて10.10での話だが、この「一応は無線LANに繋がるが頻繁にパケットロスする」症状は11.04のUSBメモリから起動した時にも遭遇した。もしかすると11.04でも有効な手順かもしれない。

どのURLにアクセスされてもステータスコード503を返して /home/www/maintenance.html を表示する設定。

server {
    server_name  your.hostname; 
    error_page 503 /maintenance.html; 
    location / { 
        return 503;
    }
    location = /maintenance.html {
        root /home/www;
    }
}

同等の設定をApache(>=2.2)で書くと次のようになる。

<VirtualHost *:80>
    ServerName your.hostname
    DocumentRoot /home/www
 
    RewriteEngine On
    RewriteCond %{REQUEST_URI} !=/maintenance.html
    RewriteRule .* - [R=503]
 
    ErrorDocument 503 /maintenance.html
</VirtualHost>

CentOS 5.5にNginxをセットアップした記録。

EPELリポジトリにrpmパッケージもあるようだが、かなりバージョンが古かったので（0.6.39）ソースからインストールすることにした。現時点での最新版（stable）は0.8.53。

まず下準備。nginxユーザの追加とビルドに必要なパッケージのインストール。

sudo useradd -s /sbin/nologin -d /usr/local/nginx -M nginx
sudo yum install gcc openssl-devel pcre-devel zlib-devel

続いてソースをダウンロードしてコンパイルする。Nginxはコンパイル時にしか拡張モジュールの組み込みができないので、ビルドの過程はシェルスクリプトの形で残しておいた方が良い。コンパイルオプションについてはWikiを参照のこと。一番下のExample 5（RedHat向け）を参考に調整を行った。

#!/bin/sh
 
NGINX=nginx-0.8.53
 
# インストール先は /usr/local/nginx になる
cd $NGINX \
&& make clean \
&& ./configure \
  --conf-path=/etc/nginx/nginx.conf \
  --error-log-path=/var/log/nginx/error.log \
  --pid-path=/var/run/nginx/nginx.pid  \
  --lock-path=/var/lock/nginx.lock \
  --user=nginx \
  --group=nginx \
  --with-http_stub_status_module \
  --with-http_ssl_module \
  --with-http_gzip_static_module \
  --with-http_realip_module \
  --http-log-path=/var/log/nginx/access.log \
  --http-client-body-temp-path=/var/tmp/nginx/client/ \
  --http-proxy-temp-path=/var/tmp/nginx/proxy/ \
  --http-fastcgi-temp-path=/var/tmp/nginx/fcgi/ \
&& make

正常にビルドが完了したらインストール。足りないディレクトリも作っておく。

sudo make install
sudo mkdir /var/tmp/nginx/{proxy,client,fcgi}

この段階で正常に起動するかどうかを確認しておく。rootで ${prefix}/sbin/nginx を実行後、http://hostname/ にアクセスして、「Welcome to nginx!」と表示されたらOK。

sudo /usr/local/nginx/sbin/nginx
 
# 確認できたら終了しておく
sudo /usr/local/nginx/sbin/nginx -s quit

この後、設定ファイル（上のコンパイルオプションの場合は /etc/nginx/nginx.conf）を編集してサーバの設定を行うことになるが、そこは省略。

サービス起動ファイルを作る。CentOS(RedHat系Linux)ならひな形がWikiに用意されているので、必要な部分を書き換えた後 /etc/init.d/nginx に保存して、 chkconfig コマンドで設定する。

# 実行ファイルのパスなど変更しておく
vi /etc/init.d/nginx
 
chmod 755 /etc/init.d/nginx
chkconfig --add nginx
chkconfig nginx on
 
# 今すぐ起動するなら
service nginx start

続いてログのローテーションの設定。/etc/logrotate.d/nginx を以下の内容で作成する。パスやパラメータは各自で調整のこと。

/var/log/nginx/*log {
    missingok
    notifempty
    delaycompress
    sharedscripts
    postrotate
        /usr/local/nginx/sbin/nginx -s reopen
    endscript
}

設定ファイルのチェックも行っておく。

sudo logrotate -d /etc/logrotate.conf

設定ファイルの内容について後で書くかも。

症状：

iPhone 3GSをiOS4にアップデートして以来、バッテリーの減りが異常に早くなった。

原因：

（多分）スリープ中もWi-Fiが有効になる状態だったから。

解決策：

（私の場合）スリープボタン+ホームボタン長押しで強制リセットしたら直った。

去年12月に買ったiPhone 3GS。以前は2日充電しなくても余裕があったのに、iOS4にアップデートして以来、1日放置しておくだけで残り15%近くまでバッテリーを消耗する状態になった。「iOS4 バッテリー」というキーワードで検索してみると、同様の症状を訴える人はたくさんいる。中でも『iOS4ではスリープ中でもWi-Fiがオフにならず、そのせいでバッテリーを早く消耗する』という情報が気になった。言われてみれば、iOS4にして以来、スリープから復帰させる時にWi-Fiのシグナルがいつも立っている。以前なら0.5秒〜1秒くらいの間があって「3G」→「Wi-Fiシグナル」と表示が切り替わっていたのに。

しかし特に問題がない人も多いところを見ると、これがiOS4の正規の挙動なのかどうかは怪しい。とりあえずものは試しと、買ってから初めて強制リセットを試してみた。方法は右上のスリープ/スリープ解除ボタンとホームボタンを押し続け、「電源オフ」のスライダが出ても押し続け、画面が暗転して銀色のリンゴが出てくるまで待つ。…すると何かの設定がリセットされたのか、Wi-Fiの挙動が以前の状態に戻り、バッテリーの異常な消耗も解消された。

必ずこの方法で復旧するとは言い切れないが、同様の問題で悩んでいる方は一度試してみると良いかと。

DB内のMEMORYテーブルのサイズを、テーブルごとにグラフ化するための munin プラグインを作ってみました。

mysql_memory_tables_

インストール

munin-node 本体のプラグインディレクトリ（/usr/share/munin/plugins など）にコピーしてください。

設定

ワイルドカードプラグインなので、mysql_memory_tables_{チェック対象となるDB名} という名前でシンボリックリンクを張ってください。

ln -s /usr/share/munin/plugins/mysql_memory_tables_ /etc/munin/plugins/mysql_memory_tables_db1

データを取得するには対象DBの INFORMATION_SCHEMA にアクセスする権限が必要です。プラグイン設定ファイル（/etc/munin/plugin-conf.d/munin-node など）で mysql コマンドに渡すユーザ名・パスワードを指定してください。

[mysql_memory_tables_*]
env.mysqlopts -u cicindela --password=hogehoge

動作確認

munin-run コマンドでテストができます。

# 値の表示
munin-run mysql_memory_tables_db1
 
# グラフ設定情報の表示
munin-run mysql_memory_tables_db1 config

動作が確認できたら munin-node を再起動してください。

Software RAID1を組んでいるサーバで、CentOS 5.3 -> 5.4にアップグレードしたところ、週末ごとに次のような警告メールが届くようになった。

/etc/cron.weekly/99-raid-check:

WARNING: mismatch_cnt is not 0 on /dev/md0

/proc/mdstat 等には特に異常などは見当たらないし、構成の異なる複数のサーバで同じ現象が起こったので、ハード的な問題ではないだろうと判断し、忙しかったこともあってそのままにしていた。しかしやはり気持ち悪いので、きちんと調べてみた。

メール中にある通り、この警告は /etc/cron.weekly/99-raid-check というスクリプトから送信されている。このスクリプトを提供しているのは mdadm パッケージで、5.4で更新されている。更新内容はレッドハットのサイトで RHBA-2009:1382-1 として提供されており、99-raid-check について説明しているのは、次の2箇所である。

* LinuxのソフトウェアRAIDスタックでは、データスクラビングがサポートされています（RAIDアレイのディスクを読み取って不良セクタを検索し、不良セクタが見つかると、他のディスクやパリティの情報を使用して、不良セクタを正常なデータで書き直します）。しかし、mdadmパッケージはこの機能を利用していませんでした。今回のパッケージは、cronジョブが/etc/cron.weeklyに追加されており、ディスクをチェックして不良セクタがないかどうかを確認し、見つかった場合は修復します。（BZ#233972）

* 今回のアップデートでは、mdadmに冗長アレイでの「データスクラビング」を可能にする新しい機能が追加されています。データスクラビングでは、冗長アレイ内のドライブ上で不良セクタが検索され、見つかった場合は他のドライブのデータを使用して修正されます。それによって、読み取りエラーを返すセクタは再構築されます。注：この新しいパッケージでは、データスクラビングはデフォルトでオンになっています。この機能は週1回実行され、実行中にある程度のパフォーマンス低下を引き起こす場合があります。パフォーマンス上の理由でこの機能を無効にしたい場合、アレイに対して実行されるチェックのタイプを管理したい場合、あるいは、どのアレイをチェックするかを制御したい場合は、/etc/sysconfig/raid-checkファイルを編集します。オプションを設定する方法の詳細は、そのファイルにコメントとして含まれています。（BZ#513200）

「データスクライピング（Data Scrubbing）」とは何か、なぜ重要なのかについては、ここで示されているBugzilla #233972およびその先のリンクに説明がある（一箇所リンクが切れているのはRAID/Software – GEntoo Linux Wikiだと思われる）。

データスクライピングを実行するには、root権限で次のコマンドを実行する。これによって不良セクタが検出され、自動的に修復される。99-raid-check が実行するのも、まさにこのコマンドである（少なくともデフォルトの設定においては）。

echo check > /sys/block/mdX/md/sync_action

ではこのコマンドと、問題の mismatch_cnt とはどう関係するのか。/etc/sysconfig/raid-check のコメントを読むと次のように書いてある。

If it finds good sectors that contain bad data (meaning that the data in a sector does not agree with what the data from another disk indicates the data should be, for example the parity block + the other data blocks would cause us to think that this data block is incorrect), then it does nothing but increments the counter in the file /sys/block/$dev/md/mismatch_count.

つまりセクタ自体は正常だが、中に入ってるデータがディスク間で異なる場合に mismatch_cnt が増加するということらしい。

ならば mismatch_cnt が 0 でないということは、ただちにRAIDが正常に機能していないことを意味するのだろうか？いろいろなMLの投稿などを読む限り、少なくとも swap パーティションを含むRAIDデバイスにおいては、全く正常であっても各ディスク間の内容が異なり得る…すなわち mismatch_cnt が0でないことがあり得るようだ。では swap を含まないパーティションの場合は？私の（また他のCentOS利用者の）ように、/boot のみを含む md0 の場合は？……これがよく分からない。この投稿を読む限り、ある種の状況においてはそうしたことも起こり得る、とのことである。

もしそうした状況に該当するなら。mismatch_cnt が 0 でなくとも、異なっているのは実際にはファイルシステムからアクセス不能な部分であって、システムの運用には影響しないのであれば。修復する方法はある。check の代わりに repair を使うことである。

#このコマンドを実行する前に以下の説明をよく読んでください！！
echo repair > /sys/block/mdX/md/sync_action

ただし /etc/sysconfig/raid-check には、次のような恐ろしいコメントが書いてある（強調は私による）。

The repair option does the same thing, but when it encounters a mismatch in the data, it automatically updates the data to be consistent. However, since we really don’t know whether it’s the parity or the data block that’s correct (or which data block in the case of raid1), it’s luck of the draw whether or not the user gets the right data instead of the bad data.

というわけで、以下は「それでも自己責任でこの方法に賭けるぜ！」という方のみ読んでください。

まず各デバイスの mismatch_cnt の値をチェックしておく。

cat /sys/block/md0/md/mismatch_cnt

そして repair を実行する。

sudo sh -c 'echo repair > /sys/block/md0/md/sync_action'

進行状況は /proc/mdstat で確認できる。

cat /proc/mdstat

repair を実行しただけでは mismatch_cnt は更新されないので、もう一度 check を実行する。進行状況はやはり /proc/mdstat で確認できる。

sudo sh -c 'echo check > /sys/block/md0/md/sync_action'

終了したら mismatch_cnt をチェックして、0 になっているか確認する。

cat /sys/block/md0/md/mismatch_cnt

……

参考にしたサイトははてブの mismatch_cnt タグにまとめてあるので、この記事に書いてあることを鵜呑みにせず、自分で調べ自分で判断するようお願いします。

16GBモデルで15000円弱。同容量のiPod nanoより2000円ほど安い。その安さに惹かれて購入したのだが、良い意味で驚かされた。それまで使っていた二世代前のiPodに比べて、圧倒的に音が良い。同じイヤホン（MDR-EX90SL）、同じ音源（mp3やAAC）なのに、全く違って聞こえる。さすがに最近のiPodならもう少し差は縮まるのかも知れないが、個人的にはもうiPodに戻ろうとは思わない。

私は初代からのiPodユーザなので、iPodシリーズとはかれこれ8年近い付き合いになる。その間にも、実はiPodの音を疑ったことは何度かあった。曲によってはっきりと不快に感じることすらあった。その度にイヤホンが悪いのか音源が悪いのかと疑い、iPod本体に目を向けることはなかった。iPodに代わる選択肢は事実上存在しない状況だったので、iPodを疑っても仕方がなかったのだ。でもついにはっきりと現実を認識する時が来てしまった。高音の歪みが不快で仕方なかったあの曲を、NW-S645は見事に奏でてくれた。iPodは、音が悪かったのだ……。

回顧はこのくらいにして、少し真面目なレビューを。

曲の転送

NW-S645は「ドラッグ＆ドロップ転送」に対応しているので、サポート対象外だがWindows以外でも使える。私の母艦であるMacBook Proに接続すると普通のUSBストレージとして認識された。ボリューム名は「WALKMAN」。中に MUSIC というディレクトリあるので、そこにコピーすればあとは勝手にアーティスト名やアルバム名のデータベースを構築してくれる（コピーしたディレクトリ単位で再生することもできる）。またiTunes Storeから購入した曲（PlusなどDRMがかかっていないもの）を転送すると、アートワークも正常に反映された。しかしiTunes上で後から割り当てたものについては反映されないようだ。

これは私の環境だけかも知れないが、取り外す際にちょっとしたトラブルがあった。Finderの取り外しアイコンをクリックすると一旦は接続解除されるのだが、すぐにまた接続が開始されてしまうのだ。結局「解除した瞬間にUSBケーブルを引っこ抜く」という、なんともいい加減な方法で対処することにした。

操作性

操作性はすこぶる良い。ほとんど何の不満も無い。iPodより使いやすいと思う。というか、これも比較して初めてはっきり認識できたことだが、iPodのタッチホイールによるUIは、別に使いやすくはなかった。例えば曲の再生方法（リピートやシャッフル）を変更したいとき、iPodだといちいちトップメニューまで戻って「設定」から変更する必要があったが、NW-S645は「OPTION」ボタンから即座に変更できる。曲を選ぶ時のカーソルの移動速度はホイールにはかなわないが、左右ボタンでA-Zあ-わ移動ができるので問題ない。全体として、よく考えられた作りになっていると思う。

その他

本体デザインは金属やガラスの質感が美しく、iPod nanoほどエレガントではないものの、とてもカッコいい。液晶も綺麗で見やすい。ACアダプタが別売りなことには面食らったが、そもそもバッテリの持ちが非常に良いのであまり問題にならない（実はiPodのものが流用できそう？）。

追記：音質について

ピアノやヴァイオリンなどの比較的静かな曲だとそのままでも素晴らしい音が出るのだが、JPOPなどの賑やかな曲だとボーカルが埋没してしまって、ひどくアンバランスに聞こえることがある。そういうときはイコライザを「ポップス」あたりに変更してやれば、見違えるような（聞き違えるような？）音になる。イコライザもOPTIONボタンから簡単に切り替えられるので、いろいろ試してみると面白い。

XREAが重過ぎて使い物にならなくなったので、エックスサーバーに移転した。ここを選んだ理由は

• PHP5, MySQL5が使える
• 比較的値段が安い（X10プランで月額1050〜1260円）
• ネット上の口コミでは速度に対する評価が高い
• “ハズレ”を引いたときの救済措置簡単サーバ移動機能がある
• SSHが使えないので、派手なことをするヤツは少ないだろうという希望的観測

今のところ速度には満足。サーバの管理画面も使いやすい（若干パワーユーザ向けだが）。WordPressも問題なく移転できた。

WordPressの移転にはいろいろな方法があるようなので、私の方法も紹介しておく。最も原始的かつ確実な方法で行った。

エックスサーバーでの下準備

1. 管理画面「MySQL設定」で新しいMySQLデータベースとMySQLユーザを作る
2. 「ドメイン設定」で独自ドメインを登録する
3. できればここで /etc/hosts ファイルを書き換えてきちんとアクセスできることを確認しておく。WebサーバのIPアドレスは「DNSレコード設定」で確認できる

旧データのバックアップと修正

1. XREAの管理画面「データベース」で「保存」ボタンを押してバックアップを作成する
2. 作成されたmysql.dumpおよびサイトの全ファイルをローカルにコピーする
3. wp-config.php を開き、データベース設定をエックスサーバーのものに書き換える

エックスサーバーにアップロード

1. 管理画面からphpMyAdminにログインして、mysql.dumpを実行
2. ドキュメントルートに全ファイルをコピー
3. 例によって /etc/hosts を書き換え、WordPressが正常に動くことを確認

あとはDNSを変更すればOK。

http://twitter.com/serpere

「フォローしないと面白くない」とは聞いていたので、とりあえず登録時におすすめされた有名人アカウントを半分くらい、それから購読しているブログの中でアカウントがすぐ判明した何人かをフォローして開始。

当たり前だが、まださっぱり面白さが分からない。混雑したファミレスの中で、他テーブルの雑談を聞くともなしに聞きながら独り言をつぶやいているような、ものすごい違和感。でもそういう雑談に思わず心の中で突っ込みを入れてしまうことがあるように、@xxx で突っ込みを入れていけば面白くなってくる…のだろうか？

会話のための会話を楽しめる人向けというか、ある意味では最も純粋なコミュニケーション・ツールという気もする。当面はひたすらフォローする人を増やしながら様子を見ていこう。