メモメモメモ

ほんとうにめも

【Laravel】Amazon SESを使って任意のメールアドレスからシステムメールを送信する方法

前提

support@hoge.co.jp（gsuiteなどで作成したメールアドレス）からシステムメールを送信したい

手順

  1. メールアドレスを作成する（今回はGsuite）
  2. Amazon SESで Verify a New Email Address する（メールアドレスの認証）
  3. Amazon SESでSMTP credentialsの設定をする
  4. Laravelの環境変数を設定する
  5. 「Amazon SES サンドボックスの外への移動」する

1. メールアドレスを作成する（今回はGsuite）

gsuiteにログインして、ダッシュボードから「ユーザ」を選択する。 「新しいユーザの追加」をクリックしてユーザを作成する。姓名は「姓: サービス名、名: サポート」とでもしておいて、メールアドレスを作成する。 これだけ。

2. Amazon SESで Verify a New Email Address する（メールアドレスの認証）

AWSにログインして、SESのダッシュボードに行く。 サイドバーのIdentify ManagementセクションにEmail Addressesがあるのでクリックする。 画面上部のVerify a New Email Addressクリックして、先ほど作成したメールアドレスを入力する。 確認メールが届くのでリンクをクリックする。するとSESのメールアドレス一覧にあるVerification Statusがverifiedになってるはず。

3. Amazon SESでSMTP credentialsの設定をする

SESのダッシュボード画面のサイドバーにあるEmail SendingセクションにSMTP Settingsがあるのでクリックする。 Create My SMTP Credentialsボタンが目立つところにあるはずなので、クリックして次のページの右下にある「作成」ボタンをクリックする。 表示される（ダウンロードもできる）認証情報を控えておく。（SMTPユーザ名・SMTPパスワード）

4. Laravelの環境変数を設定する

MAIL_DRIVER=smtp
MAIL_HOST=${SMTP Setting画面に書いてる}
MAIL_PORT=${SMTP Setting画面に書いてる}
MAIL_USERNAME=${3の「SMTPユーザ名」}
MAIL_PASSWORD=${3の「SMTPパスワード」}
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=${1で作成したメールアドレス}
MAIL_FROM_NAME=${サービス名や会社名など任意}

5. 「Amazon SES サンドボックスの外への移動」する

このままだと、認証されたメールアドレスにしかメールを送れない。 「好きなとこから」「好きなメールアドレスに」メールを送信するには、SESアカウントをSESのサンドボックス環境の外に出す必要がある。 これはセキュリティ上の理由で、

全てのSESアカウントはデフォルトでSESサンドボックス内に配置される

ことが原因。 参考リンクが詳しいので詳細は割愛。 解決方法としては、AWSのSupportCenterでService limit increase (サービスの上限緩和)・SES Sending Limits (SES サービスの制限を申請する。

・メーリングリストをどのように構築または取得しますか? ・バウンスや苦情はどのように処理しますか? ・受取人はお客様からの E メールの受信をどのようにオプトアウトできますか? ・このリクエストで指定した送信レートまたは送信クォータは、どのように選択しましたか?

これらの質問に答えなきゃいけない（SupportCenterには答えろとは書いてないが、書かないと申請が通らない）ので面倒。

追記（descriptionの例）

申請理由の説明: メーリングリストは、営業活動によって取得したユーザのメールアドレスになります。
ユーザは、サービス内の「設定」画面からメールの受信をオプトアウトできます。
バウンスメールに関しては、自社システム内で管理して次から同じメールアドレスにメールを送信しないようにしています。
メールの種類: システム通知

参考

【Laravel】AWSのSESメールサーバでユーザー登録時に確認メールを送信するまでの流れ（queueで非同期送信） - s u p ? Amazon SES サンドボックスの外への移動 - Amazon Simple Email Service

セルフホストしたRedashサーバのSSL更新手順

ここに全てがある

gist.github.com

※ To renew the certificate in the future, you can use the following command: セクションに書いてる。

自分がコメントした通り、docker-composeコマンドはdocker-compose.ymlファイルがある場所（/opt/redash）で実行しようね。

https://gist.github.com/arikfr/64c9ff8d2f2b703d4e44fe9e45a7730e

【Laravel】session管理をfileからredisに移行した際に利用したコマンド

Why / What

Laravelはsession管理をデフォルトでfile管理している。 今回アクセス過多によりファイルで管理しきれなくなった（inodeが足りなくなった）ため、redisに移行した。

単にconnectionを変えるだけじゃ既存ユーザたちが強制ログアウトされる（認証セッションもfile管理しているため）ため、 session情報をredisに移行する必要があった。

Code

gist.github.com

参考

stackoverflow.com

www.reddit.com

Laravelで "failed to open stream: No space left on device"エラーが頻発していた

状況

  • Laravel製プロジェクトを本番運用している。
{
   "class": "ErrorException",
   "message": "file_put_contents(\/home\/path_to_project\/storage\/framework\/sessions\/hogehoge): failed to open stream: No space left on device",
   "code": 0,
   "file": 
...

のようなエラーが発生している。

原因調査

No space left on deviceとあるので、文字通り「書き込み可能な領域が足りないのかな」的に万全と思っていた。

原因調査手順

  1. df -hの結果は以下のようになって、容量は空いているそうだった。 （※/dev/xvda1がディスクの容量を表してるらしい） f:id:yooska14:20200204173802p:plain

  2. ディスクに空きがあるなら、 inodeが枯渇してる可能性があると言われた。 inodeの空き状況を見るにはdf -iを実行すれば良いそうだった。 すると、以下のようにInodesとIUsedの値がほぼ同じで、ほぼ容量がないようだった。 f:id:yooska14:20200204174040p:plain

原因調査結論

inodeが枯渇している。これが原因だった。

inodeとは

inodeとは、Linux（Unix系のOS全般）がファイルのメタ情報を管理するためのデータ。

解決した方法

実際に取った方法（即効性あり）

運用してる本番プロジェクトとは別で、不要なファイルがいっぱいあったのでそれを全部削除した。

近い将来やる方法（ちょっと大変）

session情報の管理をファイルではなくredisなど、別サーバで管理する。

感謝

AWSのビジネスサポートに問い合わせたら原因調査から解決指南までやってくれた。 月10,000の価値は大いにある。 自分はインフラの専門家じゃないので安心感ある。

AWS AuroraのデータをBigQueryにインポートするまで

完全に自分のための振り返りメモ。 自分以外は「参考にした」リンクを貼っているのでそっちをメインでみた方が良いかも。

前提

  • AWS Aurora（MySQLl）を使っている
  • BigQueryを使いたい

ゴール

↓こんな風BigQueryにMySQLのデータがインポートされていること。 f:id:yooska14:20191209201402p:plain

手順（目次）

  1. GoogleCloudPlatformのbilling（支払情報）を埋める
  2. Cloud Data Fusion APIを有効にする
  3. Cloud Data Fusionのインスタンスを作成する
  4. 「IAM管理」で、作成したCloud Data FusionインスタンスへのPermissionを設定する
  5. Cloud Data Fusionの「Hub」の「Drivers」セクションで「MySQL JDBC Driver」をダウンロードする（jarファイル）
  6. Cloud Data Fusionの「Hub」の「Drivers」セクションで「MySQL JDBC Plugin」をデプロイする（jarファイルをアップロード）
  7. Cloud Data Fusionの「Hub」の「Pipelines」セクションで「Transfer Data From MySQL to Google BigQuery」を作成する
  8. パイプラインを設定する（Database（MySQL）・BigQuery両方）
  9. パイプラインをデプロイする
  10. パイプラインを実行（Run）する

詰まった

エラー1

cloud data fusionEncountered SQL error while getting query schema: Communications link failure The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.

AuroraのRDSインスタンスのセキュリティグループでGoogle Data Fusionからのアクセスを許可していなかった

参考にした

medium.com

medium.com

medium.com

【ReacNative Expo】"Facebook Policy Warning" : invalid key hashを解決した

経緯

Facebookから AnrdoidでFacebookログインするとクラッシュするから直してね。直さなかったらFacebookログイン機能停止するからねって言う旨のメールがきた。 実際のメール: f:id:yooska14:20191126170730p:plain

確かに、いつからかAndroidでのFacebookログインが失敗するようになっていたようだ。 試してみると、invalid key hash does not match any stored key hashesとエラーが出る。（本番環境で）😭 これはマズいので即刻対応した。

原因

おそらくだが、AAB（Android App Bundle）に対応すると、Facebookで使うKeyHashが変わるみたいだった。 ドキュメント（https://docs.expo.io/versions/latest/sdk/facebook/）にある通り、rRW++LUjmZZ+58EbN5DVhGAnkX4=とexpo fetch:android:hashesの結果をFacebookのKeyHashに入れれば良いはずだが、AAB対応すると別の対応が必要になるっぽい。ドキュメントに明記されてるわけじゃないが、僕の場合それで直ったので書き残しておく。

解決方法

https://github.com/magus/react-native-facebook-login/issues/297#issuecomment-433816732のソリューションが適用できた。 流れを書くと、 1. GooglePlayConsoleの「リリース管理」 > アプリの署名に行く。 2. アプリへの署名証明書セクションのSHA-1 証明書のフィンガープリントをコピーする。 ※CD:A1:EA:A3:5C:5C:68:FB:FA:0A:6B:E5:5A:72:64:DD:26:8D:44:84 のような形になる。SHA1:の部分は必要ないので除く。 3. http://tomeko.net/online_tools/hex_to_base64.phpを開き、Hex Stringの欄にコピーした文字列をペーストする 4. Convertし、結果（base64）をコピーしてFacebookのKeyHashに入れる。

参考・使ったもの

github.com tomeko.net