さくらのクラウドでディスク容量を拡張するのにハマったメモ

【問題】

・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

いけた！
ちゃんとドキュメントは読みましょうという話ですが、うーん、タグで挙動が変わるのは……なんというか裏技では……

AWS SESでメールを受信する

【前提】
某サービスで、独自ドメイン（仮に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: 開始する前に

・AWSへのサインアップとRoute53によるドメインの登録：省略

スステップ 2: ドメインの検証

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]に切り替わっていた。

ステップ 3: 受信ルールの設定

受信ルールセットは、受信するメールに対してどのような処理を行うのかを指定する順序が指定された受信ルールの集合。

受信ルールを作成する

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] を選択。

ステップ 4: テストE メールの送信

hogefuga@hoge.jpにメールすると先ほど作成したs3にメールが溜まっていく。
ダウンロードして内容を確認。
→OK。

おまけ：メールが届いたらSNSからお知らせする

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に保存されると同時に内容を記載したメールが送られてきます。

おまけ２：特定の受信者（Recipients）のみAmazon WorkMailで受信し、それ以外は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による通知を実施

おまけ３：SESで届いたACM承認メールから承認リンクを取り出す

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>"'

オンプレミスからS3にバックアップするときにアップロードの帯域制限したい

【問題】

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 にアップロードが制限」
とのこと。

trickleのインストール

CentOSへのインストールはepelを使用

yum install trickle --enablerepo=epel

aws s3 sync コマンドにtrickleを追記

[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” エラーには明示的に

• s(standaloneモード)をつけることで抑制できる。

参考：https://siguniang.wordpress.com/2015/05/17/throttle-network-bandwidth-per-program-with-trickle/

【現状】
trickle -s -u でやるとCPUの使用率が100%に、ロードアベレージが跳ね上がる等問題がありそうだったので
他の作戦を考えつつ様子見

離席時のスクリーンロックは[Win]+[L]で

離席するときは
[Win]+[L]
でスクリーンロックをかけるようにしよう＞俺

nginxで特定IP以外からのアクセスにメンテ表示

nginxで特定IP以外からのアクセスにメンテ表示する方法メモ

1)メンテ用confファイルを作成

仮に　/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;}

で。

2)nginxのconfファイルから上記mainte.confをincludeする

server {
	……
	include /etc/nginx/function/mainte.conf;
	……
	}

メンテ解除は上記をコメントするか、またはincludeしているファイルの中身を消すなどで。

【AWS Certificate Manager】複数ドメインの証明書を同一ELBで処理する場合の上限

zuntan02.hateblo.jp
これの続き

【問題】

デフォルトだと一つの証明セットに別名を10個以上追加すると
Certificate has too many domains.
というエラーになって申請できない。

docs.aws.amazon.com

Item	Default Limit
Number of ACM Certificates	100
Number of domain names per ACM Certificate	10. See the information following this table.

上記によれば上限緩和申請が効く模様、でも証明書に別名を「追加」できるわけじゃなくて、マルチドメイン証明書の再作成を都度行うことになるので、例えば別名が100個あったら、その100個の承認メールすべてを受信、承認するまで証明書が更新できないことになる。そういう業務オーバーヘッドを認識したうえで申請しろよ、と書いてある。確かにな……でもELB一台2000円くらいするじゃないですか。うーん……

ACM証明書ごとのドメイン名の数：上限緩和申請してみた

https://console.aws.amazon.com/support/home?region=ap-northeast-1#/case/create?issueType=service-limit-increase&limitType=service-code-acm
AWSサポートダッシュボードから50まで上限緩和してほしい旨申請してみた

3日後以下の回答あり

> 制限緩和のリクエスト 1
> サービス: Certificate Manager
> リージョン: アジアパシフィック（東京）
> 制限の名前: (ACM) ACM 証明書ごとのドメイン名の数
> 申請する上限数: 50
> ------------

ご依頼頂きました通り、東京リージョンの ACM 証明書ごとのドメイン名の数の上限値を 50 に設定いたしました。
反映されるまでに数分かかる場合がございますが、予めご了承くださいませ。

エラー出なくなった。20個くらいならまだ運用的には特に問題ない気がする（すべてのドメインについ承認依頼メールを管理アカウントに転送するようにしておけばらくちん）

nginxでのベーシック認証のかけかた

nginxでのベーシック認証のかけかた
参考：
qiita.com

.htpasswd ファイルの作成

# htpasswdコマンドが必要

yum install httpd-tools

ユーザ名とパスワードを追加。

（初回）htpasswd -c /etc/nginx/.htpasswd username
→2回目以降は-cを外さないと.htpasswdが上書きされるので注意
（2回目以降）htpasswd /etc/nginx/.htpasswd username

nginxの設定ファイルの追記

.htpasswd ファイルを読み込み、Basic 認証を適用。
/etc/nginx/nginx.conf

server {
    listen 80;
    root /usr/share/nginx/html;
    index index.html index.htm;

    auth_basic "Restricted";                   # 認証時に表示されるメッセージ
    auth_basic_user_file /etc/nginx/.htpasswd; # .htpasswdファイルのパス
}

特定のIPにはBasic認証を行わない場合

【参考】
http://d.hatena.ne.jp/podhmo/20110311/1299817584

server {
    listen 80;
    root /usr/share/nginx/html;
    index index.html index.htm;

    # add Basic Auth
    satisfy any;
    allow 許可IP1;
    allow 許可IP2;
    deny all;

    auth_basic "Restricted";                   # 認証時に表示されるメッセージ
    auth_basic_user_file /etc/nginx/.htpasswd; # .htpasswdファイルのパス
}

または

特定のIPにはBasic認証を行わない場合(CloudFront+ELB配下）

server {
    listen 80;
    root /usr/share/nginx/html;
    index index.html index.htm;

    # Auth Basic
    auth_basic_user_file /etc/nginx/.htpasswd; # .htpasswdファイルのパス

    set $allow 0;
    if ( $http_x_forwarded_for ~ 111\.111\.111\.111 ){ set $allow 1; }
    if ( $http_x_forwarded_for ~ 111\.111\.111\.112 ){ set $allow 1; }
    if ( $http_user_agent = "ELB-HealthChecker/2.0" ) { set $allow 1; }  #上位TGなどからのヘルスチェックはパスするようにする 

    if ( $allow = 1) {
        set $auth_basic off; #Basic認証off
    }

    if ($allow = "0"){
        set $auth_basic "Restricted";          # 認証時に表示されるメッセージ
    }
    
    auth_basic $auth_basic;
    }

反映

service nginx configtest
service nginx reload