ただつらつらと日記が書かれていくようです。
PHPの中間コードキャッシュ用のモジュールと言えば、いくつかあるが、ま、とりあえずAPCでも使ってみるかということで、ビルドしてapc.soを作って入れてみている。
そして、/etc/php.d/の下にapc.iniを作って、apc.soを読み込ませているつもりだったが、恐るべきことに「extension」と書いたつもりが「extention」とかなっていて、apc.soが読み込まれず。orzこういうスペルミスではまると、なかなか見つからないのが辛いところで、もう少しでAPCをビルドし直すところだった。
とりいそぎ、動き始めたAPCではあるが、いまのところ、割り当てるメモリ不足が不足してなさそうではあるけれど、この辺を監視してチューニングしたいと思っているけど…これまたなかなか面倒くさい(汗)
特に意味はないけれど、AWSのS3ってどんなんだろうということで、なぜかデジカメに残っていた画像をS3にアップロードしてみて、imgタグで表示してみるというベタなことをやってみるテスト。
【むかし、このへんにAWSのS3にアップロードされた写真が貼ってありました】
呼び出されるたびに課金されるのは切ないような気もするけど、ファイルの冗長性とか諸々を気にしなくていいのはもしかすると楽なことなのかも知れない。
ここだけの話だが、Windows2003 Serverってのがどうにも好きになれない。Windowsのクライアントネットワークがあるなら、ファイルサーバはWindowsサーバにしておくのが無難って時代も確かにあったけれど、Sambaもなかなか使い物になっているような気がする…のだが、とりあえず、Windows2003 Serverのお守りをしなくてはいけないようだ。
確かに、Linuxのシステムからのメッセージは全部英語だし、なにかとわかりにくいものもあるが、Windows2003 Serverの場合、もともと英語のメッセージをむりやりに英語に直したメッセージだから、これがなんともわかりにくし、Windowsならではのモジュール群がずらずらと並んでいるので、とりあえずちんぷんかんぷんってのが現状か。
そんな折、サーバのハードウェア、(特に怪しいのが)電源とかRAIDカードとか、HDDとかの障害でも起こったのか、Windows2003 Serverが動作しているマシンで突然の再起動がかかった。で、この画面である。
ごりごりとNTFSの論理チェックをかけてくれているようだが、HDDやRAIDカードのエラーだったら、行うべきはNTFSの論理チェックではなく、速やかなバックアップなのだが、一旦始まるとどうやら抜けられないらしい。というわけで、ラックにあるタワー型のDELLのPowerEdgeにモニターをつないでぼんやりとチェックの模様を見守った。
ふと、HDDのごりごりというアクセス音を聞きながら、クラウドだったらもっと楽なんだろうなぁとぼんやりと思った。
うーむ、どうやらkeepalivedのドキュメントは、あんまり気合をいれてメンテナンスされている感じではなさそうだ(最新版のVer.1.2.2をダウンロードして中身を見てる限りでは)
すくなくとも、man用に書かれたものと、keepalived.conf.SYNOPSISでは書いてある内容に違いが出てしまっている。
例えば、ロードバランシングの方法について指定する場合、「lvs_sched」って書いてあるのがkeepalived.conf.SYNOPSISで、「lb_algo」って書いてあるのがman用のファイル。どっちが新しいかというと、「lvs_sched」らしい。ってことはman用のファイルの内容が古いのか。おそらく、今のところのkeepalivedの内部ではどっちも許容することになっているんだろうけど、古い記法を使っていて将来のバージョンで使用不能になるのも切ないのでできるだけ新しい記法に書き換えておきたいような気もする。
あと、ネットで見かけるkeepalived.confのサンプルファイルによく書かれているのが「nat_mask」。keepalived.orgのUserGuideを見た感じでは、
If you are using Linux kernel 2.2 you need to specify the NAT netmask to define the IPFW masquerade granularity (nat_mask keyword).
って書いてあるから、そもそもKernel 2.6が普通に使われている現代では必要のないはずの設定項目なんだけどなぁ、とか。でも、なんとなく削る勇気がなくて残存させてみるテスト(汗)
さて、DNSサーバをどうしたもんだか、ぼんやりと考えている。Webでサービスを提供するための前提条件みたいなものだから、非常に重要…ではあるけれど、冗長構成が前提なDNSサーバーがどうにかなって困ると言うことはあまりないせいか、その重要性が理解されづらい。
また、DNSサーバに求められる要件も特段ややこしいことはなく、普通に落ちない鯖であればokで下手なハイエンドマシンなんかもったいない…そんな感じがDNSの存在を埋没させてる気がする。
要するに、いちいちサーバを用意したりするような手間はかけたくないが、ちゃんと動いてて欲しいのがDNSサーバーと言うことになる。
そう考えてみると、極めて簡素にDNSだけ預かりますってサービスに預けてしまうのが手っ取り早いが、フツーのレンタルサーバサービスではDNSだけってサービスは意外と提供されていない。そこで、クラウドである。
AmazonのAWSで提供されている「Route53」っていう名前のDNSサービスが、まさにそのサービスだった。しかも、しばらく前まではAPIしか提供されていなかったのだが、改めてWebの画面が提供されたことで簡単にゾーンファイルを編集できるようになった。
しかも、「Route53」は、世界各地のAWSの拠点において、anycastで提供されているわけだら、ネットワーク的な遅延なども少ないし、冗長性も確保されているだろう。しかも、1ドメインが$0.5くらいで提供されているというのがまた魅力的だ。いくつかのドメインを持っているとしても、「Route53」と単純に価格比較したら、わざわざDNSサーバを購入する妥当性は生まれてこないだろう、という気がする
いやー、HPのサポートサイトってなんだか使いづらい。
例えば、「Proliant DL120G6」を使っていたとして、サポートサイトで製品名で調べてみると、いろんなスペックの「Proliant DL120G6」がずらっと出てくるんですな。もちろん、BTOでカスタマイズされている可能性は高いので、いろんなドライバを提供する必要はあるとしても、製品名で検索したときにズラズラと出てくる同じサーバのどれをクリックすればいいのか、というのはなかなか難しいのは私だけでしょうか。
しかも、その先で提供されているドライバ群がビミョーに違っているので、間違った選択肢を選んでしまうとややこしいなぁ、と。(時々、RHEL6のx86_64版が提供されてなかったりして戸惑う次第)
…まー、アメリカのHPの使い回しのサイトなのでカスタマイズするのは難しいかもしれないけれど、なんとかして欲しいなぁと思うなぁ。いやはや。
もう何個目なんだろうと思いつつ、またWordPressに頼ってしまう、この感じ…(汗)
井上 理津子著 「大阪 下町酒場列伝」読了。
まず、表紙のおっちゃんが、おそらくはチューハイであろう飲み物のグラスを手にして飲み干してる様がなんとも良い感じ…ではあるのだが、この本は、筆者が月刊「大阪人」で連載していた記事(この「大阪人」もまた興味深い雑誌ではある)を文庫本にしたもの。
大阪の「居酒屋」ではなく「酒場」は、また関東の居酒屋とはまた違った雰囲気があって、どの店にも行ってみたくなる。それも、観光客としてではなく、大阪に住み着いて通いたくなる、そんな「酒場」ばかりである。それも、どのお店にも開店にまつわるエピソードがあって、それぞれ人情味にあふれていて、単純に「酒場」がどうこうのはずが、立派なノンフィクションができてしまいそうな、濃厚なドラマが背景にあるのがまたおもしろい。
しかし、文庫本にするにあたって、掲載されている酒場が今どうなっているかを筆者が調べて回ったのだろうか。それぞれのお店の記事の末尾に「XXXX年閉店」のような形で追記がなされている。この筆者のマメさが活かされている記事は、酒場の細かいところまで観察されているがゆえに、私のようなアマチュアの酒場ファンの心を惹きつける。
しかし、その「現在」の記述は、いつか大阪の「酒場」に行ってみたいと思う、淡い願望を打ち砕くものが多かったのが残念。実際のところ、戦後から始めた酒場、それよりもずっと前に営業していた酒場でも、後継者問題は割りとシビアなようで、大将や女将さんの引退を契機に店を閉めてしまうケースが多いようだ。例えば、もともとは由緒正しい天ぷら屋さんだったお店を、きれいさっぱり「酒場」にリニューアルしたお店が紹介されていたけれど、本を読んで訪れるだけの観光客予備軍としては、”そんな感じ”でうまく酒場を継承していって欲しいような気もする。
でもまぁ、「酒場」のドラマによれば、偶然のように開店したお店も少なくないから、後継者がいなくて閉店というのも風情があっていいのかもしれない。歴史と伝統といった肩肘張った感じとは無縁なのが、大阪の「酒場」の魅力の1つだとすると無理やり継承されるのもまた違うのだろう。
そういえば、先日、実家に帰省するついでに1泊2日で大阪に立ち寄る形で大阪プチ旅行を楽しんだ。そのプチ旅行で天神橋筋商店街を散歩したのだが、天神橋筋商店街の入口辺り、天満駅前あたりだっただろうか。平日にもかかわらず、駅前の立ち飲み屋が正午あたりからごった返していた。さすが、大阪だと思った。関東の辺りだと正午から開いてる居酒屋自体をそんなに見かけないし、もし、見かけることができたとしても、だいたいごった返してない。大阪はきっと「酒場」天国に違いないと確信した。そんな記憶があるから「大阪 下町酒場列伝」というタイトルに萌えてしまったのは確かだ。
そんなわけで、今度、大阪を訪れるときには、「大阪 下町酒場列伝」を片手に、大阪の酒場を覗きにいきたいような気がする…けど、常連さんがごった返す店内をちらっと眺めて、ちょっと躊躇するんだろうな(汗)そして、なんとか店内に入り込んだとしても常連さんに話しかけられてビクッとしている様が容易に想像できる。やっぱり大阪の「酒場」は遠いような気がする。
FPSの「Battlefield3」がリリースされるっていうので、なんとなく買ってみた。で、とりあえず、キャンペーンモードをやってみたので感想を書いておく、と。(以下、ネタバレ注意)
確かに、FPSのエンジンの完成度は高いような気がするし、マルチプレイとか面白そうな気がする。けど、空いてるサーバもないし、とりあえずキャンペーンモードで遊んでるしかない状況だと、シナリオとか細かい設定で切ないことになる可能性はあるかなぁ、と。Call of Dutyっぽく、スーパーマンの如く、撃って撃って撃ちまくってランボーの如く、死線を走り抜ける的なFPSなんですかね、BF3って。
今日の昼頃、会社で使っているGoogle Appsのメールアドレスにガラケーからアクセス出来ないとの一報をもらった。一報をもらったのが駅のホーム。今から関連会社に打ち合わせしに出かけるんだけど…ということで、手元にあったFOMAからimodeブラウザを使ってアクセスしてみたものの、確かになんだかおかしい。一応、何回もリダイレクトがかかっているので、認証自体は行われているようだけど、結局、最後には302が返ってきて、メールが表示されないといった症状。うーむ。昨日までは、Google Apps向けにホスト名を設定していて、そのURLからアクセスできたのになぁ。
とりあえず、出かけて仕事を終わらせて戻ってきて、パケホーダイの端末を借りてもう一回試してみたけど、症状変わらず。どうやら、Google側の障害って感じではなさそうだ。
一応、Google先生に聞いてみたら(Google Appsの問題点をGoogle先生に聞くのもなんかへんな感じだったけど)、いくつかの可能性を見つけることができた。
1つは、imodeセンターにIPアドレスが追加されたけど、それをGoogleが認識してないので、imode端末からアクセスしたときに、FOMA端末だと認識してくれないので認証エラーが出るという説。その仮説に乗っかれば、何回もアクセスすれば、すでに登録済みのプロキシーを通ることもあるはずだから、何回に1回はうまくいったりする…ことがあるような気がするが、さっぱりうまくいかない。この仮説の可能性は低そうだ。
…そこで、Googleからメールが来ていたことを思い出した。Google Appsの移行だったかな、と(汗)これまではGoogle AppsのアカウントはGoogleアカウントとは別に管理されていたっぽいけれど、Googleアカウントに統合するっぽい感じだろうか(大汗)
それで、なんとなーく、普通のGmailのログイン画面(http://www.gmail.com)を開いて、Google Appsのアカウントでログインを試みたら、すんなりログインできた…あー、そういうことなのか。FOMA端末からは、Google Apps用に用意したログイン用のURLが使えなくなってGmailのログインURLからログインしろってことなんだろうな。(PCブラウザからだと、Google Apps用のログインURLは有効なんだけど、ログインの過程でリダイレクトされてるっぽい)
まぁ、実はテスト用に使ったFOMA端末のimodeブラウザがCookieを許容する設定になっていなくてログインがうまくいかず、それなりハマったんだけど、長くなるので割愛(汗)
うーむ。なんだかよくわかんないけど、アクセスできるようになったので…一件落着ということにしておこうかな、と。なんかこのへんのドキュメントって転がってるんだろうか。
© 2025 ただのにっき。
Theme by Anders Noren — 上へ ↑