メニューが変わってて、オーストラリア産牛肉をどーんと力説するような文言が加わってました。やはり吉野家の牛丼復活に対する牽制でしょうなあ。
ログ確認したら9月16,17日だけでd169.gtokyofl28.vectant.ne.jpから30万件アクセスがあって吹いた。なにこの鯖イジメ。vectant.ne.jpは永久追放で。
思い出したようにrkhunterというrootkit検出ユーティリティをサーバーにインストールする。インストールは簡単だが、主要rootkitとバックドアのチェックをやってくれるらしい・・・openSSLライブラリが古かった模様(滝汗;さっそくバージョンアップする。その他の脆弱性はとりあえずない模様。まあ定期的に実行せなあかんね。
/usr/local/bin/rkhunter -c -sk --createlogfile
ちなみにぱぱネットの皆向けに解説しておくと。rootkitってのは、相手のサーバー上で怪しまれないように作業をするために各種コマンドを改竄したり、再度侵入しやすくするための穴(バックドア)を開ける一連のツール群のこと。これをクラッカーにインストールされてしまうと、俺がタスクマネージャみたいなもので怪しいプロセスを発見しようとしても怪しいプロセスだけ表示されなくなるように改竄されちゃうというわけ。
なにせ管理者に分からないのだから長期間やりたい放題の状況を作りだせる。他のサーバーへの侵入の踏み台として使ってもいいし、データ読み放題吸出し放題。キーロガーをインストールしておけば、そのサーバーにログインしてくる全てのユーザーのパスワードもわかるという寸法。
ま、こういう性格上、どんな優秀な検出ユーティーリティを使おうが、一度でもインストールされたら基本的にクリーンインストールしかないわけだ・・・・
というわけで10月中に、1回フルバックアップをとるため1日以上サーバー停止しますのでヨロシク。
本当は会社行こうかと思ってたんだが、やっぱり休んだ。 以前みたいに無理をして精神を害すると元も子もないので。
先週、新人君の研修の一環で特許書いてた。 アイデア出しから提出までってやつ。 本文は俺がかいた以前の特許を少し変えたもの。 新人君には、図版の訂正と、特許調査を頼んだんだが・・・ 果たして提出できたかなあ。激しく不安だ。
_ 最近忙しくて、ご飯だけは炊くけど、後は出来合いのおかずばかり。 カロリーコントロールもおざなりだったので久々に自炊。
塩、ローズマリー、ニンニクスライスをぺたぺた したカジキを常温で20分放置。オリーブオイルで両面焼いて、最後に 白ワイン少々。これだけ。付け合せは、キャベツと青ピーマンを 塩、胡椒、砂糖、レモン、白ワインで軽く煮たもの。
うーん・・・味うっす!(笑)今回は220KCalくらいかな。 ラタトゥエの冷凍でも あればそれをソースにしたかった。 生クリームベースもいいかもしれない。
たまっていたレシート類を整理して家計簿つけたり。
各方面の努力によりリポジトリが整備されているのですごぶる楽である。 ffmpegはhttp://rpmrepo.org/RPMforge/Usingから、
# wget http://packages.sw.be/rpmforge-release/rpmforge-release-0.5.1-1.el5.rf.i386.rpm # rpm -Uvih rpmforge-release-0.5.1-1.el5.rf.i386.rpm # yum update # yum install ffmpeg
でOKであった(libx264 enabled!)。
djb daemontoolsなどはhttp://download.opensuse.org/から、
# wget http://download.opensuse.org/repositories/home:/weberho:/qmail/CentOS_5/home:weberho:qmail.repo # cp home\:weberho\:qmail.repo /etc/yum.repos.d/ # yum update # yum install daemontools # vi /etc/inittab # ( v1:12345:respawn:/usr/bin/svscanboot 追加 ) # telinit Q
でOKであった。便利便利。そしてServerMans@VPS、案外速いのである。こういう細々とした作業では。
ttserverをコンパイルしてdaemontools経由で起動したところで....
突然のメモリ不足でlsコマンドも動かなくなった(T_T)...... 久しぶりに「echo *」とか駆使しちゃったよおいいい..... しばらくすると使えるようになったがDBプロセスが落ちた...
OpenVZのWiki を読むと、システム全体のメモリが足りない状態でも 最低限保証されるプロセスメモリページ数がoomguarpagesのbarrier値 らしいのね。さっそく確かめてみる。
# cat /proc/user_beancounters Version: 2.5 uid resource held maxheld barrier oomguarpages 6506 16048 26112
......
...えーと26112*4096/1024/1024だから....
えっ?!最上位1980円のプランでも1プロセス当たり102MBしか使えないの? 計算間違ってる?俺。こんなんJavaVMはおろかそこらのRubyプロセスだって殺されちゃう数値だぞ。
値の根拠は何となく理解......490円のエントリープランはメモリ256MB。 その約半分が102MBというわけだ。もしかしてOpenVZってOOMKill設定はホストOSで共通なのかな。 エントリーを何十人分もごっちゃごちゃに詰め込んだサーバに、プロも突っ込まれてると予想....
こういうことを書くとすぐ「ループするテストプログラムかいたけど1GB以上確保できたぞ!」 「DTIは悪くない!」とかいう人が出てくるので、もう少し詳しく説明しよう。
OOMKillっていう仕組みは、図にするとこういうこと。
ユーザーごとに(ゲストOSごとに)起動できるプロセスの総メモリ量は、 当然プラン別に公開されている値で、運がよければそこまで確保できる。
システム全体(ゲストOSを格納しているホストOS)のメモリ使用量がしきい値を越えたとき、ゲストOSのプロセスを殺してメモリを確保する。いわゆるOverCommit状態の解消というやつです。 このとき、OpenVZは、ゲストOSの oomguarpages barrier値未満のプロセスを優先して残す らしい。 言い換えればデータベースサーバみたいに、cputime(稼働時間)は短くても 大量のメモリをコミットするプロセスは即座に殺される ってこと。結局ナニがおきるかというとゲストOSで見えているメモリが十分足りているはずなのに「なんか突然プロセスが死ぬ」ように見えるってことです。本当にnot alloc memoryのときに(緊急避難的に)殺されるのならたいした問題じゃない。どこが閾値かユーザにはまったくわからないまま、突然プロセスが死んだりサーバが起動できなくなるのが問題なんだな。
もちろん、OpenVZでも回避する方法はあって、それはただひとつ 「ユーザを大量に詰め込まない」こと。OverCommitが起きない 余裕ある設定であれば当然起きない。
が!!、DTIは他社が廉価VPSを見て焦ったのか、こともあろうに ゲストOSのメモリが2倍使えます! なんて言い出して るわけですよ......バカジャネーノ? DTIは1サーバに恐ろしく大量のユーザを詰め込むつもりだと 確信するに十分な証拠ですよ。ちょっと無頓着過ぎるよね。
1980円も払って(払ってないけど)プロセスが使えるメモリが102MBまでの上に、 スワップも使えないのでは、さすがに実用に耐えない。 せっかく調子良く設定してたけど無料期間終わる前に解約しないとな。 MyDTIで解約も簡単だからいいんだけどね。
当然、自宅鯖にはこんなアフォな制限はないわけである....まだまだVPSは時期尚早といったところか。
さて、SaaSes VPSにいくか さくらのVPSいくか...悩むな。