これまで、通称ドメインロンダリングと一部で呼ばれている、ドメイン移管の料金が更新料金より安い業者を利用して、移管を繰り返すことで更新費用を安くするという節約術を実践してきたのですが、移管料金が380円程度と安くて利用しやすかった お名前.com が移管料金の値下げをやめてから(正確には今も100円程度は安い模様)、お手軽なロンダリングが難しくなっておりました。
そこで、一人1ドメインと制限があるものの、0.99ドルで各種gTLDを移管できるキャンペーンをよくやっている 1&1 に移管したり(ちなみに1ドメインと制限しているけど、別のgTLDなら0.99ドルで再度移管できたりする) してきたものの、さすがにキャンペーンとはいえ0.99ドルで移管し続けるのは申し訳ないし、移管後は自動でネームサーバーを 1&1 のものに変更されるというデメリットもあり(すぐ変更すればいいだけだけど)、他の候補となるレジストラも色々と探していました。
大手の GoDaddy や NameCheap もキャンペーンやクーポン利用で格安になることがあるため、そちらも利用はしていたのですが、やはり常に同じ料金で安く更新できるところがいいかなと思い、色々と調べていたところ、みんなのドメイン という会社が、ドメインの移管だけでなく更新も格安でできるようなので、喜び勇んで移管をしたところ、トラブってしまうことになりました。
移管自体には全く問題はなかったのですが、特定の条件を満たすとドメインがサスペンドされてしまい、私と同じような事態に陥る可能性がありますので、注意喚起とともにまとめておきます。
この記事は友人に届いたアパマンショップからのメールを発端とし、その後数回に及んだメールのやりとりを元に構成しています。内容は全て事実をもとに構成しておりますが、なにぶん友人が関係したことですので、私にひいき目があることも否定できません(もちろんできる限り公平な目で書いたつもりですが)。その点を踏まえてお読みいただければ幸いです。
本文が長いので、あらすじを用意しました(笑)。ざっくり言うと、以下のような感じです。
あらすじも長くなってしまいましたが、おおむねこんな感じで間違いないかなと。それでは本文は以下から、はじまりはじまりー。
Twitterでもつぶやいてましたが、PC2台が同時に起動しなくなる(正確には起動までに相当時間がかかったり、まれに立ち上がることもあった) という問題が発生していたのだけど、何とか直ったみたいなので、その顛末とか作業内容をまとめてみる。
起動しなくなったのは、メインマシンとゲーム用マシンで、それぞれWindows7 x64環境。もちろん、話題になったWindows Update適用によるトラブル ではない(アップデートを行う前に発生)。それぞれの症状は以下のような感じ。
これらは、classpnp.sys 絡みのトラブルだったのかもしれないが、何とか今は再インストールせずとも正常に起動するようになっている。実際のところ、これをやったから直ったと確実に言えることはなく、いくつか試した中のどれか、またはいくつかが組み合わさってうまくいったかなという程度のまとめで、いつ再発するか分からないという不安もあり、参考にはならないかもですが、同様のトラブルを抱えた方の参考になれば幸い。
価格:150,000円 |
衝動買いは地獄だぜ、フゥハハハァーッ!
ということで、衝動買いしたアーロンチェアが初期不良で凹んだので、衝動買いで失敗したら衝動買いで晴らすぜ! と Buffshop でHDDを購入したら購入翌日にいきなり値下がりして涙が止まらない。まあトータル1000円くらいなので送料代引き手数料くらいの被害で済んだのではあるが、香川県なら余裕で1日は生き延びられる(うどん3食) 金額と考えると、空から15年遅れでアンゴルモアの大王が降ってこないかと考えずにはいられない。
本当、衝動買いは地獄だぜ、フゥワハハハァーッ!!(涙)
ということで、腹立ちまぎれにアーロンチェアの初期不良事例として、どんな症状だったのかまとめてみた。もしアーロンチェアを購入してこんな症状があったら、たぶん初期不良って考えてもいいのかなと。
foltia anime lockerの話ばかりだったので、今回はちょっと話題を変えて、少し前にトリプルモニター環境を作った時の話でも。
自宅では、以前よりビデオカードにファンレスのRadeon 5750(PowerColor Go! Green HD5750) を使用して、30インチ2台のデュアルモニター環境を作っていた。これに使用してなかった24インチモニターを加え、3台環境にしようと考えたのだけれど、ATI Eyefinityの制約で、1台はDisplayPortを使用しないと3モニターは使えない。(現行製品も一部製品を除き、同様の制限がある模様)
普通に考えれば、メインディスプレイかサブディスプレイの1台をDisplayPortにすればいいのだけど(3台目のモニターにはDisplayPortがない)、KVMを利用している関係上、メインディスプレイはDVI接続でないとダメ。それではとサブモニターにDisplayPortを使用すると、サブモニターの電源を入り切りしたとき、デスクトップアイコンがメイン・3台目モニターに飛び散ったりするという問題が発生。調べても解決方法もなさそうだったので、このアイデアもボツに。
最後に出てきたアイデアが、メイン・サブのモニターはこれまで通りDVIで、3台目となる24インチモニターはDisplayPort変換アダプタを使って接続するという方法。結論から言うと、この方法でアイコンが飛び散ることもなく、使いたいときだけ2・3台目のモニターの電源を入れて使用することができるようになった。詳しくは以下に。
今回の内容は長文になりすぎてしまったため、結論だけ先に書く。業務サービスとか、シビアなものには さくらのVPS はやめておいた方がいい(そういったものには普通使わないだろうけど)。利用可能リソースを明記している会社のサービスか、SLAを明記しているサービスにすること。
業務で利用しているVPSに、突然制限をかけられて対応に苦労することを考えるなら、高くてもリソースの制限が明確な Linode とか、SLAをうたってる GMOクラウドVPS 、Amazon EC2 等がいいのではないかと思われる。
私の場合もミッションクリティカルと言うほどではないにしろ、社内グループウェアと外部向けのWebサービスに利用していたサーバーにおいて、突然リソース制限が掛かってしまったため、非常に焦った。せめて制限をするならするで同時に自動メール送信を行うなど、ユーザーに対する連絡は欲しかった。(これがなかったせいで、乗っ取られたことも考えてログ総ざらえする羽目になり、1日徹夜したんだぜ・・・)
どうしても予算がなくて高いサービスを使えないという場合であっても、そういったサポート体制を前提にサービスを選ばなければ、最後に泣くのは技術者たる自分である。サポート対応に定評があり、自分も信じていただけに裏切られた感が強いが、さくらインターネットには、今後もよりよいサービスに向けた改善を行ってもらいたい。
なお、今回の事例は事実に基づき記載しているが、この内容は個人としての感想を述べただけのものであり、さくらインターネットのサービス運用・体制を批判・非難するものではなく、私の所属する会社を代表した意見として記載したものではない。
・・・以上、一応会社が絡む話なので免責事項も記載してみました。
WordPress 3.1.3 日本語版が出たので自動アップデートを試みたものの、Apache環境のWordPressは問題ないのだが、nginxで動かしているこのサイトだけ何故か失敗。
ログを見てみると、
upstream timed out (110: Connection timed out)
ということだったので、本家のwikiを調べたところ、fastcgi_read_timeout が関係しているらしいと判明。デフォルトは60秒だから、それを180秒にしてやったところ、無事に自動アップデートが完了した。
あわせて、関係ないとは思うけど send_timeout の値もデフォルトが60秒なので、180秒にした。
書き方はこんな感じ。
server {
fastcgi_read_timeout 180;
…
…
}
fastcgi_read_timeout はHttpCoreモジュールの設定ではないので、server 以下に書いた。この辺りよく分かっていないので http 以下でもいいのかもしれないけど、wikiでの書き方もそうなってたので、まあそのままで。
send_timeout は http 以下に書いた。
http {
send_timeout 180;
…
…
}
もし同じ症状の方がいたら、参考までに。
ドメインキング から、XOOPS Cube Legacy で作成していたサイトを さくらのVPS に移したのだが、モジュールインストール時に以下のようなエラーが出てインストールできなくなってしまった。
You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ‘TYPE=MyISAM’ at line XXX
どうやらMySQL 5.5系では ‘TYPE=MyISAM’ 指定が無効になっており、’ENGINE=MyISAM’ とSQL文を書いてやらないとダメな模様。このサーバーではremiレポジトリからPHP 5.3系・MySQL 5.5系がインストールされているため、既にインストールされていたモジュールは問題なかったものの、モジュールの新規インストールで問題が出たようだ。
その後、いくつかのモジュールのSQLを確認したが、確認した限りのモジュール全てで ‘TYPE=MyISAM’ が使われていたため、全部置換するのも面倒だなーと思っていたら、XOOPS Cubeの公式フォーラムに投稿されていた以下のハックで解決。
class/database/sqlutility.php
の
function splitMySqlFile(&$ret, $sql)
{
直下に、以下の行を挿入。
$sql = str_replace( 'TYPE=MyISAM', 'ENGINE=MyISAM', $sql );
これでモジュールのインストールができるようになった。
我が家では、今年頭に買った YAMAHA NVR500 で契約中のプロバイダに接続していたわけだが、どうもたまに 同人荘 – doujin.so! 内部のサイトに繋がらない事があった。
症状としては、名前は引けているがpingに応答しないというもので、サーバー側の負荷のせいだろうと思っていた。しかし、負荷が低いときにもしばしば発生し、かつソフトバンクの3G網からは接続できていたので、これはプロバイダ絡みだなということで調べていた。
初めはプロバイダの障害を疑ったが、他のサイトには問題なく繋がるため、違うだろうと判断。よくよくルーターの設定を見ていると、今回はWebベースで設定していたため、MTUを自動取得する設定のままだった。
そこで、以下の設定をしてやることで解決。
ip pp mtu 1454
これでpingが通るようになった。
繋がるサイトと繋がらないサイトがあった理由は、おそらく途中の経路でのルーターの処理方法に差があるためだろう(とはいえ、大半のサイトには問題なく繋がり、この5ヶ月ほど不自由はしていなかったのだが)。繋がるときと繋がらないときがあるというのも、その時とった経路によって、パケットが破棄されるときとされないときがある、という事じゃないかなと推測。
ということで、先日急いで同人荘 – doujin.so!のトップページを移行する原因になった、同人荘 – doujin.so!へのアクセスが不通となった件は、私のルーターのせい(というかちゃんと設定詰めてなかった自分のせい) という可能性が濃厚となりました……。Youhosting.com様、ユーザーの皆様、誠に申し訳ありませんでした……。
……ま、まあ、Youhosting.com側での万一に備えるという点では、顔であるトップページや障害告知用のページは別サーバーにある方が望ましいので、移転が悪い判断だったというわけではないけど、告知もせず慌ててやらなくても良かったのにな、と反省。
今日の教訓
慌てているときこそ、原因究明は丁寧にしよう。orz
設定変更後も、負荷が増大しているときにはタイムアウトになることがありますね。それでもpingは通るので、pingすら通らない事があった設定変更前よりは良くなっているし、NVR500の設定のせいだったって可能性は高いのですけど、本当にそれだけだったのかなーと悩み中・・・。こういう、時折起こるって感じのトラブルはやっかいですねえ……。
現在、このブログがある さくらのVPS では、PHP 5.3系を使いたいのでremiレポジトリを有効にして、yumでアップデートなどを行っているのだけど、そこで発生したトラブルについてメモがてら。
昨日アップデートをしたら、大量のアップデートに混じってMySQLも5.1系から5.5系にバージョンアップされたらしく、起動しなくなっていた。MySQLのログを見ると、
[ERROR] /usr/libexec/mysqld: unknown variable 'default-character-set=ujis'
[ERROR] Aborting
となって終了している。
MySQL MLの投稿
http://www.mysql.gr.jp/mysqlml/mysql/msg/15436
によると、5.5系では [mysqld] 内では default-character-set が利用できなくなっているとのことなので(ただし [client], [mysql], [mysqldump] では問題なく利用できている)、代わりに /etc/my.cnf に
character-set-server = ujis
と書いてやることで無事起動するようになった。
が、以下のようなエラーも吐かれていたので、こちらにも対処する。
[ERROR] Missing system table mysql.proxies_priv; please run mysql_upgrade to create it
mysqld を起動しておいた状態で、
# mysql_upgrade -u root -p
として root パスワードを入力すると、データベースがチェックされ、問題なく全て OK となった。再起動後もエラーは出なくなったようだ。
そして、ここまでやった後に、下記サイト様を発見。
【MySQL】5.1から5.5へのアップグレード(rpmで)
http://www.softel.co.jp/blogs/tech/archives/2288
yumだったからか、私の場合は全く警告も出なかったけれど、データベースのダンプくらいは取っておくべきだったなと、今さらながらガクブル。ま、問題は出なかったから、よしとしよう。(mysqldumpしながら)