Internetの最近のブログ記事

今後もまた引っ越すかもしれないことだし、自分の備忘録のため、XREA+からCORE MINIに引っ越した際の手順をまとめておきませう。

• CoreServerのアカウント取得

まず最初に、移転先となるCoreServer Miniのサーバアカウントを取得する。
Xrea+で使用していたアカウントと同じにする方が楽なのだろうけど、セキュリティ向上のためにアカウント名を変更することにした。
いくつかのサーバーから選択できるので、負荷状況を見ながら混んでいなさそうなサーバーを選択する。サーバー負荷状況は公式に公開されているのでそれを参考にすればよいのだが、こうしてみると、サーバによって当たり外れがあることがよくわかる。

・coreserve負荷状況
　http://mainte.coreserver.jp/
・xrea負荷状況
　http://mainte.xrea.com/

この他、以下のようなサイトもある。ただしこれは有志によるものなので、全てのサーバー状況を観れるわけではない。

Coreserver / xrea 負荷観測所
 http://stress.junos.mobi/index.html

• ファイルのコピー

一般的にはftpでのdownload＆uploadとなるのだが、移転先がCoreServer/Xrea+の場合には「サーバー間コピー」機能を利用するのが楽で確実。移転元サーバでのパーミッションの設定や、Symbolic Linkも含めて移転先のサーバにコピーすることができる。
移転先である新しいサーバ（CoreServer）の管理メニューから「サーバー間コピー」を選択する。間違っても移転元サーバ上で操作を行ってはいけない（全て消えてしまう）。
移転元（リモート）となるサーバのftpの情報を入力すれば、あとは全て移転先（ローカル）に自動的にコピーしてくれる。ftpさえ利用できればいいので、リモートは他社サーバーでも構わない。



リモートディレクトリとローカルディレクトリの部分には、それぞれ / (ルート)とだけ入力する。
/の下には maildir と logが存在するのだが、僕はXrea+のmail は使っていないので、 /public_html と入力した。
転送方式はミラー（削除なし）でよい。実行をクリックするとサーバ間コピーが実行される。これでルートディレクトリ下にある全てのディレクトリとファイルがコピーされる。

ファイルサイズによるが、サーバ間コピーは数分～数十分程度で完了する。
進捗については、コピー先サーバのrootに、.servercopy.logというログファイルが作成されるので、管理画面からファイルマネージャーを使って内容を確認し"COMPLETE"と"END"となっていることを確認してください。

• コンフィグファイルの更新

MovableTypeなどを利用しているなど、コピーしたファイルの中にconfig.xxxなどの設定ファイルがある場合は、忘れずに新しいサーバの情報に更新する。
僕は、MovableTypeの他に Wordpress や Joomla! などのいろなCMSをインストールしていじってみたりしていたので、それぞれのコンフィグファイル全てを修正した。

• /public_html/log ディレクトリの修正

/public_html/log/ディレクトリは、アクセス解析ログの他、phpMyAdminやphpPgAdminがインストールされている。
これらの機能を利用されている方は/public_html/log ディレクトリの中のファイルを一度削除し、サーバ管理画面からログの保存の再設定やphpMyAdminを再インストールする。

ここにはベーシック認証用の.htaccessと.htpasswdファイルも置かれているのだが、コピーしたファイルに記述されているアカウントやパスワードは、移転元サーバの情報で不要であるので削除する。ファイルが存在しなければ新しいサーバの情報で朝6時に自動生成される仕組みになっているので、削除して待つだけだ。


あるいは管理画面のツールを利用すると記述内容を生成することができるので、その通りに書き換えてもよい。
このツールは.htpasswdに記述するパスワードの暗号化もしてくれるので、自動生成される初期パスワードではなく任意のパスワードに変更することが可能だ。

• Databaseのコピー

Database(以下DB)の移動は、phpMyAdminでデータをdumpする方法もあるが、Xrea+/CoreServerの機能を利用したほうが便利だ。
手順としては移転元のサーバ管理画面でDBのダンプファイルを作成し、移転先のサーバにアップロードするわけなのだが、今回の移転にあわせてユーザーアカウント名やDB名を変更したかったので、ユーザディレクトリの絶対パスなど環境依存の部分のデータ修正も併せて必要となった。

※ちなみに、MySQL4(orそれ以前)のデータは、MySQL5とは文字コード他で互換性がないために字化けしてしまう。古いversionのMySQLからMySQL5のサーバに移転する場合は、WordpressやMovableTypeの備えるデータエクスポート・インポート機能などを使用することで可能らしいのだが、僕は試したことがないのでわかりません。。。。

■DBのダンプファイルの作成
移転元のサーバにおいて、ダンプファイルを作成したいDBを選択し「保存」ボタンを押す。
数分～数十分程度で / （root）ディレクトリに「mysql.dump」という名前のファイルが作成される。
2つ目以降のDBの場合は「mysql_1.dump」などと、mysql_のあとにDB名を付加した名前のファイルとなる。
ファイルマネージャやftpツールを使ってこのダンプファイルをダウンロードする。



■環境依存データの修正
使っているCMSにもよるが、MovableTypeの場合はDB内にサーバ環境に依存するデータが含まれているので、新サーバに合わせたデータに修正が必要となる。
今回ユーザー名を変更しているので、ユーザディレクトリの絶対パスが変わっている。ダウンロードしたダンプファイルを、サクラエディタや秀丸エディタなど、Unicodeを扱えるエディタを使って編集する。文字コードを正しく扱えるエディタを使わないと文字化けの原因になるので注意すること。

秀丸エディタの場合を例にすると、メニュー「検索」→「置換」を選んで、
　検索：/virtual/移転元のアカウント名
　置換：/virtual/移転先のアカウント名
と入力し全置換する。

なお、独自ドメインを使用せずxreaのサブドメインを利用していた場合では、DB内にxreaドメイン情報が含まれているも同様に置換が必要である。


■ダンプファイルのインポート
サーバ環境依存データの修正が終わったら、次は新サーバ上にデータベースを作成し、データをインポートする。



移転先のサーバ管理画面で「データベース」メニューをクリック。
作成するデータベースを選択し、任意のパスワードを入力して、移転元DBと同じ文字コードを選択して「作成」ボタンをクリックすると、数分で空のデータベースが作成される。

次に、移転先サーバの / （ルートディレクトリ）にダンプファイルをアップロードする。
DB作成時に空のダンプファイルが作成される場合があるが、それは削除して構わない。
ダンプファイルをアップロード終えたら、管理画面からインポートしたいデータベースを選択し、今度は「復元」をクリックする。
おおよそ数分～十数分程度でデータベースのインポートが終了する。

ちなみに、２つ目以降のDBなら任意のDB名を入力するわけだが、インポートするダンプファイルのファイル名もこのDB名と一致していることが必要だ。
僕はDB名を変更したので、それに合わせてダンプファイル名を変更した上でアップロードする。
（ファイル名を、mysql_新DB名.dumpという名前に変更する）

この後、独自ドメインを使用する場合にはDNSの修正なども必要となるものの、とりあえずデータベースにちゃんとインポートされているかを試してみる。
http://hogehoge.mX.coreserver.jp/などにブラウザでアクセスして、CMSの管理画面などから確認してみよう。
無事サイトにアクセスできるようならば、CMSの管理画面から各設定を確認し、更新の必要な箇所があれば更新しておく。
データベースに接続できなかったりエラー画面が表示される場合には、コンフィグァイルのデータベース関連情報が間違っていないか、古いサーバ情報のままにになっていないかなどを確認する。

• ドメインウェブの設定とDNS情報の更新・その他の設定

独自ドメインを使用している場合は、ドメインウェブの設定をし、DNSを更新して新しいサーバに振り向ける必要がある。



移転先の管理画面にてドメインウェブの設定をするのだが、数が多い場合は煩わしいのでテキストで一括登録する方法が用意されている。画面下の方の「テキスト形式ファイルから一括設定する画面」というのがそれだ。

移転元のドメインウェブの管理画面にて、画面下の方にある「テキスト形式ファイルから一括設定する画面」をクリックすると、以下の画面に現在のドメインウェブ情報が表示されるので、表示された内容をコピー。



次に、移転先のドメインウェブ管理画面にて、同じくテキストから一括設定する画面（以下の画面）を開く。前述の、移転元でコピーした内容を貼り付けてから「仮設定」ボタンを押す。



コピーしたドメインウェブの内容が反映されて表示されるので、間違いがないかを確認してから「ドメイン設定」ボタンを押す。
この時、まだDNS設定が済んでいないので、「Aレコードのチェックを行わない（強制設定）」のチェックをつけておく。これは、設定時にDNSサーバのAレコードとの整合性をチェックしているので、このチェックをつけておかないとエラーになってしまうからだ。
ただ、強制設定してから5日経過後に再確認され、その時点でも不整合の場合にはドメインウェブの設定は自動解除される。

あとは、使用しているDNSサーバのAレコードを更新して、新サーバに振り向ける。
例えば旧サーバが111.222.33.4、新サーバが 222.33.44.5だとすると
　a www 222.33.44.5
　a @ 222.33.44.5
などのように設定する。
変更したDNSレコードがinternetすみずみに伝播するまでには少々時間がかかるので、nslookupコマンドを使ってDNSの逆引きをしてみて、返されるipaddressが新サーバのものになっていることを確認しよう。

　C:\> nslookup www.hogehoge.com

DNSレコードはドメインウェブの設定前に更新しても構わないのだが、DNSを更新したら時間を空けずにドメインウェブ設定をしよう。

これでxreaからCoreServerへのサーバの移転方法は完了となる。
お疲れ様でした！

なお、xrea+を利用している方はサービス利用権を移動できるらしいのだが、どうもCORE SERVER MINIは対象外らしい。

Firefox 3.5にバージョンアップしたところ、写真の色相や色彩がおかしくなってしまった。
同じページをIE8と比較すると、ビビッドというか、どぎつい色になってしまったのだ。調べてみると、FF3.5はカラーマネージメントに対応し、ICC Version 2およびVersion 4からのプロファイルが利用可能になったのだが、これがちゃんと設定されていないことが原因ようだ。
Firefoxで "about:config" を開いて、gfx.color_management.display_profile に、いま使用しているカラープロファイルを設定してあげることで正しい色となった。
ただ、僕のPCで色がおかしくなったのは、XP 4台+Vista 1台のうち1台だけなのだが・・・・


１．アドレスバーに、" about:config "と入力
２．" gfx.color_management.display_profile "を探し、カラープロファイルを設定する。
たとえば、「sRGB Color Space Profile.icm」の場合は、
　C:\\WINDOWS\\system32\\spool\\drivers\\color\\sRGB Color Space Profile.icm
とする（\が2ついることに注意）。
特に指定しているものがなければ、通常はこの「sRGB Color Space Profile.icm」でよいと思う。

※カラープロファイルは、
→コンパネから、画面のプロパティを開く　→　画面のプロパティで「設定」タブ　→　「詳細設定」ボタン　→「色の管理」タブ　→とたどって、
「現在このデバイスに関連付けられているカラープロファイル」
で確認できる。

Appleの「iPod touch」をIP電話の端末に変える無料アプリが、App Storeで提供開始となった。
米国にてIP電話サービスを提供するTruphone社の無料アプリによって、MP3プレーヤーであるiPod touchが携帯電話に変身するというものだが、ボクはiPod touchを持っていないので実際に試すことはできず、日本国内での利用の可否については不明。

http://www.truphone.com/

Truphoneによれば、このアプリを使うと、iPod touchに電話番号を入力するためのキーボードが現れる。Wi-Fi接続が可能なユーザーは、他のiPod touchユーザーやGoogleのメッセージングサービス利用者、TruphoneのIP電話サービスの利用者などとVoIP通話を行えるというわけだ。音声通話の利用にあたっては、別途ヘッドセットとマイクが必要となる。
　米国内では、固定電話との通話に対応する機能が追加される見込みで、その他の機能としては「Skype」や「MSN」などのVoIPサービスを利用しているユーザーとの通話やIM（インスタントメッセージ）の送受信、「Twitter」や「Facebook」などの閲覧や書き込みなども計画されているとのこと。
だが、米国でiPhoneを提供する当のAppleは、このTruphoneにそれほど脅威をは感じていないようである。

日本国内においても、「iPod touch」の普及率を考えれば、ソフトバンクの提供する「iPhone」と競争することにはならないだろう。Wi-Fiの普及が遅れていることもあるし、屋外でのヘッドセットの利用はちょっと抵抗が・・・メッセージ中心なら別だが。ただし、家庭内の無線LANでも使用できるようであればIP電話端末としての利用価値があるかもしれず、これについては未知数だ。

このアプリケーションは、AppleのiPhone/iPod touch向けのアプリケーション配布サービス「App Store」から無料でダウンロードできる。
App Storeには、「iTunes」（最新版はiTunes 8）を起動してiTunes Storeからアクセスする。

なお、同様のVoIP及びIMアプリとしては「Fring」がある。
起動すると、SIP通話、Skype、標準の携帯電話のどれを使って通話するかの選択画面が表示される。VoIP通話は携帯電話の通話時間に含まれないが、電話をかけるにはもちろんWi-Fi接続が必要だ。

iPhone/iPod Touchに限らずモバイルプラットフォームのユーザーにとって、通信の選択肢が広がることは大いに歓迎すべきことだろう。

ちょっと日があいてしまったが、MovableTpye Ver4.0 のバグ対応版として、2007/9/18付けでVer4.01がリリースされた。
6Aの言葉によれば、
「致命的なバグも多く修正されていますので、既にVer4.0で構築されている方は早めにバージョンアップを行う必要があります」
とのことであったが、MT 4.0への移行がやっと落ち着いたところだったので、ちと様子をみていた。　（さぼっていただけ？）

このたび、「さて・・・・」っと重い腰をあげ、週末を利用して4.01へのアップデートを敢行したが、何の問題も無くあっさりと完了。　まだあまりカストマイズもしてないから当たり前か。。。ちょっと拍子抜けではあるが、楽チンに越したことはない。
Bug Fixと同時に「管理画面のパフォーマンスの改善がされた」と書かれていたのだが、さてどうだろう。。。。
実際に操作を行ってみた感じでは、確かに早くなったと体感できる改善がされているようだ。　特に再構築に要する時間が短くて、これだけでも速くなっていることが実感できる。

これまでも、3.3xから4.0系にしたことによるメリットとして

・エントリを自動保存するようになった。
　書きかけのところ、ショートカットキーの誤操作などで思わずブラウザをcloseしてしまうことがあったが、自動保存されて
　いることで救われる。
・ファイル管理が楽になった。
・Staticの単一Webページもまとめて管理できる。
・マルチブログの連携

などを感じていた。　苦労してバージョンアップした甲斐はあった。。。。と自分に言い聞かせていたものの、それと同時に「でも重いなぁ・・」とも感じていた。　
それが、Ver4.01にすることで改善されてくれたことはとても嬉しい。

4.01へのアップデートのついでに、インデックステンプレートにsitemapテンプレートを追加した。　これをGoogle ウェブマスターツールを利用して登録する。　記事をエントリするたびに自動的にsitemap.xmlも更新してくれるので、Googleロボットは常に最新のsitemapを拾ってくれるというわけだ。

以下の内容でインデックステンプレートを作成して、出力ファイル名を「sitemap.xml」としておくだけである。

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">

   <url>
        <loc><$MTBlogURL encode_xml="1"$></loc>
        <priority>1.0</priority>
   </url>
<MTCategories>
   <url>
        <loc><$MTCategoryArchiveLink encode_xml="1"$></loc>
        <priority>0.4</priority>
   </url>
</MTCategories>
<MTEntries lastn="9999">
   <url>
        <loc><$MTEntryPermalink encode_xml="1"$></loc>
        <lastmod><$MTEntryModifiedDate utc="1" format="%Y-%m-%dT%H:%M:%SZ"$></lastmod>
   </url>
</MTEntries>

</urlset>

いそいそと使いはじめたMovable Type 4であるが、MT3や他のブログツールと比較して気づいた点などをメモしておこうと思う。

 

特徴

■エントリー記事の作成がWYSIWYGになった。

MT4の特徴で目立つ変更ポイントである、WYSIWYGによるエントリー記事の作成機能。

MT4ベータ版の時は、WYSIWYGエディタから吐き出されるソース（tag）が大文字表記だったり、本来なら"<br />"であるはずの改行タグが旧い記述"<br>"だったりと、お世辞にも美しいとは言えないものだった。

正式版ではどうか？？
ちゃんと小文字で吐き出されるようになっていたし、改行タグも修正されていた。
このようにキッチリ対応してくるあたり、さすが商品化されているだけあって、Wordpressなどとは違うね。

んでこのWYSIWYGエディタ、機能的にどうかというと・・・まだまだ発展途上かな。
フォントは、サイズ変更やBold/ItalicなどFontfaceの指定はできるが、Color属性が指定できず。
写真などのImageを挿入した際、キャプションを入れられるとよいなぁ・・・・これは、Joomlaのエディタでは可能。
Imageを回り込むような文章を作成すると、エディタ上での表示と実際のブラウザ表示が若干異なる。これはブラウザによるのかもしれない。

PC環境
　Firefox 2.0.0.7　
　Internet Explorer 7 ( 7.0.5730.11 )
　Internet Explorer 6 SP1 ( 6.0.2800.1106 )

デフォルトのエディタについては、現時点ではWordpressにはかなわないと思われるが、まぁJoomlaよりはずっと完成度が高い。
高機能エディタのプラグインがほしいところである。
この辺は、世の優秀なプログラマさんたちが解決してくれるでしょう。

■画像などのファイルを個別に管理・操作することが可能となった。

■Wordpressと比較すると、ウィジェットがわかり難い

■その他
細かいところでは、半角の「￥」がDefault Fontだとバックスラッシュになってしまう（テンプレートのstylesheetのせいか？）　エントリー記事内で金額の記述をする際には不便。
全角のダブルクォーテーション（""）が半角の記号（""）に変わってしまったり、３点リーダー（...）が（...）に変わってしまったりというのもあった。
MT4ベータの頃からわかっていたものもあるが、MT4正式版でも同様だった。
エントリー記事が、日本語EUCなのも気になる。　JoomlaはUTF-8。　選択できた方がいいかなぁ。。

あとは・・・重い・・・重すぎ。　
エントリー記事をちょっと修正するたび、再構築を強要されて待たされる。　せっせと何をそんなにやっているのだろう？
多数の記事をまとめて修正するときなど、ページめくり（記事送り）でもイライラするのに、保存した途端に再構築。　強制にしなくてもいいんじゃないか？

新機能部分の完成度はさることながら、ツールとして全体を通しての使い勝手は、v3.xの頃より直感的に使えるようになったと思う。
使い勝手の良いプラグインが出揃ってないことや、ユーザー向けの情報がまだまだ少ないため、カスタマイズしたいユーザーは試行錯誤を強いられるかもしれない。
（残念ながら、不満な部分を自力で改善できるほどの能力は私にはありません・・・）
現状、標準機能のままで使いつつ、順次カスタマイズにチャレンジしていこうと思う。

なにより、今年四半期（？）を目処にMTがオープンソース化されるという話もあり、しばらく目の離せない状態が続く気配．．．

 

Movable Type (MT) に限ったことではないが、PHPモジュール化やページ分割などのカスタマイズを行う場合は、テンプレートファイルの拡張子が .html から .php に変更となる。
MTでテンプレートの拡張子を変更すると、以降の再構築で生成されるページは.phpで新たに作られるが、これまで使っていた.htmlのファイルは、そのまま残ってしまう。　削除はされず、以後、更新されることもない。
同名のファイルがある場合Webサーバーは.htmlの方を返すので、本来のindex.phpではなくて古いままのindex.htmlが参照されてしまう。　あるいは、他サイトからそのファイルにリンクを貼っている場合は、デッドリンク（Error 404）になってしまう。
ブログ運用開始後に拡張子を変更した場合には、このような問題への対処が必要になる。

ここでは .htaccess を用いてリダイレクトすることによってデッドリンクを回避する方法を紹介する。
たとえば、
　http://example.com/blog/archives.htmlが参照されるた時、
　http://example.com/blog/archives.php
を返したいのであれば、

■例１　RedirectMatchを使用
パターンに合致したファイル名を「xxxxx.php」と読み替えてリダイレクトする。
　
　RedirectMatch permanent (.*)\.html$ http://example.com$1.php


■例２　RedirectPermanentを使用

　RedirectPermanent /blog/archives.html http://example.com/blog/archives.php

と.htaccessに指定することで解決できる。
しかしながら、Webサーバーから返されるステータスによってリダイレクトされたことを認識できるので、SEO的には多用は避けたいものである。