あー、仕事おわんない

rural_am00d
仕事がおわらんです、先生。いやまぁ、終わるような仕事をやっているわけでもないんだけど。とりあえず、今やっているボクの仕事を何となく書き出してみる。

  1. 自分の企画のあらすじとシナリオ
  2. 通販対応
  3. ブランドの接触窓口
  4. 外注折衝(背景、CG、プログラム、スクリプト)
  5. ウェブ更新
  6. 社内サーバ(HTTP、FTP、メール、Redmine、BTS、DB、SVN)
  7. ソフ倫対応
  8. 他、事務仕事(予算管理とか、出納管理とか、スケジュール表作ったりとかいろいろ)

おふー。2、3、4、5、7 をどこかに追い出したい!
いや、書きたいことはそういうことじゃなくて、なんでそもそもボクの抱えている仕事の話になったかというと、以下のサイトを知ったからなのだ(18 禁サイトです)。

どちらもよく出来てるのよねー。
気になったのは、これらのページって、メーカーの人が片手間に作ってるのかなぁってこと。もし片手間に作ってるんだったら、まだまだボクの仕事スキルが足りてないんじゃないかと……。誰かウェブ系担当者がいるなら、これくらいは逆にやらないとって感じなんだよね。
下のは Flash なんだけど、上は HTML5 で組まれててイイ感じ。ボクも時間があれば、これくらいやりたい。
なので、ウェブ更新を誰かにふる場合、HTML5 がカリカリ書ける人がいい! けどそういう人って、エロゲ業界に来てくれない気がする。となると、上のサイトって誰が作ってるんだー??? 気になる!!

そんな、どうでもいい話でした。

回線切れた

20 時過ぎ頃、突如、自宅サーバにつながらなくなった(その時のツイート)。
ざっとプロバイダと NTT 東日本の障害情報をみたが特になにも……とおもったら、あった。

というわけで、待つしかないカー、と思って待っていたのだが、同じエリア内の知人に聞いて見たら、もうつながるとのこと。なんだと? 再接続がうまく行ってないのか?
仕方がないので、いったん家に戻る……orz
ルータを見てみると、ずっと接続された状態になっている。
おそらく、一瞬だったんだろうな。で、ルータ的には切れてないみたいな。
いったん切断して接続し直したら、つながった。
うーん、やっぱ ping とかでチェックして、一定時間つながらなくなったらルータを再接続するようにしたほうがいいのかなぁと思いつつ。

ご迷惑をおかけしましたm(_ _)m

WAKWAK に帯域制限された

bs_ruri01d
出版社から、ウチのブランドのサーバ(HTTP)につながらないという問い合わせがあった。なんだなんだと自宅からアクセスしてみると、異様に重い。調べて見ると 500bytes/sec しか出てなかった。なんだこれ、サーバがなんかおかしくなったか? と思い、FTP を試すと普通に 1MBytes/sec 以上出る。さらに VPN 経由でその出版社がつながらないと言っているアドレスに接続すると、普通に接続し、同じく速度も 1MBytes/sec 以上出る。

あー、帯域制限だ。

んだよ、WAKWAK の法人、転送量無制限だった気が……。
この出版社がつながらないと言っている TCP ポートは出版社のみならず、外注も含め様々な人が使っているので、確かに通信量はかなり多い。

そもそもさ、WAKWAK って 20 時頃から激重になるんだよね。それが日付変わった深夜 2:00 頃まで続く。とてもストレスだったのよね。そしてこの仕打ち。WAKWAK ってバックボーン、しょぼいのかなぁ? それとも単純に会員数が多いのか……仕方がないので転送量無限のプロバイダを模索し始めた。

もう一つ WAKWAK に不満なのが帯域制限の期間が長いこと。この帯域制限、4/2 に始まって解除されたのは 4/6 だった。ボクが自宅で Asahi ネットを使っていた頃、帯域制限を喰らいまくってたんだけど(爆)、その時は長くても 1 日だった。だから 1 日我慢すればよかったんだけど、仕事で使っている回線を 5 日間近く制限されるのはかなりつらかった。
というわけで、WAKWAK は使えないなー。やっぱり OCN かなぁ。OCN の法人はまったく帯域制限されたことはなかったので、個人的には気に入ってるんだよね。ただし 1 ヶ月 1 万円もかかるけど(汗)。

事務所のサーバの RAID が飛んだ

3/12、一週間前の出来ことです。事の発端は、16:35 、事務所のサーバの D ドライブが消えたという報告だった。それを受けてもう一人の管理者がサーバの再起動をしたが、D ドライブは復活しなかった。ディスクの管理を呼び出してみると、「ミラーリングの同期エラー」だった。なんだこりゃー、HDD 逝ったか!? つーても買ったの去年の 10 月やで! まだ5 ヶ月しか経ってないやん。
ということで、とりあえずミラーを分離。片方のドライブが、もう片方のドライブの半分しか容量を使ってないwww
これはヤバいと言うことで、とりあえず容量が半分の方を一度フォーマットし、ミラー再構築するも、わりとすぐにエラーで D ドライブが消えた(ミラーの同期に失敗すると、書き込みからの保護のため、Windows はミラー・ボリュームを OS 上から切り離してしまう。別にデータが消えるわけではない)。
こりゃー完璧に HDD が壊れたな……と判断し、ミラーを解除したら今度は正常なドライブまで読み出せなくなった。
これには一瞬焦ったが、プロパティを見るとちゃんと空き容量と使用容量が変わらずに残っていた。そこでこの HDD を別のマシンにくっつけると、無事認識。データは読み出せた。

ん~……こりゃ一体何だ?
ってネットを調べたら、すぐに答えが出てきた(ぁ

ちょwwwwマジスカwwww!!!!!
っていうか、RAID に使っちゃいけない HDD なんて存在してたのか!?
って知人に何となく聞いて見たら「あぁ、噂は知ってたから WD の Green は避けた」とか言いやがった。うそーん! ボクの情報収集不足かよー!! 悔しいっ!! キ─────!!!
もっともこれが原因かどうかは分からないが……でも現象的にはそんな気がする。
そもそもどちらの HDD も異音はしないし、他のマシンにつないでもちゃんと読み書き出来る。

仕方がないのでミラーとして使っていた HDD を、それぞれのシングルの HDD とし、容量の半分しかミラー出来ていなかった HDD を改めてフォーマットし直して、そっちにバックアップ。新しい RAID に対応した HDD を買うまで、HDD 1 台で運用することにした。バックアップした方は取り外して、とっておく。
なんだかんだで復旧したのは朝の 5:54 であった……。まーほとんどバックアップの時間だけどね。ほぼ 2TB つかってたんだけど、それのコピーに 8 時間以上かかったっぽい。きっついなぁ……。

StatPress Reloaded

WordPress のプラグインで、アクセス解析というのがあったので入れてみた。名前は StatPress Reloaded。ただこれはあくまでも WordPress のアクセス解析なので、WordPress に来た分しか録れないが。まぁでも面白そうなので。ところがけっこう情報が古い。どういう情報かというと、OS やブラウザが 3 年ぐらい前で止まっている。あと日本の検索エンジンにまったく対応していない。
というわけで設定ファイルを書き換えて、Docomo や Sleipnir 、livedoor、Yahoo Japan、Rakuten などに対応させた。これは、seachengines.dat を書き換えればよい。

Yahoo|search.yahoo.|p|
Yahoo|search.yahoo.|submit|
Rakuten|websearch.rakuten.co.jp|qt|
Docomo|search.smt.docomo.ne.jp|MT|
Bing|www.bing.com|q|
Bing|bing.com|q|
Sleipnir|search.fenrir-inc.com|q|
Conduit|search.conduit.com|q|

Windows 7, 8 に対応したい場合はos.dat を

Windows 8|WindowsNT6.2|
Windows 7|WindowsNT6.1|

のようにすれば OK。
ただ、この StatPress、痒いところにはなかなか手が届かないようで、出す情報も少ない。この辺、もっといろいろ表示出来ると良いんだけど。まぁだいたいダイジェストって感じ。ただ、訪問者の追跡(どのページを最初に見て、その後どのページを見ていったかなど)がけっこう楽なのが面白い。ブログだとそういう遷移が解った方がイイのだろう。
stat_view

アリスソフトさんのアレ

2 月に起きたアリスソフトさんの件について、色々とこちらのサーバの構成を変えるべきかも知れないと思ったので日記に記す。例の事件の時もボクは大忙しで、この事件の詳細については調べる時間がなかった。ただおおむねざっと情報を横断したところ、納品先に渡すためのダウンロード・ディレクトリが洩れてしまったというのが原因の様だった。
これはどういうことかというと、ファイルをやりとりする際、こちらから一方的に送るだけの場合、利便性も考えてブラウザで落とせるようにするのが一番よい。そのため、ウェブサイトのどこかにそのデータを置き、そのデータのアドレスを相手に知らせて、ダウンロードしてくださいね、とやるのである。
この方法は実に便利で、この amatsukami.jp サーバにもある(爆)。こう言うことを書くのは非常によろしくないのだが、とは言え、まったく書かないと話が通じないので、バラしてしまった。とにかくあるのだ。主な用途は成果物の納品や、雑誌社さんに渡す素材などだ。しかも利便性を優先して、パスワードはかけていない。
そしてこの仕組みはもう 10 年以上、使ってきている。
バレないという保証はないが、いくつかのステップは必要である。

  1. ダウンロード・アドレスの特定
    どの URI からダウンロード出来るのか、知る必要がある。基本的に外部からは推測して当てるしかないが、おおむね想像がつくことも多い。たとえば、DL や Download っていう単語が入っていたり、アップローダ的な使い方をしていれば、Upload や UL、UP など。他にも Send とか To とか From とか、その手の単語は推測されやすいかも知れない。
  2. ファイル名の特定
    ダウンロード・アドレスが解っても、ファイル名が解らなければダウンロード出来ない。というのも、ダウンロード・アドレスを指定しただけでは、404 エラーなどでハネられてしまうからだ。但しここで注意が必要なのが、ファイル名ではなく、ディレクトリが指定されると、そのディレクトリにあるファイルを返してしまうという設定がある。これが ON になっていると、目も当てられない。ダウンロード・アドレスに置いてあるすべてのファイルが見えてしまうからだ。

というわけで、上の二つの名前が分からなければダウンロードはできない。そして基本的にこのダウンロード・アドレス+ファイル名の URI を知っているのは、ボクが「ここからダウンロードしてくださいね~」って教えた相手だけのはずなのだ。だからその人が漏らさない限り解らないし、Google などの検索エンジンに乗ることもない。

今回のアリスさんの場合、なんと Google で検索すると出てしまうらしい。
ここがボクはよく解ってないのだが、当事者同士のやりとりなだけのはずなのに、なんで Goolge に載ったんだろうってことだ。もう検証サイトとかできてるのかな。もし情報を持っている人がいたら教えて欲しいです。考えられることとしては、忘れないようにか、何かの理由で、URI をどこかに貼り付けておいたのが、Google に収拾されてしまったか、たまたま URI の推測に成功した人が、どこかの掲示板か何かに載せたか……でもそんなことってあるのかなぁ??

というわけでこのようなことが起きたため、ボクもダウンロードについてはどうしようか今も考え中である。まずは、一定期間経つと、そのダウンロード・アドレスに置いたファイルは削除する様にした。もともとダウンロード用のデータというのは自分の手元にマスターがあり、それを ZIP なり CAB なりで圧縮して渡しているので、ダウンロード・アドレスにあるファイルはなくなってもかまわないものだ。なので、ファイルの更新日付をチェックし、一定期間が過ぎたファイルについては自動的に削除するスクリプトを組んだ。
さらに今後対策していこうと思っているのは、以下の通りである。

  1. ダウンロード・アドレスをランダムに生成する
    ファイルを用意するたびに、ダウンロード・アドレスはランダムに生成する様にする。もしくは、相手先それぞれにダウンロード・アドレスを用意する。この際、ワイルドカード サブドメインも利用すると、より複雑になると思われる。
  2. ファイル名もランダム生成する
    ファイル名もランダム生成し、推測できないようにする。
  3. IP 制限をする
    提出する相手はだいたい会社が多いので、固定 IP を引いているところがほとんどだ。なのでそれ以外からはアクセス出来ない様に IP で制限してしまう。

1 と 2 についてはちょっとスクリプト(今なら PHP)を書く必要がある。
どちらにせよ、数ヶ月以内には対応しないとダメかなーと思っている。

WordPress あれこれ

某サイトをガリガリと作っていた。そのうち TAMA Networks でも挨拶する予定なんだけど、とりあえずサイトを紹介。

どれも WordPress で構築されている。
これらを組んだおかげで、WordPress で自由奔放にサイトを構築出来るようになった。Galette のサンタフル☆サマーのサイトも WordPress である。でも失敗しているところも実はあったりして、例えば GLacé のメニューはパーマリンクが失敗していて、カテゴリ ID が丸見えだったりとか(汗)。これは Windows Server だと rewrite がうまく動かなくなってしまった部分があって、仕方なくこうなっている(汗)。他にも相対・絶対ディレクトリの指定間違いとかがあったりして、そのたびに「あわわ」と慌てたり……いや、ちゃんとチェックしろよ(汗)。

スタッフ・ブログはいわゆる投稿ページで構成されているんだけど、サンタフル☆サマーはすべて固定ページで構成されている。スキンの方に PHP でページ名を判別して、レイアウトを変更している(現在の所、年齢認証、トップページ、その他の三つ)。GLacé 本体のサイトはトップページが固定ページで残りのページは投稿ページを使ってお知らせやダウンロードなんかを構築している。
スタッフ・ブログが一番 WordPress らしい使い方である。

なんでベタの HTML で組まなかったかというと、前の日記にも書いたような気はするけど、WordPress で構築しておけば、HTML が書けない人でもあとから更新出来るからってのが大きなメリットだったんだけど、実際に作ってみるとけっこう HTML の知識が必要だということが解った(爆)。特にサンタフル☆サマーのサイトはほとんど HTML ベタうちでつくってある(汗)。ただ、一応ボクが組んだヤツをコピペすればいいようにはしたんだけど……うーん、難しいなぁ。というのも、実は WordPress のエディタだけで作れないこともないんだけど、エディタ上で組むと、<div> や <span> を無視して改行されてしまったり、画像を挿入されてしまったりしてなかなか使いづらい。せめて <div> とか各段落ごとにうまく区分けして編集出来るようになってれば、WordPress のエディタでもいけそうなんだけどなぁ……。

ところで今回苦労したのが IE9 。とにかく IE9 だと、位置がずれるずれる。
基本 IE10 で作って、Google Chrome で確認してるんだけど、この二つはほとんど差はなく作れたんだけど、IE9 だと凄いずれる。主な原因は、Absolute。特にサンタフル☆サマーのトップページは重ねが多いため Absolute の嵐なのだが、right や left を設定してないと、親の ID(もしくはクラス)の text-align に左右されてしまうのね。本来座標を設定してないと、親の左上が起点になるはずなのだが、IE9 だと text-align で center とか設定されていると、親の真ん中の座標を起点に配置されてしまうのね……。もー。
あと CSS の座標指定を間違えて、 px じゃなくて x って書いてしまったところがあったんだけど、IE10 や Google Chrome ではそれを px として解釈して意図した位置に表示されたんだけど、IE9 では解釈してくれなかった。ところが HTML 側の表示順序を変えたら、意図した座標に表示されたりして、なんだこれw。
ただ IE9 は Windows 7 にデフォルトでついてくるブラウザなので、あんまり無視出来ないのよね。ちなみに IE8 や IE7 では確認してない(ぁ たぶん正しく表示されないような気がする。

まー、そんなこんなで、まだまだ WordPress、というか CMS を使ってサイトを簡単に構築する方法の模索は続きそうだ。
wp