なんとかなるかなぁ/経験値upにはいい題材かなぁ?と軽く始めてしまったサイトの移行は、思ったより長い道のりだった。
最期の方は"自宅サーバーを立ち上げて‥"とあきらめる寸前から、ふっと気付いた対策で急に道が開けた、という感じ。
環境の変化はだいたいこんな感じ
事前のトライアルでtaxonomy,taxonomy_dhtml,locale関係のデータベースに矛盾がある(PIMARY-keyが重複しているとか、nodeとterm_nodeが一致していない等々)がわかっていたので、これらのうち、無くてもなんとかなるtaxonomy_access/dhtml関係はどうにかしておきたかった、というのが理由
移行を出来るだけ順調に進めるために"素直な"環境に構築し直す
素直に出来るとは思っていないので、現在運用しているサイトのデータのスナップショットを取り、 環境構築が出来たら、そちらを正式サイトに定義しなおす戦略を取る事にした。
ちなみに、当サイトは投稿するのは私がメイン(時々コメントがあるけど、もしあったら手作業で 移せばいいや、という雰囲気)なので、こういうことが出来る。
以下の作業を現行サイトを運用してるサーバーに対して行う
このステップは、(Drupal5である点を除くと) Drupal.0829.infoがとてもわかりやすいし、 多分Drupal6のインストール情報も暫くしたらupされる気がする
また、後続の更新インストールに向けての動作確認ステップの位置付けなので融合させても問題ないはず
■■ターゲットの新旧比較:
環境の変化はだいたいこんな感じ
サービス | さくら(新環境) | xrea(旧環境) |
---|---|---|
レンタルサーバー | さくら・スタンダード | xrea・xrea+ |
Drupal | 6.9 | 5.7 |
Apache | 1.3.41 | 1.3.37 |
PHP | 5.2.8 | 4.4.8 |
MySQL | 5.1 | 4.0.26 |
■■事前準備 [当サイト固有]
事前のトライアルでtaxonomy,taxonomy_dhtml,locale関係のデータベースに矛盾がある(PIMARY-keyが重複しているとか、nodeとterm_nodeが一致していない等々)がわかっていたので、これらのうち、無くてもなんとかなるtaxonomy_access/dhtml関係はどうにかしておきたかった、というのが理由
移行を出来るだけ順調に進めるために"素直な"環境に構築し直す
- taxonomy_accessで、roleによって公開カテゴリをコントロールしていたのをやめる
- 非掲載もやめる
■■データベースバックアップ [Drupal,xrea]
素直に出来るとは思っていないので、現在運用しているサイトのデータのスナップショットを取り、 環境構築が出来たら、そちらを正式サイトに定義しなおす戦略を取る事にした。
ちなみに、当サイトは投稿するのは私がメイン(時々コメントがあるけど、もしあったら手作業で 移せばいいや、という雰囲気)なので、こういうことが出来る。
以下の作業を現行サイトを運用してるサーバーに対して行う
- 管理者(user_id=1)でログイン
http://www.xxx.net/?q=user (クリーンURL OFF時)
- サイトのメンテナンスから、サイトをオフラインに
http://www.xxx.net/admin/settings/site-maintenance
- モジュール/テーマを初期状態に近づける
http://www.xxx.net/admin/build/modules
当サイトでOFFしたモジュールは、(1)Taxonomy_AccessControll, Taxonomy_DHTML, Image_CAPTCHA (2)CAPTCHA (3)Aggregator, Legacy, Locale。
3段階にしているのは(1)拡張モジュールと、(2)依存し関係にある拡張モジュール、(3)標準モジュール を分けた方が気持ちよかったからなんだけど、(1)(2)はいっしょにやってもモジュール側で判断してく れるから実は問題ない。ただ、taxonomy_DHTMLとtaxonomyは依存関係があるのにチェックしてくれないので、taxonomyだけをOFFするとアクセス時にエラーが発生してしまい、リカバリ(データベースのリストア等)に てんやわんやするので注意 - phpMyAdminからmysqlをダンプ
"ファイルに保存する","nonエンコーディングに変換する"にして、
localhost.sqlをダウンロードする
MySQL4からMySQL5への移行に関してはいろんなサイトで苦労が記載されているんだけど、 「"MySQL5の漢字自動変換をさせると苦労する」が一番重要。 で、当サイトでも"UTF8"を基本に引越しを考えた。
ちなみに、xreaのmyPhpAdminからダウンロードしたsqlファイルを見ると、 MySQL4デフォルトのEUCではなく、"UTF8"になっていたというのもその理由。
ただ、全てがUTF8という訳ではなくて、 (1)データベースのコメント部 (2)データ中referer-URLの引数 (3)検索用キーワード 等が"UTF8"ではないので、単純にnkf等で変換するとツボにはまりそう
- 変更したモジュール/テーマを元に戻す
- サイトをオンラインに戻す
■■サイトバックアップ [Drupal]
- サイト全体をtarでまとめる
そのまま"さくら"にftpで転送
■■テストドメイン(www2.e384.net)作成 [ValueDomain,さくら]
- さくらサーバのIPアドレスを取得
ここなんかが便利?
以下の説明では、 xxx.sakura.ne.jp , AAA.BBB.CCC.DDD としておく
- ValueDomain側でwww2.e384.netをさくらに向ける
ValueDomainのユーザコントロールパネル・"DNSレコード/URL転送の変更"から
- さくら側でwww2.e384.netを作る
さくら・サーバーコントロールパネル ・ ドメイン設定 から、"新しいドメインの追加" ⇒"4.他社で取得、または他社で管理中のドメインを移して使う" ⇒"上記以外のドメインの場合" ⇒"他社で取得された独自ドメインへのサブドメインの追加" ・サーバー上の位置指定
www2.e384.netを /home/e384/www/www2.e384.netにエイリアス
※ns1.dns,ne.jp, ns2.dns.ne.jpにネームサーバを移すように 書いてあるんだけど、面倒なのでValueDomain担当のままにする(特に問題は発生していない)
- ドメイン情報浸透確認
/home/e384/www/www2.e384.net/index.htmlに適当な文字を入れて、 http://www2.e384.net から見えるかどうかの確認
www2の場合は新規ドメインだったからか、設定直後すぐにwww2.e384.netの確認が出来た のに対して、www.e384.netは置き換えがあるからか2時間位浸透が必要だった
■■Drupal6.9新規インストール [Drupal]
このステップは、(Drupal5である点を除くと) Drupal.0829.infoがとてもわかりやすいし、 多分Drupal6のインストール情報も暫くしたらupされる気がする
また、後続の更新インストールに向けての動作確認ステップの位置付けなので融合させても問題ないはず
- データベースの作成
さくら・サーバーコントロールパネル/データベースの設定で、 "標準[MySQL5.1](推奨)"を作成
- 必要ファイル群の取得(Drupal6標準,Drupal6拡張)
- Drupal6.9本体
drupal-6.9-japanese_009.gz
jamail-6.x-1.0.gz
- CAPTCHA
captcha-6.x-1.0-rc2.tar.gz
⇒ www2.e384.net/sites/all/modulesの下に
- Drupal6.9本体
- Drupal6.9本体を www/www2.e384.netの下に展開
※解凍直後、フォルダは全て"drwxr-xr-x(755)", phpは全て"-rw-r--r--(644)", .htaccessは"-rw-r--r--(644)"
- サイト固有設定(1)sites/default/setting.php
- /sites/default/default.settings.phpをsettings.phpにコピー
- [/sites/default/setting.php] $db_url,$base_urlを設定
- /sites/default/default.settings.phpをsettings.phpにコピー
- さくら固有設定(1)/.htaccess,/files/.htaccess,/files/tmp/.htaccess:Optionsディレクティブ
- [/.htaccess] "Options -Indexes"をコメントアウト
※さくらは、.htaccessで、Optionsディレクティブ宣言を禁止している為 - [/.htaccess] "Options +FollowSymLinks"をコメントアウト
※さくらは、.htaccessで、Optionsディレクティブ宣言を禁止している為 - [/.htaccess] "DirectoryIndex index.php"を"DirectoryIndex index.php /index.php"に
※Options -Indexesの代替手段 - [/files/.htaccess] 空ファイルを作成
※DrupalがOptions付きの.htaccessを作成するのを防ぐため - [/files/tmp/.htaccess] 空ファイルを作成
※DrupalがOptions付きの.htaccessを作成するのを防ぐため
※上は"http://www.e384.net/"直下に置く時の設定。"http://www.e384.net/dru"だと"/dru/index.php"
- [/.htaccess] "Options -Indexes"をコメントアウト
- さくら固有設定(2)/.htaccess
- Rewrite関係のコメントアウトしている"RewriteBase /"を外す
これを外さないと、通常アクセスは問題ないが、ちょっと違うところをアクセスすると、 さくらおなじみの"500 Internal Server Error"が表示されてしまう。
実は最初から更新インストールにトライした所、一部のページは正常に表示されるのに、 他のほとんどのページは"500 Internal Server Error"になってしまったので、 原因究明の為に新規インストールのステップをやってみた。
すると、Drupal標準のページは大丈夫になった(多分重箱の隅をつつくと駄目だったんだと思う) んだけど、(1)"http://www.e384.net/oooo"の様なページにアクセスすると、同じエラーが 出る(2).htaccessで、500エラーをindex.phpにリダイレクトすると殆どindex.phpが 表示される様になったから、もしかして rewrite系?と思ったらヒット。で、最終問題解決
- Rewrite関係のコメントアウトしている"RewriteBase /"を外す
- さくら固有設定(3)php.ini:マルチバイト文字列対応
- [/php.ini] 以下の内容で作成
mbstring.func_overload = 0 mbstring.language = neutral mbstring.http_input = pass mbstring.http_output = pass mbstring.encoding_translation = off mbstring.internal_encoding = UTF-8 magic_quotes_gpc = Off register_globals = Off session.auto_start = Off
- [/php.ini] 以下の内容で作成
- インストールスクリプト実行
- 日本語プロフィール
- 後アカウント等適当
※データベース設定がしてあると、GUI画面はスキップされる様子 - そこらにアクセスして問題ないことを確認
フォルダは"755"のまま、 phpは"644"が基本だけど、 sites/default/settings.phpは、"-r--r--r--(444)"に変更されていた
- 日本語プロフィール
- /install.phpを削除
■■Drupal6.9更新インストール [Drupal]
- バックアップしたlocalhost.sqlのリストア
- xreaでdumpしたsqlファイルを加工
- "^-- " で始まるコメント行を削除
コンテンツ,アクセス元ログ,コメント部分は,漢字コードがUTF8と異なって ややこしそうなので、まずはコメント部を削除
- "set names utf8;"を先頭に追加
この宣言でutf8として扱ってもらえるようになる/ これをしないと勝手に漢字コードを判断されてしまい、フィールドが空になったりする
- "DROP DATABASE 'DB名';"がもしあれば削除
- "CREATE DATABASE `DB名`;"が不要なら削除
- "USE DB名;" をの"DB名"が異なる場合は変更
- "^-- " で始まるコメント行を削除
- mysqlでデータベースを読み込む
mysql --host=DBサーバ --user=USER --password=PASSWORD < sqlファイル
- myPhpAdminでaccesslogあたりのデータで日本語が化けていないことを確認
- xreaでdumpしたsqlファイルを加工
- 旧サイトの/filesを上書き
/files/.htaccess, /files/tmp/.htaccessが上書きされないように注意
- update.phpを実行
- 一時的に、/update.phpの$access_checkを"TRUE"から"FALSSE"に変更
- update.php
予定通りエラーが出る(T.T)
user warning: Column 'vid' cannot be null query: UPDATE term_node t SET vid = (SELECT vid FROM node n WHERE t.nid = n.nid) in /home/e384/www/www2.e384.net/modules/system/system.install on line 1164. user warning: Column 'nid' cannot be null query: UPDATE upload SET nid = (SELECT r.nid FROM node_revisions r WHERE upload.vid = r.vid) in /home/e384/www/www2.e384.net/modules/system/system.install on line 1965. user warning: Duplicate entry '3348-0' for key 'PRIMARY' query: ALTER TABLE locales_target ADD PRIMARY KEY (language, lid, plural) in /home/e384/www/www2.e384.net/includes/database.mysql-common.inc on line 374. user warning: Duplicate entry '60-0' for key 'PRIMARY' query: ALTER TABLE term_node ADD PRIMARY KEY (tid, vid) in /home/e384/www/www2.e384.net/includes/database.mysql-common.inc on line 374.
- モジュール追加&update.php
Jamain,CAPTCHA,Taxonomy_menu
- AccessAnalyzerのタグ埋め込み
bluemarineなら、/themes/bluemarine/page.tpl.phpのbodyとtableの間
pixtureの場合は、/sites/all/themes/pixture/page.tpl.php
- 管理者権限でログイン
- オンラインモードに変更
- 後処理
- taxononomy情報欠落の修復
update注にtaxonomy情報が消えてしまったらしく、分類が出来なくなっていたので、
仕方無く300近い記事の情報を手作業で追加
- taxonomy_menuの記事数がおかしい
きちんと分類は出来るんだけど、集計数がおかしい。
対処方法がわからないのでこのまま放置(出さなかったらわからないという話もある)
- tableのアトリビュート(width,border等)が変(pixture)
pixtureは、本文にtableがあると、強制的にwidth=100%になって見栄えが悪い。
これは、pixtureが使用しているスタイルシート(files/color/pixture-b33d683e/style.css) の影響で、FireFoxはスタイルシート<本体の優先順位なのに対して、IEはスタイルシート>本体 の優先順位なので、本体側でアトリビュートを変えても反映できない。
かといって、スタイルシート側を変更すると、フロントページの要約のテーブルまで 変わってしまう ので駄目。(当面あきらめ) - コメントが評価されない
どうも、Drupal本体で、"<!" が "&lt;!"に変換されているようで、コメントで 隠していた物が全て見えてしまう。
これはおいおい直していくつもり(or放置)。
- taxononomy情報欠落の修復
■■正式ドメイン(www.e384.net)への変更 [ValueDomain,さくら]
- Drupal変更
sites/default/setting.phpの$base_urlを変更
- さくら側の変更
- コントロールパネルで、www.e384.netを www/www.e384.netに割り当て
- www2.e384.netフォルダをwww.e384.netフォルダにcopy
- ValueDomain側の変更
- www.e384.netをさくらにむける
■■cronの登録
- サーバーコントロールパネルからcron.phpを実行するように設定
新規項目の追加 実行コマンド: /usr/local/bin/wget -q -O /dev/null http://www.e384.net/cron.php (月,日,時,分)=(*,*,*/2,0)
- 一時的に、/update.phpの$access_checkを"TRUE"から"FALSSE"に変更
最近のコメント
…