aws ec2 ebsのディスクサイズを縮小（既存インスタンツからebsブートのAMI作成）

cloud

この方法ではダメな感じ。こちらを参照。

 

試行錯誤、約丸１日。

 

参考にしたサイト。

  1. http://recipe.kc-cloud.jp/archives/3989
  2. http://3u3.org/infrastructure/aws/34

１と２の記述には微妙に違いがある。

  • インスタンツはSTOPする必要があるのか無いのか
  • 稼働中のインスタンツのボリュームを使うのか、それとも稼働中のインスタンツのボリュームのスナップショットから作成されたボリュームを使うのか
  • ラベルの指定方法
  • rsyncの、コピー元とコピー先の指定
  • コピー先のボリュームを利用していたインスタンツにattachする必要があるのか

 

成功したのは、

 

作成元となるebsは、稼働したままスナップショットを作成し、このスナップショットからボリュームを作成したモノをコピー元とする。

 

コピー元、（減量した）コピー先とも、genericなSSDでＯＫ。（元がmagneticであっても）

 

e2lableでのラベル指定は、コピー元のラベルに、コピー先のラベルをあわせる。（ちなみに、うちのは、「_/」であった。）

 

rsyncは、「rsync -ax /larege/ /small」でＯＫ。（「/」に要注意）

 

利用していたインスタンツに（減量）コピー先のボリュームを、/dev/sda1などとしてattachする必要な無し。

 

あと。重要だったのは、コピー先から作られたAMIをローンチする際に、kernelID（あれば、RAMdisk IDも）を指定しないとうまくいかなかった。

 

以上。減量方法と既存インスタンツからebs複製の方法を知りました。

aws。素敵！

 

 

MozRepl::RemoteObjectのTypErrorは仕様？

cloud

xpath->で得た@を、$_->{innerHTML}すると、しばしばTypeErrorでコケる。

 

WWW::Mechaize::Firefoxをnewする際に、bufsizeを、=>10_000_000とか増やしたり、autodieを=>0にしてもダメ。

@の中身を、分割して小さく処理させてもダメ。

Stack Overflowで、getとis_visibleをeval{}でトラップしてる例を参考に、evalを使ってxpath->と$_->{innerHTML}を評価し、プログラム停止をトラップをさせて、ループの先頭に戻してやったら、ウマくいった。

 

なるほど。

TypeError: can't access dead ojbectとか出るので、致命的で不可逆なエラーかと思ったが、やり直しが利く（周知な？）内部エラーの模様。

作者のchangelog、ToDoにも、「！」となっているので、今後もなおる可能性が低い事もあり、これで対応する事にする。

WMFirefoxのxpathでは@hrefがとれない？

cloud

WWW::Mechanize::FirefoxでGoogle画像検索を画像URIで。が。。。

どーしてもxpathで検索結果タイトルの@hrefがとれない。

 

丸2日費やしたがダメ。才能無し。ソース見る根性も無し。

で。

 

h3の[@class="rc"]でごっそり抜いて、

$wmf->xpath('//*[@class="rc"]')

HTML::TreeBuilder::LibXMLであっさり取得。

$tree->findnodes_as_strings('//h3/a/@href')

 

二度手間で、あれだけど・・・これで、よし。と、しよう。

 

大量不正中継検知で、postfixのmynetworks_styleをhostにする

cloud

ログの様子は

 

server dropped connection without sending the initial SMTP greeting (po
rt 25)

 

で、見知らぬホストからの中継をよろしくやっていた。

で。

postfixのmain.cfにある、mynetworks_style=hostをコメントアウト。

（デフォルトは、subnetらしいが・・・）

このサーバは、NTTPCコミュニケーションで、アップデートが終了したCentOSという事もあり、中継無しでよろしかろうと。

 

としたところ、中継が止まった模様。

 

しばらく、様子見。

 

参考

http://www.postfix-jp.info/ML/arc.4/msg00624.html

http://www.obenri.com/_postfix/relay_settings.html

 

DBIx::SunnyとDBIx::Liteでいく

cloud

コネクションは、DBIx::Sunnyで。

DB操作は、DBIx::Liteで。

 

my $dbh = DBIx::Sunny->connect('DBI:mysql:＊＊＊:＊＊＊:3306', 'user', 'passwd');
my $dbix = DBIx::Lite->new(dbh => $dbh);

$dbix->table('＊＊＊')->insert({　}); とか。

 

Schemaいらずで、楽。

 

gpac fc16でもコンパイルできず。

cloud

ビルドバイナリインストールはいいんだけど、amr-nbとかamr-wbとかが絡むとソースビルドが必要。だったと、ずーっと思っている。という事で、fc16の環境ができたので試す。他のOSで過去数年の間に、何度か試したが、ソースビルドが成功したのは、１度か２度程度だったような気がする。

  • http://gpac.wp.mines-telecom.fr/downloads/　からダウンロード。
  • 展開して。
  • INSTALLに手順が書いてあるので、読む。
  • で。--enable-amr するとconfiguerで、や・は・り。Warning。
  • しかし、installはできる。

狙いは、MP4Boxなんで、amr付きでうまくコンパイルできないと心配。気分、悪い。

 

s3fsはまだ苦しい

cloud

ebsでアタッチしたりデタッチしたり、スナップショット撮って、ボリューム作って・・・ってホイホイってな感じでずいぶん便利な世の中になったなーと、実感ですが。

１つのebsをサーバ間で共有。なーんて事は、ま。できない。と。思う。

fedora16にいきなりノったら、えーっとApacheのデーモンが何でいつもの所に無いんだ！ってな躓きに散策していたらs3fsってが、躓きそっちのけでフック。これって使えるのかなってググってら、ありました。

  • ダウンロードは、http://code.google.com/p/s3fs/　から。
  • 展開して普通にmake。インストール。
  • /etc/password-s3fs　にアクセスキーとシークレットキーをしのばせ（？）。
  • マウントポイントを作成。mkdir /s3fs　とする。
  • fuseは、yumでサクッとインスコ。
  • modprobe fuse　して。
  • fusermount {s3のbacket} /s3fs -o default_acl=public-read　であっさりマウント。

使えます。が。

  • s3fs上にmkdirしてもディレクトリは作れない。
  • s3fs上にコピーされたファイルは、オーナー、パーミッション共に表示されない。
  • 転送速度はやはりそれなり。な、感じ。

ってな事で、s3cmdを使って操作しているのとあまり変わらず、ディレクトリ操作ができなかったり、s3側のファイルのオーナー＆パーミッションが見えない。など、メリットを感じられず。

せめて、ディレクトリ操作だけでもできれば。な。と、今後に期待。