https://www.hirano.cc/blog/ Recent content on blog Hugo -- gohugo.io ja-jp Tue, 24 Nov 2020 00:00:00 +0000 https://www.hirano.cc/blog/dane-for-smtp/ Tue, 24 Nov 2020 00:00:00 +0000 https://www.hirano.cc/blog/dane-for-smtp/ DANEとは DANEとは、MTA-STS同様にメールの配送経路上のメールサーバーとメールサーバーの間の暗号化の仕組みを少し強くするためのものです。 受信側が宣言することで、送信サーバーに対して、 STARTTLSを必ず使う TLS1.0以上、できれば1.2以上を必ず使う DNSSECが検証できなければ配送しない 公開鍵が正しくない場合は配送しない ようにしてもらうことを、お願いする仕組みです。 MTA-STSとの違いは、送信先が正しいということの検証を、証明書のトラストチェーンでおこなうのではなく、DNSSECのトラストチェーンと公開鍵や証明書をDNSの値と比較することで正当性の検証をおこなうというところです。 設定方法 DNSSECの有効 DANEが有効になるためには、DNSSECが有効になっている必要があります。 DNSSECは自分で管理するには敷居が高いので、今回の検証では、QUALITIA DNS QT-DNS(仮)を使用しました。 TLSAレコードの設定 DNSにTLSの公開鍵(のハッシュ)を受信メールサーバー毎に設定します。 他のメールセキュリティの設定とは異なり、TLSAという専用のレコードとして記述します。 また、記述する際のホスト名はメールアドレスのドメインパートではなく、受信メールサーバーのホスト名を使用します。 設定例 例えば、受信メールサーバーがmail1.example.jpの場合、次のように記述します。 _25._tcp.mail1.example.jp. IN TLSA 3 1 1 293F3944E435835EC797ACBBE52FFB1BC8E6637879FBE62D9B6195479E01F67E 3 1 1 の部分の最初の3 1は自分のTLSの公開鍵について記述する場合はお決まりだという程度の認識で大丈夫です。 最後の1はTLSの公開鍵のハッシュ方式を指定しています。0, 1, 2があり、それぞれ、 0. ハッシュしない 1. SHA256でハッシュする 2. SHA512にハッシュする を表します。 「ハッシュしない」はあまり使われないので、SHA256を使用したい場合は3 1 1、SHA512を使用する場合は3 1 2となります。 ハッシュの計算方法 TLSで使用している証明書ファイルcert.pemから公開鍵のハッシュを取り出すには次のようにします。 openssl x509 -in cert.pem -pubkey -noout \ | openssl rsa -pubin -outform DER \ | openssl sha256 少し回りくどいことをしているように見えますが、TLSAレコードに記述するハッシュは、PEM形式の公開鍵ではなく、正味の公開鍵本体部分についてのハッシュなので、このように一旦DER形式に変換した後ハッシュを取得しています。 https://www.hirano.cc/blog/mta-sts%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/ Sun, 22 Nov 2020 00:00:00 +0000 https://www.hirano.cc/blog/mta-sts%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1/ MTA-STSのススメ MTA-STSとは MTA-STSとは、メールの配送経路上のメールサーバーとメールサーバーの間の暗号化の仕組みを少し強くするためのものです。 具体的には、受信側が、送信サーバーに対して STARTTLSを必ず使う TLS1.2以上を必ず使う 証明書が有効でなければ配送しない ようにしてもらうことを、お願いする仕組みです。 STARTTLSだけでは、何が不足なのかということについては、後ほど説明します。 例として、sender.example.comからreceiver.example.jpへのメールの配送を考えてみます。 まず、あらかじめ、receiver.example.jpのメール管理者は、自分のところのreceiver.example.jpにメールを送るときには、ちゃんと暗号化してね、とMTA-STSのポリシーでアピールしておきます。 receiver.example.jpのMTA-STSのポリシーを見たsender.example.comのメールサーバーには、receiver.example.jpには暗号化して送る必要があることがわかるので、きちんと暗号化して送ります。また、暗号化できない場合には送りません。 設定方法 MTA-STSでは、DNSでMTA-STSを利用することを宣言し、Webでポリシーを広告します。 DNSの設定 メールのドメインがexample.jpの場合、ホスト名に_mta-stsを追加して、以下のようなTXTレコードを記述します。 _mta-sts.example.jp. IN TXT "v=STSv1; id=20201122010000" ポリシーの設定 ポリシーはDNSではなくWebに書きます。 httpsでドメインやURLも決まっているのでメール管理者にとっては少し敷居が高いかも知れません。 example.jpに対してMTA-STSのポリシーを公開する場合、次のようなURLになります。 https://mts-sts.example.jp/.well-known/mta-sts.txt ポリシーはGETで取得したときtext/plainとして取得できる必要があります。 ポリシー メール受信サーバーがmx1.example.jp、mx2.example.jpの2つである場合、次のような記述になります。 改行コードはCR/LFです。 version: STSv1 mode: enforce max_age: 86400 mx: mx1.example.jp mx: mx2.example.jp mxはワイルドカードが使用できますので、次のような書き方でも構いません。 version: STSv1 mode: enforce max_age: 86400 mx: *.example.jp TLSレポートについて 長くなったので、別に書きます！ なぜSTARTTLSだけだと不十分なのか MTA-STSはSTARTTLSをより堅牢にする仕組みです。 では、なぜ、STARTTLSだけでは不十分なのかを解説します。 Oppotunisticである STARTTLSはOpportunisticです。 といっても何のことかわからないので、翻訳すると、「STARTTLSは日和見主義です。」 はぁ・・・。やっぱりわかりません。日本語でおkです。 簡単に言うと、STARTTLSはできればやるけれども、できない場合にはやらないということになります。 （日和見というのはできればやりたくない感じがするので、Opportunisticとはちょっと違う気がします。） どういうことかというと、受信サーバーがSTARTTLSに対応してますよ、と言えば送信サーバーはSTARTTLSを使用して暗号化して送るのですが、受信サーバーがSTARTTLSに対応してると言わなければ、送信サーバーはSTARTTLSを使用せず、平文でメールを送信します。 つまり、受信サーバーがSTARTTLSに対応していれば証明書の検証などが行われるのですが、なりすました偽の受信サーバーはSTARTTLSに対応していると言わないことで、証明書の検証などされることもなく、平文でメールを手に入れられます。 MTA-STSを使えば、STARTTLSの使用が必須となるので、サーバーに平文で送信されることはありません。 中間者攻撃に弱い Opportunisticであるということと同じなのですが、経路上でを盗聴・改ざんされた場合、中間者がSTARTTLSを無効にすることが可能です。(STARTTLS Downgrade Attack) また、同様に、TLSのハンドシェイクを改ざんすることで、TLS1.1以下にダウングレードさせ、内容を盗聴することも可能なようです。(TLS Protocol Downgrade Attack) https://www.hirano.cc/blog/mta-sts%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88%E7%B7%A8/ Sun, 22 Nov 2020 00:00:00 +0000 https://www.hirano.cc/blog/mta-sts%E3%81%AE%E3%82%B9%E3%82%B9%E3%83%A1%E3%83%AC%E3%83%9D%E3%83%BC%E3%83%88%E7%B7%A8/ MTA-STSのススメ(レポート編) MTA-STSとは 詳しくは、こちらを参照ください。 MTA-STSのススメ 簡単にいうと、メールの配送経路上のメールサーバーとメールサーバーの間の暗号化の仕組みを少し強くするためのもので、受信側が、送信サーバーに対して STARTTLSを必ず使う TLS1.2以上を必ず使う 証明書が有効でなければ配送しない ようにしてもらうことを、お願いする仕組みです。 TLSレポートとは MTA-STSが成功した、失敗した、という情報をレポート形式で送ってもらう仕組みです。 MTA-STSのmodeがnone以外の時にレポートが作成されます。 MTA-STSが、と書きましたが、DANEでもレポートを送ってくれるそうなのですが、残念ながら、こちらはまだレポートを手に入れられていません。 設定方法 DNSにレポートの送り先を設定します。 メールで送ってもらう場合 example.jpのレポートをhirano@example.comに送る場合、次のように書きます。 _smtp._tls.example.jp. IN TXT "v=TLSRPTv1; rua=mailto:hirano@example.com" レポートの送り先は複数書けますが、DMARCレポートと同じように、mailto:をそれぞれに書くのを忘れないようにしてください。 _smtp._tls.example.jp. IN TXT "v=TLSRPTv1; rua=mailto:hirano@example.com,mailto:admin@example.com" 別ドメインへのレポート送信 DMARCのレポートでは別ドメインへレポートを送信する場合には、レポートを受け取るドメイン側でexample.jp._report._dmarc.example.comのようなDMARCレコードが必要ですが、MTA-STSでは必要ありません。 HTTPSで送りつけてもらう場合 example.jpのレポートをhttps://example.jp/reportにアップロードする例です。 _smtp._tls.example.jp. IN TXT "v=TLSRPTv1; rua=https://example.jp/report" 実は、まだ試したことがないので、どの程度のプロバイダーが対応しているか不明です。 レポート内容 レポートはメールの場合、JSON形式を圧縮したファイルを添付として送られます。 レポートは基本的にはUTCの00:00～24:00までの24時間単位で、集計と同時ではなく、集計後4時間以内のランダムなタイミングで送信されます。 問題がない場合 { "organization-name": "Google Inc.", "date-range": { "start-datetime": "2020-09-07T00:00:00Z", "end-datetime": "2020-09-07T23:59:59Z" }, "contact-info": "smtp-tls-reporting@google.com", "report-id": "2020-09-07T00:00:00Z_hirano.cc", "policies": [ { "policy": { "policy-type": "sts", "policy-string": [ "version: STSv1", "mode: testing", "max_age: 86400", "mx: *. https://www.hirano.cc/blog/aws-lambda%E3%81%A7git%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E4%BD%BF%E3%81%86/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/aws-lambda%E3%81%A7git%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E4%BD%BF%E3%81%86/ AWS Lambdaでgitコマンドを使う AWS Lambdaでgitコマンドを使いたい場合があります。 githubのAPIを呼んだり、dulwichを使ってもいいのですが、新しく勉強するよりは、できれば、いつもの使い慣れたgitコマンドを使いたいものです。 使う物 AWS Lambda用にコマンドとライブラリをいい感じにまとめてくれるDockerコンテナ → https://hub.docker.com/r/qualitiaco/lambda-build-pack gitコマンドとライブラリを抽出 gitコマンドを取り出すスクリプト #!/bin/sh yum install -y git cp -a /usr/bin/git ${OUTPUT_PATH} cp -a /usr/libexec/git-core/git-remote-https ${OUTPUT_PATH} cp -a /usr/libexec/git-core/git-remote-http ${OUTPUT_PATH} yum でgitをインストールし(もしかしたら既に入っているかもしれませんが)、gitコマンド実行に必要な/usr/bin/gitとhttps通信に必要な、/usr/lib/exec/git-code/git-remote-http(s) を${OUTPUT_PATH}ディレクトリにコピーします。 この後のdockerコマンドが、${OUTPUT_PATH}にあるコマンドに必要なライブラリを自動的に抽出してくれます。 今回はyumで入れましたが、最新がよければ、gitこまんどをbuild.shスクリプト内でコンパイルしても構いません。 AWS Lambda環境用のgitコマンドとライブラリの取り出し docker run -it --rm -v $(pwd)/src:/src -v $(pwd)/output:/output qualitiaco/lambda-build-pack AWS Lambdaにアップロードする Lambda Functionの作成 今回はPythonで作成してみます。 さっきできたoutputディレクトリの中に作成します。 import subprocess import os def lambda_handler(event, context): cwd = os.getcwd() os.chdir("/tmp") subprocess.call([ os.path.join(cwd, "git"), f"--exec-path={cwd}", "clone", "https://github.com/qualitiaco/action-lambda-build-pack-sample.git"]) print(open("/tmp/action-lambda-build-pack-sample/src/build.sh", "r"). https://www.hirano.cc/blog/aws-lambda%E3%81%A7%E5%AE%9F%E8%A1%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B%E7%92%B0%E5%A2%83%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/aws-lambda%E3%81%A7%E5%AE%9F%E8%A1%8C%E3%81%A7%E3%81%8D%E3%82%8B%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92%E4%BD%9C%E6%88%90%E3%81%99%E3%82%8B%E7%92%B0%E5%A2%83%E3%82%92%E4%BD%9C%E3%81%A3%E3%81%A6%E3%81%BF%E3%81%9F/ AWS Lambda で実行できるコマンドを作成する環境を作ってみた いったい何の役に立つねんシリーズ。技術の無駄遣い担当の平野です。いや、今回の役に立つはず。 AWS Lambda で Python や Node のスクリプトを書いていると、「あー、この Linux コマンド使えたら便利なのに」と思うときが時々あります。 ということで、Lambda 用に簡単にコマンドを作成、取り出しできる Docker コンテナを作ってみました。 github: https://github.com/qualitiaco/build-pack dockerhub: https://hub.docker.com/r/qualitiaco/lambda-build-pack 今回は、これの解説と使い方を説明したいと思います。 AWS Lambda の実行環境 AWS Lambda で動作しているのと同様の Docker Image が AWS から公開されています。 github: https://github.com/lambci/docker-lambda dockerhub: https://hub.docker.com/u/lambci 今回は、この dockerhub にある、lambci/lambda-base-2 を使ってビルドしてみました。 Build 環境と実行環境 lambci/lambda-base-2 のコンテナイメージには、latest タグと、build タグが存在します。 latest の方が、実際の runtime 環境のベースになるもののようで、lambda-base-2:latest に対して Python や NodeJS の環境が追加された物が lambda の実行環境になる、というようなイメージです。 実際、こちらには yum も gcc も実行時に必要なさそうなものは入っていません。 本物の AWS Lambda では Python や Node が必要とするライブラリも入っていますので、完全に同じというわけではありません。 https://www.hirano.cc/blog/centos8%E3%81%A7unbound%E3%82%92%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB%E3%81%97%E3%81%A6%E4%BD%BF%E3%81%86/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/centos8%E3%81%A7unbound%E3%82%92%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%8B%E3%82%89%E3%82%B3%E3%83%B3%E3%83%91%E3%82%A4%E3%83%AB%E3%81%97%E3%81%A6%E4%BD%BF%E3%81%86/ CentOS8でunboundをソースからコンパイルして使う 現在自宅内でbindを使って権威DNSサーバーとフルリゾルバを混ぜて使っているのですが、リゾルバ部分を分離してunboundで新しく構築してみたいと思います。 せっかくなので、DNSSECの検証もするように設定します。 CentOS8で作りましたが、CentOS7でもdnfをyumにするくらいでできると思います。 下準備 OSに入っているunvoundとunbound-libsを念のため削除します。 dnf remove -y unbound unbound-libs unboundグルーブとunboundユーザーを作成します。OSにすでにunbound-libsがインストールされていた場合にはグループやユーザーがすでに存在しているかも知れません。 groupadd unbound useradd -g unbound -s /sbin/nologin unbound 必要なライブラリをインストールします。 dnf install -y gcc openssl-devel libevent-devel expat-devel systemd-devel インストールと環境設定 unboundのソースをダウンロードしてmake, make installします。 wget https://www.nlnetlabs.nl/downloads/unbound/unbound-1.10.1.tar.gz tar xvzf unbound-1.10.1.tar.gz cd unbound-1.10.1 ./configure --enable-systemd --with-libevent make make install 共有ライブラリを登録します。 echo /usr/local/lib > /etc/ld.so.conf.d/unbound.conf ldconfig サービスに登録します。起動するようにするのは、設定が終わってからにします。 cd contrib cp unbound.service unbound.socket /usr/lib/systemd/system/ unboundユーザが書き込める領域を作成します。 mkdir -p /usr/local/etc/unbound/runtime chown unbound:unbound /usr/local/etc/unbound/runtime 後で行方不明にならないようにunbound.confを/etcにシンボリックリンクしておきます。 ln -s /usr/local/etc/unbound/unbound.conf /etc/unbound. https://www.hirano.cc/blog/docker%E3%81%A7%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E3%81%8D%E3%82%8C%E3%81%84%E3%81%AB%E7%B5%82%E4%BA%86%E3%81%97%E3%81%9F%E3%81%84/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/docker%E3%81%A7%E3%83%97%E3%83%AD%E3%82%BB%E3%82%B9%E3%82%92%E3%81%8D%E3%82%8C%E3%81%84%E3%81%AB%E7%B5%82%E4%BA%86%E3%81%97%E3%81%9F%E3%81%84/ Dockerでプロセスをきれいに終了したい EntrypointがShell Scriptの時、子プログラムを正しく終了させたい。 このようなことを実現する方法です。 前回、Pythonで終了時に必ず何か実行したい で、Pythonのプログラムをkillで停止されても、正しくCleanupするようにする方法について書きました。 そのようなきちんとCleanup処理が書かれているプロクラムをDockerで実行したとき、docker stopで正しくClecnupされる方法について見てみます。 直接Entrypointで実行する場合 main_process.pyという正しくCleanupされるように書かれたプログラムを直接Entrypointに指定してコンテナを作成してみます。 前回 Pythonで終了時に必ず何か実行したいで作成したPythonプログラムを使用します。 FROM alpine RUN apk add python3 WORKDIR / COPY main_process.py / RUN chmod +x /main_process.py ENTRYPOINT /main_process.py # docker build -t cleanup . 実行してみます。 # docker run -it --rm --name cleanup cleanup !!!Set up!!! 別のターミナルからコンテナを停止します。 # docker stop cleanup !!!Clean up!!! ちゃんと、Cleanup処理が走りました。 dockerはEntrypointで指定したプログラムをProcess番号1として起動します。 そして、docker stopは、Process番号1に対してkillを実行します。 mail_process.pyはSIGTERMが来るとClean up!!と表示するようになっているので、このように正しく動作しました。 Shell Script経由で実行する場合 単純に実行する 上記のように、直接Entrypointで指定できれば楽なのですが、環境変数から設定ファイルをゴニョゴニョしてからメインのプログラムを実行するという場合もよくあります。 このような場合の動きを確認してみましょう。 main_process.pyを実行するentry.shを作成して、Entrypointにはentry.shを指定します。 FROM alpine RUN apk add python3 WORKDIR / COPY main_process. https://www.hirano.cc/blog/dovecot%E3%81%8Cfatal-mkdir/usr/local/var/run/dovecot-failed-read-only-file-system%E3%81%A8%E8%A8%80%E3%82%8F%E3%82%8C%E3%81%A6%E8%B5%B7%E5%8B%95%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/dovecot%E3%81%8Cfatal-mkdir/usr/local/var/run/dovecot-failed-read-only-file-system%E3%81%A8%E8%A8%80%E3%82%8F%E3%82%8C%E3%81%A6%E8%B5%B7%E5%8B%95%E3%81%A7%E3%81%8D%E3%81%AA%E3%81%84/ Dovecotが「Fatal: mkdir(/usr/local/var/run/dovecot) failed: Read-only file system」と言われて起動できない 状況 Dovecot(2.3.10.1)をソースからコンパイルしてインストールして、起動しようとすると、「Fatal: mkdir(/usr/local/var/run/dovecot) failed: Read-only file system」と言われて起動できませんでした。 Permissionの問題かと思い、デレクトリをあらかじめ作ったり、ディレクトリのPermissionを777などにするなどいろいろ試しても、最終的に「master: Fatal: chmod() failed for /usr/local/var/run/dovecot/login: Read-only file system」が出て、にっちもさっちもいかなくなりました。 解決方法 /usr/lib/systemd/system/dovecot.service を修正します。 [Service] ... ProtectSystem=false <== full を false に変えます ... systemdの設定をリロードします。 systemctl daemon-reload 参考 https://forum.iredmail.org/topic13321-iredmail-support-dovecot-error-open-failed-readonly-file-system.html https://www.hirano.cc/blog/dovecot%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/dovecot%E3%81%AE%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB/ Dovecotのインストール tar xvzf dovecot-2.3.10.1.tar.gz cd dovecot-2.3.10.1 patch -p1 < ../dovecot_systemd.patch ./configure --with-systemdsystemunitdir=auto make make install groupadd -g 97 dovecot useradd -u 97 -g 97 -d /dev/null -s /sbin/nologin dovecot useradd -u 98 -d /dev/null -s /sbin/nologin dovenull mkdir -p /usr/local/var/run/dovecot/{login,empty} mkdir -p /usr/local/var/lib/dovecot chown root:dovenull /usr/local/var/run/dovecot/login chmod 750 -R /usr/local/var/run/dovecot/login chmod g+s /usr/local/libexec/dovecot/checkpassword-reply 参考 https://plaintext.blog/hosting/mail/qmail.html#dovecot https://github.com/alexh-name/plaintext.blog/blob/master/src/hosting/mail/qmail.txt https://www.hirano.cc/blog/git-clone%E3%81%A7fatal-unable-to-find-remote-helper-for-https-%E3%81%8C%E5%87%BA%E3%81%9F%E3%81%A8%E3%81%8D%E3%81%AE%E5%AF%BE%E5%87%A6%E6%96%B9%E6%B3%95/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/git-clone%E3%81%A7fatal-unable-to-find-remote-helper-for-https-%E3%81%8C%E5%87%BA%E3%81%9F%E3%81%A8%E3%81%8D%E3%81%AE%E5%AF%BE%E5%87%A6%E6%96%B9%E6%B3%95/ git cloneで「fatal: Unable to find remote helper for ‘https’」 が出たときの対処方法 はじめに ググるとlibcurl-develをリンクしろというのが多くひっかかりますが、libcurl-develをリンクしていてもエラーが出るケースがあります。 例えば、最小のgit環境を作ろうと、以下のようにした場合、 FROM centos:7 AS src RUN yum install -y git FROM centos:7 COPY --from=src /usr/bin/git /usr/bin/git ENTRYPOINT ["/bin/sh"] centos7のgitはhttpsにも対応しているのですが、できあがったコンテナではhttpsが利用できません。 # git clone https://github.com/qualitiaco/action-lambda-build-pack-sample.git Cloning into 'action-lambda-build-pack-sample'... warning: templates not found /usr/share/git-core/templates fatal: Unable to find remote helper for 'https' 原因 文字通り「remote helper for ‘https’」というのがないのが原因です。 これは、git-remote-httpsという名前で、/usr/libexec/git-coreの下にあります。 # ls -l /usr/libexec/git-core/git-remote-https -rwxr-xr-x 4 root root 1495272 Dec 10 21:39 /usr/libexec/git-core/git-remote-https 解決方法 /usr/libexec/git-core/git-remote-httpsをコピーします。 https://www.hirano.cc/blog/github-actions%E3%81%A7aws-lambda%E7%94%A8%E3%81%AE%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92build%E3%81%99%E3%82%8B/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/github-actions%E3%81%A7aws-lambda%E7%94%A8%E3%81%AE%E3%82%B3%E3%83%9E%E3%83%B3%E3%83%89%E3%82%92build%E3%81%99%E3%82%8B/ Github ActionsでAWS Lambda用のコマンドをBuildする AWS Lambda で Python や Node のスクリプトを書いていると、「あー、この Linux コマンド使えたら便利なのに」と思うときが時々あります。 そういうときに、便利なBuild用Dockerコンテナを先日作成しました。 → AWS Lambda で実行できるコマンドを作成する環境を作ってみた 今回は、これをgithub actionsにして公開してみたので、その使い方をご紹介します。 https://github.com/marketplace/actions/aws-lambda-build-and-pack Buildスクリプトの作成 今回もAWS Lambda上でdigコマンドを動かしてみたいと思います。 デフォルトのディレクトリ構造 . |-- src | `-- build.sh |-- output `-- .github `-- workflows `-- build.yaml srcディレクトリに下に、ビルドスクリプト、build.shを配置し、Github Actionsを呼び出すと、outputの下にコマンドと必要なライブラリが出力されます。 必要なコマンドの取り出すスクリプト作成 build.shは${OUTPUT_PATH}ディレクトリに必要なコマンドを出力するように書きます。 今回は以下のような Shell Script を src/build.sh として作成します。 AWS Lambda で実行したいコマンドを yum で取得するか、または、コンパイルします コマンドを${OUTPUT_PATH}にコピーします #!/bin/sh OUTPUT_PATH=${OUTPUT_PATH:-output} yum install -y bind-utils cp -a /usr/bin/dig ${OUTPUT_PATH} yumでdigコマンドをインストールして、${OUTPUT_PATH}にコピーするだけのシンプルなスクリプトです。 ここで、ソースをダウンロードしてコンパイルしても構いません。 コマンドを呼び出すAWS Lambda Function 今回もPythonで書いてみます。 https://www.hirano.cc/blog/openvz7-drbd-pacamaker%E3%81%AE%E7%92%B0%E5%A2%83%E3%82%92%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%83%E3%83%97%E3%81%99%E3%82%8B/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/openvz7-drbd-pacamaker%E3%81%AE%E7%92%B0%E5%A2%83%E3%82%92%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%82%A2%E3%83%83%E3%83%97%E3%81%99%E3%82%8B/ OpenVZ7 + DRBD + Pacamakerの環境をバージョンアップする 前に、OpenVZ7をDRBD9.0 + Pacemakerで冗長化するというのを書きましたが、この当時の環境では少し古くなってきてしまいました。 例えば、CentOS8を動かそうとすると、 # prlctl create test --vmtype ct --ostemplate centos-8-x86_64 Creating the Container... Creating cache Processing metadata for centos-8-x86_64 Failed to register the CT: PRL_ERR_VZCTL_OPERATION_FAILED (Details: Creating OS template cache for centos-8-x86_64 template Error: Python directory not found in /vz/pkgenv/rpm414x64 Error: PYTHONPATH variable not defined Creation of Container private area failed ) Failed to create the virtual machine. と怒られてしまいます。 そろそろバージョンアップが必要です。 そこで、この環境のOpenVZ7のバージョンを最新にしてみました。 通常OpenVZのバージョンアップはyum updateをすればいいのですが、この環境はDRBDのカーネルモジュールが入っていますので、こちらも新しいバージョンに合わせる必要があります。 https://www.hirano.cc/blog/openvz7%E3%82%92drbd9.0-pacemaker%E3%81%A7%E5%86%97%E9%95%B7%E5%8C%96%E3%81%99%E3%82%8B/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/openvz7%E3%82%92drbd9.0-pacemaker%E3%81%A7%E5%86%97%E9%95%B7%E5%8C%96%E3%81%99%E3%82%8B/ OpenVZ7をDRBD9.0 + Pacemakerで冗長化する OpenVZに関する記事はいくつか見かけるのですが、OpenVZ7になると極端に情報が不足しています。ましてや、冗長化の情報となると、英語で検索しても全く出てきません。 今回は実際に試してみて、うまくいったようにみえる方法をご紹介します。 もっとこうした方がいいとか、ノウハウを隠し持っている方がいらっしゃれば、ぜひご指摘願います。 事前準備 構成 今回は2台でActive/Standbyの構成を構築します。 1台目(Active): IP: 192.168.111.1 2台目(Standby): IP: 192.168.111.2 Activeな方につながるVIP: 192.168.0.1 のように構成します。 OpenVZ7のインストール OpenVZ7は以前のOpenVZとは異なり、RedHatや別のOSでKernelを入れ替えるという方法ではなく、1つのOSとしてインストールします。 https://download.openvz.org/virtuozzo/releases/7.0/x86_64/iso/ まずは、isoをダウンロードしてOSのインストールを行ってください。下記手順をそのまま実行する場合は、古いISOを持っている場合でも、最新をダウンロードするようにしてください。kernelのソースをyumでインストールするときに、古いisoではバージョンが異なり、はまります。 以下の作業は特に断りがない限り、1台目、2台目両方とも同様に実行します。 全体アップデート まずは、気分よく最新にupdateしておきます。 yum -y update 必要なモジュールのインストール OpenVZ7用のDRBDモジュールは存在しないので、自力でコンパイルするために必要なモジュールです。 yum -y install gcc gcc-c++ vzkernel-devel flex rpm-build po4a automake autoconf RPM用ディレクトリの作成 mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS} とりあえず、再起動 reboot DRBDインストール DRBD Kernel ModuleのCompile cd /usr/local/src wget https://www.linbit.com/downloads/drbd/9.0/drbd-9.0.19-1.tar.gz tar xvzf drbd-9.0.19-1.tar.gz cd drbd-9.0.19-1 make make install modprobe drbd cd .. DRBD コマンドのCompile wget https://www. https://www.hirano.cc/blog/python%E3%81%A7%E7%B5%82%E4%BA%86%E6%99%82%E3%81%AB%E5%BF%85%E3%81%9A%E4%BD%95%E3%81%8B%E5%AE%9F%E8%A1%8C%E3%81%97%E3%81%9F%E3%81%84/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/python%E3%81%A7%E7%B5%82%E4%BA%86%E6%99%82%E3%81%AB%E5%BF%85%E3%81%9A%E4%BD%95%E3%81%8B%E5%AE%9F%E8%A1%8C%E3%81%97%E3%81%9F%E3%81%84/ Pythonで終了時に必ず何か実行したい 途中でディレクトリを作るけど、終了時には残ってて欲しくない。 データベースに仮のデータを置くけど、終了時には残ってて欲しくない。 プログラムが終了したら正常な場合でも、死んだ場合でも、通知して欲しい。 このようなことを実現する方法です。 今回、やりたいこととして、以下のようなものを目指します。 正常な場合にはもちろん実行して欲しい Exceptionが発生しても実行して欲しい Ctrl-Cで止めても実行して欲しい killで止めても実行して欲しい Cleanup処理中は途中で止まらないで欲しい kill -9やSegmentaion Faultはあきらめる いくつかの方法を試してみます。 結論を急ぐ方のために、先に結論を書いておきます。 先に結論 import sys import time import signal def setup(): print("!!!Set up!!!") def cleanup(): print("!!!Clean up!!!") # Cleanup処理いろいろ time.sleep(10) print("!!!Clean up Done!!!") def sig_handler(signum, frame) -> None: sys.exit(1) def main(): setup() signal.signal(signal.SIGTERM, sig_handler) try: # いろいろな処理 time.sleep(60) finally: signal.signal(signal.SIGTERM, signal.SIG_IGN) signal.signal(signal.SIGINT, signal.SIG_IGN) cleanup() signal.signal(signal.SIGTERM, signal.SIG_DFL) signal.signal(signal.SIGINT, signal.SIG_DFL) if __name__ == "__main__": sys.exit(main()) 解説編 準備 setup()/clean()関数とmainの部分を用意しておきます。 https://www.hirano.cc/blog/%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E8%AA%AD%E3%81%BF%E6%96%B9-%E3%83%98%E3%83%83%E3%83%80%E7%B7%A8/ Sat, 28 Mar 2020 08:05:23 +0000 https://www.hirano.cc/blog/%E3%83%A1%E3%83%BC%E3%83%AB%E3%82%BD%E3%83%BC%E3%82%B9%E3%81%AE%E8%AA%AD%E3%81%BF%E6%96%B9-%E3%83%98%E3%83%83%E3%83%80%E7%B7%A8/ メールソースの読み方 (ヘッダ編) はじめに メールソースの特にヘッダ部分について、なるべくセキュリティ的な観点で解説します。 リファレンス形式ではなく読み物形式になっていますので、長ったらしいところもあるかと思いますが、ゆったりとお付き合いください。 また、随時RFCへのリンクを載せていますので、より詳しく知りたい方はそちらもあわせてご覧ください。 メールソースの確認方法 そもそも、メールソースやヘッダをどうやったら見ることができるのでしょうか。 いくつかのメールソフトについて、その方法を説明していきます。 Outlookの場合 ソースを見たいメールをメール一覧からダブルクリックして別ウィンドウで開きます。 ファイルメニューをクリックします。 プロパティを選択します。 下の方にインターネットヘッダーというのがあります。 これが、メールソースのヘッダ部分です。 残念ながら、OUtlookではメールソース全体を見ることはできないのですが、ヘッダについては表示することができます。 Gmailの場合 一覧をクリックしてメールを開きます。 メールの右上の「縦の･･･」をクリックしてメニューを表示します。 「メッセージのソースを表示」をクリックします。 「元のメッセージ」という画面が開き、メールのヘッダを見ることができます。 ただし、ここで表示されるヘッダはわかりやすいように変換されている場合がありますので、本当の生データを見たい場合には、「元メールをダウンロード」をクリックしてメールをダウンロードします。 メールのダウンロードはメニューから直接おこなうことも可能です。 Active! mailの場合 一覧をクリックしてメールを開きます。 「操作を選択」メニューから、「ソース表示」を選択します。 「ソース保存」で直接ダウンロードすることも可能です。 DEEP Mailの場合 一覧をクリックしてメールを開きます。 「その他の操作」メニューから「ヘッダの表示」を選択します。 「ダウンロード」で直接ダウンロードすることも可能です。 メール配送の流れ メールソースの話に入る前に、メールの配送の仕組みについておさらいしておきたいと思います。 メールはSMTPというプロトコルを通して配送されます。 SMTPは1980年代から使われているプロトコルで、1982年にRFC821で定義されて以降、RFC2821(2001年)、RFC5321(2008年)と改良されていますが、基本的な流れは変わっていません。 いくつかのコマンドを介して情報を受信側に伝える仕組みで、その中のDATAというコマンドで渡されるデータが今回取り扱うメールソースにあたります。 送信者側 受信者側 | 接続 | +-------------------------------------->| | | | 220 receiver.example.com ..... | |<--------------------------------------+ | | | EHLO sender.example.jp | +-------------------------------------->| | | | 250-receiver.