技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について
--------------------------------------------------------------------- ■技術解説：「DNS Reflector Attacks（DNSリフレクター攻撃）」について 株式会社日本レジストリサービス（JPRS） 初版作成 2013/04/18（Thu） --------------------------------------------------------------------- ▼はじめに 2013年3月16日（協定世界時）[CISCO2013]から3月下旬にかけ、迷惑メール 対策の活動を進めている国際組織The Spamhaus Projectに対する攻撃に端を 発する、大規模かつ長期間にわたる分散サービス不能（DDoS）攻撃が発生し ました。 今回の攻撃ではこれまでで最大規模となる300Gbps以上のトラフィ
Re: ChefとCapistranoの境界線 #opschef_ja - Hack like a rolling stone
この間の Chef Casual Talks での id:nekoruri さんの発表、ChefとCapistranoの境界線 に対する 僕の考え方を書いておこうと思います。 Chefを導入する時の「考え方」 完全に同意します。 僕は community cookbooks を使おうとみんなに吹聴して回っているように、 大抵の環境で必要とされる内容は community cookbooks に収録されていることが多いです。 ただ、細く設定ができなかったり、ちょっと代わった入れ方をしたいときが出てくると community's ではカバーできなくなります。 そんなときは僕も fork して書き換える include_recipe して、追加の処理を書き足す (設定ファイルをごそっと上書きしたりとか) あたらしいものを作る などをして回避しています。 例えば、今関わっているお仕事では Apac
Chef Casual Talks Vol.1で「ChefとCapistranoの境界線」について問題提起してきた #eytokyo - めもおきば
ChefとCapistranoの境界線 (Chef Casual Talks Vol.1) #eytokyo #opschef_ja 大きく分けて二つの話をしました。 Chefを導入する時の「考え方」 Chefのような構成管理ツールは万能でやり方もたくさんある(TMTOWTDI)ので、最初にどういうポリシーで組み立てるかが重要になります。今回「本気で使う」にあたり、以下のようなポリシーを設定しました。 原則サーバ上で作業せず、Chefで環境設定を実装する 公開されたcookbooksを再利用する opscode-cookbooksにあればそれを探す communityやgithubにあるcookbookを使う あきらめの心を持つ 必要ならばopscode-cookbook�sなど既存のcookbookをforkして手を入れる 半日調べて難しそうなことはあきらめる(自前Chef recip
日立製作所、Hadoopバッチ処理ソフトを導入したブレードシステムを発表
日立製作所は2013年4月17日、Hadoopを使ってバッチ処理を高速化するために必要なハードウエア/ソフトウエア一式をパッケージ化した製品「かんたんHadoopソリューション for バッチ処理（Asakusa Framework & JP1）」（写真）を発表した。ミドルウエアのインストールや初期導入の手間を省略できる。4月18日に販売を開始し、4月26日に出荷を開始する。 データ集計ソフトであるHadoopのディストリビューションの一つ「Cloudera Hadoop」と、バッチ処理に特化したHadoopフレームワーク「Asakusa Framework」の二つを、ブレードサーバー「HA8000-bd_BD10」（OSはRed Hat Enterprise Linux）とジョブスケジュール実行ソフト「JP1/Automatic Job Management System 3」の環境に導
アドビ システムズ株式会社 に行ってきた！＆ タイプデザイナーに話を聞いてきた！ - 941::blog
Acrobat や Photoshop、Illustrator などで知らぬ者はいない超有名デジタルマーケティングソリューション およびデジタルメディアソリューションを手がける アドビ システムズ株式会社についに行ってきた！ いやー、先日ちらっと紹介させてもらった Lightroom もそうだけど、Web業界で働くようになってから Photoshopやその他ソフトウェアでは大変お世話になっているだけに感慨深いものがございます。 というわけで、早速ご紹介。アドビの広報のばずたんさんに案内してもらったわけですが クリエイティブなツールを手がける会社なだけあってアートが身近にある素敵なオフィスでございました。 今回はいつもの「行ってきた」に加えタイポグラフィ制作を行なっているタイプデザイナーの方にもお話を 聞けちゃったので「聞いてきた」もお届けしちゃう。いやー、すごい１日だった。 エレベーター降
MySQL Casualにおける 事前登録不要/先着順受付 という開催方式に関する報告 - まいんだーのはてなブログ
MySQL Casualという、気づくともう2,3年前くらいからやっているイベントがあります。 このほどそれの第四回を開催できる運びとなり、昨今言われている「ドタキャン/何も言わずに来ない」系のなんとやらをどうにかする施策を打ってみようと思ってやったことについてまとめみたいなのを書いておきます。 結論 参加者の方々を細かく追わなくて良いが、不特定多数を相手にする必要がある場合は今回MySQL Casualが取った「事前登録不要/先着順受付/指定時間で締め切り」という手法が有効です。 参加者の方々を細かく追う必要がある場合においても、受付でケア出来るのであれば有効です。 今後のMySQL Casualについては基本「事前登録不要/先着順受付/指定時間で締め切り」というやり方で行こうと思います。 なぜそうするのか 事前登録した瞬間は行きたいと思っていても、当日までに事情が変わるケースというのは
昔の SSD はタフだった - mura日記 (halfrack)
d:id:halfrack:20130417:1366193468 を見た同僚が教えてくれた X25-M G2 のホストについて、古い SSD はマージンたっぷりだったという話。 このホストは DB サーバだが、メッセージングサービス的なものに使われているので、更新ヘビーで辛い DB になる。 [root@nantokagoe smartmontools-6.1]# uptime 19:29:02 up 1028 days, 2:49, 2 users, load average: 0.00, 0.05, 0.04 [root@nantokagoe smartmontools-6.1]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await
サーバ用途でコンシューマ SSD へ調子に乗って書き込みすぎると壊れるという話 - mura日記 (halfrack)
Crucial M500 の write endurance が 75TB しか無いというのが話題になっていて、同じく 75TB である m4 をわざと虐待していたホストはどうなったのか気になって調べて見たところ、面白い結果が観測されたという話。 石橋を叩いて壊し障害時の挙動を見るべく「自社全サービスのアクセスログを受け止める syslog サーバ」という、どう見ても書き込み中心で SSD にやさしくないホストをあえて動かしていた。具体的には下記のようなノリのホストである。 iostat の一行目なので uptime 数百日における平均値であることに注意。 [root@touge ~]# iostat -k -x -d sda | sed -n '3,4p' Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - sonots/haikanko: haikanko is a fluentd cluster management tool