ニフティクラウドのドメイン登録の落とし穴

久しぶりにメールを読んだときに「えー!」って叫んでしまった。

発端は、現在お客様がニフティクラウドで運用しているサービスを、他のサーバーに移行する作業を行っていた過程だった。ファイル、データベースの移行のテストを完了して本番のサーバーに移行するまで完了した。そう言えばドメインはどうなっているのだろうと思って調べてみると、ドメインとDNSの両方ともニフティクラウドで運用していた。

ニフティクラウドで管理しているドメインをどうやって他のレジストラに転出するのだろうかと思って調べる。レジストラにドメインを持って行くにはcomドメインなので、

  • 管理担当者メールアドレス(Admin Email) 
  • オースコード(AuthCode) 

の二つが必要である。メールアドレスはお客様のアドレスらしいから、残りのオースコードはニフティクラウドに聞く必要がある。だけど、ニフティクラウドのコントロールパネルから申請できないし、ニフティクラウドのFAQとかGoogleさんに聞いてもわからない。

しかなないので、ニフティクラウドのサポートに連絡してみる。Webサイトから、オースコードを確認する方法か発行する方法を教えて、と送る。

翌日、ニフティクラウドのサポートから回答があった。要約すると、転出はできないよ。ここに書いてあるよ。だった。これにはビックリ。

https://cloud.nifty.com/spec/dns/domain_manage.htm

ということは、一度ニフティクラウドにドメインを登録したら、二度と他には動かすことはできないってことなのね。ずっとニフティクラウドから逃げられないってこと?

再度、これって本当? 理解できないぜ。なんてことを送っておいた。現在、これの回答待ち。

もし、本当ならば、ドメインだけニフティクラウドに残したまま、ネームサーバーの設定を新しいDNSにしておくくらいしかないか。そもそもニフティクラウドのサーバーやDBを削除して、ドメインだけ残すなんてできるのかな? それに料金はどうなるのかな?

今回の教訓としては、説明項目の細かいところをよく読めよ自分、というところかな。あとは、サービスを別のクラウドに移行できないから、絶対にニフティクラウドにドメインを登録するな、ということかな。

追記

ニフティクラウドから回答があって、「将来的にドメインの転出をサポートする。」って。あくまでも将来的にだよね。

データベースに接続できないと思ったら

大昔に作ったニフティクラウドのサービスを、別のサーバーに移そうと思ったら、データベースに接続できない。ずっと悩んでいたら、ニフティクラウドのネットワーク障害だった。

トラブル情報【影響あり報】物理ネットワーク障害のお知らせ [ニフクラ]

おいおい今日の半日返してくれよ。数年ぶりのニフティクラウドでの作業なのに、障害にぶち当たるとは、ニフティクラウドとは何か因縁を感じるわ。

ってことより、障害回復に時間がかかるのね。まだ回復していない。大丈夫かニフティ。

WordPressサイトのサーバー移行

この記事が見えれば新しいサーバーを参照している。リンク切れならば、もうしばらく待ってね。

さくらインターネットのVPSで動かしていたこのWordpressサイトを、同じくさくらインターネットのレンタルサーバーに移行してみた。ほとんど思いつきの行動。httpsのこれからの対応と、ちょっとVPSのサーバーでブログサイトを面倒見るのが心配だから外部に任せようと思っただけ。

移行と言っても、Wordpressのファイルとデータベースをコピーして持って来ただけ。後はデータベースを作ったり、マルチドメインの設定したり、Wordpressの設定ファイルを書き換えたりしただけ。実質1時間位の作業。hostsファイルにIPアドレスとドメインを直接書いてテストしておく。消すことを忘れずに。

[amazon_link asins=’4295000795,4883379248,4798050040,4774173800,4844366580,4774187062,4774190292,4798052817,4774182184′ template=’ProductCarousel’ store=’5cho-me-22′ marketplace=’JP’ link_id=’9ea8cd23-bbca-11e7-bb4b-fb2ac15b99c3′]

トラブルと言えば、今までサクラのメールボックスでメールを受信したいたため、さくらインターネットでドメインがDNSに登録されていたので、メールボックスからドメインを削除しないとマルチドメインで登録できなかったくらい。

それとWP Super Cacheでキャッシュのクリアができないようで、再インストールした。

DNSのレコードをレンタルサーバーのほうに書き換えたので、後は待つだけ。

redirectionプラグインのせいで

お客さんから「トップページにアクセスすると、違うページが表示されるよ。」と言われた。そんなバカな、と思ったら、本当にそうだった。

そのサイトは、Wordpressで作成されたものを引き継いだもの。マルチサイトで作られている。

WordPressの設定もおかしなところもないし、リダイレクトの.htaccessのRewriteの設定も別に大丈夫。さて、わからない。

Googleさんに「wordpress リダイレクトプラグイン 勝手に」で聞いてみた。すると、Worpressのredirectionプラグインが悪さしているかも、と出てきた。

よく設定を見てみたら、redirectionプラグインを使っていた。ログを見ているとしっかりとリダイレクトしていた。データベースから直接redirectionプラグインの設定を削除したら、おかしな遷移をしなくなった。

何でそんな遷移をするようになったのだろう? WordPress恐るべし。

redirectionプラグインを使わずに、最初からRewriteで設定すればいいのに・・・。

サイトを #AWSへサーバー切り替え

お客さんのサイトをAWSに切り替えました。しかしながら、今回が手間取りました。予行演習をして30分でできると見積もったのに、1時間半もかかりました。

手間取ったのはデータベースサーバーの移行です。SQL Serverで動いているデータベースを、AWSのRDSのSQL Serverに移行します。これがよい方法かどうかわからないけど、メモしておきます。

直接インポートができないので、一旦ローカルのSQL Serverにバックアップ/復元をします。まずはこれではまりました。復元で最初に

既存のデータベース****以外のデータベースのバックアップを保持しています。

になります。これはよくあるエラーです。こちらはオプションに上書きをチェックすると復元できるはずです。しかし復元できません。今度は

データベース****はこのセッションで使用中なので、RESTORE では処理できません。

となります。これは初めてです。予行演習ではうまくいったのに。

さて、こちらの解決方法は、復元先のファイルを違う名前のファイルを指定してしまいます。本当にこの対応でいいのか?? 今度は上手くいきました。

[amazon_link asins=’4822237443,4774176737,479814469X’ template=’ProductCarousel’ store=’5cho-me-22′ marketplace=’JP’ link_id=’ce8d7800-bdfe-11e7-9aeb-f9ed3a2b0abf’]

次は、ローカルのSQL ServerからRDSのSQL Serverにデータベースを移行します。データのインポートウィザードで一件うまく行ったと思いましたが、実際にサイトを動かしてみると、nullが格納できなかったりと、テーブル構造がキチンと移行されていません。

これは仕方ないので、AWSのRDSのSQL Server移行の基本通りに、SQLでbcpコマンドのバッチファイルを生成してしまいます。エクスポートとインポートのバッチファイルを実行して完了です。今度は上手くできました。

本番で上手くいかず、久しぶりに吐き気がするような感覚を実感しました。

今回のサービスは、3TBほどのファイルをダウンロードするサービスで、ファイルはS3に格納しています。ファイルをアップロードするだけで、とても時間がかかりました。asp.netのC#からAWSのSDKを使ってアクセス制限をしています。

#CakePHP 3を試してみました。

環境を作ってインストールできたので、CakePHP 3を試してみました。試したみたと言ったけど、簡単にいつものブログのデータベースを作って、ControllerとModelをBakeして、使用している値をダンプしてみる。あとは、CakePHP3のドキュメントを読んでみる。

つまるところ、大幅に変わったMVCのModelの部分が肝かな。ModelがTable ObjectEntitiesになって、ORMがどう関わってくるというところが大事か。それとコントローラーとTable ObjectEntities、ビューがどう関しているかをもっと理解しなくてはいけない。

CakePHP3のドキュメントTable ObjectEntitiesを訳しながら読み進めていたけど、これはおもしろぞ。

ディスクが一杯でSOS

昔のお客さんから連絡があった。サーバーのディスクが一杯で、サーバー会社から警告があって、どうしたらいいかとSOSがあった。

1年と半年前に、私がサーバーの移行をした。すっかり忘れている。Evernoteからインストールメモを引っぱり出して、サーバーにアクセスして現状を把握する。どんなことをやったかはEvernoteにメモをとっていると後で役立つ。

サーバーの中を見ていると、MySQLのバイナリログがたくさん出ていて、これがディスクを一杯にした原因。これで報告。あとはお客さんが何とかするでしょう。これ以上の作業は、お金をいただく。

Evernoteのメモによると、このサーバーはPleskというサーバー管理ソフトでWebサーバーとか、MySQLのデータベースとか、サブドメインとかを作成している。Pleskは簡単かもしれないけど、どんなことをしてくれているかわからないので。後々厄介である。メールサーバー周りの設定はいいけど、あとは自分で設定して行ったほうが逆にわかりやすいかもしれない。

一度、自分のところのPleskが動いているサーバーで、PHPのバージョンアップをしたら、二度とPleskが起動できないことをやったことがある。おかげでそのサーバーは解約した。

 追記(2014/08/08)

今サーバーを除いたら、残りが67%になって増えていた。お客さんのほうで対応したようだ。

デルのサーバー注文完了

DELLT110お客様からWindows Serverが動くPCサーバーがほしいということで、いろいろ構成を調べて見積りをとる。お客様もデルのサポートに慣れているということで、デルにお願いした。お客さんも何回かサポートを呼んでいるけど、担当者は何とかしてくれているそうだ。

今回は、Windows Serverが必須のソフトを入れるので、最初からOSが入っているPCサーバーを選定する。Windows ServerのOEM版はFoundationと呼ばれているようで、15ユーザーまで使えるらしい。今のところこのユーザー数で十分。

それとSQL Serverも使用するが、今回使用するNECのソフトをインストールするときにSQL Server Expressも自動的に一緒にインストールするらい。SQL Server Expressは

  • 1 ソケットまたは 4 コアのいずれか小さいほうに制限
  • データベースサイズ 10GB
  • メモリ 1GB

という制限があるが、こちらも最初のうちは大丈夫のようだ。制限がきつくなったら、SQL Server をStandardにすることにする。

今回は改めて、Windows ServerやSQL Serverのライセンスについて知ることができた。NECの対応者から新設にアドバイスをいただけたことは、とてもありがたかった。

デルの営業担当者には、ほしい構成を伝えて見積もってもらう。Webからでも見積りができるのだが、RAIDとか設定すると制限がわからなくなって、結局は口頭で構成を提案してもらった方が早い。こちらも、見積書を送ってもらって、それをお客さんに確認してもらい、見積書を注文書をファックスして注文完了。

折り返しデルの担当者から電話をもらって、クレジットカードの情報を口頭で伝えて、その場で支払いの認証を取ってもらって発注完了。こちらも素早い。メールでもファックスでもなく口頭でカード情報を伝えるところがアナログっぽい。電話の向こうでは担当者が端末叩いていたけど。

今回は、お客さんのほうから。直接デルに支払うのは面倒だし時間もないしということで、私のほうで立て替えることになった。入金確認も土日をはさんで時間がかかるので、さっさとカード払いにしました。

ただし、納期は3週間後だそうだ。XPからの買い換え需要で注文が殺到しているらしい。消費税が8%に上がった後でも、4月に入ってからXPサポート終了の報道を見て注文が増えているとのこと。もっと前から準備しておけば5%のときに変えたのに思う。しかしながら、見積書の消費税の項目を見たら、とても高く感じた。

[amazonjs asin=”B00J3OBROC” locale=”JP” title=”2GB×2枚 (計4GB標準セット) DELL Workstation T3500/DELL Server PowerEdge T110, T110 T310, T320, T410などへ適合【バルク品】”]

さくらのレンタルサーバーで500エラー(その後)

さくらのレンタルサーバーで500エラー」と書きましたが、さくらインターネットのサポートに電話しても、Wordpressの問題だからサポートできないと言われ、仕方ないので他のレンタルサーバーに乗り換えました。

海外のお客さんなので、Go Daddyという海外のレンタルサーバーを指定してきました。もちろんGo Daddyは初めて使います。

WordPressのサイトの移行なんて、簡単にできると思っていましたが、なかなかどうも大変でした。まずはサーバーの設定が大変でした。

FTPのアカウントが使えるようになったのが、アカウントを設定して2時間後、MySQLのデータベースを作成するのに12時間後という、何もするにも時間がかかります。sshのアカウントなんて、72時間後に利用可能ですよ。たまりません・・・・。

MySQLのデータベースの作成は、ユーザーフォーラムによると、1時間以内に作成、これ以上時間がかかる場合はサポートに連絡、とありましたので、サポートに連絡を入れておきました。これでも12時間です。

ファイルの転送も海外にサーバーがあるだけあって遅い遅い。2時間ばかり時間をかけてファイルのアップの完了です。今回はFilezillaの同時転送の機能に助けられました。

テータベースをインポートします。インポートはPHPMyAdminで行います。国内のレンタルサーバーと違って、1Gバイトまでインポート可能ですので、バックアップファイルの分割とか考えなくて済みます。

DocumentRootのパスは、コントロールパネルに表示しています(最初に見つけるのに苦労しました)。MySQLのホスト名も、コントロールパネル内に表示されています。mysqldumpは適当に、/usr/bin/mysqldump としたら当たりました。

あとは、DNSの切り替えをして、Wordpressのサイトの移行は完了です。今度は500エラーは出ていません。さくらインターネットでのトラブルは何だったのでしょうか?

[amazonjs asin=”4844364138″ locale=”JP” title=”WordPressユーザーのためのPHP入門 はじめから、ていねいに。”]

#WordPress を3.5にアップグレード

#WordPress を3.5にアップグレード

WordPress3.5の日本語版がリリースされたので、バージョンアップしました。ほんの少しの時間を待っただけで済みました。

今回は、大きなアップグレードなので慎重に対応します。マイナーなアップグレードの場合は、ボタン一発でアップグレードしていましたが、今回は念のためです。

まずはデータベースのバックアップです。あとはテーマなどの必要なファイルをバックアップを取っておきます。

つぎにブラグインをすべて無効にします。これでアップグレードの準備OKです。管理画面から行います。WordPressのアップグレードはボタンを押すだけで簡単です。

アップグレードができたら、まずはアクセスして正しくサイトが表示されるかを確認します。無事に表示されました。

次にプラグインを一つづつ有効にしながら確認です。特にキャッシュのプラグインは要注意です。

無事にアップデートができたようです。各プラグインの機能が正常に動作しているかを順次確認していきます。

Embedded Link

WordPress | 日本語 » WordPress 3.5 日本語版リリースのお知らせ
WordPress 3.5 日本語版リリースのお知らせ. 2012年12月12日, Takayuki Miyoshi. WordPress 3.5 日本語版をリリースしました。 ダウンロード: WordPress 3.5 日本語版をダウンロード. アップグレード: 「WordPress のアップグレード」を参照してください。 新機能・変更箇所: WordPress Codex 日本語版の「Vers…

Google+: View post on Google+