AWSの認証キーを奪われて仮想通貨を採掘される攻撃が発覚
クラウド環境を悪用した仮想通貨の採掘が密かに行われているようです。今回発覚したのはLuke Chadwick氏のAWSのキーがGitHub上にアップされているのを発見した何者かが、20台ものcc2.8xlargeインスタンスを起動させてBitCoinプロトコルを使った仮想通貨であるlitecoinの採掘を行ったとの事です。 AWSからの警告で気がつき、インスタンスを停止するまでの数日間で利用料金は3000ドルを越えたとの事です。 Litecoinは、世界中の誰に対してもすぐに支払えるP2Pの仮想通貨です。Bitcoinプロトコルに基づいていますが、一般のハードウェアを用いて効率的にデータマイニングできるという点でBitcoinと異なります。Litecoinは素早い取引認証（平均2分半）を実現し、多くの人が所有している一般コンピュータとGPUをターゲットにするメモリーハード、scryptベー
僕がホスティングサービスで学び考え、取り組んだこと。 | Pocketstudio.jp log3
踊るホスティティングサービス 変化を強いられる時代 壁を越え、進む あの日僕が BASIC に挫折した事を忘れない オープンソースを積極活用、そして一次対応へ 閾値主義からの脱却 一次対応の闇 一度は仕事を辞める覚悟をした 正直、もう人間が運用や監視対応するのは限界かもしれない Serf the Librator ――運用対応自動化が、進化への鍵か 今日よりも鮮やかに 概要と書きたかったこと 師走です。年の瀬ですね。寒くなりましたね。コタツが恋しいです。ミカンおいしいです(^q^) そんな季節柄、ふと、自分の仕事を振り返りたくなりました。 僕はこれまで、ホスティングサービスの中の人として歩んできました。自分が何を考え、どのように行動を起こしてきたか。その経緯は、今の自分しか書けない気がして。色々なスライドや twitter では伝えきれなかった事を、一度まとめたいなぁと。なので、こうやって
MacからVagrantコマンド一発でSSDなVPS(DigitalOcean)上にCentOS6.5+Docker環境を構築する - Glide Note
前回のVagrantとSSDなVPS(Digital Ocean)で1時間1円の使い捨て高速サーバ環境を構築する - Glide Note - グライドノートの続き。 Vagtant+DigitalOceanだけでも十分便利なんですが、先日CentOS6.5がリリースされ、正式にDockerがサポートされたので、DigitalOcean上にCentOS 6.5+Dockerな環境を用意してみる。 といっても、2013年12月20日現在DigitalOceanではCentOS 6.5なimageが提供されていないので、選択出来るCentOS 6.4のイメージを使いながら、Vagrantを利用してコマンド一発でCentOS 6.5+Docker環境が作れるようにした。 glidenote/vagrant-docker-digitalocean これは何 Vagrantを利用して、Digital
Spring XMLでCamelを書いて、twitterとelasticsearchを連携(Apache Camel入門 その3 Spring XMLについて) - Taste of Tech Topics
こんにちは、もっと多くのJava技術者がCamelで楽できるはずと信じているツカノ(@snuffkin)です。 前回は、発達したJavaのエコシステムの恩恵にあずかり、実質数行のJavaコードで、twitterとelasticsearchを連携させることができました。 今回は、Spring XMLでCamelを記述することで、twitterとelasticsearchを連携させてみましょう。 「Camelって何？」って人は、前回までの内容を確認しておきましょう。 Apache Camel入門(その1 OSSをつなぐOSS) - Taste of Tech Topics twitterとelasticsearchを簡単に連携させる(Apache Camel入門 その2 コンポーネントについて) - Taste of Tech Topics CamelのDSLについて これまで説明してきたCa
InnoDBのREPEATABLE READにおけるLocking Readについての注意点
本日は、MySQL Casual Advent Calendar 2013の20日目である。というわけでカジュアルに小ネタを紹介しよう。 MVCC - Multi Version Concurrency Controlご存知の通り、InnoDBはMVCCを実装している。そのため、分離レベルがREPEATABLE READの場合には、行にロックをかけることなく、一貫した読み取りが可能になっている。 もし、あるトランザクションT1開始後に、別のトランザクションT2によって同じ行が書き換えられてしまった場合には、T1はロールバックセグメントにある古いバージョンの値を読み取ることができるので、T1内で実行したSELECTは常にT1開始時点のデータを参照することができるのである。大事なのでもう一度言うが、REPEATABLE READにおける単純なSELECTでは行ロックは必要ない。 Lost Up
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
