Information

さりげなく新しいトップページを公開 2012-02-05

新しいトップページの第一弾ができたので、テストを兼ねて日替わりトップページに組み込んでみました。

今日一日、G-ZONEの看板娘が、５代目ガールでお出迎えしていましたが、果たして何人の方が気がついたでしょうか。月曜日から、また４代目ガールがお出迎えです。

古いブログが表示されなくなっていた・・・ 2012-01-27

まったく恥ずかしい話。

古いブログが表示されなくなっていた事に気がついていませんでした。ログを見ると、ずっとSQLのエラーが出ていたようです。

perator does not exist: timestamp with time zone ~~ unknown

原因は、新しいサーバになってPostgresのバージョンが上がり、SQLランゲージの記述を厳格にしなければならなかったようです。具体的には・・・

SELECT * FROM table WHERE date_trunc('day',timestamp_data) LIKE '2011-12%'

などと書いていたところを

SELECT * FROM table WHERE timestamp_data::text 'LIKE 2011-12%'

と書き直して対応しました。

新年を迎えたけれど・・・ 2012-01-05

色々と積み残していることが多いなぁと反省する日々。

ログ集計は動かないので、じっくり腰を据えて取り組むことにしました。もっとも最近は、独自にログを集計する需要は無いと思います。何せGoogleでサイト内のアクセス統計を集計するシステムを無料で公開していますから。ただ、訪問してくれた方に、こんな感じで利用されていますよ〜という報告をするためには、独自に集計する必要があると思うのです。

G-ZONEでは、いくつも未実装＆未公開の機能があるのですが、今年もどこまでできるのか管理人にも良くわからないというおおざっぱな運用です。機能面もそうですが、看板娘のコスチュームも変更しようと思っていながら、なかなかできていない状況です。

思い立ったのは2009年の後半ですから、そこからなかなか手をつけられずにいます。その間に大震災もありました。しかし、進行を最も遅らせる原因となってしまったのは、３Ｄの作業に使っているコンピューターのディスクが壊れてしまった事でした。バックアップしていたデータは古く、作り始めたデータはバックアップにありませんでした。

このピクチャは、試作中にレンダリングした物です。日付を見ると2009年11月10日。このあと新年に間に合わず、そうこうしているうちにデータを失って、気落ちしている所に大震災。制作どころの騒ぎじゃなくなってしまいました。

ディスクの破損は大きなダメージでした。新しいコスチュームの他に、家やらアパートなどの小道具も失ってしまいました。他にも制作途中のクラン大尉も消えてしまったのは、大きな痛手でした。

その後、重い腰を上げたものの、ゼロからのスタート。とりあえず、メインのレオタードの制作から初めて現在は小物の製作中です。G-ZONEのマスコットガールは、言わずもがなウルトラマンをモチーフにしていますが、ウルトラマンが宇宙人の皮膚的なものを身にまとっていて、人類とは違う外観（とはいえシルエットは人間ですが）であるのに対して、巨人の女の子がコスチュームを身につけているという装い。あくまでも巨大化した人間がテーマなので、宇宙人的な要素はほとんどありません。

ここまで出来たので、このままお蔵入りということは無いと思います。今度はMacOSのTimeMachineで１時間おきのバックアップで万全の体制。あとは手を動かすだけ・・・これが難題かも。

ログ集計 2011-12-14

最近ログを全く見ていなかったので気がつかなかったけど、ログの集計プログラムが全く動作していませんでした。

BBSがアタックされて色々とプログラムをチェックしていたら、なんと、新サーバーに移行してからこっち、集計プログラムが動作していなかったというお粗末な状況でした。たぶんこれで直ったと思うけれど、明日の朝に自動で集計されるかどうか・・・

お粗末な管理人だということが、ばれてしまいました。

追伸：
まだ動かなかった・・・

久しぶりにBBSがアタックされてます 2011-12-13

ここんとこ、平穏だったG-ZONEのBBSですが、久しぶりにロボット攻撃されてます。

攻撃の発信元は中国ですね。とりあえず、どんな攻撃パターンなのか見定めて、先ほど対策しました。こてでしばらく様子見。

久々に緊張しました。

停電対策／停電で自動スリープさせる 2011-12-09

すっかり忘れていたけど、ハイバーネーションモードは１でなければ問題になるかもしれない。

ハイバーネーションモードは３種類。

・Sleep mode (hibernatemode=0)
・Safe sleep mode (hibernatemode=3)
・Deep sleep mode (hibernatemode=1)

ハイバーネーションモード＝３は、ノート型のようにバッテリーがある場合には、シチュエーションによって単純なスリープモードとディープスリープを使い分けます。サーバのようにバッテリーが無い場合は、ディープスリープになるはずです。

なので必ずディープスリープ（冷凍睡眠状態と表現する事もあります）に、設定してしまいます。設定するには、ターミナルを使って次のように入力し、パスワードを聞かれたら管理者のパスワードを入力します。

sudo pmset -a hibernatemode 1

修理前には、ハイバーネーションモードを１にしたはずですが、帰ってきたときには３になっていました。なんでだろう・・・それとも、設定していなかったのかなぁ。

ちなみに、マシンのハイバーネーションモードを確認するには、次のように入力します。

pmset -g

あとは停電を待つ・・・ではなく、停電にならないことを祈るばかりです。

ハードディスク故障 2011-12-07

サーバのハードディスクが故障したので修理に出しました。修理に出すことにしたのは、まだ今年購入したばかりのマシンで保証期間内だから、修理に出せば保証で治せるというメーカー側からの提案があったからです。

実は、ディスクが壊れたのは、今年の夏のことでした。

８月にRAIDを構成しているディスク２台中の１台が降格状態になりました。このときはディスクユーティリティを使って修復ができたのですが、その後９月ごろからしばしば降格状態になっては修復することが連続。いよいよ駄目かなと思っているうちにディスクをフォーマットすることもできなくなりました。

修理のためには、運用を止める必要があるのはもちろんですが、自力で直せば運用期間を短縮できるものの保証を捨てることになってしまいます。保証は購入時に有償で３年保証を付けましたので、この時点で保証を捨てるのはあまりにももったいなかったので、今回は数週間の運用停止もやむなしとしました。

運用を12月2日深夜に停止して、修理に出すためデータのバックアップを行い、メーカーへの発送は12月3日。しかしあっさりと修理が終了して12月6日の夜には、手元に戻ってきました。バックアップからデータを復元する作業が６時間ほど。チェックを終えて公開にこぎつけたのが、12月7日未明。結果的には５日間の運用停止でした。

今回は、RAIDとバックアップシステムに助けられた形となりました。最初の投資は悩みましたが、投資した分の価値はあったと思います。来年の夏に同じような故障が発生しないことを望みますが・・・

もう少しで１万レコード 2011-10-14

情報リストのレコード数が9500件を超えて、１万件に迫るところまできた。

１万件の情報というのがあるというのは、自分でも本当に驚いている。この１万件ものレコードを一人で入力してきたのかと思うと、今更ながら驚くというかあきれるというか・・・。しかし、これらのレコードが全て公開されている訳ではない。

全てのレコードが公開されていないのは、決して隠している訳ではなく、確実な情報として伝えたいからという思いがあるため、あまりにも不確実な情報は確認作業中ということ。もしくは、やっぱりガセネタだったという情報も、全て保管してある。ガセネタ情報も保管しおくと、またどこからともなく同じ情報を仕入れてきたときに、無駄に探すことがなくなり、結局、手間と時間を節約できるからである。

ところで、１万の情報の中には教えてもらった情報も多い。そして教えてもらった情報には、ほとんどガセネタはなかった。教えてくださった方には、本当に感謝している。

古いリンク情報が非表示に… 2011-10-05

古いタイプで記述されていたAmazonの商品へのリンクが、新サーバ移行後に全く表示されていなかった。古い情報を整理していたときに初めて気がついた。

プラグラムを修正したので、現在は問題は解消済み。

節電！前年比40%減 2011-09-02

新サーバに移行して、ひと夏過ごした結果、40%もの節電効果があることが判明。

最大の理由は、廃熱が少なかった事と、内部温度のモニタリングをした結果、クーラーでの冷却が不要だったことがあります。もっとも気温のピーク時には、ディスクの温度を監視しているシステムが何度か警告メールを送信してきましたが大丈夫でした。

監視プロセスが各種の温度を監視していて、設定温度に達するとメールを送ってくる仕組みです。設定温度は、普段は超える事の無い温度で、限界という事ではありません。警告メールが来たときには、リモートで温度をチェックして駄目そうなら緊急停止ということになりますが、そうした事態に至る事はありませんでした。

これなら、新サーバに移行した費用を節電効果で数年で元が取れそうです。思わぬ収穫でした。

すごいぞ Mac-mini サーバ！