オンプレミス時代の環境に、cronで以下のコマンドを実施しているものがあった
0 0 * * * /usr/sbin/ntpdate ntp.jst.mfeed.ad.jp > /dev/null 2>&1 5 0 * * * /sbin/hwclock --systohc > /dev/null 2>&1
ntpで時間を合わせて、さらにその時間をハードウェアクロックに反映している。
これを仮想化するとき、あれ？ハードウェアクロックってどこになるの？と
思ってググったら以下の様だった。
VMにおけるハードウェアクロックは仮想BIOSが持つ時間
VM停止後のハードウェアクロック情報はBIOSは保持せず消失
VM起動時にESXのシステムクロックをVMのハードウェアクロックとして同期する
【確認したいこと】
・ACMは1証明書あたり10個までの別名。つまり、一つのELBで10ドメインまでしかSSL証明できない。もっと追加したい。
・そもそもELBの443は複数の証明書を乗っけられないのか？
【確認手順】
既にHTTPS/443を使用しているロードバランサに、[追加]でHTTPS/443を追加
→「ロードバランサーのポートを重複して使用することはできません」となり、追加できない。
ダメだ。上限緩和申請するしかないのか。
AWSサポートダッシュボードから50まで上限緩和してほしい旨申請してみたところ、３日くらいでサクッと上限緩和してくれたので、とりあえずそれで。
参考：
http://zuntan02.hateblo.jp/entry/2016/09/28/202538
・100GBのディスクのアーカイブをもとに500GBのディスクを作成してみたところ、領域が拡張さてれなかった。
df -h Filesystem Size Used Avail Use% Mounted on /dev/vda2 95G 7.5G 83G 9% / tmpfs 499M 0 499M 0% /dev/shm lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sr0 11:0 1 1024M 0 rom sr1 11:1 1 1024M 0 rom vda 252:0 0 500G 0 disk |-vda1 252:1 0 4G 0 part [SWAP] `-vda2 252:2 0 96G 0 part /
こんな感じ。500Gのうち100Gしか使われていない。
・アーカイブからそのまま（ディスクサイズ以外は何も修正せずに）起動しただけでは拡張されない。
以下がポイント
・アーカイブのタグ「@size-extendable」をつける
・アーカイブからディスクを作成する際、ホスト名にアーカイブを取った元ホスト名と同じものをつける
さくらナレッジに紹介されている手順http://knowledge.sakura.ad.jp/knowledge/5970/に従えば問題ない。
「アーカイブソース」にtest01のディスクを選択し、タグに「@size-extendable」を付け、右下の「作成」をクリック
アーカイブのタグに「@size-extendable」をつける必要がある。
試しに同じアーカイブで、このタグを外してから同じ手順でディスクを作成してみたところ、ディスクサイズの修正は行われませんでした。
[ディスク]-[＋追加]-[アーカイブ選択]
・先ほど作成したアーカイブを選択し、ディスクサイズを500GBにする。
・接続先サーバに元のサーバを指定
・ホスト名にアーカイブを取った元ホスト名と同じ名前を入力する。
こちらは
とのこと。
ディスクに名前等をつけたら、右下の「作成をクリックし、ディスクを作成します。
省略
省略
ディスク容量の確認
df -h Filesystem Size Used Avail Use% Mounted on /dev/vda2 489G 7.5G 456G 2% / tmpfs 499M 0 499M 0% /dev/shm
いけた！
ちゃんとドキュメントは読みましょうという話ですが、うーん、タグで挙動が変わるのは……なんというか裏技では……
【前提】
某サービスで、独自ドメイン（仮にmail@hoge.jpとする）へのメールをSESで受けてみるメモ。
※これまでは、たまに来る承認メールとかのためにメールサーバを用意してた。
問い合わせなどは別の窓口で対応していたので、ホントに特定のメールが取れれば良い程度。
【参考】
Amazon SES によるメール受信の概念
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/receiving-email-concepts.html
dev.classmethod.jp
→クラスメソッドさんのページに全部書いてある。以下は俺メモ
【手順】
https://docs.aws.amazon.com/ja_jp/ses/latest/DeveloperGuide/receiving-email-getting-started-before.html
こちらからのステップに従って作業を進める
1.Route53を登録しているAWSアカウントでhttps://console.aws.amazon.com/ses の Amazon SES コンソールを開きます。→「SES is not available in アジアパシフィック (東京). Please select another region.」といわれる。2016年11月現在東京リージョンは使用できないので、バージニア北部を利用してみる。
2.[Identity Management]-[Domains]-[Verify a New Domain] を選択
3.Domain:にAmazon Route 53 に登録したドメインの名前を入力、[Generate DKIM Settings] は未選択のままで、[Verify This Domain] を選択。
4.[Verify a New Domain] ページに、DNS サーバーに追加する必要があるレコードが表示されているので、[Use Route 53] を選択。
5.[Use Route 53] ページで、[Domain Verification Record] 、[Email Receiving Record]、および使用するホストゾーンを選択。
6.[Create Record Sets] を選択し、[Domain Identities] リストに戻る。
7.数分間待ってから、コンテンツページの右上にある最新表示ボタン押下、ドメインのステータスが [verified] であることを確認します。
※この時点でRote53を確認すると、MXレコードが[inbound-smtp.us-east-1.amazonaws.com]に切り替わっていた。
受信ルールセットは、受信するメールに対してどのような処理を行うのかを指定する順序が指定された受信ルールの集合。
1.[SES Home]-[Email Receiving]-[Rule Sets]-[Create a Receipt Rule] を選択。
2.[Recipients] ページで、[Next Step] を選択。
※受信者（Recipients）を追加していないため、この受信ルールは、すべての確認済みドメインのすべての受信者宛てのメールを処理します。下記の場合、”*@hoge.jp”あてのメールはすべてs3に保存されることになります。
3.[Add action] メニューから [S3] を選択
4.[S3 bucket] で、[Create S3 bucket] を選択
BucketNmae:mail.hoge.jp（任意）
その他のオプションはデフォルト設定のままにして、[Next Step] を選択。
5.[Rule Details] ページで、ルール名に [rule-for-mail.hoge.jp] と入力し、その他のオプションはデフォルト設定のまま[Next Step] を選択、[Review] ページで、[Create Rule] を選択。
hogefuga@hoge.jpにメールすると先ほど作成したs3にメールが溜まっていく。
ダウンロードして内容を確認。
→OK。
1.[SES Home]-[Email Receiving]-[Rule Sets]で既存のルールをEdit
Action:S3の[SNS Topic]-[Create SNS topic]でSNS topicを作成する
例：
TopicName:hoge-email-recieved
Display Name:hoge-email-recieved
・[Topic ARN] フィールドで、前のタスクで作成したトピック ARNをペーストします。
・[Protocol] ドロップダウンボックスで [Email] を選択します。
・[Endpoint] ボックスに、通知を受信するために使用できる E メールアドレスを入力します。
→[Create subscription] をクリックします。
これで、メールがS3に保存されると同時に内容を記載したメールが送られてきます。
1)WorkMail(1アカウント当たり$4/月)を契約
[Quick setup]→Alias : hoge.jp
[Domains]-[Add domain] : hoge.jp
[Users]-[Create User] : info@hoge.jp
2)[SES]-[Rule Sets]
→WorkMailのルールに以下を設定
1.Recipient：info@hoge.jpのみにする
2.[Action]の[WorkMail]の次に [Stop Rule Set]を追加し、
info@へのメール処理が終わった場合はここで評価を終了するようにする
3.WorkMailのルールを一番最初にする。
【動作】
・info@hoge.jpにメールが来た場合は最初のWorkMailのルールが評価されてWorkMailに落ちる
・hogehoge@hoge.jpなど上記のRecipientにマッチしないメールアドレスに届いた場合は
上のステップ3で作成した[rule-for-mail.hoge.jp]で、S3への保存とSNSによる通知を実施
admin/hostmasterなどすべての宛先に飛ぶため、それぞれのドメイン宛に5通飛ぶ。マルチドメイン証明とかしてると一気に何十通も飛んできて、見つけ出すのが面倒だったので。
# EC2インスタンス上の作業ディレクトリにてS3にたまっているメールを取得
aws s3 cp s3://mail.hoge.jp ./ --recursive
# 以下のコマンドでadmin@へのメールのみあたりをつける
find . -mtime -1 -type f | xargs grep 'To: admin@' | cut -d ":" -f 1 | xargs -I{} sh -c 'grep ^Domain {};grep certificates.amazon.com/approvals?code {} | grep -v "</a>"'
aws s3 sync で5gb程度のdumpファイルをS3にバックアップしていたのだけど、このとき帯域を使い切ってしまうらしく、毎朝3時にデータセンターからping監視アラートが飛んでくる羽目に。
aws cliのconfigでs3の帯域制御を設定する
dev.classmethod.jp
# 帯域制限設定
aws configure set default.s3.max_bandwidth 10MB/s
# 確認
cat /root/.aws/config
[default]
aws_access_key_id=hogehoge
aws_secret_access_key=fugafuga
region=ap-northeast-1
s3 =
max_bandwidth = 10MB/s
★以下はtrickleで解決しようとしたときのメモ。
念のため残しておきます。。
【対策詳細】
trickleについてはこちらが詳しい。
http://apatheia.info/blog/2013/01/01/network-restriction-using-trickle/
「-d nで n KByte/sec にダウンロードが制限」
「-u nで n KByte/sec にアップロードが制限」
とのこと。
[before]
aws s3 sync /hoge/fuga s3://hogehoge/fuga --delete
[after]
trickle -s -u 5000 aws s3 sync /hoge/fuga s3://hogehoge/fuga --delete
# -sオプションについて
なお、“trickle: Could not reach trickled, working independently: No such file or directory” エラーには明示的に
参考：https://siguniang.wordpress.com/2015/05/17/throttle-network-bandwidth-per-program-with-trickle/
【現状】
trickle -s -u でやるとCPUの使用率が100%に、ロードアベレージが跳ね上がる等問題がありそうだったので
他の作戦を考えつつ様子見
離席するときは
[Win]+[L]
でスクリーンロックをかけるようにしよう＞俺
nginxで特定IP以外からのアクセスにメンテ表示する方法メモ
仮に /etc/nginx/function/mainte.conf とします。
if ($uri = '/mainte.html') { set $is_allow_ip 1;} ←mainte.htmlへのリクエストは許可しないとループしちゃう
if ($remote_addr = '127.0.0.1') { set $is_allow_ip 1;} ←許可IPを書いていく
if ($remote_addr = 'xxx.xxx.xxx.xxx') { set $is_allow_ip 1;}
if ($remote_addr = 'xxx.xxx.xxx.xxx') { set $is_allow_ip 1;}
if ($is_allow_ip != '1') {
rewrite ^(.*)$ http://hogefuga/mainte.html? redirect;
}※ELB配下などの場合は
if ($http_x_forwarded_for = 'xxx.xxx.xxx.xxx') { set $is_allow_ip 1;}で。
server {
……
include /etc/nginx/function/mainte.conf;
……
}メンテ解除は上記をコメントするか、またはincludeしているファイルの中身を消すなどで。
