Exchange OnlineのSMTPサーバ(587ポートTLS)にメールを送るテスト

RailsのAction MailerからExchange Onlineにメールを送ろうとしてなかなか送れない事象に悩まされました。結局の所今回大事だったことは

  • 認証情報が合っているかログインして確認してみる
  • 認証に使ったメールアドレスとメール送信時のMAIL FROMを一致させる必要がある
  • smtp_settingsの:authenticationは :login ではなく login(環境変数で設定する場合はloginでよいということなのかもしれない)
  • SMTP AUTHを個別のメールアドレスごとに有効にする必要がある

ということでした。未来の自分を助けそうなのでメモしておきます。

確認方法

smtp.office365.com:587に対して、Kubernetes上のRailsコンテナからメールを送ろうとしましたがエラーが連発していました。調査のためにSMTPを喋ってメール送信テストをしてみることとしました。 smtp.office365.com:587に接続するためにはSTARTTLSを使うのでOpenSSLが必要です。古いNginxのDocker ImageにはOpenSSLが同梱されているのでそれを使うことにしました。Kubernetesで立ち上げるならこんなマニフェストを食わせてあげれば良いですね。

kubectl apply -f openssl.yaml

apiVersion: v1
kind: Pod
metadata:
  name: openssl
  namespace: default
spec:
  containers:
  - name: openssl
    image: nginx:1.11.13
    command:
      - sleep
      - "3600"
    imagePullPolicy: IfNotPresent
  restartPolicy: Always

Podが立ち上がったらログインしてopensslコマンドでメールを送ります。自分が入力しているところは、SMTPサーバからのレスポンスと区別をしやすいように ">" と書いています。 いろいろ試してわかりましたが、SMTPサーバに接続ができたらEHLOでドメインを教えてあげて、AUTH LOGINでユーザー名とパスワードをそれぞれbase64エンコードしてあげたものを送れば認証が通りました。その後は普通のSMTPと同じでした。

kubectl exec -it openssl -- sh

> openssl s_client -connect smtp.office365.com:587 -starttls smtp -ign_eof -crlf
250 SMTPUTF8
> EHLO example.com
250-TY1XXXXXX.outlook.office365.com Hello [xxx.xxx.xxx.xxx]
250-SIZE 157286400
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-AUTH LOGIN XOAUTH2
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 SMTPUTF8
> AUTH LOGIN
334 VXNlcm5hbWU6 (base64デコードするとわかるが Username: と言っている)
> (printf 'hoge@example.com' | openssl enc -aの値)
334 UGFzc3dvcmQ6 (base64デコードするとわかるが Password: と言っている)
> xxxxxxxxxxxxxxx (printf '<password>' | openssl enc -aの値)
235 2.7.0 Authentication successful
> MAIL FROM: hoge@example.com
250 2.1.0 Sender OK
> RCPT TO: recipient@example.com
250 2.1.5 Recipient OK
> DATA
354 Start mail input; end with <CRLF>.<CRLF>
> from: hoge@example.com
> to: recipient@example.com
> Subject: test
> testmail
> .
250 2.0.0 OK

exchange online smtp starttls とかで調べたものの、意外とすぐに使える情報は出てこなかったのでブログに書きました。Gmailに送る例が多かったので、そのまま参考にならない情報も多かったというのもあります。 SMTP AUTHを個別のメールアドレスごとに有効にするために、Powershellを使う必要があるのが興味深かったです。しかもExchange Online PowerShell というものまであるとは。最近までGoogle Workspaceの世界で生きていたので新鮮に感じました。会社変わっても結局またターミナルからSMTP喋ってメール送信のテストをしていておもしろいですね。。

以下は参考リンクです。

www.workthecode.com docs.microsoft.com docs.microsoft.com docs.microsoft.com

転職エントリ

  • from: 株式会社はてな（2018年9月〜2021年3月）
  • to: 元上司が起業した会社でCTOやることになりました

新しい会社は社長含めて3名の会社でかつ、会社のWebページすら無いので書ける情報があまりありません。隠しているというわけでもないのですが。

在職中にお世話になったみなさまありがとうございました。

責務と業務の図示

責務と業務の関係性を図示しようとしている。

だいたいはマッピングできるのだが、たまにうまくマッピングできないけど現実としてはやっている業務が現れたりしてくる。ポリシーをガチガチにはしたくないからそういうものだというのはわかる。しかし、一つの責務に結びつく業務が多すぎてどう整理したらよいのかわからなくなりつつある。

うまいこと整理して仕事をシンプルにしたり、改善が回りやすいようにしたい

AWSからPolicy Deprecation Noticeを受け取ったときにサクッと影響範囲を調べる方法

最近、AWSさんからPolicy Deprecation Noticeのメールがよく来ています。そんな事言われても…と思っていたのですが、サクッと調べる方法があったのでメモしておきます。(ポリシーはDeprecationになっても、使えなくなるわけではないのですぐに対応が必要ではないようですね)

例えば以下の記事に書いてある「AWSLambdaReadOnlyAccess」 と 「AWSLambdaFullAccess」というAWS管理ポリシーってどこで使っていたかな。調べたい。というときは docs.aws.amazon.com

IAMのマネジメントコンソールで、AWSLambdaReadOnlyAccessを調べるとポリシーARNを得ることができます。 ポリシーARNがあれば、AWS CLIのaws iam list-entities-for-policyを使えば一発です。「指定したマネージドポリシーがアタッチされているすべてのIAMユーザー、グループ、およびロールを一覧表示します。」と機能説明にあります。 docs.aws.amazon.com

$ aws iam list-entities-for-policy --policy-arn arn:aws:iam::aws:policy/AWSLambdaReadOnlyAccess --profile hoge
{
  "PolicyGroups": [
    {
      "GroupName": "Admins"
    }
  ],
  "PolicyUsers": [
    {
      "UserName": "Bob"
    }
  ],
  "PolicyRoles": [
    {
      "RoleName": "testRole"
    }
  ],
  "IsTruncated": false
}

Policy Deprecation Noticeを受け取って調査しようとするまで、この機能があることに全く気がついていませんでした。この方法であれば、複数のAWSアカウントがあってもprofileを切り替えるだけでよいのでPolicy Deprecation Noticeを受け取ってから調査までを自動化することもできそうですね。

レガシーシステム撤去の工夫と所感

レガシーシステム

ここで扱うレガシーシステムは、ソースコード的なものは含みません。主にサーバやシステムのことを指します。そのためレガシーソフトウェア改善ガイドや、レガシーコードからの脱却といった書籍の内容なども登場しません。メンテナンスが行き届かずOSやミドルウェアのEoLを迎えてしまい、泣く泣く再構築することになった体験による工夫がメインのお話です。

自分がやったレガシーシステム撤去

プロキシサーバ移転、メールサーバ移転、社内DNS管理システムの置き換え、Nagios廃止、NFSサーバマネージドサービス化など

進め方

レガシーシステム撤去と立ち向かっている途中からは、SREが二人組としてタスクに取り掛かるバディ制度が取り入れられました。後述しますが、レガシーシステム撤去をするうえで二人組で取り掛かれるのはとても心強かったです。複数のバディから構成されるSREチームに自分はいます。

  • 見積もりとタスク分解
  • 作業前後の図を書く
  • 作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件がないか見てもらう

見積もりとタスク分解

再構築と撤去をするシステムごとに見積もりとタスク分解をしてドキュメントにまとめました。ドキュメントをもとにチームに説明しました。ボツ案もチームに共有することで、チームに対してどこまで技術的な検討をしたのかを共有できました。ボツ案という、実行可能なアイデアのうち最低のものを共有することでチームメンバーに安心感を持ってもらえる効果もあったように思います。

作業前後の図を書く

バディを組んだ相手が得意なムーブがこれでした。レガシーシステム撤去作業前後の図を書くことで、システムを構成する要素の変化が伝わりやすいです。我々は忘れやすいので、数ヶ月後の自分たちも助ける効果があります。

作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件ないか見てもらう

レガシーシステムについての知見はまとまっていてもドキュメントが古くなっていたり、ドキュメントが無かったり、ドキュメントされていない機能があったりします。コード管理されているのに、実際のサーバ上でコードが編集されていてドキュメントとの乖離があるということもありえます。

こうした背景がレガシーシステムの撤去を難しくしています。また、その前段階であるシステム考古学とでも言いたくなる先人の活動の調査や、システムの変化を追っていく作業を難しくしています。

こうした背景があるため、バディで行った見積もりとタスク分解の結果や、作業前後の図が、誤った前提知識や認識により作られた可能性を排除できません。そのために作業着手前にドキュメントレビューを受けて、工数感の共有や見落とし要件がないか見てもらうというステップを設けています。

 

ここまでが自分や自分たちがやってきたレガシーシステム撤去の作業上の工夫でした。ここからは所感コーナーです。

 

レガシーシステム撤去の光と闇

光

レガシーコードの撤去は、使われるかどうかはリリースした後にしかわからない新機能開発に比べて事業貢献になりやすいと友人が言っていました。対象についてのコストやレガシーっぷりがわかっており、やればいい状況であるからということでした。自分も同意する意見でした。レガシーコードであっても、レガシーシステムであってもあてはまるように思いました。しかしアピールしやすいかどうかで言うと、単純な作業をしたと捉えられやすいためにアピール方法は工夫する必要がありそうです。(自分も良いアピールができているとは思えないので、具体的な工夫の方法については書くことができません)

 

闇

レガシーシステム撤去は人によっては精神的な負荷が高いと感じました。先人の活動の調査や、システムの変化を丁寧に追っていく（システム考古学と呼びたくなる）一連の作業は、記憶力の悪い人間(自分)にとっては混乱してしまうことが多くありました。精神的に負荷でした。ここに関しては特にバディ制度に助けられました。幸運なことに僕のバディはこういった作業が得意であり、社歴が長いため知っている過去の経緯も多かったからです。

 

レガシーシステムの撤去は、本質的には本当に捨てていいのかという声との戦いであると思います。調査に時間と労力がかかってしまうことや、必要な確認事項はすでに完了しているのに捨てるアクションを取れていないということがレガシーシステム撤去のブロッカーとなっているのだと思います。事前に合意が取れている確認事項をつぶせたらサクッとつぶす必要があるように思います。そうしないとさらに年単位で生き長らえる可能性があります。それがレガシーシステム撤去の怖いところであるように思います。

 

この記事に書いた内容が、誰かのレガシーシステム撤去に役立てばうれしいです。

投資の勉強

最近投資の勉強をしている。これまでよりも力を入れている。他の理由もあり財務諸表の見方を学んだりしている。

これまでの投資の様子を振り返ってみる。

20代後半は自由なお金が少なかった。NISAが出たばかりの頃くらいから毎月積立で投資信託を数百円か千円くらいずつ買っていた。ここらへんから投資の面白さに気がつく。

投資信託買い続けるのを数年続けていたら、ある程度溜まってきたことや、景気が良かったこともあり一部売って株を買う原資にしたりし始めた。

プチ株で買っていたのが単元化できるまでに育ち、航空会社の株主優待券をもらえるようになった。

結婚してお金を使わなくなったので、NISA枠を使い切ることにした。毎日微量の投資信託を買うようになった。マネーフォワードに証券口座や確定拠出年金の口座を登録しておいて日々成績を見るのが趣味になってきた。

PCゲームをやるのでグラボ大事だよな思っていたのと、最近のAIブームもありGPUの需要高まってるしと適当な理由をつけて微量のNVIDIAの株を買って放置しておいたら2倍以上になっていて、米国株いいじゃんとなった。とはいえバブル感あるような気がしていて怖さも感じている。

 

これまでの投資について振り返ってみた。ごく少額の積立から始めたけど今はその数十倍以上になっている。これから始めてみようかなという人の参考になればうれしいし、こうした会話ができる人がまわりに増えたら更にうれしいと思う。

一方自分の投資の仕方はなんとなく売買してる感じが強い。投資についてさらに勉強し、売買する理由を強化して、結果を振り返れるようにしてもっと投資やっていきたい。