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;
…
…
}
もし同じ症状の方がいたら、参考までに。
順番が逆になったけど、SaaSes Industria Smallの初期状態とかいろいろ。
申し込んでから利用できるまでには、10分程度の時間しかかからなかった。さくらのVPS よりも早かったかな。急いでいる時にはありがたいかも。
デフォルトでは必要最低限のサービスしか立ち上がっていないため、特に各種設定ファイルを編集しなくても問題なさげ。初期ブート時で400MB程度メモリの空きがある。
初期状態では22番ポートしか開いていないので、セキュリティ面でもまだ安全なほうか。現時点ではCentOS x64のみ選択できる。yum check-update したところ、全てのパッケージが最新で、更新が必要な物はなかった。これには好感。
あとは さくらのVPS でもやったように、sshdのポート番号を変えたり、iptablesの設定を変えたりといった感じ。
あとは今回、nginx を利用したWebサーバーにする予定なので、その辺りの設定などをまた別記事にでもまとめます。
個人向けの提供を待ちきれず、知人がやっている会社でIndustriaを申し込んでもらい、試してみた。
早速使用してみたところ、もともとのXenを動かしているサーバーの時計が狂っているのか、18時間ぐらい前の時刻になっている。
Xenはホストとの間で自動時刻調整されるため、普通に時刻合わせをしてもダメなので、以下のようにした。
/etc/sysctl.conf に以下の行を追加して再起動する。
xen.independent_wallclock = 1
その場で変更したい場合は、rootになって以下のコマンドを打ってやる。
echo 1 > /proc/sys/xen/independent_wallclock
そのあとで
/usr/sbin/ntpdate ntp1.jst.mfeed.ad.jp
とすれば、正しい時刻が反映された。
ただ、再起動するとホストOS側の時刻に再設定されてしまうので、/etc/rc.d/rc.local あたりに、
/usr/sbin/ntpdate ntp1.jst.mfeed.ad.jp
と追加で書いた。これで再起動しても、常に時刻は正しく設定されるようになった。
余談だが、Industriaのデフォルトではntpが入っていないので、
yum install ntp
として、事前にインストールする必要がある。XenのホストOSと時刻が同期するから不要という事かもしれないが(さくらのVPS にはデフォルトで入っている)、ホストOSの時計が狂っていたのでは意味がないので、ホストOS側の時刻は正確に保っていただければと思う。
前は勉強会とか、いろいろなところで会社の名刺をそのまま配っていたんだけど、退社したし、その頃から個人用名刺を配っている人がうらやましかったので、自分でも作ってみた。
とはいえ金もないので、何より価格が安いところ、ということで探し当てたのが、マヒトデザイン様。
片面モノクロ100枚で380円とか、コストパフォーマンス良すぎ。今回はお試しも兼ねて、両面モノクロ100枚にしたので、490円+メール便送料180円で670円。
昨日の16時過ぎに発注して、代金を今朝振り込んだら午前のうちに発送完了とか、仕事早すぎ。こちらが送ったデザインデータの確認に何時間かかかったっぽいけど、それでも早い。当日14時までの入稿なら、その日のうちに発送しますってWebサイトに書いてあるけど、この対応速度を見ると嘘じゃないなーって感じ。
あとは実際の出来次第かな。多分2日程度で届くだろうから、楽しみに待っていよう。
ちなみにデザインはこんな感じ。一応自力で初めて本格的にIllustratorいじって作った。何となく日本語使いたくなかったから、全部英語にしたら何となく残念な感じに。次はもう少し頑張る……。
数年前にも一度これで悩んで、最近再び同じ事で悩むハメになったので、今度こそ忘れないように記録しておく。
ぴろり様が作成された、以下のスクリプトを改造して自分のサーバーのデータ領域とMySQLの両方をバックアップさせるようにしたのだが、このスクリプトはさくらインターネット用に作成されたものであるため、FreeBSDベースのものだった。
MySQLのデータベースをダンプして圧縮して90日間分保存するスクリプト
http://www.magicvox.net/archive/2009/02172054/
そのため、私が使っているさくらのVPS(CentOS) では date -v というオプションが存在せず、バックアップは正常に取れるものの、自動削除がうまくいかない。これをLinuxで利用できるように修正したときのメモ。
date -v -"30"d
というコマンドは、30日前の日付を求めるコマンドとなるが、これはLinuxだと
date --date="30 day ago"
と置き換えられる。
上記スクリプトでは、
RMFILE=mysql.`date -v -"$KEEPDAY"d +'%y%m%d'`.gz
という行を、
RMFILE=mysql.`date --date="$KEEPDAY day ago" +'%y%m%d'`.gz
とすることで、エラーもなく正常動作するようになった。
以前からTwitterでつぶやいたりはしていましたが、同人に関するニュースをまとめたサイトを作成いたしました。
各ニュースサイト様を巡回し、同人に関するニュースを集めてデータベース化するサイトです。
同人ニウス中の「このサイトについて」でも書いていますが、主に私の老化現象への対応策として作成いたしました。
また、広告成分が多めではございますが、各種広告の組み合わせや表示方法など、ノウハウ蓄積の手段としても個人的に役立ちました。いろいろと試す中で、多少のノウハウは貯まったかなと思います。いずれこのブログなどで、その辺りも公開できればいいかなーと。
当サイトともども、同人ニウスもよろしくお願いいたします。
ドメインキング から、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の設定のせいだったって可能性は高いのですけど、本当にそれだけだったのかなーと悩み中・・・。こういう、時折起こるって感じのトラブルはやっかいですねえ……。
以前から借りていてサイト作成はしていたものの、ちょっと放置気味だった ドメインキング に、同人荘 – doujin.so! のトップページを移行したときの設定とか。
将来的にサブドメインだけ残して、他のサービスを使いたくなった方のお役に立てれば幸い(そうならないようにしていきたいとは思いますが……)。