お名前サーバ（共用サーバーSD）からヘテムルへ移管 その2 まとめ

昨日に引き続き、「お名前サーバ（共用サーバーSD）からヘテムルへ移管」をしている。






ムームードメインからメールがくる

info@muumuu-domain.com
To:		info@ｘｘｘｘｘｘ.co.jp
日付:		2014年1月15日 17:26
件名:		【重要】トランスファー承認手続きのお願い

本文中のＵＲＬへ飛び、承認すると、数時間すると次にお名前.comから同様のものがきて承認する。


すると、ムームードメインの管理画面内に移管したいドメインが表示されるので、クリックして一年分のドメイン管理費を支払う。




ヘテムルにドメインを追加して、ここからがサーバ移行をして結構嫌なところ。
ブラウザサイトだけのhtml+css程度のサイトならばいいのでけれど、CMSがお手軽に使える時代なのでサーバサイドの設定やMySqlバックアップの反映、呼び出しＤＢの変更などが面倒くさい上に知らないところでエラーの原因になる。


やはり、サーバの移行はしたくないとヒシヒシと思う瞬間です。
ヘテムルのサーバにも前サーバと同じ設定が出来たらムームードメインのネームサーバをヘテムルを選択して変更、この辺でヘテムルとムームーがごっちゃになりやすいので注意。




しばらくするとヘテムルに変更されています。
※すぐには反映されません。


結局、待ち時間が多いので、複数業務をこなしつつ2日にわたってのドメイン移管とサーバの移行が終了。


移行したことで、大きめのＤＢを利用した表示速度は早くなり、拡張子.htmlのPHP化も.iniの設定も簡単に出来、というか設定を特にしなくても快適な状態になっていることが素晴らしい！
”本当に気が利く人は「気を使っている事」を気づかせない”って聞いたことがあるが、まさにその状態でしす。
ここに労力と時間がかかっていたお名前サーバは、たとえ機能に問題がなくてもやはり何か違うと思う。まぁ、月間数百円

お名前サーバ（共用サーバーSD）からヘテムルへ移管

ヘテムルサーバでは「サブドメインにwwwが付けられない」や再販禁止などの問題から、ヘテムルサーバからＧＭＯのお名前サーバの共用サーバへ移管した。

 

お名前サーバはシンプルな管理画面で、機能的にもそろっているのですが、プラスαのサービスが少ないので、いちいち手間がかかってしまい、ヘテムルサーバの時に予想の工程の倍以上の手間がかかることがザラにあったし、当然無料と考えていたものが有料だったりするので業務の効率化を優先してヘテムルに戻すことにした。

 

ちなみに時間がかかったことと言えば

• phpmyadminの手動インストール
• Whois情報公開代行
• 管理者アカウントが自動で振り当てられる（ランダム英数）
• PHP化した拡張子htmlが使えない（この変更が面倒くさかった）
• ↑ちなみにＳＥＯ的にhtaccessで403転送をかけた
• php.iniの設定
• Wordpress等のかんたんインストールでのデータベース名が指定できないので、MySqlの名前から作り直し
• ＦＴＰアカウントをディレクトリごとに作成したのも面倒

それと、理由はもう一つあって、モバイル転送がキャリアごとだったり、アクセスカウンターのたぐいの古臭いＣＧＩの簡単設定機能がそのままにされていたりと、何だか時代遅れのホテルのような「これって何のために使うの？」的なものがたくさんあり、少しの敗北感のようなものを感じていた。

 

そしてこの度、PHPライブラリのPearを使おうとしたのですが、なんと手動にてインストールが必要との事で、「もうええわ！」と古巣のヘテムルに戻ることにしました。

 

 

-----------------------------ここから手順

お名前.comにログイン

↓

Naviトップタブ

↓

移管するドメイン名をクリック

↓

テーブルの中のAuthcodeをコピーしておく

ムームードメインにログイン
↓ドメイン移管手続

https://muumuu-domain.com/?mode=transfer

↓質問に答え進む

↓

移管申請完了

↓

メールで申請内容を確認

http://muumuu-domain.com/?mode=guide&state=tp_flow_user

ここから数時間から48時間以内に「トランスファー承認手続き」メールを待ちメールが来ればそれに従い移管手続をすすめる。


という事で、本日できることはここまでです。
ムームードメインからの応答がある後日、続けます。
まぁ、一日でサーバの移行やドメインの移管は難しい上にメールの設定や、ネームサーバの設定の影響でNotFoundになるリスクを考えると、サーバ管理を請け負うのは採算が取れない。


それでもクライアントのスキルによってはせざるを得ないことになることがほとんどだと思うので、最初の時点で明確にクライアントのサーバと自社サービスのサーバは分ける方が管理も精神衛生上もいい。
また、再販可能なＧＭＯのレンサバだとしても、年間数千円程度で借りられるのでクライアントにサーバー維持費を請求しても普通に払ってくれる。

サイトの制作者がセコイ根性を出して自社とクライアントを一緒に管理することで年間数千円を節約しようとすると、自分にも制限がかかってしまいクライアントにもリスクを負わすことになるのでお勧めしない。

urlencode

ＰＨＰ覚書

urlencode(
の文字をブラウザがGETで飛ばす際に自動的にurldecode(するため、文字化けの原因になっている。

セキュリティーの面でも、出来るだけ2バイト文字は使わないか、使う場合は細心の注意が必要。

メンテナンス向上の意味からも設計段階でしっかりと決めておく。