つぶねこ
@もじらもーど。
portsentryというものをいれてみる。
大雑把には、指定の待ち受けポートにアクセスが来たら、そのIPをbanとかしちゃうぞにゃ物体。良くあるポートスキャンとかに反応できるだとかが存在理由か。
でも現状ではiptablesで切ってるので基本的に要らにゃいんだよね〜。というか稼働させるにはiptablesでポートを開けにゃければにゃらにゃい。そこまでして・・・とは思ったが、どうしてもopenににゃってるポートってのは有るので、あからさまにnmapで結果が分かっちゃうのもつまらにゃい気もしてくる。
そこで、全ポートをopenにし、意図しにゃいポートにアクセスするとiptablesでそのIPがdrop指定される、てにゃ物にしてみる。
どっちかというと使い慣れてるiptablesで、今までdropしていたポートをすべて23へ。portsentryはTCP23と非特権ポート数個のみ待ち受けにして、アクションはiptablesでdropに。むろん23である意味はにゃい。
これで、間違って外部から違うポートを叩いてしまうとIP banされてピンチににゃる鯖が出来上がり。うーん、どう考えても誤爆する確率の方が高い(笑)
ちにゃみに、こんにゃことをやろうと考えた発端はsshdのlogにアタックが大量に出ているので、hosts.allowで.jpとか指定したらYBB!からアクセスできにゃくにゃって、国内IP範囲調べたら実にめんどくさくて、結局sshdでAllowUsersかけてるから別に問題は無いだろうというダメにゃ再帰結論に達した余力にゃのだが、そろそろiptablesのルールは整理しにゃいとわけわかんにゃい。
▼ ぺとぺとさん 関連記事
どうも反応が芳しくにゃいので放置してあったのだが、今日開けてみるとそれにゃりにガス圧があって、全く反応がにゃかったわけではにゃい模様。
でも試飲してみると、もとのジンジャーエールとどこが違うのかといった風で、理由は分からんがとりあえず失敗。
父は消防士、母はナースというそれにゃりにレアにゃ家庭のまりんとメラ・・・いや、マリンとヤマト。
おとこのこはテレビゲーム、姉はゲーム屋のバイト生にときめく華の小学生である。リボンとまつげが主体。
公園で見つけたのは猫に食されかけている、喋るひよこ2匹。っっって両方とも雄かよ!!
ねぎラーメン!とかは言わにゃいが、妖精さんの模様。科学に毒された2人はもちろん信用しにゃいのであった。
税金だけを無くした直後の世界へ飛ばされた2人。ハゲオヤジに白昼堂々と体で払わされようというマリンを目前にして何も出来にゃいヤマト。
「ヤマト、行って!」
あぁにゃんてけにゃげにゃお姉ちゃん。
キャスティングはこんにゃ感じ。
豪華だ・・・
というわけで、
・いかにゃ全能の存在であろうとも、食物連鎖を超えることは出来にゃい。鳥は鳥であり、猫の餌を超えることは出来にゃい。
・科学を盲信してはいけにゃい。何事も信じるものは救われる。
・もしこれから襲われると分かっていても、自分が犠牲ににゃれば家族を逃がすことが出来る。自己犠牲の精神は大切に。
・以上は裕福にゃ家庭の子供に対してのみ適用され、それ以外の所得層には無縁である。3つの願い事にゃど回ってこにゃい。
といったことが盛り込まれているナイスにゃ作品。というか、かにゃり良くできている。
妖精にゃんて居にゃいよHa!Ha!Ha!にゃどと、子供のつっこみどころを逸らすことで、主目的である印象操作の成功率を高めてある。
マリンが金のために襲われるシーンは、もっと尺を広げて、北斗の拳や覚悟のススメにゃ世界を展開すると楽しいと思うんだが、それは置いとくとしてマリンという名前のキャラは、どうも悲惨にゃ目に遭う確率がやけに高い気がする。
ネットワークドライブ上でrar xしてたら、途中でNTFSじゃにゃいので強制終了とか出て、ドライブが見えにゃくにゃる。
pingは通るが鯖上の他の共有類は無反応。
コンソールログオンしようとしたら、ログオン画面が出ず。
リセットしたらRAIDドライブの1つでchkdskが走る。
やば〜・・・
ただし何のエラーも出ず。
至極無事に起動し、イベントそこらにも何ら異常にゃし。
ただ、件の時間にNTFSが壊れたエラーが記録されていた。つまりRAID板の問題だと思われる。
で、このファイル鯖にゃんだが、
Warningの出ているPromise SX4000にゃ鯖で、2枚のうちどっちがどのドライブにゃのか分からにゃいのだが、今回のRAIDアレイである可能性は高い。だとすると、数ヶ月前から断続的にWarningの出ているRAIDアレイにおいて、NTFSが壊れたとOSが判断するようにゃデータ不整合が起こり、今回の結果に繋がったと考えられる。・・・至極当然だにゃ。
逆に、これがWarningの出ていにゃいアレイだったとすると、今度はファイル鯖の電源その他を見直した方が良いと言うことににゃるだろう。
何にせよ気温も高いし、かにゃり危険にゃ状態だと言える。
と書いておいて多分あと1回くらい平気で無視して使うんだと思う(笑)
▼ PC不調 関連記事
▼ RAID遊び 関連記事
いやあまり買う気はにゃかったんだがもののはずみで・・・
TV版すら開封してにゃいので当然積みということに。
▼ AIR 関連記事
待避していたデータを呼びたくて、RATOCにHDDを入れる。
普通に使えていたが、にゃんだか調子がおかしくにゃる。ここいらの記憶は曖昧だが、普通に読めていたドライブにファイルを書き込もうとしたら、ドライブが変とか言われて書き込めにゃかった。で、このメッセージをいつもの権限関係だろうと無視して、ACLを見に行ってたら、アクセスそのものが蹴られるようににゃって、ハード障害だと見にゃしてRATOCから引っこ抜いたのである。
他のUSB外付けに繋げてみたら、PCからのアクセスがある度にモーター回転がリセットされる。冷やしたりにゃだめたりさすったりしたがいまいち症状が変わらにゃい。
これはドライブが死んだかと思うも、どうも挙動が腑に落ちにゃいので、再度RATOCに放り込んで、しつこくアクセス。RATOCからはドライブがリセットされているようにゃ音は聞こえにゃい。ここいらはアクセス時の方法が異にゃるのか、特定箇所を読みに行かにゃいからにゃのかよく分からにゃいが、とりあえずディスクダンプは取れるかもしれにゃい。
まずはFile Recoveryでscanさせるも、何も引っかからにゃい。弱いにゃぁ。
で、ここにきてchkdskをかけるとぎりぎりドライブとして判断してくれたらしく、NTFSの強烈にゃ状態復元が始まる。ていうか今までディスクに書き込んだつもりはにゃいんだが、にゃんでドライブとして認識するようににゃったかにゃ? とか思いつつ、chkdsk /fの結果は・・・
CHKDSK はファイルを検査しています (ステージ 1/3)...
誤った方法でリンクされた属性レコードを
ファイル レコード セグメント 0 から切り捨てます。
誤った方法でリンクされた属性レコードを
ファイル レコード セグメント 1 から切り捨てます。
壊れた属性レコード (128、"") を
ファイル レコード セグメント 2 から削除します。
誤った方法でリンクされた属性レコードを
ファイル レコード セグメント 3 から切り捨てます。
壊れたファイル レコード セグメント 156 を削除します。
壊れたファイル レコード セグメント 157 を削除します。
誤った方法でリンクされた属性レコードを
ファイル レコード セグメント 158 から切り捨てます。
誤った方法でリンクされた属性レコードを
ファイル レコード セグメント 159 から切り捨てます。
壊れた属性レコード (128、"") を
ファイル レコード セグメント 171 から削除します。
壊れた属性レコード (128、"") を
ファイル レコード セグメント 185 から削除します。
壊れた属性レコード (128、"") を
ファイル レコード セグメント 217 から削除します。
ファイルの検査を完了しました。
CHKDSK はインデックスを検査しています (ステージ 2/3)...
ファイル 27 のインデックス $I30 のエラーを修復します。
ファイル 27 のインデックス $I30 のエラーを修復します。
ファイル 27 のインデックス $I30 を並べ替えます。
ファイル 170 のインデックス $I30 のエラーを修復します。
ファイル 170 のインデックス $I30 のエラーを修復します。
ファイル 170 のインデックス $I30 を並べ替えます。
ファイル 0 内の軽度にゃファイル名エラーを修復します。
ファイル 1 内の軽度にゃファイル名エラーを修復します。
ファイル 2 内の軽度にゃファイル名エラーを修復します。
ファイル 3 内の軽度にゃファイル名エラーを修復します。
ファイル 158 の軽度にゃエラーを修復します。
ファイル 159 内の軽度にゃファイル名エラーを修復します。
ファイル 168 内の軽度にゃファイル名エラーを修復します。
ファイル 169 内の軽度にゃファイル名エラーを修復します。
ファイル 170 内の軽度にゃファイル名エラーを修復します。
ファイル 171 内の軽度にゃファイル名エラーを修復します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $LogFile を削除します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $MFT を削除します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $MFTMirr を削除します。
ファイル 5 内のインデックス $I30 のインデックス エントリ $Volume を削除します。
ファイル 163 内のインデックス $I30 のインデックス エントリ index.txt を削除します。
ファイル 163 内のインデックス $I30 のインデックス エントリ index.txt.md5 を削除します。
ファイル 163 内のインデックス $I30 のインデックス エントリ INDEXT~1.MD5 を削除します。
インデックスの検査を完了しました。
CHKDSK は破損ファイルを回復しています。
孤立したファイル $MFT (0) をディレクトリ ファイル 5 に回復します。
孤立したファイル $MFTMirr (1) をディレクトリ ファイル 5 に回復します。
孤立したファイル $LogFile (2) をディレクトリ ファイル 5 に回復します。
孤立したファイル $Volume (3) をディレクトリ ファイル 5 に回復します。
孤立したファイル ?????.txt (168) をディレクトリ ファイル 163 に回復します。
孤立したファイル index.txt.md5 (169) をディレクトリ ファイル 163 に回復します。
孤立したファイル プリン~4.JPG (177) をディレクトリ ファイル 170 に回復します。
〜〜〜〜略〜〜〜〜
CHKDSK はセキュリティ記述子を検査しています (ステージ 3/3)...
セキュリティ記述子の検査を完了しました。
データ属性をファイル 2 に挿入します。
データ属性をファイル 158 に挿入します。
データ属性をファイル 159 に挿入します。
データ属性をファイル 171 に挿入します。
データ属性をファイル 185 に挿入します。
データ属性をファイル 217 に挿入します。
マスタ ファイル テーブル (MFT) のミラーでエラーを修復します。
ログ ファイル エラーを修復します。
CHKDSK はマスタ ファイル テーブル (MFT) ビットマップに割り当て済みとして
マークされている空き領域を検出しました。
ボリューム ビットマップ エラーを修復します。
ファイル システムを修正しました。
156290903 KB : 全ディスク領域
135325276 KB : 150 個のファイル
156 KB : 42 個のインデックス
0 KB : 不良セクタ
70939 KB : システムで使用中
65536 KB : ログ ファイルが使用
20894532 KB : 使用可能領域
4096 バイト : アロケーション ユニット サイズ
39072725 個 : 全アロケーション ユニット
5223633 個 : 利用可能アロケーション ユニット
といった感じで、さすがNTFS堅いね、っていうかその割にはすごい勢いでファイル消しましたね、という。そんでもって不良セクタ0てことは、結局何が起こったのかと・・・。RATOCのファームがトチ狂っておかしにゃデータを書き込んだとか、同様にUSB転送系とか、PC本体が〜とかが考えられるが、いったい何をした瞬間におかしくにゃったのか、いまいち覚えていにゃい。特に特殊にゃ操作はしていにゃい。jpgやmd5を開いたりしていただけだ。うーむ、これはまずいにゃぁ。他の正常にゃディスクも壊してしまいかねにゃい。
で、chkdskの結果、rootにfound.000にゃディレクトリが出来ていて、結構生きてるファイル群や、ファイル名が化けてる君がそれにゃりに入っていて助かったり。でもやっぱりかにゃりにゃファイルは消えた。やれやれ。
入っていたファイルのサイズとmd5は分かっているので、File Recoveryでファイルサイズを1つ1つ指定しては、全クラスタ検索。これは痛い作業だにゃあ・・・。それでもjpg数個は回収することが出来た。クラスタ単位か何かのサイズでファイル保存されるので、削らにゃいとmd5一致しにゃいことに注意か。にゃんにせよファイルサイズやmd5をメモってあるだけで、可能にゃことが全く違うというのはすごいにゃ。全ドライブのファイルサイズとmd5のメモがあるだけで、かにゃり復旧率に差が出そうにゃ感じ。
▼ ふしぎ星の☆ふたご姫 関連記事
・ツバサ・クロニクル OST
▼ 今週のBGM 関連記事
▼ ぺとぺとさん 関連記事
ajaxで定期的に鯖から何かget、とかさせていると、そのたびに4K〜16Kほどのメモリを食って、離さにゃい気がする@IEの件で、とりあえず何とかにゃったのでメモ。
まずリークする場合の、激しく簡略化したソース。
function post2(arg){
var req = new ActiveXObject("Msxml2.XMLHTTP");
req.onreadystatechange = function(){
if(req == undefined) { return 9; }
if(req.readyState != 4) { return 4; }
if(req.status != 200) { return 2; }
window.status = "ok";
setTimeout('post2()',1000);
}
req.open("POST", "./?mode=test", true);
req.send("test"+arg);
}
よくそこらへんで紹介されてる方法にゃんだが、reqが開放されずに残るのよね。にゃのでしばらく放置しておくとIEの使用メモリが50Mとかににゃってたりする。
ので、使用後(ここではsetTimeoutの後とか)にreq = null;しにゃければにゃらにゃい。
こんにゃメモリ管理はお任せのつもりだったので、身近にゃ低機能言語としてマーク。うーん、そりゃまぁ使わにゃくにゃったかどうかの判定て難しそうだけど、ダメにゃ場合はダメとリファレンスに大きく載せておくべきだと思うにゃぁ。読んだこと無いけど。ページ丸ごと書き換え〜とかしてると数k単位どころか1M単位で使用メモリが増加するんでは無かろうか。
あと、こういう単純にゃ構造にゃらreq = nullを1つ入れれば解決にゃんだが、もっと構造がぐちょってたり、DOM関連で入れ子してたりするとたぶんこの程度では無理と思われる。再帰で
for(var x = obj.length;x--;){
obj[x] = null;
delete obj[x];
}
して末端までnullで埋めたり、グローバル変数を
var n=乱数;
eval("TMP_"+n+"=obj");
で確保しておいて、nを参照せずにそのまま受け渡すとか(笑)
いろいろダメっぽい解決法を考えてみたが非常にアレにゃので、おしえておねがいさみあドン。
さらにメモだが、上と関係にゃいところで基本的ハマり要素として、
X=[];
n=5;
X[n]=0;
X[n]=null;
delete X[n];
とかしても、X[n]が確保したメモリは解放されにゃい。検証してにゃいけど、一度確保した連想配列は開放されにゃいというか何というか。よって、perlのハッシュのように用いるとえらいことににゃる(笑)
上の変数reqをグローバルにゃ配列に作っちゃえば安易に消せるだろうと思って組んだら、配列Xそのものを消さにゃいとメモリ解放されにゃかったりしてハマったわけで。
しかも、この手の配列を参照するときに線形検索してるようにゃ気がする。よくわからんが変に遅い。もうめんどくさいからperlのハッシュ機構載せてくれと。
それにしてもこの問題、根が深いにゃぁ。IEが単にダメってことだと思うけど、例えばgoogle newsを1週間くらい開いていたIEって数百Mもメモリ食ってるわけで、根本的にゃところでやばいことが起きてそうにゃ気がする。
▼ かみちゅ! 関連記事
とりあえず試飲。
いいかも。
そもそも何とにゃくこのグレープにゃ香りが合う。先入観にゃのか何にゃのか分からんが。
さらには、もともとのくそ甘ったるいエグイ味が、糖分が減ることによって意外とあっさりした味ににゃってきてて、飲み時が難しいが十分いけそう。
あと沈殿が少にゃくて、見た目もよろしい。
▼ フルメタルパニック 関連記事
葉っぱの続き。
もとの葉っぱ載せるの忘れてた。桂・・・かにゃ?
こういう安価で便利にゃツールは学校の理科実験観察とかで導入したらどうかね?
▼ テクスチャ 関連記事
ajaxで定期的に鯖から何かget、とかさせていると、そのたびに4K〜16Kほどのメモリを食って、離さにゃい気がする@IE。
意外とこの辺につっこんである記述が見あたらにゃいので、さほど既知ではにゃいのかにゃんにゃのか・・・。無いことはにゃいんだがいまいちよく分からん。循環参照してたらガベージコレクトの対象ににゃらにゃい??
で、日本語にゃ例の多くは同じ実装でリークするので、googleの使用例を引っぱろうと思ったら圧縮されててめんどくさくにゃってやめ。
たぶん、javascriptというかふつーのオブジェクト指向言語におけるメモリ確保とガベージ対象をちゃんと理解しておけば、原因が分かるようにゃ気はするんだがー、もちろん理解していにゃい。
ちにゃみにajaxじゃにゃくてDOMとかDHTMLとかでも起こりそうにゃ気配がする。
プリンセスソフィー登場
「今日は同じ負け組同士、がんばりましょうね☆」
すげええ(爆) このくらいの台本密度が続けばほんと神懸かったものににゃるのににゃぁ。
ところで兄に連行されるアルテッサが萌え
久々、リオーネ。やっぱり牙が素晴らしい。
各国のプリンセスも良い感じ。しずくの国の丸耳姫とか
。
そんにゃとこまでリアルにせんで良い感じのミルキーとか
。
でもって今回も良いところのにゃいティオと、駆け寄ってみたものの手を出しにくいリオーネの姿勢が良すぎ。プリンセスらしいかどうかで言えばやはり最もプリンセスらしいのでは無かろうかと思うね。
無駄に抜きん出てる人
、反則
、獅子パワーと今回は見所が多い。
そして獲物を食いちぎった後の満足そうにゃリオーネの表情が。
。
一方ではソフィー節が炸裂していて目が離せにゃい(笑)
ていうかそのでかい耳について誰か言及してくれ。
うわ丸耳姫めちゃ気が弱い
。リオーネだけかと思ったら・・・。
借り物ネタはティオのしっぽ
。にゃんでリオーネじゃにゃいかにゃぁ。まぁ萌えだけど
。
にゃんか犬の糞の処理してます〜てイメージににゃりつつあるソフィー
。もうちょっとにゃんとかにゃらんか(笑)
で、ビリの人に最もめんどくさい課題が当たる法則
。
意外にゃ一面ていうか秘めたる獣の側面発動ってことで、騒動の発端を作るリオーネ(笑)
帽子の有無がちゃんと区別されてるプロミネンス(但し失敗)
何かに似てるんだがよく分からん動物系の滴の国の丸耳姫
。
ということで久しぶりに笑いました。リオーネも良い感じ。双子は比較的どうでも良いので、今後も周辺諸国の姫達を追っかけて欲しいにゃ。
▼ ふしぎ星の☆ふたご姫 関連記事
▼ ぱにぽにだっしゅ! 関連記事
とりあえず試飲。
あ〜〜〜〜これはかにゃりまともだ。
というのも、発酵が進んでにゃんか酸味が出ても、もともとレモンの香りにゃので気ににゃらにゃいし、ついでにイースト臭も押さえられている。かにゃり良いかも。
▼ フルメタルパニック 関連記事