Aug 15, 2011
■[Web][Linux]最終ログイン日を調べる監査スクリプト
企業がwebサイトを運用してると、殆どの企業でシステムの監査が必要になるかと思います。
監査といっても、何をするのかよくわからなかったりしますが、おそらく
を確認するのが目的だと思います。
具体的に良くあるもののひとつに、サーバのアカウント管理があると思います。
実は情報漏洩の原因ナンバー１は内部犯行です。
それを防ぐために、必要な人だけがサーバにアクセスできる権限を持っていることが望ましいので、最後にログインしてから数ヶ月経過している人は必要に応じてアカウントを廃止する等をしていくことになるかなあと思います。
この手の情報が検索してもあまりでてこないので、僕がやっているシンプルな方法を備忘録をかねて紹介します。
最終ログインが90日前のアカウントを抽出してメールで管理者に知らせるスクリプト
#!/bin/bash #setting MAILADDRESS=（送信先メアド） #mail user list that never logged in lastlog -b 90 | grep "Never" | mail -s "`hostname`: user audit never logged in" $MAILADDRESS #mail user list that logged in before 90 days lastlog -b 90 | grep -v "Never" | mail -s "`hostname`: user audit before 90 days" $MAILADDRESS
lastlogコマンドを使って、最終ログイン日が90日より前の人をメールします。
lastlogコマンドは一度もログインしたことがない人もリストアップするので、上記スクリプトでは運用上便利なように、一度もログインしたことのない人と90日以内にログインしてない人を別々にメールを飛ばすようにしています。
正直言ってワンライナーでかけそうですし、実際lastlogの後もっと複雑／自動化した管理をされている方も多いかと思いますが、初めてシステム管理をするような人の参考になれば良いなあと思います。
Permalink | コメント(0) | トラックバック(0) | 01:19 
Jun 25, 2011
■[Web]DevOpsカンファレンス 2011/06/24に行ってきた。
イベントURL：http://partake.in/events/b5472f43-5bc0-42d0-9469-dc70d7d95b24 (ATNDじゃなかったのがちょっと残念…)
http://d.hatena.ne.jp/marqs/20110625/1308973680
DevOpsってあまりはっきりしない言葉ではあるけれども感覚的に共感しているワード※だったりするのと、CAさんに行きたかったので（笑）参加しました。
※DevOpsについてはMTLブログ「Cloud時代の開発マインド」で触れてます。
WEBサービスでは開発と運用が分かれることはない。
僕は以前から、WEBサービスというのはリリース時点が０スタート、皆様に利用していただくために、サービスを24時間提供し続け、また利用者の為に日々改善をし続ける努力をしなければならないと思っています。
それを実現するためには、開発と運用はそもそも分けられない、どちらも同時に追求していく必要があるし、だから開発->運用に引き渡す、なんてことはおかしな話だと思っています。
WEBサービスは、サービスに関わるすべての人が、利用者のこと、事業のことを考えてないとうまくいかないと思ってます。
なので、銀河さん(@kuwa_tw)が言った
事業が最大化する形で安定させ続ける形にする。
これは素敵なマインドだなあと。
CAさんのように複数のサービスを見ているインフラチームの場合、すごく難しいんですよ。
各サービスごとに利用者、理念、事業が異なるから、どうしてもインフラ部分最適化になりやすい。
だからこそ、障害対応や責任をサービス側で一次受けして切り分けをするような体制にすることで、
事業最大化のために最短の解決策を実施できたりする気がします。
MTLもCAさんとはだいぶ一つ一つの規模が違いますが、少人数でたくさんのサービスを世の中に出すことをしてきたため、そもそもインフラエンジニアがすべてのアプリを把握することは困難な状態。なので僕も障害時はアプリ側で問題切り分けをしたり、アプリエンジニアが簡単にDNS設定したりチューニングをしたりできるような仕組みを構築してきたので、本当に共感しました。
また、りーおさん(@riywo)の
一秒○○円損失がプレッシャー
３月までNIJIBOXに所属していましたので、僕もこれはすごく意識していて、僕を始めインフラエンジニアが過去の経験から得たスキルとマインドを入りたてのアプリエンジニアに注入する努力をしてました。
エンジニアってこの辺ピンと来る人がそれほど多くはないので、なかなか理解は進まなかったり、
実際にアプリが新着トラフィックをさばききれなくて停止、ユーザー損失、○○xxx円損失ということが多く発生してしまっていたのが心残りなのだけど……
その他、メモ
気になったことはtwitterでつぶやいたので、つぶやいたものを下にまとめておきます。
- RT @riywo: 会場で聞こえる単語の5割が「銀河さん」です #devopsjp
- RT @stanaka: ざっくりまとめるとCassandraは運用が難しい、MongoDBは(Redisに比べると)MySQLとの差別化があんまりできてない、というところです。 RT @mass_cut: Cassandra/MongoDBは検証したけど使わず。理由を知りたい #devopsjp
- RT @namikawa: はてなさん、開発エンジニアは14名、運用エンジニアは4人+CTO0.5名 #devopsjp
- 2000VMだから500／人か。#devopsjp
- RT @namikawa: RT @understeer: 性能系の統計データをちゃんと取ってないと、感覚でしか話ができなくなるから、きちんと数字をとっているのはすごい。#devopsjp
- ここは一緒だ。RT @namikawa: 監視のポリシー、極力アラートは減らす、2日は放置できるように(週明け対応でOKなようにしてる。冗長性が確保できない部分は早め対応)、開発エンジニアも担当サービスのアラート。 #devopsjp
- 僕たちもそうです。RT @matsuu: #devopsjp CyberAgentでは、プログラマが監視の一時受け、監視設定をやっている。
- CAさんと自分、考え方が似てるなあ。#devopsjp
- RT @understeer: ５人なので、DevとかOpsとか無いｗｗｗ #devopsjp
- 同じく RT @hisashi: 両方知らないと書けないと思ってる、というのはとても共感。 #devopsjp
- RT @namikawa: 知識の境は持つべきではない！数十億のPVがあるサービスでは、DevもOpsも知らないと続けていけない！同意だ。 #devopsjp
- RT @matsuu: #devopsjp 女の子は１年近く書いてたブログを気分がのらないとかの理由で突然さくっとブログをリセットすることがあるらしい
- RT @masasuz: 内製のソーシャルアプリはGadgetを通さないのか。 だからあんなに速いのか #devopsjp
- タイムアウト頻発で内部DNSやめた口だけど、また頑張ろうかな。 #devopsjp
- RT @nekoruri: MySQLのマスタ自動フェイルオーバのスライド #devopsjp / Automated master failover http://www.slideshare.net/matsunobu/automated-master-failover
最後に：
何となくですが、僕が(MTLが）やっている（きた）こともお話しすると参考になる方がいるのかもしれないなあと思いました。次回エントリーしてみようかな…
これから、参加した勉強会やイベントについて何かメモを残していこうかなと思います。
Permalink | コメント(0) | トラックバック(0) | 22:08
Dec 29, 2009
■[Web]Amazon EC2のイメージ(AMI)をus-eastからus-westにコピーする方法 こぼれ話
Amazon EC2のイメージ(AMI)をus-eastからus-westにコピーする方法 : Media Technology Labs (MTL) : メディアテクノロジーラボ ブログをかなりサマった形で書いたので、ココでは詳細版というかこぼれ話的な感じで書きたいと思います。
1. US-WESTのS3にコピー
既存のEC2インスタンス(us-east-1)にログインして、以下のコマンドを実行。
% ec2-migrate-bundle -k (your private key file) -c (your cert) -a (your access key) -s (your secret access key) --bucket (your source bucket) --manifest (your manifest filename) --location us-west-1 --region us-west-1 --destination-bucket (destination bucket you want to make)
ポイントですが、EC2インスタンスから初めてイメージを保存するときとは異なり、us-west側のS3上にあらかじめbucketを作っておく必要はありません。むしろ既にあると怒られます。" --destination-bucket"にus-westのS3に作成したいbucket名を指定すれば、自動的にbucketを作成し、そこにus-eastのイメージデータをコピーしてくれます。
ググってみると、こちらのように手動でイメージをコピーしなきゃいけないのかなと思い、S3 BucketExplorerを入れてus-westにバケットを切ったり、このドキュメントだけじゃなくフォーラムに質問した際も勧められたので"ec2-migrate-image"コマンドを試したりしたのですが、”ec2-migrate-image”のドキュメントをみると
なんて書いてあったので、上記のコマンドにたどり着きました。そして"ec2-migrate-bundle"ってMacにインストールしたtoolにないよ〜と最新版をインストールし直したりしましたが、EC2インスタンス側にしかないと気づき、EC2にログインし、AMI作るためにアップロードした.pemファイルがまだ残っていたので念のためそのディレクトリに移動し、実行しました。
そしたらS3のBucketは事前に作らなくても良かったと…。
もう一つポイントとして、manifestが"bucketname/hoge/image.manifest.xml"のようにディレクトリを切って階層が深い場合の指定方法ですが、"--bucket bucketname/hoge --manifest image.manifest.xml"と指定すればOKです。
2. AMIを登録する
ElasticFoxでも出来ると思いますが、今回はローカルのMacBookからコマンドを実行しました。
% ec2-register --region us-west-1 --name (your ami name) (your new manifest fullpath on us-west-1)
"--region us-west-1"を忘れずに。
これで完成です。S3のツールやAPIをいっさい触らずに出来ますので、分かってみると非常に簡単でした。でも（自分にとっては）情報が英語だけだとやはり時間がかかりますね…
Permalink | コメント(1) | トラックバック(0) | 09:55
