カテゴリー別アーカイブ: AWS

EC2 のインスタンスタイプを変更しようとしたらエラー

AWS EC2 のインスタンスで、Create Image で AMI を作成し、別のインスタンスタイプでインスタンスを起動したところ、Unreachable で接続できない状態となってしまった。

再度同じAMIで起動しても現象は変わらず。

AMIを作り直しても現象は変わらず。

システムログを見てみたところ、

cloud-init[2555]: url_helper.py[WARNING]: Calling ‘http://169.254.169.254/2009-04-04/meta-data/instance-id’ failed [13/120s]: request error [HTTPConnectionPool(host=’169.254.169.254′, port=80): Max retries exceeded with url: /2009-04-04/meta-data/instance-id (Caused by <class ‘socket.error’>: [Errno 101] Network is unreachable)]

なエラーが出て止まっている模様。

AWSのサーバにインスタンスIDを問い合わせようとしているのだが、ネットワークがつながっていないのでできない。といったところか。

さらにログを見ていったところ

udev: renamed network interface eth0 to eth1

という一行を発見。

ネットワークデバイスの名前を eth0 から eth1 に変えといたよ!

いやいや変えちゃだめでしょ。eth0 で設定しているんだから。

つまり、ネットワークデバイスは eth1 という名前になったのだが、設定はeth0 で探しに行っているので、ネットワークデバイスが見つからず、ネットワークがつながらず、インスタンスIDが取得できず、インスタンスが正しく起動しない。

ということのようだ。

調べたら

/etc/udev/rules.d/70-persistent-net.rules

というファイルに

SUBSYSTEM==”net”, ACTION==”add”, DRIVERS==”?*”, ATTR{address}==”01:23:45:68:89:ab”, KERNEL==”eth*”, NAME=”eth0″

というような設定があり、ここのMACアドレスがハードのものと違うとリネームされてしまうようでした。

この行の先頭に # をつけてコメントアウトし、Create Image で AMI を再作成した後、再度インスタンスを起動したら問題なく起動できました。

 

 

S3 にインスタンスイメージをアップしようとしたらerror:0D0C50A1

EC2インスタンスのデータを作成してS3にアップしようとしたら以下のエラーが出てしまいました。

ERROR: Error talking to S3: Curl.Error(35): error:0D0C50A1:asn1 encoding routines:ASN1_item_verify:unknown message digest algorithm.

一年前は大丈夫だったんですが、何かが変わってしまったみたいです。

調べてみたら、openssl が古かったようで

yum update openssl

でアップデートをかけたら無事に動くようになりました。

 

Cloud Front の invalidation が有料だなんて知らんかった

AWS からお知らせが来て、Cloud Front の Invalidation にワイルドカード指定ができるようになったらしい。

Invalidation とは、各サーバにキャッシュされたファイルを削除して、新しいファイルが配信されるようにすることです。

Invalidation しないとキャッシュサーバに古いファイルが24時間ぐらい残っているので、元ファイルを更新してもエンドユーザには古いファイルが配信されます。

今までは、ファイル一つ一つを指定して Invalidate していたものが、今回ワイルドカード指定で、例えばあるディレクトリの下のファイル全部、というような指定のしかたができるようになったとのこと。

で、このお知らせに書いてあったのが、Invalidation には費用がかかるということ、最初の1000回は無料だが、それ以降は 1 invalidation 毎に $0.005 かかるそうな。

そんなの知らんかったなぁ。。。

まぁ、私の場合は機械的に Invalidate したりしていないので特に影響は無いのですが、大量に Invalidation する際は注意しましょう。

ワイルドカードを使った場合、該当するファイルがいくつになっても 1 Path 1 Invalidation とカウントするようですので、ワイルドカードを効率的に使えば安くすませられるかもしれません。

 

ERROR with rpm_check_debug vs depsolve

AWS で新規の CentOS 6.5 インスタンスを起動して、最初だから yum update でアップデートしてから始めようとしたら

ERROR with rpm_check_debug vs depsolve:
yum-plugin-fastestmirror is needed by yum-3.2.29-60.el6.centos.noarch
** Found 1 pre-existing rpmdb problem(s), ‘yum check’ output follows:
yum-3.2.29-43.el6.centos.noarch has missing requires of yum-plugin-fastestmirror
Your transaction was saved, rerun it with: yum load-transaction /tmp/yum_save_tx-2015-04-26-08-54pY64yt.yumtx

という、わけのわからんエラーで update が止まってしまう現象となりました。

よくわからんので、おっしゃられるとおり

yum install yum-plugin-fastestmirror

として、インストールしてみたら yum update も通りました。

yum-plugin-fastestmirror は一番速いダウンロードサイトを選択してそこからダウンロードしてくれるプラグインのようです。

にしても、それでエラーになるって本末転倒なような。。。

RDS の Publicly Accessible 設定を変更したい

すでに VPC 内に起動している RDS に既存の EC2(Classic) から接続したくなったので、接続を試してみたら接続できませんでした。

どうやら VPC 内の RDS には VPC 外からは接続できないようです。

ただし、Publicly Accessible という設定が ON になっていれば外からでも接続できるとのこと。

早速 Publicly Accessible の設定をON にすべく、いろいろと調べてみたところ、どうやらこの設定は後から変更することはできないようです。。。

従って、接続できるようにするには、RDS のスナップショットを取り、別のインスタンスを Publicly Accessible ON で起動し、そちらにつなぎ直す、という手順が必要なようだ、、、ちょっとめんどくさいですね。

 

EC2でSMTPサーバを立ち上げたが、トレンドマイクロのブロックリストに載せられてメールが拒否される。

GoogleさんがSMTPサーバを貸してくれなくなったので、仕方なくEC2でSMTPサーバを立ち上げました。

しばらく運用していたらユーザから、メールが戻ってきてしまう、という指摘をもらいました。

戻ってきたメールには以下のようなメッセージが
unavailable; Client host[xxx.xxx.xxx.xxx] blocked using TrendMicro RBL+

どうやら立ち上げたSMTPサーバのアドレスがトレンドマイクロさんのブロックリストに載っていて、メールがブロックされているようだ。

https://ers.trendmicro.com/reputations

でSMTPサーバのIPアドレスを見てみると Reputation: Bad だそうで、このメールサーバからのメールは拒否される。

これは正当なメールサーバだからリストから外してよ、とRequestを送ってみたが

xxx.xxx.xx.xxx is listed on our Dynamic User List (DUL) because
Amazon has told us that this is not a static IP address.

とのことで、 Staticアドレスじゃないのでダメ、アマゾンに以下のお願いをしてください。とのこと

1) properly setup an rDNS for this IP to reference static
2) update us with the latest list

1) は以下のフォームからリクエストできるらしい。

https://portal.aws.amazon.com/gp/aws/html-forms-controller/contactus/ec2-email-limit-rdns-request

このページで設定をお願いしてみる。

Use Case Descriptionに使い方の説明。(use as a smtp serverみたいな)
Elastic IP Address 1にSMTPサーバのIPアドレス(xxx.xxx.xxx.xxxみたいな)
Reverse DNS Record for EIP 1にSMTPサーバのドメイン名(smtp.example.comみたいな)

以上のような情報でリクエストすると

Request to Remove Email Sending Limitations Received
Thank you for submitting your request.
It is our intention to meet your needs.
We will review your use case and normally respond to requests within 2-3 business days.
検討するからちょっと待って。だいたい2~3営業日中には回答します。とのこと。

数時間後、アマゾンから
We have configured the reverse DNS record you requested.
ご所望の設定終わったよ。というメールが届く。

nslookup xxx.xxx.xxx.xxx
で確認してみると、おぉ、ドメインが登録されている。

しかし、この時点で再度

https://ers.trendmicro.com/reputations

を見てみると、まだ Reputation: Bad のままである。

少し待ってみよう。。。

5時間ぐらい待ってみたが Reputation は変わっていないので、再度Trend Microに以下のようなRequestを送ってみる。

Amazon has properly setup an rDNS for this IP.
Could you please remove this IP from the blocked list?

しかし、数分後に一回目と同じ内容(アマゾンにお願いしてください)のメールが届く。
どうやら Trend Micro は Amazon の IP アドレスで削除依頼がくると定型の文章で返信しているようだ。

仕方がないのでしばらく待つことにする。。。

翌日、確認してみるが Reputation : Bad のまま。。。

2日後、確認したところ Reputation : Unlisted in the spam sender list になっていました!

めでたしめでたし。

 

EC2 で新しいインスタンスを立ち上げたが root でログインできない

EC2 で、Community Instance を使い、新しいSecurity Group と Key Pair を作って起動したのだが、秘密鍵を指定して root でログインしようとすると、まずは root 以外でログインしてください、というメッセージが出てログインできませんでした。

いろいろと調べた結果、作成した秘密鍵で ec2-user というユーザ名でログインできました。

ログイン後に
sudo su
とすれば root になれるので、そこで root のパスワード設定など必要な処理を行いました。

ec2-user というユーザ名は AMI によって違うかもしれませんが、迷ったので備忘録として書きました。

 

AWS EBSボリュームの容量が実容量よりも小さく表示される

EC2でマーケットプレイスにあるインスタンスイメージを起動するときにEBSのサイズを10GB から 20GB に変更して起動したのだが、起動した後に df コマンドで見てみるとサイズが10GB のままになっていました。

でも EBSの設定をみると 20GB になっているので料金は 20GB 分取られているわけです。

そんなときは、df コマンドで確認したデバイス名に対して以下のコマンドを実行して、容量がフルに使えるようにします。

# resize2fs /dev/xvda1

* /dev/xvda1 の部分は自分の環境に合わせた名前にしてください。

# df
Filesystem     1K-blocks    Used Available Use% Mounted on
/dev/xvda1      20642428 1335708  18258272   7% /
none              302208       0    302208   0% /dev/shm

以上で無事 20GB が使えるようになりました。

 

AWS EC2 インスタンスタイプの変更手順

EC2で運用しているサーバの負荷が減ってきたのでインスタンスタイプを変更してコスト削減を図ることにしました。

以下の手順はEBSインスタンスの場合の手順です。

EBSインスタンスかどうかを知るにはAWSマネジメントコンソールでEC2のインスタンスを選択し、Description のところのRoot device type が ebs になっているかどうかを見ます。

EBSであれば以下の手順でインスタンスタイプを変更できます。

  1. AWSマネジメントコンソールで対象となるEC2のインスタンスを選択
  2. Actions -> Stop を選択し、インスタンスを停止
  3. Instance State が Stopped の状態になったら Actions -> Change Instance Type を選択し、変更したいInstance Type を選んで Apply をクリック
  4. Actions -> Start を選択し、インスタンスを起動
  5. Instance State が Running の状態になったら、Elastic IP をインスタンスに関連付ける(Elastic IPを使用している場合のみ)